[Qt-creator] Qt-creator Digest, Vol 8, Issue 32

[Paulo Silva]

>> I wouldn't say misplaced. The reason I placed them on every project
>> cell on the tree view is because when I work with several projects,
>> ex: several libs + 1 app that uses those libs, if I want to compile an
>> inactive project I need to right click and select the build option.
>> Sometimes I wish I had a button just for that.
>
> I'd say that navigating in the project tree to find the corresponding project to press the build button is not great either.
> Don't use the project tree to set the active project, use the "Target Selector" (the button above the run/debug/build buttons, or Build > Open Build/Run Target Selector).

Personally I think that button just makes it harder to select the
build. Get rid of it, in exchange for a better way of conveying the
options it hides is almost a must in my opinion. hehe.


>>> 3. IMO tabs rapidly become unusable while number of open files grow; however
>>> I rarely use "Xcode-like" outline in editor toolbar and prefer sidebar outline, so
>>> place in editor's toolbar could be used for something else tabs for recent 2-3 files.
>>
>> I also agree. But since the open files widget is still there, the
>> current usability would not change.
>
> What benefits would tabs bring over the open documents pane?

Not over, but replacing it. No fat here. And the answer is why not?


>> Using a scheme ?-l? chrome then I would say it would be incomparably better.
>> In chrome the tabs don't go out of screen (could be a layout option),
>> they are just resized (all to the same size).
>
> Comparing an editor to a web browser doesn't help finding a good solution... the use cases are just too different, but one could argue that a tab that doesn't show a sensible name to see what's behind it is even useless in the browser case.

I could argue I would probably like it. That's why I asked "is it
possibly to make it as a plugin".


>> Since the rest of the app is really slim looking, it's actually easier
>> to get a lot of tabs in there.
>
> Hm, so why destroy the slimness by cramming tabs there? ;)

Quoting me "Not over, but replacing it. No fat here."


> Putting the line/column information into the status bar under the editor can be pretty far away from the actual editor (there can be panes in between), and actually doesn't work if you split the editor region (Window > Split).

Well, AFAIK you can only have one focussed buffer (with cursor). The
cursor info would be from that buffer.
Actually I don't think I ever even looked at that info.


> The symbols combo box would be misplaces above the project tree, because it shows the symbols that are defined in the editor (would also break further with 'split'). If you open an image (e.g. png file) you get controls for the image viewer there, which would make even less sense above the project tree.

Same answer as above. Info from the focused buffer. None => no info.


>> I think I rarely edit more than say 10~20 files at the same time.
>
> I could fit at most 9-10 "reasonably" named tabs (e.g. searchresultwindow.h) on a reasonably large monitor when Qt Creator is in fullscreen.

Would have to try it. Again, a matter of taste. I have a feeling that
clipping the name and fading it out, when it dosen't fit would work
well.

These are just usability changes that I would like to play with.
For example to try a tab stack, where the tabs are ordered from left
to right ordered by most recent focus.


Most of these changes are actually pretty simple AKAI can tell. I'll
try to do something as soon as I have some free time.
My only fear is that it can't be made as an option, and it probably
requires the base code to be changed.
That would be a pity, as not everyone would like or benefit from such
changes, and that's why it should be done as a plugin.

=)