=====================================================================
NOTE: see also src/Inventor/Qt/common/BUGS.txt.
=====================================================================

000 Adding an app-specific pushbutton to the SoQtExaminerViewer will
    make the left border too thin. Reproduce with this code:

    ----8<--- [snip] ---------8<--- [snip] ---------8<--- [snip] ---
    #include <Inventor/Qt/SoQt.h>
    #include <Inventor/Qt/viewers/SoQtExaminerViewer.h>
    #include <Inventor/nodes/SoCone.h>
    #include <qpushbutton.h>
    
    
    int
    main(int argc,  char ** argv)
    {
      QWidget * window = SoQt::init("");
    
      SoQtExaminerViewer * examinerviewer = new SoQtExaminerViewer(window);
      examinerviewer->setSceneGraph(new SoCone);
    
      QWidget * parent = examinerviewer->getAppPushButtonParent();
      QPushButton * button = new QPushButton(parent);
      examinerviewer->addAppPushButton(button);
    
      examinerviewer->show();
      SoQt::show(window);
      SoQt::mainLoop();
    
      delete examinerviewer;
      return 0;
    } 
    ----8<--- [snip] ---------8<--- [snip] ---------8<--- [snip] ---

    I see at least two problems in the SoQtFullViewer::buildLeftTrim()
    code: 1) it is always set to a fixed width of 30 pixels, 2) it is
    not size-updated when buttons are added.

=====================================================================

002 The following example demonstrates a bug with how the Qt widgets
    seems to be stacked when we call SoQtComponent::show():

    ----8<--- [snip] ---------8<--- [snip] ---------8<--- [snip] ---
    #include <Inventor/Qt/SoQt.h>
    #include <Inventor/Qt/viewers/SoQtViewer.h>
    #include <Inventor/nodes/SoCone.h>
    #include <Inventor/nodes/SoSeparator.h>
    #include <qapplication.h>
    #include <qwidget.h>
    
    
    class NewViewer : public SoQtViewer {
    public:
      NewViewer(QWidget * parent)
        : SoQtViewer(parent, "buh", FALSE, SoQtViewer::BROWSER, FALSE)
      {
        QWidget * widget = this->buildWidget(parent);
        this->setBaseWidget(widget);
    
        SoSeparator * root = new SoSeparator;
        root->addChild(new SoCone);
        this->setSceneGraph(root);
    
        // FIXME: this causes the bug, remove the next line and all is
        // well. 20020619 mortene.
        this->show();
      }
    };
    
    int
    main(int argc, char ** argv)
    {
      QWidget * qw = SoQt::init(argv[0]);
      NewViewer * svapp = new NewViewer(qw);
      SoQt::show(qw);
      SoQt::mainLoop();
      return 0;
    }
    ----8<--- [snip] ---------8<--- [snip] ---------8<--- [snip] ---

    20020619 mortene.
    
    UPDATE: Not seeing the scene-graph displayed in the main window in
    the above example is actually correct behavior: Note the FALSE
    flag passed on for 'embed'. The fact that the scene-graph is
    displayed when removing 'this->show()' is the actual bug... :-) A
    quick check (SoQT/test_code/renderarea.cpp) shows that
    SoQtRenderArea does the correct thing when passed a FALSE: It is
    built outside of the application window. On the other hand, when
    the widget is passed 'TRUE' for 'embed', in the code displayed
    above, it works as expected. 20021023 rolvs

=====================================================================

003 Animations that are continually triggered by timer-sensors are not
    running as smooth in Coin's viewers as with SGI Inventor. This
    makes it looks like Coin has worse rendering performance than SGI
    Inventor.

    It also looks like we have the same problem in SoXt.

    Part of the problem, at least, seems to be that it is possible to
    get several actualRedraw() calls in-between the handling of native
    Qt events. That causes for instance SoQtExaminerViewer's
    invocations of spin() to happen more seldom than actualRedraw(),
    which again causes bad responsiveness.

    This is not a trivial task.

    mortene 20020702.

=====================================================================

