[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: kmenu concept
From:       "Aaron J. Seigo" <aseigo () olympusproject ! org>
Date:       2002-06-07 22:21:08
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On June 7, 2002 03:12 pm, Eric Ellsworth wrote:
> I was thinking something along these lines, too.  Bear in mind that for any
> managed computer, there are sysadmin-controlled menu items and
> user-controlled menu items, and as someone who sometimes sysadmins, I think
> it's important that the sysadmin be able to control at least some menu
> items.

yes, there will be an "immutable" flag that sysadmin will be able to use to 
make changes not allowed ... we will be able to do this per task group even 
...

> > much like the special menus are shown/hidden.
>
> Can we default these off?  I know lots of people like them, but I think
> they're overkill for a novice.  Let's also:
> 	Rename "Special Menus" - why are they special, what do they do.  Or put
> another way, what kind of task group are they?

they are dynamic menus that can be added / removed ... they are a holdover 
from the old kmenu, and include things like the print manager and windowlist 
menus... w/out them this becomes useless for anyone but a simple user, and 
i'd like to use this menu style when it's done too ;-)

of course, if all the special menus are turned off then this section won't 
appear at all...

> 	Turn off Run Command (put in with the Special Menus, with Kicker KCM
> control) by default

ack...

> 	Turn off Lock Screen - I claim (based only on my opinion) that Lock Screen
> is a more advanced command than

and, come to think of it, i never actually use it in the menu either ... 

> 	I might even look for a new home for "Find Files" for total novices.

finding files is a basic thing ... perhaps with the recent documents, though. 
i'll experiment about...

> I also noticed that when you pop the menu out into its own window, the
> titles disappear, which makes the items confusing.  How should we handle
> this?

that is a bug in kpopupmenu, methinks... i'll look into it eventually ...

> 	o Where is the hierarchy of menus read from?  In the case of a KMenu, how
> do you merge sysadmin-generated menus with user-generated menus

the applnk directory structures are merged ... in this case we'll use a 
regular rc file and just merge the system and user versions (which KConfig 
does for us, mostly)

> 	o A very powerful feature of a menu with a change-apps wizard built in is
> that users classify their applications by configuring it.  I'd really like
> to write a back end that takes advantage of this fact and makes their
> classification available to the rest of KDE.  Without revisiting the
> kde-look metadata wars, let me just point out that this is valuable
> metadata about apps....

it already exists: mime-types...

> 	o How does this task and classification scheme work within apps?

mime-types

> > /me looks over at kspread, knowing what this means =(
>
> Oh, you mean make this of general use for other menus... Now that's genius!
> =)

no, i mean that the work i wanted to do on kspread is going to get pushed 
aside =/

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

"Everything should be made as simple as possible, but not simpler" 
    - Albert Einstein
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9ATHU1rcusafx20MRAs89AJ9IdYoqyJfPyDO+wJUBEY5c28u7LQCfTg9X
QT9NwNzuUPsuj6TuHTBotHo=
=eImN
-----END PGP SIGNATURE-----

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]