Re: Accessibility in GTK+ under Windows - a question to maintainers
Please excuse my ignorance, but why would the *users* need to download and build anything? Why wouldn't GTK+ applications (eg. Pidgin) just ship with the accessibility bridge included with their installer? Thanks, Dom On Wed, Apr 18, 2012 at 11:24 AM, Евгений Филиппов egphilip...@gmail.com wrote: Piñeiro, I did not yet study the GTK internals. What I would like---I'd like to interlink GTK with UIA. How is should be best done is another question. Mainly my question is: Do GTK's maintainers and do GTK's Windows port maintainers allow this: If an user wants GTK to support UIA, he would download Windows SDK (WSDK) and build GTK against WSDK, namely GTK needs to be linked with UIA headers and dll/lib libraries, to support UIA. So the maintainers---please do answer this. As this would extend GTK's user base to people with disabilities who still need Windows, and is a good deed. BR, Evgeniy On 19/04/2012, Piñeiro apinhe...@igalia.com wrote: On 04/17/2012 01:50 PM, Evgeniy Philippov wrote: (I didn't yet research where my possible future UIA code goes to: probably to ATK, but I didn't study yet.) Why on ATK? ATK is an accessibility abstraction like UIA. What do you want to add on ATK in relation to UIA? BR -- Alejandro Piñeiro Iglesias ___ 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 -- I like to pay taxes. With them, I buy civilization. -- Oliver Wendell Holmes ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
If you want this sort of behavior, use a language like C++ that
supports stack-allocated objects natively. GtkMM and GlibMM already do
this wonderfully. Using a GNU-C ism which probably won't work with
most other C compilers (MSVC, LLVM, ICC, ...) feels wrong to me.
On Mon, Nov 21, 2011 at 10:34 AM, Mikkel Kamstrup Erlandsen
mikkel.kamst...@canonical.com wrote:
On 11/21/2011 03:45 PM, Morten Welinder wrote:
if (1)
{
glocal_object GFile *file = g_file_new_for_path (/tmp);
glocal_string gchar *basename = g_file_get_basename (file);
g_debug (Basename is '%s', basename);
// look ma' no leaks!
}
This is, of course, cute but I don't think this would actually catch many
of the
non-trivial leaks that make it into the code base today. Those are
typically
not scope based -- possibly because the attention span of the average
programmer is long enough to cover the writing of a whole function, ;-)
The current serious leak cases I see are:
* The dispose or finalize method of an object type fails to free some
stuff. This is
quite common.
* Cyclical links. The resulting leaks are typically quite big.
A case scope-based destructors would handle is this:
* Multiple return statements, typically for error handling, where one or
more
branches forget to free stuff. Cursory valgrinding doesn't catch this
because
the code doesn't get exercised.
The case isn't uncommon, per se, but programs don't hit the cases often.
This is precisely my motivation for introducing this; ie. not to catch
leaks, but to tidy the code. Bigger code bases almost always grow functions
with multiple returns - notably when error handling is introduced. Automatic
freeing can cut down on that complexity considerably. On less complex
functions it can still add clarity by making the actual algorithms more
apparent in between all the g_free()s and g_object_unref()s.
Cheers,
Mikkel
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
--
I like to pay taxes. With them, I buy civilization. -- Oliver Wendell Holmes
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK on Macintosh OSX
It sounds like you want magic to happen. Either you have to use some
sort of script to re-normalize the paths, or you can use glib's
functions to look up data files relative to the bundle itself, without
needing to write (much) OSX-specific ObjC code. It's not inventing
anything. It's just implementing these APIs in terms of how the
operating system's packaging conventions behave.
Best,
Dom
On Sun, Jul 12, 2009 at 10:47 PM, John Rallsjra...@ceridwen.us wrote:
On Jul 12, 2009, at 6:18 PM, Dominic Lachowicz wrote:
Glib on Win32 has routines to solve this problem. It resolves things
relative to where the Glib DLL is installed. If your applications use
the XDG data directory functions in Glib, you might get away with this
too. Maybe you could invent something similar that used the OSX bundle
as your point of reference.
The routines only solve the problem if they're used.
Don't need to invent anything. The core foundation functions are easy to
use, and Richard Hult already abstracted it into a gobject. But the code
still has to be patched. It's not just application code, either, but
infrastructure libraries like gconf, gnome-keyring, dbus, etc.
I set up a $PREFIX of /usr/local/gtk, built Gnucash, and ran `find
/usr/local/gtk -name *.dylib -exec strings \{\} | grep -H 'local/gtk' \; `
and got more than 100 hits. Many of them are likely to be just a define that
isn't used for anything, but every one would have to be examined, and a
goodly number of them would require patching.
Regards,
John Ralls
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
--
I like to pay taxes. With them, I buy civilization. -- Oliver Wendell Holmes
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK on Macintosh OSX
Glib on Win32 has routines to solve this problem. It resolves things relative to where the Glib DLL is installed. If your applications use the XDG data directory functions in Glib, you might get away with this too. Maybe you could invent something similar that used the OSX bundle as your point of reference. On Sun, Jul 12, 2009 at 9:10 PM, John Rallsjra...@ceridwen.us wrote: On Jul 12, 2009, at 4:29 AM, Paul Davis wrote: I have a fix for drag-n-drop that we have been using with Ardour for more than a year. I will get into bugzilla for review. Its a pretty simple patch. Not sure what problem you have with pasting, but that works fine for all the purposes that we use it for in Ardour. We bundle Ardour for OS X and chose the include GTK framework in the .app. Ardour is fully relocatable - I believe I was responsible for the description of how to do this that Richard wrote up. Its basically a matter of using an apple-provided tool to both locate and reset the paths to every library the app depends on. I have a nice little shell script that recursively finds every dynamically linked object that the app uses, copies it into the app structure and then resets the link-time dependency so that its relative to the app bundle. Because we have/need a couple of hacks in GTK that are not likely to go away anytime soon, I can't imagine us being interested in the blessed framework approach. Regarding the general question of non-X11 backends being 2nd-class citizens ... yes, I have seen and suffered from this problem when I was doing work on gtk/osx last year and the previous year. It would be nice if we could somehow get the core GTK team to commit to not making changes that are not tested on non-X11 backends, but this seems unlikely and the reasons are not totally unreasonable. Given that Ardour on OS X is critical to my income, you can expect me to have a strong interest in keeping at least some version of GTK functional on OS X and on continuing to fix issues that we encounter. --p Paul, Yes, the nice little shell script is part of ige-mac-bundler, a python program which populates a bundle and which is now in my care. But the problem isn't with rpaths. The problem is with path strings compiled into the library. Ardour must not run into this problem, but Gnucash does, in spades. There are three alternative solutions: 1. Build the library to use /Library/Application Support/Appname for its data prefix. Then the library can be bundled as usual, but has to use Installer to populate the data directory. 2. Bundle related libraries and executables into Frameworks with a hard-coded installation in /Library/Frameworks, and link the frameworks to the installation. Again, Installer is required. 3. Patch everything to discover if it's in a bundle, and if so use CFBundle functions to find its resources. This can create a drag-and-drop installation, but the work required is a bit daunting. There's one other, rather hacky, approach: Build into a $prefix, bundle with the install_name_tool routine turned off, and have the launch script create a softlink from the bundle's resources directory to $prefix if it's not already there. I've just implemented it for Gnucash. I don't think that it should be the official way, but it is a way. I'd like to see your fix for d-n-d. The problem I see with pasting is simply that when I cut something and try to paste it back in, nothing pastes. That could be a problem on the cut side instead of the paste side. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- I like to pay taxes. With them, I buy civilization. -- Oliver Wendell Holmes ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: cairo surface from GdkPixmap
Unfortunately this won't work for me. gdk_cairo_create() creates a Cairo surface, then it creates a Cairo context from this surface, and then it destroys the Cairo surface. What I am looking for is a function that creates a Cairo surface and returns it directly. Then I can use pycairo to create a Cairo context from the Cairo surface, which allows me to subclass the Cairo context. The gtk function _gdk_drawable_ref_cairo_surface does exactly what I want, however this is a private function. The surface isn't destroyed, it's un-reffed. You can still get the surface from the context using cairo's get_target() method, and then do with the surface as you please. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: regarding animated mng support in gtk for directfb
Also, you could write a GdkPixbufLoader plugin, so that all GTK+ apps
can view MNGs. It shouldn't be too difficult.
On Tue, Mar 10, 2009 at 11:52 AM, Sven Neumann s...@gimp.org wrote:
Hi,
On Sat, 2009-03-07 at 10:37 +0530, Monil Parmar wrote:
I am using GTK-2.12.12.
I have compiled mng lib from http://sourceforge.net/projects/libmng/ .
The test application, I have used for X11 with linux.mng is at
libmng-1.0.10/contrib/gcc/gtm-mng-view .
gtk-mng-view is a sample gtk based application to view mng.
I could able to see linux.mng with animation effect.
But when I try to run the same source code(gtk-mng-view) for
GTK/DirectFB only 1st frame it shows.
I've had a look at this and the problem is clearly in the gtk-mng-view
code. The example code there draws outside the expose handler. This is
something that you should never do. It may work for GTK-X11 if you are
lucky, but it's not supported and it definitely does not work if you
using the DirectFB backend. Simply replace the function
mng_refresh_callback() in gtk-mng-view.c with the following code and it
will work just fine:
static mng_bool
mng_refresh_callback (mng_handle mng_h,
mng_uint32 x,
mng_uint32 y,
mng_uint32 width,
mng_uint32 height)
{
gtk_widget_queue_draw_area (GTK_WIDGET (mng_get_userdata (mng_h)),
x, y, width, height);
return MNG_TRUE;
}
Sven
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
--
Mediocrity knows nothing higher than itself; but talent instantly
recognizes genius.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ documentation wikified
That's hard-ish to do today. GTK+'s documentation is generated in large part by scanning comments in C code, which a program then turns into HTML. Any proposal would require a way to keep the Wiki and the C comments in-sync. On Thu, Feb 19, 2009 at 10:28 AM, Eugene Gorodinsky e.gorodin...@gmail.com wrote: Hi all Since you guys are discussing the redesign of the gtk+ website, I'd like to propose an idea that I have. I've seen quite a lot of comments saying gtk+ documentation isn't as good as qt's. What do you think of having a wiki that documents all of gtk+ api? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- 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: gtk+ documentation wikified
Yes. The most common example I can think of is when a function is deprecated. On Thu, Feb 19, 2009 at 10:52 AM, Eugene Gorodinsky e.gorodin...@gmail.com wrote: Have there been cases where documentation for some function was changed after that function appeared in the stable version? 2009/2/19 Dominic Lachowicz domlachow...@gmail.com: That's hard-ish to do today. GTK+'s documentation is generated in large part by scanning comments in C code, which a program then turns into HTML. Any proposal would require a way to keep the Wiki and the C comments in-sync. On Thu, Feb 19, 2009 at 10:28 AM, Eugene Gorodinsky e.gorodin...@gmail.com wrote: Hi all Since you guys are discussing the redesign of the gtk+ website, I'd like to propose an idea that I have. I've seen quite a lot of comments saying gtk+ documentation isn't as good as qt's. What do you think of having a wiki that documents all of gtk+ api? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Counting bodies like sheep to the rhythm of the war drums. -- 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: utf-16 and glib
What is wrong with: gchar* g_utf8_strncpy (gchar *dest,const gchar *src,gsize n); That's one not needed as strncpy should work. hehe i know but that function it really exist: http://library.gnome.org/devel/glib/unstable/glib-Unicode-Manipulation.html#g-utf8-strncpy It does make sense. strncpy copies N bytes, when what you want to do is copy N characters from a multi-byte encoded string. You don't want to the copy to stop somewhere in the middle of a multi-byte character sequence because the result simply wouldn't make sense. and the macro: gtext* g_text_strncpy (gtext*dest,const gtext*src,gsize n); Because having 2 implementations of a function and having 1 automatically chosen by a pre-processor macro is one of the worst API decisions that Microsoft has ever made. And that's saying something. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: utf-16 and glib
Glib/gtk is full of macros. I believe que a C compiler is the right place to this kind of unsafe code. If i want create safe code i have c#,c++, JAVA, D or VALA. Using macros is the only way to ensure intermediate APIs don´t have any overhead. Besides modern GUIs have support to understand what we have in a MACRO. Visual c++ have that kind of support. The argument isn't against macros in general. It's against having macros choose an underlying implementation of a function. As far as I'm aware, this is only done in glib on win32 where filenames are concerned. And this was done because we couldn't change the *fundamentally broken* API due to ABI guarantees (the functions were defined as taking a string in your multi-byte locale. if you upgraded glib to a version that always expected utf8, a lot of existing apps would break due to no fault of their own, which would be bad). That's a completely different use case than yours. And a regrettable one, because everyone agrees that we'd rather not have those macros there if we could have somehow avoided them. You're not supposed to explicitly call the _utf8() version, nor are you supposed to have access to the other deprecated, broken version. Contrast this with all of Microsoft's A/W functions, and you'll see that the situations are completely different. So what you're suggesting is introducing brokenness by design, rather than reluctantly coping with some brokenness of an existing design. Besides, your case is based on some presumed efficiency of using UTF-16, but you have demonstrated no such evidence in your favor, which is unlikely to convince glib's maintainers. The cost of converting a filename from UTF-8 to UTF-16 isn't very high, I'll tell you. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: utf-16 and glib
What is wrong with: gchar* g_utf8_strncpy (gchar *dest,const gchar *src,gsize n); That's one not needed as strncpy should work. hehe i know but that function it really exist: http://library.gnome.org/devel/glib/unstable/glib-Unicode-Manipulation.html#g-utf8-strncpy It does make sense. strncpy copies N bytes, when what you want to do is copy N characters from a multi-byte encoded string. You don't want to the copy to stop somewhere in the middle of a multi-byte character sequence because the result simply wouldn't make sense. and the macro: gtext* g_text_strncpy (gtext*dest,const gtext*src,gsize n); Because having 2 implementations of a function and having 1 automatically chosen by a pre-processor macro is one of the worst API decisions that Microsoft has ever made. And that's saying something. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: utf-16 and glib
Glib/gtk is full of macros. I believe que a C compiler is the right place to this kind of unsafe code. If i want create safe code i have c#,c++, JAVA, D or VALA. Using macros is the only way to ensure intermediate APIs don´t have any overhead. Besides modern GUIs have support to understand what we have in a MACRO. Visual c++ have that kind of support. The argument isn't against macros in general. It's against having macros choose an underlying implementation of a function. As far as I'm aware, this is only done in glib on win32 where filenames are concerned. And this was done because we couldn't change the *fundamentally broken* API due to ABI guarantees (the functions were defined as taking a string in your multi-byte locale. if you upgraded glib to a version that always expected utf8, a lot of existing apps would break due to no fault of their own, which would be bad). That's a completely different use case than yours. And a regrettable one, because everyone agrees that we'd rather not have those macros there if we could have somehow avoided them. You're not supposed to explicitly call the _utf8() version, nor are you supposed to have access to the other deprecated, broken version. Contrast this with all of Microsoft's A/W functions, and you'll see that the situations are completely different. So what you're suggesting is introducing brokenness by design, rather than reluctantly coping with some brokenness of an existing design. Besides, your case is based on some presumed efficiency of using UTF-16, but you have demonstrated no such evidence in your favor, which is unlikely to convince glib's maintainers. The cost of converting a filename from UTF-8 to UTF-16 isn't very high, I'll tell you. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gdkpixbufloader-API shortcoming
A possible (though non-optimal) solution is to create 2 loaders - 1 for image/x-foo and 1 for image/x-bar. You can share 99% of the code, and then pass the mime type to your decoder function, based on which DLL got invoked. This is what the GDI+ based loaders do on Windows, for instance. Best, Dom On Wed, Jun 11, 2008 at 3:19 PM, Magnus Bergman [EMAIL PROTECTED] wrote: A small shortcoming in the gdkpixbufloader-API causes me trouble. The problem is this: Let's say my loader libpixbufloader-foobar can handle the two (very similar) formats image/x-foo and image/x-bar. Then an application identifies an image as either foo or bar it invokes my loader. But the loader has no way of telling if it's supposed to handle a foo-image or a bar-image. I guess that the idea is that the loader should be able to easy distinguish between the two formats by fingerprinting the first few bytes. But since both foo and bar lack a decent header that cannot be done. (I must stress that this is not a hypothetical problem but a very real one I have encountered more than once then writing loaders for obscure formats). The solution is some way for the loader to know why it was chosen. Either which mimetype or which extension (of those supplied by the loader) was a match. Perhaps just a function which could be called by the loader like: gdk_pixbuf_why_me(gpointer handle,gchar **matching_mimetype,gchar ** matching_extension); Or are there some plans for a totally new API for pixbuf loaders since I have seen some other shortcomings of the current one. Someone requested about the same thing as me (but for using an external library which already supported all image formats supported by gdkpixbuf and then some). Another thing mentioned is the one to one mapping between loader and image format which is bad then then saving images (even if the loader can distinguish between different variants then loading it does nothing for saving). A suggested solution (read ugly hack) was to duplicate all of the code for each format (or create a library which is called by a small wrapper for each format). But that is obviously not an optimal solution. I did't find anything about this in bugzilla. But I'll wait with filing a bug until I know if there is a plan already. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- 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: Memory-buffer only port?
It'd probably be easier to just install Xvfb: http://en.wikipedia.org/wiki/Xvfb 2008/5/16 Joshua Chia [EMAIL PROTECTED]: I'm trying to use the GTK port of WebKit to render web pages to image files. This normally would involve a simple hack, but I'm running this on a Linux system that has no X11 or DirectFB. Is there a port of GTK that only uses a simple memory buffer without any hardware support? If not, could anyone give me an idea of how much work I should expect to do for making such a port and roughly which areas I would need to work on? Josh ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- 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: Move to LGPL3
On Tue, Mar 18, 2008 at 8:46 PM, Mark Mielke [EMAIL PROTECTED] wrote: 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 There's no explicit reference to the Windows API in the GPL or LGPL, but there's an important clause in both the GPLv2.0 and LGPL2.1: 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. In this case, the Windows API and DirectX would be considered normally distributed major components of the operating system, and thus be ok to use in a L/GPL licensed work. Dom ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Move to LGPL3
This is open to interpretation - but the exact wording of the license does not necessarily match the legal rights a person has in terms of copyright law, and the ability for a copyright to limit the use of the product. In my opinion, the special exception is not part of the license, but stating the obvious. I don't believe the GPL can stop me from linking with non-GPL software, as long as I don't distribute my change as a derived work. Copyright law is about distribution rights. Indeed it is. But I, an application vendor, shipping an EXE of GPL'd licensed software (let's call this product AbiWord) that's linked to the Microsoft C runtime is most certainly a distribution. And it most certainly is a derivative work of the MSFT C runtime. The GPL says that, in this case, I'm only responsible for providing you the source code to my application, and not the source to the MSVCRT. The GPL (and not only the MSFT EULA license, as you claim) can and indeed does dictate if and how you can derive from another work *if you choose to distribute the resulting work.* That's why the GPL compatibility matrix exists, why there are 20 implementations of SSH, and why we're having this LGPL 3 discussion. The GPL's exception clause isn't superfluous, as you claim. It doesn't mention you linking something on your own machine without distributing it. You're correct - as a distribution-based license, it doesn't have to. The clause is directly targeted at the distribution of Free software works on non-Free operating systems. So yes, this exception is important and necessary, it is a special case, and it does (without mentioning Microsoft specifically) address the case of whether you can use Microsoft's APIs in your GPL'd program. 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
* 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
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
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
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
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
Image saving framework
Hi, Arc and I are writing a GdkPixbuf plugin that wraps Window's GDI+ library. This library supports loading and saving a variety of formats, such as PNG, JPEG, GIF, WMF, EMF, TIFF, ... I'd like to implement saving to PNG/JPEG/whatever from the plugin. GdkPixbuf's architecture allows you to handle multiple formats in the same plugin. Unfortunately, the GDK_PIXBUF_FORMAT_WRITABLE flag means that all of your formats are writable. Worse still, GdkPixbuf assumes that a plugin is only capable of saving to a single format, so it doesn't bother passing that format to the plugin's save function. Is there time to change the plugin API? Otherwise, each format capable of being written to will need its own plugin. Of course, these will be shallow wrappers around shared functionality, but it's annoying to say the least. Dom ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
API/ABI break request
The GdkPixbuf simple animation class implementation [1] uses an internal iterator type. Unfortunately, the GObject type instantiation function accidentally was placed in the header file instead of being a static function in the source file. Johan noticed a crash in the new defaultvaluetest when the iter's finalize vfunc was called. The iter was created via g_object_new(). This function/type should have never been public. The only way to get a valid iter is to use the animation class' get_iter() vfunc. So, what should we do? Some options: 1) Work around the crash (which can only happen if you instantiate one of these via g_object_new()) 2) Remove this from the public API/ABI and pretend it never happened 3) Keep the function, but make it return G_TYPE_INVALID, and rename the function internally I'd vote for #2. There's precedent for breaking API/ABI, and there was no way anyone ever created and successfully used one of these iters via g_object_new(). If you did this, your program would crash. Thanks, Dom 1: http://svn.gnome.org/viewvc/gtk%2B/trunk/gdk-pixbuf/gdk-pixbuf-simple-anim.h?view=markup ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: File plugin with c++
Hi, Is it possible to write a file plugin like gdk-pixbuf/io-jpeg.c in c++? Yes. The problem is openexr expects a char* for it's constructor and gdk works with FILE. That doesn't have anything to do with C++ AFAICT. The GdkPixbufLoader also has a push API, where a stream of bytes is sent to the loader. The SVG loader uses this API instead of the file-based one. Eg. http://svn.gnome.org/viewvc/librsvg/trunk/gdk-pixbuf-loader/io-svg.c?revision=1136view=markup If openexr doesn't have a way to load an image from a stream of bytes, you could always serialize the bytes to a temporary file and then load that. Dom ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVfs status report
The issue is that file descriptors shouldn't be passed from a dll / exe using one C runtime to another using a different C runtime -- or if they are, they must be used only with functions from the appropriate C runtime. Use of file descriptors within a single dll is generally not a problem. That's correct, and a major complaint of people using gstdio's g_fopen() routine. The native win32 calls (CreateFile and others) probably has advantages, but I can't say whether a separate implementation would be desirable. As best as I can tell, most of stdio is just shallow wrappers around the native Win32 API. A major discrepancy (as I've said before) is that Windows places an artificial limit of 2k FILE*s or fd_ts per process. Wine even goes so far as to duplicate this madness. By not using the Win32 CreateFile/OpenFile functions, you unintentionally limit how many open files a user of your library might have. This comes up more than you'd think in real life. For example, here's a bug against Sun's JVM reported against JDK 1.1 and not fixed until JDK 1.5: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4189011 Cheers, Dom ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVfs status report
Hi Alex, On 9/14/07, Alexander Larsson [EMAIL PROTECTED] wrote: On Thu, 2007-09-13 at 14:12 -0400, Havoc Pennington wrote: Hi, There's a lot of code to absorb here, a minor comment, I might expect GUnixFileInputStream/GWindowsFileInputStream rather than GLocalFileInputStream. Well, the same class is used on both unix and windows. Its the implementation of native files, and I don't see any need to split it out really. What differences would there be between the two? Well, we'd probably want at least a Win32 implementation in terms of the native Windows file API. Windows limits the number of FILE*s or fd_ts to 2048 per process. The only way to get around this limitation is to use the native API. Cheers, Dom ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wimp tab rendering patch
I committed a similar patch yesterday. It was bug #403470. Dom On 4/20/07, Arnaud Charlet [EMAIL PROTECTED] wrote: Sorry, I overlooked this message until now and just found your latest patch. I will review this patch really soon, and if it looks okay I'll get it committed to svn. Thanks a lot! BTW, did you see my message (and the follow up) on http://bugzilla.gnome.org/show_bug.cgi?id=399253 ? Comment #9 from charlet act-europe fr (points: 11) 2007-04-19 10:31 UTC [reply] There's still a memory leak in the case of e.g. Windows Classic style, fixed by the following patch: --- msw_style.c.old +++ msw_style.c @@ -2541,6 +2548,9 @@ draw_extension (GtkStyle * style, HDC dc; gint32 aPosition; + if (real_gap_side == GTK_POS_BOTTOM) + g_object_unref (pixmap); + dc = get_window_dc(style, window, state_type, x, y, width, height, rect); if (real_gap_side == GTK_POS_TOP) Could someone apply it ? Arno Comment #10 from Daniel Atallah (reporter, points: 8) 2007-04-19 14:29 UTC [reply] The fix for comment #9, and an additional fix for the LEFT/RIGHT tabs is in Bug #403470. Arno ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- 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: GtkCanvas requirements?
So does Gtk want to reduce themeing and just have a simple file that specifies colors (like Metacity) or does it want to increase its features to allow stuff such as allowing theme engines to do animations, fades and what do I know? If we care about looking native on Win32 and OSX, I'd say that rules out the simple file that specifies colors approach. Dom ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Adding support for OS X icons in GDK-Pixbuf
Hi Lyonel, What do I have to make GTK+ applications recognise icns files? WMF and SVG support seem to suggest developing a GDK-Pixbuf loader. I co-authored both of those loaders, so hopefully I can help you. I've tried to create a shared lib modeled after io-wmf.so (in libwmf) but without much success so far: when I run gdk-pixbuf-query-loaders I get: When you installed the loader, did you run gdk-pixbuf-queryloaders and overwrite the existing gtk-2.0/gdk-pixbuf.loaders file? Here's an example from librsvg: http://cvs.gnome.org/viewcvs/librsvg/gdk-pixbuf-loader/Makefile.am?rev=1.13view=markup Please follow-up privately off-list, as this is probably a more appropriate question for the gtk-app-devel forum. Thanks, 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: What about official GTK+ installer for win32?
I think that the situation is much better than people here are making it out to be. Or, at least that's been my experience. I have Gaim, Gimp, Gnumeric, Glade-3, Workrave, gQview, and Xchat all using the same GTK+ runtime on WinXP, and they all work flawlessly. As far as I know, nothing gets installed into system/system32 - GTK+ gets installed into its own prefix, sets some registry keys, and things subsequently just work. With this approach, Win32 application developers can focus on shipping their own software and not worry about shipping a messy dependency. If GTK+'s installation was more like QT (i.e. you can link in a static qt.lib to your program or ship qt.dll and be done with it), I might have a different opinion. Best, Dom On 10/26/06, Tor Lillqvist [EMAIL PROTECTED] wrote: Michael Lawrence writes: Modular systems are simply easier to maintain. When said modules are maintained by people who have never heard of each others, and with different ideas what the modular system is? I feel that a sophisticated package management system for Windows is a must for open-source to become mainstream on Windows. Well, *some* open-source software is quite mainstream on Windows already, like Firefox. And you don't see Firefox attempting to share installations of stuff like libjpeg, libpng, zlib etc DLLs, even though they for sure use them. They just build them in. Of course, the construction and maintenance of such a system would be a monumental task and far beyond the scope of GTK+. Indeed. Not to mention the clout required to convince other developers/maintainers then to use such a system. I really wish Microsoft would come up with a package management system for 3rd-party software on Windows... Windows Installer technology is monumentally powerful and complex, but it answers the wrong question, I think. --tml ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- 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: What about official GTK+ installer for win32?
Maybe you got lucky, and didn't install anything that dumps shared DLLs to System32. And you know how to get those applications to behave next to eachother. Typical end-user doesn't. The funny thing is that both you and Tor assumed that I did something special that a normal end-user couldn't do. I assure you that no magic was involved. All I did was install GTK+ first (usually gladewin32), and then install versions of Gaim, Gimp, etc. that had no-gtk in their filename. And that's all. My experience leads me to believe that we'd benefit from an official installer that didn't dump crap into System32 and for maintainers not to include GTK+ in their installers. At that point, I don't look any different than a typical end-user. Best, 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: GRegex
Hi Marco, Please take my review with a grain of salt. I've been wanting a convenience API on top of PCRE for a while now, and it would be great if we could get something like GRegex into Glib proper. 1) Please don't name variables 'string', as there may be a conflict with C++'s std::string 2) I noticed that there are g_regex_ref/unref() methods. Why did you choose to do this, rather than subclass GObject? You would also then have easy GObject-style accessors for the regex's pattern and match_options. 3) Should there be a GRegexMatch object too? For instance, at least Python and Java have a notion of a read-only Pattern and a Match Set. Your design combines the two into a single GRegex object. Having the pattern be read-only gets around your thread-safety gotcha comment in the docs. 4) Python's search() and match() methods have a start position and an end position argument, while your match_full() has only a start position argument. Is there a reason for this? Could it be implemented? 5) I didn't fully investigate, but Java and Python have a concept of search vs. match with slightly different semantics. Is this semantic distinction easily expressible in your API? http://docs.python.org/lib/re-objects.html 6) GRegex requires that PCRE be built with UTF-8 support, which some existing installations aren't. For reference, Gnumeric and Goffice get around this by including a copy of PCRE in their distribution and statically link it in. How do you ensure that GRegex finds a version of PCRE compiled with UTF-8 support? Thanks, Dom On 10/24/06, Marco Barisione [EMAIL PROTECTED] wrote: As discussed some times ago [1] I propose to add a PCRE wrapper to GLib. Bug #50075 [2] contains a patch that adds it as a separate libgregex. The documentation of the new API is at [3] (yes, there are some unresolved problems with gtk-doc). Owen Taylor would prefer to have GRegex directly in the main GLib library: (17:38:55) owen: is the latest plan for gregex really a separate library? (17:39:45) mclasen: owen: you would prefer it folded in ? (17:40:16) owen: mclasen: I think it makes tons more sense folded in. A regular expression facility is most useful if you can just use it when you need it (17:40:36) owen: mclasen: And on the desktop, having it folded in is purely a performance win (17:41:36) owen: if there is an embedded problem (how big is it anyways?) then a --without-regex configure option would be better (17:43:19) mclasen: owen: you are probably right What are your ideas? I would like to add to the documentation a simple and short tutorial on regular expressions and GRegex API. Does someone know something good (and with a compatible license) to copy? [1] http://mail.gnome.org/archives/gtk-devel-list/2006-July/msg00099.html [2] http://bugzilla.gnome.org/show_bug.cgi?id=50075 [3] http://www.barisione.org/gregex/ -- Marco Barisione http://www.barisione.org/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- 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: GRegex
On 10/24/06, Behdad Esfahbod [EMAIL PROTECTED] wrote:
On Tue, 2006-10-24 at 16:05 -0400, Marco Barisione wrote:
If you prefer you can pass --enable-system-pcre to use the
system-supplied library but, if it's compiled without utf-8 support,
g_regex_new fails.
This is broken. It should err at configure time, not run time. The
user shouldn't need to check the output of g_regex_new for failures,
just like any other thing we do with glib.
It should be possible to write an auto* check that basically checks
whether something like:
#include pcre.h
int main(int argc, char ** argv) {
int has_utf8_support;
if(pcre_config(PCRE_CONFIG_UTF8, has_utf8_support))
return has_utf8_support;
return 0;
}
returns '1' or '0'. If so, we should probably favor the system
installation of PCRE over the glib-supplied one.
Best,
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: gdk event function
Please read the documentation. GdkEvent* gdk_display_peek_event (GdkDisplay *display); http://developer.gnome.org/doc/API/2.0/gdk/GdkDisplay.html#gdk-display-peek-event On 9/14/06, news.gmane.org [EMAIL PROTECTED] wrote: Is there gdk function, which checks (only peeks) for certain event on certain display? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- 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: Design decisions for GLib and GTK+ on Win32
I don't know much about win32 or GTK+ on that platform, but my uninformed vote is yes on all counts, too. Thirded. -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: Gtk Printing and evince
Hi Carlos, In evince we have the document pages already rendered, so can I take the pixbuf of the page and create a cairo surface from it and use it in draw_page signal? I don't know if this is the right way to do it. Unless rendered at a high resolution, the output will probably look pretty ugly and be much larger than strictly necessary. Since poppler has a Cairo rendering backend and the GtkPrintContext pipeline is built around cairo, it'd probably be better to do something like this pseudo-code: cairo_t = gtk_print_context_get_cairo(context) for page in document.pages: poppler_page_render(page, cairo_t) Best, 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: Problem with preview and the blocking print dialog
This was my original thought but Matthias and others suggested this. One of the issues with cairo is that we would have to either run through the drawing commands on every expose event or save out to a bitmaps surface which would remove the ability to zoom. The other option is to recreate evince in gtk+. That is not going to happen. Or convince Carl to make the meta surface a public API before 1.2 hits the streets, and make whatever improvements are necessary for that to happen. That's essentially what GnomePrint does, anyway. Best, 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: [Win32] Great enhancement of native look feel for gtk+ win32. (with patch files)
I haven't personally reviewed the patches yet but you mention changing the color and look of a few widgets. Will these changes still work if the theme is switched from the normal luna theme to one of the other luna themes in windows XP? Do they pull in the appropriate values from the Microsoft theme engine dll? WIMP has always pulled in the appropriate colors from Windows. And it has always used Microsoft's theming API, which means that it works with all of the Luna themes and should work fine with 3rd-party themes. 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: graphics using GTK+
You might want to check out the GOffice graphing library. Gnumeric and GnuCash both use it. cvs co goffice from Gnome's CVS. Best, Dom On 4/3/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi!! I've a problem to solve... I need to graph some points in a graphic using GTK+. And after graph them,i need to can delete some of the points. How can i do?? thanks ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- 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: GTK+ Mac OS X state of the union
I'm sorry for what may be a stupid question. Why do we need a bridge API (assuming that there's a 1:1 mapping between Cocoa and GTK+ menus) if we're already putting the onus on developers to: 1) Modify their menus to conform to MacOS style guidelines, including putting entries into special menus (e.g. the Apple menu), which don't have a GTK+ equivalent 2) Call GTK+-MacOS specific APIs to inject the menus into the OSX menu bar 3) Call #2 at appropriate times when different windows get focus (e.g. the Gimp) Wouldn't it be preferable for the developers to just use the Cocoa menu-creation APIs directly? If we were talking about some shim that automatically takes any focussed window's GtkMenuBar and injects it into the OSX menu bar, that might be different. Or if we had the equivalent of Qt's QMainWindow, that might be ok too. But (afaik) we're not talking about that. Best, Dom On 3/28/06, Michael L Torrie [EMAIL PROTECTED] wrote: On Tue, 2006-03-28 at 11:44 -0500, John Ehresman wrote: A separate api is probably needed. OS X applications can and should display menu bars when no top-level windows are open. Also the preferences, quit, and possibly other items should be on the menu with the applications name on it instead of the file menu. Since preferences and even quit could be anywhere, the app developer would have to create a mac-specific GtkMenu object that followed the OS X guidelines and then throw that up. I think putting the burden on the developer in this thing isn't too bad. The Gtk main routine could even be patched to display the initial application menu (with its name). The developer would then put assemble the rest of the menu and throw it up with this API. I haven't done any development work on GTK itself since the 1.2 says, so I can't really say how the best way to actually implement any of this is. What do any GTK developers think of a small API to bridge this gap? I'm assuming that the goal is an application that looks feels as native as possible and not to replicate the X11 / gnome look feel. Both are reasonable goals, but I suspect that more OS X users want native look feel. A good start is a normal OS X menu bar. Then work on the look and feel of the actual application windows. A long time down the road too, modal dialog boxes could be implemented OS X-style, sliding out the title bar of the parent window. If somehow GTK became a first-class OS X developer toolkit, I think that would be wonderful. I'm not clear if GTK for OS X is using carbon or cocoa for drawing. Carbon is easiest to use from C, but Cocoa is better in the long run (handles OS X-isms like Command-clicking unfocused windows and scrolling better). Is it possible to build gtk for native OS X via jhbuild? John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- 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: Re g_error() in g_private_new_win32_impl
Hi Tor, BTW, the pthreads-win32 POSIX thread implementation from http://sourceware.org/pthreads-win32/ just uses native thread-local storage slots as allocated by TlsAlloc() in its implementation of pthread_key_create(). The number of those is 1088 per process in Windows 2000 and newer, and under 100 in Win9x. Maybe gthread-win32 should do the same. On the other hand, instead of thus rewriting significant parts of gthread-win32.c, maybe it would make sense to simply start using the pthreads-win32 implementation underneath, i.e. use gthread-posix.c on Windows, too? FWIW, my company makes heavy use of pthreads-win32 in our server products without any issues. It just works. They ship 4 DLLs - GCC, MSVC, GCC+SEH, MSVC+SEH (SEH = structured exception handling). If we decided to use this, we'd probably want to use the non-SEH version, as that bit isn't portable across pthreads implementations or across GCC/MSVC compilers. The authors also recommend against using SEH for these reasons. AFAIK, the GCC/MSVC non-SEH DLLs are binary compatible with each other; they're just built using different compilers. http://sourceware.org/pthreads-win32/faq.html The library is actively maintained, FOSS, has gotten a lot more attention than gthread-win32.c (especially, as Tor mentions, with respect to corner cases), and could piggy-back on glib's robust gthread-posix implemenation. pthreads-win32 seems to be much more carefully written than gthread-win32, for instance the recently fixed problem related to the details of GPrivate destructor calling wouldn't have happened with pthreads-win32. Using it would mean one more external dependency, though, although it's just one DLL at run-time. Adding one more DLL to the Win32 GTK+ installers shouldn't be an issue. gladewin32 ships with at least 52 DLLs in its bin directory alone, for instance. This includes iconv, intl, zlib, bz2, charset, gettext, asprintf, and other glib/gtk dependencies. Best, 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: Rich Text copy and paste (bug #324177)
On the Windows platform (as an example), there are standards for richtext interchange between applications. Those standards are RTF and to a lesser (but growing) extent, (X)HTML. You'll find that a lot of the more richtext copy+paste centric apps on Linux and MacOS also commonly use these interchange formats. Applications like MSIE, Outlook, Office, Mozilla, Evolution, AbiWord, etc. will offer their selections in these formats and copy+paste between them can be said to work fairly well. These are applications that know how to serialize and deserialize their data Model. If these applications encounter some semantic that their data Model can't handle, they have already assumed responsiblity of the data and will fall-back or transform that data as is necessary. The Model will never be in a state that is inconsistent with what its View or Controller can respresent. In his simple MUA example, Mitch proposes that perhaps there is a class of applications where the Model and View are considerably smarter than the Controller. GtkTextView is pretty smart, I'll grant you, but all of its data must have come from somewhere. The application feeding the TextView data must have a mapping from that data's model into the TextView's model. And the inverse must be true for deserialization. Consider the primary ways that a user will get data into a MUA: 1) Typing it herself, interacting with the MUA's controls 2) Displaying a previously sent email (either by itself, or in a reply-to form). This email may have come from a smarter MUA, and thus need to be dumbed-down for viewing or editing. 3) A distant third is pasting between MUA message windows. Since the data came from another window in your application, it is probably safe to assume that this data is already in a format that your MUA understands. I contend that this shows that Mitch's example MUA would necessarily be smart enough to filter out the bits of HTML it doesn't understand for viewing. It must also be smart enough to serialize the TextView into a HTML syntax that it does understand when sending. It's not hard to make the leap from serializing all of a message when you click Send to serializing a subset of the message when you hit copy. Similarly for recieve vs. paste. In these cases, the MUA doesn't need (or even want) the TextView to do anything on behalf of it. Applications should not blindly use GtkTextView blindly as both their Model and their View. Any app that does this probably deserves whatever wonky results they get. Mitch's tagset attempts to strike a middle-ground, but I don't think that a middle ground is what we should seek. The tagset attempts to brute-force filter some semantics that aren't handled by an application. Think I don't support bold text. But it can't handle more complex scenarios, such as I don't handle tables inside of tables or I handle bold text and italic text, but not bold, italic text. But filtering may not be what you want. One might want to tranform a HTML table into an ASCII-art one, or a bullet/numbered list into asterisks/numbers plus some tabs. The tagset as proposed can't capture even these simple semantics. In doing so, it proposes to use yet another interchange format that is specific to GtkTextView. Unless more common formats are offered AND accepted or a clipboard manager does conversion, copying and pasting richtext between applications is in the same sorry state that it is today. This is especially true for inter-toolkit cases. I can't see a tagset-based approach working for anything but the most contrived examples. And I don't see that as preferable (or even easier) than having the application filtering the data itself as it must already be doing elsewhere. With that said, I think that the best course of action is to keep this sort of application-style logic out of the TextView, and push the onus onto the apps that would use it. My ideal setup would probably be: *) The TextView can serialize and deserialize (a selection of) itself into UTF-8 text, for the common copy + paste semantic. *) Applications are responsible for serializing and deserializing the text view into more complex formats, such as RTF and XHTML. Push any smarts up to the application level rather than the widget level, since the application should have control over its Model, and not the other way around. *) If it is felt to be necessary (and I'm not convinced that it is), there can be an opt-in serialization/deserialization API for several of these more-common interchange formats, such as XHTML and RTF. These must be optional, since they mustn't compete with their parent applications for control of the interchange atoms on the clipboard. Best, 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: Rich Text copy and paste (bug #324177)
Hi Matthias, *) The TextView can serialize and deserialize (a selection of) itself into UTF-8 text, for the common copy + paste semantic. Sure, it does that already. Yup, I'm fully aware. *) Applications are responsible for serializing and deserializing the text view into more complex formats, such as RTF and XHTML. Push any smarts up to the application level rather than the widget level, since the application should have control over its Model, and not the other way around. This is what mitch's gtk_rich_text_register() api does, more or less: it gives apps a way to register functions for serializing and deserializing text buffer content into different formats. If that's all it did, I wouldn't have a problem with it. *) If it is felt to be necessary (and I'm not convinced that it is), there can be an opt-in serialization/deserialization API for several of these more-common interchange formats, such as XHTML and RTF. These must be optional, since they mustn't compete with their parent applications for control of the interchange atoms on the clipboard. mitch's current patch just provides an internal format, but I think we would be happy to include XHTML and RTF format support if patches appear... So, it seems your recommendations are fairly close to what mitch's patch already provides. Or did I miss your critcism of the tagset mechanism somehow ? I think that you missed my point completely. So let me restate it, hopefully more clearly: *) I think that Mitch's data model incompatibility problem is a very real one that needs to be addressed. *) I think that the tagset metaphor is too primitive to do anything genuinely useful with and we will be butting our heads up against that wall *very* quickly. *) Richtext copy + paste should be handled *only and entirely* by the app that owns the GtkTextView, and not the GtkTextView itself, because only the application necessarily knows what its data model can represent. Combine this with the limitations evidenced by my previous point to get the full effect. The fact that some applications might use GtkTextView as both their Model and View is confusing the situation. The app and only the app needs to have fine control over what goes into the Model. It - not the GtkTextView - is the Controller. This should be solely the application's responsibility, and not part of the GtkTextView API. *) I think that if we want to provide convenience functions for serializing/deserializing common formats, then that's great. But I don't think it is necessary, nor do I think that a subsetting/translation mechanism such as the one that Mitch proposes has any business being anywhere near the serialization API or GtkTextView. *) I think that tagsets are the wrong approach for solving this problem. As such, I think that richtext copy+paste facilities should be something layered on top of the GtkTextView by the parent application and not be a builtin feature of the TextView itself. The application knows in detail what its data model and controller supports. The TextView does not, and should remain dumb in this regard. Best, -- 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: gtkspell (was Re: Announcing: Project Ridley)
On 1/19/06, Matthias Clasen [EMAIL PROTECTED] wrote: On 8/27/05, Chipzz [EMAIL PROTECTED] wrote: I'm not a Gtk+ developer, but I think one of the criteria for being considered is: doesn't introduce a new library dependency, or maybe it can, if it really makes sense. Gtk+ depending on a spell checking library hardly makes sense, however. I would envision a solution having two parts here: - some framework in GtkEntry/GtkTextView to support spellchecking - a module which makes use of the framework. The module could use Enchant, GtkSpell or any other spell-checking library - the module could be loaded desktop-wide, by using the gtk-modules setting that was introduced for this purpose a while ago. Enchant has been API/ABI stable for a while now, so I wouldn't mind proposing it for inclusion to the platform at some future point (or better still, free desktop). Chris Hammond's libsexy has a spell checking enabled GtkEntry subclass that depends on Enchant. It dlopen()'s the .so and looks up the functions by name rather than linking against it explicitly. If the module isn't found, spell checking is disabled. This might be something of a compromise solution, since it gives consumers a soft dependency on a spell checking lib rather than a hard dependency. Best, Dom ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
