Re: gtk_widget_show() and the 'size-allocate' signal

[v4r4n <console cowboy gmail com>]

For the record, building my own GtkWidget to handle the "size-allocate"
signal  according to my extra parameters has at least begun to solve my
problems without creating too many new ones.

For the moment, I'm working on figuring out how/why a GtkBox will fill up
the space of a window and give it to the child and a GtkLayout does not, but
I'm still unsure if I really need my widget to do that at this point.


On 3/7/07, v4r4n <console cowboy gmail com> wrote:
> "the problem": my GUI library in its current state goes through an overly
> complex size negotiation phase where my widgets are drawn multiple times
> before they settle on a position and size that was intended by the
> application programmer.  This causes lots of flickering every time the user
> clicks on anything and sometimes gets in the way of signals sent by the
> user.  Trying to start an open file dialog sometimes fails.
>
> At first I tried to implement the library with box widgets, but could
> never give the application programmer the full control that is expected by
> my application code, so now I use GtkLayouts as my primary container widgets
> that tell all other widgets (frames and boxes) using the "size-allocate"
> signal how big and where they're supposed to be (this at least works, but is
> wasteful and ugly).
>
> I believe I understand what you meant by subclassing earlier, basically
> use the GtkContainer or GtkBox widgets to implement my own variation.  On
> the technical side, I mostly worry that I'll have compatibility problems if
> I use the latest source code as a reference, when a primary machine I need
> this to work on is still running on GTK 2.4...
>
> I also fear that due to the very nature of all GtkWidgets and the
> "size-allocate" signal, my own widget still won't help, so I'm left thinking
> about ways of hiding GTK's native behavior until the widgets are 'truely'
> ready for the user to see them.  Then make sure they always hide an reappear
> when ready...
>
> Next, I do plan on at least trying to make a widget very similar to
> GtkLayout, but with the additional properties that my code requires.
>
>
>  On 3/6/07, David Nečas (Yeti) <yeti physics muni cz > wrote:
> >
> > On Tue, Mar 06, 2007 at 11:41:24AM -0800, v4r4n wrote:
> > > Since my latest efforts to minimize the number of "size-allocate"s
> > being
> > > thrown around by holding off on key gtk_widget_show() calls, I'll
> > attempt to
> > > subclass a widget, but I've never made my own custom widget before.
> > >
> > > There is a http://www.gtk.org/tutorial/x2312.html tutorial on making
> > your
> > > own widgets but it seems to make a 'subclass' of a widget in GTK using
> > C, I
> > > have to copy the source of a widget and make changes from there.
> >
> > No.  If you have to copy the source, you are either not
> > subclassing but creating a [similar] widget from scratch
> > instead -- or you are subclassing, but the original widget
> > was not written with the possibility of subclassing in mind
> > and probably you should rather write the widget from scratch.
> >
> > If you subclass (define a new class with the original class
> > as its parent) a widget, the new one inherits everything
> > from the original one by default.
> >
> > In fact, you may want to create a new widget from scratch.
> > It's hard to tell not knowing anything about how and how
> > much the behaviour should differ nor from what.
> >
> > I would point to some tutorial but this is scattered to
> > too many places...
> >
> > > Where am I
> > > going to get all the necessary source code for a GtkLayout from GTK
> > 2.4?
> >
> > Do you mean you were not able to find Gtk+ source code?
> >
> > > Using this method, what happens when different versions of GTK are
> > compiled
> > > against or used with my applications?  Will my old custom/'subclass'
> > widget
> > > eventually stop working or create an incompatibility?
> >
> > No, if you do it right.  And Gtk+ devs don't screw anything.
> > It is not always clear what assumptions one is allowed to
> > make when subclassing, therefore the probability of
> > something going wrong increases with the complexity of the
> > original widget and of the changes.
> >
> > > I'm also a little foggy on how my custom widget will be able to solve
> > my
> > > problem.
> >
> > Maybe I misunderstood your problem.  Do you want a container
> > widget that allocates space for its children differently
> > than existing container widgets?  Or do you just want to
> > perform some action in response to "size-allocate"?  And why
> > the bottom-to-top order is a problem then?
> >
> > > Is it common for people to make custom signals as well, or is that
> > > impossible?
> >
> > I can't tell what is common.  It is possible both to add
> > signals to existing classes and to register new signals when
> > you create new classes -- both with g_signal_new().
> >
> > Yeti
> >
> >
> > --
> > Whatever.
> > _______________________________________________
> > gtk-app-devel-list mailing list
> > gtk-app-devel-list gnome org
> > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
> >