In this week's KDE Commit-Digest: The KDE Commit-Digest 2006 retrospective. blinKen and KNetWalk become the latest applications to move to scalable graphics. KSquares further develops, with an AI player implemented. More maps and a more sophisticated divisions and capitals implementation in KGeography. Support for password-protected RAR archives in the kio_rar interface. Work to support drag-and-drop of transfers in KGet. Import of "koregressions" test suite for KOffice. Longstanding KWeather and KHTML bugs fixed. Major refactoring in the "sonnet" natural language checker. Version 1.0 of Eigen, the library for vector and matrix math, is released.
Dot Categories:
Comments
Thanks, and a happy new year!
2007 will be a great year for KDE =)
11:16pm local time and I just walked in the door from a restaurant and checked for the digest.
Is it crazier that I'm checking right before New Year's or that Danny's release is like clockwork?
Well done, KDE team! Looking forward to 2007!
Hey all,
If anyone is interested, I have a screenshot for the new 'fill' for ksysguard:
http://img139.imageshack.us/img139/3906/sensorload22oo5.png
(please no comments on text colour or svg. The artist hasn't committed his changes just yet.)
I'm hoping that the semi-transparency will make it clearer that the lines are stacked on top of each other (so the height of the second line, is the value of the first sensor plus the value of the second sensor)
Nice :-)
Looks great! :)
Are the colors blended in the lower regions.
How do you expect to get the color yellow if you blend red with blue? :o)
I suppose now would be a time to point out that the color side of my brain sucks ;-) Also, apparently, the part that decides whether to put a question mark on the tail end of a sentence.
Anyway, I think blending the colors would make it particularly evident that the graphs are stacked.
IMHO it would look even better if the line separators b/n each graph is completely removed. There is no need to have a separator that says things like "CPU Load" when the graph is clearly labeled with the same wording. Just my 2 cents worth YMMV...
Hi John!
The screenshot looks great.
- The semi-transparency does make it a lot clearer that the lines are stacked
- I agree with above poster: No need to put a label above the graphs if the graphs already have they own labelling.
- The CPU load graph needs a label 100% above the 80% one for the left axis.
Great work (and as the rumors go you just solved some bad instability issues? :)
PS: The colours and the svg are alright, by the way :-)
Hey,
Thanks :-)
There are other ways to see the information though - for example there's a LCD-number type view etc. Only the graph has the label.
Also it looks a bit strange not having the labels or anything. Also what about when the graph isn't wide enough to be able to show the label in the small place?
Hmm, I'm not sure where exactly I'd put a 100% label. It's already getting complicated to the layouting of the axis labels heh.
Maybe putting the labels outside of the graph would be better. It would give me more room to do that if the instead of having the graphs in a 2x2 grid, they were in a 1x4 grid. The I'd have horizontal room to have the labelling outside. Just a thought.
Mmmm. Those are points worth exploring, the labelling inside the graph looks so much better though...
But yes, it isn't obvious where to put the 100% label. But being able to see 0% and 100% is more important than the other labels(20%,40%...) IMHO, as then you can quickly visually interpolate.
How do other efforts solve the problem?. Let's see:
Either they don't show labels on the axis at all,
- Windows: http://www.worldstart.com/tips/screenshots/performance.jpg
- OSX http://www.apple.com/server/macosx/images/cpuusage06212003.gif
or they put them outside the graph, as you propose:
http://static.flickr.com/34/91507931_92f7a939d7_m.jpg
more innovative approaches:
- meter: http://www.widgetgallery.com/view.php?widget=36564
- combo: http://www.apple.com/downloads/dashboard/status/qcpu.html
I hope that inspires you :-)
Also in KGet appears to be the beginning for support of the awesome Metalinks (http://metalinker.org). No more need for aria2; just insanely fast downloads straight through .metalink files in kget, hopefully. :)
to Martin Koller - this bugs in Konq were small but irritating.
And of course for Danny Allen :)
hello there,
first i want to thank you for your outstanding efforts. thanks a lot for the last seven years of outstanding desktop experiences.
can someone make up a summary or assumptions on how many of the open issues for the 3.5 branch will be closed in 3.5.6? since all issues are in progress they could be closed through fixes. or might there follow a 3.6 and 3.7 branch?
to put the question short: when will the 3.5 development be switched to maintenance status?
3.5 development is in maintenace status since 3.5.0 ;-) Only that we are allowing "small and well tested" features in the 3.5 branch since KDE 4 is/was a bit far.
There probably will be a 3.5.7 and 3.5.8, but not a 3.6 or 3.7 version of the kde3-series.
This is a huge step forward... i was really starting to think that kde 4.0 was going to be released in 2008...
Well, you should not assume anything. KDE4 will be released when it is ready. Personally I hope it will be in 2007 but it's always better to release when it is done than to stress the release to get it out early.
I'm not assuming anything. It is explicitly mentioned in the digest that kde4 is going to be out in 2007
also dont mix up KDE4 and KDE 4.0 : http://www.kdedevelopers.org/node/2600
What I ask myself is:
Why Don't you ship "KDE4 core" early and KDE4 with all applications later.
Who cares about Majong: these are just applications for the plattform.
Then I really wonder why KDE 4.0 is not out now?
I mean, do we really need "KDE Games" for a KDE 4.0 release?
The point is you first need a working and used plattform. That can be a plattform for few developers or a plattform for users which then start to ask: Oh, where is my favourite game? Let us port it from KDE 3.5.5.
Release early, release often. Plasma may follow later.
Thomas Zander says 'And most important, our fonts just look and print great now.', while I agree that this is an important goal, in the image that he linked(*), I disagree that the font look great.
For example, in the 'suscipit' word in the horizontal text,the 's' and the 'c' are too close to each other (kerning issue), and the inside of the closed loop in the 'e' letter is grey (this one is maybe because I'm watching the png on a LCD screen, I don't know).
* at:
http://commit-digest.org/issues/2006-12-31/files/koffice-text_runaround_...
To clarify as it was may be a bit harsh, I don't mean that it looks ugly, it looks quite good, but 'great' no, I don't think so.
At least not in this png.
Best regards,
renoX
I agree, the font kerning in the image is not perfect at all.
I got the idea that the image is placed in the wrong context, since it shows how text can be wrapped around images, not how the font kerning behaves..
Go and have a look to this screen shot, whitch show the same thing but with an other font :
http://members.home.nl/zander/images/200612-Text%20runaround.png
Not better at all. Is it "feu giat" or "feugiat" to the right of the red arrow? Is it "vero" or "ver o"?
> Not better at all.
LOL!
That's _exactly_ the same screenshot as this article supplies :)
The font issues you noted have been reported and should be fixes in time for the final release.