This bug annoys me too. I can't even see the filename for any files in my
desktop or anything deeper than my home folder, as /home/keith/Desktop takes up
the whole taskbar.

Created attachment 31306 [details] [review]
Title of the document follows the HIG guide lines in the patch.

The Patch fixes the HIG guidelines to display only the file name not the whole
path.

Comment on attachment 31306 [details] [review]
Title of the document follows the HIG guide lines in the patch.

thanks for working on this issue!

I'm not the maintainer, however the patch doesn't look right to me. It should
be fixed in gnome-document.c

Note that there is already a gedit_document_get_short_name there.
However all this stuff would need a bit of cleanup and rethinking (hint hint ;)
since it's affected by UTF-8 conversion issues and by the use of eel_*
functions. see bugs #138454 and #141844.

<random thoughts mode>

- maybe it would be worth replacing the uri field in GeditDocument->priv with a
GnomeVFSUri, especially if we swith to gnome-vfs also for file writing

- another thing that may be considered (dunno if it's worth though) is to also
have a "filename" field in GeditDocument->priv which would contain the filename
always in utf8 to be used in the gui. at that point
gedit_document_get_short_name etc could be switched to return a const pointer to
it that should not be freed instead of strdup'ing the string everyb time

- last consideration, if I recall correctly proper ellipsization has now been
added to pango/glib, so we may get rid of the eel hack

</random thoughts mode>

Ya, your right its time to get rid of the eel hack, and about adding the field
in GeditDocument ,hope paolo maggi should give a green flag to alter it.

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

Copying from bug #148992
------------------------

Reporter: pborelli@katamail.com (paolo borelli)

gedit has this bit of code in gedit-mdi.c which is apparently supposed to set
the name in the window list

- if (GTK_WIDGET_REALIZED (active_window))
- { 
-  gchar *short_name;
-  
-  short_name = gedit_document_get_short_name (doc);
-  
-  gdk_window_set_icon_name (active_window->window, short_name);
-  g_free (short_name);
- }

I stumbled upon it while grepping for users of get_short_name and tried removing
it since docs says that "Most of the time this is a bad idea from a user
interface standpoint. But you can set such a name with this function, if you
like" and didn't notice any difference.

We either should remove it or investigate why it doesn't work anymore.

it might be useful to allow users to have the full path (or a slightly truncated
using "..." in the middle) if they really want it by setting a gconf key.  

it is weird but i have seen users who create files with the same name over and
over again only in different directories and with a simple implenentation as
suggested the following files would all have the same title bar:

foo/file.txt
bar/file.txt
baz/file.txt

so for them the option to see a long file name would be helpful.  

another alternative that other applictions use is to show both the filename and
document title metadata but text files opened in gedit wont likely provide that
kind of title.
gedit could instead show the short filename followed by the first line (or N
characters) of the document, another user I have observed (a meticulous and well
organised programmer) always starts his documents with a title.  

if you want to go with the straight forward solution for now, I would be happy
to refile these issues as a seperate bug report but i do hope this change can be
made into an option configurable from gconf for those users who need it.  

I think that the user should have the full patch (or a slightly truncated
using "..." in the middle) in the title bar. This is really useful when you are
editing files with the same name.
At the same time only the short name should be shown in the taskbar (and in the
windows list).
I wrote code to do this, but for some reasons it does not work anymore (see
comment #7).
What do you guys think?

"Use Filename as the window title for document-based applications. Do not
use the full pathname..."

I think that one of these should happen:

1. Follow the HIG.
2. File a bug against the HIG suggesting an improvement.

Ryan, I think both #1 and #2 need to happen.

Ryan I think it is important to follow the guidelines but they are only
guidelines and it is more important to provide a usable application.  

There is no room in the HIG to explain every detail and for every possible
circumstance and every possible type of user but it does provide a good
guideline for how the defaults should be.  

If we were to strictly implement the guidelines litterally as they were written
we would definately break gedit for some users, which goes against the spirit of
the HIG if not the letter of it.  

The guidelines are great but we should not become slaves to the HIG.  
The HIG provides good general ideas but the users and developers of an
application will often know the specifics better and know when to adapt things
to the circumstances.  

All I'm really asking is that we wait and hold off on following the HIG until we
can follow the HIG in a way that does not break Gedit for a small minority of
users.  

Paolo your suggestion sounds really good if you can get it to work again.  
Given that Gedit effectively has two title bars, the main window title and the
tab title, at a stretch we could argue that your patch fullfils the HIG
suggestion by using the tab title to provide the clearer shorter name.  

The most useful information is towards the end of the pathname (the filename is
*the* most important, the directory it is directly contained in is 2nd, etc...)
 If possible, there should be some sane way to display the directory name backwards.

The problem with '...' with the filename at the end is that you don't know how
much room is going to be available on the window switcher bar (and as you open
new windows, the amount of room gets smaller).  Admittedly, if Paolo can get the
code for displaying two different titles to work again then this is less of a
problem.

If we have to have the same title in both places, then instead of:
/home/desr...older/file.txt
I'd be happy with:
file.txt (in folder)
file.txt (in /home/desrt/fo   (cut off here)
file.txt (folder:desrt:home   (cut off here)
file.txt : folder : desrt :

The : things are questionable in their usefulness because they're not a
standardised representation of the filesystem.  On the other hand, the user is
theoretically abstracted away from the filesystem by nautilus and shouldn't know
about absolute pathnames anyway (ie: just know that they have some "file"
contained in some "folder").  Does someone have a better way of expressing this?

In all cases if space got really cramped, you'd see "file.txt" instead of
"/home/de".

Another idea to help alleviate the problem would be to use some method of
shortening the path similar to what bash does.  ie:
"/home/desrt/folder/file.txt" -> "~/folder/file.txt" (since most users probably
only edit files in their home.)  You could do this for other locations too (like
Desktop) maybe even basing it on the list of shortcuts the user has defined in
the GTK file chooser.  This is probably overkill. :)

Anyway, I'm sorry if this all seems nitpicky... Just tossing ideas out here.

> shortening the path similar to what bash does.  ie:
> "/home/desrt/folder/file.txt" -> "~/folder/file.txt" 

excellent idea, 
I'm on a university network and my homepath is very long, 
almost 30 characters (subfolders for different faculties, different years and
other stuff.  

Fixed in CVS HEAD