Nick Name wrote:

...

Apple expressly forbids "Yes" and "No" as button labels - they recommend using verbs ("Don't Save" - "Cancel" - "Save") instead. Might be too much work to bridge these differences, but who knows?

dialogYesNoCancel verb otherArguments = ...

on windows it would display verb in the titlebar and yes no cancel buttons, on osx and kde environments (yes, kde3 also has verbose dialog buttons) it would display "don't "++verb, verb, cancel.

User-visible text doesn't belong in the source code. On Windows, the label text normally lives in the resource (.rc) file; with Xt-based toolkits (Athena, Motif), it belongs in the app-defaults file. Generally, you only set widget properties programmatically if you have to (i.e. because the values are determined dynamically). -- Glynn Clements

On Sunday 16 February 2003 03:25 pm, Wolfgang Thaller wrote:

Agreed. However, the general consensus (correct me if I'm wrong) seems to be that we shouldn't use platform-specific resource files. When we have an API for programmatical creation of the UI, we can implement a library for platform-independent resource files on top of that.

I would phrase it slightly differently. We should have a platform-independent API related to resources, which in some cases may use underlying capabilities of the target O/S.

Cheers,

Wolfgang

_______________________________________________ GUI mailing list GUI@haskell.org http://www.haskell.org/mailman/listinfo/gui

-- Seth Kurtzberg M. I. S. Corp. 480-661-1849 seth@cql.com

On Sun, 16 Feb 2003 20:58:05 +0000 Glynn Clements wrote:

Generally, you only set widget properties programmatically if you have to (i.e. because the values are determined dynamically).

Yes,yes :) I was not proposing any true API, just arguing that one can abstract over a yesNoCancel dialog window, parametrizing it with the verb to use on macos and kde3 to avoid a "yes/no" question. This can be done in an rc-file abstaction as well, if we chose to have haskell-specific resource files wich are translated to the appropriate thing on all platforms. This does not solve the verb conjugation problem,indeed (how does apple handle it in internationalization?) If we chose to interpret rc-files of all platforms and not to have our, this can't be done I suppose. How does wxWin handle the "yesnocancel" issue on macos? Vincenzo -- Teatri vuoti e inutili potrebbero affollarsi se tu ti proponessi di recitare te [CCCP]

On Mon, 17 Feb 2003 22:09:53 +0100 Wolfgang Jeltsch wrote:

Why shouldn't we just define a function which has the captions of the Yes and the No button directly as arguments? An example application of it could be dialogYesNoCancel "Save" "Don't save" <other arguments> which would name the buttons "Save", "Don't save" and "Cancel" on the Mac and "Yes", "No" and "Cancel" on a PC running Windows or KDE (:-)).

Yes, then we just don't have a YesNoCancel dialog ;) It would be a generic dialog. I don't see problems however. So it seems that apple hasn't got a yesnocancel dialog. How do they costraint the programmer to put "cancel" on the left ? Is it just a convention? Vincenzo -- First they ignore you, then they laugh at you, then they fight you, then you win. [Gandhi]

On Tue, 18 Feb 2003 00:15:47 +0100 Wolfgang Thaller wrote:

You'd say that you have one OK button, one Cancel button, and one button that doesn't fit in any of those two categories, and the library would place the buttons appropriately.

This seems a special case of an automatic layout layer to my eyes. I know few things about GUIs and am wondering if automatic layout wich takes in account issues like button ordering is common pratice or a very difficult problem (no need to say it seems not difficult to me at a first glance :)). V.

Wolfgang Jeltsch wrote:

...

...

Generally, you only set widget properties programmatically if you have to (i.e. because the values are determined dynamically).

Yes,yes :) I was not proposing any true API, just arguing that one can abstract over a yesNoCancel dialog window, parametrizing it with the verb to use on macos and kde3 to avoid a "yes/no" question.

I think the distinction between static values (which don't have to be computed at run-time) and dynamic values (which have to be computed at run-time) is not very natural. It is just like a distinction between squares and rectangles which are not squares.

Huh? Would you build a web site entirely from CGI scripts, even for static pages? Static-vs-dynamic is a pretty fundamental programming concept; e.g. the distinction between variables and functions in most languages (or between values and e.g. IORefs in Haskell). Sure, you *can* make everything dynamic; that doesn't mean that you should.

I would prefer if we would handle static values the same way we handle dynamic values. That would mean that certain static values would appear in the source code.

If dynamic values were the norm, that might make sense. But it's seldom the case for UIs. Most of the time, most of the UI is constant between program runs, with a few specific properties being determined dynamically.

...

This does not solve the verb conjugation problem,indeed (how does apple handle it in internationalization?)

Your approch for the Yes-No-Cancel dialogs was to specify a verb describing the action (e.g., "save") and to let the system produce the button captions. Why shouldn't we just define a function which has the captions of the Yes and the No button directly as arguments? An example application of it could be dialogYesNoCancel "Save" "Don't save" <other arguments> which would name the buttons "Save", "Don't save" and "Cancel" on the Mac and "Yes", "No" and "Cancel" on a PC running Windows or KDE (:-)).

Because localisation is a lot easier if all user-visible text is in one place (and in a place other than the source code). Xt handles this by using the value of $LANG in the default search path for resource files; to support multiple languages, you just need to provide multiple resource files. The end user can even do the localisation themselves if you don't provide a version for their language (or you've chosen the wrong variant of the language). On Windows, user-visible text is stored in a string table resource in the executable. This has the disadvantage that the end user can't modify it (although commercial developers may consider that an advantage), but it still reduces the localisation process to translating a single text file. Don't make localisation and customisation the programmer's problem. Every real UI toolkit tries to ensure that this gets thrown in for free. Don't even make UI layout the programmer's problem unnecessarily. Graphical UI builders are widely used. End-user UI modification can be useful e.g. for special-purpose applications, or educational use. Most of the time, the only thing that the application logic *really* needs to know about the UI is that certain widgets exist. If you need to display a value in a text field, you just need to be able to get a handle for that widget; you don't need to know anything else about it. -- Glynn Clements

"Nick Name" wrote:

...

*) File types

Has this really something to do with the UI library? The fileopen dialog will always show correct file types for you if it is native.

An application that presents an open dialog will have to tell the GUI library to "display just plain text and RTF files by default". When a file is opened, it needs to discover whether it was a text file or an RTF file.

...

*) Displaying File Names and Extension Hiding

The same. IMO, this has to do with a filesystem abstraction, not with the UI library.

Then why is it part of Apple's GUI toolkits? I think in this case, this file system feature is an important part of the UI experience, and it's probably just a single function. Something like this: displayNameForPath :: String -> IO String #if MACOS displayNameForPath path = .. - don't remember exactly #else displayNameForPath = return . reverse . takeWhile (/= '/') . reverse #endif Cheers, Wolfgang