SEP
17
2003

KDE 3.1.4 Released!

The KDE Project announced
KDE 3.1.4 today. It's the fourth maintenance release of the successful KDE 3.1.x series and
ships with many bugfixes and improved translations. KDE 3.1.4 also contains two fixes for security issues in KDM. Users of KDE 3.x are advised to upgrade to KDE 3.1.4. Read the incomplete change log or jump directly to the
download links on the KDE 3.1.4 Info Page. The Konstruct build toolset was updated accordingly.

Comments

I hope it makes it into the releases for Mandrake RH, SuSE etc. It sounds like a lot of annoyances have been fixed making 3.1.4 top knotch.


By mario at Tue, 2003/09/16 - 5:00am

there are not much important changes since 3.1.3 instead of the security issues related to KDM and maybe the "Konqueror: Don't crash when opening a directory in tab from the navigation panel" bug..
or are there any new features like font-shadow on desktop in Release 3.1.3 ?
:)


By Mumumba at Wed, 2003/09/17 - 5:00am

Well, the crashing fix and cpu waste of knewsticker was what pisse dme off most about 3.1.3.

Anyway, Im sure that these are just a few improvements in 3.1.4, probably a lota re not mentioned.


By mario at Wed, 2003/09/17 - 5:00am

You should study the changelog again now (and perhaps in some days again). And of course there are no new features because the KDE 3.1.x branch is feature-frozen.


By Anonymous at Wed, 2003/09/17 - 5:00am

Whoa, I thought it was a 3.2 feature!

I'm using 3.1.3 right now, where can I activate the shadows? There's nothing in my 'Desktop configuration' dialog about it :?


By Saiyine at Wed, 2003/09/17 - 5:00am

which packages are you using ?
i am running SuSE8.2 but the kde-packages from ftp.suse.com (or mirros) doesn't contain the font-shadow patch. instead they included the window-shadow patch, but when i tried the packages, i didn't find the shadows or the configuration anywhere.. so i reinstalled the 3.1.3 packages from ftp.kde.org (well, from a mirror ;)
(i read about the fact that SuSE removed the font-shadow patch from the kdebase3-3.1.3 package in the package-info, but i think, the font-shadow is more usable than window-shadow;)

but now, i am looking for the SuSE packages of 3.1.4 !
it seems they are still not uploaded/finished on the ftp.kde.org Server..

also i found, there are much more bugfixes in 3.1.4 release.. when i first looked at the changelog, there where only some notes added.

Great, now, where are the SuSE packages? ;)
thx


By Mumumba at Wed, 2003/09/17 - 5:00am

I think that I will wait for the 3.2 release instead!

/Dave


By rogue at Wed, 2003/09/17 - 5:00am

I thought it was a joke but it looks like they really did remove "View Document Source" from the Konqueror context menu in 3.2 unfortunately.


By ac at Wed, 2003/09/17 - 5:00am

In case I give the wrong idea, other than that, I think KDE 3.2 is looking superb. Konqueror, KControl, etc have made some real advances!


By ac at Wed, 2003/09/17 - 5:00am

Honestly it doesn't make much sense. The "context" for the document is the application menu. That's why it was moved there. The context menu now has "Show Frame Source".


By George Staikos at Wed, 2003/09/17 - 5:00am

Wait, so View Document Source was completley remove dor not? I thought it was very useful, I would rather have this stuff removoed: http://bugs.kde.org/show_bug.cgi?id=53772 and making the context menus context sensitive, (read Alex's post in the above link)


By mario at Wed, 2003/09/17 - 5:00am

Actually, that seems like a better idea overall. What do people think of this suggestion? Would anyone really detest it if someone went and implemented it?


By Rayiner Hashem at Wed, 2003/09/17 - 5:00am

Nope. Go and implement it :)


By Dawnrider at Wed, 2003/09/17 - 5:00am

There is no "Show Frame Source" when there is a single frame. It doesn't make sensce to have "Show Frame Source" sometimes and not other times. It's quite inconvenient in fact...


