Re: (severe) performance issues
Hi David,
On 3/26/07, David J. Andruczyk <[EMAIL PROTECTED]> wrote:
> I would NOT expect updating approx 10 labels perhaps 5-10 times per
> second (ie. when data chages) on a 1.8Ghz machine be so cpu hungry.
I made a tiny test program. This updates 50 labels at 100Hz with less
than 1% CPU on my machine.
--
/* compile with
* gcc -Wall try16.c `pkg-config gtk+-2.0 --cflags --libs`
*/
#include
#include
const int NUM_LABELS = 50;
const int FPS = 100;
gboolean
update_labels (GtkWidget * label[])
{
int i;
for (i = 0; i < NUM_LABELS; i++)
{
char buf[256];
snprintf (buf, 256, "%d", rand ());
gtk_label_set_text (GTK_LABEL (label[i]), buf);
}
return TRUE;
}
int
main (int argc, char **argv)
{
GtkWidget *label[NUM_LABELS];
GtkWidget *win, *box;
int i;
gtk_init (&argc, &argv);
win = gtk_window_new (GTK_WINDOW_TOPLEVEL);
g_signal_connect (win, "destroy", G_CALLBACK (gtk_main_quit), NULL);
box = gtk_vbox_new (FALSE, 0);
gtk_container_add (GTK_CONTAINER (win), box);
for (i = 0; i < NUM_LABELS; i++)
{
label[i] = gtk_label_new (NULL);
gtk_box_pack_start (GTK_BOX (box), label[i], TRUE, TRUE, 0);
}
g_timeout_add (1000 / FPS, (GSourceFunc) update_labels, label);
gtk_widget_show_all (win);
gtk_main ();
return 0;
}
-
I have Dapper still on my machine (gtk 2.8, amd64 2.7 GHz) which might
make some difference I guess. Though I think Pango has actually sped
up in 2.10.
I wonder if another reason might be resizing? Setting a label's text
can cause the label to change size, which might be forcing some
(large?) chunk of your interface to resize too. You could try using
gtk_widget_set_size_request() on your labels to make them a fixed
size.
John
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: use of g_thread_exit
On 3/26/07, Pritesh Kumar <[EMAIL PROTECTED]> wrote: > NOW i want to perform a operation in "int main()" function of my > application only if the above mentioned thread has exited successfully. > is there a way to do this. how can the "int main" know if the created thread > has exited or not. g_thread_join()? http://developer.gnome.org/doc/API/2.0/glib/glib-Threads.html#g-thread-join This will block if the thread has not exited yet. You'll need to send a "I'm about to exit, please call g_thread_join()" message from the worker. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On 3/26/07, David J. Andruczyk <[EMAIL PROTECTED]> wrote: > I added your code, and it DOES stop the display from resizing > widgets when the labels display small values, Yea! \o/ > but it DOES NOT drop > cpu usage at all. so internally GTK+ is still going something with > regards to the labels. Oh dear :-( What about that tiny program that just changes labels? Is that fast on your machine? I guess I'd try experimentally commenting out other elements of the interface. Sorry not to have any more ideas. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On 3/30/07, Paul Davis <[EMAIL PROTECTED]> wrote: > So I've spent about 15 minutes going through software on this computer > looking through different windows trying to find an example of a label > that changes to convey some interesting piece of information. I can't > find any. I don't know if this is what you mean, but I have an example in my image processing application. Image windows have an optional status bar which shows width, height, etc. and also current mouse position in x/y image coordinates, and the value of the pixel under the mouse. http://cima.ng-london.org.uk/~john/statusbar.png The labels showing x/y/value have to be fixed in size so they don't jiggle left-right as you move the mouse around. I do this by calling gtk_widget_set_size_request() on them after measuring the size of the largest value I can show in the right font. It seems that calling gtk_widget_set_size_request() on a label locks the size, but doesn't stop the label from triggering a resize when the label's content next changes. Maybe this is somthing that could be changed without breaking anything? John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
Hi Bobby, On 4/3/07, Bobby Jack <[EMAIL PROTECTED]> wrote: > Can you include some details as to how you gathered > these metrics? I'm seeing very different results from > your test program, although I'm just eyeballing top so > I'd like to use whatever method you did. That's all I did as well. If I compile and run the test program, it (almost) never appears on top. If I change it to 100 labels at 100 Hz, I see just over 1% CPU (from memory). Do you see something very different? What X server / graphics card / CPU / gtk do you have? My card is a very modest nvidia (less than 100 ukp), though I do have a fast CPU. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On 4/3/07, Bobby Jack <[EMAIL PROTECTED]> wrote: > My results with the following: > >* Intel P4 3.2 GHz >* Onboard graphics controller (this may well be the > limitation) >* GTK 2.10.8 >* Test program defaults (50 labels, 100 FPS) > > are CPU usage consistently above 50%. I can try to > reproduce this on another machine (much slower CPU, > better - although still quite old - nvidia graphics > card) if that would be useful. That's interesting. I just tried on my laptop (1.8 GHz PM, ATI mobility, gtk2.10) and I get about 40% CPU usage, which is more than I'd expect. I'll try building gtk2.10 on my work machine tomorrow and see if 2.8 -> 2.10 makes much difference. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How do you develop you GTK code?
On 4/14/07, Robert Pearce <[EMAIL PROTECTED]> wrote:
> The other thing to bear in mind is this:
> If you have a row or column of similar widgets, say buttons, then a tool
> like Glade or BCB requires you to place every one individually. Writing the
> code by hand lets you do:
> for ( cc=0; cc<10; cc++ )
> {
> MyButtons[cc] = gtk_button_new (..);
> gtk_box_pack_start ( );
> }
>
> This is even more relevant if the number of buttons isn't known at design
> time!
This is a good point. In my app I have functions like (an example)
build_label_entry() which makes a GtkLabel + GtkEntry with layout
following the HIG guidelines. Once you have a few of these set up,
building a dialog from code is really easy. Plus now your layout is
just in one function, so you can change the layout of all label +
entry pairs by just altering a couple of lines of code.
It also depends on the kind of program you are writing. Mine has a
relatively 'small' GUI (most of the code is in the back end) so Glade
would not save me a significant amount of time.
Having said that, most people tell me it has an awful interface, so
maybe you shouldn't listen to me.
John
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: scrolling logs in GtkTextView to the end (Re: scrolling windows)
Hi, On 5/4/07, ibrar ahmed <[EMAIL PROTECTED]> wrote: > http://mail.gnome.org/archives/gtk-app-devel-list/2003-March/msg00064.html > > Please see this reference where this problem already handled, but there is > issue regarding work on FTP server. I use the following code to append to a text buffer and scroll to the bottom. It seems to work fine for me and doesn't need an idle handler: GtkTextView *text_view = GTK_TEXT_VIEW( trace->view ); GtkTextBuffer *text_buffer = gtk_text_view_get_buffer( text_view ); GtkTextMark *mark = gtk_text_buffer_get_insert( text_buffer ); GtkTextIter iter; gtk_text_buffer_get_end_iter( text_buffer, &iter ); gtk_text_buffer_move_mark( text_buffer, mark, &iter ); gtk_text_buffer_insert_at_cursor( text_buffer, buf, -1 ); gtk_text_view_scroll_to_mark( text_view, mark, 0.0, TRUE, 0.5, 1 ); John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Gnuplot-like library for GTK
On 5/23/07, Bleriot Trece <[EMAIL PROTECTED]> wrote: > I wonder whether anybody knows if a library for GTK providing a > functionality similar to the GNU plot is available. Our company is beginning I've been using GtkPlot, part of gtkextra: http://gtkextra.sourceforge.net It only sort-of works, sadly. It's rather buggy, the API is not very gtk-like and it uses huge amounts of memory. It has it's own slightly wobbly canvas widget. It ought to be redone on top of goocanvas or similar. If you use it, expect to have to hack on the sources quite a bit. There's guppi, which was going to be the official gnome chart component: http://www.gnome.org/projects/guppi But I think this project has died. Gnumeric used to use guppi but they've abandoned it and now have their own thing. I don't know if the gumeric charter is available as a separate component (I doubt it). There was a fork of gnuplot which could work as a library, but again I think this was abandoned. Perhaps someone knows of something better? John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: open new window
On 7/2/07, brad smith <[EMAIL PROTECTED]> wrote:
> I am trying to open a new window(that has a text view widget) from a
> button on the main window. I have looked for examples but could not
> find any.(or maybe I just do not know what I am looking for)
I had this lying around. You'll need to add the text window to the popup.
/* compile with
* gcc try8.c `pkg-config gtk+-2.0 --cflags --libs`
*/
#include
int nums[3] = { 0, 1, 2 };
void
doDialogue (GtkButton * but, int *action)
{
static GtkWidget *dialogue;
GtkWidget *button;
switch (*action)
{
case 0: // make and realize dialogue widget
if (!dialogue)
{
dialogue = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_window_set_transient_for (GTK_WINDOW (dialogue),
GTK_WINDOW (gtk_widget_get_toplevel (GTK_WIDGET (but;
gtk_window_set_position (GTK_WINDOW (dialogue),
GTK_WIN_POS_CENTER_ON_PARENT);
g_signal_connect (dialogue, "destroy", G_CALLBACK (doDialogue),
&nums[2]);
button = gtk_button_new_with_label ("Cancel");
g_signal_connect ((button), "clicked", G_CALLBACK (doDialogue),
&nums[1]);
gtk_container_add (GTK_CONTAINER (dialogue), button);
gtk_widget_show_all (dialogue);
}
gtk_widget_show (dialogue);
break;
case 1: // hide the dialogue
gtk_widget_hide (dialogue);
break;
case 2: // dialogue has been destroyed, record
dialogue = NULL;
break;
}
}
int
main (int argc, char **argv)
{
GtkWidget *mainWin, *button;
gtk_init (&argc, &argv);
mainWin = gtk_window_new (GTK_WINDOW_TOPLEVEL);
g_signal_connect (mainWin, "destroy", G_CALLBACK (gtk_main_quit), NULL);
button = gtk_button_new_with_label ("Dialogue");
g_signal_connect ((button), "clicked", G_CALLBACK (doDialogue), &nums[0]);
gtk_container_add (GTK_CONTAINER (mainWin), button);
gtk_window_set_default_size ( GTK_WINDOW (mainWin), 250, 250);
gtk_widget_show_all (mainWin);
gtk_main ();
}
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: portable socket wrappers
On 7/4/07, Baurzhan Ismagulov <[EMAIL PROTECTED]> wrote: > * SDL -- After a quick look at the docs I couldn't see socket functions. You need SDL net, though I don't know if it had what you needed: http://www.libsdl.org/projects/SDL_net/ ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Learn GTK
On 7/25/07, Michael L Torrie <[EMAIL PROTECTED]> wrote: > Years ago I bought a book on developing (in C) with GTK+ 1.2 and it was > immensely helpful. So a book that deals with GTK+ 2.x would probably be > useful and illustrative. I have a copy of The Official GNOME 2 Developer's Guide and it's very good, though it's starting to become a little dated: http://www.amazon.com/Official-GNOME-Developers-Guide/dp/1593270305 There's are chapters on glib, gobject and gtk. > These days I still do some programming in GTK in C and C++, most most of > it is now in Python. I've decided to program almost exclusively, where > possible, in python, writing modules in C or C++ as appropriate. > Certainly developing GUIs seems ideal for Python. ... also excellent advice. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
libexpat.dll?
I've been following Tor's instructions for setting up a GTK build environment on windows and hit a problem: http://www.gimp.org/~tml/gimp/win32/downloads.html the libfontconfig-1.dll seems to link to something called libexpat.dll (as discovered by dependency walker), whereas the expat.zip that page links to only includes xmlparse.dll. I copied xmlparse.dll to libexpat.dll and it seems to work, but I wonder if that's right. Is libexpat.dll part of expat2? Google is failing me :( John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: libexpat.dll?
On 7/27/07, Tor Lillqvist <[EMAIL PROTECTED]> wrote: > Have you > noticed if some other binary I distribute requires xmlparse.dll and > not libexpat.dll? That's a good question - I'll check on Monday when I'm back at the windows machine. > libexpat.dll can be found at least in > http://ftp.gnome.org/pub/GNOME/binaries/win32/dependencies/expat-2.0.0.zip > . That zip archive is (I assume) just a repackaging by me, but I can't > recall where it originally is from. James Clark's page > http://www.jclark.com/xml/expat.html mentions only expat version > 1.2. Expat 2.0 is probably maintained by somebody else? I found a 2.01 expat on sourceforge, but it installed as a .exe which I'm too chicken to touch :-( Perhaps that include libexpat.dll? I later installed the gtk runtime and noticed there's a libexpat.dll in there. I copied that to my build area and all seems OK. I don't know if that's the same libexpat that you have above. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How to clear pending events?
On 8/27/07, Andrew E. Makeev <[EMAIL PROTECTED]> wrote: > When GUI-objects are destroyed, Glib::Dispatcher notifiers are destroyed > as well, but it happens before MAIN-LOOP actually reads all events those > were stored by notifiers. So, application crashes, when trying to access > data from Glib::DispatchNotifier structure. I have a similar thing in my (plain C) application. A set of background threads calculate image tiles for display. If an image display window is destroyed, I need to not respond to any more tile repaints from the background. My solution was simply to keep a list of valid tile generators and for my GUI thread to check each incoming tile's source. If it sees an event coming from a dead tile generator, it discards it. This is potentially crashable if an address is reused: a tile generator with a pending tile might be destroyed and a new one then made which happened to be at the same point in memory as the old one. This hasn't been a problem for me, since tile generators are only made much later, after the queue will have cleared. I guess if this is a problem you'd need the data generators to track their pending requests and cancel them all on destroy. This should be easy if you use g_idle_add() rather than Glib::Dispatcher. (I hope I've understood your problem) John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_option_context_parse under cron execution
On 10/3/07, Richard Boaz <[EMAIL PROTECTED]> wrote: > 1) why does g_option_context_parse() fail when executed under cron? > 2) why is there no error set on this failure? I just tried and it works fine for me. I added this with "crontab -e": 50 * * * * /home/john/vips/bin/run-nip2.sh --version > /tmp/nip.out run-nip2.sh is a wrapper script that sets LD_LIBRARY_PATH and friends so my app picks up the environment it expects. I think the error must lie elsewhere, though I'm not sure exactly where. Can you make a tiny standalone main.c that shows your problem? John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_option_context_parse under cron execution
On 10/3/07, Richard Boaz <[EMAIL PROTECTED]> wrote: > as indicated in the documentation example. Looking into the details of > the call gtk_get_option_group(TRUE), TRUE is an indication that the > default display should be opened when parsing the command line. > > So under cron, this fails, naturally. You're right, you'd expect this to set the error to "can't open display" or somesuch. Perhaps you could file a bug on that? It sounds like it should be an easy thing to fix if you have some time spare. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: glib main loop concept
On 10/2/07, Christian Buennig <[EMAIL PROTECTED]> wrote: > * Do main loops exist per process or per thread? > If I start a main loop in one thread (A) and add an IO watch in > another thread (B), does this watch get added to the main loop of the > thread A or B ? Each process can have one or more GMainContext. A context holds a set of IO watches, timeouts, callbacks, etc. There's a default context, which is generally the only context. If you use the convenience functions g_timeout_add() etc., they will automatically add to the default context. You'll need to roll up your own timeout_add() (or whatever) if you want to add to a different context. Each context can have one or more main loops. These main loops are not active at the same time, instead they nest in a stack with only the top one active. GTK uses nested main loops to handle modal dialogs. I imagine the context and all the main loops for that context have to be created and run in a single thread, but I don't know. It would certainly reduce confusion if they were. So to answer your question, if you have a main loop running in thread (A) and add an IO watch from thread (B), the callback on input arriving will be called by (A). Unless you go to a lot of trouble to add your watch to the non-default context. > * If there is only one main loop (regardless of per thread or per > process), why the function g_main_loop_new()? This is for the nesting feature. > * What's the purpose of the parameter 'is_running' in > g_main_loop_new() ? When should I set it to TRUE and when to FALSE? No idea :) I guess you should leave it FALSE and rely on g_main_loop_run() to turn this on for you. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: glib main loop concept
On 10/3/07, Christian Buennig <[EMAIL PROTECTED]> wrote: > I want to add IO watches to the default context in a library. Apps using > the library may decide to start a main loop themselves (in the default > context) or to let the library do this. Of course they could tell the > library somehow if there already is a running main loop in the default > context, but it would be nice if the library could detect this itself. I'm not sure this is a good idea. I think a library has no place starting main loops, unless they are completely isolated from the (possible) application main loop. You are likely to cause confusion and distress. A main loop should be started from an application's main() and nowhere else (except for nested calls I guess). I recommend you just add your IO watches to the default context (or maybe have a parameter for context-to-add-the-watch-to, in the way that glib does) and say in your documentation that the library user is responsible for calling g_main_loop_run() or whatever. (not that I'm a great expert on this) John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: menu accelerators not working
On 10/30/07, Philip Tricca <[EMAIL PROTECTED]> wrote: > >> I'm using the GtkUIManager to build my menus from GtkActionEntrys and > >> an > >> xml description. Everything works great except for the accelerators. > >> I > >> can't seem to get them working at all, even the stock quit. Have you added the accel group to the window? You need: accel_group = gtk_ui_manager_get_accel_group( mainw->ui_manager ); gtk_window_add_accel_group( GTK_WINDOW( mainw ), accel_group ); For example, search in: http://vips.svn.sourceforge.net/viewvc/vips/nip2/trunk/src/program.c?view=markup for accel for some boilerplate. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How can I emulate a mouse click event at a specific location in my code?
Hi, On 11/8/07, ying lcs <[EMAIL PROTECTED]> wrote: > How can I emulate a mouse click event at a specific location (x,y)in > my code so that my GTK application will response to it as if a user > has clicked at the same location? You can use the XTest extension to do this. Here's a bot that plays the flash game "zookeeper" by grabbing the screen, analysing the board, and generating click events: http://cima.ng-london.org.uk/~john/zoobot.c search for send_click(). John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How can I emulate a mouse click event at a specific location in my code?
On 11/9/07, ying lcs <[EMAIL PROTECTED]> wrote: > Thank you. But i only have ' GtkWidget *', How can I get a get a > GdkWindow in order to use XTestFakeMotionEvent? You can use gtk_widget_get_toplevel() to get the GtkWindow that's enclosing your GtkWidget, then (as long as the window is realized), use GTK_WINDOW()->window to get the GdkWindow. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GDK_POINTER_MOTION_HINT_MASK has no effect
On Nov 27, 2007 2:27 AM, Stewart Weiss <[EMAIL PROTECTED]> wrote:
> Does anyone know what the real semantics are, and when is_hint is true?
Here's a complete small program that shows mouse events (with hints)
for a drawing area.
--
/* compile with
* gcc -g -Wall try32.c `pkg-config gtk+-2.0 --cflags --libs`
*/
#include
#include
static gboolean
event_cb (GtkWidget * widget, GdkEvent * ev)
{
gboolean handled;
handled = FALSE;
switch (ev->type)
{
case GDK_BUTTON_PRESS:
printf ("button %d press\n", ev->button.button);
handled = TRUE;
break;
case GDK_BUTTON_RELEASE:
printf ("button %d release\n", ev->button.button);
handled = TRUE;
break;
case GDK_MOTION_NOTIFY:
/* A hint? Read the position to get the latest value.
*/
if (ev->motion.is_hint)
{
GdkDisplay *display = gtk_widget_get_display (widget);
GdkScreen *screen;
int x_root, y_root;
printf ("seen a hint!\n");
gdk_display_get_pointer (display, &screen, &x_root, &y_root, NULL);
ev->motion.x_root = x_root;
ev->motion.y_root = y_root;
}
printf ("motion at %g x %g\n", ev->motion.x_root, ev->motion.y_root);
if (ev->motion.state & GDK_BUTTON1_MASK)
printf ("(and btn1 held down)\n");
if (ev->motion.state & GDK_BUTTON2_MASK)
printf ("(and btn2 held down)\n");
handled = TRUE;
break;
default:
break;
}
return (handled);
}
int
main (int argc, char **argv)
{
GtkWidget *win;
GtkWidget *area;
gtk_init (&argc, &argv);
win = gtk_window_new (GTK_WINDOW_TOPLEVEL);
g_signal_connect (win, "destroy", G_CALLBACK (gtk_main_quit), NULL);
area = gtk_drawing_area_new ();
gtk_widget_add_events (GTK_WIDGET (area),
GDK_POINTER_MOTION_MASK |
GDK_POINTER_MOTION_HINT_MASK |
GDK_BUTTON_PRESS_MASK |
GDK_BUTTON_RELEASE_MASK);
gtk_signal_connect_after (GTK_OBJECT (area), "event",
GTK_SIGNAL_FUNC (event_cb), NULL);
gtk_container_add (GTK_CONTAINER (win), area);
gtk_window_set_default_size (GTK_WINDOW (win), 250, 250);
gtk_widget_show_all (win);
gtk_main ();
return (0);
}
You get output like:
seen a hint!
motion at 1367 x 446
seen a hint!
motion at 1368 x 446
button 1 press
seen a hint!
motion at 1368 x 447
(and btn1 held down)
button 2 press
seen a hint!
motion at 1368 x 448
(and btn1 held down)
(and btn2 held down)
John
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GDK_POINTER_MOTION_HINT_MASK has no effect
On Nov 28, 2007 2:44 AM, Stewart Weiss <[EMAIL PROTECTED]> wrote: > I am running this on a Windows box with gtk+ 2.12 installed. Ah, OK. I don't think the windows backend uses the is_hint field, so you can just ignore it. It's because X11 is asynchronous. The window server keeps on trucking (and sending a lot of highly detailed mouse tracking information) even if your program pauses for a moment. As a result, you can get a backlog of mouse events and this causes very annoying lag in your application. The idea of is_hint is that when your program comes back to check for mouse events it just sees an is_hint event, meaning "a lot of mouse action has taken place, read the pointer explicitly to get the latest". So you get asynchronous mouse evnts and no lag. Windows is synchronous (the server can never run ahead of the application) so it doesn;t need this mechanism. Just ignnore is_hint and it'll work fine. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GDK_POINTER_MOTION_HINT_MASK has no effect
On Nov 28, 2007 4:27 AM, Stewart Weiss <[EMAIL PROTECTED]> wrote: > Aha! I did not know that I could configure the GC to draw using > various functions of the source and dest pixels values. Thanks ! I posted a mail about rubberbanding a couple of months ago: http://mail.gnome.org/archives/gtk-app-devel-list/2007-October/msg7.html Might be helpful. In my opinion, you should structure your program like this: - appstate should have a flag for "displaying rubberband line", plus start/end points - in your expose handler, first draw the background for the exposed area, then draw the rubberband liine on top - in your button-press handler, set the rubber band flag and note the start position - in mouse-motion, if rubberband is set and this is a button drag event, queue a draw for the old position of the rubber band line, update appstate with the new position, and queue a draw there too - in button-release, unset the rubber flag and queue a draw for the position of the line John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GDK_POINTER_MOTION_HINT_MASK has no effect
On 11/29/07, Stewart Weiss <[EMAIL PROTECTED]> wrote: > This also explains why my solution for drawing the line worked > reasonably well on Windows but on Linux, the old lines did not get > erased. So I guess I have to resort to conditional compilation > directives to make it work in both environments. The code I pasted will work well on windows and on linux, you shouldn't need to do any conditional compilation. The line drawing problems are for other reasons ... you should do all drawing in the expose handler. If I get a moment, I'll try to make a small rubber-band example for you. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GDK_POINTER_MOTION_HINT_MASK has no effect
On 11/29/07, Stewart Weiss <[EMAIL PROTECTED]> wrote: > 1. I am assuming that when I queue a draw for the old position of > the rubberbanded line, I am using XOR to draw it, so that it is in > effect, an erasing, right? Actually, I'd suggest using a plain draw rather than an XOR. XOR rubberbanding works if you can treat your display as something you can draw incrementally, that is, you know what is on the screen and therefore you know whether this XOR draw will set or unset a line. This is often not the case, especially in a complex application. Instead, you should think of your window as being composed from a number of separate layers (like photoshop layers), and that on an expose you should completely repaint that section of the window by drawing all layers from the back forwards. > Right now, my function to draw a line uses gdk_draw_line into the pixmap > and then calls gdk_window_invalidate_rect to send the expose event later. > If I actually call the gdk_draw_line in the expose event handler, directly > into the pixmap, would I then use gdk_draw_drawable to copy the pixmap into > the window? I know I can't queue a drawing event in the handler or else > I have an infinite indirect recursive loop. Is this how? Is this a raster drawing program, or a vector one? Assuming it's raster, you should have two separate data structures. Keep a large image around which has the current state of your user's image. Only drawing operations go into this, no rubberbanding. This is your background layer. Rubberband operations are in another layer which floats on top of this. On an expose, use your background image to paint the exposed pixels. Then, if there's a rubber band active at the moment and if the bounding box of the rubber band intersects the expose, draw that as well on top of the image. If you're curious, my app is here: http://www.vips.ecs.soton.ac.uk To see the rubberbanding, load an image, doubleclick the thumbnail to get a view window, then hold down CTRL and click and drag up and left to get a vector, down and right to get a region, just click to get a point, or drag from a ruler to get a guide. If you try resizing outside the edge of the window, the window will scroll in the background. You can move objects around by dragging on their names. Hopefully you'll see all the objects, including the animated ones, float over each other smoothly. There's a simple paintbox on the View menu which also does some rubberbanding with some of the tools. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: To Draw | ! To Draw in an Expose Handler
I thought of another point: soon (please!) gtk will come with a nice cairo canvas widget which ought to be able to replace the drawing code of a lot of applications. All of this messy detail and noise will just vanish and we won't have to worry about retained vs. non-retained mode. The nastiest thing most apps might have to do is to roll a few custom canvas items. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: To Draw | ! To Draw in an Expose Handler
On 11/30/07, Richard Boaz <[EMAIL PROTECTED]> wrote: > Sorry, I can't think of a single application responsible for making its > own drawings by hand where option 2 is not crazy hard. (If anybody has an > example of this in real-world application, please post?) My 2p: Most applications let you zoom the display, or at least have a main window which is a viewport into a much larger document. There's no way you can keep a pixmap for the whole thing (imagine a word processor, or an image editor with the display zoomed in 10 times), so you will always have to have some mechanism for clipping your document view against a viewport. Once you have this, it's trivial to clip against each expose event rather than the viewport, and once you do that, you don't need a backing pixmap. No pixmap means less memory use (X server memory is still constrained, so this is a win), and the slight loss in speed is more than made up for (IMO) by the drop in latency due to not having to manage a large memory object. My app, for example, is an image processing package. The images are very expensive to generate, so I keep parts of them around (in a tile cache) on the client side. On an expose, I extract the set of rects for the damaged area from the image and paint them to the screen, then I loop over all the image annotations and for each one test for bounding-box-of-expose-intersects-bounding-box-of-annotation. If there is an intersection, I redraw that annotation. I will only ever have a few hundred annotations, so I can just loop over a list. If I had 900m objects (eeek) then yes, I'd need either a very fast culling algorithm (quad trees or some such I suppose) or a cache of pre-rendered views I could paste from. Even in this case I would still compose the window in expose: add rubber-band objects, annotations, axies, etc. But I think very few applications have to deal with datasets of this size. (though my image processing app can do multi-gigabyte images, so maybe that is of a similar scale, if you consider each pixel to be a separate object) John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Container performance
On 12/1/07, digicapt - gtk dev <[EMAIL PROTECTED]> wrote: > If you try following code, you'll see that filling a container with 4000 > entries (first button) is about 20 times slower than filling a container with > 4000 labels (second button) : 1 seconds for labels on my PC, 20 seconds for > the edits. Entries are just much, much more complicated. Creating 4000 edit widgets is always going to be slow. What you need to do is use a treeview instead, and have a editable as a cell renderer. Now it will display like a label (it should be even quicker than the label case), but when you click on an item, it will turn into an edit widget for the time that you are using it. Read about it here: http://library.gnome.org/devel/gtk/unstable/TreeWidgetObjects.html John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GDK_POINTER_MOTION_HINT_MASK has no effect
Hi again Stewart,
On Dec 2, 2007 5:12 AM, Stewart Weiss <[EMAIL PROTECTED]> wrote:
> I do still have one question about a specific suggestion that you made in
> this thread, below:
I've just spent a while writing you a sample rubberband program and
now I come to post it I see Richard has done the same! Ah well,
perhaps you can't have too much sample code. Mine is a little
different from Richard's, so I'm going to paste it here anyway.
Richard's is a retained mode program. He keeps a complete bitmap for
his display in an offscreen buffer and does all animation there. On
expose, he just copies the relevant part to the screen.
Mine is a list-mode program. I have no backing pixmaps: I do all
drawing in the expose handler. The display only exists as a few
numbers for the positions of the images and the rubberband line.
The two styles are probably appropriate for different type of program
(as I guess our discussion showed). I suppose most programs will fall
somewhere inbetween these two.
If you try it out, run with something like:
./a.out ~/pics/*.jpg
(or wherever you keep some pictures). It creates a window with the
first 10 images bouncing around and lets you rubberband a white line
that floats on top. It has the following nice properties:
- the images animate smoothly, they float over each other in a clearly
defined stacking order, and the rubberband line is always on top
- the animation routine is very simple, since it does no drawing
- because drawing and animation are decoupled, the speed stays
constant even under load (the framerate just drops)
- resizing is fluid and doesn't interrupt the animation, since there's
no pixmap to rebuild
- it uses motion hints so the rubberband doesn't lag
-
/* compile with
* gcc -g -Wall try144.c `pkg-config gtk+-2.0 --cflags --libs`
*/
#include
#include
#include
#define MAX_IMAGES (10)
/* Application state.
*/
typedef struct _App
{
/* Drawingarea we draw to.
*/
GtkWidget *drawing;
/* Loaded images.
*/
GdkPixbuf *image[MAX_IMAGES];
int n;
/* Bounding box and velocity of each image.
*/
GdkRectangle area[MAX_IMAGES];
int u[MAX_IMAGES];
int v[MAX_IMAGES];
/* Rubberband state.
*/
gboolean rubber;
int x1, y1;
int x2, y2;
GdkRectangle box; /* Bounding box of rubberband line */
} App;
static void
repaint_rect (App * app, GdkRectangle * rect)
{
gtk_widget_queue_draw_area (app->drawing,
rect->x, rect->y, rect->width, rect->height);
}
static gboolean
event_cb (GtkWidget * widget, GdkEvent * ev, App * app)
{
gboolean handled;
handled = FALSE;
switch (ev->type)
{
case GDK_BUTTON_PRESS:
if (ev->button.button == 1)
{
app->rubber = TRUE;
app->x1 = app->x2 = ev->button.x;
app->y1 = app->y2 = ev->button.y;
handled = TRUE;
}
break;
case GDK_BUTTON_RELEASE:
if (ev->button.button == 1)
{
app->rubber = FALSE;
handled = TRUE;
}
break;
case GDK_MOTION_NOTIFY:
if (ev->motion.state & GDK_BUTTON1_MASK && app->rubber)
{
/* A hint? Read the position to get the latest value.
*/
if (ev->motion.is_hint)
{
int x, y;
gdk_window_get_pointer (widget->window, &x, &y, NULL);
ev->motion.x = x;
ev->motion.y = y;
}
app->x2 = ev->motion.x;
app->y2 = ev->motion.y;
/* Queue a repaint at the old position to wipe out where te line
* was.
*/
repaint_rect (app, &app->box);
handled = TRUE;
}
break;
default:
break;
}
/* If we handled the event, update the bounding box for the rubberband
* line and queue a repaint.
*/
if (handled)
{
app->box.x = MIN (app->x1, app->x2);
app->box.width = MAX (app->x1, app->x2) - app->box.x;
app->box.y = MIN (app->y1, app->y2);
app->box.height = MAX (app->y1, app->y2) - app->box.y;
repaint_rect (app, &app->box);
}
return handled;
}
static gboolean
expose_cb (GtkDrawingArea * area, GdkEventExpose * event, App * app)
{
int i;
for (i = 0; i < app->n; i++)
{
GdkRectangle repaint;
if (gdk_rectangle_intersect (&event->area, &app->area[i], &repaint))
gdk_pixbuf_render_to_drawable (app->image[i],
GTK_WIDGET (area)->window,
GTK_WIDGET (area)->style->white_gc,
repaint.x - app->area[i].x,
repaint.y - app->area[i].y,
repaint.x, repaint.y, repaint.width,
repaint.height,
GDK_RGB_DITHER_NORMAL, 0, 0);
}
if (app->rubber && gdk_rectangle_inte
Re: GDK_POINTER_MOTION_HINT_MASK has no effect
Last post on this I swear, but I thought of another simple improvement.
GTK performs expose event compression, that is, when it sends an
expose to your program, the expose is the union of all the expose
events which the window system generated since your app last saw
expose. GTK computes the smallest set of non-overlapping rectangles
which are damaged (in event->region), and also the bounding box of
that set of rectangles (in event->area).
In the code I posted previously I was just using the bounding box of
the rects. If you have a large number of images moving around, this
will usually be almost the entire display. Very inefficient! Here's a
new version of the expose handler which extracts the list of the exact
damaged areas and only repaints those. This saves about 20% CPU on my
desktop machine, and would save much more if I used small images.
-
static gboolean
expose_cb (GtkDrawingArea * area, GdkEventExpose * event, App * app)
{
GdkRectangle *rect;
int i, j, n;
gdk_region_get_rectangles (event->region, &rect, &n);
for (j = 0; j < n; j++)
{
for (i = 0; i < app->n; i++)
{
GdkRectangle repaint;
if (gdk_rectangle_intersect (&rect[j], &app->area[i], &repaint))
gdk_pixbuf_render_to_drawable (app->image[i],
GTK_WIDGET (area)->window,
GTK_WIDGET (area)->style->white_gc,
repaint.x - app->area[i].x,
repaint.y - app->area[i].y,
repaint.x, repaint.y,
repaint.width, repaint.height,
GDK_RGB_DITHER_NORMAL, 0, 0);
}
if (app->rubber && gdk_rectangle_intersect (&rect[j], &app->box, NULL))
gdk_draw_line (GTK_WIDGET (area)->window,
GTK_WIDGET (area)->style->white_gc,
app->x1, app->y1, app->x2, app->y2);
}
g_free (rect);
return TRUE;
}
-
John
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GtkTable isn't updating properly
On 18/02/2008, Lindley M French <[EMAIL PROTECTED]> wrote: > I have a GtkTable containing labels and entries. I don't want all label/entry > pairs to be visible at all times. To control this, I use gtk_widget_show/hide > on the labels and entries of a given row. > > Previously, this worked just fine. After I refactored slightly, it no longer > does, and I cannot pin down the reason. I find I have to call gtk_widget_queue_resize() on the widget enclosing the table after a table's member changes size. I'd try putting in a few of them after you change the visibility of your labels and entries. If your table is large, you'll also find that having many gtkentries is very slow. If possible, it's much faster to create and destroy them rather than to show and hide. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Questions about low level programming.
On 29/03/2008, Diego Jacobi <[EMAIL PROTECTED]> wrote: > Those device are mostly programmed in assembler and or C/C++. > Just to say some of this devices are 8085, 8086, freescale(motorola) > microcontrollers, etc. > > We have to use them to manually build a computer model and this includes > programming an OS to accomplish certain tasks. Of course, it wont be a > linux, and it wont fit inside those roms. > > But i was thinking on the possibility to use glib to make it much easier to > build this OS and handle whatever data is required by the electronic > project. I've done projects like this (though I think we used a 68000). I'm not sure there's much of glib you can directly reuse. I would copy-paste basic things like the data structure code (hash table, linked list, etc.), but the rest, particularly the main loop and the event system, I think will not be very useful. > If i need a rutine to turn on a pin or to write a word to a port > sincronously (like turn on/off a LED every 2 seconds) i have to take into > account the amount of clocks in the routine wasting a lot of processing time > doing lots of sleep(..), if i use timeout_add it will be much more > efficient. But in some cases an sleep like routine is required on this kind > of processes, i dont know why there isnt one on glib to be able to do a > sleep and pause a function execution but continue doing MainLoop stuff and > not break the event system. Sorry, no. Make your own tiny event system. You only need something very simple, you could do it in less than 100 lines of code. I guess you have a timer on the board somewhere? John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk_widget_destroy not freeing memory
2008/4/18 Harinandan S <[EMAIL PROTECTED]>: > allocated. I have a main window which creates sub windows. While returning > back to main window from sub window, i destroy the sub window. I observed > that memory increased gradually by 2% when a sub window is created and > memory did not decrease after destroying it. After several opening and > closing of windows, OS killed the process saying "out of memory". > > Am i not using the correct way to destroy a window and its children? That should work. I would guess something else is not being freed. Try running your program under valgrind. It will be able to tell you exactly where the memory that is not being freed was allocated. Something like: $ export G_DEBUG=gc-friendly $ export G_SLICE=always-malloc $ valgrind --leak-check=yes myprogram arg1 arg2 arg3 ... John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Glib hashtable memory leak
2008/4/30 Ovidiu Gheorghies <[EMAIL PROTECTED]>: > The following program appears to leak memory according to mtrace: glib has it's own allocator and this is confusing mtrace. Try setting: export G_DEBUG=gc-friendly export G_SLICE=always-malloc before running your program. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: checking for memory leaks in gtk
2008/5/2 Ionutz Borcoman <[EMAIL PROTECTED]>: > I'm trying to find a way to test for memory leaks in GTK+ apps. I've created > a > very simple HelloWorld app and profiled it with valgrind. > > I have run valgrind as: > > G_SLICE=always-malloc G_DEBUG=gc-friendly \ > valgrind --tool=memcheck --leak-check=full --leak-resolution=high \ > -num-callers=20 ./helloworld &> helloworld.out That sounds OK, though you will get a lot of output. I generally just use G_SLICE=always-malloc G_DEBUG=gc-friendly \ valgrind --tool=memcheck ./helloworld &> helloworld.out You could look at memprof as well, it's a bit basic compared to valgrind, but programs run at (almost) full speed, it has a nice GUI, and it shows your memory use as the program runs. > ==15450== LEAK SUMMARY: > ==15450==definitely lost: 429 bytes in 5 blocks. > ==15450==indirectly lost: 180 bytes in 13 blocks. > ==15450== possibly lost: 800 bytes in 20 blocks. > ==15450==still reachable: 362,035 bytes in 9,875 blocks. > ==15450== suppressed: 0 bytes in 0 blocks. > > I'm surprised that even for such a simple program I still get memory leaks. > So > I'm probably doing something wrong. The gtype system doesn't free a lot of stuff on exit (there's no point), so you will see reported leaks. I believe xlib fails to free a number of singleton classes as well. But these leaks won't grow over time, so they are not really leaks. When I valgrind my app and check for leaks, I let it run for a while before quitting, then check the output for repeated allocations. If I see the same thing being allocated several times and not freed I know I probably have a leak. I have stumbled upon a few leaks in GTK over the years (and submitted patches, heh), but really rather few. You can write large programs with GTK and have them run for a very long time. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: checking for memory leaks in gtk
2008/5/2 Ionutz Borcoman <[EMAIL PROTECTED]>: > Actually my own leak are my greatest concern. The problem is that having > those > leaks reported because of how glib caches data makes debugging your own code > harder. > > Any recipe to easily spot or isolate your allocations/dealocations from those > from GTK/Glib? > > How do you know the leak is because I haven't freed the memory or because > I've > freed it, but Glib hasn't? Here's an example. I started my app (about 250,000 line of C, so quite large), did a few things, and shut it down again. Run with: G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --leak-check=yes nip2 &> leaklog It's about 500 lines of output, so I won't paste it here. Looking at leaklog, I have a lot of crap at the start with 'invalid read' in ld.so as my program is linked (I really need to update my suppressions file), then the first reported leak is this (trimmed a bit): ==18092== 292 (52 direct, 240 indirect) bytes in 1 blocks are definitely lost in loss record 59 of 199 ==18092==by 0xA77C240: (within /lib/libc-2.7.so) ==18092==by 0xA77CAFE: __nss_database_lookup (in /lib/libc-2.7.so) ==18092==by 0xA730A40: getpwnam_r (in /lib/libc-2.7.so) ==18092==by 0xA21ECDF: (within /usr/lib/libglib-2.0.so.0.1600.3) ==18092==by 0xA220444: g_get_home_dir (in /usr/lib/libglib-2.0.so.0.1600.3) This is clearly some platform nonsense. The next one (again, trimmed a bit) is: ==18092== 98 bytes in 6 blocks are definitely lost in loss record 73 of 199 ==18092==by 0x9953DC3: FcStrCopy (in /usr/lib/libfontconfig.so.1.3.0) ==18092==by 0x995705A: (within /usr/lib/libfontconfig.so.1.3.0) ==18092==by 0xD13EFEA: (within /usr/lib/libexpat.so.1.5.2) ==18092==by 0xD136000: XML_ParseBuffer (in /usr/lib/libexpat.so.1.5.2) ==18092==by 0x9956533: FcConfigParseAndLoad (in /usr/lib/libfontconfig.so.1.3.0) ==18092==by 0x9956623: (within /usr/lib/libfontconfig.so.1.3.0) Obviously something to do with the fontconfig parser. Next is: ==18092== 729 (360 direct, 369 indirect) bytes in 3 blocks are definitely lost in loss record 118 of 199 ==18092==by 0x6DECEF6: xmlNewText (in /usr/lib/libxml2.so.2.6.31) ==18092==by 0x5341E3: prettify_tree_sub (util.c:438) ==18092==by 0x5342AE: prettify_tree (util.c:467) ==18092==by 0x45F8A5: filemodel_save_all_xml (filemodel.c:282) ==18092==by 0x45FACA: filemodel_real_save_all (filemodel.c:338) ==18092==by 0x545487: workspace_save_all (workspace.c:1271) ==18092==by 0x45F27B: filemodel_save_all (filemodel.c:128) ==18092==by 0x54387C: workspace_checkmark_timeout (workspace.c:637) ==18092==by 0xA1EF98A: (within /usr/lib/libglib-2.0.so.0.1600.3) ==18092==by 0xA1EF261: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.1600.3) ==18092==by 0xA1F2515: (within /usr/lib/libglib-2.0.so.0.1600.3) And this is one of mine. I know about this one: for debugging, I paste some whitespace into my xml savefiles to make then easier to read and don't bother freeing the strings (it's just debugging code). This is clearly one of mine, since the calls are all rooted in my source files. A useful trick is to run a gtk 'hello world' program under valgrind with the --gen-suppressions flag. Assuming you don't have any leaks in your gtk hello-world program (!!), the generated suppressions file will then make valgrind remove all the system and background leaks and errors from your reports. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: checking for memory leaks in gtk
2008/5/14 Harinandan S <[EMAIL PROTECTED]>: > I observed continuous accumulation of memory while running GTK over > DirectFB on MontaVista linux on TI Davinci. I also observed > significant memory accumulation while running GTK-win32 on Windows XP. > But to my surprise there is no accumulation of memory > on GTK-X window running on RHEL 4 on x86. I'm only speculating, but some resources (server-side images or pixmaps, for example) are kept by the X server and won't show significant memuse for your application in "top". With other backends, like win32 or directfb, you may well see these objects in your own memory space. I'd suggest running with valgrind and looking for leaks with that. For what it's worth, my largish project (250 kloc or so) does not seem to leak significantly under linux or windows. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: checking for memory leaks in gtk
2008/5/14 Harinandan S <[EMAIL PROTECTED]>:
> I dont have any pixmaps or images in my sample application.
You don't directly, but the theme engine you are using might. I tried
your program under valgrind and it reports no leaks, so I imagine you
are OK. I don't have a directfb install or a windows machine handy
though, so I can't test there.
> Am i calling the correct APIs? Help is greatly appreciated. Somehow i
> feel destroy is not happening properly!
I think you're OK. I'd change a few things on style grounds though:
void
on_close_clicked (GtkButton * button, gpointer user_data)
{
GtkWidget *window = GTK_WIDGET (user_data);
gtk_widget_destroy (window);
}
I'd use a GTK_WIDGET() cast here, it'll check the pointer for you, much safer.
You shouldn't use gtkfixed unless you REALLY have to. gtk has a large
set of layout widgets that can do all this for you automatically and
attractively. As a bonus, when someone translates your application and
the sizes of all the text strings changes, you won't need to
reposition everything.
gtk_button_new_with_mnemonic () is a strange one to use, that's really
for menus. gtk_button_new_from_stock () might be better.
John
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: checking for memory leaks in gtk
2008/5/14 Harinandan S <[EMAIL PROTECTED]>:
> When i ran it under valgrind with G_SLICE=always-malloc G_DEBUG=gc_friendly\
> valgrind --tool=memcheck --leak-check=yes ./a.out &>leak.log
>
> I got these leaks reported.
Those are harmless singleton objects (I think), they are not leaks.
> My main concern is running this on DirectFB platform. Its accumulating
> memory completely. I see no decrease in memory usage when second
> window is destroyed.
Is that valgrind output for the directfb backend? As I'm sure you
know, apps never (almost never) shrink. If you
open/close/open/close/open/close and see a steady increase in memuse
that does sound like a leak. But that's something valgrind should be
able to help you with.
Here's a version of your program that uses a timeout to pop the popup
up and down repeatedly. I tried it on windows and linux and saw no
steady increase in memuse, as least as reported by the pretty useless
task manager.
I don't have a directfb install to test it on, sadly.
John
/* compile with
* gcc try39.c `pkg-config gtk+-2.0 --cflags --libs`
*/
#include
void
on_close_clicked (GtkButton * button, gpointer user_data)
{
GtkWidget *win = GTK_WIDGET (user_data);
gtk_widget_destroy (win);
}
static gboolean
on_close_timeout (gpointer user_data)
{
GtkWidget *win = GTK_WIDGET (user_data);
gtk_widget_destroy (win);
return FALSE;
}
GtkWidget *
create_window2 (GtkWidget * parent, gboolean self_close)
{
GtkWidget *win;
GtkWidget *align;
GtkWidget *but;
win = gtk_window_new (GTK_WINDOW_POPUP);
gtk_window_set_default_size (GTK_WINDOW (win), 100, 100);
gtk_window_set_transient_for (GTK_WINDOW (win), GTK_WINDOW (parent));
gtk_window_set_position (GTK_WINDOW (win), GTK_WIN_POS_CENTER_ON_PARENT);
align = gtk_alignment_new (0.5, 0.5, 0, 0);
gtk_container_add (GTK_CONTAINER (win), align);
gtk_widget_show (align);
but = gtk_button_new_from_stock (GTK_STOCK_CLOSE);
gtk_container_add (GTK_CONTAINER (align), but);
if (self_close)
g_timeout_add (50, (GSourceFunc) on_close_timeout, win);
else
g_signal_connect (but, "clicked", G_CALLBACK (on_close_clicked), win);
gtk_widget_show (but);
return win;
}
void
on_open_clicked (GtkButton * button, gpointer user_data)
{
GtkWidget *win = GTK_WIDGET (user_data);
GtkWidget *window2;
window2 = create_window2 (win, FALSE);
gtk_widget_show (window2);
}
static gboolean
on_open_timeout (gpointer user_data)
{
GtkWidget *win = GTK_WIDGET (user_data);
GtkWidget *window2;
window2 = create_window2 (win, TRUE);
gtk_widget_show (window2);
return TRUE;
}
GtkWidget *
create_window1 (void)
{
GtkWidget *win;
GtkWidget *but;
GtkWidget *align;
GtkWidget *hbox;
win = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_window_set_default_size (GTK_WINDOW (win), 200, 200);
align = gtk_alignment_new (0.5, 0.5, 0, 0);
gtk_container_add (GTK_CONTAINER (win), align);
gtk_widget_show (align);
hbox = gtk_hbox_new (FALSE, 2);
gtk_container_add (GTK_CONTAINER (align), hbox);
gtk_widget_show (hbox);
but = gtk_button_new_from_stock (GTK_STOCK_OPEN);
gtk_box_pack_start (GTK_BOX (hbox), but, FALSE, FALSE, 2);
g_signal_connect (but, "clicked", G_CALLBACK (on_open_clicked), win);
g_timeout_add (100, (GSourceFunc) on_open_timeout, win);
gtk_widget_show (but);
but = gtk_button_new_from_stock (GTK_STOCK_CLOSE);
gtk_box_pack_start (GTK_BOX (hbox), but, FALSE, FALSE, 2);
g_signal_connect (but, "clicked", G_CALLBACK (on_close_clicked), win);
gtk_widget_show (but);
return win;
}
int
main (int argc, char *argv[])
{
GtkWidget *window1;
gtk_init (&argc, &argv);
window1 = create_window1 ();
gtk_widget_show (window1);
g_signal_connect (window1, "destroy", G_CALLBACK (gtk_main_quit), NULL);
gtk_main ();
return 0;
}
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: checking for memory leaks in gtk
2008/5/19 Harinandan S <[EMAIL PROTECTED]>: > Anyway, I digged some more details about the leak. When i stepped > through the code i found that gdk_window_destroy_notify function in > gdkwindow-directfb.c which is called when the window is really gone is > not being called. > > I also found a quite old bug which exactly resembles what I am observing: > http://mail.gnome.org/archives/gtk-devel-list/2006-December/msg00048.html It does sound like a bug. I see you filed a report, I guess you just need to wait for a gtk-fb dev to see it. I guess you saw this page? http://www.directfb.org/wiki/index.php/Projects:GTK_on_DirectFB It has some build notes for gtk-fb John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: All-in-one bundle at http://www.gtk.org/download-windows.html
2008/5/24 Damon Register <[EMAIL PROTECTED]>: > configure:4058: checking for XML::Parser > configure:4064: error: XML::Parser perl module is required for intltool I can help here: I spent many unhappy hours trying to get the XML::Parser module working in the Perl that comes with msys. Success came by ignoring the msys perl and installing ActiveState Perl instead. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: All-in-one bundle at http://www.gtk.org/download-windows.html
2008/5/24 Damon Register <[EMAIL PROTECTED]>: > make[2]: Entering directory `/d/glade3-3.4.5/po' > file=`echo az | sed 's,.*/,,'`.gmo \ > && rm -f $file && -o $file az.po > /bin/sh: -o: command not found > make[2]: *** [az.gmo] Error 127 I think it's not found your msgfmt program. Check you have it installed. If you have it and it's not been found, try something like: GMSGFMT="/opt/local/bin/msgfmt" ./configure .. or wherever you have msgfmt installed. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How to make the gtk+ application run faster?
2008/5/28 Harinandan S <[EMAIL PROTECTED]>: > I am using GTK+2.12.2 on DirectFB on TI Davinci platform with 300MHz ARM > processor. I observe that my GTK application takes around a second to open a > window, and around a 700-800 ms to switch tabs. I have built it with O3 > optimization in release mode. > > How to speed up the application? Is there any way to build the libraries > with different options to make it faster? You can give the compiler options with something like: CFLAGS="-O3 -ffast-math -funroll-loops" ./configure ... You could try looking at the FP options, Pango (and maybe Cairo?) used to use a lot of floating point which caused performance problems on machines without FP support. Though I think this is supposed to have got a lot better recently. You could try gtk 2.8 (or was it 2.6? I forget), this was the last version before rendering switched to Cairo/Pango, so it should be easier on your hardware. You could check which theme you are using, obviously some are much 'heavier' than others. The built-in default theme is relatively light, I think. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Splash screen as widget
Hi,
2008/6/9 George Brink <[EMAIL PROTECTED]>:
> 1) I think command
>splash = MY_SPLASH(g_object_new(my_splash_get_type(), NULL));
> should create new window (since GtkWindow is a parent) but how can I set to
> this new window GTK_WINDOW_POPUP as GtkWindowType?
In your _init() function, do
gtk_window_set_type_hint( GTK_WINDOW( splash ),
GDK_WINDOW_TYPE_HINT_SPLASHSCREEN );
> 2) I am inheriting MySplash from GtkWindow:
> But when I am trying to cast MySplash as GtkWindow
> I get a run-time warning:
> GLib-GObject-WARNING **: invalid cast from `MySplash' to `GtkWindow'
Are you setting GtkWindow as the parent class in your type creator?
> 3) Each time label or progress bar is updated on splash screen, it should be
> updated on the real screen, so I define (by tutorial):
>while(gtk_events_pending()) {
>gtk_main_iteration();
>}
That's from a rather old tutorial, better to use:
while( g_main_context_iteration( NULL, FALSE ) )
;
> Also I am a confused, loop while(gtk_events_pending()) gtk_main_iteration();
> will run BEFORE gtk_main_loop(), Since splash screen always shown during
> initialization phase of application. Will this loop work?
Yes, should work fine.
Here's the splash class from my app, for what it's worth:
http://vips.svn.sourceforge.net/viewvc/vips/nip2/trunk/src/boxes.c?view=markup
search for 'splash'.
John
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Splash screen as widget
2008/6/11 George Brink <[EMAIL PROTECTED]>:
> By the way, why splash screen is not in the default set of library widgets?
> I believe it is very common thing for almost all modern applications...
There's one in GNOME, but it's not been pushed down into GTK. There
was a discussion about it, I seem to remember, but I forget why it was
resisted.
The HIG says that your app should start up quickly enough that it
doesn't need a splash screen, which is good advice, if not always
possible. GIMP still has a splash widget, heh.
> That rises another question: Tutorial I read, suggests to use
> g_type_register_static() with GTypeInfo structure instead of
> gtk_type_unique() with GtkTypeInfo. Author of tutorial does not explain why
> he prefer g_type_register_static() over gtk_type_unique(). I guess, first
The type system used to be in GTK, but for gtk2.0 it was moved down a
layer into glib (as the gobject library).
So the modern, recommended way is g_type_register_static() and
gtk_type_unique() is now just a compatibility stub. You still see it
sometimes in code that's been ported from gtk-1.2.
>>> while(gtk_events_pending()) {
>>> gtk_main_iteration();
>>> }
>>
>> That's from a rather old tutorial, better to use:
>>
>> while( g_main_context_iteration( NULL, FALSE ) )
>> ;
>
> Why is that better? One is for gtk events only, other also works with glib
> events?
Same reason: the main loop used to be part of gtk, but in the 2.0
series it's been pushed down into glib and the gtk functions are just
compatibility stubs.
John
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: dynamic accelerators
2008/7/29 Wesley Smith <[EMAIL PROTECTED]>:
> I'm trying to get runtime-settable accelerators to work with my app.
Have you added the accel group to the window? Also, I'd use UI manager
to make the abse set of menus, then hang extra run-time menus off that
if necessary.
The boilerplate is something like:
action_group = gtk_action_group_new( log_class->action_name );
gtk_action_group_set_translation_domain( action_group,
GETTEXT_PACKAGE );
gtk_action_group_add_actions( action_group,
log_class->actions, log_class->n_actions,
GTK_WINDOW( log ) );
gtk_action_group_add_toggle_actions( action_group,
log_class->toggle_actions, log_class->n_toggle_actions,
GTK_WINDOW( log ) );
ui_manager = gtk_ui_manager_new();
gtk_ui_manager_insert_action_group( ui_manager, action_group, 0 );
accel_group = gtk_ui_manager_get_accel_group( ui_manager );
gtk_window_add_accel_group( GTK_WINDOW( log ), accel_group );
if( !gtk_ui_manager_add_ui_from_string( ui_manager,
log_class->ui_description, -1, &error ) ) {
g_message( "building menus failed: %s", error->message );
g_error_free( error );
exit( EXIT_FAILURE );
}
Here's the program edit window from my app:
http://vips.svn.sourceforge.net/viewvc/vips/nip2/trunk/src/program.c?view=markup
search for "accel" to find the menus being built.
John
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK and threads
Hi,
2008/7/29 Bernhard Jung <[EMAIL PROTECTED]>:
> I'm currently having a problem in a application where I try to update a
> GtkListStore from a thread. When calling gtk_list_store_set I often get error
> messages that repeat
GTK doesn't work like this. You can call gtk from more than one
thread, but you need to be very careful with locking, and you will
find you have problems getting it working on win32.
In my opinion, the best way to do threading in gtk is to keep all
gtk_*() calls in a single GUI thread. Have a set of worker threads
which do the background stuff and have them pass packets of processed
data to the GUI to update the display on their behalf.
This is very easy to do, it turns out, with g_idle_add(). Unusally,
this function can be safely called from a background thread with no
need for any locks. Something like (untested):
// the stuff the bg thread calculates
typedef struct _Packet {
double data[100];
} Packet;
// run as a background thread ... generate a packet of data
// every second
void background_task (void *stuff)
{
for(;;) {
Packet *packet = g_new (Packet, 1);
int j;
for (j = 0; j < 100; j++)
packet->data[j] = (double) rand() / RAND_MAX;
sleep (1);
g_idle_add (new_packet, packet);
}
}
// this is run by the main GUI thread every time a new
// packet of data arrives
gboolean new_packet (Packet *packet)
{
int j;
for (j = 0; j < 100; j++)
update_gui (packet->data[j]);
g_free (packet);
// remove this idle function
// we only want to run once
return FALSE;
}
John
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk2 multithreaded programming win32 issue
Hi, 2008/8/28 Kuang-Chun Cheng <[EMAIL PROTECTED]>: > My GUI require update after some non-gui thread finish it's task. > > So I create an idle callback + GAsyncQueue in main thread. > When non-gui thread push message to GAsyncQueue, my idle callback will > be wakeup and do the GUI update. You don't need the GAsyncQueue. Just call g_idle_add() from the non-gui thread and the idle callback will run in the gui thread next time the main loop is idle. I do this in my app and it works well on linux and windows. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk2 multithreaded programming win32 issue
2008/8/28 Tor Lillqvist <[EMAIL PROTECTED]>: > Have the idle callback function return FALSE... Schedule it again with > g_idle_add() whenever you have something new that needs to be done in > the GUI thread. I wrote a tiny bit of sample code in an old mail: http://lists-archives.org/gtk/08308-gtk-and-threads.html maybe that helps a bit. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Large GTK Application design tips
2008/9/11 Paul Stuart <[EMAIL PROTECTED]>: > I'm about to embark on designing a large application that will use GTK+. I > was wondering if there are any resources out there that might have tips on > architecture practices specific to GTk+, style guides, etc. I've written > small apps, but I'm curious about how things scale up. This is probably all very obvious, but in my experience (a 100 kloc GTK+ app in C): - make your own widgets - model/view is a very useful, and in fact hard to over-use - avoid complex class hierarchies - connect things together with signals rather than function calls where you can - if I were to start again, I think I'd do most of the gross structure in Python and just have C for the lower levels - actually I'd consider clutter - but of course making heavy use of technologies like that which are still somewhat in flux and rather new sets you up for a lot of problems with distribution and maintenance John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Large GTK Application design tips
2008/9/12 Paul Stuart <[EMAIL PROTECTED]>: > I'm curious; a number of people have recommended to "make your own widget". > Is this recommendation purely to give one's application a unique feel, or is > there an efficiency gain to be had in creating a custom widget? The suggestion is to use gtk's object system to wrap up collections of widgets as new widgets. If you have a set of widgets you find yourself commonly using together, make a new widget that encapsulates them as a single thing. Now you can use the usual gtk api to manipulate them and you gain regularity in your app's structure. I'd also suggest a complete model/view split (sorry of this is obvious). It depends on the application of course, but commonly the model part of the app consists of a large set of objects of a variety of types, all linked together. You can often: * implement the model's types with gobject (ie. subclass gobject and to make non-gui gobjects) * make a parallel widget for each type which draws the view for that part of the model * have a 'changed' signal from your model objects which puts the matching view on a 'to be refreshed' list * on idle, refresh any view widgets that need updating It's all part of breaking the app up into mostly independent chunks of code. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: file open dialog settings?
2008/9/22 Stanislav Maslovski <[EMAIL PROTECTED]>: > Let me ask directly: is there anyone who is working in this direction now? > Should we form a kind of sponsoring commitee for such an individual? =) > Half-joking, but having such big companies as Google or Canonical around > that are willing to support free software this might certainly be helpful. The file chooser is mostly the work of the wonderful Federico Mena-Quintero. You can fiind snippets about it on his blog, for example: http://www.gnome.org/~federico/news-2008-02.html#gtkfilechooser-bug-week http://www.gnome.org/~federico/news-2006-02.html#16 Asynchronous filling of the file chooser (close to your suggestion) was added in gtk 2.10 by Kristian Rietveld and released in July 2006. Though I think it's been turned off at some point since due to a regression with the gnome-vfs backend. Or something like that. It's supposed to all be working again now, I understand, and works with completion as well. I'm sure if you have a good idea for improving performance, Federico would love to hear it. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Scrolled window initial size
2008/10/11 <[EMAIL PROTECTED]>: > I want to put some widget in a scrolled window, but I want it initially > displayed in its full size. The scroll bars will be useful when the top > level window becomes smaller. Unfortunately, this is not possible at the moment. GTK is due to get fancier size negotiation, but it's not arrived yet. Until then, the best you can do is set the initial size of the enclosing window to a large enough value with gtk_window_set_default_size(). Getting the size exactly right is very hard since it will change with different fonts and themes, sadly. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How to install GTK in linux
008/11/2 Ian Puleston <[EMAIL PROTECTED]>: > I downloaded the gtk 2.14 and glib 2.18 .tar.gz packages, unpacked them and > ran configure, make and make install. But they install into /usr/local/lib > and so the app still picks up the older versions from /usr/lib. I tried > "make install prefix=/usr" but that failed with an error. I wouldn't install to /usr, that area is managed by fedora for you and you are likely to break everything horribly if you start messing with it. The best way to do this, in my opinion, is to install the new gtk to /usr/local/ and then to build and run your app against that. This way you won't disturb your system or any of the other applications you have installed. You need to set PKG_CONFIG_PATH so that your new gtk appears before the system one for apps you build. Put something like this in your .bashrc: export PKG_CONFIG_PATH=/usr/local/liib/pkgconfig then at the command-line, try: $ source ~/.bashrc $ pkg-config gtk+-2.0 --cflags and verify that its seeing the version in /usr/local Other stuff to set: - add /usr/local/bin to your path so that you pick up the new versions of any gtk/glib utilities - add /usr/local/lib to LD_LIBRARY_PATH so that your app picks up the gtk/glib libraries at run time - you can add /usr/local/share/man to MANPATH, though I can't remember if gtk still makes man pages John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Flash and GTK
2008/11/11 Alexander Semenov <[EMAIL PROTECTED]>: >> I need to play a flash file in my gtk application. >> is it possible? >> if so can someone give me a code example. > > You can try to embed gnash (http://www.gnu.org/software/gnash/) into you app > (I'm not sure this is quite simple). Also, try googling on "gnash gtk". But > better, stay away from flash. ;-) There's also swfdec, a rival flash player: http://swfdec.freedesktop.org/wiki They have a gtkwidget that can play flash: http://swfdec.freedesktop.org/documentation/swfdec/SwfdecGtkWidget.html Though I've never tried it. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: popup menu problem
2008/12/22 Roei Azachi : > when I popup the menu and click outside the the menu on the main application > window, the menu is closed, but the main window does not get focused. > if I try the same scenario and press on a different window, it get focused. > I tryed it on another gtk application (pidgin) and I get the same result. > it seems like gtk window "eats" the click and does not response to it. > any idea? This works OK for me on Ubuntu. What platform are you seeing this problem on? John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_main_loop and g_async_queue
Hi Chris,
2009/1/5 Cris :
> I'm having a main loop which is somewhat time critical, and a thread
> which is dedicated to tasks which can take longer and have often a
> lesser priority. I chose to use threads over forks because complex data
I think you have this backwards for glib.
You can't really do anything time critical in the main loop. All it's
there for is repainting the screen and responding to messages from
widgets. Any real-time stuff has to be in worker threads and they
can't (usually) do anthing to the GUI. They need to send messages to
the main thread when they want the display updated.
The system I use is something like this:
// the stuff the bg thread calculates
typedef struct _Packet {
double data[100];
} Packet;
// run as a background thread ... generate a packet of data
// every second
void background_task (void *stuff)
{
for(;;) {
Packet *packet = g_new (Packet, 1);
int j;
for (j = 0; j < 100; j++)
packet->data[j] = (double) rand() / RAND_MAX;
sleep (1);
g_idle_add (new_packet, packet);
}
}
// this is run by the main GUI thread every time a new
// packet of data arrives
gboolean new_packet (Packet *packet)
{
int j;
for (j = 0; j < 100; j++)
update_gui (packet->data[j]);
g_free (packet);
// remove this idle function
// we only want to run once
return FALSE;
}
So a worker thread does something (anything) in the background and
sends data to the main thread with g_idle_add(). The main thread
updates the model and marks the view for refreshing. I don't have
anything to limit the depth of the queue, but in some cases I guess
this might be necessary.
John
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: main window snap to screen edge
2009/1/6 Roei Azachi : > is there a way of making my main window snap to the screed edge when i get > close to it? This is done by the window manager, not by your program, and most window managers do this. You need to look at your window manager preferences, or if your WM can't do snap-to-edges, find one that can (eg. the default GNOME one). John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ and Gimp
2009/1/24 Michael Grosberg : > things worked out without needing a workaround. Oh, by the way - > Microsoft actually do have a powertoy for WindowsXP giving you four > virtual desktops - google "Virtual Desktop Manager xp". Unfortuntaly it's awful and unuseable :( The problem (as I understand it) is that on Windows, applications are responsible for drawing their own window borders, handling minimise/unminimise, and that kind of thing. This makes it very hard for a program to quickly hide one set of windows and bring up a new set, since every application on the old desktop and the new desktop has to start up and act on an event before the switch can complete. As a result, even the basic switch-between-desktops action is slow and (depending on the apps involved) unreliable. And many applications get confused and start popping up windows on the wrong desktop, or simply don't work at all. Their new display system has much better support for manipulating windows without the app's knowledge or consent, so perhaps it would be possible to write a proper virtual desktop now. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: ImageButton
2009/2/2 Steffen Toksvig : > What is the best way to make an 'owner drawn' button that draws > different images depending on the state of the button. > The button would draw only the relevant image, possibly scaled if the > button has a different size compared to the image and a label. But it > should not draw any of the normal button graphics. Just make a regular button and turn off the relief decoration and the border: gtk_button_set_relief( GTK_BUTTON( but ), GTK_RELIEF_NONE ); gtk_container_set_border_width( GTK_CONTAINER( but ), 0 ); No doubt you could do this with a style file too. Put a GtkImage inside the button and change the graphic to whatever you want, whenever you want. You'll still get the mouseover and press effects, but they're rather useful, I think. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Mixing immediate drawing with drawing via expose events
2009/1/31 Douwe Vos : > 1. all the immediate drawing is done as a result of a key- or mouse-event (so > no extra thread). Isn't the event-dispatcher for the key- and mouse-event > handled by the same thread as the expose-event dispatcher (or even they are > the same event-dispatcher?). So if that is the case then am I not running a > single threaded program and therefore the immediate drawing should not > interfere with the expose event drawing? That's true, but not helpful :( the problem is that the order of event dispatch can vary. If it's taking you a coupe of events to do you immediiate drawing (eg. you want to be able to spot mouse down and mouse up), you can't be sure there won't be an intervening expose event. Or what if your view scrolls between your immediate mode draw and the following expose? I struggled with this for a while. You can mix immediate mode and expose drawing in a simple application but once you have a more complex mix of stuff it's just impossible to get it working reliably. The final straw for me was when I needed to add drag scrolling (drag an element to the edge of the window and the view scrolls). It was just impossible to get it working correctly. I switched to expose-only drawing and everything worked and my code was smaller and simpler. It's really the only way to do a complex view, in my opinion. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GDK_POINTER_MOTION_HINT_MASK
2009/4/17 Jean-Philippe Chancelier : > I am using the GDK_POINTER_MOTION_HINT_MASK on a slow > machine and have signal handlers for "motion-notify-event" > "button-press-event" and "button-release-event". > I have the feeling that signal handlers for motion > are activated before signal handlers for press/release that > occured before: I move an object and during the move press > a button to stop the object and I continue to move the mouse, > the object follow the move after the stop for a while, > then go back to the stop. Without GDK_POINTER_MOTION_HINT_MASK > this behaviour do not seams to appear. > Is such behaviour impossible and just the result > of something wrong on my side ? You need to read the pointer explicitly to flush the queue of pending movements. I wrote a tiny program a while ago that shows how to do this: http://lists-archives.org/gtk/07028-gdk_pointer_motion_hint_mask-has-no-effect.html John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK+ on windows
2009/10/13 Dov Grobgeld : > I have created several cross-platform gtk programs, and while it took a > while to get right the first time, my development is now so trustworthy that > I can do all my development under Linux and then once it works, just > generate a windows installer and I know that it will just work. I agree, after struggling with gcc on Windows, MSVC and even cmake and jam, I now cross-compile from Linux and it works wonderfully. This solution has the following nice properties: *) I have not only a single, cross-platform source tree, I also have a single build system to maintain. *) It's very scriptable (my bash is much better than my VBA of whatever the Windows equivalent is). For example, I have a simple script that does a nightly build from SVN, updates a website with a fresh Windows binary, and sends me a mail if there were any problems. *) It's much faster than mingw on Windows, though I guess that's not saying much, heh. I don't build gtk+ myself, I use Tor's zips plus a few other packages I've had to build myself. I can update parts of the stack by just dropping an updated zip into the tree, it's about as nice as it could be without a proper package manager. > microsoft like you can make it use the intel compiler?) In any case, as gtk > is a pure c-program, there are no ABI differences between the visual > compiler and gcc. So why can't you just use the standard gtk distribution > together with the studio compiler? My understanding is that there are differences in the C runtime. mingw links against msvcrt.dll (the runtime from VC6) since this is the one that's guaranteed to be on almost all Windows machines, so you don't need to bundle a C runtime, so there's no problem with rights. Almost all free DLLs are built like this, I believe. Current VS links against msvcrt80.dll (is that right? can't remember) which is not present on all machines and needs to be bundled in your installer, which is a little dubious. Even if you take the IP risk and bundle it, that's not enough, you really need to run an installer for it as well and make some registry changes before i18n will work in the runtime. Erm, I think. The upshot is that VS projects can't link against GTK DLLs, unless you fiddle with the VS link stuff to link against msvcrt.dll instead of the more recent one, which is quite difficult to do, I think. Or this blog suggests that it is anyway: http://kobyk.wordpress.com/2007/07/20/dynamically-linking-with-msvcrtdll-using-visual-c-2005/ I'm not a Windows person at all though, I've probably got most of that wrong :( Friends who do serious Windows application development simply statically link everything to avoid all this pain. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Multhithreading internals in GTK+
Hi Vish, 2009/12/2 Vishwanath Venkatesan : > I am trying to understand the internals of threading in GTK+-2.0. From my > understanding there are threads generated with GTK+ functions (ex. Opening a > file-dialog) even without explicit threading. That's not correct. Gtk+ is a single-threaded system with an event loop. gtk_main() sits in a loop getting events from various sources and dispatching them to various scraps of code according to the event type. Each scrap of code will do a tiny bit of processing and then return back to the main loop again. Everything runs in the same thread. You can have nested main loops: if you pop up a window, it can be a programming convenience to have another main loop to handle the interaction for that dialog, but it's not required. Again, the inner main loop runs in the same thread. If you want to have several threads in your application, it's usually best to only have one of them doing all the gtk calls. You can use some parts of glib to get worker threads to send safe messages to the main thread. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Multhithreading internals in GTK+
2009/12/9 Vishwanath Venkatesan : > I did see this behavior when I instrumented Gedit with PIN. Whenever there > is a dialog box spawned, there are thread spawned. The behavior is random, > and moreover I don't think I used any GFS. It was on a VM running Ubuntu. > > Any intuitions why this is happening? It could be something as simple as loading the icon for the dialog box I guess. Try putting a breakpoint on g_thread_create() or g_thread_create_full() and looking at the stack. Anyway, it won't be anything important, GTK does not directly use threads. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GtkTreeView unbearably slow
Hi Vikram, 2009/12/27 Vikram Noel Ambrose : > Why is GtkTreeView so horrendously slow compared to... QTreeView for > example? I think you need to give more information. What is slow, exactly? Scrolling? Adding rows? Sorting by colums? Resizing? How are you measuring speed? Do you have some example code that demonstrates poor performance? > I'm using a GtkTreeView with about 5 columns, all small text strings. Using > GtkTextCellRenderer. A couple thousand rows. That doesn't sound like a large data set, you'd think it would be pretty quick. Synaptic (to pick one example) has a treeview with ~30,000 rows and performs acceptably (for me). John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: What, in detail, the GDK do?
2009/12/28 frederico schardong : > So how low level GDK goes? It renders the widgets according the OS? > Where GTK+ ends and GDK starts? Where GDK ends and GLib starts? You can read about it here: http://www.gtk.org/documentation.html gdk wraps the business of creating a window and getting events, cairo does low-level drawing, glib does data structures, utility functions and event loops, gobject is the object model, pango renders text, gdkpixbuf loads and transforms images, gtk issues all the drawing commands to display widgets, your application does everything else. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: OT comprehending large application (was What, in detail, the GDK do)
Hi Patrick, 2009/12/29 Patrick : > Does any one person actually understand 18K pages of this code or is it just > a case of sticking to a small section? Could any pros out there explain how > you tackle this monumental task? People vary in how much code they can hold in their head in any detail, but I doubt if anyone could manage 60MB of source. A lot of software design is about how to structure a large project so that you only need to understand a smallish bit at any one time. The general principle is always "divide and conquer". For GTK, you need to understand GObject (the object model) and GtkWidget (the GTK base class) and once you have that down pat, you can write your own widget subclasses. It's not so much code to understand. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Benchmark test
2010/1/1 frederico schardong : >> Does anyone know about benchmark testing GTK in C and it >> bindings(PyGTK, PHPGtk, etc..)? I've searched but not found nothing. I think you need to be more specific. What do you want to measure? Things like gtkperf will try to measure gtk's performance (though I'm not sure how useful the numbers are). You can use sysprof to watch a running program (and the window system) and see where it's spending its time. valgrind (with cachegrind) will let you do detailed testing of code and see where cache spills or misses are happening. You could just use g_timer_*() and add some elapsed time logging to your program. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: performance problems double buffering to 1600x1200 window
2010/1/28 Robert Gibbs : > Can anyone tell me why the built-in double buffering would yield such poor > performance? The built-in double buffering allocates and frees a backing buffer the size of the expose for every expose event. I imagine your program is spending a lot of time doing this. I suppose the gtk buffer could also somehow not be in fast memory, giving you slow offscreen - onscreen copies. You'd need to do some timing. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: performance problems double buffering to 1600x1200 window
On 29 January 2010 03:54, Andrew Cowie wrote: > On Thu, 2010-01-28 at 08:08 +, jcup...@gmail.com wrote: >> The built-in double buffering allocates and frees a backing buffer the >> size of the expose for every expose event. I imagine your program is >> spending a lot of time doing this. I suppose the gtk buffer could also >> somehow not be in fast memory, giving you slow offscreen - onscreen >> copies... > > I thought the whole idea of using Pixmaps (vs GdkPixbufs) was that they > were in X server memory and didn't have to be copied across from > application memory each time they were rendered. That's right, but the X server can't always place pixmaps in fast memory if server memory becomes very full or fragmented. It depends on the details of the hardware and the driver. Or that's my understanding anyway, I read a blog post by Keith Packard a while ago that talked about how they were addressing these problems with the Intel server. > Anyway, is this heavy allocation behaviour expected with GtkDrawingAreas > and the default double buffer implementation? Yes, that's expected behaviour. It's not so usual (I think, probably wrong) for pixmap allocate/free to be so expensive. I'll try some timings on my machines later for fun. > I wonder if there's some engineering we should try to do to make custom > widgets more performant or memory efficient. It seems a touch off to say > "use DrawingArea, but don't let it draw". Large GtkDrawingAreas are > fairly common as "canvases" (sic) and custom widgets. It's only large drawing areas where you are redrawing the whole drawingarea every frame. If you just update small parts of it, you'll only need small expose pixmaps and you won't have these problems (hopefully). John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: performance problems double buffering to 1600x1200 window
Hi Robert,
On 29 January 2010 02:06, Robert Gibbs wrote:
> I have attached an example program. With this example I get 220 FPS using a
> pixmap for buffer and 11 FPS using the GDK buffering.
Here's a very slightly modified version of your program. I put the fps
measure in the expose handler rather than in the idle callback, since
GDK can coalesce exposes, and added a bit more feedback about when
it's starting and stopping tests.
On my work machine (x.org 1.6.4 with nvidia driver 185 on a quadro nvs
285, compiz enabled, 1920x1200 display) I get these results:
Using GDK buffering
starting fps test
1 fps
62 fps
64 fps
64 fps
64 fps
64 fps
64 fps
stopping fps test
Using internal buffer
starting fps test
64 fps
127 fps
52 fps
53 fps
52 fps
52 fps
52 fps
53 fps
52 fps
53 fps
So on this machine anyway, the gdk double buffering does not cause
terrible performance.
John
/* compile with
gcc double-buffer.c `pkg-config gtk+-2.0 --cflags --libs`
*/
#include
#include
#include
#include
#include
#include
typedef struct
{
guint idle_id;
GtkWidget *da;
GdkPixmap *pix;
gboolean use_buffer;
} AppData;
static gboolean
on_expose (GtkWidget * widget, GdkEventExpose * event, AppData * app)
{
static GTimer *timer = NULL;
static int frames = 0;
GdkColor color;
GdkDrawable *drawable;
GdkGC *gc;
if (!timer)
timer = g_timer_new ();
frames += 1;
if (g_timer_elapsed (timer, NULL) > 1)
{
printf ("%d fps\n", frames);
g_timer_reset (timer);
frames = 0;
}
if (app->use_buffer)
{
drawable = GDK_DRAWABLE (app->pix);
gc = gdk_gc_new (drawable);
gdk_color_parse ("black", &color);
gdk_gc_set_rgb_fg_color (gc, &color);
gdk_draw_rectangle (drawable, gc, TRUE, 0, 0,
widget->allocation.width,
widget->allocation.height);
}
else
{
drawable = GDK_DRAWABLE (widget->window);
gc = gdk_gc_new (drawable);
}
gdk_color_parse ("red", &color);
gdk_gc_set_rgb_fg_color (gc, &color);
gdk_draw_line (drawable, gc, 0, 0,
widget->allocation.width, widget->allocation.height);
gdk_draw_line (drawable, gc, widget->allocation.width, 0,
0, widget->allocation.height);
if (app->use_buffer)
{
gdk_draw_drawable (GDK_DRAWABLE (widget->window), gc,
GDK_DRAWABLE (app->pix), 0, 0, 0, 0, -1, -1);
}
return TRUE;
}
static gboolean
on_configure (GtkWidget * widget, GdkEventConfigure * event, AppData * app)
{
if (app->use_buffer)
{
if (app->pix)
g_object_unref (app->pix);
app->pix = gdk_pixmap_new (GDK_DRAWABLE (app->da->window),
event->width, event->height, -1);
}
return TRUE;
}
static gboolean
on_fps_idle (AppData * app)
{
gtk_widget_queue_draw (app->da);
return TRUE;
}
static gboolean
on_key_press_event (GtkWidget * widget, GdkEventKey * event, AppData * app)
{
switch (event->keyval)
{
case GDK_t:
case GDK_T:
if (g_source_remove_by_user_data (app))
{
printf ("stopping fps test\n");
}
else
{
printf ("starting fps test\n");
g_idle_add ((GSourceFunc) on_fps_idle, app);
}
break;
case GDK_b:
case GDK_B:
if (app->use_buffer)
{
printf ("Using GDK buffering\n");
app->use_buffer = FALSE;
GTK_WIDGET_SET_FLAGS (app->da, GTK_DOUBLE_BUFFERED);
if (app->pix)
g_object_unref (app->pix);
app->pix = NULL;
}
else
{
printf ("Using internal buffer\n");
app->use_buffer = TRUE;
GTK_WIDGET_UNSET_FLAGS (app->da, GTK_DOUBLE_BUFFERED);
app->pix = gdk_pixmap_new (GDK_DRAWABLE (app->da->window),
app->da->allocation.width,
app->da->allocation.height, -1);
}
break;
default:
break;
}
return FALSE;
}
static char *keymaps = "\
t.T\t\tStart or stop a frame per second (FPS) timing test.\n\
b.B\t\tToggle internal buffering on or off..\n\
";
int
main (int argc, char **argv)
{
GtkWidget *window;
GdkColor color;
AppData app;
memset (&app, 0, sizeof (app));
gtk_init (&argc, &argv);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
g_signal_connect (window, "delete-event", gtk_main_quit, NULL);
app.da = gtk_drawing_area_new ();
GTK_WIDGET_SET_FLAGS (app.da, GTK_CAN_FOCUS);
gdk_color_parse ("black", &color);
gtk_widget_modify_bg (app.da, GTK_STATE_NORMAL, &color);
gtk_widget_set_size_request (app.da, 400, 400);
gtk_widget_set_events (app.da,
GDK_KEY_PRESS_MASK |
GDK_KEY_RELEASE_MASK |
GDK_LEAVE_NOTIFY_MASK |
GDK_FOCUS_CHANGE_MASK | GDK_EXPOSURE_MASK);
g_signal_connect (app.da, "key-press-event",
G_CALLBACK (on_key_press_event), &app);
g_signal_connect (app.da, "expose-event", G_CALLBACK (on_expose), &app);
g_signal_connect (app.da, "configure-event", G_CALLBACK (on_configure),
&app);
gtk_container_add (GTK_CONTAINER (window), app.da);
gtk_widget_show_all (window);
printf ("%s\n", keymaps);
gtk_main ();
return 0;
}
___
gtk-list mailing list
gtk-li
Re: Nesting gtk_main ?
On 30 January 2010 18:48, Siddu wrote: >> Modal dialog boxes etc. > > Yes thats right ! but later gtk_main blocks the former which is not what i > want > > Assuming i have two different windows window1 and window2 > > can the events or signals on each of them be processed concurrently with two > gtk_main( one for window1 and other for window2) being isolated under their > own GMainContexts (maybe in two threads) ? A single gtk_main will run multiple independent windows. You only need to nest them if you want a modal dialog. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Nesting gtk_main ?
On 1 February 2010 10:37, Martin Vejnár wrote: >>> In electronics design, it is common to have two independent windows, one >>> which shows the schematics and the other shows the circuit board. You >>> don't want dialog boxes pertaining to one window to block the other. I have a pair of classes I use in my app which implement a window / dialog tree. You can have many independent top-level windows, you can freely mix modal and non-modal dialogs, dialogs can pop up nested child dialogs, and a modal dialog only blocks windows below it in the tree, leaving other parts of your app working. It all works with a single gtk_main(). It is a bit hairy :-( it's all based on continuations and is probably overkill. But if anyone is curious: http://vips.svn.sourceforge.net/viewvc/vips/nip2/trunk/src/iwindow.c?view=markup http://vips.svn.sourceforge.net/viewvc/vips/nip2/trunk/src/idialog.c?view=markup John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Nesting gtk_main ?
On 1 February 2010 14:46, Martin Vejnár wrote: > I've already solved the problem by putting the windows into separate window > groups. I didn't see any calls to window group API, so I assume your code > works differently? Window groups were added to GTK some time after I wrote my base classes. Though I'm not sure they are really equivalent. Ah well! > Yes, it's rather sad that you have to use continuations. In Windows, you run > each "window stack" in its own thread, which allows you to simply call the > equivalent of gtk_dialog_run() and everything works. > > But you can't run gtk_main() in multiple threads, can you? No, not portably. It'll work on Linux, if you're very careful, but won't work on Windows, ironically. I like having a single GUI thread and just using threads for longer tasks. The Windows model seems to introduce a lot of unnecessary complexity. Though of course I just posted a mind-boggling continuations-in-C implementation as an alternative, heh. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: performance problems double buffering to 1600x1200 window
On 2 February 2010 03:14, Robert Gibbs wrote: > Just want to report the results of running the included example.c benchmark > on 7 different machines: > > ATI w/open source driver - no speedup > Nvidia w/open source driver - no speedup > Old Nvidia FX5200 w/closed source driver - 5X speedup > New Nvidia w/closed source driver - 10X speedup I just tried on a Dell mini9 running Ubuntu 9.10 (Intel GMA 955 I think) and I see a steady 250 fps with GDK or with application double-buffering. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: performance problems double buffering to 1600x1200 window
On 2 February 2010 03:14, Robert Gibbs wrote: > Conclusion: self implemented GdkPixmap helps only when the X server can use > certain optimizations from the graphics card. Or perhaps that's backwards: doing your own double-buffering can help if your X server does not support fast pixmap allocate/deallocate. It looks like this problem only happens with some older nvidia cards (is that right?) John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Memory leaks?
On 11 March 2010 10:32, Chris Vine wrote: > It would be nice if someone in the gtk+/gnome projects were to produce > a suppression file (there was work on one for gtk+-2.12) but the I posted this the last time this subject came up, but I made this for my project: http://www.vips.ecs.soton.ac.uk/development/nip2.supp With this, I get no reported leaks in my huge application with current gtk+. There are some comments in the file explaining what the various bits do. No doubt I've made some errors :-( but perhaps it might be useful. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk on win32
On 30 March 2010 08:26, John Emmas wrote: > Another consideration is which compiler you're intending to use. My preferred solution is to cross-compile from linux. I develop and debug on linux, which I find much more comfortable than Windows, then when it's all working, press a button and get a windows installer. This has a few advantages over building on Windows: Easier maintenance I can use all the usual unix tools to keep the GTK stack (cairo, freetype, pango, fontconfig and friends) and my application dependancies (openexr, libtiff, fftw etc.) up to date. On Windows, I've found building and maintaining these things time-consuming. On a linux host it's pretty much automatic. Single build system I can use autotools to automate the build process on every platform. I don't need to maintain a separate set of Windows project files. More automation I find linux much easier to automate than Windows. For example, I have a simple script which runs at 2am every day to checkout SVN trunk, build a Windows installer, and upload it to the project website. If there are any problems it sends me a mail with all the configure and buid logs. I expect something like this is possible on Windows, but I wouldn't know how to do it. I wrote some notes on the process if you're curious: http://www.vips.ecs.soton.ac.uk/index.php?title=Build_on_windows And here's a typical installer built this way: http://www.vips.ecs.soton.ac.uk/supported/7.20/win32/nip2-7.20.7-2-setup.exe It's not using the win32 theme, so it looks a little odd. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: gtk on win32
On 29 March 2010 19:57, Jorge Opaso Pazos wrote: > Can I use GTK and all its dependencies to develop Windows applications at > production level? That is a general question, no about a particular versions. > I have to make a decision, because a new project I'm participating > (commercial application). Inkscape is arguably the best gtk application on WIndows: http://www.inkscape.org So (with some work of course) you should be able to make something at about that level. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: shrink GTK+ disk usage for Windows
On 30 March 2010 18:04, Andrew Ziem wrote: > How can I shrink GTK+ binaries? > > I develop a simple, cross-platform PyGTK app (BleachBit) and include > GTK+ 2.16 binaries in my Windows installer. Compared to my app itself > and the Python runtime, GTK+ is huge. I just had a look at my project's win32 zip, and it looks like the complete gtk 2.18 stack is just under 6MB, including cairo, pango, treetype and friends and a theme engine (I'm shipping clearlooks at the moment, for some reason). It's probably possible to shrink that a bit more, perhaps by stripping symbols from the files more aggressively. What's your current size? John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: file chooser not to display icons
On 31 March 2010 12:27, Jonh Wendell wrote:
> Em Qua, 2010-03-31 às 14:27 +1300, m.c.wilk...@massey.ac.nz escreveu:
>> I am trying to open a file in a directory with about 15000 things in
>> it. It takes forever (10 mins or so). I do an strace and I can see
>> the following:
>
> Dude, this is an ancient version of gedit and very probably gtk+. There
> were huge improvements in open file dialog in recent versions of gtk+.
> Checkout for instance Federico's blog.
>
> Consider updating your system.
I just tried this program:
-
#!/usr/bin/python
for i in range (1, 2):
file = open ('file%d' % i, 'w')
file.write ('hello world')
file.close ()
--
ie. create 20,000 files with some small amount of text in. If I start
gedit and click File / Open, it takes about 2 seconds for the file
browser to appear and about 20 seconds before all the icons have been
drawn. This is gedit 2.28.0 (the one in current Ubuntu) on a
5-year-old desktop PC.
John
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: file chooser not to display icons
On 31 March 2010 20:43, wrote: > You say all the icons have been drawn: do you know if your gedit is > just displaying two sorts of icons, one for directory, and one for a > file? Yes, it sniffs each file to determine the file type. If it was simply displaying a list of filenames it would be quite a bit quicker still. For example, if I look at a directory containing an a.out I see a funny blue square as an icon. If I rename it to "rgh", the blue icon stays. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: shrink GTK+ disk usage for Windows
On 31 March 2010 17:59, Andrew Ziem wrote: >> It's probably possible to shrink that a bit more, perhaps by stripping >> symbols from the files more aggressively. > > Wow, using Linux 'strip -v bin/*' cuts the bin directory from 16M to > 9.3M! After UPX, it's down to 3.9M (compare to 7.8MB below). Good stuff. I think you need to be a bit careful with strip, it's possible to break linking if you take too much off (I seem to remember breaking it at some point anyway). Test carefully! You could take a look at projects like Inkscape. It'd be interesting to see how large the stack they use is --- they have put a lot of time into this sort of issue. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: file chooser not to display icons
On 31 March 2010 21:42, wrote: >> Yes, it sniffs each file to determine the file type. > > Damn, I was hoping newer versions weren't doing this. Do you know if > the file chooser is actually sniffing every single file initially, or > just the ones that are visible in the chooser? I believe it loads the list of file names, then sniffs in the background. Or it has done that anyway, I think the background sniffing was disabled for a while, but is back now. Erm, I think. I half-remember someone saying that it had some rules to stop sniffing for network shares. but I can't find a link :-( How about trying a live CD of the current Ubuntu or similar and benchmarking the gedit there? That's probably the safest way to check the speed of the current version. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: shrink GTK+ disk usage for Windows
On 1 April 2010 06:00, Andrew Ziem wrote: > I hadn't tested yet when I wrote that :). Now I see that stripping > almost anything (except freetype6.dll) causes the app to not start. > From Linux I tried 'strip' and 'strip -g'. Are there safer ways to > strip? I use this as part of my package builder (running on linux): # we can strip the exes and some of the DLLs ( cd $installdir/nip2-$version/bin ; strip -F efi-app-ia32 --strip-unneeded *.exe ) ( cd $installdir/nip2-$version/bin ; strip -F efi-app-ia32 --strip-unneeded libvips-15.dll ) ( cd $installdir/nip2-$version/bin ; strip -F efi-app-ia32 --strip-unneeded libfftw3-3.dll ) Perhaps you can strip more of the DLLs, I didn't spend that long experimenting. I should try again: the WIndows build of my app works in Wine now (woo!) so it's a lot easier for me to test. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Windows theme not working in GTK 2.18.7
On 2 April 2010 00:18, Ian Puleston wrote: >> If you read the release notes, you'll see that XP theming is broken >> from 2.18 onwards, and is thus disabled. > > Thanks. The release notes say "XP themes have been disabled since they don’t > work". Does this mean all use of themes is disabled in XP? And is it only XP > or does the same apply for Vista and Windows 7? I'm shipping my app with Clearlooks (fairly plain, not too ugly) and 2.18 and it seems to work OK on XP and win7. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Displaying a v4l2 webcam output on memory buffer (rgb24) with GTK!
On 2 April 2010 07:48, Guilherme Raymo Longo wrote: > I am struggling on how to output the content of a v4l2 webcam software which > I have already working on a GtkWidget. You can use gdk_draw_rgb_image() to draw a memory buffer to the screen. http://library.gnome.org/devel/gdk/stable/gdk-GdkRGB.html#gdk-draw-rgb-image Make a GtkDrawingArea and call that in expose. You can also use cairo, though it'd probably be a little slower. If you need more speed than gdk_draw_rgb_image() (though you should be able to do 640 x 480 x 60 fps on most machines) you'll need to use opengl or similar. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: FW: Running gprof on gtk demo...
On 7 April 2010 22:13, Martin, Charles wrote: > Has anyone ever tried to run the GNU profiler on the gtk-demo program? I > did the following: Off-topic, but you could try some other profilers too. Linux has some interesting alternatives. At a higher level than gprof, sysprof or oprofile will profile the whole system. They add a kernel module which at some regular interval (100x a second? something like that, you can tune it) takes a snapshot of the stack and context. It can show you broadly where time is being spent, including time in syscalls and in other processes in your system. This is very helpful for profiling tasks like window resizing where the performance visible to the user is the result of the cooperative behaviour of many processes. At a lower level than gprof, valgrind with the cachegrind plugin will run your program in a virtual CPU. Performance is not great (about 20x slower than native), but you can see %cpu figures down to individual line numbers and see on exactly which lines of code L1 and L2 spills and misses are occurring. Neither requires compiling with extra flags, though of course enabling debugging will help. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How to debug gtk application using gdb in Fedora
On 14 April 2010 08:14, Huang, FrankR wrote: > I want to know the gtk application call to the glib and gtk > library, such as the gtk_init(). How to step into it? Make sure you've built your program with the "-g" flag, then type something like: $ gdb myapp (gdb) break gtk_init (gdb) run See: http://www.gnu.org/software/gdb/documentation There are also plenty of GUI wrappers over gdb, such as kdbg or even ddd. You might find them easier to use. valgrind is very useful for debugging memory errors. > I have compiled the gtk+-2.18.9 with the option > “—enable-debug=yes”. You only need to do this if you want to debug the internals of gtk. Even then, there are probably already debug versions of the libraries in your package manager. Just build your program with -g. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Re[2]: How do i find out if a widget is shown or hidden?
On 10 May 2010 11:22, Lothar Scholz wrote: > And what does "mapped" mean? Here's my understanding of what happens when you show a window. I'm sure I've made some errors and reality is far more complex :( 1) You build the contents with gtk_label_new() and friends. A window/widget in this state is !_get_visible(). When you want to show it, you call gtk_widget_show(). After calling _show(), _get_visible() will start returning TRUE (I think this is correct?), but your window is a long way from actually being visible to the user. Most of the rest of the process happens asynchronously (except for resource allocation, I think) over the next few milliseconds with a lot of chit-chat back and forth between your program and the underlying window system. 2) First your window and widget are realized. This is the process of allocating real window system resources (eg. windows, pixmaps, colourmaps and so on) to the components of the window. You can implement a _realize method if you want to be part of this process. 3) Next everything is configured. This is computing the layout of widgets within your window. You can implement a _configure_event method to be part of this process. Erm, I think this happens here, perhaps it's actually after map. 4) Now things are mapped. This is the process of asking the window system to display the windows on the screen. map/unmap are a good pair of events to look for if you want to be aware of window or widget visibility at the lowest level. 5) Finally expose events come in from the window system, are routed to your widgets, and cause drawing of the screen to take place. This can be a long time (many milliseconds) after your original _show() call. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Re[4]: Does GTK leak memory
On 2 June 2010 21:33, Lothar Scholz wrote: > Suppression files? > Please tell me more about it. Hi Lothar, I posted this the last time this subject came up (March, I think), but I made this for my project: http://www.vips.ecs.soton.ac.uk/development/nip2.supp With this, I get no reported leaks in my huge application with current gtk+. There are some comments in the file explaining what the various bits do. No doubt I've made some errors :-( but perhaps it might be useful. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Re[2]: Does GTK leak memory
On 5 June 2010 20:18, Lothar Scholz wrote: > And second unfortunately using valgrind is just not really useable as > it slows down the application to a point where you simply can't use it > during normal test runs. This is a bit off-topic, but valgrind performance is much better than it used to be. Programs typically run around 5x slower --- less than the performance difference between a netbook and a fast desktop machine. In any case, leak checking is usually an occasional task, so leaving it to run overnight is fine. I've not looked at Purify for years, but i think they offer similar (but with knobs on) functionality under Windows. Perhaps a Purify suppressions file would be the answer? John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: On deprecating GtkTearOffMenuItem
On 26 May 2010 20:25, Paul Tan wrote: > For those who care or use "menu/submenu tear-off feature" > (GtkTearOffMenuItem), please read: > https://bugzilla.gnome.org/show_bug.cgi?id=602882 > > this issue. We would also like to hear from other GTK+ developers/ > Application-developers/users on their usages of GtkTearOffMenuItem, My application, nip2, uses tearoff menus and my users tell me they like them. nip2 is a GUI for an image processing library and has to present the 300 or so operations in the library to the user. Additionally, the app includes it's own programming language which the user can use to create more operations. In total, nip2 has about 600 operations available by default. These operations are best represented to the user as text strings, something like "4-connected dilate", for example. These operations are presented in four ways: * The canonical representation is as a hierarchy, organised by function. This is presented as a large set of nested menus, up to 4 menus deep in cases I think, with tearoffs. This is an easy way to find something if you know roughly what you are looking for (all the morphological operators are appear together, for example). Tearoffs are handy if you want to repeatedly use functionally related operations and don't want to drill down 4 levels of menus each time. * A second set of menus present the operations organised by task. For example, all the operations you might find useful during image acquisition are grouped together. Again, tearoffs can save a lot of clicks. * A pull-out browser shows the operations as a flat list of operation name and operator tooltip text. There's a search box that lets you filter the operations to make it a bit more manageable. This is a good way to find things if you only have a vague idea what you want, but it takes up a huge amount of space. * ... and you can type equations, like "sobel A2", but I'm probably about the only user of the program who does this, heh. You can also bind keystrokes to operations, which can be very convenient. http://www.vips.ecs.soton.ac.uk John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How to improve GTK aspect in Ekiga ?
On 9 June 2010 04:52, YannUbuntu wrote: > I am new here. I hope you can help with the following issue : > Ekiga (SIP client for linux and windows) is coded in GTK 2.16 , but > its main interface (tabs, lists...) does not look nice in Windows. > Are there ways to get "round" tabs ? or nice "skin" with GTK ? > > Please see screenshot and dev comments on : > https://bugzilla.gnome.org/show_bug.cgi?id=619812 Yes, you can set a theme for gtk to draw with. There are many themes to choose from, for example: http://art.gnome.org/themes/gtk2?page=1 Perhaps the one pidgin uses (also a gtk program) would look better for you? I don't know what they ship with at the moment. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Windows theme not working in GTK 2.18.7
On 3 November 2010 12:30, Damon Register wrote: > On 4/1/2010 7:18 PM, Ian Puleston wrote: >> Thanks. The release notes say "XP themes have been disabled since they >> don’t work". Does this mean all use of themes is disabled in XP? And is it >> only XP or does the same apply for Vista and Windows 7? > > I have the same question but I don't find the answer. Can anyone > tell me what is the status of themes in Windows? It's just the theme that tries to give an XP look that's broken, as far as I know. > How do major apps such > as Wireshark deal with this? What is the future for gtk themes > on Windows? I'm not a major app, but mine ships with clearlooks (fast, fairly plain, not too ugly) from gtk-engines-2.20.1 on gtk+_2.20.1-1 and all seems OK on XP, Vista and win7. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Performance of many widgets
On 21 December 2010 22:41, Brian Phelps wrote: > Performance really decreases in my experience with large resolutions and > older hardware. Try it with an older 1GHz shared graphics card machine at > 1024x768 with just 40 buttons spread out and it takes 3/4 a second to a > second. No need to try it with thousands. Try it with 40 on a large > screen. It's fast for me with 40 buttons on a large screen and old(er) hardware (a seven-year-old laptop). I would first try with the default gtk+ theme, it's very fast, though rather ugly. If that produces a good performance improvement, you could hunt for a simple theme that's less unpleasant to look at. Next, investigate your graphics driver and see if there is anything broken. You could look at disabling gtk's double-buffering I suppose, though that's rather desperate. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Performance of many widgets
On 22 December 2010 20:16, Paul Davis wrote: > did you try different themes yet? these can have a VERY dramatic > impact on drawing speed. my main application is more or less unusable > on certain backends with certain themes, because the themes are so > slow and use functions that are not efficiently implemented in the > backend This is very true. The default gtk theme uses plain X11 draw calls (though actually I think this all goes through cairo now), is hideous (to modern eyes), but fast. Many themes compose sets of bitmaps to draw the widgets, which can be slow on graphics cards with little off-screen memory. Most modern themes use cairo to draw gradient effects and this will be appallingly slow on many elderly graphics drivers, Try the default gtk theme and see if that's also slow. John ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
