G. Roderick Singleton wrote:
What is this? Frank if you want details, ask offline. All I will say to
this is that I would like OOo to have its own DevGuide and other
documents as well and avoid problems.
So please explain offline. I'd like to understand.
[...]
Well this would be good. If the doc project goes ahead and gets some
decent words down. We could examine merging at that point or whatever.
Why wouldn't we just build on what's there instead of restarting?
No sources. We are back full circle. No source from which to start for
whatever reasons. This requires starting from scratch, does it not.
You may have read that we are going to have sources to
work on soon. Why that rush now?
Apart from that, we should start discussing a strategy around
this type of docs instead of just starting off. Even with a
dev guide there are still huge gaps in the dev doc space that
should be identified and closed:
- we have the in-depth dev guide that is very detailed
and highly technical for the geeks among us.
- we also have the (StarOffice) BASIC guide as an entry level doc
We are working on addressing this.
Addressing what exactly? I was just meaning to list what we have.
- there is Andrew Pitonyak's excellent macro document
I agree it is excellent. However it is Andrew's and, at this point, we
at the doc project have not approached him about formalizing it in the
documentation set. We have chosen, rather, to host it.
- cross references VBA<->BASIC on docs.oo.o
In the works.
That's good to know. Where are these works documented?
Can one see what's in the works and where it is?
They are accepted tasks for which the authors are taking full
responsibility.
Are these tracked in the task list?
[...]
You mean like a master doc and chapters? Excellent idea. I used the
monolithic approach with the 1.1.x guide and found it unsatisfactory.
The 2.x guide is master and chapters.
No, I mean creating several smaller guides addressing sub-topics.
The dev guide already is a master document but getting to be big
to be easily manageable both from an author's and from a reader's
point of view.
Ah. That would work but considering that we like to publish our larger
documents on Lulu so as to generate some income for OOo, your small
section idea would have to be examined to see how it fits.
Well, why not publish multiple books then? I don't mean to split them
up down to the chapter level. But, say, 3 documents of 350 pages each
would be easier to handle than one book of 1,100 pages. And if
split up in a sensible way they would probably all deserve publication
on their own.
- merge BASIC guide and macro information
Maybe useful, maybe not. Creating a document that addresses only
OOoBASIC macros might not be the best approach. However, that
What else would you like to include?
Python, perl, java are the ones that come to mind. Why do you want to be
restrictive?
One step at a time. The logical first choice is Basic since it's
available to every OOo, has the IDE built in, and can be used
with the macro recorder.
I agree that this deserves to be extended to other script
languages later.
[...]
- create a OOo macro cookbook
Not sure about this one. On the surface, a good idea but I think that
the limited target audience is well served by the wiki and lists.
Why would that target audience be so limited? In my experience
most of the folks that do use macro functionality start off
based on examples.
Most folks want extensions/addons that they simply install and they
work. They do not want to create their own. Those that do want to create
their own, there are the resources I mentioned. Or do you see every OOo
user as a geek? In my experience, this is not so. So explain why you
think that the situation, as I see, does not fit your model.
No, of course not every OOo user is a geek. We have users ranging
from the very beginner that will probably never make it to the site,
or any mail alias. We have intermediate users that are familiar
with internet resources and use OOo as a productivity tool. And
then we have geeks of different levels that would like to do
some of the more advanced stuff with OOo.
If you say, we're serving the second type. That's fine. I think
we need to serve the third type, too. A lot of professional
users of OOo need some sort of automation capability to be able
to use OOo in their evironments. A cookbook (or something similar)
will provide them with the knowledge they need without having
to scrape the information from several sources.
I am not saying that the wiki is a bad place for this info.
We just should have a central access to this and not let the
folks wander around to find stuff. Not everyone is comfortable
with mailing lists.
You are talking to the converted. However, I have no control over the
lists. I have tried in the past to provide a proper site map. If you
have time, perhaps you could map out what we have.
I am not saying that we need a mailing list list. I am saying
that mailing lists may not be the right medium to spread the
information.
On OOoCon2006, this was one of the central topics and from a
strategic point of view, it is planned to be the future for OOo.
It is a very exciting topic, also. Extensions would allow
folks to contribute without touching the inner circle of
OOo source code. Lots of functionality and little tools
could easily be distributed. And you may know from projects
like Thunderbird and Firefox, that a lot of these little goodies
are simple an easy, yet powerful helpers.
Hmm, are TB and FF good examples? I find these more bloated than OOo.
Well maybe. TB and FF have a large and growing user community.
And they have a vibrant contributor community through extensions.
You are free to use or leave those but the fact that these helpers
are available makes TB and FF even more interesting.
However, I will admit that addressing extensions/addons is probably
worthwhile. Who did you have in mind? I ask because all my techie
authors are tied up with on-going projects. Therefore it would have to
Who are your techie authors? Are you having author contact outside
of this group? Sorry again, if I am overlooking the obvious.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