By ac at Wed, 2003/09/17 - 5:00am

Agreed. There should be "Show Frame Source" no amtter how many frames are open it should just show the source of the current frame, if it's only one than so be it.

I do agree taht "Show Frame Source" is a technically more correct name, However I think "View Frame Source" is more consistent with other applications on all platforms.


By Alex at Thu, 2003/09/18 - 5:00am

Agreed. The growing consensus from what I can gather on the usability list is that the context menu should be properly context sensitive, and only display items which are very inconvenient just being in the main menubar, or cannot be used there at all (like frame sensitive options).


By Tom at Wed, 2003/09/17 - 5:00am

Awesome. The latest 3.2 menu down to about 14 entries. The next things I want to see go:

Duplicate in New Window/Duplicate in New Tab --- There should only be one, following the same behavior the user chooses for opening links in new windows.

Copy Text --- The menu should be context-sensitive to what's underneath. There should be a text menu similar to what you get when you right-click in a text-box, and that should have cut/copy/paste. The "Copy To" item already takes care of copying the page itself.

Encrypt File --- I liked the "actions" menu that was in here originally. How often do you want to encrypt Slashdot?

Stop animations --- Again, how is this context sensitive? It should be a toolbar button.

Security --- This one doesn't even make much sense. It just tells you whether this page if secure, and gives you a shortcut to the SSL settings. The "page is secure" indicator should be a status bar item.

This is probably the low hanging fruit, and gets Konqueror down to 10 entries. That's not bad. If you really want to hit that magic 7 and under number, you could go after a few of the more controversial entries, like set encoding.


By Rayiner Hashem at Wed, 2003/09/17 - 5:00am

Security has to be in the menu because it is context sensitive. It shows you the security for the inner-most frame at that point.

Encrypt file is a plugin, not part of konqueror.


By George Staikos at Wed, 2003/09/17 - 5:00am

It should be reworked as a menu item that shows a dialog telling you about security for each frame on the page, and then removed from the context menu. Same with "view document source".


By Spy Hunter at Wed, 2003/09/17 - 5:00am

Still, I think secuirity and many context menu tiems do not belong there, they are not foten used and should be in the main menus.

Also, please don't remove the open in new window option or open in new tab or duplciate tab or duplicate window options, these are useful in many isntances and tehre is a reason tehre are two. If tabs were as versatile as Windows I would have no problemw ith this, but they are not and widnwos have much ebtter drag and drop support etc.

I'm all for removing features that do not fit into the context of the suer's actions or just plain aren't used by anybody, but I don't think this is one of them.


By mario at Wed, 2003/09/17 - 5:00am

You know that you can 'detach' a tab to its own window?


By luciano at Wed, 2003/09/17 - 5:00am

And how do you intend to find out the security for the point where you're clicking on the page? This is all too complicated. The security is context sensitive and belongs in the context menu, plain and simple. Originally it wasn't in the context menu, but this was wrong.


By George Staikos at Wed, 2003/09/17 - 5:00am

People, enough discussions about context menu in Conqueror!
If you want to learn from someone how much they should be - learn from Apple!
There are only two items in the context menu in Safari they are:
-View Source
-Save Page As...
If you open context menu on a link they are more:
- new win
- new tab
- download
- copy link
- add bookmark
If you click somewhere else it's different but it's always exactly depending on place you click. Notice the meaning of the word "context" menu!!!
The look of Safari is really very clean and extremely useful at the same time. Also it's far more stable than Conqueror. I will be happy if Apple or someone else ports Safari to Linux or Windows, of course you can merge their great improvements if you wish.

And spellcheck the name of the app, it will be one of the greatest improvements to Konqueror.

Thanks for your efforts, and your great service!
Without your efforts Safari (the best browser for the best OS) would not be possible these days!
Many thanks also to Andras Mantia of Quanta, once he and his team implements the WYSIWYG mode for KHTML, Apple will be able to burn a fresh new HTML editor.

Anton


By Anton Velev at Wed, 2003/09/17 - 5:00am

Man put the crackpipe down...

