Home Download News Features Screenshots Documentation Communicate Participate Resources Applications Site Map
The questions:
I found a bug, what should I do?
Why I cannot load my microscope files?
Why C programming language?
Why to use Gtk+ library?
Can I use my own routines with this software?
What about portability to other systems?
Could we use commercial plug-ins?
When it will be finished?
Can I use other graphical library (Qt, MFC) with the program
Why Gwyddion?
Will my plug-ins work with future versions of
Gwyddion?
Will my modules work with future versions of
Gwyddion?
How can I get notified of new releases?
What systems and architectures Gwyddion runs on?
What the strange PSDF values mean?
How do I send large data files to you, do you have a FTP upload area?
I linked Gwyddion with --as-needed and it broke. How to fix it?
Please, report it to Petr.
Also please check it is still present in the latest stable version. You will be likely asked to upgrade if you report a bug in an old version.
If your microscope native files are not supported yet, you can write a IO plugin by yourself or you can contact us and send us your format specifications and some data.
If your format is supported but you have problems with file loading, report it as a bug (we will need the problematic file to fix it).
There is page describing the file format situation in details.
The core and modules is written in C language.
This language was chosen as it is well known and widely spread, there are many important libraries that could be used (Gtk+), and it's relatively easy to bind C function to other languages. The plugins can be written in C, C++, Perl, Python and maybe more. The simplest ones can be written in almost any language.
The Gtk+ graphical library is used because of its licensing, portability and capabilities.
Yes, you can make a plug-in very easily from your software. This is one of the main goals.
Roughly said, you just need to use the specified data recieveing and sending back to the program. Then you can use your software routines as a plug-in inside the program. If you want, you can take more time programming it as a module so that everybody will be able to use your functions.
The high portability will be respected within the core and modules. The system will be developed and tested under Windows and GNU/Linux operating systems but all the libraries can be used also in many more systems. Therefore it can be ported relatively easily.
Yes you can. You can use a plug-in with other than open source license. However, such a plug-in can't be official part of the program, but can be distributed separately.
As the system should be framework for developement and share of new analytical methods, everlasting continuous developement is expected.
Yes you can do it in a form of simple plug-ins. But note, that with using some libraries (MFC) you may produce code that is not portable. This is not problem if you use code for you own, but you might be in a problem when you want to share your plug-in with someone.
Please see explanation.
Yes, virtually forever.
Even if a decision was made the current plug-in system is so bad that a new one must be designed, Gwyddion architecture would allow the old and new plug-in system to coexist, and the current would be kept for compatibility with existing plug-ins.
Note: The plug-in system is considered ill-designed. While this does not mean the plug-in support will disappear soo, certainly it will not disappear before Gwyddion 3.0, it is not the preferred method to add routines in other programming languages any more and it cannot be expected to be further developed. Better alternatives can be language bindings, such as pygwy, or writing a small C wrapper module specific for your language and problem domain, i.e. a kind of small specialized plug-in proxy that interfaces your routines the way you prefer.
Yes, under normal circumstances.
Modules are bound to Gwyddion more tightly than plug-ins, so a substantial change in it may break compatibility. Normally, all new versions are both source and binary level compatible with previous ones and modules linked against old versions work even with the newest one.
Gwyddion 2.0 is neither binary compatible (so modules have to be recompiled) not source compatible (so beside recompilation, some changes in module code are necessary) with 1.x versions. But all 2.x version will be backward compatible with other 2.x versions again.
Actually, there already was a one unplanned incompatible change, in version 1.3, where a serious bug present in previous versions could not be fixed while retaining compatibility. This should not happen again.
If you are a Freshmeat.net user, you can subscribe to project Gwyddion (there's a Subscribe to new releases link near the bottom, you have to log-in to subsrcibe).
If you are a SourceForge.net user, you can subscribe to project Gwyddion (see the envelope icon in Latest file releases section, you have to log-in to subsrcibe).
SourceForge also offers a RSS feed, although this method is probably a bit silly.
OS-wise, Gwyddion is known to work on GNU/Linux, Microsoft Windows, Mac OS X, and FreeBSD. Architecture-wise, it has been tested on i386, AMD64, and PowerPC. It should work on any Unix-like system where Gtk+ and other dependencies work.
Most probably you are looking at the PSDF method of fractal dimension estimation. It uses a log-log plot with arbitrary shifts and scale. Use the statistical functions tool to obtain PSDF in absolute units.
The x axis units are then lateral_unit-1 and y axis units lateral_unit × value_unit2. The normalization corresponds to the PSDF expressions for various surfaces that can be used to fit rms and autocorrelation length of rough surfaces in graph fitting.
Unfortunately, we do not have any public FTP upload space. The preferred method of sending large files is to upload them to a location of your choice and send the URL. Such a location should be generally available in the academic world, you can also use one of the many free file hosting services.
Not preferred, but also possible is to send files by e-mail. In such case compress the files with bzip2 or zip. First, it often reduces their size considerably. Second, e-mail clients sometimes fail to detect that files contain binary data (often this occurs for Nanoscope or WSxM files) and they send them as text which makes them subject to various irreversible manglings. This is especially a problem on MS Windows where text and binary files are handled differently. Compressed files are usually recognized and sent correctly.
Please do not send large files to the mailing lists.
--as-needed and it broke. How to fix it?Contrary to the popular belief linking with --as-needed would
make Gwyddion slow and bloated, not more efficient. So the short answer is:
you fix it by not linking with --as-needed.
On platforms that support it, and that means at least all modern Unix
systems, the main application is linked with some “redundant” libraries
and modules are not linked with anything (unless they need a specific extra
library). Symbols in modules are resolved from the libraries the main
application was linked with. Obviously, --as-needed makes this
optimization impossible and every module would have to be linked with all
libraries it requires – this would be less than the full set of libraries,
but still much more than none. It would take more time to build (even 2×)
and install (almost 10×), it would start more slowly (module loading time
increases 2×).