File: BUGS.txt

package info (click to toggle)
soqt 1.6.0~ea5cd76+ds1-1
  • links: PTS, VCS
  • area: main
  • in suites: buster, sid
  • size: 11,056 kB
  • sloc: sh: 11,393; cpp: 8,650; makefile: 8,649; perl: 863; ansic: 329
file content (918 lines) | stat: -rw-r--r-- 31,000 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
=====================================================================
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.

    UPDATE 20050621 mortene: some additional information from pederb,
    in a support reply:

        You might run into problems if you're using SoQt, since Qt's
        QTimer isn't (or at least wasn't) thread safe. If you change
        something in a thread that causes some sensor to trigger,
        SoSensorManager will make a callback into SoQt, which will set
        up timers (QTimer) to process the sensor queues. Creating
        QTimers in some other thread than the main thread isn't
        possible in Qt.

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

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.

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

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

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

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.

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

029 Window id element is missing

    Make SoHandleEventAction, SoGLRenderAction et al set the a window-
    specific window id element before traversing the scene graph.

    20040831 larsa.

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

030 SoQtRenderArea::setRedrawPriority(0) bug

    Does not work as expected.

    20040831 larsa.

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

031 Generated .DSP/.DSW files for MSVC IDE-based build have
    dependencies on the Qt version number they were made with.

    This is a fairly large generator of support requests and
    frustration among external users and first-time testers of Coin,
    so consider this a high priority item.

    20040901 mortene.

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

032 SoQt-based applications will crash on exit with recent Qt-version.

    With at least Qt 3.3.1, this will now crash under Windows:

----8<------ [snip] ------------------8<------ [snip] ---------
#include <Inventor/Qt/SoQt.h>

int
main(int argc, char ** argv)
{
  SoQt::init(argc, argv, "hepp");
  return 0;
}
----8<------ [snip] ------------------8<------ [snip] ---------

    The crash happens on exit, somewhere within the Qt DLL.

    I've tracked the problem down to this: if a QApplication instance
    is made within SoQt (as it will be whenever a QApplication has not
    explicitly been made from the application code), the crash will
    happen -- otherwise not.

    My first guess at a cause would be that something goes very wrong
    when memory (for the QApplication) is allocated in one DLL (SoQt)
    and deallocated in another DLL (Qt). So this is most likely our
    old foe "separate C Run-Time heaps" causing confusion and mayhem
    yet again.

    According to thammer, the bug does not show up on his dev-system,
    using the same CRT for everything. Anyway, we should handle the
    case of different CRTs for different libs.

    Unsure how to solve this yet. One option to check is whether it is
    possible to call some function in Qt which will implicitly make
    the QApplication instance for us (within the Qt DLL). Not a
    perfect solution, though, as that makes it impossible to inherit
    and override QApplication, as we do now, to install an event
    handler for e.g. spaceball devices. That could however perhaps be
    solved in some other manner.

    This should be considered high priority, close to critical,
    something which should trigger a new SoQt-release (patch/micro
    level) when solved.

    20040921 mortene.

    UPDATE 20040921 mortene: note that the bug in question should be
    considered a bug in *Qt*, BTW: they are deallocating an instance
    which they don't know for sure that they allocated -- which spells
    b-a-d. This problem could easily be fixed by Troll Tech by using a
    flag to remember whether or not the global QApplication was
    instantiated inside of Qt or not, then only deallocate it on exit
    if this flag was "true".

    UPDATE 20040922 mortene: as noted by pederb, this may not be the
    cause. It seems like memory allocated through the C++ "new"
    operator for new class instances is done within the DLL of the
    class's implementation. I.e. when calling "new QApplication", the
    memory allocation actually happens within the Qt DLL's heap, and
    not the one in SoQt.

    (If it were not like this, we would run into trouble with
    e.g. SoQt or application code new'ing a Coin node -- as Coin nodes
    are always deallocated from within the Coin DLL by "delete this".)

    So I'm a bit baffled about what the exact reason for this bug is.

    UPDATE 20041003 mortene: investigated more. The crash happens
    before the QApplication instance is deallocated, actually, so
    something else is going on.

    I tried to reproduce with an SoQt- and Coin-free stand-alone test.
    The DLL + EXE below crashes when the DLL is built with a different
    CRT than the Qt DLL we're linking against. Here are the source
    code parts of the test system:

    Header-file for DLL, "dll.h":

