Re: Best practice for bundling GTK with an windows application?
Oops. Make that: http://ftp.gnome.org/pub/gnome/binaries/win32/ Regards, Dov 2009/7/11 Dov Grobgeld dov.grobg...@gmail.com I've been doing cross platform development and windows installer during the last few years of lots of C/C++ programs. Here is an outline of my practices: - Build done through scons. - Special scons rules for doing cross compilation for Windows from Linux. - Use NSIS for Windows installer deployment. (cross compiled mingw32 version of nsis used). - The Windows installer is self contained, i.e. it is not dependent on the installation of a separate gtk installation. - The windows binaries are the standard compiled binaries from ftp.gtk.org - Testing done through a WinXP installation under VirtualBox. See the SConstruct and NSIS files of my two programs giv and gemtcl for examples of how to do the above. Regards, Dov 2009/7/11 Hartmut Goebel h.goe...@goebel-consult.de Hi, I'm currently working to make setting up a Python application (www.tryton.org) easier for Windows users. Meanwhile I'm totally confused about which package of bundle to use and what to put into the installer package. Now GTK for Windows comes in quite a lot of flavours. Since Tryton uses pygtk Co., we only need the runtime environment, no developer files. But there are still some options left: - zipped runtime bundle including 3rd-party dependencies. - zipped archives for individual packages (glib, gtk+, pango, ...) - installer from glade-win32 somewhat outdated, but including librsvg http://sourceforge.net/projects/gladewin32/files/ - installer from http://gtk-win.sourceforge.net/: much more up to date but missing librsvg and libbz2 Which one should I use? Is there some agreed best practice? I'm currently tending to this solution: * use the installer from gtk-win for the development environment * put additional .dlls (e.g. librsvg) into the development directory * include the whole gtk-win installer into the Tryton installer. Any comments or suggestions anyone? -- Schönen Gruß - Regards Hartmut Goebel Dipl.-Informatiker (univ.), CISSP, CSSLP Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkAssistant flow question
Hi, I have a simple GtkAssistant with : - one intro page - two content pages - one confirm page - one summary page. All works fine : the confirm page has 'Cancel' and 'Apply' buttons, and the summary page has only a 'Close' button. Of course (or is it only obvious for me ?), I'd wish display on the summary page the result of the work done when the user has clicked on the Apply button. But it appears that the next page is computed, and so the 'prepare' message is sent, _before_ the 'apply' message is itself emitted. So, when I handle the prepare message for the summary page, I don't know what is the result of the operations, as they have not be done yet. As a work-around, I have to do the work at the very beginning of the prepare handler. And so handling the apply message becomes useless. IMHO, the usual programmer does want 'apply' its operations before 'preparing' the display of the summary page. As the GtkAssistant cannot be considered as new (appeared in 2.9 or so), it is surely not a bug. But I don't understand the rationale behind this. Could someone explain it to me ? Why this order has it be choosen ? And how do we should handle the apply message ? Thanks in advance. Regards Pierre ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkAssistant vs. GtkFileChooserWidget
Hi all,
I'm building a GtkAssistant which embeds a GtkFileChooserWidget
in one of the content pages.
My problem is when I run the assistant for the second times, the
GtkfileChooserWidget doesn't display at all. Below the sample code
which reproduces the problem :
enum {
ASSIST_PAGE_INTRO = 0,
ASSIST_PAGE_FILES_SELECTION,
ASSIST_PAGE_DONE
};
static void
on_cancel( GtkAssistant *assistant, gpointer user_data )
{
gtk_widget_hide_all( GTK_WIDGET( assistant ));
gtk_main_quit();
}
/**
* Run the assistant.
*/
void
nact_assist_import_run( void )
{
static GtkBuilder *xml = NULL;
if( !xml ){
xml = gtk_builder_new();
gtk_builder_add_from_file( xml, GLADEDIR
/nautilus-actions-config.ui, NULL );
}
GtkAssistant *assistant = GTK_ASSISTANT( gtk_builder_get_object( xml,
ImportAssistant ));
GtkWidget *intro = gtk_assistant_get_nth_page( assistant,
ASSIST_PAGE_INTRO );
gtk_assistant_set_page_complete( assistant, intro, TRUE );
GtkWidget *selector = gtk_assistant_get_nth_page( assistant,
ASSIST_PAGE_INTRO );
gtk_assistant_set_page_complete( assistant, selector, TRUE );
g_signal_connect( G_OBJECT( assistant ), cancel, G_CALLBACK(
on_cancel ), NULL );
gtk_widget_show_all( GTK_WIDGET( assistant ));
gtk_main();
}
Note that if I initialize a new GtkBuilder _each time_ I run the
assistant, then all works fine. But I feel this work-around as a
waste of resources...
Note also that embedding other widgets (combobox or so) is fine,
and doesn't show the same problem.
Could someone be kind enough to explain me what is wrong in the code ?
Or what is wrong in embedding a GtkFileChooserWidget in a GtkAssistant ?
Thanks in advance
Regards
Pierre
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Copying widgets
Hi all, I'm writing a program that, like gimp, has a control window, from which users can open one or more viewer windows that present different aspects of a data set (it's a weather radar display program). The sub-windows are identical, and I'm using libglade and glade-3 to do the interface layouts. Currently, I call glade_xml_new each time I want to create a new window. Is there a better way, which prevents libglade from having to parse the XML each time? Also, I'm interested in moving to GtkBuilder. Do I use different xml files for each window and create a new GtkBuilder object for each new viewer window, or is there a smarter way? Thanks in advance. -Jim ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Copying widgets
On Sun, Jul 12, 2009 at 3:27 PM, Jim Georgejimgeo...@gmail.com wrote: Hi all, I'm writing a program that, like gimp, has a control window, from which users can open one or more viewer windows that present different aspects of a data set (it's a weather radar display program). The sub-windows are identical, and I'm using libglade and glade-3 to do the interface layouts. Currently, I call glade_xml_new each time I want to create a new window. Is there a better way, which prevents libglade from having to parse the XML each time? Sure, you can build the dialog at startup time or on demand the first time, but just hide it and show it on demand. Also, I'm interested in moving to GtkBuilder. Do I use different xml files for each window and create a new GtkBuilder object for each new viewer window, or is there a smarter way? GtkBuilder works pretty much the same way, but GTK+ now inherits the parsing code, so you cannot build a GTK+ interface from a GtkBuilder format file without running the actual parsing code from the widgets (which I guess is one thing libglade provides that GtkBuilder does not; the ability to compile the glade file into a binary and completely replace the parser). Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Copying widgets
On Sun, Jul 12, 2009 at 3:46 PM, Tristan Van Berkomt...@gnome.org wrote: On Sun, Jul 12, 2009 at 3:27 PM, Jim Georgejimgeo...@gmail.com wrote: Hi all, I'm writing a program that, like gimp, has a control window, from which users can open one or more viewer windows that present different aspects of a data set (it's a weather radar display program). The sub-windows are identical, and I'm using libglade and glade-3 to do the interface layouts. Currently, I call glade_xml_new each time I want to create a new window. Is there a better way, which prevents libglade from having to parse the XML each time? Sure, you can build the dialog at startup time or on demand the first time, but just hide it and show it on demand. That's how I handle things like properties dialog boxes. The display windows, however, are different in that there can be more than one open at a time, and I have no way to predict how many the user would like to have open. Currently, I'm forced to call glade_xml_new for each new display window the user would like. If there was a clone function, though, I could have done something like create a window on startup, then clone it for each new window that the user wanted. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK on Macintosh OSX
On Sat, Jul 11, 2009 at 2:14 PM, John Rallsjra...@ceridwen.us wrote: As you all probably know, Richard Hult has withdrawn from working further on the osx/quartz implementation of gtk. You may not know that I have taken over the build, bundle, and menu integration part of that and consolidated it at http://gtk-osx.sourceforge.net. I'm concerned, though, about how committed the gtk development team is to completing and maintaining the internal parts. There are some serious holes (pasting and drag-and-drop don't work, just as a particularly egregious example). Richard told me that he hoped that some of his former Immendio colleagues would step up, but I don't see that that's happening. I have a fix for drag-n-drop that we have been using with Ardour for more than a year. I will get into bugzilla for review. Its a pretty simple patch. Not sure what problem you have with pasting, but that works fine for all the purposes that we use it for in Ardour. We bundle Ardour for OS X and chose the include GTK framework in the .app. Ardour is fully relocatable - I believe I was responsible for the description of how to do this that Richard wrote up. Its basically a matter of using an apple-provided tool to both locate and reset the paths to every library the app depends on. I have a nice little shell script that recursively finds every dynamically linked object that the app uses, copies it into the app structure and then resets the link-time dependency so that its relative to the app bundle. Because we have/need a couple of hacks in GTK that are not likely to go away anytime soon, I can't imagine us being interested in the blessed framework approach. Regarding the general question of non-X11 backends being 2nd-class citizens ... yes, I have seen and suffered from this problem when I was doing work on gtk/osx last year and the previous year. It would be nice if we could somehow get the core GTK team to commit to not making changes that are not tested on non-X11 backends, but this seems unlikely and the reasons are not totally unreasonable. Given that Ardour on OS X is critical to my income, you can expect me to have a strong interest in keeping at least some version of GTK functional on OS X and on continuing to fix issues that we encounter. --p ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Trouble with core.autocrlf=true on GLib and Gtk+ master
Two translation files are recently causing some grief when working with GLib and Gtk+ master. Before a git pull --rebase I need to commit the changes I doidn't do. And afterwards I have to git rebase --abort because these changes can not be merged. The problem are wrong line-endings and I'd like to get some input how to best fix it (without switching core.autocrlf to false). Shoud I just convert these files to the right line-endings and commit them from Linux? Shoud there be a pre-commit hook to avoid such trouble in the future? Thanks, Hans D:\devel\from-git\gtk+git pull --rebase po/li.po: needs update refusing to pull with rebase: your working tree is not up-to-date D:\devel\from-git\glibgit pull --rebase po/be.po: needs update refusing to pull with rebase: your working tree is not up-to-date Hans at Breuer dot Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: client-side-windows merged
Alexander Larsson wrote: The client-side-windows branch has now been merged into master. The http://git.gnome.org/cgit/gtk+/commit/?id=0b586a5a change to gdkdrawable.h: @@ -100,6 +100,7 @@ struct _GdkDrawableClass void (*draw_drawable) (GdkDrawable *drawable, GdkGC*gc, GdkDrawable *src, + GdkDrawable *original_src, gint xsrc, gint ysrc, gint xdest, breaks a part of the API/ABI that is (at least) used in PyGTK: gdk.c:7243: warning: passing argument 4 of ‘((struct GdkDrawableClass *)g_type_check_class_cast((struct GTypeClass *)klass, gdk_drawable_get_type()))-draw_drawable’ makes pointer from integer without a cast gdk.c:7243: error: too few arguments to function ‘((struct GdkDrawableClass *)g_type_check_class_cast((struct GTypeClass *)klass, gdk_drawable_get_type()))-draw_drawable’ How should this matter be resolved ? Frederic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk-doc for non-library.
Hi, I want to document C code written let's say in files obj.c obj.h contain GObject, signals, properties, in order to doc these gtk-doc needs the _get_type function to produce GObject doc, but this code is not a library and i don't want to have .la library in the project just to doc the code. I wonder if someone can help. Thanks. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: the 2.18 endgame
On Fri, 2009-07-10 at 21:35 -0500, Cody Russell wrote: On Fri, 2009-07-10 at 10:45 -0400, Matthias Clasen wrote: GTK+ 2.90: - Outstanding GSEAL issues have not been resolved. bratsche spent some time on it, but gave up for lack of feedback Here is my proposal: - If people still want to do a 2.90 release in parallel with 2.18, now is the time to step forward and finish the GSEAL work Mitch said he has almost gotten GIMP compiling with GSEAL, minus about ~10 missing functions. So this is actually not quite as far off as it seemed before. The big missing thing at the moment is new API for widget-allocation and widget-requisition, which I will try to push for resolution on soon. Indeed. I have actually started to make GIMP work with GSEAL again now. Accessors for GtkCellRenderer and some widget flag API (e.g. gtk_widget_get_sensitive() and is_sensitive()) are already done. Will file patches this week. ciao, --mitch ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: client-side-windows merged
On 07/12/2009 01:02 PM, Frederic Peters wrote: Alexander Larsson wrote: The client-side-windows branch has now been merged into master. The http://git.gnome.org/cgit/gtk+/commit/?id=0b586a5a change to gdkdrawable.h: @@ -100,6 +100,7 @@ struct _GdkDrawableClass void (*draw_drawable) (GdkDrawable *drawable, GdkGC*gc, GdkDrawable *src, + GdkDrawable *original_src, gint xsrc, gint ysrc, gint xdest, breaks a part of the API/ABI that is (at least) used in PyGTK: gdk.c:7243: warning: passing argument 4 of ‘((struct GdkDrawableClass *)g_type_check_class_cast((struct GTypeClass *)klass, gdk_drawable_get_type()))-draw_drawable’ makes pointer from integer without a cast gdk.c:7243: error: too few arguments to function ‘((struct GdkDrawableClass *)g_type_check_class_cast((struct GTypeClass *)klass, gdk_drawable_get_type()))-draw_drawable’ How should this matter be resolved ? For starters, why isn't pygtk just using gdk_drawable_draw_drawable() instead of dereferencing the class pointer? Regardless, if you check out current master, it appears that change that's causing your problem isn't there anymore (instead there's a draw_drawable_with_src function pointer that's been added to GdkDrawableClass). See http://git.gnome.org/cgit/gtk+/log/gdk/gdkdrawable.h. This was fixed 11 days ago, it seems. -brian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Cairo based engine api for GTK+ 3.0
On Thu, 2009-06-18 at 22:45 +0100, Chris Wilson wrote: On Thu, 2009-06-18 at 22:35 +0100, Thomas Wood wrote: Thanks Chris. Obviously once the API is converted to pass in cairo contexts, the context creation/destruction will happen outside of the drawing functions. That's a relief. I was thinking to myself that it was a good job I'd just managed to eliminate some overhead from cairo_create()... :-) Just a little up date on this; I've pushed a commit that changes the gtk_paint_* API to take a cairo context rather than a GdkWindow. This clearly breaks all widgets and so although it compiles, it won't run in any shape or form. I'm a bit undecided on how to proceed next. I could go through every single use of gtk_paint_* in GTK+ and update it to the new API. However, this will be somewhat tedious and lengthy task, and if we want to change the API further (such as remove the GtkWidget pointer), I'd have to this all over again. Any thoughts would be welcome. Regards, Thomas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: client-side-windows merged
On Sun, Jul 12, 2009 at 7:50 PM, Brian J. Tarriconebj...@cornell.edu wrote: For starters, why isn't pygtk just using gdk_drawable_draw_drawable() instead of dereferencing the class pointer? Regardless, if you check out current master, it appears that change that's causing your problem isn't there anymore (instead there's a draw_drawable_with_src function pointer that's been added to GdkDrawableClass). See http://git.gnome.org/cgit/gtk+/log/gdk/gdkdrawable.h. This was fixed 11 days ago, it seems. Yes, the api breakage was discovered soon after the merge and is fixed in 2.17.4 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK on Macintosh OSX
On Jul 12, 2009, at 4:29 AM, Paul Davis wrote: I have a fix for drag-n-drop that we have been using with Ardour for more than a year. I will get into bugzilla for review. Its a pretty simple patch. Not sure what problem you have with pasting, but that works fine for all the purposes that we use it for in Ardour. We bundle Ardour for OS X and chose the include GTK framework in the .app. Ardour is fully relocatable - I believe I was responsible for the description of how to do this that Richard wrote up. Its basically a matter of using an apple-provided tool to both locate and reset the paths to every library the app depends on. I have a nice little shell script that recursively finds every dynamically linked object that the app uses, copies it into the app structure and then resets the link-time dependency so that its relative to the app bundle. Because we have/need a couple of hacks in GTK that are not likely to go away anytime soon, I can't imagine us being interested in the blessed framework approach. Regarding the general question of non-X11 backends being 2nd-class citizens ... yes, I have seen and suffered from this problem when I was doing work on gtk/osx last year and the previous year. It would be nice if we could somehow get the core GTK team to commit to not making changes that are not tested on non-X11 backends, but this seems unlikely and the reasons are not totally unreasonable. Given that Ardour on OS X is critical to my income, you can expect me to have a strong interest in keeping at least some version of GTK functional on OS X and on continuing to fix issues that we encounter. --p Paul, Yes, the nice little shell script is part of ige-mac-bundler, a python program which populates a bundle and which is now in my care. But the problem isn't with rpaths. The problem is with path strings compiled into the library. Ardour must not run into this problem, but Gnucash does, in spades. There are three alternative solutions: 1. Build the library to use /Library/Application Support/Appname for its data prefix. Then the library can be bundled as usual, but has to use Installer to populate the data directory. 2. Bundle related libraries and executables into Frameworks with a hard-coded installation in /Library/Frameworks, and link the frameworks to the installation. Again, Installer is required. 3. Patch everything to discover if it's in a bundle, and if so use CFBundle functions to find its resources. This can create a drag-and- drop installation, but the work required is a bit daunting. There's one other, rather hacky, approach: Build into a $prefix, bundle with the install_name_tool routine turned off, and have the launch script create a softlink from the bundle's resources directory to $prefix if it's not already there. I've just implemented it for Gnucash. I don't think that it should be the official way, but it is a way. I'd like to see your fix for d-n-d. The problem I see with pasting is simply that when I cut something and try to paste it back in, nothing pastes. That could be a problem on the cut side instead of the paste side. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK on Macintosh OSX
Glib on Win32 has routines to solve this problem. It resolves things relative to where the Glib DLL is installed. If your applications use the XDG data directory functions in Glib, you might get away with this too. Maybe you could invent something similar that used the OSX bundle as your point of reference. On Sun, Jul 12, 2009 at 9:10 PM, John Rallsjra...@ceridwen.us wrote: On Jul 12, 2009, at 4:29 AM, Paul Davis wrote: I have a fix for drag-n-drop that we have been using with Ardour for more than a year. I will get into bugzilla for review. Its a pretty simple patch. Not sure what problem you have with pasting, but that works fine for all the purposes that we use it for in Ardour. We bundle Ardour for OS X and chose the include GTK framework in the .app. Ardour is fully relocatable - I believe I was responsible for the description of how to do this that Richard wrote up. Its basically a matter of using an apple-provided tool to both locate and reset the paths to every library the app depends on. I have a nice little shell script that recursively finds every dynamically linked object that the app uses, copies it into the app structure and then resets the link-time dependency so that its relative to the app bundle. Because we have/need a couple of hacks in GTK that are not likely to go away anytime soon, I can't imagine us being interested in the blessed framework approach. Regarding the general question of non-X11 backends being 2nd-class citizens ... yes, I have seen and suffered from this problem when I was doing work on gtk/osx last year and the previous year. It would be nice if we could somehow get the core GTK team to commit to not making changes that are not tested on non-X11 backends, but this seems unlikely and the reasons are not totally unreasonable. Given that Ardour on OS X is critical to my income, you can expect me to have a strong interest in keeping at least some version of GTK functional on OS X and on continuing to fix issues that we encounter. --p Paul, Yes, the nice little shell script is part of ige-mac-bundler, a python program which populates a bundle and which is now in my care. But the problem isn't with rpaths. The problem is with path strings compiled into the library. Ardour must not run into this problem, but Gnucash does, in spades. There are three alternative solutions: 1. Build the library to use /Library/Application Support/Appname for its data prefix. Then the library can be bundled as usual, but has to use Installer to populate the data directory. 2. Bundle related libraries and executables into Frameworks with a hard-coded installation in /Library/Frameworks, and link the frameworks to the installation. Again, Installer is required. 3. Patch everything to discover if it's in a bundle, and if so use CFBundle functions to find its resources. This can create a drag-and-drop installation, but the work required is a bit daunting. There's one other, rather hacky, approach: Build into a $prefix, bundle with the install_name_tool routine turned off, and have the launch script create a softlink from the bundle's resources directory to $prefix if it's not already there. I've just implemented it for Gnucash. I don't think that it should be the official way, but it is a way. I'd like to see your fix for d-n-d. The problem I see with pasting is simply that when I cut something and try to paste it back in, nothing pastes. That could be a problem on the cut side instead of the paste side. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- I like to pay taxes. With them, I buy civilization. -- Oliver Wendell Holmes ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK on Macintosh OSX
On Jul 12, 2009, at 6:18 PM, Dominic Lachowicz wrote:
Glib on Win32 has routines to solve this problem. It resolves things
relative to where the Glib DLL is installed. If your applications use
the XDG data directory functions in Glib, you might get away with this
too. Maybe you could invent something similar that used the OSX bundle
as your point of reference.
The routines only solve the problem if they're used.
Don't need to invent anything. The core foundation functions are easy
to use, and Richard Hult already abstracted it into a gobject. But the
code still has to be patched. It's not just application code, either,
but infrastructure libraries like gconf, gnome-keyring, dbus, etc.
I set up a $PREFIX of /usr/local/gtk, built Gnucash, and ran `find /
usr/local/gtk -name *.dylib -exec strings \{\} | grep -H 'local/gtk'
\; ` and got more than 100 hits. Many of them are likely to be just a
define that isn't used for anything, but every one would have to be
examined, and a goodly number of them would require patching.
Regards,
John Ralls
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
