GNOME Bugzilla – Bug 137539
Tooltip (and status bar) broken for very long file names
Last modified: 2005-08-03 15:44:54 UTC
Distribution: Debian testing/unstable Package: gedit Severity: enhancement Version: GNOME2.4.1 2.4.x Gnome-Distributor: Debian Synopsis: Size of title bar expands the window in a unusable way Bugzilla-Product: gedit Bugzilla-Component: general Bugzilla-Version: 2.4.x Description: I just tried to open the following link with galeon: http://landfill.mozilla.org/bugzilla-tip/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&field0-0-0=noop&type0-0-0=noop&value0-0-0=&ctype=ics and I decided open the file with gedit after the application asked to me. So, the title of the window was set with the URL and the window was rezise so much. Very unusable. I closed the window, but for the next time, it was openend with the same big size. IMHO, if the titlebar were so long, it could be cut and ended with periods. The same things applied to the tab. ------- Bug moved to this database by unknown@bugzilla.gnome.org 2004-03-17 17:49 ------- Reassigning to the default owner of the component, paolo.maggi@polito.it.
Is it still reproducible?
It is fixed in gedit 2.6.0 But I noticed another problem while verifying it. Changing the summary.
Recent file menu is broken too.
*** Bug 135134 has been marked as a duplicate of this bug. ***
Created attachment 26146 [details] [review] Proposed patch I have not change the tooltip and the info in the status bar because this is the only way to know the full name of the file, if it is too long.
You are right, the tooltip should not be truncated, but the problem with the tooltips is that the text should be escaped before being displayed (give a look at the tooltip when the URI on the first comment is used). I think the statusbar text should be escaped too, but it is not a great problem. About your patch: In + docname = egg_recent_util_escape_underlines (basename); + escaped = eel_str_middle_truncate (docname, MAX_URI_IN_TITLE_LENGTH); probably it is better to swap the statement, i.e. I think it is better to call eel_str_middle_truncate before egg_recent_util_escape_underlines. I think you should submit your patch against libegg/recent-files too. snorp: I think you should give a look at this problem and include the solution in egg-recent.
When loading the URI given in the initial report, the "Loading file:" dialog that appears after a few seconds has a problem. The markup isn't parsed, so the <b> and </b> show up. This means that the URI string needs to be escaped before being put into the label string maybe? (gedit:3737): Gtk-WARNING **: Failed to set label from markup due to error parsing markup: Error on line 2: Character '=' is not valid inside an entity name
Created attachment 31325 [details] [review] propesed fix for the issue raised in the last comment using gnome_vfs_format_uri_for_display (uri) fixes the issue about the "=" character and thus the markup is interpreted correctly, however the URI displayed ends up containing ugly escape sequences (%whatever). The patch instead splits the message in two labels, one marked up containing "Loading file" and the other containg the uri.
Tested that last patch, it seems to work fine.
That patch from March doesn't seem to have been applied anywhere, and I can't see a corresponding bug in libeel bugzilla. Can we get this applied to gedit with the suggested lineswap? Or does it need to go into libeel before going into gedit?
such a patch should be included in recent-files (note that it is in libegg not libeel!) however the patch uses a libeel function and I do not think that recent-files in libegg can depend on it. Note also that gtk+ >= 2.5 includes proper pango ellipsisation, so we should switch to it once it becomes am accetable dependency.
Comment on attachment 31325 [details] [review] propesed fix for the issue raised in the last comment Please, test it and commit.
Created attachment 36442 [details] [review] proposed patch for the window title Paolo: here is a proposed patch for the window title: the directory path was already ellipsized in the current code, however it may happen that the filename itself is very long... the patch does the following: - if the filename exceeds MAX_LENGHT then it is shortened, and dirname is set to NULL so that it is not displayed in the title: I did this beacuse I didn't like the idea of having two "..." in the title - if the filename isn't too long, than dirname is shortened to MAX (20, MAX_TITLE_LENGHT - strlen (name)), so that we use all the remaining space for the dirname but we avoid the corner case of having the dirname shortened to one or two characters. I used MAX_TITLE_LENGHT = 100, since before it was 75 + filename lenght... however 100 may still a bit too long... Can you review, test, eventually tweak the max value and, if it is ok, commit? I do not have the laptop with my cvs tree available.
Comment on attachment 36442 [details] [review] proposed patch for the window title Sorry for the late reply. >+#define MAX_TITLE_LENGTH 100 I think 100 is ok. We can change it in the future if needed. >+ /* use the remaining space for the dir, but use a min of 20 chars */ >+ dirname = gedit_utils_str_middle_truncate (str, MAX (20, MAX_TITLE_LENGTH)); It seems wrong to me: MAX (20, MAX_TITLE_LENGTH) > Can you review, test, eventually tweak the max value and, if it is ok, commit? I don't think I will have time to test it... I trust you, feel free to commit if you are confident about the patch.
Comment on attachment 36442 [details] [review] proposed patch for the window title committed the patch for the title with the following changes: - use g_utf8_strlen instead of strlen - obviously MAX (20, MAX_TITLE_LENGTH - len)
Should the remaining patch here be obsoleted by the already commited one?
Created attachment 49945 [details] [review] This patch should fix all the reported problems. Note that part of this patch should be committed in libegg/recent-files.
paolo, you can't change the short name returned by the EggRecentItem, because that is used in places where we can have ellipsization using the Pango code. either we provide a egg_recent_item_get_ellipsized_name or we port the Pango ellipsization code where is needed. Or, as a third and secret option, we provide an ellipsization option on the short name: void egg_recent_item_set_uri_ellipsize (EggRecentItem *item, PangoEllipsizeMode mode); but that would be overkill, if I may say...
Created attachment 50117 [details] [review] This patch adds ellipsization to egg-recent-bonobo-view
Fixed in CVS HEAD. 2005-08-03 Paolo Maggi <paolo@gnome.org> * gedit-document.c (get_uri_shortname_for_display): cleaned up Fixed bug #137539: recent files menu broken with very long file names. * recent-files/*: sync to libegg.