Combine Maximize and Fullscreen
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
- Started by
- Completed by
- Danielle Foré
Related branches
Related bugs
Sprints
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/
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-
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://
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/
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(Fullscree
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:/
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:/
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.