Re: GNOME user environment brainstorming


I hope people that Cody mailed will get to read this mail. I guess
they're all on the gnome2 mailing-list.

Here are my thoughts.

On 24 May 2001 15:45:30 -0500, Cody Russell wrote:
> On 24 May 2001 15:48:04 -0400, Havoc Pennington wrote:
> > 
> > Anyway, here's what we came up with.
> Hi Havoc, I'm really glad to see this mail.  I'm happy that someone is
> now pushing to have things more integrated in this way.  I'd like to
> make a couple suggestions as well now that this topic is opened.  Better
> integration between the file manager and the panel is one of my main
> concerns right now.  Both of them deal with launching of applications
> and stuff, but they don't make any attempt to deal with things
> similarly, and so GNOME has sort of a non-unified appearance.
> 1/ Changing your icon for gnome-terminal on the desktop should change
> the icon for gnome-terminal on the panel.  Perhaps some sort of
> application/document/icon registry in GConf.

Yep, Would be a good idea, gnome terms that I start with a keyboard
shortcut in the root menu (Window Maker, if you ask) have a different
icon from the one I want them to have.

> 2/ We can drag objects from the panel to Nautilus and the desktop, but
> we cannot do the opposite.

Second that.

> 3/ Editing the foot menu is a long-overdue feature, although it is not
> simple.  It should be possible to drag icons to the foot menu, re-order
> it, etc.  Dealing with .desktop files sucks.
> The problem is that there should be some method for system
> administrators to install objects as read-only or something, so they
> can't be removed or modified by users.
> I've thought about this one already, but haven't really come up with any
> fantastic solutions.  If anyone can think of one, I'd be willing to help
> work on it.

KDE (1.x, not used 2.x enough to know about that) has something we could
use. KFM was the editor for applications, mime-types, etc. and was
merging the content of /usr/share/kde/mime-types/ with
(Bear with me for the dir names, that's from top of my head).

> 4/ Let panel launchers and foot menu use any type of object, not just
> "programs".  e.g., you might have a launcher for Slashdot or
> on your panel or in your "Favorites" menu.
> Technically this is already possible because panel supports launchers
> for types "Application", "PanelApplet", and "URL".  This is
> insufficient, though, I think.  I think it should transparently handle
> this and let you use any type of object.. a better example would be a
> "Most Recent Documents" submenu, which might contain Gnumeric or AbiWord
> documents.

This could be done easily if the launchers were actually an helper
application. Like the gnome-edit that launches the editor, this one
would detect the type of the thing we're clicking on and launch it...
That means we could put documents and all sorts of files on the panel,
like it's possible on the OpenStep beta shelf, and the MacOS X dock.

Adding a function for the apps to register their newly edited documents
in the gnome-libs could give you the "Recent Documents" feature you
want. The app would call the function, the function take a look at what
the user wants (last 10 documents only ? we delete the oldest link), and
the panel re-reads the directory containing the links.

That bring me to something that I need for the application I'm writing,
and could certainly be of great use. Why do all the applications, as
soon as they need more than simply reading config files, have to create
their own directories (some hidden, some not) in the ~/

My application is an iTunes clone. I want to save Playlists, have users
an easy way to add or remove effects configuration files (for the
visualisation plugin), and store the newly ripped songs. So I created a
~/RhythmBox/ directory containing all that. Nautilus has its ~/Nautilus,
Evolution the ~/evolution (or ~/Evolution...), gtk+ themes in ~/.themes,

Would it be possible to have all this visible, and in one directory like
GNUStep does: ~/Gnome ?
And every app could create the subdirectories as needed, and the user
has a much better experience, because he knows there is important data
there, and he can modify it. Drop a theme, a plugin, a script, a
playlist, a song that the app will understand.

> So, the bottom line here is just better document abstraction and type
> registration of some sort.

Comments ?

/Bastien Nocera

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]