Re: Minutes: Foreign OSes BoF
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
Re: Minutes: Foreign OSes BoF
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
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
(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
* 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: Minutes: Foreign OSes BoF
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
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 gdk-pixbuf-i18n.h 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
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. I think it should be fine to start integrating gdip-pixbuf-loader into gtk+/trunk now then? Will start on it this evening, probably, unless somebody else beats me to it. --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
While hacking on integrating the GDI+ loader into the GTK+ tree I started wondering: If we build the GDI+ loader into the gdk-pixbuf DLL (instead of having it as a separate DLL), then it should be possible to determine the supported formats at run-time, right? (And thus automatically get support for whatever new formats are added to GDI+, or have been added on the machine by installing some extension or plug-in to GDI+.) Presumably the GDI+ loader would then have to appear to gdk-pixbuf as two separate loaders, one for the read-only formats, and one for the read-write ones, even if both are implemented in the same source file(s). --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
Hi Tor, In order for that to happen, someone would need to re-design (at minimum) GdkPixbuf's module and loader interfaces and use Windows Vista or newer. Some notable problems are: * The loader's create by type function uses the module's name (i.e. gdi+ or png), rather than a mime-type. Lots of programs assume a 1:1 relationship (eg. give me the 'wmf' loader). * The savers have a similar deficiency. You can't say save as this mime type. You have to say use the 'png' module to save this. The format is implied by the module's name. * Along with that, there's the assumption that a module may load many formats, but there's no corresponding way for it to save to multiple formats as GDI+ can do. * The query-loaders mechanism requires that the supported formats be known ahead of time But enough about GdkPixbuf's deficiencies, because GDI+ has its share too: * 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. You can't get a GpMetafile's pixels, even if you load it as a GpBitmap. The work-around is to draw it to a GpGraphics object backed by a bitmap, but you probably don't want to do that for something that is already a bitmap. It's wasteful of CPU cycles and RAM. But that's overshadowed by the bigger problem of: * 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. That's just off the top of my head. Best regards, Dom On Mon, Mar 17, 2008 at 8:55 PM, Tor Lillqvist [EMAIL PROTECTED] wrote: While hacking on integrating the GDI+ loader into the GTK+ tree I started wondering: If we build the GDI+ loader into the gdk-pixbuf DLL (instead of having it as a separate DLL), then it should be possible to determine the supported formats at run-time, right? (And thus automatically get support for whatever new formats are added to GDI+, or have been added on the machine by installing some extension or plug-in to GDI+.) Presumably the GDI+ loader would then have to appear to gdk-pixbuf as two separate loaders, one for the read-only formats, and one for the read-write ones, even if both are implemented in the same source file(s). --tml -- Counting bodies like sheep to the rhythm of the war drums. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minutes: Foreign OSes BoF
Hmm, there are the ImageCodecFlagsSupportBitmap and
ImageCodecFlagsSupportVector bits in the ImageCodecInfo::Flags field,
is that enough?
Apparently not. Running the attached test program (from the Plaform
SDK docs, with some additions) prints for me on XP:
Decoders:
image/bmp: *.BMP;*.DIB;*.RLE: Built-in BMP Codec
BMP
Encoder Decoder SupportBitmap Builtin
image/jpeg: *.JPG;*.JPEG;*.JPE;*.JFIF: Built-in JPEG Codec
JPEG
Encoder Decoder SupportBitmap Builtin
image/gif: *.GIF: Built-in GIF Codec
GIF
Encoder Decoder SupportBitmap Builtin
image/x-emf: *.EMF: Built-in EMF Codec
EMF
Decoder SupportBitmap Builtin
image/x-wmf: *.WMF: Built-in WMF Codec
WMF
Decoder SupportBitmap Builtin
image/tiff: *.TIF;*.TIFF: Built-in TIFF Codec
TIFF
Encoder Decoder SupportBitmap Builtin
image/png: *.PNG: Built-in PNG Codec
PNG
Encoder Decoder SupportBitmap Builtin
image/x-icon: *.ICO: Built-in ICO Codec
ICO
Decoder SupportBitmap Builtin
Encoders:
image/bmp
image/jpeg
image/gif
image/tiff
image/png
Note that for EMF and WMF it just says SupportBitmap like for the
true bitmap formats. Sigh.
--tml
#include windows.h
#include GdiPlus.h
#include stdio.h
using namespace Gdiplus;
int
main (int argc, char **argv)
{
// Initialize GDI+.
GdiplusStartupInput gdiplusStartupInput;
ULONG_PTR gdiplusToken;
GdiplusStartup(gdiplusToken, gdiplusStartupInput, NULL);
UINT num;// number of image decoders
UINT size; // size, in bytes, of the image decoder array
ImageCodecInfo* pImageCodecInfo;
// How many decoders are there?
// How big (in bytes) is the array of all ImageCodecInfo objects?
GetImageDecodersSize(num, size);
// Create a buffer large enough to hold the array of ImageCodecInfo
// objects that will be returned by GetImageDecoders.
pImageCodecInfo = (ImageCodecInfo*)(malloc(size));
// GetImageDecoders creates an array of ImageCodecInfo objects
// and copies that array into a previously allocated buffer.
// The third argument, imageCodecInfos, is a pointer to that buffer.
GetImageDecoders(num, size, pImageCodecInfo);
// Display the graphics file format (MimeType)
// for each ImageCodecInfo object.
printf(Decoders:\n);
for(UINT j = 0; j num; ++j)
{
printf ( %S: %S: %S\n
%S\n,
pImageCodecInfo[j].MimeType,
pImageCodecInfo[j].FilenameExtension,
pImageCodecInfo[j].CodecName,
pImageCodecInfo[j].FormatDescription);
printf ( );
#define BIT(x) if (pImageCodecInfo[j].Flags ImageCodecFlags ## x) printf (
%s, #x)
BIT (Encoder);
BIT (Decoder);
BIT (SupportBitmap);
BIT (SupportVector);
BIT (SeekableEncode);
BIT (BlockingDecode);
BIT (Builtin);
BIT (System);
BIT (User);
#undef BIT
printf (\n);
}
// Ditto for encoders
GetImageEncodersSize(num, size);
pImageCodecInfo = (ImageCodecInfo*)(malloc(size));
GetImageEncoders(num, size, pImageCodecInfo);
printf(Encoders:\n);
for(UINT j = 0; j num; ++j)
{
printf( %S\n, pImageCodecInfo[j].MimeType);
}
free(pImageCodecInfo);
GdiplusShutdown(gdiplusToken);
return 0;
}
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minutes: Foreign OSes BoF
Tentative patch at http://tml.pp.fi/gdip-in-gtk.diff . Comments, please. By default, with this patch, the GDI+ loaders are built when targeting Windows. If one uses the --with-included-loaders (without any further specification) option to configure, the GDI+ loaders (and the others, too) are built-in, otherwise they are built as DLLs. If one uses --disable-gdiplus-loaders, no GDI+ loaders are built, and instead the traditional ones are built. Other combinations of options probably won't work, or require listing all the gdip-foo loaders, or something like that. Will have to work on this. Or maybe all this optionality is unnecessary bling when targeting Windows, and it should just always build the GDI+ loaders and the non-external-library ones as built-in. --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
I think that they're ready to go. Outside of the GTK+ tree, they won't get much testing. Do you think they cam unconditionally replace the traditional loaders that depend on external libraries for Win32, or should we add some --disable-gdiplus-loaders switch to the configury? --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
Hi Tor, On Sun, Mar 16, 2008 at 4:27 AM, Tor Lillqvist [EMAIL PROTECTED] wrote: I think that they're ready to go. Outside of the GTK+ tree, they won't get much testing. Do you think they cam unconditionally replace the traditional loaders that depend on external libraries for Win32, or should we add some --disable-gdiplus-loaders switch to the configury? I'd have them unconditionally replace the traditional loaders wherever the format is supported by the GDI+ plugin. I'd unconditionally add the formats supported by this plugin but not by GdkPixbuf (i.e. WMF and EMF). And I'd still build the traditional XPM, ANI, etc. plugins, as they don't have any external dependencies. Dom -- Counting bodies like sheep to the rhythm of the war drums. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minutes: Foreign OSes BoF
Am Sonntag, den 16.03.2008, 11:22 -0400 schrieb Dominic Lachowicz: Hi Tor, On Sun, Mar 16, 2008 at 4:27 AM, Tor Lillqvist [EMAIL PROTECTED] wrote: I think that they're ready to go. Outside of the GTK+ tree, they won't get much testing. Do you think they cam unconditionally replace the traditional loaders that depend on external libraries for Win32, or should we add some --disable-gdiplus-loaders switch to the configury? I'd have them unconditionally replace the traditional loaders wherever the format is supported by the GDI+ plugin. I'd unconditionally add the formats supported by this plugin but not by GdkPixbuf (i.e. WMF and EMF). And I'd still build the traditional XPM, ANI, etc. plugins, as they don't have any external dependencies. So what are your plans for PNG tEXt records? Does GDI+ support them? Unconditionally replacing the libpng loader, without supporting that records would be a regression. 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
Relatedly, I believe we should also consider bundling the 'native' pixbuf loaders that have seen the light of day recently. Sure. Will do soonish for the Win32 GDI+ one. --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
Matthias Clasen wrote: 2008/3/13 Alberto Ruiz [EMAIL PROTECTED]: * Engines: both needs some love, the win32 one is almost into an acceptable shape, whereas the Mac OS X one still nees some love, although it's getting along pretty well. There is an os x theme engine ? Where is it, I don't see it in the gtk+ tree. Should we not include it here, similar to the ms-windows theme engine ? Yes, there is one underway, still quite far from being usable. It lives in git currently (git://git.imendio.com/richard/quartz-engine.git), and the plan is to move it into gtk+ when it starts to get useful. /Richard -- 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: Minutes: Foreign OSes BoF
On Sat, Mar 15, 2008 at 4:18 AM, Tor Lillqvist [EMAIL PROTECTED] wrote: Relatedly, I believe we should also consider bundling the 'native' pixbuf loaders that have seen the light of day recently. Sure. Will do soonish for the Win32 GDI+ one. I've just committed proper support for metafiles (EMF, WMF). Also, I've separated all of the formats out into their own DLLs, so that gdk_pixbuf_loader_new_for_type(wmf) will continue to work. As of now, the loaders are on-par with the builtin ones, with the exception that they don't load or save PNG tEXt chunks. I think that they're ready to go. Outside of the GTK+ tree, they won't get much testing. Cheers, 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
2008/3/13 Alberto Ruiz [EMAIL PROTECTED]: * Engines: both needs some love, the win32 one is almost into an acceptable shape, whereas the Mac OS X one still nees some love, although it's getting along pretty well. There is an os x theme engine ? Where is it, I don't see it in the gtk+ tree. Should we not include it here, similar to the ms-windows theme engine ? Relatedly, I believe we should also consider bundling the 'native' pixbuf loaders that have seen the light of day recently. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minutes: Foreign OSes BoF
13 mar 2008 kl. 10.13 skrev Alberto Ruiz: Hi Alberto, Thanks for sharing the results of the BoF! Looks like you had a good discussion. Cheers, Micke Hi, this is some sort of summary of the issues discussed in the foreign OSes BoF at the hackfest. Attendees: tml, jdahlin, rhult, kris, bratsche and myself were there. The discussion was focussed on Win32 and OSX, and we identified the main challenges there. The problems: * We tried to identify the reason because people are choosing wxWidgets or Qt over Gtk+, it's not a technical issue rather than a marketing one. People feel like wxWidgets is better because they use native widgets, improving the engine and the dialog look and feel would help there. * It's really hard for application developers to figure out how to create and deploy an application out of the linux environment. We should provide better developer tools. * Regarding the previous point, we should provide better installers of the Gtk+ runtime that can be reused from their development environment so people don't have to rebuild Gtk+ themselves and distribute a custom version. The status: * Backends: rhult keeps working hard to get the Mac OSX one into shape, it seems that we're not far to get there. bratsche and tml are rocking on the win32 front, it's been working for a while now, and besides some glitches, it's in an acceptable state at this point. * Engines: both needs some love, the win32 one is almost into an acceptable shape, whereas the Mac OS X one still nees some love, although it's getting along pretty well. *Development tools: kris got XCode integration working, it would be nice to automate the generation of the XCode template installer and kind of make it a mainstream process. As for Visual Studio, bratsche and I am going to start getting into Visual Studio to see if we can come up with something similar. *Packaging: On OSX seems to be pretty much there for Gtk+ installation, not a big deal anyway. On the Win32 front we are close to have a componentized .msi installer. The plans: We splitted the target audience for this effort into two: Gtk+ Application developers, and Gtk+ developers. We're going to focus first in the first ones. And hold the discussion about people wanting to hack on gtk+ using the development environments on osx and win32. First step: Let's have a clear and only answer for people willing to create and distribute/deploy applications on those platforms. We got to the conclusion that we should encourage apps to redistribute gtk+ bundled with their apps, but make sure that they don't build it themselves, so we don't have dozens of incompatible binaries out there. For win32 we want to research if we could reduce the complexity of the runtime by trying to come up with a single .dll and bundle the .mo catalog files so we end up with less unix hierarchy involved in the runtime. This is not a problem at all on OSX though. We're going to try to push this as a consistent effort between the win32 and osx gangs. Once we have most of the goals there, we will be able to start to send the message that Gtk+ is getting real native :) That's pretty much it, If someone from the BoF feels like I missed something please add your comments. Cheers, Alberto Ruiz ___ 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