It's easy to be the best when you're not exactly writing anything. I openly acknowledge Apple's improvements on KHTML that everyone has been ranting on and on about, but it's much easier to come up with short term hacks. Don't forget that Apple writes code ONLY for it's OS - designed ONLY to run on it's own hardware. They don't have a fourth of the responsibility KDE has.

The orginal code base is the hardest part to come up with, but of course a MacOS user wouldn't know, seeing how Apple didn't write the codebase for any of it's top products. The GUI is NeXTStep with a shiny new theme and icons, the kernel is the Mach from NeXT, the core of the OS is FreeBSD, and the browser is based on KHTML. Maybe you meant the best assembly of misc programming projects ?


By Chris Spencer at Fri, 2003/09/19 - 5:00am

Friend,

Read some news.
Apple has a great framework and platform, have you ever heard of Quartz, Chrome and Cocoa? What about the QT technology? And a number of state of art applications like iTunes, AppleWorks, Mail, iCal, iChat, etc etc.
I agree that Apple uses the truly free open source projects for implementing closed source solutions but there is nothing wrong about it. And that's why I am saying thanks to kde people for KHTML and of course would thank FreeBSD people for their great UNIX.

Btw are really doing a good things be in terms of open source freedom because they support only truly free sources, more than that they are freeing them from GPL - look what they did to KHTML it is now not dependent on the Troll GPL library that KDE is relying on.

Thanks Again.


By Anton Velev at Fri, 2003/09/19 - 5:00am

> KHTML it is now not dependent on the Troll GPL library that KDE is relying on.

KHTML has always had little Qt depedencies. You need someone expert in porting to port it to other platforms though (yes, Apple's team was expert)


By anon at Fri, 2003/09/19 - 5:00am

> Awesome. The latest 3.2 menu down to about 14 entries.

14 - did you say f o u r t e e n !?! I expect a usable context memu to have 6 to 8 entries, maybe 10, if it is relly necessary.


By Carlo at Wed, 2003/09/17 - 5:00am

Read the rest of the post :) It is a CVS version, after all, and 3.2 won't be out until December at the earliest. Heck, its almost getting usable now :)


By Rayiner Hashem at Wed, 2003/09/17 - 5:00am

well, opera has 16. Nobody complains.

I think the notion 'bloated' also caused by the horizontal and
vertical spacing.

By horizontal spacing, I mean the space between phrase (e.g "back")
and shortcut ("alt-back"). Whereas for vertical spacing, I mean the
line spacing between line could be reduce.

Just compare with Opera, 16 entries, but the context menu looks small/
compact.


By anon at Wed, 2003/09/17 - 5:00am

It's not a matter of size. Its a matter of numbers. Anything more than 7 or 8 is too many for people to remember. Once you get too many for people to recall at once, you suffer a giant slowdown because people now actually have to *read* the menu to use it. There is a reason why phone numbers are only 7-10 digits long in most countries, as are license plates. Nobody complains about Opera because not that many people use Opera where on dot.kde.org :)


By Rayiner Hashem at Wed, 2003/09/17 - 5:00am

Mmm. There was a titanic flame fest when the Mozilla folks took the "back" menu item out of a lot of the Mozilla context menus.. seems that was one that a lot of people really did expect to be everywhere so that they could always right click and flick to go back.

Instead, the powers that be at Mozilla.org were very concerned about the menu length, even though for those users used to using the context back, the context back was used 99 times for every time any other context menu item was chosen.

I'd say that unless you're talking about the very top one or two items, the length of the menu isn't really that critical, as you'll still need to read the menu to see if you've moved down far enough for what you're looking for.

Far better to have slightly longer menus than to right click to go back and find you've accidentally right-clicked on a transparent gif file and your trusty back reflex has turned into a useless 'View this image' item.


By Jonathan Abbey at Wed, 2003/09/17 - 5:00am

I'd say that unless you're talking about the very top one or two items, the length of the menu isn't really that critical, as you'll still need to read the menu to see if you've moved down far enough for what you're looking for.
>>>>>>>>>>>>>>
That's the whole point. You can keep the whole menu in your head if it is only 7-8 items long. If it goes bigger than that, you can't really keep any of it in your head without a lot of practice.


