Re: Move to LGPL3

[Ryan Lortie]

On Mon, 2008-03-17 at 14:16 +0400, Alexander Shaduri wrote:
> Hi all,
> 
> Having studied the FSF licenses and their restrictions, I think
> it would be reasonable to re-license GTK+ under the LGPLv3
> (or later) + GPLv2 linking exception (or, alternatively, simply
> multi-license it under LGPLv3 / GPLv2).

This idea crossed my mind as well.  It has a couple of interesting ups
and downs.

1.  Any program that is GPL2-only-plus-exceptions would be
compatible, but the "plus exceptions" clause would effectively
be nullified by the straight-up-GPL2 GTK.  Depending on who you
talk to, this may or may not be the case with the LGPL (Havoc,
for example, believes LGPL also has this problem).  In any case,
I don't know if anyone is affected by this.

2.  You lose a lot of the benefit of the relicense.  It would
still leave us open to, for example, "tivoisation" (although,
they'd have to tivoise us under the GPL2 which means that they'd
have to provide source to anything they linked against -- an
interesting twist).

Probably this is the only idea that can really be practically used in
the short term without hurting some projects in our community.

As an interesting twist: this idea could be applied short-term and the
GPL2 option marked as "deprecated" as a lead-up to a future LGPLv3+-only
release (3.0, naturally)...

Cheers


signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Move to LGPL3

[Alberto Ruiz]

2008/3/19, Mark Mielke <[EMAIL PROTECTED]>:
>
> Jean Bréfort wrote:



I can't see this thread going anywhere close to a conclusion, at this point
we should stop discussing about the hundreds of possible interpretations of
the licenses. Probably none of the people that has participated  is a
lawyer,  we all try hard to understand the licenses and respect them, so I'm
not trying to say that any of us knows anything about licensing.

But for this kind of issues, I suggest to ask for help to the foundation for
legal advisory here, licenses are not that much about personal
interpretation, but effective transposition into each countries' laws and
stuff like that. I feel that the only way to make sure we don't mess this up
is having proper consultancy about what can be done, and what can't be done.

And just then, let's discuss what we wanna do among the real choices.
Everything else is kind of noise to me, and I think is not helping to clear
it up (even though some mails have come up with really good points).

My 2 cents anyway.
-- 
Cheers,
Alberto Ruiz
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Moving "Open with" to the platform

[Mikael Hermansson]

On Tue, 2008-03-18 at 14:02 -0600, Federico Mena Quintero wrote:

> * Leave the dialog in place inside Nautilus, and provide a D-Bus
> service
> for the "open with" GUI. I'm 51% leaning towards this option, since
> then this would have a chance of working with a desktop-specific GUI,
> depending on your choice of desktop environment --- aside from
> promoting
> the use of D-Bus for this kind of stuff.
> 

Not a good solution IMHO. Reason is that not all people is using
nautilus for filemanagement. 

Sounds more intresting to add it in Gtk.. Because then all apps using
gtk will work without nautilus installed.

Greets

Mikael Hermansson



___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Move to LGPL3

[Mark Mielke]

Jean Bréfort wrote:
> Windows API (and may be DirectX) is a special case, because you can't
> write a Windows program without using it.
>   

It's not a special case. There is certainly no reference to the Windows 
API in the GPL or the LGPL.

The only license that matters when it comes to deciding whether or not 
you can link to the Windows API, is the license that Microsoft grants 
you for the Windows API. The GPL cannot dictate how you may or may not 
make use of the Windows API. I do not see a clause anywhere that states 
"you may never derive from, or make us of, a non-GPL or non-LGPL 
library." It is always the product you are deriving from, or making use 
of, whose license defines what you are allowed to do or not allow to do.

The GPL "virus" is in the form of a copyright. It prevents people from 
copying, which includes distribution of the product and derivations of 
the product. Accessing a non-GPL library is not copying of GPL code. 
Using the published interface of another library is not copying of GPL 
code. If such were the case, it would be impossible to use GPL software 
on anything except for a full-stack GPL system, arguably including the 
hardware. It would be ridiculous and impractical for everybody, 
including the FSF.

The GPL cannot prevent you from linking a given product with another 
library. However, the GPL can force all products that are derived from a 
GPL product, to themselves be GPL products. Library use, that of linking 
at run time, is a grey zone in terms of whether a product is derived 
from the library, or merely makes use of it. Most interpretations I have 
read consider it a violation if a non-GPL product links to a GPL 
product, unless the use of the GPL library is one of at least two 
options, and effort is made to distance oneself from any conclusion that 
the product might require the use of a GPL library or that the product 
will function better with the GPL library. Messy.

Anyways - I hope this helps.

Cheers,
mark

-- 
Mark Mielke <[EMAIL PROTECTED]>

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Move to LGPL3

[Mark Mielke]

Tommi Komulainen wrote:
> IANAL and all, but here are a few points for consideration based on my
> experience after being exposed to Nokia legal machinery.
>
>  1. Changing the wording from "version 2 or later" to "version 3 or
> later" will remove the "2 or later" option. To my understanding
> changing the terms of the license text counts as relicensing.
>   

The license explicitly allows for this, though. The license allows for 
itself to be relicensed, providing the new license is blessed by the 
FSF. There would be no value to stating "version 2 or later" if it meant 
"version 2 only". Anybody - including you or I, may privately take a GPL 
v2 piece of software, change the license to GPL v3 (without even 
notifying the original authors), and distribute all further 
modifications under GPL v3 only. This clause made me uneasy when I first 
read it 10 to 20 years ago. The idea that if I distribute a program 
under GPL v2, the FSF could be taken over by somebody worse than Richard 
Stallman, create a new license stating anything it wishes (as long as it 
is called GPL v2 or later), and redistribute all my software under this 
new license. This is why the GPL is labeled a virus by some.

I am not up-to-date on LGPL v3. What I state above is for GPL v3 only.

>  2. Due to the (L)GPLv2 and v3 incompatibility everything above glib
> (or gtk+) would have to be distributed under v3, which as
> already noted is a problem if you have any v2 only sources in
> any glib application. It would be a significant disruption for
> distributors to make sure all the licenses are OK.
>   

It is only a problem if these v2 programs require updates. If the v2 
programs stick to v2 interfaces, there is no issue.

>  3. Companies are vary of GPLv3. It took a long time to begin to
> understand GPLv2, GPLv3 is still relatively more intimidating.
>   

The GPL has always been scary. The people who were ever comfortable with 
it, probably didn't read the fine print.

Cheers,
mark

-- 
Mark Mielke <[EMAIL PROTECTED]>

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Move to LGPL3

[Yevgen Muntyan]

Hubert Figuiere wrote:
> On Tue, 2008-03-18 at 16:03 -0700, Brian J. Tarricone wrote:
>   
>> "You may opt to apply the terms of the ordinary GNU General Public 
>> License instead of this License to a given copy of the Library. [...] 
>> (If a newer version than version 2 of the ordinary GNU General Public 
>> License has appeared, then you can specify that version instead if
>> you 
>> wish.)"
>>
>> Personally I think this clause is kinda ridiculous, but it's there, 
>> nonetheless. 
>> 
>
> It is there because implicitely LGPL code linked with GPL code becomes
> GPL as a whole[1], just because LGPL allow setting restriction that the
> GPL does not allow (hence the "Lesser-" part in the name).
>
> Similarly how the v2+ is compatible with v3+ via the upgrade part of the
> licence.
>   

