From kde-usability Tue Aug 12 00:22:01 2003 From: Henrique Pinto Date: Tue, 12 Aug 2003 00:22:01 +0000 To: kde-usability Subject: Re: RMB - once again X-MARC-Message: https://marc.info/?l=kde-usability&m=106064838809147 Hi, On Sunday 10 August 2003 10:55, Sander Devrieze wrote: > ...but also possible to dissable. (Don't ask this again e.g.) Huh? > And much people are too lazy to spend time to change the default > application manually...like me :D But some are not. And these people wouldn't want to be bothered by popups. Of course those popups shold offer a "Don't show this dialog box again" option, but that rises an issue. They have two options ( "Change" and "Not change", of course worded in another way). What should be the default if the user chooses not to see the dialog again? > > Such a dialog should be simple. > > What about puting this functionallity in the menu editor? > > I Agree. Ok. Anyone disagrees? If not, I'll fill a wishlist item for KMenuEdit in b.k.o. > > > The items in this list of applications could be draggeable in order > > > that people may set their own preferred order. > > > > Agreed. And so should be the whole menu, not only this part. > > Not agreed: this functionality should be done by another dialog like now > already possible with the K-menu (of course there are usability problems > with this editor that needs to be solved). > > Why? > o People don't use this functionality much. Do you have data to backup this statement? > o People will not know that this functionality exists. Most people don't know it is possible to resize a window by holding the ALT key and pressing the right mouse button. Should this functionallity be removed only because of this? > o People will get disappointed if they click wrong and so change their menu > without knowing why it changed. (They will feel they have no control and > this will results in fear when using KDE.) Of course that should be done in a way that prevents this type of accident. There should be a sensible delay before it gets activated. > o Doing it in another application makes it possible to add advanced > functionallity in a simple and usable way. (e.g.: we can add the > possibillity to change the actions in the Actions >> submenu.) And why implementing this functionality would stop you from doing this? Or do you think one wouldn't need KMenuEdit anymore as soon as this gets implemented. > o It will be easier to disable this functionallity with kiosk without > having users complaining that their is a bug in their menus (they can't > edit it). I'm not sure I understood this statement fully. Preventing my users from accessing /, having shell access and other things is actually a feature for me, not a bug. And my users don't think KDE is buggy just because they can't browse /etc. Why would this be different? And users getting confused by KIOSK restrictions is a problem that should be dealt by the sysadmin, not KDE. Is he the one who chooses what restrictions to apply or not. BTW, someone pointed out in aseigo's blog that threads on kde-usability should be summarized in http://usability.kde.org/activity/recent/. This thread is a great candidate for this because: 1) It is getting rather big; 2) It deals with many things that were already discussed previously; 3) Many things were already agreed upon; 4) Many other things are too subjective for us to agree on them; 5) Because of its size, it is unlikely that many people will keep reading the whole thread to look for already agreed upon things and implement them. What is the policy for submiting this kind of summary to the site? -- Henrique Pinto stampede@coltec.ufmg.br _______________________________________________ kde-usability mailing list kde-usability@mail.kde.org http://mail.kde.org/mailman/listinfo/kde-usability