By Rayiner Hashem at Wed, 2003/09/17 - 5:00am

That is utter nonsense. The context menu is to have local access to commonly used commands, or to have access to local object specific commands.

Indeed there may be some menu items that don't apply. And context specific ones can be improved. But to cut out menu items that are commonly used for good reason to meet some imaginary number goal is nonsense. It is an attempt to change user habits into what you think is the right way.

I have two machines, one a laptop with some useless touchpad, and hard to see mouse cursor. I don't want to move the mouse any more than I need to. Usability suffers greatly if I have to scratch all over the screen to do things that are very very common in browsing. If fact that is one thing I dislike about the Mac. You are forced to mouse all over the place to do anything. I think it is a major design flaw in the whole system.

Derek


By Derek Kite at Wed, 2003/09/17 - 5:00am

Agreed. I'd really like to see View Source back too.


By Navindra Umanee at Wed, 2003/09/17 - 5:00am

It's a context menu, not a common menu. "View Source" is unlikly very very common in browsing. Either use accels, define a shortcut or change your local khtml_popupmenu.rc copy.


By Anonymous at Wed, 2003/09/17 - 5:00am

Don't put View Source in context menu it does not belong there and isn't context sensitive is it?


By Alex at Thu, 2003/09/18 - 5:00am

It is VERY context sensitive when browsing frames. In that regard, it's one of the most context sensitive items in that menu.


By Metrol at Thu, 2003/09/18 - 5:00am

Take up the argument with the psychological community. They say human beings are good at remembering sets of only about 7 entries. As a layperson in the field, I'm inclined to believe them. Go beyond that limited, its much more difficult to remember any of the items in the set (ordering gets confused). Its not an "imaginary" number, but a hard-limit of how our brains are wired. It should be a familier concept to anyone who wroks in computer science. Make sure your data-set fits in cache, or the performance of your algorithm plummets.

PS> Context menus are about easiest access to the *most common* actions on an object, not all possible actions on an object. Context menus can greatly increase efficiency when designed properly. When you go over 7 menu items, you make them nearly useless for what they're really good at, and only save some mousing, which could be reduced anyway by proper use of keyboard shortcuts.


By Rayiner Hashem at Wed, 2003/09/17 - 5:00am

Yes Rayiner, that's what I had in mind, too. On the other hand, Derek's point isn't that wrong; The problem is, that everyone has his own habits and opinion what should be in a context menu and what not. I for one vote for extending the file types with a context menu for each of them, with restricted default "values" and editable system wide and user local entries.


By Carlo at Wed, 2003/09/17 - 5:00am

Well, usability generally is like that, therefore, you want to target the largest amount of your users and make something that's good for them.


By anon at Thu, 2003/09/18 - 5:00am

A stop-gap measure to a more "OO" way of handling context menus might be to make them a configurable (but auto-managed) thing like toolbars. Toolbars in KDE are pretty well abstracted (ie. they provide for configuration without causing a lot of extra checks in the code) and KDE would be unusable to me if they weren't configurable. Maybe something similar for context menus would appease those who have special preferences.


By Rayiner Hashem at Thu, 2003/09/18 - 5:00am

Eh, what's with this mantra of "more than seven items - BAD"?

My keyboard has more than seven key! BAD. It must be badly designed.

The alphabet has more than seven letters in it. BAD! Can't you see this should be cut? The designer of the alphabet should be eviscerated!

Point is, it doesn't matter about your magical seven number. What matters is that the context menu provides the most commonly used commands that users require in any given context. Yes, we don't want hundreds of options in there, but neither is having a dozen or more so awful - least not when the mental peons are catered for by putting the absolutely most commonly clicked at the very top of the menu - back, forward, all that. They don't even need to look down the menu, but it is there for the rest of us. Konqueror is hardly any different to most other popular browsers in terms of the size of its context menu, so I think established opinion is on the side of that application's designers, and the usability freaks (the ones that want to shoehorn everybody into a horrid spartan vision that lacks all utility and requires 10x the legwork to get things done), well, they always have Apple with its (imo) limited GUI (and Gnome by the looks of it, when its ready, any time real soon now).

