size of qdiff windows invoked twice from qlog lost maximized flag

Bug #716384 reported by Alexander Belchenko
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
QBzr
Fix Released
Critical
Alexander Belchenko

Bug Description

I found the way to reproduce it.

run bzr qlog
invoke qdiff for some revision -> all ok
close qdiff -> all ok
invoke qdiff for other revision -> qdiff window is no more maximized,
and corresponding setting disappears from qbzr.conf

So, second qdiff invocation from qlog resets maximized flag to nothing,
and even the line

diff_window_maximized = True

disappears from qbzr.conf.

That's because in qbzr/lib/utils.py we have the following code in restoreSize:

         is_maximized = config.get_option(name + "_window_maximized")
         if is_maximized in ("True", "1"):
             self.setWindowState(QtCore.Qt.WindowMaximized)

Adding trace point after config.get_option I see the following:

first time for qdiff we read qdiff_window_maximized option as u'True'
(unicode string), but second time we read the same option from the same
process as bool True. Why? I don't understand.

So the if statement in the second line is False for the second case.

The simplest fix is to extend the if statement, the better fix is to
adopt get_user_options_as_bool from bzrlib.config.

Related branches

Revision history for this message
Alexander Belchenko (bialix) wrote :

I can't reproduce it now. Something weird.

Changed in qbzr:
status: New → Invalid
Revision history for this message
Alexander Belchenko (bialix) wrote : Re: [Bug 716384] Re: size of qdiff windows invoked from qcommit (pending merge) is default

No, actually I found the way to reproduce it.

run bzr qlog
invoke qdiff for some revision -> all ok
close qdiff -> all ok
invoke qdiff for other revision -> qdiff window is no more maximized,
and corresponding setting disappears from qbzr.conf

So, second qdiff invocation from qlog resets maximized flag to nothing,
and even the line

diff_window_maximized = True

disappears from qbzr.conf.

Definitely a bug. Once lp returns back from read-only mode I need to
change status of this bug.

Revision history for this message
Alexander Belchenko (bialix) wrote :

So, investigating this bug I found that:

in qbzr/lib/utils.py we have the following code in restoreSize:

         is_maximized = config.get_option(name + "_window_maximized")
         if is_maximized in ("True", "1"):
             self.setWindowState(QtCore.Qt.WindowMaximized)

Adding trace point after config.get_option I see the following:

first time for qdiff we read qdiff_window_maximized option as u'True'
(unicode string), but second time we read the same option from the same
process as bool True. Why? I don't understand.

So the if statement in the second line is False for the second case.

The simplest fix is to extend the if statement, the better fix is to
adopt get_user_options_as_bool from bzrlib.config.

Changed in qbzr:
status: Invalid → In Progress
importance: Undecided → Critical
milestone: none → 0.20.1
assignee: nobody → Alexander Belchenko (bialix)
summary: - size of qdiff windows invoked from qcommit (pending merge) is default
+ size of qdiff windows invoked twice from qlog lost maximized flag
description: updated
Revision history for this message
Alexander Belchenko (bialix) wrote :

Another problem is: when we save is_maximized flag as bool then configobj simply drops it from the output file.

Weird, weird, weird.

Revision history for this message
Alexander Belchenko (bialix) wrote :

So the problem with reading the same value twice gives as u'True' and True maybe because we have some sort of caching inside config object?

Revision history for this message
Alexander Belchenko (bialix) wrote :

Yes, the content of qbzr.conf is cached.

Revision history for this message
Alexander Belchenko (bialix) wrote :

Some fix pushed to lp:qbzr/0.20, but we need to decided whether we need to switch to bzrlib.config instead of our re-implementation.

Changed in qbzr:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.