GNOME Bugzilla – Bug 609713
redesign the toolbars and statusbars for space efficiency
Last modified: 2010-05-18 16:18:20 UTC
Created attachment 153597 [details] screenshot Since GNOME 2.28/gtk-something, the default setting for toolbar buttons is "text besides icons". This means that we now have an opportunity to reconsider the design of the epiphany toolbars, and be much more space efficient (reduce the amount of "chrome" around website contents), especially for devices such as netbooks. Some proposals: 1- Only one toolbar. Move the address bar inside the main toolbar, on the right of the buttons. 2- Get rid of the status bar by default. Its functionnalities all seem to have been replaced: the loading progress is now shown in the address bar, the secure connection icon is also shown in the progress bar... the only thing left is the link URLs when we hover the mouse over links... but the feature that "shows a tooltip when hovering a link and the status bar is deactivated" (à la Chromium) is already implemented. So technically, we are just one step away from killing the status bar: changing the default gconf setting /apps/epiphany/general/show_statusbar to False. This bug report is in direct contradiction with bug #595144. Enclosed is a screenshot of what it could look like (approximately).
The default toolbar configuration has already been reduced to one toolbar in the most recent unstable release. I'm against removing the status bar because it is the only way to have a resize grippy which makes it much easier to resize a window.
> The default toolbar configuration has already been reduced to one toolbar > in the most recent unstable release. Oh, I didn't know :) I guess this happened after 2.29.6. > I'm against removing the status bar because it is the only way to have > a resize grippy which makes it much easier to resize a window. By that logic, then Empathy, Baobab, gnome-terminal, and the gnome games should all have a status bar too? :) sounds to me like a "fix GTK, not the apps" issue (just for the sake of the argument).
Yes, ideally the resize grippy should not be dependent on a status bar. But we have to live with the current situation and I think a browser window is much more likely to be resized than the other Gnome apps you mention. Gnome-terminal has a Terminal-menu that will resize it to another rows x cols preset.
(In reply to comment #0) > 2- Get rid of the status bar by default. Its functionnalities all seem to have > been replaced: the loading progress is now shown in the address bar, the secure > connection icon is also shown in the progress bar... the only thing left is the > link URLs when we hover the mouse over links... but the feature that "shows a > tooltip when hovering a link and the status bar is deactivated" (à la Chromium) > is already implemented. So technically, we are just one step away from killing > the status bar: changing the default gconf setting > /apps/epiphany/general/show_statusbar to False. I would like this, but I think we need at least one to happen before this can be on: currently the overlay Epiphany adds with the link may make you unable to click a link that is in the bottom left corner of the page. We need it to either move away from the pointer, or to at least pass clicks down to the page.
Gustavo: agreed, I already filed a bug about that, bug #609238
Is it hard to get the resize grippy image from the theme and overlay it in the bottom-right corner without help of the statusbar?
Created attachment 161250 [details] [review] chromium-statusbar.diff So, this gets rid of our statusbar completely, and replaces it with a native (ie, no web stuff) chromium-like statusbar. We lose the resize grip, but hopefully we'll get it back really soon when they add it to GtkWindow. Opinions and reviews welcome.
Some notes: - I removed the statusbar messages when selecting stuff in the back/forward/up toolbar buttons. They are kid of pointless IMHO. - I had to connect to the adjustments in the widget and invalidate the area of the statusbar when we scroll, since our parent class thinks it can reuse it (we are drawing there without its knowledge). This could be avoided by giving the statusbar its own window, but that would be more code and complexity just to avoid that workaround. - We can further cleanup this now by making the EphyWebViews set their own messages, but that will come in a follow-up.
Oh, and this makes somewhat more noticeable a bug we already had where messages get stuck in the statusbar. We should fix it!
Created attachment 161262 [details] [review] remove-messages.diff Do not put stuff in the statusbar for the toolbar navigation action buttons.
Created attachment 161263 [details] [review] chromium-statusbar.diff Use a Chromium-like statusbar by default.
Review of attachment 161262 [details] [review]: Love removing code!
Review of attachment 161263 [details] [review]: I couldn't spot any problem. I almost feel we should split that out of webview, but I think the code is simple/small enough to be there, though.
(In reply to comment #13) > Review of attachment 161263 [details] [review]: > > I couldn't spot any problem. I almost feel we should split that out of webview, > but I think the code is simple/small enough to be there, though. The thing is the statusbar is not a widget, just a feature of the EphyWebView, so splitting it is a bit artificial.
OK, I've pushed this plus a few bugfixes on top of it, so I'll close the bug.