Working on OMS, want to do things correctly.

[elanhickler]

How should I take the BreakpointModulatorEditor class and keep only the point/curve editor? One way would be to bypass the resized() but I don't have access to the members because they are protected.

[RobinSchmidt]

you may use class ModulatorCurveEditor directly.

[elanhickler]

If I do that, it seems I essentially need to recreate everything from BreakpointModulatorEditor and BreakpointModulatorAudioModule minus the editor controls. So maybe I should copy/paste all that code and then edit it.

[RobinSchmidt]

why not subclassing BreakpointModulatorEditor?

[elanhickler]

I'll try that.

[elanhickler]

Ok, so this is where I need you to make changes to your library so that it's easier to skin. Firstly, would you be willing to use JUCE's menu system? I think it's better than your combo box in every way and also easy to use and I could even recreate your combo box look easily. Submenus are easy to make as well. It has all the handling in terms of making sure screen overflow is not a problem.

I just can't use painters on your combo box. That's the problem. You didn't provide a painter because of how complex it is. JUCE's menu system would be a good replacement for your combobox.

Edit: Or somehow you have to make your combo box replaceable with JUCE... can't think of how this will work at the top of my head.

[elanhickler]

bahh I already ran into a roadblock. I can't customize the editor because members are protected in a sub editor member BreakpointModulatorGlobalEditor* globalEditor of the main class BreakpointModulatorEditor

[elanhickler]

what should I do Mr. Robin!

Edit: It's possible your decision to make use of friend classes was a mistake here, and possibly a bad design since it prevents the usefulness of subclassing / overriding.

Edit: Maybe you should simply unprotect the UI widget members?

[RobinSchmidt]

I just can't use painters on your combo box. That's the problem. You didn't provide a painter because of how complex it is. JUCE's menu system would be a good replacement for your combobox.

actually, i don't really think, it would overly complex to provide painters for this - it's just not yet done. sure, a bit more complex than for buttons and sliders, because of the embedded pop-menu - which would also need to get its own painter. but nothing really too bad, i think.

would you be willing to use JUCE's menu system?

i'm not really familiar with that anymore ever since i switched to my own combobox widget. i wanted tree-views inside the widget instead of this cascade of opening windows for the submenus. that was really a lot of work and i don't really want to throw that away just for reverting to something that i like much less

whats your ultimate goal with all this? just customizing the look of the menus? if that is the case, i think, we should do it with painters again.

[elanhickler]

whats your ultimate goal with all this? just customizing the look of the menus? if that is the case, i think, we should do it with painters again.

Before you do that, JUCE's menus have more features than just selecting and submenus. You can even insert buttons in menus and other functionality. You can insert whole components! Before you go through the trouble of providing a painter class, I want to explore the idea of somehow having a switch in your library where you can say "I am using JUCE menu instead of RS-MET combo box" and pass in the juce combo box. I can do some research on how JUCE menu works and give you example code.

Edit: One of the big problems with your combo box is that it doesn't adjust for screen, so you have menu items going off screen. JUCE's menu system solves all this and more.

[elanhickler]

Waiting for a comment on how I should use your library! I may just have to unprotect members on a custom version of RS-MET unless you have a better idea.

[RobinSchmidt]

ah - ok - i thought, that i'm now supposed to wait for your suggestions how to allow a switch between my and juce's combobox. ...maybe i could templatize the class on the type of the combobox - but that would be ugly and require me to be strictly compatible with juce::ComboBox'es interface

I can't customize the editor because members are protected in a sub editor member BreakpointModulatorGlobalEditor* globalEditor of the main class BreakpointModulatorEditor

...so - is the problem that you can't assign painters to the widgets because they are protected in the sub-editor? if that is the problem, the clean solution would be to provide setSliderPainter, setButtonPainter (and later setComboBoxPainter) methods in jura::Editor that iterates through all the widgets and sets their painters (and recursively calls the same method on all sub editors). i also could introduce a painter mechanism for the editors themselves (an EditorPainter - to allow custom background drawing).

but as a temporary workaround, you may unprotect them.

[elanhickler]

I need to set bounds.

Iterating is not so useful. Even between sliders they may have a unique painter.

I'll worry about the combobox later.

[RobinSchmidt]

hmmm...ok - yes - makes sense. if you use - say - knobs, then my arrangement of the sliders obviously makes no sense anymore. in this case, unprotecting them might indeed be the most sensible solution. i probably should do it in the library - although it's perhaps not the best programming style

[elanhickler]

Well, do you really need a perfect programming style on your top level modules? All you would be doing is unprotecting the components (unless I run into other unseen issues). Anyway, i'll unprotect them on my end and we'll see how the dust settles and you can do it in your library if it's working out well for me.

Edit: I don't like the idea of you keeping an array of components to solve problems. There's a better design waiting to be discovered here that I can't see just yet. First of all your C pointers (not using smart pointers) are a bad design and you don't want to bandaid a bad design.

[RobinSchmidt]

I don't like the idea of you keeping an array of components to solve problems.

are you talking about the arrays of widgets and sub-editors in the editor class? how else would i iterate through them? ...and if i already have those arrays anyway, i don't need the additional overhead of smart-pointers just to avoid memory leaks. the baseclass destructor reliably cleans up everything

[elanhickler]

I don't remember the issue I ran into trying to use your array for something useful. Let's see how far I get by unprotecting your component members.

[elanhickler]

Ok, next roadblock! I created and assigned a painter, but now I need to have a custom mouse handling for the slider. Here's my example knob mouse handling code:

void mouseDrag(const MouseEvent & e) override
{
  double scale = .003;

  if (ModifierKeys::getCurrentModifiers().isShiftDown())
    scale *= 0.0625;

  if (!isEnabled())
    return;

  if (!e.mods.isRightButtonDown() && !e.mods.isCommandDown())
  {
    int newDragDistance = e.getDistanceFromDragStartY() - e.getDistanceFromDragStartX();

    int dragDelta = newDragDistance - oldDragDistance;
    oldDragDistance = newDragDistance;
    dragValue += scale * dragDelta;

    double y = normalizedValueOnMouseDown;
    y -= dragValue;
    y = clip(y, 0.0, 1.0);

    setNormalizedValue(y);
  }

  // this updates the central global value / mouse over display and help text
  updateParameterInfo();
}

Two ideas to accomplish this:

A. Add some members to set mouse handling

1. absolute position drag (how your sliders work now) OR relative drag (how my knobs work)
2. relative drag pixels per value change

OR

B. add virtual void mosueDrag(const MouseEvent& e, RSlider* slider) = 0; as a member to RSliderPainter

I think B is better so I can customize keyboard modifiers.