In this week's
KDE CVS-Digest (experimental layout):
KPDF adds zoom, search, thumbnails and is optimized.
Kontact now supports Kolab version 2.
Krita adds startup templates.
khtml improves the outline painting algorithm.
Kopete merges Novell GroupWise Messenger support into HEAD.
Plastik style optimized.
Dot Categories:
Comments
I really like the new layout, but I think the "next" link should be somewhat clearer (perhaps a picture aside the link). A "back" link would be nice, too :) And perhaps you can also place these links on the top of the page, and not only on the bottom? Just some suggestions :)
I think the word wrapping is somewhat wrong, you have to scroll sideways if your window is less than 1085 Pixel wide. Thats way too much.
Otherwise the Layout looks good
Fabio
Good idea. The footer is not even close to being finished.
Derek
1. This grey looks sadly :(
2. New category of browsing would be good: By branch. At least - HEAD, last stable, other.
3. Something should be done with width of content. It doesn't fit on my 1024x768. Probably the most common resolution of monitors on the web.
4. For dial-upers all-in-one format is veeery useful. Please, keep it somewhere.
Yes please: keep one "All in one" page
Any suggestions on color?
A branch category is in the works.
The all in one format will stay.
Derek
Color: I like CFE6E7 (it's kruler fault if wrong ;) of current Digest design. Why change it?
Branch: don't put too much work in it. I think three subcategories would be enough - HEAD - for curious what is going on the bleeding edge; Last Stable - which fixes/features are backported; the rest - I suppose there is miriad of small, temporary branches and creating subcategory for each one would rather destroy readability of this category than improve it.
Thanks once again for Digest.
There are two things I would like to accomplish with a branch category.
Identify backported fixes: Most right now go into KDE_3_3_BRANCH or 3.2 etc. This is useful information.
Watch development branches: We will have a KDE_4 branch in the near future. Or maybe the opposite, a KDE_3_4_?? and HEAD will be kde4 material. Either way there will be some interesting things happening in both places. Right now kpdf is being reworked in a branch. Kolab 2 stuff was in a branch. Kopete Groupwise support was in a branch (the last two were merged into HEAD this week).
The only manual intervention in the Digest is the summary, commentary and selecting the commits to highlight. The rest is generated by php script, including the tables in the left column. So the challenge with a branch category is to have it generate something logical. And not use too many resources in generating the table, since it is generated dynamically. The only things that are cached are the commit logs. Branch names are derived from the cvs logs, which would entail cvs lookups on most selection entries. That would be too slow. Hence the challenge.
Derek
What the heck is that? Because it sure isn't HTML.
I really hope Quanta didn't generate that.
Agree! Please use valid HTML/XHTML.
Quanta generates (by itself) very little code, and that should be standard compliant. Otherwise even if Derek uses Quanta for CVS-digest, the code is whatever he wrote there.
Andras
As much as I would like to blame someone else, any bugs are of my own doing.
I must add that Quanta rocks. I use it for php and html coding. It even has a spell checker.
Derek
First of all and most important; thanks a lot for the Digest every week, I enjoy every time I read it.
About the experimental layout;
- please also add a one page layout.
- you have created some sort of filtering (By Module, By Category, By Type), please add a "By Branch" to this filter.
- about the filtering; I think it would we nicer to be able to combine these filters, by creating checkboxes for all possibilities for four categories (By Module, By Category, By Type, By Branch). Readers can select the combination they find interesting. Create a cookie to remember the preference of the reader.
- try to create a more w3c-compliant website.
Off Topic:
By the way, at amule.org they are reaporting core and gui separation is alomst done. To me, amule is the best client for the e2dk network, a kde gui for it could be great!
It's already there and named krdc. The only thing missing is a popup-feature like kopete, one click-open from systray, next click-close to systray.
Huh?
Krdc = KDE Remote Desktop Control
Amule = client to de ed2k p2p network
It's Qt (cute), not QT (QuickTime). Thanks. ;)
It's also KDE, not Kde. :)
The kile link goes to http://kile.sourceforget.net/download.php
when it should really go to http://kile.sourceforge.net/download.php
Thanks for the digest Derek
-Sam
Amarok is a great player and I'm willing to test the 1.1 version. Anyone knows where can I find rpms of it for suse 9.1?
Use a CVS-Snapshot from http://amarok.kde.org until 1.1-final is released.
I'm hoping not to compile it by myself.
You see, I'm using Suse 9.1 personal, that dosen't come even with gcc, so every devel package I have to install is a long download :)
But I can give it a try, maybe, by lucky, I already have all the necessary packages... (I doubt that the the shot is free)
Not mentioned in Digest (or too late to include in this issue):
Plastik is now in kdelibs, no need to install kdeartwork to get this slick theme :)
m.
..and default!!! Finally! :-)
You're kidding me!
Plastik default? No, really... that sounds too great to be true - especially _before_ the 3.x line is ending.
I think this would (at best) meant plastik might be default in 3.4 ... not in 3.3.1, would it?
AFAIK it´ll be the default for 3.4.0.
Too bad. Plastik is about as visually interesting as Windows 98, and it seems kinda slow, too.
Ah, well. At least Keramik is staying part of the core, so I can switch over before I nod off.
No, it is not a joke (for KDE 3.4).
See the thread:
http://lists.kde.org/?t=109500725600001&r=2&w=2
Have a nice day!
Thanks for the info.
I've always been one of those asking for Plastik as default (or for something else than Keramik for that matter), so this is good news.
Thanks.
And its been optimized greatly...
Faster than keramik now!
Top-quality work by Sandro Giessl!
full ack!
Optimizing is so important, we users just are mad about it!
Where can I read about this optimization?
Check out the CVS Digest... ;)
New in this version:
* Animated systray icon with progress display
Could all the animation be disabled please? The flashing playing song is simply unnecessary, but the blinking "play icon" is really annoying.
* Third category for Collection filtering
A third category is fine, but the collection sorting algo is even worse than 1.0.x with soundtracks, which have multiple interprets. Having 20 different entities for one album, just because you want to sort by interpret and then by album, sucks.
Animated systray:
Sorry, but we're really into animations and flashy stuff :) We try to avoid adding yet another option, if not absolutely necessary.
A blinking icon in my systray is absolutely unnecessary. This means one user less, but I guess you don't count.
Yeah, I guess you don't count. Bye!
I'm not sure yet as I haven't tried it, but I think constant change in the systray would be very distracting over time.
I like amaroKs overall flashy feel, but this might interfere with the use of other applications.
Simple scenario is if you have KMail set up to display the number of new messages in the sstray - so if there is a change in the systray you would look at it and notice there's a new mail. With amarok doing it's flashy stuff in the systray you'd either constantly be staring at your systray waiting for new mail or not notice the (minor) change of the kmail icon at all because amarok does it's magic all the time and thus the little kmail icon is less noticeable.
It's probably a bit of an over-dramatization, but I guess that's how one makes a point ;)
Anyway I'd like that one-more (tm) little option to disable it, too :)
None of the regular developers are willing to maintain a deflashification option. If someone wants to make the patch, make it well, and maintain it. It would probably be accepted.
The main issue for me is the many areas that branches would be required. The code would be nasty.
I gotta agree that we should make the play icon not flash and instead make the pause icon flash in the systray.
I also think we should totally ignore Carlo, he's one of those irritating "Do as I say or I'll use Noatun" people.
>I also think we should totally ignore Carlo, he's one of those irritating "Do as I say or I'll use Noatun" people.
You are free to ignore me and opensource developers are free to code what they want, of course. I'm a bit astonished about your impoliteness Max. Maybe you should think about, why you can't stand positive criticism.
> >I also think we should totally ignore Carlo,
> I'm a bit astonished about your impoliteness Max.
Maybe if you should both take it down a notch.
Carlo: You're were not exactly being tactful, what'd you expect?
Max: Maybe a clarification on why it not as distracting as people in this thread (Not just Carlo) fear would have been less inflamatory.
Something like:
It's not really as big a deal as you all may think; It's not so much a flashing icon, but a progress indicator. The icon is saturated from the bottom up (think filling a glass) as a progress indicator.
I just downloaded and installed from CVS. I don't care too much for the animated icon, but it's not distracting to me.
I prefer it over noatun or juk by a large margin.
Keep up the good work.
>Carlo: You're were not exactly being tactful, what'd you expect?
Eh? I neither intended nor did attack anyone personally. And I really won't excuse myself for having an opinion.
You pulled a tantrum and "threatened" the developers. That kind of behaviour doesn't really impress people.
Thank you for enhancing my english vocabulary. ;) I agree. My statement, that I would have to drop amaroK, wasn't that nice, even though the perception, that I intended to "threaten" developers is not correct. It's a bit frustrating reading "Sorry, but we're really into animations and flashy stuff" when you're interested in a functional application, which does not consume more cpu cycles than necessary and seeing the most promising kde audio application being pushed in an (not opposite, but still) other direction. That a constantly blinking icon in the tray would force me, not to use it, doesn't mean, that I do not respect the work of the developers of amaroK.
> And I really won't excuse myself for having an opinion.
And you shouldn't. But adding "This means one less user" to your opinion is not exactly tactful.
Besides, as I said before: It's not a blinking icon anyways. I think this is getting blown out of proportion.
Disclaimer: I pulled source from CVS, so it could be the systray thing changed after the release.
yeah, can't tell of anything more annoying than something like that jumping on my systray constantly. If I see something changing there immediately calls my attention (kopete messages for example)
Please add an option to disable the animation. Even if it is juts a config file option with no gui or users have to replace icon files. The systray relly shouldn't blink when it does not need to drw attention to a new event.
Yes, I hope too that there will be a simple way to disable that disturbing and unnecessary icon.
I don't like a flashing icon in the system tray either.
It's very very annoying.
I hate it when webpages for example have animated banners on them, because when I read on that page, I'm constantly distracted from the text, which makes reading that page very difficult.
Luckely, I can disable the banner animations in my browser.
Amarok won't let you disable it, so this means that if I have Amarok playing something, and I'm reading a text on my pc, it will be extremely difficult to focus on the text as the flashing icon is constantly grabbing my attention.
Please, pretty please, add those couple of lines of code to disable the animation timer if the user wants to. Please.