--------8<------------ [snip] -------------------------------------------
class QApplication;

#ifdef MAKE_DLL
#define MYDLL_API __declspec(dllexport)
#else
#define MYDLL_API __declspec(dllimport)
#endif

class MYDLL_API MyDLLClass {
public:
  static QApplication * my_dll_function(void);
};
--------8<------------ [snip] -------------------------------------------

    Implementation of DLL, "dll.cpp":

--------8<------------ [snip] -------------------------------------------
/*
  Build with e.g.:

  $ cl.exe /DMAKE_DLL /I$QTDIR/include /LD dll.cpp $QTDIR/lib/qt-mt331.lib
 */

#include "dll.h"
#include <qapplication.h>

QApplication *
MyDLLClass::my_dll_function(void)
{
  int argc = 0;
  return new QApplication(argc, NULL);
}
--------8<------------ [snip] -------------------------------------------

    Application-code, "app.cpp":

--------8<------------ [snip] -------------------------------------------
/*
  Build with e.g.:

  $ cl.exe app.cpp /I$QTDIR/include dll.lib $QTDIR/lib/qt-mt331.lib
 */

#include <stdio.h>
#include <qapplication.h>
#include "dll.h"

int
main(void)
{
  printf("qApp==%p\n", qApp);
  QApplication * a = MyDLLClass::my_dll_function();
  printf("a==%p, qApp==%p\n", a, qApp);
  return 0;
}
--------8<------------ [snip] -------------------------------------------

    This should probably be reported to Troll Tech -- after first
    checking that the problem is still present with the latest
    Qt release.

    I then built Qt in its debug configuration, to get something
    sensible out of the call stack. Here are the results when running
    inside MSDEV V7's debugger (this is with Qt 3.3.1):

    0  QObject::~QObject()
                => crashes in "if ( parentObj )\n parentObj->removeChild( this ) "
    1  QFontCache::~QFontCache()
                => runs through to end of destructor
    2  QFontCache::`scalar deleting destructor`()
    3  QSingleCleanupHandler<QFontCache>::~QSingleCleanupHandler<QFontCache>()
                => from "delete *object"-line
    4  [CRT iterating over _onexit() / atexit() functions]



    UPDATE 20041027 mortene: according to kintel, Qt has a global
    function qAddPostRoutine(), which is called when QApplication
    dies. I mention it since it may be possible to utilize that for a
    work-around in some way.

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