But that clause is a part of LGPL-2, it doesn't say
that it applies only to the case when you have
"LGPL-2 or later". So you can take LGPL-2 (not
"or later") code and release it under GPL-3, while
you can't do that with GPL-2-not-or-later code.
Isn't it funny?

Yevgen

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Move to LGPL3

[Brian J. Tarricone]

Hubert Figuiere wrote:
> On Tue, 2008-03-18 at 16:03 -0700, Brian J. Tarricone wrote:
>> "You may opt to apply the terms of the ordinary GNU General Public 
>> License instead of this License to a given copy of the Library. [...] 
>> (If a newer version than version 2 of the ordinary GNU General Public 
>> License has appeared, then you can specify that version instead if
>> you 
>> wish.)"
>>
>> Personally I think this clause is kinda ridiculous, but it's there, 
>> nonetheless. 
> 
> It is there because implicitely LGPL code linked with GPL code becomes
> GPL as a whole[1], just because LGPL allow setting restriction that the
> GPL does not allow (hence the "Lesser-" part in the name).
> 
> Similarly how the v2+ is compatible with v3+ via the upgrade part of the
> licence.
> 
> Hub
> 
> [1] Where are talking about a whole software as it is being
> redistributed.

Getting a little OT, but... the issue I have is that, unless I'm reading 
it wrong, if I release something under LGPLv2.1-only (i.e., NO "or any 
later version" wording), then someone can still relicense my code under 
GPLv3, or even GPLv2-or-later. (But, strangely, one couldn't relicense 
as LGPLv3.)  I'm not terribly concerned about being able to relicense 
LGPL to GPL *of the same version*, but discarding my wishes to stay with 
the same (L)GPL version is not ok (to me, anyway).

-brian

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Move to LGPL3

[Hubert Figuiere]

On Tue, 2008-03-18 at 16:03 -0700, Brian J. Tarricone wrote:
> "You may opt to apply the terms of the ordinary GNU General Public 
> License instead of this License to a given copy of the Library. [...] 
> (If a newer version than version 2 of the ordinary GNU General Public 
> License has appeared, then you can specify that version instead if
> you 
> wish.)"
> 
> Personally I think this clause is kinda ridiculous, but it's there, 
> nonetheless. 

It is there because implicitely LGPL code linked with GPL code becomes
GPL as a whole[1], just because LGPL allow setting restriction that the
GPL does not allow (hence the "Lesser-" part in the name).

Similarly how the v2+ is compatible with v3+ via the upgrade part of the
licence.

Hub

[1] Where are talking about a whole software as it is being
redistributed.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Move to LGPL3

[Yevgen Muntyan]

Brian J. Tarricone wrote:
> Yevgen Muntyan wrote:
>   
>> Alexander Shaduri wrote:
>> 
>>> Hi all,
>>>
>>> Having studied the FSF licenses and their restrictions, I think
>>> it would be reasonable to re-license GTK+ under the LGPLv3
>>> (or later) + GPLv2 linking exception (or, alternatively, simply
>>> multi-license it under LGPLv3 / GPLv2).
>>>   
>>>   
>> But you can't do that. Gtk is *LGPL*-2, so you can't
>> make it GPL-2 (unless you convince all contributors,
>> including aliens and dead).
>> 
>
> Yes, you can.  Quoth the LGPLv2.1:
>   

Right. My bad, confused the order. I will not
talk about licenses without consulting  my
lawyer first ;)

Yevgen

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Move to LGPL3

[Ben Pfaff]

Yevgen Muntyan <[EMAIL PROTECTED]> writes:

> Gtk is *LGPL*-2, so you can't make it GPL-2 (unless you
> convince all contributors, including aliens and dead).

It appears that you have not read LGPLv2.  Clause 3 explicitly
says that "You may opt to apply the terms of the ordinary GNU
General Public License instead of this License to a given copy of
the Library."
-- 
Ben Pfaff 
http://benpfaff.org

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Move to LGPL3

[Brian J. Tarricone]

Yevgen Muntyan wrote:
> Alexander Shaduri wrote:
>> Hi all,
>>
>> Having studied the FSF licenses and their restrictions, I think
>> it would be reasonable to re-license GTK+ under the LGPLv3
>> (or later) + GPLv2 linking exception (or, alternatively, simply
>> multi-license it under LGPLv3 / GPLv2).
>>   
> 
> But you can't do that. Gtk is *LGPL*-2, so you can't
> make it GPL-2 (unless you convince all contributors,
> including aliens and dead).

Yes, you can.  Quoth the LGPLv2.1:

"You may opt to apply the terms of the ordinary GNU General Public 
License instead of this License to a given copy of the Library. [...] 
(If a newer version than version 2 of the ordinary GNU General Public 
License has appeared, then you can specify that version instead if you 
wish.)"

Personally I think this clause is kinda ridiculous, but it's there, 
nonetheless.  Any LGPLv#-covered program can be relicensed as a 
GPLv#-or-later program as well.  Interestingly, my reading of this shows 
that, even if you license under "LGPLv2.1-only", someone can relicense 
as GPLv2-or-later, or GPLv3-or-later, or even GPLv3-only.

-brian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Move to LGPL3

[Yevgen Muntyan]

Alexander Shaduri wrote:
> Hi all,
>
> Having studied the FSF licenses and their restrictions, I think
> it would be reasonable to re-license GTK+ under the LGPLv3
> (or later) + GPLv2 linking exception (or, alternatively, simply
> multi-license it under LGPLv3 / GPLv2).
>   

But you can't do that. Gtk is *LGPL*-2, so you can't
make it GPL-2 (unless you convince all contributors,
including aliens and dead). For a linking exception,
you'd need a lawyer to say if it's possible.

Yevgen

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: visibility-notify-event query

[Federico Mena Quintero]

On Sun, 2008-03-16 at 21:06 -0700, iluvlinux wrote:

>  i have a question regarding visibility-notify-event
> If i add widgets to a container than i get the signal
> visibility-notify-event, whenever visibility changes
> but if i add widgets to a scrolledwindow i donot get visibility-notify-event
> for the widgets that have
> scrolled up ie not visible nor i get unmap signal.

What widgets are you putting in there?  If they are no-window widgets,
they may not get the visibility-notify event, as the underlying window
(which belongs to the scrolled window) is still visible.

  Federico

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Move to LGPL3

[Brian J. Tarricone]

Alexander Shaduri wrote:
> Hi all,
> 
> Having studied the FSF licenses and their restrictions, I think
> it would be reasonable to re-license GTK+ under the LGPLv3
> (or later) + GPLv2 linking exception (or, alternatively, simply
> multi-license it under LGPLv3 / GPLv2).

Hmm, there's a nifty idea.  All GPLv2-compatible projects could still 
use gtk without any changes, and, as you say, all closed proprietary 
apps would be forced to follow the terms of the LGPLv3 for gtk.

