Re: RFC: Pushing Math support into plugins

HI Everyone,
           I have a lot to say about all of this but it will take me a
while to collect all my thoughts into something coherent.

We need to think about the next generation of abiword objects and get the
design right. We have several options and I want to make sure we clearly
articulate them all and to give us time to think of new options too.

Cheers

Martin

On Wed, 7 Jul 2004, Mark Gilbert wrote:

>
> On Wed, 2004-07-07 at 16:17, Marc Maurer wrote:
> > I agree, but it is currently not possible. Our layout engine does not
> > support layouting arbitrairy (and possible unknown) objects.
> >
>
> True, but I get the feeling some folks (not just you) might be
> overestimating just how far from being able to we really are. A lot of
> the format and pt code (regarding fields, frames, images, etc) was
> designed or redesigned with just this in mind (not doing it, but putting
> small pieces in place along the way and making the existing code as
> ready as possible for when it is done, which looks to be soon now).
>
> (restating from irc for list) It isn't trivial, but I think we agree
> that it isn't premature either, we're pretty much ready to make the
> final preliminary discussions (like this) and finally dive into this
> (outside of mainline of course for now).
>
> Martin has the best grasp on those pieces code, since most of it was
> written by him (for examples of stuff that's just begging to be
> abstracted to our hypothetical object, see pf_Frag_Object and it's
> relatives, or see the classes from which your friendly neighbourhood
> frame (textbox) is derived). You can even iirc see bug reports (re
> images, for example) where mention is made of fixes done by utilizing
> the aforementioned classes the way text boxes do.
>
> (look at abi_object.txt, the visual and piece representation of our
> hypothetical object abstraction is just barely more than an abstraction
> of a text box. Add a couple attributes here or there for which textbox
> would use defaults, wind in a couple ui hooks...)
> have you noticed that the proposed visual rep for an unsupported object
> (without a specified alternative rep which was also discussed on irc) is
> nothing more than a textbox with a grey background and missing caret?
> (-:
>
> (I know, it's also more work than I make it sound, just trying to give
> pointers to how I might focus myself)
>
> Anyway, I'm most interested, now that textboxes are in place, in hearing
> what martin has to say about the useful code that IS already in place
> (if needing more abstraction work, just how much, for example?)
>
> > http://130.89.227.64/uwog/abi_object.txt
> >
>
> My main point I've already given, that a lot of the mentioned
> hypothetical classes aren't all that hypothetical. I think a detailed
> survey of fmt/ and pt/ code that isn't use-specific (like the
> pf_Frag_Object code but not so much the *_Bookmark code which uses it)
> would be a potentially good approach. And no, such I survey needn't be
> formal, nor all at once.
>
> Only other point would be to plan on allowing alternative
> representations in addition to falling back on the grey box (for
> example, a jpg/png alternative rep of an svg could be useful for
> displaying on a box without the svg plugin).
> But that's just a detail for later, worrying about it now would be
> putting the cart before the horse.
>
>
> I'm glad we (well, not me, the people who end up coding this) are
> finally getting around to this. I think the timing is right, too. We
> have table and frame and image objects, mathml objects too, in its
> branch. What better opportunity to make object objects (-:
>
> (we also have field objects, marker objects, noteref objects... d= )
>
> Regards
> -MG, nightmarishly verbose as always
>
> Oh, P.S.: Martin, as hard as it is, documentation of your existing code
> (frag_object for example again) would make it a lot easier to work on
> this, and posts like this would be much less speculation, much more
> exact. Uwog and anyone else, documentation of the new arbitrary object
> code is _necessary_ for it to be really effective, because that lowers
> the bar greatly for people who want to implement new features (like math
> or whatever) this way. As discussed on irc, not every project
> maintainer is gonna overhaul his entire codebase for us, like luca's
> doing. What wasn't discussed on irc was how much more useful this
> object architecture is when people besides those who wrote it (who could
> just as easily hardwire new features/deps) can read up and use it.
>
> yay, world's longest P.S., w00t.
>
>
Received on Thu Jul 8 03:14:45 2004