[openbox] client list with submenus

Alexey Korop akorop at gmail.com
Wed Jan 5 11:29:03 EST 2011


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?

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: openbox-cl-list-menu1.patch.gz
Type: application/gzip
Size: 11726 bytes
Desc: not available
URL: <http://icculus.org/pipermail/openbox/attachments/20110105/eb8955fe/attachment-0001.bin>


More information about the openbox mailing list