Open question: are there any weird legal side-effects of dual-licensing? 
  I recall a big deal in the *BSD community not to long ago where some 
people didn't believe that dual-licensing was even legal (or something 
like that).

Aside from that, would there be any downsides to any existing open 
source apps that use gtk?

-brian

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Move to LGPL3

[Brian J. Tarricone]

Lieven van der Heide wrote:
> Ok, according to the matrix on
> 
> http://www.fsf.org/licensing/licenses/gpl-faq.html#AllCompatibility
> 
> it's indeed not allowed, although I don't really understand why.

Mathias pointed out exactly why.  It's not that linking GPLv2-only to 
LGPLv3 violates the LGPLv3 license of the library.  Linking a GPLv2-only 
app to a LGPLv3 library actually violates the app's its own license. 
The GPL in general doesn't allow linking to libraries with more 
restrictive licenses[1], and the LGPLv3 is more restrictive than GPLv2-only.

-brian

[1] The exception being for supposed "platform" libraries; e.g., you can 
link to Microsoft's C runtime even though it's closed source because 
it's a standard interface that can be considered part of the OS.  I 
believe Sven quoted the exact bit from the GPL in another post.


> 
> On 3/18/08, Lieven van der Heide <[EMAIL PROTECTED]> wrote:
>> Does that really apply for the code you link to? Afaik, if a GPL
>>  program uses an LGPL library, it doesn't relicense that library under
>>  GPL too, it merely links to it, and leaves it up to the user to make
>>  sure the library is available. If this would be the case, than it
>>  wouldn't be possible for GPL code to use something like the Windows
>>  API or DirectX either.
>>
>>  I think the restriction from the link you posted only apply to GPL
>>  libraries, but not LGPL.
>>
>>
>>  On 3/17/08, Mathias Hasselmann <[EMAIL PROTECTED]> wrote:
>>  >
>>  >  Am Montag, den 17.03.2008, 00:31 +0100 schrieb Mathias Hasselmann:
>>  >
>>  > > I am really wondering what's the reason for FSF claiming, that
>>  >  > programs
>>  >  > licenced GPL-2 only are not allowed to use LGPL-3 libraries. The LGPL-3
>>  >  > allows non-free, proprietary programs to use LGPL-3 libraries, but
>>  >  > excludes free software, licensed GPL-2 only? This sounds absurd to me!
>>  >  >
>>  >  > Is the FSF spreading FUD with their license matrix? Why doesn't the
>>  >  > matrix have footnotes explaining that absurd conflict?
>>  >
>>  >
>>  > Ok, it is not FUD. It seems the problem is, that LGPLv3 imposes
>>  >  additional restrictions not found in the GPLv2. So it isn't the LGPLv3
>>  >  that forbids LGPLv3 libraries to be used by GPLv2-only programs. It is
>>  >  the GPLv2 which forbids to linking against libraries more restrictive
>>  >  than itself.
>>  >
>>  >  See http://www.fsf.org/licensing/licenses/gpl-faq.html#v2v3Compatibility
>>  >  for details.
>>  >
>>  >  In theory LGPLv3 allows addition of exceptions, but they have to be
>>  >  approved by all copyright holders. Doubt this will happen. So only
>>  >  chance for upgrading to a new version of the LGPL is waiting for an FSF
>>  >  approved version of the LGPL, which drops those additional restrictions
>>  >  for GPLv2-only programs.
>>  >
>>  >  Total insanity...
>>  >
>>  >
>>  >  Ciao,
>>  >  Mathias
>>  >  --
>>  >  Mathias Hasselmann <[EMAIL PROTECTED]>
>>  >  Openismus GmbH: http://www.openismus.com/
>>  >  Personal Site: http://taschenorakel.de/
>>  >
>>
>>> ___
>>  >  gtk-devel-list mailing list
>>  >  gtk-devel-list@gnome.org
>>  >  http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>>  >
>>  >
>>  >
>>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
> 
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Moving "Open with" to the platform

[A. Walton]

On Tue, Mar 18, 2008 at 4:26 PM, Cosimo Cecchi <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2008-03-18 at 14:02 -0600, Federico Mena Quintero wrote:
>  > Hi,
>  >
>  > Right now, the "Open with another application" dialog lives in
>  > nautilus/libnautilus-private/nautilus-open-with-dialog.[ch].  This
>  > dialog uses the machinery in GIO's GAppInfo to figure out which apps can
>  > be used to open a file of a certain MIME-type.
>  >
>  > There's a long-standing annoyance in Firefox, where it implements "open
>  > with" by starting a file chooser in /usr/bin.  Now, if you complain
>  > about the file chooser *right here* I will ignore your mail :)  My point
>  > is that it would be nice if the "open with" GUI were available to all
>  > apps, not just Nautilus.
>  >
>  > We could do a few things:
>  >
>  > * Move nautilus-open-with-dialog.[ch] into GTK+.  From a super-quick
>  > read of the code, this uses no Nautilus-only stuff except for some of
>  > libeel's convenience error dialogs, and some "the MIME info changed"
>  > signal.
>  >
>  > * Leave the dialog in place inside Nautilus, and provide a D-Bus service
>  > for the "open with" GUI.  I'm 51% leaning towards this option, since
>  > then this would have a chance of working with a desktop-specific GUI,
>  > depending on your choice of desktop environment --- aside from promoting
>  > the use of D-Bus for this kind of stuff.
>  >
>  > Thoughts?
>  >
>  > Oh my god, this is a nice little project for the Summer of Code... it
>  > would involve figuring out the above, and also changing Firefox to use
>  > it :)
>
>  Hi Federico,
>  I started working some time ago on a similar request for Epiphany [1],
>  and I think this may be useful to other applications too.
>  On the other hand, there are requests [2] for a Nautilus D-Bus API not
>  just for this task, and it would be a good idea to implement it (maybe
>  even as a standardized spec for file managers?).
>  I also lean towards the D-Bus API, as that would potentially bring much
>  more integration across the desktop, but I have to say that having this
>  in GTK+ could allow creating nicer UIs for this kind of things.
>
>  [1] http://bugzilla.gnome.org/show_bug.cgi?id=163827
>  [2]
>  http://mail.gnome.org/archives/nautilus-list/2008-March/msg00047.html

I'm somewhat in agreement with Cosimo here. I think it'd be good for
us to think about developing D-Bus/Nautilus interaction this cycle,
but I'm not sure this is particularly the best use case for it; this
really should be in the toolkit IMO, as it's something that needs to
be a bit different on every platform but is nicely hidden through the
GAppInfo abstraction so it's not a particularly ugly bit to add. And
it's something that applications that run on multiple platforms
definitely need to be able to do (it's in the use case of Firefox,
Epiphany as already stated, cross-platform mail apps, etc). I think
that GTK+ needs to have something like this, even if it's a cleaned up
copy-n-paste job from Nautilus. If it doesn't end up being in Gtk+,
someone who's a lazy developer (like me ;) will eventually make an Egg
widget out of the one in Nautilus, and we'll spend the next few years
trying to kill its propagation throughout the platform after Gtk+'s
got an upgraded version of it, and all of the APIs have changed, etc.

