>>>>> "Asger" == Asger Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> I understand the problem, and have considered it myself.
Asger> However, the benefit of doing a multi-toolkit port are worth
Asger> it, IMO. This approach allows us to do this stuff in an
Asger> incremental manner, and this have a working LyX.
Well, once LyXView is done, you have a working LyX anyway. Sure, some
popups don't work, but it compiles and runs...
Asger> I haven't given this idea much thought, but instead of having
Asger> the stubs, what if the Qt port simply pretended that all the
Asger> XForms dialogs were Qt-dialogs? I.e. let the Qt port use the
Asger> XForms code as a slave? Ok, that is the general idea. How to
Asger> realize this? I don't know right now.
I fear that trying to get a new port fully functional from the
beginning is more work than benefits. I guess you are not planning to
use a brand new incomplete port for real work, anyway.
Asger> Regarding the signals for the LyXView (and more importantly for
Asger> the work-area) I mentioned: We need to encapsulate keypressed,
Asger> mouse-clicks and motions in the work-area to something GUI
Asger> independent.
Some sort of LyXEvent, you mean? Yes, this would be nice, but maybe
difficult.
I have a few questions loosely related to the above, but that I never
had the occasion of asking. Here they go
- will the painter be ported to use the native functions of the
toolkit (Qt, glib, gltk), or will it remain X-based? If it is ported,
it would work somehow transparently on windows (for those three
toolkits).
- is there some provision in the painter to select colors suitable for
mono screens (i.e. avoid black-on-black)?
- if support/include/Toolbar.h is supposed to be used in a toolkit
independant way, shouldn't it hide its tk-dependant variables in an
opaque data structure? [I can do this one]
That's all I can think about for now.
JMarc
