2008/10/21 Vincent Torri <[EMAIL PROTECTED]>:
> speaking of that, as there are other Windows library, not related to gtk,
> that may use libjpeg, tiff, png, etc..., woud it be possible to install them
> in a drectory not specific to GTK (like in Program Files/Common
> Files/generic, or something li
On Tue, 21 Oct 2008, [EMAIL PROTECTED] wrote:
2008/10/21 Tor Lillqvist <[EMAIL PROTECTED]>:
But I admit I don't have any *really* strong preference. If it really
is so that the majority of people who distribute GTK+ apps on Windows
would prefer that the pixbuf loaders were separate DLLs I can
2008/10/21 Tor Lillqvist <[EMAIL PROTECTED]>:
> But I admit I don't have any *really* strong preference. If it really
> is so that the majority of people who distribute GTK+ apps on Windows
> would prefer that the pixbuf loaders were separate DLLs I can return
> to that. Is there anybody out there
> Sorry (just out of ignorance): who or what forced you to revert to
> the libjpeg- and libtiff-based loaders?
The GDI+ ones don't work... They work for "small" files, but if the
file size (not the image size!) is larger than a limit that seems to
be around 60 KB, loading fails... See bug #552678.
On Tue, 21 Oct 2008, Tor Lillqvist wrote:
> >> Was there a compelling reason for this reversion?
>
> Not really. As has already been said, if/when the GDI+ -based
> pixbuf loaders would be used, then it would hopefully be 100%
> clear that it makes sense to build them as built-in in the
> gdk-
On Mon, Oct 20, 2008 at 7:20 PM, Tor Lillqvist <[EMAIL PROTECTED]> wrote:
>>> Was there a compelling reason for this reversion?
>
> Not really. As has already been said, if/when the GDI+ -based pixbuf
> loaders would be used, then it would hopefully be 100% clear that it
> makes sense to build them
>> Was there a compelling reason for this reversion?
Not really. As has already been said, if/when the GDI+ -based pixbuf
loaders would be used, then it would hopefully be 100% clear that it
makes sense to build them as built-in in the gdk-pixbuf DLL. But now
when I was forced to revert to the lib
On Mon, Oct 20, 2008 at 4:57 PM, Allin Cottrell <[EMAIL PROTECTED]> wrote:
> On Mon, 20 Oct 2008, Daniel Atallah wrote:
>
>> On Mon, Oct 20, 2008 at 12:01 PM, Allin Cottrell <[EMAIL PROTECTED]> wrote:
>> > But I see that the current GTK 2.14.4 package
>> > ( http://www.gtk.org/download-windows.html
On Mon, Oct 20, 2008 at 4:57 PM, Allin Cottrell <[EMAIL PROTECTED]> wrote:
> On Mon, 20 Oct 2008, Daniel Atallah wrote:
>
>> On Mon, Oct 20, 2008 at 12:01 PM, Allin Cottrell <[EMAIL PROTECTED]> wrote:
>> > But I see that the current GTK 2.14.4 package
>> > ( http://www.gtk.org/download-windows.html
On Mon, 20 Oct 2008, Daniel Atallah wrote:
> On Mon, Oct 20, 2008 at 12:01 PM, Allin Cottrell <[EMAIL PROTECTED]> wrote:
> > But I see that the current GTK 2.14.4 package
> > ( http://www.gtk.org/download-windows.html ) has reverted to a
> > monolithic build, so that a gtk app won't start without
On Mon, Oct 20, 2008 at 12:01 PM, Allin Cottrell <[EMAIL PROTECTED]> wrote:
> A while back some app developers who have need of GTK+ on MS
> Windows, yet whose apps use only a subset of the available
> image-loaders, requested that the build of the Windows packages be
> made modular (as it was in t
A while back some app developers who have need of GTK+ on MS
Windows, yet whose apps use only a subset of the available
image-loaders, requested that the build of the Windows packages be
made modular (as it was in the old days). That way, one can slim
down the packaging of one's app, skipping
12 matches
Mail list logo
