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 <[EMAIL PROTECTED]> 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) <[EMAIL PROTECTED] > 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 > > > > _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
