Hi All, Thanks for the feedback.
[Mark wrote: I personally would rather just link against the 3dconnexion library directly.] Although the Microsoft library in question TDxNavlib.lib is a simple stub which could be open sourced it effectively invokes HMODULE h = LoadLibrary(“TDxNavlib.dll”); where TDxNavlib.dll will not be open sourced and would represent under my understanding an infringement of the open source license, unless KiCAD were to add an exception for it. It's the same lib used on the mac. The websocket approach is, as Jon mentioned, so that there are no new libs to link against, although it does pose issues which wouldn’t exist if we could link against the lib. The proposed loopback websocket interface is very similar to the implementation used to service web applications for example OnShape – there are some samples in the 3Dconnexion v4 SDK if you want to get the basic idea of what the intension is – there its javascript, here it would be C++. Previously we had been using websocketpp, which we have moved away from. @Jon: Thanks: Sending events to the main thread - is exactly what I need. I looked at [2] below. The requirements lined out by Wayne seem doable. 3Dconnexion already has an extensive library of motion models, UI feedback and button mappings implemented in TDxNavlib.dll which can be selected by the user, so I don’t think going to low level HID of each OS (again) etc. is something 3Dconnexion will want to do. Markus From: Mark Roszko <mark.ros...@gmail.com> Sent: Thursday, February 25, 2021 3:38 PM To: Jon Evans <j...@craftyjon.com> Cc: Markus Bonk <markus_b...@3dconnexion.com>; kicad-developers@lists.launchpad.net Subject: Re: [Kicad-developers] Code execution context On another note, I personally am not a fan of websockets usage locally on Windows. In corporate environments there's going to be hell with security software interfering and in general it's fragile. I personally would rather just link against the 3dconnexion library directly. We have the MSVC builds now, we can compile against MSVC built libraries no problem. MSYS2 builds would just remain without it. But just my opinion on this. On Thu, Feb 25, 2021 at 9:32 AM Jon Evans <j...@craftyjon.com<mailto:j...@craftyjon.com>> wrote: That is a good point Mark, we could either have this behind a flag so that it only gets enabled/compiled with new-enough Boost versions, or investigate a different websockets library. I'm not sure the overlap of 3dconnexion users and 18.04 users is large enough to rule that approach out, at least if there are no other issues with Beast. -Jon On Thu, Feb 25, 2021 at 9:23 AM Mark Roszko <mark.ros...@gmail.com<mailto:mark.ros...@gmail.com>> wrote: * Boost 1.65 being the version Ubuntu 18.04 LTS currently has and are committed to support until EOL. On Thu, Feb 25, 2021 at 9:19 AM Mark Roszko <mark.ros...@gmail.com<mailto:mark.ros...@gmail.com>> wrote: Markus, We currently require support for a minimum of boost 1.59 due to Linux distros lagging behind. boost/beast is not a viable option as beast did not appear in boost until 1.66. From some offhand sounding out we may be able to bump the minimum to 1.65 but that doesn't help :/ Regards, Mark On Thu, Feb 25, 2021 at 9:00 AM Jon Evans <j...@craftyjon.com<mailto:j...@craftyjon.com>> wrote: Hello Markus, This is exciting news, as some of our users are also big fans of 3dconnexion products[1] Others have looked in to what it would take in the past, but there were some questions about the need for proprietary drivers on some platforms[2] It sounds like this websocket interface is a new approach that doesn't require any additional libraries for KiCad to link against? Does the hardware use some other daemon process to bridge between the device driver and websockets? As you may know, KiCad uses wxWidgets as a framework, so you probably want to plug in to the wx event loop on the main thread. There are some guidelines on this in their docs[3]. You probably want to check out ./common/view/wx_view_controls.cpp to see how existing input events are handled by the 2D canvases. I guess your new code would hook in here somewhere, and provide additional event handlers to manage the data from the 3D device. Your communication thread should be able to post wxWidgets events to the main thread and then we can consume them here. By the way: although the wx docs use wxThread, I think this general concept should work with C++ standard libraries threads just fine. The documentation for wxEvtHandler::QueueEvent may also be useful[4] Hope this helps! Best, Jon [1] https://gitlab.com/kicad/code/kicad/-/issues/4951 [2] https://lists.launchpad.net/kicad-developers/msg29464.html [3] https://wiki.wxwidgets.org/Inter-Thread_and_Inter-Process_communication#Sending_events_to_the_main_thread_-_wxWidgets_3_only [4] https://docs.wxwidgets.org/3.0/classwx_evt_handler.html#acffd03bf407a856166ea71ef0318b59a On Thu, Feb 25, 2021 at 1:47 AM Markus Bonk <markus_b...@3dconnexion.com<mailto:markus_b...@3dconnexion.com>> wrote: Hi, I am currently investigating adding support for 3D input devices to pcbnew. The plan is to use a websocket interface (boost/beast) to communicate with the 3D device. Effectively the communication runs on an extra thread. Somewhere the event code will need to switch to executing on the main thread. One way of achieving this on say win32 might be to add functors to a queue post a message to a message window handler in the main thread which empties the queue and invokes the functor. Is such a mechanism already in place in KiCAD? What is the KiCAD recommended solution to the issue? Thanks -Markus ________________________________ Markus Bonk Senior Software Engineer [cid:image001.gif@01D70C16.AACAF300] Clarita-Bernhard-Str. 18 81249 München Germany markus_b...@3dconnexion.com<mailto:markus_b...@3dconnexion.com> www.3dconnexion.com<http://www.3dconnexion.com> Geschäftsführer: Antonio Pascucci Sitz der Gesellschaft: München Registergericht: München HRB 99232 This email and any files transmitted with are from 3Dconnexion GmbH. The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this email is received in error, please contact 3Dconnexion GmbH by calling +49 89 8974542-0 and then delete it. Please note that neither 3Dconnexion GmbH nor the sender accepts any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. Any opinion expressed in this email are those of the individual and not necessarily those of 3Dconnexion GmbH. 3Dconnexion GmbH processes and stores for commercial purposes your personal data, collected upon your consent, in accordance with its privacy policy available at https://www.3dconnexion.eu/privacy.html, which has been drafted in accordance with Regulation (EU) no. 679/2016 and all applicable local data protection laws and regulations of the countries where the company operates. To revoke your consent or exercise all your rights with regards to personal data, please contact us at priv...@3dconnexion.com<mailto:priv...@3dconnexion.com>. _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net<mailto:kicad-developers@lists.launchpad.net> Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net<mailto:kicad-developers@lists.launchpad.net> Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp -- Mark -- Mark -- Mark
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
