[Bf-funboard] floating windows don't stay on top!

Jude Jackson syzygy6 at gmail.com
Thu Sep 26 06:11:13 CEST 2013


I was merely disagreeing with the contrarian implication that always-on-top
windows are worthless. They're a common part of many people's workflows,
especially people who don't have the luxury of two or three UHDTV monitors
at their disposal.

I have to roll my eyes at the "it's Blender design philosophy" argument
because blender design is a joke. Making it one's "philosophy" to constrain
the UX is very much putting the cart before the horse, and obviously is not
being upheld consistently. The search menu, tooltips, drop-down menus, and
a few other interface elements are all windows in the interface that
overlap other interface windows, working incredibly well without causing
any trouble (so much so your "philosophy" has conspicuously overlooked
them).

That said, it sounds as if there are indeed technical limitations that I
have no way of solving, and the problem is ill-defined. But as someone who
has tried using blender with a relatively small screen I can very much say
I vastly prefer expandable toolboxes a la CS4. Although the
blender interface has a charming sort of consistency, it's impractical,
without a truly regal monitor, to fit all the windows one needs to
efficiently work arranges in its infuriating enmeshed grid. Certainly one
can click the teensy-weensy icon in the corner and sort through the list of
lists, or toggle between window presets, but for various reasons it's not
ideal.

In other words, the request, while not necessarily the correct solution, is
indicative of a persistent UI problem that is being exasperated by the
silly rule that "windows don't overlap."

On Wednesday, September 25, 2013, david j wrote:

> On Wed, Sep 25, 2013 at 6:02 PM, Jude Jackson <syzygy6 at gmail.com<javascript:;>>
> wrote:
>
> > There are plenty of reasons to want a window always-on-top, assuming
> there
> > is ever a point during which you want a toolbar to be any size other than
> > the width of another window. Usually a partial obstruction of the main
> > viewport is more desirable than a full obstruction.
> >
>
> I think there are both philosophical and practical subtleties underneath
> your assertion here. It is important to be *precise* about what is
> requested, as the code is only going to do one precise thing! :)
>
> First, blender philosophy is to avoid overlapping windows, and so down this
> path we'd like to know the real *problem* you're trying to solve. Perhaps
> there is a way to solve it well which fits into the non-overlapping
> paradigm.
>
> Second, assuming this is something that should be added, there are at least
> three different "meanings" for always-on-top windows. (a) an OS global
> always-on-top, which stays ontop of ALL other apps. (b) an application
> global always-on-top which stays ontop of other blender windows, (c) a
> free-floating 'subregion' within the blender window which accepts
> ui-editors and is trapped within the OS-level window.
>
> Which are you asking for? To me it sounds probably like "b", but it's not
> clear without considering the use-case a bit more.
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard at blender.org <javascript:;>
> http://lists.blender.org/mailman/listinfo/bf-funboard
>


More information about the Bf-funboard mailing list