PiP relative/incremental moves, additional features/issues

[arikorn]

Notes to self and for comment (@fa1k3n, @WOTBox, etc.) :
I'm thinking about modifications to the current implementation of relative movement for USK (PiP) windows and interested in feedback from you folks.

Some ideas:

• add a variable: pipIncrement or xyIncrement to the module?
  • The main points being
    1. not to require the user to create a new variable (for a preset, for example)
    2. not to use two separate variables xIncrement and yIncrement
  • However, this would require an additional action to set the increment since module variables are read-only to the user
• add presets for my arrows pad? may take some effort... (note: without a module variable, presets may be limited to a constant increment value.)
• add ability to set the edge "buffer" (currently 5 pixels -- snap moves the window 5 pixels from the edge). Or just set it to 0?
• internal: move sendCommand to the state class, or at least have encode put it in the array form.
• ... (other ideas?) ...

[WOTBox]

* add a variable: _`pipIncrement`_ or _`xyIncrement`_ to the module?

I'm in favour of a single pipincrement.
In my personal usecase (don't know about other users), I would very much like a patternIncrement as well...

* add presets for my arrows pad? may take some effort... (note: without a module variable, presets may be limited to a constant increment value.)

100% in favour of an arrows pad Preset.

* add ability to set the edge "buffer" (currently 5 pixels -- snap moves the window 5 pixels from the edge). Or just set it to 0?

In normal practise I'd use Pips snapped to the edge. Having tried your 5 pixel buffer, I have to admit it looks good. So yes, the ability to set buffer size from zero to about 10 pixels would be handy

* ... (other ideas?) ...

For now, just the aforementioned patternIncrement variable

[fa1k3n]

internal: move sendCommand to the state class, or at least have encode put it in the array form.

no, very much against this. sendCommand has nothing to do with state and adding it there is moving along the wrong direction. I would like all interaction with the communication layer to go through function calls

arrow pad, sure thing to add as presets

the other points. To me they seems to add lots and lots of specific things to the actions increasing the complexity of th

[arikorn]

@fa1k3n wrote
1.

sendCommand has nothing to do with state and adding it there is moving along the wrong direction.

Please read my comment on issue #96 (Decouple Osee protocol from Companion).
(edit: Please see next comment here, too, for a more specific explanation.)

Could you be more specific about which "other points" you object to? Also it looks like your sentence was cut off in the middle.

[arikorn]

very briefly briefly regarding moving sendCommand out of the action: this originates from my experience with recording quality (see issue #107). We currently embed the communication protocol id's in the actionId -- this definitely violates "decoupling" and, in fact, caused a problem mentioned there.
I will posted more detail in Issue #96 in a short while. [edit: posted!]

[fa1k3n]

@fa1k3n wrote 1.

sendCommand has nothing to do with state and adding it there is moving along the wrong direction.

Please read my comment on issue #96 (Decouple Osee protocol from Companion). (edit: Please see next comment here, too, for a more specific explanation.)

Yes I have read that, I have also now replied to that. I stand firm sendCommand has absolutely nothing to do with state

Could you be more specific about which "other points" you object to? Also it looks like your sentence was cut off in the middle.

other point refers to edge buffer i this case. I feel the whole PIP action is very complex with different snap modes and now suggestions to add edge buffers et.c. It gets more and more specialized towards specific usecases and loses its ease of use with all these settings. Even if they have default values for the user. I understand your usecase, but perhaps that is just your usecase, it should be in your local fork instead?

[arikorn]

Edge buffer is already there and hardcoded at five pixels. You may have noticed that the default Osee macros (M1 - M4) hardcode a buffer as well -- around 10 pixels, so it's not an "outrageous" or even original idea of mine!

Let me know if you want the current code changed and how.

Regarding sendCommand, we can discuss it elsewhere, though since it appears that you agree in principle with my issue #129 and #96, I find it hard to believe that you would suggest here that sendCommand belongs in the action callback.