For us Nautilus folk, we should probably start another thread to talk
about replacing the Bonobo Nautilus stuff with D-Bus infrastructure.
The only reason it's worth mentioning in this message is to see what
other application developers would like to see Nautilus expose. I did
some prototype work on this in a git branch when we first discussed
this in IRC a few months ago but at the time I didn't get very far.
Through working on GVFS I've picked up a of understanding here. I'd
love to pick this up as a 2.24 goal. I also think it would be
interesting to hear what applications would like the interface to be
like so we can get a better idea here of what to do. (Perhaps we
should even broaden it further as Cosimo suggests and mail FD.O and
ask everyone what it should look like across desktops?)

Just a few thoughts.

-A. Walton

>  Cheers,
>
>  Cosimo
>
>
>
>  ___
>  gtk-devel-list mailing list
>  gtk-devel-list@gnome.org
>  http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Moving "Open with" to the platform

[Bastien Nocera]

On Tue, 2008-03-18 at 17:09 -0300, Claudio Saavedra wrote:

> What about the "open with..." menu items machinery? This is
> reimplemented in more than one place (being eog and gthumb the examples
> I recall at the moment).

Totem has one to open videos embedded in web pages with the movie player
associated to it in the desktop. We only do the default player currently
though.

Even then, if would allow me to completely remove the application
launching code, which is pretty gross if you want to do startup
notification.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Moving "Open with" to the platform

[Cosimo Cecchi]

On Tue, 2008-03-18 at 14:02 -0600, Federico Mena Quintero wrote:
> Hi,
> 
> Right now, the "Open with another application" dialog lives in
> nautilus/libnautilus-private/nautilus-open-with-dialog.[ch].  This
> dialog uses the machinery in GIO's GAppInfo to figure out which apps can
> be used to open a file of a certain MIME-type.
> 
> There's a long-standing annoyance in Firefox, where it implements "open
> with" by starting a file chooser in /usr/bin.  Now, if you complain
> about the file chooser *right here* I will ignore your mail :)  My point
> is that it would be nice if the "open with" GUI were available to all
> apps, not just Nautilus.
> 
> We could do a few things:
> 
> * Move nautilus-open-with-dialog.[ch] into GTK+.  From a super-quick
> read of the code, this uses no Nautilus-only stuff except for some of
> libeel's convenience error dialogs, and some "the MIME info changed"
> signal.
> 
> * Leave the dialog in place inside Nautilus, and provide a D-Bus service
> for the "open with" GUI.  I'm 51% leaning towards this option, since
> then this would have a chance of working with a desktop-specific GUI,
> depending on your choice of desktop environment --- aside from promoting
> the use of D-Bus for this kind of stuff.
> 
> Thoughts?
> 
> Oh my god, this is a nice little project for the Summer of Code... it
> would involve figuring out the above, and also changing Firefox to use
> it :)

Hi Federico,
I started working some time ago on a similar request for Epiphany [1],
and I think this may be useful to other applications too.
On the other hand, there are requests [2] for a Nautilus D-Bus API not
just for this task, and it would be a good idea to implement it (maybe
even as a standardized spec for file managers?).
I also lean towards the D-Bus API, as that would potentially bring much
more integration across the desktop, but I have to say that having this
in GTK+ could allow creating nicer UIs for this kind of things.

[1] http://bugzilla.gnome.org/show_bug.cgi?id=163827
[2]
http://mail.gnome.org/archives/nautilus-list/2008-March/msg00047.html

Cheers,

Cosimo

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Moving "Open with" to the platform

[Claudio Saavedra]

El mar, 18-03-2008 a las 14:02 -0600, Federico Mena Quintero escribió:
> Hi,
> 
> Right now, the "Open with another application" dialog lives in
> nautilus/libnautilus-private/nautilus-open-with-dialog.[ch].  This
> dialog uses the machinery in GIO's GAppInfo to figure out which apps can
> be used to open a file of a certain MIME-type.
> 
> There's a long-standing annoyance in Firefox, where it implements "open
> with" by starting a file chooser in /usr/bin.  Now, if you complain
> about the file chooser *right here* I will ignore your mail :)  My point
> is that it would be nice if the "open with" GUI were available to all
> apps, not just Nautilus.
> 
> We could do a few things:
> 
> * Move nautilus-open-with-dialog.[ch] into GTK+.  From a super-quick
> read of the code, this uses no Nautilus-only stuff except for some of
> libeel's convenience error dialogs, and some "the MIME info changed"
> signal.
> 
> * Leave the dialog in place inside Nautilus, and provide a D-Bus service
> for the "open with" GUI.  I'm 51% leaning towards this option, since
> then this would have a chance of working with a desktop-specific GUI,
> depending on your choice of desktop environment --- aside from promoting
> the use of D-Bus for this kind of stuff.
> 
> Thoughts?

What about the "open with..." menu items machinery? This is
reimplemented in more than one place (being eog and gthumb the examples
I recall at the moment).

Claudio

-- 
Claudio Saavedra <[EMAIL PROTECTED]>

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Moving "Open with" to the platform

[Federico Mena Quintero]

Hi,

Right now, the "Open with another application" dialog lives in
nautilus/libnautilus-private/nautilus-open-with-dialog.[ch].  This
dialog uses the machinery in GIO's GAppInfo to figure out which apps can
be used to open a file of a certain MIME-type.

There's a long-standing annoyance in Firefox, where it implements "open
with" by starting a file chooser in /usr/bin.  Now, if you complain
about the file chooser *right here* I will ignore your mail :)  My point
is that it would be nice if the "open with" GUI were available to all
apps, not just Nautilus.

We could do a few things:

* Move nautilus-open-with-dialog.[ch] into GTK+.  From a super-quick
read of the code, this uses no Nautilus-only stuff except for some of
libeel's convenience error dialogs, and some "the MIME info changed"
signal.

* Leave the dialog in place inside Nautilus, and provide a D-Bus service
for the "open with" GUI.  I'm 51% leaning towards this option, since
then this would have a chance of working with a desktop-specific GUI,
depending on your choice of desktop environment --- aside from promoting
the use of D-Bus for this kind of stuff.

Thoughts?

Oh my god, this is a nice little project for the Summer of Code... it
would involve figuring out the above, and also changing Firefox to use
it :)

  Federico

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: exporting _gtk_selection_request for selection manager use

[Sven Neumann]

Hi,

On Tue, 2008-03-18 at 17:50 +0100, Alexander Larsson wrote:

> Load large spreadsheet, click "select all", watch your eager clipboard
> manager suck down lots and lots of data, probably in duplicates
> converted to all possible data types the spreadsheet can convert to. And
> this may happen even for in-process cut&paste, greatly slowing it down
> and causing it to serialize all data.

This is exactly what happens (or at least used to happen) when people
run klipper or glipper and use GIMP. You are working on a large image
and want to duplicate a layer, Ctrl-C, Ctrl-V. Within GIMP this is a
copy-on-write operation and happens almost immidiately, even for large
layers. If you have one of those misbehaving clipboard managers running,
it will ask GIMP for this data in various formats and GIMP will be busy
for several minutes dealing with this request.

This is absolutely pointless as GIMP is a nice application and pushes
the contents of the clipboard to the clipboard manager when it exits.
All we really need is an implementation of the clipboard manager spec.
And as far as I know gnome-settings-daemon does this.


