[openbox] client list with submenus

[Dana Jansens]

Thanks Alexey.  Last comment below.

2011/1/5 Alexey Korop <akorop at gmail.com>:
> Dana Jansens wrote on 04.01.2011 23:06:
>
>>>     1.1. Now default item is marked in a expanded submenu by the same
>>> symbol
>>> as a menu item mark, but placed at the right of the bar.
>>
>> In the example the default menu item doesn't have an icon of its own.
>> If it did would the icon not show up, or would the default marker not
>> show up?  What if we bolded the default entry instead? Then it would
>> always be visible.
>
>     Default marker is visible always, instead of the icon if a icon is
> defined too.
>     It is possible to show the marker in the its own field if the conflict
> with the icon is actually present. But it seemed to me that the complexity
> of the program was not warranted. What is Your opinion?

I think we have 3 types of menu items.  Non-submenus, Submenus with
default, and Submenus without default.  I'd like to use the "submenu"
indicator to instead display these 3 things.  That is, currently the
submenu indicator is either empty or an arrow.  I would like to change
it instead to have 3 states.  How about empty, an arrow, or a diamond
(for submenu with default).  This way it is also independent from the
icon, which is a big plus.

>>>     1.3. Default item temporary may be marked by '*' as firsr character
>>> of a
>>> label. This '*' is not displayed. This possibility can be removed after
>>> Obmenu will support the menu with default.
>>
>> I really don't want to do it this way.
>
>     OK. '*' removed.
>
>>>     1.3. New menu property "has_default" added. It may be used for
>>> pipe-menus, f.e.<menu has_default="true" execute="my_script"
>>> id="my_script"
>>> label="my pipe menu"/>. If the menu has this property, then its row in
>>> the
>>> parent menu will be marked with the symbol of a menu with default.
>>
>> This is messy because it depends on the user to know details about the
>> pipe menu when adding it to their menus.  The pipe menu should dictate
>> this stuff itself.
>
>     May be... Now I removed this possibility. The issue can be revisited in
> the future.
>
>>>     I don't send this patch to the Bugzilla because I don't understand
>>> what
>>> I need to do with internationalization. There are two new
>>> internationalizable strings ("_Activate" and "_Kill") and several strings
>>
>> The Close action already allows for killing when the application isn't
>> responding.  So I think that adding another option for killing
>> clutters the interface and can lead to a lot of lost work by
>> accidental clicks that bypass any save dialogs etc.  So I don't think
>> the kill option needs to be in the menu.
>
>     OK. "Kill" removed.
>
>> Some style things with the patch.  Variable declarations should always
>> be at the top of the code block.  For example, at line 340 of the
>> diff.  They are usually followed by a blank line.
>
>     Fixed.
>>
>> The ACTIONS_TAG and SEND_TO_TAG seem like hidden tricks that will hurt
>> to trip over in the future.  Why are you using those?  It seems like
>
>> you're making a new menu for each client in the menu, making it tricky
>> to tell if the client menu is showing.
>    You are right. I have removed such use. Now these tags are used only for
> preventing intersection with user defined menus.
>    May be better to place the definition of these tag characters in the
> menu.h, to facilitate the safely addition of other internal nonprintable
> characters in the future?
>
>> Why not use a single menu for
>> all the clients, then attach it as a submenu for all of the clients.
>
>     It is with this that I began to. Alas, it's not so simple. Submenus for
> differ clients has differ titles; submenus for clients of the current
> desktop have not the default for its "send to" submenu, but the submenus for
> clients of other desktops have the default (send here).
>     I am not able to overcome the problems associated with using a single
> submenu for all clients. A program with a separate submenu for eaach client
> get simpler and clearly.
>     Compare this with the released client_list_menu.c, where each desktop
> have it's own submenu ("desktop_menus" variable etc.).
>     About the use of memory, maximum use is determined by the maximum number
> of clients, and there is no memory leaks. Average use can be reduced by
> destroying all the submenus when the main menu be closed. I thought it would
> be an unnecessary complication of the program. But if You think that's
> better, I can add releasing of all the created submenus.
>
>     In addition to the above, I made another small change about the "Send
> to" action when the Ctrl key pressed.
>
>     Revised patch is attached (gzipped due to the size limitation).
>     Thank You for Your advices.
>
> Yours truly Alexey

Cheers,
Dana

>
>
> _______________________________________________
> openbox mailing list
> openbox at icculus.org
> http://icculus.org/mailman/listinfo/openbox
>
>