Redistribution of GTK DLLs
I have a Pike GTK app that works on Windows and Linux (and theoretically other platforms but I haven't tested it). The Windows version of Pike distributes GTK DLLs for 2.12.11, which has some flaws compared to 2.24.10 which I use elsewhere. So it would be convenient for my users if I could have a simple command inside my app that goes and fetches eighteen files (including Pango, Cairo, etc) and deploys them to the correct location. And therein is a licensing problem. GTK is licensed LGPL, but my app is under the freer MIT license. So the question is: Am I making a derivative/combined work by making an installer that fetches GTK DLLs? I don't want to have to mess with the licensing of my project (putting some of it under the (L)GPL) for the sake of a convenience feature, but on the flip side, there's no point listing lengthy instructions saying go download this, extract this, put this this this and this in here, then restart the program if I can say enter this one-word command. What's the rule on distributing DLLs with non-GPL software? The GPL FAQ has a lot, but not really what I'm after. Thanks! ChrisA ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Redistribution of GTK DLLs
Standard disclaimer: I am not a lawyer. If you're in doubt, I think the best way to do this is to distribute things separately. Just make an installer / updater for the GTK libs ( that would be handy, by the way ... oh and if you build some Windows themes, *please* distribute these too ). Then in your MIT licensed app, say You'll need GTK libs ... and an installer / updater exists at location blah. This would surely not break any licenses, as they're separate projects. Dan On Wed, Mar 5, 2014 at 7:16 AM, Chris Angelico ros...@gmail.com wrote: I have a Pike GTK app that works on Windows and Linux (and theoretically other platforms but I haven't tested it). The Windows version of Pike distributes GTK DLLs for 2.12.11, which has some flaws compared to 2.24.10 which I use elsewhere. So it would be convenient for my users if I could have a simple command inside my app that goes and fetches eighteen files (including Pango, Cairo, etc) and deploys them to the correct location. And therein is a licensing problem. GTK is licensed LGPL, but my app is under the freer MIT license. So the question is: Am I making a derivative/combined work by making an installer that fetches GTK DLLs? I don't want to have to mess with the licensing of my project (putting some of it under the (L)GPL) for the sake of a convenience feature, but on the flip side, there's no point listing lengthy instructions saying go download this, extract this, put this this this and this in here, then restart the program if I can say enter this one-word command. What's the rule on distributing DLLs with non-GPL software? The GPL FAQ has a lot, but not really what I'm after. Thanks! ChrisA ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Redistribution of GTK DLLs
On Wed, Mar 5, 2014 at 12:27 PM, Daniel Kasak d.j.kasak...@gmail.com wrote: If you're in doubt, I think the best way to do this is to distribute things separately. Just make an installer / updater for the GTK libs ( that would be handy, by the way ... oh and if you build some Windows themes, *please* distribute these too ). Then in your MIT licensed app, say You'll need GTK libs ... and an installer / updater exists at location blah. So, effectively, I make a separately-downloadable thing that I'd license more restrictively than the rest of my app. Hmm. Seems an odd way to do things. ChrisA ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GTK signals question.
Okay, I'm out of ideas... I'm writing an app, that among a lot of other stuff, has three mutually interacting spinbuttuns, i.e., if I increment spinbutton A, its callback then updates values in B and C. B and then would try to update A, and C, etc., resulting in a bottomless recursion. So, what I need to do is, while I'm in A's callback, block the B and C callbacks; while in in B, block A and C and so on. Every combination of g_signal_handler_block(), g_signal_handlers_block_matched(), etc, I've tried just results in seg faults--all that stuff works fine outside the callbacks, but the moment I stick them in a callback, death happens. Any suggestions? Thanks. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Redistribution of GTK DLLs
On Wed, 2014-03-05 at 17:13 +1100, Chris Angelico wrote: On Wed, Mar 5, 2014 at 12:27 PM, Daniel Kasak d.j.kasak...@gmail.com wrote: If you're in doubt, I think the best way to do this is to distribute things separately. Just make an installer / updater for the GTK libs ( that would be handy, by the way ... oh and if you build some Windows themes, *please* distribute these too ). Then in your MIT licensed app, say You'll need GTK libs ... and an installer / updater exists at location blah. So, effectively, I make a separately-downloadable thing that I'd license more restrictively than the rest of my app. Hmm. Seems an odd way to do things. Personally I wouldnt like to do it this way either, on win32 I would rather not trust DLL sharing - and rather just pack everything into the same bundle and run it, avoiding any possible binary incompatibilities which might otherwise creep in. I don't believe that your MIT licensing problem is any different than a proprietary license for your app, at least with regards to the usage of LGPL libraries. I.e. using LGPL libraries does not infect the calling code which links these libraries in with the GPL contagion - what is required is that if you do distribute these libraries in compiled form, you must also make available those LGPL sources which were used to build those said libraries. Since these particular LGPL sources are already made available by other parties (i.e. GTK+ friends by GNOME etc) - I believe that you do not need to host these files directly - but must somehow at least link to these sources when distributing your app, possibly in your application release notes, on your website if any, and ideally in some text which reaches those people you distribute software to (I.e. perhaps in a GtkAboutDialog somewhere it would be prudent to mention that the application is built with LGPL libraries which are available at some specific location). I am not a lawyer either, but this is my understanding of the issue. Cheers, -Tristan ChrisA ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK signals question.
On Wed, 2014-03-05 at 18:01 +1100, Chris Angelico wrote: On Wed, Mar 5, 2014 at 5:43 PM, Chris Moller mol...@mollerware.com wrote: I'm writing an app, that among a lot of other stuff, has three mutually interacting spinbuttuns, i.e., if I increment spinbutton A, its callback then updates values in B and C. B and then would try to update A, and C, etc., resulting in a bottomless recursion. So, what I need to do is, while I'm in A's callback, block the B and C callbacks; while in in B, block A and C and so on. Are you simply setting the three to the same value? If so, just check first to see if it's already that value, and if it is, don't set it. That's a technique that's worked for me since my earliest GUI programming days on VX-REXX... great system, that, pity it's bound to the obscure and forgotten platform of OS/2! :) In case this is of any help, the GtkAdjustment::value-changed signal does this check for this exact reason (to avoid some unneeded feedback when the value has not actually changed). Cheers, -Tristan ChrisA ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK signals question.
On Wed, Mar 5, 2014 at 6:20 PM, Chris Moller mol...@mollerware.com wrote: No, they're not the same value. They're all for setting an angle, in radians, pi-radians, and degrees, and I want the user to be able to set the angle in any unit and have the equivalent angle in the other units show up in the other spinbuttons. Ah, okay. Same consideration does apply, though - if you query first and then set, you avoid spurious signal delivery much more conveniently than fiddling with signal blocking. In the specific case cited, Tristan's solution is likely what you want, but for generalities, the query-before-set model is always there as a fall-back. ChrisA ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK signals question.
On Wed, 2014-03-05 at 02:20 -0500, Chris Moller wrote: On 03/05/14 02:01, Chris Angelico wrote: On Wed, Mar 5, 2014 at 5:43 PM, Chris Moller mol...@mollerware.com wrote: I'm writing an app, that among a lot of other stuff, has three mutually interacting spinbuttuns, i.e., if I increment spinbutton A, its callback then updates values in B and C. B and then would try to update A, and C, etc., resulting in a bottomless recursion. So, what I need to do is, while I'm in A's callback, block the B and C callbacks; while in in B, block A and C and so on. Are you simply setting the three to the same value? If so, just check first to see if it's already that value, and if it is, don't set it. That's a technique that's worked for me since my earliest GUI programming days on VX-REXX... great system, that, pity it's bound to the obscure and forgotten platform of OS/2! :) No, they're not the same value. They're all for setting an angle, in radians, pi-radians, and degrees, and I want the user to be able to set the angle in any unit and have the equivalent angle in the other units show up in the other spinbuttons. Interesting, if I were you I would try to share the same adjustment between all of your views. I.e. I would keep the adjustment in the finest grained unit of each unit you want to display, and have your spin buttons format the value differently depending on what they are used for (or perhaps use GtkScale if that makes sense in your UI). The idea of multiple GtkAdjustments holding separate values when you really only want a single value that is displayed differently by different widgets - is a bit maddening. Note that this might prove challenging with the way GtkAdjustment is designed, I was just speculating that this approach of multiple adjustments is not ideal... ideally these views should share the same value. Cheers, -Tristan ChrisA ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK signals question.
On Wed, Mar 5, 2014 at 6:29 PM, Tristan Van Berkom tris...@upstairslabs.com wrote: Interesting, if I were you I would try to share the same adjustment between all of your views. I.e. I would keep the adjustment in the finest grained unit of each unit you want to display, and have your spin buttons format the value differently depending on what they are used for (or perhaps use GtkScale if that makes sense in your UI). Now *that* is an elegant solution, if it can be done! ChrisA ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
