n3roaster / typica Goto Github PK

There are a few possible ways to deal with this.

At present Typica is written in such a way that the usual text translation tools do not work very well. Fixing this is essential to getting Typica translated for international use.

On the project web site I said that I'd put an about box in with a section thanking anybody who provided financial support to the ongoing development of Typica. This happened today so an about box is now required to provide this.

There are many areas where profile loading can be optimized. Things to consider:

1. Drawing code on some platforms is slow. Would deferring graph drawing until all data has been loaded improve anything?
2. Can the measurement model be improved?
3. Can those modifications be made in such a way that proxy models become a realistic option for handling varying table view granularity?

The last in particular makes certain requested features much easier to implement.

Part of this transition will need to wait until Typica switches to Qt 5 unless the new connection syntax is back ported to the 4.x series. By the time Typica 2.0 is released, compiler support for C++11 should be much improved.

This will improve application startup time and keep Typica responsive during complex report generation.

What subset of records would be most useful to start from? How do we make it clear that it is possible to dig up other data? Is this even the best solution to the underlying problem that as the batch history increases in size it takes longer to pull up the complete set of records?

This mainly affects SQL, already covered in #21, and National Instruments hardware initialization. The latter potentially improves responsiveness in opening the logging view.

Current release versions of Typica have all code (aside from that brought in through third party libraries) in a single file (typica.w, processed into typica.cpp). When writing new code, consider splitting this out into multiple .w source files (remember to @i the file in typica.w) and use @(@> chunks to split output to multiple .cpp and .h files. This allows multiple translation units to be built in parallel, improving compilation time, and opening the possibility of further optimizations of the build process. It might also make it easier to find the appropriate portion of the code when changes are needed without consulting the PDF version of the source documentation.

By version 2.0 old code should be fully broken apart in this way.

The configuration prompt is one of the largest sources of support emails. I don't understand what is so challenging about it personally, but this has been established empirically. With ongoing development the use cases for the current configuration system have been reduced and should continue to be reduced and this portion of the application should change to reflect that. The ability to run custom configurations must be retained, however Typica should start with a sane default to help people new to the program or people who forget to point new versions at new configurations get started more quickly.

This appears to be a bug in Qt/WebKit, but if it is possible to work around the issue in Typica, we should.

The current graph widget is too inflexible for planned features. Are any third party graph widgets license compatible with Typica and architected suitably for Typica's use cases?

The instruction manual should be available from the Help menu. Additional forms of in program help should also be provided wherever appropriate.

Currently National Instruments hardware, Modbus RTU hardware, and test data sources are handled in separate class hierarchies exposing a common interface. There is room for improvement in code cleanliness and in making it easier to extend hardware support to additional device classes if this is cleaned up.

While the DATAQ SDK will support both the DATAQ DI-145 and DI-148U, it only works on Microsoft Windows. There is serial protocol documentation for the DI-145 (but not for the DI-148U) that would allow this hardware to be used with Mac OS X or Linux and it is likely that this could also be used to improve reliability under Microsoft Windows.

An Ubuntu PPA is planned for distributing Typica versions 1.5 and later. A .desktop file will be needed and there may be other issues that need to be resolved to make distribution on Linux easier.

Currently building Typica from CWEB source requires renaming the generated typica.c file to typica.cpp. It is very easy to forget to do this and test builds that do not incorporate the latest changes. The auto-generated typica.c file should be a stub with its current content pushed from a @(@> chunk.

Typica already includes some icons from Tango. These should be used in all appropriate places.

Scroll bars are required to handle deep hierarchies (not that such configurations are recommended but they are possible) and configurations that travel among several different machines (also not particularly ideal, but this is a situation that exists).

The Measurement class is too inflexible to keep up with planned features. Replacing this with QVariantMap will make it much easier to add new capabilities to the measurement pipeline as well as making it easier to work with measurements from QtScript or QML. This will require modifying all classes that currently work with Measurement objects.

This is more a complete overhaul of the existing configuration system, moving more into C++, building out a more complete preferences window, and maintaining hooks for scripts to use.

This can be fixed by using std::chrono::steady_clock to measure roasting time as soon as standard libraries on major platforms have conforming implementations. Until then, platform specific workarounds will be required.

Currently this report has sacks purchased, pounds purchased, and cost as the rows and each year as a column. The rows should instead be the columns and each year should be a row.