unity-design team mailing list archive

[Jo-Erlend Schinstad <joerlend.schinstad@xxxxxxxxx>]

Hey Ted.

Thanks for responding.

Den 22. mars 2012 20:08, skrev Ted Gould:

> 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.

Yes, I was thinking more in the long run. There's not a snowballs chance 
of me getting this properly implemented in that time frame anyway. But 
in the long run, I think it brings up some interesting questions which, 
if answered could open up some new opportunities.

> 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.

That is bad for a number of reasons. For instance, many applications 
will change the label when the state changes. For instance "show/hide", 
"play/pause", etc. It is really the same action, so the priority should 
also be the same, but it makes sense to change the label. Actually, 
that's more useful when considering the HUD. If I want to pause music, I 
wouldn't consider saying "toggle play", though that's something I could 
get used to with a visible menu.

But it's good to know. It means my improved code actually makes things 
worse, the way it is now. :)

> 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.

Yes, that sounds much better. Are there any concrete plans for that, or 
is it more of a long-term fuzzy goal? Using "Edit Current" as a static 
label is a good idea. I'll do that for now, though it'd be better if it 
would say what the current project is as well.

> 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.

If you remember, we had a brief chat on IRC about that the other day. I 
was a little bit puzzled by your description of how the search is done, 
though that was obviously rather vague, IRC being what it is. But my 
immediate thought was that it would be better to walk up the tree from 
the most recently used actions in decending order. That's based on the 
assumption that users actions will map fairly closely to how actions are 
organized in applications. If that assumption is correct, then this 
approach should search the most likely actions first, which increases 
the likelihood that the user will abort the search by selecting the 
right action, eliminating the need to search all entries. That would 
presumably increase the speed significantly. But of course, that's too 
many assumptions. I haven't even seen the algorithm that's currently 
used. But I'm very interested in this and I think it could be great fun 
to explore other solutions. Could you point me to the algorithmic parts 
of the HUD search? I haven't really looked too much at Unity code yet, 
so I'm not entirely sure where to look.

You're right that applications won't expect the parent items to be used 
as actions. But that's the point. While writing the Quickly HUD 
prototype, two things very quickly became apparent:
1) The HUD really works in the opposite way of how visible menus work.
2) "HUD-apps" can be a very comfortable way of combining different 
applications into a bigger context.
> 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.

Right. And I share that concern. But I think either the HUD should hide 
parent items, which traditionally have no associated user actions, or 
that item should be used for something. It makes no sense to have an 
option that has no consequences. But I'm also thinking about 
applications that have no visible interface, but is designed 
specifically for the HUD, like my Quickly-thing is. That changes things. 
And I think those kinds of applications can be quite useful. So to me, 
the question is not if, but how. I don't think it necessarily has to be 
too complicated. Adding a few bits and pieces to the appindicator 
library would probably be sufficient, I think.

Thanks again :)

--
Jo-Erlend Schinstad