-
Notifications
You must be signed in to change notification settings - Fork 1
Custom Commands #65
base: development
Are you sure you want to change the base?
Custom Commands #65
Conversation
@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? |
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... |
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. :-) |
@antis81, YES, rebasing to development would have been the right choice in this case. I actually did that and force-pushed it here... |
Yes, already notice that :). No Problem ( see PM -> unfortunately, this will probably not work for Jenkins ). |
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. |
Okay. So what is missing:
|
@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:
|
@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. |
Are your action groups referring to macgitver/libHeaven#15? These are totally different things, actually: Just wrapping However, I was thinking along this lines: When the RM is finished, every visible object will have a 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... |
Yes, actually I misunderstood the QActionGroup mechanism. But fortunately you understood what I mean and set it in the right context 😄. Two more topics I see here:
Hope this sounds plausible enough. Also, we need to rebase this branch on top of |
MGV should make fetch definitively more prominent than pull ^^
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.
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
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. |
Think that's the best we can do 👍. |
@antis81, this Context Menu stuff is now in the RepoMan branch |
Actually, you could rebase this upon the repoman work and just go ahead ^^ |
Ok, I'll rebase it there :). |
ConfigPage
)RM::RepoMan
Waiting for:
RM::RepoMan
being finished (required)RefTree
andRepoTree
using context menus as provided fromRM::RepoMan
(required)LogView
(required)WorkTree View
being based onRM::WorkingTree
(Optional, this code can be adjusted to that later; Just omit everything WT related)Index View
being based onRM::Index
(Optional, same as for worktree)