From: msevior@physics.unimelb.edu.au
Date: Mon Nov 03 2003 - 16:22:26 EST
> Lets jump right to the actual content part:
>
> Our current source tree layout is getting insanely hard
> for people (possible new developers) to grasp. Furtermore
> our build and packaging systems are overly compilicated,
> since important things like plugins and help documentation
> resides outside the main abi module.
>
> I want to propose some changes to our current tree layout and
> present an idea on how bootstrap AbiShow (that cria thingy that
> did not came of the ground) within the current (or new) tree
> layout.
>
Hi Marc,
Thanks very much for getting this started. I'm not sure about the
plugins but I know what you're trying to achieve.
Before we do this with the plugins though I like to suggest we change make
the following changes.
1. Implement a localization scheme so plugins with dialogs or menu entries
can be internationalized. I think we might as well just use gettext. It's
much easier for the translators.
2. Implement a "lazy-loader" scheme. By this I mean something like what
we've been talking about in the gnome-office list. This is:
2.a An XML file description of the type of plugin (IE,loader,menu,toolbar)
, tooltip for the plug, icon, where it goes in the menu/toolbar layout,
internationalization of this information. These entires can be NULL if
there is no tooltip or icon etc.
2.b On start-up all this info gets loaded into abiword, the additional
menu-items and toolbar items are loaded into the application and our
menu's and toolbars are extended.
2.c However the code that actually does the useful stuff (like say
ImageMagic or Aiksaurus) is not loaded until the user requests it.
This way we can have massive hulking plugins with no loss of start-up
speed. The boiler-plate code in every plugin can be abstracted into a
single location that simply parses the XML file associated with the
plugin.
I believe that Gnumeric already has a scheme similar to this and in
discussions on the GNOME-Office list there was general agreement that this
was the way to go.
Regarding AbiShow, I agree we should *just do* something. Initially we
should mirror the wp/ap/* structure with show/ap/*. However I dunno about
moving dialogs for wp/ap to xap/*. This is because almost every single
dialog and a huge fraction of ap_EditMethods would be useful to AbiShow.
Instead I would I like to make everything in wp/ap/* available to show/ap/*
Although we clearly need to define a different menu and toolbar structure,
I would like to able to use everything in wp/ap/* in show/ap/*.
I think this is doable we just need to *not* include stuff that would get
in the way to show.
Cheers
Martin
>
> Proposed Tree Changes:
>
> General Cleanup
> ===============
>
> 1) Move the abiword-docs module into ./abi/docs
> 2) Create ./abi/projects and move IDE projects to it, ie.:
> ./abi/projects/msvc
> ./abi/projects/anjuta
> ./abi/projects/...
> 3) Move the abiword-plugins module into ./abi/src/plugins/wp and
> compile them by default *). Add the configure switches that
> are currently present in the abiword-plugins module to abi's
> configure, so people who don't want plugins can disable
> building them.
>
> This also means shipping them by default in _1_ package. Feedback
> like
> http://gnomedesktop.org/comments.php?op=Reply&pid=19257&sid=1426&mode=nested&order=0&thold=-1
> means we are not serving our users the best way we can. IMO, users
> prefer having most functionality by default any day over a download
> package that is as small as possible. They just want it
> "To Work", something we cannot say at all giving our current
> plugin distribution method.
>
> Besides, quite a lot of users don't even _know_ that plugins
> exists for some particular piece of functionality. That's not
> their fault, that's our fault.
>
> *) Plugins for AbiShow (see below) can go into ./abi/src/plugins/show.
>
> Making room for AbiShow
> =======================
> (Only to be done when developers show interest)
>
> 1) Add an ./abi/src/show/ directory for the AbiShow application
> The layout of this dir will mirror the structure ./abi/src/wp, ie:
> ./abi/src/show/
> ./abi/src/show/ap
> ./abi/src/show/ap/{xp,unix,win,qnx,mac}
> We can start by just 'forking' ./abi/src/wp/ into ./abi/src/show/
> 2) Some dialogs currently residing in ./src/wp/ap, like the
> FormatTable dialog might be moved to ./src/af/xap/, since
> they will be both used by AbiWord and AbiShow.
> 3) Fiddle around with the build system to allow the building
> of AbiShow
>
> Feedback is welcome,
> Marc
>
>
> --
> Marc Maurer <j.m.maurer@student.utwente.nl>
This archive was generated by hypermail 2.1.4 : Mon Nov 03 2003 - 16:20:36 EST