On 06/07/12 02:51, Alan Alpert wrote:
> On Fri, 6 Jul 2012 02:32:06 ext Philip Ashmore wrote:
>> On 06/07/12 02:05, d3fault wrote:
>> > For programmers, a lot of you are pretty bad at reading. Hopefully you
>> > understand designs better:
>> >
>> > Current Non-Interoperable Design: http:
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 01.21.01, Leandro Melo de Sales wrote:
> Hi,
> In my project I use QHttpResponseHeader that is obsolete and it isn't
> available in Qt5. What is the equivalent class of it in Qt5?
QHttpResponseHeader is still available in the qthttp module, if you really
need i
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
Hi,
In my project I use QHttpResponseHeader that is obsolete and it isn't
available in Qt5. What is the equivalent class of it in Qt5?
--
Leandro Melo de Sales
PhD candidate in Computer Science
Pervasive and Embedded Computing Laboratory, UFCG
___
Deve
On Fri, 6 Jul 2012 02:32:06 ext Philip Ashmore wrote:
> On 06/07/12 02:05, d3fault wrote:
> > For programmers, a lot of you are pretty bad at reading. Hopefully you
> > understand designs better:
> >
> > Current Non-Interoperable Design: http://bayimg.com/oapnKAAdJ
> > Which will probably eve
> 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 06/07/12 02:05, d3fault wrote:
> For programmers, a lot of you are pretty bad at reading. Hopefully you
> understand designs better:
>
> Current Non-Interoperable Design: http://bayimg.com/oapnKAAdJ
> Which will probably eventually turn into: http://bayimg.com/oAPnpAaDj
>
> Ideal Solution
For programmers, a lot of you are pretty bad at reading. Hopefully you
understand designs better:
Current Non-Interoperable Design: http://bayimg.com/oapnKAAdJ
Which will probably eventually turn into: http://bayimg.com/oAPnpAaDj
Ideal Solution: http://bayimg.com/PaPneAadj
The sooner we get off
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
On quinta-feira, 5 de julho de 2012 15.30.27, André Somers wrote:
> Op 5-7-2012 12:28, Thiago Macieira schreef:
> > We can add them, but I don't see a value in doing that if no one is using
> > them. They'll just increase build time.
>
> How could we use it, if it is not included?
Chicken-and-the-
> 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
Op 5-7-2012 12:28, Thiago Macieira schreef:
> We can add them, but I don't see a value in doing that if no one is using
> them. They'll just increase build time.
How could we use it, if it is not included?
André
___
Development mailing list
Development@
Hi,
I have tryed to install last binary beta1 qt5 windows installer on
http://origin.releases.qt-project.org/qt5.0/beta-snapshots/
source is installed, but when trying to install binary, there is a dialog
box saying that qmake is not installed, ... only a few dll (icuxx) are
installed in bin folde
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.
Yes, same problem happened when using qmake.
for qbs, I made a patch for link to static library, see:
https://codereview.qt-project.org/#change,29232
2012/7/5
> Does the same problem happen if using qmake instead of qbs?
>
> There is a qtmain.lib static library that should be added automaticall
> 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
Does the same problem happen if using qmake instead of qbs?
There is a qtmain.lib static library that should be added automatically to
windows executables, which provides the WinMain entry point.
--
From: development-bounces+shane.kearns=accenture@qt-project.org
[mailto:development-bounces+
On Thu, 05 Jul 2012 13:28:58 +0300, Thiago Macieira wrote:
> We can add them, but I don't see a value in doing that if no one is
> using
> them. They'll just increase build time.
extra module?
I always wondered where to throw stuff that
- can't make it (yet) into Qt,
- is too small to be i
> 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
On quinta-feira, 5 de julho de 2012 11.28.58, Michael Hasselmann wrote:
> On Thu, 2012-07-05 at 09:04 +0300, Thiago Macieira wrote:
> > Hello all
> >
> > I think that, despite the potential benefits of the changes, we should not
> > apply them at this time. There are far too many chances for breaka
On quinta-feira, 5 de julho de 2012 10.44.52, Marc Mutz wrote:
> On Thursday July 5 2012, Thiago Macieira wrote:
> > On quarta-feira, 4 de julho de 2012 23.09.03, Marc Mutz wrote:
> > > Any opinions either way?
> >
> > There are no plans to write any class to replace QFuture. However,
> > renaming
> 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 Thu, 2012-07-05 at 09:04 +0300, Thiago Macieira wrote:
> Hello all
>
> I think that, despite the potential benefits of the changes, we should not
> apply them at this time. There are far too many chances for breakage and it's
> a blatant disrespect for the feature freeze.
>
> The changes are
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 Thursday July 5 2012, Thiago Macieira wrote:
> On quarta-feira, 4 de julho de 2012 23.09.03, Marc Mutz wrote:
> > Any opinions either way?
>
> There are no plans to write any class to replace QFuture. However, renaming
> the class right now is close to impossible due to source-compatibility
> re
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
45 matches
Mail list logo
