The Road to KDE 4: SVG Rendering in Applications
Tuesday, 2 January 2007 | Tunrau
Since KDE 4 development is in full swing with plans for a KDE 4.0 release sometime later this year, I thought I'd put together a weekly piece entitled The Road to KDE 4. The idea is to have a short overview of one or two of the features that show progress in KDE 4. For my first issue, the goal is to show off some of the great SVG work that has taken place so far. Read on for the details...
Since many features are covered in personal blogs via the KDE Planet, I'll try to cover those that receive less public coverage, or need more public coverage.
The first thing I'd like to point out is that KDE 4 builds, installs, and runs well enough that I can test many of the ported KDE 3.x applications, and most of them are pretty stable. The real joys come when you look more closely at those improvements that are afforded by the changes in the base technologies. Today, I'll talk about one of the eyecandy features provided by Qt 4: SVG rendering in applications.
There are many other KDE applications reaping the benefits of SVG drawing to make them more pleasing, and more scalable. Check out some of these posts:
Today I'm going to focus on a handful of apps, providing before and after screenshots to compare the KDE 4 development version (pre-alpha stuff) to the existing KDE 3.5.5 equivalents.
To begin, I'll look at the KDE System Guard, a useful utility packed into KDE that you can pull up as 'ksysguard'. It does all sorts of neat things like display charts of memory and CPU usage, and a process table (also accessible via the Ctrl-Esc keyboard shortcut).
Here's how it looked in KDE 3.5.5:
And now, in the KDE 4 development series (the lines are antialiased, the graphs are translucent and the backgrounds are SVG):
As you can see, it is visually much improved from its current and very functional form.
Next we'll look at some of the diversions shipped in the kdegames package. KAtomic is a puzzle game. It's fun, semi-educational, and could definitely have used an image overhaul. Here it is in it's spartan KDE 3.5.5 glory:
And now, with much improved oxygen-style graphics in the development series:
KMahjongg ships in the kdegames package, and is a staple of puzzle gaming. Here it is from KDE 3.5.5 looking like a game that escaped from the Best of Windows Entertainment Pack:
And now, with a much-improved SVG-powered tileset in the development series:
And last but not least, is one of the more frequently used parts of KDE: the "Run Command" dialog (Alt-F2). Previously this:
Now, thanks to desktop interface guru Aaron Seigo, it's a SVG themable, really slick element of the Plasma desktop. Still a work in progress, but you'll get the idea from this screenshot.
Until next time folks, when I reveal yet another KDE 4 feature under development. Cheers.
Comments:
Looks like the important Apps are ported first - chri - 2007-01-02
<just fun> Why browse and tag your Files when you can play a nice round mahjong :) Its already usable by secretaries now :) And they will be more productive ! Lets add more games :) kate/konqueror/okular/plasma , who needs this :>> </just fun> seriously : The ksysguard and mahjong look awsome , alt-f2 and atomic need much more work/love :)
Re: Looks like the important Apps are ported first - Troy Unrau - 2007-01-02
Well, krunner (the new run dialog) is only a few weeks old... it works well enough, and we'll probably see it mature in the next few weeks (as it's really a very simple app anyway). As for KAtomic, it'll get some love too... the SVG graphics are just preliminary at this point anyway. Notice how there's still shadows under the arrows there... it's because the arrows are just stolen toolbar icons so far. The beauty of SVG though is that it can be very easily changed, themed, etc. without having to do much work (IE: no recompilations to fix a pixel).
Re: Looks like the important Apps are ported first - Aaron J. Seigo - 2007-01-02
yes, krunner is about 4-5 hours of work altogether so far including me sitting down and thinking about what i wanted it to do.. =)
Re: Looks like the important Apps are ported first - chri - 2007-01-03
i really liked the music when atomic came out on the Amiga. Can we perhaps somehow *ask* the copyright holders if we can have the music ?!?!? that would be soo great
Re: Looks like the important Apps are ported first - pascal - 2007-01-03
scratch your itch :-)
Re: Looks like the important Apps are ported first - Stephan Sokolow - 2007-02-07
I'm sure the KDE game devs would be very grateful if you would. Half the problem is getting in contact with the people authorized to make such a decision.
Video Shots ? - chri - 2007-01-02
as kde gets more and more animations - What about Video-Shots , instead of Screenshots? Would be a nice addition for KSnapshot !
Re: Video Shots ? - KubuntuUser - 2007-01-03
Now, that's an _excellent_ idea. Talk about innovation!
Re: Video Shots ? - gerd - 2007-01-04
Try wink
Mahjong - Caesar Tjalbo - 2007-01-02
Oh wow, the new KMahJongg looks almost as good as the Gnome version.... I am excited about KDE 4 though!
Re: Mahjong - drizek - 2007-01-03
From the looks of it, they took the svgs from the gnome version. Im sure it will be improved further later on. I hope they make the two compatible though, so the two apps can continue to borrow tile sets from each other.
Re: Mahjong - Mauricio Piacentini - 2007-01-03
Actually the SVG tilesets used by Kmahjongg (and shared with KShisen) in KDE4 are original, contributed by Raquel Ravanini and Robert Buchholz. Due to our needs (angle switching) we needed to compose tile backgrounds and faces at runtime and have all elements separated in the SVG file, so these were drawn specifically to match what our games needed.
Re: Mahjong - gfranken - 2007-01-03
I admit that the current GNOME Mahjongg looks better than the current KDE 3.5.5 Mahjongg. However, the KDE 4 Mahjonng with the SVG graphics makes the GNOME version look cartoonish. Take some screen clips, and compare the three side by side. After seeing some of this stuff, I now believe that KDE 4 is going to be stunningly beautiful.
Re: Mahjong - superstoned - 2007-01-03
nice thing is, the KDE version can change the orientation of the tiles with the g and h keys (if i'm not mistaken), and do that incredibly fast.
Looks good, but... - Carlo - 2007-01-02
...the question is: Does it render quickly enough, not to flicker, when the system is under load and you're resizing the window (without keeping a (in "advance" filled) cache, eating a large amount of memory)? Or do the minimal GPU requirements match Vista? Hopefully there's at least a compatibility mode for people who don't want exchange a fast working system for 'bells and whistles' or feel forced to buy new hardware (or to choose another desktop)... The minicli above looks much better.
Re: Looks good, but... - John Tapsell - 2007-01-03
SVG's can take a while to rerender when you resize the window. I was thinking for ksysguard to just resize the cached image, with a, say, 500ms timer to rerender the svg once the user stops resizing. But I didn't think it was worth the effort. If people do care, then I could perhaps do that. (At the moment it rerenders as you resize. This means it feels jerky as you resize.)
Re: Looks good, but... - Carlo - 2007-01-03
That (at X, Y, Z size prerendered) bitmaps of the SVG's would be scaled down (at best on GPU level) was the premise I had in mind. Just that you quickly run into the problem of large cache sizes, which are a PITA. Hopefully everyone is keeping this in mind (rather a lot of small elements that get reused and are already cached, than each application "its" fat svg costume; prerendering and caching, incl. storing the cache on disk: Nothing is more annoying than having slow starting applications, because of svg elements being rendered - large bitmap loading might be slower though; aggregating multiple svg's in one file avoids seek times,...) Scalable graphics are nice at development time, but at runtime with users noticing artifacts and slowdowns in milliseconds, there's no way to go without very smart bitmap caching. >(At the moment it rerenders as you resize. This means it feels jerky as you resize.) At the moment it doesn't matter. A 4.0 release with such a "feature" would be catastrophic.
Re: Looks good, but... - Carlo - 2007-01-03
Remains the question, why Xorg doesn't care about application provided vector graphics - especially when you think about remote desktops. But that's way off topic, I suppose. :)
Re: Looks good, but... - superstoned - 2007-01-03
xorg just lacks good SVG rendering acceleration. we'll have to wait a (long) while for that... it would solve the speed problem, tough. btw here it's definitely not jerky, but outright slow. it takes approx a sec to resize the window. but imho that's better than being jerky, tough, it takes some time but doesn't flicker or something.
Re: Looks good, but... - Carlo - 2007-01-03
> btw here it's definitely not jerky, but outright slow. it takes approx a sec to resize the window. but imho that's better than being jerky, tough, it takes some time but doesn't flicker or something. Well, even if Qt 4 does draw off-screen, avoiding flickering, and isn't as retard...err...90's with regards to threading as Qt 3.x - any user interface "stalling" is nowadays outright unacceptable, would be a very bad user experience and bad PR for KDE 4. Such "little" things count more, than a long feature list.
Re: Looks good, but... - Diederik - 2007-01-03
> SVG's can take a while to rerender when you resize the window. That would totally s**k. I have a similar problem with Beryl, I'm back to outline resizing because Beryl is too slow with resizes. Would it be possible to precompile the SVG into something more efficient? This could be done on the fly when a SVG is changed. Microsoft seams to be something something like that with their XAML format (see http://en.wikipedia.org/wiki/Extensible_Application_Markup_Language). They compile it into BAML before it's used as resource. Like SVG, their XAML files can be created by a designer and used 1-on-1 by developers as application interface.
Re: Looks good, but... - Robert Knight - 2007-01-03
Parsing the XML is not the problem with resizing. I presume that Qt is sensible enough to only do that when the SVG is first loaded (although processing large quantities of XML is expensive to do and can adversely affect startup times which is presumably why Microsoft compiles XAML into another binary format). The expensive part when resizing (I think) is drawing the complex polygons which were described by the SVG file and then filling them with all manner of gradients and transparencies. Qt 4.3 includes some hefty improvements for rendering complex polygons, including making better use of OpenGL to cut down some of the work considerably. Zack Rusin's blog provides more details.
Re: Looks good, but... - John Tapsell - 2007-01-04
Qt reads in the xml and makes a kind of dom tree.
Re: Looks good, but... - Thomas Zander - 2007-01-04
A strategy I used in scaling images like that before was using a bitmap of, say, max 200 pixels wide and scaling that up to give instantaneous feedback while scaling. A background thread would then render the svg in its full resolution and when its done it will be shown on screen. This gives direct results and smooth rescaling. And while things move the human eye can't discern details anyway so if it takes a maximum of 200msec before the final svg is finally rendered you would totally NOT notice. If it took half a second you'd just see some updating, but you'd have to look really good to see what it was. Lets see if we can get that into kdelibs somehow ;)
Re: Looks good, but... - Phase II - 2007-01-03
You want to know, but talk like you already know the answer (of course the answer is negative). Also, next time someone complains about "bells and whistles", they should be sent straight back to the command line. Or install Windows 95 if they get that running. Sorry, technical Darwinism is cruel.
Re: Looks good, but... - Kirk - 2007-01-04
Are you serious?
krunner and options - apokryphos - 2007-01-02
I'm not convinced krunner really needs any options. The current run command dialog has: (i) run as a different user; (ii) run as root. (iii) run in terminal (iv) run with different priority (v) run with realtime scheduling (i) is practically never done, and (ii) should never have to be. Any app that requires root privs should launch with them. (iii) obviously doesn't need to be there; if you want it to run in the terminal, then run it in one. (iv) and (v) are [rarely-used] power-user features and I don't think they should be there.
"should" - crc - 2007-01-02
You use the word "should" three times. Developers: Please don't remove useful functionality based on how things "should" be! Should not the "Cancel" button be removed? If the user does not intend to run a program, she should not press Alt-F2 in the first place. That said, you do have a point that these options are probably rarely used, but that is IMHO already taken care of by hiding them under the "Options" button.
"should" additional options go away? NO!! - confused reader of news - 2007-01-03
I'm using each of the enumerated options no more than 4-5 times a year. I'm using [alt]+[f2] about 20 times a day *without* any options. That means, 99.7% of occurrences when ${me} is using [alt]+[f2] I'm happy with the most simplistic "dialog" you can ever imagine (I don't even notice the "Options >>", "Run" and "Cancel" buttons then -- I just hit [enter]... ) Do I therefore want the listed features go away? No, most certainly NO!, 'cause I still need and *use* one of them once a month or so.... Would I strongly oppose any move to scrap the "Options >>" button (or an obvious way to invoke a more feature-rich krunner) altogether? Hell, YES!, you can bet on that for sure. Those new SVG capabilities do open a whole new universe of implementing lots of eyecandy as well as new usability features. (Though I expect no-one, developers or artists, to be able to find the correct balance in his first approach playing with his new SVG tools... be prepared to see also quite some creations that you do only like a week or a month and then be saturated...) I think this is a premier opportunity for KDE to draw a whole new layer of artists into its ranks, who will be excited to see what huge play- and creation-ground these things do offer to them.
Re: "should" additional options go away? NO!! - otherAC - 2007-01-03
Indeed, as we are KDE and not GNOME I like power user options to be accessible, not to be completely hidden from the (not so powerful) user.
Re: "should" additional options go away? NO!! - confused reader of news - 2007-01-03
Forgot to mention that I *did* notice the (very unobtrusive) "Options" link (not a button) in the screenshot of the new krunner above, and I'm happy to see it is still there. I just did want to let a voice be heared that opposes these "fascist GUI purgers" (Linus Torvalds' expression) who do want to dictate users what they ought to have and what they ought to forego. Of course, I'm not opposed to cleanse "cluttered" and "bloated" UI elements from the default views -- but please let me continue to get easy access to all of them should I so desire.
Re: "should" - apokryphos - 2007-01-03
That's a bit of a ridiculous argument. "Should" is simply an imperative, and even if you don't think or know it, it's used ALL the time. Should all our window decorations be red? No, they shouldn't. Don't get me wrong, I absolutely adore the configurability and extensibility of KDE, and I in no way want that to change. And re-organising things is certainly not that. And none of what you've said addresses the point. You should *never* have to use the "run as root" option, and in fact that's even dangerous to new users. If the "run as new user" is actually being used then we should find a way to incorporate that, but there's no reason for why it should be in the very basic "run application" dialogue.
Re: "should" - devicerandom - 2007-01-03
"You should *never* have to use the "run as root" option, and in fact that's even dangerous to new users. If the "run as new user" is actually being used then we should find a way to incorporate that, but there's no reason for why it should be in the very basic "run application" dialogue." No. You simply don't see a reason to use it, while I can imagine a lot of occasions in which I want to run application X sometimes as root, sometimes not, and *I* want to decide it (not the application). Who are you to decide what I should have and don't have to use?
Re: "should" - Olivier. - 2007-01-03
+1 I hate "facist GUI purgers" too. I hate people that dictate how I should use my computer and what I should do with it. I want to decide myself! I hate GUIs that requires a registry editor to access all features because someone decided for me. (Gnome / Windows) purging GUIs is as stupid as swapping Ok/Cancel buttons to differenciate from windows forgetting in the meantime that some users may required to run both windows and gnome and thus leading to many mistakes. This to illustrate that when the programmer decides for the end-user he can never think to the whole impact of his decision and thus, this always lead to reduced ergonomy. Emacs succeeded because it was flexible and feature rich. Think about that when removing features.
Re: "should" - Cerulean - 2007-01-04
-1 By all means, no one dictates how you should use Linux. That's freedom for you ;-). If you want to decide for *yourself* then write your own software. "I hate GUIs that requires a registry editor..." Lots of KDE functionality is hidden in rc files. Are you going to hate KDE for that too? "as stupid as swapping Ok/Cancel" I think you'll find that swapping the OK/Cancel buttons wasn't done to be different from Windows, so stop with the outlandish, uninformed claims. As for "when the programmer decides for the end-user" -- the programmer is always deciding for the end user when they write their program. Simple as. You have to draw the line somewhere. I'd argue that the original request of removing those arcane options is warranted. If you want a more powerful way of executing applications you're most probably a power user that has a shell open and can do that for yourself. If not, a replacement could be optional. With that said, I think the new options is unobtrusive enough to not matter. I definitely agree that the current dialog needs some TLC, and the new one looks sweet.
Re: "should" - Sergey - 2007-01-04
>If you want a more powerful way of executing applications you're most probably a power user "GUI fascists" see users black and white , i. e. either completely stupid and scared or so advanced as to work with registry/command line. But you excluded! a whole lot of users who are not at all afraid about extra 30 options in configuration dialogs, but either cannot edit registries/cmdline or have no time to find out what/where/how to do it. As for swapping the OK/Cancel buttons - nobody thought that you saved little mouse movement, but overloaded my user brain with thinking much more about what button to press, as users you know have habits, and you broke them. It seems to me that some stupid manager/designer decided this, and other people don't see, that king is naked..
Re: "should" - pilpilon - 2007-01-04
well, it is really a lot easier to press ok in GNOME, when one gets acustomed to it. The problem is, if you need to ask, defaylt should be Cancel, not OK :)
Re: "should" - Sergey - 2007-01-05
people may switch back to Windows long before the time will come, they would become accustomed to reversed buttons. I think Gnome is optimized only for corporate users, home users are ignored.
Re: "should" - Lessismoreisless - 2007-01-05
It is hilarious how commenters accuse people of "GUI fascists" while at the same time making incredibly harsh generalisations themselves. There are tradeoffs. Sometimes less is more and sometimes less is just less. Gnome doesn't always get things right but no one ever claimed KDE was perfect. Gnome is aiming for a different audience, and they make it much harder to get lost or to shoot yourself in the foot but the downside is things are far less configurable at first. KDE on the other hand makes many things configurable, probably more than most users need but with time it should become clearer which options can be streamlined or better presented at the right time and place. Both Gnome and KDE will continue to improve and bounce in and out from the happy medium. I wont go into the button order thing but it isn't an arbitrary decision and Apple did it long before Gnome. QT 4.2 makes it even easier for developers to integrate applications with whichever button order users prefer, hopefully GTK will also improve the work they have done so far to allow alternative button ordering.
Re: "should" - Sergey - 2007-01-07
I think the best way to address mentioned tradeoffs is to make in applications menu two choices "Options" and "Advanced Options"(which would have "set all to default" button). Clueless users won't go to "Advanced options" . Those who shooted themselves in the foot will just press "set all default" in "advanced options".
Re: "should" - Lessismoreisless - 2007-01-05
"Emacs succeeded because it was flexible and feature rich." Yes and no. Read about Emacs http://www.jwz.org/doc/lemacs.html Emacs was forked and replaced by the more user friendly X-Emacs which succeeded because it was more user friendly and gave more people what they wanted (although you could chose to interpret that user friendliness as "more features" if you wanted). :P Dont underestimate the power of broader appeal and I think the parent post was pointing at that with better defaults and asking the right questions in the right places for less options would be needed. If the user was prompted for root passwords when needed then wouldn't it be possible to combine both run as root and run as other user?
Re: "should" - apokryphos - 2007-01-04
All very nice and vague until you back up an actual use-case. Which X application do you need to run as root; and, do you know of a user that doesn't know about kdesu who runs these applications as root? If there's a case, then tell me; I'd genuinely like to know. I actually started off just wondering if we really do need them. See my first post; I only said that I'm not yet convinced. I think the argument raised here that running an application as a different user (with the example of kmail) is a valid use-case, and perhaps makes the option quite worthy. > Who are you to decide what I should have and don't have to use? I'm not a KDE developer but, believe it or not, users can still have opinions on how an application should function. There's nothing controversial in this; see bugs.kde.org -- they're all cases of users proposing that an application doesn't function in the appropriate way. Do you think that's unreasonable?
Re: "should" - Stephen - 2007-01-03
There are cases where the application does not have the ability to prompt the user for a root password. Is that the fault of the program? Should it be fixed? Is it really the user's fault that the programmers didn't implement this? Answer: No, no and no. Just because a user want to run a program as root doesn't mean the program always should run in root. There for its not a good idea for the program to automatically prompt the user. Lets say I wanted to edit a text file. I don't want to open the file using kate or kwrite, as with a different user as it could take longer to open and if they are not configured it could create a backup file which I don't want. I want to use a console based text editor, and the file I need to edit isn't owned by me. How do I do this? without the options button I'm forced to start konsole, run su, run nano /path/to/file with the options button? I type in: nano /path/to/file check the run as different user check run in terminal window How often does one have to do this, perhaps not too often. But that doesn't mean they shouldn't have that ability. having that ability doesn't clutter up anything nor does it make it run slower or not do a good job at what it does.
Re: "should" - apokryphos - 2007-01-04
> There are cases where the application does not have the ability to prompt the user for a root password. > Is that the fault of the program? Should it be fixed? Is it really the user's fault that the programmers didn't implement this? Very wrong, in fact. It's the distribution's fault if it ships with an application that requires root privs and yet still doesn't open with kdesu or gksu when being launched. > Lets say I wanted to edit a text file. I don't want to open the file using kate or kwrite, as with a different user as it could take longer to open and if they are not configured it could create a backup file which I don't want. I want to use a console based text editor, and the file I need to edit isn't owned by me. > How do I do this? > without the options button I'm forced to start konsole, run su, run nano /path/to/file Again, wrong. Right-click -> edit as root is a very valid option. See my other post for why I think this is the method that a new user would choose.
Re: "should" - Roberto Alsina - 2007-01-04
But in that case, the RMB gets duplicated entries for each app able to edit that kind of file. That causes uglyness.
Re: "should" - Morty - 2007-01-04
Exactly, good point. And not to mention you have to open Konqueror, navigate to /path/to/ and then RMB on the file. Which is rather different to the whole concept of using alt+f2 in the first place.
Re: "should" - david - 2007-01-29
So you check if the user can write to the file. If they can, you only need 'edit' If they can't, you only need 'edit as root' (and you could then name just them both 'edit')
Re: "should" - Morty - 2007-01-04
>Very wrong, in fact. It's the distribution's fault if it ships with an >application that requires root privs and yet still doesn't open with kdesu or >gksu when being launched. No, it's you thats wrong. This is not a thing for the distribution or developers to decide, it's for the user to decide if root privs is needed when running the application. You use it for applications you sometimes run as root, but mostly don't. The deleopers or distributions have no way to decide if the user want's it with kdsu or not. In a menu they can do it, like with kfm(Konqi in filamnager mode) where you have one entry for normal and one for starting it as root. But this does not fit in the concept and use of alt+F2. The whole point is to *not* use a menu and *not* right clik on files etc.
Re: krunner and options - otherAC - 2007-01-03
>>I'm not convinced krunner really needs any options. Then stay away from the [options] button in krunner :o) (i) i use that to start the e-mail application of my SO (ii) i use that one to start an application that i otherwise could use as user as well, but want to run it as root for now, or for non-kde-applications that need to be run as root but do not provide options to become root (iii) nice for people who need to run something in a terminal but don't know how to start one (as linux becomes more popular, more and more users have no idea what a terminal, commandline, shell, etc is..) (iv) and (v): why hide power user options? The whole thing is hidden for the average user anyway.
Re: krunner and options - apokryphos - 2007-01-03
(i) granted, but this doesn't suggest that the application couldn't be perhaps put elsewhere. I'm not sure where yet myself. A strong point against my argument, sure. But to address a few of the others: (ii) please give me an example of the said application. (iii) really doesn't work at all. Partly because I've never seen someone struggle to find a terminal, but also of course because it would be plain silly to get a new user to familiarise themselves with using the run dialogue to always start up a terminal. If the terminal's hidden (which it isn't at all), then we should make it more visible and accessible, not create a duplication of effort around when there's no clear need at all.
Re: krunner and options - Morty - 2007-01-03
>(ii) please give me an example of the said application. The most obvious, KWrite. Very handy if you wan't to quikly edit a configuration file. The use cases for this functionality are extreamly numourus. I'll even give you one for (ii) and (iii) at the same time, it's a nice way to start Minicom (if you run Suse and don't change the default access rights).
Re: krunner and options - apokryphos - 2007-01-04
With regard to kwrite, I don't see why you shouldn't be able to just right-click -> edit as root, which is what a normal user would do. They *wouldn't* alt+f2 -> kwrite /etc/some/file and select "run as different user". The users that know about using paths that confidently (and know about editing system-wide config files) know about kdesu.
Re: krunner and options - Morty - 2007-01-04
The option is for real normal users, not your "normal". The way you talk it seems like you actually mean simple or novice users. Normal users are(or very soon gets to) a level above novice, but far from expert user. This option is for those users, they will have a easy way to run as root without knowing about kdesu. Which is rather more obscure and harder to learn, while cliking the options button is not. Your "normal" would not know about running as root or alt+F2 anyway. In normal use this option is not needed, that's the whole reaseon it's hidden too. That's usability btw, it's only there when you need it. It does not degrade speed or create confusion. But *when* you need the functionality it's easily accesable, even for non-expert users(For instance a ordinary user having run his home PC on Linux a year or two, but not a sysadmin wizzard). And personaly I find using the option both easier and more logicall than: alt+F2 kdsu kwrite /etc/somefile
Re: krunner and options - otherAC - 2007-01-04
>>With regard to kwrite, I don't see why you shouldn't be able to just right-click -> edit as root, If I right click, i don't see an option 'edit as root' And if i want to create a new file as root, that option would not help at all to gain root privileges. Furthermore, every action on a computer system can be done in several different ways. (like with pasting text, you can use the middele mouse button, the context menu of the right mouse button, the past icon in the toolbar or the menu option [edit -> paste]), so why should we want to strip a (hidden) option from krunner, just because there are other ways to perform the desired action??
Re: krunner and options - Joe - 2007-01-03
2.) Run as root? kwrite /etc/apt/sources.list or /etc/init.d/whatever restart The point is, my boy, you are telling ME how I am supposed to run my shop? Fart on that. You have no clue how most people use computers, so don't say "should".
Re: krunner and options - apokryphos - 2007-01-04
Er, yeah, you really run that in alt+f2? Good luck, since it won't give you *any* output. Great use that is. If it errors out, you won't know, if it succeeds, you again won't know. I'm quite sure you run your /etc/init.d/ scripts from the terminal. > You have no clue how most people use computers, so don't say "should". Evidently. I "have no clue" that alt+f2 gives you absolutely no output, unless you select the terminal option as well (which I already gave an argument for not having).
Re: krunner and options - Roberto Alsina - 2007-01-04
Check the "run in console" option in Alt+F2
Re: Yeah, scrap it all! - Phase II - 2007-01-03
I like how you can talk stuff away. "Practically never", "should never have to be", "obviously doesn't need to be" or simply "don't think they should be"... I'm totally hooked. Next time I'm sitting in front of some longer TODO I try to apply your relieving attitude.
Options are good! - Hobbes - 2007-01-03
The ability to run applications as a different user is really convenient for me! I have a personal (or "home") account and a professional (or "work") account on my laptop. I am not going to mix them! And, sometimes, I need to run a graphical application from the other world... For instance KMail, Korganizer or Kaddressbook, for obvious reasons. With Krunner, I save time. Thanks for the application!
Re: krunner and options - pascal - 2007-01-03
Actually I agree with you. Only problem is that KDE is all about choices and the extra options are not even really visible unless you look for them. But maybe you are right, maybe nobody are using this functionality. On another note: The built-in calculater in krunner ROCKS! I simply love it. It's so fast and handy when I need it.
Re: krunner and options - pascal - 2007-01-03
Well, If I had refreshed the page I would have seen that lots of people are using it. And it seems like a cool feature to be able to open kmail as another user quickly.
Re: krunner and options - ac - 2007-01-03
I agree, this should be a "tip of the day", till now my girlfriend and I used start new desktop, but for a quick email check, this will be very helpfull, thanks
Re: krunner and options - Lessismoreisless - 2007-01-05
being able to switch to another user account more quickly would help too though...
Re: krunner and options - Felix - 2007-01-03
(i) Is very useful if you have more than one non-root account and don't like to switch desktop sessions (ii) Maybe programs should ask for a root password, but kde cannot know if all apps really do this. The option doesn't hurt, (iii) Very useful for me, as it is better as starting an extra console. Useful for debugging. (iv) Also useful for people don't understanding how to use nice/renice (v) Some users might need this, I not, but it doesn't hurt. Most of the time, having more options is better, at least for me. I really like desktops/applications where options are hidden for normal users how cannot understand and use them, but are easily available for me. I don't see a problem in having an "Options" or "Advanced" button. It gives users the choice ! Felix
Re: krunner and options - apokryphos - 2007-01-04
I agree with a lot of your points that perhaps these options don't hurt. It is true that in krunner they are less obtrusive. No harm in questioning if each one is needed though, too.
Re: krunner and options - Andre - 2007-01-04
True, but I guess that as long as the features are not in the way, and they are usefull for *someone*, it would be a good idea to keep the feature.
Re: krunner and options - Tyson - 2007-01-03
Excuse me, but I use (i) all the time. One of the best things about it is that it seems to handle all the details of the X connection (i.e., authorization). The only problem I have with it is that tab is disabled from selecting the options box after you use the drop down box that pops up when you start typing. Personally, I think you could use reading some of the criticism of over simplification. - While it is true that users only uses about 10% of the features of an app, the 10% differs enough for each user that their union covers pretty everything present. Taking the intersection of all the feature sets used by all users and remove everything else just winds up leaving everyone disappointed. - Being a power user is forever; being a novice user is just a passing phase on the road to being a power user. Killing the features that those that actually use your apps more than just in a passing fancy use is not cool at all. - Usability is not about killing features. Usability is about organizing features. In short, please stay away from my apps! : )
Re: krunner and options - Golodh - 2007-01-04
Please please ... the dialogue for KRunner is good as it is. The remarks that one "should never" run or have to run application xyz as root mean precisely nothing to me. I have a few applications that need root access. And as long as Krunner asks for the root password the responsability is where it belongs ... with whoever gave out the root password. In my case that would be me. I don't think that developers should interfere in this matter. And another thing. I notice that the example application shows signs of gratuitous styling of the worst kind. Whereas the look and feel of KRunner for KDE 3 is neat and functional (as if it was designed for me to get something done without fuss instead of as a programmer's show-off), the picture of the same application under KDE4 has this totally superfluous picture of a gear, much wasted space, obtrusive colouring, an awkwardly small business area, and a stealth button for options. Promise me one thing please ... if you are going to implement this to show off your theming powess, do provide a theme that brings back the KDE3 look and feel ... and make it default so that I never have to look at such styling monstrosities again please. I mean it. I thank and respect you as a developer, but I _really_ don't want you around as a stylist. The KDE3 look currently resembles that of Windows, and that is a good thing. Because ... for better or worse, that plain functional WIndows look has been tested and vetted by a lot of ergonomics experts. And what they have done is to remove clutter and to make / keep the look and feel functional. Besides it reminds people of Windows and makes them feel a bit more at ease with Linux. So on behalf of the my users (and those I'm trying to convince to become Linux users) no fancy funky theming please ... and keep the look-and-feel as Windows-like as you can. They've gotten used to it, and they *hate* it when developers change the layout of basic applications just to indulge in some random restyling. And I have to say that I sympathise. So please ... make it scalable if you must, make it themable if you want, but please please don't touch it's looks, and keep all the options in.
Re: krunner and options - otherAC - 2007-01-04
>> the picture of the same application under KDE4 has this totally superfluous picture of a gear, much wasted space, obtrusive colouring, an awkwardly small business area, and a stealth button for options. as stated before, the backgrounds used in the screenshots are for development purposes only, just to show what's possible with svg. They will be replaced with something more sensible
Re: krunner and options - Ben Morris - 2007-01-05
These are indeed seldom-used features. This is exactly why they are hidden until you press the Options button. If you find too many options annoying or confusing, you can just try not to press Options. I personally like those options and use at least three of them from time to time, and while I can do any of them by opening a terminal emulator, I find it more convenient to start apps or run commands that way. Maybe krunner doesn't *need* options, but why shouldn't it have them anyway? We don't actaully *need* to be able to change the desktop background. This is part of why I prefer KDE to Gnome. I refer you to the stuff Linus said about Gnome's print dialog. Basically, potentially useful options were removed, to avoid causing confusion. I couldn't see why they didn't just do exactly what krunner does: hide the advanced options till you ask for them.
Thanks! - Joergen Ramskov - 2007-01-02
That was a neat little article - looking forward to the next! How much will actually be rendered with SVG? yeah, I know that is probably unknown, but what is the goal then? :)
Re: Thanks! - Johann Ollivier Lapeyre - 2007-01-03
As much as possible ;) More seriously, i'd like to have (and i plan to do) all kdegame/kdeedu in SVG with an oxygen style, and several other things (finish ksysguard, krunner, umbrello...). But it will be hard to make them all for kde4.0 i fear, and there are still missing maintainer for some games.
Re: Thanks! - Joergen Ramskov - 2007-01-04
Thanks for the answer. I know that KDE 4.0 is just the start, just look at how KDE 3 has evolved over time :) I think the same will happen with KDE 4.0 - it will be an amazingly good base to build from!
Excited - Lans - 2007-01-03
Of these four, I think KMahjongg has improved the most and looks most mature. Ksysguard looks nice, but I really dislike the background. KAtomic needs, as somebody already said, some work (and love). I think it is the black blocks (walls) that look a little bit.. too much? And Krunner, this one was new to me. Looks pretty cool, kind of reminds me of Katapult (which is great). I wonder if it works the similar way? Well, to sum everything up, it looks promising. Yes, there are many things to be improved, and I look forward to see the result.
Re: Excited - otherAC - 2007-01-03
>> Ksysguard looks nice, but I really dislike the background. As stated in replies at other dot articles: the background are for testing purposes only, the final background has not been made/released yet. >> And Krunner, this one was new to me. Looks pretty cool, kind of reminds me of Katapult (which is great). I wonder if it works the similar way? Never seen krunner? Try pressing [Alt][F2] in KDE (works since kde 2 or earlier)to start it.
Re: Excited - Lans - 2007-01-03
>> Never seen krunner? Ah, I meant I haven't seen the new Krunner.Or whatever it is called now.
Re: Excited - otherAC - 2007-01-03
there is no new krunner
Re: Excited - Troy Unrau - 2007-01-03
Yes there is... The old run dialog is part of kdesktop, but with plasma in the works, it needed to go the way of the dodo. So krunner, a new application will take over the run dialog (and, I think, screen locking once it's implemented). It is 100% new. Everything else in the article is a port of KDE's existing apps to use the new architecture.
Re: Excited - otherAC - 2007-01-03
True, but the screenshot in this article is just krunner with a different skin, not a successor with different skills.
Re: Excited - Aaron J. Seigo - 2007-01-03
what is everyone smoking in this thread? =) there is no krunner in kde3 (or 2 for that matter). the screenshot is of a completely new application that shares zero lines of code with the old implementation right now (though that will change in a bit as i'll be bringing over some of the options implementations for command execution). the new skills of this successor include being able to have multiple consumers of the entered text each of which can offer possible matches (think: search). it will also include such things as access to servicemenus (of konqi's action context menu fame). and it already does things kdesktop fails to do such as restart reliably in the case of a crash =)
Re: Excited - Lans - 2007-01-03
Will there be "plugins" that add support to or example Calculator (this one is currently already in alt+F2), add songs to Amarok, chat with someone in Kopete etc.? Kind of like the current Katapult. :)
Re: Excited - Michael - 2007-01-03
Guess that's what he meant with the "consumers".
KMahjongg - The guy who made Traditional - 2007-01-03
Yeah, those SVGs look hella nice, but to fair you should compare them with the "Traditional" tileset in KMahjongg (with the "Wood" background, naturally). If I had my druthers, I would have made it the default years ago. It was hard enough getting the damn thing accepted in the first place, though. :-) I guess it's time to start working on an SVG version now... :-P
Re: KMahjongg - Shamaz - 2007-01-03
If you think the default tileset is not so good, there's already a "classic" SVG tileset done. You can see it here : http://maupiacentini.blogspot.com/2006/12/shisen-sho.html It looks more like your "Traditional" one. And I think you can quite easily to edit this "classic" tileset to make it more "Traditional"-like. Good luck :)
Re: KMahjongg - The guy who made Traditional - 2007-01-03
There are some similarities but it looks pretty different from "Traditional." I'll have to take a closer look at those tiles. ;-) And yes, "Default" is ugly, ugly, ugly. That's the whole reason I went to the trouble to create "Traditional" and have it included in the base package--I thought KMahjongg deserved to have a little eye candy. ;-)
Re: KMahjongg - UglyMike - 2007-01-03
Waw!!! Never really looked there... And you're right of course: Traditional tileset with Wood background (and Tile Shadow) already make KMahjongg look a LOT better. Why was this never made the default setting? Looks like a no brainer to me!! Thanks for your contribution.
Re: KMahjongg - UglyMike - 2007-01-03
....too bad Shisen-Sho doesn't offer the same customizations.
Re: KMahjongg - Mauricio Piacentini - 2007-01-04
Well, actually it does now, in the KDE4 trunk. It shares the tileset rendering code and art with KMahjongg, so you will be able to use the same SVG tiles and backgrounds.
Looks exciting - MM - 2007-01-03
But what about the performance of especially ksysguard (e.g. when the system is already swapping and one needs to kill a process)? However, it looks really great.
Re: Looks exciting - otherAC - 2007-01-03
you can start the version of ksysguard without the graphs, with the commmand 'kpm' or the keystroke ctrl esc
Re: Looks exciting - MM - 2007-01-03
Thx
Re: Looks exciting - JohnFlux - 2007-01-03
When you are looking the process list (which is what shows first when you launch ksysguard), then the hidden graphs require (practically) no cpu etc (they log a bit of data but that's it). In particular, the svg's etc are rendered until viewed. I have spent a large amount of effort to try to ensure that ksysguard is usuable even when the machine is going crazy. It's not perfect and there's a long way to go, but it's not so bad as it is.
Re: Looks exciting - MM - 2007-01-03
Thanks for your reply. But I am not so much concerned about the graphics themselves, but about loading, linking and initializing of the appropriate libraries used to display them. Are they loaded dynamically only when they are really needed? However, good work.
Re: Looks exciting - John Tapsell - 2007-01-03
Yeah, it means it has to link against QSvg etc.. but all those libraries should be already loaded etc so I don't konw if it's a big deal
Re: Looks exciting - MM - 2007-01-03
I'm not sure how linking really works on Linux. Is it correct to say that one special dynamic library is loaded once for all processes on that machine (or at least for that user on that machine) (prefetching etc.)? If so, IMHO it may depend on whether the libraries are swapped out (to disk) or not, and the more is going on on a machine, it becomes more likely that they have to be loaded from swap space to RAM... If it is statically linked it seems clear to me that it has to be loaded again. Maybe there is a chance to load the libs dynamically when they are necessary/used only, so that for startup and display of the process list, the libs aren't loaded (and maybe in a further step to not load them at all, e.g. when the machine is already slow, and to use "traditional" display (without svg) instead)?
Re: Looks exciting - Felix - 2007-01-03
I also hope that this will be possible, but personally, I prefer a console (not konsole ;)) in such a case, e.g. xterm or Ctrl+Alt+F1
Re: Looks exciting - MM - 2007-01-03
Yeah, the problem with Ctrl+Alt+F1 is that one has to login first. Konsole is okay too if it is already running, IMHO.
Really like the use of SVG! - BJ - 2007-01-03
Really like the use of SVG! About the new System Guard, the graphs now have titles in the graph itself as well as above it. Also the 'Load Average' title is missing its first letter. I know this is probably a minor issue but I see this kind of annoyance regularly in graphical user interfaces, KDE is no exception. What would also be nice for the System Guard IMHO would be an x-axis scale, so you get an impression of how long the history is you are looking at.
Re: Really like the use of SVG! - Ben Morris - 2007-01-05
Rough edges happen in alpha stuff... They probably haven't even looked for that sort of issue yet. However, the time-axis idea would be very useful.
Thanks ! - Felix - 2007-01-03
Thanks for this great summery ! I really missed easy to get informations about the progress of kde4. Greetings Felix
Not impressed - Charles - 2007-01-03
I prefer the original KMahjongg screenshots. Also, is KDE 4 going to look as ugly as KDE 3.5.5? I'd like something much much better, as good looking as Windows Vista is possible.
Re: Not impressed - redeeman - 2007-01-03
kde 3.5.5 is already much better than vista.
Re: Not impressed - AC - 2007-01-04
Well, no. Vista looks a lot more elegant and polished than a stock KDE install. Functionality and speed-wise, I'd say they're on par, not "much better". I really hope that KDE 4.0 would be an "all about the defaults"-release, since the current ones, well, suck.
Re: Not impressed - Lans - 2007-01-04
Si it is only me who really dislike the look of Vista? Not because it is Window or Microsoft; well, I've never liked MS' designs, but I think Vista just looks "too much". Bleh. A little bit off topic. But I agree that the default look should (and I think will) be improved.
Re: Not impressed - otherAC - 2007-01-04
XP was already too much with the luna interface, Vista made things only worse..
Re: Not impressed - AC - 2007-01-04
Yes, Luna was horrible, I agree on that. But Vista's Glass interface looks good and works well, you have to try it. I'm running it since a month, and it actually doesn't seem a typical Microsoft product. It's very fast, not even a single crash so far, and a lot more polished. And it's trying to "modernize" the classic WIMP paradigm, just look at the new Office. I think that we can learn - and borrow - a lot from our main competitor's work.
Re: Not impressed - John - 2007-01-11
If you have ever tried PCLinuxOS you will see how KDE 3.5.5. can look 10x better than XP and at least as good as Vista. It is extremely good looking distro.
Re: Not impressed - Thomas Zander - 2007-01-04
> Functionality and speed-wise, I'd say they're on par, not "much better". Funny, I thought that you needed to buy a new super duper machine just to run Vista, while KDE runs fine on a 4 year old machine. I can only imagine what that must doe for 'speed'. The functionality is part is personal; you can configure your KDE much more, for one. You get a much much better command-line application and many more apps in general. For a price you can't beat.
Re: Not impressed - A.S. - 2007-01-05
The good thing is this, yeah. KDE can give an even better look with very few resources, ie <100m RAM vs 512. The "bad" thing, is that the default look of KDE sucks. Oversized icons and bars, very common colors and stuff. It makes me wonder why don't the devs go take a look at kde-look.org and get some inspiration... maybe they can include in there 5-10 extra themes. I'm kind'a sick of distros shipping with only mild tuning of the KDE default, thus making it seem so much "less" than it actually is. And it's all simple things.. proper icon sets and sizes / bar sizes / nice colors etc. These can make the difference between "ok I can work with this" and "wow, what's that?" Personally I like black so I've singled out one simple / elegant from kde look http://www.kde-look.org/content/pre1/48437-1.jpg but which has a relative harmony in icon sizes / bars / colors ... ..and this one which is was while trying to go a bit vista on mine.. The default suse (10.2) start button sucks anyway - aesthetically. It was just like a rectangle with a not-so-good-look so I used another theme from kde-look... Anyway that's my attempt: http://img515.imageshack.us/my.php?image=sss53oz8.png So let's hope default look and embedded themes get significantly improved. It makes a hell of a difference with not much work - just a few choices on fonts, icons, wallpapers, bar sizes etc and voila...
Re: Not impressed - AC - 2007-01-05
Lets just say that tastes differ. I'm afraid a significant set of people would walk away in disgust if KDE looked like either of these images by default. I know my first reaction was one where I'm happy I didn't hold a drink in my hands while walking on an expensive carpet.
Re: Not impressed - Troy Unrau - 2007-01-03
KDE4 will look quite different than 3.x in many ways. However, things like menus and toolbars and such look much like KDE3 at this point because I made the screenshots using the default themes. At this point though, using the default theme allows app development and porting without having to worry about the possibility of an app crashing because of an untested theme. I have a few articles scheduled for later that will show off just how different KDE 4 can look, but at this point I'm still focusing on the apps and features.
Re: Not impressed - otherAC - 2007-01-04
>>as good looking as Windows Vista o_O
Will be possible to copy-paste the SVG? - dis - 2007-01-04
Hi, the new ksysguard looks really great. Will be possible to copy the current graphic and paste it as SVG on a text editor, or an SVG editor as Inkscape? That will be a nice feature (and I guess similar feature would be also nice in other programs).
Re: Will be possible to copy-paste the SVG? - Cerulean - 2007-01-04
That's interesting. Kind of like how text is copied and pasted now. I think the biggest problem would be how exactly you would select individual SVG images. Text doesn't 'overlap' in a window, SVG images can.
Re: Will be possible to copy-paste the SVG? - John Tapsell - 2007-01-04
I suppose this could be possible, but why would you want to? Do you mean copy the graph with the lines, axis and everything as an svg?
what theme are you using? - joe - 2007-01-04
those are very pretty screenshots, I've compiled from svn a couple of weeks ago and it doesn't look like that. what did you add?
Re: what theme are you using? - superstoned - 2007-01-04
i'd say nothing, development is going fast... it's getting at the stage they can start working on the interfaces.
Re: what theme are you using? - Troy Unrau - 2007-01-04
I didn't use anything unusual... In fact, the only things I built to get that all up an running were dbus, qt-copy, kdelibs, kdepimlibs, kdebase and kdegames... all in a fresh account on my system that's isolated from KDE 3.5.5... and I purposefully wiped out .kde before loading to ensure that it was using the KDE defaults for all options.
redundancy in ksysguard - MamiyaOtaru - 2007-01-04
What's with the redundancy in ksysguard? Specifically the bar showing current CPU usage. One can simply look at the far right of the graph to see that. What's the point in showing it twice? See pic if this isn't clear enough: http://img81.imageshack.us/my.php?image=redundantwz1.png I'd ask for an option to disable that, but for heaven's sake it should just go. It grates. A better way to do it if you simply must have the current value highlighted somehow would be something like this: http://img205.imageshack.us/my.php?image=lessredundantut2.png
Re: redundancy in ksysguard - Simon - 2007-01-04
I dunno, personally I prefer the original screenshot. The second is misleading because it looks as if the load has been steady at the current load for some seconds. Seeingt he current load in a separate bar is a nice feature imo as it can be difficult to appreciate current load from the graph when it is rising or falling rapidly.
Re: redundancy in ksysguard - papillion - 2007-01-04
what about placing the 'currrent load bar' on the right of the graph and making it vertical. this way you would be able to compare both more easily and it might even look less out of place
Re: redundancy in ksysguard - AC - 2007-01-04
Yes, that's the way Windows does and it makes a lot of sense, and it does look less "busy". http://www.tomshw.it/guides/software/20060304/images/taskcariconormale.JPG Besides, having duplicated captions (one in the window and one on the graphs) is really a no-go. I'm not sure about the numbers shown in the status bar either. They contains so much information that to be read you are forced to enlarge the window. How about rewording it? Instead of "Memory: 349.9 MiB used, 1,001.8 MiB total" just show "Memory: 350/1,002 MiB used" or even better "Memory: 35% used" and move the actual numbers to another tab.
How can I code and contribute ? - Ankur Gupta - 2007-01-04
Can some one tell me where is the repository (svn/cvs) for KDE System Guard (KDE 4 dev series ) ... Have QT/C++/SVG skills will like to contribute ...
Re: How can I code and contribute ? - Carsten Niehaus - 2007-01-04
To compile KDE4 read this tutorial: http://developer.kde.org/build/trunk.html KSysGuard is here: http://websvn.kde.org/trunk/KDE/kdebase/workspace/ksysguard/ HTH
Re: How can I code and contribute ? - superstoned - 2007-01-04
it's just in svn trunk. if you compile and install KDE4, you'll get the new system guard.
Re: How can I code and contribute ? - John Tapsell - 2007-01-04
You can email me : johnflux at gmail dot com and we can discuss ideas. Actually the biggest thing I want added at the moment is a simple hard disk monitor to check the hard disks are okay. John
Re: How can I code and contribute ? - LordBernhard - 2007-01-13
wow.. this idea sounds really nice... please develope this for us ^^
Beryl/Compiz compatability? - Dr No - 2007-01-04
Just wonder about any Beryl/Compiz compatability?
Re: Beryl/Compiz compatability? - otherAC - 2007-01-04
AFAIK kwin wil get xgl capabilities.
Re: Beryl/Compiz compatability? - LordBernhard - 2007-01-13
what about aiglx then?
Re: Beryl/Compiz compatability? - Ben Morris - 2007-01-05
You can run Beryl fine with KDE right now. Yes, it involves not using kwin, but there is now a way to use standard kwin themes (I don't know if the window menu has a KDE rather than GTK look yet). The only thing that doesn't really work for me now is kicker's pager.
Lol - Guille - 2007-01-04
Gnome Rulz this enviroment sucks
Re: Lol - Mr.Gosh - 2007-01-04
Oh man - use your gnome and tay away from future! I love the upcoming - KDE Ruled allways...
Re: Lol - Mr.Gosh - 2007-01-04
Oh man - use your gnome and stay away from future! I love the upcoming - KDE Ruled allways...
Re: Lol - otherAC - 2007-01-04
Wow, you must be very jealous :) But don't worry, you can always switch to kde4 when it's ready, without having to worry about loosing data etc. Heck, you can even use some of your old applications onder KDE, and with the promise of Portland even with KDE functionality.. So even for you, the future will look bright!!
Revolutionary? - Axl - 2007-01-04
I thought KDE 4 was going to bring a revolutionary new approach to office computing. But this just looks like the same windows-like desktop with neater graphics. Anyway, is KOffice for Windows coming out anytime soon??
Re: Revolutionary? - Thomas Zander - 2007-01-04
No promises; but probably later this year.
Re: Revolutionary? - Lans - 2007-01-04
Focus as been on porting libs etc., so the current "KDE4" looks much like KDE 3.x.
svg ktuberling love please! - Tim Middleton - 2007-01-06
I just don't see how KDE4 can possibly be released without shame if someone doesn't upgrade ktuberling to SVG... That and some sort of 3d semi-transparent treatment for kteatimer... and we'd have something very special in a desktop environment.
Re: svg ktuberling love please! - Morty - 2007-01-06
I guess kteatimer needs to be made a Plasmaoid(sp) and use all the niftyness you get from Plasma :-)
Re: svg ktuberling love please! - a thing - 2007-01-07
http://wiki.kde.org/tiki-index.php?page=KDE+Games+SVG+status says it's in progress.
KDE's new look - anonymous - 2007-01-06
I'm all for KDE taking these steps, but I honestly think that, save for the "Run" design, every single one of these screenshots is simply hideous. Mentally challenged toddlers could scribble more attractive usage graphs with crayons. Those fonts still look like ass. It's like the KDE folks are desperately shouting down a wind tunnel at Vista and Mac OS X. What are they screaming? "Wait for me! I can play too! Look at me!". Vista and Mac OS X simply cling their wine glasses together and laugh.
Re: KDE's new look - Ephracis - 2007-01-06
Remember that this is all just work in progress. You can expect a lot of things to change as we go.
KDE 3.5.5 SVG Deco - bitwit - 2007-01-06
http://www.kde-look.org/content/show.php?content=49665 KDE 3.5.5 Windeco that loads frame and buttons from SVG files. Based on Plastik it should be really easy to port to v4 or, at least, the functionality. Is this even needed ? I haven't dug into Qt/KDE 4 src yet, waiting until its included with my distro, Qt 4 is, so KDE 4 shouldn't be too far behind. Life expectancy of this dist is supposed to be 2.5 years. #B^]
Great - TK - 2007-01-07
I think the SVG rendering is excellent. If all the icons are moved to SVG, then the icons keep their sharpness with increased size. The same with any other graphical item on the desktop. Resizing without pixelating just makes the desktop so much more appealing. I can already see the benefit of this with SVG icons - and this is with the previous version of KDE. One icon image, not multiples for different sizes. And it scales perfectly without pixelating - and is usually smaller.
Re: Great - LordBernhard - 2007-01-13
is it planned vor kde4 that all icons are completely scaleable?
Amazing!!!!! - Wowser - 2007-01-09
I am so completely blown away!!! This has got to be the most unbelievable and quite simply the uttermost anticlimactic news article I have read involving KDE4 to date. Unfortunately there have been more than a few. :(
Awesome Looks - Adekunle Lawal - 2007-02-12
With what im seeing KDE4 promises to be very exciting. The looks are just awesome. Keep up the great work guys.
KDE Needs To Be Faster, Faster, Faster! - Maxei DeVraie - 2007-01-12
Right now I see that the efforts of KDE developers are again making a mistake by concentrating efforts in the Eye Candy Factor. But there are issues much more important: One is improvement of handling and distributing memory resources. KDE is getting fatter and fatter like a vulgar pig named VISTA. Should I remind that Linux is notable for its (so far) ability to run in old, discontinued hardware? The competitor Microsoft Vista is already entangled in its own trap, being able to run only in top, expensive new hardware. C'mon KDE guys, Don't follow the steps of Microsoft as your model to imitate or emulate. Linux and of course KDE are not Windows! Please keep doing the right thing. Follow your common sense. I know you have. You should realize that KDE, as a faster GUI will have much more acceptance. If you have to choose between beauty and functionality.... I'm sure u're understanding now. Maxei DeVrai SLED 10-KDE 3.5 running in SOYO SY-k7VTA-B, cpu 1.1GHz, 896 MB SDRAM pc133, Radeon and 3D enabled!
Re: KDE Needs To Be Faster, Faster, Faster! - James Richard Tyrer - 2007-01-13
Yes, I have to agree. KDE has become so slow that I am going to have to upgrade my 400 MHz K6 III. When I open too many windows and tabs in Konqueror, it just seems to get lost at the point that I have 1/2 GByte of swap. I have 7/16 GByte of memory and also have a Radeon (a 9200 for which X11 supports 3D acceleration). Then there is the question of the visually impaired. Is there going to be some simple way to turn off all of this eye candy -- eye candy which is clearly going to make the GUI much less clear for the visually impaired. IAC, with KSysGuard, I think that it would be a greater improvement to make it fully functional than to add totally unneeded eye candy such as backgrounds and anti-aliased lines. Which lines? A bar graph isn't a line -- there is no line to anti-alias -- and I don't think that you can (or need to) anti-alias horizontal and vertical lines.
Re: KDE Needs To Be Faster, Faster, Faster! - Emil Sedgh - 2007-01-26
KDE4 is really faster than 3.x series because of QT4 improvements.
URL, nothing more. - James Smith - 2007-03-27
Read this and find a cushion for your liar's chair. KDE is becoming slimmer with QT4, not fatter. http://ktown.kde.org/~seli/memory/desktop_benchmark.html
Re: URL, nothing more. - Anon - 2007-03-27
That link would be great if it had anything to do with KDE4's memory usage. At all. "KDE itself was KDE 3.5.2 with my performance patches" Why did you even bother to post it?
Suggestion concerning Ksysguard - J - 2007-02-07
The KDE System Guard background needs to be lighter. Also loose the line or whatever there, it's useless and makes the graph less readable. I'm generally against using graphics everywhere, they should be used if it makes the application in question easier to use, but not for prettiness sake. Also, try to make KDE4 not Vista-slow. Just tested Vista today and it was eating around 20% CPU idle on a 1200$ laptop. Vector graphics are pretty and powerful but eat a lot of cpu, at least before dedicated vector GPUs appear, and thus should be used sparingly. Also, when using SVG, remember to optimize! There should be a function in every respectable vector graphics package to do that. Better yet, design effective(as in few paths and few points) graphics from the ground up. Sorry to sound so critical, it's just that I run KDE and want it to be as good as possible. But, good work and carry on! ps. If there is a particular area that needs improving graphics-wise, I'm a fairly experienced graphic designer trying to learn SVG
Increased use of memory with SVG? - Daniel Aleksandersen - 2007-02-13
Correct me if I am wrong, but will not using SVG mean increased use of memory?
Amazing - Ali - 2007-03-05
It is really amazing this KDE 4 ! I am impressed with new look ! It is great! Thanks KDE team!