---- On Sat, 10 Mar 2018 23:02:03 +0800 <[email protected]> wrote ----
> > How to proceed? Maybe I should push my branch to my fork and someone else can take a look?
> You should move the function you're working on to help_browser.cpp. It will solve your compiler error (that file includes main.hpp which has the definition you need), and you will also get faster build times because every edit will only lead to recompilation of a single TU, and not every TU helpbrowser.hpp is included in (from a quick search it looks like there are 5).
Aha -- thanks. That was correct. Sorry it took so long to try it (work has been so busy, it's been literally a month since I could get enough time to concentrate on this -- and today, only because it's the traditional Tomb Sweeping Day and I have an extra day off from work).
But, the bad news-es are:
- It doesn't help. If I force the help browser to be invisible in onInterpreterStart(), it's still hit or miss whether the window closes properly. So, either this is the wrong approach, or it's the right approach and Qt has a really (expletive deleted) frustrating sync bug.
- I still can't access the settings object. restoreDetachedState() gets it this way:
QByteArray base64data = data.value( docklet->objectName() ).value<QByteArray>();
So I cribbed some code from MainWindow::restoreWindowState() to get the "const QVariantMap & data" object, and then I figured, my function is in the context of HelpBrowserDocklet anyway, so maybe it would work to do "data.value( this->objectName() ).value<QByteArray>();" -- but it doesn't. "base64data.isEmpty()" ends up being true.
https://github.com/jamshark70/supercollider/blob/topic/HelpWindowDebug/editors/sc-ide/widgets/help_browser.cpp#L487-L518
So I'm lost on both of these counts.
By "frustrating," I want to emphasize that this has been for a few YEARS now, that I have to take extra steps in the interface to get the help browser to be in the correct state. The help browser state that is persisted to disk is undocked and closed. I get this result without manual intervention only 10-20% of the time. The vast majority of times that I launch scide, I have to do this:
1. Switch window focus to the IDE (because the partially-drawn, nonfunctioning help browser has focus).
2. Ctrl-D to activate the help window (which I don't want to do, because I don't want to wait for help files to be indexed every time I start the IDE).
3. Click on the help browser's close box.
With 365 days a year, it takes only an average of three times a day opening the IDE to reach a thousand launches. An 80% failure rate is really astonishing, coming to over 800 times a year (at that hypothetical rate) that I would have to do these extra steps. 5 seconds * 800 times = 4000 seconds = 66+ minutes wasted.
IT IS DRIVING ME CRAZY.
This really needs to be fixed. And I'm out of ideas.
It used to work perfectly, when we were using some older version of Qt. So I guess something in Qt changed, and we're supposed to adapt to it, but nobody knows even which haystack to look in, let alone what the needle looks like.
hjh
_______________________________________________
sc-dev mailing list
info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/
search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.