I was just thinking this: at the moment the LookAndFeel class is divided in sections that contain the callbacsk pertaining the drawing/painting of all the different widgets. Wouldn’t it be more convenient to have those sections divided in a collection of simpler classes instead, each pertaining the painting of a single widget?
Instead of a monolithic LookAndFeel class, we’d have classes like PopupMenuLookAndFeel, SliderLookAndFeel, ButtonLookAndFeel and so on. This would pretty much resemble the (clever) way Listeners are implemented now. In fact, it would even be possible for each widget class to contain its LookAndFeel, e.g. Slider::LookAndFeel, TextEditor::LookAndFeel and so on.
Each Component’s setLookAndFeel() method would take as an argument a pointer to the LookAndFeel specific for that component, and it still would be possible to have a single class that consistently describes the look and feel of a whole application: subclassing the look and feels for all the widgets used in the UI will do the trick, similarly to how one can have a single object handle events from multiple widgets by subclassing their listeners.
Couldn’t agree more! It’s one of those classes that grew like a cancer over the years, and which I’d love to scrap and refactor… Unfortunately to do that would break a huge amount of people’s code, so I’ve never quite had the courage to sit down and tackle it. One day!
well, to reduce the impact on existing code, I think one could start with an incremental refactoring:
for each widget:
1- create the (widget)::LookAndFeel class moving there all the methods from LookAndFeel that pertain the widget painting
2- make LookAndFeel inherit from (widget)::LookAndFeel to get back those methods inside the whole LookAndFeel class
3- make the (widget)::setLookAndFeel take a (widget)::LookAndFeel pointer
after every completed such iteration, the LookAndFeel hasn’t changed the set of provided methods thus hasn’t broken any existing code (yet), so it’s not a job that needs to be done “all at once”.
When this process completes, the whole LookAndFeel class will ideally consist only of a set of parent classes and no added methods in its body. At this point, it could be marked as deprecated and the needed refactoring for each widget could be taclked separately.
First refactoring suggestion for those (widget)::LookAndFeel classes: I think that’s the logical place where to put the ColourIds enums!
Yes, don’t be tempted! I would much more appreciate a projucer alpha version than a refactoring of the lookandfeel stuff!
BTW jules, in case you haven’t seen vinnie’s post and if you’ve got time to give him your thoughts about deletedAtShutdown and plugins I would appreciate it :
