Re: Panel GUI (A new panel proposal)

[Jim Pick <jim jimpick com>]

George <jirka@5z.com> writes:

> >    - When the panel is on the right side of the screen, it would be
> >      nice if the arrows for the submenus pointed to the left.
> 
> dunno how to do it with the menus, didn't look too deep into that code,
> but I think this is a problem with stock gtk that would require a gtk
> change

Yes.
 
> >    - When using autohide, the panel should hide itself until the
> >      menu is closed.
> 
> huh? ... I don't know exactly what you are saying? ... you mean the main
> menu?

Oops.  I meant to say "_not_ hide itself until the menu is closed".  I
really ought to proof-read my posts.  :-)

> >  * Saving and exiting
> > 
> >    - There should be a "Save" menu entry for saving the state of the
> >      panel.  Otherwise, the only way to do it is to close down the
> >      panel, and reload it.
> 
> why would you want to save it in the meiddle of a session???

In case it crashes!  It happened to me several times.  If the panel is
truly useful to people, they will spend hours customizing it -- then
the power will fail.  Murphy's law.  No two ways around it.

> >    - "Log out" should really be "Close down panel"
> 
> well the panel is meant to be the app that when it ends, X session
> ends ... (or it contants the session manager to end the session)

I'd like to be able to quit the panel without logging off my computer
(which I almost never do - I work at home).  In a pinch, I guess I can
use my window manager to do that.

> >    - I'd like to have panel to have two modes - design time and
> >      run time.  That way, it would be locked in normal use, so
> >      it would be hard to accidentally move or remove applets.
> 
> hmm .. but that would add complexity to the thing ...

Not much.  Just a boolean variable (with a toggle) and a bunch of if
statements.

That's part of the problem with the Win95 interface - it's always in
"design" mode.  I've got a nice set of little toolbars set up for my
parents on their computer.  But occasionally, they click in the wrong
place and screw it up.  A good "design mode" has all sorts of
"handles" all over the place that you can click and drag with the
mouse.  But they can get in the way when you are finished designing.

> >  * Components  (down the road)
> 
> yes .. would be nice wouldn't it :) ... I am right now thinking about a
> major rewrite of the panel (though my idea of a rewrite is usually
> ripping code appart and trying to reuse some of it :)
> 
> it would probably take a lot of time though .. (to do it right) ...

I think the CORBA stuff gives us 90% of what we want.  I think it's
just a matter of getting a basic generic container to embedded-app
interface written up and implemented.  Plus a few support services.

No hurry though - because it's not too hard to rip apart the code
already written and rearrange it for CORBA.

I'd like to see the prototype component system happen outside of any
of the main apps first.  We need sort of a "hello world" thing first.
 
> > Anyways, I've got more ideas ... but that's a start.  I'd be
> > willing to work on some of these specific items if nobody else
> > is already working on 'em.  Keep in mind that I'm a bit
> > slow to get things done.
> 
> we'd need to get a design spec down ... since I've worked on the panel a
> bit already, I know what the current limitations are (or I think I know)
> ...
> 
> what it definately needs is an OO design ... the current design is very
> inflexible ... also what we need is a "panel widget" .. soemthing that
> does the widget geometry ... hopefully different styles of geometry ...
> (the old gtkfixed one, the new table type one)
> 
> Iw as thinking about this last night and an idea that cam to me was this:
> 
> 1)the panel would be a widget capable of embedding other apples or even
> panels

I see two things - a Gtk widget that handles the panel animations.

Then there's the true gnome "container" app which would use that
widget, and arrange embedding objects (that handle the "panel applet"
document type) inside it.  It might have a scripting interface built
into too.

> 3)the panel would be configured and used with drag and drop only, (to
> move an applet, you would drag and drop it in the new place, this makes
> multiple panels a lot easier) ...

I wouldn't mind a "panel editor", which spits all the data out to a text
file, allows the user to edit it, and then reparses it back in.  Or
maybe something similar with a Gtk touch, with a few more constraints.

Also, I'd like to see some methods exported via CORBA, and scripts could
be used to plant and re-arrange stuff in the panel too.  (when the CORBA
stuff gets settled)
 
> 4)applets would be further separated from the panel, a separate
> gnome-lib should be made for creating applets, they should not be
> dependant on this implementation of the panel in any way

I'd like to see applets implemented as any other Gnome application.
They'd all be registered to support a "panel item" document type (or
something like that) and behave in a similar manner.

The GOA (Gnome Object Adapter) would launch them.  They could be
implemented using any supported activation method the GOA supports.
ie.  Staticly linked code (ie. internal procedures), dynamic
libraries, shared "server" executables, unshared executables,
persistent "server" daemons, etc.  The panel wouldn't have to worry
about any of this - the GOA would do this.

ie.  To use an over-used example - if there were CORBA binding on
Emacs, it could be set up via the GOA to act as a shared "server"
executable.  A panel applet could be implemented in elisp (if emacs
also had a Gtk library).  ie.  The emacs "diary" might implement
an applet to pop up reminders for important appointments.

The first time that panel applet is referenced, the GOA would start up
emacs (if it wasn't already started), and run the elisp.  Any
subsequent time the applet is referenced, the GOA would just forward
the calls onto the already running emacs.

Conversely, applets could be implemented "in-process", just as they
are now, or via dynamically linked libraries.  The GOA would take care
of all the details.

> 6)panel should be responsible for the screen and the applets on it ...
> basically what it would do is to have some free floating applets on the
> screen and some may be on a panel widget ... a panel widget would be
> used if you want the applets grouped together and have the possibility
> of hiding them

Again, this is the "container" concept.  Even though the applets (and
launched applications) are floating, they could be considered as being
embedded in the panel, from where they were launched.
 
> since I really really want to learn ObjectiveC ... I guess that would be
> the language I'd use :) ... (unless somebody protests, but I'd gues a true
> OO language would be good for this) ... applet-lib and the communication
> applet<->panel would be in C to maximize portability ...

With CORBA, you can use any language for which bindings exist.

The big problem currently is that the mico ORB only has C++ bindings
currently.  I don't think it's too much work to add additional ones
though.

So,

For the panel - I wouldn't worry too much about introducing
"libraries", external "applets", and such since we'll probably have
the CORBA embedding stuff working within a month or two.

Cheers,

 - Jim

PGP signature