Well, I’m sending this to everyone after starting to get my hands back
into the API.
It seems like the code is already starting to decay. For a simple
example, there are these functions like staticType, staticName, type,
name, typeName (exaggerating here) and some of them don’t even appear to
have a reason.
There is no reason that Color can’t be a subclass of Plugin. As long as
Color isn’t a subclass of any other QObject (which it isn’t) then there
is no problem. The problem is that Color has a function:
virtual QString type() const { return “Virtual Base Class”; }
and Plugin has a function:
virtual int type() const = 0;
So there are two things each plugin needs based on my experience with
Engines:
– A plugin now needs to return a type (Plugin::EngineType,
Plugin::ColorType… etc enumeration of all our types of plugins).
– A plugin must return a static name (Ball and Stick, Vanderwall, Color
by Element, etc)
– A plugin must return a name (if a plugin got renamed).
And now that i’m thinking about this, we really should let ::name() be
the static name (Ball and Stick, Vanderwall) and we should have an
::alias for any specific class that needs renaming.
-
tools, extensions don’t need to ever be renamed. you will never
create more than one tool (maybe we will add this later).
-
engines, colors need aliases because you might create more than one
and then need them to be named different. (My Color By Element 1, My
Engine 1, etc etc)
There is no reason to need a string counterpart for each enumeration
of type. If something is compiled to use an enumeration
Plugin::EngineType then the UI and the coders do not need a function to
tell them that this translates to “Engines” or something like that.
I decided that the one thing I wanted to do once I got back was to audit
the code and clean it up. I definitely don’t want to take out features
or stuff like that, I just want to try to organize and make things much
more efficient, not that it isn’t, I’m just seeing some things I hope is
OK.
–
Donald
(Sat, Jul 12, 2008 at 07:22:16PM +0200) Tim Vandermeersch tim.vandermeersch@gmail.com:
On Sat, Jul 12, 2008 at 6:57 PM, Donald Ephraim Curtis
d@milkbox.net wrote:
After downloading the new source, I am a little confused why we have
both a Color, and a ColorPlugin which is simply a glass with a widget
and a pointer to a Color. It just seems a bit redundant. Couldn’t we
have simply a Color be an interface as a plugin and then have a
ColorFactory and be done with it?
Yes, I briefly explained this in one of my previous mails. My main
objective was to get all plugins to use the Plugin and PluginFactory
classes. However, I encountered some problems when making Color a
derived class from Plugin (which itself is derived from QObject). The
Color::operator=(const QColor &color) didn’t seem to work. It is
possible (even likely) that this can be fixed but I didn’t want to
make too much changes to the Color class before everything
compiled/worked again. I agree on the fact that it’s a bit redundant
and will have a look at this now…
Tim
