Re: Can't localize GTK+ itself on Windows XP
> The mistake was I didn't notice py2exe didn't automatically package > int.dll, so now I include it manually. Ah OK. intl.dll is loaded at run-time, if available. I.e., if an application doesn't have localisation for its own messages, it makes little sense to ship it with GTK+ localisation then either, and in that case one can just leave intl.dll out, too. > UPX works nicely with all of GTK and saves me about half the space > plus a little disk I/O time. Good to hear. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Can't localize GTK+ itself on Windows XP
On Mon, Jul 27, 2009 at 12:40 AM, Tor Lillqvist wrote: >> * GTK 2.16.4 from binaries at http://www.gtk.org/download-windows.html > > Including the gettext-runtime binaries? Yes. >> * Executables compressed with UPX > > Including the GTK+ DLLs? Yes > Try without doing this. I have no idea how > UPX works, but I guess it is possible that it decompresses the DLL to > a temporary location and then loads it from there? That would break > the lookup of the message catalogs. The mistake was I didn't notice py2exe didn't automatically package int.dll, so now I include it manually. UPX works nicely with all of GTK and saves me about half the space plus a little disk I/O time. Andrew ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Virtual drag drop using gtk api's
rajat mahajan wrote: > The link i have provided is on windows. I need the same on Linux I don't know anything about it, really. Here is a link on the freedesktop specification that might give you some idea. Then again it might not. Basically there's nothing in the drag and drop raw protocol to prohibit this from working, but it's a matter of what the drop target expects (which you have no control over). http://www.freedesktop.org/wiki/Specifications/XDS ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: custom tree model, iters, and memory management
Kristian Rietveld wrote: Hi, On Sun, Jul 26, 2009 at 8:22 PM, Thomas Stover wrote: While working on a custom tree model (thanks to Tim-Philipp Müller for the tutorial), I needed more pointers in my iter structure than the user_data, user_data2, and user_data3. So I defined a new structure and stored that in user_data. For the model's _get_iter(), _iter_children(), _iter_parent(), iter_nth_child() methods, if the "output" iter's user_data is NULL, a new one of these "extra pointers structures" gets allocated. At the moment, all of these allocations get also referenced in a GSList in the custom model, and freed when the model is finalized. While this does work ok, it feels strange. Any thoughts? Some light analysis shows the treeview doesn't use that many iters, so maybe this is fine? Feels strange indeed :) One of the problems is that you do not really know when an iterator is no longer used. This also depends on whether your model hands out persistent or non-persistent iterators. Persistent iterators stay valid for ever, non-persistent stay valid until the model changes its stamp, which is whenever the internal data structure of the model changes in such a way that the iterator for the same node will be different. For the persistent case, you need to keep all these extra allocated structures around until finalization, if you really allocate a new structure for every iterator handed out, the memory usage here is not bounded. I would suggest you to have a look at how GtkTreeModelSort and GtkTreeModelFilter handle this. A valid iterator only exists for a row in your model. You can group all the data you need for each row in a structure and group these structures in a list or tree form representing the layout of your model. Each row now has a structure with all required data and is accessible by a pointer. Instead of allocating a new structure for each iterator, put the pointer to the (already allocated) structure in the model's internal data structure in the iterator's user_data pointer. No need to allocate a new structure each time and the other model methods of your model can use the pointer in the iterator's user_data to access the internal data structure. Hope this helps and clear things up a bit. regards, -kris. Thanks for the input. Ideally iters would have an optional callback to free private data, but I think understand the thinking behind the design more now. It seems the custom model approach would be best if, as you describe, you can just point iters to real data nodes directly. In may case I think it is going to be worth going back to the source data store that I'm providing an optional gtk tree model wrapper for, and redoing it slightly so that every leaf depth uses the same base C structure, enabling me to do that. People like to say that low level Gtk+ is a rough edge, and while it is in deed something one has to "learn to love", there is just no substitute for the power and flexibility it offers. This being an excellent example. Thanks again Gtk world. On the same topic, I'm trying to think of the best way to deal with the performance of deriving iterators from paths in a case like mine. Essentially I have linked lists that right now have to be traversed through to the the Nth position to resolve a path of N for a given depth. I could store another table somewhere with indexes mapped to pointers, but this table itself would have to be dynamically resized and completely rebuilt every time the data changed, virtually defeating the point of the linked list. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Makeing librsvg work (bizp2.dll missing)
> That sounds straight forward enough. And a hell of a lot better than the > current situation. By all means, go ahead then and create a project aiming at this, and convince all distributors of installers for GTK+-using software to cooperate with you. Please note that not all GTK+-using applications on Windows use the same builds of the GTK+ stack. Some use the ones from ftp.gnome.org, others use these but with digital signatures added to the DLLs, others compile the stack themselves (with some own patches perhaps, even). > At least that way, with some minimal smarts in the installer, the GTK > libraries will get the occasional update. Are there any good reasons why > that shouldn't be the default install? It is, unfortunately, so that new versions of GLib, Pango or GTK+ often introduce subtle regressions especially on Windows. (On Unix / X11 this is much less of a problem.) Some of these regressions then might be especially troublesome for a particular application. Thus one application might want to stay with specifically GLib 2.16.6 (to pick an arbitrary example), while another application again requires new API in GLib 2.18. Etc. > How hard would it be to provide a "GTK sub-installer" For which installer-writing technology? Windows Installer (a.k.a MSI) (perhaps with the WiX front-end), NSIS, InnoSetup, InstallShield? (Just to mention the best known (?).) Or something totally different, new and improved? --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Virtual drag drop using gtk api's
The link i have provided is on windows. I need the same on Linux On Thu, Jul 30, 2009 at 10:21 PM, Michael Torrie wrote: > Is this on Solaris? Linux? X11? Framebuffer? OS X? > ___ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > -- Regards, Rajat Mahajan. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Makeing librsvg work (bizp2.dll missing)
Freddie Unpenstein wrote: > That sounds straight forward enough. And a hell of a lot better than the > current situation. I just checked the latest pidgin installer and indeed they do operate this way. However their GTK runtime just uses the major version number, so it installs to C:\Program Files\Common Files\GTK\2.0 for all versions of 2.x. At first glance this would seem to be okay as GTK is supposed to be ABI compatible across backwards from newer 2.x versions to older ones. In practice there can be issues though. In past years, Gaim and Gimp for windows actually had different versions of GTK that they needed, and with this common scheme there ended up being conflicts. IE Gaim would run but Gimp wouldn't. In linux we could solve this by having versions stored with their full version number, and symlinking the latest one to 2.0 for programs that don't need to know or care. But in Windows you can't symlink. So if you choose to go this route, be aware that your GTK runtime could cause Pidgin (or other programs using a common GTK runtime) problems and vice versa. Hence the conventional wisdom to just bundle the runtime with each app. And actually issues like theming and OS integration shouldn't be a problem as on Windows there ought to only be one theme for the app: the Windows look and feel. Users shouldn't know that the app is GTK-based; it should just appear to them to be a windows app. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Makeing librsvg work (bizp2.dll missing)
From: "Michael Torrie", Date: 31/07/2009 02:49, Wrote: > If you are hell-bent on a system-wide GTK, then you need to do it the > way that Gaim for win32 used to. They would install GTK to C:\Program > Files\Common Files\GTK\%version%. Then their own app would go to > C:\Program Files\Gaim. The magic is in the startup shortcut (or batch > file). All they have to do is start Gaim inside the GTK folder > (optionally add the application's bin folder to PATH). Hence this > scheme supports multiple versions of GTK also by just adjusting which > folder the app actually started in, if that makes sense. It seemed to > work pretty well. I'm not sure if they still do this though. That sounds straight forward enough. And a hell of a lot better than the current situation. At least that way, with some minimal smarts in the installer, the GTK libraries will get the occasional update. Are there any good reasons why that shouldn't be the default install? The only one I've seen so far, is so that changes in the appearance of one application don't propagate to other GTK-based applications. So make it easier to set application-level theme overrides. I've seen a couple programs that install 3rd party components as part of their own installation process. Several that even download those components at install time, before starting their own installation. How hard would it be to provide a "GTK sub-installer" that could; - check for a GTK package optionally included with the application - offer to check for and download a newer version where suitable - ask (if not already told) whether to install app- or system- wide - not downgrade an existing more recent GTK install - be able to run as a component of the application installer If the GTK installer were to register applications with the GTK libraries (a simple ini file in the GTK directory), the uninstaller could offer to remove the old GTK libraries if nothing else is using them. Further, a 3rd party (recommended, if not included with GTK for Windows) application could periodically check for minor updates to the installed GTK versions (possibly even the applications themselves as well), and take over removal of no longer used versions. It's a function that most Linux distributions do already, but until Windows Update starts supporting random 3rd party applications, having the framework the application is based on handle it in a consistent manner is probably the next best thing. Updating for security reasons is becoming a big issue these days, and having every application do it its own way, some of which work better than others, and worse still, all wanting to install their own programs to periodically check for updates, and so forth... I think a system-wide (or at least, user-wide) install with trivial support for application configuration overrides (for those who still want their application to live in a little world all its own, Windows-style), is just the right thing to do. Fredderic Health Insurance Click to find great rates on health insurance, save big, shop here. http://tagline.excite.com/fc/FgElN1gyzz6QmJXJSFbabDiwCNUguMWMSWb7x9Me8OxHH92oLkFIPKLjYfG/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Virtual drag drop using gtk api's
I need to make a native gtk application which has the functionality of virtual file drag and drop. What i mean here is that when we start dragging a file from the native application then that file actually doesn't exist there but is either generated or downloaded from some remote location and is finally available at the drop location. The virtual drag drop is possible in windows , visit the below given link [blogs dot msdn dot com/oldnewthing/archive/2008/03/19/8080215 dot aspx] The gtk api's for drag drop doesn't provide the functionality to know the drop destination location. -- Regards, Rajat Mahajan. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
