[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Renaissance was (Re: Menu (Was: Re: Unimplemented AppKit classes))

From: Alan West
Subject: Re: Renaissance was (Re: Menu (Was: Re: Unimplemented AppKit classes))
Date: Fri, 24 Jan 2003 23:54:10 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030120

Martin Häcker wrote:

I think the idea of a platform independant UI description is very possible, one of the things that is often different between platforms is sizes of standard controls, borders, spacing etc... if the UI description avoided specific sizes but instead described a size such as; normal, small, medium, large, xlarge, and as a last resort percentages, then maybe each backend could relate these sizes to their platform specific style, even on PDAs.

I do not completely agree with you on this topic.

I think that one of the strengths of Next/GnuStep/Apple is that its interface is positioned pixel by pixel and thus the developer has full control over where and how the interface elements are positioned.

To loose this would mean to loose something big as auto-layouted interfaces can never look as good as hand crafted well thought out and fixed ones.

(Just think about internationalization issues...)

Though I may be at a loss of the features of .gsmarkup here.

Once you have a higher level description of what controls are required in a window, you can then write autolayout modules for the specific platforms GNUstep supports. A Mac would follow a lot of the Aqua user interface guidelines without a developer bothering to even think about Apple's guidelines... Then if GNUstep have documented UI guidelines, it too could have its own autolayout module... It enables crossplatform apps to look consistent with the native platform their running on.

Imagine a simple message box with an 'OK' and 'Cancel' button, on Windows those buttons would be aligned in the centre, on a Mac those buttons may be aligned to the right of the window.

Internationalization is one of the largest benefits of a higher level user interface description, as the auto-layouter can adjust the whole window so text labels never get truncated.

Imagine a user who requires all text on the screen to be at least a specific size as they are visually impaired, the auto-layout mechanism can deal with that for every app which uses it, without the developer ever even thinking of supporting Accessibility requirements. If you used specific sizes - this visually imparied person may not be able to use your app, or you would have to write support for it to be enlarged.

.xul and .gsmarkup files allow user interfaces to be very dynamic just like Objective-C allows your objects to be very dynamic. It could also be the file which gets changed when a user changes an option about hiding a toolbar, imagine a large graphical ERP system where users have different roles and security requirements - somone could visually tailor the dialog views for goups of users or specific users, those views could even be stored in the database - so they always see their configured forms from any client machine linked to the ERP system.

Dohhhh spent too much time writing this instead of NSToolbar.   :-(


reply via email to

[Prev in Thread] Current Thread [Next in Thread]