When will the next release be?

I rarely put dates on releases. My current development plans are outlined on the Development Status page. If there is an anticipated release date, it will be listed there. If you want to be notified of new releases, you can subscribe to the misfitmodel3d-announce mailing list--see the Mailing List page for details.

Are you planning to implement feature X?

Check the Features page and see the "Development release" section for the next release. If you do not see the feature you want listed there you can go to the Bugs page to submit a feature request (RFE), or you can go to the Contact page to email me.

Can you make a filter for format X?

See the notes on Requested Formats.

Does MM3D support Qt 4.x?

Yes. MM3D can be built with Qt 4.x using the Qt3 compatibility layer. MM3D will be completely ported to Qt 4.x around the time that KDE 4.0 is available.

On Windows, Qt 4.x is the only supported version. On Unix-like systems (Linux, FreeBSD, Mac OS X), Misfit Model 3D will not auto-detect the presence of Qt 4. However, it will compile and link with Qt 4 if you explicitly tell ./configure to do so using the --with-Qt-dir command line option.

See the Install page for details.

I have Lua installed but MM3D is not detecting it. What is wrong?

MM3D requires Lua to be built as a shared library. The default Lua build configuration does not build shared libraries. Recent versions do not even have a build rule for shared libraries. This dependency was causing problems for a number of users so I have disabled Lua support by default. While Lua support is still present, feature is no longer maintained and may be removed in a future release. For now if you want to re-enable it see the lua configure options by running:

./configure --help

I have some code changes I would like to submit to you. How can I send you my changes?

If your changes are a new tool, command, filter, or other set of self-contained files, you can simply create a zip archive or tarball and email those files to me.

If your changes are modifications to existing files, the best way to send changes is by sending a unified diff to me in email. In your email, be sure to include a description of what the patch does. Also note which version of the source code you made your patch from.

If your change is to a single file, make a copy of the original file, use the Unix diff utility to compare against the modified file, and redirect the output to a patch file. The following example compares file.cc.bak to file.cc and saves the results to patch.diff.

diff -up file.cc.bak file.cc > patch.diff

If your change is to multiple files, make a copy of the entire src directory after you have successfully built the program. Make your changes and then use diff to compare the original src directory against your new src directory. In the example below, the original src directory is src.bak.

diff -urpN src.bak src > newpatch.diff

It is a good idea to compress the patch with zip or gzip before attaching it to your email, though this is not required.

Why do you provide a binary version for Windows but not for other platforms?

In general I avoid providing binary releases because I do not have time to test them thoroughly. For Linux and FreeBSD ./configure works well and users are familiar with this as an install process. I make an exception for Windows because it is easier to provide an installer than it is to help people through the Windows build process.

I can create a binary build for [Linux Distro]. Would you like me to send it to you?

Software hosted on Misfit Code or Source Forge needs to be supported. That means either I must have the time and capacity to support it, or I need to be able to rely on a contributor to support it. I cannot host 3rd-party binaries until a contributor has a demonstrated track record with timely, reliable releases. However, I will link to 3rd-party binaries from Misfit Code.

My policy on binary packages is this:

1. If it's a one-time offer for a specific version, I will not accept the package.
2. If a contributor is interested in maintaining regular binary builds I can create a section on the download page that would direct users to content hosted by the contributor. I do this with Mac OS X binaries and it seems to work well.
3. If binary builds are in high demand and consistently available in a timely manner I would consider adding them to the Source Forge downloads page. This also means the contributor needs to be able to support users who have package-specific problems.

This policy is all about managing user expectations, which helps avoid frustration for them and for me. If you are interested in hosting binaries on an ongoing basis, contact me and we can discuss specifics.

I'm having problems with the Mac OS X port. What is up with that?

I do not have access to Mac OS X at all. Any support for OS X is done through patches from other OS X users or by getting feedback and attempting to debug issues by proxy. Mac OS X support is still experimental so if you are running into problems you can try to contact me to help get them resolved. It is probably best to send emails to the developer's mailing list since I may not be able to help you directly.

If your problem is a build problem (you cannot get MM3D to compile) try getting a 3rd-party binary version.