[Gtk-sharp-list] Text input in drawing area

[Andy Selvig]

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
<m.j.hutchinson at gmail.com> wrote:
> On Mon, Jan 11, 2010 at 6:51 PM, Piotr Zurek <p.zurek at gmail.com> wrote:
>> Hi Michael,
>>
>> On Tue, Jan 12, 2010 at 12:18, Michael Hutchinson
>> <m.j.hutchinson at gmail.com> 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
>