On May 13, 2014, at 4:08 PM, Cristian Tibirna <[email protected]> wrote:
> 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. There’s even a task for that: https://bugreports.qt-project.org/browse/QTCREATORBUG-9141 I hadn’t thought about any automatism yet. And since actually documents are always “open” in all splits simultaneously, that couldn’t depend on which mime-types are currently shown in a split (because that’s a condition that does not exist :) ). But maybe it could be an option to automatically pull editors to a split if the mime type matches the currently shown editor in that split. In addition I would like to have shortcuts to “make the current document visible in the next/previous split instead of the current split (potentially opening a new split or window)”. So, when you e.g. “blame” a file, the blame opens in your current split, but you can easily and with little pain just “move” it to a different split. Br, Eike -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Qt-creator mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qt-creator
