JUL
16
2007

KDE Commit-Digest for 15th July 2007

In this week's KDE Commit-Digest: Much work in Amarok, with the implementation of a CoverFlow-esque OpenGL album art visualisation, codenamed "CoverBling", and Service Framework and Plasmification efforts. Sample OpenGL-based applets added to Plasma,, with Plasmoids to watch for changes to files, for browsing files, and to monitor network interfaces. General progress in the 2d projection and KML in Marble, OpenPrinting, and KOrganizer Theming Summer of Code projects. KWallet support in KRDC. KMines essentially rewritten with a QGraphicsView base, with support for multiple background SVG themes in KGoldRunner. More manipulation and view work in Kreative3d. Implementation of Kubelka-Munk paint mixing research in Krita. Internet integration in Kaider, with a WebQuery view and example script to use Google Translate. okular becomes usable as a print preview component. KTrace, a "strace" interface for KDE 4 added to playground/sysadmin. Beginnings of support for ComunIP, a Brazilian IM protocol in Kopete. More progress in the porting of Digikam and KTorrent to KDE 4. The start of a rewrite of the Oxygen widget style. KBFX, an alternate K menu, moves to kdereview.

Comments

"KBFX, an alternate K menu, moves to kdereview"

As I know KMenu and KBFX, both will replaced by Raptor Menu of Plasma and Kicker will have no place is 4.x Series.Where doest KBFX Wants to go?


By Emil Sedgh at Mon, 2007/07/16 - 5:00am

It's in the realm of possibility that Raptor is "just" a renamed KDE4 version of KBFX since it's developed by the same team as far as I know. Raptor has been a very elusive target for some time now which is worrisome to a slight degree as the application launcher menu (or start menu :-P) is a commonly used tool which has hopefully gone through some usuability review.


By Erunno at Mon, 2007/07/16 - 5:00am

IMHO, we should kill the menu-idea and integrate the Applikation-start in the desktop itself. But well, this, could be to innovative for most of the visiting windows-geeks :->

But, hopefully there comes one day a functional quicksilver-clone, so the menu-button could replace with a button to show the dialog of this clone ;)


By Chaoswind at Mon, 2007/07/16 - 5:00am

Hopefully, Plasma will lower the barrier to entry and making writing/ installing such things so easy that we'll see all sorts of novel and innovative designs thrown together. Only time will tell, though :)


By anon at Mon, 2007/07/16 - 5:00am

Personally, I rarely SEE my desktop, never mind use it. Usability wise, it makes no sense to have windows that don't reach the edges of the screen. It's easier to throw a mouse into the corners/edges and click, and it's better to have a larger, more detailed, full-screen view without contrast issues between the desktop and the background. Combine that with multitasking, where I have lots of windows open, and even closing one still leaves other windows... they all close in time, but rarely back to a blank desktop.

This all makes the desktop pretty much useless for interactivity. That's why we have taskbars; to provide an OS-interface that's actually visible and usable despite having windows open.

So, no, please don't put anything on the desktop. Also, please don't make any of these new plasma things necessary. Ideally, please make sure they're all fully dockable in the panel/kicker, too.


By Lee at Mon, 2007/07/16 - 5:00am

I rarely use my desktop as well, but that's partly due to the fact it's pretty useless now - so it's a habit not to use it! I'm open for changes, provided the desktop is easily accessible and useful...

[i]Ideally, please make sure they're all fully dockable in the panel/kicker, too.[/i]

Don't worry, they'll do that. Each applet will have 4 states, one on desktop, media center, panel and another one I don't recall.


By Jos Poortvliet at Mon, 2007/07/16 - 5:00am

Thats true. The Desktop ist mostly useless, and that's why he should become more functional. I think, it would also better if work more like a normal window, with a regular entry in the taskbar and such.


By Chaoswind at Mon, 2007/07/16 - 5:00am

Sometime ago, I made a suggestion that both of you could probably live with:

http://home.earthlink.net/~tyrerj/kde/NO-menu0.png

The row of icons acts like a child panel that can be covered with other things but which is brought to the front when the mouse touches an edge or corner of the screen -- this would be configurable as would the position of the menu.

Clicking on these icons would bring up that section of the menu which would act just like it currently does.


