Re: g_malloc overhead
Paul LeoNerd Evans escribió: On Sun, 18 Jan 2009 17:43:57 +0100 Martín Vales mar...@opengeomap.org wrote: Other overhead i see is the open dir/file funtions, where in windows we need do the utf8 to utf16 everytime in windows. If JAVA,.NET and Qt use utf16 by default why in gnome world we use utf8 by default?. Probably one of the biggest reasons, is that UTF-8 does not use \0 octets, whereas UTF-16 does. This means that UTF-8 data can transparently pass through all of the usual str*() functions in C, such as strlen(), strcpy(), etc... I can see the advantages of use utf8 but the true it´s most of people use utf16. I know gnome/linux/cairo/freedesktop promote utf8 but most people use utf16: http://unicode.org/notes/tn12/#Software_16 Regards. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_malloc overhead
Martín Vales wrote: I can see the advantages of use utf8 but the true it´s most of people use utf16. I know gnome/linux/cairo/freedesktop promote utf8 but most people use utf16: http://unicode.org/notes/tn12/#Software_16 This is a very baseless claim. One that actually turns out to be false. Most people don't right Windows code. Most people read and write content on the internet, and I bet more than 99% of the Unicode content on the net is in UTF-8. As for the technical note you cite, it's a very biased document of its own. I once wrote a full critical review of it but can't find it. Lets just say that UTF-16 is at best implementation details of Firefox. I can't see how that can be relevant here. Moreover, it's plain wrong that Python uses UTF-16. Python APIs are encoding-agnostic, and while Python 2.x can be compiled with UCS-2, it's recommended that UCS-4 be enabled. And note the difference: I said UCS-2, not UTF-16. UTF-16 is a disease. It's variable-width, so it doesn't have the benefits of UTF-32. It's sixteen bit, so it doesn't have the ASCII-compatibility of UTF-8. Tell me one good thing about it other than everyone made the mistake of using it and now they have to keep doing that because they exposed it in their API. behdad ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_malloc overhead
On Mon, Jan 26, 2009 at 9:12 AM, Behdad Esfahbod beh...@behdad.org wrote: Lets just say that UTF-16 is at best implementation details of Firefox. Well, JavaScript is notably UTF-16. Given that the Web, Java and .NET (i.e. all the most important platforms) are all UTF-16 it's likely to be with us for quite a while, so it's important to understand. But yeah, there's no way POSIX/GNOME etc. could switch even if it made sense to do so (which it clearly doesn't). ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkTreeModel / GtkTreeStore for big models
Hi I am currently developping a model browser for a car crash application. I am using GTK2.12 to populate all the objects that are in my car crash model. For this I used the standard GtkTreeModel / GtkTreeStore design pattern. When the model is becoming really big (more than 250 000 objets ie 250 000 rows) the tree management (populating the rows, expanding rows, collapsing rows, ) takes too much time to be used.. Does anybody know how to speed up GtkTreeModel for a large number of rows? Or is it a better idea to write my own implementation of the GtkTreeModel Interface? (cf. for example chapter 11 in http://scentric.net/tutorial/treeview-tutorial.pdf In this topic, it is said that by reimplementing the GtkTreeModel Interface, I could have better results.) Thanks Christoph ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_malloc overhead
Colin Walters escribió: On Mon, Jan 26, 2009 at 9:12 AM, Behdad Esfahbod beh...@behdad.org wrote: Lets just say that UTF-16 is at best implementation details of Firefox. Well, JavaScript is notably UTF-16. Given that the Web, Java and .NET (i.e. all the most important platforms) are all UTF-16 it's likely to be with us for quite a while, so it's important to understand. Yes i only wanted say that. For example i work in c# and i would like create glib libraries and use it in .net, but the char in mono/.NET is utf16 and therefore i have there the same overhead. The solution are 2: 1.- conversion using glib (): http://library.gnome.org/devel/glib/2.19/glib-Unicode-Manipulation.html#gunichar2 .-2. automatic NET conversion in the p/invoke side. The 2 solutions have the same overhead. But yeah, there's no way POSIX/GNOME etc. could switch even if it made sense to do so (which it clearly doesn't). Yes, i only talked about the overhead with utf8 outside of glib, only that. Perhaps the only solution is add more suport to utf16 in glib with more methods. Regards. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_malloc overhead
On Mon, 2009-01-26 at 18:30 +0100, Martín Vales wrote: Colin Walters escribió: On Mon, Jan 26, 2009 at 9:12 AM, Behdad Esfahbod beh...@behdad.org wrote: Lets just say that UTF-16 is at best implementation details of Firefox. Well, JavaScript is notably UTF-16. Given that the Web, Java and .NET (i.e. all the most important platforms) are all UTF-16 it's likely to be with us for quite a while, so it's important to understand. Yes i only wanted say that. For example i work in c# and i would like create glib libraries and use it in .net, but the char in mono/.NET is utf16 and therefore i have there the same overhead. The solution are 2: 1.- conversion using glib (): http://library.gnome.org/devel/glib/2.19/glib-Unicode-Manipulation.html#gunichar2 .-2. automatic NET conversion in the p/invoke side. The 2 solutions have the same overhead. But yeah, there's no way POSIX/GNOME etc. could switch even if it made sense to do so (which it clearly doesn't). Yes, i only talked about the overhead with utf8 outside of glib, only that. Perhaps the only solution is add more suport to utf16 in glib with more methods. There's zero point in talking about a solution until you have profile data indicating that there is a problem. - Owen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_malloc overhead
Martín Vales mar...@opengeomap.org writes: Colin Walters escribió: On Mon, Jan 26, 2009 at 9:12 AM, Behdad Esfahbod beh...@behdad.org wrote: Lets just say that UTF-16 is at best implementation details of Firefox. Well, JavaScript is notably UTF-16. Given that the Web, Java and .NET To be honest - aren't web currently XML-based (XHTML co.)? And isn't UTF-8 default encoding, and acidentally the most widly used, for XML? But yeah, there's no way POSIX/GNOME etc. could switch even if it made sense to do so (which it clearly doesn't). Yes, i only talked about the overhead with utf8 outside of glib, only that. Perhaps the only solution is add more suport to utf16 in glib with more methods. Well - what do you mean? Having 2 functions - one reciving utf-16 and one utf-8? To be honest - it doesn't make any sense to me (it would create much mess, double the code, make programming errors easier...). Converting? What's wrong with g_utf16_to_utf8? Regards -- I've probably left my head... somewhere. Please wait untill I find it. Homepage (pl_PL): http://uzytkownik.jogger.pl/ (GNU/)Linux User: #425935 (see http://counter.li.org/) ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_malloc overhead
hi: Well - what do you mean? Having 2 functions - one reciving utf-16 and one utf-8? To be honest - it doesn't make any sense to me (it would create much mess, double the code, make programming errors easier...). Converting? What's wrong with g_utf16_to_utf8? I was talking about a full utf16 and utf8 api in glib and use a macro to work work intermediate string: For example in windows they have this types: LPSTR =char * LPWSTR= utf16windowschar * ... and: LPTSTR type. If we defined the _UNICODE macro is LPWSTR else LPSTR . ,...after they have a full api to manage utf16 and ansi strings, (strcat, strcpy, etc), http://msdn.microsoft.com/en-us/library/h1x0y282.aspx ... and finally macros to use string in the same way _TEXT _T, etc. _TEXT(are you defined _UNICODE macro?. Perhaps i am ansi or perhaps utf16) http://msdn.microsoft.com/en-us/library/dd374074(VS.85).aspx http://msdn.microsoft.com/en-us/library/dd374074%28VS.85%29.aspx perhaps in glib we could have utf16 and utf8 in that way or am i wrong? Regards. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_malloc overhead
Maciej Piechotka escribió: On Mon, 2009-01-26 at 22:30 +0100, Martin (OPENGeoMap) wrote: hi: Well - what do you mean? Having 2 functions - one reciving utf-16 and one utf-8? To be honest - it doesn't make any sense to me (it would create much mess, double the code, make programming errors easier...). Converting? What's wrong with g_utf16_to_utf8? I was talking about a full utf16 and utf8 api in glib and use a macro to work work intermediate string: For example in windows they have this types: LPSTR =char * char * is used for utf-8 AFAIR LPWSTR= utf16windowschar * gunichar2 perhaps in glib we could have utf16 and utf8 in that way or am i wrong? I'm not glib developer. As far as the module of operating on utf-16 strings is proposed I'm not against. However I would prefere to not have 2 entries to each function. Hi: What is wrong with: gchar* g_utf8_strncpy (gchar *dest,const gchar *src,gsize n); gunichar2 * g_utf16_strncpy (gunichar2*dest,const gunichar2*src,gsize n); and the macro: gtext* g_text_strncpy (gtext*dest,const gtext*src,gsize n); regards. Regards Regards. ___ 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
Maciej Piechotka escribió: On Mon, 2009-01-26 at 22:49 +0100, Martin (OPENGeoMap) wrote: Maciej Piechotka escribió: On Mon, 2009-01-26 at 22:30 +0100, Martin (OPENGeoMap) wrote: hi: Well - what do you mean? Having 2 functions - one reciving utf-16 and one utf-8? To be honest - it doesn't make any sense to me (it would create much mess, double the code, make programming errors easier...). Converting? What's wrong with g_utf16_to_utf8? I was talking about a full utf16 and utf8 api in glib and use a macro to work work intermediate string: For example in windows they have this types: LPSTR =char * char * is used for utf-8 AFAIR LPWSTR= utf16windowschar * gunichar2 perhaps in glib we could have utf16 and utf8 in that way or am i wrong? I'm not glib developer. As far as the module of operating on utf-16 strings is proposed I'm not against. However I would prefere to not have 2 entries to each function. Hi: 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 gunichar2 * g_utf16_strncpy (gunichar2*dest,const gunichar2*src,gsize n); That's kind of support I'm not against. and the macro: gtext* g_text_strncpy (gtext*dest,const gtext*src,gsize n); regards. With the entries - nothing. With macro - it may be just me but I percive it shooting into foot. Just imagine that some header will assume gtext to be utf-8. Other will turn on the macro (or user code) and change it to utf-16. IMHO - having magic switch which might change the ABI is not good. Regards ___ 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
Dominic Lachowicz escribió: 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. 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. Regards. ___ 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
Martin (OPENGeoMap) wrote: Dominic Lachowicz escribió: 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. 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. You are still to show us where this becomes a bottleneck. This does not make any sense in glib. I've been thinking about possibly adding UTF-16 and UTF-32 APIs to Pango, and that makes more sense when interfacing with other apps. But I've kept the macro idea just for my internal implementation in Pango, not as crack to be put in public header files. behdad Regards. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GTK+ 2.15.2 released
GTK+ 2.15.2 is now available for download at: http://download.gnome.org/sources/gtk+/2.15/ gtk+-2.15.2.tar.bz2 md5sum: 1c230eeb1bf24b69b480d0a35da34794 gtk+-2.15.2.tar.gz md5sum: 1e9d42fb6bdfb6752a82f6c3afc3b3e7 This is another development release leading up to GTK+ 2.16. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GTK+. If you have problems, you'll need to reinstall GTK+ 2.14. * GTK+ 2.16 will be source and binary compatible with the GTK+ 2.14 series. The API additions in GTK+ 2.15 are finalized at this point, only minor API changes are expected to happen between 2.15.2 and 2.16. * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html http://www.gtk.org/faq/ Contributing GTK+ is a large project and relies on voluntary contributions. We are actively searching for new contributors in various areas and invite everyone to help project development. If you are willing to participate, please subscribe to the project mailing lists to offer your help and read over our list of vacant project tasks: http://live.gnome.org/GtkTasks Overview of Changes from GTK+ 2.15.1 to 2.15.2 == * GtkAction: - Make toolitems pick up icon names from actions - Draw proxies of radio actions properly - Make menu proxies of recent actions work - Avoid accidental activations when changing actions on proxies - Make derived button classes work as proxies * Input methods: - Avoid an assertion due to early use of input methods * GtkScale: - Avoid a segfault in the marker drawing code * GtkImageMenuItem: - Add a property to override the show-menu-images setting * Bugs fixed: 566628 gdk_display_close always asserts on win32 and quartz 569240 Crasher when using markers 569104 Toggle menu entries showed as check menu entries... 322932 Always show icons on panel menus * Updated translations: Finnish (fi) German (de) Thanks to all contributors: Claudio Saavedra Tristan van Berkom Björn Lindqvist Richard Hult Bastien Nocera William Jon McCann January 27, 2009 Mattthias Clasen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GSeal bugs in GtkAccelLabel hampering flexibility
Am Montag, den 26.01.2009, 04:03 + schrieb Peter Clifton:
Hi,
I'm trying to write a subclass of GtkAccelLabel in order to override its
source for the accelerator string.
gEDA (GPL Electronic CAD) uses multi-key-press keyboard shortcuts which
are unfortunately incompatible with the GtkAccelGroup way of achieving
keyboard shortcuts.
By subclassing GtkAction, I've been able to add extra data, stashing our
desired accelerator string, and have been able to override the
connect_proxy method in order to replace the GtkAccelLabel in the menu
item with a custom GschemAccelLabel, upon which I set a string
property with our desired accelerator text.
All is well here, and menus work - display as expected. (Even if I
suspect the fact you can swap the GtkMenuItem's label before hooking the
GtkAction connect_proxy method may be exploiting implementation details
of the system.
Unfortunately, GtkMenuItem will only check the accelerator width for
GtkAccelLabel and its subclasses. (I'm currently subclassing GtkLabel).
However.. even if I subclass GtkAccelLabel, I have no means to override
its idea of what the accelerator string is, nor the width it returns
when queried.
The header file GSEALs the required members:
struct _GtkAccelLabel
{
GtkLabel label;
guint GSEAL (gtk_reserved);
guint GSEAL (accel_padding); /* should be style property? */
GtkWidget *GSEAL (accel_widget); /* done*/
GClosure *GSEAL (accel_closure); /* has set function */
GtkAccelGroup *GSEAL (accel_group);/* set by set_accel_closure() */
gchar *GSEAL (accel_string); /* has set function */
guint16GSEAL (accel_string_width); /* seems to be private */
};
seems to be private - Has broken my ability to override it
accel_string _does not_ have a direct setter - I can't override it.
I felt like I was so close to making this work without having to
re-write the whole damned GtkMenu* GtkAction* GtkAccel* class hierarchy
in our app, but I'm beginning to realise this isn't going to work
without major surgery.
Please please ensure that when GSEAL'ing members / hiding implementation
details away in prep for GTK3.0, that the toolkit is actually actually
usable / flexible enough for developers who need to subclass and extend
or change its default behaviour.
Either make the widgets flexible enough in the first place, or expose
the appropriate hooks / class member virtual functions in order for us
to extend things! GtkAccel* could so nearly have been directly usable
for what we want, but due to lack of virtual functions in the class, we
can't just subclass it to give the behaviours we need.
I'm running out of decent arguments against other developers on the team
who want to switch away from GTK, and my own patience is becoming
stretched. I want to love GTK, but sometimes (like tonight) it
frustrates me so very much!
Sorry for the rant..
Any suggestions as to how to fix this will be warmly received.
What about creating a patch providing the hooks you need?
In the end that's how FOSS works.
Ciao,
Mathias
--
Mathias Hasselmann mathias.hasselm...@gmx.de
Personal Blog: http://taschenorakel.de/mathias/
Openismus GmbH: http://www.openismus.com/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_malloc overhead
On Sun, 18 Jan 2009 17:43:57 +0100 Martín Vales mar...@opengeomap.org wrote: Other overhead i see is the open dir/file funtions, where in windows we need do the utf8 to utf16 everytime in windows. If JAVA,.NET and Qt use utf16 by default why in gnome world we use utf8 by default?. Probably one of the biggest reasons, is that UTF-8 does not use \0 octets, whereas UTF-16 does. This means that UTF-8 data can transparently pass through all of the usual str*() functions in C, such as strlen(), strcpy(), etc... -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bikeshedding the invisible-char
On Mon, 19 Jan 2009 20:07:09 -0600 Federico Mena Quintero feder...@novell.com wrote: I'm arguing for committing openSUSE's patch based on the following unquestionable criteria: Do you have any numbers on the glyph coverage of these two characters in a variety of common fonts? Are either of them glaringly missing anywhere? -- Paul LeoNerd Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_malloc overhead
Paul LeoNerd Evans escribió: On Sun, 18 Jan 2009 17:43:57 +0100 Martín Vales mar...@opengeomap.org wrote: Other overhead i see is the open dir/file funtions, where in windows we need do the utf8 to utf16 everytime in windows. If JAVA,.NET and Qt use utf16 by default why in gnome world we use utf8 by default?. Probably one of the biggest reasons, is that UTF-8 does not use \0 octets, whereas UTF-16 does. This means that UTF-8 data can transparently pass through all of the usual str*() functions in C, such as strlen(), strcpy(), etc... I can see the advantages of use utf8 but the true it´s most of people use utf16. I know gnome/linux/cairo/freedesktop promote utf8 but most people use utf16: http://unicode.org/notes/tn12/#Software_16 Regards. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_malloc overhead
Am Montag, den 26.01.2009, 12:40 +0100 schrieb Martín Vales:
Paul LeoNerd Evans escribió:
On Sun, 18 Jan 2009 17:43:57 +0100
Martín Vales mar...@opengeomap.org wrote:
Other overhead i see is the open dir/file funtions, where in windows we
need do the utf8 to utf16 everytime in windows. If JAVA,.NET and Qt use
utf16 by default why in gnome world we use utf8 by default?.
Probably one of the biggest reasons, is that UTF-8 does not use \0
octets, whereas UTF-16 does. This means that UTF-8 data can transparently
pass through all of the usual str*() functions in C, such as strlen(),
strcpy(), etc...
I can see the advantages of use utf8 but the true it´s most of people
use utf16. I know gnome/linux/cairo/freedesktop promote utf8 but most
people use utf16:
http://unicode.org/notes/tn12/#Software_16
Currently C doesn't support for UTF-16 literals. The wchar_t type is 32
bits on Linux. So instead of:
do_something (abc)
you'd suddenly have to write:
const utf16_t abc_literal[] = { 65, 66, 67, 0 }; /* abc */
do_something (abc_literal);
I really don't see how this would help.
Ciao,
Mathias
--
Mathias Hasselmann mathias.hasselm...@gmx.de
Personal Blog: http://taschenorakel.de/mathias/
Openismus GmbH: http://www.openismus.com/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_malloc overhead
Martín Vales wrote: I can see the advantages of use utf8 but the true it´s most of people use utf16. I know gnome/linux/cairo/freedesktop promote utf8 but most people use utf16: http://unicode.org/notes/tn12/#Software_16 This is a very baseless claim. One that actually turns out to be false. Most people don't right Windows code. Most people read and write content on the internet, and I bet more than 99% of the Unicode content on the net is in UTF-8. As for the technical note you cite, it's a very biased document of its own. I once wrote a full critical review of it but can't find it. Lets just say that UTF-16 is at best implementation details of Firefox. I can't see how that can be relevant here. Moreover, it's plain wrong that Python uses UTF-16. Python APIs are encoding-agnostic, and while Python 2.x can be compiled with UCS-2, it's recommended that UCS-4 be enabled. And note the difference: I said UCS-2, not UTF-16. UTF-16 is a disease. It's variable-width, so it doesn't have the benefits of UTF-32. It's sixteen bit, so it doesn't have the ASCII-compatibility of UTF-8. Tell me one good thing about it other than everyone made the mistake of using it and now they have to keep doing that because they exposed it in their API. behdad ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GSeal bugs in GtkAccelLabel hampering flexibility
On Mon, 2009-01-26 at 10:15 +0100, Mathias Hasselmann wrote:
Am Montag, den 26.01.2009, 04:03 + schrieb Peter Clifton:
Hi,
I'm trying to write a subclass of GtkAccelLabel in order to override its
source for the accelerator string.
gEDA (GPL Electronic CAD) uses multi-key-press keyboard shortcuts which
are unfortunately incompatible with the GtkAccelGroup way of achieving
keyboard shortcuts.
By subclassing GtkAction, I've been able to add extra data, stashing our
desired accelerator string, and have been able to override the
connect_proxy method in order to replace the GtkAccelLabel in the menu
item with a custom GschemAccelLabel, upon which I set a string
property with our desired accelerator text.
All is well here, and menus work - display as expected. (Even if I
suspect the fact you can swap the GtkMenuItem's label before hooking the
GtkAction connect_proxy method may be exploiting implementation details
of the system.
Unfortunately, GtkMenuItem will only check the accelerator width for
GtkAccelLabel and its subclasses. (I'm currently subclassing GtkLabel).
However.. even if I subclass GtkAccelLabel, I have no means to override
its idea of what the accelerator string is, nor the width it returns
when queried.
The header file GSEALs the required members:
struct _GtkAccelLabel
{
GtkLabel label;
guint GSEAL (gtk_reserved);
guint GSEAL (accel_padding); /* should be style property? */
GtkWidget *GSEAL (accel_widget); /* done*/
GClosure *GSEAL (accel_closure); /* has set function */
GtkAccelGroup *GSEAL (accel_group);/* set by set_accel_closure()
*/
gchar *GSEAL (accel_string); /* has set function */
guint16GSEAL (accel_string_width); /* seems to be private */
};
seems to be private - Has broken my ability to override it
accel_string _does not_ have a direct setter - I can't override it.
I felt like I was so close to making this work without having to
re-write the whole damned GtkMenu* GtkAction* GtkAccel* class hierarchy
in our app, but I'm beginning to realise this isn't going to work
without major surgery.
Please please ensure that when GSEAL'ing members / hiding implementation
details away in prep for GTK3.0, that the toolkit is actually actually
usable / flexible enough for developers who need to subclass and extend
or change its default behaviour.
Either make the widgets flexible enough in the first place, or expose
the appropriate hooks / class member virtual functions in order for us
to extend things! GtkAccel* could so nearly have been directly usable
for what we want, but due to lack of virtual functions in the class, we
can't just subclass it to give the behaviours we need.
I'm running out of decent arguments against other developers on the team
who want to switch away from GTK, and my own patience is becoming
stretched. I want to love GTK, but sometimes (like tonight) it
frustrates me so very much!
Sorry for the rant..
Any suggestions as to how to fix this will be warmly received.
What about creating a patch providing the hooks you need?
In the end that's how FOSS works.
Don't lecture me on FOSS. It works fine in gEDA, and other projects I'm
contributing to with occasional bug-fixes / reports, like X / Intel
video etc... and it does NOT always require the bug reporter sends a
patch. (It wasn't me who sealed members without providing setters).
Some times recognising / diagnosing the problem is more important than
learning an alien code-base and attempting a fix the problem. That
probably isn't going to lead to great code either. At the very least,
I'd need some input from a GTK developer suggesting how the fix should
be architected, what the original design decisions were which made the
code as it is now.
The way GTK seems to have worked (from my past experience), is I /
others write patches, then they sit in Bugzilla and get ignored. I won't
pollute this reply with the list of examples, but I can think of
several. (Ok - only one patch was mine).
Having the first reply to my post basically saying get lost and write
some patches is not conducive to good collaboration on the problem.
In any case.. to rely on upstream code changes we'd be waiting several
years or so before we can actually write applications based on that
code, and assume it to be present. The gEDA userbase is very
conservative, and tends not to run a bleeding-edge distro - which is a
pain. I've only just been allowed to depend on GTK 2.8 for our latest
release, that's how bad things are!.
I brought the issue up at all (rather than just sulking about the
problem privately) was in the hope that it would result in the problem
_eventually_ being fixed.
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson
Re: g_malloc overhead
On Mon, Jan 26, 2009 at 9:12 AM, Behdad Esfahbod beh...@behdad.org wrote: Lets just say that UTF-16 is at best implementation details of Firefox. Well, JavaScript is notably UTF-16. Given that the Web, Java and .NET (i.e. all the most important platforms) are all UTF-16 it's likely to be with us for quite a while, so it's important to understand. But yeah, there's no way POSIX/GNOME etc. could switch even if it made sense to do so (which it clearly doesn't). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GSeal bugs in GtkAccelLabel hampering flexibility
Peter Clifton wrote: The way GTK seems to have worked (from my past experience), is I / others write patches, then they sit in Bugzilla and get ignored. I won't pollute this reply with the list of examples, but I can think of several. (Ok - only one patch was mine). Peter, I understand your frustration, but I don't see how attacking GTK+ maintainers helps. SO yeah, GTK+ has two part-time maintainers. What do you expect them to do? Qt has a team of 100 behind it. Does that make Qt more responsive to bug reports? Go try... If you want a workaround for now, just access the member as GSEAL(member_name). I told them the GSEAL macro should use __line__, they didn't listen :P. behdad ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GSeal bugs in GtkAccelLabel hampering flexibility
On Mon, 2009-01-26 at 00:59 -0500, Yu Feng wrote: Hi Peter, I agree with you to seal accel_string without any getter/setter sucks. But some of my code may interest you. Look for class MenuLabel in the following file to see its public interface: Thanks for the suggestion. I did in fact do similar. From within the GtkAction subclass, you get a chance to set the GtkMenuItem*'s label _before_ calling the parent class connect_proxy fuction. gnome2-globalmenu.googlecode.com/svn/trunk/libgnomenu/Gnomenu-1.0.gir The dirty trick is to throw GtkAccelLabel away, then put two GtkLabels in one MenuItem. one of them aligns to the left, the other aligns to the right. It is not exactly the the same as Gtk's accel labels, but so close that none of my users have noticed the diff. The computation of the proper alignments is off for me, unfortunately. There are more exposed methods for setting the toggle size of a menu item, but I couldn't find anything suitable to override the size of the accelerator. I don't know if you can still assign GtkActions to them though. Should be able to.. just won't have it display the accelerator. GtkAction is quite a nice class. You can subclass it and provide custom factories for making menu items / toolbar buttons of the desired type.. or set the GType to be created by the built-in functions. It falls down slightly because the built-in connect_proxy member function needs to be called (it hooks up some private stuff, and refcounts etc..), but also manipulates the way a proxy object is connected. You have to be careful how you override that, and doing so is probably exploiting implementation details of just how the built-in connect_proxy function operates. Best regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GSeal bugs in GtkAccelLabel hampering flexibility
On Mon, 2009-01-26 at 09:59 -0500, Behdad Esfahbod wrote: Peter Clifton wrote: The way GTK seems to have worked (from my past experience), is I / others write patches, then they sit in Bugzilla and get ignored. I won't pollute this reply with the list of examples, but I can think of several. (Ok - only one patch was mine). Peter, I understand your frustration, but I don't see how attacking GTK+ maintainers helps. SO yeah, GTK+ has two part-time maintainers. What do you expect them to do? Qt has a team of 100 behind it. Does that make Qt more responsive to bug reports? Go try... Sorry, I didn't mean to attack the GTK maintainers in general, I was just cross that the first reply I got was basically patches welcome. I should learn to move away from my computer when I'm in a bad mood about something ;) If you want a workaround for now, just access the member as GSEAL(member_name). I told them the GSEAL macro should use __line__, they didn't listen :P. Ok - didn't know I could do that. I had presumed the sealed members we not available for prodding outside GTK's codebase. (BTW.. what would __line__ do exactly?) If this lets me work around the problem, perhaps I can help prepare a more complete fix for GTK 3.0, whilst not being stuck in limbo waiting for users to move onto some as-yet unreleased GTK version. I'm not event sure whether all the fixes can even be made without breaking ABI. (GTK 3.0 will break ABI right?) I presume accessing members with GSEAL(member_name) carries a big Caveat Emptor, that you're now relying on implementation details. Thanks Behdad, I know I didn't deserve a helpful reply when I was being a grumpy git, but you provided one anyway. Best wishes, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_malloc overhead
Colin Walters escribió: On Mon, Jan 26, 2009 at 9:12 AM, Behdad Esfahbod beh...@behdad.org wrote: Lets just say that UTF-16 is at best implementation details of Firefox. Well, JavaScript is notably UTF-16. Given that the Web, Java and .NET (i.e. all the most important platforms) are all UTF-16 it's likely to be with us for quite a while, so it's important to understand. Yes i only wanted say that. For example i work in c# and i would like create glib libraries and use it in .net, but the char in mono/.NET is utf16 and therefore i have there the same overhead. The solution are 2: 1.- conversion using glib (): http://library.gnome.org/devel/glib/2.19/glib-Unicode-Manipulation.html#gunichar2 .-2. automatic NET conversion in the p/invoke side. The 2 solutions have the same overhead. But yeah, there's no way POSIX/GNOME etc. could switch even if it made sense to do so (which it clearly doesn't). Yes, i only talked about the overhead with utf8 outside of glib, only that. Perhaps the only solution is add more suport to utf16 in glib with more methods. Regards. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_malloc overhead
On Mon, 2009-01-26 at 18:30 +0100, Martín Vales wrote: Colin Walters escribió: On Mon, Jan 26, 2009 at 9:12 AM, Behdad Esfahbod beh...@behdad.org wrote: Lets just say that UTF-16 is at best implementation details of Firefox. Well, JavaScript is notably UTF-16. Given that the Web, Java and .NET (i.e. all the most important platforms) are all UTF-16 it's likely to be with us for quite a while, so it's important to understand. Yes i only wanted say that. For example i work in c# and i would like create glib libraries and use it in .net, but the char in mono/.NET is utf16 and therefore i have there the same overhead. The solution are 2: 1.- conversion using glib (): http://library.gnome.org/devel/glib/2.19/glib-Unicode-Manipulation.html#gunichar2 .-2. automatic NET conversion in the p/invoke side. The 2 solutions have the same overhead. But yeah, there's no way POSIX/GNOME etc. could switch even if it made sense to do so (which it clearly doesn't). Yes, i only talked about the overhead with utf8 outside of glib, only that. Perhaps the only solution is add more suport to utf16 in glib with more methods. There's zero point in talking about a solution until you have profile data indicating that there is a problem. - Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_malloc overhead
On Mon, Jan 26, 2009 at 12:57:28PM -0500, Owen Taylor wrote:
On Mon, 2009-01-26 at 18:30 +0100, Martín Vales wrote:
Yes, i only talked about the overhead with utf8 outside of glib, only that.
Perhaps the only solution is add more suport to utf16 in glib with more
methods.
There's zero point in talking about a solution until you have profile
data indicating that there is a problem.
Indeed. UTF-16 is horribly broken by design, and any attempt made to
migrate in the direction _towards_ it is a flawed one, and should be
avoided.
UTF-8 is backward-compatible with the legacy str*() functions in C,
which, like it or not, will be around for a while yet.
* It makes sure not to embed any ASCII NUL ('\0') in the stream unless
it means it, as U+, which makes it work with these functions.
* UTF-8 has nice properties in substring matches - grep can work on
UTF-8 despite not knowing it, because no valid UTF-8 string ever appears
falsely as a substring of another.
* This also means that the only occurance of '\n' in a UTF-8 stream is
a real one. This means that cat, head/tail, awk, etc... can properly
detect where the linefeeds are. 'head' can print, say, the first 3
lines of UTF-8 text without knowing it's UTF-8.
* UTF-8 can be sorted by only sorting the encoded bytes. sort can sort
a UTF-8-encoded text file. The order of the Unicode strings, is the
same as the bytewise-sorted order of the raw bytes that encode it.
This list goes on.
Meanwhile, on the other end of the spectrum, storing Unicode data as
decoded 32bit integers makes some sense. It means string indexing
operations are constant-width - the substring between the 4th and 9th
characters in such an array will be known to lie between the 16th and
36th bytes. The presence of combining characters, and double-width
glyphs does make this transformation a bit harder, effectively reducing
the advantage such a scheme has.
Compared to that, UTF-16 offers NONE of these advantages. UTF-16 cannot
be passed through any legacy str*() function, nor will it work in grep,
sed, awk, cut, sort, head, tail, or in fact _any_ of the standard UNIX
text tools. Nor can UTF-16 be array indexed in constant time, because of
the surrogate pairs used to encode codepoints outside of the BMP (Basic
Multilingual Plane).
In Summary - UTF-16. Don't. Just Don't.
--
Paul LeoNerd Evans
leon...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: Digital signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_malloc overhead
Martín Vales mar...@opengeomap.org writes: Colin Walters escribió: On Mon, Jan 26, 2009 at 9:12 AM, Behdad Esfahbod beh...@behdad.org wrote: Lets just say that UTF-16 is at best implementation details of Firefox. Well, JavaScript is notably UTF-16. Given that the Web, Java and .NET To be honest - aren't web currently XML-based (XHTML co.)? And isn't UTF-8 default encoding, and acidentally the most widly used, for XML? But yeah, there's no way POSIX/GNOME etc. could switch even if it made sense to do so (which it clearly doesn't). Yes, i only talked about the overhead with utf8 outside of glib, only that. Perhaps the only solution is add more suport to utf16 in glib with more methods. Well - what do you mean? Having 2 functions - one reciving utf-16 and one utf-8? To be honest - it doesn't make any sense to me (it would create much mess, double the code, make programming errors easier...). Converting? What's wrong with g_utf16_to_utf8? Regards -- I've probably left my head... somewhere. Please wait untill I find it. Homepage (pl_PL): http://uzytkownik.jogger.pl/ (GNU/)Linux User: #425935 (see http://counter.li.org/) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_malloc overhead
hi: Well - what do you mean? Having 2 functions - one reciving utf-16 and one utf-8? To be honest - it doesn't make any sense to me (it would create much mess, double the code, make programming errors easier...). Converting? What's wrong with g_utf16_to_utf8? I was talking about a full utf16 and utf8 api in glib and use a macro to work work intermediate string: For example in windows they have this types: LPSTR =char * LPWSTR= utf16windowschar * ... and: LPTSTR type. If we defined the _UNICODE macro is LPWSTR else LPSTR . ,...after they have a full api to manage utf16 and ansi strings, (strcat, strcpy, etc), http://msdn.microsoft.com/en-us/library/h1x0y282.aspx ... and finally macros to use string in the same way _TEXT _T, etc. _TEXT(are you defined _UNICODE macro?. Perhaps i am ansi or perhaps utf16) http://msdn.microsoft.com/en-us/library/dd374074(VS.85).aspx http://msdn.microsoft.com/en-us/library/dd374074%28VS.85%29.aspx perhaps in glib we could have utf16 and utf8 in that way or am i wrong? Regards. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GSeal bugs in GtkAccelLabel hampering flexibility
Peter Clifton wrote: If you want a workaround for now, just access the member as GSEAL(member_name). I told them the GSEAL macro should use __line__, they didn't listen :P. Ok - didn't know I could do that. I had presumed the sealed members we not available for prodding outside GTK's codebase. It's a bad hack. I'm sure the GTK3 guys will find me and hunt me for letting this out. (BTW.. what would __line__ do exactly?) It expands to the line number. If the GSEAL macro used that to include the line number in the mangled name you couldn't use this trick. If this lets me work around the problem, perhaps I can help prepare a more complete fix for GTK 3.0, whilst not being stuck in limbo waiting for users to move onto some as-yet unreleased GTK version. I'm not event sure whether all the fixes can even be made without breaking ABI. (GTK 3.0 will break ABI right?) Correct. But the idea is to make transition as straightforward as possible. I presume accessing members with GSEAL(member_name) carries a big Caveat Emptor, that you're now relying on implementation details. Well, one is not supposed to use the GSEAL'ed members. But given your situation, well, why not... Cheers, behdad ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_malloc overhead
Maciej Piechotka escribió: On Mon, 2009-01-26 at 22:30 +0100, Martin (OPENGeoMap) wrote: hi: Well - what do you mean? Having 2 functions - one reciving utf-16 and one utf-8? To be honest - it doesn't make any sense to me (it would create much mess, double the code, make programming errors easier...). Converting? What's wrong with g_utf16_to_utf8? I was talking about a full utf16 and utf8 api in glib and use a macro to work work intermediate string: For example in windows they have this types: LPSTR =char * char * is used for utf-8 AFAIR LPWSTR= utf16windowschar * gunichar2 perhaps in glib we could have utf16 and utf8 in that way or am i wrong? I'm not glib developer. As far as the module of operating on utf-16 strings is proposed I'm not against. However I would prefere to not have 2 entries to each function. Hi: What is wrong with: gchar* g_utf8_strncpy (gchar *dest,const gchar *src,gsize n); gunichar2 * g_utf16_strncpy (gunichar2*dest,const gunichar2*src,gsize n); and the macro: gtext* g_text_strncpy (gtext*dest,const gtext*src,gsize n); regards. Regards Regards. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: utf-16 and glib
Maciej Piechotka escribió: On Mon, 2009-01-26 at 22:49 +0100, Martin (OPENGeoMap) wrote: Maciej Piechotka escribió: On Mon, 2009-01-26 at 22:30 +0100, Martin (OPENGeoMap) wrote: hi: Well - what do you mean? Having 2 functions - one reciving utf-16 and one utf-8? To be honest - it doesn't make any sense to me (it would create much mess, double the code, make programming errors easier...). Converting? What's wrong with g_utf16_to_utf8? I was talking about a full utf16 and utf8 api in glib and use a macro to work work intermediate string: For example in windows they have this types: LPSTR =char * char * is used for utf-8 AFAIR LPWSTR= utf16windowschar * gunichar2 perhaps in glib we could have utf16 and utf8 in that way or am i wrong? I'm not glib developer. As far as the module of operating on utf-16 strings is proposed I'm not against. However I would prefere to not have 2 entries to each function. Hi: 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 gunichar2 * g_utf16_strncpy (gunichar2*dest,const gunichar2*src,gsize n); That's kind of support I'm not against. and the macro: gtext* g_text_strncpy (gtext*dest,const gtext*src,gsize n); regards. With the entries - nothing. With macro - it may be just me but I percive it shooting into foot. Just imagine that some header will assume gtext to be utf-8. Other will turn on the macro (or user code) and change it to utf-16. IMHO - having magic switch which might change the ABI is not good. Regards ___ 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-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GSeal bugs in GtkAccelLabel hampering flexibility
On Mon, 2009-01-26 at 16:34 -0500, Behdad Esfahbod wrote: Peter Clifton wrote: If you want a workaround for now, just access the member as GSEAL(member_name). I told them the GSEAL macro should use __line__, they didn't listen :P. Ok - didn't know I could do that. I had presumed the sealed members we not available for prodding outside GTK's codebase. It's a bad hack. I'm sure the GTK3 guys will find me and hunt me for letting this out. (BTW.. what would __line__ do exactly?) It expands to the line number. If the GSEAL macro used that to include the line number in the mangled name you couldn't use this trick. If this lets me work around the problem, perhaps I can help prepare a more complete fix for GTK 3.0, whilst not being stuck in limbo waiting for users to move onto some as-yet unreleased GTK version. I'm not event sure whether all the fixes can even be made without breaking ABI. (GTK 3.0 will break ABI right?) Correct. But the idea is to make transition as straightforward as possible. I presume accessing members with GSEAL(member_name) carries a big Caveat Emptor, that you're now relying on implementation details. Well, one is not supposed to use the GSEAL'ed members. But given your situation, well, why not... Turns out about 20% of our source files don't compile with -DGSEAL_ENABLE anyway, so looks like we've got some work to do before GTK3.0 comes out ;). Oh.. and a fair number of these bugs were in my stolen and modified from GTK sources GtkAction and GtkAccelLabel subclasses. Please do help enlighten me though.. I'm going mad trying to figure this one out... how does actually GSEAL work? (I've not found anything using Google). I can't grep a single reference defining the GSEAL macro in /usr/include, nor _g_seal__. Yet magically -DGSEAL_ENABLE makes the code compilation break by hiding those members. Am I being dumb...? What black magic is going on here? -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GSeal bugs in GtkAccelLabel hampering flexibility
On Mon, 2009-01-26 at 22:09 +, Peter Clifton wrote: I can't grep a single reference defining the GSEAL macro in /usr/include, nor _g_seal__. Yet magically -DGSEAL_ENABLE makes the code compilation break by hiding those members. Am I being dumb...? What black magic is going on here? Found it... /usr/lib/gtk-2.0/include/gdkconfig.h Sorry for the noise. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: utf-16 and glib
Dominic Lachowicz escribió: 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. 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. Regards. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: utf-16 and glib
Martin (OPENGeoMap) wrote: Dominic Lachowicz escribió: 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. 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. You are still to show us where this becomes a bottleneck. This does not make any sense in glib. I've been thinking about possibly adding UTF-16 and UTF-32 APIs to Pango, and that makes more sense when interfacing with other apps. But I've kept the macro idea just for my internal implementation in Pango, not as crack to be put in public header files. behdad Regards. ___ gtk-app-devel-list mailing list gtk-app-devel-l...@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ 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: utf-16 and glib
Maciej Piechotka escribió: On Mon, 2009-01-26 at 23:48 +0100, Martin (OPENGeoMap) wrote: Dominic Lachowicz escribió: 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. Glib/gtk is full of macros. But how many of them changes the meaning by other 'switch-macro'? I'm nearly sure that all of them evaluate to the same values at each gived platform. I believe que a C compiler is the right place to this kind of unsafe code. What do you mean by 'unsafe'? If the 'unsafe' code is unsafe there is no place to put it. If the 'unsafe' means that the code cannot be verified easily by compiler if it is correct that there is place in C code (or any other). by unsafe i want say something like the g-signal-connect macro: http://library.gnome.org/devel/gobject/unstable/gobject-Signals.html#g-signal-connect 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. How much is the overhead? How big it is in compare to for example I/O in accessing filesystem, drawing in access to GTK+ or to GC in access to C#/Java? hummm. Example: If we have for example a DWG binary file we have for example 15000 utf16 strings. If i use glib i need make 15000 translations utf16/utf8 to use the utf8 glib api. When i need save the file i need make other 15000 translations. There are thounsand of formats using utf16. I don´t love utf16, but I MUST use utf16 in the real world. I am not the guilty of existence of utf16 :'( . Regards. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: utf-16 and glib
Martin (OPENGeoMap) wrote: hummm. Example: If we have for example a DWG binary file we have for example 15000 utf16 strings. If i use glib i need make 15000 translations utf16/utf8 to use the utf8 glib api. When i need save the file i need make other 15000 translations. There are thounsand of formats using utf16. I don´t love utf16, but I MUST use utf16 in the real world. I am not the guilty of existence of utf16 :'( . Your examples fails to show that the conversion takes any considerable time compared to other stuff you are doing (for example, I/O is orders of magnitude slower). behdad ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: utf-16 and glib
On Tue, 2009-01-27 at 00:19 +0100, Martin (OPENGeoMap) wrote: hummm. Example: If we have for example a DWG binary file we have for example 15000 utf16 strings. If i use glib i need make 15000 translations utf16/utf8 to use the utf8 glib api. When i need save the file i need make other 15000 translations. There are thounsand of formats using utf16. I don´t love utf16, but I MUST use utf16 in the real world. I am not the guilty of existence of utf16 :'( . If you find that really is a bottleneck, there's nothing stopping you from writing functions _in your app_ which would deal with the strings as UTF-16 throughout the process of loading and saving. Philip Regards. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: utf-16 and glib
Martin (OPENGeoMap) wrote: I don´t want say we MUST add more support to glib. I only say most software developers works with utf16 text and many of that people are not fan of that encoding but they must use it in the 100% of the source code. Other than making a lot of noise, what are you actually requesting? What functions exactly? If you don't have numbers to back your request, just stop it already. behdad ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ 2.15.2 released
GTK+ 2.15.2 is now available for download at: http://download.gnome.org/sources/gtk+/2.15/ gtk+-2.15.2.tar.bz2 md5sum: 1c230eeb1bf24b69b480d0a35da34794 gtk+-2.15.2.tar.gz md5sum: 1e9d42fb6bdfb6752a82f6c3afc3b3e7 This is another development release leading up to GTK+ 2.16. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GTK+. If you have problems, you'll need to reinstall GTK+ 2.14. * GTK+ 2.16 will be source and binary compatible with the GTK+ 2.14 series. The API additions in GTK+ 2.15 are finalized at this point, only minor API changes are expected to happen between 2.15.2 and 2.16. * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html http://www.gtk.org/faq/ Contributing GTK+ is a large project and relies on voluntary contributions. We are actively searching for new contributors in various areas and invite everyone to help project development. If you are willing to participate, please subscribe to the project mailing lists to offer your help and read over our list of vacant project tasks: http://live.gnome.org/GtkTasks Overview of Changes from GTK+ 2.15.1 to 2.15.2 == * GtkAction: - Make toolitems pick up icon names from actions - Draw proxies of radio actions properly - Make menu proxies of recent actions work - Avoid accidental activations when changing actions on proxies - Make derived button classes work as proxies * Input methods: - Avoid an assertion due to early use of input methods * GtkScale: - Avoid a segfault in the marker drawing code * GtkImageMenuItem: - Add a property to override the show-menu-images setting * Bugs fixed: 566628 gdk_display_close always asserts on win32 and quartz 569240 Crasher when using markers 569104 Toggle menu entries showed as check menu entries... 322932 Always show icons on panel menus * Updated translations: Finnish (fi) German (de) Thanks to all contributors: Claudio Saavedra Tristan van Berkom Björn Lindqvist Richard Hult Bastien Nocera William Jon McCann January 27, 2009 Mattthias Clasen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
