???

???

Yes... looks like we don't yet handle a title before the first item. I had something similar happen. Not investigated yet.

I put a separator with label part way down the menu and it does something similar to the above
the separator label is highlighted, and it's the right width but the rest of the menu both above and below
do not pick up the width from the label, so still the same width as the normal items.

Edit to add: never mind on the above, I had forgotten to adjust the menu max width in the theme
separator with label still acts funny, acts as if separate menu or it forgets it has a separator label and item starts new.

Finally figured out what was going on. The separator_create needed to have menu->item_height set because it
was 0 for the 1st entry.

I feel like we should also add a font face for headers so users can for example make headers bold / italic use a smaller or bigger fonts size compared to the other menu items.

We don't handle a pipemenu without a parent (well technically the parent is "openbox_menu", not "current_menu".)
But a pipemenu without a parent should be similar to setting up root-menu/client-menu.

So, I'm thinking of copying init_rootmenu, adding another parm ie title, where the title matches the id= from
the pipemenu definition, and setting up a new menu.

Does this sound like the direction to go?

I feel like we should also add a font face for headers so users can for example make headers bold / italic use a smaller or bigger fonts size compared to the other menu items.

Yes, good point. Will do.

I'll probably leave this though until we're on 0.18

Ok, got pipemenus straightened out. Leaving out angle brackets (does funny formatting)

• This works
  openbox_menu
  ...
  menu id="test-menu" label="TestMenu"
  __menu id="date-menu" label="cal" execute="/home/don/bin/date-menu.sh"

• This works also
  openbox_menu
  __menu id="date-menu" label="cal" execute="/home/don/bin/date-menu.sh"
  ,,,
  menu id="test-menu" label="TestMenu"
  menu id="date-menu"
  /menu

Either way shows the pipe menu

Ok, so far, I have pipemenus working, both with and without parent
also have x,y menu placement (similar to openbox) as well as original atCursor y/n

I have started working on client-list-menu.

Edit to add: 07/31 have added client-list-combined-menu and client-send-to-menu

Looking at what you referenced in OP about theme elements, I have these mentioned in many of my
openbox themes, we might want to add some of them when work is done in that area.

I don't think we address them at this time, the font and text color for title and menu would be useful.
!! menu title
menu.title.bg:
menu.title.bg.color:
menu.title.text.color:
menu.title.text.font:
menu.title.text.justify:
menu.border.width:
menu.border.color:
!! menu items
menu.items.bg:
menu.items.font:
menu.items.justify:
menu.items.disabled.text.color:
menu.items.active.bg:

ETA2: added entry for MenuHeader (font),
added menu.title.text.color
added oblique to slant.

So with this, my separator labels are sligthly larger than items, bg blue, fg yellow with an oblique slant.

ETA3: center justification to separator label

From the todo list only menu.title.bg.border.color is not done, as I didn't venture into the border area.
I've documented the stuff I added but not sure if it's enough, when you review my code you can check that out.

Only thing wrong with this code is it needs to pass code check, scripts/check will point that out.
You don't handle the first title properly, but my first set of menu changes takes care of that.

If you make many more changes than what you have already,
then let me know, so I can rebase/readjust/add/remove.

src/menu/menu.c:281: ERROR: space required before the open brace '{'

I feel like we should also add a font face for headers so users can for example make headers bold / italic use a smaller or bigger fonts size compared to the other menu items.

@droc12345 is adding that in a subsequent commit

Ready for review from my perspective.
All comments so far addressed.
I fixed the item-height problem when a title is the first item by simply removing it from the menu struct and making it part of the "global" theme struct instead - which I think is a more correct solution anyway.

Something weird going with on with the Void check which feel like it could be related to the patch.

Not sure what's going on with void. I used your current code as a base and void didn't complain, compiled fine.

I looked at the output log, but didn't see anything that stood out. and it took 3 minutes, so maybe it was
something to do with their container stuff. ???
I just checked with my additions it only took 2 min for the void compile.

Edit to add: After I made this comment, I started thinking that I had had a problem with void early on.
I believe that it has something to do with void not having a menu.xml file and there is a separator
with a blank label in the init_windowmenu, and the separator code doesn't distinguish that properly.

I had to add a fix in the separator to recognize the label being blank ie "", and make it a separator line
not a label. That's probably what''s biting you.

As I say, my changes will fix that. So don't worry about it.

On Void it compiles fine, but the smoke test fails and the gdb stack-trace points to code in the PR. So doesn't feel right to ignore without investigating.

So here goes the investigation:

1. In scaled-font-buffer.c _create_buffer() we don't initialize buffer to NULL.
2. ...which becomes a problem because in font_buffer_create() we bail out on string_null_or_empty()
3. ...whereas in menu.c separator_create() we only NULL-check label.
4. ...and of course in in init_windowmenu() we call separator_create() with label="". Boom.

So that buffer was pointed to garbage on Void (guess on Arch/FreeBSD CI we were just lucky and it pointed to a block of zeroed memory).

Hooray for smoke test.

Right, will sort some patches later.

On my end, I just made sure never to send a "" label, as it didn't parse well.
Inside separator_create, it make a decision on label being null, but sending "" to some font mechanism is wrong.

How does one do anything to a zero length string?
So I just converted "" to a separator line, and if someone wants a blank title size line use " "

Have force pushed with fixes for the Void-smoke-test-failure. Also added documentation.
It feels like this needs a review from scratch some testing.

LGTM

Thanks.

@droc12345
It's ready for your follow PRs now.
I'll try not to touch menu.c for a while 😄