On 26 March 2013 11:36, Jürgen Schmidt <jogischm...@gmail.com> wrote:
> 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. > I dont agree with this. Flexibility is in general a nice feature, but having extensions within our main source is not flexibility that is pure confusion. If a feature is an extension then it belongs outside the main source, and if not it should not be an extension (but might of course still be activated/deactivated like other features). I think the idea of simplifying our main source is brilliant and I support every step in that direction...having extensions 1 class (those in the source tree) and 2 class (those kept external) is not simplifying. jan I. > Juergen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
