- User Since
- Jul 26 2018, 5:02 AM (51 w, 8 h)
Thu, Jul 11
Aha! now that is a detail that I was not aware of. I had incorrectly assumed that ui_scale was simply the value that appears in preferences->interface, I never actually queried the value. It does correctly report a ui_scale that takes dpi into consideration, and now that I have a multiplier I can create consistent results on any display. Thanks for the guidance!
It's not a feature request, so far as I know, unless I'm missing something. The issue is that there is no way to ensure the end result is 100% identical on different displays that have different dpi. it doesn't matter what I set the dpi to in blf.size, it will look incorrect regardless. For example, if I set the dpi in blf.size to bpy.context.preferences.system.dpi, I get the following result in my 4k monitor (with a dpi of 108, according to system.dpi):
Wed, Jul 10
Tue, Jul 9
sorry, got distracted! It's happening in Linux as well. Two videos from Ubuntu 18.10 attached. First video shows same repro in multiple UV editors in the UV workspace, second video shows that it's not happening in any other workspace! so bizarre, hopefully since it's so weird nobody else will run into it 🙂
Mon, Jul 8
This is actually still happening with sticky selection disabled! See attached video.
Fri, Jul 5
Yeah it should be happening with any object in that scene in that particular workspace. It could be a windows-specific thing, I'll try it on Linux when i get home from work and see if it repros there.
Yes, this is still happening with the latest build- but it's only happening in one particular layout, which is very odd. If I create a new UV editor elsewhere it doesn't happen, so this appears to be some sort of edge case. blend file attached if you'd like to see it in action.
This is happening with the latest version from the buildbot with factory settings loaded. Here is a video with simplified repro:
so then there is no way in Blender to do the common task of selecting alternating uv edge loops in a UV island without also selecting UV edges from a completely separate island. that's pretty awful, but you are right, it's not a bug- just awful by design. hopefully that will be improved someday.
Additionally, this behavior is not exhibited while sync selection is enabled:
Note that this also happens with incorrectly 'selected' edges in edge mode. This is virtually impossible to show in a video due to compression, so here's a screenshot.
Thu, Jul 4
Wed, Jul 3
For anyone else who might need this functionality, a workaround that I use is the following:
Fri, Jun 21
Ah, okay- the fix probably hasn't made its way over to the nightly builds yet. I'll check it again tomorrow.
This is still happening in the latest 2.80 build available on buildbot: version: 2.80 (sub 74), branch: master, commit date: 2019-06-19 18:29, hash: rBd30f72dfd8ac
Wed, Jun 19
Jun 16 2019
Jun 15 2019
Jun 5 2019
I should clarify that image.view_zoom *does* work correctly, the bug is that view2d.zoom should either work in the UV editor- or not work at all. Right now the operator is allowed to execute, and correctly displays the tooltip- but does not function.
May 30 2019
May 6 2019
Apr 9 2019
Feb 19 2019
Dec 31 2018
No worries, thanks for taking another look!
Dec 30 2018
Dec 29 2018
Dec 28 2018
It's ten lines of code.. is there really nobody who can review this? It's been sitting in limbo for two and a half years. This would be very useful for addon developers....
Dec 26 2018
yeah this behavior is just bizarre. are any other modal tools affected by this, or is it just Inset?