-width property is
convoluted and causes unexpected results when the size of the entire
treeview is changed (see [1]). After my patches, the code is simpler
and behaves as expected (see [2]).
Please look over the attached patches and comment.
John Lindgren
[1] screencast before (ogv): https
On 08/04/2012 04:58 PM, Emmanuele Bassi wrote:
hi John;
(snip)
I left a comment in bug 671939, but I can also repeat it here.
the patch in attachment 217892 looks okay - but what I'd like to see:
a) bisecting to see what commit broke this;
b) a test case for the TreeView test suite, to
On 08/04/2012 05:54 PM, Matthias Clasen wrote:
On Sat, Aug 4, 2012 at 4:58 PM, Emmanuele Bassi eba...@gmail.com wrote:
the patch in attachment 217892 looks okay - but what I'd like to see:
a) bisecting to see what commit broke this;
b) a test case for the TreeView test suite, to ensure we
Hi,
The func argument passed to g_signal_handlers_block_matched() is
currently a gpointer, which causes a warning when GCC is in strict C99
mode, since C99 does not allow converting a function pointer to an
object pointer. Wouldn't it make more sense for func to have
GCallback type?
-- John
affects the Audacious project to the point that we will be forced to go
back to using GTK 2.x if it is not resolved soon. I agree with the
conclusion of another user that this is a bug breaking [the] UI design
of GTK applications.
Thank you for your attention.
-- John Lindgren
Steve,
I use the time shell command and wait for my CPU meter to drop back to
idle before quitting the test program, giving something like this:
time ./list-test
real0m31.719s
user0m29.168s
sys0m0.023s
-- John
On 12/16/2011 12:24 AM, Steve . wrote:
John,
Time to
On 12/16/2011 05:54 AM, jcup...@gmail.com wrote:
...
I did notice that you forgot to put the treeview into fixed-height mode.
Normally, treeview lets rows vary in height (so you can change font
between rows, for example). To make this work, treeview has a idle
task which scans the entire
Jannis Pohlmann wrote:
I only briefly read the other replies, so maybe I'm repeating something
here. One thing I remember that can speed things up drastically is to
only associate the model with the tree view once it has all its data.
AFAIR, populating the model while it's linked to the tree
for such long lists?
-- John Lindgren
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
On 12/15/2011 09:56 PM, Steve . wrote:
John,
I can't tell you this /will work/. More over this is how I'd first
approach the problem (maybe I'm way off base here too)
My initial thoughts are that the user can't see 100,000 items at once
so there is no need to expect the widget to handle
Steve,
Are you looking at the time it takes to show the window or the time
before the CPU usage drops to idle? GtkTreeView does a lot of work in
the background after the window appears.
-- John
On 12/15/2011 11:17 PM, Steve . wrote:
John,
I just ran your test on my thinkpadx61, It only
On 12/05/2011 02:22 AM, Tristan Van Berkom wrote:
On Mon, Dec 5, 2011 at 4:18 PM, Tristan Van Berkomt...@gnome.org wrote:
Hi John,
I am responsible for a large part of your pain.
And I'm also surprised that this code is not working for you.
The last time I looked at size negotiation, the
://bugzilla.gnome.org/show_bug.cgi?id=665560
3. GtkWindow ignores gtk_window_set_default_size() and instead goes to
its natural size if the window is not resizable:
https://bugzilla.gnome.org/show_bug.cgi?id=665596
-- John
On 12/05/2011 08:56 AM, John Lindgren wrote:
This works for resizable
Hi Tristan,
This makes a bit more sense now.
On 12/05/2011 09:27 AM, Tristan Van Berkom wrote:
On Mon, Dec 5, 2011 at 11:18 PM, John Lindgrenjohn.lindg...@aol.com wrote:
It looks to me as though there are 3 separate problems contributing here:
1. GtkLabel does not take into account
On 12/04/2011 04:02 AM, Emmanuele Bassi wrote:
the status is always the same: bugs reported will be looked at by the
gtk maintainers depending on time.
So the status at this moment is that no developers have time to look at
bugs reported by application developers. Or is there something wrong
affects the Audacious project to the point that we will be forced to go
back to using GTK 2.x if it is not resolved soon. I agree with the
conclusion of another user that this is a bug breaking [the] UI design
of GTK applications.
Thank you for your attention.
-- John Lindgren
Hi,
This question seems to have been asked before [1] and never really
solved. The scenario is as follows. I have a GtkBox acting as a
toolbar and holding various widgets (buttons, a slider, a label, and a
volume slider), some of which may be hidden at times. I want to show a
pop-up menu when
17 matches
Mail list logo
