Em seg 17 mar 2014, às 21:27:00, Damian Ivanov escreveu:
> Hi,
>
> A general question but maybe you are so kind and help me :-)
> /usr/lib/libMyLib.so and
> /opt/MyProj/lib/libMyLib.so
> (100% indentical files)
> So when I have 2 programs: one uses the one and the other, the other
> lib, will they
Hi,
A general question but maybe you are so kind and help me :-)
/usr/lib/libMyLib.so and
/opt/MyProj/lib/libMyLib.so
(100% indentical files)
So when I have 2 programs: one uses the one and the other, the other
lib, will they still share memory?
Thanks in advance!
I've recently started to use QtGraphicalEffects module and the effect set
is really nice!
Howerver I think the approach to apply an effect on a qml item is somewhat
cumbersome.
The docs give an example where we need to create an effect as a neighbour
of the original item :
Item {
width:
Hi all,
I recently tried compiling Qt 5.3.0-alpha for iOS and ran into a number of
build errors related to ATSFont declarations:
https://gist.github.com/bdentino/9592695
It looked like all of these errors were caused by attempting to compile
code only processed when the HAVE_ATS macro is nonzero
Le 17/03/2014 16:03, Sean Harmer a écrit :
> On Monday 17 March 2014 13:42:04 Yves Bailly wrote:
>> Le 17/03/2014 12:59, Agocs Laszlo a écrit :
>> So I'm back to my initial question: can Glew be used nicely with Qt? Seems
>> so in my quick test program (even using QOpenGLShaderProgram), but I'm
>>
I tried to override the flags function in the model but the function never gets
called, it never printed out my debug statement or hit my break point. Not
sure what to do here...
Qt::ItemFlags MessageList::flags(const QModelIndex &index) const
{
qDebug() << "Flags [" << index << "]: " << in
On Monday 17 March 2014 13:42:04 Yves Bailly wrote:
> Le 17/03/2014 12:59, Agocs Laszlo a écrit :
> > No, that is expected. After all it has to look up the versionFunction
> > internals from the hash table maintained by the context. With the design
> > shown here, deriving GL_Model from QOpenGLFunc
Il 17/03/2014 14:22, Jason H ha scritto:
I need to do a fast 1/2 resample of an image. This was exactly what
those articles were about. But I'm betting they were on a Nokia or TT
server, so no longer on the web, which is why I cant find them anymore.
Does anyone know what I'm talking about?
Ye
Back in 2009 or so there were from TT blog posts about a fast resampling
algorithm in Qt. I'm looking for those articles, or the outcome of them.
I need to do a fast 1/2 resample of an image. This was exactly what those
articles were about. But I'm betting they were on a Nokia or TT server, so
Le 17/03/2014 12:59, Agocs Laszlo a écrit :
> No, that is expected. After all it has to look up the versionFunction
> internals from the hash table maintained by the context.
> With the design shown here, deriving GL_Model from QOpenGLFunctions* feels
> like an overkill indeed.
>
> The options I
No, that is expected. After all it has to look up the versionFunction internals
from the hash table maintained by the context.
With the design shown here, deriving GL_Model from QOpenGLFunctions* feels like
an overkill indeed.
The options I see are:
1. Do not derive, just get an QOpenGLFunctio
Le 17/03/2014 10:05, Agocs Laszlo a écrit :
> I must correct my previous statement about not resolving functions that are
> not called. This deferred behavior is only true for QOpenGLFunctions. The
> versioned variants will resolve all functions for the given version already
> when initializeOpe
I must correct my previous statement about not resolving functions that are not
called. This deferred behavior is only true for QOpenGLFunctions. The versioned
variants will resolve all functions for the given version already when
initializeOpenGLFunctions() is first called with a given context.
Yes, the internals are shared between shared contexts. For QOpenGLFunctions at
least. The versioned variants are somewhat different, those are strictly
per-context, it seems. But the rest still holds: initializeOpenGLFunctions()
will use the same internals if there has already been a versionFunc
Le 17/03/2014 09:28, Agocs Laszlo a écrit :
> Some notes about QOpenGLFunctions:
>
> One QOpenGLFunctions belongs to one QOpenGLContext. Creating additional
> instances of QOpenGLFunctions for the same context will automatically share
> the internals behind the scenes so "it's way too much memory
Hello,
Some notes about QOpenGLFunctions:
One QOpenGLFunctions belongs to one QOpenGLContext. Creating additional
instances of QOpenGLFunctions for the same context will automatically share the
internals behind the scenes so "it's way too much memory and time for each to
resolve is functions"
Hi,
this question should be asked on the dev mailing list.
>Qt devs: is there a rationale behind the decision to not allow
>custom input context plugins on Windows?
There is no particular reason, I guess, it is not very common to have
custom input contexts on Windows.
https://bugreports.qt-p
Greetings all,
I would like to raise again a question which has already been discussed
a bit, without finding a satisfactory answer (for me at least).
It's about using OpenGL, more precisely getting access to OpenGL functions.
Is it possible to use Glew with Qt 5.2? I mean, is it possible to us
18 matches
Mail list logo
