I'm breaking this out as a separate thread, in case people really really
want to spend time debating the merits of different methods for laying out
dialog widgets:
- native platform resource files compiled into binary
- separately-packaged files parsable at runtime
- code-driven automatic layout managers & constraint systems
- etc.
Currently, our APIs are agnostic for this issue, which allows
platform-specific (and even dialog-specific) flexibility.
People do tend to have strongly-held opinions in this area, though, so I'd
like to concentrate any potential flamewars and keep them from polluting
other discussions.
Thanks,
Paul
At 02:49 PM 2/11/01 +0100, Mike Nordell wrote:
>Tom Briggs wrote:
>> Basically what you've just described are two of the possible ways to
>> construct dialogs in Java. If you think laying out dialogs once for each
>> platform is a lot of work, try laying out dialogs that don't look like
>> shit using either of these systems.
>
>If a layout engine is implemented for each platform, laying out the controls
>according to that platforms conventions, how would it be possible to make it
>_not_ look native?
>
>> One of the most subtle reasons that AbiWord has a chance to succeed
>> cross-platform is that for each platform, it looks like an app designed
>> for that platform. Any attempt to abstract the dialog layout system
>> will result in sacrificing the "designed for this platform" look.
>
>Again, how would that be possible if code written for that platform takes
>care of laying out the controls? That somehow implies that even using native
>tools it's impossible to make dialogs look native on that particular
>platform.
>
>> Having an abstract dialog layout system will help us developers but hurt
>> the users. Don't forget which is more important.
