Actually it is going to be harder than this... as the patch I outlined results in the toolbar icons being lost ('up', 'back' etc).

Here is the solution;
---------------------

modify source code;
	1. nedit thunar-location-entry.c, change;
		static void
		thunar_location_entry_location_bar_init (ThunarLocationBarIface *iface)
		{
		  iface->accept_focus = thunar_location_entry_accept_focus;
		  #ifdef THUNAR_LOCATION_BAR_PLACE_ON_SEPARATE_LINE
		  iface->is_standalone = (gpointer) exo_noop_true;
		  #else
		  iface->is_standalone = (gpointer) exo_noop_false;
			#endif
		}
	2. nedit thunar-location-entry.h, add;
		#define THUNAR_LOCATION_BAR_PLACE_ON_SEPARATE_LINE	/*added by RBB*/

	3. nedit thunar-window.c, change;
		static void
		thunar_window_install_location_bar (ThunarWindow *window,
                                		    GType         type)
		{
		  GtkToolItem *item;

		  _thunar_return_if_fail (type == G_TYPE_NONE || g_type_is_a (type, THUNAR_TYPE_LOCATION_BAR));
		  _thunar_return_if_fail (THUNAR_IS_WINDOW (window));

		  /* drop the previous location bar (if any) */
		  if (G_UNLIKELY (window->location_bar != NULL))
		    {
		      /* check if it was toolbar'ed (and thereby need to be disconnected from the toolbar) */
		      if (!thunar_location_bar_is_standalone (THUNAR_LOCATION_BAR (window->location_bar)))
        		{
        		  /* disconnect the toolbar from the window */
        		  gtk_container_remove (GTK_CONTAINER (window->table), window->location_toolbar);
        		  window->location_toolbar = NULL;
        		}
        		#ifdef THUNAR_LOCATION_BAR_PLACE_ON_SEPARATE_LINE
        		else
        		{
				gtk_container_remove (GTK_CONTAINER (window->table), window->location_toolbar);
				window->location_toolbar = NULL;     	  	
			}
			#endif

		      /* destroy the location bar */
		      gtk_widget_destroy (window->location_bar);
		      window->location_bar = NULL;
		    }

		  /* check if we have a new location bar */
		  if (G_LIKELY (type != G_TYPE_NONE))
		    {
		      /* allocate the new location bar widget */
		      window->location_bar = g_object_new (type, "ui-manager", window->ui_manager, NULL);
		      exo_binding_new (G_OBJECT (window), "current-directory", G_OBJECT (window->location_bar), "current-directory");
		      g_signal_connect_swapped (G_OBJECT (window->location_bar), "change-directory", G_CALLBACK (thunar_window_set_current_directory), window);

		      /* connect the location widget to the view (if any) */
		      if (G_LIKELY (window->view != NULL))
        		exo_binding_new (G_OBJECT (window->view), "selected-files", G_OBJECT (window->location_bar), "selected-files");

		      /* check if the location bar should be placed into a toolbar */
		      if (!thunar_location_bar_is_standalone (THUNAR_LOCATION_BAR (window->location_bar)))
        		{
        		  /* setup the toolbar for the location bar */
        		  window->location_toolbar = gtk_ui_manager_get_widget (window->ui_manager, "/location-toolbar");
        		  gtk_table_attach (GTK_TABLE (window->table), window->location_toolbar, 0, 1, 1, 2, GTK_EXPAND | GTK_FILL, GTK_FILL, 0, 0);
        		  gtk_widget_show (window->location_toolbar);

        		  /* add a separator before the location bar (destroyed with the location bar) */
        		  item = gtk_separator_tool_item_new ();
        		  g_signal_connect_object (G_OBJECT (window->location_bar), "destroy", G_CALLBACK (gtk_widget_destroy), item, G_CONNECT_SWAPPED);
        		  gtk_toolbar_insert (GTK_TOOLBAR (window->location_toolbar), item, -1);
        		  gtk_widget_show (GTK_WIDGET (item));

        		  /* add the location bar tool item (destroyed with the location bar) */
        		  item = gtk_tool_item_new ();
        		  gtk_tool_item_set_expand (item, TRUE);
        		  g_signal_connect_object (G_OBJECT (window->location_bar), "destroy", G_CALLBACK (gtk_widget_destroy), item, G_CONNECT_SWAPPED);
        		  gtk_toolbar_insert (GTK_TOOLBAR (window->location_toolbar), item, -1);
        		  gtk_widget_show (GTK_WIDGET (item));

        		  /* add the location bar itself */
        		  gtk_container_add (GTK_CONTAINER (item), window->location_bar);
        		}
		      else
        		{
        		#ifdef THUNAR_LOCATION_BAR_PLACE_ON_SEPARATE_LINE
			//added by RBB;
			   // setup the toolbar for the location bar

			  window->location_toolbar = gtk_ui_manager_get_widget (window->ui_manager, "/location-toolbar");
			  gtk_table_attach (GTK_TABLE (window->table), window->location_toolbar, 0, 1, 1, 2, GTK_EXPAND | GTK_FILL, GTK_FILL, 0, 0);
			  gtk_widget_show (window->location_toolbar);

			gtk_box_pack_start (GTK_BOX (window->view_box), window->location_bar, FALSE, FALSE, 0);	

			#else
        		  /* it's a standalone location bar, just place it above the view */
        		  gtk_box_pack_start (GTK_BOX (window->view_box), window->location_bar, FALSE, FALSE, 0);	
			#endif 

        		}

		      /* display the new location bar widget */
		      gtk_widget_show (window->location_bar);
		    }

		  /* remember the setting */
		  g_object_set (G_OBJECT (window->preferences), "last-location-bar", g_type_name (type), NULL);
		}

