Hi to all, I am a bit ignorant about debian package creation so be patient with my naiveness :) I would try to help as I can. My comments intermixed below. (Thanks for your effort!)
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. > ahem . probably it is not a very intuitive pattern of action but eventually it was intentional http://meshlab.sourceforge.net/wiki/index.php/Interactive_editing_tools > 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.