Ugh! You just can't pluck some half-arsed psychological factoid out of the air and apply it willy-nilly as though its the One Rule to guide all UI design. I thought this silly attitude died with the early Apple-fanatics.


By Hollywood finochio at Thu, 2003/09/18 - 5:00am

> Gnome by the looks of it, when its ready

Actually, Nautilus 2.4 has more context menu entries by default than Konqueror does. However, it has more sane entries. Why do we need crap like "Add to bookmarks" in the file manager? Why I click on a link, I want options for that link, not "Back" and "Forward" and "Set Encoding" (those are fine if I click on blank space I guess)

Note that Konqueror is more sane than other browsers.. I'm typing this from IE 5.2 for MacOSX which includes things like "Track page with Auctions Manager" and "Set home page" in it's popup menu. People set their home page in what??? once per year?


By anon at Thu, 2003/09/18 - 5:00am

Eh, what's with this mantra of "more than seven items - BAD"?
>>>>>>>>>>>>>
If you want context menus to be a real time saver, you'll make it easy for people to quickly remember the exact entries in the list. If you have more than about seven items (depends on the person) most people can't remember all the items, and they have to linearly search the menu looking for the item they want.

My keyboard has more than seven key! BAD. It must be badly designed.
>>>>>>>>>>>>
How long did it take you to learn to touch type? How'd you like to do that for each app you use? Remember how slow a typist you were before you memorized the layout of the keyboard? That's what giant lists of actions are doing to the usability of your context menus. Given enough time and patience, people can memorize anything. People learn 2000 Kanji characters just fine, after all. But the human brain has a special ability to quickly learn and recall sets of 7-8 items. That's why you can remember all your friends phone numbers without even trying to learn them. There is no point wasting this ability.

least not when the mental peons are catered for by putting the absolutely most commonly clicked at the very top of the menu - back, forward, all that. They don't even need to look down the menu, but it is there for the rest of us.
>>>>>>>>>>>>>
This has nothing to do with "mental peons." I'm not bitching about this in the name of "let's make things easier for newbies!" I'm bitching about this because the lack of real context menus kills efficiency. Also, you seem to have no understanding what a context menu is about. Why are back/forward/etc at the top, when they are right on the menu bar? Besides the all-inclusive main menu, there are three access methods:
toolbars
context menus
hotkeys
These are all different things optimized for different uses and used for different purposes! They are not interchangable.

Konqueror is hardly any different to most other popular browsers in terms of the size of its context menu, so I think established opinion is on the side of that application's designers
>>>>>>>>>>>
If by popular browsers you mean Internet Explorer, then yeah, Konqueror is no different. However, Microsoft is known widely for their horrid UIs! If you include other major browsers, you're just plain wrong. Mozilla's page context menu has 10 entries, and its link context menu has 9 entries. Its pushing it a little, but its usable. Most of the Mac browsers (again, aside from IE) have about half a dozen items in their menus. So the established opinion is most definately *not* on the side of large context menus, unless you want to do the judging by sheer numbers, in which case we might as well just make a WinXP clone...

Ugh! You just can't pluck some half-arsed psychological factoid out of the air and apply it willy-nilly as though its the One Rule to guide all UI design. I thought this silly attitude died with the early Apple-fanatics.
>>>>>>>>>>>>>>
Its not a "half-arsed psychological factoid." Its a generally well-understood principle of UI design. UI design, in all its forms, is a science. There are researchers who study not only computer UI design, but all human-machine interfaces, such as in industrial design, etc. This is what they have come up with. Also, the guideline about keeping context menus as short as possible is in the Gnome, Apple and Microsoft HIGs. You're free to disagree with it, but please provide some evidence that would make us believe that *all these other people are wrong*.


By Rayiner Hashem at Thu, 2003/09/18 - 5:00am

