Michael Meeks wrote:
Ultimately, it boils down to the fact that a purely generic dialog
solution is not really feasible: custom logic per dialog is necessary.
If people want to wrap that with a propert-set API (as we do already
though not an UNO one) - that is great ! at least, since I'm not hacking
on that I have no firm views :-)
My point is only - that this doesn't belong in the layout discussion
(per-se). We will always need:
nice property API <-> dialog implementation <-> widgets
Actually a nice property API would have a vetoable change listener API
that would make somthing like
Application code <-> property API <-> layouter <-> widgets
^
|
v
dialog property dependencies code
possible. "dialog property dependencies code" would be code that manages
the relations between different properties (and would probably be near
the application code, too) if they cannot be expressed as simple min/max
values.
But you're right, this does not affect the layouting discussion.
Kind regards, pl
--
If you give someone a program, you will frustrate them for a day;
if you teach them how to program, you will frustrate them for a lifetime.
-- Author unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
