Re: Some general facts about panel and gnome

> Fact 1: There should a recent accessed-modified document sub-menu.
>This is implemented in Windows and is a good idea! This sub-menu is of
>course a gnome_private thing. It should of course be created by gmc or
>its descendant with mime-types and all!

I think it might be necessary to implement this at a lower level than Gnome,
and provide a Gnome interface on platforms that support this feature. On
Linux, I would think the vfs could provide a list of files recently modified
by a particular user, although I doubt the kernel hackers would want to add
this feature.

> Fact 2: The panel as it is right now is either below or above other
>windows! When above, dialogs can be partially hidden. When below
>(normal thing by the way) and you use a drawer, the drawer will always
>be below. This is bad!

The new WM spec will give you more flexibility in this respect. Docks and
panels are identified as such by a window manager hint, and it is up to the 
window manager how it treats them (autoraise, always below, etc).

> Fact 3: There should be a device manager for God's sake! Either we do
>it, or I will go beg kernel developers to make one (as they did with
>make xconfig), however it will probably be Tcl/Tk and not Gnome! I
>already suggested that but no one even discussed it!

I heartily agree with you, this should be a priority for Linux ease of use, 
but because this must be platform-specific it is not likely to be adopted by 
the core Gnome developers, and because it is Gnome-specific it is not likely 
to be adopted by the Linux kernel developers. Perhaps you could try to 
organise some Linux/Gnome users to work on the project? You could look at (Red
Hat's?) gnome-linuxconf as a starting point, also I think there is a GUI Linux
kernel builder on the Gnome software map. Maybe Red Hat would contribute some
time to the project if you could convince them that some Linux users want to
configure their own machines and not depend on a Unix guru to do it for them.

> Fact 4: Either tell enlightenment (best window manager in my opinion)
>folks to be compliant or fork if you wanna keep it as default gnome
>window manager! Someone with good window manager knowledge should do
>it! I have yet to see another decent window manager for gnome that is
>at least not completely ugly! We NEED a default 100% compatible window
>manager by default. Other are welcome to comply if they wish!

Enlightenment is not the default Gnome window manager, although Red Hat may
configure Gnome to use Enlightenment by default. But that's their problem.  :)

The window manager spec will be undergoing a major revision soon, so expect to
see better-behaved Gnome-compliant window managers.

<plug>I'm working (very slowly) on a simple window manager for Gnome. It will 
get finished twice as fast if you help.  :)  My aim is to provide a wm which
is very small, requires no extra libraries on top of gnome-libs, and which
matches GTK/Gnome themes.</plug>

>  Fact 5: I don't know if this redhat's problem or gnome's. It's the
>file manager! I know you guys are re-writing it from scratch. Anyway,
>avoid the following problem: I keep setting my zip drive icon in the
>gmc icon link on my desktop along with other 'disk' icons. Except that
>cdrom is not there. That's ok with me, but each time I mount a CDROM,
>all devices are re-scanned and all their icons are reset to default.

You could submit a bug report, but as you said the file manager is being

> Fact 6: Gnome is simply beautiful! The prettiest panel, icons out
>there! Keep it that way.


> Fact 7: We need to talk to several software vendors to make their
>stuff support gnome one way or the other! Example: staroffice can plug
>itself in KDE and CDE. They should do the same with gnome. Same thing
>goes to other major software makers. This is called PR, and either
>everybody, RedHat, Helix... must do it!

Hopefully the new wm spec (which is meant to apply to both Gnome and KDE) will
allow applications which are written for one environment to behave sanely
under the other environment.

Michael Rogers

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