Created attachment 2553 
location bar on separate line screenshot

Comment 4 Jannis Pohlmann 2009-09-30 12:04:06 CEST

(In reply to comment #0)
> In order to maximise the user's ability  (and to conform to existing and
> previous browser UI standards) an option is required in Thunar Preferences to
> place the location bar on separate line to the main tool bar. 

I'm sorry to disappoint you but this won't happen. Most modern browsers like Firefox or Midori have buttons and the location entry in the same toolbar. 

There's a reason why this layout was chosen and the standalone feature wasn't exposed in the preferences dialog. The toolbar only contains a few buttons and it's simply a waste of space to make the location entry standalone. And there's no reason to change this.

The reason I first migrated from Mozilla to Firebird in 2003 (now called Firefox) was because of exactly this reason. https://bugzilla.mozilla.org/show_bug.cgi?id=49543. If path names increase in size overtime with increasing average storage space I am predicting the importance of this mod will become more apparent (ultimately it depends upon how you name your directories in your system).

I understand your argument (it might have been argued for mozilla as well), however;
1. there are also many toolbar buttons which are not in the Thunar file browser which could be added (Eg, create new folder button, Go button), and,
2. to expand the file browser window to overcome this issue wastes far more space than that wasted with an extra location bar line.

---

And here is a modification to thunar-path-entry.c which allows the user to copy and paste a path into the location path entry text box and go there without taking their right hand off the mouse to press the enter key - Ctrl-g simulates a 'Go' Button with this patch:

static gboolean
thunar_path_entry_key_press_event (GtkWidget   *widget,
                                   GdkEventKey *event)
{
  ThunarPathEntry *path_entry = THUNAR_PATH_ENTRY (widget);

  /* check if we have a tab key press here and control is not pressed */
  if (G_UNLIKELY (event->keyval == GDK_Tab && (event->state & GDK_CONTROL_MASK) == 0))
    {
      /* if we don't have a completion and the cursor is at the end of the line, we just insert the common prefix */
      if (!path_entry->has_completion && gtk_editable_get_position (GTK_EDITABLE (path_entry)) == GTK_ENTRY (path_entry)->text_length)
        thunar_path_entry_common_prefix_append (path_entry, FALSE);

      /* place the cursor at the end */
      gtk_editable_set_position (GTK_EDITABLE (path_entry), GTK_ENTRY (path_entry)->text_length);

      /* emit "changed", so the completion window is popped up */
      g_signal_emit_by_name (G_OBJECT (path_entry), "changed", 0);

      /* we handled the event */
      return TRUE;
    }
 #ifdef THUNAR_LOCATION_BAR_GO_KEYBOARD_SHORTCUT   
    else if((event->keyval == GDK_g) && ((event->state & GDK_CONTROL_MASK) != 0))
    {
    	gtk_widget_activate(widget);
    
    	 return TRUE;
     }
 #endif
        

  return FALSE;
}