Sven


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: exporting _gtk_selection_request for selection manager use

[Alexander Larsson]

On Sat, 2008-03-15 at 13:46 -0500, Xavier Toth wrote:
> Thanks I'll look at the gnome-settings-daemon. A little background,
> the problem I'm looking to address is the one related to MCS/MLS
> policy in the SELinux world where you are copying and pasting between
> windows of different contexts and or levels. In particular my concern
> is MLS where you need a 'middle man' to be able to downgrade
> information in a secure way when copying from a higher level
> window/app and pasting to a lower level window/app. Could you please
> expand upon what types of problems 'eager' clipboard managers cause?

Load large spreadsheet, click "select all", watch your eager clipboard
manager suck down lots and lots of data, probably in duplicates
converted to all possible data types the spreadsheet can convert to. And
this may happen even for in-process cut&paste, greatly slowing it down
and causing it to serialize all data.

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Move to LGPL3

[Sven Herzberg]

Quoting GPL 2:

»However, as a special exception, the source code distributed need not
include anything that is normally distributed (in either source or
binary form) with the major components (compiler, kernel, and so on) of
the operating system on which the executable runs, unless that component
itself accompanies the executable.«

Regards,
  Sven

Am Dienstag, den 18.03.2008, 12:35 +0100 schrieb Lieven van der Heide:
> Does that really apply for the code you link to? Afaik, if a GPL
> program uses an LGPL library, it doesn't relicense that library under
> GPL too, it merely links to it, and leaves it up to the user to make
> sure the library is available. If this would be the case, than it
> wouldn't be possible for GPL code to use something like the Windows
> API or DirectX either.
> 
> I think the restriction from the link you posted only apply to GPL
> libraries, but not LGPL.
> 
> On 3/17/08, Mathias Hasselmann <[EMAIL PROTECTED]> wrote:
> >
> >  Am Montag, den 17.03.2008, 00:31 +0100 schrieb Mathias Hasselmann:
> >
> > > I am really wondering what's the reason for FSF claiming, that
> >  > programs
> >  > licenced GPL-2 only are not allowed to use LGPL-3 libraries. The LGPL-3
> >  > allows non-free, proprietary programs to use LGPL-3 libraries, but
> >  > excludes free software, licensed GPL-2 only? This sounds absurd to me!
> >  >
> >  > Is the FSF spreading FUD with their license matrix? Why doesn't the
> >  > matrix have footnotes explaining that absurd conflict?
> >
> >
> > Ok, it is not FUD. It seems the problem is, that LGPLv3 imposes
> >  additional restrictions not found in the GPLv2. So it isn't the LGPLv3
> >  that forbids LGPLv3 libraries to be used by GPLv2-only programs. It is
> >  the GPLv2 which forbids to linking against libraries more restrictive
> >  than itself.
> >
> >  See http://www.fsf.org/licensing/licenses/gpl-faq.html#v2v3Compatibility
> >  for details.
> >
> >  In theory LGPLv3 allows addition of exceptions, but they have to be
> >  approved by all copyright holders. Doubt this will happen. So only
> >  chance for upgrading to a new version of the LGPL is waiting for an FSF
> >  approved version of the LGPL, which drops those additional restrictions
> >  for GPLv2-only programs.
> >
> >  Total insanity...
> >
> >
> >  Ciao,
> >  Mathias
> >  --
> >  Mathias Hasselmann <[EMAIL PROTECTED]>
> >  Openismus GmbH: http://www.openismus.com/
> >  Personal Site: http://taschenorakel.de/
> >
> > ___
> >  gtk-devel-list mailing list
> >  gtk-devel-list@gnome.org
> >  http://mail.gnome.org/mailman/listinfo/gtk-devel-list
> >
> >
> >
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: reg - USB and Ethernet performance open source utility

[Mikael Hallendal]

17 mar 2008 kl. 16.13 skrev Sarahana:

Hi,

This is the development mailing list for the GTK+ project, please stay  
on topic.

Best Regards,
   Mikael Hallendal

> Dear Sir
> I am Sarahana, working in an embedded product concern based on  
> linux, i wish to have an utility to check the performance of both  
> USB and Ethernet, thing is that i have to cross compile the code for  
> my device, if you have any such open source utility, if not can you  
> please suggest me to go through, i would be thankful to you.
>
> warm regards,
> Sarahana T
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list

-- 
Imendio AB, http://www.imendio.com




___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Move to LGPL3

[Tor Lillqvist]

>  If this would be the case, than it
>  wouldn't be possible for GPL code to use something like the Windows
>  API or DirectX either.

And don't forget proprietary Unixes with proprietary C libraries. That
was after all the expected runtime for the original GPL programs (like
Emacs, gcc, bison, etc) that existed long before there was any LGPL C
library on a GPL kernel to run them.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

reg - USB and Ethernet performance open source utility

[Sarahana]

Dear Sir
I am Sarahana, working in an embedded product concern based on linux, i wish
to have an utility to check the performance of both USB and Ethernet, thing
is that i have to cross compile the code for my device, if you have any such
open source utility, if not can you please suggest me to go through, i would
be thankful to you.

warm regards,
Sarahana T
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Move to LGPL3

[Alexander Shaduri]

Hi all,

Having studied the FSF licenses and their restrictions, I think
it would be reasonable to re-license GTK+ under the LGPLv3
(or later) + GPLv2 linking exception (or, alternatively, simply
multi-license it under LGPLv3 / GPLv2).

This method allows people to link GTK+ with any of the following:
- LGPLv2.1-only (since it's compatible with "GPLv2 or later");
- LGPLv3 or later;
- GPLv2 (because of the linking exception);
- GPLv3 (because LGPLv3 is explicitly compatible with GPLv3).

Notes:
Re-licensing GTK+ won't pose any problems - the current
license allows it to be redistributed as LGPLv3/GPLv2 as a whole,
so no problem there.

The main reason to move to LGPLv3 is usually the patent protection.
By using the GPLv2 (as opposed to LGPLv2.1) exception, GTK+
will limit the damage by forcing the proprietary folk to use LGPLv3
(since most of them can't use GPLv2), so the patent protection is
still in effect.

I always wonder how the programmer has to be a lawyer too these days. :)

Thanks,
Alexander

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: glib utf8 api

[Gregory Sharp]

> > 2) There seems to be no way to create a "best guess" valid
> > string.  g_utf8_validate is nice and all, but if validation 
> > fails I still need to create a valid string.  Am I supposed 
> > to use g_convert_with_fallback() from UTF-8 to UTF-8?
> 
> Very good point.  I raised this here too:
> 
> http://bugzilla.gnome.org/show_bug.cgi?id=391261#c9
> 
> In Pango these days I loop over the string, calling
> g_utf8_validate()
> and replacing any invalid bytes with -1.  The -1 byte is known
> to be
> safe when passed to various glib UTF-8 functions.

As I dig deeper, it seems I also need this 
for non-utf8 strings.  For example, my input string is 
nominally SJIS, but contains a corrupt character in 
the middle.  g_convert stops at the corruption 
point.  I would like instead to recover the string 
(using substitution or deletion of corrupt characters) 
as I convert to utf8.