033 Sensor handling incorrect

    This SoGui library has its own delayqueue timeout timer.
    This will cause delayqueue timeouts to trigger twice since Coin
    handles this internally as well.

    In addition, the code should be reviewed for bugs related to
    assumptions on when the global field is updated in Coin
    (the global field is updated after SoSceneManager::render(),
    not after SoSceneManager::redraw() as was the case earlier.

    I suspect further bugs to surface when the issues above are fixed,
    so a thorough code review should be performed.

    See the Sc21 source code for en example of how this should be done.

    20040921 kintel.

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

034 setSize() for anything inheriting SoQtViewer doesn't work as
    expected.

    For the stand-alone example below, *none* of the 3 "#if 0 // BUG"
    have the desired effect when enabled -- the window size defaults
    to ~ 640x400 no matter what:

--------8<------------ [snip] -------------------------------------------
#include <Inventor/Qt/SoQt.h>
#include <Inventor/Qt/viewers/SoQtViewer.h>
#include <Inventor/nodes/SoCone.h>

// *************************************************************************

class MyViewer : public SoQtViewer {
public:
  MyViewer(QWidget * parent);
};

MyViewer::MyViewer(QWidget * parent)
  : SoQtViewer(parent, NULL, TRUE, SoQtViewer::BROWSER, FALSE)
{
#if 0 // BUG
  this->setSize(SbVec2s(1024, 800));
#endif

  this->setClassName("MyViewer");
  QWidget * viewer = this->buildWidget(this->getParentWidget());
  this->setBaseWidget(viewer);
}

// *************************************************************************

int
main(int argc, char ** argv)
{
  QWidget * window = SoQt::init(argv[0]);

  MyViewer * viewer = new MyViewer(window);
  viewer->setSceneGraph(new SoCone);

#if 0 // BUG
  viewer->setSize(SbVec2s(1024, 800));
#endif

  viewer->show();
  SoQt::show(window);

#if 0 // BUG
  viewer->setSize(SbVec2s(1024, 800));
#endif

  SoQt::mainLoop();

  delete viewer;

#ifdef __COIN__
  SoDB::cleanup();
#endif // __COIN__

  return 0;
}

// *************************************************************************
--------8<------------ [snip] -------------------------------------------

    20041130 mortene.

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

035 "Animating Drawstyle" == "no texture" has no effect.

    ...when "Still Drawstyle" == "as is".

    This is probably an error common over all So* toolkits.

    Low priority item.

    20041207 mortene.

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

036 Simple timers in Qt will be taken out for Qt 4.

    ..so we shouldn't use them any more, as we now do in
    SoQt/src/Inventor/Qt/SoQt.cpp, ~line 300.

    I think the best thing to do would be to work around the Qt timer
    issues by using Win32 timers directly if feasible.

    High priority item.

    20041213 mortene.

    UPDATE 20051110 mortene: the timers seems to work just fine in Qt
    4, without any need for the internal Qt flag for simple timers to
    be set to ''false''. So this bug ticket can probably be killed.

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

037 Qt 4 support has various problems.

    This is the current list of issues to fix or look into before we
    can reasonably say that Qt 4 is properly supported:

    - Get rid of Q3PopupMenu-use in QtNativePopupMenu, since it's the
      sole reason that we still have to link against the Qt3Support
      library.

        => frodo & mortene believes this is best done by splitting the
           QtNativePopupMenu class into both a Qt-3 and a Qt-4 version

           (and before doing that, audit the code in
           QtNativePopupMenu.cpp to see if some of that can be moved
           up into the toolkit-neutral superclass first)

    - In the RMB popup-menu, clicking on already selected sub-menu
      does not bring up its sub-sub-menu.

    - SoQt/configure Qt 4 detection and setup on MS Windows. (Fix in
      simacros/cfg/m4/qt.m4.)

    - The SoQtFullViewer-derived viewers' thumbwheels are thicker (at
      least when horizontal).

    - The SoGuiExamples/component/simpleexviewer comes up with a
      different default size than with Qt 3. (Note that it may be Qt 3
      which we're buggy with -- sizing and resizing has been a
      long-standing problem in various ways.)

    - Have a look at bug issue #036. Only relevant for MS Windows.

    - Needs more testing! Check SoQtRenderArea, the other
      SoQtFullViewer-derived viewer classes apart from the
      SoQtExaminerViewer, and any features we can think of.

    20050630 mortene, updated 20050802 kyrah.

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

038 configure Qt-check doesn't find 64-bit libraries.

    We only look in $QTDIR/lib, but 64-bit libraries are typically
    found under $QTDIR/lib64, and we don't handle the case where these
    are the ones wanted for the build.

    Not sure how this should be handled properly.

    20060307 mortene.

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

039 Render Buffer Type ignored on Mac OS X

    Reported by kintel on 20060404:

      Switching between single, double, interactive buffer doesn't
      seem to work under Mac OS X (see context menu: Draw Styles ->
      Render Buffer Type).

    Since with early versions of Qt/Mac, it was hard to get _any_
    kind of correct OpenGL rendering working at all, there might
    be some hacks in SoQt that need to be cleaned up. Need to
    investigate this further.

    20060405 kyrah.

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

040 soqt-config weaknesses under Mac OS X

    soqt-config --build-app:
    o Missing documentation
    o Not possible to specify multiple source files
      (e.g. soqt-config --build-app executable source1.cpp source2.cpp)

    20070123 kintel.

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