Thanks for taking the time to think about this.

The number of settings (and their inconsistencies) are actually a big pain of this project. I'd like to rework it from the ground up. So if I may, I'd like to postpone your patch. When I'm finished with the planned rework I'll definitely add your use-case into account.

I'd actually like to present my point of view here so we can discuss if it is a good idea or not:

I'm proposing to have a bunch of standalone items with some common placement settings. The items are:

• icon
• text
• window buttons
• appmenu

Mentioned items would be placeable by drag-drop in settings like window buttons are already.

Each item would have following settings in common:

• occupying | floating
• horizontal alignment: left | right

Window text and appmenu would additionally have:

• fill width
• fill height (default: true)

Appmenu and buttons would additionaly have:

• height
• vertical alignment: top | bottom | center
• hide on mouse out

Of course there will still be specific settings for the items like window title eliding etc.

I also plan to create some presets like:

1. Unity (Ubuntu style)
2. Thick (thick panel with floating and disappearing menu and buttons over icon and title)
3. One Liner (from the left: buttons, icon, window text, appmenu)

Any opinions are appreciated :).

The patch definitely can wait until you finish the rework. A few thoughts that crossed my mind when reading proposed changes:

• I really like the standalone basic items placed by drag and drop.
• Is floating really floating or just another layer of occupying? E.g. thick panel and on bottom appmenu (on left) and buttons (on right) (floating because they are over window label -- or this option going away?): would the appmenu elide [1] or be drawn over the buttons? (Note: I'm not saying this should be a supported use-case, just playing with possible setups in my mind and the floating is really floating would be much easier to implement.)
• To support my use-case #2 all items should have
  • show on: mouse out | mouse in | always (and possibly never show unless it is covered by other options, show on mouse out not available for buttons and appmenu)
  • checkbox to restrict mouse area used by "show on" option only to rect occupied by given item (for the in-parenthesis part of use-case #2)
• Some predefined presents are a great idea -- do you intent to support saving current setup as a present?
• All around the rework looks like a big improvement.

The use-cases I am most interested in are:

• One Liner with buttons on right
• The previous one but with appmenu shown only on mouse-in and window text only on mouse-out (and preferably the mouse events should be restricted to area between icon and buttons -- i.e. if i click buttons window text is shown). This is better than One Liner setups for small screens.

[1] I think this is an important feature, I tried implementing it in D11073. I must say I am surprised that there is no ElidingGridLayout or something -- the patch tries to emulate it, but without touching internal positioning code of the layout it will always be a hack... (Also why is the backend plugin private?)

active window control is a 3rd party plasmoid, right?

Sorry for being dark for so long, Radek. I was busy and I hope it will get better. Thanks a lot for your ideas.

Is floating really floating or just another layer of occupying?

You are right, it should be another level of occupying. I haven't thought that one through enough.

show on: mouse out | mouse in | always (and possibly never show unless it is covered by other options, show on mouse out not available for buttons and appmenu)

This one I don't fully understand. Why show on: mouse_out|mouse_in for all items is not enough to satisfy all scenarios?

checkbox to restrict mouse area used by "show on" option only to rect occupied by given item

Good idea!

Some predefined presents are a great idea -- do you intent to support saving current setup as a present?

Ideally yes along with export/import presets.

I think this is an important feature, I tried implementing it in D11073.

I can see you put a lot of work into it and I still have it in mind. Thanks! I intend to review and accept it soon.

Also why is the backend plugin private?

The backend plugin was basically copied from existing Global Menu plasmoid - that was also a private plugin. I think the Global Menu one should one day be public so it can be used by other widgets.

active window control is a 3rd party plasmoid, right?

@mart: yes, it is. I intended to request addition of this widget to kdeplasma-addons once these usability issues are resolved.

show on: mouse out | mouse in | always (and possibly never show unless it is covered by other options, show on mouse out not available for buttons and appmenu)

This one I don't fully understand. Why show on: mouse_out|mouse_in for all items is not enough to satisfy all scenarios?

They are if you think about them as two checkboxes, I thought about it as single combobox...

Hello after some time. I finally manage to more or less finish the layout rework I was planning. I tried to work in most of what we discussed here.

@Pitel Radek, if You have some time, can You please check out layout-rework branch and try if You manage to set up your desired configuration? And of course if you see any issues, please let me know of them and I'll do my best to fix them.

In Layout configuration section there is also a facility to upload/download custom configuration JSON to ease up config exchanges between users (and devs for bug-reports:) ). Known issue/feature of this facility is that the JSON does not cover all possible config properties. Just the ones related to layout (although some of the supported properties are from config sections different from layout section).

I'm also open to tuning up existing hard-coded config profiles, and adding new if it makes sense.

@martinkostolny I will try to give it some testing this week.