14 |
This PEG proposes creating **Abstract ColorableVob** class, which |
This PEG proposes creating **Abstract ColorableVob** class, which |
15 |
implements a new **Colorable interface** also defined by this PEG. |
implements a new **Colorable interface** also defined by this PEG. |
16 |
|
|
17 |
**Colorable Vob** is a very basic vob type, which enhances the Vob |
**Colorable Vob** is a very basic vob type, which enhances the regular |
18 |
with interface for placing multiple solid colors on it background. The |
Vob with interface for placing multiple solid colors on its |
19 |
multiple solid colors are used a lot in basic Views i.e. to show |
background. The multiple solid colors are used a lot in basic views |
20 |
cursor location and node properties. In current implementations |
i.e. to show cursor location and node properties. In the current |
21 |
multiple solid colors are shown as parallel vertical stripes or |
implementations multiple solid colors are shown as parallel vertical |
22 |
sectors. |
stripes or sectors. |
23 |
|
|
24 |
This PEG replaces the older `PEG for Abstract Background Vob`__. |
This PEG replaces the older `PEG for Abstract Background Vob`__. |
25 |
|
|
32 |
- Why is Abstract Colorable Vob needed? |
- Why is Abstract Colorable Vob needed? |
33 |
|
|
34 |
RESOLVED: Currently there is no common interface for multiple solid |
RESOLVED: Currently there is no common interface for multiple solid |
35 |
colors in node vobs, but they are defined and implemented from the scratch in |
colors in vobs, but they are defined and implemented from the scratch in |
36 |
every background vob (starting from ``RectBgVob``). A common interface is |
every background vob (starting from ``RectBgVob``). A common interface is |
37 |
necessary when that a single node view could select between multiple different |
necessary when a single node view that supports solid colors, should |
38 |
background vob types depending on nodes' content; the same node view could place |
select between multiple different background vob types (basing the |
39 |
different vob depending on the node's content. |
selection i.e. on nodes' content). |
40 |
|
|
41 |
- Why was the PEG for Abstract BackgroundVob declared irrelevant? |
- Why was the PEG for Abstract BackgroundVob declared irrelevant? |
42 |
|
|
43 |
RESOLVED: It was about to propose such interfaces for background |
RESOLVED: It was about to propose such interfaces for background |
44 |
vobs, which would have made them strongly mutable. It was also |
vobs, which would have made them strongly mutable. It was also |
45 |
criticized to restrict background too much by forcing them to have |
criticized to restrict background vobs too much by forcing them to |
46 |
border and background color properties. |
have border and background color properties. |
47 |
|
|
48 |
- Should Colorable Vob be immutable? |
- Should Colorable Vob be immutable? |
49 |
|
|
50 |
RESOLVED: Yes. The current multi-color implementation in |
RESOLVED: Yes. The current multi-color implementation in |
51 |
``RectBgVob`` and other background vobs have been made them mutable. |
``RectBgVob`` and other background vobs have made them mutable. |
52 |
Inheriting those multi-color features from Colorable Vob should turn them |
Inheriting those multi-color features from Colorable Vob should turn them |
53 |
back to immutable. Immutability allows storing created vob objects, |
back to immutable. Immutability allows storing created vob objects, |
54 |
re-using them and finally enhancing the performance. |
re-using them and finally enhancing the overall performance. |
55 |
|
|
56 |
- How is Colorable Vob related to background vobs? |
- How is Colorable Vob related to background vobs? |
57 |
|
|
60 |
immutable and use the common interface for multiple solid colors; |
immutable and use the common interface for multiple solid colors; |
61 |
They should be inherited from ``AbstractColorableVob``. |
They should be inherited from ``AbstractColorableVob``. |
62 |
|
|
63 |
- How should ColorableVob be assembled? |
- How should Colorable Vob be assembled? |
64 |
|
|
65 |
RESOLVED: ColorableVob extends the basic Vob class and implements |
RESOLVED: ColorableVob extends the basic Vob class and implements |
66 |
Colorable Interface for multiple background colors. |
Colorable Interface for multiple background colors. |
68 |
- How should the new interfaces and classes be named? |
- How should the new interfaces and classes be named? |
69 |
|
|
70 |
RESOLVED: **public interface Colorable** and **public abstract class |
RESOLVED: **public interface Colorable** and **public abstract class |
71 |
ColorableVob**. |
ColorableVob** |
72 |
|
|
73 |
- Where they should be located? |
- Where they should be located? |
74 |
|
|
76 |
(``gzz.vob.Colorable`` and ``gzz.vob.ColorableVob``. Probably in the |
(``gzz.vob.Colorable`` and ``gzz.vob.ColorableVob``. Probably in the |
77 |
future they will be moved into package ``org.libvob.vob``. |
future they will be moved into package ``org.libvob.vob``. |
78 |
|
|
|
- How should the common features of current background vobs be |
|
|
splitted between Background Interface and Colored Interface? |
|
|
|
|
|
RESOLVED: Methods for single color backround and border will be |
|
|
defined in Background Interface and methods of multiple |
|
|
background colors in Colored Interface. The AbstractBgVob will |
|
|
contain the default implementations for them. |
|
|
|
|
79 |
- How should *solids* be renamed? |
- How should *solids* be renamed? |
80 |
|
|
81 |
RESOLVED: Earlier, *cellColors* has been proposed. Although, we are |
RESOLVED: Earlier, *cellColors* has been proposed. Although, we are |
82 |
currently moving away from *cells* to *nodes*. Therefore *solids* |
currently moving away from *cells* to *nodes*. Therefore *solids* |
83 |
should be called simply **colors**. Note that already the method |
should be called simply **colors**. Note that the method |
84 |
adding them has been called *addColor*. |
adding them in the current implementations has been called |
85 |
|
*addColor*. |
86 |
|
|
87 |
- How should we store colors? |
- How should we store colors? |
88 |
|
|
92 |
- How should the colors be set? |
- How should the colors be set? |
93 |
|
|
94 |
RESOLVED: Since Colorable Vob should be immutable, colors |
RESOLVED: Since Colorable Vob should be immutable, colors |
95 |
could be added only by cloning a new vob. This methdo would prefer |
could be added only by cloning a new vob. This method would prefer |
96 |
setting all the colors at once as a single List. |
setting all the colors at once as a single List. |
97 |
|
|
98 |
- Should SolidBgVob be inherited from Colorable Vob? |
- Should SolidBgVob be inherited from Colorable Vob? |
99 |
|
|
100 |
RESOLVED: No. ``SolidBgVob`` is not such background vob than other |
RESOLVED: No. ``SolidBgVob`` is not a such background vob than other |
101 |
BgVobs (``RectBgVob`` and ``OvalBgVob``). More prefarably, SolidBgVob |
BgVobs (``RectBgVob`` and ``OvalBgVob``). More prefarably, SolidBgVob |
102 |
should be renamed to avoid misunderstandings. |
should be renamed to avoid misunderstandings. |
103 |
|
|
160 |
- ``gzz.vob.vobs.RectBgVob`` |
- ``gzz.vob.vobs.RectBgVob`` |
161 |
- ``gzz.vob.vobs.OvalBgVob`` |
- ``gzz.vob.vobs.OvalBgVob`` |
162 |
|
|
|
**Cell Views** and **Node Views** will be broken after this change, |
|
|
since background vobs' addColor interface will be removed to make vobs |
|
|
immutable. |
|
163 |
|
**Cell Views** and **Node Views** will be broken (and hast to be |
164 |
|
fixed) after this change, since background vobs' addColor interface |
165 |
|
will be removed to make vobs immutable. |