Creating submenus in TC2.0RC4

[bmarkus]

I have two applications, xwota and xdx, both for Ham Radio use. I wanted to add them to the JWM Menu in a common submenu called HAM Radio. How to do that? If I define the HAM Radio submenu as below and install both packages there are two submenus with the same title containing one of the programs each:

<JWM>
<Menu label="HAM Radio">
<Program label="xwota">/usr/local/bin/xwota</Program>
</Menu>
</JWM>

<JWM>
<Menu label="HAM Radio">
<Program label="xdx">/usr/local/bin/xdx</Program>
</Menu>
</JWM>

Is there a tool to add <Program label... item on the fly to a Menu which can be called during the installation to get this below or any other way?

<JWM>
<Menu label="HAM Radio">
<Program label="xwota">/usr/local/bin/xwota</Program>
<Program label="xdx">/usr/local/bin/xdx</Program>
</Menu>
</JWM>

Béla

[robc]

you could write a startup script for the extensions that look in the menu file to see if the Ham Radio submenu is present.

Though, I think this could be very useful if supported on a more universal level in TC. Having the ability to create submenus within the desktop menu only makes sense with our growing extension repository. The word processing and other office tools could go into one submenu, games in their submenu, file managers in a different submenu, etc.

[bmarkus]

OK, I'm just writing a shell script to dynamically create the submenu definition file and can add items when extension installed.

[roberts]

If not for personal use then a public submittal would need to support the other window manages currently supported.

[robc]

If not for personal use then a public submittal would need to support the other window manages currently supported.

that is true, not everyone will be using jwm.
I do like the idea of keeping similar applications together. perhaps restructuring the layout of the extension menu files to something a bit more universal and simpler, kinda similar to the extension icon files. for example:

Code: [Select]

submenu: Office Utils
name: beaver
exec: /usr/local/bin/beaverfor TC 2.X each window manager should have the interface files to use this info for the menu system. This way it would be up to the owner of the window manger extension to create the interface files correctly. It is looking more and more like microcore is going to be the base system and jwm and the Xlibs will just be extensions. So why not treat the jwm extension like any other window manager extension?

[roberts]

It would be nice to have such a specification for menus.

However, we have hundreds, namely 532 existing tces and 504 existing tcz, already with the JWM XML menu specification. All these extensions for v2.0 and v2.0 is not even final yet!

It would be quite an undertaking to unpack, adjust, and repack all those extensions for the new menu specification.

Plus it would mean a delay to release 2.0 final. 
If it were to be considered, a major change, such as v2.0 would be the time for such a change.

[bmarkus]

Hi,

there is www.freedesktop.org :

freedesktop.org is open source / open discussion software projects working on interoperability and shared technology for X Window System desktops. The most famous X desktops are GNOME and KDE, but developers working on any Linux/UNIX GUI technology are welcome to participate.

freedesktop.org is building a base platform for desktop software on Linux and UNIX. The elements of this platform have become the backend for higher-level application-visible APIs such as Qt, GTK+, XUL, VCL, WINE, GNOME, and KDE. The base platform is both software and standards.

One of their standard is for menus:

http://www.freedesktop.org/wiki/Specifications/menu-spec

It is followed by KDE, xfce and others but not by JWM

My script to manage the menu in JWM now works. After some testing I will publish in a separate topic to discuss. For sure other WM's can be supported too.

But the best would be to use freedesktop structure and then convert it to the appropriate native format of the used WM.

BTW, which other WM's must be considered with TC 2.0?

[roberts]

And not flwm, or many of the other "small is beautiful" window managers.
Besides to implement would likely add much bulk compared to existing busybox's awk applet currently being used.

[bmarkus]

And not flwm, or many of the other "small is beautiful" window managers.
Besides to implement would likely add much bulk compared to existing busybox's awk applet currently being used.

It's clear. On the other hand it means that all tiny WM has its own menu definition method. An extension maker can't support all when creating tce/tcz, the OS has to offer a mechanism.

