From jim@jimpick.com
Received: (qmail 15562 invoked from network); 27 Jan 1998 20:07:16 -0000
Received: from fleming.jimpick.com (jim@204.209.212.123)
by mail2.redhat.com with SMTP; 27 Jan 1998 20:07:16 -0000
Received: (from jim@localhost)
by fleming.jimpick.com (8.8.8/8.8.8/Debian/GNU) id MAA10538;
Tue, 27 Jan 1998 12:07:08 -0800
To: gnome-list@gnome.org
Subject: Panel GUI
X-Url: http://www.jimpick.com/
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: multipart/signed; protocol="application/pgp-signature";
boundary="pgp-sign-Multipart_Tue_Jan_27_12:07:02_1998-1"; micalg=pgp-md5
Content-Transfer-Encoding: 7bit
From: Jim Pick <jim@jimpick.com>
Date: 27 Jan 1998 12:07:06 -0800
Message-ID: <87u3ap7kb9.fsf@fleming.jimpick.com>
Lines: 109
X-Mailer: Gnus v5.4.66/XEmacs 20.2
X-Face: Hz"C77\53<,u1}C~=DFwS#Ddj161XLl6W!3g7xjxh*P'`FF^-IYQXX$a*WC~=^8rvy"~<3z
UeQqGo&KZe[}lJg`\+SDMGRVIUJ~P,#(=w~yYv{g9i%"k|\J|jYVvv^Bzfwo=@AddrDMO<xV_IAl`(
TW7;|vH6Kik(,iljluXex0vrnM:SedI@lbAeNvM
I've been playing around with the latest panel, and I'm really
starting to like it.
Here are some requests:
* Menus
- The right-click menus are somewhat hazardous to use. The item
under the mouse is selected when the mouse button is released.
If you decide not to do something, you have to consciously
move the mouse off of the menu. That's not intuitive.
- The menu that pops up when clicking on the background of the
panel should be the same one as the "Panel" menu in the top
menu level.
- The menus should grab the mouse, so that when you click off the
menu, they disappear.
- 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.
- When using autohide, the panel should hide itself until the
menu is closed.
* 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.
- "Log out" should really be "Close down panel"
* Installing
- I'd like it if the installation Makefile would set the "Exec"
entries in the .desktop files to include the full path
(ie. add on $bindir). I've got multiple versions of Gnome
on my machine.
* Customizing
- When adding a new applet to the panel, it would be nice if it
would appear in a blank space, rather than rearranging the
rest of the applets.
- I'd like to be able to add text icons, pixmap icons, or icons
with both. Down the road, it would be cool to have a pixmap
editor based on the Gimp - with Net-Fu style "canned" scripts.
- A nice pixmap browser/selector would be cool.
- 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.
* Components (down the road)
- I'd like to see the whole panel concept be an application
that sat inside a Gnome container app. That way, there
could be multiple panels. In turn, the panel itself would
just be a container.
ie. I might have a "window edge" container app in which
I can embed multiple panels. There might one panel on the
top of the screen, and two auto-hide ones on the right.
A panel could have a fixed size so it wouldn't take up
an entire side of the screen. The container app might
have some support for scripting too.
Other container apps would be able to embed the panel too,
so the panel could be used inside the borders of the
client application. That would be cool with the auto-hide
feature.
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.
I hope somebody is reading this list. :-)
Cheers,
- Jim
From jirka@5z.com
Received: (qmail 10556 invoked from network); 27 Jan 1998 22:17:27 -0000
Received: from dt063n08.san.rr.com (HELO 5z.com) (@204.210.38.8)
by mail2.redhat.com with SMTP; 27 Jan 1998 22:17:27 -0000
Received: (from jirka@localhost)
by 5z.com (8.8.7/8.8.7) id OAA01507;
Tue, 27 Jan 1998 14:16:42 -0800
Message-ID: <19980127141642.30238@julia.5z.com>
Date: Tue, 27 Jan 1998 14:16:42 -0800
From: George <jirka@5z.com>
To: GNOME Malinglist <gnome-list@gnome.org>
Subject: Re: Panel GUI (A new panel proposal)
References: <87u3ap7kb9.fsf@fleming.jimpick.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.85e
In-Reply-To: <87u3ap7kb9.fsf@fleming.jimpick.com>;
from Jim Pick on Tue, Jan 27, 1998 at 12:07:06PM -0800
> I've been playing around with the latest panel, and I'm really
> starting to like it.
>
> Here are some requests:
>
> * Menus
>
> - The right-click menus are somewhat hazardous to use. The item
> under the mouse is selected when the mouse button is released.
> If you decide not to do something, you have to consciously
> move the mouse off of the menu. That's not intuitive.
there is already a FIXME in the code about this :)
> - The menu that pops up when clicking on the background of the
> panel should be the same one as the "Panel" menu in the top
> menu level.
yes this is also something I've been considering, problem is that a menu
applet has to be registered .. and there has to be some sort of interface
to it ... I'll get to it though ...
> - The menus should grab the mouse, so that when you click off the
> menu, they disappear.
yes .. this is an annoying behaviour ...
> - 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
> - 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?
> * 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???
> - "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)
> * Installing
>
> - I'd like it if the installation Makefile would set the "Exec"
> entries in the .desktop files to include the full path
> (ie. add on $bindir). I've got multiple versions of Gnome
> on my machine.
hmmm .... probably a good idea ...
> * Customizing
>
> - When adding a new applet to the panel, it would be nice if it
> would appear in a blank space, rather than rearranging the
> rest of the applets.
I already have a scheme that will allow this, I just haven't implemented
it yet
> - I'd like to be able to add text icons, pixmap icons, or icons
> with both. Down the road, it would be cool to have a pixmap
> editor based on the Gimp - with Net-Fu style "canned" scripts.
this requires some changes, I plan to develop a "Generic" button applet, that
all the "button type" applets can inherit from (menu, launcher, log out) ...
then a change to properties of this, would change all the "button type"
applets, this would keep consistency
> - A nice pixmap browser/selector would be cool.
I think Ian had one (or was working on one)
> - 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 ...
> * Components (down the road)
>
> - I'd like to see the whole panel concept be an application
> that sat inside a Gnome container app. That way, there
> could be multiple panels. In turn, the panel itself would
> just be a container.
>
> ie. I might have a "window edge" container app in which
> I can embed multiple panels. There might one panel on the
> top of the screen, and two auto-hide ones on the right.
> A panel could have a fixed size so it wouldn't take up
> an entire side of the screen. The container app might
> have some support for scripting too.
>
> Other container apps would be able to embed the panel too,
> so the panel could be used inside the borders of the
> client application. That would be cool with the auto-hide
> feature.
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) ...
> 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
2)the panel would be devided into a sparse grid (maybe with the look of
my prototype table implementation, where each cell has a 0-size button
in it since it looked cool) .... this grid would be homogeneous ...
larger applets could take up more then one cell (the panel would decide
this based on the size of the cell/applet and center it on the cells it
is taking up)
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) ...
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
5)panel would also take care of the menus (it would take the
responsibility of menus from the menu applet, a menu applet would be
just a simple button type applet that would contact the panel to display
a certain menu, this makes the menu stuff easier
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
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 ...
so what do you all think ...
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!!
From miguel@nuclecu.unam.mx
Received: (qmail 2984 invoked from network); 27 Jan 1998 23:10:44 -0000
Received: from athena.nuclecu.unam.mx (132.248.29.9)
by mail2.redhat.com with SMTP; 27 Jan 1998 23:10:44 -0000
Received: (from miguel@localhost)
by athena.nuclecu.unam.mx (8.8.7/8.8.7) id RAA12367;
Tue, 27 Jan 1998 17:09:36 -0600
Date: Tue, 27 Jan 1998 17:09:36 -0600
Message-Id: <199801272309.RAA12367@athena.nuclecu.unam.mx>
From: Miguel de Icaza <miguel@nuclecu.unam.mx>
To: gnome-list@gnome.org
In-reply-to: <"JRHyy1.0.1x3.5wZpq"@mail2.redhat.com> (message from Jim Pick on
27 Jan 1998 20:07:36 -0000)
Subject: Re: Panel GUI
X-Unix: is friendly, it is just selective about who its friends are.
> - The right-click menus are somewhat hazardous to use. The item
> under the mouse is selected when the mouse button is released.
> If you decide not to do something, you have to consciously
> move the mouse off of the menu. That's not intuitive.
yes. The right button menus should probably pop above the panel, or
not close to the mouse.
> - The menus should grab the mouse, so that when you click off the
> menu, they disappear.
Oh, that is the trick :-). Hopefully George is listening to.
Miguel.
From jirka@5z.com
Received: (qmail 7817 invoked from network); 28 Jan 1998 04:12:42 -0000
Received: from dt063n08.san.rr.com (HELO 5z.com) (@204.210.38.8)
by mail2.redhat.com with SMTP; 28 Jan 1998 04:12:42 -0000
Received: (from jirka@localhost)
by 5z.com (8.8.7/8.8.7) id UAA02723;
Tue, 27 Jan 1998 20:11:54 -0800
Message-ID: <19980127201154.01325@julia.5z.com>
Date: Tue, 27 Jan 1998 20:11:54 -0800
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)
References: <19980127141642.30238@julia.5z.com>
<87g1m9l7ub.fsf@fleming.jimpick.com> <19980127190950.44874@julia.5z.com>
<87k9bldzxb.fsf@fleming.jimpick.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.85e
In-Reply-To: <87k9bldzxb.fsf@fleming.jimpick.com>; from Jim Pick on
Tue, Jan 27, 1998 at 07:45:36PM -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!!