Maybe this is too much to ask, but I ask anyway.  :)

Thanks,
Greg


Greg Sharp
[EMAIL PROTECTED]


  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Gtk+ stock-icons how r they supposed 2b installed?

[Yotam Medini יותם מדיני]

Hello Gtk+ developpers.

The gtk+2.12 (or similar versions) source tree, 
contains the sub directories gtk/stock-icons{16,20,24,32,48}
with rich set of icons.
When building and installing it (using say, prefix=/home/local)
these icons (at least in my case) are _not_ installed.

My questions:

+ What is the 'right' way to install them with non-root privileges
  (using the --prefix) 

+ When running ${prefix}/bin/gtk-demo and activating the 
  'Stock Item and Icon Browser' demo, 
  most of the
GTK_STOCK_foo -:- gtk-foo 
  have the icon displayed, but a few are missing, such as:
'gtk-apply', 'gtk-ok', 'gtk-cancel'
  Any reason?
  Where exactly they are being searched for?


Just to clarify, my question are related to Gtk+ _without_ Gnome.

regards -- yotam
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Minutes: Foreign OSes BoF

[Dominic Lachowicz]

Hi Tor,

On Mon, Mar 17, 2008 at 10:26 PM, Tor Lillqvist <[EMAIL PROTECTED]> wrote:
> Tentative patch at http://tml.pp.fi/gdip-in-gtk.diff . Comments, please.

A few things in io-gdip-utils.h need attention:

1) I redefined _() if it wasn't already defined. Instead, you probably
want to remove that code and add an #include 
2) I'd remove the "_ico" suffix from the MODULE_ENTRY macro definition.

Thanks!
Dom
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Minutes: Foreign OSes BoF

[Tor Lillqvist]

>  Will cairo move away from libpng too?

If somebody just writes the code, I think it would be accepted to have
a configure-time choice to either use GDI+ or libpng on Windows. Dunno
what the Mozilla folks think.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Minutes: Foreign OSes BoF

[Dominic Lachowicz]

>  >  * There is no way that I know of to distinguish between a
>  >  metafile/vector format and a raster format, except maybe to try
>  >  loading everything as a metafile and see if something fails.
>
>  Hmm, there are the ImageCodecFlagsSupportBitmap and
>  ImageCodecFlagsSupportVector bits in the ImageCodecInfo::Flags field,
>  is that enough?

I've seen stories that GDI+ reports that every format is a bitmap. I
didn't have the opportunity to test it myself because
GetImageEncoders() isn't in my GDI+ DLL.

>  >  * The functions that enumerate GDI+'s loaders simply don't exist in
>  >  the 1.0 version of the GDI+ DLL.
>
>  Are you sure? The sample program from the GDI+ documentation in the
>  Platform SDK that lists encoders using GetImageDecodersSize() and
>  GetImageDecoders() works fine for me on XP. The version of the
>  GdiPlus.dlls I find in the WinSxS folders is 5.1.3102.2180.

Unfortunately, they're not present in at least my copy of WinXP. It's
why I do a TRY_LOOKUP() on GetImageEncoders and GetImageEncodersSize,
and why GetEncoderClsid() has a fallback branch that uses hard-coded
CLSIDs.

>  I really would love to be able to have the GDI+ loader as a built-in...

As would I. You can definitely do it with the existing architecture,
albeit a little awkwardly. The combination wouldn't have support for
any new formats dynamically added to GDI+. But in all honesty, I think
adding new formats is pretty uncommon and that 99% of people just have
the builtin set.

Thanks for working on this patch, Tor. I really appreciate it.

Dom
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Move to LGPL3

[Jean Bréfort]

Windows API (and may be DirectX) is a special case, because you can't
write a Windows program without using it.

Le mardi 18 mars 2008 à 12:57 +0100, Lieven van der Heide a écrit :
> Ok, according to the matrix on
> 
> http://www.fsf.org/licensing/licenses/gpl-faq.html#AllCompatibility
> 
> it's indeed not allowed, although I don't really understand why.
> 
> On 3/18/08, Lieven van der Heide <[EMAIL PROTECTED]> wrote:
> > Does that really apply for the code you link to? Afaik, if a GPL
> >  program uses an LGPL library, it doesn't relicense that library under
> >  GPL too, it merely links to it, and leaves it up to the user to make
> >  sure the library is available. If this would be the case, than it
> >  wouldn't be possible for GPL code to use something like the Windows
> >  API or DirectX either.
> >
> >  I think the restriction from the link you posted only apply to GPL
> >  libraries, but not LGPL.
> >
> >
> >  On 3/17/08, Mathias Hasselmann <[EMAIL PROTECTED]> wrote:
> >  >
> >  >  Am Montag, den 17.03.2008, 00:31 +0100 schrieb Mathias Hasselmann:
> >  >
> >  > > I am really wondering what's the reason for FSF claiming, that
> >  >  > programs
> >  >  > licenced GPL-2 only are not allowed to use LGPL-3 libraries. The 
> > LGPL-3
> >  >  > allows non-free, proprietary programs to use LGPL-3 libraries, but
> >  >  > excludes free software, licensed GPL-2 only? This sounds absurd to me!
> >  >  >
> >  >  > Is the FSF spreading FUD with their license matrix? Why doesn't the
> >  >  > matrix have footnotes explaining that absurd conflict?
> >  >
> >  >
> >  > Ok, it is not FUD. It seems the problem is, that LGPLv3 imposes
> >  >  additional restrictions not found in the GPLv2. So it isn't the LGPLv3
> >  >  that forbids LGPLv3 libraries to be used by GPLv2-only programs. It is
> >  >  the GPLv2 which forbids to linking against libraries more restrictive
> >  >  than itself.
> >  >
> >  >  See http://www.fsf.org/licensing/licenses/gpl-faq.html#v2v3Compatibility
> >  >  for details.
> >  >
> >  >  In theory LGPLv3 allows addition of exceptions, but they have to be
> >  >  approved by all copyright holders. Doubt this will happen. So only
> >  >  chance for upgrading to a new version of the LGPL is waiting for an FSF
> >  >  approved version of the LGPL, which drops those additional restrictions
> >  >  for GPLv2-only programs.
> >  >
> >  >  Total insanity...
> >  >
> >  >
> >  >  Ciao,
> >  >  Mathias
> >  >  --
> >  >  Mathias Hasselmann <[EMAIL PROTECTED]>
> >  >  Openismus GmbH: http://www.openismus.com/
> >  >  Personal Site: http://taschenorakel.de/
> >  >
> >
> > > ___
> >  >  gtk-devel-list mailing list
> >  >  gtk-devel-list@gnome.org
> >  >  http://mail.gnome.org/mailman/listinfo/gtk-devel-list
> >  >
> >  >
> >  >
> >
> 

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Move to LGPL3

[Lieven van der Heide]

Ok, according to the matrix on

http://www.fsf.org/licensing/licenses/gpl-faq.html#AllCompatibility

it's indeed not allowed, although I don't really understand why.

