Re: Panel GUI (A new panel proposal)



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]