unity-design team mailing list archive

[Ted Gould <ted@xxxxxxxxxx>]

On Sun, 2012-03-18 at 10:16 +0100, Jo-Erlend Schinstad wrote:
> I'm writing an application for Quickly to enable HUD navigation. The 
> prototype proved to be an extremely comfortable way of using Quickly, so 
> I'm going ahead with the project. However, it also presented a few 
> questions that I need to get answered by someone more deeply involved in 
> HUD. In order for you to follow, I'll quickly provide a heads-up on the 
> design :)

Cool.

<snip>
> So, the three main questions are;
> 1) Should I be doing this, or are parent items supposed to be hidden in 
> the HUD and this is a bug that will go away at some point? I hope that's 
> not the case, because I'm designing this purely for the HUD. I'm not 
> even displaying menus at all. Using the parent item as default is very 
> comfortable when using the HUD. I also think it makes very good sense, 
> at least as long as you ignore the past.

I think you're running into a few issues here, some are bugs, some are
technicalities that perhaps we should fix.  I don't know that it this
point we can do anything big for 12.04, but we should definitely
consider how to make this better.  But, let me explain a little.

To track usage we're using the text for the menu.  So in the database
for File > Open we probably have something like "_File||_Open" which is
how the item gets tracked.  This is done for a couple of reasons.
Mostly because we have no other way to track entries between program
launches.  The IDs are effectively random between runs.  So what that
means is that when you have "Project||Edit (active: Bob)" and you change
it to "Project||Edit (active: Al)" HUD is tracking those as entirely
different menu items.

Now, in the future, we can do better, and that's mostly because of
GMenuModel being action based.  We can start to track the menu usage by
the action name instead of the label, which will be really cool.  So if
you create an action "edit-last-project" we can start to lookup things
by that.

> 2) If it's not a bug, and it's ok for me to rely on this; can I ask that 
> the parent item gets a higher default priority than the submenu items? 
> Because currently, it gets the lowest priority, which means you'll have 
> to actively choose it until it gets a high enough priority to become 
> default. In my use-case, that means that the default is not the default 
> by default, which makes the feature less user friendly, and certainly 
> less "intuitive".
<snip>

So we have discussed, but haven't implemented the idea that position in
the tree should provide some initial bias about how the entry is
weighted.  I think it's a good idea, but it needs to be played with.  I
think that it doesn't make sense to activate the parent items though as
that's simply not what the application would expect.  For instance, some
GTK applications use this for effectively "about-to-show" signaling.
And we in fact send it as such to applications on the global menu bar.

> 3) In classical menus, it is assumed that if the parent item is 
> deactivated, then all children are as well, since it would be impossible 
> to reach them. This makes sense for classical menus, but does it make 
> sense for the HUD, and if it doesn't; what could be done to allow the 
> HUD to make use of them differently without breaking current apps? 
> Again, I think adding some properties for HUD-specific features will 
> make sense.
> 
> If the parent item should be displayed, then it should be possible to 
> use it for something. If you hide it or set it insensitive in client 
> code, then you also remove all children from the HUD. Using it to point 
> at the last used child action, possibly regardless of depth, seems like 
> a useful feature. This is a way to use menu structures that isn't common 
> for visible menus, but I imagine this will be quite useful for many 
> applications that has deep structures and wants to optimize for the HUD. 
> So I hope I can get some feedback on this.

Again, as above, I'm worried about breaking standard applications in
activating menu items that, for instance, don't have the callbacks set
up properly in that case.  I think a better way is to allow for actions
to be exported that aren't in menus, which is something that we don't
yet have a plan for.

		--Ted

Attachment: signature.asc
Description: This is a digitally signed message part