After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 312122 - disable autosizing of entry view columns
disable autosizing of entry view columns
Status: RESOLVED FIXED
Product: rhythmbox
Classification: Other
Component: User Interface
HEAD
Other Linux
: Normal normal
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-07-31 08:04 UTC by Jonathan Matthew
Modified: 2005-11-29 01:14 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (5.15 KB, patch)
2005-07-31 08:06 UTC, Jonathan Matthew
none Details | Review
updated patch (8.15 KB, patch)
2005-10-30 16:45 UTC, James "Doc" Livingston
none Details | Review
another updated patch (8.04 KB, patch)
2005-11-05 02:01 UTC, James "Doc" Livingston
none Details | Review
new patch (11.47 KB, patch)
2005-11-22 12:42 UTC, Jonathan Matthew
committed Details | Review

Description Jonathan Matthew 2005-07-31 08:04:01 UTC
gtk+ wastes an inordinate amount of time measuring every string we put into a
RBEntryView, whether visible or not.  Disabling column autosizing (which doesn't
really help much anyway - it just makes the column sizes change a bit while
loading the library) makes the rhythmbox UI noticeably faster.
Comment 1 Jonathan Matthew 2005-07-31 08:06:39 UTC
Created attachment 50009 [details] [review]
patch

The only problem with disabling autosizing is that it means all entry view
columns  either need to be expanding or have a fixed minimum size.  Most of the
changes in the patch are there to measure minimum sizes for the non-expanding
columns, and I'm not sure this is the best way to do it.  The tree view widget
somehow calculates a minimum width it'll allow you to resize a column to, but I
can't see a way to get at that value.
Comment 2 James "Doc" Livingston 2005-09-05 03:41:05 UTC
There is a function (gtk_tree_view_column_cell_get_size) which you can use to
get the width of a column - but unfortunately the non-ellipsised text columns
(where you have used the templates) don't yet contain any text, so it returns 0.
I don't know if there is a better solution than the templates, because of the
lack of rows when this code is run.

Even if we don't think up a better way of doing it, getting this into cvs would
be good - currently it takes about 9 seconds for my playlists to fully load
after the library source has, and this patch reduces that to under 2 seconds.
Comment 3 Baptiste Mille-Mathias 2005-10-25 09:21:38 UTC
CC myself to remember to test the patch
Comment 4 James "Doc" Livingston 2005-10-30 16:45:32 UTC
Created attachment 54088 [details] [review]
updated patch

Updated to apply to cvs.

Looking over it the potentially bad columns are:
* Last Played/Date Added/Podcast Date, which might be wider in some locales
* Track #, where there may be more than 9999 tracks in a playlist or the string
is wider in some locales
Comment 5 James "Doc" Livingston 2005-10-31 14:00:31 UTC
One idea I've just had: we dont't have to move away from autosizing completely.
We could at least commit a partial version of this to cvs, with the following
column properties:

* The Playcount and Time columns have their width set by the strings "Never" and
"Unknown" respectively (like in the patch)
* Track # and the date/time columns stay as autosizing
* The title/artist/etc columns have no minimum with and are set to expanding to
take up the rest of the space equally (like in the patch)


That should provide a reasonable improvement in speed, without the potential
l10n problems of using fixed widths for the date/time columns. I'll probably
have a go at trying this soon, to see how much improvement there is.
Comment 6 James "Doc" Livingston 2005-11-05 02:01:17 UTC
Created attachment 54342 [details] [review]
another updated patch

updated to cvs head
Comment 7 Jonathan Matthew 2005-11-22 12:42:29 UTC
Created attachment 55076 [details] [review]
new patch

Now measures dates properly (more or less) and does podcast-specific columns.
I've tested date formatting in Japanese (the only translation to use anything
besides %Y, %m, %d, %H, and %M) and it works fine.
Comment 8 James "Doc" Livingston 2005-11-22 13:02:07 UTC
Looks good. About the only other thing I can think of is that we should probably
use g_strdup_printf ("%d", 9999) rather than "9999", to work better in locales
that don't use Arabic numerals.
Comment 9 James "Doc" Livingston 2005-11-29 01:14:51 UTC
Patch committed to cvs. If there are any remaining problems with this, they will
probably be found by people using it and complaining.