Am 23.03.2012 05:16, schrieb Tim E. Real:
> On March 21, 2012 12:24:47 PM Florian Jung wrote:
>
>> Am 21.03.2012 07:02, schrieb Tim E. Real:
>>
>>> On March 9, 2012 4:27:39 PM Florian Jung wrote:
>>>
>>>> Hi
>>>>
>>>> how's the status?
>>>>
>>>> is anyone aware of any bugs not mentioned in
>>>> http://www.muse-sequencer.org/index.php/TODO ?
>>>>
>>> There's one visual bug that's been there for a while.
>>> Certain Qt styles cause see-through MDI window backgrounds.
>>> I've been banging my head trying to figure it out.
>>>
>>> This snapshot is in MDI mode with Arranger and Pianroll open,
>>>
>>> using Motif Qt style, but it happens in other styles:
>>> http://dl.dropbox.com/u/53315356/see-through-MDI-top-wins.jpeg
>>>
>>> Usually it only happens to the Arranger upon loading a song, but I've
>>> seen>
>>> it with Arranger AND Pianoroll before.
>>>
>>> If you move the MDI window out on its own, and then BACK into MusE
>>>
>>> as a subwindow, presto! It works.
>>>
>>> I thought about setting QWidget::autoFillBackground(true)
>>>
>>> which may or may not work, but it's a moot point - the window is in
>>> fact drawn correctly if you take it out then put it back in, so why
>>> isn't it working the first time around? ...
>>>
>> strange thing... i cannot reproduce it by just creating some windows in
>> motif style, or by opening songs.
>> but i had a similar issue long long before, where parts of the windows
>> "forget" to redraw themselves. when i switched from a pianoroll to an
>> arranger, it might happen that the arranger displays parts of the
>> pianoroll-canvas. forcing the arranger to redraw fixes this.
>> but that was a long time ago and i cannot reproduce that one any more.
>>
>> can you maybe provide sample files?
>> also consider testing on different machines (with different graphics
>> cards), or try using the "vesa" driver in your x-server. it might be
>> actually a problem at your site, especially ATI can be nasty sometimes ._.
>>
>>
>>> Say, about that Motif style (and possibly others):
>>>
>>> Why does it look so different in MusE than when I preview
>>>
>>> (an MDI or other) mock-up as Motif style in QtDesigner?
>>>
>>> All the bars and highlights are black in MusE but in QtDesigner
>>>
>>> they are blue.
>>>
>>> Can anyone explain?
>>>
>>> Are we not setting something fully in MusE?
>>> I removed our default style sheet setting so I know that it shouldn't
>>>
>>> be a style sheet issue - that caused some headaches before.
>>>
>> good question. it might simply be that designer is buggy. (it IS)
>> i was happening to me that spacers looked differently-sized in designer
>> and in muse, i even tried a completely new qt project. same issue.
>>
>>
>>> ---
>>> Also there's an issue with the Cakewalk and Mac IFs.
>>> Sometimes when a window opens, you must click INSIDE it
>>>
>>> before a toolbar appears in the MusE window.
>>>
>>> I've got a sample project here where every time it opens the
>>>
>>> toolbars are missing until you click inside EACH window.
>>>
>>> Well, at least it did before I just tried it again...
>>> Will try to pin it down.
>>>
>>> I just hope my focus fixes didn't cause that.
>>> I don't allow the TopWins to have focus anymore, but the
>>>
>>> mdi subwindows are still allowed focus (they must).
>>>
>> interesting. i had exactly that problem some time ago, and it was caused
>> by a combination of TopWins not accepting focus, and subwins be created
>> before the topwin inside has finishied constructing...
>>
>> when did you try again? it it was some months ago, it might be fixed now.
>>
>> focus thingy can easily be the problem here, hmmmm...
>> can you please give me the file, so i can have a look at it?
>>
>>
>> but do you have to just click inside it, or do you need to click into
>> another window and THEN inside the actual window?
>>
>> also, does this happen with all "window-classes", or only with some?
>>
>>
>>> It may be more of an init thing, possibly no control or canvas
>>>
>>> in the window has focus at all when it first opens.
>>>
>> i think it is.
>> that's why i've added MusE::topwinMenuInited(), which must be called at
>> the end of every topwin's constructor (every window class must do this
>> on its own)
>>
>>
>>> But I'm pretty sure pianoroll and/or drums force canvas->setFocus()
>>>
>>> in their constructors.
>>>
>> this might even cause the problem... it it possible that the canvas is
>> accepting focus before the menus are created?
>>
>>
>> tim, please try the patch i've attached (against release_2_0), and watch
>> out for message like these:
>> "====== DEBUG ======: topwin's menu got inited AFTER being shared!"
>> if my assumption is correct, then this patch will fix it (though don't
>> commit it, because it's dirty)
>>
>>
> It didn't help. Did not print out the test message.
>
> I found a step to reproduce.
> It seems to be only when I remove windows from the MDI and then
> put them back in again.
> I probably shouldn't be doing that without changing the GUI mode...
> It's more of a result of testing than anything else.
> Still, it is a selectable menu item.
>
> To reproduce:
> I started with no config files.
> Start MusE.
> Turn off Arranger window config -> as subwindow.
> Then turn it on again.
>
> Then no Arranger toolbars in Main window.
>
> Found some -DD messages, check out the "has no effect" parts:
>
> You can ignore the first and last few parts, they're just when I was
> switching windows and closing 'did you know'.
>
>
fixed.
some long time ago, this used to work (when a QMdiSubWin was activated,
it was treated as if it's child got focus); however, it broke toolbars
because their toolbar state was saved BEFORE they existed at all,
deleting the sane state.
i fixed this by not treating it like above, but instead remember that
window for the future, and when the window signals that it was done with
creating toolbars, THEN it's treated as if it got focus.
my fix now combines both ways: if the window is still initing, it's
ignored for now and remembered. if it's not initing, it's treated as if
the child just got focus.
greetings
flo
|