Re: GSoC07: keep dialogs in libabiword?

-----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 10:49:46 2007