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 extension 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: http://lists.freedesktop.org/archives/libreoffice/2012-August/036627.html > >>- 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: > > SHL1STDLIBS= $(CPPUHELPERLIB) \ $(CPPULIB) > \ $(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: > >http://www.openoffice.org/api/docs/common/ref/com/sun/star/drawing/XPresenterHelper.html > > 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 http://hg.services.openoffice.org/OOO340/rev/c376a483f2ef 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: > >https://issues.apache.org/ooo/show_bug.cgi?id=120606 Of course, the > >proper fix for this bug is fixing it. Why is the Presenter Screen > >a bundled extension? To work around > >https://issues.apache.org/ooo/show_bug.cgi?id=120338 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? https://issues.apache.org/ooo/show_bug.cgi?id=120606#c10 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: http://svn.apache.org/viewvc?view=revision&revision=r1461094 http://svn.apache.org/viewvc?view=revision&revision=r1461102 > (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 > > https://issues.apache.org/ooo/show_bug.cgi?id=121871 > https://issues.apache.org/ooo/show_bug.cgi?id=121872 > https://issues.apache.org/ooo/show_bug.cgi?id=121873 > > 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, etc.) > 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. Regards -- Ariel Constenla-Haile La Plata, Argentina
pgpypj_kEgmFK.pgp
Description: PGP signature
