Blender user since 2009
- User Since
- Nov 6 2013, 3:54 PM (244 w, 5 d)
Aug 16 2014
The text would already be unreadable after a certain point, and this is pretty much the standard in other applications anyway, so this way we could keep a constant spacing between the drag area and collapse area.
If we do it right, the space itself could be the divisor. Or, on the mouse entering the header, we could highlight the drag area slightly:
I just realized this: any indicator splitting the panel header would have run-off problems if the text overlaps the drag area; how would you separate two overlapping areas?
Aug 13 2014
Wow, again I pushed submit too early...
@Warren Bahler (russcript) I do agree with your 'hidden' functions statement though.
@Warren Bahler (russcript), what do you think about just adding a minimum size, because even with the percentage (which can easily be done btw), we can have extreme situations where you end up with just one or two dots.
Aug 12 2014
@Warren Bahler (russcript), now that you've said that, I agree that the pin icons take up excess space, but they should still be implemented similarly across all panels.
Also, the percentage would still lead to an overflow issue when the region is too small in the same circumstance as before. We could clamp the width of the drag panel to a minimum though, and that would lead to a never-disappearing interface...
Aug 10 2014
@Tillmann Schütz (Ionarn) I think those would play very nicely with @Pablo Vazquez (venomgfx)'s widget redesign, but IMO it still needs some indicator that it can be dragged. I have taken the last week to think about this issue, and have come up with this idea (many similarities to yours):
And some not pinned:
(Pay no attention to the colors in the mockup, those are just for emphasis)
- This design places the functions by most used (most used function first):
- Collapsing (whose click area extends to the end of the text)
- The dot on the right would be the pin area (should still have the pin icon, not a circle, when pinned, this is just a pre-vis).
- Pinning should be more thoroughly implemented in the UI to provide
- improved consistency in the interface
- improved functionality
- The drag widget would hide when the mouse is not in the header
Aug 3 2014
Accidentally pushed post too early :P
Here's a mockup:
I have an idea. How about dividing the header between the collapse icon and the text? While I'm not too fond of the cluttering effect, it would delineate the different functions much better than what we have currently.
Aug 2 2014
@Albert (wevon) I think unless the whole UI team agrees, we should keep the blender style, but your concept would be cool looking!
Aug 1 2014
@Julian Eisel (Severin), how do you do the corner-rounding?
Jul 31 2014
Jul 29 2014
Something like this:
What if you numbered the listbox in ascending order? This will encourage the idea of priorities (#1 needs to be applied/is calculated first, #2 is second, etc). This would clarify the stack ideology while not hindering the effect of the listbox, as well as being much easier to code than a change to the listbox class itself.
Jul 28 2014
If you were to add a solo modifier, how would that work if the modifier is in the middle of the stack? Would you literally only view that modifier or would you view only that modifier and above?
Jul 27 2014
Sorry about yet another email, but I noticed a problem with my last diff. the dots should only use the header color if it is enabled, otherwise use the window back color.
Nevermind, I just remembered I'm not supposed to do that.
I will create a separate task for the panel redesign so this can be closed
Fix requested by @Campbell Barton (campbellbarton). Would've been sooner, had I figured out why the diffs weren't applying
Jul 24 2014
Fixes the scaling issue, the way they actually wanted!
OOHH MA GAWD! That's what you meant? Wow I thought you were talking about the individual box, not the highlight. Your past arguments make loads more sense now! haha XD
Idk why it says I accepted it, because I didn't push the button.
I made a mistake earlier, so here is the corrected diff. @Jonathan Williamson (carter2422), if you have a high density monitor, it would be a big help.
Jul 23 2014
That Contains the working handles, and just the handles so it will be a small patch for @Jonathan Williamson (carter2422)
I can't make a diff right now because I don't have the source, but here's the .c file
On higher density screens, those larger dark dots will appear to be about the same (maybe a little large), which is what DPI is made for, correct? If we were to leave them the same at higher densities (4k monitors) they would become invisible. Also, Region overlap can be fixed with changing the colors a bit, Show Background can be added to an if-statement, offset scaling is dividing space amount by block->aspect. I will commandeer at lunch if no one has made these changes by then. :)
Jul 22 2014
@Pablo Vazquez (venomgfx) I think using the widget for now would be the best option until the next release because such a drastic change as the panel redesign proposed needs to undergo more testing before being release-ready.
Also, @Pablo Vazquez (venomgfx), I have attempted active drag widgets, but as of the current mouse tracking system, there is no feasible way to do this IMO.
Here's a previous post, see if you can get it working:
- Idk if you were talking about codestyle for the new version or old, so I did both. Hopefully I got what you were talking about.
The block->aspect is related to the window zoom from what I can deduce, and the UI_DPI_FAC relates to the dpi scaling for denser screens. I think having it scale with both is more typical of similar UI elements, so I can implement that easily.
Jul 20 2014
@Antony Riakiotakis (psy-fi), with your last update (and probably all of mine), region overlap doesn't work with the panel body because it's not transparent. How should this be fixed?
Also, IDK if you committed already, but will you be using the simple widget as per @Paweł Łyczkowski (plyczkowski) or final windowed version?
Sorry for the delay (I was at a grad party with some of my hs friends), but @Antony Riakiotakis (psy-fi), what is the difference between glcolor4ub and glcolor4ubv?
I appreciate the help guys, very nice of you.
I agree with @Jonathan Williamson (carter2422), we could always wait to redesign the panels until after the next update or further in the future, so I am cool with using the original idea.
Jul 16 2014
Just an FYI: out of the box patch from master to metropolis_19 yields "patch does not apply" and "trailing white space" errors and when compiling:
blender\intern\cycles\kernel\kernel_compat_cpu.h(260): error C3861: 'InterlockedCompareExchange64': identifier not found blender\intern\cycles\kernel\kernel_compat_cpu.h(272): error C3861: 'InterlockedCompareExchange': identifier not found blender\intern\cycles\device\..\kernel\kernel_compat_cpu.h(260): error C3861: 'InterlockedCompareExchange64': identifier not found (blender\intern\cycles\device\device_cpu.cpp) blender\intern\cycles\device\..\kernel\kernel_compat_cpu.h(272): error C3861: 'InterlockedCompareExchange': identifier not found (blender\intern\cycles\device\device_cpu.cpp) blender\intern\cycles\device\device_cuda.cpp(716): error C2143: syntax error : missing ')' before '.' blender\intern\cycles\device\device_cuda.cpp(716): error C2228: left of '.w' must have class/struct/union type is 'int' blender\intern\cycles\device\device_cuda.cpp(716): error C2059: syntax error : ')'
Jun 17 2014
Relocated to here...
Ohhhhh! gotcha! like I said, my first post.
Feb 16 2014