By James Richard Tyrer at Mon, 2007/07/16 - 5:00am

That's possible now, but it makes it awkward (if not impossible) to have things show status, such as when you have mail waiting (note: not when it arrives), or when your network or cpu usage is climbing, or when you just want to keep an eye on the time regularly over the next few minutes before you have to go somewhere.


By Lee at Tue, 2007/07/17 - 5:00am

> That's possible now, ...

Yes, but some further improvements could be made if it was a special type of panel rather than just a regular child panel.

> but it makes it awkward (if not impossible) to have things show status,

That is a child panel; it is in addition to the regular panel.


By James Richard Tyrer at Wed, 2007/07/18 - 5:00am

you never see your desktop, others go to it all the time. oh my, what ever will we do?! =)

how about this: we make the difference between panels and desktop go away. we make it so that anything that can appear on your desktop can also appear on a panel and the only difference that "thing" sees is a difference in a form factor variable.

which is exactly what we've done.

let's go to the next step here: let's allow the desktop to be treated similarly to the rest of your windows and allow it to be brought to the front of the existing windows!

which is exactly what we've got planned.

the original poster wanted to see a quicksilver clone. well, i'm not much on cloning (think of sheep! baaaa means no!) but krunner will be pretty close to providing what quicksilver does in 4.0 and we'll be able to continue improving it for 4.0+N

everyone happy now?


By Aaron Seigo at Tue, 2007/07/17 - 5:00am

"everyone happy now?"

Yep :)


By Lee at Tue, 2007/07/17 - 5:00am

personally, I love what Gimmie did: http://www.beatniksoftware.com/gimmie/Main_Page

did you have a look at that?


By Jos Poortvliet at Wed, 2007/07/18 - 5:00am

of course. i've also discussed the various issues with the author in person. we once shared a row of seats on an airplane even... made for a much less boring trip.

that said, i'm a lot less interested at the moment in creating something like gimme than i am in creating a system where creating things like gimie is stupidly simple for those that want it.


By Aaron J. Seigo at Wed, 2007/07/18 - 5:00am

Personally, I don't like having to lose any real estate with any program I am using. Like an earlier post stated, "Usability wise, it makes no sense to have windows that don't reach the edges of the screen." Which is true, at least for me, which can be accomplished now by having the kicker panel "auto-hide". However, I also like having certain things visible to me all the time. Which makes what I want impossible right now, I can't have my cake and eat it too as the saying goes. If I want to always see the clock, I can't have the window reach the edges of the screen, if I want the window to reach the edges of the screen, I can't see the clock. I hope with all the compositing stuff that is going on now, someone will figure out how to use transparency to our advantage by letting us finally have AND eat that cake. Why can't a small transparent clock reside above all windows, with an easy drag to move it if it gets in the way, or click to hide it if necessary, or better yet, by simply moving the mouse to a corner. That way we could have "the best of both worlds".


By Mike E at Wed, 2007/07/25 - 5:00am

No, I dont think so.
If it was just a Rename, then...why rename?I dont know about its development team but Im sure to make a Plasmoid, you need to Create a DataEngine to Feed the Plasmoid.Raptor menu should be a Plasmoid that uses a DataEngine and as I know, there is no dataengine for Application List, so the raptor Team have to develop the DataEngine too...
KBFX is a Kicker applet which doesnt work as a Plasmoid.
even if it works, Im sure Plasma team doesnt wants an Official Plasmoid which is included in a Default KDE Workspace be a Not-Native Plasmoid that uses different architucture.


By Emil Sedgh at Mon, 2007/07/16 - 5:00am

I'm aware that Raptor will be using Plasma as there's a projekt page about it on Techbase. I was more thinking about the user interface when calling it a "renamed KBFX" and less about the technical foundation. But you're right, of course, Raptor should be drastically different from a technical point of view.


By Erunno at Mon, 2007/07/16 - 5:00am

> there is no dataengine for Application List,

Is'nt the new filewatch-engine useable for this? IIRC i read such a thing in their description.


By Chaoswind at Mon, 2007/07/16 - 5:00am

