Re: [Bf-committers] Blender 'a' release
Please include 41194 as well. Am 23.10.2011 02:51, schrieb Campbell Barton: On Thu, Oct 20, 2011 at 10:16 PM, Ton Roosendaalt...@blender.org wrote: Hi all, Yeah... we need an update! Campbell suggests to use the release branch. He will then merge in only crucial fixes in the release, sofar only 4 commits: 41113, 41117, 41128, 41134 Proposal would be to call for next Ahoy this monday though, to allow us to tackle other unforseen issues that can get reported still. Campbell will keep track of commits that need to go to 260a. -Ton- List has grown but all are still small/important changes: 41151, 41152, 41113, 41117, 41128, 41132, 41134, 41175, 41203 We also have to deal with addons, I have mailed bf-python list asking authors to say if they want fixes included in 2.60a, there is at least one fix which needs to be made for bug [#28988]. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 'a' release
41194 ??? - this is a commit to a branch. since last mail I found 2 more bugs. Updated list: 41151, 41152, 41113, 41117, 41128, 41132, 41134, 41175, 41203, 41211, 41214. On Sun, Oct 23, 2011 at 6:47 PM, Thomas Dinges blen...@dingto.org wrote: Please include 41194 as well. Am 23.10.2011 02:51, schrieb Campbell Barton: On Thu, Oct 20, 2011 at 10:16 PM, Ton Roosendaalt...@blender.org wrote: Hi all, Yeah... we need an update! Campbell suggests to use the release branch. He will then merge in only crucial fixes in the release, sofar only 4 commits: 41113, 41117, 41128, 41134 Proposal would be to call for next Ahoy this monday though, to allow us to tackle other unforseen issues that can get reported still. Campbell will keep track of commits that need to go to 260a. -Ton- List has grown but all are still small/important changes: 41151, 41152, 41113, 41117, 41128, 41132, 41134, 41175, 41203 We also have to deal with addons, I have mailed bf-python list asking authors to say if they want fixes included in 2.60a, there is at least one fix which needs to be made for bug [#28988]. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 'a' release
41197, sorry. :) Am 23.10.2011 09:58, schrieb Campbell Barton: 41194 ??? - this is a commit to a branch. since last mail I found 2 more bugs. Updated list: 41151, 41152, 41113, 41117, 41128, 41132, 41134, 41175, 41203, 41211, 41214. On Sun, Oct 23, 2011 at 6:47 PM, Thomas Dingesblen...@dingto.org wrote: Please include 41194 as well. Am 23.10.2011 02:51, schrieb Campbell Barton: On Thu, Oct 20, 2011 at 10:16 PM, Ton Roosendaalt...@blender.orgwrote: Hi all, Yeah... we need an update! Campbell suggests to use the release branch. He will then merge in only crucial fixes in the release, sofar only 4 commits: 41113, 41117, 41128, 41134 Proposal would be to call for next Ahoy this monday though, to allow us to tackle other unforseen issues that can get reported still. Campbell will keep track of commits that need to go to 260a. -Ton- List has grown but all are still small/important changes: 41151, 41152, 41113, 41117, 41128, 41132, 41134, 41175, 41203 We also have to deal with addons, I have mailed bf-python list asking authors to say if they want fixes included in 2.60a, there is at least one fix which needs to be made for bug [#28988]. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Arabic support in text editing
hello I was wondering after enabling UTF-8, how much work it needs to implement a filtering function that replaces normal Arabic text with it's universal UTF encoding, as it is currently implemented in python forking a c++ version is trivial. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Blender developer IRC meeting minutes, 23 October 2011
Hi all, Here's the notes from today's developer meeting: 1) Blender 2.60a update Some errors in 2.60 release are worth to immediately update. Campbell kept a dozen of crucial fixes separately, which will be applied on the 2.60 release source itself (so we don't release current svn trunk). Quick list of fixes (cleanup needed): http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/changelog_260a The 2.60a ahoy is expected to happen today or monday latest. Campbell will provide the instructions. 2) 2.61 targets plans - Bastien Montagne: reminder, we need to add a link for bf- translations into bf-blender svn. - Ton will update this page to reflect current state: http://wiki.blender.org/index.php/Dev:Doc/Projects - Ocean Sim patch: Lukas Toenne reports there's a new patch in the tracker that compiles and works fine, with some minor render issues though. After the Blender Conference he'll check on the new depenendency with fftw, whether or not it should be compile option. - DynaPaint branch: Sergey/Brecht are still reviewing it. - Planning for as now: October 30: confirm the list of targets for 2.61 (via mailing list) November 15: last day to get the branch in trunk entirely, or it moves to 2.62. - Cycles/Tracking branches: most merge work will happen after the Blender Conference. 3) other stuff - Next week: we skip the IRC meeting, too many people then are at the Blender Conference. Thanks, -Ton- Ton Roosendaal Blender Foundation t...@blender.orgwww.blender.org Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] image-save + .blend save destroys work without warning!
I've found that most blender users incl. advanced ones generally don't know this about blender so I think it needs to be discussed. Let me first explain how this works. What happens is that when you save out an image to file and then subsequently save your .blend and then reload your .blend then the image buffer will be reloaded from the image you saved. As an example let's say you went through the hard work of hand painting a floating point image and then save out, in Blender, as png, tga or even tiff (which is setup to 8 bits). If you then save the .blend file (and reload) then all your precision is lost and cannot be recovered. No warning is given and no options are presented when saving out an image. A similar example is alpha. Most of the image formats support alpha but for whatever reason Blender does not save alpha with all of them. If you pick such a format, save, then save the .blend and finally reload .blend then the alpha will be lost. I was hoping to have a discussion here on committers and hear what you all think is a good solution. I can personally understand why blender chooses to reload images from file since saving the image buffers with .blend file directly (to preserve them) is just asking for an explosion in file size. But in my opinion there should be a warning when there will be loss of data associated with a save (when its not just straight pass-through). Also I would prefer that when you do save out that you should be presented with options available for the chosen file format such as bit depths and number of channels or something. Cheers, Morten Mikkelsen ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] 2.60a Ahoy
Hi, I've merged in the fixes from trunk into the 2.60a tag. Tag: https://svn.blender.org/svnroot/bf-blender/tags/blender-2.60a-release/blender Unlike previous releases this isn't a revision from trunk, rather 2.60 release with specific commits merged from trunk. If you don't want to do a fresh checkout you can do... svn switch https://svn.blender.org/svnroot/bf-blender/tags/blender-2.60a-release/blender This will switch the addons repo too. The lib/ dir remains unchanged from 2.60. details - incase people want to know whats been changed... --- commits from trunk. svn merge ^/trunk/blender \ -c41113 \ -c41117 \ -c41128 \ -c41132 \ -c41134 \ -c41151 \ -c41152 \ -c41175 \ -c41197 \ -c41203 \ -c41211 \ -c41214 \ -c41219 --- commits from extensions svn merge ^/trunk/py/scripts/addons \ -c2494 \ -c2495 \ -c2496 \ -c2504 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] 2.60a Ahoy
Please squeeze in 41137, the fix for moving modifier icons. As far as I know it was a small but important fix, not resulting in new bugs (correct me if I'm wrong). It really would be nice to have this fix in a stable release. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] blender Control armatures precision Help!
I'm using two armatures to rig my model, one for rig the model and other to control it now when i use constraint for example. 'copy position' or something like that. the skeleton to control, copy too slow the last position of the control and some times isn't follow. the IK constraint works perfectly but the others not i want use armatures separatly why i dont want many vertex groups that i don't use, and also is follow if isn't have weight painted ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.60a Ahoy
Linux builds are on ftp. tag: blender-2.60a-release blender revision: 41226 addons revision: 2506 Campbell Barton wrote: Hi, I've merged in the fixes from trunk into the 2.60a tag. Tag: https://svn.blender.org/svnroot/bf-blender/tags/blender-2.60a-release/blender Unlike previous releases this isn't a revision from trunk, rather 2.60 release with specific commits merged from trunk. If you don't want to do a fresh checkout you can do... svn switch https://svn.blender.org/svnroot/bf-blender/tags/blender-2.60a-release/blender This will switch the addons repo too. The lib/ dir remains unchanged from 2.60. details - incase people want to know whats been changed... --- commits from trunk. svn merge ^/trunk/blender \ -c41113 \ -c41117 \ -c41128 \ -c41132 \ -c41134 \ -c41151 \ -c41152 \ -c41175 \ -c41197 \ -c41203 \ -c41211 \ -c41214 \ -c41219 --- commits from extensions svn merge ^/trunk/py/scripts/addons \ -c2494 \ -c2495 \ -c2496 \ -c2504 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] 2.60a Ahoy
On Mon, Oct 24, 2011 at 3:58 AM, Konfuse Kitty konfuseki...@yahoo.com wrote: Please squeeze in 41137, the fix for moving modifier icons. As far as I know it was a small but important fix, not resulting in new bugs (correct me if I'm wrong). It really would be nice to have this fix in a stable release. 2.60a is mainly for important bugfixes and we try not to make too many changes here, while 41137 is most likely ok, I think this is too late. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [41230] trunk/blender: Remove some more $Id$ that still were left after r41227 and r41228.
That Trunk does not compile after all these ID commits is known I guess? ;-) Lots of errors. Am 23.10.2011 21:01, schrieb gsr b3d: Revision: 41230 http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=41230 Author: gsrb3d Date: 2011-10-23 19:01:59 + (Sun, 23 Oct 2011) Log Message: --- Remove some more $Id$ that still were left after r41227 and r41228. -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] SVN (Trunk) broken
Hi, Trunk compile is broken, starting with SVN 41227. Please do not update SVN until further notice. Regards, Thomas -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] SVN (Trunk) broken
Fixed in SVN 41231, Thanks Bastien! :) Am 23.10.2011 21:23, schrieb Thomas Dinges: Hi, Trunk compile is broken, starting with SVN 41227. Please do not update SVN until further notice. Regards, Thomas -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] UI changes from cycles branch
Hi all, Here's a patch with a subset of the UI changes in the cycles branch that I'd like to merge into trunk. Are there any objections to this? Before: http://www.pasteall.org/pic/show.php?id=19452 After: http://www.pasteall.org/pic/show.php?id=19453 Patch: http://www.pasteall.org/25777/diff I don't think they would need any documentation updates, it's just small things that wouldn't confuse anyone in screenshot: * Remove emboss on areas and regions * Remove button emboss * More subtle colors and gradients on buttons * Black arrows on menu button * Panel header changed look smaller * Screen splitting widgets look * Toolbar/properties expand button look Not included: * Droid sans font, was not received very well for the few days it was in trunk * Contrast reduction on icons * Auto hide scrollers (later, is unfinished) I'd still like to change the font in trunk, but it seems hard to get an agreement on this. Some tests: Lucida Grade (mac ui font, non-free): http://www.pasteall.org/pic/show.php?id=19454 Ubuntu font: http://www.pasteall.org/pic/show.php?id=19457 Droid Sans font: http://www.pasteall.org/pic/show.php?id=19458 Thanks, Brecht. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] UI changes from cycles branch
On Mon, Oct 24, 2011 at 10:21 AM, Brecht Van Lommel brechtvanlom...@pandora.be wrote: Hi all, Here's a patch with a subset of the UI changes in the cycles branch that I'd like to merge into trunk. Are there any objections to this? I'd personally like to hear the rationale for these rather than just saying here's the patch. Some of it seems a bit more like a matter of taste too, rather than something that's designed for a wide audience, so I'm curious to hear the reasoning. I don't think they would need any documentation updates, it's just small things that wouldn't confuse anyone in screenshot: * Remove emboss on areas and regions * Remove button emboss * More subtle colors and gradients on buttons Most of these I don't think it would be a problem to make the embossing a bit more subtle, but I'm not keen on removing it all entirely. Even just a subtle hint of shape and shading really helps to distinguish the buttons from everything else - not just in the literal sense of give it an affordance 'this is a button, you can click on it' but mainly for some visual difference between the rest of everything else on screen. When everything is flat with single pixel outlines (not just buttons, but also other dividers, grids, scrollers, lines in other editors like the animation/timeline editors), it loses a sense of visual hierarchy and rhythm - it all tends to merge into one soup of lines and flat shaded areas, and makes it harder to find things quickly in the UI. * Black arrows on menu button -1, Way too low contrast, there's almost no point in having them there. Makes them look like other dark UI widgets like radio buttons, which is not good. * Panel header changed look smaller Seems ok, but I would give it an extra pixel or so of padding both above and below, it's quite cramped and loses its sense of importance in wayfinding (becomes much more like just another button). * Screen splitting widgets look Not a fan of how it is now, but perhaps if it was the dark triangle with a hint of the 'gripper' lines blended on top it would work better. * Toolbar/properties expand button look Looks great I'd still like to change the font in trunk, but it seems hard to get an agreement on this. Some tests: Again, I'd like to hear the rationale - I think the font in trunk right now is very good. If it's to make things smaller and more condensed, be wary of cutting off one's nose to spite one's face - you *need* whitespace in design, it's not just wasted areas where more can be crammed in. cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] UI changes from cycles branch
Hi all, as a user not a dev., imo * Remove emboss on areas and regions * Remove button emboss removing emboss will revert blender to the 2.4x looks, which i think is very old i don't see why you have to change the current * More subtle colors and gradients on buttons yes it's better * Black arrows on menu button it's hard to see, and hidden for newbies * Panel header changed look smaller it's already small n big screens * Screen splitting widgets look * Toolbar/properties expand button look definitely better Not included: * Droid sans font, was not received very well for the few days it was in trunk * Contrast reduction on icons * Auto hide scrollers (later, is unfinished) the provided fonts are narrower, hard to see and more blurry. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] UI changes from cycles branch
Matt Ebb +1 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] UI changes from cycles branch
I agree with the comments about the black arrows, and the buttons looking less like buttons. Love the new side panel expanders, but the splitting corners are too hard too see, i agree it might be better with some gripper lines. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] UI changes from cycles branch
Even though I like it better with your modification, I do agree with Matt this is just a design subjectif point of view. not sure if it MUST be changed or not. 2011/10/24 Αντώνης Ρυακιωτάκης kal...@gmail.com Matt Ebb +1 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- François Tarlier www.francois-tarlier.com www.linkedin.com/in/francoistarlier ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] UI changes from cycles branch
When i started with blender 2.48, for a month at least i wasn't able to distinguish when a button was pressed or not because of the flat and shadeless style, so -1 for that. +1 to give a panel title background a little background color difference. Arrows in combo boxes are useful for beginners, -1 for the change I don't have any special inclination for the other changes. cheers. 2011/10/23 François T. francoistarl...@gmail.com Even though I like it better with your modification, I do agree with Matt this is just a design subjectif point of view. not sure if it MUST be changed or not. 2011/10/24 Αντώνης Ρυακιωτάκης kal...@gmail.com Matt Ebb +1 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- François Tarlier www.francois-tarlier.com www.linkedin.com/in/francoistarlier ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] UI changes from cycles branch
Hi, On Mon, Oct 24, 2011 at 1:39 AM, Matt Ebb m...@mke3.net wrote: I'd personally like to hear the rationale for these rather than just saying here's the patch. Some of it seems a bit more like a matter of taste too, rather than something that's designed for a wide audience, so I'm curious to hear the reasoning. Alright, I already discussed this with a few people, so forgot that it might need more explanation :) * Remove emboss on areas and regions The embossing distracts from the buttons and text in the actual region. There wasn't any embossing around areas (mistakenly mentioned that), only black lines. It's around regions only, and there it doesn't seem to help much, because the regions are in a different color from the main region anyway? * Remove button emboss * More subtle colors and gradients on buttons For me this helps a lot in making the buttons more readable. Most user interfaces have only sparsely distributed buttons, but in blender we have many buttons, and I think at a certain point embossing and gradients just make it harder to actually read the text in them. Buttons with more embossing make a clear distinction with e.g. the 3d view or timeline, but I think they just take away attention too much. Most user interfaces have most buttons in the same color and nearly the same color as the background. In Blender this is not the case, and adding embossing doesn't seem needed. * Black arrows on menu button -1, Way too low contrast, there's almost no point in having them there. Makes them look like other dark UI widgets like radio buttons, which is not good. For me the arrows are quite visible but they could be made darker still. I think that if you look at the buttons, you see the arrows, but if you're scanning over buttons they can be skipped over. I think this is a good thing, for example in the 3d view header, there's a few of those in a row. The white arrows distract from the white text/icons and it's harder to scan for the right button. * Panel header changed look smaller The panel header with a single line makes it more difficult to see where one panel ends and the other begins, so I made the entire header darker. There is no longer space between the panels when they are collapsed, but otherwise the header has the same size. They could be made a bit bigger but don't feel cramped to me, maybe they would on a bigger screen. * Screen splitting widgets look Not a fan of how it is now, but perhaps if it was the dark triangle with a hint of the 'gripper' lines blended on top it would work better. Ok, I can try to add some subtle gripper lines. * Toolbar/properties expand button look Guess this one was obvious, unconnected (+) buttons are confusing. I'd still like to change the font in trunk, but it seems hard to get an agreement on this. Some tests: Again, I'd like to hear the rationale - I think the font in trunk right now is very good. If it's to make things smaller and more condensed, be wary of cutting off one's nose to spite one's face - you *need* whitespace in design, it's not just wasted areas where more can be crammed in. I don't particularly care about the text being smaller, any gains there are very minor. I just think the current font is hard to read at this size, too 'smudgy', and the shapes of words aren't very distinctive. My impression is that there are fonts that were designed to work better at this font size. Thanks, Brecht. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] UI changes from cycles branch
Hi, The only two things I care about are the button shading and the font. I don't like the idea of removing the button shading, I love the shading, and I don't think just drawing rounded boxes and passing them off as buttons looks good. However, I don't feel very strongly about this, as I have been using Cycles for a while, and only noticed the flat buttons about a week ago, and can always change it in the User Prefs. On the font front however, I really don't think you should change the font. -10 on Droid Sans. Maybe -1 on Mac font, and -0.5 Ubuntu font. I like the Ubuntu font when it's big, but I just don't think it belongs in Blender, especially at that size. The mac font is just ugly, though that's just my personal opinion. Oh, and I love the new Texture icons and the gray subpanel divider boxes! On Sun, Oct 23, 2011 at 9:29 PM, Brecht Van Lommel brechtvanlom...@pandora.be wrote: Hi, On Mon, Oct 24, 2011 at 1:39 AM, Matt Ebb m...@mke3.net wrote: I'd personally like to hear the rationale for these rather than just saying here's the patch. Some of it seems a bit more like a matter of taste too, rather than something that's designed for a wide audience, so I'm curious to hear the reasoning. Alright, I already discussed this with a few people, so forgot that it might need more explanation :) * Remove emboss on areas and regions The embossing distracts from the buttons and text in the actual region. There wasn't any embossing around areas (mistakenly mentioned that), only black lines. It's around regions only, and there it doesn't seem to help much, because the regions are in a different color from the main region anyway? * Remove button emboss * More subtle colors and gradients on buttons For me this helps a lot in making the buttons more readable. Most user interfaces have only sparsely distributed buttons, but in blender we have many buttons, and I think at a certain point embossing and gradients just make it harder to actually read the text in them. Buttons with more embossing make a clear distinction with e.g. the 3d view or timeline, but I think they just take away attention too much. Most user interfaces have most buttons in the same color and nearly the same color as the background. In Blender this is not the case, and adding embossing doesn't seem needed. * Black arrows on menu button -1, Way too low contrast, there's almost no point in having them there. Makes them look like other dark UI widgets like radio buttons, which is not good. For me the arrows are quite visible but they could be made darker still. I think that if you look at the buttons, you see the arrows, but if you're scanning over buttons they can be skipped over. I think this is a good thing, for example in the 3d view header, there's a few of those in a row. The white arrows distract from the white text/icons and it's harder to scan for the right button. * Panel header changed look smaller The panel header with a single line makes it more difficult to see where one panel ends and the other begins, so I made the entire header darker. There is no longer space between the panels when they are collapsed, but otherwise the header has the same size. They could be made a bit bigger but don't feel cramped to me, maybe they would on a bigger screen. * Screen splitting widgets look Not a fan of how it is now, but perhaps if it was the dark triangle with a hint of the 'gripper' lines blended on top it would work better. Ok, I can try to add some subtle gripper lines. * Toolbar/properties expand button look Guess this one was obvious, unconnected (+) buttons are confusing. I'd still like to change the font in trunk, but it seems hard to get an agreement on this. Some tests: Again, I'd like to hear the rationale - I think the font in trunk right now is very good. If it's to make things smaller and more condensed, be wary of cutting off one's nose to spite one's face - you *need* whitespace in design, it's not just wasted areas where more can be crammed in. I don't particularly care about the text being smaller, any gains there are very minor. I just think the current font is hard to read at this size, too 'smudgy', and the shapes of words aren't very distinctive. My impression is that there are fonts that were designed to work better at this font size. Thanks, Brecht. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] UI changes from cycles branch
Can we start a new thread discussing the design constraints on the default typeface perhaps? With respect, TJS On Oct 23, 2011 4:39 PM, Matt Ebb m...@mke3.net wrote: On Mon, Oct 24, 2011 at 10:21 AM, Brecht Van Lommel brechtvanlom...@pandora.be wrote: Hi all, Here's a patch with a subset of the UI changes in the cycles branch that I'd like to merge into trunk. Are there any objections to this? I'd personally like to hear the rationale for these rather than just saying here's the patch. Some of it seems a bit more like a matter of taste too, rather than something that's designed for a wide audience, so I'm curious to hear the reasoning. I don't think they would need any documentation updates, it's just small things that wouldn't confuse anyone in screenshot: * Remove emboss on areas and regions * Remove button emboss * More subtle colors and gradients on buttons Most of these I don't think it would be a problem to make the embossing a bit more subtle, but I'm not keen on removing it all entirely. Even just a subtle hint of shape and shading really helps to distinguish the buttons from everything else - not just in the literal sense of give it an affordance 'this is a button, you can click on it' but mainly for some visual difference between the rest of everything else on screen. When everything is flat with single pixel outlines (not just buttons, but also other dividers, grids, scrollers, lines in other editors like the animation/timeline editors), it loses a sense of visual hierarchy and rhythm - it all tends to merge into one soup of lines and flat shaded areas, and makes it harder to find things quickly in the UI. * Black arrows on menu button -1, Way too low contrast, there's almost no point in having them there. Makes them look like other dark UI widgets like radio buttons, which is not good. * Panel header changed look smaller Seems ok, but I would give it an extra pixel or so of padding both above and below, it's quite cramped and loses its sense of importance in wayfinding (becomes much more like just another button). * Screen splitting widgets look Not a fan of how it is now, but perhaps if it was the dark triangle with a hint of the 'gripper' lines blended on top it would work better. * Toolbar/properties expand button look Looks great I'd still like to change the font in trunk, but it seems hard to get an agreement on this. Some tests: Again, I'd like to hear the rationale - I think the font in trunk right now is very good. If it's to make things smaller and more condensed, be wary of cutting off one's nose to spite one's face - you *need* whitespace in design, it's not just wasted areas where more can be crammed in. cheers Matt ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] UI changes from cycles branch
Hi, I fully agree with Brechts changes and give +1 for them as Py UI Module Owner and member of the Interface Look team! I would also not necessarily change the screen splitting widget, I think it's way better in the Cycles branch now, compared to trunk. Removing the white arrows in menus, making them darker, helps indeed a lot while scanning over buttons as well. Regards, Thomas Am 24.10.2011 03:29, schrieb Brecht Van Lommel: Hi, On Mon, Oct 24, 2011 at 1:39 AM, Matt Ebbm...@mke3.net wrote: I'd personally like to hear the rationale for these rather than just saying here's the patch. Some of it seems a bit more like a matter of taste too, rather than something that's designed for a wide audience, so I'm curious to hear the reasoning. Alright, I already discussed this with a few people, so forgot that it might need more explanation :) * Remove emboss on areas and regions The embossing distracts from the buttons and text in the actual region. There wasn't any embossing around areas (mistakenly mentioned that), only black lines. It's around regions only, and there it doesn't seem to help much, because the regions are in a different color from the main region anyway? * Remove button emboss * More subtle colors and gradients on buttons For me this helps a lot in making the buttons more readable. Most user interfaces have only sparsely distributed buttons, but in blender we have many buttons, and I think at a certain point embossing and gradients just make it harder to actually read the text in them. Buttons with more embossing make a clear distinction with e.g. the 3d view or timeline, but I think they just take away attention too much. Most user interfaces have most buttons in the same color and nearly the same color as the background. In Blender this is not the case, and adding embossing doesn't seem needed. * Black arrows on menu button -1, Way too low contrast, there's almost no point in having them there. Makes them look like other dark UI widgets like radio buttons, which is not good. For me the arrows are quite visible but they could be made darker still. I think that if you look at the buttons, you see the arrows, but if you're scanning over buttons they can be skipped over. I think this is a good thing, for example in the 3d view header, there's a few of those in a row. The white arrows distract from the white text/icons and it's harder to scan for the right button. * Panel header changed look smaller The panel header with a single line makes it more difficult to see where one panel ends and the other begins, so I made the entire header darker. There is no longer space between the panels when they are collapsed, but otherwise the header has the same size. They could be made a bit bigger but don't feel cramped to me, maybe they would on a bigger screen. * Screen splitting widgets look Not a fan of how it is now, but perhaps if it was the dark triangle with a hint of the 'gripper' lines blended on top it would work better. Ok, I can try to add some subtle gripper lines. * Toolbar/properties expand button look Guess this one was obvious, unconnected (+) buttons are confusing. I'd still like to change the font in trunk, but it seems hard to get an agreement on this. Some tests: Again, I'd like to hear the rationale - I think the font in trunk right now is very good. If it's to make things smaller and more condensed, be wary of cutting off one's nose to spite one's face - you *need* whitespace in design, it's not just wasted areas where more can be crammed in. I don't particularly care about the text being smaller, any gains there are very minor. I just think the current font is hard to read at this size, too 'smudgy', and the shapes of words aren't very distinctive. My impression is that there are fonts that were designed to work better at this font size. Thanks, Brecht. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] UI changes from cycles branch
I think it's okay to discuss button shading a bit though, but apart from that, the changes are pretty much straight forward and should go to trunk for sure. :) Again, big +1 for this! Am 24.10.2011 06:01, schrieb Thomas Dinges: Hi, I fully agree with Brechts changes and give +1 for them as Py UI Module Owner and member of the Interface Look team! I would also not necessarily change the screen splitting widget, I think it's way better in the Cycles branch now, compared to trunk. Removing the white arrows in menus, making them darker, helps indeed a lot while scanning over buttons as well. Regards, Thomas Am 24.10.2011 03:29, schrieb Brecht Van Lommel: Hi, On Mon, Oct 24, 2011 at 1:39 AM, Matt Ebbm...@mke3.net wrote: I'd personally like to hear the rationale for these rather than just saying here's the patch. Some of it seems a bit more like a matter of taste too, rather than something that's designed for a wide audience, so I'm curious to hear the reasoning. Alright, I already discussed this with a few people, so forgot that it might need more explanation :) * Remove emboss on areas and regions The embossing distracts from the buttons and text in the actual region. There wasn't any embossing around areas (mistakenly mentioned that), only black lines. It's around regions only, and there it doesn't seem to help much, because the regions are in a different color from the main region anyway? * Remove button emboss * More subtle colors and gradients on buttons For me this helps a lot in making the buttons more readable. Most user interfaces have only sparsely distributed buttons, but in blender we have many buttons, and I think at a certain point embossing and gradients just make it harder to actually read the text in them. Buttons with more embossing make a clear distinction with e.g. the 3d view or timeline, but I think they just take away attention too much. Most user interfaces have most buttons in the same color and nearly the same color as the background. In Blender this is not the case, and adding embossing doesn't seem needed. * Black arrows on menu button -1, Way too low contrast, there's almost no point in having them there. Makes them look like other dark UI widgets like radio buttons, which is not good. For me the arrows are quite visible but they could be made darker still. I think that if you look at the buttons, you see the arrows, but if you're scanning over buttons they can be skipped over. I think this is a good thing, for example in the 3d view header, there's a few of those in a row. The white arrows distract from the white text/icons and it's harder to scan for the right button. * Panel header changed look smaller The panel header with a single line makes it more difficult to see where one panel ends and the other begins, so I made the entire header darker. There is no longer space between the panels when they are collapsed, but otherwise the header has the same size. They could be made a bit bigger but don't feel cramped to me, maybe they would on a bigger screen. * Screen splitting widgets look Not a fan of how it is now, but perhaps if it was the dark triangle with a hint of the 'gripper' lines blended on top it would work better. Ok, I can try to add some subtle gripper lines. * Toolbar/properties expand button look Guess this one was obvious, unconnected (+) buttons are confusing. I'd still like to change the font in trunk, but it seems hard to get an agreement on this. Some tests: Again, I'd like to hear the rationale - I think the font in trunk right now is very good. If it's to make things smaller and more condensed, be wary of cutting off one's nose to spite one's face - you *need* whitespace in design, it's not just wasted areas where more can be crammed in. I don't particularly care about the text being smaller, any gains there are very minor. I just think the current font is hard to read at this size, too 'smudgy', and the shapes of words aren't very distinctive. My impression is that there are fonts that were designed to work better at this font size. Thanks, Brecht. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] UI changes from cycles branch
Overall seems ok to me, though some of these details I'm not fussed either way. dark vs light arrows - no strong opinion here, though I like lower contrast but agree its too low at least on my monitor. Matt, agree emboss on buttons could be good but think how its used in trunk does not communicate anything about the buttons state. In Agustin Benavidez's reply he mentions about buttons being pressed being hard to see, While I agree with him (and think we should improve this), I don't think you're patch makes this better or worse, in both since the emboss is on the outside not showing if the button is pressed or not. On Mon, Oct 24, 2011 at 3:01 PM, Thomas Dinges blen...@dingto.org wrote: Hi, I fully agree with Brechts changes and give +1 for them as Py UI Module Owner and member of the Interface Look team! I would also not necessarily change the screen splitting widget, I think it's way better in the Cycles branch now, compared to trunk. Removing the white arrows in menus, making them darker, helps indeed a lot while scanning over buttons as well. Regards, Thomas Am 24.10.2011 03:29, schrieb Brecht Van Lommel: Hi, On Mon, Oct 24, 2011 at 1:39 AM, Matt Ebbm...@mke3.net wrote: I'd personally like to hear the rationale for these rather than just saying here's the patch. Some of it seems a bit more like a matter of taste too, rather than something that's designed for a wide audience, so I'm curious to hear the reasoning. Alright, I already discussed this with a few people, so forgot that it might need more explanation :) * Remove emboss on areas and regions The embossing distracts from the buttons and text in the actual region. There wasn't any embossing around areas (mistakenly mentioned that), only black lines. It's around regions only, and there it doesn't seem to help much, because the regions are in a different color from the main region anyway? * Remove button emboss * More subtle colors and gradients on buttons For me this helps a lot in making the buttons more readable. Most user interfaces have only sparsely distributed buttons, but in blender we have many buttons, and I think at a certain point embossing and gradients just make it harder to actually read the text in them. Buttons with more embossing make a clear distinction with e.g. the 3d view or timeline, but I think they just take away attention too much. Most user interfaces have most buttons in the same color and nearly the same color as the background. In Blender this is not the case, and adding embossing doesn't seem needed. * Black arrows on menu button -1, Way too low contrast, there's almost no point in having them there. Makes them look like other dark UI widgets like radio buttons, which is not good. For me the arrows are quite visible but they could be made darker still. I think that if you look at the buttons, you see the arrows, but if you're scanning over buttons they can be skipped over. I think this is a good thing, for example in the 3d view header, there's a few of those in a row. The white arrows distract from the white text/icons and it's harder to scan for the right button. * Panel header changed look smaller The panel header with a single line makes it more difficult to see where one panel ends and the other begins, so I made the entire header darker. There is no longer space between the panels when they are collapsed, but otherwise the header has the same size. They could be made a bit bigger but don't feel cramped to me, maybe they would on a bigger screen. * Screen splitting widgets look Not a fan of how it is now, but perhaps if it was the dark triangle with a hint of the 'gripper' lines blended on top it would work better. Ok, I can try to add some subtle gripper lines. * Toolbar/properties expand button look Guess this one was obvious, unconnected (+) buttons are confusing. I'd still like to change the font in trunk, but it seems hard to get an agreement on this. Some tests: Again, I'd like to hear the rationale - I think the font in trunk right now is very good. If it's to make things smaller and more condensed, be wary of cutting off one's nose to spite one's face - you *need* whitespace in design, it's not just wasted areas where more can be crammed in. I don't particularly care about the text being smaller, any gains there are very minor. I just think the current font is hard to read at this size, too 'smudgy', and the shapes of words aren't very distinctive. My impression is that there are fonts that were designed to work better at this font size. Thanks, Brecht. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org
