Re: GtkCanvas requirements?
Hmm: Once again I too fast on pressing send and forgot the links: Vala: http://live.gnome.org/Vala EggDocument: http://taschenorakel.de/svn/repos/eggdocument/trunk/ Am Samstag, den 21.04.2007, 17:49 +0200 schrieb Mathias Hasselmann: Am Samstag, den 21.04.2007, 10:30 -0500 schrieb Federico Mena Quintero: [Side note... at this point I think doing a canvas in C is a big mistake. Interesting canvases will inevitably get cycles in the pointer graph, and reference counting becomes just too painful then. [This is irrelevant to .net or whatever; it's a general We Should Stop Writing Nontrivial Shit In C thing. People would be really really happy with the Piccolo.NET API implemented with pygtk or gtk-sharp.]] I'd rather consider using Vala in that case: It gives you a highlevel syntax for the GObject system, whilest generating native, binding friendly code. GNOME avoids using high-level languages for libraries for good reason: Bindings and politics. Used it for toying with some document model for printing [1] and expect for minor bugs in Vala's code generator, which where resolved quickly, vala worked pretty well for me in creating a native GObject library. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
Am Samstag, den 21.04.2007, 10:30 -0500 schrieb Federico Mena Quintero: [Side note... at this point I think doing a canvas in C is a big mistake. Interesting canvases will inevitably get cycles in the pointer graph, and reference counting becomes just too painful then. [This is irrelevant to .net or whatever; it's a general We Should Stop Writing Nontrivial Shit In C thing. People would be really really happy with the Piccolo.NET API implemented with pygtk or gtk-sharp.]] I'd rather consider using Vala in that case: It gives you a highlevel syntax for the GObject system, whilest generating native, binding friendly code. GNOME avoids using high-level languages for libraries for good reason: Bindings and politics. Used it for toying with some document model for printing [1] and expect for minor bugs in Vala's code generator, which where resolved quickly, vala worked pretty well for me in creating a native GObject library. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
Am Samstag, den 21.04.2007, 11:57 -0500 schrieb Yevgen Muntyan: Federico Mena Quintero wrote: [snip] [Side note... at this point I think doing a canvas in C is a big mistake. Interesting canvases will inevitably get cycles in the pointer graph, and reference counting becomes just too painful then. [This is irrelevant to .net or whatever; it's a general We Should Stop Writing Nontrivial Shit In C thing. People would be really really happy with the Piccolo.NET API implemented with pygtk or gtk-sharp.]] Only mono (python) people would be happy with whatever implemented in gtk-sharp (python). If it's not C, then everybody implements same thing in their favorite language. Unfortunately, it is just hard to implement so we use that one works only if that one is written in C. Even if you forget about problems of interoperability between different languages (some bindings do work two ways, e.g. pygtk; some don't, e.g. gtkmm). So while it's good to write something totally good in C# (and same thing about python, vala, C++, and lisp), it's totally useless as GTK canvas. I agree for you, expect for Vala where you are wrong: Vala doesn't directly produce machine or byte code, it produces standard C code with standard C headers. So technically writing something in Vala is the same as writing something in C - expect that you save alot of typing. As the Vala parser itself is avaiable as GObject library, it even should by extremly easy to generate GAPI files for language bindings directly (without parsing the generated C code). Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GObject based Collection framework
I think you mean below the gobject stack, don't you? The data structure libraries are required by gobject after all, aren't they? Heh, yeah maybe my idea of gobject'ized glib data structs is a little futile :) not sure just exactly what I'd do with a derivable GList, I'm sure something random could come of it haha, maybe I've found myself wanting GObject derived GList. The idea is to have a list of things with some GType, and make the API which modifies that list emit changed, deleted, inserted signals, etc. I coded a GObject derived class to do most of this. Regarding a GObject based collection framework: Currently Jürg Billeter, Philip Van Hoof, Johannes Schmid and others work on such a framework called libtpz, as they need/want reference counting collection classes. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Common widget for choosing file formats
Quoting myself from Bug 440431[1]:
Applications supporting multiple file formats needs a file-format
chooser in
their file saving dialog. Several GNOME apps implement very similiar
file-format choosers - so it makes sense to me, to add this widget to GTK+.
The widget would be used like this:
GtkWidget *format_chooser = egg_file_format_chooser_new();
gtk_file_chooser_set_extra_widget(GTK_FILE_CHOOSER(dialog),
format_chooser);
EggFileFormat *format;
format = egg_file_format_new (_(Scalable Vector Graphics (SVG)), svg,
NULL);
egg_file_format_chooser_add_format(EGG_FILE_FORMAT_CHOOSER(format_chooser),
format);
format = egg_file_format_new (_(Compiliertes Layout (C-Header)), h,
NULL);
egg_file_format_chooser_add_format(EGG_FILE_FORMAT_CHOOSER(format_chooser),
format);
...
if (GTK_RESPONSE_ACCEPT == gtk_dialog_run (file_chooser))
{
EggFileFormat *format = egg_file_format_chooser_get_format
(format_chooser);
gchar *filename = gtk_file_chooser_get_filename (chooser);
if (NULL == format)
format = egg_file_format_chooser_guess_by_extension (format_chooser,
filename);
app_file_format_save (APP_FILE_FORMAT (format), filename);
g_free (filename);
}
Suggested API:
http://bugzilla.gnome.org/attachment.cgi?id=88596action=view
http://bugzilla.gnome.org/attachment.cgi?id=88598action=view
Is it OK, to commit this to GTK+? Should I add it to libegg first?
Ideas? Suggestions?
[1] http://bugzilla.gnome.org/show_bug.cgi?id=440431
--
Mathias Hasselmann [EMAIL PROTECTED]
http://taschenorakel.de/
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Common widget for choosing file formats
Am Dienstag, den 22.05.2007, 14:51 +0200 schrieb Xavier Bestel: On Tue, 2007-05-22 at 14:43 +0200, Mathias Hasselmann wrote: Applications supporting multiple file formats needs a file-format chooser in their file saving dialog. Several GNOME apps implement very similiar file-format choosers - so it makes sense to me, to add this widget to GTK+. The widget would be used like this: GtkWidget *format_chooser = egg_file_format_chooser_new(); gtk_file_chooser_set_extra_widget(GTK_FILE_CHOOSER(dialog), format_chooser); EggFileFormat *format; format = egg_file_format_new (_(Scalable Vector Graphics (SVG)), svg, NULL); egg_file_format_chooser_add_format(EGG_FILE_FORMAT_CHOOSER(format_chooser), format); That may be a bit short for container formats, which must handle subformats (e.g. AVI with different audio/video codecs). Definitly didn't have this case in mind, and maybe its out of scope for a _common_ widget - nevertheless we should figure out, if a common widget can cover this case. What would be a good UI for that? - A tree with the container formats as root nodes? - A second chooser widget changing its content everytime a new container format is choosen? - Something completely different? Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Logo (was Re: GTK+ Website Review)
Am Dienstag, den 29.05.2007, 01:31 +0200 schrieb Felix Rabe (public): I wonder where the GTK logo proposal went? I think it would fit quite well in this design. Actually Andreas was doing some work there. I was sent a few ideas and they looked good, but nothing further so far. I might have another proposal based on the first one from Christophe ready in a short while. Those detached, glossy faces look cool, but they also make the logo look fragile. Well, and fragile that's definitly not a term I do or want associate with GTK+... Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Pango-warning
Am Donnerstag, den 14.06.2007, 22:22 -0700 schrieb Jeevan: Hi, Here I am trying to run a simple Gtk+ program, I am getting error as follows: Can you plz give me suggestion.. This list is for development of Gtk+ itself, the list for developments using Gtk+ is [EMAIL PROTECTED] *8 linux:~ # gcc base.c -o base `pkg-config --cflags --libs gtk+-2.0` linux:~ # ./base (base:4262): Pango-WARNING **: No builtin or dynamically loaded modules were found. Pango will not work correctly. This probably means there was an error in the creation of: '/usr/local/etc/pango/pango.modules' You should create this file by running pango-querymodules. Doing what the message suggests and running pango-querymodules /usr/local/etc/pango/pango.modules as described in the very fine manual of that program should help. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.11.3 released
Am Montag, den 18.06.2007, 19:08 -0600 schrieb Elijah Newren: On 6/18/07, Hubert Figuiere [EMAIL PROTECTED] wrote: I don't agree with that one. It is much simplier to add a C++ compile test. Afterall, which platform does not have a C++ compiler? Why reinventing the wheel yet again to make it square? Do all embedded platforms have a C++ compiler? And are there really that many C++-specific keywords? You are missing the point. This test would be run by make check to prevent that the maintainer releases code having C++ keywords in its headers. Regular users would not be affected by this test. Created a Bugzilla ticket: http://bugzilla.gnome.org/show_bug.cgi?id=449016 Potential implementation of the test: http://bugzilla.gnome.org/attachment.cgi?id=90258 Ciao, Mathias PS: Pardon for spaming, but seems like Evolution enjoys it to randomly choose my sender address. The taschenorakel address is not subscribed to gtk-devel list. -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.11.3 released
Am Montag, den 18.06.2007, 19:08 -0600 schrieb Elijah Newren: On 6/18/07, Hubert Figuiere [EMAIL PROTECTED] wrote: I don't agree with that one. It is much simplier to add a C++ compile test. Afterall, which platform does not have a C++ compiler? Why reinventing the wheel yet again to make it square? Do all embedded platforms have a C++ compiler? And are there really that many C++-specific keywords? You are missing the point. This test would be run by make check to prevent that the maintainer releases code having C++ keywords in its headers. Regular users would not be affected by this test. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Blacklisting themes?
1. User gets a crash in gnumeric-n.m, reports it. 2. Developer determines that the crash is in the theme engine. 3. Developer blacklists the theme engine; releases gnumeric-n.m+1 4. User updates gnumeric, and can't run it anymore because it barfs on that engine. He still risks crashes in other apps. I don't think blacklisting will work due to (4). If you require the user to upgrade the app, then the user may as well update the theme engine, too. It's better to tell the user you should really update your theme engine; that will fix his problem and prevent crashes in other apps as well. Well, but that still keeps the problem of countless dups in Bugzilla and bad reputation. I support the idea of blacklisting as this could be some efficient measure for quality control, but only if the blacklisting doesn't happen in the application, but in GTK+. Blacklisted themes would by detected by the MD5, SHA256, whatever hash over their gtkrc. Distributors would be encouraged to frequently backport our blacklist into their current GTK+ package. The blacklist even could be packaged separatly to make upgrades cheap. Just my 2 cents... Ciao, Mathias -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: openPrinting + the dialog...
Hi Peter, Nice to meet you again. Now that we have mock-ups to show of the new concepts we are introducing in the printing dialog, it is the right time to start working with the UI toolkits like gtk on moving towards implementation. I've seen those mockups at the LinuxTag and the idea to use tags instead of tabs for organizing looked very reasonable for me. Well choosen tags allow the user to quickly reach the options they need for their current printing task without endlessly searching complex notebook pages. The power of using tags to organize information instead of some artificial hierarchy has been demonstrated several times already in applications like Epiphany, F-Spot and on several Web 2.0 sites. So I highly recommand considering those mockups for a future versions of the printing dialog. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Theming improvements
Why not use the most obvious solution for the problem: Keep the theming engine as is, but instead of using one single theming detail string, let's attach a theming class property in the spirit of CSS class names to widgets: const gchar** gtk_widget_get_style_classes (GtkWidget *widget); gboolean gtk_widget_has_style_class (GtkWidget *widget, const gchar *class_name); Well, or for optimal speed let's use GQuarks instead: const GQuark* gtk_widget_get_style_classes (GtkWidget *widget); gboolean gtk_widget_has_style_class (GtkWidget *widget, GQuark class_name); Now let's add the rule, that widgets have to provide a macro for each style class they define, and we even get some easy way to document style classes: #define GTK_STYLE_CLASS_TREE_VIEW_COLUMN_BUTTON \ gtk_style_class_tree_view_column_button_get_quark () You might argue defining quarks for this purpose is quite some effort, but Bugzilla and libegg contain the implementation of a G_DEFINE_QUARK, respectively EGG_DEFINE_QUARK marco declaring *_get_quark functions: G_DEFINE_QUARK (GtkStyleClassTreeViewColumnButton, gtk_style_class_tree_view_column_button); This approach might not be a big and final solution, but its an approach that can be implemented right now without breaking much stuff. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK Scrolls
Am Donnerstag, den 30.08.2007, 11:30 +0200 schrieb bardzo_szorstki: Welcome, some time ago you send me the solution to remove a space between frame and scroll (like on this image: http://gnome-look.org/content/show.php?content=48820vote=goodtan=40330149 ) But I've lost that mail and don't remember source needed to be add to gtkrc :/ You want to play with the scrollbar-spacing style property. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Behaviour of getters wrt dup/ref
Hi Alex,
Strange that nobody replied yet, so let's start discussion by dropping
some random thoughts:
For convenience and performance I consider returning a weak reference
(const char*) the most reasonable choice for getters. If you want to
keep a reference to the value returned longer than it is guaranteed to
be valid, you still can call g_strdup on the caller side --- without
putting any memory management overhead on callers which just want to
have a short look on your properties.
Well, but you raised the question for properties which have to be
evaluated before returning them so for those properties I see two
possibilities:
1) rename the methods from maman_get_bar to maman_eval_bar
(or similiar)
2) handle them as lazy evaluated properties:
const char* maman_get_expensive_info (Maman *self)
{
if (NULL == self-priv-expensive_info)
self-priv-expensive_info = eval_expensive_info ();
return self-priv-expensive_info;
}
Every time you know that property could become invalid you reset the
_expensive_info field and of course you have to reset that field in your
object's dispose method. IMHO this pattern is quite common in OOP and
gives most convenience without sacrifing performance.
Well, and if you think its reasonable to transfer ownership for that
expensive field to the caller, you still can follow the pattern
introduced by GValue:
char* maman_steal_expensive_info (Maman *self)
{
char *result = maman_get_expensive_info (self);
self-priv-expensive_info = NULL;
return result;
}
Hope those thoughts help.
Ciao,
Mathias
--
Mathias Hasselmann [EMAIL PROTECTED]
http://taschenorakel.de/
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Behaviour of getters wrt dup/ref
Hi Alex,
Strange that nobody replied yet, so let's start discussion by dropping
some random thoughts:
For convenience and performance I consider returning a weak reference
(const char*) the most reasonable choice for getters. If you want to
keep a reference to the value returned longer than it is guaranteed to
be valid, you still can call g_strdup on the caller side --- without
putting any memory management overhead on callers which just want to
have a short look on your properties.
Well, but you raised the question for properties which have to be
evaluated before returning them so for those properties I see two
possibilities:
1) rename the methods from maman_get_bar to maman_eval_bar
(or similiar)
2) handle them as lazy evaluated properties:
const char* maman_get_expensive_info (Maman *self)
{
if (NULL == self-priv-expensive_info)
self-priv-expensive_info = eval_expensive_info ();
return self-priv-expensive_info;
}
Every time you know that property could become invalid you reset the
_expensive_info field and of course you have to reset that field in your
object's dispose method. IMHO this pattern is quite common in OOP and
gives most convenience without sacrifing performance.
Well, and if you think its reasonable to transfer ownership for that
expensive field to the caller, you still can follow the pattern
introduced by GValue:
char* maman_steal_expensive_info (Maman *self)
{
char *result = maman_get_expensive_info (self);
self-priv-expensive_info = NULL;
return result;
}
Hope those thoughts help.
Ciao,
Mathias
--
Mathias Hasselmann [EMAIL PROTECTED]
http://taschenorakel.de/
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.12 released
Am Freitag, den 14.09.2007, 00:53 -0400 schrieb Matthias Clasen: GTK+ 2.12.0 is now available for download at: Woohoo! Guess it's time to create a merging plan for extended layout management now? When do you think the gtk-2.12 branch will be created, so that cool new stuff can land in trunk? Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Behaviour of getters wrt dup/ref
Am Sonntag, den 16.09.2007, 12:12 -0400 schrieb Behdad Esfahbod:
On Sun, 2007-09-16 at 03:03 -0400, David Nečas (Yeti) wrote:
On Sat, Sep 15, 2007 at 11:08:38PM -0400, Behdad Esfahbod wrote:
On Fri, 2007-09-14 at 10:35 -0400, Alexander Larsson wrote:
char * g_data_input_stream_get_line (GDataInputStream *data_stream,
gsize *length,
GCancellable *cancellable,
GError **error);
This actually reads new data from the stream, so it has to dup. One
could imagine a similar call that returns some form of object instead
of a string.
I think it's pretty common in glib and pango at least to return
g_strdup'ed strings. The no-ref-count rule is mostly for objects that
have a literal ref/unref pair.
Other than that, for functions that return read data from the stream,
some people may have reasons to want to avoid malloc/free'ing on each
line. One way to work around that is to have the function take a
GString, so you can reuse the buffer from the previous line. I know
most people are not a big fan of that idea though.
The right interface for this type of functions have been
already invented: that of glibc's getline. It can allocate
new buffers, it can reuse existing buffers resizing them if
necessary -- and it can be even used with GStrings [if they
use the same memory allocator] although that's a bit dirty.
Well, that's exactly what happens if you make the API take GString.
Don't know if you try to support GString APIs, but I do not understand
any GString bashing (expect maybe for the missing reference counting).
In my opinion GString is a very useful member of the GLib API - so it
also should be used in the public API of other libraries when it makes
sense. Reading lines is such a place. A pattern I found useful for
read_line like stuff is this:
const gchar*
maman_bar_read_line (MamanBar *self, GString *buffer)
{
g_size offset;
g_return_val_if_fail (MAMAN_IS_BAR (self), NULL);
if (NULL == buffer)
{
g_string_truncate (self-priv-buffer, 0);
buffer = self-priv-buffer;
}
offset = buffer-len;
manan_bar_real_read_line (self, buffer);
return buffer-str + offset;
}
Sidenote to Alex: g_data_input_stream_get_line and its friend really
should use read as verb, not get. The verb get usually indicates
you do not change the state of an object - expect maybe for buffering
expensive data.
Ciao,
Mathias
--
Mathias Hasselmann [EMAIL PROTECTED]
http://taschenorakel.de/
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: branching GLib-2.15 and Gtk+-2.13
Am Dienstag, den 02.10.2007, 20:13 +0200 schrieb Tim Janik: there have been some pings recently on API changing bugs in bugzilla, and i've heared about other API related bugs coming up soon. so i guess next week would be a good time to branch Gtk+ for 2.13 and GLib for 2.15. at least, i intend to do it then if no one beats me at it. ;) Sounds like its time to prepare extended layout for merging! :-) Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: md5 in glib [was: Re: GtkFileChooser + thumbnails ... history?]
Am Donnerstag, den 04.10.2007, 09:06 +0200 schrieb Mikael Hallendal: That would indeed be very welcome. I also have one a SHA algorithm in Loudmouth that would be nice to get rid of. So let's finally get this in: http://bugzilla.gnome.org/show_bug.cgi?id=443648 Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Logo (was Re: GTK+ Website Review)
Am Montag, den 08.10.2007, 11:36 +0200 schrieb Kristian Rietveld: On Sun, Oct 07, 2007 at 04:22:09PM +0100, Alberto Ruiz wrote: Have anyone seen this[0] one? I think it's a great improvement over the original one. And as Xan said, we avoid the aqua-and-rounded-corners-mac-and-web20-like look and feel :) [0] http://en.wikipedia.org/wiki/Image:GTK.svg I think this one is worse than the current GTK+ logo; it looks all watery to me and the colors are very pale. Things I like about the current logo are the box concept (that has some kind of message like Matthias said earlier in this thread) and the sketchy look. The colors might be too intensive, but maybe they just need to be tango-ized and get some fading/shadow. I am certainly not against having a new, more modern, logo, but I couldn't find any I like in the logos posted in this thread so far ... Vectorized the old logo and tried to apply Tango colors and gradients to it. Not satisfied with the result - seems I've lost any art-foo I probably never had. For what's worth I am attaching the result nevertheless. Guess we should get one of the real Tango wizards to work on the logo. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ attachment: gtk-logo-no-foo.svg signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Logo (was Re: GTK+ Website Review)
Am Mittwoch, den 10.10.2007, 18:11 -0400 schrieb [EMAIL PROTECTED]: Message body is too big: 173477 bytes with a limit of 100 KB So I'll resend: Am Mittwoch, den 10.10.2007, 11:08 +0100 schrieb Alberto Ruiz: The light in the middle of the cube (in the center corner) doesn't help to make contrast with the white letters. Tango suggests to use the upper left corner as a light source and I think it would work better. Ok, modified the icon: - gtk-logo1.svg: Just cleaned up the glyphs. - gtk-logo2.svg: The same, but black glyphs. - gtk-logo3.svg: Moved the light source to the upper left corner. - gtk-logo4.svg: Same again, but bright glyphs. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ gtk-logo.tar.gz Description: application/compressed-tar signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: turning g_assert* into warnings
Am Freitag, den 12.10.2007, 11:52 +0200 schrieb Tim Janik:
note that in practice, this shouldn't change anything for programmers
(except for the ability to write better code ;)
because of G_DISABLE_ASSERT, programmers can already not rely on
failing assertions to abort their programs (only g_error will reliably
do that).
I was in strict HELL, NO! mode until I read this reasoning. Still I am
not sure if G_DISABLE_ASSERT is a misfeature, since when using g_assert*
instead of g_return* or g_warning you usually really have no good
fallback strategy and therefore accept the program crashing.
So for better error handling I'd suggest keeping the old and boring if
(blub) { g_warning ... } paradigm.
Also remember that such a dramatic that (external) programmers most
certainly do not expect their program to continue after a failed
assertion (despite the G_DISABLE_ASSERT misfeature). So not calling
abort on failed assertions could make the program eat little children,
if not worse.
So I guess what you really want is some kind of g_soft_assert or some
g_warn_if_fail.
Ciao,
Mathias
--
Mathias Hasselmann [EMAIL PROTECTED]
http://taschenorakel.de/
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GInterfaces and API Stability
Am Mittwoch, den 14.11.2007, 17:40 +0100 schrieb Murray Cumming:
On Wed, 2007-11-07 at 14:58 -0700, Mike Kestner wrote:
[snip]
While it may not break C ABI/API to add a method to an existing
GInterface, adding a method to an interface is a clear break in C#.
You
must implement all members of a C# interface, so code which previously
compiled will break when a method is added to an interface.
[snip]
Can't you just choose not to wrap that vfunc in your C# binding?
I think this is similar to a problem we have in gtkmm. When a GTK+
widget implements an extra GInterface, we can't just add a base class to
our existing C++ class, because that would break ABI in C++. So we just
don't wrap it, and tell people to use the C API when they need to use
that part of the API. It doesn't happen much, luckily.
Wouldn't it possible to implement the GInterface as C++ class and add an
operator like this to the GObject wrapper class:
public:
GLib::RefPtrGFooInterface operator () {
return GLib::wrap_interface (gobj ());
}
?
--
Mathias Hasselmann [EMAIL PROTECTED]
http://taschenorakel.de/
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Signals with gchar** arguments
It happens that you want a signal having pointers to strings (gchar**)
as argument. Those arguments are used to retrieve strings in the signal
handler, and return them to the signal emitter. A prominent real-world
example is the authenticate signal of SoupSession[1]:
static void
authenticate (SoupSession *session,
/* other arguments... */
gchar **username,
gchar **password,
gpointer user_data)
{
/* ... */
g_free (*username);
*username = g_strdup (lookup_username ());
/* ... */
}
Notice that this use of gchar** arguments is different from the usage
as NULL terminated arrays of strings, aka. G_TYPE_STRV.
Currently glib doesn't provide a fundamental type for dealing with that
kind of arguments, so usually G_TYPE_POINTER is used as argument for the
g_signal_new call registering such signals. Technically this works, but
it leads to bad API documentation. The signal argument is documented as
gpointer whilst being in fact of the type gchar**, which is quite a
difference.
So my question is: How to solve this issue?
- Introduce a new fundamental type G_TYPE_STRING_PTR duplicating
the behaviour of G_TYPE_POINTER under a new name.
- Patch gtk-doc to retrieve the real argument by inspecting for
instance the signature of the signal's virtual method?
Currently I use the approach of registering an artificial fundamental
type of the name EpcStringPtr to get proper documentation in libepc:
GType
epc_string_ptr_get_type (void)
{
static GType type = G_TYPE_INVALID;
if (!type)
{
static GTypeInfo info = {
0,/* class_size */
NULL, /* base_init */
NULL, /* base_finalize */
NULL, /* class_init */
NULL, /* class_finalize */
NULL, /* class_data */
0,/* instance_size */
0,/* n_preallocs */
NULL, /* instance_init */
NULL /* value_table */
};
static GTypeFundamentalInfo fundamental_info = {
G_TYPE_FLAG_DERIVABLE
};
info.value_table = g_type_value_table_peek (G_TYPE_POINTER);
g_assert (NULL != info.value_table);
type = g_type_register_fundamental (g_type_fundamental_next (),
g_intern_static_string
(EpcStringPtr),
info, fundamental_info, 0);
}
return type;
}
It fulfills my needs of documenting the argument type, but my feeling is
there should be a better solution for this problem. Feels like shooting
birds with cannons (to break a butterfly on a wheel?).
Ciao,
Mathias
[1]
http://library.gnome.org/devel/libsoup/2.2/SoupSession.html#SoupSession-authenticate
--
Mathias Hasselmann [EMAIL PROTECTED]
http://taschenorakel.de/
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Signals with gchar** arguments
Am Donnerstag, den 15.11.2007, 14:21 +0100 schrieb Alexander Larsson:
On Thu, 2007-11-15 at 13:06 +, Emmanuele Bassi wrote:
On Thu, 2007-11-15 at 12:52 +0100, Mathias Hasselmann wrote:
static void
authenticate (SoupSession *session,
/* other arguments... */
gchar **username,
gchar **password,
gpointer user_data)
{
/* ... */
g_free (*username);
*username = g_strdup (lookup_username ());
/* ... */
}
Notice that this use of gchar** arguments is different from the
usage
as NULL terminated arrays of strings, aka. G_TYPE_STRV.
this is probably the most evil use of signals I've seen in a while. ;-)
the SoupSession should really take a AuthenticateCallback function and
emit a signal on success or one on failure.
What gio does in the similar case of mounting is that GMountOperation
gets a ask_for_password signal. Then the implementation of this gets to
throw up some dialog and then it calls back into the GMountOperation
when it knows the answer. This also allows the ask-for-password code to
run async, and not having to recurse the mainloop (and generally be
modal).
Sounds interesting, but guess I have to read your code to understand
what __exactly__ you mean.
Ciao,
Mathias
--
Mathias Hasselmann [EMAIL PROTECTED]
http://taschenorakel.de/
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib and Gtk+ branched for 2.15.0
Am Montag, den 19.11.2007, 11:18 +0100 schrieb Tim Janik: Hay all. upstream GLib and Gtk+ have been branched now. That's cool. So I'd like to merge my extended layout work[1] now - unless someone says STOP, want to review first. Ciao, Mathias [1] As found in the extended-layout branch and Bug #101968. -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Extended Layout Summary
= allocation-y + border_width; + else +y = allocation-y + allocation-height - border_width; After that the usual natural size algorithm has been applied. When calculating natural sizes for children of GtkHBox, width-for-height negotiation is preferred over static natural size information. Same for GtkVBox, just that height-for-width negotiation is used here. 0016-table.patch This implements extended layout for GtkTable. Natural size information is collected during gtk_table_size_allocate_pass1. After that the scheme from GtkScrolledWindow is used to calculate natural size and requested size. If feel quite confused for now, as I cannot see my size-negotation work in this patch. Only see the orientation property I've added for that purpose. Have to inspect my local git repo to find that work. Hopefully I didn't wipe it by accident. 0017-extended-layout-test-suite.patch - This patch provides the extensive test suite I used to test my code. 1000-update-changelogs.patch This file contains the change log of the extended-layout branch. 1001-update-documentation.patch --- Some initial documentation. SUMMARY === So, that's all. Hope this information is helpful for review. I feel exhausted for now. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Am Dienstag, den 20.11.2007, 14:10 +0100 schrieb Vincent Untz: Hi Mathias, Le mardi 20 novembre 2007, à 13:23 +0100, Mathias Hasselmann a écrit : The solution to this problem is simple: Interpret the result of the size-request signal as absolutely minimum size and introduce a new function for expressing the natural size of a widget. Obviously something I should have asked during SoC... What about widgets that may have more than one natural size? I'm thinking of the window list here, which can group windows if necessary. Maybe that's the only case where it would be useful, and if that's true, just forget this edge case ;-) Actually its a good question and answering it should be part of the extended layout docs, I guess. The grouping feature of the window list actually is a fallback strategy, therefore the list should calculate its natural size by accumulating the natural sizes of its children in the ungrouped mode, were as it should accumulate minimum sizes in grouped mode for its own size-request. Well, unless you highly prefer the grouped mode, and see the ungrouped mode as fallback. In that uncertain case you'd also use the grouped mode for calculating natural size. Switching between grouped and ungrouped mode should happen automatically as reaction on the currently allocated size - as it is done already. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Am Dienstag, den 20.11.2007, 14:49 +0100 schrieb Vincent Untz: Le mardi 20 novembre 2007, à 14:32 +0100, Mathias Hasselmann a écrit : Am Dienstag, den 20.11.2007, 14:10 +0100 schrieb Vincent Untz: Hi Mathias, Le mardi 20 novembre 2007, à 13:23 +0100, Mathias Hasselmann a écrit : The solution to this problem is simple: Interpret the result of the size-request signal as absolutely minimum size and introduce a new function for expressing the natural size of a widget. Obviously something I should have asked during SoC... What about widgets that may have more than one natural size? I'm thinking of the window list here, which can group windows if necessary. Maybe that's the only case where it would be useful, and if that's true, just forget this edge case ;-) Actually its a good question and answering it should be part of the extended layout docs, I guess. The grouping feature of the window list actually is a fallback strategy, therefore the list should calculate its natural size by accumulating the natural sizes of its children in the ungrouped mode, were as it should accumulate minimum sizes in grouped mode for its own size-request. Well, unless you highly prefer the grouped mode, and see the ungrouped mode as fallback. In that uncertain case you'd also use the grouped mode for calculating natural size. The issue here is that the current way it works is that you can have more than one natural sizes, No, you have only one natural size. depending on the number of groups you can [Epiphany][Epiphany[Epiphany][Terminal][Terminal] This one. can become: [Epiphany ^][Terminal][Terminal] One fallback strategy. or: [Epiphany ^][Terminal ^] Another one. So it's not a bit more complex than having only a minimum size and a natural size. No, it is simple. Natural Size is the size you ultimatively prefer. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Am Dienstag, den 20.11.2007, 15:53 +0100 schrieb Vincent Untz: Assume the natural width is 500px in the first case, 350px in the second case and 200px in the third case. And the minimum width is 400px, 280px and 150px. In such a situation, it doesn't make much sense to allocate 250px to the window list because it's between the natural size of the third case and the minimum size of the second case. So it's better to only allocate 200px. Ok, I see the problem. So maybe natural-size should be renamed to preferred-size? For supporting your feature there should be a separate call: void (*get_supported_sizes) (GtkOrientation orientation, GtkRequisition **sizes, guint *n_sizes); The sizes would be sorted regarding orientation - but guess we should focus on merging what we got first. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Am Dienstag, den 20.11.2007, 11:55 -0500 schrieb Ryan Lortie: This is definitely no time to go blindly adding new API. :) True. Very true. -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Get rid of deprecated widgets
Am Mittwoch, den 05.12.2007, 12:17 +0100 schrieb Mikael Hermansson: Hello! Some thoughts For years now there has been widgets that is deprecated in Gtk+ GtkList GtkCList GtkFileSel GtkCTree GtkItemFactory Imho it really is time to kill this or atleast add an option in Makefile/configure to not include them as default. If there still is apps that using this old API(is there any???) they should just copypaste it to theyr project or just migrate to the new widgets. I am also supporting this idea for a long time: There is no point in deprecating code, if you plan to support it forever. Regarding ABI stability: That old code could be moved into libgtk-compat-2.0.so. So programs that still want to use deprecated widgets: - link against an old version of gtk - for what other reason gtk is using libtool's -version-info switch? - link against libgtk-compat-2.0. Its really pointless to pay of this old stuff everyday, when none of your daily programs uses those old and deprecated symbols. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Am Dienstag, den 20.11.2007, 20:45 -0500 schrieb Behdad Esfahbod:
On Tue, 2007-11-20 at 20:09 -0500, Behdad Esfahbod wrote:
On Tue, 2007-11-20 at 07:23 -0500, Mathias Hasselmann wrote:
When a container widget got more space allocated than requested, it
considers the difference between natural and requested size of its
children to distribute that additional space, in relation to the child's
difference between natural and minimum-size. Let's use an example for
demonstration:
Assume we have a container with two children. Both children request
a_min = b_min = 50 pixels as minimum size. The first child announces
a_nat = 100 pixels, the second announces b_nat = 200 pixels as
natural size.
This gives a requested size of c_min = 100 pixels, and a natural
size of 300 pixels (c_nat) for the container. Now the container gets
allocated at a size of 200 pixels (c_cur). This are 100 pixels to
distribute (c_gap).
So the first child gets:
a_cur = a_min + c_gap * (a_nat - a_min) / (c_nat - c_nat)
= 50+ 100 * 50 / 200
= 75 pixels.
The second child gets:
b_cur = b_min + b_gap * (b_nat - b_min) / (c_nat - c_nat)
= 50+ 100 * 150 / 200
= 125 pixels.
Something that Ryan brought up, and I was hoping that Havoc answer is
that the above algorithm is not optimal, you can easily do better.
Quoting Havoc's words: bring smaller items up to natural size first.
Read his entire TEXT LAYOUT THAT WORKS PROPERLY? post here:
http://log.ometer.com/2006-10.html
Without checking HippoCanvas's implementation, I think this is how it
should work:
Say there are n child widgets c^0 .. c^{n-1}, let
c^i_diff = c^i_nat - c^i_min
We want to assign c^i_gap such that the sum of c^i_gap's is equal to
c_gap, the container's extra space to distribute. We only consider the
case that there's not enough space for all children to take their
natural size. The goals we want to achieve:
a) Maximize number of children taking their natural size.
b) The allocated size of children should be a continuous function of
c_gap. That is, increasing the container size by one pixel should never
make drastic changes in the distribution.
Goal a rules your current algorithm out as yours essentially keeps all
children off their natural size until there's enough room for all.
Goal b means that you cannot start from the least child gap, fulfill
them and then distribute the remaining gap between the rest of the
children, because when enough gap becomes available for you to
accommodate one more natural child, the allocations jump
noncontinuously.
This algorithm achieves both goals: Distribute gap to children equally
(not linearly) and not more than they need. That is:
- Sort children with decreasing c^i_diff. Use child order in the
container to break ties.
I have some concerns that the sorting step changes the complexity class
for some containers from O(n) to O(n log n). On the other hand we have
O(n^2) in GtkTable already. So probably this doesn't hurt too much, I
guess.
- Allocate like this:
for (i = n - 1; i = 0; i--)
{
double share = (double) c_gap / (i + 1);
if (share = c^i_diff)
c^i_gap = c^i_diff;
else
c^i_gap = ceil (share);
c_gap -= c^i_gap;
}
So it sounds interesting to try. But as Matthias pointed out already,
the use of natural size information is an implementation detail. So the
question is, if I should try that variant before my code is merged.
Something completely unrelated: now that you are adding extended layout
features, should we switch to doubles or some fixed subpixel format for
size negotiation? The idea being, making it easier to make Gtk+
dpi-independent in the future.
From my observation late conversion to integer values could save some
pixels wasted due pessimistic rounding, which would be another
advantage.
Ciao,
Mathias
--
Mathias Hasselmann [EMAIL PROTECTED]
http://taschenorakel.de/
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: SoupInputStream / trying out gio
Am Mittwoch, den 05.12.2007, 13:33 +0100 schrieb Alexander Larsson: On Wed, 2007-12-05 at 12:56 +0100, Mathias Hasselmann wrote: Specially as you can use #undef in your C code, when stuck with a platform doing such stupidities... Thats fine inside glib, but if you export these symbols in public headers you're forcing all applications to do said #undef:s. And such stupid platforms include linux and glibc. Only recently samba had to change a structure member name from close to close_fn due to this, and I had to handle the fallout in gnome-vfs. Oh! Really!? Crap. Stupid C pre-processor. :-( Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: SoupInputStream / trying out gio
Am Mittwoch, den 05.12.2007, 09:24 -0500 schrieb Morten Welinder: Specially as you can use #undef in your C code, when stuck with a platform doing such stupidities... Aha, a member of the standards-don't-apply-to-me school, :-) No, just the don't worry too much about the sky might fall down school. Well, but as Alex mentioned, sky has fallen already - in this case - and I only can repeat myself: Oh! Really!? Crap. Stupid C pre-processor. :-( Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Am Dienstag, den 20.11.2007, 15:41 -0500 schrieb Havoc Pennington: Hi, While I haven't looked at the patches in detail, based on your writeup it feels like the interfaces here will make it a little hard to implement in widgets. [...] I had your suggestion in mind all the time, when implementing the extended layout stuff, but at least for the existing container widgets in GTK+ calculating minimum and natural size at the same time would have resulted in more complicated code, as many variables would have to be duplicated: One set of variables to hold state for minimum size calculation, one set for natural size. So the pattern I successfully used was adding a flag to the old size_request implementation indicating weither requested size, or natural size is needed. In the requested size case only gtk_widget_size_request is called for children, in the natural size case the extended layout hints were tried first, with as fallback gtk_widget_size_request. My implementations of GtkWidgetClass::size_request and GtkExtendedLayoutIface::natural_size just redirect to that function, using the correct flag. After finding that pattern, adding natural size support to existing container widgets was quite trivial. Another thing I'm not clear on from your mail is the padding stuff; basically, it looks like every widget implements padding support for itself. In that case, what's the point of having get_padding in the generic extended layout interface? I mainly needed it, when trying to implement baseline alignment for GtkBin derived widgets: GtkBinClass doesn't have any padding for additional virtual functions, so I abused the extended-layout interface to get that information. Guess it can be ignored for now, as I didn't manage to get baseline alignment working - all tough using extended layout hints to add padding to all widgets, without using GtkAlignment sounds quite interesting. Well, and you are right: Using GtkBorder is quite wasteful in terms of memory usage. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: SoupInputStream / trying out gio
Am Mittwoch, den 05.12.2007, 11:17 +0100 schrieb Mathieu Lacage: On Wed, 2007-12-05 at 09:28 +0100, Alexander Larsson wrote: On Tue, 2007-12-04 at 15:59 -0500, Morten Welinder wrote: I added an extra check for -write != NULL in the splice case (because write() already did that) and commited. I would be to avoid having struct members called write. That is a reserved symbol and if the C library decides to use a macro you will have some very interesting effects. Oh, yeah. Maybe we should rename it to something like _write? What other symbols can be macros like this? close? read? Pretty much everything, yes. I doubt it makes any sense to try to protect yourself from such stupidity. Specially as you can use #undef in your C code, when stuck with a platform doing such stupidities... Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: volume:// uri support
Am Donnerstag, den 13.12.2007, 01:17 -0500 schrieb David Zeuthen: There's a screenshot here showing integration into Nautilus http://people.freedesktop.org/~david/gvfs-hal-2-persistent-volume-uris.png Woah! Wtf! That URL in the screenshot makes me wish we'd have MS-DOS style drive letters! That wish scares me. There must be a better solution than this geek style techie stuff. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: volume:// uri support
Am Donnerstag, den 13.12.2007, 02:07 -0500 schrieb David Zeuthen: On Thu, 2007-12-13 at 08:01 +0100, Mathias Hasselmann wrote: Am Donnerstag, den 13.12.2007, 01:17 -0500 schrieb David Zeuthen: There's a screenshot here showing integration into Nautilus http://people.freedesktop.org/~david/gvfs-hal-2-persistent-volume-uris.png Woah! Wtf! That URL in the screenshot makes me wish we'd have MS-DOS style drive letters! That wish scares me. There must be a better solution than this geek style techie stuff. Why do think the URI would ever be displayed in the UI? The screenshot? (In fact, if you want to avoid implementations details like URI's leaking into the UI one way of solving that problem is to make them really ugly.) Might be true. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Name of the utility library (Was: GIO API review)
Am Donnerstag, den 13.12.2007, 12:17 +0100 schrieb Alexander Larsson: If we add things like GSettings to libgio (to avoid adding yet more .so's) then things look even more weird. GIOSettings? Off-topic, but random though since we couldn't find a name of the utility .so between libgobject and libgtk yet. What's about libgcore.so? Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Force redrawing of a window
Am Dienstag, den 18.12.2007, 00:33 + schrieb Xaero: Hi, I added an rgba colormap to a screen (using gdk_screen_get_rgba_colormap and gtk_widget_set_default_colormap); The result is that the change affects only new created windows, while those which already exist remain the same. Is there a solution? I have not worked with RGBA visuals yet, but from my theoretical understanding you cannot chance the visual of existing __X11__ windows. Therefore I'd try to call gtk_widget_unrealize(), followed by gtk_widget_realize() on your window. I hope this information helps. This list has the purpose of coordinating development of the library itself, btw. For questions regarding use of GTK+ there are the gtk-list and the gtk-app-devel-list mailing lists. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_format_file_size_for_display()
Am Dienstag, den 18.12.2007, 23:01 +0100 schrieb Sven Neumann: Hi, On Tue, 2007-12-18 at 16:45 -0500, David Zeuthen wrote: On Tue, 2007-12-18 at 14:50 -0600, Federico Mena Quintero wrote: Should this be called generically g_format_size_for_display()? You could use it for more than file sizes (free RAM in gnome-system-monitor, etc.). It's here btw http://svn.gnome.org/viewvc/glib/trunk/glib/gfileutils.c?revision=6076view=markup char *g_format_file_size_for_display (goffset size); Ideally this one needs to take another parameter indicating whether you want 1kb = 1000 bytes or 1kb = 1024 bytes. We should also decide then whether the displayed size should use MB or MiB, see http://en.wikipedia.org/wiki/Mebibyte and http://www.iec.ch/zone/si/si_bytes.htm I am all for SI units, even it writing MiB could cause some users to believe, we are too stupid to spell. Seemingly random switching between 1000 and 1024 whouldn't really help - I guess: Imagine some user wants to copy a 64 MiB file from some 1024 to some 1000 scale media: WTF doesn't this 64 MB file (64 * 2^10 bytes) fit on this 64 MB stick (64 * 10^6 bytes)? Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Am Dienstag, den 20.11.2007, 15:41 -0500 schrieb Havoc Pennington: Then the following default implementations: - all four of the new functions have default implementations that invoke the current size_request and use it for both min and natural size; so unmodified widgets still support the new interface So you suggest, that GtkWidget implements GtkExtendedLayout? Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Am Donnerstag, den 20.12.2007, 11:46 -0500 schrieb Havoc Pennington:
Hi,
Mathias Hasselmann wrote:
Am Dienstag, den 20.11.2007, 15:41 -0500 schrieb Havoc Pennington:
Then the following default implementations:
- all four of the new functions have default implementations that
invoke the current size_request and use it for both min and natural
size; so unmodified widgets still support the new interface
So you suggest, that GtkWidget implements GtkExtendedLayout?
Several factors I can think of here.
First when implementing each container, it would be nice to avoid:
if (is_extended_layout(child)) {
use new request API
} else {
use old size request API
}
One solution would be that GtkWidget automatically implements extended
layout in terms of size request. Another solution would be just a
convenience function that does the above.
Yes, it makes sense to implement GtkExtendedLayout at GtkWidget level
already. This step has quite some potential to simplify code.
I'm guessing your patch already had a solution to this, I don't remember
what it was.
Two, when implementing a widget, it would be good to avoid writing both
the old size request and the new extended layout. So, one way to do that
is that in GtkWidget there's a default implementation of size request
that invokes extended layout. This may require GtkWidget to implement
extended layout, or maybe the default impl of size request could do
GTK_IS_EXTENDED_LAYOUT(), that might be fine too. Then GtkWidget would
not have to implement extended layout.
The solution I used, was adding a flag, respectively a callback to the
old size_request method indicating the operation mode (minimum
size/natural size). My size_request implementation called that now
internal function with minimum-size arguments, the natural_size
implementation called with natural-size arguments.
Ugly, compared to the smart choice of fallback behavior you suggest.
I'll modify my patches, so that all containers directly use the extended
layout interface, without any if/else mambo for child measurement.
Third, since implementing an interface requires extra boilerplate
GObject stuff, it would be convenient for authors of a custom widget if
GtkWidget already did the boilerplate for them. Since for newly-written
custom widgets, the recommendation would be to always support extended
layout.
I don't see the boilerplate savings you talk about? As far as I
understand GObject interfaces, you always need this this single-line
boilerplate for overriding interface methods:
G_DEFINE_TYPE_WITH_CODE (MamanBar, maman, GTK_TYPE_WIDGET,
G_IMPLEMENT_INTERFACE (GTK_TYPE_IFACE, maman_bar_iface_init))
Ciao,
Mathias
--
Mathias Hasselmann [EMAIL PROTECTED]
Openismus GmbH: http://www.openismus.com/
Personal Site: http://taschenorakel.de/
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Extended Layout and Size Groups
Seems GtkSizeGroup has to be modified to cache and modify natural sizes.
See attached picture for details.
Ciao,
Mathias
--
Mathias Hasselmann [EMAIL PROTECTED]
Openismus GmbH: http://www.openismus.com/
Personal Site: http://taschenorakel.de/
inline: extended-layout-and-size-groups.png#include gtk/gtk.h
#include math.h
static void
size_group_toggled_cb (GtkToggleButton *button,
GtkSizeGroup*group)
{
if (gtk_toggle_button_get_active (button))
gtk_size_group_set_mode (group, GTK_SIZE_GROUP_HORIZONTAL);
else
gtk_size_group_set_mode (group, GTK_SIZE_GROUP_NONE);
}
static void
ellipsize_toggled_cb (GtkToggleButton *button,
GtkWidget *vbox)
{
GList *rows, *cells, *iter;
PangoEllipsizeMode mode;
if (gtk_toggle_button_get_active (button))
mode = PANGO_ELLIPSIZE_END;
else
mode = PANGO_ELLIPSIZE_NONE;
rows = gtk_container_get_children (GTK_CONTAINER (vbox));
for (iter = rows; iter; iter = iter-next)
{
if (!GTK_IS_CONTAINER (iter-data))
break;
cells = gtk_container_get_children (iter-data);
if (cells GTK_IS_LABEL (cells-data))
gtk_label_set_ellipsize (cells-data, mode);
g_list_free (cells);
}
g_list_free (rows);
}
int
main (int argc,
char *argv[])
{
GtkWidget *window, *vbox, *button;
GtkSizeGroup *groups[2];
gint x, y;
gtk_init (argc, argv);
for (x = 0; x G_N_ELEMENTS (groups); ++x)
groups[x] = gtk_size_group_new (GTK_SIZE_GROUP_NONE);
vbox = gtk_vbox_new (FALSE, 6);
gtk_container_set_border_width (GTK_CONTAINER (vbox), 6);
for (y = 0; y 4; ++y)
{
GtkWidget *hbox = gtk_hbox_new (FALSE, 6);
for (x = 0; x 2; ++x)
{
gchar *text = g_strdup_printf (Label #%.0f.%d, pow(10, y), x + 1);
GtkWidget *label = gtk_label_new (text);
g_free (text);
if (!x)
gtk_label_set_ellipsize (GTK_LABEL (label), PANGO_ELLIPSIZE_END);
else
gtk_box_pack_start (GTK_BOX (hbox), gtk_vseparator_new (), FALSE, TRUE, 0);
gtk_box_pack_start (GTK_BOX (hbox), label, 1 == x, TRUE, 0);
gtk_size_group_add_widget (groups[x], label);
}
gtk_box_pack_start (GTK_BOX (vbox), hbox, FALSE, TRUE, 0);
}
gtk_box_pack_start (GTK_BOX (vbox), gtk_hseparator_new (), FALSE, TRUE, 0);
for (x = 0; x G_N_ELEMENTS (groups); ++x)
{
gchar *text = g_strdup_printf (Size Group #%d, x + 1);
button = gtk_check_button_new_with_label (text);
gtk_box_pack_start (GTK_BOX (vbox), button, FALSE, TRUE, 0);
g_free (text);
g_signal_connect (button, toggled, G_CALLBACK (size_group_toggled_cb), groups[x]);
}
button = gtk_check_button_new_with_label (Ellipsize);
gtk_box_pack_start (GTK_BOX (vbox), button, FALSE, TRUE, 0);
gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (button), TRUE);
g_signal_connect (button, toggled,
G_CALLBACK (ellipsize_toggled_cb),
vbox);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_container_add (GTK_CONTAINER (window), vbox);
gtk_widget_show_all (window);
g_signal_connect (window, destroy,
G_CALLBACK (gtk_main_quit),
NULL);
gtk_main ();
return 0;
}
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Am Dienstag, den 20.11.2007, 15:41 -0500 schrieb Havoc Pennington:
What if the API for GTK+ were something like the above, plus a
width-for-height variant, so rename the above two:
get_desired_width(int*,int*)
get_desired_height_for_width(int,int*,int*)
and add:
get_desired_height(int*,int*)
get_desired_width_for_height(int,int*,int*)
Then the following default implementations:
- all four of the new functions have default implementations that
invoke the current size_request and use it for both min and natural
size; so unmodified widgets still support the new interface
- the default implementation of size_request
(gtk_widget_real_size_request) is modified to do something like
You mean do_size_request() in gtksizegroup.c, don't you?
gtk_widget_real_size_request just returns cached data since size groups
were introduced.
if (widget has height-for-width feature) {
get_desired_width(widget, min_width, NULL);
get_desired_height_for_width(widget, min_width, min_height,
NULL);
This API would require to calculate the size of GtkLabel for at least
three times:
1) get_desired_width
2) get_desired_height_for_width with min_width
3a) get_desired_height_for_width with allocated width of the
parent in vertically aligned containers like GtkVBox
3b) get_desired_width_for_height with allocated height of the
parent in horizontally aligned containers like GtkHBox
Why is it sensible to calculate the size three times?
Wouldn't it be better to replace size_request with
void get_desired_size (GtkRequisition *minimum,
GtkRequisition *natural);
Your get_desired_height_for_width and get_desired_width_for_height
functions would keep the signature you suggested (expect that I'd drop
the word desired).
I cannot imagine situations, where you are without size restrictions,
but cannot trivially retrieve the other dimensions of a desired size.
So we really should calculate both dimension in one single step.
The point is, in newly-written widgets ideally there is no need to code
the now-deprecated size_request; and also for most widgets hopefully no
need to implement width-for-height since that's something of a strange case.
How to react when a library user adds a handler to size-request signal
of a modern widget? Simply ignore it? Would be quite nasty if each
implementation of get_desired_size would have to emit and handle that
signal.
That's a bit tricky for GTK since there's legacy gunk in the way, but I
think it's the ideal.
That comment was directed to the padding stuff, we do not discuss right
now. Nevertheless it's also right for the new size request. Specially
since size groups were hacked in at some point in history. That's why
I've chosen the less ambitious way of adding a simple get_natural_size
method: Less interaction with legacy code.
Ciao,
Mathias
--
Mathias Hasselmann [EMAIL PROTECTED]
Openismus GmbH: http://www.openismus.com/
Personal Site: http://taschenorakel.de/
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [PATCH] example for gtk-demo demonstrating offscreen-rendered widgets with reflection-effect
A really useful addition for gtk-demo, demonstrating that GTK+ is ready for The Bling. Matthias (Clasen), permission: Permission to commit? Am Montag, den 24.12.2007, 01:05 +0100 schrieb Mirco Müller: Am Sonntag, den 23.12.2007, 14:56 +0100 schrieb Sven Neumann: + color[0] = (gdouble) style-bg[GTK_STATE_NORMAL].red; + color[1] = (gdouble) style-bg[GTK_STATE_NORMAL].green; + color[2] = (gdouble) style-bg[GTK_STATE_NORMAL].blue; + color[0] /= (gdouble) 0x; + color[1] /= (gdouble) 0x; + color[2] /= (gdouble) 0x; + cairo_set_source_rgb (cr, color[0], color[1], color[2]); You probably want to use gdk_cairo_set_source_color() instead. Agreed. Here's the updated patch. Best regards... Mirco ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Mathias Hasselmann [EMAIL PROTECTED] Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: State of natural size, Havoc/Behdad style
Seems I didn't get all details of Behdad's algorithm.
Fixed. Like it much better now:
http://taschenorakel.de/media/movies/natural-size-behdad-style.ogg
TODO:
- get size-group-natural-size interaction halfway right.
- get agreement on code/API (commit?)
- factor out Behdad's/Havoc's natural size algorithm for reuse
Am Dienstag, den 08.01.2008, 19:17 +0100 schrieb Mathias Hasselmann:
Attached the current state of natural size, with an API similiar to
Havoc's wishes and implementing the natural size allocation they both
suggested.
Havoc suggest to have two methods: get_desired_width() and
get_desired_height(), but I implemented get_desired_size(), since I do
not see how to implement this for GtkLabel, without recalculating the
entire layout four times on each desired size request.
--
Mathias Hasselmann [EMAIL PROTECTED]
Openismus GmbH: http://www.openismus.com/
Personal Site: http://taschenorakel.de/
diff -u b/gtk/gtkhbox.c b/gtk/gtkhbox.c
--- b/gtk/gtkhbox.c
+++ b/gtk/gtkhbox.c
@@ -169,7 +169,7 @@
}
static gint
-gtk_vbox_compare_gap (gconstpointer p1,
+gtk_hbox_compare_gap (gconstpointer p1,
gconstpointer p2,
gpointer data)
{
@@ -178,16 +178,14 @@
const GtkBoxSpreading *c2 = p2;
const gint d1 = MAX (sizes[c1-index].natural_size -
- sizes[c1-index].minimum_size,
- 0);
+ sizes[c1-index].minimum_size, 0);
const gint d2 = MAX (sizes[c2-index].natural_size -
- sizes[c2-index].minimum_size,
- 0);
+ sizes[c2-index].minimum_size, 0);
- gint delta = (d1 - d2);
+ gint delta = (d2 - d1); /* sort descending by gap... */
- if (0 == delta)
-delta = (c1-index - c2-index);
+ if (0 == delta) /* ...and position on draw. */
+delta = (c2-index - c1-index);
return delta;
}
@@ -209,6 +207,8 @@
nexpand_children = 0;
children = box-children;
+ /* Count number of visible children. */
+
while (children)
{
child = children-data;
@@ -236,7 +236,7 @@
gint width;
gint extra;
- gint x, i;
+ gint i, x;
width = (allocation-width - border_width * 2 -
(nvis_children - 1) * box-spacing);
@@ -247,7 +247,7 @@
}
else
{
- /* Retreive desired size for visible children */
+ /* Retreive desired size for visible children. */
for (packing = GTK_PACK_START; packing = GTK_PACK_END; ++packing)
{
@@ -275,23 +275,51 @@
}
}
- /* Sort children by difference between natural and minimum size */
+ /* Distribute the container's extra space c_gap. We want to assign
+ * this space such that the sum of extra space assigned to children
+ * (c^i_gap) is equal to c_cap. The case that there's not enough
+ * space for all children to take their natural size needs some
+ * attention. The goals we want to achieve are:
+ *
+ * a) Maximize number of children taking their natural size.
+ * b) The allocated size of children should be a continuous
+ * function of c_gap. That is, increasing the container size by
+ * one pixel should never make drastic changes in the distribution.
+ * c) If child i takes its natural size and child j doesn't,
+ * child j should have received at least as much gap as child i.
+ *
+ * The following code distributes the additional space by following
+ * this rules.
+ */
+
+ /* Sort descending by gap and position. */
g_qsort_with_data (spreading,
nvis_children, sizeof (GtkBoxSpreading),
- gtk_vbox_compare_gap, sizes);
+ gtk_hbox_compare_gap, sizes);
- for (i = 0; width 0 i nvis_children; ++i)
+ /* Distribute available space.
+ * This master piece of a loop was conceived by Behdad Esfahbod.
+ */
+ for (i = nvis_children - 1; i = 0; --i)
{
- extra = sizes[spreading[i].index].natural_size
-- sizes[spreading[i].index].minimum_size;
-
- extra = MIN (width, extra);
- width -= extra;
+ /* Divide remaining space by number of remaining children.
+ * Sort order and reducing remaining space by assigned space
+ * ensures that space is distributed equally.
+ */
+ gint glue = (width + i) / (i + 1);
+ gint gap = sizes[spreading[i].index].natural_size
+ - sizes[spreading[i].index].minimum_size;
+ extra = MIN (glue, gap);
sizes[spreading[i].index].minimum_size += extra;
+
+ width -= extra
Re: GIO API review
Am Donnerstag, den 13.12.2007, 17:31 +0100 schrieb Alexander Larsson:
typedef enum {
G_FILE_QUERY_INFO_FLAGS_NONE = 0,
G_FILE_QUERY_INFO_NOFOLLOW_SYMLINKS = (10)
}
vs
typedef enum {
G_FILE_MONITOR_FLAGS_NONE = 0,
G_FILE_MONITOR_FLAGS_MONITOR_MOUNTS = (10)
} GFileMonitorFlags;
What do people think is the best approach here?
To my knowledge GTK+ would call them:
typedef enum { /* flags */
G_FILE_QUERY_INFO_NONE = 0,
G_FILE_QUERY_INFO_NOFOLLOW_SYMLINKS = (10)
} GFileQueryInfoFlags;
and
typedef enum { /* flags */
G_FILE_MONITOR_NONE = 0,
G_FILE_MONITOR_MONITOR_MOUNTS = (10)
} GFileMonitorFlags;
A problem is the doublicate monitor, so the second value should be
something like:
G_FILE_MONITOR_WATCH_MOUNTS
Ciao,
Mathias
--
Mathias Hasselmann [EMAIL PROTECTED]
http://taschenorakel.de/
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_format_file_size_for_display()
Am Dienstag, den 18.12.2007, 23:01 +0100 schrieb Sven Neumann: Hi, On Tue, 2007-12-18 at 16:45 -0500, David Zeuthen wrote: On Tue, 2007-12-18 at 14:50 -0600, Federico Mena Quintero wrote: Should this be called generically g_format_size_for_display()? You could use it for more than file sizes (free RAM in gnome-system-monitor, etc.). It's here btw http://svn.gnome.org/viewvc/glib/trunk/glib/gfileutils.c?revision=6076view=markup char *g_format_file_size_for_display (goffset size); Ideally this one needs to take another parameter indicating whether you want 1kb = 1000 bytes or 1kb = 1024 bytes. We should also decide then whether the displayed size should use MB or MiB, see http://en.wikipedia.org/wiki/Mebibyte and http://www.iec.ch/zone/si/si_bytes.htm I am all for SI units, even it writing MiB could cause some users to believe, we are too stupid to spell. Seemingly random switching between 1000 and 1024 whouldn't really help - I guess: Imagine some user wants to copy a 64 MiB file from some 1024 to some 1000 scale media: WTF doesn't this 64 MB file (64 * 2^10 bytes) fit on this 64 MB stick (64 * 10^6 bytes)? Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: pango_layout_set_height()
Am Dienstag, den 22.01.2008, 05:14 -0500 schrieb Behdad Esfahbod: - Most of the time you have allocated height and that's positive. So this is relevant only in size_request(), not size_allocate(). In size_request() it's probably a very valid argument, but one may still use 2*font_metrics.height. Which one is more common (using actual text, or font metrics). Damn, you are more clever than me. Guess this would be sufficient for calendar details. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Move to LGPL3
Am Sonntag, den 16.03.2008, 07:49 +0100 schrieb Jean Bréfort: Le samedi 15 mars 2008 à 21:43 +0100, Christian Persch a écrit : Hi Jean; Am Samstag, den 15.03.2008, 21:09 +0100 schrieb Jean Bréfort: Hmm, and what will happen to applications using at least one GPLv2-only libraries? This might indeed pose a problem, though I'm not sure how major it is. I have to admit that it is however not a theoretical problem, since we just found out that we do depend on one such library in Gnome: evince uses libpoppler which is a fork of Xpdf, and it is GPL version 2 only. Other affected projects are Goffice (GPL-v2 only) and all those which depend on it, namely Gnumeric, Abiword, Gnucash and GChemUtils (the last also use OpenBabel, another GPL-v2 only library). Seems that all the projects I'm involved in would be affected. Some can be relicensed, but probably not all, just because some previous contributors seem to have disappeared from the earth surface. I am really wondering what's the reason for FSF claiming, that programs licenced GPL-2 only are not allowed to use LGPL-3 libraries. The LGPL-3 allows non-free, proprietary programs to use LGPL-3 libraries, but excludes free software, licensed GPL-2 only? This sounds absurd to me! Is the FSF spreading FUD with their license matrix? Why doesn't the matrix have footnotes explaining that absurd conflict? Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Move to LGPL3
Am Samstag, den 15.03.2008, 21:48 +0100 schrieb Tim Janik: On Sat, 15 Mar 2008, Andrew Cowie wrote: This topic was discussed recently on foundation-list. http://mail.gnome.org/archives/foundation-list/2008-March/msg00032.html In summary, attempting to relicence the library would be, in practise, impossible. No further benefit is gained by discussing this topic further. Updating the glib gtk+ headers to LGPLv3 is not relicensing. Alternative interpretation: You fork under LGPLv3 or later, as permitted by LGPLv2.1 or later and keep LGPLv3 or later for the fork. Well, but I am no expert on legal stuff... Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minutes: Foreign OSes BoF
Am Sonntag, den 16.03.2008, 11:22 -0400 schrieb Dominic Lachowicz: Hi Tor, On Sun, Mar 16, 2008 at 4:27 AM, Tor Lillqvist [EMAIL PROTECTED] wrote: I think that they're ready to go. Outside of the GTK+ tree, they won't get much testing. Do you think they cam unconditionally replace the traditional loaders that depend on external libraries for Win32, or should we add some --disable-gdiplus-loaders switch to the configury? I'd have them unconditionally replace the traditional loaders wherever the format is supported by the GDI+ plugin. I'd unconditionally add the formats supported by this plugin but not by GdkPixbuf (i.e. WMF and EMF). And I'd still build the traditional XPM, ANI, etc. plugins, as they don't have any external dependencies. So what are your plans for PNG tEXt records? Does GDI+ support them? Unconditionally replacing the libpng loader, without supporting that records would be a regression. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minutes: Foreign OSes BoF
Am Montag, den 17.03.2008, 21:18 -0400 schrieb Dominic Lachowicz: * The functions that enumerate GDI+'s loaders simply don't exist in the 1.0 version of the GDI+ DLL. They may exist in the 1.1 DLL (which is not re-distributable AFAIK), but that's only in Windows Vista, and we know how great Vista adoption is going. Not sure if .NET's image loaders use GDI+ 1.0 or 1.1 or if they are fully managed (the API doesn't look like that). Well, but I've successfully enumerated image loaders using this method: System.Drawing.Imaging.ImageCodecInfo.GetImageEncoders() So maybe the functionality just is well hidden for GDI+ 1.0? Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GSoC proposal: gtk+ bindings for prolog
Am Dienstag, den 01.04.2008, 12:56 +0200 schrieb Jean-Yves Lefort: On Mon, 31 Mar 2008 22:52:09 +0200 Ben Torfs [EMAIL PROTECTED] wrote: As a fan of both the prolog programming language and the GTK+ toolkit (as a user), I was wondering why the GTK page makes no mention of any prolog bindings. For those of you that are unfamiliar: prolog is a declarative language (like haskell, but very different in the way it works). Until now, it has mostly been used as a research tool in artificial intelligence (theorem proving, knowledge representation, etc.) However, I believe it has a lot of potential to be used for desktop applications too. Haskell too, for example, has also proven to be a success for end-user applications (gtk+ bindings exist). I think prolog is just a breeze to program in, and I would love to push it further! Specifically, by implementing GTK+ bindings for this language myself, as a Google Summer of Code project. Implementing all functions would probably be too much work for a 3-month project, but it could certainly deliver a basic subset, as a basis for myself and other developers to continue working on later. It should take much less than 3 months. I've implemented exhaustive GTK+ bindings for a language I'm designing in a couple of days. The internal API representation suitable for use by a generator program can be automatically obtained: - for types and methods, by parsing the C headers Please don't replicate efforts done by other binding authors, please. Really. Read the GTK+ Hackfest papers about GTK+ 3.0 and look for recent information about GObject introspection support. Search for pybank, which is a prototype[?] for a next-generation GObject binding and understand how it works. Perl has a related project if you prefer that language, but I don't know its name. After getting a basic idea about recent binding efforts you might want to join #introspection at irc.gimp.org. Btw, why is the language-bindings list dead? Which mailing list is used for discussing (and documenting) pybank and introspection efforts? All this shiny infrastructure is not in place yet, but hopefully it will be next spring. With that infrastructure creation of Prolog bindings looks much more useful and educational that it is this year - in the sense of we do, because we can do itin a reasonable way. IMHO. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Print preview widget
Am Donnerstag, den 17.04.2008, 14:20 -0400 schrieb Behdad Esfahbod: On Thu, 2008-04-17 at 11:14 -0700, Carl Worth wrote: I can write a program where both of these are correct: Display to screen: App-Cairo-Screen Print to PDF: App-Cairo-PDF But the following is totally broken: Print preview: App-Cairo-PDF-Cairo-Screen And that's simply because there are bugs in poppler, which does the PDF-Cairo step, and poppler isn't actually involved in either the display-to-screen or print-to-pdf scenarios. Sure. But if you are printing to PDF and sending that PDF over to someone, there's advantage in the preview showing what your friend will be seeing when opening the PDF in evince... All these said, not sure what GTK-printing actually generates. If it's PS, it may be hitting a completely different set of bugs... The problem with using an external application for print previews is, that you cannot embed it into your own UI, that you cannot remote control it. You absolutely need that features when integrating the print preview into some kind of work-flow, like order processing for instance. Using an external application really doesn't work here. The round trip testing argument is artificial. You use test suites for round trip management. For print preview there are situations were you want ultimate control over the preview canvas. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About GTK+ 3.0 and deprecated things
Am Mittwoch, den 16.07.2008, 09:16 +0200 schrieb Colin Leroy: What do you plan on doing for users of your toolkit who don't have time to rewrite things every four years? One obvious option would be to stay with GTK2 forever, and to take over bug fixing for it. Another **rough** idea I always had in mind is moving all that deprecated code into some libgtk-compat library: Obviously this approach would not work for structure fields, but it should be trivial for entirely deprecated classes. This approach also should be support deprecated functions. Obviously those deprecated functions would suffer from the fact, that they cannot access internal data structures anymore. So for functions that cannot be easily be ported maybe just some stub yielding linker warnings would be created in that compat library. Filling that stub would be the task of people willing to use that deprecated function (instead of porting their code). Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal for a collection API in glib
Am Donnerstag, den 17.07.2008, 14:23 -0400 schrieb Havoc Pennington: Hi, On Thu, Jul 17, 2008 at 2:06 PM, Philip Van Hoof [EMAIL PROTECTED] wrote: You could make a GLib.Iterator that uses gobject-introspection, but I don't think you want to make gobject-introspection the one thing everybody who wants to expose collections in his API has to use and learn. I didn't mean that - I meant if you exposed collections you'd use GList or whatever, and g-i would know that it was a GList of Foo, and g-i would generate an iterator around the list based on that. Then users of the g-i API for language bindings would see only the iterator. Well, I am doing some refactoring right now and during this process it would be quite helpful if we'd have something better than GList: It would be really helpful if our GLists would express its element type. Maybe we can figure out how to do this in a sane way for GTK3? Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Translucent Scrollbars
When looking at some Android screen shots[1] I've realized that their scrollbars are translucent. That's a really nice idea IMHO. I wonder if we can implement this feature in GTK+. Ciao, Mathias [1] http://www.spiegel.de/fotostrecke/fotostrecke-34358-7.html#backToArticle=572913 -- Mathias Hasselmann [EMAIL PROTECTED] Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RFC: Deprecate GTK_{RESPONSE,STOCK}_{YES,NO}
Hi, The pure existence of GTK_RESPONSE_YES, GTK_RESPONSE_NO, GTK_STOCK_YES and GTK_STOCK_NO encourages creation of horrible user interfaces. One recent example is on Planet GNOME right now[1]. Other examples were posted on Planet GNOME in the past, and still exist in applications like OpenOffice.org. So I wonder if we should deprecated those symbols, in the hope that people obey the GNOME HIG and properly label the buttons of their message dialogs. Ciao, Mathias 1:http://libwilliam.wordpress.com/2008/08/25/alerting-users-of-mistakes/ -- Mathias Hasselmann [EMAIL PROTECTED] Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Decorating scales
Am Dienstag, den 06.01.2009, 10:29 -0500 schrieb Matthias Clasen: On Tue, Jan 6, 2009 at 12:55 AM, Tristan Van Berkom t...@gnome.org wrote: On Tue, Jan 6, 2009 at 12:41 AM, Yu Feng rainwood...@gmail.com wrote: Hi, If GtkRange were a gtk container perhaps using gtk_container_xxx with child_properties will be an alternative. GtkContainer also has bettern granularity - the programmers can modify/remove each marker individually. Unfortunately it isn't a Container. Oh yeah, time for those GContainer/GContainable interfaces, nudge nudge ;-) One way this _could_ be done is to restrict the GtkScale api to just add undecorated marks, and then have a special-purpose DecoratedScale container that would have one slot for a scale, and then allow to add other children to decorate the scale, using child properties for the position and the value. The container would then use the scale marks api to add the marks at the positions/values which its children request, and position the child widgets next to the marks. Not sure the minor benefits justify the effort, though... Weren't the GtkCellRenderer/GtkCellLayout interfaces written exactly for stuff like those marks? So maybe gtk_scale_add_mark_text() and gtk_scale_add_mark_icon() should be replaced by an implementation of the GtkCellLayout interface? Ciao, Mathias -- Mathias Hasselmann mathias.hasselm...@gmx.de http://taschenorakel.de/mathias/ http://www.openismus.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bikeshedding the invisible-char
Am Dienstag, den 20.01.2009, 11:59 +0100 schrieb Christian Dywan: Am Mon, 19 Jan 2009 21:17:50 -0500 schrieb Yu Feng rainwood...@gmail.com: Hi Federico, If I can have a word on this: The big circle is wider than most characters. Compare the following 3 patterns: (10 chars, monospace) ●● •• 1234567890 When people type in a password they don't expect it to look much longer than what has been typed, right? Although the original question has been answered already, for the record, those three examples of yours have all the very same size in my font, which happens to be monospace. Beside that, the user is only ever seeing a number of occurences of a single character. So there is nothing to compare a wider or larger character to. The whole idea behind invisible characters is that they don't reflect the actual password in the first place. I wonder if the default password character shouldn't be a style property. In that case you could use big circles for the default theme, small circles for monospaced themes and pumpkins or skulls for Halloween themes. 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: 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
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: GtkOrientable: Can widgets now be flipped?
Am Sonntag, den 08.02.2009, 18:36 +0100 schrieb Murray Cumming:
On Sun, 2009-02-08 at 14:51 +0100, Sven Herzberg wrote:
AFAIR, you can flip it of you create a GtkBox/GtkScale, but not if you
create a Gtk[HV]{Box,Scale}... Mitch?
Ah. Were those base classes (GtkBox, etc) instantiable before?
If the base classes can now already do everything then shouldn't the V/H
classes be deprecated already?
Oh, I hear you volunteer to update the gazillions lines of code in the
wild refering those classes? ;-)
I am pretty sure API users would rather switch to Qt, than to follow
this deprecation.
Well, actually those V/H classes even serve a purpose: When using them
in a derived widget you can be sure, that nobody will be that evil to
suddenly change the orientation of your derived widget.
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: GtkOrientable: Can widgets now be flipped?
Am Sonntag, den 08.02.2009, 21:04 +0100 schrieb Murray Cumming:
On Sun, 2009-02-08 at 18:47 +0100, Mathias Hasselmann wrote:
Am Sonntag, den 08.02.2009, 18:36 +0100 schrieb Murray Cumming:
On Sun, 2009-02-08 at 14:51 +0100, Sven Herzberg wrote:
AFAIR, you can flip it of you create a GtkBox/GtkScale, but not if you
create a Gtk[HV]{Box,Scale}... Mitch?
Ah. Were those base classes (GtkBox, etc) instantiable before?
If the base classes can now already do everything then shouldn't the V/H
classes be deprecated already?
A deprecation doesn't force people to change anything. It's not (yet) a
removal of the API, though I guess that is planned for the future. It is
a useful hint and it explains the apparent duplication.
Still you have to react on deprecations better soon than later, if you
want to avoid drowning some day.
Well, actually those V/H classes even serve a purpose: When using them
in a derived widget you can be sure, that nobody will be that evil to
suddenly change the orientation of your derived widget.
Apparently that's not true though.
Oh, from reading this thread I thought this would be the case, but
apparently it is not. Seems you really can change the orientation of
some Gtk[HV]Box now. Shocking.
Maybe GtkBox and friends should get an internal flag for locking that
property? Whilst changing the orientation of widgets can be useful under
certain circumstances, there are others where you don't want to permit
this. Well, but maybe I think too restrictive right now, as you can do
nonsense to derived widgets already. Thinking about evil actions like
calling gtk_container_remove() on some essential child.
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: GtkOrientable: Can widgets now be flipped?
Am Sonntag, den 08.02.2009, 21:57 +0100 schrieb Murray Cumming:
On Sun, 2009-02-08 at 21:36 +0100, Mathias Hasselmann wrote:
Am Sonntag, den 08.02.2009, 21:04 +0100 schrieb Murray Cumming:
On Sun, 2009-02-08 at 18:47 +0100, Mathias Hasselmann wrote:
Am Sonntag, den 08.02.2009, 18:36 +0100 schrieb Murray Cumming:
On Sun, 2009-02-08 at 14:51 +0100, Sven Herzberg wrote:
AFAIR, you can flip it of you create a GtkBox/GtkScale, but not if
you
create a Gtk[HV]{Box,Scale}... Mitch?
Ah. Were those base classes (GtkBox, etc) instantiable before?
If the base classes can now already do everything then shouldn't the
V/H
classes be deprecated already?
A deprecation doesn't force people to change anything. It's not (yet) a
removal of the API, though I guess that is planned for the future. It is
a useful hint and it explains the apparent duplication.
Still you have to react on deprecations better soon than later, if you
want to avoid drowning some day.
Yes, but surely that decision has been made already by the addition of
GtkOrientable?
Oh, from reading this thread I thought this would be the case, but
apparently it is not. Seems you really can change the orientation of
some Gtk[HV]Box now. Shocking.
Actually Christian Dywan says they can't flip. But I still think they
are meant (by the developers who made the change) to be deprecated so
that isn't very relevant anyway.
It is relevant, as I'd seriously question a decision to deprecate
classes as widely used as Gtk[HV]Box.
The community's effort to follow that little deprecation is close to
infiniteness. Keeping Gtk[HV]Box around costs exactly 54 lines of code
and four public symbols.
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: Compiling the girepository.h header with C++
Am Dienstag, den 10.02.2009, 18:33 -0200 schrieb Johan Dahlin: Hi Richard, 2009/2/10 Richard Dale rd...@foton.es: When I built a mixed C/C++ program, I had a couple of problems with the argument names used in functions in the girepository.h header. There were args called 'namespace' and 'type-info' and I changed them to 'gnamespace' and 'gtype-info' respectively. Please find a patch attached. Thanks for the patch, but usually the right place for this is: http://bugzilla.gnome.org/ - Product: glib, Component: introspection Perhaps just ns or nsname instead of gnamespace? Well, those abbreviations are common in XML world, but each time I read them I wonder what XML has to do with National Socialism. Well, but guess that's only a problem affecting Germans. 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: GLib plans for the next cycle
Am Mittwoch, den 11.02.2009, 11:31 + schrieb Alberto Ruiz: 2009/2/11 Matthias Clasen matthias.cla...@gmail.com: With 2.20 winding down, I think now would be a good time to talk about what should happen in Glib 2.22. One thing that has been tossed around for a long time is that it would be really good to have DBus support on the Glib level. Would this support be optional? I'm concerned about making GLib dependant on a dbus development environment on Windows as DBus has no regular windows builds whatsoever (AFAIK). This would allow us to move forward with several things in GTK+ that will work much better if they can use DBus: - session support - unique application support Would DBus be swappable here for something else on non freedesktop environments? (Windows, Mac) Well, probably we should first answer the questions if Windows and OSX provide APIs which could serve as drop-in replacement for DBus. No idea what's available on OSX. For Windows I wonder if it's really possible to seamlessly emulate DBus via COM. DBus is quite dynamic, maybe the IDispatch interface[1] comes close? Otherwise, if those platforms don't have a proper drop-in replacement it probably would be more reasonable to really use DBus even on those platforms. Ciao, Mathias [1] http://msdn.microsoft.com/en-us/library/ms221608.aspx -- Mathias Hasselmann mathias.hasselm...@gmx.de Personal Blog: http://taschenorakel.de/mathias/ Openismus GmbH: http://www.openismus.com/ -- 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: minutes of the gtk+ team meeting - 2009-01-20
Am Mittwoch, den 18.02.2009, 01:54 + schrieb Alberto Ruiz: I plan to work on some other mockups of the website for other sections and I would like to get feedback from you guys. Awesome mockup! Let's get it in place! 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: gtk+ documentation wikified
Am Donnerstag, den 19.02.2009, 10:33 -0500 schrieb Dominic Lachowicz: 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. Still that proposed idea has some merits: Currently entry barrier for fixing GTK+ docs still is quite high. Guess the most trivial fix would be, to do what the PHP community does and attach some comment system/forum to library.gnome.org. More sophisticated would be some application that allows editing of API docs via web site and provides some way to easily merge them back. Maybe automatic commits to some separate branch? Maybe just additions to some patch queue? Don't know. But maybe a nice SoC project? Ciao, Mathias 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 -- 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: Fwd: gtk+ documentation wikified
Am Donnerstag, den 19.02.2009, 17:52 +0200 schrieb Eugene Gorodinsky: Have there been cases where documentation for some function was changed after that function appeared in the stable version? Yes, this happens frequently: Spelling errors, explanations of limitations, code examples, usage scenarios, ... In the end programmers primary are programmers, not book writers. Therefore API documentation provided by programmers always can be just a start. Still API documentation should be close to programmer's finger tips, 'cause otherwise the documentation will start to bit rot quickly. Ciao, Mathias 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. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- 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: fsync in glib/gio
Am Freitag, den 13.03.2009, 12:18 +0100 schrieb Sven Neumann: Hi, On Fri, 2009-03-13 at 08:38 +0100, Alexander Larsson wrote: If you want to you can make all i/o sync by mounting it as such. But thats of course really slow. Generally the gio file write operations are used for saving files, and people sort of expect that when save returns the file is ok on disk. Do they?? Doing file I/O asynchronously is a feature, in particular for laptop users. It improves I/O performance and it saves power. Of course it's a risk and may result in data loss under certain rare circumstances. But it's a risk that people are willing to take. Please do not ruin this by implicitly enforcing fsync. I think you don't understand the problem. Other file systems but ext3 in order=data mode are that brain dead and broken, that they lose __both__ the old and new document on power loss! This is __not__ acceptable, in no way. Maybe the time kernel hackers will realize some day, that they lost any sense for real world applications and over-optimized their file systems for write performance benchmarks. Well, but until this happens we have to suffer from fsync(). Really, loosing both versions of files really isn't an option. 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: .gitignore files
Am Freitag, den 01.05.2009, 14:10 -0400 schrieb Behdad Esfahbod: git.mk. What's this git.mk? -- 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: .gitignore files
Am Samstag, den 02.05.2009, 14:25 +0200 schrieb Vincent Untz: Le samedi 02 mai 2009, à 14:14 +0200, Mathias Hasselmann a écrit : Am Freitag, den 01.05.2009, 14:10 -0400 schrieb Behdad Esfahbod: git.mk. What's this git.mk? http://git.gnome.org/cgit/pango/tree/git.mk Vincent Oh, fancy! Nice! +1 Why isn't this brilliant logic part of automake already? :-D 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
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-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
