Qt 5.3 should be fine, too. Bas sent patches to make it work. Personally I like qtcreator. But that is a matter of taste. KDevelop or CodeLite are probably fine, too.
You already forked the repository. That is the correct way to do it. You keep the fork private. That is fine, until you do a pull request. At that point I would ask you to give me and Christian read access. I recommend to use TortoiseHg as GUI to Mercurial. Generally there are two stages. With pull and push you get changes from a remote repository or you send changes to a remote repository. With update and commit you update your local repository to a revision and you commit new changes. Use push to send several commits to the Butbucket repo. Bitbucket will tell you when your fork is not in sync with the original repository. You need to sync, pull and merge with your local changes. When done commit and push. One you think you are done you initiate a pull request at Bitbucket. This will be reviewed. You will commit new changes and push them. These changes will show up in the pull request. If everything is settled we will aprove the pull request and merge it into the main repository. A clone is just a local copy of the repository to work on. A fork is a standalone repository of another one. You made a fork in Bitbucket and you have a clone one your harddrive. The easiest way to use IRC is the Web interface linked in the Wikis support section. It's fast for step by step instructions. But you can use any other media as well. HTH Oliver Am Mittwoch, 13. Juli 2016, 01:00:10 schrieb Wolfgang Rosner: > Am Tue, 12 Jul 2016 13:11:10 +0200 > schrieb Oliver Eichler <[email protected]>: > > Hi Oliver, > > OK, I think I understand the basics of the data structure. > This looks promising. > I hope a few lines of copying the "name" property from wpt_t to > rtept_t / and keeping the name on edit might do the first part of > the job. > > > > your building instructions here > https://bitbucket.org/maproom/qmapshack/src > recommend qt 5.4 > > debian jessie only offers > qt 5.3.2+dfsg-4+deb8u1 > and this is what the last QMS 1.6.2 displays, also. > > > does this hurt? - give it a try... > > after some fiddling with missing packages, > one of my consoles shows > Linking CXX executable ../bin/qmapshack > [100%] Built target qmapshack > - looks like I have successfully compiled :-) > > what happens if I concurrently run QMS from debian installation and > from fresh build? will they conflict? use same paths? > > > > My next idea is to run QMS in a decent GUI debugger and try to > reproduce & understand the example data I used to produce the issue > screen shots. Watch the variables on the fly. > > Can you recommend a debugger? > I'd prefer something available as debian package. > But it MUST be able to dig down into QMS data structure. > > > And have a look here: > > > > https://bitbucket.org/maproom/qmapshack/wiki/DeveloperCommitCode > > Hm, I have worked (little bit) with SVN and git so far. > I followed your building instructions, so I have a working copy > (clone, right?) of your cutting edge branch (or whatever it is called in > hg) on my machine, right? > > However, I want a fork to fiddle with it - both in bitbucket and > locally, right? how do I get this? > > What's the difference between clone and fork? > Do I need a hg tutorial to read? > > > If you need help on that use IRC to contact us. My IRC client is > > usually active on working hours. But I might need some time to check > > it. > > Sounds good, but I've never done IRC in my live. > I only know it from my kids, and from course participants who got bored > by my lessons.... ^^ probably because you bragged about unnecessary stuff too long ;) > Well, the the real problem I think is that my work hours are not in sync > with "normal people's" work hours. > > I'd prefer the asynchronous email, if you don't mind. > Maybe we switch to private email to avoid clobbering the list with > silly questions like those above. > > Maybe we can even switch to German or Bavarian or Upper Palatinean ;-) > then? ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev _______________________________________________ Qlandkartegt-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qlandkartegt-users
