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

List:       kde-devel
Subject:    Re: Your technical opinion on this new user interaction paradigm?
From:       Maurizio Colucci <seguso.forever () tin ! it>
Date:       2003-11-10 10:44:46
[Download RAW message or body]

> using the servicemenus you could do something like this. what would need to
> be worked out:
>
>  A) selections from multiple sources
>  B) selecting actions applying to subsets of selected files, not just the
> combination of all selected files.
>  C) greater application-specific introspection
>
> thoughts on each:
>
>  A) it's very difficult to know where various files are selected and would
> result in a rather confusing UI. 

If you introduce complexity, you must also REMOVE more complexity than you are 
introducing. My approach would only be of any value IF it allowed you to get 
rid of ordinary menus and toolbars. (except of course for sorting items in a 
windows). Otherwise there is no paradigm unification, only confusion.

> if you select files in two konqi windows, 
> only to have to then deselect them depending on what you want to do, it's
> not very ergonomic

don't assume that. Wait for my prototype. (of course you are free to do one on 
your own ;-))

> and it breaks the windowing concept. if you added a dock 
> where one can drag icons (not the files) to temporarily, then this is
> neatly solved: no additionally KDE infrastructure needed, no
> paradigm-breaking

I don't get your idea. You could post a screenshot?

>  B) all selected files should be acted upon. otherwise, why select them in
> first place only to have to reselect them again? all actions that apply to
> any file in the selection would act upon any file that it applies to. so if
> you have a kword doc, a text file and an mp3 

In my approach, if the user wants to play mp3 file, he must _deselect_ the doc 
file and the txt file. If you select all three files together, you would not 
see the "play" option nor the "edit" option. Just burn to, delete, copy, etc.
So, obviously, you are not talking about my approach but are proposing another 
semantics, totally different, which cannot be called "narrowing". Because 
there is no narrowing with your approach: if you select more and more, the 
possible vebs are NOT narrowed down, but they increase! It should be tested 
for effectiveness, but it is totally different.

> selecting "play with Juk" 
> would act on the mp3, "print" would act on the kword doc and text file, and
> "archive" would act on all three
>
>  C) to get perfect application introspection (e.g. which CD burner to burn
> to) you'd have to be running every app that you need to introspect into. 

I'm not sure I follow you.
couldn't you just call the application with the right command line arguments?
example:

k3b --burner-dev 0,0 --files a.txt c.doc

so the app needn't be open.
Of course, the apps would need to have an appropriate command line 
interface...

> to 
> approximate the effect, one could simply rely on more robust servicemenu
> files. for post 3.2 i plan to allow dynamic menu creation in servicemenus
> (via the output of commands), as well as introduce ways to programmatically
> manipulate servicemenus (which will then get a universal UI so users can
> manage their servicemenus easily, but also so that apps can create
> servicemenus simply at run-time)
>
> so a dock area to drag apps to which also exposed possible actions via
> servicemenus might be a very good direction to go in?
>
> - --
> Aaron J. Seigo
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
>
> iD8DBQE/rs6v1rcusafx20MRAnQ3AKCCl3KVX1XbUe0K+DxHNTORVXQRSgCff1Ul
> dL5ea8fZlzdpuGFXrFbqsLw=
> =Pgva
> -----END PGP SIGNATURE-----
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> >> unsubscribe <<

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]