Hiding main toolbar on OSX not persistent
Removing main toolbar doesn't save after restart of client on OS X.
#2 Updated by sdboyer over 8 years ago
Giant +1 to fixing this.
it seems to me that, with a persistent daemon/bouncer like quasselcore, it's reasonable to assume that the common use pattern is to simply sit, constantly, in the same set of IRC rooms. at least, that's my use pattern. it thus strikes me as odd that one would sacrifice so much vertical screen real estate for buttons that are almost never used.
if making it persistent is hard, then maybe just making the main toolbar default to being off would be a workable interim solution.
for the record, i created a bugtracker account specifically and exclusively for this bug.
#3 Updated by Ycros about 8 years ago
I have a pull request that works around the issue by storing the state manually using
QtUiSettings - https://github.com/quassel/quassel/pull/53
The actual bug is caused by
setUnifiedTitleAndToolBarOnMac(true);, and this Qt bug: https://bugreports.qt-project.org/browse/QTBUG-23285
Given the list of unresolved Qt bugs around the
setUnifiedTitleAndToolBarOnMac (https://bugreports.qt-project.org/issues/?jql=text%20~%20%22setUnifiedTitleAndToolBarOnMac%22%20AND%20resolution%20%3D%20Unresolved), maybe the better and simpler fix is to simply remove that call and have a normal Qt toolbat instead.
#6 Updated by Ycros about 8 years ago
This is also likely causing #1224
Have you tried out if your PR fixes that issue as well, or could you do it please?
My PR won't, but I've just tested it with removing the call to
setUnifiedTitleAndToolBarOnMac(true); and it does fix it.
It means Quassel goes from looking like this (more OSX-like): https://dl.dropboxusercontent.com/u/125278/Screenshots/Quassel/Quassel_-__1116_-_unified_toolbar__current_-2.png
My PR fixes saving the hidden/visible state of the toolbar when the unified toolbar is enabled. If you'd like I could alternatively submit a PR to remove the unified toolbar instead, it's a smaller change and it might fix more things, but it will look slightly worse on OSX (I personally don't care because I always have it hidden). It's also possible that Qt5 might fix some of these things (they also added native fullscreen support in 5, which would be nice).
#7 Updated by Sputnick about 8 years ago
In this case I would prefer merging your workaround for now without deterioating the visuals for the other problem, and maybe revisit #1224 once we have Qt5 in (I would assume that the Mac builds would switch to Qt5 quite soonish then, considering they don't need KDE integration which is going to hold back Qt5 for Linux for a while).
#10 Updated by Ycros almost 8 years ago
- Status changed from Resolved to Feedback
So I didn't notice right away, but apparently my change to #ifdef Q_WS_MAC breaks my fix - if I comment it out from the mainwin.h then everything works, otherwise it can't find the slot.
What's odd is that if I introduce a deliberate syntax error, compilation does fail on a few files - so it's like parts of the build have it defined, and other parts don't. I'm not familiar enough with the build system to work out why.
I could leave the slot in there, and just keep the code that hooks up to it #ifdef'd.
#11 Updated by Bombe almost 8 years ago
I compiled latest master (bb584446aa5e60086ec3a7d14069681f3cfb17fa) yesterday, and when starting up quasselclient it tells me:
Object::connect: No such slot MainWin::saveMainToolBarStatus(bool)
Object::connect: (sender name: 'MainToolBar')
and shows the toolbar again even though I hide it every time.