Kalle Dalheimer and I have been having a discussion about possible ways
forward with the GUI-I stuff. Thought you might be interested (and of course,
I'll be able to find this on the archive in future!)
Feel free to comment...
A
Angus> Incidentally, how do you find the new scheme?
Angus> Any suggestions for improvements now that you're
Angus> involved with the nitty-gritty?
Kalle> I was wondering whether it was possible to even
Kalle> abstract the widget access so that only the form
Kalle> construction and the event handling would be
Kalle> toolkit-dependent. For example, where you
Kalle> have in XForms
fl_get_choice( FL_OBJECT* mychoice )
Kalle> we have in Qt
mychoice->currentItem()
Kalle> What could be done would be something like this:
#ifdef XFORMS
typedef FL_OBJECT* WidgetPtr;
#elif defined QT
typedef QWidget* WidgetPtr;
#endif
Kalle> and then:
int getChoiceItem( WidgetPtr choice )
{
#ifdef XFORMS
return fl_get_object( choice );
#elif QT
ASSERT( choice->isA( "QComboBox" ) );
return static_cast<QComboBox*>( choice )->currentItem();
#endif
}
Kalle> This is not very type-safe, of course, so we might
Kalle> want to define a ChoicePtr in addition and define
int getChoiceItem( ChoicePtr choice );
Kalle> instead. On XForms, ChoicePtr would be defined to
Kalle> be a FL_OBJECT* (what does XForms do if you
Kalle> pass a FL_OBJECT* to fl_get_choice() that does
Kalle> not point to a choice object but to something else?),
Kalle> on Qt, it would be QComboBox*.
Kalle> But I am not really sure whether all this really saves
Kalle> more work than it brings.
Angus> It could be made typesafe by templatising it on WidgetPtr.
Angus> However, I don't think we should go too far down this road at
Angus> the moment. First, let's get the current scheme stable;
Angus> I think the LyX developers are very wary now about
Angus> multiple implementations of half-thought-through ideas.
Angus> Something about being burnt badly in the past...
Angus> Note also that giving the frontends the freedom to
Angus> implement their own view allows more sophisticated
Angus> GUIs (no names here!) to bring all their facilities to
Angus> bear. Your idea, would reduce maintenence of the
Angus> different GUIs to near-zero, but would reduce us to
Angus> the lowest common denominator. I think I've heard
Angus> arguments against this from Matthias Ettrich?
Kalle> Yes, you are completely right here. However, if the pieces
Kalle> are small enough, the individual GUIs could e.g. override
Kalle> virtual methods where they want to provide something
Kalle> more sophisticated than the standard.
Kalle> But I completely agree that we should get the current
Kalle> implementation first and have at least one GUI besides
Kalle> XForms complete (complete to the extent that a LyX
Kalle> using that GUI won't link libxforms any longer) before
Kalle> we go down that road.
Angus> Having said all that though, the idea is attractive.
Angus> Your also not alone in having such thoughts. Baruch Even
Angus> has just posted me an attempt to do just this with the
Angus> ButtonController. I'm compiling it now and will post it out
Angus> again, slightly revised, so that you can try it out too.
Kalle> That would be interesting!
