On Jan 24, 2011, at 7:46 PM, ext tbp wrote: > On Mon, Jan 24, 2011 at 11:10 AM, <[email protected]> wrote: >> 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. > Wholeheartedly agreed. > >> 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) > That's what i did first. But there's actually 3 parts there: locator, > completion list, option menu. Since that last mail i've gone back to > that code and now intrusively track all of them. Works as intended, if > a bit ugly. > >>> . 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. > My overlay widget hooks in via the FancyTabWidget, because that's > where most the relevant stuff is; locator comes later in the init > chain. But the fix was simple and already there in the form of > MainWindow::extensionsInitialized(), i should have looked better. My > bad. > As it is a tad intrusive by nature (stealing space owned by others), > i'd need a way to properly query some dimensions dynamically (ie > rightmost vertical scrollbar thickness, header bar height). It's > rigged for now, as i have no idea how to do it proper and there's > interaction with other pending patches. > >> Feel free to hop by on irc.freenode.net #qt-creator . > Well, for me it's feature-complete now but certainly not of > merge-request grade. If irc is the place for further discussion, then > irc it is.
IRC has the advantage of much faster and direct communication cycles without spamming a mailing list but perhaps I understand what you mean if I could have a look at your code on a updated qt.gitorious clone :) -- 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
