Re: GUI - X Error: BadMatch

[Torsten]

On 28.01.2013 22:01, Daniel J Sebald wrote:
> On 01/28/2013 02:49 PM, marco atzeri wrote:
>> On 1/28/2013 9:28 PM, Daniel J Sebald wrote:
>>> On 01/28/2013 02:16 PM, marco atzeri wrote:
>>>> On 1/28/2013 7:00 PM, marco atzeri wrote:
>>> [snip]
>>>>> re-testing ....
>>>>> Marco
>>>>>
>>>>
>>>> the only change seems the Resource Id number
>>>
>>> Marco,
>>>
>>> In file-editor-tab.cc replace ->setFocus() with
>>>
>>> ->setFocus (Qt::OtherFocusReason)
>>>
>>> and in file-editor.cc replace ->setFocus() with
>>>
>>> ->setFocus (Qt::ActiveWindowFocusReason)
>>>
>>> compile and run again. No rhyme or reason to the changes, but perhaps
>>> it will reveal where or what is happening.
>>>
>>> Dan
>>
>> Dan
>> the second does not exist
>>
>> all "->setFocus" I see are:
>>
>> src/m-editor/file-editor-tab.cc: _edit_area->setFocus
>> (Qt::OtherFocusReason);
>> (changed)
>>
>> src/main-window.cc: _terminal->setFocus ();
>> src/main-window.cc: _terminal_dock_widget->setFocus ();
>> src/main-window.cc: _terminal->setFocus ();
>> src/main-window.cc: _history_dock_widget->setFocus ();
>> src/main-window.cc: _files_dock_widget->setFocus ();
>> src/main-window.cc: _workspace_view->setFocus ();
>> src/main-window.cc: _documentation_dock_widget->setFocus ();
> 
> Oh, sorry, I didn't realize that setFocus was used elsewhere.  It could
> be those instances of setFocus which are the issue.  I see there are
> several instances of this combination of lines of code:
> 
>   _terminal_dock_widget->setFocus ();
>   _terminal_dock_widget->activateWindow ();
> 
> If you are adventurous, you could swap around the order of one or two of
> those (activate first, then focus) and see if it affects the number of
> error messages you are seeing.
> 
> Dan
> 

Marco, thanks for testing.

The order of the above calls was not changed by the changeset. What is
new is that these functions are also called when the related widget
becomes visible (important for tabbed widgets). It is strange that the
error messages only appear at start-up regardless when the
visibility-signals are connected.
Could you please make another test where the signals are not connected
before the main window is shown for the first time (attached patch)?

Torsten

x-messages-04.diff
Description: Text Data