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

List:       kde-devel
Subject:    Re: New paradigm of interaction - prototype ready.
From:       "Manuel Amador (Rudd-O)" <amadorm () usm ! edu ! ec>
Date:       2003-11-20 2:01:38
[Download RAW message or body]

> I agree you would hate it, but maybe not if you use compliant apps. This 
> system requires compliant applications:

with apps installing verb information in e.g. /usr/share/verblnk or
/usr/share/apps/kverb/verbs ?

> 1. It doesn't (yet) support the concept of directory (just dynamic filters 
> based on features).
> 2. it requires each program to declare the verbs it supports.
> 
> > Firstly, your list of programs there is very meager. I don't really want
> > to scroll through my dozens and dozens of programs to find something I
> > would usually have on my desktop or in kicker. So normally I would never
> > open this thing to start off.
> 
> You use filter for this. You will have filters on files, on programs, on 
> verbs, and on devices.

Wasn't the idea of the verbs panel to be a nonobtrusive thingie that appears
upon selection?

> 
> > Secondarily, the problem increases dramatically when you have a billion
> > files to work with. Just one CVS tree could completely swamp a window full
> > of filenames for one to traverse.
> 
> There is no concept of tree currently...
> Would that be solvable with filters too? "only show files written by x, y and
> 
> z AND belonging to the cvs project k".
> 
> > I see the same problems for this interface as for the GNOME project to
> > make a database-centered filesystem with information "soup" where you type
> > things like "all George Lucas's movies" and it narrows down to a list. It
> > sounds great, but in actual use it would be inferior to the file tree
> > system experienced users are used to.

I don't think so.  For experienced users it might be less useful than the
tree.based approach, but noobs find it's great.

On storage proper, It's the implementation detail that bugs me.  GNOMEVFS-based
URLs abstract the thing and not all apps are ready for VFS ready urls.  This
kind of abstraction should be pushed directly into the filesystem namespace,
it's about time it did.

They use a relational database, where they should be using a database that
integrates seamlessly with operating system security (I find relational
databases suck at this).  Either they branch a relational database and fit it to
the purposes of the app, or build a new one.

They use the database as the primary source of metadata, when in actuality, EAs
or in-band data should be doing the trick, and the OS should be caching that
information.

> Perhaps to a complete novice who
> > could not organize his/her files and didn't know where things when when
> > they hit "save" it would be nice...
> 
> Yes, and this is the primary target.
> 
> > But it had darned well better not get 
> > in my way when *I'M* trying to do something.
> 
> Well, you could just use it for common tasks.
> 
> > While this MAY be helpful for the novice who doesn't KNOW what their linux
> > distro can do, I think it could quickly become unweildy in actual use.  
> 
> That's why I'm developing a prototype.
> I want to know if, witch filtering and common selection remembering, it 
> becomes easier for experts too.
> 
> Thanks again!
> 
>  
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
> <<
> 


    suerte,

    Rudd-O

===========================================================
     UNIVERSIDAD TECNICA FEDERICO SANTA MARIA
                 CAMPUS GUAYAQUIL
        CENTRO DE SERVICIOS INFORMATICOS
Mail enviado a traves de IMP-USM: http://www.usm.edu.ec/imp
    Los invitamos a visitar  http://www.usm.edu.ec
===========================================================
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]