[prev in list] [next in list] [prev in thread] [next in thread]
List: gtk-devel
Subject: Re: help on disabling file-chooser
From: Ruben <rtmoran () gmail ! com>
Date: 2010-01-31 18:49:00
Message-ID: 27781a6c1001311049s73f0924aoce02e2abb77e19df () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Maybe I didn't explained myself,
Is not a license concern, just techical- Has nothing to do with that.
What I need is to customize GTK with file-chooser
disabled/removed/noreferenced on my compiled library, just
doing nothing when a save file signal is generated.
The app that runs above makes a call to save a file on the system, and
leaves this GTK window opened breaking the normal operation flow.
Cheers.
2010/1/31 Kevin Krieser <k_krieser@sbcglobal.net>
>
> On Jan 31, 2010, at 9:00 AM, Tor Lillqvist wrote:
>
> > Sounds like an exercise in futility.
> >
> > If you are doing this to prevent people from saving something because
> > of commercial/security/whatever interests, and if the users will have
> > a real interest in working around the limitations you try to impose,
> > they will. And there is nothing you can do to stop them.
> >
> > The very purpose of the license of GTK+ (LGPL) is to allow your users
> > to replace GTK+ with a modified version. For instance one where they
> > have re-instated the functionality you have removed.
> >
> > The same license that gives you the right to modify GTK+ gives the
> > end-users of your modified version the right to revert the
> > modification, and share such a reverted copy with others as they
> > please.
> >
>
> I don't know the original poster's requirements, but I've worked on
> projects where we have limited the access of the user of the application.
> In our case, even the non GPL code is provided to the customer, so they
> retain the rights to modify the code later, etc.
>
> In more embedded type systems, you generally want to limit the damage that
> the user can do, normally inadvertent. Would you really want a file chooser
> in, say, an ATM?
>
> Obviously the OP's is using non GPL code in the 3rd party libraries, or he
> could fix it there easier. If his customer decides to remove this
> limitation, it is out of his hands.
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
--
Ruben Tato
--
[Attachment #5 (text/html)]
Maybe I didn't explained myself, <br><br>Is not a license concern, just techical- \
Has nothing to do with that. <br><br>What I need is to customize GTK with \
file-chooser disabled/removed/noreferenced on my compiled library, just <br>
doing nothing when a save file signal is generated.<br><br> The app that runs above \
makes a call to save a file on the system, and<br> leaves this GTK window opened \
breaking the normal operation flow. <br><br> Cheers.<br><br><br><div \
class="gmail_quote">2010/1/31 Kevin Krieser <span dir="ltr"><<a \
href="mailto:k_krieser@sbcglobal.net">k_krieser@sbcglobal.net</a>></span><br><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5"><br>
On Jan 31, 2010, at 9:00 AM, Tor Lillqvist wrote:<br>
<br>
> Sounds like an exercise in futility.<br>
><br>
> If you are doing this to prevent people from saving something because<br>
> of commercial/security/whatever interests, and if the users will have<br>
> a real interest in working around the limitations you try to impose,<br>
> they will. And there is nothing you can do to stop them.<br>
><br>
> The very purpose of the license of GTK+ (LGPL) is to allow your users<br>
> to replace GTK+ with a modified version. For instance one where they<br>
> have re-instated the functionality you have removed.<br>
><br>
> The same license that gives you the right to modify GTK+ gives the<br>
> end-users of your modified version the right to revert the<br>
> modification, and share such a reverted copy with others as they<br>
> please.<br>
><br>
<br>
</div></div>I don't know the original poster's requirements, but I've \
worked on projects where we have limited the access of the user of the application. \
In our case, even the non GPL code is provided to the customer, so they retain the \
rights to modify the code later, etc.<br>
<br>
In more embedded type systems, you generally want to limit the damage that the user \
can do, normally inadvertent. Would you really want a file chooser in, say, an \
ATM?<br> <br>
Obviously the OP's is using non GPL code in the 3rd party libraries, or he could \
fix it there easier. If his customer decides to remove this limitation, it is out \
of his hands.<br> <div><div></div><div \
class="h5">_______________________________________________<br> gtk-devel-list mailing \
list<br> <a href="mailto:gtk-devel-list@gnome.org">gtk-devel-list@gnome.org</a><br>
<a href="http://mail.gnome.org/mailman/listinfo/gtk-devel-list" \
target="_blank">http://mail.gnome.org/mailman/listinfo/gtk-devel-list</a><br> \
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Ruben Tato<br>--<br>
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic