openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ariel Constenla-Haile <>
Subject Re: [CODE][PROPOSAL]: AOO 4.0 getting rid of the 3 layer office, part 1
Date Wed, 27 Mar 2013 01:48:55 GMT
On Tue, Mar 26, 2013 at 11:03:09AM +0100, Andre Fischer wrote:
> >>>IMO it was a non-sense from the beginning to develop these as
> >>>extensions (at least the presentation minimizer and the presenter
> >>>screen, that have no external dependencies).

> >>I disagree and I don't see why this change should be a good thing.
> >>
> >>Being an extension has several advantages:


> I am not sure what your point is.

I'm not into "making my point", nor having the last word; I already
explained why I think these extensions are no extension at all, and why
shipping them as pre-registered extensions is a bad idea; so I'm not
going to start arguing, at the end I think my approach is good, you'll
think it's not, and this won't change.

As you repeated several times that "you don't get  what my point is",
and I think I was already clear in this mail and the one to Hagar,
I summarize, may be you get it clear: 

These are no extension at all (this meaning that their conception and
realization goes against the notion of an "extension" that allows
developer to extend OpenOffice without having to learn any single line
of source code, nor modify the source code, nor build it), because:

- an extension that requires the extension developer to modify the source
  code is not truly an extension
- an extension that requires to get the whole source tree and set up the
  build environment in order to compile the OXT is not truly an

The right approach, IMO, would have been at least to make these
extensions buildable with the SDK only, at the time of being developed
the SRB and the MySQL/OOoConn I pointed this out on the dba mailing list
(in particular for C++ extensions, this has the advantage that if linked
against older URE libraries, for a particular OOo version is needed, you
only need to keep a copy of OO and the SDK, not a whole source tree)

That's what I called a "non-sense from the beginning".

My other main opinion is that pre-registered extensions are bad, and
applies to the following as well:

> >>- Easy control over the feature set that is shipped with OpenOffice.
> >>This is something that we use extensively for dictionaries.
> >If dictionaries were ALv2, for sure AOO would include them, as
> >Sun/Oracle did (this was something the native-lang asked for long
> >time).  So this is something we use with dictionaries just because we
> >cannot include them by default.
> No.  If the licenses where different then we would still need a way to
> make the set of included dictionaries configurable.  We might end up
> using pre-bundled extensions for that.  If otherwise dictionaries
> would be integrated into some module, then we would have to build the
> whole office for each language set (a matter of hours) instead of just
> building the installation set (just some minutes).

I was talking about the way Sun/Oracle did it. Not as pre-registered or
bundled extensions, but as packages by their own. I only know about
Linux: the dictionaries were in their own rpm/deb package and you could
choose whether to install it or not (may be on Windows this translated
to select a custom installation, and un/marking the dictionary to be
installed). From a Linux user perspective, this is a regression, and you
are forced to install both the dictionaries and the pre-regs with the
basis core-01 package.

And as for pre-registered extensions and unopkg sync being bad, sorry
for the fallacy of appealing to an authority, but I'm not insane to
think I know more than Stephan:

> >>- Forces the developer to write clean code that does not use
> >>anything outside the ODK.
> >You must be kidding, "nothing outside the ODK" is not what happened
> >with the Presenter Screen, you know this as you were the one that
> >developed it :)
> No, I am not kidding.  If I look at the makefile of the presenter
> console I see this for linked libraries:
> \ $(SALLIB)
> >
> >The work-arounds used to develop the Present Screen only show how
> >badly designed is sometimes the API (I'm talking about the canvas
> >module, a *whole* API module that cannot be used by the API users).
> >IMO this is the proof that this was no clean code that uses only
> >stuff in ODK:
> >
> Again.  I don't see your point.

See above, an extension should not require the extension developer to
study any single line of core code, not modifying it, in order to
achieve the goal of the extension.

> >"This interface is a collection of functions that are necessary to
> >implement larger parts of the presenter screen as extension. The
> >methods of this interface give access to services that can, at the
> >moment, only implemented in the Office core, not in an extension."
> And it goes on like this:
> "With time some, maybe all, methods can moved to other, better suited,
> interfaces."
> I admit that I was too lazy to do that and clean up the UNO API a bit
> more.

I didn't cite the continuation of the paragraph on purpose, but now you
bring it: this was a workaround, the proper fix would have been to make
the canvas factory API work with plain API stuff, making it possible to
initialize it with a css.awt.XWindow.

The "with time some ..." just puts this workaround on limbo, since added
in 2008 
instead of fixing the CanvasFactory bug and making the rendering API
available to API users.

> You are right.  I mentioned that in may mail, see next paragraph.
> I was hoping that I would find the time in the future to fix this but
> not this seems to be your task :-)

Not anymore :-)

> >So I see the following advantages:
> >
> >* pre-bundled extensions are broken on Linux:
> > Of course, the
> >proper fix for this bug is fixing it. Why is the Presenter Screen
> >a bundled extension? To work around
> > Could the
> >extension be a normal extension as downloaded from the extension site
> >without deadlocking? This is just another point to have this
> >integrated and not as an extension
> Including the pre-bundled extensions into the core is a workaround not
> a fix.

In my perspective the workaround was to make the extensions
pre-registered extensions, because of the deadlock bug, instead of
fixing it.

> >* we have three extensions that we never released. Why? I'm not sure.
> >But for these three, the argument that having them as extensions
> >allows a release cycle independent from the main application release
> >doesn't seem to apply.
> This is not my conclusion.  We are still able (well until your
> changes) to release the presenter console under Apache license if the
> need would arise.  We did not do that because it was not necessary.

Not necessary?
Running unopkg sync as root is not user friendly, a workaround, it is
broken, it leaves folders after uninstalling, etc.

> I still don' t see the benefit of the change.

For me the benefit was obvious, but I won't invest time in convincing
you, nor in extending the discussion.

> But since this looks like a done deal

you got the wrong idea:

> (did I miss the announcement for this change?)

read my answer to J├╝rgen:

> Mea culpa, it didn't ever cross my mind to do so, nor thought the
> change was controversial, I just opened the bug reports on March the
> 9th
> submitted the patch, and in the weekend committed the code (which
> I tested on two platforms for two weeks). I would expect that
> people/developers are subscribed to our issues mailing list, and read
> the bug reports (at least, I do so).
> If for every code commit you expect a mail (and possible -IMO-
> pointless discussion here on the mailing list with people that know
> nothing about code - what at the ends is just of waste of developer
> time reading the mails and answering), then it would be better to
> implement code review, like LO has done with gerrit.


> The current design of the presenter console is centered on it being an
> extension.  It uses the API for everything.  Although I am not aware
> of any serious flaws with this design it should be modified to take
> advantage of the core libraries now being freely available.  Doing
> that would require a complete re-implementation.

Not necessarily; there are several UNO components shipped with the
Office, the PS and PM could have been among them, without the bugs and
ugliness of pre-registered extensions, until someone volunteered to do
a full integration (using an svt::RoadmapWizard in the case of the PM,

> Any volunteers?

was this rhetoric? was this sarcastic? never mind, for me this
"discussion" ends here. But as these extensions will still be
pre-registered extensions

> * fix the preregister extension/uno sync brokenness on Linux
> * and/or fix the original bug with the deadlock which ended on the
>   extension being prereg.
> * and make sure that in time, for the release, the extensions are
>   ready to be released, too

These extensions as pre-registered extensions, but not working
on Linux is IMO release blocker, it must be fixed before releasing.

Ariel Constenla-Haile
La Plata, Argentina

View raw message