After I built it (on lenny), I ran meshlab from an xterm. It opened
an entirely blank override-redirect pale grey window covering the top
left area of my display, as well as the main window. What is that
blank window for ? Can it be got rid of ?
This is not a the exepected behaviour. if meshlab is invoked without any mesh it should ask for a file to open with the standard filedialog.
If I ask for `Edit / Measure' I can't get the rest of the edit menu
back without clicking on the measuring tape in the toolbar. I assume
this is unintentional and is an upstream UI bug.
If I run the program with --help or -h, it tries to open them as
files. It ought at least to bomb out with a message saying please
refer to the meshlab wiki (with a URL).
quite a good idea.
if started with -h or --help it could directly open the meshlab wiki by using the defaul os browser.
lintian says:
W: meshlab: menu-item-uses-apps-section /usr/share/menu/meshlab:2
W: meshlab: menu-item-creates-new-section Apps/Technical /usr/share/menu/meshlab:2
W: meshlab: description-contains-homepage
W: meshlab source: debian-rules-ignores-make-clean-error line 38
These should be fixed I think. To get these messages say
lintian meshlab_1.1.0-1_i386.deb
lintian meshlab_1.1.0-1.dsc
and you can get a fuller explanation with `lintian -i'.
I did not fully understand the above, but i hope that i can ignore them :)
Eyeballing the patch I notice an awful lot of
-INCLUDEPATH += ../.. ../../../../sf ../../../../code/lib/glew/include
+INCLUDEPATH += ../.. ../../../../sf
Maybe it would be possible to suggest to prepare a patch for upstream
submission which replaces ../../../../code/lib/glew/include with
$(GLEWINCLUDEPATH) or some such, which would be set in one place.
Likewise various places where glew.c is referred to.
Changing the same thing in many places like this is asking for merge
conflicts in the future.
TRUE. We have to make a bit of order in our .pro files.
In any case i have seen (if i am still able to read diff's) that all the references to glew src code in the plugins have been removed.
they were intentional. I think that this could cause some problem in the various plugins
There are quite a few places where we see things like this
+#if defined(DEBIAN)
+ QDir shadersDir = QDir(QString("/usr/share/meshlab/shaders"));
+#else
QDir shadersDir = QDir(qApp->applicationDirPath());
I'm not sure -DDEBIAN is the right answer here. If possible I would
try to persuade upstream to provide a compilation option for FHS
compliance.
In the same area, I note that you appear to have been slighly careless
with the whitespace in one of these:
- QDir shadersDir = QDir(qApp->applicationDirPath());
-#if defined(Q_OS_WIN)
+#if defined(DEBIAN)
+ QDir shadersDir = QDir(QString("/usr/share/meshlab/shadersrm"));
+#else
+ QDir shadersDir = QDir(qApp->applicationDirPath());
+# if defined(Q_OS_WIN)
Note that the indentation of the the applicationDirPath()-based
initialisation has changed (perhaps due to tab/space conversion). It
is a good idea to be very careful not to do this as it just causes
spurious merge conflicts in the future.
I notice that you had to change two very similar sets of code
initialising a shadersDir. You should submit a patch upstream to move
this into a single function to avoid repetition (if you haven't
already).
Yet another good suggestion. Initialization of application dirs (plugins, shaders, textures) is a mess.
On same OS like macs is rather tricky...
Some cleaning strongly needed here :)
I raise another issue:
U3D. meshlab, to export files into u3d format, needs a binary (idtfconverter), that is compiled out of the u3d open source library.
So i see that here there is another dependency here and perhaps there is the need for someone to NMU
sourceforge.net/projects/u3d
Cheers
and thanks again for your brave efforts.
P.