On 17 May 2012, at 11:06, ext Paulo Silva wrote:
> Hi, thanks for the feedback.
>
>> 1. I like the idea of hidden labels of mode icons ("Welcome" etc.). It could
>> be implemented in mainline as an option.
>
> Well, it''s not just that, but the bar is also less than half the
> original width. =)
With the current design you run into the problem that the progress indicators
(e.g. for building, parsing, searching) are in that bar as well, and need at
least a bit of space for a their UI too.
On my list of
should-probably-be-done-at-some-point-but-somewhat-not-high-priority things to
do there's also to move the progress indicators to a more sensible place.
>> 2. Probably you are right that build/run/debug buttons are misplaced. They
>> should
>> stay somewhere on top and stop button should be among them, but I'm not sure
>> if they should replace settings of project tree.
>
> 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).
> Another possibility would be for the project selection to be by double
> clicking on its name, instead of left click + menu option.
> Then I could at least use the key shortcut to build the project. Still
> a bit, but at least less work than it is now.
>
>> 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?
> As for tabs versus drop-down menu, in my usage experience can't
> remember ever using it.
> I either use the open files widget or option+tab to cycle through the
> open buffers.
> Hoever I do think that tabs are still better than the drop-down menu,
> specially when there's up to say 10 tabs open or so.
>
> 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.
> 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? ;)
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).
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.
> 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.
> And
> if I do, I usually endup closing some, otherwise I just get too
> confused. And it's actually slower to switch between the important
> buffers.
> That is, the probability of the screen getting too crammed with tabs is low.
I rarely close editors. Basically only when I switch to a different issue to
work on, then I just close all. (Yes, I also don't use the combo box too often,
instead I'm mostly using ctrl+tab, locator, and once in a while the open
documents pane.)
> A tabbar with ordering scheme selection would also be cool. Like FIFO,
> manual, most used. etc.
These kind of options might actually make sense to a certain agree for the open
documents pane.
--
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
_______________________________________________
Qt-creator mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/qt-creator