004 When turning on decorations (use the RMB popup-menu to do this)
    with a small viewer window, the decorations layout will initially
    be erroneous. Just a small interactive resize in any direction
    will automatically correct the layout again.

    Found by kintel. Looks like a Qt bug. Very low priority on fixing
    this one, as it's just a very small blemish in a boundary-kind-of
    condition anyway.

    ----8<--- [snip] ---------8<--- [snip] ---------8<--- [snip] ---
    #include <Inventor/Qt/SoQt.h>
    #include <Inventor/Qt/viewers/SoQtExaminerViewer.h>
    #include <Inventor/nodes/SoCone.h>
    #include <qwidget.h>
    
    int
    main(int argc, char ** argv)
    {
      QWidget * window = SoQt::init(argv[0]);
    
      SoQtExaminerViewer * viewer = new SoQtExaminerViewer(window);
      viewer->setSceneGraph(new SoCone);
      viewer->setDecoration(FALSE);
    
      viewer->show();
      SoQt::show(window);
    
      window->resize(100, 100);
    
      SoQt::mainLoop();
    
      delete viewer;
      return 0;
    }
    
    ----8<--- [snip] ---------8<--- [snip] ---------8<--- [snip] ---

    mortene 20020703.

=====================================================================

005 Using SoQtComponent::setSize() to set a smaller size than the
    default _after_ doing either SoQtExaminerViewer::show() or
    SoQt::show(SoQtExaminerViewer*) fails, at least for an
    SoQtExaminerViewer embedded in a top-level shell (like in the
    SoGuiExamples/components/examinerviewer example.

    The interior resizes correctly (?), but the exterior does not
    shrink to fit.

    See also the FIXME above SoQtComponent::setSize() in
    SoQtComponent.cpp.

    mortene 20020808.

=====================================================================

009 Michael Wimmer reported that using SoQt on top of SGI Inventor
    causes one particular scene he had to run veeeeeery slow, both
    compared to SoQt-on-Coin and InventorXt-on-Inventor.

    The scene consists of some very simple geometry and 11
    textures. The textures are in total shared > 1000 times in the
    scene, though.

    (I could reproduce the problem with Wimmer's example model file,
    but it was too large (lots if inlined textures) to cut down on and
    include here.)

    It seems likely that the bad rendering performance is caused by
    continuous re-construction and re-destruction of GL texture
    objects. According to pederb, SGI Inventor has a bug here which
    has since been fixed by TGS.

    Should a) construct a scene which reproduces the problem, b)
    investigate how we set up cache context IDs for the
    SoGLRenderAction instance in SoQt and determine what causes SGI
    Inventor to completely flip out, c) try to find a work-around.

    20021002 mortene.

=====================================================================

012 Error with SoQtExaminerViewer::getViewerTitle().

    A bug-report from Paul van Santen of Hitec-O:

         It seems that this method now returns an empty string, even
         though we have set the title in the class' constructor. Is
         this a bug or an intended code change?

    Not yet investigated, but sounds very likely to be a bug.

    After fixing, make sure the different possible "configurations" of
    an SoQtExaminerViewer component in a Qt component-ownership tree
    is tested to work: both SoQtExaminerViewer as a top-level window,
    and embedded in an application Qt widget.

    20021018 mortene.
    
    UPDATE: I've tried to recreate this bug by creating QMainWindow
    with an embedded ExaminerViewer, and fetching the title of the
    viewer after initialization. This does not demonstrate the
    erroneous behaviour, and the demo application is sent to Paul van
    Santen. Awaiting reply from him. 20021022 rolvs.

=====================================================================

