1 |
Tasks for navidoc |
Tasks for navidoc |
2 |
|
|
3 |
0.1alpha1: First separate release |
humppake: |
4 |
anybody: |
- classify following between the first and second release, |
5 |
- umltool: mputils.dbg for handling screen output and logging |
priorize etc... |
6 |
- document our UML software (metacode/uml*, |
- PEG the new architecture |
7 |
used by doc/uml/*) |
|
8 |
- reST -> latex (cleanup?) |
... |
9 |
|
- document our UML software (metacode/uml*, used by doc/uml/*) |
10 |
|
- figure out need of restructuring |
11 |
|
|
12 |
|
- rationalize doc directory structure: |
13 |
|
!! Depends on pegboard upgrade for simply compiling of |
14 |
|
deep tree structure !! |
15 |
|
Gzz_Frontend_View.rst -> doc/frontend/View.rst |
16 |
|
(i.e. no Gzz_ prefixes, tree structure explicit) |
17 |
|
|
18 |
|
UML language: |
19 |
|
|
20 |
- fix umltool graphics to be closer to the UML 3amigos books |
- fix umltool graphics to be closer to the UML 3amigos books |
21 |
|
- Fix UML sequence diagram: now you have to put |
22 |
|
seqobjects *after* the sequence... |
23 |
- fix dep directive to be |
- fix dep directive to be |
24 |
dep BuoyViewNode "calls" BuoyLinkListener |
dep BuoyViewNode "calls" BuoyLinkListener |
25 |
instead of |
instead of |
26 |
dep "calls" BuoyViewNode BuoyLinkListener |
dep "calls" BuoyViewNode BuoyLinkListener |
27 |
currently. Involves fixing many diagrams! Reason: then can use in class: |
currently. |
28 |
|
Involves fixing many diagrams! |
29 |
|
Reason: then can use in class: |
30 |
class BuoyViewNode |
class BuoyViewNode |
31 |
dep "calls" BuoyLinkListener |
dep "calls" BuoyLinkListener |
32 |
because inside class, the class is given as the 1st argument. |
because inside class, the class is given as the 1st argument. |
33 |
- make pegboard to be only a directive, when all reST could be |
|
34 |
compiled using $(JYTHON) metacode/umldoc.py `find doc -name "*.rst"` |
Design issues: |
35 |
- enhancing umltool |
|
36 |
- rationalize doc directory structure: |
- make sure that umltool works also with pure doccxx |
37 |
- Gzz_Frontend_View.rst -> doc/frontend/View.rst |
=> doc++ plugin |
38 |
(i.e. no Gzz_ prefixes, tree structure explicit) |
- nested classes in javadoc: grep for MipzipLoader.Level |
39 |
- nested classes in javadoc: grep for |
=> issue of javadoc plugin |
40 |
MipzipLoader.Level |
|
41 |
- a lot of things, which would be easier to handle with better |
- Currently diagrams are embedded into html-documents after |
42 |
design, so these will be fixed on the second implementation |
the first header-tag. This could be enough for javadoc and |
43 |
round with more object-oriented design |
other, but in reST this should be possible to overdrive by |
44 |
Two of the following would be fixed with re-design of |
own directive. |
45 |
jlink class. |
- diagram names should be unique, currently this can't be |
46 |
- fix jlink focus matching problem, currently matching sees no |
easily tested, make something for it |
47 |
difference e.g. between View (Java class) and |
+ Highlighting should be optional. This should be in UML source, |
48 |
Gzz_Frontend_Java.gen.html |
but it could also be added there from an optin of UML directive. |
49 |
- write all errors and warnings in some place so it's easy to |
Anyway, implementing is not trivial, since even the same png |
50 |
look for them and fix. Current output is incredibly bogously |
diagram could be used in all documents, the imagemap should |
51 |
spewy. |
always be regenerated. So, two points: |
52 |
- warn properly about diagrams referencing classes that are |
- all refers to the same diagram should use the same png |
53 |
not there. For instance, gzz.DimManager is referenced but |
- still every document needs own imagemap |
54 |
does not exist. Maybe show jlink in some special color |
- there should be no highlighting |
55 |
(bright red?) if false. |
|
56 |
- reST documents where diagram is explicitly included |
0.1alpha1: First separate release |
57 |
using the directive, should also be included into diagram |
- debug class for handling screen output and logging |
58 |
(and highlighted when shown in current document) |
- write all errors and warnings in some place so it's easy to |
59 |
- make sure that umltool works also with pure doccxx |
look for them and fix. Current output is incredibly bogously |
60 |
- Currently diagrams are embedded into html-documents after |
spewy. |
61 |
the first header-tag. This could be enough for javadoc and |
|
62 |
other, but in reST this should be possible to overdrive by |
0.2alpha1: Rewriting |
63 |
own directive. |
vegai: |
64 |
- diagram names should be unique, currently this can't be |
+ Download new and clean Docutils CVS snapshot, check the |
65 |
easily tested, make something for it |
problems when importing it in Jython |
66 |
- Fix UML sequence diagram: now you have to put |
+ some fatal errors |
67 |
seqobjects *after* the sequence... |
+ harmless SyntaxWarning, but could it still be removed |
68 |
+ Highlighting should be optional. This should be in UML source, |
|
69 |
but it could also be added there from an optin of UML directive. |
anybody: |
70 |
Anyway, implementing is not trivial, since even the same png |
pegboard: |
71 |
diagram could be used in all documents, the imagemap should |
|
72 |
always be regenerated. So, two points: |
- pegboard should be made work fully as reST directive |
73 |
- all refers to the same diagram should use the same png |
+ after this all reST-files could be compiled from the root |
74 |
- still every document needs own imagemap |
using $(JYTHON) metacode/umldoc.py `find doc -name "*.rst"` |
|
- there should be no highlighting |
|
|
- split this todo into correct releases / sections :) |
|
75 |
+ clean pegboard.py (= make more oo, since Python is oo language) |
+ clean pegboard.py (= make more oo, since Python is oo language) |
76 |
+ check why running with jython causes harmless SyntaxWarning |
|
77 |
|
rest -> latex: |
78 |
|
|
79 |
|
- cleanup |
80 |
|
- strip all unnecessaries, if there's any |
81 |
|
- collect comments and experiences of used when |
82 |
|
writing the article |
83 |
|
... |
84 |
|
|
85 |
|
|
86 |
1.0: Feature-complete |
1.0: Feature-complete |
87 |
anybody: |
anybody: |