Hi Ariel,
Ariel Constenla-Haile wrote:
Hi Jürgen,
Juergen Schmidt escribió:
Juergen Schmidt escribió:
JS> mmm, a useless statement with out any concrete examples, isn't it
I'm happy to provide the example, but don't know how to do it. Do you
want me to attach the Eclispe project as a zip file?
Why not? I plan to provide all SDK examples as NetBeans projects.
Why not for Eclipse?
that is a great idea :-)
Since the JDK came with its examples as NetBeans Projects, I was
wondering why wouldn't OOo SDK do the same (...well, reading
sometimes some mails in [EMAIL PROTECTED] against Sun, I thought you
had your concerns, and didn't want people to start complaining also
about this).
As I am in my Southern-hemisphere-summer-of-code, if I can help with
this, let me know: I have already turn some SDK examples into
NetBeans Projects.
cool, let me know which examples do you have already converted.
I'm not at home now, so I can't recall... but I have severals, last one
I've made was the amazing EmbeddedObject example
(/examples/java/EmbedDocument/EmbeddedObject), the GUI examples (BTW,
one of them crashes OOo: UnoMenu.java, I had the same problem when
closing a top window, IIRC I had to dispose both the XFrame and the
XWindow to prevent the crash...not sure, I will have to debug it), the
Filter examples, the Components examples, etc.
I had some questions:
* In some cases, I did them with an older version of the plug-in, not
using the central registration class IIRC. Should I change the examples
to "make them fit" to the latest plug-in version?
yes, if possible i would prefer projects based on the latest version
* although the plug-in does not support NB 6.0 I'm using it: it has
several enhancements, among them it shows all *unused* code. This way I
could see that some SDK examples need some clean-up. Should I clean-up
the code, or just turn them into a NB Proj. as they are?
it depends, some examples show tow different ways but only one way is
per default used. But in general i would say you can and should clean up
the code when it's obvious.
* naming issues: what should be the package name, the extension
identifier, etc? For packages, I tried to use, when possible, the SDK
file hierarchy: for example, for
sdk/examples/DevelopersGuide/GUI
I used
org.openoffice.sdk.examples.devguide.gui
but I'm not sure if it is a good idea: the package name turns out too
long :-(
well the length shouldn't be a problem but i would align it a little bit
more with the wiki structure
org.openoffice.sdk.samples.gui
My idea is to provide the projects as zip files. I will provide a
place in the cvs section of the api project. I would also like to have
some docu for each example in the Wiki.
how should the docu be? a simple introductory comment referencing where
in the Dev's Guide to find the technical explanations? or something more
complete?
good question, i woudl suggest that we simply start with a base docu and
can adapt it later on ... Let it evolve
The idea is to put them under
http://wiki.services.openoffice.org/wiki/API/Samples/Java and there
under the appropriate category. The wiki page will link later to the
zip file. The docu can be shared for Eclipse projects as well.
Does that make sense?
why not shipping them with the SDK, as the JDK does?
i will split the SDK. The base dev tools etc. should be part of the
office installation (an optional package). The docu (mainly the
DevGuide) will be moved in the wiki (coming soon) and the examples
should available as a separate download and the docu for the samples
should be in the wiki as well.
I'm not sure if the wiki is the best place: for example, I just counted
two developers asking questions in the extensions mailing list about the
complex toolbar controls, so I suppose not many developers are trying
this amazing feature, and think that the reason why not many
[extension's] developers know Carsten Driesner's tutorials is because
they are quite "hidden" in the wiki; and on the other hand, the SDK
example is in Cpp (of course not very accessible for developers not
knowing Cpp).
i think that will change. We will make more noise around this things and
the docu wiki should be the place in the future where such tutorials
can be found. Flash demos etc. are also very useful ...
Do developers really search in the Wiki for documentation, or just use
the SDK? I tend to think this last one...
mmh, i don't know but i think it's not the problem of the wiki but more
a communication problem and i am sure that we will improve it.
Juergen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
