[haiku-development] Re: Experimenting with menu code

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sun, 09 Jan 2011 11:09:48 +0100

Hi,

Am 09.01.2011 10:45, schrieb pete.goodeve@xxxxxxxxxxxx:

On Sun, Jan 09, 2011 at 12:57:01AM -0500, Ryan Leavengood wrote:

On 1/9/11, Clemens Zeidler<clemens.zeidler@xxxxxxxxxxxxxx>  wrote:


to just update libbe. Think thats much easier than setting up your own
build system


Yeah I'm not sure if you develop in Haiku Pete, but in my development
I just build libbe.so and copy that into the right place for testing
on my running Haiku machine (the same machine I'm compiling on.) If
only a few files change making a new libbe.so only takes 10 seconds or
so. Just be sure that if you happen to want to replace the system
libbe.so, you must delete it first (just copying it into place can
lock up Haiku.) But I'd recommend just copying one into ~/config/lib,
which should load before /boot/system/lib.


Ahh. Many thanks for those tips.  (Yes I do build in Haiku.)  That's
pretty much what I was doing with the USB-MIDI driver, but I was a bit
more worried about plugging in the whole libbe!  I probably wouldn't
have thought of using a config/lib copy...  Cool idea.
That is not necessary and is dangerous, since you may place a broken libbe.so there. Just put a link to your version of libbe into a lib folder alongside your test application. 


I really don't see how your code could replace code from libbe.so,
especially since you don't really have all that much control on how
things are loaded. But clearly it seems like something was messed up.


Yeah, it was odd.  Compiling the test program alone and using the system
lib works fine, but as soon as I link in the menu objects (code as yet
unmodified) I get garbage.
There is static code in libbe which might now be duplicated or missing looking from your code... or who knows what... :-) 


But either way it is good to see someone else looking at the menu
code. I think if a few of us take a look at it and spend a little time
it could be improved. Though I know Stefano put a lot of time and bug
fixes into it so we should definitely pay attention to how things are
done now and make sure any tests cover all cases.


I'm hoping I can get enough understanding to at least patch the annoying
click behaviour.  We'll see!


Stephan did mention he had played around with a BMenuTracker class to
consolidate the tracking code into one object. That would surely be an
improvement.


One thing I might ask the assembly about at this point.  I noted that
there was a comment in one of the tickets that Be's use of polling was
hampering things.  Would it be possible to extend SetMouseEventMask
with an option to *continue* mouse-tracking after Mouse Up (until
specifically cancelled)?  I'd think it would then be easier to rewrite
the Menu code to avoid GetMouse, and make things cleaner.  Just a thought...
Tracking happens from a different thread anyway. Where you feed mouse coords from is not actually relevant. Using GetMouse() is fine. But there is also a SetEventMask() which makes sure you receive mouse events outside your window and when the mouse is not pressed. It even works without the bugs of the BeOS implementation. A dedicated BMenuTracker class would be aware of the menu hierarchy and one tracking state that incorporates both mouse and keyboard control. I think the SetEventMask() solution is even borked, since then all submenus (each their own BWindow) would then all try to feed (the same) mouse coords to the same tracker. Probably easier if the tracker invoked GetMouse() on whatever menu it considers the currently tracked one. In fact, since tracking happens in the Track() method of the current menu anyway, this is not a problem and not something I would change, I'd just start by moving all the tracking related members into one place and use one instance and pass that to each submenu's Track() hook. 

Best regards,
-Stephan

Other related posts:

  1. Home
  2. haiku-development
  3. Archive
  4. 01-2011