Plug-ins: element positioning API

• Oct 23, 2019 - 12:35

Firstly, I am not sure this belongs here or to the plug-in forum: it seems to me the plug-in forum be for development (and advertisement!) of individual plug-ins, while core development of the plug-in API belongs here. If I am wrong, please advise (with my apologies).

Revising the methods / properties to get / set element positions, I find a few things puzzling me.

  1. Element.offsetX and Element.offsetY, when set, result in the new value not being set in place of the current value but added to the current value. In practice:
    e.offsetX = val; actually means e.offsetX += val;
    Is this done on purpose? Should it not, at least, be documented?
  2. Element.offset accepts (and probably returns, but I didn't check) values in raster units, while all other positioning properties work in spatium units. Is this done on purpose?
  3. To use Element.offset together with the other position properties, a spatium scale factor is needed which, as fas as I can tell, is not currently available. Is this done on purpose or simply has not been added yet?
  4. Given these sharp corners, is Element.offset really necessary or Element.offsetX and Element.offsetY are enough?
  5. Element.posX/Y are read-only. In 2.x, it was possible to set it (the implementation routed this change into an offset change); this seems to me the most direct and ‘expectable’ way to set the position of an element with respect to its parent, so it would be very convenient to have.

As in the relevant source files none of these points are marked with "TODO" annotations and several months have elapsed, it is not always clear what is by design and what is work in progress.

Comments

• Oct 26, 2019 - 11:33

The situation with positioning properties is indeed not good, but I'll try to answer these questions:

  1. Adding offset rather than setting it sounds strange indeed. If I recall correctly, my intention when restoring plugins API for MuseScore 3 probably was to preserve the old semantics of offset setters. These setters should have probably set an offset to the automatically defined position. In MuseScore 2 this wasn't a problem, but in MuseScore 3 this "automatically defined" includes does also influence offset value (at least style settings do define offset values). Maybe adding an offset rather than setting it was an attempt to compensate this new offset semantics, but it apparently makes things only more complicated. Maybe we should switch to setting an offset instead, maybe along with some way to ensure a compatibility with old semantics for old plugins.

  2. No, spatium units should probably be preferred. For that reason we can probably just change handling of POINT_SP and POINT_SP_MM property types in ScoreElement wrapper

  3. Spatium value is a part of style settings so exposing it should probably be good to be done along with exposing other style values (or maybe even some means to change style settings).

  4. Element.offset allows working with native Qt Point type so I would leave it, provided we make it consistent with other positioning properties.

  5. If setting position from a plugin would actually change offset settings than this indeed may be a good thing. However this may be more difficult to implement because of the autoplacement. Although it currently allows free positioning of most of elements this sometimes requires setting MIN_DISTANCE property accordingly to allow some elements to go inside staff boundary, but it should probably better not be modified unless not really necessary. Overall, it may be good to have such way to define elements positions from plugins but the implementation still needs to be developed.

Reply

• Oct 29, 2019 - 08:43

Thanks for the reply and the clarifications.

1) As I still work a lot with MS 2.3.2 and its plug-ins, I am pretty sure that, by assigning the offset property a value, is was set _ into it, rather than _added (and the ver. 2.3.2 source code matches this); so, I believe the current behaviour already breaks with the old semantics. Of course, the offset is an offset from a reference position, but I think there should be a way to set it, rather than further offset it indefinitely...

Aside: it seems to me that been consistent with the old ver. 2 semantics may be useful when possible, but it should not be a straitjacket. The details have already changed enough that source sharing between version is no longer a sensible option.

2) and 3) IIUC, to be implemented separately from dealing with Element.offset(X/Y) or Element.pos.

4) Preserving Element.offset: ok.

5) I still have to understand the whole matter of autoplacement: what it actually does and how it works, so I may be utterly wrong. It is my feeling however that, if a plug-in allows to place an element (whatever the mean: via an offset, via an absolute position, via a magic spell, ...), that element should be placed there and not further 'interpreted' by the layout engine, otherwise it would be the case of "the dog biting its tail"...

Reply

Do you still have an unanswered question? Please log in first to post your question.