Angus Leeming wrote:
> On Friday 04 October 2002 1:52 am, Rob Lahaye wrote:
>
>>Angus Leeming wrote:
>>
>>>The attached patch works around an xforms bug and appears to
>>>work beautifully. Ok to apply?
>>>
>>>Index: src/frontends/xforms/forms/form_graphics.fd
>>>============================================================
>>
>>Angus,
>>When I ignore your patch to form_graphics.fd, the tooltips
>>still follow the graphics dialog. And if not needed, I prefer
>>the dialog as it was. Also: why 10 pixels instead of 5 above
>>the tabs do make a difference?
>>
>>It's great to see the tooltips now working properly.
>
> I found that /most/ of the time this does happen, but some
> "enter"s get dropped. Moving in the left hand edge of the
> tabfolder by 5 pixels seemed to help, but why don't you move it
> back and see what happens for you.
>
> Testing is pretty easy:
> for (;;) {
> Move dialog and position mouse over widget;
> if (bored)
> break;
> }
break!
I'd say:
1) /most/ at your end, means /always/ here with me.
So lets compromise this to /almost always/ :).
2) your patch is a /temporary/ patch until Xforms will deal with the problem
properly, right? (yes I know, such things go slow in the Xforms Open Source
development, but nevertheless...). For that, /almost always/ will do; no need
for crippling the dialogs unnecessarily.
I intentionally use the word "crippling" here, because your patch of
shifting & resizing the main tabform by 5 pixels, actually cripples the
layout of the tabs that go in there (5 pixels of bottom edge is cut off);
you should modify these too, but no, that's just too much for a temporary fix.
(Note that I designed the dialog such that each tab precisely fits into the
main tab window!)
I hope it's alright when I keep the '5 pixels' here in my tree. Though I would
also prefer to 'uncripple' form_graphics.fd in present CVS.
Regards,
Rob.
