element::draw

[djowel]

So I implemented #224 and it looks good. But now that we're talking about API changes, one change I want to make is add the current cursor point to the draw API. So instead of:

      virtual void            draw(context const& ctx);

I would like

      virtual void            draw(context const& ctx, point p);

Why? A lot of the draw routines track the cursor position and draws highlighted parts depending on mouse position. Yes it could be done using cursor member function, but that requires saving some state information and doing a refresh on highlight state changes.

It was once possible to just call view.cursor_pos(); but that is no longer a good way to obtain the cursor position because it does not take into account translation and scale.

[djowel]

Another strategy is to place the local cursor position in the context so it will be available in all element member functions (and making the mouse point argument redundant). Thoughts?

[Xeverous]

I think this will force some elements to move their state calculation into draw, which IMO is bad. In libraries I have worked before, mouse movement itself was an event and was passed along just like any other event. Mouse movement can trigger complex actions just like any other event, not just highlight.

Yes it could be done using cursor member function, but that requires saving some state information and doing a refresh on highlight state changes.

You know my opinion on refresh. I always completely redraw entire frame, making refresh and dirty area tracking redundant.

[djowel]

I think this will force some elements to move their state calculation into draw, which IMO is bad. In libraries I have worked before, mouse movement itself was an event and was passed along just like any other event. Mouse movement can trigger complex actions just like any other event, not just highlight.

No it does not. There will be no be state calculation in the current use-cases in elements. Can we keep the discussion within the confines of elements? Elements does things differently compared to other libraries. How library XYZ does it is irrelevant.

You know my opinion on refresh. I always completely redraw entire frame, making refresh and dirty area tracking redundant.

Well then we are in different universes again. These discussions are of no value to me if you keep on going out in left field WRT elements. You always want me to understand it in your POV. How about having some effort to understand it in my POV?

[Xeverous]

Well, you asked about changing the API so I gave my POV. If you want to stick your goals (it's your project after all) then just go with it. I have different views and just explained why IMO this change seems bad.

If your design is that the cursor movement only affects highlight - then it can be thought of as a part of the drawing input, just like element bounds are. My only concern then is whether you will be tempted to add even more input arguments to the draw function, in case an extra effect (like highlight) will need another extra data.

[djowel]

IDK, we seem to diverge more over time.

[Xeverous]

Started to read what VST and DAW are aftering seeing them mentioned more often recently in Discord... now I know my goals are really far away from yours. I'm glad to experience your element UI design (I really like the context stack-based passing down the hierarchy + so little state) but ... that's pretty much it ... that's the only thing I'm going to "rip-off" in my own project(s).

[djowel]

Good luck, @Xeverous and thank you for your contributions.

[djowel]

Closing this now. I'll decide what to do with this. I'm leaning towards having the cursor position in the context.