On 3/26/13 11:07 AM, Ariel Constenla-Haile wrote: > On Tue, Mar 26, 2013 at 10:32:58AM +0100, Jürgen Schmidt wrote: >>>>> You are right, these extensions were bundled with the >>>>> installation; 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 don't want to discuss the reason for the design as extension >> here because it coming from the past and personally think >> extensions are good fro many things but not for everything. >> >> What I would have preferred is at least a short proposal mail in >> front of the change that you plan to do that. > > 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).
me to but I miss a lot of messages as well, I read so many emails ;-) > > 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. I don't think we need to discuss everything but a short mail should be also no big effort. In most cases where deeper knowledge is required I expect less discussion or feedback. The advantage is that nobody can complain later about the change ;-) I don't think it is a problem. I am working now for IBM today and some people seems to have a problem with IBM as one of the bigger sponsors in this project. We want collaborate with others and don't want control anything. We just want to drive things forward where we can. And I personally started to inform early about potential bigger changes to ensure that people know about it and can't complain later. We did it for the sidebar and involve the community early and collect feedback. That's it. I think the gerrit approach is also very interesting but don't know enough about it at the moment. I am not sure if would really help us at the moment. Or something similar. > >>>> In this special case I would like to know how the user can >>>> turn of the presenter screen. Did you add a button or option >>>> for this?. >>> >>> No, I guess the user can deactivate the UNO component (I'm >>> kidding). How does the user deactivate it now? As bundled >>> extension is not listed in the Extension Manager. The average >>> user will have no idea that the Presenter Screen is installed >>> as an extension. >>> >>>> The original idea was that activation/deactivation is done by >>>> activating/installing or deactivating/uninstalling the >>>> extension. That was somewhat undermined by product managers >>>> who shipped the extension with OOo but hid the Presenter >>>> Console extension from the extension manager. It was still >>>> possible to uninstall the extension but not via the UI. >>> >>> I don't see a regression here, from the user perspective, in >>> 3.4.1 the Presenter Screen cannot be deactivated. >> >> The missing option to disable the presenter screen is a valid >> point from Andre. > > As I answered to Hagar, an option in the Options dialog, and the > respective configuration registry entry is the best approach, and > very doable. > > Note that I am not a "lunatic" who wants to have always the reason > and the last word, nor a "drama queen" who will leave to LO because > someone didn't like a commit of mine; on the contrary, if Andre > does not like the approach, I'm fine with him reverting it :) I don't think this will is necessary, all here are very happy with your work in the project. And the change is not bad at all. > > But please, if doing so, then > > * 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 * fixing the > problem of the double space consumption by preregistered extensions > would also be fine, thought it does not seem simple fixing or reworking, both would be fine in general. I haven't looked in the changes from Stephan in detail but every simplification is welcome. In this area the design was also driven by some questionable decision of others ;-) > > All of these problems are not present with my approach of > integrating these two extensions (I guess this is the reason why it > never crossed my mind that this change would be something > polemic/arguable). one reason to keep them but the issues remain if we decide to bundle a further useful extension in the future. In general it is not a bad idea to have more flexibility here. Allowing the selection of features early and build an office based on this input is nice. And allowing to add initially missed features later as extension is even nicer. Means having features implemented as well formed components would be nice and is the main idea of UNO. The reality is often a little bit different and many small libraries are not the best approach from a performance perspective when they are loaded all. Juergen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
