<snip, possibly move "math3d" folder out-of-"QtGui">
charley spaketh: > <snip, need not-coupled-to-GUI domain-specific math3D stuff> > > (We currently have our own 2D and 3D math libs, but if Qt had a non-GUI > coupled lib, we could use it.) > Thiago respondeth: > Can you tell me whether those classes would suffice to your needs? > Inside "math3d" I see some "qvector") stuff (2d, 3d, 4d), a "qgenericmatrix", "qmatrix4x4", and some math-utility stuff (2d, 3d). Short answer: Yes, we could use this. Some Qt stuff is "better" than our home-grown stuff (like "fuzzy-compare" and other "quaternion" stuff -- we didn't do that, we are mostly "Cartesian", but expect to need more transform-stuff as we move to OpenGL, and we would prefer to not write that). Both Qt and ours should both be cross-platform, but Qt is proven and ours is not, so that would be in-Qt's-favor. We have a domain-specific need for "2DMatrix-inversion", which isn't yet supported by Qt, but that's easy enough to add (just standard matrix-math-inversion). (There's a "special-case" where some 2D matrixes cannot be inverted, and we had to handle that, so it would be nice if Qt's implementation dealt with that too. There's another special case where you can "fiddle" with a cannot-be-inverted matrix to make it "invertible", and it would be nice if Qt's implementation did that too.) But, worst case, we could use Qt's class and have an external algorithm do that inversion. (I'll also check at work to see if we can contribute that code, maybe, I don't know.) However, the "biggest-advantage" that I see for us to move to Qt's classes would be for us to *avoid* the marshaling-to-a-different-data-structure when interfacing with Qt's GUI or other modules (e.g., exposing Qt-classes as bound-properties to QML), so that we don't keep copy-constructing "QVector3D" from "MyVector3D". There's not really anything "special" or "clever" in our code, we just needed it throughout our model. So, it would be nice to have one-set-of-point-and-line-and-vector-and-matrix-types. If it didn't really "fit-in" to the "QtCore" (I see your point), I'd probably vote to put it into a "QtGeometry" (or "QtGeometry3D"). Even if it's currently "small", I expect it would grow -- it would be nice to have a package where we could "dump" new algorithms that are generally useful. For example, (our domain again), we deal with *lots* of N-dimensional parametric data. There are *tons* of generic-algorithms that are useful to identify populations, establish bounds on data sets, perform "smoothing", compute population-and-data-set-statistics, perform transforms, establish "contours", etc. We have algorithms for all of these on 1D and 2D and some 3D, and are moving more into N-D. Any of these algorithms could be interesting/relevant to a number of applications, from mere GUI-manipulation, to audio-data-sets, to "edge-detection", to GIS/Spatial-data-analysis/Remote-Sensing, etc. (Our domain uses them for biology/cell-populations.) For example, it would be nice IMHO for "QVector2D" to have even-basic-stuff like "min", "max", and maybe "mode". For our domain, we live-and-die on "CV" and "Standard Deviation", so if those had to be "external" to QVector, that's ok. (We compute all stats through one-pass-through-the-matrix, and it is incredibly fast.) However, QVector2D already supports addition-and-subtraction-and-scaling (we need those), so it's useful now. (Hmm... QVector2D is based on "qreal", would be nice if we had an "integer" option, as we often "increment(x,y)" when they represent "2D-histograms". Ours are all implemented as templates. But, we could go-all-floating as long as the performance was there.) I'm not sure where Qt/QML is at-the-moment with "handwriting-recognition" or "stylus-input" (e.g., "gestures-algorithms"), but those types of gesture/stroke-analysis would also lend-well to 2D data-set-algorithms (usually 3+D, as one must deal with stylus "pressure" and "velocity" in addition to the 2D surface). I don't mean to "explode" this topic. However, my selfish goal would be: (1) "GUI-Model-Reflection" -- Generic math/geometry data structures *not* coupled-to-GUI, but which are the same physical types *used* by GUI. Then, the GUI would merely "reflect-the-model-directly" (e.g., no marshaling-to-different data-structures.) (We did this in the past in MFC, amazingly fast, I can elaborate if people are interested.) (2) "Out-Of-The-Box-Basics" -- Generic math/geometry algorithms to manipulate/transform/compute-stats (just basic stuff would be great, some of that is already present through "fuzzy-compare" and "rotateVector", etc.). ...and it would be simple for users to extend with their own domain-specific algorithms as-needed. But, we could "share" algorithms more, as IMHO most "domain-specific" algorithms are actually generically-useful algorithms that are surprisingly applicable/relevant to completely-unrelated domains. For example, I've personally implemented some very-rich "typesetting" libraries. However, when it comes-down-to-the-details, the "heavy-lifting" is actually something that looks a whole lot like QLayout in what it's trying-to-achieve (e.g., most math algorithms are generically useful/interesting). --charley
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development