The point is this... Learning the complete layout of a context menu is daft. If you really feel masochistic enough to do it, then you won't mind if there are 8 or 12 entries, or whatever.

Moreover, if you have fully context-specific menus that change for links, files, pages, images, embedded objects, etc. Then that entirely breaks your learnt layout.

Users are perfectly capable of reading the words in a context menu, moreover, context menus are there for power users, not the people who can barely open a browser and who can't master a double-click. Power users can read.

Sure, reducing the menu does make reading is slightly faster, but users who use the menu enough to remember the entries are also capable of skimming-reading the menus fairly quickly. Typically the time for the eye to find the menu is more than the time to read. Moreover, Konqy does well through using separators to segment the different types of item and adding icons for common tasks. 12 items in Konqy is worth 8 anywhere else for those reasons.

Actually, when it comes to the human brain, the brain prefers smaller sets than 7 or 8. Ideally, groups of 3 or 4, and then about 3 or 4 groups. Higher numbers are gained easily through associativity, such as the icons in the context menus.

I think you need to appreciate, when you talk about productivity, that context menus are a minute issue in comparison. You say that Microsoft produce terrible UIs. Sometimes they do, but often they don't, at least not at the application level. their problem is that they make it hard to navigate between applications, control panels, etc. and make it a pain to find things. Microsoft, ultimately have produced basic software that fulfills a set of needs. It allows people to operate fast enough. No-one cares if it takes you 0.5s to read a context menu instead of automatically clicking the 5th entry for whatever you want. That time is dwarfed by reading the document, examining the images, getting interrupted by phone calls, going for a cup of tea, making a note on a piece of paper, creating a new file to store some text to copy and paste, and many other things.

To be honest, OSX has short context menus, and they are absolutely useless for the power users they are meant to be addressing. How does it help me as a user of Safari if when I right click I get three options and the ones I wanted are elsewhere? Gnome is doing the same thing, and it is stupid. I want the context menu to hold the entries that I need for a task, and if it doesn't, then the entire idea of saving me the effort of going all the way up to the menus and digging out the correct entry is rendered a lie. Moreover, if entries aren't in the context menu, and you expect them to be there and go looking for them, then you also achieve a penalty, because after an exhaustive search, you have to go and look in the main menus afterwards. On balance, it is better to have all of the options *people reasonably expect* rather than a trimmed down menu.

What are those options? They are the ones that are already there and people find useful, and an averaged set of ones from other browsers, most especially IE. We have to remember that the people coming to using the context menus are not brand new users who've never touched a mouse before. They are people who will almost always have experience of other browsers. Changing the menus to exclude things they need will cause them massive disruption.

It's not a case of duplicating IE or windows XP, but it is a case of having a sane range of options and at least enough nods to WinXP that people migrating feel fairly at home.

And for what it is worth, HIGs can be useful and they can be worthless. It depends on the audience and what the application/DE/OS wants to achieve. The ultimate trouble with usability studies, is that it only tests given users (who are at a given state, based on social factors and past exposure) with existing methods and applications. You then use this to try and inform future development, but by the very nature, sticking to the results of a usability study religiously prevents you from doing things in imaginative ways. The same is true of HCI books. It is trying to deduce trends in a snapshot of computing life, where the new moment has rendered portions of the work obselete. It is hard to truly derive long-term trends.

At the moment, I personally would ask that developers spend very little time on the context menus, and instead make sure that for example KWord never crashes and loses people's work (not having a dig, btw... it's purely hypothetical), that IMAP support in KMail works properly, so that users don't have to rely on POP and drive to the office at night when they realise they forgot to turn off their mail client, which is grabbing all their e-mail that they need for tomorrow's report. There are a hundred things which are better to spend time on than Konqy's silly context menus.


By Dawnrider at Thu, 2003/09/18 - 5:00am

