Hi Michael, cool idea, that kept me thinking the whole weekend. As tracks are the most complex elements in the GPS family and users have more than a sane amount ideas how to tweak them, providing a script interface is a logical step forward.
I never heard of Lua, but the integration looks pretty easy. I never used QtScript either, thus I can't tell what's the better choice. Helmut's opinion might count. too, as he has to integrate Lua into the Windows build. These 3rd party libs sometimes develop to quite a pain in the ass. However there is a Windows binary on the Lua homepage. Probably it's pretty easy. But the script language in detail was not part of my thoughts this weekend. It was more about how to integrate that stuff from a users perspective. And about the possible use cases. If it is just about a Douglas-Peucker filter we could do easier :) The longer I thought about it the more I questioned the current filter dialog. Wouldn't it be better to have that dialog in another tab in the track edit tab widget? And why not using that script thing for all filters? And is the current filter UI really good. I mean in the perspective of "do the users really understand how to use it?" After all that dialog grew, as many parts of QLGT, without a real vision on how it should look like in the future, resulting in a bit of a mess. That new dialog could supply the current filters as predefined scripts, that could be used as example for own ones. But how to expose them to the user? As script files? No. As tool button? As combobox? Hm. What if I want to apply several filters like weeding out points and smoothing the profile? And what about cutting the track into pieces and applying those filters? And what about filters that need user defined input parameters? A lot of questions and no concept so far. At least not in my head :) But I definitely want to give that idea a chance. First we should agree on the script language. I do not have any strong opinion on any of them[1]. If it comes to user parameters QtScript might be the better choice. But as I know nothing about Lua I can't tell if it can wrap the Qt API, too. Next I would suggest to add that additional tab in the track edit dialog and to start implementing a better track filter UI. For the next releases this can be in parallel to the current track filter dialog. If it supersedes the old dialog the old one will be removed. What do you think about that? Oliver [1]However I do agree that Python is too much effort to integrate. I do that occasionally. -------- Original-Nachricht -------- > Datum: Sun, 25 Sep 2011 21:19:11 +0200 > Von: Helmut Schmidt <[email protected]> > An: [email protected] > Betreff: Re: [Qlandkartegt-users] User definable track filtering? > Hi Michael, > > I like it, sounds really cool! > > Helmut > > Am 2011/09/23 23:55, schrieb Michael Klein: > > Hi! > > > > I think it would be really nice to have the possibility to add some user > > definable track filtering mechanism without the need to hack around in > > CDlgTrackFilter and compile the whole thing from source, but some > > interpreted scripting language instead. > > > > Compared to e.g. Python, Lua is embarrassingly easy to embed, so I made > > a quick hack that adds a "Lua" page to the track page, where you can > > simply paste your Lua filter script and execute it. Obviously the > > attached hack isn't ready for prime time yet and leaves much to be > > desired on the UI, but it's enough to play a bit around and check what's > > possible. > > > > The track data is exposed to the Lua interpreter through the single > > global array "track". Note that array elements are, by convention, > > counted from 1 instead of 0 in Lua. Currently only a subset of the track > > point data is exposed: lat(itude), lon(gitude), ele(vation), flags and > > timestamp. > > > > Attached is also a simple implementation of the Douglas-Peucker > > algorithm in Lua. Filtering a track with 3000 points takes only a few > > seconds on my dated G4 Powerbook, and it seems most of the time is > > actually spent in track.rebuild() *after* the Lua work. So performance > > is IMHO no showstopper. > > > > Opinions? > > > > Regard, > > Michael > > > > ------------------------------------------------------------------------------ > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2dcopy2 > _______________________________________________ > Qlandkartegt-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qlandkartegt-users ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Qlandkartegt-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qlandkartegt-users
