[feature] - Only show title if window is maximized

[Sporif]

Would it be possible to add this option? applet-window-buttons has this, so it would be great if this applet could do the same.

[psifidotos]

makes sense, it would give the user the sense that the window titlebar is moved to the top panel...

[cyclinggeorgian]

just came here to ask for it... applet window buttons supports this feature, would be great to get it here to.

[psifidotos]

can be someone what will happen with Window AppMenu integration if the user enables that option?

The Window AppMenu integration[Unity workflow] means that the appmenu is hidden, until the window title is hidden ... From my understanding if such option is provided and the user chooses it then the AppMenu integration should be disabled.

Do you agree?

[LazyGeniusMan]

Hi

can be someone what will happen with Window AppMenu integration if the user enables that option?

The Window AppMenu integration[Unity workflow] means that the appmenu is hidden, until the window title is hidden ... From my understanding if such option is provided and the user chooses it then the AppMenu integration should be disabled.

Do you agree?

Hi, I build Window AppMenu (git) from AUR, i don't really understand Window AppMenu integration, which setting should i check ? i can't find it.

+1 for this feature request, when window is not maximized and default Title Bar is shown I think it's kind of redundant to show two Title Bar.

[lyndhurst]

This feature would be great.

[trmdi]

This also need to keep the title of the last maximized window, no matter if it is active or not.

[psifidotos]

This is the case because you use appmemu in the window titlebar. Users that are using appmemu in the window titlebar are too few in order to implement only a Latte specific solution that will work only for them with no any other benefits of all the rest.

[trmdi]

This is the case because you use appmemu in the window titlebar. Users that are using appmemu in the window titlebar are too few in order to implement only a Latte specific solution that will work only for them with no any other benefits of all the rest.

You can ignore the appmenu in the screenshot.

[psifidotos]

This is the case because you use appmemu in the window titlebar. Users that are using appmemu in the window titlebar are too few in order to implement only a Latte specific solution that will work only for them with no any other benefits of all the rest.

You can ignore the appmenu in the screenshot.

It is not the only argument. I had implemented it in the past, in the end from user point of view it was not worling properly. Introduce last maximized window will need:

1. Latte implementation to support it like the last active window one
2. Someone that will take responsibility for that implementation and maintain it for the future
3. New Latte options in order to support it for dragging and maximize / restore through top panel
4. Update all three windows family applets to support it
5. All above will fail if the user has added appmenu in top panel because the user will lose appmenu for current active window and will not be available and only solution would be to use a decoration with that ability like yours
6. Dragging from top panel should work for last maximized window and not the active window and from user point of view I couldnt stand it, it was getting in the way all the time. I was trying to move active window and instead of that I was moving a window below the active one.
7. Window Buttons inactive state fail their drawing for some specific decorations, with the responsibility from the decorations implementation

In screenshots it looks ok but when the real user workflow is examined it fails. So my perspective if that I will follow that road only if the entire user workflow is examined, screenshoted and described and in the end it makes sense.

[trmdi]

This is the case because you use appmemu in the window titlebar. Users that are using appmemu in the window titlebar are too few in order to implement only a Latte specific solution that will work only for them with no any other benefits of all the rest.

You can ignore the appmenu in the screenshot.

It is not the only argument. I had implemented it in the past, in the end from user point of view it was not worling properly. Introduce last maximized window will need:

1. Latte implementation to support it like the last active window one

2. Someone that will take responsibility for that implementation and maintain it for the future

3. New Latte options in order to support it for dragging and maximize / restore through top panel

4. Update all three windows family applets to support it

5. All above will fail if the user has added appmenu in top panel because the user will lose appmenu for current active window and will not be available and only solution would be to use a decoration with that ability like yours

6. Dragging from top panel should work for last maximized window and not the active window and from user point of view I couldnt stand it, it was getting in the way all the time. I was trying to move active window and instead of that I was moving a window below the active one.

7. Window Buttons inactive state fail their drawing for some specific decorations, with the responsibility from the decorations implementation

In screenshots it looks ok but when the real user workflow is examined it fails. So my perspective if that I will follow that road only if the entire user workflow is examined, screenshoted and described and in the end it makes sense.

