wingpanel
wingpanel copied to clipboard
Auto-hide wingpanel
Maybe it would be possible to integrate a auto-hide function for the next version of elementary OS ?
Thus the applications could be displayed in full screen mode.
Best regards.
Yeah this is a wonderful idea indeed I was searching for the same and I found this for the time being:
https://github.com/mlibre/hide-wingpanel
I guess instead of waiting for the next version this can be done in an OS update itself.
Thanks. I'll test that as soon as possible. ☺
In fact I had asked on launchpad too.
When I maximize a screen I don't need to look at to the calendar or any indicator.
I need to focus on my work on maximized window. And Wingpanel occupies some place although I maximize a window. Espically this is importan when working on a small screen computer like a laptop.
I hope @danrabbit evaluates this topic :smiley:
I guess this is impossible, (and most likely developers had thought about it many times) but it would be great if menu titles are set next to Applications button when window maximized in Wingpanel. Hereby, wingpanel will never occupy the screen.
I haven't gotten around to implementing "Dodge" (hide when focused window is fullscreen) yet, as I hope to find a way to do this independently of Gala (and if possible agnostic of display server protocol) which requires that I actually learn vala.
I could use some help with that, and I should also port to a"HideManager" class like other pantheon components use (plank, super-wingpanel). In the meantime, please give this branch a try; more feedback is always helpful!
For the record, this bugs has already been closed as "Won't Fix" on Launchpad https://bugs.launchpad.net/wingpanel/+bug/1079575
@tintou that was a long time ago, and I don't find that @danrabbit's argument is any longer valid.
I've been over this pretty thoroughly in #93, but to briefly reiterate:
First of all, the concept of apps somehow overwhelming the panel by equating 'maximized' with 'fullscreen' isn't catching on and doesn't work: in the best case, some apps may draw over the panel in fullscreen, however they get there, and then the panel is inaccessible until the window is resized or closed, or the user switches to a different viewport (desktop); in the worst case, the panel is always shown and always occupies the top 24px of the screen disregarding the fullscreen or maximized state of the window. Much more logical to have a panel that could hide itself in either case and can be brought down with a simple mouseover at the top edge ("Dodge-Float").
Secondly, the issues with drawing struts and accidental unhides have been handled. "Float" avoids the strutting problem entirely by not dislocating windows when unhiding; the "Dodge" modes restrut after animating so users won't end up chasing moving buttons while hiding or unhiding; a configurable delay with a sane default eliminated accidental unhides.
The auto-hide function of the top bar hopes to be a setting Open: the window will be enlarged and the panel will be hidden Close: the window is enlarged and the panel will not be hidden The current top bar is not friendly to devices with small screens.
The auto-hide function of the top bar hopes to be a setting Open: the window will be enlarged and the panel will be hidden Close: the window is enlarged and the panel will not be hidden The current top bar is not friendly to devices with small screens.
@Scfy-Code you want "Dodge" or "Dodge-Float" as provided by #93
I think with the new dock we'll probably want to implement hiding in Gala itself so we can reveal with edge swipes, pressure reveal, etc and it'll be able to do positioning internally for other elements like the notification stack and animating struts etc I think should be better done internally in the window manager. I think that would solve some of the technical issues with this sort of thing and we could de-duplicate code between the panel and the dock.
Revisiting the question of fullscreen vs maximize, I think even in fullscreen situations we do have some demand for being able to access the panel to adjust things such as sound in a full screen video or game and not having to re-implement those UIs inside apps and having several layers of volume controls etc. So there still might be room for some discussion about how hiding works with regards to maximize vs fullscreen but I think revealing is a feature that at the least should be pursued