Qt4-preview-feedback Archive, April 2007
QMdiArea seems to be coupling activation and focus
Message 1 in thread
I've noticed the following issue with QMdiArea.
Suppose a QMdiSubWindow is active within the area.
If a user moves the focus outside of the area to
(for example) a dock widget, the QMdiSubWindow
is deactivated. In other words, it seems to
require focus to remain active.
This is problematic if the user wants to perform
some operation based on the active window (e.g.
maybe some kind of search).
It seems like an active QMdiSubWindow should
remain active unless it is destroyed, explicitly
deactivated programatically, or until some other
QMdiSubWindow in the same QMdiArea is activated.
Thanks,
Joe Newman
Synopsys, Inc.
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Message 2 in thread
Joe Newman wrote:
> I've noticed the following issue with QMdiArea.
> Suppose a QMdiSubWindow is active within the area.
> If a user moves the focus outside of the area to
> (for example) a dock widget, the QMdiSubWindow
> is deactivated. In other words, it seems to
> require focus to remain active.
>
> This is problematic if the user wants to perform
> some operation based on the active window (e.g.
> maybe some kind of search).
>
> It seems like an active QMdiSubWindow should
> remain active unless it is destroyed, explicitly
> deactivated programatically, or until some other
> QMdiSubWindow in the same QMdiArea is activated.
The current behavior seems reasonable to me. I don't see why
QMdiSubWindow should have its own definition of the Qt::WindowActive
window state.
--
[ signature omitted ]
Message 3 in thread
-----Original Message-----
From: Bjoern Erik Nilsen [mailto:bnilsen@xxxxxxxxxxxxx]
Sent: Wednesday, April 25, 2007 1:02 AM
To: Joe Newman; qt4-preview-feedback@xxxxxxxxxxxxx
Subject: Re: QMdiArea seems to be coupling activation and focus
Joe Newman wrote:
>> I've noticed the following issue with QMdiArea.
>> Suppose a QMdiSubWindow is active within the area.
>> If a user moves the focus outside of the area to
>> (for example) a dock widget, the QMdiSubWindow
>> is deactivated. In other words, it seems to
>> require focus to remain active.
>>
>> This is problematic if the user wants to perform
>> some operation based on the active window (e.g.
>> maybe some kind of search).
>>
>> It seems like an active QMdiSubWindow should
>> remain active unless it is destroyed, explicitly
>> deactivated programatically, or until some other
>> QMdiSubWindow in the same QMdiArea is activated.
>The current behavior seems reasonable to me. I don't see why
>QMdiSubWindow should have its own definition of the Qt::WindowActive
>window state.
Requirements should not be driven by a pre-existing
set of flags. That's like saying it's reasonable
for a car to only park or move forward because the
transmission doesn't understand "reverse."
There is a clear need to have a QMdiSubWindow remain
"active" or "current" or whatever you want to call it
when the focus has moved outside of the QMdiArea.
How else can a user perform operations that pertain
to the active subwindow from someplace other than
the QMdiArea? There's no visual indication of what
they're doing.
Look at Excel. Whether you move focus to a docked
widget or to a dialog, the "current" or "active"
MDI window stays in that state. Are you saying we
simply can't do that with Qt?
Joe Newman
Synopsys, Inc.
To unsubscribe - send "unsubscribe" in the subject to qt4-preview-feedback-request@xxxxxxxxxxxxx
Message 4 in thread
> There is a clear need to have a QMdiSubWindow remain
> "active" or "current" or whatever you want to call it
> when the focus has moved outside of the QMdiArea.
> How else can a user perform operations that pertain
> to the active subwindow from someplace other than
> the QMdiArea? There's no visual indication of what
> they're doing.
>
> Look at Excel. Whether you move focus to a docked
> widget or to a dialog, the "current" or "active"
> MDI window stays in that state. Are you saying we
> simply can't do that with Qt?
Hi Joe,
I agree with you that it should be possible to perform operations on a
QMdiSubWindow when the focus is moved outside the window itself. We
clearly have to change the current behavior.
We are currently looking into how other MDI applications such as Excel
behave just to make sure we are doing the right thing.
I'll let you know when we have a fix for it in our snapshots.
Thank you very much for the report.
--
[ signature omitted ]
