Merging libstarred into GTK+?
Hi, Just released libstarred 1.0 - http://gitorious.org/libstarred It provides a widget and a cell renderer for doing editable five-star ratings, but also starred favorites. You configure it to your needs. It seems feature complete to me and also seems to work properly. More testing, code review, feature requests, patches - all very welcome of course. Now I don't really have the time for maintaining such libraries in the long run, and also the stuff in the library should be of common interest for application developers. Therefore I wonder if it makes sense to add those widgets to GTK+ itself. Can I drop this code here? Ciao, Mathias -- Mathias Hasselmann mathias.hasselm...@gmx.de http://taschenorakel.de/ ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Merging libstarred into GTK+?
Am Donnerstag, den 15.12.2011, 16:27 +0100 schrieb Petr Tomasek: Just a dumb question: are other shapes/objects possible instead of starrs? There are no dumb questions! You can freely configure the chars to use per property and per style property. You also can use theme icons. The minimum and maximum rating also can be configured. http://taschenorakel.de/files/libstarred/StarredRating.html#StarredRating.properties http://taschenorakel.de/files/libstarred.png Ciao, Mathias -- Mathias Hasselmann mathias.hasselm...@gmx.de http://taschenorakel.de/ ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Merging libstarred into GTK+?
Am Freitag, den 16.12.2011, 10:03 +0400 schrieb Igor Chetverovod: Hi All, I think this widget could be added to GTK+ as a submode of the GtkScale. I'd object that, not every tool is a hammer. IMHO adding sub-modes over sub-modes over sub-modes over sub-modes instead of defining task focused class is one of the biggest design issues of GTK+: $ wc -l *.c | sort -n | tail 7291 gtktextbtree.c 8231 gtknotebook.c 8761 gtkiconview.c 9619 gtkwindow.c 9649 gtktextview.c 10463 gtkfilechooserdefault.c 10479 gtkentry.c 14572 gtkwidget.c 16443 gtktreeview.c 441157 total This approach is not scaling forever. Ciao, Mathias -- Mathias Hasselmann mathias.hasselm...@gmx.de http://taschenorakel.de/ ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-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: 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: 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: 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: 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: 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: 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
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: 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: 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
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
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
Re: So many warnning when I compiled base.c ?
Am Montag, den 11.08.2008, 17:47 +0800 schrieb Wu Yin: I wrote a Makefile for base.c, like following: +-- |# Makefile | |CFLAGS+=`pkg-config --cflags --libs gtk+-2.0` | |base:base.o | $(CC) $ -o $@ $(CFLAGS) +-- I know gcc -c make this happen, but how to change Makefile to fix it? What the Makefile should be commonly? You should not pass the linker flags to the compile stage. CFLAGS += `pkg-config --cflags gtk+-2.0` LDLIBS += `pkg-config --libs gtk+-2.0` To link your object files you should use something like this: base: base.o $(LINK.o) $^ $(LOADLIBES) $(LDLIBS) -o $@ make -p | fgrep LINK.o will show you how GNU make declares the predefined LINK.o variable. Probably you want to use some more sophisticated build system like autotools. Others believe that WAF or cmake make some sense. 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-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK - reading data from database
Am Mittwoch, den 30.07.2008, 18:33 -0700 schrieb paragasu: i am writing a gtk application to interface with postgresql database. the database contain few hundred rows. how programmer usually do this, the load the entire database content to app or just load part of it? First of all I'd suggest to have a look at libgda[1]. This library abstracts database access and also provides widgets for database access. Maybe those guys already invented the wheel you need. Otherwise I'd implement a custom list store, which first just do a SELECT COUNT(*) ... query to create empty rows, and then only fetches rows from the database when some range with still empty rows get visible. You'll easily detect the need for fetching more rows by waiting for the tree view calling your list store's get_value() method. Ciao, Mathias [1]: http://www.gnome-db.org/ -- 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-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: GTK - reading data from database
Am Mittwoch, den 30.07.2008, 18:33 -0700 schrieb paragasu: i am writing a gtk application to interface with postgresql database. the database contain few hundred rows. how programmer usually do this, the load the entire database content to app or just load part of it? First of all I'd suggest to have a look at libgda[1]. This library abstracts database access and also provides widgets for database access. Maybe those guys already invented the wheel you need. Otherwise I'd implement a custom list store, which first just do a SELECT COUNT(*) ... query to create empty rows, and then only fetches rows from the database when some range with still empty rows get visible. You'll easily detect the need for fetching more rows by waiting for the tree view calling your list store's get_value() method. Ciao, Mathias [1]: http://www.gnome-db.org/ -- 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-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-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
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: pango_layout_set_height()
Am Montag, den 21.01.2008, 23:23 -0500 schrieb Behdad Esfahbod: Hi, In pango-1.19.3 that just hit the door is the new API: void pango_layout_set_height (PangoLayout *layout, int height); Behadad, thanks alot for this very useful function! Pardon, for not commenting on the Bug yet, doing it here now. Height setting only has effect if a positive width is set on @layout and ellipsization mode of @layout is not %PANGO_ELLIPSIZE_NONE. The behavior is undefined if a height other than -1 is set and ellipsization mode is set to %PANGO_ELLIPSIZE_NONE, and may change in the future. [] - I don't like the fact that negative numbers are per-paragraph limits. But this was needed to keep compatibility with previous releases. Otherwise a third mode needed to be introduced as default to behave as previous releases. I don't have any concrete uses for the negative cases other than -1 at this time, so it's not a huge issue to me. But read below. GtkCalendar details would make use of other negative values than -1. Why can't a default value of zero be used to preserve compatible behaviour, and get arround the per-paragraph limit? 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-i18n-list mailing list gtk-i18n-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
Re: Lost Pointer when adding GTK+ to an application
Am Donnerstag, den 08.05.2008, 09:04 +0100 schrieb Rob Pearce: On Thursday 08 May 2008, Diego Rivera wrote: I believe i have made no memory errors in my console application, since it runs ok every time. However, i haven't seen the correct output from my GTK application. That's not a safe assumption. I've seen console apps with huge memory errors keep going for months or years before the problem ever shows up. Normally it's a matter of accessing beyond the allocated block, which can be reasonably harmless until you add some other code that uses the heap. ACK. Diego, you should try to run your console application with Valgrind. This amazing tool is really helpful to detect such nasty issues. 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-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-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: 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: 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: 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: Row with different columns at runtime?
Am Freitag, den 08.02.2008, 18:09 +0100 schrieb Johannes Lorenz:
Hi,
I am using GTKmm for a little project. I have a problem because I do not know
how to solve the following problem:
I have a List Store. In the most right column shall EITHER be a text,
OR be a combo box, OR be a button etc. My programme shall read a file
which shall tell it which type (text, combo, button etc.) to use for
this column in the current row.
However, I do not know how I can realize such a dynamic row. Is there a
solution?
Seems you have to write your on cell renderer. Maybe you can get it
done, by referencing all the pre-built cell renderers you need, and
forward function calls to the instance matching your data (pseudo code):
struct _FunkyCellRenderer
{
GtkCellRenderer *text;
GtkCellRenderer *combo;
GtkCellRenderer *button;
};
static void
funky_cell_renderer_some_function (GtkCellRenderer *cell, ...)
{
FunkyCellRenderer *self = FUNKY_CELL_RENDERER (cell);
switch (self-mode)
{
case TEXT_MODE:
gtk_cell_renderer_some_function (self-text, ...);
break;
...
}
}
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-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Does gtk have issues with STL?
Am Montag, den 11.02.2008, 18:19 -0500 schrieb Jacques Pelletier:
On February 11, 2008 05:37:54 pm Vallone, Anthony wrote:
From:
Vallone, Anthony [EMAIL PROTECTED]
To:
gtk-list@gnome.org
Myself, I avoid the enter/leave calls in favor of g_idle_add() as a
mechanism to queue all gui calls for the main event loop thread. Let
your other threads stick to performing the non-gui work, and you'll save
yourself from many headaches. (I wish someone told me that 3 years ago).
Hi,
I'm interested to know more about that. Is there some source code example
that
I can follow?
The pattern goes like this:
if (!g_thread_create (background_worker, job_data, joinable, error))
{
report_error (error);
return;
}
static gpointer
background_worker (gpointer data)
{
JobStruct *job = data; /* extract job description from data */
/* do everything you like, EXPECT touching widgets */
g_idle_add (report_progress, progress_data);
/* still do what your want, EXPECT touching widgets */
return result;
}
static gboolean
report_progress (gpointer data)
{
ProgressData *progress = data; /* extract progress from data */
MamanBar *ui = progress-ui; /* retreive UI handle */
gtk_label_set_text (GTK_LABEL (ui-progress_label), progress-text);
gtk_progress_bar_set_fraction (GTK_PROGRESS_BAR (ui-progress_bar),
progress-fraction);
/* UI has been update. Do not call this function again, unless
* new progress happend. In this case the function is re-added
* to the idle queue with g_idle_add().
*/
return FALSE;
}
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-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Howto use a GdkFont in Cairo?
Am Mittwoch, den 06.02.2008, 15:42 +0100 schrieb Clemens Eisserer: Hello, I am trying to convert gtk_paint_string to use Cairo only. However the Fonts which should be used is only available as GdkFont, so I wonder whats the best way to use this GdkFont in Cairo. Always looking up the font-name seems to add a lot of overhead :-/ GdkFont is from a very old era, predating inovations like Xft, Pango or cairo. Most propably you want to use pango_cairo_show_layout_line() and friends. 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-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-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: Newbie Question about Navigating API doco
Am Mittwoch, den 23.01.2008, 06:04 +1100 schrieb Peter E Dennis: I am sorry for being pedantic but this would make me believe when reading the documentation that I was to use delete-event in my program with a hyphen '-' not with an underscore '_' Is this standard notation in the documentation? Should I be reading any signals I see that contain a hyphen to substitute this with an underscore when it is written in code? Whether you use hyphen or underscore is a matter of personal preference, both variants work. 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-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Changing the foreground colour of combo boxes
Best approach would forking an existing theme engine and adjusting it to your device's special requirements. - IMHO. Am Freitag, den 18.01.2008, 13:55 +1300 schrieb Alwin Leerling: Hi, My program runs on a device on which it is very hard to see the current selected widget. I therefore wrote to functions on_button_focus_in_event and on_button_focus_out_event that set or reset the background color ( gtk_widget_modify_bg( widget, GTK_STATE_NORMAL, color_active ) and gtk_widget_modify_bg( widget, GTK_STATE_NORMAL, NULL ) respectively ) and attached these callbacks to my buttons. I tried the same trick with the combo boxes but the background does not change. Anybody got any suggestions how I can change the color of a combo box when it gets the focus? Thanks in advance Alwin ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-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-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: '.' as a TAB key
Attached one possible implementation.
Am Freitag, den 18.01.2008, 14:19 +0530 schrieb kartikay malhotra:
Thank you all for your feedback.
Dear Carlos, how do I make use of the '.' key as a TAB (\t) key? Using
the tutorial, I am able to print a TAB on the console. But I want to
use '.' key as a TAB in the GUI.
Thanks
Kartikay
On Jan 17, 2008 11:09 PM, Carlos Pereira [EMAIL PROTECTED] wrote:
Hello,
Chapter 11 of the excellent book Foundations of GTK+
Development (Andrew Krause, Apress) shows how to create a
custom widget with the functionality you want.
There is source code available in www. gtkbook.com
Best regards!
Carlos
2008/1/15 kartikay malhotra [EMAIL PROTECTED] :
Dear All,
I am making an IP address bar in GTK. It would
function as 123 . 445 . 521 . 444.
Now friends, I am facing 2 problems:
1) How to ensure that only numbers are pressed. I
don't want the user to enter alpha characters.
2) How to draw points in GTK, without using GNOME?
Many Thanks for your consideration.
--
Best Regards
Er. Kartikay Malhotra
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
--
=
Prof. Carlos José de Almeida Pereira
Universidade Estadual de Santa Cruz
Ilhéus - Bahia - Brasil
Quem agora conhece a antiga linguagem da Lua ?
Quem agora fala com a Deusa ? ...
Só as pedras agora se recordam do que a Lua nos disse há muito
tempo,
e o que nós aprendemos com as árvores, e as vozes das ervas e
dos
cheiros das flores...
(Tony Kelly, Pagan
Musings 1970)
http://www.sam.paganfederation.org/index.php?id=13amp;lang=pt
--
Best Regards
Er. Kartikay Malhotra
Sure I am this day we are masters of our fate, that the task which
has been set before us is not above our strength; that its pangs and
toils are not beyond our endurance. As long as we have faith in our
own cause and an unconquerable will to win, victory will not be denied
us. --Winston Churchill
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
--
Mathias Hasselmann [EMAIL PROTECTED]
Openismus GmbH: http://www.openismus.com/
Personal Site: http://taschenorakel.de/
#!/usr/bin/python
import gtk
def cycle_entry(widget):
box = widget.get_parent()
position, = box.child_get(widget, 'position')
position = (position + 2) % 8
sibling = box.get_children()[position]
sibling.grab_focus()
return sibling
def key_press_event_cb(widget, event):
keyval = gtk.gdk.keyval_name(event.keyval)
# allow backspace, arrows and friends...
if not event.string:
return False
# allow digits...
if event.string in '0123456789':
value = int(widget.get_text() + event.string)
# cycle when value would become too large, and no text selected
if (value 255 and not widget.get_selection_bounds()):
sibling = cycle_entry(widget)
sibling.set_text(event.string)
sibling.set_position(1)
return True
# insert the text
return False
# cycle on dot...
if event.string in '.':
if len(widget.get_text()):
cycle_entry(widget)
return True
# reject all other
return True
hbox = gtk.HBox(False, 0)
for i in range(4):
if i:
hbox.pack_start(gtk.Label('.'), False, True)
entry = gtk.Entry(3)
entry.set_width_chars(3)
entry.connect('key-press-event', key_press_event_cb)
hbox.pack_start(entry, True, True)
window = gtk.Window()
window.add(hbox)
window.show_all()
window.connect('destroy', gtk.main_quit)
gtk.main()
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
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: 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: GtkTextView drag_data_received handler
Am Freitag, den 04.01.2008, 16:14 -0800 schrieb Micah Carrick:
The GtkTextView has it's own handler for the drag_data_received. I
don't see any property or way to squash this handler. Am I missing
something?
GtkTextView just installs a default handler. Those are called after all
custom signal handlers installed with g_signal_connect() (and before any
signal handler installed with g_signal_connect_after()).
Therefore you can connect your own signal handler, which stops signal
emission:
static void
drag_data_received_cb (GtkWidget *widget)
{
g_signal_stop_emission_by_name (widget, drag-data-received);
}
Alternatively it should work to derive your own class from GtkTextView
which overrides drag_data_received(), but doesn't call it's parent
class' variant of that method:
static void
maman_bar_drag_data_received (GtkWidget*widget,
GdkDragContext *context,
gint x,
gint y,
GtkSelectionData *data,
guint info,
guint time)
{
}
static void
maman_bar_class_init (MamanBarClass *cls)
{
GtkWidgetClass *wcls = GTK_WIDGET_CLASS (cls);
wcls-drag_data_received = maman_bar_drag_data_received;
}
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-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: g_object_get_property() with unknown type
The value type is a fixed part of each property, so in normal code you
should know the property type by looking at the property docs.
Well, but if you want to do something that requires introspection
capabilities I can point you on g_object_class_find_property().
Am Montag, den 31.12.2007, 17:30 +0100 schrieb [EMAIL PROTECTED]:
Given a GObject* and a property name, what are the steps
required to extract the property inty a GValue, not
knowing its type beforehand?
It seems I can only make g_object_get_property work if
I set the type of the GValue before the call.
This code works when the property is string-valued:
GValue v = {0, };
g_value_init(v, G_TYPE_STRING);
g_object_get_property(object, name, v);
- but is it not possible to initialize the GValue in a
manner so that g_object_get_property() can switch to
the appropriate type?
Don't think so.
I tried with G_TYPE_INVALID and G_TYPE_NONE but this doesn't
work.
You could patch glib/gobject/gobject.c and send that patch to Bugzilla,
if you can explain, why that feature is useful and worth the overhead.
If I really do need to walk the type information, what are the
steps required to find out the type and initialize the GValue?
As written above: g_object_class_find_property().
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-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-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: 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: 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: Reg:Key Event Handle
Am Mittwoch, den 19.12.2007, 10:15 +0530 schrieb [EMAIL PROTECTED]: Hi, I am developing an mobile application using GTK+ C programming,now I have an issue that there is no response for the key event handle for all the applications that I run.I am not able to handle the left and right keys and nor any keys. Please let me know how to resolve the issue Thanks in advance Hard to help you with that few information. As a wild guess: Did you call gtk_widget_add_events with the relevant flags on your widgets? Also notice, that you widget has its own GdkWindow associated to receive any X11 events. Did you consider using GtkEventBox? Hope this hints help you. 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-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Can I port gtk for BlackFin processor?
Am Mittwoch, den 19.12.2007, 16:39 +0800 schrieb NalaGinrut: Hi everybody! Can I port gtk for BlackFin processor? How can I do that? I didn't find any document.Please help me. Not that I can confirm, that GTK+ runs on BlackFin processors, but once you got for instance Linux with X11 or DirectFB running, you should be able to compile GTK+ and applications for that platform. Google suggests that a BlackFin Linux Project exists: http://blackfin.uclinux.org/gf/ Or does your question target specific problems? 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-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-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: Can I Disable or Alter GtkEntry and GtkTextView Clipboard Menus?
Am Montag, den 17.12.2007, 19:29 -0500 schrieb Vallone, Anthony:
I am developing applications that run in a very user controlled
environment (think big brother). When a GtkEntry or GtkTextView widget
is clicked with button 3, a clipboard menu opens with basic clipboard
options, an Input Methods sub menu, and an Insert Unicode ... sub
menu. How can I disable or alter that menu?
I also tried connecting to the popup-menu from the GtkWidget level,
but that signal never seems to propagate.
I don't know what went wrong, but connecting to the popup-menu signal
definitly works, as the attached program demonstrates.
Ciao,
Mathias
--
Mathias Hasselmann [EMAIL PROTECTED]
Openismus GmbH: http://www.openismus.com/
Personal Site: http://taschenorakel.de/
#include gtk/gtk.h
int
main (int argc,
char *argv[])
{
GtkWidget *window, *vbox, *entry, *text_view;
gtk_init (argc, argv);
entry = gtk_entry_new ();
g_signal_connect (entry, popup-menu,
G_CALLBACK (gtk_true),
NULL);
text_view = gtk_text_view_new ();
g_signal_connect (text_view, popup-menu,
G_CALLBACK (gtk_true),
NULL);
vbox = gtk_vbox_new (FALSE, 6);
gtk_box_pack_start (GTK_BOX (vbox), entry, FALSE, TRUE, 0);
gtk_box_pack_start (GTK_BOX (vbox), text_view, TRUE, TRUE, 0);
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-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Gtk and threading
Am Montag, den 17.12.2007, 16:01 -0500 schrieb Andres Gonzalez:
Everybody is saying that all of my Gtk processing should be done in
the main thread, and indeed, whenever I use a Gtk/Gdk routine in my
camera thread I get Xlib async errors. But then how do I trigger a
render from my camera thread whenever my camera buffer gets a new
video frame without calling a Gtk/Gdk API routine?
The recommended pattern for passing data from a worker thread to the
main thread, is installing an idle-function with g_idle_add(). The
g_idle_add() function is designed to be thread safe
One variant to achieve that would be:
static gboolean
update_canvas_cb (gpointer data)
{
gtk_widget_queue_draw (canvas_widget);
return FALSE; /* remove the callback */
}
...
g_idle_add (update_canvas_cb, NULL);
...
Notice that you cannot directly connect gtk_widget_queue_draw(), since
that function has no (defined) return value.
I currently have a common memory buffer that both threads have access
to. But the Gdk_pixbuf routines seem to be double buffering the data
so I have to use a Gdk_draw routine to have my common memory rendered.
No need for a shared buffer. Just pass ownership of the picture buffer
to the main thread, by passing it as user_data argument to g_idle_add.
After doing that, the worker thread can discard the pointer:
g_idle_add (update_canvas_cb, picture);
picture = NULL; /* ownership passed to main-thread */
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-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
RE: Can I Disable or Alter GtkEntry and GtkTextView Clipboard Menus?
Am Dienstag, den 18.12.2007, 11:56 -0500 schrieb Vallone, Anthony: I don't know what went wrong, but connecting to the popup-menu signal definitly works, as the attached program demonstrates. Thanks for replying Mathias. When I run your code, the clipboard menu still opens. Does the menu open for you with this code? If not, does the menu open for you if you remove the popup-menu signal connect? If we are seeing different behavior for this code, maybe its a configuration/environment difference. Oh, being a keyboard guy I only tested using the context-menu key. On right-click the menu still appears. Weird. Turns out, you also have to connect to button-press-event and return TRUE there, when seeing event-button == 3 event-type == GDK_BUTTON_PRESS. Maybe you want to file a bug-report, that GTK+ should emit the popup-menu signal when seeing that condition, instead of shortcutting to the code displaying the popup menu. 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-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: How to simulate full window (manager) close-button behaviour?
Am Freitag, den 14.12.2007, 10:21 +0100 schrieb Toralf Lund: This is something I've wondered about for a long time. Or maybe I solved the problem once, but I can't find the code now: Is there a simple way to tell Gtk to do exactly what it would do when if the user pressed the window (window manager) close button, when working with a Window widget? I mean, usually gtk_widget_destroy() or gtk_widget_hide() will be called as part of the handling, but those functions are not what I'm looking for; I also want to execute the full event handler chain that may lead to these calls as well as other tests or whatever that are part of the full close behaviour. Pressing the close button usually causes the window manager to send the WM_DELETE_WINDOW message[1], as described in the ICCCM. A short look over the GDK source code didn't reveal a location where GDK _sends_ that message. So GDK/GTK don't seem to support it. But you could have a look at libwnck, which should have a working implementation for that message. Ciao, Mathias [1] http://tronche.com/gui/x/icccm/sec-4.html#s-4.2.8.1 -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Gtk on Embedded Device Query
No idea. I'd suspect some folders missing and run the program with strace to see if folder locations are correct. Ciao, Mathais Am Freitag, den 14.12.2007, 11:18 +0530 schrieb Saroj Kumar: Hi, I ported X11 and Gtk with X11 support on Embedded board(arm-linux). The problem I am facing now is setting the fontconfig. Because I have fontconfig and freetype libraries for X11 and I compiled Gtk with those libraries. The following error is produced when I tried to run gtkdemo application. (gtk-demo:1152): Gdk-WARNING **: Error converting from UTF-8 to STRING: Could not open converter from 'UTF-8' to 'ISO-8859-' (gtk-demo:1152): Gdk-WARNING **: Error converting from UTF-8 to STRING: Conversion from character set 'UTF-8' to 'ISO-8859-d Fontconfig warning: line 32: unknown element cachedir Fontconfig warning: line 33: unknown element cachedir Fontconfig error: conf.d, line 1: no element found (gtk-demo:1152): Gdk-WARNING **: Error converting from UTF-8 to STRING: Conversion from character set 'UTF-8' to 'ISO-8859-d (gtk-demo:1152): Gdk-WARNING **: Error converting from UTF-8 to STRING: Conversion from character set 'UTF-8' to 'ISO-8859-d (gtk-demo:1152): Gdk-WARNING **: Error converting from UTF-8 to STRING: Conversion from character set 'UTF-8' to 'ISO-8859-d Segmentation fault What I am doing is correct or not. Pls. suggest some solution for this. Thanks and Regards, Saroz ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-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: 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: Calling gtk_drag_get_data() in a drag-motion signal handler.
Am Dienstag, den 11.12.2007, 14:46 +0100 schrieb Murray Cumming: As the attached test case shows, this problem is fixed by calling gtk_drag_dest_set() with 0 instead of GTK_DEST_DEFAULT_ALL (0 causes the targets array to be ignored too, but just passing NULL for the targets doesn't change the behaviour.) The meaning of gtk_drag_dest_set's flags argument is to install default behaviors, so that you have just a few signal handlers for implementing primitive DnD support. With GTK_DEST_DEFAULT_ALL for instance you just have to connect the drag-data-received signal to get primitive DnD support suitable for accepting plain text. I've updated the documentation for gtk_drag_dest_set and GtkWidget:drag-motion: gtk_drag_dest_set: Sets a widget as a potential drop destination, and adds default behaviors. The default behaviors listed in flags have an effect similar to installing default handlers for the widget's drag-and-drop signals (drag-motion, drag-drop, ...). They all exist for convenience. When passing GTK_DEST_DEFAULT_ALL for instance it is sufficient to connect to the widget's drag-data-received signal to get primitive, but consistent drag-and-drop support. Things become more complicated when you try to preview the dragged data, as described in the documentation for drag-motion. The default behaviors described by flags make some assumptions, that can conflict with your own signal handlers. For instance GTK_DEST_DEFAULT_DROP causes invokations of gdk_drag_status() in the context of drag-motion, and invokations of gtk_drag_finish() in drag-data-received. Especially the later is dramatic, when your own drag-motion handler calls gtk_drag_get_data() to inspect the dragged data. widget : a GtkWidget flags : which types of default drag behavior to use targets : a pointer to an array of GtkTargetEntrys indicating the drop types that this widget will accept. Later you can access the list with gtk_drag_dest_get_target_list() and gtk_drag_dest_find_target(). n_targets : the number of entries in targets. actions : a bitmask of possible actions for a drop onto this widget. GtkWidget:drag-motion: [...] Note that you cannot not pass GTK_DEST_DEFAULT_DROP, GTK_DEST_DEFAULT_MOTION or GTK_DEST_DEFAULT_ALL to gtk_drag_dest_set() when using the drag-motion signal that way. [...] Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] www.openismus.com -- Mathias Hasselmann [EMAIL PROTECTED] http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-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
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: 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
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: 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
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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
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
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
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
