Modular Fungi Lights Off mode

Hi, I would like to implement a custom widget that remains bright in the Modular Fungi Light Off mode. After examining the code of the Light Off module I saw that it checks if the widget is a descendant of LightWidget, so I simply modified my widget struct declaration:

struct MyWidget : Widget { ...`  


struct MyWidget : LightWidget { ...`  

and move the draw stuff from:

void draw(const DrawArgs &args) override {


void drawLight(const DrawArgs &args) override {

and it seems to work.

  • Is it the correct way to do it?
  • What is the difference between draw() and drawLight() ?


1 Like

LightWidget gets drawn with draw() like any other widget, but LightWidget defines draw() as a call to two other functions: drawLight() and drawHalo(). So, your current method works fine if you want (or are content with) Rack drawing its standard “light halo” on top of your widget. Keeping everything in draw() instead would bypass the call to drawHalo().

In Rack v2, lights will no longer come with halos, and the virtual method LightWidget::drawHalo() might or might not even exist anymore.

Besides all that, you’ve got it right with simply inheriting from LightWidget.

1 Like

Occasionally there are more complicated scenarios. If your illuminated widget has no mouse interaction, then it’s fine. But if you need to respond to the mouse events its more tricky.

Early on in the hierarchy, widgets divide into OpaqueWidget and TransparentWidget. This had nothing to do with the visuals and everything to do with mouse and keyboard events. TransparentWidget just ignores these events and passes them through to its parent. Since LightWidget descends from TransparentWidget, simply changing your widget to TransparentWidget might break your mouse interaction.

When that happens to me, my best solution is usually this: I create a new class descended from LightWidget and move the draw method from the original to the new class. Then I make sure that whenever the original class is added, I add a new widget, either as a child or a sibling of the original. The drawing is done by the LightWidget, and the mouse interaction passes through it to the OpaqueWidget underneath.

You will likely have to tweak the draw method to access the correct member variables, but this technique has covered 90% of my tricky cases.