GtkFixed disables expand propertiy of GtkVBox ?
Hi i am packing /putting notebook and one search box into fixed (GtkFixed). and this fixed is packed into vbox with expand and fill parameter as TRUE . so that when i maximized window only notebook get expand but when i maximized window the notebook is not get expanded i am not getting where i am wrong. and not getting how fixed working . please can anybody help me . The code is as follows vbox = gtk_vbox_new (FALSE, 0); /*- Notebook--*/ notebook = gtk_notebook_new (); gtk_notebook_set_tab_pos (GTK_NOTEBOOK (notebook), GTK_POS_TOP); label = gtk_label_new (tab1); tab = gtk_frame_new(Frame1); gtk_widget_set_size_request(tab,300,450); gtk_notebook_append_page (GTK_NOTEBOOK(notebook ), tab, label); label = gtk_label_new (tab2); tab = gtk_frame_new(Frame2); gtk_notebook_append_page (GTK_NOTEBOOK(notebook ), tab, label); /*search box -*/ label = gtk_label_new (Search); tab = gtk_entry_new_with_max_length (20); hbox = gtk_hbox_new (FALSE, 0); gtk_box_pack_start (GTK_BOX (hbox), label, FALSE, FALSE, 0); gtk_box_pack_start (GTK_BOX (hbox), tab, FALSE, FALSE, 0); fixed= gtk_fixed_new(); gtk_fixed_put (GTK_FIXED(fixed),notebook,3,3); gtk_fixed_put (GTK_FIXED(fixed),hbox,100,3); gtk_box_pack_start (GTK_BOX (vbox), fixed, TRUE, TRUE, 0); gtk_container_add (GTK_CONTAINER (window),vbox); gtk_widget_show_all(window); Thank you sphurti Why delete messages? Unlimited storage is just a click away. Go to http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to get PangoFontFamily?
On Tue, 13 Nov 2007 18:31:21 -0500, Behdad Esfahbod [EMAIL PROTECTED] wrote: On Tue, 2007-11-13 at 18:51 +0100, Enrico Tröger wrote: Hi, I have a PangoFontDescription, created from a font string. Now I would like to use pango_font_family_is_monospace() to know whether it is a monospaced font or not. But I don't find a way to get a PangoFontFamily object at all. Any ideas? A PangoFontDescription is just that: a description. It doesn't identify any specific font on your system just yet. You need a PangoFont first. Unfortunately the current Pango API is lacking any way to connect a PangoFont to a PangoFontFamily. So, right now, you can't do that. I've opened a but about it: http://bugzilla.gnome.org/show_bug.cgi?id=496545 Thanks. Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.key ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to scroll my gtk application window programmically
On Sat, 2007-11-10 at 20:48 -0600, ying lcs wrote: I would like to know how can I scroll my gtk application window programmically? I have tried this, but the scroll bar does not make and the content of the window did not get refresh? GtkWidget* topLevelWindow; GdkWindow* win = topLevelWindow-window; gdk_window_scroll (win, 1, 880); Is your top level window scrollable? My guess is that you actually have a scrollable widget (GtkTextView in a GtkScrolledWindow, or whatever) embedded somewhere in your top-level, and that's the thing you want to scroll. -Alan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Changing a style property?
Hi Can someone tell me how to change the 'style property' (as it's called in the reference manual) of a gtkwidget? Specifically right now I'm looking to change the 'shadow-type' property of gtkmenubar, gtktoolbar, and gtkcombobox. They look like crap on vista. I tried a g_object_set() but that says 'object class gtkmenubar has no property named shadow-type'. I can't find anything in the manual describing how to work with style properties, only some vague references to themes here and there. I would prefer to not have a theme, but I will write one if I have to, in which case would you please point me to a guide or a reference? Thanks in advance, Andrew ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
How to change font size
Hello, I'm developing an application with gtk+, and I'm trying to change the fonts that is used in the application, to use diferent sizes of letters. I didn't find any class or method that changes the properties of the font used by the application. So I don't know if it is possible to change the fonts of an application, and if it is possible wich class can do it. Thanks for the help. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to change font size
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here's a snippet of python using PyGTK: self.value = gtk.Label() valuefont = pango.FontDescription() valuefont.set_family(monospace) valuefont.set_absolute_size(300*pango.SCALE) self.value.modify_font(valuefont) - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHPR/5UJT6e6HFtqQRArZsAJ94xXPnVJFePfIw/e0EgkOjCeFmcACfUVeK PuizFPs3Q33S/Y5G2yZP2lE= =dYJp -END PGP SIGNATURE- ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
clist query
Hi All, Have query on clist : 1. How to count the number of rows in a clist - Is there any CPI for the same ? 2. Any API to retrive the position of first selected item in a clist 3. How to retrive number of selected items in a list ? - Any API ? tia, Udayan =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GInterfaces and API Stability
On 11/14/07 Sven Herzberg wrote: I think it's not about the compiler doesn't barf. It was a design decision to be able to always extend interfaces. The only thing GTK+ I guess this is a documentation issue, then, as this design decision is not mentioned at all in the GObject documentation at http://library.gnome.org/devel/gobject/unstable/gtype-non-instantiable-classed.html. It actually says that GInterfaces are very similar to Java interfaces but Java interfaces definitely don't allow adding new methods (without breaking previously working code). (talking about the concrete additions) has to handle non-implementations gracefully, which it easily can by NULL-checking before calling into the interface implementation. Even a default implementation can be added to be called if the interface function is not explicitly implemented. This reminds me of the Microsoft API Design video that Philipp van Hoof has blogged about. The speaker even claims that MS is extending their .Net-interfaces in similar ways. I didn't watch that video, but this claim looks strange. Adding a method to an interface in C#/CLI will break the code and I don't know of a single case where this happened. What happens instead is that a new interface is defined and the relevant types are extended to implement the new interface. This is exactly what Mike suggested. Regardless, even if a future .net implementation allowed adding methods to interfaces, this wouldn't address Java's needs (but I don't know the status of the java bindings: do they support GInterfaces at all?And if they do, do they use Java interfaces? In the following I assume they do). So, let's create a table with the options available in the C libs and in the bindings and see if there is a compromise that would make most people happy. Please comment on this, as my understanding of some of the bindings is lacking. In GObject (and Gtk+) we have two options: adding new methods to existing interfaces or adding new interfaces. Let's see how the major bindings cope with this: new methods new interface Python doesn't caredoesn't care Perldoesn't caredoesn't care Rubydoesn't caredoesn't care C++ ABI break ABI break JavaABI break OK C# ABI break OK Here doesn't care means that the language doesn't really care much about the issue, though there may be problems as the mentioned NULL dereferences (nothing much can be done in Gtk+ here, except what Sven rightly mentioned about checking for NULL method implementations and updating the documentation to match, so other people follow this pattern as well). ABI break means that following the existing implementation of GInterfaces for the language (or following the most natural implementation of the concept for the language) the ABI would break when the change is introduced. There may be workarounds (like just using the C function in C++ or explicitly adding new interfaces for C# and Java). If the above table is correct (please send me corrections or add more language bindings) it seems that adding new interfaces would be the preferred extension mechanism. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ 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
On Thu, 2007-11-15 at 12:52 +0100, Mathias Hasselmann wrote: 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. As well as bad API documentation, it means that you can't use the signal from many bindings (such as python), because they can't know what the argument is supposed to be. 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? - Make the return type of the signal be char*, and use an appropriate signal accumulator. Exactly what you should do depends on what semantics you want when multiple handlers are registered on the signal, but one common method is to stop the signal emission as soon as any handler returns a non-NULL value, and use that as the return value of the signal. Cheers, -- 25 grams of wafers and 20 ml of wine undergo transubstantiation and become the flesh and blood of our Lord. How many Joules of heat are released by the transformation? --Theological Physics exam, 1997 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Signals with gchar** arguments
On Thu, 2007-11-15 at 12:52 +0100, Mathias Hasselmann wrote: 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? - Use a helper object that has methods (or fields) to set the string. Jürg ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Signals with gchar** arguments
On Thu, 2007-11-15 at 23:28 +1100, James Doc Livingston wrote: On Thu, 2007-11-15 at 12:52 +0100, Mathias Hasselmann wrote: 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. As well as bad API documentation, it means that you can't use the signal from many bindings (such as python), because they can't know what the argument is supposed to be. This happens fairly often, so bindings hand-code their .defs files. For instance, for gtkmm the *-event signals have to be changed from GdkEvent to, for instance, GdkButtonEvent. It needs to be improved when pygtk one day uses the future full GObject introspection. 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? - Make the return type of the signal be char*, and use an appropriate signal accumulator. That's no good if there are two gchar** parameters, as in this case. Exactly what you should do depends on what semantics you want when multiple handlers are registered on the signal, but one common method is to stop the signal emission as soon as any handler returns a non-NULL value, and use that as the return value of the signal. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Signals with gchar** arguments
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.
ciao,
Emmanuele.
--
Emmanuele Bassi,
W: http://www.emmanuelebassi.net
B: http://log.emmanuelebassi.net
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GInterfaces and API Stability
On Thu, 2007-11-15 at 11:28 +0100, Paolo Molaro wrote: On 11/14/07 Sven Herzberg wrote: I think it's not about the compiler doesn't barf. It was a design decision to be able to always extend interfaces. The only thing GTK+ I guess this is a documentation issue, then, as this design decision is not mentioned at all in the GObject documentation at http://library.gnome.org/devel/gobject/unstable/gtype-non-instantiable-classed.html. It actually says that GInterfaces are very similar to Java interfaces but Java interfaces definitely don't allow adding new methods (without breaking previously working code). This is because someone other than Tim wrote those docs. GObject interfaces was not modeled on Java style interfaces, but rather on an gcc c++ extension calles signatures, which is slightly different than java interfaces. So, let's create a table with the options available in the C libs and in the bindings and see if there is a compromise that would make most people happy. Please comment on this, as my understanding of some of the bindings is lacking. In GObject (and Gtk+) we have two options: adding new methods to existing interfaces or adding new interfaces. Let's see how the major bindings cope with this: new methods new interface Pythondoesn't caredoesn't care Perl doesn't caredoesn't care Ruby doesn't caredoesn't care C++ ABI break ABI break I believe C++ could work around the new methods approach by padding classes with stub vcalls and using those for new methods. Java ABI break OK C#ABI break OK Here doesn't care means that the language doesn't really care much about the issue, though there may be problems as the mentioned NULL dereferences (nothing much can be done in Gtk+ here, except what Sven rightly mentioned about checking for NULL method implementations and updating the documentation to match, so other people follow this pattern as well). If you install a default handler for the new interface method there is never any NULL problem. If the above table is correct (please send me corrections or add more language bindings) it seems that adding new interfaces would be the preferred extension mechanism. There is another dimension too. Extension of an interface is often the most natural way for people using the interface in C. Having a totally new interface for a minor optional addition to an interface is pretty ugly. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Signals with gchar** arguments
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).
___
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
On Thu, 2007-11-15 at 01:16 +0100, Mathias Hasselmann wrote:
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 ());
}
As well as a general learned avoidance of reckless C++ operator
overloading, I think you'd lose the advantages of actually using the
regular C++ hierarchy, such as type-safe casts at compile-time.
For gtkmm I am not greatly troubled by the new-interfaces-break-ABI
issue because it happens so rarely.
--
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: CairoIO - Cairo compatible successor to GdkPixbuf
On 13/11/2007, BJörn Lindqvist [EMAIL PROTECTED] wrote:
Hello all!
Some background info about this project is found here:
* http://www.mail-archive.com/gtk-devel-list@gnome.org/msg06472.html
* http://live.gnome.org/GtkCairoIntegration
* http://bugzilla.gnome.org/show_bug.cgi?id=395578#c6
In short, GdkPixbuf has some big problems which are hard to solve, so
we need a new image library which is more compatible with Cairo.
CairoIO is my attempt at creating such a library. The library is not a
reimplementation of GdkPixbuf, it only wraps it to provide a
cairoified front end to all the image loading functionality.
Currently it consists of nothing more than a executable specification
written in Python and unit tests. The intention is to first create a
rock-solid, future-proof interface that solves all architectural
problems GdkPixbuf has. So lets have some nice discussion about it!
The things I've found really bad with GdkPixbuf and which I think
CairoIO can solve are listed in Targeted GdkPixbuf Problems in the
/ref/cairoio.py file. In particular I was not happy with how
PixbufAnimations work so I've tried to make them better.
Checkout using:
svn co svn.gnome.org/svn/cairoio/trunk cairoio
The implementation is in /ref/cairoio.py which also contain lots of
documentation. I know the name CairoIO might not be so nice, but it
is only seven characters. Maybe someone can think of a better name?
Feedback welcome!
And thou shalt have feedback :-)
1) I am wondering if it should integrate with the upcoming libgio? Ie, take
a GFile instead of a filename in function args..? Or maybe going entirely
G{Input,Output}Stream based? That would obsolete a few of the methods in the
API.
2) I see that you do not have any methods to match
GdkPixbuf.get_has_alfaand a handful other methods on GdkPixbuf. Is the
reason documented somewhere
or am I missing something obvious?
3) Why is there a load_xpm()?
4) I gather that the load*() family functions replace the constructors of
GDkPixbuf.
4.1) How exactly would you map the load_frames() method with the keyword
arguments?
4.2) Why do I have to call load_frames() to request the image size on
construction of the surface? Just load() would space me the linked list for
normal images.
4.3 (Assuming gio based) If we are in stream terminology s/load/read is
probably more in line
5) All load_*() family functions returns a SurfaceInfo, but load() returns a
Surface... A bit odd maybe.
I am really exited about the idea about joggling cairo surfaces around over
G{In,Out}putStreams, but the idea may be bonkers, I have not read the GIO
api much, not do I understand the finer details of cairo surfaces.
Cheers,
Mikkel
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
