Re: GSoC07: keep dialogs in libabiword?

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-----
>
>
Received on Fri Apr 27 16:48:26 2007