On Tuesday 13 May 2014 11:14:10 Tobias Hunger wrote: > On 12.05.2014 18:31, Cristian Tibirna wrote:
[...] > > I have 2 displays (yay!) and I use to open a secondary QtCreator > > editor(separate window) in the second display. If I hit Alt+G, Alt+B in > > one > > editor, the git-blame's output is sent to the other window/frame (the one > > which doesn't have the focus). Now, if in the blame I click one of the > > revision numbers, the corresponding git-diff appears in the original > > (first) window. This, IMHO, breaks the rule of least surprise. [...] > How would you think about your use case if you had three splits (e.g. > you buy your next monitor and wire it up)? Then the text would be on the > first, the git blame output on the second and the git show output on the > third. Wouldn't that again be as expected then? Well I guess that would depend. If I edit in the central screen, have git blame pop on the right screen then git diff in the left screen, I'd see it would still be "suboptimal". I should perhaps underline that yes, I get the logic of opening new editors in another split. Yet for the vcs editors, I don't really see the necessity. When I open "git blame", I don't really need the source code editor right away. I anyways have the code *in* the "git blame" editor. (I agree that this is a bit more ambiguous for "git show" though...) (All this remembers me some irc chats long time ago (in another century... in another millenium even), when we, Sirtaj Khan[1] and I, were jokingly designing "focus follows mind" for KDE's window manager.) > We have some "InNextSplit" variants for some commands like > "followSymbol" and some more. Maybe we need to generalize that so that > we have similar options for all commands that open editors. That way you > could decide which variation you prefer. You could either trigger > "gitShow" or "gitShowInNextSplit" based on the current situation or just > assign your key bindings in such a way that your preferred actions are > the ones that are trigged by the key sequences you are used to. I think this (or something like it) is what I was getting at, with my initial message. > Somewhat unrelated to the key bindings: I have a personal wish list > items for a long time now: Being able to always have headers in one > split and sources in another (next to each other on one monitor in my > setup). One approach for that to work could be to have splits that > "attract" certain mime-types. So all editors opened with documents of > that mime type would by default end up in the split most attractive to > that mime-type. > > Could something like that work for you? Basically you would have to set > up one split attractive to VCS-relevant mime-types and all the editors > triggered by the VCSes end up there. Yes indeed. This would be even more useful. It would eliminate almost completely the aforementioned surprises. It might be even rendered automatic, I guess (perhaps also this automatism configurable -- on/off). Once a "mime-type" gains a "split" it renders it automatically selected for same. > > Let's assume you have splits A and B with B being attractive to VCS > editors. So if you trigger git blame in split A, then git blame output > would end up in split B. Triggering git show there would have that > output in split B, too. That is what I understood you to want. Exactly. > But if > you trigger git blame in split B, then that would also open in split B, > covering the editor you were just working with. That in turn does not > seem to be what you want. Well, if I understand myself well enough, it _would actually be what I want_, if this second scenario is consequent to the first. It would have some sort of consistency: "ah, ok, all git blames get opened here". In conclusion, I believe your idea of mime-type-attractive splits would be very useful. And the beauty of it is that it would be highly predictive and configurable. And optional. Thanks. This is constructive. -- Cristian Tibirna KDE developer .. [email protected] .. http://www.kde.org _______________________________________________ Qt-creator mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qt-creator
