Issue #45 of Kernel Cousin KDE is up. Hopefully from now on I'll be able to release a new one every Monday. Quite a lot of stuff in this one: eric, klogtool, kcmrandr, Kommander, Liquid (home) and *much* more. Please send me feedback after reading it here.
Zack, it's obvious that KC KDE has gained some new blood and has made a huge leap in quality. These improvements are really looking great. Thanks for your work (and Charles and other contributors) in bringing KC back!
Thanks a lot Navindra. I'm not going to be laying by saying that I much rather spend my free time coding than summarizing mailing list discussions, so it's very important for me to know that people actually like KC KDE.
I understand. Hey, can you make sure you get proper exposure by getting sites like LT and LWN to pick up the latest issues?
Hey, I got an even better idea, maybe you could do it =)
I submitted it to LT, but if someone would be willing to be submitting KC KDE announcements to whatever news sites they're reading that I'd make my life so much easier (read as in leave me more time to code).
Actually, Zack Brown generally does this stuff. Get in touch with him... as far as I know LT didn't post the last KC KDE.
I _love_ KC KDE. Really, it gives me a great overview of what is happening with my favourite desktop, and as a researcher, I find it interesting to follow the some main lines of the development process without having to read zillions of mails.
Hi, a few things:
- kmenu, yesterday Aaron was kind enough to let me see the new KMenu that he's working on, check it here and drool in front of your computer:http://urbanlizard.com/~aseigo/tom.png
Note that this is not a mockup, this is an actual, working implementation.
- James Blackwell, linuxguru.net editor, emailed me after reading this KC saying "Our thanks and apologies go out to the developers of the KDE Team, the Kmail team and the Kmail users for any mistakes that have been caused.". It was a really nice gesture! Thanks James.
That new menu looks cool and much more newbie friendly than the current one!
It's too cluttered.
And way too verbose. Who the heck cares about these so-called "tasks". I don't see any good reason to fill up the menu with text talking about "tasks".
Yes, "Special" "Recent", "Modify" "Remove" "Insert" is enough. "Task" is also in conflict with the Korganiser vocabulary, "Application" or "Program" is more classical. Also I hope that "Modify" (these or above tasks") allows to detach the menu as now (so it is more "Detach / Modify")
But, these are few things, the very more important is that it becomes very easy and quick to modify the menus. And later a "Move" (this task) will come....
Thank you for this great improvement !
I also see the difference between the role of the program (Browse the web, Manage email) and its name (Konqueror web browser, KMail), good thing !
I now hope that distros like Mandrake will allow a good management of both KDE menus, personnal menus and the menus of the distro.
some of those terms are found only in the context menu, which means many users will never see them. they will access them through the integrated menu editor via the "Modify.." entries.
as for the difference between the role and app, that is so people can keep their menu structure but choose different apps. i'm glad you noticed it, since that means it is relatively apparent.
so someone may choose Konqueror for their webrowser, another might choose Mozilla. both can be referred to as "Browse the web" and no one needs to know the actual name of the program or get familiar with a different menu structure.
one of my goals w/TOM is to give those who distribute KDE something a bit more userfriendly than the current KMenu that is easily extended without having to invent their own non-standard and/or broken design.
It doesn't look as cluttered as the old menu.
Yes, it's verbose. But that makes it easier for newbies to immediately understand what that part of the menu does.
No newbie will ever read that clutter! All that modification stuff should be in a separate menu editing applicaiton.
what do you base your "no newbie will ever read that clutter!" statement upon?
i'm actually striving to test this menu on people as i write it, with the hope that the final design reflects the needs and behaviours of real users. i want to be able to say "newbies do find this menu immediately usable, powerusers who want simplicity find it liberating and powerful, and everyone else can stick to the kmenu we know and love" =)
Actually, newbies WILL read that "clutter", because they don't know what else they should do.
Be careful, some newbies will read it. Some just dont read it and call their sysadmin...
Newbies never read a damn thing.
Then why do people complain about that "any application without documentation is unprofessional" if they don't read the docs anyway?
thanks for the insightful and detailed feedback. =/
anyways... what might help are the following facts:
o the font is configurable (allowing you to make the entries larger)
o the last menu you see on the right is a context menu. it only shows up if you right click on an item. in other words, its a power user feature.
o you can add remove pretty much any task you wish and many of the more static menu items as well. so you can unclutter it all you wish.
o i want TOM to be usable by those who aren't power users, and those people need extra hints. for instance, a LOT of users i interviewed had no idea what the items at the top of the kmenu were. ergo, titles to clue them in.
o this is not meant to displace the existing kmenu completely, but to be an option. those who like the kmenu will continue to have it. hoo-ray for choice!
I think it would be a good idea to increase the size of the icons (and thus the size of the menu items). With the current KMenu navigating involves too much fiddling. With larger items navigating would be much easier. To avoid problems with low-resolutions and/or many entries the menu could compute the required size and fall back to smaller icons if the menu does not fit on the screen otherwise.
enlarging the icons does not enlarge the size of items in the menu. that is based on the font size, which is why i made the font size configurable rather than the icon size.
otherwise, i agree with your statement completely.
Are you sure of that? That'd be a bug. Got any testcase handy?
this is how it is in TOM right now... perhaps it's just a keramik thing? i'll test again with larger icon sizes in other styles and let you know via email or irc what i find..
I like it very much, much more task oriented instead program oriented, so that's definitelly the right way to go. But I guess I'd change the theme to make the headers and run box a little less obtrusive...
it follows whatever theme you have installed. with litev3 it looks very plain and subdued, for example.
Bloody hell translucent menus suck. I just don't understand how people promote them. That screenshot is a prime example of how unreadable the menu text can become.
hehe... well, i don't usually run with translucent menus either. but when doing the Run widget (which consists of the icon, the label and the combobox) in the menu i needed to test that translucency worked properly when it was turned on. as you can see in the screenshot, it does (after a bit of a hack). whee... =) more interesting was getting the mouse over and tab focus on the Run widget to work "properly". anyways, i took that screenshot when i was still fiddling with the Run widget ergo the translucency.
all in all, though, i agree that translucent menus aren't the best thing around. they look cool on the movies, though. ;-)
I like it. It looks great and it is not just a copy of the XP menu like most of the suggestions on kde-look.
Thanks for your work on this!
Hey, there's some really interesting ideas in that menu layout. I'm really encouraged by the various ideas people are throwing around about the KMenu. More of it! :)
About the "run" text box: I will never ever use it, and I doubt that power users will use it.
It's a great thought, but power users will rather use Alt+F2 (which save you some mouse navigating time), and newbie users won't figure it out, or will only use the menu items I think.
Nevertheless it's great to see that there are people with innovative thoughts!
Wow, wow, I am _very_ impressed with the professional way KDE releases are handled.
The translucent panel won't make it into 3.1.
To late for the feature => not in release. That is the logical and professional
way to do - even though you know many users will appreciate it if it _is_ in 3.1.
(I don't mind that much)
In KDE we trust... :)