Hi Michael,

I recently upgraded to Mavericks, and I'm having a bit of trouble with MoI v3 beta Nov-19-2013. The first thing I encountered is that the program startup time increased a lot-- to perhaps 30 seconds or thereabout. Second, sadly, multitouch control seems to have stopped working. And third, as has been already reported on the forum, multi-monitor behavior is buggy.

The first and third don't really affect me much, however the second is pretty important to me. If it isn't some sort of problem with my system, I would be happy to assist once again with the multitouch library. My final exam (literally the last one before graduating) is a week from now, so I should have some time after that.

Will

Hi Will, for the multi-monitor issue #3, see this post here on an operating system setting that you can change which should then work better:
http://moi3d.com/forum/index.php?webtag=MOI&msg=6337.3

re: long startup time, I seem to remember there was at one point a problem with wineskin leaving old prefs files around or something like that, which once they accumulated to a certain level could then slow things down. I thought that didn't apply anymore to the version that MoI is currently using but maybe it does. Check if you have a huge number of files in ~/Library/Preferences like 2543243142241.wineskin.prefs.plist (with the same last part but different prefix numbers) and remove them.

re: multitouch not working - that's the first I've heard of this problem, right now I don't have any clue about that, probably will need some help tracking that down.

Thanks, - Michael

Here's also a previous thread about slow startup:
http://moi3d.com/forum/index.php?webtag=MOI&msg=5858.1

- Michael

Hi Will, I installed Mavericks over here for testing. I can't repro the slow startup issue, so check out that info above about clearing out some possible old prefs files and see if that solves that issue.

The multi-monitor issues should be solved by changing that operating system setting under System Preferences > Mission Control - uncheck "Displays have separate Spaces" there (reboot needed for it to take effect).

I can repro that multitouch panning is not working. Multitouch zoom and double-tap for view reset seem to be ok though. I'll take a look and see if I can figure out what's wrong with panning.

- Michael

Hi Will, ok so the multitouch panning isn't working because the method for getting the number of touches isn't working anymore and is always returning 0.

This is for processing NSEventTypeBeginGesture:

fingersTouching = [[event touchesMatchingPhase:NSTouchPhaseAny inView:nil] count];


That leaves fingersTouching as 0 every time now, and that means no panning will happen because it does panning with 2 fingers touching and 3D view orbiting with 3 fingers touching.

I guess hopefully this is just an NSEvent bug that they'll fix up in a future release. There does not seem to really be anything else available for gathering up the current touch info...

- Michael

Hi Michael, sorry about being incommunicado for a bit.

I deleted the saved state files as suggested, which unfortunately did not help. I also noticed that MoI creates two saved states per launch (one almost instantly, then another one perhaps 15 seconds later) and upon exiting deletes only one (the second one). I launched/quit MoI a few times to verify that it is still accumulating saved state files. However, I noticed that of the bunch of saved states I deleted, most were from before I upgraded to Mavericks. Yet, the slow launch only started happening after I installed Mavericks. Also, I just timed it-- MoI takes just over a minute to launch. Gigs of free ram, processor cores near idle the entire time... Any ideas as to what else it could be?

Re. the multi monitor issue, that is not a workaround I'm willing to use. The new behavior is far preferable to me and more useful to my workflow. Luckily, I don't usually use MoI in a multi monitor setup, so it doesn't much matter to me.

I'll look into the touchesMatchingPhase issue; there's likely a temporary workaround.

Will

Hi Will,

> Gigs of free ram, processor cores near idle the entire time... Any ideas
> as to what else it could be?

Nope, no idea myself... Do you see any different behavior on the first launch versus subsequent launches? Over here the operating system seems to cache things or something and MoI launches more quickly after the first time.


> Re. the multi monitor issue, that is not a workaround I'm willing to use.

Ok, but I expect it's going to be a while before multi-monitor fixes get implemented in XQuartz. It seems to need some kind of fix at the operating system level before it's going to happen, so it will probably take some update to Mavericks itself combined with some unknown amount of time after that before the fix trickles down to MoI.

In the meantime the choices for the Mavericks multi-monitor problems are to either not use Mavericks, not use MoI, or to set that option to uncheck "Displays have separate Spaces". That will also solve some multi-monitor problems in other apps as well.


> I'll look into the touchesMatchingPhase issue; there's likely a temporary workaround.

I tried to do a quick look around about it but I wasn't able to find anything myself. I guess it's probably the part about inView:nil not working like it used to - I guess it's supposed to (and previously did) return touch information without regard to what view they were in, this seems to not return anything anymore.

- Michael

Hi Michael,