Thats a FileSystem Browser.There is a video showing it.I dunno where, I cant remember, maybe Youtube or Dev Blogs...
Raptor Menu needs a DataEngine that gives information such as Categorized List of Applications, Newly Installed Applications, etc.


By Emil Sedgh at Mon, 2007/07/16 - 5:00am

From http://marc.info/?l=kde-panel-devel&m=118410336007163&w=3

[..]the engine is intended to be used in making the kmenu replacement[..]


By Chaoswind at Mon, 2007/07/16 - 5:00am

then, sorry for wrong information...


By Emil Sedgh at Mon, 2007/07/16 - 5:00am


By debian at Mon, 2007/07/16 - 5:00am

I'm sorry but from what things look like now it would be absolutely crazy to consider using kbfx or raptor instead of Kickoff, the K menu developed by several top KDE developers and which comes as the result of several usability studies. It has also been in openSUSE and Sabayon by default for some time, and has worked incredibly well.

From what I've seen of Raptor it seems to be a mild attempt at trying to replicate most of the Kickoff Stuff. Why, exactly, is Kickoff not just used? (I'm sure it could easily be ported if this was to be decided)

Yes, everyone keeps saying "kicker will be out, plasma will draw the panel"... yes, so what? Are we going to have a K menu or not? If we are, I can see absolutely no good reason for not having Kickoff in by default. It's incredibly awesome, makes you very productive, a lot clearer instead of the current KDE menu which is a little antiquated now, etc. There have also been extensive studies on it, which is great.

So: why not Kickoff? KBFX and Raptor (unless it pretty much just completely imitates Kickoff) are not viable options IMO.


By apokryphos at Mon, 2007/07/16 - 5:00am

At least once you are used to it.

With some plasma-Modifications it could easily be one of the very best start menus available.


By Max at Mon, 2007/07/16 - 5:00am

So: why not Kickoff? KBFX and Raptor (unless it pretty much just completely imitates Kickoff) are not viable options IMO.

So basically you have no clue what Raptor will be like, but you've already decided that it will not be viable. Hmm, maybe you should just stick to saying "I like Kickoff."


By matt at Mon, 2007/07/16 - 5:00am

No, I've seen several posts about it, the links provided on techbase, and the _original_ mockups for the idea. Again I ask, why was kickoff not considered? If it was, what were the reasons for rejecting it? I've had several discussions on #kde4-devel, #plasma etc where no reasonable (and even remaining) objections were presented.

So tell me :)


By apokryphos at Tue, 2007/07/17 - 5:00am

because kickoff is completely useless? at leased if it still works like shown on the videos...

kickoff completely destroys the main idea of a menu: easy browsing. it should as easy as possible to browse through the menu. back buttons instead of additional windows and scrollbars make a menu completely useless...

a normal menu is useable without any clicks (after its opened, at leased), you can switch bitween serveral levels/folders with the move of the mouse.

kickoff needs at least a breadcrump like thing, and automatic resizing - instead of the back button and scrollbars...


By ac at Mon, 2007/07/16 - 5:00am

The Main idea is that whit the favorite menu you shouldn't need to browse the applications menu.


By Luis at Mon, 2007/07/16 - 5:00am

> kickoff completely destroys the main idea of a menu: easy browsing.

Videos? The usability studies are fully available, with videos, for you to see. No-one told these people how to use the menu before they used it. The stats are also public: people are more productive with it.

Despite what you've been tricked into thinking with the current K Menu, the main point of the menu is NOT to quickly browse _all_ applications, though that is _a_ function of it. The general user won't use more than 5 applications 95% of the time. Once you realise this it's almost senseless to give "all applications" precedence over favourites.

There are so many other great things with it that it's hard to decide really where to begin. Search with integrated results (alt+f2 and katapult's fatal flaw), quick access to history, nice, not too big.


By apokryphos at Tue, 2007/07/17 - 5:00am

I think the main function of the main menu is to browse all applications. You can (currently) put icons of the most used applications on the panel, or you can put them on the desktop and put a quick browser applet for the desktop on the panel. You can even have more than one custom menus with the quick browser applet. And, there is also a place for most/recently used applications at the top of the standard K menu.

Even people use 5 applications regularly, there _is_ a need for a menu for browsing all the applications, especially for a beginner who wants to explore the system.