Can't these issues be solved by simply activating that window when the user clicks on the Latte panel?

5. All above will fail if the user has added appmenu in top panel because the user will lose appmenu for current active window and will not be available and only solution would be to use a decoration with that ability like yours

This feature only works when the user chooses the filter "Only for Maximized windows"

[psifidotos]

This is the case because you use appmemu in the window titlebar. Users that are using appmemu in the window titlebar are too few in order to implement only a Latte specific solution that will work only for them with no any other benefits of all the rest.

You can ignore the appmenu in the screenshot.

It is not the only argument. I had implemented it in the past, in the end from user point of view it was not worling properly. Introduce last maximized window will need:

1. Latte implementation to support it like the last active window one

2. Someone that will take responsibility for that implementation and maintain it for the future

3. New Latte options in order to support it for dragging and maximize / restore through top panel

4. Update all three windows family applets to support it

5. All above will fail if the user has added appmenu in top panel because the user will lose appmenu for current active window and will not be available and only solution would be to use a decoration with that ability like yours

6. Dragging from top panel should work for last maximized window and not the active window and from user point of view I couldnt stand it, it was getting in the way all the time. I was trying to move active window and instead of that I was moving a window below the active one.

7. Window Buttons inactive state fail their drawing for some specific decorations, with the responsibility from the decorations implementation

In screenshots it looks ok but when the real user workflow is examined it fails. So my perspective if that I will follow that road only if the entire user workflow is examined, screenshoted and described and in the end it makes sense.

Can't these issues be solved by simply activating that window when the user clicks on the Latte panel?

of course not. The moment you will activate the last maximized window and start dragging it , it wont be maximized any more so the applets will not show anything. This is not only case of failing... Again, screenshots, user workflow how things will behave etc.etc. and afterwards someone to take responsibility for everything related.

[trmdi]

The moment you will activate the last maximized window and start dragging it , it wont be maximized any more so the applets will not show anything.

It's ok because we're talking about a feature when the user chooses the filter "Only for Maximized windows". It mean he doesn't need the menu for unmaximized ones.

This is not only case of failing...

I will think more about it.

[haizaar]

I as well would like to have an option for "title/buttons of the last maximized window"
I understand it's a highly personal preference that will not work for everyone but for some it will make a perfect sense.
I personally almost never use app-menu so for me it would be enough to just have both panel title and button to correspond to the last maximized window.

For me the current behavior of, e.g. Konsole having a Chrome title and icon is really confusing.

Eventually I resorted to the old "application window control" 3-in-1 applet with "buttons on maximize & active only" and "no title" - this way I only see buttons only when window is active & maximized; and since this is 3-in-1 control it can still take all the space pushing the system tray to the right. So basically it only leaves me with the working buttons. The problem is that this unmaintained applet can stop working any time and this is why it will be great to have a proper support in latte tech stack.

Can you please at least allow hiding both text and icon ?

[Everest10]

I would like to request that you be included in the Window Title Widget an option to show the window title only if the window is maximized. If the window is not maximized the Application title widget stays hidden.

Follow the screenshot link https://imgur.com/WIQQ0zn

Best Regards,

[Everest10]

This is the case because you use appmemu in the window titlebar. Users that are using appmemu in the window titlebar are too few in order to implement only a Latte specific solution that will work only for them with no any other benefits of all the rest.

You can ignore the appmenu in the screenshot.

It is not the only argument. I had implemented it in the past, in the end from user point of view it was not worling properly. Introduce last maximized window will need:

1. Latte implementation to support it like the last active window one

2. Someone that will take responsibility for that implementation and maintain it for the future

3. New Latte options in order to support it for dragging and maximize / restore through top panel

4. Update all three windows family applets to support it

5. All above will fail if the user has added appmenu in top panel because the user will lose appmenu for current active window and will not be available and only solution would be to use a decoration with that ability like yours

6. Dragging from top panel should work for last maximized window and not the active window and from user point of view I couldnt stand it, it was getting in the way all the time. I was trying to move active window and instead of that I was moving a window below the active one.

7. Window Buttons inactive state fail their drawing for some specific decorations, with the responsibility from the decorations implementation

