Mac OS X windows start in background

Bug #417162 reported by Neil Martinsen-Burrell
32
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Bazaar Explorer
Fix Released
High
Luis Arias
QBzr
Fix Released
High
Luis Arias

Bug Description

In bzr-explorer, pressing a button that brings up a QBzr dialog box brings that dialog box up *behind* the explorer window. Since the explorer window is quite large and there is no "window list" toolbar on Mac OS X, it is very difficult to know that a particular button click did anything. This may be a bug in qbzr, since the same problem appears with ``bzr qbranch``. In that case, it is less egregious, because a Terminal window doesn't generally cover a large portion of the screen, so it is possible to see the window that is created.

The created window appears to be directly below the calling window and above all other windows, and in the exact center of the screen. The window should appear *on top* of the calling window. See the attached screenshot, where the Explorer window is moved very far to the upper left just to expose a piece of the qbranch dialog.

Tags: mac
Revision history for this message
Neil Martinsen-Burrell (nmb) wrote :
Changed in bzr-explorer:
importance: Undecided → High
status: New → Triaged
Changed in bzr-explorer:
importance: High → Medium
Revision history for this message
Martin Pool (mbp) wrote :
Revision history for this message
Ian Clatworthy (ian-clatworthy) wrote :

Explorer's sub-command launching is reasonably well isolated in app_runner.py. Perhaps we need a custom implementation of launching commands on OS X?

Revision history for this message
Martin Pool (mbp) wrote : Re: [Bug 417162] Re: Mac OS X windows start in background

On 4 February 2010 07:47, Ian Clatworthy <email address hidden> wrote:
> Explorer's sub-command launching is reasonably well isolated in
> app_runner.py. Perhaps we need a custom implementation of launching
> commands on OS X?

So every dialog is a separate process? That would explain it, also bug 516447.

I guess you either need to find some os x magic to say "these are
actually the same app though they're different processes" or run the
dialogs in the same process or tolerate the bugs. jfroy may be able
to offer some advice.

--
Martin <http://launchpad.net/~mbp/>

Revision history for this message
Ian Clatworthy (ian-clatworthy) wrote :

Martin Pool wrote:
> On 4 February 2010 07:47, Ian Clatworthy <email address hidden> wrote:
>> Explorer's sub-command launching is reasonably well isolated in
>> app_runner.py. Perhaps we need a custom implementation of launching
>> commands on OS X?
>
> So every dialog is a separate process? That would explain it, also bug
> 516447.
>
> I guess you either need to find some os x magic to say "these are
> actually the same app though they're different processes" or run the
> dialogs in the same process or tolerate the bugs. jfroy may be able
> to offer some advice.
>

Or more ideally, a separate thread in the same process. (One advantage
of the separate processes now is command isolation wrt errors and
non-blocking of the UI thread).

Ian C.

Revision history for this message
John A Meinel (jameinel) wrote :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Clatworthy wrote:
> Martin Pool wrote:
>> On 4 February 2010 07:47, Ian Clatworthy <email address hidden> wrote:
>>> Explorer's sub-command launching is reasonably well isolated in
>>> app_runner.py. Perhaps we need a custom implementation of launching
>>> commands on OS X?
>> So every dialog is a separate process? That would explain it, also bug
>> 516447.
>>
>> I guess you either need to find some os x magic to say "these are
>> actually the same app though they're different processes" or run the
>> dialogs in the same process or tolerate the bugs. jfroy may be able
>> to offer some advice.
>>
>
> Or more ideally, a separate thread in the same process. (One advantage
> of the separate processes now is command isolation wrt errors and
> non-blocking of the UI thread).
>
> Ian C.
>

I'll mention that bzrlib isn't particularly good about being used by
multiple threads concurrently. (Witness the recent hot-fix for issues
with Loggerhead on launchpad.)

I guess if you generally use different objects we are mostly ok (we only
have a couple of global caches which we can try to improve on anyway).
But certainly a single Repository object is not thread safe, for example.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktq6jwACgkQJdeBCYSNAAOcBwCbBDIEdsW1O9hJnPk8lW/9a1Nm
c2QAn1QiaH4y8qLBteLSkOHg7ffX/n4i
=ioXp
-----END PGP SIGNATURE-----

Revision history for this message
Martin Pool (mbp) wrote :

I think running in threads in the same process would be an
unnecessarily risky way to fix this bug. You will be dealing with
annoying threading bugs for ever.

--
Martin <http://launchpad.net/~mbp/>

Changed in bzr-explorer:
status: Triaged → Confirmed
Revision history for this message
JerryShea (jerry-shea) wrote :

I'd vote for this to be a "High" as it makes explorer nearly unusable on the Mac... My 2cents

Changed in bzr-explorer:
importance: Medium → High
tags: added: mac
Revision history for this message
Federico Bett (gfbett) wrote :

Other issue on MacOS is that the bazaar explorer windows are kept on top of other windows, (I´m using Macports to install bzr explorer on Snow Leopard).

Luis Arias (kaaloo)
Changed in bzr-explorer:
assignee: nobody → Luis Arias (kaaloo)
Revision history for this message
Gary van der Merwe (garyvdm) wrote :

Affects qbzr because the fix is in qbzr.

Changed in bzr-explorer:
status: Confirmed → Fix Released
Changed in qbzr:
assignee: nobody → Luis Arias (kaaloo)
importance: Undecided → High
status: New → Fix Released
milestone: none → 0.19b2
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.