[R-gui] Another R-GUI

[Thomas Friedrichsmeier]

> One other thing:  like XML, we should allow details to be put into the
> widget description even if they are meaningless on some systems,
> instead of restricting descriptors to those that are common
> everywhere.

Yes, I totally agree.

> For example, things that don't make sense (like "font=Helvetica" on a
> text mode display) should just be ignored.  Things that ask for too
> much (e.g. "position this at (0.314159, 0.271828)" on a system that
> only allows widgets to be placed on a coarse grid) should be
> approximated sensibly.

I personally would however vote against allowing attributes like font="Helvetica" at all. There really is no need to have different dialogs in the same app to use different fonts. The application may decide to use Helvetica for this and Courier for that, but for something to be shared across different applications, specifying fonts does not make much sense.

> This way it should be relatively easy to write a bare bones display
> engine, and then extra features could be gradually added to it over
> time.

Here, I agree again. Chances are my app will stay on the lower end of layout-features...

> One question I'd like to hear opinions about:  if we're allowing the
> user to create new specialized widgets, should we use an
> object-oriented inheritance scheme, or do everything by delegation?
> For example, I said I'd like to see a string selector being used by
> the varselector that Thomas described.  But that could be done in two
> ways:  either the varselector is a descendant of a string selector, or
> it's a new component that contains a string selector.  Opinions?  (For
> what it's worth, Delphi uses the inheritance system, and it works
> pretty well, so that's where I'd lean.)

Hmm. Now I really do think, we're talking about something different. In my framework a user would not want to and would not be able to derive from anything. The XML-files I'm proposing would be much like HTML in some ways. You can use this widget or that and potentially get a bit of scripting, but how would the user (i.e. the plugin-writer) be able to derive from anything? After all, in my case it's the app that somehow has to makes sense of the plugin, not the user writing the whole application, so the application would need to know beforehand, what widget A provides and what widget B can understand.
Perhaps you can provide a (rough) example of how and where this would be used?

Thomas