Re: GtkNotebook with action on click of special tab
2011/4/20 Tristan Van Berkom t...@gnome.org
On Wed, Apr 20, 2011 at 8:34 AM, Bernhard Schuster
schuster.bernh...@googlemail.com wrote:
Hi I am trying to achieve the effect of new tab openening if one tab gets
selected. Unfortunaltly the doc is very sparse on that:
http://developer.gnome.org/gtk/stable/GtkNotebook.html as of using the
select-page signal. Can anyone give me a hint how to use it properly
with
a g_signal_connect function?
Note: I am still in a learning phase so please be patient with me :)
What I tried so far:
gboolean
derived_notebook_insert_page (DerivedNotebook *obj, gboolean b, gpointer
data)
{
// do page insert
}
and within foo_derived_notebook_init: g_signal_connect (obj,
select-page,
G_CALLBACK (derived_notebook_insert_page), NULL);
If anybody could shed some light of what the return value is for, and how
to
achiev what I want, thanks very much
Hi,
First of all if you are deriving the notebook, you should not connect a
signal handler but instead override the class vfunc (in this case would
be GtkNotebookClass-select_page).
Also, select-page is generally a keybinding signal used to move
focus (it's used when one of the tabs have keyboard focus and
spacebar is pressed to make that tab's page the current page,
the return value I believe is whether the notebook keeps focus or
not).
Probably you want to use the switch-page vfunc which will be
called to do the work of actually changing the current page (whether
it's done by code or by user interaction, so you might have to
be careful to avoid recursion here).
Also, I have a hard time imagining how it would be desirable
to open a new tab as a result of selecting a different tab (maybe
some more context here would let us give you better advice).
Texteditor, where the last tab head is just a plus and the tab content is
never expected to be visible. The tab head is GtkImage showing
GTK_STOCK_ADD. On click its expected to spawn a new tab let of the special
one and gets focused instantly.
Thanks for your tipp!
B.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkNotebook with action on click of special tab
Hi Bernhard
Not sure what you are trying to do.
Gtk_Notebook is a nice feature. What I found works is to process the
switch-page signal.
Generally I setup each page prior to displaying it and associate my own
control data with each page. (From memory GTK does not bother to
display blank pages, which can be confusing)
Then I display the page I want.
If the user tabs to another page, I let gtk handle the page switch and
handle input from the selected page as appropriate, using my own control
data to do this.
I suppose there is a case for writing my own extention for gtk-notebook,
a derived class, but have not tried this, as I prefer to keep my own
data completely separate from GTK.
The only thing to watch is that if you delete a tabbed page, then the
page index for all higher pages decrements. Just allow for this when
switching your own control data
Hope this helps
Bill C
On 20/04/11 09:34, Bernhard Schuster wrote:
Hi I am trying to achieve the effect of new tab openening if one tab gets
selected. Unfortunaltly the doc is very sparse on that:
http://developer.gnome.org/gtk/stable/GtkNotebook.html as of using the
select-page signal. Can anyone give me a hint how to use it properly with
a g_signal_connect function?
Note: I am still in a learning phase so please be patient with me :)
What I tried so far:
gboolean
derived_notebook_insert_page (DerivedNotebook *obj, gboolean b, gpointer
data)
{
// do page insert
}
and within foo_derived_notebook_init: g_signal_connect (obj, select-page,
G_CALLBACK (derived_notebook_insert_page), NULL);
If anybody could shed some light of what the return value is for, and how to
achiev what I want, thanks very much
Regards
B.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkStatusbar and DGSEAL_ENABLE
On 9 April 2011 19:44, Carlos Pereira jose.carlos.pere...@ist.utl.pt wrote: Hi there, Hello Carlos, Perhaps we could have a function: label = gtk_statusbar_get_label (GTK_STATUSBAR (statusbar)); This way GTK developers could futurely change the inner workings of GtkStatusbar without affecting user code that needs access to the Label. Could you comment in this bug? [1] Thanks [1] https://bugzilla.gnome.org/show_bug.cgi?id=594535 -- Javier Jardón Cabezas ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
[no subject]
http://krstarenje.kr.funpic.org/inside.html ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
understanding gtype and gobject
I am trying to understand the gtype system and the gobject system. http://developer.gnome.org/gobject/stable/ Unable to figure out the difference between the gobject constructor and the gtypes instance_init function. Why do we use a constructor function in gobject ? Can we not do the functionality in the instance_init itself ? - abhi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: understanding gtype and gobject
Le mercredi 20 avril 2011 à 06:13 -0400, abhishek desai a écrit : I am trying to understand the gtype system and the gobject system. http://developer.gnome.org/gobject/stable/ Unable to figure out the difference between the gobject constructor and the gtypes instance_init function. Why do we use a constructor function in gobject ? Can we not do the functionality in the instance_init itself ? instance_init is the standard init function to use. constructor is called later when the object has been initialized, and is only useful if you need to rely on construction GObject properties having been set already. See http://developer.gnome.org/gobject/stable/chapter-gobject.html#gobject-instantiation For instance_init: Provide an instance_init function to initialize your object before its construction properties are set. This is the preferred way to initialize a GObject instance. This function is equivalent to C++ constructors. For constructor: If you need to complete the object initialization after all the construction properties are set, override the constructor method and make sure to chain up to the object's parent class before doing your own initialization. In doubt, do not override the constructor method. But I'd like to understand why the table on the page shows constructor before instance_init, while the former is actually called *after* the latter... Regards PS: General questions like yours should rather be asked on gtk-app-devel-list: the present list is for development of GTK+ itself. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: understanding gtype and gobject
On 20/04/11 12:12, Milan Bouchet-Valat wrote: But I'd like to understand why the table on the page shows constructor before instance_init, while the former is actually called *after* the latter... That page of the documentation addresses that question: “Readers should feel concerned about one little twist in the order in which functions are invoked: while, technically, the class' constructor method is called before the GType's instance_init function (since g_type_create_instance which calls instance_init is called by g_object_constructor which is the top-level class constructor method and to which users are expected to chain to), the user's code which runs in a user-provided constructor will always run after GType's instance_init function since the user-provided constructor must (you've been warned) chain up before doing anything useful.” Someone with a spare hour or two might want to refresh that documentation in light of the existence of 'constructed', which (IME) is more convenient than overriding the constructor for everything except making singletons. -- Will ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Crashes with long words in strings passed to gtk_widget_set_tooltip_text()
Emmanuel Thomas-Maurin manutm...@gmail.com wrote: On 04/20/2011 02:34 AM, Morten Welinder wrote: If you really want to safely pass a very long text, you will have to know the font (family and size) then check with stuff like pango_layout_set_text() and pango_layout_get_pixel_size(). The application where I noticed the problem doesn't intentionally pass a very long text. It passes a text that comes from an untrusted source (similar to Morten's example below) and the assumption made by the authors seems to be that GTK will deal with the rest, or the documentation would explicitly mention it. If it is considered acceptable for gtk_widget_set_tooltip_text() to crash the application, I'd consider that worth documenting, too. Preferably together with a complete list of circumstances where crashes are to be expected. This happened in Gnumeric at some point too. Basically, every time user supplied string make it into tooltips, this will happen. So it's probably better to fix this in gtk+. I don't think pixmap dimensions limit is mentioned in the GTK/GDK doc. Width and height type is gint, not guint16 or gint16. Is the pixmap dimension limit really that important here? If the tooltip is wider or higher than my screen I can only see parts of the tooltip anyway. If I press a key to switch desktops the tooltip disappears, so GTK could simply truncate the tooltip to the resolution of my screen and I wouldn't be able to tell the difference. If getting the actual resolution is too much work, it could be truncated to some arbitrary size. I think even not showing a tooltip at all, or replacing the text provided by the application with something like tooltip doesn't fit screen would be a behaviour that is vastly superior to crashing and less surprising for developers that are reading the GTK documentation but aren't familiar with the actual code. Fabian signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: New GTK+ website design
On 19/04/11 15:47, Cosimo Cecchi wrote: Hi Martyn, On Tue, 2011-04-19 at 15:30 +0100, Martyn Russell wrote: There are a few things to decide on, so I will try to get some consensus from you all before making the final decision on these points: 1. The titles are available in blue (default) or red. If you append ?red to the link you can see them in red. What do people prefer here? I quite like the blue now. I think I like the blue better too. 2. The features page has 2 approaches. One is with next/previous buttons to go through the features. The other lists them as we did before. What do people prefer? I feel that next/previous approach is a bit confusing, as the buttons are not really discoverable and it doesn't give an overview of all the items at a glance, which I think is important for such a prominent page. You're not the first to say that. I agree. It's now not the default. I will disable the next/prev look. I also feel the layout of the other page is a little too crowded at a first sight, but not being a web designer I don't have concrete suggestions to improve it (and I prefer it over the former anyway). Two other suggestions: - I think the home page should mention Javascript among the bindings, which is getting a lot of traction nowadays (more than Perl for instance). We have a bindings page. Was there something specific you wanted to mention here that covers more than the language bindings page? - It would be nice to have some screenshots updated to GNOME3/GTK3 styles. I agree. I will steal some from the gnome 3 live.gnome.org pages unless someone can point me to something useful? Thanks for the comments, -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: New GTK+ website design
On 19/04/11 17:53, Allin Cottrell wrote: On Tue, 19 Apr 2011, Martyn Russell wrote: Are there any other points or questions people have about the content/design that we should address before moving over to this? In general this looks very good. One nit: I don't care for the faux-embossed text in the header (The GTK+ Project). The font itself is fine, but I'd drop the black shadows for a cleaner and non-pixelated look. I have improved this. Let me know if you think it works or not. Thanks, -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: New GTK+ website design
On 19/04/11 19:41, Matthew Bucknall wrote: I think the approach *without* prev/next buttons is better. It's much better to see all features at a glance rather than go through all those pages. Unless you already know the buttons are there, it's not even immediately obvious what they are or what you're supposed to do with them. I second Allin Cottrell's opinion re the header. The drop shadow looks pretty dated. Great, thanks, these should be done now. -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: New GTK+ website design
On Wed, 2011-04-20 at 21:31 +0100, Martyn Russell wrote: Two other suggestions: - I think the home page should mention Javascript among the bindings, which is getting a lot of traction nowadays (more than Perl for instance). We have a bindings page. Was there something specific you wanted to mention here that covers more than the language bindings page? No, I was just thinking out loud that mentioning Perl as the first language binding in the home page sounded a bit backwards given the current trends in the GNOME community (no offense intended, I don't really have any idea of how many GTK+ applications are developed in Perl). Also, if the versions table in the binding page is up to date, Perl bindings don't seem to be 3.0 compatible yet. - It would be nice to have some screenshots updated to GNOME3/GTK3 styles. I agree. I will steal some from the gnome 3 live.gnome.org pages unless someone can point me to something useful? Screenshots from the official website or from l.g.o should be just fine, or you can run the live image and make some if you're looking for something different (or ask around...I can make some too if you want). Thanks, Cosimo ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Crashes with long words in strings passed to gtk_widget_set_tooltip_text()
On 04/20/2011 09:42 PM, Fabian Keil wrote: I think even not showing a tooltip at all, or replacing the text provided by the application with something like tooltip doesn't fit screen would be a behaviour that is vastly superior to crashing and less surprising for developers that are reading the GTK documentation but aren't familiar with the actual code. I've been searching a little bit in the source code for the GDK warning: Native Windows wider or taller than 65535 pixels are not supported. It appears (in gdkwindow-x11.c and gdkgeometry-x11.c) that, in case width or height is 65535, then it's set to 65535. But (if I'm right), as supported width / height go down to 32767 for X, the app get a GDK error and crashes anyways. Maybe setting the width / height limit to 32767 in GDK could fix that. BTW, have you file a bug for the issue? It's the best way to have it fixed. -- Emmanuel Thomas-Maurin manutm...@gmail.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
