Project

General

Profile

Bug #1116

Hiding main toolbar on OSX not persistent

Added by mattwb65 about 13 years ago. Updated almost 11 years ago.

Status:
Feedback
Priority:
High
Assignee:
-
Category:
Quassel Client
Target version:
Start date:
10/25/2011
Due date:
% Done:

100%

Estimated time:
Version:
0.7.2
OS:
Mac OS X

Description

Removing main toolbar doesn't save after restart of client on OS X.


Related issues

Related to Quassel IRC - Bug #1224: Main window does not restore size on Mac (10.6) - gets shorter every time it runsNew2013-05-23

Associated revisions

Revision e49189fd (diff)
Added by Ycros almost 11 years ago

Save Main ToolBar state when not built against KDE. Fixes #1116

Revision 91c03b98 (diff)
Added by Ycros almost 11 years ago

Save Main ToolBar state when not built against KDE. Fixes #1116

History

#1 Updated by Anonymous almost 13 years ago

  • Subject changed from Main toolbar to Hiding main toolbar on OSX not persistent
  • OS changed from Any to Mac OS X

#2 Updated by sdboyer over 11 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 almost 11 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.

#4 Updated by Ycros almost 11 years ago

This is also likely causing #1224

#5 Updated by Sputnick almost 11 years ago

Ycros wrote:

This is also likely causing #1224

Have you tried out if your PR fixes that issue as well, or could you do it please?

#6 Updated by Ycros almost 11 years ago

Sputnick wrote:

Ycros wrote:

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

To this: https://dl.dropboxusercontent.com/u/125278/Screenshots/Quassel/Quassel_-__1116_-_non_unified_toolbar.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 almost 11 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).

#8 Updated by Sputnick almost 11 years ago

  • Target version set to 0.9.3

#9 Updated by Ycros almost 11 years ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100

Applied in changeset quassel|commit:91c03b989493223b3969ba1da9a8a2e676000a5d.

#10 Updated by Ycros almost 11 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 11 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.

Also available in: Atom PDF