Passing an iter
Is it safe to pass an iter as a parameter to a function? Thanks, Dave ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
MS Windows packages and modularity
A while back some app developers who have need of GTK+ on MS Windows, yet whose apps use only a subset of the available image-loaders, requested that the build of the Windows packages be made modular (as it was in the old days). That way, one can slim down the packaging of one's app, skipping the redundant loaders along with their third-party dependencies (e.g. libtiff and libjpeg). This was done for a while (e.g. with the GTK 2.12.11 package), and I was grateful for that. But I see that the current GTK 2.14.4 package ( http://www.gtk.org/download-windows.html ) has reverted to a monolithic build, so that a gtk app won't start without having the tiff and jpeg libraries installed, even if they're never used. Was there a compelling reason for this reversion? Any chance of getting a modular build again? Thanks. -- Allin Cottrell Department of Economics Wake Forest University ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Glade (Re: What widgets in TES Construction Set?)
About Glade. I tried to create something simple (which I don't remember now) it didn't succeed. The menubar was simple, but this equally simple thing was too hard. I will check it again and post to glade lists someday. It would be nice if there would be complete examples which could be grabbed and dragged to the project. This equals to adding complete subgraph of widgets to the project. For other project, I need an audio waveform display with callbacks and with overdrawn controls (draggable selection edge) and displays (playhead time display moving with the pointer). It would be nice if I could grab an example of this kind of thing, and then modify it to my taste in Glade. Such an audio waveform display may require multiple pixmaps. If waveform is moved forward, only the new revealed waveform is drawn, and the rest are copied. One pixmap could contain the waveform and other the controls (which are widgets), the final rendering then composite of the two pixmaps. All the code making the framwork work could be part of the Glade (not the waveform drawing, not the audio reading). Then if I have an Open File dialog, I would want Glade to generate me a framework code for opening the audiofile at background thread, if necessary. If the waveform drawing LOD file is missing it needs to be generated and that may take time. At meanwhile user should be able to continue editing of other audio. Threads etc. are standard part of modern software so they should be easily available. If Glade searches for means to extends its cababilities, this would be the way. Juhana ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Glade (Re: What widgets in TES Construction Set?)
On Mon, Oct 20, 2008 at 1:50 PM, Juhana Sadeharju <[EMAIL PROTECTED]> wrote: > > About Glade. I tried to create something simple (which I don't > remember now) it didn't succeed. The menubar was simple, but > this equally simple thing was too hard. I will check it again > and post to glade lists someday. > > It would be nice if there would be complete examples which > could be grabbed and dragged to the project. This equals to > adding complete subgraph of widgets to the project. Yeah, weve discussed such a probable feature under the terms of "widget templates", we would have offered a whole bunch of composite widgets and dialogs based on the feature, and also allow users to save a "template" so they could access it in the palette... ofcourse nobody came around to do the work ;-) Man the possibilities would be endless if we had more than 1.5 people working on Glade ! :D > For other project, I need an audio waveform display with > callbacks and with overdrawn controls (draggable selection edge) > and displays (playhead time display moving with the pointer). > It would be nice if I could grab an example of this kind of > thing, and then modify it to my taste in Glade. > > Such an audio waveform display may require multiple pixmaps. > If waveform is moved forward, only the new revealed waveform > is drawn, and the rest are copied. One pixmap could contain the > waveform and other the controls (which are widgets), the final > rendering then composite of the two pixmaps. > All the code making the framwork work could be part of the Glade > (not the waveform drawing, not the audio reading). > > Then if I have an Open File dialog, I would want Glade to generate > me a framework code for opening the audiofile at background > thread, if necessary. If the waveform drawing LOD file is missing > it needs to be generated and that may take time. At meanwhile user > should be able to continue editing of other audio. > > Threads etc. are standard part of modern software so they should > be easily available. If Glade searches for means to extends its > cababilities, this would be the way. Hi, Currently using glade you could conceivably edit anything you want in glade - so long as you work with GObjects that have properties and signals (you can even invent properties that are loaded and saved in custom ways, like GtkListStore data for example). Now obviously I'm not going to write your toolkit of objects and your application for you, but I can offer you a dynamic way to edit save and load all your objects from an xml description, whether your objects are waveforms contained inside a track object which asks your waveforms to draw itself at specific locations, depending on the waveform properties or data, or whether your objects represent frames in an animation, or even singleton objects that may represent devices on the embedded system your writing your application for. Nothing is stopping you from writing a GThreadedObject that runs a thread when its in "active" state and the thread just fires a signal for the code to implement. As glade, we dont have the resources (and its not part of our task description) to go and write all the fancy toolkits that we could support, but I would love to see the envelope pushed, for instance, I dont see any reason why GStreamer pipelines coulnt be edited in glade and loaded by GtkBuilder. Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Using a key to generate mouse button press?
My software uses Alt modifier but the Alt key is now blocked by Gnome. A quick solution is to use key presses for generating mouse button presses. How to generate them? A method found from the mail archives is win = gdk_window_at_pointer(&wx, &wy); event.type = GDK_BUTTON_PRESS; event.button.send_event = True; event.button.window = win; event.button.x = wx; event.button.y = wy; event.button.state = 0; event.button.button = Button1; event.button.source = GDK_SOURCE_MOUSE; event.button.x_root = (double)newx; event.button.y_root = (double)newy; gdk_event_put(&event); Problem 1: I catch key presses at the top window because I could not get them working with a drawing area. How to get the pointer position with respect to the drawing area? How to know if the pointer is in the drawing area? There is no point in sending the event if pointer is somewhere else. Problem 2: Why I should fill the pointer position at all? I just want generate the mouse button press (with modifier Alt), and to get GTK/GDK in process of doing the rest, like checking the pointer position, the active window, and widget. Problem 3: While sending a mouse button press from the code is interesting, how my application could catch the Alt modifier? When my software is in use (focus, enter etc.) the Alt modifier flow should be guided to my software instead of Gnome. Juhana ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: MS Windows packages and modularity
On Mon, Oct 20, 2008 at 12:01 PM, Allin Cottrell <[EMAIL PROTECTED]> wrote: > A while back some app developers who have need of GTK+ on MS > Windows, yet whose apps use only a subset of the available > image-loaders, requested that the build of the Windows packages be > made modular (as it was in the old days). That way, one can slim > down the packaging of one's app, skipping the redundant loaders > along with their third-party dependencies (e.g. libtiff and > libjpeg). > > This was done for a while (e.g. with the GTK 2.12.11 package), and > I was grateful for that. > > But I see that the current GTK 2.14.4 package > ( http://www.gtk.org/download-windows.html ) has reverted to a > monolithic build, so that a gtk app won't start without having the > tiff and jpeg libraries installed, even if they're never used. > > Was there a compelling reason for this reversion? Any chance of > getting a modular build again? Thanks. The reason for this change is that the 2.14.x series uses a new GDI+ based loader instead of the previous loaders. If you run dependency walker on libgdk_pixbuf-2.0-0.dll, you'll see that it doesn't depend on the various external libraries. -D ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: MS Windows packages and modularity
On Mon, 20 Oct 2008, Daniel Atallah wrote: > On Mon, Oct 20, 2008 at 12:01 PM, Allin Cottrell <[EMAIL PROTECTED]> wrote: > > But I see that the current GTK 2.14.4 package > > ( http://www.gtk.org/download-windows.html ) has reverted to a > > monolithic build, so that a gtk app won't start without having the > > tiff and jpeg libraries installed, even if they're never used. > > The reason for this change is that the 2.14.x series uses a new GDI+ > based loader instead of the previous loaders. OK, thanks for the info. > If you run dependency walker on libgdk_pixbuf-2.0-0.dll, you'll see > that it doesn't depend on the various external libraries. Hmm, but I've tried it on Windows XP: when I use the GTK 2.14.4 package my GTK app won't start without jpeg62.dll. Allin Cottrell ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: MS Windows packages and modularity
On Mon, Oct 20, 2008 at 4:57 PM, Allin Cottrell <[EMAIL PROTECTED]> wrote: > On Mon, 20 Oct 2008, Daniel Atallah wrote: > >> On Mon, Oct 20, 2008 at 12:01 PM, Allin Cottrell <[EMAIL PROTECTED]> wrote: >> > But I see that the current GTK 2.14.4 package >> > ( http://www.gtk.org/download-windows.html ) has reverted to a >> > monolithic build, so that a gtk app won't start without having the >> > tiff and jpeg libraries installed, even if they're never used. >> >> The reason for this change is that the 2.14.x series uses a new GDI+ >> based loader instead of the previous loaders. > > OK, thanks for the info. > >> If you run dependency walker on libgdk_pixbuf-2.0-0.dll, you'll see >> that it doesn't depend on the various external libraries. > > Hmm, but I've tried it on Windows XP: when I use the GTK 2.14.4 > package my GTK app won't start without jpeg62.dll. Oh, weird. You're right. I guess I'm confused as to how the new situation works. I just ran the dependency walker and it is different than I thought it was; someone more clueful than me will have to clarify. -D ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: MS Windows packages and modularity
On Mon, Oct 20, 2008 at 4:57 PM, Allin Cottrell <[EMAIL PROTECTED]> wrote: > On Mon, 20 Oct 2008, Daniel Atallah wrote: > >> On Mon, Oct 20, 2008 at 12:01 PM, Allin Cottrell <[EMAIL PROTECTED]> wrote: >> > But I see that the current GTK 2.14.4 package >> > ( http://www.gtk.org/download-windows.html ) has reverted to a >> > monolithic build, so that a gtk app won't start without having the >> > tiff and jpeg libraries installed, even if they're never used. >> >> The reason for this change is that the 2.14.x series uses a new GDI+ >> based loader instead of the previous loaders. > > OK, thanks for the info. > >> If you run dependency walker on libgdk_pixbuf-2.0-0.dll, you'll see >> that it doesn't depend on the various external libraries. > > Hmm, but I've tried it on Windows XP: when I use the GTK 2.14.4 > package my GTK app won't start without jpeg62.dll. I had previously tried with the GTK+ 2.14.1 libgdk_pixbuf-2.0-0.dll and it only depended on libpng and not libjpeg, libtiff, etc. I wonder if this was a mistake in how the 2.14.4 binaries were built as I don't see anything in the ChangeLog related to this. -D ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: MS Windows packages and modularity
>> Was there a compelling reason for this reversion? Not really. As has already been said, if/when the GDI+ -based pixbuf loaders would be used, then it would hopefully be 100% clear that it makes sense to build them as built-in in the gdk-pixbuf DLL. But now when I was forced to revert to the libgpej and libtiff -based loaders, there are two more or less equivalent choices, both which have their disadvatages: either 1) build separate png, jpeg and tiff loaders, which means there are more files to distribute for people who want to minimize the number of files in the GTK+ runtime and still be able to load jpef or tiff files, or 2) build built-in loaders which means the png, jpeg and tiff DLLs are required even for a GTK+ runtime used in a situation where it doesn't use any png, jpeg and tiff files. Would the best solution be to build the png, jpeg and tiff libraries as static libraries, and link them statically into gdk-pixbuf? --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: MS Windows packages and modularity
On Mon, Oct 20, 2008 at 7:20 PM, Tor Lillqvist <[EMAIL PROTECTED]> wrote: >>> Was there a compelling reason for this reversion? > > Not really. As has already been said, if/when the GDI+ -based pixbuf > loaders would be used, then it would hopefully be 100% clear that it > makes sense to build them as built-in in the gdk-pixbuf DLL. But now > when I was forced to revert to the libgpej and libtiff -based loaders, > there are two more or less equivalent choices, both which have their > disadvatages: either 1) build separate png, jpeg and tiff loaders, > which means there are more files to distribute for people who want to > minimize the number of files in the GTK+ runtime and still be able to > load jpef or tiff files, or 2) build built-in loaders which means the > png, jpeg and tiff DLLs are required even for a GTK+ runtime used in a > situation where it doesn't use any png, jpeg and tiff files. > > Would the best solution be to build the png, jpeg and tiff libraries > as static libraries, and link them statically into gdk-pixbuf? I don't particularly like the built-in loaders, and statically linking the dependent library doesn't address my concern. There are occasionally security vulnerabilities in these libraries (most recently libpng and libtiff (which is still unpatched)) - I like being able to update the library versions without changing GTK+. It is particularly handy that I can disable the tiff loader via the gdk-pixbuf.loaders file until there is an updated libtiff. -D ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: MS Windows packages and modularity
On Tue, 21 Oct 2008, Tor Lillqvist wrote: > >> Was there a compelling reason for this reversion? > > Not really. As has already been said, if/when the GDI+ -based > pixbuf loaders would be used, then it would hopefully be 100% > clear that it makes sense to build them as built-in in the > gdk-pixbuf DLL. Yes, that seems to make sense. > But now when I was forced to revert to the libgpej and libtiff > -based loaders... Sorry (just out of ignorance): who or what forced you to revert to the libjpeg- and libtiff-based loaders? > there are two more or less equivalent choices, both which have > their disadvatages: either 1) build separate png, jpeg and tiff > loaders, which means there are more files to distribute for > people who want to minimize the number of files in the GTK+ > runtime and still be able to load jpef or tiff files, or 2) > build built-in loaders which means the png, jpeg and tiff DLLs > are required even for a GTK+ runtime used in a situation where > it doesn't use any png, jpeg and tiff files. I'm not speaking from any great base of expertise, but just IMO: 1) "...more files to distribute for people who want to minimize the number of files in the GTK+ runtime..." Why would anyone want to minimize the _number of files_ in a GTK runtime package, as opposed to the size in bytes of the package? 2) I suspect that most GTK apps (other than apps such as GIMP which traffic in images) have no use for JPEG or TIFF functionality. This is really quite specialized. > Would the best solution be to build the png, jpeg and tiff > libraries as static libraries, and link them statically into > gdk-pixbuf? This would avoid the need for the app developer to package third-party DLLs, yet it still seems a bit awkward: it includes in the byte-count of the GTK distro specialized functionality that, I suspect, few will need. (I'd place PNG functionality in a different category since in many ways it's treated as "native" in GTK.) -- Allin Cottrell Department of Economics Wake Forest University ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
