On Fri, 18 Aug 2000, Baruch Even wrote:
> 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.
Yes, but I want 1.2.0 out this year not next Christmas. Just take smaller
steps between revisions. We have people working on dialogs, so we get
the dialogs done. Lars and JMarc have been working on toolbar, menu,
LyXView, Painter etc. but there's still a way to go.
> 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.
Of course it's a good idea. It just takes time. Rather than do
everything and then release a final-all-cleaned-up-no-more-work-to-do
version we need to make several smaller steps with several
releases. Remember, all those emails about why we switched our
development process? Why we abandoned the first attempt at a
final-all-cleaned-up-no-more-work-to-do version?
> > 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.
Sure. We are in a transition phase. Even when we reach a state of
complete separation of frontend and core, new ports will still want to use
mixed toolkits just so they are able to get people to use and test them.
We don't need to have everything done at once. We aren't capable of doing
everything at once (despite our recent growth; and throwing more
developers at it won't make it go away any faster). So we will get there,
we do have the same long term goals. Just seems we have a different idea
of which road to travel (or how many roads to travel on at once) to get
there.
> > [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.
I'd be inclinded to merge External and Graphics sooner rather than later.
It seems to me that you could then externalise the various conversions and
reduce your workload overall. However, a merged External+Graphics might
not look much like either of them currently does.
> 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?! :-)
Adding features of any sort is easy (or should be). It's getting the
foundations right that is the hard part.
Allan. (ARRae)
