Re: Panel GUI (A new panel proposal)
- From: George <jirka 5z com>
- To: Jim Pick <jim jimpick com>
- Cc: GNOME Malinglist <gnome-list gnome org>
- Subject: Re: Panel GUI (A new panel proposal)
- Date: Tue, 27 Jan 1998 20:11:54 -0800
> 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.
well but it's intended to be use used with the session managment stuff
... so I don't think that's the big problem now ... if people do run a
panel as a separate app without gsm, then there might be some option ...
or a separate applet called exit which will not even talk to session
managment
> 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.
well I would let the design mode be completely usable just as it is now,
(since some pople don't want to have two modes of operations) ... the
lock mode could remove handles to indicate you CAN'T resize stuff ... or
at least it would make them grey, inactive or soemthing to that extent
> > 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.
yes I would say the "road plan" would be something like
1) develop the applet<->container interface (just so that we know what
kind of chit chat will be going on between these two, I don't think this
will be hard ...)
2) create a panel container widget which does geometry of "objects"
3) create a panel object that includes the panel widget ...
4) develop/port existing applets to the new framework
5) develop the "desk"/"workspace" whatever manager, which will itself have
panels and applets, anywhere on the screen, (applets will be floating only,
panels could be snapped to sides/corners or floating)
> > 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.
yes .. most scripting languages are quite nicely embedable so adding
support should not be hard
> > > 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.
somewhat like a "verifier" ... yeah .. that would be good ... I don't think
it's of the essence now ...
> > 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.
such as the workspace manager thingie ... :) (hmm probably workspace
manager is the best thing to call it ...) ... it would be a container
which would "own" the screen so you could place the applets/panel anywhere
...
> > 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. :-)
well .. I'm not much of a writer, ... :)
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!!
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]