Kickoff is much less configurable than the standard K menu. It is good for some people and useless for others. As Mark Twain said there are lies, damned lies and statistics.


By Grósz Dániel at Tue, 2007/07/17 - 5:00am

I completely disagree that that's the main menu's function. It's pointless to say that the menu's main purpose is to do something that would be done on rare occasions. If you think users should browse all applications every time they want to launch an application then you are quite mistaken.

> Even people use 5 applications regularly, there _is_ a need for a menu for browsing all the applications

This would only be a problem if the "all applications" was no longer accessible. Whereas in actual fact it is very accessible, and its location is quite obvious to everyone.

Kickoff is reasonably configurable from the CLI, though making it more configurable is a bit of a trivial task so could hardly be a reason for rejecting it.

Please let me know which people kickoff is useless for. Proposing a non-existent usecase, like someone who browses all applications every time they want to launch an app, really just doesn't cut it.


By apokryphos at Tue, 2007/07/17 - 5:00am

well, whats the point of the menu then? the all-apps-menu in kickoff is way slower to use. not only when browsing through every app - everything thats not on the first level or hidden because of the scrollbars is slower to reach then in the standard k-menu.

there is nothing better about the all-apps-menu of kickoff. the things that may be better are the extension to the menu. though these could be used with a standard menu as well...

i don't think usebility experts would argue about that... the kickoff menu is the way it is because it should look cool, and different. a kmenu with search and favorites would be way more useable.


By ac at Tue, 2007/07/17 - 5:00am

K menu has "favorites": you can set the number of mostly or recently used programs which appear at the top of the menu. It also has a search box in which you can search programs. You have Kerry for desktop search - in the current concept K menu is for launching applications, while desktop search is a different thing, so it is not integrated in the K menu.


By Grósz Dániel at Tue, 2007/07/17 - 5:00am

> It also has a search box in which you can search programs.

The original KDE menu doesn't have this.


By Anonymous at Tue, 2007/07/17 - 5:00am

I use KDE 3.5.5 on openSUSE 10.2. openSUSE people may have patched it.


By Grósz Dániel at Tue, 2007/07/17 - 5:00am

"If you think users should browse all applications every time they want to launch an application then you are quite mistaken."

No, I don't think so. But there are other possibilities to start frequentely used applications: panel icons, quick browser panel applet, recently used items at the top of the K menu. We need those also, of course.


By Grósz Dániel at Tue, 2007/07/17 - 5:00am

After all, why is the Kickoff style of navigation (which I think is definitely slower than the classic menu navigation) better?


By Grósz Dániel at Tue, 2007/07/17 - 5:00am

I don't like it either, but they've done a bunch of usability studies on several subjects, and they clearly showed that ALL actions require less mouseclicks and less time with Kickoff compared to the current KDE menu.


By Jos Poortvliet at Wed, 2007/07/18 - 5:00am

how is that possible if you can't use the main menu without clicking? the current k-menu only needs clicking to start applications, folders are opened with mouseover alone. and thats still the ideal case for kickoff. if your menu is "too large", it gets even worse because of scrollbars....

kickoff can't be faster for everything. its only faster if you use the new extras. but those extras could be used with a standard menu, too...


By ac at Wed, 2007/07/18 - 5:00am

Standard K menu needs exactly 2 clicks for everything. Kickoff needs at least 2 clicks for everything and more than 2 for starting an application from the all applications tab. So all actions require the same or greater number of clicks in Kickoff than in the standard K menu.


By Grósz Dániel at Wed, 2007/07/18 - 5:00am

Correction: I understand. You don't need to click to open the Kickoff menu. But I don't think it makes it significantly faster.


By Grósz Dániel at Wed, 2007/07/18 - 5:00am

"The general user won't use more than 5 applications 95% of the time"

Once you realise you don't need a start menu for your 5 applications (a quickstart menu in kicker/plasma panel'll do) favourites becomes quite obsolete. The menu is used for the stuff you don't often need access to, so adding an extra layer doesn't make it more productive. There are other solutions to adress the 5 applications 95% of the time 'rule'. Kickoff (IMHO) is a complete and utter mess and solves the problems you bring up in the wrong way.


