Closed rnwgnr closed 4 years ago
That is a good idea. I can't merge this PR, because I already implemented such feature on my local branch. It includes ability to add comments and images on Android client. I have been testing it for some time and just need some more time to make it public. Thanks anyway!
It's a pity that you keep develop branches locally and work is done twice because nobody knows you already started working in it... :(
Sorry! I usually don't have time enough to make proper documentation, changelogs, roadmaps etc. Even if I publish my WIP branch it will be difficult to find new features without proper documentation. Apart from new "comments and images" feature I am in a process of refactoring javascript UI to make it maintainable and testable. As soon as I have it working again I will push it to development branch.
Hi, i can totally understand that developing an open source project in your spare time is just a hobby which has to step back from time to time, no need to be sorry about that. I've published freeware a few years ago (before the idea of opensource and collaboration got spread widely), so i know for sure that time is very limited to work on such software. You started to implement something and gave other the opportunity to use it without charging anything, thats way more than most people tend to do.
From my point of view develop branches are exactly this and there's no need to have a documentation or readme in them at this point. But i think it's useful to have them in the public repo. People can have a look at what you are working on, pick things up to come back with (hopefully usefull) PRs or simply give feedback or help testing. If you're using feature branches with a understandable name it's even easier to get in touch with the changes. Currently the project is rather simple (which i really like), there are only a few places one have to look at when searching for specific implementation. Thats how a started to get familiar with the current code and made some small additions.
I'd like to make some adjustments to the gpx import as well, but i guess that has changed in your develop branch as well and it's not useful to do more additions on my side.
You are completely right. I will push my development branch soon. I usually publish my feature branches, but this time I started playing with some ideas I wasn't even sure I would use. As this is a hobby project I am more interested in exploring new fields than just creating efficient software based on well tested patterns and frameworks. Which doesn't mean I don't care for its quality and performance, as I am active user of µlogger myself. Reworking the code to be modular and testable is a must, if I want to accept PR's. Also I am thinking about introducing plugins scheme, because I don't want the main system to grow beyond basic functionalities. But this would be a next challenge.
This PR is currently a "work in progress" for discussion.
In the current version, the comment-field of a track is imported from a gpx file (gpx->metadata->name), but it never gets exported. So i added this field to the export (same xml attribute as import).
I'd like to do some additional adjustments, especially the handling of metadata->name and metadata->description. My unterstanding is that metadata->name should be an alternative to trk->name if the later is not set and the "comment" should use metadata->description instead. Should i add these changes to this PR or do you prefer a new one to keep PR as small as possible?