(In reply to comment #4)
> (In reply to comment #0)
> > In order to maximise the user's ability  (and to conform to existing and
> > previous browser UI standards) an option is required in Thunar Preferences to
> > place the location bar on separate line to the main tool bar. 
> 
> I'm sorry to disappoint you but this won't happen. Most modern browsers like
> Firefox or Midori have buttons and the location entry in the same toolbar. 
> 
> There's a reason why this layout was chosen and the standalone feature wasn't
> exposed in the preferences dialog. The toolbar only contains a few buttons and
> it's simply a waste of space to make the location entry standalone. And there's
> no reason to change this.

(note I reopened this enhancement request but feel free to close it again)

Comment 7 Jannis Pohlmann 2009-09-30 16:22:12 CEST

(In reply to comment #5)
> If path names increase in size overtime with increasing average storage 
> space I am predicting the importance of this mod will become more apparent 
> (ultimately it depends upon how you name your directories in your system).

Exactly. There's no reason to assume that more storage space leads to longer path names.

> 1. there are also many toolbar buttons which are not in the Thunar file 
> browser which could be added (Eg, create new folder button, Go button), and,

These buttons were left out on purpose. Thunar's user interface is supposed to only show things that are really necessary for a good user experience. 

> 2. to expand the file browser window to overcome this issue wastes far more
> space than that wasted with an extra location bar line.

That's true of course. But I'm not really concerned about the width of the location entry at this point. This bug is closed, please don't reopen it again.

Oh, and if you have other proposals with code, please provide proper patches against the master branch from git as attachments to separate bugs. Thanks.

Created attachment 2559 
location bar on separate line patch

Thanks for the info on the patch creation procedure.

I realise you are a (/the) major developer for Thunar and appreciate all of your feedback.

I realise my original comments were all pretty rushed, but was pretty impressed that I was able to change the two things which were preventing me from making Thunar my default file manager (now it is) and all on the first day I discovered this project.

I have create patches for both of these ideas - at least people have the option of trying them out or creating their own version if necessary. Note I didn't initially create a separate enhancement request for the Go Location keyboard shortcut as I was pretty sure it will get fired like this one. The fact that people use Nautilus everyday without complaining too much when it is as slow as it is means that either people are pretty tolerant of file browsers nowadays or that Vista has lowered their standards; and since Thunar is ahead of Nautilus in the fundamental file browser requirement of speed I am guessing they would probably complain even less.

Here are some additional arguments for reference (its OK - I know they won't change anything);
- a File manager window does not generally have to be as wide as an internet browser window to perform browsing (meaning there is less space in the location bar).
- it is of higher priority to be able to see ones full location in a file browser as opposed to an internet browser.

Cheers,

Richard

For reference, here is a summary of arguments supporting an option for the Thunar location bar to be placed on a separate line;

- as storage space increases over time, the total number of files on ones system increases, and longer and more descriptive file/folder names are required to differentiate and recall content
- as monitor resolution increases over time, people become accustomed to using longer and more descriptive file/folder names
- as the user base of linux moves further towards the non-technical community, people have less history of using abbreviated file/folder names
- as mouse versus keyboard usage increases over time, people become accustomed to copying and pasting file/folder names where there is no operational speed advantage of using short file/folder names  
- there are possibly file browser toolbar buttons which are not in the Thunar file browser which might be worth adding there (Eg, create new folder button, Go button)
- to expand the file browser window to overcome this issue wastes far more space than that wasted with a separate extra location bar line
- it is still the standard for file browsers to have the location bar on a separate line (or with only a small number of tool bar buttons, eg 2)
- it used to be the standard for internet browsers to have the location bar on a separate line until mozilla first took off - a problem originally fixed by firebird (firefox) via introduced flexibility in the UI - and completely ignored by Microsoft engineers with the release of IE 7
- there are more toolbar icons in thunar than by default in firefox, so the space left for the location bar is less than that for firefox
- if there is ever any space wasted on a toolbar, one could argue the majority of the menu bar is a waste of space for a similar reason
- the mouse path is more consistent when the location bar is on a separate line allowing single direction (vertical) travel between files, location, and toobar buttons. 
- a file browser window does not generally have to be as wide as an internet browser window to perform browsing (meaning there is less space in the location bar) 
(note file browsers are designed such that they can be shortened, eliminating the lower priority fields if necessary - eg Date Modified, Type, and Size)
- it is of higher priority to be able to see ones full location in a file browser as opposed to an internet browser 
(folders and their internal paths structure may be duplicated, and the user should not be required to spend milliseconds thinking about where they are on their system they are when this information can be displayed)

Comment 10 Jannis Pohlmann 2009-10-07 09:23:13 CEST

(In reply to comment #9)

Ok, I'll go for this one more time but after that I want this bug to be really closed. And that means that the discussion is over.

> For reference, here is a summary of arguments supporting an option for the
> Thunar location bar to be placed on a separate line;
> 
> - as storage space increases over time, the total number of files on ones
> system increases, and longer and more descriptive file/folder names are
> required to differentiate and recall content

That really depends. I agree directory hierarchies may change with more storage space available. But personally, I haven't seen an increasing length of file or folder names at all on my machine or those of my friends. And I've gone from 40GB on my old laptop to the ~1.5TB I have right now. However, what I have noticed is increased nesting. I guess that could be seen as an equal problem. 

Now, why is this not a problem with the current toolbar design? 

See, if you have very descriptive folder names, this means you can almost uniquely identify a folder by its name and don't necessarily need to know where it is located in the file system hierarchy. As a consequence, you only need as much space for the location entry as is needed to display the folder itself and maybe its oe or two parent folders.

If you have a deep level of nesting that usually means you use shorter file and folder names. I'd say that happens intuitively as it is easier on the eyes and you no longer need to distinguish files and folders by using long, descriptive names anymore. Deep nesting implies shorter names. And that means the location bar will, even for very long paths, display a lot of nesting levels even when the window width is not 1000px.

Here's an example for deep nesting:

/home/jannis/Studies/seminare/deskriptive-komplexitaetstheorie/zusammenfassung

At about 700px, this will cut of the first few characters and render as 

/Studies/seminare/deskriptive-komplexitaetstheorie/zusammenfassung

in the location entry. This is a lot of information, and I doubt people need more than that. A few might, but I'd consider this special cases.

> - as monitor resolution increases over time, people become accustomed to using
> longer and more descriptive file/folder names

And to bigger window sizes, which pretty much neutralizes the issue.

> - as the user base of linux moves further towards the non-technical community,
> people have less history of using abbreviated file/folder names

That's true, of course. But I think I made my point about file and folder names already on the top of this comment.

> - as mouse versus keyboard usage increases over time, people become accustomed
> to copying and pasting file/folder names where there is no operational speed
> advantage of using short file/folder names  

I don't see how there's a difference between copying using the keybord or the mouse. You have to type in the file or folder names when you want to copy them with Thunar. Irrelevant.

> - there are possibly file browser toolbar buttons which are not in the Thunar
> file browser which might be worth adding there (Eg, create new folder button,
> Go button)

Nope, there are not. 

> - to expand the file browser window to overcome this issue wastes far more
> space than that wasted with a separate extra location bar line

Yes, but it also allows you to see substantially more of the folder content. Here, you are assuming your personal issue with the toolbar to be more important than the overall information presented in the window. Not a good argument.

> - it is still the standard for file browsers to have the location bar on a
> separate line (or with only a small number of tool bar buttons, eg 2)

This is changing. See https://bugs.edge.launchpad.net/hundredpapercuts/+bug/386150 for a long discussion (that I have read over only briefly) about the UI of Nautilus, proposing an interface similar to Thunar. I think there were several user interface designers and usability people involved, so this discussion might have some more arguments for you.

> - it used to be the standard for internet browsers to have the location bar on
> a separate line until mozilla first took off - a problem originally fixed by
> firebird (firefox) via introduced flexibility in the UI - and completely
> ignored by Microsoft engineers with the release of IE 7

Sorry for ignoring this in Thunar, too. As you might notice, I don't feel too bad about it. ;)

> - there are more toolbar icons in thunar than by default in firefox, so the
> space left for the location bar is less than that for firefox

I count five buttons, plus two narrower menu arraow buttons for the history, plus the drop down button for the location entry. Firefox on my machine has: Back, forward (with separate menu arrow button), refresh, cancel, home, location entry drop down button. And it also has search bar which takes up the same space as the buttons. I think we're pretty good in comparison here.

> - if there is ever any space wasted on a toolbar, one could argue the majority
> of the menu bar is a waste of space for a similar reason

I agree. But it also uses a lot less vertical space. BTW, I think we'll see menu bars changing over the next few years, with UI concepts like that of Google Chrome emerging.

> - the mouse path is more consistent when the location bar is on a separate line
> allowing single direction (vertical) travel between files, location, and toobar
> buttons. 

I guess there isn't anything I can argue with against this. It's not a strong argument though. Okay, maybe for handicapped people, but they are probably much better off using the keyboard rather than the mouse.

> - a file browser window does not generally have to be as wide as an internet
> browser window to perform browsing (meaning there is less space in the location
> bar) 
> (note file browsers are designed such that they can be shortened, eliminating
> the lower priority fields if necessary - eg Date Modified, Type, and Size)

Agreed. But again, Thunar only cuts off the leading characters in the paths it displays, so you still get as much information displayed as possible about the current folder in the location entry.

> - it is of higher priority to be able to see ones full location in a file
> browser as opposed to an internet browser 
> (folders and their internal paths structure may be duplicated, and the user
> should not be required to spend milliseconds thinking about where they are on
> their system they are when this information can be displayed)

Again, I'm not in disagreement here. I think I made my point at the top.

As far as I'm concerned, this discussion is over. I've replied to your arguments and I don't see them being strong enough to add such an option.

Basically what is required on Linux is file browser designed for power users who do not want to spend milliseconds either waiting for things to display, performing tasks via methods that have known faster alternatives, or thinking about things which can instead be displayed in a consistent manner.

Thunar can easily be modified to fulfill this role for all powers users, regardless of their personal file or folder naming preferences, and it is suggested that this option is integrated to allow it to do so.

I should have numbered these arguments originally, but did not expect a reply. Thanks for all your time and effort in replying to these. Again, I don't expect a reply, and realise that this feature request has been closed.


(In reply to comment #10)
> (In reply to comment #9)
> 
> Ok, I'll go for this one more time but after that I want this bug to be really
> closed. And that means that the discussion is over.
> 
> > For reference, here is a summary of arguments supporting an option for the
> > Thunar location bar to be placed on a separate line;
> > 
> > - as storage space increases over time, the total number of files on ones
> > system increases, and longer and more descriptive file/folder names are
> > required to differentiate and recall content
> 
> That really depends. I agree directory hierarchies may change with more storage
> space available. But personally, I haven't seen an increasing length of file or
> folder names at all on my machine or those of my friends. And I've gone from
> 40GB on my old laptop to the ~1.5TB I have right now. However, what I have
> noticed is increased nesting. I guess that could be seen as an equal problem. 
> 
> Now, why is this not a problem with the current toolbar design? 
> 
> See, if you have very descriptive folder names, this means you can almost
> uniquely identify a folder by its name and don't necessarily need to know where
> it is located in the file system hierarchy. As a consequence, you only need as
> much space for the location entry as is needed to display the folder itself and
> maybe its oe or two parent folders.
> 
> If you have a deep level of nesting that usually means you use shorter file and
> folder names. I'd say that happens intuitively as it is easier on the eyes and
> you no longer need to distinguish files and folders by using long, descriptive
> names anymore. Deep nesting implies shorter names. And that means the location
> bar will, even for very long paths, display a lot of nesting levels even when
> the window width is not 1000px.
> 
> Here's an example for deep nesting:
> 
> /home/jannis/Studies/seminare/deskriptive-komplexitaetstheorie/zusammenfassung
> 
> At about 700px, this will cut of the first few characters and render as 
> 
> /Studies/seminare/deskriptive-komplexitaetstheorie/zusammenfassung
> 
> in the location entry. This is a lot of information, and I doubt people need
> more than that. A few might, but I'd consider this special cases.
> 

the deep nesting example you provided is arguably quite short. (it depends upon your file naming conventions and no assumptions should be made about these by one's file browser - ie options should be provided to cater for any scenario). Here is another deep nesting example; 
/home/rich/tasks/Gemini Data/uploaded/geminireductionCosmicRayRemovalFirstDebug/debuglacosspec/backup using no bias and no cosmic ray removal

Primarily however, see my final argument regarding the mental processing time of semi-rendered path names. "folders and their internal paths structure may be duplicated, and the user should not be required to spend milliseconds thinking about where they are on their system they are when this information can be displayed". The text contained within the path name changes horizontal position every time a browser movement is performed allowing, a) no visual reference point for subconscious processing of ones current path, and b) no immediate confirmation of their absolute path.

> > - as monitor resolution increases over time, people become accustomed to using
> > longer and more descriptive file/folder names
> 
> And to bigger window sizes, which pretty much neutralizes the issue.
> 

users would prefer to spend their increased display size on new information while maintaining their file browser width

> > - as the user base of linux moves further towards the non-technical community,
> > people have less history of using abbreviated file/folder names
> 
> That's true, of course. But I think I made my point about file and folder names
> already on the top of this comment.
> 

(see top).

> > - as mouse versus keyboard usage increases over time, people become accustomed
> > to copying and pasting file/folder names where there is no operational speed
> > advantage of using short file/folder names  
> 
> I don't see how there's a difference between copying using the keybord or the
> mouse. You have to type in the file or folder names when you want to copy them
> with Thunar. Irrelevant.
>

file names are often copied and pasted rather than typed (eg from Thunar to a terminal). And folder names (paths) are often copied and pasted rather than typed (eg from Thunar to a terminal, or from a terminal to Thunar)

> > - there are possibly file browser toolbar buttons which are not in the Thunar
> > file browser which might be worth adding there (Eg, create new folder button,
> > Go button)
> 
> Nope, there are not. 
> 

In Windows Explorer for example one could right click and select New Folder anywhere in the browser window. In Nautilus and Thunar this is not possible, and one can only do this in white space areas below the content where the content height is less than the window height. The case for a 'new folder' button is therefore much stronger for Thunar and Nautilus than for Windows Explorer (it is quicker than either using both hands to execute Ctrl-Shift-n, or navigating the File Menu).

> > - to expand the file browser window to overcome this issue wastes far more
> > space than that wasted with a separate extra location bar line
> 
> Yes, but it also allows you to see substantially more of the folder content.
> Here, you are assuming your personal issue with the toolbar to be more
> important than the overall information presented in the window. Not a good
> argument.
> 

Expanding the window horizontally does not allow you to see substantially more of the folder content. (See previous argument: file browsers are designed such that they can be shortened, eliminating the lower priority fields if necessary - eg Date Modified, Type, and Size).

> > - it is still the standard for file browsers to have the location bar on a
> > separate line (or with only a small number of tool bar buttons, eg 2)
> 
> This is changing. See
> https://bugs.edge.launchpad.net/hundredpapercuts/+bug/386150 for a long
> discussion (that I have read over only briefly) about the UI of Nautilus,
> proposing an interface similar to Thunar. I think there were several user
> interface designers and usability people involved, so this discussion might
> have some more arguments for you.
> 

See my own comments on Nautilus here; http://live.gnome.org/Nautilus/Ideas (Traditional File Browser Behaviour option required for power users)

> > - it used to be the standard for internet browsers to have the location bar on
> > a separate line until mozilla first took off - a problem originally fixed by
> > firebird (firefox) via introduced flexibility in the UI - and completely
> > ignored by Microsoft engineers with the release of IE 7
> 
> Sorry for ignoring this in Thunar, too. As you might notice, I don't feel too
> bad about it. ;)
> 

yeah I noticed ;)

> > - there are more toolbar icons in thunar than by default in firefox, so the
> > space left for the location bar is less than that for firefox
> 
> I count five buttons, plus two narrower menu arraow buttons for the history,
> plus the drop down button for the location entry. Firefox on my machine has:
> Back, forward (with separate menu arrow button), refresh, cancel, home,
> location entry drop down button. And it also has search bar which takes up the
> same space as the buttons. I think we're pretty good in comparison here.
> 

I was incorrectly assuming the search bar had been removed by the user in Firefox - agree with you here (notice how IE7 dont even allow you to remove the search bar without hacking the registry).

> > - if there is ever any space wasted on a toolbar, one could argue the majority
> > of the menu bar is a waste of space for a similar reason
> 
> I agree. But it also uses a lot less vertical space. BTW, I think we'll see
> menu bars changing over the next few years, with UI concepts like that of
> Google Chrome emerging.
>
 
If the padding around the location bar were removed, the vertical space of a menu bar would be the same as that of the location bar. (Note I am waiting to check out Google Chrome for Linux - and agree with you about menu bars being removed in the future).

> > - the mouse path is more consistent when the location bar is on a separate line
> > allowing single direction (vertical) travel between files, location, and toobar
> > buttons. 
> 
> I guess there isn't anything I can argue with against this. It's not a strong
> argument though. Okay, maybe for handicapped people, but they are probably much
> better off using the keyboard rather than the mouse.
> 

Note the issue I am raising here is speed, not ability.

> > - a file browser window does not generally have to be as wide as an internet
> > browser window to perform browsing (meaning there is less space in the location
> > bar) 
> > (note file browsers are designed such that they can be shortened, eliminating
> > the lower priority fields if necessary - eg Date Modified, Type, and Size)
> 
> Agreed. But again, Thunar only cuts off the leading characters in the paths it
> displays, so you still get as much information displayed as possible about the
> current folder in the location entry.
> 

(see top).

> > - it is of higher priority to be able to see ones full location in a file
> > browser as opposed to an internet browser 
> > (folders and their internal paths structure may be duplicated, and the user
> > should not be required to spend milliseconds thinking about where they are on
> > their system they are when this information can be displayed)
> 
> Again, I'm not in disagreement here. I think I made my point at the top.
> 

(see top).

(In reply to comment #10)
> (In reply to comment #9)
> 
> Ok, I'll go for this one more time but after that I want this bug to be really
> closed. And that means that the discussion is over.
> 
> > For reference, here is a summary of arguments supporting an option for the
> > Thunar location bar to be placed on a separate line;
> > 
> > - as storage space increases over time, the total number of files on ones
> > system increases, and longer and more descriptive file/folder names are
> > required to differentiate and recall content
> 
> That really depends. I agree directory hierarchies may change with more storage
> space available. But personally, I haven't seen an increasing length of file or
> folder names at all on my machine or those of my friends. And I've gone from
> 40GB on my old laptop to the ~1.5TB I have right now. However, what I have
> noticed is increased nesting. I guess that could be seen as an equal problem. 
> 
> Now, why is this not a problem with the current toolbar design? 
> 
> See, if you have very descriptive folder names, this means you can almost
> uniquely identify a folder by its name and don't necessarily need to know where
> it is located in the file system hierarchy. As a consequence, you only need as
> much space for the location entry as is needed to display the folder itself and
> maybe its oe or two parent folders.
> 
> If you have a deep level of nesting that usually means you use shorter file and
> folder names. I'd say that happens intuitively as it is easier on the eyes and
> you no longer need to distinguish files and folders by using long, descriptive
> names anymore. Deep nesting implies shorter names. And that means the location
> bar will, even for very long paths, display a lot of nesting levels even when
> the window width is not 1000px.
> 
> Here's an example for deep nesting:
> 
> /home/jannis/Studies/seminare/deskriptive-komplexitaetstheorie/zusammenfassung
> 
> At about 700px, this will cut of the first few characters and render as 
> 
> /Studies/seminare/deskriptive-komplexitaetstheorie/zusammenfassung
> 
> in the location entry. This is a lot of information, and I doubt people need
> more than that. A few might, but I'd consider this special cases.
> 
> > - as monitor resolution increases over time, people become accustomed to using
> > longer and more descriptive file/folder names
> 
> And to bigger window sizes, which pretty much neutralizes the issue.
> 
> > - as the user base of linux moves further towards the non-technical community,
> > people have less history of using abbreviated file/folder names
> 
> That's true, of course. But I think I made my point about file and folder names
> already on the top of this comment.
> 
> > - as mouse versus keyboard usage increases over time, people become accustomed
> > to copying and pasting file/folder names where there is no operational speed
> > advantage of using short file/folder names  
> 
> I don't see how there's a difference between copying using the keybord or the
> mouse. You have to type in the file or folder names when you want to copy them
> with Thunar. Irrelevant.
> 
> > - there are possibly file browser toolbar buttons which are not in the Thunar
> > file browser which might be worth adding there (Eg, create new folder button,
> > Go button)
> 
> Nope, there are not. 
> 
> > - to expand the file browser window to overcome this issue wastes far more
> > space than that wasted with a separate extra location bar line
> 
> Yes, but it also allows you to see substantially more of the folder content.
> Here, you are assuming your personal issue with the toolbar to be more
> important than the overall information presented in the window. Not a good
> argument.
> 
> > - it is still the standard for file browsers to have the location bar on a
> > separate line (or with only a small number of tool bar buttons, eg 2)
> 
> This is changing. See
> https://bugs.edge.launchpad.net/hundredpapercuts/+bug/386150 for a long
> discussion (that I have read over only briefly) about the UI of Nautilus,
> proposing an interface similar to Thunar. I think there were several user
> interface designers and usability people involved, so this discussion might
> have some more arguments for you.
> 
> > - it used to be the standard for internet browsers to have the location bar on
> > a separate line until mozilla first took off - a problem originally fixed by
> > firebird (firefox) via introduced flexibility in the UI - and completely
> > ignored by Microsoft engineers with the release of IE 7
> 
> Sorry for ignoring this in Thunar, too. As you might notice, I don't feel too
> bad about it. ;)
> 
> > - there are more toolbar icons in thunar than by default in firefox, so the
> > space left for the location bar is less than that for firefox
> 
> I count five buttons, plus two narrower menu arraow buttons for the history,
> plus the drop down button for the location entry. Firefox on my machine has:
> Back, forward (with separate menu arrow button), refresh, cancel, home,
> location entry drop down button. And it also has search bar which takes up the
> same space as the buttons. I think we're pretty good in comparison here.
> 
> > - if there is ever any space wasted on a toolbar, one could argue the majority
> > of the menu bar is a waste of space for a similar reason
> 
> I agree. But it also uses a lot less vertical space. BTW, I think we'll see
> menu bars changing over the next few years, with UI concepts like that of
> Google Chrome emerging.
> 
> > - the mouse path is more consistent when the location bar is on a separate line
> > allowing single direction (vertical) travel between files, location, and toobar
> > buttons. 
> 
> I guess there isn't anything I can argue with against this. It's not a strong
> argument though. Okay, maybe for handicapped people, but they are probably much
> better off using the keyboard rather than the mouse.
> 
> > - a file browser window does not generally have to be as wide as an internet
> > browser window to perform browsing (meaning there is less space in the location
> > bar) 
> > (note file browsers are designed such that they can be shortened, eliminating
> > the lower priority fields if necessary - eg Date Modified, Type, and Size)
> 
> Agreed. But again, Thunar only cuts off the leading characters in the paths it
> displays, so you still get as much information displayed as possible about the
> current folder in the location entry.
> 
> > - it is of higher priority to be able to see ones full location in a file
> > browser as opposed to an internet browser 
> > (folders and their internal paths structure may be duplicated, and the user
> > should not be required to spend milliseconds thinking about where they are on
> > their system they are when this information can be displayed)
> 
> Again, I'm not in disagreement here. I think I made my point at the top.
> 
> As far as I'm concerned, this discussion is over. I've replied to your
> arguments and I don't see them being strong enough to add such an option.

Note the following findings;

- I have found these UI requirements may occur more often when Tree View is disabled by the user. 
- When tree view is enabled and this location bar on separate line mod is not installed, it is recommended that the home (and reload) buttons are removed from the tool bar (see enhancement request http://bugzilla.xfce.org/show_bug.cgi?id=5921). 
- When tree view is disabled, and regardless of whether or not this location bar on separate line mod is installed, it is recommended that the full path is displayed in the title bar (see enhancement request http://bugzilla.xfce.org/show_bug.cgi?id=5920)