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

[eike.ziller at nokia.com]

On 21 May 2012, at 13:38, ext Paulo Silva wrote:

>>> 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?

You say in the sentence above "But since the open files widget is still there", i.e. that you wouldn't want to replace it.
Maybe we have a terminology problem here. With "open documents pane" I mean the thing titled "Open Documents" at the left hand side where also the project tree is shown.

>>> 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".

It's not possible as a plugin on top of what is there "as is".

>>> 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.
> 
> =)
> _______________________________________________
> Qt-creator mailing list
> Qt-creator at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator

-- 
Eike Ziller
Principal Software Engineer

Nokia, Qt Development Frameworks

Nokia gate5 GmbH
Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany
Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B
Umsatzsteueridentifikationsnummer: DE 812 845 193
Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori