On 25.03.2013 18:37, 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 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").
I am not sure what your point is. I said that in the past I have
gladly used the opportunity to release bug fixes for the presenter
console without having to wait for the next release of OpenOffice.org.
I do not claim that this is the preferred way.
The presenter console extensions has not been released under AOO because
it was part of AOO and there where not improvements or bug fixes that
needed out of sync distribution. And I did not find the time to put a
new version with updated license into the extension repository.
- 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).
- 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. Is the UNO API perfectly or at least
well designed? No, certainly not. But it is a lot better designed than
the underlying core libraries. Yes, I needed a small set of functions
that where not present via the API. So what? It was not available in
the core either.
"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.
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.
And again, what is your point? The presenter console makes heavy use of
the canvas. The canvas is used for every graphical output, for every
pixel on the screen. And every call to the canvas is made via the UNO
API. Of course you finally implement missing functionality on top of
the core libraries. But that is abstracted away by the API. That is
the major point of it. We could replace VCL by something else. We could
re-implement the canvas and we still would not need to modify the
presenter console.
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.
No I did not, as I hope I have shown above.
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.
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 :-)
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.
No regression but also no improvement.
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.
* 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.
I still don' t see the benefit of the change. But since this looks like
a done deal (did I miss the announcement for this change?) we should try
to make the best of it. I have to admit that I have not seen your
changes yet (I am trying to cloning trunk but my Laptop has some strange
problem and crashes before that operation completes).
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. Any volunteers?
Best regards,
Andre
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
