Prepare Renderer classes for Composites #167
Conversation
tmssngr
force-pushed
the
feature/renderer-prepare-for-composites
branch
from
ab74a52 to
d4f2aa0
Compare
| @@ -107,7 +107,7 @@ public static <T> T executeOnGC(Control control, Function<GC, T> operation) { | |||
| } | |||
| } | |||
|
|
|||
| public static Point getTextExtent(CustomControl control, String text, int drawFlags) { | |||
| public static Point getTextExtent(Control control, String text, int drawFlags) { | |||
There was a problem hiding this comment.
I also thought of this and later realized that this might leave some methods "unhooked". See this part of #164 (comment)
That's why it overrides Control::computeSize and calls its very own (abstract) CustomControl::computeDefaultSize
What I meant is that I wasn't sure that the "old" Control hierarchy would play well with the "new" CustomControl hierarchy, e.g. I'm not sure the size of Controls would be calculated correctly. There may be other methods that are not "hooked" yet too.
Did you by any chance already checked/experienced this @tmssngr ? I haven't gotten that far yet.
There was a problem hiding this comment.
I've didn't have such problems (yet), but IMHO changing the parameter type from CustomControl to Control should not have any negative impact.
tmssngr
force-pushed
the
feature/renderer-prepare-for-composites
branch
from
8381585 to
6a07cf1
Compare
tmssngr
force-pushed
the
feature/renderer-prepare-for-composites
branch
from
6a07cf1 to
3eaadd4
Compare
… to Control to allow Composites, too
because some implementations will need size hint arguments
tmssngr
force-pushed
the
feature/renderer-prepare-for-composites
branch
from
3eaadd4 to
2983983
Compare
|
@HeikoKlare I'm not sure whether the commit ControlRenderer: make generic is best suitable. @DieterMai mentioned that |
ControlRenderer became generic to avoid casting or control specific fields in subclasses