- User Since
- Dec 12 2013, 11:11 PM (171 w, 1 d)
Just to make that clear: When talking about adding more information to tooltips I'm not talking about giving such in-depth descriptions like the manual. They should give all the essential information, the manual can go much broader than that (add screenshots, put tools/options into context, etc). Don't recall if we talked about this explicitly, but I think that's what other UI workshop attendees had in mind too.
I can think of two ways to solve this:
- Always use the first set of edges that form the same x/y coordinates as the one dragged from - In your example this would be the screen boundary on the right.
- Allow gradually increasing join size edge by edge - In your example this would look something like this:
Mouse release after dragging over first vertical edge: +-----+-+---+ | | | | | 1 +-+-+-+ | | | | +-----+---+-+
Thu, Mar 23
Great to see this tackled!
I also don't really agree with @Aaron Carlisle (Blendify) here, I find this much more intuitive than what we have currently.
Functionality wise I'd say it's fine to put this into the 2.8 branch as it overlaps with quite some other (planned) 2.8 UI changes. Note that there might be some conflicts when porting the patch to the blender2.8 branch.
Sat, Mar 18
Great! Just quickly compiled & tested it, and it's working just fine.
I don't think we should use separate files for every tooltip though, I'd prefer having JSON/XML/Python files for each module (mesh ops/props, screen ops/props, render ops/props, ...). IMHO that would be totally fine for users as well, it can be made really simple and self-explaining. Changing them won't be a common thing anyway, this is more meant to make it easier for people to do these changes and submit them for master inclusion.
On IRC we concluded that using this will be the exception, however thinking about it some more, I realize we actually should make heavy use of this. It could be a great way to improve our tooltips based on the new guidelines. And everybody could help doing it, not just devs ;)
Already discussed this with @Clément Foucault (fclem), we need a shader with clipping plane support here. I did this in the transform-manipulators branch already, see rBc5c2c3be9815670b.
We can also just wait until the new transform manipulators are ready to get merged into master (eventually!) which will fix this issue anyway. However it's not much work to fix this particular issue.
Fri, Mar 17
Committed rB2977a8cd2176 to 2.8 branch.
- Update patch for blender2.8
- Use new immediate mode work-alike drawing
- Remove testing code
Thu, Mar 16
Grrr... seems like auto-closing is failing... Closed by commit rB7eecc2e1c43ba.
Note that this only applies to "Active Render Layer" (which is now the default) and "Master Collection Tree" display mode, others should still work fine.
What you describe is intended behavior but it's optional. You can disable it using the "Lock to Scene" option.
Wed, Mar 15
I think this is a pretty fine proposal, although there are a few key-points that I'm not sure about, or which I imagined in a different way at least.
Good catch. Noticed something was off too, but didn't investigate and assumed it was in 2.8 branch only...
Tue, Mar 14
Mon, Mar 13
Closed by commit rB7bc76f8a3c14 :)
Sun, Mar 12
After all decided to keep things simple and just use a static char  for the screen names. This is how the menu looks like now:Could definitely be improved further, e.g. by adding a title to the popup, but better do that separately.
- Corrections to previous changes
- Cleanup, silence warnings, correct return type
- Correct tooltip
- Fix various issues with duplicating screens and creation of enum
- Display screen previews in menu
I'm glad this is being tackled too.
I assume plan is to apply @Brecht Van Lommel (brecht)'s patch on top of this? Better update the diff to avoid confusion if so. Without it I get a far too big UI drawing here because of the UI code assuming 72 DPI.
I got some local changes for this to fix a couple of issues I found, commented one major one inline.
Also, renaming operators usually causes breakage in scripts and keymaps. Guess for 2.8 that's fine, would still suggest to update add-ons and keymaps alongside this.
Sat, Mar 11
Blender has the virtual pixel size option for HiDPI screens, you can find it just below the DPI setting. Check the Blender manual for more info. So thanks for the report and the patch, but is just don't see a need for a change here ;)
Fri, Mar 10
Thu, Mar 9
Wed, Mar 8
This is a known limitation, we have it on our ToDo list https://wiki.blender.org/index.php/Dev:Source/Development/Todo/UserInterface#Regions.
We can fix it by keeping information about the state of an area/region prior to resizing it or changing the DPI. Would like to have a look at it at some point, but right now there's no time for it ;/
I quite like your approach and I'll probably reply as soon as I find the time to work on the project again. I'd really like to get this into the 2.8 branch soon but for that I need the time to finish it, but currently I'm working on some other projects :) (workspaces, new top bar, collection/layer UI, etc)
We've just discussed the idea of moving the '+' and 'x' icons into the menu here in the Bender Institute, and we agreed this is probably a good thing to do. The 'x' would always and only be visible for the active item of the menu, also adding feedback for what the active item is. Pablo is planning to do some mockups for 2.8 related things, he'll also incorporate this idea.
Tue, Mar 7
In short: If we want a multi-platform HMD support in Blender that's all we can get for now. For Linux users that's a big step forward, for Windows users not so much. (Not sure how HMD support in OSX is doing in general.)
I'm not saying I'm really happy with this, and I'm still not against having additional OpenVR support for those who have proprietary drivers for their system. I made sure there's an abstraction between OpenHMD and GHOST/Blender, so if the OpenVR API isn't too terribly different (and from a quick glance it isn't), it shouldn't be a huge task to add support for it (volunteers, raise your hand!).
I'm not aware of what OpenHMD does so that it changes the primary display, and of course that should definitely not be the case. @Joey Ferwerda (TheOnlyJoey), could you describe what's going on there?
- Return info in tooltip on why IPD button is disabled
- HMD settings are completely independent from multiview, render and camera data now
- Show info in tooltip on why HMD session can't be started
- Fall back to return unit matrix in OpenHMD GHOST calls
- Add libhidapi to install_deps.sh script.
- All HMD options are in properties region (3D View) and User Preferences (System) now.
- Allow zooming/panning while HMD view is in camera perspective
- Use solid draw mode by default for HMD view
- Mirror mode support (sync HMD viewpoint with regular 3D view)
- Use view orientation data from current 3D view for creating HMD view
- "Only Render" option for HMD view
- Don't allow orthographic view in HMD view
- Disable OpenHMD dummy device for release builds
- PSVR, Oculus CV1 and Vive support.
- Fixes for HMD support windows build (thanks LazyDodo)
- Refactor split-view drawing to make popups readable
- Don't draw HMD view lens shader if session is not running
- Draw additional viewport info in HMD view again (3D-cursor, mini-axis, etc)
So here is a outline of what I've discussed with @Dalai Felinto (dfelinto). As for a possible merge into master, if the bugs mentioned in Dalai's last comment are fixed, a merge should be fine.
I had a chat about the integration with @Dalai Felinto (dfelinto), will outline the results in a separate comment. Just answering some previous points here.
Should be fixed in rBca796f872e19.
3Dsmax and Blender 2012 Experimental presets still don’t have Shift+ Left Mouse keymap for planar constraints, after adding them manually before Any Left Mouse makes them work as expected for Translate and Rotate, Scale is still not working with planar constraints.
I have also noticed that in Blender (default) it is now possible to hold Shift before using Rotate to get accurate rotations, but in Maya config you still have to press Shift after starting rotation.