By Matthias Logghe at Sat, 2007/07/21 - 5:00am

> From what I've seen of Raptor it seems to be a mild attempt
> at trying to replicate most of the Kickoff Stuff.
> Why, exactly, is Kickoff not just used?

You seam to forget one of the motivations for Plasma. People had a hard time writing new panels / plugins. Each task panel had to re-implement the backend code for accessing task data. For RSS feeds, people had to re-implement rss parsers. The list goes on.

Plasma separates this. It provides "data sources" for all kinds of data. There will be "data sources" for things like taskbar tabs, menu data, the time, rss fees, etc. etc... You can write a new GUI on top of any of those, and another. Each one re-uses the same "data engine" plasma provides, both reducing CPU time and code size.

So instead of copying Kickoff, I assume the Plasma developers make a "start menu data source", and a default GUI for it. It will be painfully easy to write a different start menu instead. That's what the Plasma design is about too!

And there is one more thing...
Copying is boring, and you can do better then that. e.g. take the new dock appearance of Mac OS 10.5. Perhaps they spent 4 months on it, and were happy with the results. At some point you'll always be glad what you've got out, and you'll be blinded by any imperfections. In this case we have two options:
- copy that UI litterally
- spent one month extra of thinking "how can I improve _upon_ this"?
After all you have a fresh mind and not tired of 4 months research.
And it makes all the difference.


By Diederik van de... at Mon, 2007/07/16 - 5:00am

> Copying is boring

Using KDE's own work is 'copying'? Using something different which might be worse just doesn't make much sense. Kickoff has been proven to work, and there's no good reason (even in your explanation of Plasma) for why the menu could not be ported (yes, using all the later plasma goodness). Of course we're essentially talking about the UI.

> - spent one month extra of thinking "how can I improve _upon_ this"?

What exactly is there to say that Kickoff itself could not be improved?

What I'm mildly worried about is getting a far worse menu (Raptor, from what I've seen of the mockups) when a much better one is available, for almost no reason at all. I have no idea why you would want to ignore all the research that has gone into Kickoff already. We want usability to improve in KDE4? If so, why exactly are we ignoring the studies that have taken place? It doesn't even look like the people doing the raptor mockups have even looked into the openusability stuff. Not a very comforting approach.


By apokryphos at Tue, 2007/07/17 - 5:00am

Kickoff is not available, as -- to my knowledge -- it's not ported to KDE4 (yet?). Raptor is KDE4 code, and with the feature freeze approaching, the solution that is available will be used. That doesn't mean that this menu won't change in the future (replace, improve), it's only an observation you seem not to have made yet: How things work in KDE development.


By Sebastian Kügler at Tue, 2007/07/17 - 5:00am

I think you're missing the point here. I'm trying to say people should think first. Not just assuming something is good because MS, Apple or openSUSE designers invented it. KDE4 wants to make a good first impression, so they should consider more options. Look what exists, learn from it, and improve upon that.

> > Copying is boring
> Using KDE's own work is 'copying'?

What other term would you propose then? :-p If I use idea's from other projects, and incorporate them in my own it can be not copying, depending on the similarities between the two. But just taking a project, improve only 1-5% means you're copying that 95%.

> Kickoff has been proven to work, and there's no good reason (even in your
> explanation of Plasma) for why the menu could not be ported (yes, using all
> the later plasma goodness). Of course we're essentially talking about the UI.

Thereby you're ignoring the fact how code is written. "Only talking about the UI" and "except for the explanation of plasma" are easily said. Just like "put this body around a different shaped car please".

Those things are not that easy! It means code architectures don't match at all, and any potential entangled part needs to be cut loose first. The whole point is Plasma is to make it easy to "only copy the UI". Almost every project out there doesn't allow this.

> > - spent one month extra of thinking "how can I improve _upon_ this"?
> What exactly is there to say that Kickoff itself could not be improved?
>
> I have no idea why you would want to ignore all the research that
> has gone into Kickoff already.

What exactly is there to say that Kickoff is being ignored?

> It doesn't even look like the people doing the raptor mockups have even
> looked into the openusability stuff. Not a very comforting approach.

