On Jan 22, 2011, at 4:28 PM, ext tbp wrote:
> On Wed, Jan 19, 2011 at 6:34 PM, André Pönitz <[email protected]> wrote:
>> Next step perhaps the left tab bar with notifications moved to the statusbar.
> Didn't have much chance with it at first try; what's in that
> progressview doesn't cooperate: it expects a minimal vertical height
> larger than available in the status bar (at least the equivalent of 2
> lines of text per item), and play games animating the geometry,
> vertically only again. It needs further doctoring than simply
> transferring to the statusbar and switching to an horizontal layout.
I wouldn't even try to put progress indicators directly into the status bar,
horizontal space is just not enough.
One idea for them (if we still have a status bar) would be to show a single
("merged") progress bar in the status bar (lower right corner),
really only a bar without label or anything, and show the "overlayed ones" that
you are talking about below, also in the lower right corner right above the
status bar when mouse is hovered over the status bar.
On the other hand it would be insane to have different layouts for cases "mode
bar invisible but status bar visible" and "mode bar and status bar invisible",
both from the user perspective and from the maintainance perspective. So if the
"final" goal is to support invisble mode bar + status bar, then the one
alternative way for progress indicators must work for that directly.
> At that point i thought it would be just as easy to do what i'm really
> after, an overlay; see attached screenshot.
> It captures both the locator and the whole progressview (can also
> release them back), wrap them in a fading in/out alpha composited
> overlay that kicks in when:
> . mouse is near
> . locator activates (shortcut or otherwise)
> . some progress notification does something.
> It's otherwise transparent.
>
> Rationale for putting it on the top/right corner: near headers, which
> will be about the only remaining widgets in the intended final "mode"
> (less eye/mouse travel), and since it's borrowing code display space,
> putting it on the right makes it less susceptible to hide more
> important content (line start > line end).
>
> There's a few details to resolve, but they require much more
> comprehensive modifications of other parts, that's the reason for this
> email (getting things straight before engaging deeper).
> . progressview thingies: need to be taught about horizontal layouts to
> fit the status bar, and geometry animation needs to go for both the
> status bar case and overlay.
See above, I'd not try to put them into the status bar directly.
> . locator: i've tried to detect "activation" without the need to alter
> anything in that plugin, but it's brittle (my event filters miss
> much), some cooperation is required; the popup list needs to be told
> about other orientations anyways.
Feel free to hop by on irc.freenode.net #qt-creator .
I'm not sure what kind of "activation" you think of aside from "shortcut
pressed" (or better "LocatorWidget::show called", since the locator can also be
directly activated from code, e.g. for the "Go to line" menu+shortcut)
> . dependency on other patches, for the presence of scrollbars (vertical)
> . late activation: i haven't seen simple mechanisms to hook on the end
> of plugin registration/init and i need to steal that late locator; i
> need something reliable.
I don't quite understand that last one. There's SIGNAL ICore::coreOpened(), but
I don't see why you'd need it.
--
Eike Ziller
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.nokia.com/mailman/listinfo/qt-creator
