Hi Maarten,
:murb: [maarten brouwers] wrote:
Hi Ingrid,
Let me try an example with the chart to show the problem:
[snip]
There are many many other modules involved.
Hmmm. Just to keep the focus clear, do you also like to present this
type of information already? Or is this merely to illustrate that
creating a table as suggested by John is very hard to accomplish?
Both :-). I think a 2D table is not suitable. But I think we need to be
able to answer those two questions to newbie developers:
1) 'What does this code?' and more important
2) 'Where is the code for this feature?'
1) 'What does this code?'
I think this question is more or less answered by the description of
each module. You can find a list of the modules that belong to a project
somewhere on the project sides.
But we could do better here:
a) The descriptions could be better (more precise, more correct, more up
to date).
b) The representation of the modules on each project page should be the
same. Thus orientation and searching is easy.
c) In addition I would like to have one list containing all modules.
This would make searching for buzz words easier.
2) 'Where is the code for this feature?'
I believe we could entlist more developers when we would offer an answer
to this question. So the newbie developer can find an entry point for
debugging. We could start with a few more global features like 'Impress
or Chart' and put more and more features later on. So the list could
steadily grow.
What do you think?
I
think it should be possible to not focus too much on the connections
between the projects, but mainly on presenting the projects itself in a
much more structured manner. Of course this structure will probably
relate to how the projects relate to each other, but then from a
relative abstract point of view.
The problem with the existing project structure is that it already tears
apart things that belong together. For example the functionality to load
and save impress documents is in the module xmloff. But xmloff belongs
to the XML Project not to the Graphics Application project.
Thus when you try to figure out where the code is that loads you impress
wrong the project hosting the impress is a dead end for your research
activities.
So I think it is important to reflect the existing connections between
the projects with cross links or something.
I could imagine e.g. having the blocks writer, calc, impress/draw, and
these packed in whatever project creates the basic architecture, which
also includes offering additional 'services' like chart functionality.
Saying that Writer, Calc and Impress do create the basic architecture
draws a wrong picture. If you would say 'these are the main
applications' ok thats right (maybe Base in addition?). But the main
applications do not create the basic architecture. If we would want to
offer a chart without Writer and Calc and Impress (and we did that
somewhere in the past with StarOffice 5.2 ) we could do that. So the
chart from the architecture point of view does not sit 'on' or 'in'
those applications but beside them.
Putting the chart into the applications in any picture brings the
problem that you have to duplicate it for all applications. It is in
Calc as well as in Writer as well as in Impress. So for example where
should you put the help for charts in a book? In the impress chapter
only? That would be wrong. The chart needs to have an own chapter that
can be pointed to from all using applications. And I believe this
argument is valid for all other 'additional' services that are used from
more than one application (Math, Basic Macros, Spellchecker, etc. )
Above all blocks the ui project... etc. These kind of drawings are
pretty common right, in communicating basic software architecture?
Wouldn't that be an idea for the project page, and in addition add links
directly to the development page and/or end-user page? If draws it, and
tells me where the links should point to, I'm willing to turn it into
some friendly looking HTML.
When we put the 'additional' services also to this picture ( maybe as
satellites around the main applications ) and connect each part of the
picture with a related project page (or an extra page as for charts) I
would be fine with that! Yeah great.
Yours,
Maarten
Ingrid
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
