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
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
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
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
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
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
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
13 matches
Mail list logo