On 3/18/08, Lieven van der Heide <[EMAIL PROTECTED]> wrote:
> Does that really apply for the code you link to? Afaik, if a GPL
>  program uses an LGPL library, it doesn't relicense that library under
>  GPL too, it merely links to it, and leaves it up to the user to make
>  sure the library is available. If this would be the case, than it
>  wouldn't be possible for GPL code to use something like the Windows
>  API or DirectX either.
>
>  I think the restriction from the link you posted only apply to GPL
>  libraries, but not LGPL.
>
>
>  On 3/17/08, Mathias Hasselmann <[EMAIL PROTECTED]> wrote:
>  >
>  >  Am Montag, den 17.03.2008, 00:31 +0100 schrieb Mathias Hasselmann:
>  >
>  > > I am really wondering what's the reason for FSF claiming, that
>  >  > programs
>  >  > licenced GPL-2 only are not allowed to use LGPL-3 libraries. The LGPL-3
>  >  > allows non-free, proprietary programs to use LGPL-3 libraries, but
>  >  > excludes free software, licensed GPL-2 only? This sounds absurd to me!
>  >  >
>  >  > Is the FSF spreading FUD with their license matrix? Why doesn't the
>  >  > matrix have footnotes explaining that absurd conflict?
>  >
>  >
>  > Ok, it is not FUD. It seems the problem is, that LGPLv3 imposes
>  >  additional restrictions not found in the GPLv2. So it isn't the LGPLv3
>  >  that forbids LGPLv3 libraries to be used by GPLv2-only programs. It is
>  >  the GPLv2 which forbids to linking against libraries more restrictive
>  >  than itself.
>  >
>  >  See http://www.fsf.org/licensing/licenses/gpl-faq.html#v2v3Compatibility
>  >  for details.
>  >
>  >  In theory LGPLv3 allows addition of exceptions, but they have to be
>  >  approved by all copyright holders. Doubt this will happen. So only
>  >  chance for upgrading to a new version of the LGPL is waiting for an FSF
>  >  approved version of the LGPL, which drops those additional restrictions
>  >  for GPLv2-only programs.
>  >
>  >  Total insanity...
>  >
>  >
>  >  Ciao,
>  >  Mathias
>  >  --
>  >  Mathias Hasselmann <[EMAIL PROTECTED]>
>  >  Openismus GmbH: http://www.openismus.com/
>  >  Personal Site: http://taschenorakel.de/
>  >
>
> > ___
>  >  gtk-devel-list mailing list
>  >  gtk-devel-list@gnome.org
>  >  http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>  >
>  >
>  >
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Minutes: Foreign OSes BoF

[Yevgen Muntyan]

Tor Lillqvist wrote:
>> (Unless there is some way to read and
>>  write text chunks also through GDI+ after all.)
>> 
>
> GDI+ does provide access to *some* tEXt chunks that it knows about a
> priori. At least the Description chunk is available as
> PropertyTagImageDescription and the Software chunk as
> PropertyTagSoftwareUsed. But that doesn't help, as libgimpthumb wants
> to read and write chunks that GDI+ has no idea about, like Thumb::URI
> and Thumb::X-GIMP::Type.
>
> This is a design mistake in the GDI+ library IMHO... Surely they have
> known that in many image formats one can have a set of arbitrary
> tag-value pairs, and they should have provided a way to access these,
> not just those properties they chose to enumerate in GdiPlusImaging.h.
>
> Oh well, we will have to continue using the libpng-based PNG loader
> then. We could link libpng statically, though, if we want to minimize
> the number of "external" DLLs we depend on.
>   

Will cairo move away from libpng too? If not, then
libpng dll is still needed in an application, and so
it's fine for gtk.

Yevgen

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Move to LGPL3

[Lieven van der Heide]

Does that really apply for the code you link to? Afaik, if a GPL
program uses an LGPL library, it doesn't relicense that library under
GPL too, it merely links to it, and leaves it up to the user to make
sure the library is available. If this would be the case, than it
wouldn't be possible for GPL code to use something like the Windows
API or DirectX either.

I think the restriction from the link you posted only apply to GPL
libraries, but not LGPL.

On 3/17/08, Mathias Hasselmann <[EMAIL PROTECTED]> wrote:
>
>  Am Montag, den 17.03.2008, 00:31 +0100 schrieb Mathias Hasselmann:
>
> > I am really wondering what's the reason for FSF claiming, that
>  > programs
>  > licenced GPL-2 only are not allowed to use LGPL-3 libraries. The LGPL-3
>  > allows non-free, proprietary programs to use LGPL-3 libraries, but
>  > excludes free software, licensed GPL-2 only? This sounds absurd to me!
>  >
>  > Is the FSF spreading FUD with their license matrix? Why doesn't the
>  > matrix have footnotes explaining that absurd conflict?
>
>
> Ok, it is not FUD. It seems the problem is, that LGPLv3 imposes
>  additional restrictions not found in the GPLv2. So it isn't the LGPLv3
>  that forbids LGPLv3 libraries to be used by GPLv2-only programs. It is
>  the GPLv2 which forbids to linking against libraries more restrictive
>  than itself.
>
>  See http://www.fsf.org/licensing/licenses/gpl-faq.html#v2v3Compatibility
>  for details.
>
>  In theory LGPLv3 allows addition of exceptions, but they have to be
>  approved by all copyright holders. Doubt this will happen. So only
>  chance for upgrading to a new version of the LGPL is waiting for an FSF
>  approved version of the LGPL, which drops those additional restrictions
>  for GPLv2-only programs.
>
>  Total insanity...
>
>
>  Ciao,
>  Mathias
>  --
>  Mathias Hasselmann <[EMAIL PROTECTED]>
>  Openismus GmbH: http://www.openismus.com/
>  Personal Site: http://taschenorakel.de/
>
> ___
>  gtk-devel-list mailing list
>  gtk-devel-list@gnome.org
>  http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Move to LGPL3

[Sven Herzberg]

Hi Tommi,

Am Dienstag, den 18.03.2008, 11:56 +0200 schrieb Tommi Komulainen:
> On Sat, 2008-03-15 at 21:03 +0100, ext ryan lortie wrote:
> > After some talk at the Hackfest about it, I'm writing the list to
> > officially request that glib and GTK be moved to LGPL "version 3 or
> > later".
> 
> IANAL and all, but here are a few points for consideration based on my
> experience after being exposed to Nokia legal machinery.
> 
>  1. Changing the wording from "version 2 or later" to "version 3 or
> later" will remove the "2 or later" option. To my understanding
> changing the terms of the license text counts as relicensing.

Not really, using "LGPL 2 or later" code unter the terms of "LGPL 3 or
later" is explicitly allowed by the "or later" amendment. Replacing the
"LGPL 2" part of that phrase with "LGPL 3" is completely okay. The text
would only have to be changed once the first patches with "LGPL 3 or
later" (no LGPL 2 anymore) start getting applied.

Remember, anyone is still free to use the last release published under
"LGPL 2 or later" (that's why I actually think that we should only do
that with GTK+ 3.0 if we have really large/good features arriving after
3.0 which people will want to see in their applications - to make them
consider relicensing).

Regards,
  Sven

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GdkWindow clean up for offscreen redirection

[varun shrivastava]

hi

   i tried using the offscreen patch, but has a doubt regarding pixmaps.
