[haiku-commits] Re: r41754 - in haiku/trunk/src/apps: . switcher

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Mon, 30 May 2011 21:08:04 +0200

Clemens <clemens.zeidler@xxxxxxxxxxxxxx> wrote:
> - focus follows mouse gives somewhat random results for the left 
> right  
> menu...

It chooses the last window you rest the mouse cursor over for more than 
50ms to retrieve the team. While the delay might not be optimal yet, I 
have no idea how a better algorithm would work.
In any case, I wanted to make the panels available via shortcuts as 
well (and make them usable by keyboard only, too), so that wouldn't 
matter that much in that case. Also, if you know how it works, you get 
used to it pretty easily (at least that happened to me).

> - how the apps for the top/bottom menu are chosen? found it not very  
> helpful, for example which terminal is on which workspace? / which  
> terminal is meant by the icons?

Well, it's a work in progress. As you may know, the Deskbar doesn't 
actually show all teams, but groups them together by signature. The 
Switcher app doesn't do this yet, and shows you all running teams 
separately -- which is confusing for terminals, but should by no means 
stay that way.

> - animation could be bit faster or switched off?  looks very nice but  
> slows down the workflow IMHO.

I tried to make it fast enough to not be annoying, but I obviously 
failed in your case :-)
Of course, it would be pretty easy to change that (or even have an 
option for no animations which might also be useful for older 

> Did somebody already thought about an animation framework? For 
> example, a  
> class derived from BHandler that can be used to do the animation and 
> has  
> to be installed into a BLooper. The programmer has to overwrite a 
> hook  
> function Animate(float progress) to do the work (progress from 0 to 
> 1)...

Depending on your use case, using a BHandler is probably not a good 
idea for smooth animations, as updating the view works asynchronously, 
so you'll always have a delay until the next invalidation is "cured". 
For animations, it's better to do the computations in another thread 
which gives you less delay for redrawing the view.


Other related posts: