Le 23 févr. 12 à 11:49, Andre Fischer a écrit :
Hi Maho, Eric,
Hi Andre,
On 23.02.2012 11:03, eric b wrote:
Hi,
Le 23 févr. 12 à 08:37, Maho NAKATA a écrit :
quoting from slideshow/source/engine/makefile.mk
.IF "$(ENABLE_PRESENTER_EXTRA_UI)"=="YES"
ENABLE_PRESENTER_EXTRA_UI is not used anymore
.ENDIF
That's not true.
I am afraid it is. OpenGrok shows that this flag is only evaluated
in sd/source/ui/slideshow/makefile.mk and in slideshow/source/
engine/makefile.mk and in both places you are only warned that this
flag is not supported anymore.
Ooops, excuse me : I was refering to 3.2.x tree (I'm used to use
OpenGrok, nice tool btw).
Indeed, reading quickly the code in DEV300_m106 tree, such flags are
no longer needed. I found the XDrawPages still used, and this means
the code has been integrated ( yes !). Testing with a recent build I
even got the color dialog box initialized too.
The bad news is the annotations are not persistent. What was the
reason ? (at the beginning, the idea was to make them persistent, and
to save the presentation including them or not at the end)
On my side, I got the current status:
- the annotations are persistent
- the redraw causing growing memory fooprint is fixed (every time
you goto next / previous slide, the annotations are no longer
duplicated as before)
- annotations are visible in the slideshow excepted for the first
slide (investigating)
- OpenGL transitions on Mac OS X : annotations are now visible
Residual bugs: :
- reverse order is wrong (no annotations), excepted during
transition ( prefetch slide seems to have problem, and there is one
inut offset somewhere. Searching where ... )
(probably the same root) :
- OpenGL transition on Mac OS X only : it is not possible to add
annotations during the presentation (caused by the last view at the
end of the transition, not removed
- OpenGL transition on Mac OS X only : last transition view is not
removed, and hides everything in the window when presentation stops.
If interesting, everything mentionned above could be reversed to
Apache OpenOffice (if the code worth it of course)
The flag is also mentioned in XSlideShow.idl but only in a comment.
I see.
The only think that has to be checked are references in several
localization files. Removing the flag might lead to missing
translated strings.
Indeed. I think we could ask the translators to reverse the strings
to apache OpenOffice ?
FYI, I modified l10n build system, and if you are intersted, I could
explain how I improved.
quoting from configure.in
AC_ARG_ENABLE(presenter-extra-ui,
[ --enable-presenter-extra-ui enables extra functionality during
slideshow,
e.g. selecting pen color, erasing drawings etc.
],,enable_presenter_extra_ui=no)
Which can be used? I don't know.
It is used for Impress annotation mode feature (pen, color,
eraser). The
code was written by Ecole Centrale Nantes students, mentored by
Thorsten
Behrens and myseld, with Education Project.
Whatever code was written, it is now either gone or is not guarded
by the ENABLE_PRESENTER_EXTRA_UI flag anymore.
You are right, it can be removed in the current code. Or why not,
kept for new features to come ?
We added those flags, because the feature was not well accepted
(don't
ask me why ...)
OT : this is one good example of what we did with the OpenOffice.org
Education Project, students from engineers schools : a winner -
winner
example.
Anyway cleanup is needed.
Yes, please go ahead. Can you check the localize.sdf files in
extras/l10n that contain references to ENABLE_PRESENTER_EXTRA_UI?
In Apache OpenOffice I don't know, but FYI, I fixed some issues
and I am
currently improving the feature in OOo4Kids and OOoLight.
For OOo4Kids and OOoLight the situation may be different. By the
way, are there any plans to integrate OOo4Kids into Apache
OpenOffice (if that is possible at all)?
OOo4Kids ( OOoLight shares the same code) are based on OOo3.2.x, and
until I'll find a full diff explaining what has been changed into the
new config manager, the upgrade to OOo3.3.x + sources is compromised.
Nevertheless, and as I explained Armin on IRC, there is work in
progress to integrate the native SVG feature he wrote. This will
force me to resynchronyze most of the tree with 3.3.0. No idea how
complete this will be though, and I'm testing several scenarii for
the integration -> investigating.
Back to your questions, IMHO, integrate OOo4Kids into Apache
OpenOffice is not a good idea : it will take a lot of time, will add
a lot of files (the whole design), and complicated things at
configure and buid time. Worse, some parts like design are under
LGPL, and can't be re-used excepted if Ben Bois accepts to relicense
all the stuff.
What is possible : I wrote most of the modified code in OOo4Kids, and
if some feature is considered as interesting, there is no problem to
reverse the changes I wrote to Apache OpenOffice.
Since OOo4Kids is a lab, better use what has been done when
interesting, instead of spending more time to integrate the whole thing.
Note: for code relicensing, and on the design side, ask Ben Bois. On
the localization side, I can ask the people who contributed, to
relicense their contributions.
Though, thanks for your answer : testing Apache OpenOffice to verify
what was integrated / what was not, helped me to see a very good work
has been done since my last test :-)
Best regards,
Eric
--
qɔᴉɹə
Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page
L'association EducOOo : http://www.educoo.org
Blog : http://eric.bachard.org/news
