[patch] xfdesktop menu icons

[Danny Milosavljevic]

Hi,

Am Don, den 29.01.2004 schrieb Jasper Huijsmans um 09:34:
> On Thu, Jan 29, 2004 at 02:13:55AM -0500, Brian J. Tarricone wrote:
> > hi all-
> > 
> > this is by no means finished, but i wanted to get out a patch before i 
> > went to bed tonight so people can play...
> > 
> 
> Wow, that's a pretty big patch. Nice.
> 
> Two suggestions (for now ...) :
> 
> * Don't show icon when there is none found and/or none specified. A menu
>   full of default icons is not very useful ;-)
> 
> * Perhaps we should limit the system menu to one level, or at least
>   'collapse' empty menus, e.g I have this:
>   
>    Graphics -> 2DGraphics -> RasterGraphics -> The Gimp
> 
>    No other items in the menus ;-) I'd say Graphics -> The Gimp would be
>    more appropriate.

Yup, a little (depth first) recursive function searching for menus 
1) having no child nodes of type "app"
which moves the child nodes of type "branch" (if any) into the parent
and destroys the (now empty) menu and the assoc item.

and/or

a (depth first) recursive function no.2 searching for menus 
2) having only one(x) child node of type "branch", nothing else,
which moves the child nodes of the child node x into this menu and
destroys the now empty menu.

like

fun1(pitem):
  pmenu = pitem.get_submenu()
  assert(pmenu)
  list = container_get_children(pmenu)
  for i in list: if i.get_submenu(): fun1(i)

  appitems = False
  for i in list: 
    if not i.get_submenu():
      appitems = True

  if not appitems:
    # menu has no apps
    for i in list:
      i.set_property("parent", pitem.get_property("parent"))

    pitem.delete()

I wanted to write this one in C but got lazy for some reason :-> (plus
there are weird side effects that need to be handles when deleting pitem
- and continuing the traversal in the previous recursion level -, I
guess)

[but if someone with much gtk experience *hint* writes a safe
menu_item_set_parent_menu which does the dirty work, I'd do the
remainder ;)] 

(
Also maybe there could be a setting of "max total menu depth", and as
soon as the max menu depth would be reached, it would not create anymore
submenus (i.e. it would put the menuitems into the last depth).
Preferrably via a collect/expand button per menu *grin* or just a
#define for now ;) hehe somehow I get the feeling this would be real
weird to use. 
So that's not good, maybe. I have another proposal instead below :->
)

> 
>    One idea is to pick a number of toplevel categories and try to fit
>    everything into them. Well, just a thought, probably inspired by the
>    fact that I don't like hierarchic menus much at all.
> 
> Great work brian.

Yeah, hierarchical menus which are overdone can be a real pita. But when
having small submenus collated into the parent menu with a headline, it
would be ok .

like: 

currently the (my) Game menu is (its one of the worst, width-like ^^):
|Mines   |
|Action >|1   1|Quake 3   |      2|Mahjongg|          3|Robots|
|Board  >|2    |Unreal    |       
|Arcade >|3    |Descent 2 |
              


I'd like the Game menu being:

|*Game*  |<<headline
|--------|
|Mines   |
|--------|
|*Action*|<<headline
|--------|
|Quake 3 |
|Unreal  |
|Descent2|
|--------|
|*Board* |<<headline
|--------|
|Mahjongg|
|--------|
|*Arcade*|
|--------|
|Robots  |

Thats what I'd *really* like to see.
Now lets say when the number of action games increases to >4, or better
the number of total entries in the collated menu increases over a
certain limit, THEN it would become:

|*Game*  |<<headline
|--------|
|Mines   |
|--------|
|Action >| -->|Quake3    |
|*Board* |    |Unreal    |
|--------|    |Descent2  |
|Mahjongg|    |Somenew   |
|--------|    |I missed  |
|*Arcade*|    |Here stuff|    
|--------|
|Robots  |

:P

Yeah I know... much work...
Then again, if reparenting of menu entries to another menu is possible,
then its not that bad. Just create the menu in totally expanded
(hierarchical) way first, then traverse nodes depth-first and fix
up/collate if number of entries in child menu is small enough and number
of entries in this menu is not over a certain limit.

This certain limit would be like what 2/3 of the screen (not display)
height divided by height of an icon is.

So the menu building/showing process would be:
  1) build menu totally hierarchical (expanded)
  2) eat unneeded submenus (i.e. menus having 1 branch only,....)
  3) collapse until 
      - everything is contained in 1 menu or 
      - per-collapsed-menu-limit-on-number-of-entries is reached
     depth-first again (I say that a lot today ;)); add titles into 
     the menus to show what has been a submenu before.

Anyways, I stop now :)

Tell me what you guys think :)

cheers,
   Danny

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20040131/eaca1f51/attachment.pgp>