[George <jirka@5z.com>] Re: Panel GUI (A new panel proposal)

[Jim Pick <jim jimpick com>]

This is actually from George, I'm just forwarding it because he
forgot to cc: the list.  My reply will follow.

---

• From: George <jirka 5z com>
• To: Jim Pick <jim jimpick com>
• Subject: Re: Panel GUI (A new panel proposal)
• Date: Tue, 27 Jan 1998 19:09:50 -0800

> > >  * 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.

well the saving doesn't take all that much, I think it should be
transparent to teh user ... (say saving the state every 5 minutes
or so) ... or we could save state after every change (we don't need
save the whole state information, just whatever changed) ... this would
be the easier approach and the one more bullet proof ...

> > >    - "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 would think of the panel as the session manager (in a sense that it is
the app that is "running" the session, not the xsm type of session manager
... in most cases the window manager is that type of a session manager,
in our case it would be either the panel or gsm ... panel for a simple
setup with no session management, gsm for the whole bit)

> > >    - 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.

would be somewhat like vi ... two modes .... :) ... well but I'd say
most people (especially newbies wouldn't like it) ... I would say a lock
button or soemthing similiar would be better .... so the panel would
start up in normal mode ... in which you could change anything ... if
you wish to lock it down .. you press the lock button and the panel
freezes the positions and applets, so you can't move/delete/add them ...
it could be set up to start up in the locked mode as well ...

> 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.

well I'd guess the handle will be the applets themselves :)

> > >  * 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.

yes this should/could be done with CORBA ... I meant the panel would take
up a lot time ... I have no previous experiences with CORBA ... (or rather
no experiences and don't know too much about it) ... my impression is
it is somewhat like an OO way of providing functionality ... but
transparently

so there would be the applet object which would be embedded in some sort
of workspace manager, where panels would also be embedded ...

> 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.

I would start writing something like the panels which can hold applets
then the workspace manager would have the panels and even applets embedded
in it

> > 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.

I don't see much use for scripting though ...

> > 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.

you could allways edit the config files

> 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)

yes, once the corba stuff is in place :)

> > 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.

yes .. soemthing such as that ... all the stuff that would be common to
applets would be in teh library which could be just used by applications
needing to make applets available ...

> 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.

yup .. that would be it's job :) ... (isn't that why we are using corba:)

> 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.

well actually this "thing" should no longer be called a panel ....
probably workspace manager would be an appropriate name ... or desktop
manager or ...

panel is a place to put applets on ...

> > 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.

and consequently gnome will have all tehbindings for all the languages
that are used ... (C,C++,objc,guile,whatever ...) ... I'd really like
to see other scripting languages then guile, since I tend to dislike
lisp-like languages :) ... as long as I can use C I'm ok though :)

> 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.

yes .. I'd better start reading up on corba then eh? ... :)

George

-- 
------------------------------------------------------------------------------
George Lebl <jirka@5z.com> http://www.5z.com/jirka/
------------------------------------------------------------------------------
While some may have the year 2000  | $ emacs
problem, my 64-bit alpha's got the | bash: emacs: command not found
year 292471208677 problem          | YES!!

---