Okay then, ... ...

[ciaobaby]

New servers commissioned, all clients migrated (finally) and the "invader repelling" systems are all set up and working nicely so I should have some free time to get back to my first love, which is programming, and to that end have forked and  cloned qBT, and I've got to say it might have benefited from some "road mapping" way, way back at the start, and I'm thinking in terms of defining UI colour schemes for the status bars etc.
Sledge if you know your way around that lot you have my admiration 'cause on first impressions, it looks like a jigsaw where every piece is identical in shape and there's no picture to work from. 

[hyperion1is]

Okay then,... you are working on a qBt project of your own. Should we expect 2 3.2 versions? One from you one from sledge? I got it right?

[sledgehammer_999]

These are some issues tagged for the respective milestone:
1. v3.1.10: https://github.com/qbittorrent/qBittorr ... state=open
2. v3.2.0: https://github.com/qbittorrent/qBittorr ... state=open

Of course you can work any other of the myriad of wishlist items in the bug tracker (or non-wishlist). One request though. Stay away from the WebUI code (c++/html/css/javascript). Another user is working on totally overhauling that code and he doesn't want us to touch that code. (it will interfere with merging if we do).

If you have something in mind and don't know where to begin looking, I'll gladly point you to the correct place of qbt code. Just tell me.

[ciaobaby]

[quote="hyperion1is"]
Okay then,... you are working on a qBt project of your own. Should we expect 2 3.2 versions? One from you one from sledge? I got it right?
[/quote]
Maybe, but I'll just get into some 'bug' fixing and the odd thing that "bugs" me (the confirm recheck dialogue being one of those things ) until I have QT & git worked out, as my usual weapon of choice is Geany and flying solo as a working method.

[sledgehammer_999]

[quote="ciaobaby"]my usual weapon of choice is Geany and flying solo as a working method.
[/quote]

Give info about your OS. Qt Creator is godsend. Simple example. You open the project file and it parses your whole project. Let's say that you open a huge .cpp file. And find a variable somewhere that you aren't sure from where it originated. Or if it is a class variable you want to look what other code touches/sets it/unsets it. All you have to do is right click->find usages. It will find all usages of that PARTICULAR variable even if there are other variables of the same type and name.
Also let's say that you see a function being called(or class function). Instead of searching its implementation you simply do right click->follow symbol under cursor and you instantly get transfer to the function implementation.

[ciaobaby]

OS is Mint 16

All you have to do is right click->find usages. It will find all usages of that PARTICULAR variable even if there are other variables of the same type and name.

A bit like  Borland's  Delphi (Kylix) in that respect then.
And yep I'll steer away from the webUI  

[sledgehammer_999]

Then all you have to do is go to the qbt source dir and issue "./configure" in order to produce the necessary files and check if you have all dependencies.
Then open qtcreator and the qbittorrent.pro file. The whole project should load now. It may ask you what kind of build you want to configure(debug/release) and where to build. Choose the "shadow build" option so you won't pollute the qbt src dir with .o files.

[Nemo]

Ciao in action ! Nice .

[ciaobaby]

Ok now I'm confused,

Forked -> https://github.com/qbittorrent/qBittorrent to -> https://github.com/chrishirst/qBittorrent, cloned the fork to my machine and version.pri file says 3.2.0alpha YET mainwindow.ui is missing "Add link to torrent" on the menu.
I am assuming that forking off the master repository SHOULD be up to date at least, or am I missing something?

And if the menu is different what else might be missing, github says "This branch is 0 commits ahead and 0 commits behind master" but that does not appear to be the case in practice

[sledgehammer_999]

Seeing here the commit history: https://github.com/chrishirst/qBittorre ... its/master it seems that the forking went bad. It didn't fork until the last commit.

This is easily fixable. Your local git repo will refer to your fork as "origin". "origin" is the alias given for your remote(forked) repo. And it is a way to identify the remote repo without pasting the full URL.
Now you can solve this, with the current flow.
1. Add an alias for the qbittorrent remote repo URL
2. Pull the official qbt's master on top of your (partial) local master.
3. Push your local master to your (forked) remote repo.

Instructions:
1. Open terminal and cd into your local git repo.
2. git remote add upstream https://github.com/qbittorrent/qBittorrent.git
3. git pull --ff-only upstream master
4. git push origin master

It will add the official git remote repo with the alias "upstream". You can choose a different alias. Also you can choose a different type of URL (eg ssh instead of https).
The pull will fail if your local branch contains commits not present in the official upstream. (--ff-only switch)
The push will also fail if there is a mismatch between your local repo and your remote repo.

PS: You'll use the same commands (pull/push) to keep your local repo current with the official repo. All local development should be done in separate branches in order to have a clean local copy of the official code and not constantly redownloading the master branch. So what happens if you branch off master, develop something locally but in the meantime the official master is advanced forward with new commits? You first switch to your master and update it as usual with the official master. Then you switch back to your developing branch. Now you normally want to merge the new commits and have your commits AFTER them. Not in between. Otherwise future pull requests might go badly. You do a "git merge master --rebase". This command will merge the master branch into your current branch and then replay your commits on top of it. If the new commits touch different files than your commits the replay/merging will go smoothly. If not you'll get merge conflicts and you'll need to use git mergetool to help you resolve them. (google on how to use and setup a mergetool for git).

[ciaobaby]

Sounds like a job for tomorrow with a clear head