On Jul 9, 2012, at 11:44 AM, ext Uwe Rathmann wrote:
> On 07/09/2012 11:30 AM, Thiago Macieira wrote:
>> But we need to explain the difference between QPointF / QVector2D and
>> QPointF3D
>> and QVector3D. A point's coordinates are equal to that of the vector pointing
>> to the point in question
On 07/09/2012 11:30 AM, Thiago Macieira wrote:
> But we need to explain the difference between QPointF / QVector2D and
> QPointF3D
> and QVector3D. A point's coordinates are equal to that of the vector pointing
> to the point in question from the origin of the coordinate system.
>
> Laszlo, you're
On segunda-feira, 9 de julho de 2012 08.44.17, gunnar.sle...@nokia.com wrote:
> The integer QPoint was used throughout Qt for mouse events, drawing and
> widget geometry. It makes sense. I do not see the same for an integer 3D
> point, but Thiago gets to decide
I think it has value, so I will allo
On Jul 9, 2012, at 8:55 AM, ext Laszlo Papp wrote:
>
>> And how useful is really the integer version? There is almost no 3D math
>> that works with integer only arithmetics.
>
> If there is a point representing 2d with integers, I do not see the
> problem with having the analogy for 3D. Please
On Mon, Jul 9, 2012 at 7:55 AM, Laszlo Papp wrote:
>> The float version is a simplified duplicate of QVector3D. Is this really the
>> right way to go?
>
> You should really consider in QtGui to use 3D point base in the
> future, and extend that with your math wishes.
Not to mention, it is the sa
> The float version is a simplified duplicate of QVector3D. Is this really the
> right way to go?
You should really consider in QtGui to use 3D point base in the
future, and extend that with your math wishes.
> And how useful is really the integer version? There is almost no 3D math that
> work
On Jul 8, 2012, at 8:40 PM, ext Laszlo Papp wrote:
>> Okay, I will try to put up something soon with WIP then, based
>> somewhat on the current QPoint(F) implementations. I will also double
>> check the Qwt needs in order to make sure we fulfill those as well.
>
> I am sorry for the delay with t
> Okay, I will try to put up something soon with WIP then, based
> somewhat on the current QPoint(F) implementations. I will also double
> check the Qwt needs in order to make sure we fulfill those as well.
I am sorry for the delay with this, but I have not had stable internet
connection recently,
> I don't see a problem with a QPoint3D and QPointF3D class in QtCore, in
> Qt 5.1, provided you also fix any ambiguities with QVector3D's existence.
Okay, I will try to put up something soon with WIP then, based
somewhat on the current QPoint(F) implementations. I will also double
check the Qwt n
On 07/06/2012 07:54 AM, Laszlo Papp wrote:
> In any case, I would call for QPointF3D (and similarities) again.
Qwt offers this implementation:
http://qwt.svn.sourceforge.net/viewvc/qwt/trunk/qwt/src/qwt_point_3d.h?revision=1083&view=markup
The fact that QwtPoint3D exists shows, that QVector2D i
On sexta-feira, 6 de julho de 2012 06.54.19, Laszlo Papp wrote:
> > But you failed to indicate how you'd address the main issue of it using
> > float, which leads me to believe you did not do a thorough investigation
> > of the API and the internals before you made your proposal.
>
> To be fair, I
> But you failed to indicate how you'd address the main issue of it using float,
> which leads me to believe you did not do a thorough investigation of the API
> and the internals before you made your proposal.
To be fair, I have already asked twice without getting *any* replies:
what about QPoint
On sexta-feira, 6 de julho de 2012 02.39.14, Laszlo Papp wrote:
> > Yes, it might be a sad conclusion for your project, but it is probably a
> > happy conclusion overall.
>
> As far as I see, way more people wanted to have more in common as a
> collaborative way than not.
Which is irrelevant becau
> OpenGL, Audio 3D, QtSensors, Qwt, and others are not really just "my
> project" who spoke up to have something common.
To be fair, "my project (just a Qt add-on)" is a bit misleading
"qualifier". Ideally, a library (also this one) would be used by many
applications. So any hard coded decision wo
> We've long stopped discussing your project. The moment you suggested making
> this a Qt feature, we stopped talking about your needs and we started talking
> about everyone's needs. I expect you to come up with and consider a reasonable
> set of use-cases when proposing Qt classes or a Qt module.
On quinta-feira, 5 de julho de 2012 19.39.37, Laszlo Papp wrote:
> Like I said, we have used that about two years ago when I first took a
> look at that, and not feasible for my project from what I can say. See
> the previous emails about that.
We've long stopped discussing your project. The momen
> Sure, mplayer, mpd and /many/ other command line based multimedia
> applications use that... With your thinking, there is almost no need
> for things like kdecore since almost any kde applications are UI
> based...
I would agree with that, it is not a common case, but you would not
even be able
> I didn't say anything about there being an outside library. I'm simply saying
> that, as the QtCore maintainer, I do not want those classes in QtCore. The
> only thing I said about "other modules" is "please check Eigen first".
Like I said, we have used that about two years ago when I first took
On quinta-feira, 5 de julho de 2012 17.00.36, Laszlo Papp wrote:
> > No, that's not my thinking. I said nothing of that, so please don't
> > attribute
> those things to me.
>
> That is exactly what you have said. I mentioned that there could be a
> shared and collaborative solution (not necessarily
> No, that's not my thinking. I said nothing of that, so please don't attribute
those things to me.
That is exactly what you have said. I mentioned that there could be a
shared and collaborative solution (not necessarily QtCore like I said
many times) outside QtGui (similarly to kdecore, kio-core,
On quinta-feira, 5 de julho de 2012 16.31.31, Laszlo Papp wrote:
> Also, why would I look into a more difficult API with a lot of
> features around I do not need, especially if we already have a good
> deal of work done in Qt? Again, I prefer the Qt ecosystem. Perhaps, I
> am wrong about that, espe
On quinta-feira, 5 de julho de 2012 16.35.52, Laszlo Papp wrote:
> > Talking about your case in specific: multimedia applications often have a
> > GUI. So using QtGui is not a big deal. As I said, 99% of the
> > applications do use QtGui anyway, so moving the classes into QtCore does
> > not buy y
> Talking about your case in specific: multimedia applications often have a GUI.
> So using QtGui is not a big deal. As I said, 99% of the applications do use
> QtGui anyway, so moving the classes into QtCore does not buy you much.
Sure, mplayer, mpd and /many/ other command line based multimedia
> Either you haven't looked at Eigen, or you haven't understood it.
You can say that these are wrongly packaged things, but it is an
additional dependency for getting things built on gentoo (and source
distributions in general) anyway:
http://www.archlinux.org/packages/extra/any/eigen2/
Also, why
On quinta-feira, 5 de julho de 2012 14.32.33, Laszlo Papp wrote:
> Aye, so much for collaboration! Let me duplicate 9X% of those classes
> so we can maintain from two places. We can surely afford this since we
> are a manpower army (especially looking forward in the near future
> with this Nokia ch
On Thursday 05 July 2012 14:08:45 Laszlo Papp wrote:
> Using eigen for managing some coordinates sounds utterly overkill.
Either you haven't looked at Eigen, or you haven't understood it.
Christoph Feck (kdepepo)
KDE Quality Team
___
Development mailing
> If we move these classes out of QtGui and into a math library and then QtGui
> still needs to link with that library as the classes are used there. If we
> then start adding more domain specific classes to this math library, then the
> stuff that a plain UI would drag in also increases, even t
On Jul 5, 2012, at 2:08 PM, ext Laszlo Papp wrote:
>> I understand it's useful for you, but other people who might use the
>> functionality said it isn't and they'd need more. That means I've got a
>> single
>> use-case to consider (yours) and I'm not convinced that this is worth the
>> moving.
> I understand it's useful for you, but other people who might use the
> functionality said it isn't and they'd need more. That means I've got a single
> use-case to consider (yours) and I'm not convinced that this is worth the
> moving.
Like I said, we agreed about that, you are totally against m
On quinta-feira, 5 de julho de 2012 11.40.04, Laszlo Papp wrote:
> > No, we're not. I asked if the classes were enough and the answer I
> > received
> > was that they aren't.
>
> I believe, I am not following you. It is enough for my case as of now,
> but if that is blocked into QtCore for whatever
> No, we're not. I asked if the classes were enough and the answer I received
> was that they aren't.
I believe, I am not following you. It is enough for my case as of now,
but if that is blocked into QtCore for whatever reasons, and if there
is a need for more in the same module like Uwe requeste
On quinta-feira, 5 de julho de 2012 11.24.00, Laszlo Papp wrote:
> > moving the math3d classes to a more prominent place instantly prompts
> > the question: why don't we just use Eigen?
>
> The question instantly prompts the answer: eigenX is not part of the
> Qt ecosystem (with all its traits, wha
> moving the math3d classes to a more prominent place instantly prompts
> the question: why don't we just use Eigen?
The question instantly prompts the answer: eigenX is not part of the
Qt ecosystem (with all its traits, what that means), and we are just
discussing few already existing classes in
On 07/05/2012 11:32 AM, Thiago Macieira wrote:
> Before that, you need to tell us if Eigen isn't enough:
>
This is not what - at least - I had in mind. I was thinking about
algorithms like:
- Sutherland Hodgman
- Douglas Peucker
- Quadtrees, R-trees
- Interpolation ( bilinear, trilinear ... )
-
On quinta-feira, 5 de julho de 2012 07.25.04, Laszlo Papp wrote:
> So, instead of adding these few classes into QtCore, there would be a
> need another module. Who supports the creation of such a math library
> in Playground? Not that, I could work on that right now, just asking.
Before that, you
On Wed, Jul 04, 2012 at 06:27:19PM +0100, ext Laszlo Papp wrote:
> I would like to propose to move the math3d folder with all the
> portings of course to QtCore from QtGUI in Qt5. The reason is simple:
> I have recently started to work again on QtAudio3D, and I realized
> that, I would need such th
On Wednesday 04 July 2012 16:12:59 Charley Bay wrote:
> (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 p
Hi,
On Wednesday 04 July 2012 20:33:03 Thiago Macieira wrote:
> On quarta-feira, 4 de julho de 2012 18.27.19, Laszlo Papp wrote:
> > I would like to propose to move the math3d folder with all the
> > portings of course to QtCore from QtGUI in Qt5. The reason is simple:
> > I have recently started
> Qwt would also have interest interest in classes like QPointF3D
+1
> but this is not what QVector3D is ( or at least in Qt4 was ). As far as I
> understood QVector3D is designed as a helper class for drawing and IMHO
> should stay in QtGui as long as it is not implemented with a more common
> u
On 07/04/2012 08:33 PM, Thiago Macieira wrote:
> And you also need to tell me that the classes are generally useful, even
> outside of any relation to OpenGL (which was their original goal).
Qwt would also have interest interest in classes like QPointF3D, but
this is not what QVector3D is ( or a
On 05/07/2012, at 5:31 AM, ext Thiago Macieira wrote:
>
> I don't know what other applications would use these classes you're proposing
> to move. You have to show me that.
advanced motion/computer vision gesture recognition systems could make use of
them.
I agree these classes should be lo
charley spaketh:
>
> > (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
"qgenericma
On quarta-feira, 4 de julho de 2012 14.41.45, Charley Bay wrote:
> (We
> currently have our own 2D and 3D math libs, but if Qt had a non-GUI coupled
> lib, we could use it.)
Can you tell me whether those classes would suffice to your needs?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Sof
I agree with Laszlo: The "3D-math" stuff is generally useful, and need not
be coupled to QtGui. (We have domain-specific reasons for using 3D-math
stuff outside GUIs, separate of Laszlo's interest in "QtAudio3D" which also
does not want to couple to "QtGui" -- we cannot couple to QtGui either.)
> I'm waiting for a reason to be in QtCore before I accept the classes into my
> lib.
You wanna me heading towards a math add-on module for these few classes?
> There is a good reason for the command-line parser to be in QtCore: there are
> uses for QtCore-only applications, as well as in QtCore
On quarta-feira, 4 de julho de 2012 20.05.37, Laszlo Papp wrote:
> I do *NOT* wanna have the QtGui stack as a dependency. If you think, I
> should establish another module for these few classes because you do
> not accept this in QtCore, I will. Again, this is VERY bad to depend
> on the whole UI s
> My concern is that QtCore is not a dumping ground for "everything non-GUI that
> some library or app might need". We now have two discussions about moving
> classes into QtCore.
> I want to see a good argument of why it should be in QtCore, as opposed to why
> it shouldn't be in QtGui. 99% of the
On quarta-feira, 4 de julho de 2012 18.27.19, Laszlo Papp wrote:
> Hi,
>
> I would like to propose to move the math3d folder with all the
> portings of course to QtCore from QtGUI in Qt5. The reason is simple:
> I have recently started to work again on QtAudio3D, and I realized
> that, I would need
Hi,
I would like to propose to move the math3d folder with all the
portings of course to QtCore from QtGUI in Qt5. The reason is simple:
I have recently started to work again on QtAudio3D, and I realized
that, I would need such things like QVector3D. Surely, an 3D audio Qt5
add-on should not depen
49 matches
Mail list logo
