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

[Jim Pick <jim jimpick com>]

George <jirka@5z.com> writes:

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

Sure, sounds good.
 
> > > >    - "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 just figured out how the session management works, so I sort of get
where you are coming from now.

I still maintain that the "log out" button is quite confusing though
if you aren't running session management - because it won't actually
log you out.

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

Sure, that sounds good too.
 
> > 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 :)

You might want to have a "handle" on the edge of the panel so you can
adjust the width too.  Maybe even drag and dock it.  Plus you might
want to adjust it so it only takes up 50% of a side of the screen,
etc.

Also, when you toss it into design mode - some additional windows
might pop up on the screen, to change colours and such.  That would be
sort of cool - make the design mode dialogs as non-modal as possible
(ie. throw them all up at once).  When the user is finished tweaking,
they can lock it down.  During design mode, you could even blank out
the rest of the screen and write in big letters "DESIGN MODE" in the
root window.

> > > >  * Components  (down the road)

> 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

CORBA is actually pretty simple once you've got the proper language
bindings happening and your ORB set up, etc.
 
> so there would be the applet object which would be embedded in some sort
> of workspace manager, where panels would also be embedded ...

Generally, containers should also be embeddable - but not always.

We could work slowly, adding the ability for the panel to be a container,
and then later work on making it so it can act as an embeddable object
itself.
 
> I don't see much use for scripting though ...

I'm sure somebody could figure out a use for it.  :-)

I wouldn't worry about that at first.  Exporting methods from the
panel would be a nice start however.

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

That's very naughty.  One screw-up, and the panel is fried.  But, you
could have an interface which makes this legit.  Think of visudo - which
is a frontend for vi when editing the sudo config files.  It verifies that
you don't screw-up - so it is a clean interface.
 
> 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 ...

That's all it should be, I think.  But if it is embeddable itself, it
can be used within a more ambitious container.
 
> > 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? ... :)

It wouldn't hurt.

Eventually, when we've got something concrete - we really ought to
write a Gnome specific introduction to CORBA.  That would be a lot
less dry and less abstract than most of the documentation out there.

I'll volunteer for that job.  :-)

Cheers,

 - Jim

PGP signature