Reorganize clone dialog

[antis81]

This PR is INVALID and closed. See PR's #35 and #36 instead.

[antis81]

FYI: The "clone" dialog is now based on the central ExpandableDlg and the central ProgressDlg.

[antis81]

Here's a screenshot of current state:

⭐ Note, that we now actually report the checkout progress for non-bare repositories as well.

@scunz Can you please review this? The implementation is a draft of the structural concept. The dialog provides no predefined slots by itself. I.e. an "onTransferProgress(...)" slot has to be implemented outside the dialog. Progress is reported to the dialog via "setPercentage(activity, step, percentageRatio)". The single steps have no "ordered state" => When progress is reported, it will be visible.

Progress update happens through a timer (default interval: 500ms), because we need to cumulate the values of each single step into the total percentage for each activity. Ding this on each "setValue" would produce an O(n^2) or even O(n^n) runtime behaviour, while the timer approach is always linear.

[scunz]

In general, the concept is okay. But I can see lot of trouble ahead merging this. Mostly due to the fact that this PR isn't a clean implementation of just one thing, but it rather a) moves stuff around, b) changes the clone dialog, c) introduces the new progress concept.
Some of these commits will clash with the repoman branch, of which I think is the only sane way forward.

So, I'd suggest to do the following:

• I will create the Activity classes this weekend.
• You should separate everything from this PR that deals with the CloneDialog
  • Properly provide a convenient way to deal with that expand / hide feature (I can setup a demo of what I've in mind). Get this setup as a PR in its own right and have it merged into development (Then rebase repoman to that)
  • Change the clone dialog, so that it makes use of that (Actually, should change all dialogs that we have so far). Do this in a separate PR for each dialog against development; get them each merged and rebase repoman
  • While doing anything of that, don't be afraid to remove any functionality from the dialogs. It's easier to rebase repoman against a UI that has no functionality than to rebase against a moving target that tries to keep working... The new implementations are likely not to be compatible and we don't lose anything as we can always view the history...
• This brings us into a state where the UI in development looks like we want to have it but without functionality.
• You can then setup two branches from the tip of repoman (and keep them regularly rebased to the tip of repoman)
• These two branches would be:
  • CloneService:
    • Create a data container to store all input data into the clone service.
    • Change the Clone Dialog to fill the CloneServiceInput.
    • Implement the clone service (Emitting all the required Activity into the Activity classes)
  • ProgressReport
    • Implement a ReportProgressDialog based upon this draft (located in the core)
    • Have it triggered from within the core itself.

[antis81]

You should separate everything from this PR that deals with the CloneDialog

Damn, I knew this would happen ... This PR is in a messy state I know. However, I just pushed a new branch ngf/central-progress -> the new PR #35 now reflects this topic and just contains the changes for the very progress dialog itself.

I need to do further cleanup here (rebasing and stuff) to separate the changes. I'll report back when it's done.

[antis81]

This PR was split and is handled in #36.