Re: [Gzz] Asko 2002-12-04/05 (OvalBgVob)

[Tuomas Lukka]

>    - OvalBgVob works now like RectBgVob as backgroud for content, both
>      AWT and GL draws solids (where that term comes from?) as colored
>      stripes

Solid colors. Very bad term -- feel free to use something else,
like "cell colors".

>    + I'd like to implement GL side for all of them as renderables
>      (and make them dice). Though, I'm not yet sure, how should those
>      solids should be handled then. Probably the renderable is only
>      a primitive and solids are created on the Java side. E.g.
>      one solid is created as a colored and clipped part of the renderable.

Hmm. What exactly are the things you want to draw?

>  - Discussed with Benja about making creating views easier. Benja
>    proposed creating some kind of ViewTool, which abstracts view's tasks
>    a litte like VanishingClient does, but more coordsys centered. So,
>    we don't hide coordsys', but make them easier to use. Eg. ViewTool's
>    place doesn't truly place vob, but returns a coordsys for true placing.

What type of methods would ViewTool contain, exactly? Could you give
some examples?

If there are obvious shortcuts, adding them to VobCoorder or VobScene
could also be an option.

>  - We discussed also about the problem, how connection could be drawn
>    differently in LollipopCV and BoxCV. Came up that the same problem
>    exists also with TDecoder. We ended up with solution, where View
>    queries the connection/Tdecoder vob for spesific angle from CV.

Angle from CV? I'm not understanding completely...

Also, how would you make fillets work here?

>  - Finally, Tuomas asked my interest for enhanching current documl tool
>    and trying to write an article about it:
>    + at first architecture htmls should be replaced with rst's, for
>      reST this needs our own UML-directives.
>    + at the beginning of UML-diagram should be a link list for all reST
>      (architecture and peg) pages where diagram is included

>    + the diagram should be included in every documenet where it links to
>    + finally the diagram should be 'personalized' for document where
>      its included (explicitly or implicitly by this script)

Implicitly; we certainly don't want to do all versions ourself.

>      + the current document should be focused by coloring (and maybe
>        later with zooming) in included diagrams, here this gets
>        interesting :)

>    I would be interested enough, if I'm allowed to extract a fully GZZ's
>    cvs independent tool from this. Since everything is LGPL, this
>    shouldn't be a problem - needs only a little more time. 

This is no what you're allowed to do; this is what you're *EXPECTED* to do ;)

In all of Gzz's design we try to make things reusable: Vobs, fillets, libpaper,
mediaserver, now the uml tool: they're all *expressly* designed to be 
independent
of the rest of Gzz.

> What this needs
>    is at least some kind of config and listing all dependencies (javadoc,
>    (docxx,) metapost, docutils). 

I think that's about it. You can do the "strace -f" trick to find out all
files referred to.

> Probably uml.py and uml-helper.mp should
>    be also documented little more :) 

And rewritten a bit.

> My motive is that I could easily
>    use these tools also with other projects than gzz afterwards. And if it
>    gets good enough, probably someone elso wants also...

Yes, exactly. 

If they were for use with Gzz only, publishing would not be interesting.


>    What would be the targets of the paper?
>     - using several doc tools serially together for synergy
>     - embedding architectural diagrams (also within the
>       documentation of single components to show their using contexts)
>     - bidirectional linking within documentation (also within
>       documentation created using different tools)
>     - focus+context in diagrams
>     (- how all this should come naturally in GZZ ;)

Hmm. All these are important, but probably the central point is

        bidirectional links, *easily* (300 lines of python + existing tools),
        for easy-to-browse hypertextual architectural documentation

There's not necessarily anything new in any part of the thing; the new thing
is that we put together many old things, a little of our own and out comes
a complete, working system.

        Tuomas