013 Minor user-interaction bug with the SoQtExaminerViewer.

    The camera-interaction mode can "get stuck" in this manner: click
    and drag the model. While still holding the LMB, hit 'ESC' to
    switch to scenegraph-interaction mode. Let go of LMB. Hit 'ESC'
    again. You're now in "drag/examine"-mode even though you're not
    holding down the LMB.

    (Simple to work around for the user -- just hit 'ESC' twice -- but
    it's still an irritating bug.)

    This bug is very likely common for all the So@Gui@ toolkits.

    20021022 mortene.

=====================================================================

014 Win32-specific build problem: if Qt or Coin is a static library,
    SoQt must also be built static and *without* including the static
    libraries we depend on.

    If built as a DLL under those circumstances, the static libraries
    we depend on will be linked into the DLL -- but without them being
    accessible from the application code. Then an app programmer is
    likely to include several instances of either Qt or Coin, which
    results in various sorts of difficult to understand problems.

    (Can typically be detected through a warning message from Qt,
    something like this: "you must set up a QApplication before
    calling QPaintDevice".)

    20021118 mortene.

=====================================================================

015 Can't change viewer embedded within a Qt widget on-the-fly.

    The following code shows how to reproduce the problem, and was
    written by Gatien Mellion and posted to coin-discuss:

    ----8<--- [snip] ---------8<--- [snip] ---------8<--- [snip] ---

    #include "config.h"
    #include <qapplication.h>
    #include "SoQt.h"
    #include "SoQtExaminerViewer.h"
    #include "SoQtPlaneViewer.h"
    #include <Inventor/nodes/SoBaseColor.h>
    #include <Inventor/nodes/SoCone.h>
    #include <Inventor/nodes/SoSeparator.h>
    
    int main(int argc, char ** argv)
    {
       QApplication app(argc, argv);
       SoQt::init("");
    
       QWidget * parent = new QWidget;  
       app.setMainWidget(parent);
    
        SoSeparator * root = new SoSphere;
        root->ref();
        root->addChild(new SoCone());
      
        SoQtExaminerViewer * viewer = new SoQtExaminerViewer(parent);
        viewer->setSceneGraph(root);
        viewer->show();
        delete viewer;
    
        SoQtPlaneViewer* planeviewer = new SoQtPlaneViewer(parent); 
        planeviewer->setSceneGraph(root);
        planeviewer->show();
    	
        app.exec();
    
        return 0;
    }
    ----8<--- [snip] ---------8<--- [snip] ---------8<--- [snip] ---

    20021122 mortene.

=====================================================================

016 SoQtExaminerViewer pref menu needs two RMB presses to pop up.

    This problem was reported by Scott Toelly. Happens both when the
    SoQtExaminerViewer is embedded within a QMainWindow, aswell as
    from the SoGuiExample/components/examinerviewer example.

    Scott is seeing this on Windows 2000 Pro + Visual C++ .NET Pro +
    Qt 3.0.6. I am not able to reproduce it with SoQt-1 on NT 4 + MSVC
    v6 + Qt 3.0.1, nor on Linux.

    Should try more local MSWin platform configurations to see if we
    can reproduce it locally.

    A generally nice thing to do for debugging event-handling problems
    would be to insert tracing code in the processEvent() /
    processSoEvent() methods that could be turned on at run-time with
    an environment variable. This could even help us debug remote
    problems.

    20021219 mortene.

=====================================================================

017 Tooltips on viewer buttons.

    The functionality of the different viewer pushbuttons is not
    entirely obvious, so we should add tooltips on the buttons.

    20030114 mortene.

=====================================================================

018 Problems with multi-threading Coin applications.

    larsa and pederb found a problematic case, leading to obscure
    bugs, when using SoQt in a multi-threading application: if a
    different thread than the SoQt-init thread causes a notification
    chain from the Coin scene graph, which again leads to the
    scheduling a sensor for the SoSensorManager, the callback
    invocation of the SoSensorManager runs into SoQt code to set up a
    Qt timersensor. This seems to not be mt-safe in Qt.

    20030204 mortene.

=====================================================================

019 Incompatibilities with TGS Inventor v3.1.

    HitecO reports misc problems running SoQt on top of TGS Inventor
    3.1, especially when initializing multiple threads through the
    Inventor library.

    This problem could be related to item #018.

    20030204 mortene.

=====================================================================

020 Likely memory leaks in SoQtExaminerViewer.

    thammer reports that this app apparently shows ~60KB leaks under
    MSWin for each SoQtExaminerViewer allocated and deallocated (while
    apparently only 1-2KB for the SoQtRenderArea):

    ----8<--- [snip] ---------8<--- [snip] ---------8<--- [snip] ---
    #include <stdio.h>
    #include <conio.h>
    
    #include <qapplication.h>
    #include <qwidget.h>
    
    #include <Inventor/Qt/SoQt.h>
    #include <Inventor/Qt/viewers/SoQtExaminerViewer.h>
    
    int main()
    {
      QWidget *unusedwidget = SoQt::init("memtest");
    
      QWidget *widget;
      SoQtExaminerViewer *viewer;
      // SoQtRenderArea *viewer;
    
      char c = 0;
    
      while (c != 'q') {
        printf("Creating widget... ");
        getch();
        widget = new QWidget();
        printf("OK.   ");
        printf("Creating viewer... ");
        getch();
        viewer = new SoQtExaminerViewer(widget);
        // viewer = new SoQtRenderArea(widget);
        printf("OK.   ");
        printf("Deleting viewer... ");
        c = getch();
        delete viewer;
        printf("OK.   ");
        printf("Deleting widget... ");
        c = getch();
        delete widget;
        printf("OK.\n");
      }
      return 0;
    }
    ----8<--- [snip] ---------8<--- [snip] ---------8<--- [snip] ---

    More investigation needed to confirm the leak.

    20030214 mortene.

=====================================================================

021 Boundary cases not handled when zooming too much either way in
    SoQtExaminerViewer.

    Reproduce by loading any model into an examinerviewer, switch to
    using orthographic camera, then just zoom either into or out from
    the model until the system starts spewing messages about

        Coin warning in SbVec3f::normalize(): The length of the vector
        should be > 0.0f to be able to normalize.

    Investigate and fix.

    This is very likely a problem with all So* toolkits.

    20030630 mortene.

=====================================================================

022 The X11 error message warning seems to come up too often.

    pederb is seeing it on QMessageBox'es, we're both seeing it on
    QColorDialog.

    Investigate and check whether or not it's a _real_ Qt-on-X11 bug
    here, or if our technique for hooking up with the X11 error msg
    handler is giving false negatives.

    This is an ugly problem, as it probably causes external users to
    be nervous that there is something wrong with SoQt, when it most
    likely isn't. So; it's a high priority problem.

    20031022 mortene.

=====================================================================

023 Fullscreen mode buggy for ATI (?) graphics on WinXP.

    SoQtComponent::setFullScreen() sends the window with the OpenGL
    canvas to the bottom of the window stack. Reproducible at least
    with our Geo2k application (which uses the SoQtRenderArea).

    Only happens with ATI cards/drivers, I believe, but I haven't
    confirmed this.

    Seems likely to be a Qt bug.

    Should a) reproduce problem with a Geo2k-less test app, e.g. just
    a SoQtRenderArea, b) test with the latest version of Qt, c) if the
    problem is still present, make a test-case for submitting to Troll
    Tech.

    Nasty problem, this, and one which looks very bad for end-users,
    likely to cause many support inquiries.

    20031202 mortene, reported by pederb.