In screenshots it looks ok but when the real user workflow is examined it fails. So my perspective if that I will follow that road only if the entire user workflow is examined, screenshoted and described and in the end it makes sense.

Can't these issues be solved by simply activating that window when the user clicks on the Latte panel?

of course not. The moment you will activate the last maximized window and start dragging it , it wont be maximized any more so the applets will not show anything. This is not only case of failing... Again, screenshots, user workflow how things will behave etc.etc. and afterwards someone to take responsibility for everything related.

did you have the ability to create the widget and can't just hide the label when the window isn't maximized ??? Ridiculous and Inexplicable !!

[psifidotos]

So you didnt like my explanation. Look how ridiculous it is. Because this is my project I can even choose to never implement that request for the simple reason that this is my preference. You on the other hand ungrateful @Everest10 feel free to fork the project, provide whatever you want and take also responsibility to maintain your fork for your base.

[haizaar]

@psifidotos I'm sorry to see the conversation with Everest10 went emotional.
I'm sure others from this thread will join me in expressing how much we appreciate all the work you've done on this project.

I understand you position regarding the matter but can we at least keep this open - there is quite a lot of feedback collected here and leaving it open will encourage ppl to contribute more feedback. Thanks again.

[felagund]

I think the setup requested here would exactly mimick how Unity 7 used to work.

1. Latte implementation to support it like the last active window one
2. Someone that will take responsibility for that implementation and maintain it for the future
3. New Latte options in order to support it for dragging and maximize / restore through top panel
4. Update all three windows family applets to support it
   I think you plan this here: [feature] - common visibility interface for all Window applets applet-window-appmenu#99 ). I personally see there three applets as basically interlink and the advantage to them being separate is that you can rearrange them and possible not use some of them. But I find it hard to think of a scenariou where you would want their visibility settings to be different from each other.

5. All above will fail if the user has added appmenu in top panel because the user will lose appmenu for current active window and will not be available and only solution would be to use a decoration with that ability like yours

I think the whole workflow assumes menu in unmaximized windows, possible locally integrated menus (LIMú: https://www.reddit.com/r/kde/comments/p6vqoa/breeze_locally_integrated_menu_support_beta/
and it also assumes dissapearing window decorations as done here:
https://www.reddit.com/r/kde/comments/6b6793/how_do_i_hide_window_decorations_of_maximized/

I am not sure if there is a wayhow to force these (one is Kwin setting, I guess LIM are also implementedi n Kwin?), but in my ideal world, this is exactly what I would get when I select the "unity 7" layout in Latte.

6. Dragging from top panel should work for last maximized window and not the active window and from user point of view I couldnt stand it, it was getting in the way all the time. I was trying to move active window and instead of that I was moving a window below the active one.

Are you talking about two maximized windows on top of each other and you dragging the one below? That is of course something that should not happen. Or are you talking about a situation where there was an unmaximized windows and you tried to drag it using the top panel instead of the window decorations of the unmaximized windows? That sounds more like a habit to me. In the use-case requested here, the top bar should behave as much as possible as window decoration of the maximized window.

7. Window Buttons inactive state fail their drawing for some specific decorations, with the responsibility from the decorations implementation

I do not understand what you meant here at all:-).

UPDATE: The other two applets can already behave this way (hidden unless a window is maximized), so I am not sure how this is different?

[felagund]

By the way, this issue evolved from the original one starting with this comment: #33 (comment)

1. The original demand was if the applet can be shown only with maximized windows and it seems to be unproblematic, it would mirror the options of the button and menu applets, received 9 likes and there is an unfinished imlpementation here: Add "Show Information only for Maximized Windows" #106

2. The new demand was for the applet (and I guess the same would then be needed for the buttons and appmenu applets too) to be also shown for a maximized window that is partially overlayed by unmaximized window.

Not sure if github issues allow meaningful splitting.

I would actually like both features, but they are different features (both would basically implement how Unity 7 used to behave).

[Akselmo]

Hi, is this issue being worked on anymore? I would also like to hide the window title when the app is not maximized.

[amorozov]

