[openbox] HCI-based suggestions for minor feature additions and behaviour updates
Clay Barnes
clay at hci-matters.com
Fri Feb 1 13:14:17 EST 2008
On 10:50 Fri 01 Feb , Dana Jansens wrote:
> On Fri, Feb 1, 2008 at 1:48 AM, Clay Barnes <clay at hci-matters.com> wrote:
> > I've been playing with the new release of of OB (quality as usual!),
> > and I thought I'd make a few HCI suggestions for the next release.
>
> Hi Clay,
>
> Thanks for your ideas!
>
> > * First, linear menus are accessed far faster (more than double
> > speed), if, instead of aligning sub-menus with the top edge by the
> > super-menu entry that holds it, it is centered on said super-menu
> > entry.
>
> As Mika said, this is already done. The setting is in the rc.xml, not
> in menu.xml files (it sounded like that is where you were trying to
> put it).
>
> > * Second, an useful option to add to rc.xml (or the theme files)
> > would be the ability to set the color of the
> > "selected/moving/resizing" box, since the default ones are not highly
> > visible with some setups/themes.
>
> I'm not sure what box you mean by selected.. but if I understand what
> you are referring to, these are themed by the osd.* theme settings,
> which many themes do not bother to set, and so they are inherited from
> elsewhere in the theme.
I think the osd.* are what I'm looking for. I'm going to play with
them now.
>
> > * Third, I would like to propose a new rc.xml setting defining how
> > edges are considered in movement/resizing. It would potentially be
> > called "Consider All Edges" and be boolean. The effect of enabling it
> > (which would be off by default, to ease transition) would be to
> > consider not only the edges of applications aligned with it, but also
> > all others (see example).
>
> This is an interesting idea, and would be very simple to implement..
Yay! I'm glad it'd had such a positive reception!
>
> > .___________.____.___________._____________________________.
> > | | f i |
> > | | | | |
> > a d | ._______|_______________. |
> > | | ~~~~g m |
> > | | | |__. |
> > |~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~|~~~~ | |
> > | .______. | | |
> > | .___. .___________. | | l n |
> > | b c | | j k | | |
> > | | | e h | | | | |
> > | ~~~~~ | | ~~~~~~~~ | | |
> > | | | | | |
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > In this example, moving window with edges b&c east with the move to
> > edge key, it would only consider the edges e, h, j, k, l, and n. The
> > new behaviour would be to consider every edge (d, e, f, g, h, i/j, k,
> > l, m, and n).
> >
> > * Fourth, I would like to propose that the edge that is currently
> > "stopping" edge motions should be highlighted along with the entire
> > line. In cases where the edge doesn't resize all the way to the
> > "stopping" edge (such as gvim or an xterm), the relevant edge should
> > also be highlighted. In the figure below, the user has moved the
> > aforementioned window east once and is still holding down a modifier
> > key. The highlight line is shown in asterisks.
>
> I really really like this idea.
:-D
> As well as this, I've wanted to but
> haven't added feedback for which edge is being resized (through
> positioning the cursor over it and setting it to an appropriate
> arrow).
I'd be careful about moving the cursor---remember there are absolute
positioning pointing devices (like the tablet I use) that generally do
strange things when moved around, jumping back and forth and so on.
Also, remember that you have to be very careful not to leave any
changes in mouse position after operations finish---otherwise users
will get frustrated quickly.
>
> Rather than this being a "while you hold down the modifier" thing, I
> would prefer this to simple flash a little line on screen for a second
> that is unrelated to modifiers. (Keyboard grabbing should be avoided
> at all costs in general..) This could be really prettified by a
> composite manager too. :)
Well, how is the current system handled? I know that when I hold down
the Meta4 key and use my vim keys to move around, the current window
is stays selected until I release my Meta4 key. That was the system I
imagined expanding to cover this situation, too.
>
> > .________________.___________._____________________________.
> > | * f i |
> > | * | | |
> > a d | ._______|_______________. |
> > | * ~~~~g m |
> > | * | |__. |
> > |~~~~~~~~~~~* ~~~~~~~~~~~~~~~~~~~~|~~~~ | |
> > | * .______. | | |
> > | .___*.___________. | | l n |
> > | b c| | j k | | |
> > | | *e h | | | | |
> > | ~~~~*| | ~~~~~~~~ | | |
> > | *| | | | |
> > ~~~~~~~~~~~~*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > The highlighting line also clarifies when things like terminals that
> > resize in larger-than-pixel increments. I find that I often overshoot
> > edges thinking I can squeeze in an extra character-width resize.
> >
> > Even without the consider all edges option, I think the edge
> > highlighting would be nice.
> >
> >
> >
> > Despite the length of this email, I think these suggestions would not
> > be too difficult to implement. I would highly appreciate thoughts or
> > suggestions on these proposals (especially on whether they're likely
> > to make it into a future release!).
>
>
> Would you mind dropping #3 and 4 into the bugzilla so they are less
> likely to be lost? And please clarify if #1 and 2 are not already
> available as I think they are..
I'll do that today!
>
>
> Cheers,
> Dana
>
--
Clay Barnes
Website:
http://www.hci-matters.com
GPG Public Key (Fingerprint 0xbb14 fce2 1199 c413):
http://www.hci-matters.com/keys/claybarnes_public_key_until20080718.gpg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://icculus.org/pipermail/openbox/attachments/20080201/1f015b74/attachment.pgp>
More information about the openbox
mailing list