View Issue Details

IDProjectCategoryView StatusLast Update
0001477FreeCADPatchpublic2014-03-18 10:49
Reportermauriz Assigned Towmayer  
Status closedResolutionfixed 
PlatformlinuxOSKubuntuOS Version12.04
Product Versiontrunk 
Summary0001477: Spaceball becomes uncontrollable for large FreeCAD Documnets on X11 (spacenav)
DescriptionWhen I load a large Document, my spaceball becomes uncontrollable. I use spacenav on Kubunto 12.04.
Steps To ReproduceExample document: "Twin Cylinder Steam Engine Model" of ppemawm (

After a spacball input action, the object continues moving on the screen (up to several seconds).
Additional InformationIt appears that the window system event queue is flooded: The events are faster generated than they are consumed by FreeCAD.

Possible solution for X11 using spacenav:
If FreeCAD is busy, the motion data of the incoming events are added up. When FreeCAD is ready, a Spaceball event is generated. To detect a flooding situation, a self addressed event is sent through X11 (see attached patch)

At least on my system the patch is working perfectly.

Comments and inputs are welcome.

TagsNo tags attached.
FreeCAD Information



2014-03-16 19:36


patch.txt (Attachment missing)


2014-03-17 08:51

administrator   ~0004462

Great! I'll send a message to one who has a space mouse too. If there it also works we will add it.

Many Thanks!


2014-03-17 08:52

administrator   ~0004463

Reminder sent to: tanderson69

Hello Thomas,

since you also have a space mouse can you please verify this patch?



2014-03-17 14:38

developer   ~0004464

I have noticed this problem also, but never looked into it. The patch does fix the continued motion problem. Thanks.

Don't we have this problem on other platforms also? It would be nice if we could address this inside Qt or coin somehow instead of the native windowing system.


2014-03-17 17:38

reporter   ~0004465

Thanks a lot for the quick feedback.

It would be great if someone implemented an operating system independent solution. First I tried also, but I could not come up with a solution without moving the screen updates to a separate thread. This is a task I don't dare to start with...



2014-03-17 18:27

developer   ~0004466


I agree with not moving into a threading solution. I am curious as to what you tried. I had to 2 quick thoughts.

1) storing or posting or ignoring values based upon QCoreApplication::hasPendingEvents().

2) Mostly X ignorant here, but isn't there a timestamp for the xevent generation? Maybe test event generation time vs processing time in view3d handler.

I haven't looked into these much, so they might be silly.

IMHO: At some point in this event "lag" it wouldn't bother me if the events didn't get accumulated. I find it irritating when the display catches up and all of the sudden the model is off the screen. Don't know if it would be possible to find a "sweet spot" for the cut off between accumulating and ignoring.


2014-03-17 19:13

reporter   ~0004467


no idea is silly, ever.

1) QCoreApplication::hasPendingEvents(): Unfortunately, there are other events originating from the window system. QCoreApplication::hasPendingEvents() returns quite often 'true', even if FreeCAD has no problem to catch up with the incoming spacenav events.

2) timestamp: I can't remember to have read something about a timestamp in the documentation, neither for the XClientMessageEvent (spacenav) nor for the XEvent. Did I miss something? Can you give me a hint?

IMHO "cut off between accumulating and ignoring": Do you have an example Document where this is a problem?
Currently, the feeling of the spaceball navigation is consistent: Lets say, that for a given spaceball manipulation, the model jumps off the screen. Then, with the same manipulation, a model containing a cone only would jump as far ...

If we add a cut off, it should be adjustable on the spaceball configuration page (it is a matter of taste). What do you think? Should I prepare an additional patch for that one?


2014-03-17 20:17

developer   ~0004468

I figured as much with the "hasPendingEvents()"

It looks like the "timestamp" is a spnav thing not a "X thing"(spnav:event.c:135). Time in between dispatched events. I suppose we could try to keep track of this timing and do something accordingly. not sure it is worth it though.

No I don't have a document that shows what I was getting at with the "accumulation vs ignoring". This would be more with long waits and an impatient user. I was thinking that by skipping we could fix that problem also, but not worth too much effort. I lived with it inside UG. Yes your patch provides a consistent movement.

I say we merge this and maybe visit the cross platform thing again when somebody on windows starts complaining. Thanks again.

Related Changesets

FreeCAD: master 490f0417

2014-03-18 11:27:52


Details Diff
+ fixes 0001477: Spaceball becomes uncontrollable for large FreeCAD Documnets on X11 (spacenav) Affected Issues
mod - src/Gui/GuiApplicationNativeEventAware.cpp Diff File

Issue History

Date Modified Username Field Change
2014-03-16 19:36 mauriz New Issue
2014-03-16 19:36 mauriz File Added: patch.txt
2014-03-17 08:51 wmayer Note Added: 0004462
2014-03-17 08:52 wmayer Note Added: 0004463
2014-03-17 14:38 tanderson69 Note Added: 0004464
2014-03-17 17:38 mauriz Note Added: 0004465
2014-03-17 18:27 tanderson69 Note Added: 0004466
2014-03-17 19:13 mauriz Note Added: 0004467
2014-03-17 20:17 tanderson69 Note Added: 0004468
2014-03-18 10:49 wmayer Changeset attached => FreeCAD Master master 490f0417
2014-03-18 10:49 wmayer Assigned To => wmayer
2014-03-18 10:49 wmayer Status new => closed
2014-03-18 10:49 wmayer Resolution open => fixed