Combine Maximize and Fullscreen

Registered by Cassidy James Blaede on 2011-09-09

1. Maximize and fullscreen are redundant (both aim to serve the purpose of maximizing the real estate for the app). This simplifies things by making them one and the same and helps provide fullscreen to any app that supports maximizing.

2. Give the panel hide-on-maximize. This behavioral consistency is relatively easy and would help achieve that maximization of screen real estate.

3. Maximized apps would retain their titlebar by default, meaning it'd be both touch-friendly and old-person friendly since there would still be a visual way to close or un-maximize the app.

4. App developers would be encouraged to think of how to better use their apps real estate when maximized (like Postler did back in the day).

5. We could provide a nice auto-hiding overlay titlebar widget (like in Audience mockups) for media apps so that they could show this when maximized; this way even if they choose to do a true fullscreen like Audience, the UI would be consistent between apps. Moving a mouse or tapping a finger would reveal it, like many fullscreen UIs on desktops and mobile.

6. This could allow us to do some nice behaviors that Dan has previously suggested like giving maximized apps their own workspace by default.

Blueprint information

Status:
Complete
Approver:
elementary core
Priority:
Medium
Drafter:
None
Direction:
Approved
Assignee:
None
Definition:
Obsolete
Series goal:
None
Implementation:
Not started
Milestone target:
None
Completed by
Daniel Fore on 2015-11-12

Whiteboard

It would be nice if Wingpanel show up when mouse touches the top of the screen, than drags it down without clicking. ~sal-merone

I agree. It would maximize screen real estate. However, sutff like the time should still be visible. Could wingpanel be embedded into the window frame, even if it's just an overlay with theming?

Or hide the titlebar instead of wingpanel. The titlebar holds almost no information nor functions (title, close, unmaximise) and yet takes a lot of space. These two buttons and the title could easily be moved into wingpanel when maximised.

@sal-merone:
Certainly, if implemented, the wingpanel should appear when the cursor reaches the upper edge, so that the user don't have to click or so, only for taking a peek at the clock, open another app, adjust the volume of playing music, etc.
But even then there is problem: what if the user opens another app that isn't in fullscreen? Does the fullscreen-app stay in background and the wingpanel overlays its title-bar or is the fullscreen-app in background reduced a bit to show the wingpanel without overlaying its title-bar? Maybe it should simply stay like today.
@anonymous:
I think hiding the title-bar and show its elements (title, closing-button, maximize/normal-button) in the wingpanel would be the worst solution. One of the most important usability-principles is consistency. If in normal mode those "title-bar-elements" are in the titlebar and when maximized in the wingpanel that wouldn't be consistend.
If the title-bar really is wasted space, it should be thought if it makes sense to intergrate tabs (in browser, file-manager, multi-document-apps,...) in it (similar to Firefox, Chrome,...).
But in my opinion, keeping it as today would be the most usable way.
~Felix

IMO it is a mistake to see fullscreen and maximise as equivalent. Both allow you increase the screen space given to a window, but fullscreen minimises distractions (better if you want to focus on one task or app), whereas maximise allows you to keep the context of your whole desktop (better if you want to multi-task or use multiple apps). This is the mistake Microsoft made when they removed the start menu. Although the new menu screen provides the same functionality, it removes the user from the context of the desktop, which is disorientating and distracting. A better solution might be adding a "hide" button to wingpanel, to easily enable an autohide mode. Then maximise is per app, but fullscreen is global (or per workspace).
~Nico

I agree with @Nico that there should be a way to toggle between auto-hide and always visible. Sometimes you simply want to be able to glance at the clock to see the time, see if you've got messages on Skype (you might not notice if it's hidden) or something else along those lines.
The only problem with putting such a button on the wingpanel is that there doesn't seem to be any obvious place to put it (at least that I can think of), so I made a quick mockup of a lock icon placed underneath the clock instead.
http://i.imgur.com/1Z5eJgq.png
With this solution, the toggle would be visible while you're hovering the wingpanel, but disappear once you do things elsewhere. Since it extends beneath the wingpanel, it can be very noticable but still being out of the the way most of the time, when it retracts.
~Stefan

I agree with Nico, I run most of my apps maximized, but I don't want to go fullscreen because I like having the clock/indicators always in view and in context.
-Heath

A lot has changed with window decorations since this blueprint was filed. Hiding window controls or the "titlebar" doesn't apply anymore since apps are moving to GtkHeaderBar and apps can control what happens to their own decorations with this Gtk widget. Basically, this blueprint just boils down to adding "hide on maximize" as an option for wingpanel and making this the default behavior. Of course, we still want to be able to change the hide mode for the shell like we already do in Switchboard. --DanRabbit

I know it doesn't actually solves the problem raised but, as a suggestion, thinking about giving both modes in the Maximize Button particularly:
What about adding a modifier(i.e. Super + Left Click) to the maximize button to go fullscreen(hiding the Wingpanel)?
Left Click --> Maximize/Wingpanel is visible.
Super + Left Click --> Fullscreen/Wingpanel is hidden.
Some apps do include a fullscreen button generally in the app's toolbar, and it doesn't make sense with the header-bars design anyway because that would result in 2 identical icons(Fullscreen/Maximize) in the header-bar, basically. But the addition of the modifier would still provide a fullscreen button in the interface. It isn't obvious for the new user but F11 isn't that obvious either anyway.
Obs.: If this suggestion is completely out of the blueprint's scope, but it's considerable and it's better to post as a separated suggestion, let me know. ~Hyuristyle

@Hyuristyle Some people might disagree, but personally I find the maximize button to be pretty much obsolete at this point considering how easy snapping is. It could simply be replaced by a full screen button all together.
If fullscreen windows get sent to their own workspaces (like in the original suggestion), each workspace could then individually be either fullscreen (no wingpanel, single application) or non-fullscreen (wingpanel visible, any number of applications) with the option to maximize windows normally without fullscreen by simply snapping. ~Stefan T

@Stefan T When started using elementary OS, I thought the same while exchanging the maximize button with the minimize button (as missed the latter more often). But after a while, I missed the maximize button as well. Now, I ended up with OS X style having both available. I have no idea why but although I use snapping extremely often to move windows around, I still use those buttons (and I also use double-clicking the header bar).
Instead of combining max and fullscreen, I would rather see combining Wingpanel and the header bar: https://answers.launchpad.net/wingpanel/+question/270949 ~Sven

I immensely enjoyed using super-wingpanel in Luna. It made the titlebar and the wingpanel both accessible at once. Of course, the disadvantage with this might be that very long titles gets shortened by ellipses. But with GTKHeaderBars we could try and wrap the long titles or perhaps even give the user a switchboard option as to whether they want the titles wrapped or shortened by ellipses. ~TC

I was also a huge fan of super-wingpanel, and deeply saddened by its discontinuation. I hope removing the distinction of "maximized" and "fullscreen" is still an active goal for elementary OS; it is one of the reasons I have been working on autohide: https://github.com/elementary/wingpanel/pull/93
My pull request now sports four autohide modes, with two that could satisfy item 2: Dodge (with struts) and Dodge-Float (without struts). ~quequotion

(?)

Work Items

Work items:
Make dock hide when active app is maximized: DONE
Make panel hide when active app is maximized: TODO
Make first-party apps utilize fullscreened windows better: TODO

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.