The point is this... Learning the complete layout of a context menu is daft. If you really feel masochistic enough to do it, then you won't mind if there are 8 or 12 entries, or whatever.
>>>>>>>>>>
You don't really seem to understand here. The whole idea is that yes, memorizing the items in the context menu *is* daft. But if there are only 6-7 items, you don't *have* to memorize it. Your brain just picks it up in the process of using it. There are all sorts of effects at work here, not just number, but location. When you have just a handful of items, its easy for your muscle memory to tie the important ones to the beginning or end of the menu. When you have 14-15, most are just in the middle, and your muscle memory fails.

Moreover, if you have fully context-specific menus that change for links, files, pages, images, embedded objects, etc. Then that entirely breaks your learnt layout.
>>>>>>>>>>>>
No it doesn't. Human beings are incredibly adept at doing things like this. From what I understand, the number of sets learned is not very important, but the size of each set is. Its much easier to remember, for example, 10 sets of 3 items then to remember 3 sets of 10 items.

Users are perfectly capable of reading the words in a context menu, moreover, context menus are there for power users, not the people who can barely open a browser and who can't master a double-click. Power users can read.
>>>>>>>>>>>>>
Yes, context menus are there for power users. Power users like efficiency. Scanning a linear list of words is a very slow process for humans. Flicking your wrist in a learned reaction is much faster.

Typically the time for the eye to find the menu is more than the time to read.
>>>>>>>>>>>>>>
With small menus, your eye doesn't need to find it. That's the whole point of making them short! Your fingers do all the work.

I think you need to appreciate, when you talk about productivity, that context menus are a minute issue in comparison.
>>>>>>>>>>>>>>>>
It depends on how you use the UI. I'm a twitchy user, I do most things through keyboard shortcuts and context menus. For me, bad context menus are a big productivity loss. But overall, yes, its a relatively minor (though not minute) issue. But if we're going to bother to do context menus, let's do them right.

Microsoft, ultimately have produced basic software that fulfills a set of needs. It allows people to operate fast enough.
>>>>>>>>>>>>>
I didn't realize we were going for just "good enough." Well shucks, then, why don't we all strick with Win 3.1? I mean, that's good enough for the e-mail/word-processing/etc that most people do!

No-one cares if it takes you 0.5s to read a context menu instead of automatically clicking the 5th entry for whatever you want.
>>>>>>>>>>>>
0.5 seconds is an eternity.

That time is dwarfed by reading the document, examining the images, getting interrupted by phone calls, going for a cup of tea, making a note on a piece of paper, creating a new file to store some text to copy and paste, and many other things.
>>>>>>>>>>>>>
Your net time lost is probably more than you think. The effort you're spending reading those context menus disrupts your thought process. This is why, for example, I prefer to use Vi for coding rather than a GUI editor. Since I know all the commands and shortcuts and whatnot, I never have to stop thinking about the code. Also, even if the net time saved isn't that much, its these little inefficiencies that make the computing process much less enjoyable.


By Rayiner Hashem at Thu, 2003/09/18 - 5:00am

That stuff about seven items lacks a qualifier.

People has trouble remembering sets of over seven ARBITRARY items.

Like "apple, dodge, bird, zuul, 4, mother, mars".

It is absolutely trivial to remember larger sets if they are related. In fact, you don't have to remember the menu options at all.

You want to do something to a thing in a page, then right click and it's there. What's there to remember?


By Roberto Alsina at Thu, 2003/09/18 - 5:00am

Right now I'm working on a patch to implement #53772 -- making sure Konqueror's context menus are CONTEXT sensitive. Should have it ready soon. Should whack 4 or 5 enteries from links/images in html pages, and a few from icons in file manager modes.

http://bugs.kde.org/show_bug.cgi?id=53772


By anon at Wed, 2003/09/17 - 5:00am

That sounds great, i always thought that context menus should be CONTEXT sensitive and not just the most commonly used items. I am defintely looking forward tos eeing your patch in 3.2 ;)


By Alex at Thu, 2003/09/18 - 5:00am

> There is a reason why phone numbers are only 7-10 digits long in most countries

Not every ant has telephone?


By Anonymous at Wed, 2003/09/17 - 5:00am

Pages