Re: GSoC07: keep dialogs in libabiword?

Hi Ryan,

Just to be clear, neither Rob nor I are advocating removing our native
Win32 or MacOS port. I'm using GTK+ as a convenient example to argue
from, as it seems that we've been actively re-moudling that port for
different sub-platforms (hildon, olpc, ...).

As you said, a "GTK+-everywhere" approach isn't feasible until we make
major modifications to our graphics and font classes, and that largely
depends on the viability of Cairo + GTK+-print on Win32 and MacOSX.
We're not close to being there yet.

Best,
Dom

On 4/27/07, Ryan Pavlik <abiryan@ryand.net> wrote:
>
> I agree with this non-exclusive approach, as I see three potential kinds
> of consumers for AbiWord:
>
> 1) Embedded developers (hildon, sugar, develop could go here or #2)
> 2) Developers who want to integrate rich text/document support (for
> report generation, etc)
> 3) People who actually want to use AbiWord.
>
> It seems like an approach along the lines of what Tomas is discussing
> does a good job taking care of both 1 and 2. I'd just like to put in my
> obligatory plug for #3 - these are some fairly radical changes being
> discussed if I understand this correctly, and I want to make sure
> Windows (and Mac OS X) support is not being overlooked in the
> discussion. Until we move to Cairo, GTK-Print, and I am satisfied that
> GTK-Print produces acceptable results in a nearly-native way on Windows
> (and presumably also Mac), I will not be satisfied with a GTK port as
> our only Windows port. I will have time this summer, thanks to SoC, to
> take care of some of the more irritating problems with the Abi Win32
> port, as well as bring it up to speed in terms of feature parity, so
> please don't write Windows off yet! (If we completely [naively] ignore
> external distributions and AbiWord Portable, Windows still blows
> everyone else out of the water on our download graphs...)
>
> Ryan
>
> Tomas Frydrych wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi Rob (and everyone else, of course),
> >
> > Having read through what has been said through this thread, I see number
> > of good points on all sides, and here is my take on things:
> >
> > 1) As an embedded software developer in my day job, I would like to see
> > a lean and mean libabiword that provides the MV and a clean, easy to
> > use, controller API. I do not want the UI in the lib, as I want to be
> > able to write an UI of my own, typically following different use
> > paradigms, facing severe HW resource restrictions, and possibly using a
> > custom toolkit. I would like, like Dom, to have something that I can
> > work with in normal gtk way, as gtk is rapidly becoming the toolkit of
> > choice for mobile/embedded Linux.
> >
> > 2) When I take my embedded hat off, I find myself agreeing with Martin.
> > I want a library with the complete AbiWord UI in it that I can use,
> > subclass (or ignore) if I wish to; it makes good sense for something
> > like the presentation application Martin wants to write, providing
> > maximum possible code reuse.
> >
> > I do not think the two are exclusive; I would, like Marc suggest having
> > two libraries, libabiword along the lines that Dom and Rob have in mind,
> > and a libabiword-ui, containing the complete AbiWord ui, dialogs, etc,
> > implemented as a user of libabiword. I think Dom is right that we have a
> > really good Model and View, but that the way in which those can be
> > controlled is suboptimal (Mike Nordel has been making this point as far
> > as my memory reaches), and I do believe that if we fix this, it will
> > open many new possibilities for us.
> >
> > So, to come back to Rob's query, I heartily support Rob in what he
> > originally intended with this SoC project, a lean and mean libabiword
> > with a sane API; I see this not as an end in itself, but as a
> > (necessary) step in the right direction (toward world domination, where
> > else, of course).
> >
> > Tomas
> >
> > P.S. I think we really should get 2.6 out of the way ASAP -- it seems
> > that no longer just our minds, but also our efforts are being spent in
> > the 2.7 era.
> >
> >
> >> Hi Dom,
> >>
> >> there's been an IRC discussion whether to keep abiword's dialogs in
> >> libabiword yesterday. That'd of course be a deviation from my/our
> >> current plan to focus on (see also [1])
> >> (1) slim libabiword, but with migration path
> >> (2) libabiword API
> >>
> >> Martin and also Marc to some extent advocated keeping the dialogs, the
> >> main argument was that the code/installation size decrease wasn't
> >> worth the loss of functionality. Hub pointed out that if I thought it
> >> was too hard to create or modify dialogs I should fix the framework
> >> instead -- which would be of course a monster project and there's been
> >> precedent of abandoned dialog migration efforts [2].
> >>
> >> My counterarguments were that with a sane "model" interface it would
> >> be comparatively easy to implement dialogs as a libabiword consumer
> >> and that -- given an existing language binding -- dialogs could be
> >> implemented in whatever language. Also there's a number of assumptions
> >> connected to the way modal/non-modal dialogs work, that might lead to
> >> problems for apps using multiple abiwidget instances. Finally one has
> >> to start somewhere, I decided that this starting point/project should
> >> be a nice standalone rich-text widget, and there's of course the
> >> possibility to create a "libabiwidgets" at some later point in time.
> >>
> >> So much for the context, it would be helpful if you would weight in as
> >> my GSoC Mentor.
> >>
> >> [1] http://www.abisource.com/twiki/bin/view/Abiword/LibAbiwordDiet
> >> [2]
> >> http://www.abisource.com/viewcvs/cgi/viewcvs.cgi/abi/src/af/xap/unix/xap_UnixWidget.{cpp,
> >>
> >> h}
> >>
> >> Thanks,
> >> Rob
> >>
> >>
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.3 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iD8DBQFGMbk3Qf19fl0LrwsRApUTAKCYuFIanevamfbaXawI4zdTWUHtuQCdH6vX
> > vu2lIVMl3y3ZcA4f7Y71oVE=
> > =n2oq
> > -----END PGP SIGNATURE-----
> >
> >
>
>

-- 
Counting bodies like sheep to the rhythm of the war drums.