Re: scalable icons Windows
forgot to reply to all. Sorry. On Tue, Aug 11, 2009 at 2:47 AM, Tor Lillqvist wrote: >> Any ideas how to make this work? > > Install the svg pixbuf loader (and its dependencies), and edit the > gdk-pixbuf.loaders file (or use gdk-pixbuf-query-loaders). > > See http://ftp.gnome.org/pub/GNOME/binaries/win32/librsvg/2.26/ for > Windows binaries for the svg pixbuf loader. You will have to trawl > around on the site a bit for all dependencies (no package management > for this on Windows), but it shouldn't be rocket science. > > --tml > Thanks for the advice, but I believe that I already have all the dependencies needed. I did install the pixbuf loader and edit the gdk-pixbuf.loaders file. According to Dependency Walker, I have all the dependencies except for "IESHIMS.DLL" and "WER.DLL". I have no idea what those are. Matthew ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: scalable icons Windows
> Any ideas how to make this work? Install the svg pixbuf loader (and its dependencies), and edit the gdk-pixbuf.loaders file (or use gdk-pixbuf-query-loaders). See http://ftp.gnome.org/pub/GNOME/binaries/win32/librsvg/2.26/ for Windows binaries for the svg pixbuf loader. You will have to trawl around on the site a bit for all dependencies (no package management for this on Windows), but it shouldn't be rocket science. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
scalable icons Windows
I have set up the svg pixbuf loader according to the instructions here http://www.mail-archive.com/gtk-app-devel-list@gnome.org/msg11731.html, including editing the gdk-pixbuf.loaders file and gathering all dependencies. My application uses a named icon, "insert-link", and on linux (Ubuntu) this automatically loads the scalable icon, because the requested image size is larger than 48x48. On Windows, it refuses to load the scalable icon no matter what. If I change the image to load the file directly rather than using the name, it gives this error: "Gtk-WARNING **: Could not load image 'insert-link.svg': Couldn't recognize the file format for file 'c:/full/path/to/file/insert-link.svg'" Any ideas how to make this work? Thanks, Matthew ___ 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 quite get my head around this, can anyone help?
I think I might just have to go with your idea and store the entire array of current values before I check for user-changes. Like I said, this isn't a small chunk, but so what. It sucks, it's a kluge, but allowing the hscale to move forward the then forcing it back will (or should) work, and that's more promise than I've seen in the last three days working on this. So, although I still believe there's a better way to do this, I have to say thanks for getting me to look at this from a different perspective. Perhaps I'll figure out the correct way someday -- just not this day. > -Original Message- > From: gtk-app-devel-list-boun...@gnome.org > [mailto:gtk-app-devel-list-boun...@gnome.org] On Behalf Of > Michael Torrie > Sent: Monday, August 10, 2009 2:44 PM > To: Gtk app list > Subject: Re: Can't quite get my head around this, can anyone help? > ___ 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 quite get my head around this, can anyone help?
It's not the original data that I can't hold onto, it's the user-changed data I'm loosing. I have the original at my disposal freely. It's not in a database, but it's in a very, very, very gimungous shared memory segment with lookup functions, and just like in a database, these are arrays of structures within structures, giving me the same mechanism as a parent-child relationship. I can do the equivalent of a rollback here. In fact, if I do nothing, that's the default. The problem is, I have a flag that tells me the user changed something. I may not know what, but I know that they changed something. I'm just trying to tell them they're about to loose their changes because they forgot to save. If it were one or two values, no great loss. But among the hundreds of values, I think the user would cuss like a sailor. I know I would. Even if I knew I was to blame, I'd think twice before I came back to this software since I know there's a better (safer) implementation. If you've ever read "Why Software Sucks", I'm trying to reduce the suckage here. The worst part is, the documentation on the change-value signal of the range object sounds like just what I need when you set the return value to TRUE. Only it doesn't work. Being quite a noob, I'm sure I'm doing something wrong, but I can't seem to find a clue anywhere. > -Original Message- > From: David Nečas [mailto:y...@physics.muni.cz] > Sent: Monday, August 10, 2009 3:12 PM > To: Boggess Rod > Cc: Gtk app list > Subject: Re: Can't quite get my head around this, can anyone help? > > On Mon, Aug 10, 2009 at 02:52:56PM -0400, Boggess Rod wrote: > > BTDT. Won't work because by then, the user-value I'm trying not to > > loose would already be lost. > > It would not if you kept the original value elsewhere as suggested. > > > I would have thought this was a somewhat popular function, > especially > > when processing records from a database. But I don't seem to know > > what to search for. I can seem to find one single example anywhere > > that makes use of the change-value signal. > > Databases have commit/rollback mechanisms so you usually > don't need to implement your own in Gtk+. Even if they don't > they can always serve as the `elsehwere' that contains the > original value. > > The 'change-value' signal is not what you need. The signal > is something few people need that's why you cannot find examples... > > 1) You have the original value because you had it when the > dialog was created. You just need to keep it somewhere. The > simplest method is to work on a copy of the dialog model (in > MVC sense), leaving the original intact. > > 2) When the user moves the slider, it should really move (so, > no 'change-value'). Signal 'value-changed' is emitted and > you change the value in the dialog model working copy. > > 3) If the user accepts the changes replace the original model > with the values from the working copy. If he does not just > discard it. > > Yeti > > ___ 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 quite get my head around this, can anyone help?
The last one is easy to answer: there are lots of fields to work with, and many times, records are shown in a parent-child relationship. The lots of fields makes it easy for the user to forget if they've made a change. The parent-child relationship makes it meaningful to have a parent set of entry-boxes, and a child set of entry-boxes with a scroll widget to page through all the child records. The example is little more difficult. Technically speaking, it's not impossible to save the current value. As it stands, every entry box shares one common changed event handler which simply sets a flag to say the data on the form has changed. If there were only one or two, I could write a custom handler, and store the value there. At least, I think I could. Much of this isn't working the way I expected, so my confidence is waning. Anyway, the problem is that I have lots and lots of entry boxes. Worse, I don't really know how many I have until the application runs. Writing individual changed event handlers would be impossible. So, where would I store the value? When you click on the trough, the new value is already set, which causes the lookup of the new child-record, replacing all of the values in the entry-boxes, including any that the user may have changed. At this point, all you'd be doing is telling the luser what an idiot they were because they forgot to save their data that they forgot they changed. What I need is an event that triggers before the hscale value has changed. One that I could intercept, prompt the user, and choose to cancel or continue. I suppose I could save every value on the form before I lookup the data for the new child record. But that's not a small amount of data. And, as I said, I can't believe I'm the only one that has ever done this before. If there isn't a way to intercept and stop these signals, then there's a major piece missing from GTK. And I would have thought (perhaps mistakenly) that it was mature enough to have this type of functionality. Not that I'm opposed to contributing to the effort, but I won't have time to do it before I have to release this application. Which means I'll have to work around this. I see some examples of code where the programmer performs a g_signal_handlers_block_by_func call to disable callbacks, and I thought they were doing exactly this -- but even that doesn't seem to prevent the recursion of my callback. And perhaps worse, a set_value on the range from within the change-value handler, doesn't (set the value, that is). I'll see if I can't post an example that's stripped down to just one entrybox. But as I said above, in such a trivial case, it's nothing to save a single value in the entry-changed event handler. > -Original Message- > From: gtk-app-devel-list-boun...@gnome.org > [mailto:gtk-app-devel-list-boun...@gnome.org] On Behalf Of > Michael Torrie > Sent: Monday, August 10, 2009 3:14 PM > Cc: Gtk app list > Subject: Re: Can't quite get my head around this, can anyone help? > > Boggess Rod wrote: > > BTDT. Won't work because by then, the user-value I'm trying not to > > loose would already be lost. > > Guess I don't understand the problem, then, as I don't see > why this would be if you kept track of it in an external > variable between callbacks. Maybe a very small, > self-contained example would be appropriate. > > > I would have thought this was a somewhat popular function, > especially > > when processing records from a database. But I don't seem to know > > what to search for. I can seem to find one single example anywhere > > that makes use of the change-value signal. > > How would it be used in a database-driven app? Not having > written any, it's not something I'm familiar with. > ___ > 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
Re: Can't quite get my head around this, can anyone help?
Boggess Rod wrote: > BTDT. Won't work because by then, the user-value I'm trying not to > loose would already be lost. Guess I don't understand the problem, then, as I don't see why this would be if you kept track of it in an external variable between callbacks. Maybe a very small, self-contained example would be appropriate. > I would have thought this was a somewhat popular function, especially > when processing records from a database. But I don't seem to know what > to search for. I can seem to find one single example anywhere that > makes use of the change-value signal. How would it be used in a database-driven app? Not having written any, it's not something I'm familiar with. ___ 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 quite get my head around this, can anyone help?
On Mon, Aug 10, 2009 at 02:52:56PM -0400, Boggess Rod wrote: > BTDT. Won't work because by then, the user-value I'm trying not to > loose would already be lost. It would not if you kept the original value elsewhere as suggested. > I would have thought this was a somewhat popular function, especially > when processing records from a database. But I don't seem to know what > to search for. I can seem to find one single example anywhere that > makes use of the change-value signal. Databases have commit/rollback mechanisms so you usually don't need to implement your own in Gtk+. Even if they don't they can always serve as the `elsehwere' that contains the original value. The 'change-value' signal is not what you need. The signal is something few people need that's why you cannot find examples... 1) You have the original value because you had it when the dialog was created. You just need to keep it somewhere. The simplest method is to work on a copy of the dialog model (in MVC sense), leaving the original intact. 2) When the user moves the slider, it should really move (so, no 'change-value'). Signal 'value-changed' is emitted and you change the value in the dialog model working copy. 3) If the user accepts the changes replace the original model with the values from the working copy. If he does not just discard it. Yeti ___ 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 quite get my head around this, can anyone help?
BTDT. Won't work because by then, the user-value I'm trying not to loose would already be lost. I would have thought this was a somewhat popular function, especially when processing records from a database. But I don't seem to know what to search for. I can seem to find one single example anywhere that makes use of the change-value signal. > -Original Message- > From: gtk-app-devel-list-boun...@gnome.org > [mailto:gtk-app-devel-list-boun...@gnome.org] On Behalf Of > Michael Torrie > Sent: Monday, August 10, 2009 2:44 PM > To: Gtk app list > Subject: Re: Can't quite get my head around this, can anyone help? > > Boggess Rod wrote: > > I guess I wasn't clear. The messagebox is working fine. > It returns > > whether the user clicked Ok or Cancel. I'm calling the > > gtk_dialog_run(...) from within the callback of the > > on_hscale_valuechanged(...) (or _changevalue) event > handler. It's the > > hscale's event handler that I can't get to work. > > > > The valuechanged signal is only raised after the hscale > value has been > > changed. That's too late, because if the form contains unsaved > > changes, clicking message box's cancel button should prevent the > > hscale from changing on the parent form. > > Interesting. I have no idea what would work in this case. > > I wonder if you could just punt and set the scale value back > to the original value that it had before the valuechanged > signal was emitted. > Would be a bit of a hacks since you'd have to keep track of > the value in an external variable. But maybe a bit of visual > feedback (the scale moving and then going back) might be good > from a usability standpoint. > ___ > 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
Re: Can't quite get my head around this, can anyone help?
Boggess Rod wrote: > I guess I wasn't clear. The messagebox is working fine. It returns > whether the user clicked Ok or Cancel. I'm calling the > gtk_dialog_run(...) from within the callback of the > on_hscale_valuechanged(...) (or _changevalue) event handler. It's the > hscale's event handler that I can't get to work. > > The valuechanged signal is only raised after the hscale value has been > changed. That's too late, because if the form contains unsaved changes, > clicking message box's cancel button should prevent the hscale from > changing on the parent form. Interesting. I have no idea what would work in this case. I wonder if you could just punt and set the scale value back to the original value that it had before the valuechanged signal was emitted. Would be a bit of a hacks since you'd have to keep track of the value in an external variable. But maybe a bit of visual feedback (the scale moving and then going back) might be good from a usability standpoint. ___ 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 quite get my head around this, can anyone help?
Michael Torrie wrote: > Well inside a callback you can return TRUE which stops signal > propagation right here. Or FALSE, which lets it continue. So you could > do it two ways. One would be to to display a GtkDialog, and use > gtk_dialog_run() from within your callback [1]. The other would be to > create new gtk main loop instance from within your callback to allow > another window to be displayed and run, and then based have that > window's event callbacks set a flag and end the main loop, which you can > then use in the original callback to end the propagation. Forgot the references. [1] http://library.gnome.org/devel/gtk/stable/GtkDialog.html#gtk-dialog-run Also the glib main loop documentation is here: http://library.gnome.org/devel/glib/stable/glib-The-Main-Event-Loop.html specifically, g_main_loop_new() ___ 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 quite get my head around this, can anyone help?
Boggess Rod wrote: > Can someone point me to some example code in Gtk that intercepts a > signal, prompts the user, and either continues or aborts the signal, > depending on user response? A button wouldn't do this, but I'm sure > there are other widgets that would. I've Googled everything I can think > of, but I either receive an overwhelming, unapplicable list of results > or none. Well inside a callback you can return TRUE which stops signal propagation right here. Or FALSE, which lets it continue. So you could do it two ways. One would be to to display a GtkDialog, and use gtk_dialog_run() from within your callback [1]. The other would be to create new gtk main loop instance from within your callback to allow another window to be displayed and run, and then based have that window's event callbacks set a flag and end the main loop, which you can then use in the original callback to end the propagation. Not example code, but if I understand what you're asking for, it's relatively doable. Why wouldn't a button be be able to do this? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Can't quite get my head around this, can anyone help?
I've got a bunch of entry boxes and an HScale widget. If the user changes something on the form and clicks the HScale Widget before clicking the save button, I popup a message box. If the user clicks Ok, the HScale should ignore the changes and procede. If the user clicks Cancel, the HScale should stop. Ok, so I can't can't use the "value-changed" signal for the HScale. I belive I can use the "change-value", but I can't quite get it to work right. If I return TRUE when the user clicks Cancel, that works. But whether I return TRUE or FALSE on the OK button, it doesn't work. It either ignores the change or it calls itself repeatedly. Can someone point me to some example code in Gtk that intercepts a signal, prompts the user, and either continues or aborts the signal, depending on user response? A button wouldn't do this, but I'm sure there are other widgets that would. I've Googled everything I can think of, but I either receive an overwhelming, unapplicable list of results or none. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