Ctrl + F for kickoff in this page please: http://techbase.kde.org/Projects/Plasma/Menu


By Diederik van de... at Tue, 2007/07/17 - 5:00am

I have only a passing knowledge on the research conducted for Kickoff, but considering my personal experience with the K-menu, I could easily imagine an important flaw in the user-testing.

First of all my suspicion on the research is this; Novell funded most of the research, so the K-menu used for testing was the implementation used in recent Suse distributions.

Based on how big the perceived difference for me between the K-menu in Suse 9.3 and 10.0 and the K-menu in Kubuntu 6.06-7.04, the exact same technology can with only a minor change go from causing a nightmarish to a blissful experience.

My issue with the implementation Suse followed (as I remember it) was:
1) Putting the burden of choice between applications on the user. Putting too many options in the menu.

2) Naming and placing applications in unintuitive ways (I believe Amarok was placed in multimedia, which was OK, but it was named "Audio Player (Amarok)", which _sounds_ like good nomenclature until you have many applications called "audio player", or wish to find the application quickly without using search)

3) Putting slightly too many features in the same place ('all applications', 'favorites' and 'search' made it a little too cluttered for me)

Now, it seems to me that Kickoff fundamentally has the same goals as the Suse menu. It tries to accomplish the feat of supplying a wealth of information, but this is something I personally do not want it to do. In my eyes it is a clever way of solving a dumb problem, and the research conducted on kickoff might (if I'm correct in my starting assumption) have been influenced by not asking the right questions.

Personally I primarily use (not counting pervasive applications like Kget, Kmix, Klipper etc.) the following applications: Amarok, Akregator, Kopete, Ktorrent, Firefox and Konqueror. Out of these only Firefox requires me to use the K-menu since the other applications start on default (or in the case of konqueror, via an applet).

Kickoff would allow me to open this program (Firefox) easily, but so would the Kubuntu version K-menu (Internet -> Firefox becomes very fast after a while :) or any other non-cluttered, intuitive menu.

Other, fairly important applications such as Kaffeine, Dosbox (personally important), K3B or Ark do not really need the menu either, since they are mostly opened 'automatically' in the instances where they are needed.

So far, so good. What I have pointed out so far doesn't really put Kickoff in a bad position even for a user like me. But as others have said, Kickoff isn't the most pleasant menu when looking for an application that _isn't_ used regularly, and since many people (not just me) almost only use the menu for such things, Kickoff does not seem like the right choice for KDE4. Granted, all the efforts put into it should not go to waste, but I would not like to see it become the default or even to see the alternative default (Raptor) being overly inspired by what Kickoff seems to try achieving.

In the end I trust the KDE developers will find a solution that is far more intelligent than anything I could come up with, even if it ends up resembling Kickoff. But having said that, you shouldn't think Kickoff has unanimous support amongst regular users just because of the results of scientific research. Science depends on the question asked, and I'm not sure Kickoff answers the same questions that Raptor will address.

Hope someone reads this tripe :P (and sorry if the English is a bit rusty, I haven't written in English for awhile.)
-NicolaiM


By NicolaiM at Wed, 2007/07/18 - 5:00am

About the original SUSE K menu:
1. But almost all of these applications have to be in the menu because users should be able to find and run them somehow. Kaffeine and Ark is often started through an associated file, but for example I start K3b many times from the menu.
2. You can set this in the panel settings.

About starting firefox: in openSUSE there is a place for recently or frequentely used applications at the top of the original K menu.


By Grósz Dániel at Wed, 2007/07/18 - 5:00am

DISCLAIMER: I'm in no way connected to/know the author of the following software, other than I requested it be included in Kubuntu.
Why KBFX? TastyMenu is lightyears ahead, usability- and bug-lessness-wise, imho. (I never could get KBFX to work/look "right" (tried on both Kubuntu and gentoo), might be me, though).
TastyMenu takes the best ideas from both KBFX and SuSE/Novell's Kickoff and integrates them into the best menu I've seen on any OS.
http://www.notmart.org/index.php/Software/Tasty_Menu_0.8.2


By Martin at Mon, 2007/07/16 - 5:00am

I fully agree.


By Tiberiu Ichim at Mon, 2007/07/16 - 5:00am

Pages