I have read through the conversation and it looks like so far nobody clearly defined the use case for which this feature request is needed. Let me try to fill the gap.

By using these three applets I try to mimic Unity7 behavior. And I do it for a reason: preserve precious vertical space (on small displays). To achieve this goal,

1. the task bar / launcher is kept hidden most of the time (available on demand by mouse move to a screen edge/corner).
2. the appmenu is moved out of the window
3. the (upper) panel is kept narrow and contains only important information that needs to be accessible at a glance: current time, messages. maybe brief CPU load info etc, nothing more.

At the same time all these status elements: the notification area, wall clocks, load info etc, — are compact enough and there's plenty of space that remains unused in the panel. And here come the window buttons/title/menu applets: they can make the upper panel a substitution for a window decorations altogether. That is for a maximized window we can hide the real window decorations and put everything from the window title to the upper panel. So far, so good.

On the other hand, a non-maximized window already has those things: control buttons, title, menu and/or even all that fancy stuff that modern GNOME applications provide through the CSD. It can be (almost safely) stated that there's no need for repeating the window decoration stuff in the upper panel as the window already has it.

That's the reason why this request has appeared: users consider the upper panel as a pseudo-window title and ask to track there a visible maximized window even if it's not the front window. Not a non-maximized front window. As a minimal task they ask to hide window stuff from the panel completely when the window is not maximized because in this case they already have the stuff in the window decoration.

There's another consideration, by the way. In real life horizontal space is also precious resource, For example, many IDEs, terminals and alike put file names into titles. This makes titles really wide, and there's no space left for e.g. a window menu. Here comes another trick from Unity7 approach. They stated that users need to have appmenus visible only when they asked for, particularly by moving their mouses close to the menu area. At the same time menu title is likely known at this moment and that's why the window title can be completely hidden while the user operates with the menu. This consideration is applicable to global menu/title and the menu/title in the window decorations.

Hopefully I have described the rational behind the feature request.

[linusrg1]

I have read through the conversation and it looks like so far nobody clearly defined the use case for which this feature request is needed. Let me try to fill the gap.

By using these three applets I try to mimic Unity7 behavior. And I do it for a reason: preserve precious vertical space (on small displays). To achieve this goal,

1. the task bar / launcher is kept hidden most of the time (available on demand by mouse move to a screen edge/corner).
2. the appmenu is moved out of the window
3. the (upper) panel is kept narrow and contains only important information that needs to be accessible at a glance: current time, messages. maybe brief CPU load info etc, nothing more.

At the same time all these status elements: the notification area, wall clocks, load info etc, — are compact enough and there's plenty of space that remains unused in the panel. And here come the window buttons/title/menu applets: they can make the upper panel a substitution for a window decorations altogether. That is for a maximized window we can hide the real window decorations and put everything from the window title to the upper panel. So far, so good.

On the other hand, a non-maximized window already has those things: control buttons, title, menu and/or even all that fancy stuff that modern GNOME applications provide through the CSD. It can be (almost safely) stated that there's no need for repeating the window decoration stuff in the upper panel as the window already has it.

That's the reason why this request has appeared: users consider the upper panel as a pseudo-window title and ask to track there a visible maximized window even if it's not the front window. Not a non-maximized front window. As a minimal task they ask to hide window stuff from the panel completely when the window is not maximized because in this case they already have the stuff in the window decoration.

There's another consideration, by the way. In real life horizontal space is also precious resource, For example, many IDEs, terminals and alike put file names into titles. This makes titles really wide, and there's no space left for e.g. a window menu. Here comes another trick from Unity7 approach. They stated that users need to have appmenus visible only when they asked for, particularly by moving their mouses close to the menu area. At the same time menu title is likely known at this moment and that's why the window title can be completely hidden while the user operates with the menu. This consideration is applicable to global menu/title and the menu/title in the window decorations.

Hopefully I have described the rational behind the feature request.

There are some things I would like to add to this. I also use a setup like the one explained here, but I instead have the application menu in the panel at all times. It would be nice if there was an option that made the app menu widget visible and hid the title bar widget when the current active window isn't maximized, and then when the window is maximized the title bar widget gets enabled, and the app menu becomes hidden behind the title bar.