Re: Proposal: Enable threads by default
On Tue, 2009-12-01 at 16:16 -0500, Dan Winship wrote: > On 12/01/2009 03:36 PM, Alexander Larsson wrote: > > I don't think that is quite right. Its only safe to set this define > if > > you can guarantee there is no calls to your code before g_type_init > (or > > g_thread_init directly) is called. > > Hrmph. Could potentially add a define which would cause a G_LIKELY() > to be added in to G_THREAD_CF() when linking to gobject... but we'd want > to test that it actually had a measurable effect first. Actually, why are the thread primitives using g_thread_supported() at all? They're all virtualized anyway, can't we just change the default operation to be some non-NULL version that does what the !g_thread_supported case does? > > I wouldn't mind this, but on the other hand its not really a large > > maintainance burden, is it? > > Continuing to maintain the existing code which we already know works > is not a large burden, but having to write non-threaded versions of *new* > APIs might suck (having to write *two* non-threaded versions of > GResolver did) and then after we write them they're never going to get > used and so they'll probably be all buggy anyway. And besides, who are > we providing the no-thread-support version for anyway? There used to > be some somewhat-relevant unixes without pthreads, but I don't think > there are any non-toy OSes that have that problem any more. I'm certainly for this. Does anyone know of any system in use where gthreads are not availible? Another aspect is that you might want to disable threads in e.g. an embedded system where they are not used. I'm not sure people actually do this though, since embedded systems large enough to run e.g. gtk or other gobject things are generally big enough that you can support threads and you're likely to actually want to use things like threadpools and async i/o. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a lonely white trash assassin who dotes on his loving old ma. She's a vivacious foul-mouthed magician's assistant from the wrong side of the tracks. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Enable threads by default
On Tue, 2009-12-01 at 14:29 +0100, Alexander Larsson wrote: > On Thu, 2009-11-26 at 14:35 +0100, Alexander Larsson wrote: > > This was previously discussed here, but was sort of hidden in a > > technical discussion so it got no replies. I'm starting over in > order > > to > > reach a wider target for the discussion. > > > > I'll start with the proposal and then explain the reasons for it: > > > > Starting with next glib release: > > * libgobject links to libgthread > > * g_type_init() starts with: > > > > #ifdef G_THREADS_ENABLED > > if (g_thread_supported()) > >g_thread_init (NULL); > > #endif > > > > This means that everything above gobject can rely on thread > primitives > > being availible, and that global stuff in glib (mainloop, gslice, > > globals, etc) are threadsafe. > > I'm attaching a patch that implements this. Running with this patch i ran into an issue while building gnome-shell: GENGdm-1.0.gir GThread-ERROR **: GThread system may only be initialized once. aborting... Command '['/gnome/src/gnome-shell/src/tmp-introspectpoWP_f/Gdm-1.0', '--introspect-dump=/gnome/src/gnome-shell/src/tmp-introspectpoWP_f/types.txt,/gnome/src/gnome-shell/src/tmp-introspectpoWP_f/dump.xml']' returned non-zero exit status -5 Not sure exactly what crashed, but obviously something ran: g_type_init() and then g_thread_init(). Maybe we need to make this a non-fatal warning? -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a notorious bohemian librarian from a doomed world. She's a beautiful renegade lawyer with the soul of a mighty warrior. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Enable threads by default
2009/12/2 Alexander Larsson : > I'm certainly for this. Does anyone know of any system in use where > gthreads are not availible? One problem I've had in the past is writing mysql plugins. I help maintain an image processing library, and one use of the library was a mysql plugin that added query-by-image-content. To get the plugin working we had to make sure we could run threadless. I've not actually checked for years, perhaps mysql allows plugins to link to more stuff now. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Enable threads by default
On Wed, 2009-12-02 at 11:48 +, jcup...@gmail.com wrote: > 2009/12/2 Alexander Larsson : > > I'm certainly for this. Does anyone know of any system in use where > > gthreads are not availible? > > One problem I've had in the past is writing mysql plugins. > > I help maintain an image processing library, and one use of the > library was a mysql plugin that added query-by-image-content. To get > the plugin working we had to make sure we could run threadless. By threadless, do you mean not linking to the thread library, or do you mean "don't spawn threads". Because initializing threads doesn't mean we'll create threads, just that we make global us data threadsafe. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a time-tossed coffee-fuelled gangster with a robot buddy named Sparky. She's a supernatural tomboy former first lady with the power to bend men's minds. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Enable threads by default
2009/12/2 Alexander Larsson : > On Wed, 2009-12-02 at 11:48 +, jcup...@gmail.com wrote: >> 2009/12/2 Alexander Larsson : >> > I'm certainly for this. Does anyone know of any system in use where >> > gthreads are not availible? >> >> One problem I've had in the past is writing mysql plugins. >> >> I help maintain an image processing library, and one use of the >> library was a mysql plugin that added query-by-image-content. To get >> the plugin working we had to make sure we could run threadless. > > By threadless, do you mean not linking to the thread library, or do you > mean "don't spawn threads". Because initializing threads doesn't mean > we'll create threads, just that we make global us data threadsafe. Sorry, I wasn't clear. You mustn't even link to pthreads when building mysql plugins. Or that used to be the case anyway. I tried a quick google but couldn't find anything saying whether or not this was still a problem, so this might all be a red herring anyway. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Enable threads by default
On Wed, 2009-12-02 at 13:07 +, jcup...@gmail.com wrote: > 2009/12/2 Alexander Larsson : > > On Wed, 2009-12-02 at 11:48 +, jcup...@gmail.com wrote: > >> 2009/12/2 Alexander Larsson : > >> > I'm certainly for this. Does anyone know of any system in use > where > >> > gthreads are not availible? > >> > >> One problem I've had in the past is writing mysql plugins. > >> > >> I help maintain an image processing library, and one use of the > >> library was a mysql plugin that added query-by-image-content. To > get > >> the plugin working we had to make sure we could run threadless. > > > > By threadless, do you mean not linking to the thread library, or do > you > > mean "don't spawn threads". Because initializing threads doesn't > mean > > we'll create threads, just that we make global us data threadsafe. > > Sorry, I wasn't clear. You mustn't even link to pthreads when building > mysql plugins. > > Or that used to be the case anyway. I tried a quick google but > couldn't find anything saying whether or not this was still a problem, > so this might all be a red herring anyway. I guess this is the same problem that we had recently, where its not allowed to dynamically link in libpthreads in a binary that doesn't link to libpthreads. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an underprivileged ninja vampire hunter searching for his wife's true killer. She's a transdimensional nymphomaniac mermaid with the power to bend men's minds. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Embedding the VTE Virtual Terminal
Hi,
I'm writing a Gui+Terminal application, where VTE is embedded on window, and
the GUI Menu Items.
And i'm trying to call this action...
... calls to this action from the menu... (just fork a 'ls' command)
But i'm unable to get the 'ls' listing ...
void VimWindow (GtkWidget *widget, gpointer gdata)
{
GtkWidget *vte;
vte = vte_terminal_new();
[b]vte_terminal_fork_command(VTE_TERMINAL(vte), "ls", NULL,
NULL, ".", FALSE, FALSE, FALSE);[/b]
}
All the source;
#include
#include
#include
#include
#include
/* gcc -Wall -g term.c -o term `pkg-config --cflags --libs gtk+-2.0 vte`
*/
/*-- This function allows the program to exit properly when the window
is closed --*/
gint destroyapp (GtkWidget *widget, gpointer gdata)
{
g_print ("Quitting...\n");
gtk_main_quit();
return (FALSE);
}
/*-- This function allows the program to exit properly when the window
is closed --*/
gint ClosingAppWindow (GtkWidget *widget, gpointer gdata)
{
g_print ("Quitting...\n");
gtk_main_quit();
return (FALSE);
}
void VimWindow (GtkWidget *widget, gpointer gdata)
{
GtkWidget *vte;
vte = vte_terminal_new();
vte_terminal_fork_command(VTE_TERMINAL(vte), "ls", NULL, NULL,
".", FALSE, FALSE, FALSE);
}
long size;
char *buf;
char *ptr;
int main( int argc, char *argv[] )
{
size = pathconf(".", _PC_PATH_MAX);
if ((buf = (char *)malloc((size_t)size)) != NULL) ptr = getcwd(buf,
(size_t)size);
GtkWidget *window;
GtkWidget *vbox;
GtkWidget *menuFile;
GtkWidget *menuEdit;
GtkWidget *menuApp;
GtkWidget *menuHelp;
GtkWidget *menubar;
GtkWidget *menu;
GtkWidget *menuitem;
GtkWidget *vte;
GtkWidget *notebook;
GtkWidget *scrolled_window;
GtkWidget *label;
gtk_init (&argc, &argv);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_widget_set_size_request (GTK_WIDGET (window), 800, 600);
gtk_window_set_title (GTK_WINDOW (window), "gnomenus v0.1");
g_signal_connect (G_OBJECT (window), "delete_event", G_CALLBACK
(gtk_main_quit), NULL);
vbox = gtk_vbox_new(FALSE,0);
gtk_container_add (GTK_CONTAINER (window), vbox);
menubar = gtk_menu_bar_new();
gtk_box_pack_start(GTK_BOX(vbox), menubar, FALSE, TRUE, 0);
gtk_widget_show(menubar);
/* Create File menu items --*/
menuFile = gtk_menu_item_new_with_label ("File");
gtk_menu_bar_append (GTK_MENU_BAR(menubar), menuFile);
gtk_widget_show(menuFile);
/*-- Create File submenu --*/
menu = gtk_menu_new();
gtk_menu_item_set_submenu(GTK_MENU_ITEM(menuFile), menu);
/*-- Create New menu item under File submenu --*/
menuitem = gtk_menu_item_new_with_label ("Open Tab CTRL+T");
gtk_menu_append(GTK_MENU(menu), menuitem);
gtk_widget_show (menuitem);
/*-- Create Open menu item under File submenu --*/
menuitem = gtk_menu_item_new_with_label ("Open");
gtk_menu_append(GTK_MENU(menu), menuitem);
gtk_widget_show (menuitem);
/*-- Create Exit menu item under File submenu --*/
menuitem = gtk_menu_item_new_with_label ("Exit");
gtk_menu_append(GTK_MENU(menu), menuitem);
gtk_signal_connect(GTK_OBJECT (menuitem), "activate",
GTK_SIGNAL_FUNC (ClosingAppWindow), NULL);
gtk_widget_show (menuitem);
/* End File menu declarations */
/* Create Edit menu items */
menuEdit = gtk_menu_item_new_with_label ("Edit");
gtk_menu_bar_append (GTK_MENU_BAR(menubar), menuEdit);
gtk_widget_show(menuEdit);
/*-- Create File submenu --*/
menu = gtk_menu_new();
gtk_menu_item_set_submenu(GTK_MENU_ITEM(menuEdit), menu);
/*-- Create Undo menu item under Edit submenu --*/
menuitem = gtk_menu_item_new_with_label ("Undo");
gtk_menu_append(GTK_MENU(menu), menuitem);
gtk_widget_show (menuitem);
/*-- Create Copy menu item under File submenu --*/
menuitem = gtk_menu_item_new_with_label ("Copy");
gtk_menu_append(GTK_MENU(menu), menuitem);
gtk_widget_show (menuitem);
/*-- Create Cut menu item under File submenu --*/
menuitem = gtk_menu_item_new_with_label ("Cut");
gtk_menu_append(GTK_MENU(menu), menuitem);
gtk_widget_show (menuitem);
/* End Edit menu declarations */
/* Start App menu declarations */
menuApp = gtk_menu_item_new_with_label ("App");
gtk_menu_bar_append (GTK_MENU_BAR(menubar), menuApp);
gt
how to use gtk in directfb
Hi How to use gtk in directfb or how to map gtk to directfb With regards Shruthi.G Philips Innovation Campus Philips Electronics India Ltd Manyata Tech Park, Nagavara Bangalore 560 045 Tel: +91 80 4189 2870 intranet: pww.bangalore.philips.com internet: www.bangalore.philips.com email: shru...@blr.pin.philips.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GtjComboBox question
Hi, ALL, Is there a function to show a list box of a combo box? It looks like gtk_combo_box_popup() is what I'm looking for, but the documentation says that it should be used with an accessibility pack. Thank you. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Gtk Critical Error While Using Cairo and Pango.
Hello everyone,
I am having following example code which i am using to Draw background of a
window plus a GtkImage On It. I am drawing background of GtkWindow by use of
Cairo on Expose Event. I am Adding One GtkImage on this window and in that
GtkImage i ma adding Text Using Pango but this image is not visible.
You can try and run this program.
It will just display window with given PNG image as background. but not the
image on it. when i use export XLIB_SKIP_ARGB_VISUALS=1 on terminal then it
displays both Window and Image on it but Transparency of background image is
Lost.
Code
#include
#include "string.h"
gboolean DrawTextOnImage(GtkWidget *image, const gchar *markup, const gchar*
fg_color)
{
g_return_val_if_fail( image != NULL, FALSE );
g_return_val_if_fail( markup != NULL, FALSE );
gint x, y, pwidth, pheight;
GdkGC *gc;
GdkPixmap *pixmap;
GdkPixbuf *pixbuf;
GdkColor color;
GdkBitmap *mask;
PangoRectangle extents;
GtkRequisition req;
pixbuf = gtk_image_get_pixbuf( GTK_IMAGE(image) );
gdk_pixbuf_render_pixmap_and_mask( pixbuf, &pixmap, &mask, 1 );
if (fg_color == NULL)
gdk_color_parse("black", &color);
else
gdk_color_parse(fg_color, &color);
gc = gdk_gc_new( GDK_DRAWABLE( pixmap ) );
gdk_gc_set_rgb_fg_color(gc, &color);
PangoLayout *layout;
layout = pango_layout_new( gtk_widget_get_pango_context(image));
pango_layout_set_markup( layout, markup, strlen(markup) );
pango_layout_get_pixel_extents (layout, &extents, NULL);
gtk_widget_size_request( image, &req );
x = image->allocation.x;
y = image->allocation.y;
gdk_draw_layout( GDK_DRAWABLE(pixmap),
gc,
x + (req.width - extents.width) / 2,
y + (req.height - extents.height) / 2,
layout);
g_object_unref (G_OBJECT (gc));
g_object_unref (G_OBJECT (layout));
GdkColormap *cmap = NULL;
cmap = gtk_widget_get_colormap(image);
gdk_drawable_get_size(pixmap, &pwidth, &pheight);
pixbuf = gdk_pixbuf_get_from_drawable( NULL, pixmap, cmap,
0 , 0,
0 , 0,
pwidth, pheight );
g_object_unref( pixmap );
GdkPixmap *new_pixmap;
gdk_pixbuf_render_pixmap_and_mask( pixbuf, &new_pixmap, NULL, 1 );
gtk_image_clear( GTK_IMAGE(image) );
gtk_image_set_from_pixmap( GTK_IMAGE(image), new_pixmap, mask );
g_object_unref( pixbuf );
g_object_unref( cmap );
return TRUE;
}
G_MODULE_EXPORT gboolean window_expose_cb(GtkWidget *widget, GdkEventExpose
*event, gpointer data)
{
char *img_path = g_build_filename( "background.png", NULL);
cairo_surface_t *g_imgGlass;
g_imgGlass = cairo_image_surface_create_from_png( img_path );
g_free( img_path );
cairo_t *cr;
cr = gdk_cairo_create(widget->window);
cairo_set_source_surface(cr, g_imgGlass, 0, 0);
cairo_set_operator(cr, CAIRO_OPERATOR_SOURCE);
cairo_paint(cr);
cairo_destroy(cr);
return FALSE;
}
int main( int argc, char *argv[])
{
GtkWidget *window;
GtkWidget *image;
GdkScreen* screen;
GdkColormap*colormap;
gtk_init(&argc, &argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER);
gtk_window_set_default_size(GTK_WINDOW(window), 350, 100);
gtk_window_set_title(GTK_WINDOW(window), "XYZ");
gtk_container_set_border_width(GTK_CONTAINER(window), 5);
gtk_window_set_resizable( GTK_WINDOW(window), FALSE );
gtk_window_set_decorated(GTK_WINDOW(window), FALSE);
gtk_widget_set_app_paintable(window, TRUE);
gtk_window_set_opacity(GTK_WINDOW(window), 1);
gtk_widget_set_events(window, GDK_EXPOSURE_MASK
| GDK_ENTER_NOTIFY_MASK
| GDK_LEAVE_NOTIFY_MASK
| GDK_BUTTON_PRESS_MASK
| GDK_BUTTON_RELEASE_MASK
| GDK_POINTER_MOTION_MASK | GDK_POINTER_MOTION_HINT_MASK);
g_signal_connect(G_OBJECT(window), "expose-event",
G_CALLBACK(window_expose_cb), NULL);
g_signal_connect(G_OBJECT(window), "destroy", G_CALLBACK(gtk_main_quit),
NULL );
image = gtk_image_new_from_file("Button_normal.png");
gtk_container_add(GTK_CONTAINER(window), image );
DrawTextOnImage(image, "Some Text",
"#FF" );
screen = gtk_widget_get_screen(window);
colormap = gdk_screen_get_rgba_colormap(screen);
gtk_widget_set_colormap(window, colormap);
gtk_widget_show_all(window);
gtk_main();
return 0;
}
Some times i get these types of Warnings and Errors:
GObject Introspection Support and Gnome 3.0
How is desirable to have support of GObjectInstrospection in a Gnome component for the upcomming Gnome 3.0 release? What if I need to break ABI to get "easy support" of GObjectIntrospection for a library? -- Trabajar, la mejor arma para tu superación "de grano en grano, se hace la arena" (R) (en trámite, pero para los cuates: LIBRE) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gnome-db] GObject Introspection Support and Gnome 3.0
2009/12/2 Daniel Espinosa : > How is desirable to have support of GObjectInstrospection in a Gnome > component for the upcomming Gnome 3.0 release? > > What if I need to break ABI to get "easy support" of > GObjectIntrospection for a library? I would be very surprised if there wasn't any way to add introspection support without breaking the ABI, and I really don't want to break the ABI now. So please try to find a way for the few objects which are a problem and make special (not automatically generated) rules for them (if I remember correctly there are ony 2 or 3). Thanks a lot for the work you put in bringing introspection support to Libgda. Vivien ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Embedding the VTE Virtual Terminal
On Thu, Nov 26, 2009 at 3:07 PM, Stevenix wrote:
>
> Hi,
>
> I'm writing a Gui+Terminal application, where VTE is embedded on window,
> and
> the GUI Menu Items.
>
> And i'm trying to call this action...
>
> ... calls to this action from the menu... (just fork a 'ls' command)
>
> But i'm unable to get the 'ls' listing ...
>
> void VimWindow (GtkWidget *widget, gpointer gdata)
>{
>GtkWidget *vte;
> vte = vte_terminal_new();
> [b]vte_terminal_fork_command(VTE_TERMINAL(vte), "ls", NULL,
> NULL, ".", FALSE, FALSE, FALSE);[/b]
>}
>
>
Try something like this (untested):
char [][] argv = {
"ls", NULL
};
vte_terminal_fork_command(VTE_TERMINAL(vte), "ls", argv, NULL, ".", FALSE,
FALSE, FALSE);
If I recall well the first "ls" is actually the name you want the users to
see when they run ps while argv[0] has the name of the program to execute.
--
Emmanuel Rodriguez
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Enable threads by default
On Wed, Dec 2, 2009 at 11:03 AM, Alexander Larsson wrote: > > Running with this patch i ran into an issue while building gnome-shell: > > GEN Gdm-1.0.gir > > GThread-ERROR **: GThread system may only be initialized once. > aborting... > Command '['/gnome/src/gnome-shell/src/tmp-introspectpoWP_f/Gdm-1.0', > '--introspect-dump=/gnome/src/gnome-shell/src/tmp-introspectpoWP_f/types.txt,/gnome/src/gnome-shell/src/tmp-introspectpoWP_f/dump.xml']' > returned non-zero exit status -5 > > Not sure exactly what crashed, but obviously something ran: > g_type_init() and then g_thread_init(). Maybe we need to make this a > non-fatal warning? Nah, just a bug in the dumper. Fixed: commit ffd9b39620c9665a8685363202b4f02fa895288c Author: Colin Walters Date: Wed Dec 2 12:56:52 2009 -0500 [dumper] Fix threads initialization Correctly guard with g_thread_supported, call g_thread_init before g_type_init. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Enable threads by default
On Wed, 2009-12-02 at 18:01 +, Colin Walters wrote: > On Wed, Dec 2, 2009 at 11:03 AM, Alexander Larsson > wrote: > > > > Running with this patch i ran into an issue while building > gnome-shell: > > > > GENGdm-1.0.gir > > > > GThread-ERROR **: GThread system may only be initialized once. > > aborting... > > Command '['/gnome/src/gnome-shell/src/tmp-introspectpoWP_f/Gdm-1.0', > > > '--introspect-dump=/gnome/src/gnome-shell/src/tmp-introspectpoWP_f/typ > es.txt,/gnome/src/gnome-shell/src/tmp-introspectpoWP_f/dump.xml']' > returned non-zero exit status -5 > > > > Not sure exactly what crashed, but obviously something ran: > > g_type_init() and then g_thread_init(). Maybe we need to make this a > > non-fatal warning? > > Nah, just a bug in the dumper. Fixed: This particular instance is fixed, but there can be a lot more out there. Why force every app to add this check when we could do it ourselves. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's a genetically engineered neurotic boxer with a robot buddy named Sparky. She's a warm-hearted out-of-work advertising executive with someone else's memories. They fight crime! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: differences between Glade and GtkBuilder
Yes. They are all set to visible. I'll change them in the GUI and see if that makes a difference. I still think something in the process has changes, at least from the "user" perspective. I'm almost certain, that with glade you would load the xml (containing many top levels), then, call get the object you wanted out (which at that time it would construct and realize the widget making it visible) It seems with GtkBuilder loading the XML and realizing it are done in the same step, which makes it so that each individual top level has to be in its own file? Does it not make more sense to have a function that load the XML without realizing anything, then, as objects are requested, doing the actual construction and realization? EMAILING FOR THE GREATER GOOD Join me > Subject: Re: > From: sc...@asofyet.org > Date: Wed, 2 Dec 2009 13:37:42 -0500 > To: shashan...@hotmail.com > > > On Dec 1, 2009, at 1:01 PM, Shawn Bakhtiar wrote: > > > Previously, I was able to open a Glade XML file with multiple top level > > windows, and only load the specific window I wanted from within that file. > > I have tried to re-write this routine, however, every time a call is made > > to gtk_builder_add_from_file it not only loads the file but it also loads > > and displays ALL the windows in that file. > > > > Should this not work like glade did before, where you would load the file, > > then call the objects you wanted to be displayed? > > Do you have the "visible" property set for all of the windows in the > buildable xml? > > glade would also always construct all of the windows in the xml, but i think > there was a default to *not* visible. (It would also construct them only > when you parse the xml, so if you let them be destroyed, you had to parse the > file again. I haven't used buildable enough to tell you if it behaves that > way.) > > > -- > I've been using emacs for 20+ years and have barely touched lisp. I wouldn't > know lambda calculus if it took all its clothes off and waved a placard that > reads "I am lambda calculus" in blinking 48-point Comic Sans. > -- Dave Hodgkinson, on london.pm > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Enable threads by default
On Wed, Dec 2, 2009 at 8:38 PM, Alexander Larsson wrote: > > This particular instance is fixed, but there can be a lot more out > there. Why force every app to add this check when we could do it > ourselves. I'm not objecting to defaulting to working around this bug; it's certainly possible other applications do it. However the docs are pretty clear on how to call g_thread_init, and I was doing it wrong =) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: differences between Glade and GtkBuilder
On Wed, Dec 2, 2009 at 6:52 PM, Shawn Bakhtiar wrote: [...] Note that this list is about the development of GTK+ itself, please address gtk-app-devel-list or gtk-list in the future for help using the GTK+ apis. > I'm almost certain, that with glade you would load the xml (containing many > top levels), then, call get the object you wanted out (which at that time it > would construct and realize the widget making it visible) > > It seems with GtkBuilder loading the XML and realizing it are done in the > same step, which makes it so that each individual top level has to be in its > own file? > Does it not make more sense to have a function that load the XML without > realizing anything, then, as objects are requested, doing the actual > construction and realization? > FYI libglade and GtkBuilder work the same way in this respect; Parsing the file builds the widget hierarchy. If your widgets are getting realized in the process of parsing the file, it means that one of your toplevel widgets is set to be visible at startup time (as the builder/libglade sets the toplevel to be visible, this triggers the realize) - you can deffer the realization of your widgets by building the toplevels in your project with the "visible" property set to False (and then showing/realizing them at a later time) Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
