On 3/27/13 2:48 AM, Ariel Constenla-Haile wrote: > 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
why did you revert it? I don't think that it was necessary and it is of course an improvement and a fix for some existing problems. Can you please or would you please so kind to integrate it back again? Or let us know if not than I will do it with your permission. Different opinions came up and we had some discussion and you pointed out that you can live with feedback. Where is exactly your problem now? I don't think that it will help us if we react this way. Really nobody wanted that you revert anything here. Juergen > >> (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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
