Reorganize clone dialog

[antis81]

Depends on PR #35, which should be merged before this one.

• Move clone dialog (and menu action) to "Remotes" module.
• Reorganize clone dialog by using centralized ExpandableDlg.
• Rewire clone dialog to centralized ProgressDlg

[scunz]

fromNativeSeparators would be fitting better, wouldn't it?

[scunz]

Hey, @antis81,

as I'm progressing with everything here a fair bit, I need some code paths to do the actual testing.

Here's the steps that need to be done, in order to have a fully working centralised and not content-related progress reporting facility:

• Move ProgressDlg. It should be moved into libActivities (requires to rebase 35 on top of 37).
• Adapt to libActivities. Basically: There are real objects for Activity and Step. Further, the following things will be done under the hood for you:
  • Determine when to show the dialog
  • Determine when to hide the dialog
  • Tell the dialog that it has to be modal or stop being modal
  • Timed updates.
  • Deferred showing of the dialog and auto-dismissal.
  • Thread mashalling / Mutex protection / Object Lifetime
  • Managing mutable log entries. (Mutable, because the \r that the git server sends, actually means that we have to replace the last log line with a new one)
• After that, we'll need a 38 "Implement the CloneService"
  • Do we want to remove the crap from libGitWrap? If so, we'd have to do that first.
  • Otherwise, implement a not-operation-based non-asynchronous clone method in GW. (private: using setBackgroundMode; could be a starter...)
  • Generate Activities and Steps from within the CloneService.
  • Fill them up with non-asynchronous callbacks from LG / GW.
  • We need to create a dumb data container that transports the clone options from the dialog into the service.
• Then we can get back to 36. It still contains two topics:
  • Porting it to the new ProgressDlg
    • I'm afraid this code won't be necessary at all with libActivities: CloneDialog shouldn't interact with this whole progress-thing in the first place.
  • Pimp up of the Clone Dialog. I couldn't get my MagicDialog to do what I actually wanted it to do (I got it to expand/collapse widgets without adding further hierarchy nodes, but the sizing got wired...). So, I might get back to that later. For now, the Ui changes herein are cool enough to get them in. We should probably do the following:
    • Rebase 36 to development; omitting the commits in 35.
    • Remove everything from 36 that depends on 35.
    • The result could be merged into development, right now.
    • Then create a new PR, which does:
      • Remove all other code that deals with the Git::CloneOperation.
      • Fill the dumb data container
      • Kick off a CloneService and close itself.
      • Clone is not necessarily a background operation, so the service should set the Modality Required flag on the Activity.

Depending on a) your available time and b) your plans for the GitWrap Operations, I'd either take 38 myself and use that code to finish 37 - While you'd be finishing 35
Or: You'd change GitWrap so that the clone operation vanishes and take care of 38 to implement a clone service on top of that (It is basically the same thing as an operation in GW, just that the Services are better manageable) - At the same time I'd be finishing 37 and maybe port 36 on top of that.

[antis81]

Currently time is the least problem I'm worrying about. It's the question of organization.

Let me set your points into parts:

Part 1 - Move ProgressDlg to libActivities:

1. Rebase ngf/central-progress onto sacu/activities and leave everything else aside!
2. Move the files.
3. Setup a test environment to simulate a clone activity/service. Leave out the clone dialog for now and add it after everything else is in place.

Part 2 - Implement the CloneService:
Setup a new PR.
Note: I prefer the approach with the synchronous clone method in GW. But it might be better to completely realize it in libActivities. We'll see ...

Part 3 - Rebase PR #26 onto libActivities
This contains the menu structure for clone, fetch, push, ... and is mandatory for the clone dialog thingy to work.

Part 4 - Adapt #36 to libActivities

1. Rebase onto libActivities.
2. Remove the obsolete code and adapt to libActivities.

Btw.: It is natural, that bigger chunks of the code become obsolete in the current clone dialog implementation. Don't hesitate to remove/replace those.

Depending on a) your available time and b) your plans for the GitWrap Operations, I'd either take 38 myself and use that code to finish 37 - While you'd be finishing 35
Or: You'd change GitWrap so that the clone operation vanishes and take care of 38 to implement a clone service on top of that (It is basically the same thing as an operation in GW, just that the Services are better manageable) - At the same time I'd be finishing 37 and maybe port 36 on top of that.

Q: Do you like to eat 🍦 or 🍭 better?
A: Yes! 😄

No, seriously. I'd finish the dialog first as much as possible, but as the service is a basis for that, I think it is better to finish that first.