> Well, once LyXView is done, you have a working LyX anyway. Sure, some
> popups don't work, but it compiles and runs...
Yes, I know. However, LyXView might be the big one. That is my only
hesistation: If we need to port LyXView first, it might take a long
time to get a port running.
But, it'll be easier to judge when LyXView is done.
Maybe we can make it a piece-of-cake to port LyXView.
> 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.
No, but having something that at least runs is important. This allows
you to port a pop-up, test it to see that it works, and then start on
the next.
If LyX is not running at least so much that you can use the menu or
the keyboard to load files and such, you'll have a hard time testing
the menus.
Ok, one potential insight emerges: The first thing to port is the
minibuffer. With that ported, we can test all new pop-ups, even
if the menu and such is not working.
And even without a minibuffer working, we can use the LyXServer to bring
up the pop-ups initially.
> Some sort of LyXEvent, you mean? Yes, this would be nice, but maybe
> difficult.
I think a bunch of slots can do it. Shouldn't be too hard.
> 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).
Depends. Most of the time, the X11-based painter will fit the different
toolkits fine. Other times, it won't (ncurses, windows). When it doesn't
fit, a reimplementation is needed.
Lgb is doing some good work in getting the painter.C file minimal, such
that porting to a new graphics system is easier.
> - is there some provision in the painter to select colors suitable for
> mono screens (i.e. avoid black-on-black)?
Not currently, but we plan to do that: In the list of colors, add a
bool: "Foreground/background" color. With this single boolean, we can
ensure that we don't get black/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]
Yes, it should. Go ahead.
Greets,
Asger
