Re: Bug#426581: meshlab - anyone still working on this
(shortened and with intermixed answers...)
On Fri, Feb 22, 2008 at 10:00 PM, Ian Jackson
<ian@davenant.greenend.org.uk> wrote:
> Paolo Cignoni writes ("Re: Bug#426581: meshlab - anyone still working on this"):
>
> > 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"
Gotcha.
It's a problem of the interacton between QT and your window manager,
On win mac and some other wm this windows do not appear.
the creation code is the following one
void MainWindow::createStdPluginWnd()
{
stddialog = new MeshlabStdDialog(this);
stddialog->setAllowedAreas ( Qt::NoDockWidgetArea );
addDockWidget(Qt::RightDockWidgetArea,stddialog);
stddialog->setFloating(true);
stddialog->hide();
}
I do not know how to patch this. I could ad a SetGeometry to make it
very small, but it seems me a workaroud.
> > > 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.
Yes it is a mess, the whole activation/deactivation mechanism of the
plugins will change
in 1.2.
> > > 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.
ok. np.
I'll do this in this weekend.
>
> > > lintian says:
> > ...
> > 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'.)
>
Ok,
currently if the binary is missing it just report that the exporting
has failed becouse the binary is missing.
Cheers
and thanks again for you help.
Reply to: