Custom Commands

[scunz]

• [x] Create, change and edit custom commands (via a ConfigPage)
• [x] Save and load custom commands
• [x] Integrate global custom commands into main application menu
• [ ] Register context specific custom commands to their respective context in RM::RepoMan
• [ ] Execute the command itself
• [ ] Refresh views after command execution
• [ ] Add the result of the execution to a logging view.

---

Waiting for:

• [x] RM::RepoMan being finished (required)
• [ ] RefTree and RepoTree using context menus as provided from RM::RepoMan (required)
• [x] LogView (required)
• [ ] WorkTree View being based on RM::WorkingTree (Optional, this code can be adjusted to that later; Just omit everything WT related)
• [ ] Index View being based on RM::Index (Optional, same as for worktree)

[antis81]

@scunz Hm, I'd like to work on this branch, but it doesn't compile at present. I see no way to "know" the matching commits in depending modules. Instead of trying around to find the matching commit(s) where everything worked I'd simply rebase it onto development. Seems like a reasonable general method to solve this situation, what do you think?

[scunz]

Actually, I think of this branch as "waiting for further features" at the moment, so I'd request you to discuss what you want to change in advance.

As for not compiling; I'll have a look into that. Should be 20 minutes until I'm through with the Qt4/5 stuff for WebKit...

[scunz]

Also note: As long as Jenkins is broken, all of the nice automation is gone... We'll have to integrate commits into submodules manually... I will also take care of the current stage in a second. :-)

[scunz]

@antis81, YES, rebasing to development would have been the right choice in this case. I actually did that and force-pushed it here...

[antis81]

Also note: As long as Jenkins is broken, all of the nice automation is gone... We'll have to integrate commits into submodules manually... I will also take care of the current stage in a second. :-)

Yes, already notice that :). No Problem ( see PM -> unfortunately, this will probably not work for Jenkins ).

[antis81]

Actually, I think of this branch as "waiting for further features" at the moment, so I'd request you to discuss what you want to change in advance.

Actually I don't know yet :). I plan to look into the branch, find what might be missing and then put it in a task (the todo list like always :) ) or discuss it here.

[scunz]

Okay. So what is missing:

• [ ] Trigger per context menu on Ref/Repo-Tree or WD/Index View. => WD/Index View has to be rethought; Ref/Repo-Tree might get a completely new implementation depending on the outcome of the RepoMan stuff. Also this might require some changes in libHeaven.
• [ ] Execute refreshing after command execution => This is what RepoMan stuff is actually for.
• [ ] New View to show the Execution-Result. In my book, this conflicts with some of the RepoMan stuff. As I want to implement LogView in a similar way like it's done in Qt-Creator: One Window for different content.
• [ ] The execution itself. (This is actually one point where someone could work on)

[antis81]

@scunz Put your points to the top TODO list. We need some activation context to control to which menu(s) a command is visible. Do we have that already?

Other than that I plan to implement something like this in the menu:

• Default Menu Items

• ---

• Custom Commands Item -> Submenu "List of custom commands for the activation context"

[antis81]

@scunz Not sure how to proceed on this one. I think it is a good idea to wait for your RM changes first. Further I thought of moving the "context" part into libHeaven. One idea would be, to register a context within the hid file of the menu itself. Means something like that:

...
    ActionGroup CustomActionsRepo {
      CustomCommands {
        Contexts Repository, Global;
      };
    };

    ActionGroup CustomActionsSM {
      CustomCommands {
        Contexts Submodule, Global;
      };
    };

    Menu CtxMenuRepo {

        Action      Activate;
        Separator;
        MergePlace  RepoRootCtx;
        Separator;
        Action      Close;

        Separator;
        ActionGroup CustomCommandsRepo;

    };

    Menu CtxMenuSMRepo {

        Action      Activate;
        Separator;
        MergePlace  RepoSubCtx;

        Separator;
        ActionGroup CustomCommandsSM;
    };

The compiled "contexts" could be shown as available in the settings page. Maybe even with a descriptive, translateable text. What do you think? It is basically a raw idea though.

[scunz]

Are your action groups referring to macgitver/libHeaven#15? These are totally different things, actually: Just wrapping QActionGroup objects around Heaven::Action (Which was required to have radio buttons inside menus => which in turn was required for the switching logic in the new history tool bar).

However, I was thinking along this lines: When the RM is finished, every visible object will have a RM::Base object derivate. We will have to change the RepoTree and the RefsTree to acknowledge for that. And when we've done that, we can turn any of those two tree's QModelIndexes into a RM::Base. Now, consider this:

Heaven::Menu* RM::Base::getContextMenu() {
    Heaven::Menu* menu = MacGitver::repoMan().getContextMenuFor(this);
    menu->setActivationContext(this); // <- This doesn't work atm
    // because ActivationContexts must be
    // QObject-Pointers and I've removed QObject inheritance.
    return menu;
}

// and the hic:
Ui RepoMan {
    Menu CtxBranch {
        MergePlace CtxBranchMP;
    };
    Menu CtxTag {
        MergePlace CtxTagMP;
    };
    // and so on
};

// and again C++:
Heaven::Menu* RM::RepoMan::getContextMenuFor(RM::Base* obj) {
    switch(obj->type()) {
    case BranchType: return mmuCtxBranch;
    case TagType: return mmuCtxTag;
    // ...
    }
}

Actually, I already have some code prepared that extends this concept to Working Tree and Index. If I can get that done, we'll be having a really cool basis to build some features upon...

However, your post inspired me to some thinking. Give me a day or two. Your idea might help me solve some problems that I still see here...

[antis81]

Are your action groups referring to macgitver/libHeaven#15? ...

Yes, actually I misunderstood the QActionGroup mechanism. But fortunately you understood what I mean and set it in the right context :smile:. Two more topics I see here:

• As we know the available activation context providers at compile time, using some Context<T> template class rather than the "item-object" itself together with setActivationContext(const Context<T> &ctx) feels more convenient. What if we want to allow CustomCommands for a commit or a "branch label" within the history view? Means, the provider object does not necessarily inherit RM::Base.
• We should allow usage of item constants within a custom command (e.g.: $OID, $NAME, etc.). Maybe the above mentioned Context class could provide these by connecting a name to a class method (or a slot). Ok?

Hope this sounds plausible enough. Also, we need to rebase this branch on top of mgv/develop again in respect of your cmake cleanup ( sorry, I did a pull on the umbrella project :innocent: ).

[scunz]

MGV should make fetch definitively more prominent than pull ^^ Why don't you pull with --rebase instead? It is way more convenient.

As we know the available activation context providers at compile time, using some Context template class rather than the "item-object" itself together with setActivationContext(const Context &ctx) feels more convenient.

Still need to think more about that. Giving it directly from the hid has a charm on its own. But I'm not sure that this would be right.

What if we want to allow CustomCommands for a commit or a "branch label" within the history view? Means, the provider object does not necessarily inherit RM::Base.

Actually, we're having a "commit-cache" in Mod-History anyway. We could as well move that to the RepoMan and have it accessible everywhere. This would mean, that RM::Commit would become objects which are not all created at once, but lazy populated on demand. Well, this idea is good indeed: This would allow us to keep the commit cache when we have to redo the revwalk in history-view.... We just would revwalk and get the commit ids and then reuse the already populated commit objects from repo man (which would then contain the details rather than the cache in history view).

We should allow usage of item constants within a custom command (e.g.: $OID, $NAME, etc.). Maybe the above mentioned Context class could provide these by connecting a name to a class method (or a slot). Ok?

I'm not sure where to get those from. Another thing that needs some thinking. But what we could definitively do, would be to populate the usual GIT-environment variables... (Maybe add a checkbox for that inside the config page).

After all, this RepoMan thingie is getting very large - and there is no end in sight. Actually, this code should have been written as the first code for MGV. I'm tempted to just merge that code and go on incrementally from there.

[antis81]

I'm tempted to just merge that code and go on incrementally from there.

Think that's the best we can do :+1:.

[scunz]

@antis81, this Context Menu stuff is now in the RepoMan branch

[scunz]

Actually, you could rebase this upon the repoman work and just go ahead ^^

[antis81]

Ok, I'll rebase it there :).