On 3/25/13 6:37 PM, Ariel Constenla-Haile wrote: > On Mon, Mar 25, 2013 at 05:37:06PM +0100, Andre Fischer wrote: >> On 25.03.2013 03:36, Ariel Constenla-Haile wrote: >>> On Sun, Mar 24, 2013 at 07:04:53PM -0700, Dennis E. Hamilton >>> wrote: >>>> @Ariel, >>>> >>>> This is where they are in 3.4.1. Are you talking about a >>>> change for 4.0 or something else? >>> Yes, by "now" I meant right-now, on trunk (it would be helpful >>> if people -reading this mailing list, not normal users- use the >>> builds from the build bots; it would help finding >>> bugs/regressions early, not one week before voting the >>> release). >>> >>>> The ones quoted below were installed with the normal >>>> installation (which is why they are under C:\Program >>>> Files\OpenOffice.org 3\). I did nothing to obtain them as >>>> extensions. >>> 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. >> >> I disagree and I don't see why this change should be a good >> thing. >> >> Being an extension has several advantages: >> >> - Updates can be provided independently of the AOO release >> cycle. > > When was the Presenter Screen released since OpenOffice is at the > ASF? > >> This is something that I have used several times in the past and >> always was very glad that I had it. > > Did AOO ever release the extensions? No. You can go to the > extension site and there are still the Sun/Oracle versions of these > extensions (the wiki publisher is even named "Sun"). > >> - 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. > >> - 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 :) > > 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 > > "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." > > Could you have developed the Presenter Screen without such a > workaround? The same applies for the ReportBuilder, but we don't > build it anyway. > > A "normal" extension developer could have never developed the > Presenter Screen. The Presenter Screen and the Report Builder > needed code in the application core (and not only designing new > API): for the case of the Presenter Screen, could it work without > the code here? > http://svn.apache.org/viewvc/openoffice/trunk/main/sd/source/ui/presenter/ > > I think this doesn't matter here and the design is of course related to the general decision to provide it as extension. >From my pov it is a very useful core feature and integrated in the code directly make sense. The question is if the design at all would have been completely different without the tweaks and workarounds? > So you choose the worst example, the WikiPublisher and the > Presentation Minimizer are certainly pure UNO code, but the PS no. > >> I personally would like to see more code moved to extensions >> than the other way round. > > While I agree in general, I disagree with the case of these three > extensions. I tend to agree but the ReportBuilder is a different problem. > >> 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. I know we lose this feature with hiding the preregistered extension and nobody have worked so far on this. But I think it is more because the lack of time and resources, isn't it? > > 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 > > * 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. mmh, maybe because we didn't focused on this and had too much to do with the normal release. But such a model can of course make sense for specialized features. Juergen > > > Regards > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