What i did is , added gtkentry as a child of gtkoffscreenBox widget.
And than tried setting event mask
GDK_VISIBILITY_NOTIFY_MASKusing
gtk_widget_add_event (after realizing)

I expected to get a signal for visibility-notify-event, but no signal was
emitted
So i looked through the GdkWindow.c and GdkOffscreenWindow.c and found that
iface->set_events has been overridden  to
gdk_offscreen_window_set_events which just updates the  event_mask for
GDK_WINDOW_OBJECT and doesn't propagates to default backend handler
gdk_window_x11_set_events

So what i want to know (as i am not familiar with Xserver), is
Can't we ask xserver to set event mask for pixmaps , if  so, it means i can
not set any event mask using gtk_widget_add_events to offscreen child
widgets.

what can be the solution for adding event mask to offscreen child widgets

bye
varun

On Wed, Feb 27, 2008 at 5:11 PM, Emmanuele Bassi <[EMAIL PROTECTED]> wrote:

> hi all;
>
> the original offscreen redirection patch[1] introduced a clean up work
> for GdkWindow[2] in order to implement the offscreen GdkWindow object.
>
> since this affects the various GDK backends, I think it should go
> through a round of discussion first.
>
> the offscreen redirection patch needs to implement a GdkOffscreenWindow
> class which redirects itself, and every child window, into an offscreen
> pixmap. this means that the GdkWindow API should be implementable not
> only on a per-backend basis but also by any internal, backend-agnostic
> class. in order to achieve that, a GdkWindowImpl interface has been
> added, and every GdkWindow class must implement it.
>
> this moves all the per-backend public API into GdkWindow, proxying the
> GdkWindowImpl vtable functions. the value of this patch, aside from
> making it possible to actually implement GdkOffscreenWindow as a
> GdkWindow subclass, is also in the clean up itself, which removes a lot
> of crud and makes it easier (in my opinion) to implement backends.
>
> I'd like a comment on the patch from the various backends maintainers so
> that we can push the clean up forward and have it land in trunk.
>
> ciao,
>  Emmanuele.
>
> +++
>
> [1] http://bugzilla.gnome.org/show_bug.cgi?id=318807
> [2] the patch has been broken down here:
>http://bugzilla.gnome.org/attachment.cgi?id=104923&action=view
>http://bugzilla.gnome.org/attachment.cgi?id=104924&action=view
>http://bugzilla.gnome.org/attachment.cgi?id=104925&action=view
>http://bugzilla.gnome.org/attachment.cgi?id=104926&action=view
>http://bugzilla.gnome.org/attachment.cgi?id=104927&action=view
>
>the last attachment is the port of the X11 backend to the new
>GdkWindowImpl interface.
>
> --
> Emmanuele Bassi,
> W: http://www.emmanuelebassi.net
> B: http://log.emmanuelebassi.net
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Move to LGPL3

[Tommi Komulainen]

On Sat, 2008-03-15 at 21:03 +0100, ext ryan lortie wrote:
> Hello.
> 
> After some talk at the Hackfest about it, I'm writing the list to
> officially request that glib and GTK be moved to LGPL "version 3 or
> later".

IANAL and all, but here are a few points for consideration based on my
experience after being exposed to Nokia legal machinery.

 1. Changing the wording from "version 2 or later" to "version 3 or
later" will remove the "2 or later" option. To my understanding
changing the terms of the license text counts as relicensing.
 2. Due to the (L)GPLv2 and v3 incompatibility everything above glib
(or gtk+) would have to be distributed under v3, which as
already noted is a problem if you have any v2 only sources in
any glib application. It would be a significant disruption for
distributors to make sure all the licenses are OK.
 3. Companies are vary of GPLv3. It took a long time to begin to
understand GPLv2, GPLv3 is still relatively more intimidating.


-- 
Tommi Komulainen<[EMAIL PROTECTED]>

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Minutes: Foreign OSes BoF

[Tor Lillqvist]

> (Unless there is some way to read and
>  write text chunks also through GDI+ after all.)

GDI+ does provide access to *some* tEXt chunks that it knows about a
priori. At least the Description chunk is available as
PropertyTagImageDescription and the Software chunk as
PropertyTagSoftwareUsed. But that doesn't help, as libgimpthumb wants
to read and write chunks that GDI+ has no idea about, like Thumb::URI
and Thumb::X-GIMP::Type.

This is a design mistake in the GDI+ library IMHO... Surely they have
known that in many image formats one can have a set of arbitrary
tag-value pairs, and they should have provided a way to access these,
not just those properties they chose to enumerate in GdiPlusImaging.h.

Oh well, we will have to continue using the libpng-based PNG loader
then. We could link libpng statically, though, if we want to minimize
the number of "external" DLLs we depend on.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Minutes: Foreign OSes BoF

[Tor Lillqvist]

> This change would still break the thumbnailing system built into
>  libgimpthumb. This code uses the PNG module from gdk-pixbuf to load and
>  save thumbnails and it relies on the ability to read PNG text chunks
>  from PNG images and to set the PNG text chunk when creating PNG files.

Ah, thanks for the heads-up. This means we can't use a GDI+ -based
gdk-pixbuf loader for PNG then. (Unless there is some way to read and
write text chunks also through GDI+ after all.)

>  It's also important to support the JPEG quality option on the JPEG save 
> module.

That is handled, yes. Also setting the PNG compression level is possible,

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Minutes: Foreign OSes BoF

[Mathias Hasselmann]

Am Montag, den 17.03.2008, 21:18 -0400 schrieb Dominic Lachowicz:
> * The functions that enumerate GDI+'s loaders simply don't exist in
> the 1.0 version of the GDI+ DLL. They may exist in the 1.1 DLL (which
> is not re-distributable AFAIK), but that's only in Windows Vista, and
> we know how great Vista adoption is going.

Not sure if .NET's image loaders use GDI+ 1.0 or 1.1 or if they are
fully managed (the API doesn't look like that). Well, but I've
successfully enumerated image loaders using this method:

  System.Drawing.Imaging.ImageCodecInfo.GetImageEncoders()

So maybe the functionality just is well hidden for GDI+ 1.0?

Ciao,
Mathias
-- 
Mathias Hasselmann <[EMAIL PROTECTED]>
Openismus GmbH: http://www.openismus.com/
Personal Site: http://taschenorakel.de/


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Minutes: Foreign OSes BoF

[Sven Neumann]

Hi,

On Mon, 2008-03-17 at 12:42 +0200, Tor Lillqvist wrote:
> >  GIMP will continue to link in libpng, libjpeg, and etc., so
> >  that won't be affected by this regression.
> 
> Yep. GIMP needs all the information it can get, especially for JPEG,
> where it needs to actually have a look at the quantization tables from
> the image file.

This change would still break the thumbnailing system built into
libgimpthumb. This code uses the PNG module from gdk-pixbuf to load and
save thumbnails and it relies on the ability to read PNG text chunks
from PNG images and to set the PNG text chunk when creating PNG files.
So if you are taking away this functionality from the PNG module on the
Windows platform, then this would be a major regression.

It's also important to support the JPEG quality option on the JPEG save
module. How is that handled in the GDI code?


Sven


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list