In this week's KDE Commit-Digest: Resurgent development work on KDevelop 4, with work on code parsing, code completion and the user interface. Support for converting the KVTML XML-based format to HTML in KDE-Edu. Support for the much-wanted feature of multiple album root paths in Digikam. Various continued developments in Amarok 2. Multiple additional comic sources for the Plasma Comic applet. Support for Kopete plugins written in Python, Ruby, JavaScript and other supported languages through the Kross scripting framework. A simple command-line application for playing media supported by Phonon. WavPack, TrueAudio and Speex format support added to the TagLib support library used by JuK and Amarok. Audio device work (utilising Solid) in KMix. Work begins on KsCD by a team of French students. Various optimisations in Plasma and Dolphin, amongst other applications. okular moves to a shared FreeDesktop.org library for PostScript format support. KGhostView finally removed in favour of okular for KDE 4.0. Code for supporting Apple OS X Dashboard applets via WebKit imported into playground (not for KDE 4.0!)
Comments
And then there seem to be the type of users who liked it and missed it on their distribution so that they made packages for their distribution (kde-apps.org shows Slackware, Fedora, Kubuntu and Crux). And last Mandriva has it in their distro package as option.
Mandriva even iclude it by default, it's just a right click on the Kmenu, and choose the 'switch to kickoff menu' even from the liveCD.
But thanks for keeping old plain Kmenu the default :)
"Kickoff did get some changes between 10.2 and 10.3"
Sorry, I just tried Kickoff in both versions, I didn't notice the change. Anyway, the application browser did not improve.
What non-gui options did kickoff get in 10.3?
See the comment of Sebastian, it has the links.
Hate to be the one bringing this up, as it has been discussed over and over. Beta state should mean everything has been implemented and it's time to test, bug fix and optimize.
Yes , and many have probably switch back to
the old menu without make some noise ;-)
at least my daughter , who is not a computer geek,
screams if put the new menu active.
Yes, kickoff seems to be OK. I haven't conducted a usability study so I really can't say if it is better than the large tree structure of KMenu in KDE3.
One thing which I really like is that it has room for larger type.
I wouldn't say that Kickoff is pretty but it's very usable, it's nicely structured and the built-in search function is just great.
Kickoff needs a little polishing and a few eye-candies and then it would be perfect for me and my wife :) I prefer it to every start menu that Windows has and even KBFX.
People bash Kickoff unfairly like you pointed out and give Raptor hig ratings (I can't say anythig about it because I never used it) but I like a few others, think that it would be a good idea if the Raptor crew would work together with the Kickoff guys to making ONE GOOD START MENU for KDE. We don't need a thousand! All we need is one good one that everyone can adjust and configure to fit his/her needs and taste. The Open Source people need to learn to work together more instead of scattering their talents all over the place. Together we are strong!
I disagree strongly.
First, an advantage of open source choice. There are a bunch of different solutions to choose from, free to try, and modifiable if I don't find something that suits me.
Second, Kickoff is essentially useless for me. I've tried it, and it gets in my way for what I use application launchers for. Although, I don't discount its use for others.
Third, from what I can tell, raptor should fit me well. If the Raptor crew junked the project to work on KickOff, I'd be screwed, since I don't have the creativity to come up with something like raptor for myself.
Finally, there are the cliches like "too many chefs to a pot". If everyone worked on one thing, it would be disorganized, and never get done, since everyone would have different ideas for it.
You are right about choice but sometimes I think that too many projects at the same time for the same thing without having one very good product isn't really good.
Look at the Linux Kernel for example, it's only one Kernel that thousands of developers work on and it gets better and better everyday. I don't know if that would be possible with 100 Linux Kernels. Yes there are many distros which makes choice possible but in some cases also causes confusion for newbies.
Now back to the start menu. Like i said, I can't say much about Raptor apart from what i read and the fact that it looks real cool (screen shots). It sounds like your have tried it the way you wrote. I would like to do the same in order to make a fair comparison. How can I install and use it in KDE4 (present beta)? I would appreciate a few tips. Thanks.
"One example: the navigation between the tree of applications is still very awkward and confusing. But don't you think the Kickoff guys know about it?"
Not everyone can simply assume this when looking at how long it has been like this in the openSUSE environment.
In the current vanilla kde 3 environment, when one clicks on the K, one can then simply look/hover around the application tree. So far I have not seen this very, very simple and effective mechanism replicated in any new start menu, which I believe makes some people somewhat nervous as in overlooking something relatively obvious. Note that this only about navigating that tree, not necessarily how you get to that tree in the first place. You can't blame people when, seemingly, already Kickoff has been developed in a vacuum of perceived perfection, all the while having this relatively obvious problem, at least to me.
Well yes, I guess it will be solved, I guess, but how such a design survived for so long in the first place, is a bit of a mystery to me.
> You can't blame people when, seemingly, already Kickoff
> has been developed in a vacuum of perceived perfection
That is not the case. The reason why Kickoff (in KDE 4) is essentially identical to the one in KDE 3 (at present) is very simple - it is just down to a lack of resources and time.
The original design was the result of an iterative process of refinement done by Novell engineers with the aid of a usability lab. When I wrote the initial code for the KDE 4 version, the only tool I had was a laptop. I didn't have any means to test whether major user interface changes cause usability 'breakage', other than basic heuristics. Therefore I copied the KDE 3 design verbatim - aside from a few aesthetic changes and fixes for problems that could not be solved easily in KDE/Qt 3 for whatever reason.
I personally do not encounter the problems described when using the Application tab, so without actually seeing video footage of a poor suffering user, it isn't obvious what is not working.
Although I am no longer involved with it, discussion about Kickoff happens on panel-devel and kde-usability for those who wish to participate.
Thanks Robert for having invested your time into this earlier, that's the least I should offer.
I guess there is a good case for the way the new app. tree is to be browsed and 'my' way must have it's flaws too. The reason I fall over this is, for me it is related to speed and oversight. When I started kde4 beta with the kickoff menu, I found myself aiming left and right only to navigate the application tree. I lost speed and oversight in relation to the app. tree. The result was I could not quickly scan the available applications or get to them and ended having to iterate and click trough each category.
Reading bellow comments, I see there must be cases where this new approach actually solves problems, obviously it would solve problems in some cases. But still, I find the 'old' approach where you can simply with 1 single click quickly hover over each category and sub category and quickly get to where you want without having to aim for extra mouse clicks left and right to browse the tree, much easier and faster.
If I am a minority with this view, I suspect I am missing something, but I just find for myself the one click quick hover approach to be faster and less confusing. I don't have a video of myself or others struggling with this, but all I know is that I was struggling to get trough the application tree in that kde4 beta kickoff menu. All I thought was that it was supposed to be more easy, all I observed was a bit of frustration with it on my part.
If I have time, I will see if my experience here is shared by any others and do so on panel-devel and kde-usability as you suggested.
I totally agree with you. This is exactly the problem I have with Kickoff's application browser. While I applaud their effort to try something new in this regard, I also think they should have the courage to admit that the experiment failed. Trying to hide the application tree does not make life easier for users -- quite on the contrary: it makes them a) feel lost among the categories, and b) make access to applications so slow as to be frustrating.
Moreover, I'm a bit suspicious of these so-called usability tests they supposedly performed. I found a few guinea pigs around the office and gave them Kickoff to try out. While they like the general look and feel and love having quick access to favourites and whatnot, everyone found the application browser awfully confusing. Granted, these 3 people were all Windows XP users, so they might be more used to the more traditional tree-like approach, but still, I really would like the meet a person who thinks that hiding a tree structure makes life easier.
"I really would like the meet a person who thinks that hiding a tree structure makes life easier."
That seems to be the prevailing thought among people working on file browsers. A tree view squeeked into Dolphin, but is surely off by default. Hardly a surprise that the same thinking is now being applied to the application^H^H^Heverything menu.
Sorry dude, but Dolphin does NOT try to hide the fact that you're navigating through a tree structure. The "bread crumbs" are very visible.
In any case, you can hardly compare the file system tree to the application tree. The former is orders of magnitude larger. When dealing with trees of that size you need different metaphors.
I still maintain that it's a mistake to hide the arboreal nature of the application tree.
>>If I have time, I will see if my experience here is shared by any others ...
Why? The comments here and in previous dot articles should tell you straight away that your experience is shared by others. Here's my best "usability" anecdote:
I'm an IT Tech by trade, so my 8y/o son naturally gets lots of computer exposure, and is pretty savvy at this point. When I first installed OpenSuse with Kickoff, I had to explain to him how to find the various programs that he uses. Even after I showed him, he told me that it was like trying to "find his programs in a maze." I immediately switched back to the K menu (thanks for leaving it as an option, guys). I gave it some thought later, and decided that his maze analogy was right on - try this path, no, backtrack, try that path, repeat. It seems to me that Novell were trying to solve a problem that didn't exist. Getting to my programs should be natural and unobtrusive. K menu did that; Kickoff misses the mark for me and my 8y/o.
> If I am a minority with this view ...
maybe WE are minority, but it seems that we are being taken seriously ... once again, I have to advertise this wishreport:
http://bugs.kde.org/show_bug.cgi?id=150883
- unfortunately, I am struggling with getting KDE compiled from svn so I did not have a chance to try Robert's menu implementation yet :-/
Thanks, I added my votes.
Whats wrong with the application browser? a tree based menu is extremely annoying when using a touchpad: if you move it too far in the vertical direction, it switches to another part of the tree. I've been using the kubuntu port of open suse's kickoff (kde 3) and I like it; the only problems I have with it is that its difficult to select a search option without moving across the tab bar (which of course navigates away from the search results); and that the search is very slow. Otherwise it is a very nice product...
as for raptor, I'm not sure where it's trying to go. Lancelot, however, looks very very nice, so I'm keeping an eye on him.
About the touchpad thingy, the more accurate solution is to use your arrow keys and you won't have problems anymore with the mouse pointer going too far :).
I see your point, it is valid. Still, I think this only describes the problem of switching to another, unwanted part of the tree when your aim is off. However, it does not invalidate the approach itself - it only describes a problem when an aim is off. I think, if possible, it would be nice if the new kde application tree menu could offer the 'old' navigation mode as well. I find in this case the either or approach a bit too harsh, seeing also as how the 'old', or current approach is more then a decade old and works just fine for some people (while dealing with the moments the aim is off). Again, perhaps an either or approach is a bit too harsh.
At the same time I am aware how young these menu's are and am aware that over time what I find works much faster, to become dated - but it would have to earn that, prestige ;)
One improvement I think useful is to allow user to configure the order of tab. For instance, I'd like to put 'all aplications' as the first tab since I've almost never use favourites (and I even disable this feature in the classic KMenu).
Nice sentence: I never use my favorites (==most used applications) :-)
(but I know what you mean)
Here is my use case for Digikam:
1. Set up repositories on my laptop and on an external drive/network drive.
2. As the laptop drive fills up, I move pictures from the laptop repository to the external repository, not necessarily from inside Digikam.
3. Digikam does not delete the database information about the moved files, but notices that they are missing. Optionally it shows them as "ghosts" in the interface.
4. When I plug in the drive/connect to the network, Digikam finds the moved pictures and associates them with the already present database information.
5. Since Digikam could not know in step 3. whether the pictures were moved or deleted, there is a function that allows me to confirm expunging of pictures that were truly removed, to get rid of the ghosts.
I suppose this use is not supported yet, but with the new feature we got a lot closer!
(Identifying moved picture can be reliably done with checksums, but would primarily be done by looking at file sizes/names/dates and/or by a hidden file in each directory. I'm sure there is some synergy with Strigi and Nepomuk here?)
As far as I understand with those new features this scenario is working with exception of point 2. Such migrations should be done from managing program.
I strongly disagree. Just because I sometimes use Digikam I should be chained to using only that program for my file management, or things break. There are several good reasons to want to be able to use e.g. Dolphin or the command line to move things around.
The first commandment only applies to Emacs after all. Not to other software. http://www.emacswiki.org/cgi-bin/wiki/faith.el
Amarok has always worked that if you move a file off and then back the statistics are kept. It's easy to do, you just don't bother cleaning the statistics table. :) Of course you don't want to show stuff that isn't there, and Amarok doesn't.
Now we have more sophisticated stuff, it takes a hash of the first 4k of the file + the metadata. It works pretty well.
A similar feature that would be neat (and unfortunately quite complex i fear):
support for creating albums on cds and dvds and then if that files are deleted from the hard disk, digikam keeps the info and the thumbnails in the db and the album is still available from the main view.
when the user tries to open a photo from that album a message appears with something like "please insert the disc labaled foo"
This is already in the bug tracker as a feature request. Go vote for it! :)
Nice things to read. Nice work.
I don't know what I would miss more if they didn't exist :
the "much-wanted feature of multiple album root paths in Digikam"(yay, finaly, that's great) or
the commit digest every week
I use Digikam too... but, what does that actually mean, 'multiple root paths' ??
Can't live without commit-digest...
That's the reason I secretly hope that KDE will be delayed for more than a year. Than I could read 50 more digests for sure...
Have no fear, I think we can safely say that commit digests containing drool-inducing feature commits will continue after the 4.0 release :)
Has Ligature definitely been abandoned now? Could someone tell the story of what happened to it? Is our good friend Wilfried Huss, who kept us up to date in the past, still lurking on the Dot?
(FYI: Ligature is/was the renamed KViewShell, an app that on the surface of it looks/looked almost identical to Okular, but has/had different internals. I don't know exactly what was unreconcilably different, since also the low-level libraries, such as Poppler for PDF, were shared, but supposedly Ligature is/was more tailored for DVI files. Its developers also claimed it to be faster.)
I'm not going to make any suggestions here.
Reading between the flames on the KDE-dev mailing list, I find that large changes are planed for Konqueror which I am not sure if users will like.
So, a simple question, where is the proper place for users to post their suggestions on how to improve Konqueror?
Link(s) to discussion in the list archive? Thanks.
I believe there is a kfm-devel mailing list.
Not really intended for user input. We shouldn't clog up a development list with a lot of user traffic.
Should there be a non 'devel' kfm (or Konqueror) list if a list is the place for this?
I specifically ask because there is a lot of discussion about Konqueror 3.x.y in BugZilla that really belongs in a suggestion box forum. Bugs are intended to be about what is wrong, not long discussions about how to change something.
It seems that the Amarok playlist is getting bigger and bigger (as it should) -- now it's about a third of the window. Now let's move in to the middle!
What's the point of having an empty blue screen in the middle, if this scrunches up the majority of the titles in the playlist and forces them to be hidden behind an ellipses symbol (...)? Let the user see what song is actually playing, and give the playlist the focus that it deserves ;)
Overall, I like the fact that the various widgets are more compact, resulting in less wasted screen real-estate. I hope this trend continues.
I think you are right. But let's give the devs some time to come up with really cool context widgets, to make good use of that empty blue space. If they fail to produce something that motivates its central position, it can always be moved back to the side later!
The center is a big blue Amarok logo obviously because the dev's need some way to promote their product.
No, that big blue space is integrated with plasma, so the dev's can add cool plasmoids in there. Honestly I am not convinced that it will be as good as it sounds, because i haven't seen any use of this feature yet, but it has potential.
More on-topic, great digest Danny! I expect it every week =]
Since Amarok is the only non-plasma user of libplasma, sometimes (often) libplasma breaks things for Amarok. It will all be sorted out in the end. But there are in fact several plamoids already developed, they just aren't always working.
the only non-plasma user of libplasma outside of kdebase/workspace =)
I think only the letters in "Interstate Medicine" should be highlighted grey in Amarok's treeview, and not the space to the left (see attached screenshot). It's not supposed to highlight the vertical line representing the parent folder. This highlighting behavior in treeviews seems to be a problem throughout KDE 4, since Dolphin also extends the highlighting to the left.
Also, is there any way to eliminate the space between a scrollbar and the window it controls? (see red arrow on attached screenshot).
Yes I agree with you about highlighting.
It's too early to worry about pixels here and there, probably just some widget margins.
Good observations.
> KGhostView finally removed in favour of okular
I use KPDF to read PDF files and I have no doubt that okular will be a great app but currently I need to use KGhostView in order to print print-protected PDF documents. Will okular allow me printing of print-protected PDF documents?