On Mon, 26 Sep 2011, Oliver Eichler wrote: > 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.
It's my first hands-on contact with Lua as well, and I've never used QtScript either ;-) Admittedly I am no JavaScript fan at all, but Lua looks definitely more non-programmer friendly than QtScript to me, but that might be just my impression. I suppose QtScript is very well suited to make your application scriptable as a whole, i.e. adding a scripting interface to features you already have in the UI, but it is probably easy to expose more internal structures than necessary, causing compatibility issues in the future. This should be also seen from a users perspective: The language and the scripting environment must be easy enough to allow a non-programmer to understand and tweak filter scripts for his needs without unintentionally breaking anything. > 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. My specific use case is a "loop elimination" filter: When we are documenting bicycle trips for books and magazines I usually want to eliminate digressions, e.g. when we come to a city and stroll through the center before we move along, or if we decide to take another route after a few kilometers and drive back for whatever reason. There are surely many more specific use cases. Waypoint information should be also made available, so you can both filter trackpoints depending on waypoints (e.g. to keep certain digressions in the example above when there is a waypoint) and create or modify waypoints based on track data (e.g. to mark breaks or whatever). Occasionally it makes also sense to tweak Douglas-Peucker, BTW: We have a long straight road here with a moderately steep 40m hill, which gets mostly flattened out by the standard 2D-Douglas-Peucker, because it doesn't take elevation data into account ;-) > 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. Yes, the dialog looks a bit "historically grown" ;-) I am no UI expert, but I think the apply-this-or-that check box on each page at least not optimal. Oh, while we're at it: Contrary to the current filter implementation, Lua track filters are atomic. If something goes wrong in the middle of a Lua filter no data is modified, because a track where half of the data is modified is generally rather useless. > 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? Good questions ;-) To apply several filters you could use an effect stack like here: http://www.kdenlive.org/user-manual/reference-guide/kdenlive-074/main-window/docking-panels/effect-stack Input parameters and track splitting are definitely required. > 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? Sounds reasonable! Michael > 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 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
