Re: Bug#426581: meshlab - anyone still working on this

[Ian Jackson <ian@davenant.greenend.org.uk>]

Paolo Cignoni writes ("Re: Bug#426581: meshlab - anyone still working on this"):
> 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 reply and sorry for the delay in getting back to you.

> 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.

So as a test today I'm running
   meshlab t.stl
where t.stl is a file generated by a prograam of my own.

I get two windows.  One is the main meshlab window which has my object
in in, the various menus, and so on.  That is fine.

The other window is blank, 800x700, at the top left corner of the
screen, and is somehow bypassing the X11 window manager.  xwininfo
says this:

  xwininfo: Window id: 0xc40009b "Plugin"

    Absolute upper-left X:  0
    Absolute upper-left Y:  0
    Relative upper-left X:  0
    Relative upper-left Y:  0
    Width: 800
    Height: 480
    Depth: 24
    Visual Class: TrueColor
    Border width: 0
    Class: InputOutput
    Colormap: 0x20 (installed)
    Bit Gravity State: NorthWestGravity
    Window Gravity State: NorthWestGravity
    Backing Store State: NotUseful
    Save Under State: yes
    Map State: IsViewable
    Override Redirect State: no
    Corners:  +0+0  -800+0  -800-720  +0-720
    -geometry 800x480+0+0

It's basically pale grey.  Looking at it in xmag it's a uniform shade
with rgb = 0xefef 0xefef 0xefef.  A closer examination shows two small
darker squares side by side in the top right corner, coloured rgb =
0xdddd 0xdfdf 0xe4e4.

My window manager is vtwm, in case that's relevant.

I have taken a screenshot of my whole desktop and put it at
 http://www.chiark.greenend.org.uk/~ian/t.2008-02-22/screenshot.png
(this is after I resized the main meshlab window, which usually
starts to fill the whole screen).

> > 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

I think this should be addressed at some point.  If one is not
supposed to be able to drive the program from the menu then there is
little point having the menu item.  Perhaps it would be better if the
menu items (and indeed the other tools in the toolbar) were not greyed
out ?  Selecting them could then go straight from the old mode to the
new.

> > 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.

I don't think this would be appropriate in Debian.  Users would expect
--help to print some information to stdout.  So a simple message with
a URL in it, or some documentation, would be ideal from our point of
view.

> > lintian says:
> ...
>
> I did not fully understand the above, but i hope that i can ignore them :)

These are Debian-specific things which as upstream you do not need to
worry about :-).

> 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*

I think for Debian this isn't critical, if meshlab at least doesn't
crash if the binary isn't found.  Although of course importing u3d
files would be good.

(`NMU' isn't the right term.  You can probably just say `package'.)

Ian.