Okay, but does any of this offer benefits to simply using a Fixed? That seems like a simple and effective solution, but if there's a better way to do it then I'm interested...
On Sun, Jan 17, 2010 at 12:43 AM, Michael Hutchinson <[email protected]> wrote: > On Mon, Jan 11, 2010 at 6:51 PM, Piotr Zurek <[email protected]> wrote: >> Hi Michael, >> >> On Tue, Jan 12, 2010 at 12:18, Michael Hutchinson >> <[email protected]> wrote: >>> It's perfectly possible to have a custom widget position a child entry >>> directly. You don't necessarily need the Fixed to do this for you. >> >> Any idea where I could find a bit more information on how to do it or >> maybe an example of a project that is doing it? > > I can't think of any examples of exactly this, but the basic idea is > that you're just implementing a special container that only sometimes > shows its child and shows it at different positions. > > Because you're only using the child in a very limited way, you can > probably just subclass Bin and stuff the child in that, so it does the > bulk of work of propagating mapping, realization, destroying, etc. to > the child. Then, on the expose event of your widget, you have to check > the child state depending on the state of your widget. You may have to > set its visible state, or give it a requisition if its position has > changed, then propagate the expose. Or you could subclass Alignment, > and use the xpad/ypad to handle the positioning. Then you'd just have > to handle giving your widget a GdkWindow and overriding the expose and > allocation like usual. Just make sure you make the PropagateExpose > calls so the child is exposed too. > > Something like that, anyway. > > I think the Medsphere GTK# widget have some containers written in > managed code you could look at. > > -- > Michael Hutchinson > http://mjhutchinson.com > _______________________________________________ Gtk-sharp-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
