Changes between Initial Version and Version 1 of Ticket #204, comment 8


Ignore:
Timestamp:
Aug 21, 2011, 1:01:22 AM (13 years ago)
Author:
Dmitry A. Kuminov

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #204, comment 8

    initial v1  
    55    // [1] resize the video widget to match the size of the video
    66    videoWidget->resize (800, 600);
    7     // [2] resize the main widget to match the size of the vide widget
     7    // [2] resize the main widget to match the size of the video widget
    88    resize(size() - stackCentralW->size() + QSize(800, 600));
    99}}}
    1010
    11 According to my understanding of Qt, this is *completely* wrong because {{{videoVidget}}} position and size is managed by a QLayout subclass and therefore must be not moved or sized manually. In this particular case, the line marked with ![2] (i.e. resizing the main window) is totally enough -- videoWidget will get its size (800 x 600 as well) automatically thanks to its QLayout. If only ![2] is used, the test case doesn't reveal any problems with the wrong position of {{{videoWidget}}} and I believe VLC would not have them as well.
     11According to my understanding of Qt, this is *completely* wrong because the {{{videoVidget}}} position and size is managed by a QLayout subclass and therefore it must be not moved or sized manually. In this particular case, the line marked with ![2] (i.e. resizing the main window) is totally enough -- videoWidget will get its size (800 x 600 as well) automatically thanks to its QLayout. If only ![2] is used, the test case doesn't reveal any problems with the wrong position of {{{videoWidget}}} and I believe VLC would not have them too.
    1212
    13 However, for some reason, the Windows version of Qt behaves correctly in this case (and I assume the Linux version as well). This may be just an accident or maybe Nokia deliberately made this case supported because many people did the same mistake... In either case, we have to support this poor behavior on OS/2 as well.
     13However, for some reason, the Windows version of Qt behaves correctly in this case (and I assume the Linux version as well). This may be just an accident or maybe Nokia deliberately made this case supported because many people did the same mistake... In either case, we have to support this poor behavior on OS/2 too.
    1414
    1515BTW, doing {{{stable->setAutoFillBackground (true);}}} in VideoWidget::request() is a bad idea either. I suppose this is done to paint empty bands on sides of the video frame with black color when the aspect ratios of the video and the window don't match, but this introduces a terrible flicker when e.g. resizing the window during playback. A smarter solution would be to set the window color of VideoWidget itself to black and fix the constraints of the stable widget (using e.g. heightForWidth()) so that it's aspect ratio always matches the video frame size -- this way, the VideoWidget's layout would simply center the stable widget inside it and no flicker would occur since setAutoFillBackground() is not necessary in this case.