=====================================================================

024 Repaint problem with Qt-3.3.0 (Mac OS X only).

    When using an examinerviewer as a standalone component (like
    e.g. in the SoGuiExamples), only a completely blank window is
    displayed. It's only when the window is resized that the content
    appears. Hiding and unhiding the window doesn't make a difference,
    nor does sending it any events. 

    A temporary workaround for this problem has been committed (see
    FIXME comment in SoQtComponent::show()) but this should really be
    investigated and fixed properly, since whatever is going on here
    may very well result in other problems further down the road...

    20040211 kyrah

=====================================================================

025 Need more 'ivinfo' information

    We should be able to see which version of simage and freetype
    and similar libraries has been detected by Coin.  The simage
    information should also list supported file types / plugin APIs
    in use.  The full path to the actual libraries would also be
    nice to see.  Too often people wonder why textures don't load -
    this would give that answer right away.

    Note: Duplicate bug entry (103) in Coin/BUGS.txt because this
    must be implemented in cooperation between both libraries.

    20040218 larsa

=====================================================================

026 setMinimumSize() ignored on SoQt/Mac

    Doug Epps reported that "a window pops up at some 'default' size
    regardless of 'setMinimumSize ()'. Not verified yet.

    20040624 kyrah

=====================================================================

027 Zooming can cause internal errors.

    Reproduce by doing the following in the standard examinerviewer,
    with e.g. just a cone in it: first zoom in very close, then switch
    camera type from perspective to orthographic, zoom even closer in,
    switch camera type again, zoom closer again, repeat until Coin
    starts spewing out warnings about coplanar points given to the
    SbPlane constructor.

    20040708 mortene

=====================================================================

028 Could improve check to pick up Qt libraries needed for linking.

    An idea from kintel: use ''qmake'' to generate a Makefile from a
    simplest possible .pro-file, and grep for link libraries (and
    other compiler and/or linker option?) in the generated Makefile.

    (I.e. modify simacros/cfg/m4/qt.m4 to use this strategy instead of
    running through a list of known library names, like we do now.)

    20040805 mortene.

=====================================================================
