In this week's KDE Commit-Digest: Image support in Parley, and support for formulas in the note feature of the Step physics simulation package. blinKen changes capitalisation to Blinken for the KDE 4.0 release. Theme work across kdegames, with better collision detection in Kolf. More XMP integration work in Digikam. Work on KConfig merged back into trunk/. Colour conversion system becomes fully operational in Krita. Continued work on the port of the Kickoff menu to KDE 4, initial work on a centred-button menu in Raptor. KIOFuse, the KIOSlave filesystem bridge, starts to be ported to KDE 4. An uncertain future for the Klipper applet in KDE 4.0, compared to its KDE 3.x form.
Dot Categories:
Comments
Nah, no need to remeber anything not needed, just ALT+F2 and type the executable name -> enter and you're done. Or maybe it's just me that finds easier to remember exec's name? Whatever :)
And yes, it's definitely quickier than using mouse + menu.
No problem. Here's my thought process:
Desire: I want to start Openoffice Writer
With a good application launcher:
Alt+Space+w+enter (or maybe wri if the system hasn't learned yet)
There is a direct map from my thought (I want Writer) to my actions (start to type writer)
With a menu. Move mouse to menu icon, click, scan categories to find the category that Writer is probably in (Office perhaps?), click the entry, scan entries in the submenu for my application, click the app. This is very indirect (moving a pointer on a 2d plane to target a small rectangle) compared to typing what you want.
thats funny. what do you think your doing while typing? hitting the right small "rectangles" in the right order, perhaps? if you think using the keyboard is aktually easier then the mouse than i don't know what to say... why are you using a gui at all!?
its simple: most computer users, at least here in germany, don't type if they don't need to. because of that, they actually arn't able to use a keyboard productive. thats a direct consequence of propagating the use of a _g_ui.
most users here in germany use a menu or even more the desktop to start applications. they use the favorites to get on google.de and they reach for "Bearbeiten/Rückgängig" instead of hitting ctrl+z. oh, and they use windows, but thats a bit offtopic ;).
so, providing all sorts of shortcuts for us keyboard users is all nice, but don't leave the normal gui user out in the cold!
> hitting the right small "rectangles" in the right order, perhaps?
Yes, but that requires no conscious thought. Unless you are a first time typist, you don't tend to think about "hitting small rectangles", your fingers know where the letters are due to muscle memory.. With varying pointer acceleration and mouse sensitivity, it is almost impossible to achieve the same with a mouse. Try to launch a common app blindfolded with the mouse, versus typing that apps name, also blindfolded.
>> why are you using a gui at all!?
Nothing about a GUI ties it to a mouse. GUI's have many benefits over the CLI, completely independent of the input device.
>> most users here in germany use a menu or even more the desktop to start applications. they use the favorites to get on google.de and they reach for "Bearbeiten/Rückgängig" instead of hitting ctrl+z. oh, and they use windows, but thats a bit offtopic ;).
Yes, they have been trained this way, because keyboard shortcuts have been traditionally hard to memorize. Nothing about Ctrl-Z suggests Undo, so no one bothers to remember it (aside from us geeks). Context sensitive search is very different, in that you never have to remember anything, you just start typing what you want. Of course, it doesn't replace the menus, it merely is a more efficient way of accessing items in them.
using the mouse doesn't _need_ any conscious processing, too. ever saw a lan party?
using the mouse properly needs just as much training as using the keyboard. you only need different training.
being able to do stuff blindfolded doesn't show anything about the difficulty of the task.
the human brain is able to handle all kinds of "difficult" tasks without us thinking about it at all. and one of the most powerfull areas is the one responsible for our vision. gamers (just like helicopter pilots, or car drivers) show that our brain is indeed able to handle a mouse without any kind of conscious thought. you don't have to think "mouse 100px up", just like you don't have to position your fingers "yourself" while typing.
what about trying to type your whole next post blindfolded? just to see how much easier it is to handle a keyboard, really :P.
LOL, lan party you say, so you're clearly talking about some quake deathmatch... well, this has _nothing_ to do with launching apps on a desktop. Nothing.
sure it has. just like shooting something in quake doesn't requires any conscious thought, clicking on the desktop doesn't need any either.
how much conscious thought is required depends only on your level of training. someone new to the keyboard will take ages, and many consciouse toughts, scanning the all keys again and again, to type even simple words.
> most users here in germany use a menu or even more the desktop to start applications
do not say it that loud or you will get beaten by some usability study that your "armchair perspective" is completely wrong ... although from my experience, I would agree that most of the "lame" users that I know prefer icons on desktop ;-)
"With a menu. Move mouse to menu icon, click, scan categories to find the category that Writer is probably in (Office perhaps?), click the entry, scan entries in the submenu for my application, click the app."
You assume here that I've never used my menu before. As I said already, I have organized my menu very tightly, and know _exactly_ where everything is, and can hit most of them with muscle-memory. To be fair, if you're going to assume that the keyboard user has memorized all the executable names, then you also have to assume that the mouse user knows his menu intimately.
Either way, I'm glad that KDE lets us have both.
>> and can hit most of them with muscle-memory.
Try it blindfolded then. It is just about impossible. If you can't do it blindfolded, then it isn't muscle memory.
>> To be fair, if you're going to assume that the keyboard user has memorized all the executable names
No one needs to memorize anything. You just need to know what you want to start. I assume you know in your mind that you want to start "Kopete" before you actually perform the actions necessary to start this application. At the very least you will know something like "messenger". With a good text based launcher (Alt-F2 is a run dialog, not a launcher, it is not the same), you can start to type any of the words you already know. There is no need to ever memorize any keyboard commands.
You missed my point. Point was that I know my menu; I don't have to browse it as you suggested. I can't think of any use case where I would be computing blindfolded, so I don't open programs that way either. I can get to any program on my menu, however, using peripheral vision, without taking my eyes off the app I'm currently using.
Further, some of the programs in my menu I pass arguments to so they open just how I like. That seems a bit more difficult to do with a launcher, unless you start creating symlinks and stuff.
>> You missed my point. Point was that I know my menu; I don't have to browse it as you suggested.
No, I understand your point. But no matter how well you know your menu, you still need the visual feedback system to start apps. Now you may be very fast at finding your apps, but there is still some feedback necessary there, and a lot of memory (you are basically memorizing the exact position of all the apps you use). If apps are added or removed from the menu, and the position of your apps changes, you revert back to scanning. This never happens with keyboard based launching. New apps do not influence the launching of current ones, and there is nothing to memorize.
>> I can't think of any use case where I would be computing blindfolded, so I don't open programs that way either.
Of course not. I said that to illustrate that the task of selecting application entries with a mouse in a traditional hierarchical menu requires visual feedback and is not pure muscle memory as you suggested.
>> I can get to any program on my menu, however, using peripheral vision, without taking my eyes off the app I'm currently using.
Heh, if you had an eye tracker you would see that is not the case. Your eyes will have saccadic eye movements towards your menu as you bring it up, nothing you can do about it. This is also a funny use case. Why are you so intent on not looking at your menu? Since you are starting a new app, you are breaking your focal context anyway, so there is no point in trying to maintain it.
>> Further, some of the programs in my menu I pass arguments to so they open just how I like. That seems a bit more difficult to do with a launcher, unless you start creating symlinks and stuff.
The launcher has absolutely no effect on something like arguments. That's defined in the .desktop files, which will be used by any menu or launcher in the same way. How you find and select those .desktop files is irrelevant.
>>no matter how well you know your menu, you still need the visual feedback system to start apps...
I need visual feedback when using Katapult, also. All the stuff that starts with K requires me to keep typing until if finally get the right app. K-o-n might be Kontact, Konqueror, or Konsole.
>>This never happens with keyboard based launching. New apps do not influence the launching of current ones
No? If I installed a program call Konquest, I would have to type even more to get Konqueror.
>>Of course not. I said that to illustrate that the task of selecting application entries with a mouse in a traditional hierarchical menu requires visual feedback and is not pure muscle memory as you suggested.
Just to satisfy my own curiosity, I tried the blindfolded thing. Out of the top 20 programs that I use, I was able to hit 14 of them! I surpassed my own expectations. I should point out that I use a mousepad with a very slight "grid" indention and my thumb can "feel" distances. It also helps that the Kmenu is infinite with regards to the screen corner. I didn't practice prior to testing myself; I just have a good sense of where my stuff is. Sweet!
>>you are breaking your focal context anyway, so there is no point in trying to maintain it.
I actually do have use cases here. I frequently start Amarok while surfing. It starts minimized and begins playing without breaking my focus. I also frequently start Ktorrent to resume a download after I had turned it off for a while. It, too, starts minimized.
>>The launcher has absolutely no effect on something like arguments.
The launcher can't distinguish between the different ways that I like to start some apps. Here an example: I sometimes start Frozen Bubble in colorblind mode and sometimes in regular mode, depending on if it's me or my wife that's playing. Katapult doesn't distinguish, but my menu entries do.
And lastly - I can open my programs with my right hand while chugging a cold beer in my left! How's that for productivity!!! :-)
All that said, I still use both Alt+F2 and Katapult on occasion, and find them to be great tools.
>> No? If I installed a program call Konquest, I would have to type even more to get Konqueror.
Yes, this is because Katapult is unfortunately not a good text-based launcher. It doesn't learn. With something like Launchy, k would select konqueror if that's the app (starting with k) that you used most often. KDE does make this harder because of all the K names.
>> I just have a good sense of where my stuff is. Sweet!
Hehe. Well that's cool. I didn't think it could be done, but I guess there are exceptions.
>> Katapult doesn't distinguish, but my menu entries do.
If you have two menu entries for the different modes of Frozen bubble (with different names I suppose, else how could you distinguish them in the menu?), then a launcher will pick them up as separate as well.
Good point on the one handed casual use though, I do that as well. Of course, I have completely removed the kmenu icon from my desktop, so starting apps with the mouse is a bit difficult now :)
>>I have completely removed the kmenu icon from my desktop...
Awesome. You have made your computer idiot-proof in a new sense of the phrase :-) You're the man!
BTW, thanks for the lively and diplomatic discussion. It's been fun.
Katapult works in a similar way: http://katapult.kde.org/screenshots
"I can launch an application before you can even display the start menu. Alt-Space-F-Enter. Takes a fraction of a second and launches Firefox, ... ."
I like using the keyboard, also. This is one of the reasons I like Linux in general better than Windows (and KDE in particular). With KControl, I can assign a key combination to launch any program I wish. For me, Win-F opens Firefox, Win-T opens Thunderbird, etc. This actually seems slightly faster than Alt-Space-F-Enter, etc.
Since these options were available in KControl, I was able to use them without installing anything extra.
>> For me, Win-F opens Firefox, Win-T opens Thunderbird, etc. This actually seems slightly faster than Alt-Space-F-Enter, etc.
Absolutely. I also have these shortcuts (funny that the Windows key is actually more useful in Linux). However I don't think most people go to the trouble of defining shortcuts for every app they use, so having a system that works with every app is very handy. I tend to make a specific shortcut for apps I use every few minutes (browser mostly) and use a text based launcher for the rest, where the extra keystroke isn't going to make much difference.
Krunner is going to bring this kind of interaction to the masses (well, as many masses as are using KDE+linux :)
Please, don't be so freak. What about if I just want to see which programs are installed? should I search for all of them by writting words? Please.
Yes, and for that use case it is fine to take some time to browse the list - you don't really need speed for that.
... so it is fine to slow down the things necessary to browse the list
and while at it, why do not slow down the speed at which the browser displays the page, 'cause people do not read at greater speeds than say 1 line per second for sure, etc. etc.
- great logic :-)
I agree that what i would like most is a quick a dirty hack to get kmenu from kde3 into kde4. Should not be standard, but i'm sure many people would like it, and not those shiny animated menus. I'm simply too used to the the normal menu, and i get the application i want very fast. Perhaps a new menu could save me a few miliseconds...but.. is it realy worth it? i simply don't use the menu often enough
What I like about Kickoff is the search field. In a hierarchical menu, it can take quite some time for me to find an application that I don't use often, especially since the location seems to be different across distros and change over time.
If it would be possible in Kickoff to have the Applications tab as the first tab (instead of Favorites) and skip/speed up the enter/leave menu transition, would that solve your complaint? Or is hover vs click navigation essential?
I think there should be configurable options to start on the favorites or apps, as options are always good things. I'd also like to see the transition from one layer of the menu to the next a bit faster, perhaps via hovering with a minimal delay.
However, at the same time, I don't believe I'm the target user for Kickoff since other people seem to like it just fine.
To put it simple: If "Kickoff" is what is the default start menu in openSUSE 10.3 and if KDE 4 won't allow me to use the traditional style menu - then KDE 4 will never see the light on any of my computers.
The traditional style provides me with a much better overview of what is available to me.
I don't need the most used apps as default panel (forcing me to switch to a different panel every time) - those apps get icons in my control bar.
I don't like the slow horizontal scrolling of the sub-menus which always make me wonder where I've got lost and which force me to click back my trail on those arrow buttons on the left instead of directly seeing what other options I have on the top level.
You may put as much effort in these menus as you like, but just let the users choose.
Jason Harris / KStars: "I am using QPrinter and QPrintDialog instead of KPrinter, because from what I've read, KPrinter will probably not be ready for KDE-4.0."
In the KDE 4 release schedule it says under Printing (current state: showstopper): "All current users of libkdeprint (ie: KPrinter) need porting to QPrinter/QPrintDialog/KPrintPreview."
So does this mean...?
* KDE 4.0: Ditch KPrinter. Port all programs from KPrinter to QPrinter.
* KDE 4.1: Resurrect KPrinter. Port all programs from QPrinter to KPrinter.
That's how I would reconciliate the two statements. But that sounds a bit strange, of course. Or is KPrinter going away for good? What is the story?
It's a said story. A story about how KDE managed to kill one of its former showpiece applications through carelessness, lack of maintenance, bit-rotting and abundant negligence.
I would never have thought that Gnome would ever have better printing support than KDE. But soon it will (and not because Gnome has catched up).
That's an interesting way of spinning the events.
What really happened is that the person who wrote the code barely documented anything, making him the only person with a realistic chance of maintaining it. Since he no longer has time to do so, and since printing is inherently a complex field that few people know anything about, it had to be ditched - people tried to get it to work, but were defeated by the daunting 50k+ lines of code with very little comments. There's no way they could have got it in shape for 4.0 and if they had left it in, they would have had to support this mess through the entirety of the KDE4 cycle. These people are overworked enough as it is, without having to take on this additional burden.
Saying that "KDE killed it" through "abundant negligence" and "carelessness" is nonsensical - they don't have the funds to hire people to work on printing, and they can't *force* volunteers to work on it, so what could they have done?
Well actually "50k+ lines of code with very little comments" is negligence and carelessness. And blaming "KDE" seems appropriate as the development process didn't work. Stricter guidlines and policy enforcement for documentation of core components of KDE would be a good thing.
Not really trying to play a blame game here. Of course people are overworked and most fon't even get paid to do anything, we all know and understand that. This arguments can be used to 'justify' any lower quality standards, be it missing features, bugs, or whatever. Instead it seems much better to just look at what happened, try to learn from it, and find ways to minimize the chances of it happening again.
> Well actually "50k+ lines of code with very little comments" is negligence and carelessness
or a sign that the task is rather complex or would you name any project that has more then 50k loc "negligence and carelessness" ?
No. Just those with very little comments. Got it?
Send your patch to any one of the kde developers. I'm sure they would appreciate it.
Derek
Maybe you've read that answer a number of times and from the context you deduced that it's something you're supposed to say whenever someone is or seems to be "complaining" about something. If you actually pay attention to the meaning of those words and to the content of my post though, you'll eventually realize that in this particular case talking about a "patch" is nonsense. I wish you better luck with your next use of this standard answer though. Cheers.
Actually I'm very serious.
Complaints in a contribution community are corrosive.
We have a large number of people who work long hours without pay to make KDE. They are well aware of the shortcomings of the code. That's why they work long hours on it.
I would rather act in a way that gives them an idea that I appreciate what they do. Corrosive complaints actually cause people to not want to give to those who seem only to complain.
So again, where is your patch? I'm sure it would be appreciated.
Derek
I know you're serious. You're just not making any freaking sense.
Okay, in freaking simple words: you see a problem. Go fix it.
First of all let me say that I really respect your work and enjoy reading your posts. Honestly that is the only reason why I even bother to reply.
The whole point of my first post was to say, there was a problem and it shouldn't be ignored. Any developer knows that 50k lines of code without proper documentation is insane. Also suggested that maybe enforcing stricter guidelines regarding documentation of core components might be a good idea.
Not being allowed to acknowledge problems unless you're able and willing to fix them makes no sense. And Kite's talk about submiting patches just reads like a post in the wrong thread, totally out of place.
Keep up the good work!
>> Keep up the good work!
Hint: mixing your encouragement with unfounded whining makes the whole thing ring hollow.
The problem is with KDE allowing 50k LOC with minimal documentation in an important part of th DE. I can't think of a patch to send in to correct that policy shortcoming.
QPrinter has caught up quite a bit with Qt4, from a maintenance and support point of view, it makes total sense to base KDE's printing more closely on the one of Qt4. With those changes, we don't have to choose wether to implement everything ourselves. We can now do cherrypicking from the Qt's printing system. That also helps a lot with platform compatibility of course.
Even if KDE4's printing support will not be as excellent as KDE3's, I'm sure this will get sorted out over time.
So, this means that we will not have the "multiple pages per sheet" option in kde4?
Man will i miss it.
It means that for KDE4.x we ditch KPrinter completely since QPrinter does everything KDE3's KPrinter (class) did, and even more plus its actually maintained.
The obvious advantage is that there don't have to be two parties both doing approximately the same printing development, KDE can just depend on the stuff that Qt does and get all the new features themselves; something that didn't happen with the old system we had in KDE3.
Is there any work on a Yakuake port to KDE 4?
I thought I had read somewhere that real transparency was going to be included int he KDE 4 version, but I haven't seen any development on it that I'm aware of. Again, this isn't something vital, but I do love Yakuake.
> Is there any work on a Yakuake port to KDE 4?
It's not been ported yet, but the plan is certainly to have it available in KDE4 Extragear in time for the KDE 4.0 release. The Yakuake codebase is fairly small, and a full port shouldn't take more than weekend. COMPOSITE support is still on the roadmap.
Sounds fantastic! Thanks for the update.
And color me ignorant, but doesn't konsole support composite/transparency now? Doesn't yakuake depend on a konsole kpart?
Yes, but the standalone Konsole application doesn't actually use the KPart, and Konsole and the KPart each implement background painting individually. The KDE 3 Konsole application does have a hackish implementation of COMPOSITE support (that requires a Qt patch to work without side-effects), but the KPart does not: the provisions to adjust the painting depending on whether or not an ARGB32 visual is used are deactivated.
Fair enough. However I'm assuming the code to the painting can be easily copied/ported from konsole to the newly ported yakuake when that is done, right?
No, you didn't catch that right. The culprit with regard to COMPOSITE support is the Konsole KPart, not Yakuake, and fixing that requires changing the Konsole KPart, which will hopefully materialize for KDE 4.
Sorry. When you said they each handle painting separately, I thought that meant painting was outside the KPart.
Konsole doesn't use the KPart.