What happenes if a WM installed fom tce/tcz after the extensiion installed, who will create the menu defs for already installed apps?

[roberts]

The default mode for TC is that apps (extenions) are either mounted or loaded upon boot from tce directory, therefore the menu for such is dynamically generated. I already have dynamic menu via standardized calls to interface files supporting TC extension menus for flwm and hackedbox. I believe winmdow maker is also now available. If you choose any of these alternate window managers you still have your application extension menu. That was a major improvement for v2.0.

If you choose to use persistent local, then by your choice you have decided not to be dynamic.So YMMV. I don't promote persistence and have been promoting pristine boot with dynamic extensions for over five years now..

[robc]

Perhaps a better way to implement this for TC 2.X is to have the WM menu interface files create the submenus. The current JWM menu specs can still be used with the <Menu label="XXXXXX"> tags. This way not all of the extensions would have to be repacked, just the window managers with the updated interface files. Though this would also require JWM to be updated which could delay the next release.

This could also wait until the next major release since its more cosmetic then functional.

[bmarkus]

This could also wait until the next major release since its more cosmetic then functional.

Well, I agree that there are higher priorities and things to be fixed. However I woudn't call it cosmetic. It will become functional when 'real' applications added to the core.

[jpeters]

Perhaps a better way to implement this for TC 2.X is to have the WM menu interface files create the submenus.

I remember doing that with DSL for ICEWM from Fluxbox when the submenus weren't working.  

[bmarkus]

Thinking it over I decided not to use my script to create submenus for compatibility and maintanence reasons but will wait for official solution. Till it happenes will not use submenus.

Béla

[Jason W]

I do like the idea of submenus, given the ever growing extension collection.  But I also first cringed at the thought of retooling all the existing extensions to support a new menu file format, that does not have to be done.  And also after retooling all the extensions, what if that format was not ideal and needed to be altered?  The existing JWM menu spec allows for submenus within an extension already, and many have those.  A new menu file format to allow the same submenus within an extension while adding the new general submenu parameter would not necessarily be any simpler to use then using the existing JWM menu spec to do the same.  The awk script to make other menus from the JWM spec can be fairly simply tweaked to accomodate other WM's.
The beauty of WM's now being an extension means that desired functionality can be worked into the extension itself rather than changing the existing extension menu format.  We can come up with a few general submenu titles and use those titles in the WM_makemenu script to create the submenu categories for extensions that support it.  Here is an example menu file that could do that:

Code: [Select]

Submenu: "HAM Radio"
<JWM>
<Menu label="somemenuname">
<Program label="xwota">/usr/local/bin/xwota</Program>
<Program label="xdx">/usr/local/bin/xdx</Program>
</Menu>
</JWM>

This could be used to create a Ham Radio submenu section, add a "somemenuname" with xdx and xwota as its submenus under the Ham Radio category.
The WM_makemenu could look for a few defined submenu titles, create that in the resulting menu, and add any extensions with that submenu title into that area of the menu.  Any other extensions installed after that that are in the Ham Radio category would be added under that submenu.  I may do this with Windowmaker soon to provide an example.

We would just need to decide on a few submenu categories, and more could be added later.  Of course, this method would only create submenus for extensions that support them.  Even right before release, we had to change the name of all the library extensions and that was when we had maybe around 100 extensions.  That was a headache, and it was only changing the name and related md5 and info file entries and not repacking.  I prefer change by attrition when possible, in this case the submenu being added when extensions are new or updated, replacing the old ones in time.  

I will also add a "wmaker_setup" utility that will allow for use of Windowmaker simply by loading the extension and running that utility, even if another WM is in use. Or it could fuction to rebuild the menu in the case of a tampered with menu or after uninstalling an extension.  Exiting to a prompt and startx would put you in Windowmaker then and also setup it's menu.  All the functions to make that happen already exist, but a simple setup script would allow changing WM's in mid stream.

EDIT:  On closer look this would require a change to the JWM makemenu function though Hackedbox should remain unaffected.  Let me try this out on Windowmaker, and don't submit any extensions with this kind of thing at this point.