After some investigation into touchesMatchingPhase, I suspect the bug is very low priority if it is known at all; I wasn't able to find any bug reports online, so it appears we're the first ones running into it. I fiddled with it for a bit looking for a workaround, but haven't come up with much. As I see it, there are three options:

1) Ditch the finger count and use a modifier key to switch between pan and rotate. I've already hacked my dylib to do this as a temporary solution by commenting out the NSEventTypeBeginGesture and NSEventTypeEndGesture sections and inserting "fingersTouching = ([event modifierFlags]&NSShiftKeyMask ? 3 : 2);" above "if (fingersTouching == 2) {". While this solution is easy, I don't particularly like it because I had previously used the modifier key to scale the input up for situations where I wanted to move faster, and using multiple modifier keys at once is awkward.

2) On creation of a window, pass the window identifier/context to moi_touch. There may be a way for me to get the X11 window, and, from that, the NSWindow. At that point, I can add an NSResponder to the window which correctly overrides the various event handler methods (quickLookWithEvent, scrollWheel, touchesBeganWithEvent, touchesEndedWithEvent, etc.). I think this may be the "Right" way to do it; CGEventTap is fragile, considering we are currently using some magic undocumented stuff that is bound to break.

3) Write a native GUI, or perhaps go with a cross-platform GUI like wxWindows or some such. I don't know how much of MoI's code is windows specific, but I suspect that would be a lot of work.

Will

Hi Will,

#2 is problematic because I think that XQuartz does not actually create NSWindows at all, when I looked into how it created windows before it seems to be creating low level CGWindow objects which NSWindow seems to be built on top of.

re: #3 I'd like to do that at some point using Qt but yes as you suspected there is quite a lot of Windows specific code in MoI currently for all sorts of things like process handling, threading, timers, event handling, etc... It will probably take quite a while before I'll be able to convert all of that to any different system, that's the main reason why I'm using WINE in the first place. I think I will do some investigation of this path in the MoI v4 timeframe but it's definitely not something that can just happen right now though.

#1 isn't actually a full solution itself either, because the magic mouse thing also sends scroll events (with a begin gesture event as well) when you move your finger on it like a scroll wheel and those ones need to be allowed through as a scroll wheel event rather than doing panning or rotating at all - previously this was detected by seeing that there were no active touches associated with the gesture.

It seems kind of odd that there isn't any proper API to just return the current active touch information.

Right now I guess I'll just wait and see if it's a bug that will hopefully get fixed in a future OS release.

Thanks for looking into it.

- Michael

Hi again Michael,

Indeed you appear to be correct about #2; I verified by injecting code into XQuartz and calling [[NSApplication sharedInstance] windows], which failed to list client application windows. From browsing XQuartz code, I did see NSWindow being used, though I'm not sure in what way. The NSEvents being captured seemed to not have valid NSWindow references, so it's pretty conclusive that it's doing something else for client windows.

The situation for #1 seems to be the same as when we first looked into this: there is no known way to get device information from an NSEvent. The hasPreciseScrollingDeltas member function will differentiate a regular scroll wheel from a trackpad scroll, but since the magic mouse uses a touch sensor, it is indistinguishable from an actual trackpad (other than the number of fingers touching, but even then, I believe the magic mouse allows two finger scrolling as well; not sure how many fingers are reported via touchesMatchingPhase since I don't have a magic mouse). It is possible Apple attaches IOHID device information to the NSEvent in the various data fields (data1, data2, userData, etc.), but it would be undocumented and I haven't looked into it.

It seems #3 would be the way to go, though it's been a long time since I've used cross-platform UI kits, so I don't have much to add. IIRC, QT requires licensing fees for commercial use. Also, I remember wxWindows/wxWidgets being pretty good, and it's development looks to be active, but nowadays there are a lot of competitors which may or may not be better.

It a real shame the OS X input API is in such bad shape. I had hoped that the iOS input API (which is nice) would replace the API in OS X 10.9, but sadly it didn't. Hopefully Apple will get it together for 10.10.

Cheers and happy holidays,
Will

FYI, I've reported the touchesMatchingPhase bug to Apple, rdar #15734852.

Hi Will, thanks for reporting the touchesMatchingPhase to Apple to get it on their official bug list. Maybe that will help give it a better chance of getting fixed in a Mavericks update.

re:
> IIRC, QT requires licensing fees for commercial use.

This used to be the case prior to Qt4.5, but with the 4.5 release in 2009 they added an LGPL license that allowed commercial use of Qt without needing to purchase anything.


> Also, I remember wxWindows/wxWidgets being pretty good, and it's development looks to be
> active, but nowadays there are a lot of competitors which may or may not be better.

I evaluated wxWidgets back a while ago, but for my particular targeted use then of trying to use their WebKit integration I ran into an awful lot of instability in that particular area.

- Michael