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 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/ 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. > 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. 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. Regards -- Ariel Constenla-Haile La Plata, Argentina
pgpmVArVS0AkS.pgp
Description: PGP signature
