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

List:       kde-usability
Subject:    Re: Some TOM thoughts
From:       "Aaron J. Seigo" <aseigo () olympusproject ! org>
Date:       2002-06-11 9:44:43
[Download RAW message or body]

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

On June 11, 2002 05:23 am, Marten Klencke wrote:
> If, for a specific task, there is one app registered, the menu
> item will execute that application. If there are more apps, the
> menu item has a submenu consisting of the apps. The default application
> for the task is at the top with a separator beneath it.

in this case the user may as well use the regular kmenu ... submenus decrease 
usability. if the user wants two similar apps, they can add another (similar) 
task. 

it keeps the concept simple: one task, one app.
it keeps the menu simple: task groups full of tasks.

i've been toying with the concept of top-level tasks, but even that threatens 
to mar the simplicity and consistency.

> The Manage Tasks item pops up the dialog for selecting applications
> for tasks, adding new tasks, etc. When selecting applications, the
> applications that are registered in the normal applnk are used, but

yes

> custom applications can be specified. Just like specifying applications
> for file types in Konqueror.

in the case of specificying applications, it should probably just create 
another .desktop file in the applnk/ hierarchy.

> TOM Storage
> -----------
>
> <tomapplnk>/
> This is the main directory consisting of subdirectories and
> .desktop files. In the above case there are 2 subdirectories
> (Internet and Office). This can be nested a few times.

i'd prefer to avoid submenus. there is no need for nesting.

> The .desktop files are just like the applnk .desktop files, but
> with 2 extra items:
>
> Task: The task they belong to
> TaskDefault: Is this application the default application to handle
>     this task?

i don't want to duplicate the .desktop files in applnk/ since that would mean 
duplicating those files and all their management (e.g. when apps get 
installed, or uninstalled, etc) i want to rely on applnk entries since those 
are going to be consistent with the system.

right now i'm using simple config files to store the contents of the task 
groups. the next two things on my TODO that i'll be tackling is launching 
apps in the task menus (which is trivial) and to handle system/user setting 
merging. this will probably be easier to accomlish using seperate files, ala 
applnk, which will mean some minor changes to the task group loading code but 
nothing enormous. i'll be exploring a few options, though..

> There are, just like with applnk, a system wide tomapplnk and a user-
> specified tomapplnk. The user's overrides the system wide one. For

this is exactly the reason i'm contemplating moving to one file per entry..

> (Do we need a way for users to remove system wide menu entries? Simply
> leaving them out doesn't work because both menus are merged. There
> has to be a explicit indication somewhere that the user wants to hide
> a certain system-wide entry/task-group)

items will be marked as hidden, nothing too difficult.

> Other things
> -----------
> One special submenu in the TOM that has the normal applnk items.
> This way, no two menus are needed on the panel if you also want
> to keep the old-style menu.

this is already there. it is labelled "More Applications" and appears beneath 
the task groups...

- -- 
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)

iD8DBQE9BcaM1rcusafx20MRAnYuAKCAF1WUsl583+/RYzn/3dcxoNLbrQCfVlgf
uh/qij15ljMYrX7qPj5i/sw=
=4E1q
-----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]