Created attachment 83412 [details]
Current default setup (aproximatly)

Created attachment 83414 [details]
My preferred layout.

My preferred layout. Usually I use the space won for bookmarks.

I second this RFE, moving the address bar to the main toolbar is the first thing I always do in first installations of Ephy.

Perhaps the zoom out and zoom in can go the right as well.

Created attachment 83418 [details]
Screenshot

Zoom buttons on the right side of the toolbar. Note that the home button is missing in this layout, it should be included in the default layout.

But I would leave the "Go To" button next to the address bar.

Wouter, is there a specific reason why you are proposing to move the zoom buttons to the right?

(In reply to comment #6)
> But I would leave the "Go To" button next to the address bar.

Yup.

> Wouter, is there a specific reason why you are proposing to move the zoom
> buttons to the right?

Separation from navigation (as in go-to) controls. Makes sense.

> > Wouter, is there a specific reason why you are proposing to move the zoom
> > buttons to the right?
> 
> Separation from navigation (as in go-to) controls. Makes sense.

Exactly, that's the rationale.

The current default toolbar layout was well-considered.
Please read this thread completely: http://www.mail-archive.com/epiphany-list@gnome.org/msg01244.html

If you're arguing for the default layout to be changed, please support it with a stronger use case than "First thing I do on a fresh GNOME installation is moving Ephy's address bar into the main toolbar. " What benefits would it bring for first-time users, in particular?

(In reply to comment #9)
> The current default toolbar layout was well-considered.
> Please read this thread completely:
> http://www.mail-archive.com/epiphany-list@gnome.org/msg01244.html
> 
> If you're arguing for the default layout to be changed, please support it with
> a stronger use case than "First thing I do on a fresh GNOME installation is
> moving Ephy's address bar into the main toolbar. " What benefits would it bring
> for first-time users, in particular?
> 
My problem with that old discussion: It is no discussion. Marco came up with some weird idea and Epiphany was broken to support that idea. If we'd have been as critical as you are now, we still would have some sane toolbar layout.

Reasoning:

- The current additional buttons are rarely used - in my opinion. Rarely used items should not show up on any toolbar. They are confusing for the new user, make Epiphany feel cluttered. Let him go back to Firefox.
- The waste of space argument you put down that easily is an important argument: We waste valueable space for adding four very unimportant buttons to the toolbar. On 800x600 the current setup wastes 800 * 30 + 200 * 35 = 31.000 pixels, which are 6.5% of this small screen. On 1024x768, which is much more common those days[1], 1024 * 30 + 224 * 35 = 38.560 pixels (4%), on the common 1280x768 widescreen format 1280 * 30 + 680 * 35 = 62200 (6%) are wasted.
- The original problem of the address bar being too short just happend, because there were too much icons on the primary toolbar. When dropping bookmarks, history, zoom-in and zoom-out from the default toolbar, there are 354 pixels available for entering addresses on 800x600. Sufficient space to enter fancy addresses like "www.tittenguckendeluxeundsichtotalzumaffenmachen.com".
- Current default setup of Epiphany seems to feel that cluttered, that my little sister even searches for the more clearly structured Firefox, if I ban it from all panels.
- Major advantage of Epiphany over Firefox ist not a wider back button or some overloaded toolbar with history, bookmarks and zooming buttons on the default toolbar. The killer feature of Epiphany is the tagging based bookmark system, which is better promoted by just leaving the addressbar (and maybe adding some "bookmark this" button).

If you want to show new users how pretty Epiphany is, better set the default homepage of Epiphany to some local page providing a guided tour through Epiphany, than clutter its toolbar.


[1] Accordingly to BFL IT Index (http://www.bfl-it-index.de/) in Germany only 4.4% of all screens are CRT monitors still. No wonder as you can by 19" LCDs for as few as just €150 those days.

Forgot to mention the location bar drop-down: Poor excuse for bad code. Properly coded the drop-down would align to the right boundary of the location bar and expand to the left, if it would need more space, that the location bar provides.

Created attachment 83444 [details]
800x600 with clean toolbar setup.

For the posisioning, see bug 405727.

(In reply to comment #13)
> For the posisioning, see bug 405727.
> 

Looks like a little bounty.

@Mathias: you may not agree with Marco's design ideas but that doesn't mean Epiphany was/is broken.

- Which buttons are / are not rarely used, differs from person to person. Case in point: I have no need for a Home button but use the 'Up' button (non-default) regularly. However I'm NOT the typical audience Epiphany is intended for, so I won't argue to make this layout the default. Nevertheless I do feel strongly that the (+) and (-) buttons are valuable additions because especially on *nix setups fonts often appear too small on sites that were designed under windows/IE. Inexperienced users are known not to explore menus but at most the buttons that are visible. As for Bookmarks/History, those windows were intended to be major ways to access webpages besides/instead of the address bar, but this idea never really took off. These buttons need revisiting when/if the bookmarks+history rewrite is ever completed.

- I don't wish to put down the waste of space argument too easily. It is valid. However it is also important that the user is able to read the complete URL of the site (s)he visits (think about phishing).

- Setting a tour-of-Epiphany homepage is useless because distro vendors will override it anyway. See also bug 355251.

For detecting phishing it is not necessary for the entire URL to be visible, just the part equivalent to the genuine domain (which is usually quite short).

I think the shift in defaults from two toolbars to one in NS4->Firefox, IE6->IE7, and MacIE->Safari, reflects an increase in the average experience of Web users, and to a lesser extent an increase in the use of Web applications for which less browser chrome is better.

Created attachment 83625 [details]
dynamic toolbar layout

Ok, trying to be constructive: What about placing the address bar automatically depending on the space available?

Created attachment 83626 [details]
makefile for the mockup

Created attachment 83627 [details]
Compact layout

Created attachment 83628 [details]
Wide layout

harves rewrote a lot of the toolbar code, he should be able to answer that question. cc'ing.

I'm guessing the question relates to "can we make the address bar automatically move around on the toolbar, based on width". :)

I would think that, to do it properly, the behaviour would have to be part of the base GtkToolbar class. Rearranging toolbar widgets into two rows based on availabe width, minimum widget size, maximum widget size, etc would change a lot of the logic in GtkToolbar. My preference would be to copy the entire GtkToolbar codebase and modify to become a custom Epiphany widget. Assuming of course that there was such a large demand for automatically rearranging toolbars.

That said, you could probably come up with some horrible hack that implements what you're suggesting without modifying GtkToolbar. It'd be ugly, and wouldn't necessarily work in all cases. I note that the attachments don't describe what should happen if I have a few more buttons located on the right side of the addressbar entry. Should they move down to the second line before the address bar? When do you decide it's time to move widgets to the next row? That kind of detail is really going to require a rewrite of GtkToolbar in my opinion.

(In reply to comment #22)
> I'm guessing the question relates to "can we make the address bar automatically
> move around on the toolbar, based on width". :)

No, its rather "do we want the address bar to move arround automatically". The possibility of this behaviour is demonstrated by the attached mockup. It works using three toolbar widgets. 

The widget hierachy looks like this for two-row mode:

GtkToolbar "main"
+- GtkToolItem
   +- GtkVBox
      +- GtkToolbar "actions"
      |  +- GtkMenuToolButton "go-back"
      |  +- GtkMenuToolButton "go-forward"
      |  +- GtkToolButton "stop"
      |  +- ....
      |  +- GtkToolItem "address-item"
      |  +- GtkSeparatorToolItem
      |  +- GtkToolButton "zoom-in"
      |  +- ...
      +- GtkToolBar "address-bar"
         +- GtkToolItem
         |  +- GtkEntry "address-entry"
         +- GtkToolButton "go-to"

The widget hierachy looks like this for single-row mode:

GtkToolbar "main"
+- GtkToolItem
   +- GtkVBox
      +- GtkToolbar "actions"
         +- GtkMenuToolButton "go-back"
         +- GtkMenuToolButton "go-forward"
         +- GtkToolButton "stop"
         +- ....
         +- GtkToolItem "address-item"
         |  +- GtkToolBar "address-bar"
         |     +- GtkToolItem
         |     |  +- GtkEntry "address-entry"
         |     +- GtkToolButton "go-to"
         +- GtkSeparatorToolItem
         +- GtkToolButton "zoom-in"
         +- ...

The trick for getting rid of the bevel arround the nested toolbars looks like this:

    gtk_rc_parse_string("                               \
        style \"nested-toolbar\" {                      \
            GtkToolbar::shadow-type = none              \
        }                                               \
                                                        \
        widget_class \"*<GtkToolbar>*GtkToolbar\"       \
        style \"nested-toolbar\"                        \
    ");

Maybe this should go into gtk+ by default.

See also: Bug 314163.

I completely agree with those who think the current toolbar layout is a waste of space. It's one of the first things I do after starting Epiphany for the first time as well, limiting the buttons to back-forward-stop-refresh-stop-home, and having those and location bar on one row.

I can understand why you would want to keep the buttons for shrinking/enlarging the text, because there can be websites with very small fonts. But at least remove the buttons for favorites and history, those are completely useless, at least in my opinion.

*** Bug 594447 has been marked as a duplicate of this bug. ***

Added link to bug reported downstream: https://bugs.launchpad.net/ubuntu/+bug/343402

from bug 59447: "Big navigation bars waste valuable screen space and are U-G-L-Y! Maximizing
screen space for actually viewing web pages is important. Chromium has done an
incredible job at this. We can try to do the same with simple things like:
Merging the search and URL bar: https://bugs.launchpad.net/bugs/343400
Star for bookmarks: https://bugs.launchpad.net/bugs/343401
etc, etc.

Of course, we shouldn't copy chromium, but make our use of space more efficient
in the way we see fit. Bottom line though, we need to use screen space more
efficiently."

*** Bug 594607 has been marked as a duplicate of this bug. ***

That bug is even more accurate since GNOME decision to use "Text beside icons" toolbar style for version 2.28,
we see that 50% of Epiphany bars are empty in normal use cases !

Pushed 80ca4ae3c2215e8af467c2c577581df841cd2ae6 defaulting to one toolbar, with less icons.