Drag panel movement doesn't take ui scale into consideration

[eldeesmith]

At very large scales, the panel will accelerate away from the mouse cursor. At smaller scales the panel will lag behind.

[mmmrqs]

Hi @eldeesmith, thank you for the feedback. Yes, that is in my to-do list to get fixed, however it is not trivial because scale is applied everywhere in the code and I will have to compensate for it in many places. I haven't given it a bigger priority because dragging the panel around seems not to be an action the user will keep doing all the time, and even if he/she does that, it is just a matter of releasing the mouse and picking the panel again to complete the drag if it starts lagging back too much. But it is one issue I really want to get fixed, just don't know when I am going to have the time for doing that.

[SuddenDevelopment]

it is common, on retina especially it shows up tiny. I think this is causing my tooltip issues as well.

[SuddenDevelopment]

you can see the 1.0 scale difference between the n panel and the viewport panel

the n panel are 16x16 pixels, the viewport panel is 32x32 pxixels but they come in the same size

[mmmrqs]

These are two different issues, @SuddenDevelopment - The issue with the drag feature is due to calculations in code that currently I am not taking in account the scale offset. It is something I really need time to work on and get it sorted out.

On the other hand what you are experiencing with "no scaling" in your panel I believe is because there are three hidden properties which control this behavior and they were expected to be set on the Preferences page of the add-on. They act as switches to turn scaling and sliding features on/off. My bad that I never thought to have them exported to developer.

I don't know when I will be able to enhance that because I am totally without time to work on anything Blender related, but perhaps you can mess with it and find a work around, like overriding these functions. You may want to take a look also on the Prefs.py to see how I bound those props to code. See below, these are in the BL_UI_Widget.py and the one which may interest you more is the top RC_UI_BIND() that binds the panel scale to Blender's UI Resolution scale and it changes on the fly:

def RC_UI_BIND(self):
    """ General scaling for 'Remote Control' panel """
    if __package__.find(".") != -1:
        package = __package__[0:__package__.find(".")]
    else:
        package = __package__
    try:
        bind = bpy.context.preferences.addons[package].preferences.RC_UI_BIND
    except Exception as e:
        bind = True
    return (bind)

def RC_SCALE(self):
    """ Scaling to be applied on the Remote Control panel
        over (in addition to) the interface ui_scale.
    """
    if __package__.find(".") != -1:
        package = __package__[0:__package__.find(".")]
    else:
        package = __package__
    try:
        scale = bpy.context.preferences.addons[package].preferences.RC_SCALE
    except Exception as e:
        scale = 1.0
    return (scale)

def RC_SLIDE(self):
    """ Keep Remote Control pinned when resizing viewport.
        If (ON): remote panel slides together with viewport's bottom border.
        If (OFF): remote panel stays in place regardless of viewport resizing;
    """
    if __package__.find(".") != -1:
        package = __package__[0:__package__.find(".")]
    else:
        package = __package__
    try:
        slide = bpy.context.preferences.addons[package].preferences.RC_SLIDE
    except Exception as e:
        slide = True
    return (slide)

Images below show the Demo panel tiny (scale=0.5) or huge (scale=2), following the Resolution Scale set on Blender's Interface Preferences window.

[eldeesmith]

I actually started digging through the code to fix this bug so I could submit a PR, but after spending a day with it I had to punch out. there's too much demo code embedded into 'core' code, and everything is run by monolithic classes that try to do too many things. Once I started pulling the thread the rug started to unravel. This particular issue is a side effect of how the project has been designed architecturally... in my opinion it needs a major refactor to be more modular, such that the transformation of objects is a self contained class where all logic is shared across across all objects who use it as a component. It's a pervasive issue on this project unfortunately, perhaps somebody is willing to invest the time needed to refactor, but personally I think it would make more sense to start from scratch.

Truly not trying to disparage the project, just giving some context to anyone who stumbles across this issue and wants to tackle it. Obviously some perfectly viable interfaces can be made with this project, as demonstrated by the various screenshots of interfaces that have already been made, and this is an easily fixable bug if you're willing to ignore the other timebombs waiting to explode.