On Fri, 18 Aug 2000, Allan Rae wrote:
> > I think that taking a break now will be a good idea, we could then try to
> > aim for better support for GUII in 1.2.0, as far as I looked into it, it
> > will require quite a bit of work to get LyX fully GUII, quite a bit of its
> > internals are dependent on X windows calls.
>
> There's GUII and SI (System Independence). X is used on all the Unix
> platforms and keeps us going on Windows and OS/2. Lets get the GUI
> independent of toolkits first (but still dependent on X) and then get
> independent of X. That doesn't mean we should ignore SI issues just that
> we concentrate on sweeping the floor [removing xforms/toolkit code
> from the core] before we polish it [make it shine ;-)].
I thought GUII to include SI, and think that we should go at the 1.2.0
level on a sweeping work to move everything X or Toolkit dependent to
other classes. The work itself to create a
Windows/OS2/Mac/BeOS/Commodore64 version of LyX probably wouldn't be done
so fast anyhow. But the localization of everything frontend related in the
frontends directory/domain is a very good idea IMHO.
> For 1.2.0 I'd be happy to have most of the dialogs in all three toolkit
> ports. We don't need all of them but it would certainly make a nice
> milestone for 1.2.0 to be toolkit agnostic. Then 1.x.0 (x >=3; probably
> x>>3) can be the SI or XI target.
In any way that you look at it, in order to be really toolkit agnostic
you'll need to seperate the frontend from the core. Otherwise you'll have
trouble LyX work completely in a single toolkit, as opposed to now that
the Gnome/KDE ports are part Native part XForms, I know the problem of
porting all dialogs to the toolkit, it takes time, but the main app itself
is not portable, even though there is a move toward it with the toolbars
and the mainmenu.
> [imlib dependency]
>
> I'd rather do without inline rendering until later and have you work on
> all those other things you listed.
I actually consider the inline rendering a must before going to the wild
word of creeping freaturism. Inline rendering is expected anywhere a
graphics is embedded, it will be important also to the External/Graphics
Inset combination, and is as far as I can see it the main reason why I
wouldn't suggest replacing the FigInset with the GraphicsInset at this
time.
Adding features to the GI will not be too hard a task, many things that
can be added are pretty simple to do, some others are more elaborate, but
I do think that none of them is in the order of the inline rendering.
Besides the inline rendering as it is developed now will give me the tool
for a freeping creature, Having thumbnails in the image file chooser, that
will be a neat feature (freeping creaturism or not?! :-)
--
Baruch Even
http://techst02.technion.ac.il/~sbaruch/ (My Site)
http://rpghost.com/jindor/ (My brothers AD&D site)
" Learn to laugh ... it's the path to true love! "
- The Angel in the movie Michael
