[Bf-committers] 2.5 UI font
doug at mudpuddle.co.nz
Wed Dec 9 01:38:38 CET 2009
Just from another perspective in the changing world of computers.
The standard screen aspect ratio for new monitors (exceptions exist) is
16:9 or 16:10. This means that vertical toolbars are more appropriate in
these situations since the leftover realestate is still wider than tall.
In terms of moving more of the toolbars to horizontal layouts, it may be
appropriate to target which toolbars should be horizontal based on
appropriate content. I.e. the tools, the timeline, the sequencer... are all
appropriate for a horizontal layout. whereas the buttons window is
certainly not appropriate for horizontal layout based on the flexibility of
From: William Reynish
Subject: Re: [Bf-committers] 2.5 UI font
Sent: 08 Dec '09 23:14
I'm not quite following this debate.
First of all, horizontal properties are still available: [LINK:
This image really shows the issue with horizontal layout (bad use of
space), which was already largely unusable in 2.49. Many panels already
varied in height back then (See Mirror in Shading context or especially
constraints and modifiers), and the ones that didn't largely consisted of
random, unorganized buttons.
Second, are you proposing to have two independent layouts for horizontal
and vertical layouts? If so, I don't see that solving any issues.
Conversely I think it's asking for trouble.
That said, I'm all for a solution that makes it possible to have a
vertical or horizontal layout, but so far there's been talk about it in
vague terms. Better to get actual proposals/mockups/something concrete.
Whichever way I can think of looking at it, the problem comes down to
this: How do we organize panels of arbitrary height in a horizontal
Three possible solutions I can think of:
1: remove horizontal layout - use vertical instead
2: keep it as-is to ease transition to vertical
3: Implement clever way to make panels 'wrap around' and spill contents
into the next panel column
4: Use a simple type of 'autofit' to make panels fit into the available
space without spilling/splitting panels over multiple columns
Did I miss any?
Something like option 3 is of course theoretically possible, though that
both requires a fair bit of work, and I don't think its really viable in
terms of usability. What it means is that panels would jump around as you
resize the properties area, making the UI seem very unstable. Option 4
implies headers not always aligned, making eye scanning through many panels
On 8 Dec, 2009, at 8:35 PM, GSR wrote:
> [LINK: http://email@example.com]
dingto at gmx.de (2009-12-08 at 1903.45 +0100):
>> honestly. 2.5 was designed for vertical buttons window in the first
>> place, everything else is up to the user, who can modifiy the layout
>> files as he wish.
> So there will be lots of redundant work that is not properly
> shared. There should be no problem if layout engine provided
> horizontal functions, just add two functions draw_horizontal and
> draw_vertical, move current contents of draw to draw_vertical and make
> draw have an if/else decide (until h is implemented, use v
> one). Finally let users become new developers and contribute the
> draw_horizontal code.
> Bf-committers mailing list
Bf-committers at blender.org
> [LINK: http://lists.blender.org/mailman/listinfo/bf-committers]
Bf-committers mailing list
Bf-committers at blender.org
More information about the Bf-committers