[Development] GridView
I get strange scrolling behavior with QML's GridView on OSX with with a touchpad doing the typical two finger scrolling gesture. Click drag seems to be doing what two finger click drag should be. Is this a bug or am I missing a step? Also I have a large data base (orm) of image assets that I display in the grid view and get periodic updates from the server with ‘windows’ of data about 1000 items long. Any tips on segmenting ListModels to allow for continuos scrolling of large datasets like this? Is it safe to just let the y displacement accumulate to very large numbers? Thanks, j ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQml value types
On Apr 25, 2014, at 3:51 AM, Alberto Mardegan ma...@users.sourceforge.net wrote: On 04/24/2014 03:11 PM, Joshua Kolden wrote: [...] We have a solution that works very well for us using QVariantMaps and an MVC pattern / strong separation between data objects and view. It appears to me that most people are having this issue because it’s not common to use MVC with QtWidgets. But you can easily expose complex data structures to QtQuick without subclassing QObject via QVariantMaps. [...] While your proposed approach is rather clean, it carries one drawback, which is the lack of type information, with all its consequences. For instance, I would like to have a GeoPoint type with latitude and longitude properties; if I exposed it as a QVariantMap, I wouldn't be able to prevent the QML code from doing stuff like: p.latitude = 60 p.longitde = 10 // note the typo Actually you can (at least at runtime), although we don’t. In the application runtime we use explicit input validation for user input in the view as apposed to relying on compiler errors. This gives us much finer grain control over what constitutes valid data, as apposed to only validating type and existence as compilers do. Also our GUI development is in real time on top of the running application (do that with widgets), so variable typos are immediately obvious. If as I’ve described these data types are QML properties then onChanged is signaled, so you can easily run any type of validator (in javascript or c++). This includes listing all keys in the QVarianMap for `eatra` values that shouldn't be there, missing values, type or range invalidations etc. Also once you grab your data back from the QVariantMap in C++ in the controller you must use an accessor like .toString() etc to cast the QVariant to a known type, and that brings back your type checking on the C++ side. However, what you’ve described is a coding error, as apposed to a user input error, we don’t check this in application code at all nor do we rely on the compiler to catch everything as this is the domain of the test sweet. j Ciao, Alberto -- http://blog.mardy.it - geek in un lingua international! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQml value types
On Apr 25, 2014, at 7:28 AM, Dominik Holland dominik.holl...@pelagicore.com wrote: Am 25.04.14 15:05, schrieb Joshua Kolden: On Apr 25, 2014, at 3:51 AM, Alberto Mardegan ma...@users.sourceforge.net wrote: On 04/24/2014 03:11 PM, Joshua Kolden wrote: [...] We have a solution that works very well for us using QVariantMaps and an MVC pattern / strong separation between data objects and view. It appears to me that most people are having this issue because it’s not common to use MVC with QtWidgets. But you can easily expose complex data structures to QtQuick without subclassing QObject via QVariantMaps. [...] While your proposed approach is rather clean, it carries one drawback, which is the lack of type information, with all its consequences. For instance, I would like to have a GeoPoint type with latitude and longitude properties; if I exposed it as a QVariantMap, I wouldn't be able to prevent the QML code from doing stuff like: p.latitude = 60 p.longitde = 10 // note the typo Actually you can (at least at runtime), although we don’t. In the application runtime we use explicit input validation for user input in the view as apposed to relying on compiler errors. This gives us much finer grain control over what constitutes valid data, as apposed to only validating type and existence as compilers do. Also our GUI development is in real time on top of the running application (do that with widgets), so variable typos are immediately obvious. If as I’ve described these data types are QML properties then onChanged is signaled, so you can easily run any type of validator (in javascript or c++). This includes listing all keys in the QVarianMap for `eatra` values that shouldn't be there, missing values, type or range invalidations etc. Also once you grab your data back from the QVariantMap in C++ in the controller you must use an accessor like .toString() etc to cast the QVariant to a known type, and that brings back your type checking on the C++ side. However, what you’ve described is a coding error, as apposed to a user input error, we don’t check this in application code at all nor do we rely on the compiler to catch everything as this is the domain of the test sweet. j We are also currently using QVariantMaps in a Project and beside having more work to validate the Data which comes in the Controller classes instead of validating the input in the QmlType classes itself it also has some other problems at least for us. We are using QDoc to generate QML Documentation for our Interfaces and instead of describing all the available properties in the QmlType you need to document the properties of the QVariantMap in the function. Sure i think there are ways to some kind of Fake QmlType page and document the properties (which is a QVariantMap in the real world) but i don't think it's a proper solution. Ah yes we don’t use QDoc. I can see how auto documentation generation could be improved. (Currently we use literate coffeescript for the views and are setting up something similar on the c++ side. Admittedly a fairly obscure approach for most.) A other problem i can see is the Code-Completion which you can't get for QVariantMap because it's a variable type which can store anything in any format. I think for Projects where the QML Developers know the C++ Developers this works, but in larger Projects like having a API for 3rdParties i think QVariantMaps doesn't work and we need to invest some time to make a proper solution. I’m not sure what you mean, are you talking about a particular IDE? I would think any custom data type weather it’s c++ or javascript would have a similar issue within an IDE. Personally I use sublime text and from time to time I do create code completion snippets for custom objects, but no more so for javascript data types than c++ ones. I don’t think I understand what you mean though. Definitely, I’m not arguing against a better way / ‘proper solution’. By all means lets work on that please. I was only addressing the concern that you can’t use QML at all when working with large numbers of non QObject derived domain specific data objects. In that respect I’d say we’re quite better of, at least in our project, for using QtQuick/QML over widgets. j Dominik Ciao, Alberto -- http://blog.mardy.it - geek in un lingua international! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQml value types
I’m sorry I intended to respond to this in the other thread, but super busy.
Nevertheless I think it’s important for people to know there are answers to
this now without waiting for any new APIs so I stole the time to write our
process out.
We have a solution that works very well for us using QVariantMaps and an MVC
pattern / strong separation between data objects and view. It appears to me
that most people are having this issue because it’s not common to use MVC with
QtWidgets. But you can easily expose complex data structures to QtQuick
without subclassing QObject via QVariantMaps.
On the data side your `value classes` are best when optimized for the domain
you use them in. You rightly don’t want to contaminate them with view logic.
Conversely you don’t want to contaminate your view with specific knowledge of
internal data representations. This is where the controller comes in to map
the view concepts to the model data allowing either to change independently of
each other.
Things like
`dataModel-getAircraft().getCom1().getFrequency(chosenUnit).toQString();` are
generally bad practice in OO design regardless of QML or Qt because it’s
fragile, and requires knowledge of every step in the chain. If however you can
provide an interface that just returns frequencies say, then do whatever you
want with your value classes behind that interface without worrying that it’ll
break your UI.
We do this by creating controllers based on UI concepts. For us these include:
“groups”, “assets”, “processes”, “accounts” etc. For you it might be things
like “communications”, “navigation”, “flight_controls”, “simulator_state”, or
whatever works best for you conceptually. We create QObject based controllers
on the C++ side for each of these conceptual areas, and expose a select few
signals as the interface to pass data back and forth to the view. We do this
for widget apps, and web apps too, it’s not a workflow that is specific to QML.
It works a lot better than having a separate QObject for every value class
since it lets you keep your data models focused on the problems they are
designed to solve without regard to the display of the data. Conversely in the
GUI we just have the data we need we don’t need to care about how it is derived.
In QML QVariantMaps show up as javascript object/hashes/maps (whatever you like
to call them). They can have arbitrary nesting, and data types, so you can
maintain or alter your data representation at your desecration. The data can
than be mapped to QML object properties in a declarative way, either once for
the entire data representation or individually for each attribute.
(With QML a better mental model might be ‘link’ to data as apposed to passing
data ‘back and forth’ since we don’t do a lot of method calling. Properties
work automatically via signals, so it’s a bit more like a patch panel, once the
connections are made they just work moving the data back and forth as it
changes on either side.)
For example:
Rectangle {
id: radioInterface
property var comData: communications.com
function foo() {
frequencyDisplay.text = comData.com1.frequency;
...
}
or
Rectangle {
id: radio Interface
property var com1freq: communications.com.com1.frequency
property var com1amp: communications.com.com2.amplitude
…
}
For the controller you’d have something like this:
class CommunicationsController : public QObject
{
Q_OBJECT
Q_PROPERTY(QVariantMap com READ com WRITE setCom NOTIFY comChanged)
…
public:
QVariantMap com() const;
public slots:
void setCom(const QVariantMap com);
signals:
void comChanged();
}
Later you expose this controller to QtQuick with something like.
CommunicationsController communications;
interface.addProperty(“communications, communications);
Now everything is connected. On the QML side you can just directly access the
values as above, or copy them to a javascript object (i.e. `var comData =
communications.com`) etc. On the c++ side you can set and read values in this
structure with the QVarianMap accessors.
QVariantMap comData;
QVariantMap com1;
com1[“frequency”] =
dataModel-getAircraft().getCom1().getFrequency(chosenUnit).toQString(); // if
you must
comData[“com1”] = com1;
return comData;
and
dataModel-getAircraft().getCom1().setFrequency(com[“com1][“frequency”].toFloat());
// or whatever type
The only thing that’s a consideration with QVariantMaps vs QObjects is that you
can’t include methods. But that’s where the OO design comes in which tells us
we shouldn’t have too many operations happening on data in the views anyway.
Nevertheless if you truly need to have operators such as convince helper
methods in the view you can expose them with Q_INVOKABLE methods in the
controller.
It’s important to note that this workflow is in production now with our
software and works great, and is very maintainable. The javascript data models
are very easy to
Re: [Development] Question about Qt's future
On Apr 21, 2014, at 6:31 AM, Yves Bailly yves.bai...@laposte.net wrote: On 21/04/2014 04:53, Thiago Macieira wrote: Em dom 20 abr 2014, às 22:37:11, m...@rpzdesign.com escreveu: Isn't Qt Widgets so mature that they are stable? They are. But so much could still be done... as a basic example I stumbled upon very recently, why is it so hard to change the font of *one* item in a combo box?? Trivial in QML. The design direction is because QML is easier to develop with, Not for heavy-weight applications, even less when part of the UI is dynamically build at runtime according to context, config files, etc. I think you may have a miss perception about QML. QML although young, is not a toy interface kit. It may seem like it since it is so young, and because it’s light and easy to work with. However it is actually a much better platform to do UI heavy lifting. The unified scene graph of QtQuick gives substantial performance gains (at least as intended) over redraw and QML ease of use improves implementation time and maintainability for complex interfaces. You could absolutely create QtCreator’s interface in QML. We haven’t had the problems some have mentioned regarding a fuzzy line between view/controller javascript/c++, so I’m not sure what the issue is there. However we’ve seen significant development productivity gains by being able to implement and integrate UI with c++ backend in the running application in realtime. Usually one developer can work entirely independently from the other. Don’t be put off by the fact most QtQuick demos are on portable devices. Our project is a desktop app in the professional post production space. Granted, we have some issues, there are still unimplemented features, bugs and performance issues that are being shaken out. And as discussed elsewhere it may not be the perfect fit for legacy QtWidget apps (not that you couldn’t use both to some extent). So while I am suspicious that there may be other concerns that I’m keeping an eye out for, “heavy-weight”, and dynamic UIs are QML’s sweet spot not weakness. You may also be interested in this video: https://www.youtube.com/watch?v=kvWeE3kurEQ more modern, and based on OpenGL. Widgets don't have that and will never be as efficient. Therefore, the effort is directed towards the technology that has the potential to make interfaces for 2017-2020. Even in 2017-2020, we'll still have desktops. Phones or even tablets are just not suited for *real* work, and I don't see how they could be. A professional writer can type 100 words per minute on a keyboard, I doubt this will be even remotely possible on a tablet. Doing serious 3D modeling on a tablet is a joke. And think about the hundreds of mouse/keyboards shorcuts... if you remove them, as its the case on modern devices, you loose a lot in productivity. QtCreator is a complex application, though not as heavy-weight as some I work on. Could it be redone the right way, with *all* the UI in QML and the business logic in C++? would developing QtCreator this way be as efficient as it is today? and finally, would a user be as efficient with it on a modern device as he can be on a good'old desktop? Same question for Calligra and others. QML has its merit, it's certainly perfect for some projects. But for all I've seen and tried until now, only for projects having a rather simple UI. For really complex UIs, QML seems not suitable - at least for now. Mind, what I (and others) is talking about, are applications where user's productivity matters more than the UI being nice - or even looking native. Take Blender: sure, the learning curve is steep. But once you know it, you can very very productive with it, *on any platform*, because it looks the same *on all platform*. Looking native might be a nice selling or demo thing, but it's just irrelevant (or even counter-productive) for a whole class of applications. So please, please... keep improving widgets! :-) some things are unnecessary difficult to do, some features would be so nice to have... -- (o | Yves Bailly | -o) //\ | Linux Dijon : http://www.coagul.org | //\ \_/ | | \_/` ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about Qt's future
I’m curious why you are not interested in QML. I’m just finishing up a an initial production release of software oriented towards high-performance graphics. We used QML for the interface, coffeescript for view logic, and Qt/c++ for processing and business logic. It works astonishingly well sine we can design and build the UI separately from the business logic, and designers can work interactively without a compilation step, while the business logic can worry about threads and other performance processing complexity without regard to the event loop, just throwing things over the fence to the UI when ready. I see no reason to stay with Qt Widgets at all other than legacy application support. So what is your concern? Is it just that you don’t what to go from being an expert in the tools you already know to an beginner at new tools, or are you up to speed on QML and you have some details on why this approach is a bad idea? I haven’t found any major issues, other then a few bugs and missing features that will be fixed soon enough. Please don’t read this as me being facetious, I’m genuinely looking for any information that would indicate the we are on the wrong path with our application design. Thanks, j On Apr 20, 2014, at 6:40 PM, Michael Knight jackdalton20...@gmail.com wrote: I feel like Qt is going in the direction of being Qml and Javascript only.I fear that they may abandon Qt Widgets in the near future,I think they are heavily promoting Qml.I don't want to use Qml,and before I start using Qt,I want to be sure that they will not abandon C++ side of Qt and that they continue to develop C++ side.It seems to me that they are developing Qml side mostly. What do you think about this? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Future of QtOpenCL
Thanks for picking this up. I'm in the process of integrating OpenCL with our qt/qml application. I will be happy to test, and contribute our work as applicable so as to encourage this development. j On Mar 29, 2014, at 2:31 PM, Liang Qi cavendish...@gmail.com wrote: Time is so fast. I got some free time this weekend, and did a bit work for building QtOpenCL with Qt 5. My latest work in the dev branch of following repo: https://github.com/liangqi/qtopencl If someone could setup a labs project, qtopencl, in codereview, maybe we could continue work on this topic there. Regards, Liang On 29 June 2013 19:00, Sebastian Lehmann q...@leemes.de wrote: Hello Qt developers, I'm sadly noting that the QtOpenCL project [1] is dead since end 2010, yet it's still usable. I want to bring this module back to life. Currently, the module has a couple of issues such as const-correctness and missing support for Qt5. I see two options with that: Either rewriting the whole module with a new design, or improving the existing code base. Also, I'd love to have some basic, generic and reusable algorithms implemented in OpenCL and available with an interface similar to QtConcurrent. This could be in a separate module. I have some nice ideas for the design of this. Some people say that there's no big advantage in having a QtOpenCL module, as everything can also be done with CL library function calls. But both the advantage of RAII as well as having a Qt'ish interface are a huge help when writing applications with a lot of GPGPU computations, as the raw CL functions are way too painful to write (and read). How's your opinion about bringing QtOpenCL back to life (especially in Qt5)? Any concrete ideas or suggestions? Anyone out there who wants to help? How is the typical workflow for new modules in Qt5? Cheers, Leemes PS: I already read through the Qt Contribution Guidelines. PPS: I'm currently writing an OpenCL powered application with the old QtOpenCL module within the context of a GPGPU computing course I'm taking. I have quite a good knowledge of GPGPU computing as well as the old QtOpenCL module and its flaws. But I think this won't be enough to rewrite a whole new Qt5 module from scratch. So I think this won't work unless some people from the community can be found willing to help. [1]: http://doc.qt.digia.com/opencl-snapshot/ -- http://www.qiliang.net ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QML testing
I’ve done a buch of work with TDD and qml now, and built a very nice test framework in coffeescript with “before each” “after each”; nice spec style ‘it “has a feature”`, signal handling, color coded output the whole bit. There are, however, two remaining big frustrations that make continuous testing during development very challenging. One is the tendency for the test runner to pull focus, for longer running tests it makes it nearly impossible to leave the test system running while coding. Every time you save a watched file focus is pulled away from the text editor and may or may not ever come back. If one is working in full screen mode on a mac then the entire screen is shifted to a different desktop even if no actually GUI pops up. Is there any way to keep this from happening? The second issue is the hard stop on test failure. Actually there is even a hard stop if a SignalSpy.wait() doesn’t receive it’s signal. It may not be an error for a signal not to fire, so I don’t agree with the behavior that SignalSpy.wait() fails hard. However, even the test conditions shouldn’t stop code execution. It makes it very hard to predictably reset the environment for the next test. I can’t do things like after each test dump the LocalStorage, or prior to each test ask my web service if a test object still exists (wait for signal from XMLHttpRequest) and call the server’s delete api if it does, and move on to the test either way. I’d love to be able to wait for either success or fail signals at the same time so I can jump right to debugging the issue instead of simply getting a uninformative failure because a success signal did not fire, but as it is I can only include SignalSpy.wait if it is exactly the only thing I expect to happen. I can call wait() and then look at each spy’s count, but that makes the test very difficult to read, and starts spinning off into absurd complexity in every individual test to handle just a few conditional signals. So I’d like to know if there is any way to alter these two behaviors as it stands now now. I'm hard pressed to understand a reason to fail hard when a test condition fails, is this deliberate behavior? Also, I’d like to ask whoever is working on the QML test case stuff if these are features that could be included in the near future (perhaps even as the default behavior). Thanks, j P.S. I’ll probably open source the test framework in the near future if anyone is interested. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML Image aliasing when animating
Interesting. I tried the layer.mipmap previously with no effect, I did’t catch
that one needed to “enable” it too. However, I just tried this, and although
it created a different, marginally smoother result is is still very noticeably
aliasing.
Here is a move of that test:
http://c4.dev.s3.amazonaws.com/QMLImageRenderQuality2.mov
In fact this version is starting to look very similar to the results I was
seeing with the font renders.
On Jan 21, 2014, at 11:50 PM, Gunnar Sletta gunnar.sle...@jolla.com wrote:
This is the expceted result. smooth: true uses bilinear filtering which is
what is supported in hardware. When scaling down, this starts to degrade. The
effect is drastic for high-contrast content like the edges of a font. Once go
get below 0.5x scale factor the sampling starts to ignore pixels and aliasing
become very visible.
The preferred solution is to prepare raster content (images in your case)
close to the size you intend to show them. If you must scale them down, then
use mipmapping. With the image element, you can get this by doing:
Image {
layer.enabled: true
layer.smooth: true
layer.mipmap: true
...
}
However, by enabling the layer you get an extra texture copy of your rather
large image, so it might be preferable to implement a custom QQuickItem which
returns a QSGSimpleTextureNode with a QSGTexture with mipmapping.
cheers,
Gunnar
On 22 Jan 2014, at 04:03, Joshua Kolden jos...@crackcreative.com wrote:
I’m getting boxed in with rendering bugs on two fronts. Originally I tried
to work with fonts for the following animation, but have both render quality
and font ‘subfamily’ selection bugs to deal with there. So I took the effort
to switch a lot of stuff around and use images instead, however I’m getting
aliasing artifacts now. I’m rather stuck at the moment for rendering a good
quality large font design.
This video shows the aliasing I’m talking about. There are 3 images here
one is 2048x512 and two are 512x512 for the Camera4 and C4 text logos. The
movie is captured pixel for pixel, and the images at their largest (in this
example) are smaller then the source resolution.
http://c4.dev.s3.amazonaws.com/QMLImageRenderQuality.mov
Here is an example of one of the Image invocations:
Image {
id: c4CameraImage
fillMode: Image.PreserveAspectFit
source: “path/to/c4camera.png
anchors.left: parent.left
anchors.top: parent.top
anchors.bottom: parent.bottom
smooth : true
opacity: 0.0
}
The animation is created with a number animation on the width and height of
the parent rectangles.
I’ve asked on IRC, and in the [interest] list, but one said it should just
work and the other didn’t reply.
Is this a known issue, a bug, or and I’m I doing it wrong?
Thanks,
j
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML Image aliasing when animating
Upon further experimentation I find that turning layer.mipmap on and off, has
no effect. While smooth on a layer vs. smooth on the image does effect the
image differently. This makes sense if one is being filtered against the
original image size and the other against the Item’s layer texture size. We
should have a mipmap option on images themselves not just an Item layer since
layer size != image size. It appears to me mipmaping is not working at all and
I’d hesitate to go to any trouble with QSGTexture as that may be where it’s
broken if thats the base for Image.
Enabling bilinear filtering without enabling mipmaping is not an intuitive
choice. In effect it means images can only be displayed properly at their
original size or larger then their original size. I would not consider this
expected behavior. You do not have this problem in web page rendering for
example. Given the wide verity of devices and resolutions QML is targeted for
I would expect mipmaping to be default behavior, as well as exposing the filter
setting or simply hardcoding `anisotropic` when smooth is enabled..
I just tested and indeed, it appears that even static images are not being
rendered properly when they are displayed at a resolution lower then their
original resolution, and
layer.enabled: true
layer.smooth: true
layer.mipmap: true
has no effect on images that are displayed larger their there original
resolution.
Thanks,
j
On Jan 22, 2014, at 12:04 AM, Joshua Kolden jos...@crackcreative.com wrote:
Interesting. I tried the layer.mipmap previously with no effect, I did’t
catch that one needed to “enable” it too. However, I just tried this, and
although it created a different, marginally smoother result is is still very
noticeably aliasing.
Here is a move of that test:
http://c4.dev.s3.amazonaws.com/QMLImageRenderQuality2.mov
In fact this version is starting to look very similar to the results I was
seeing with the font renders.
On Jan 21, 2014, at 11:50 PM, Gunnar Sletta gunnar.sle...@jolla.com wrote:
This is the expceted result. smooth: true uses bilinear filtering which is
what is supported in hardware. When scaling down, this starts to degrade.
The effect is drastic for high-contrast content like the edges of a font.
Once go get below 0.5x scale factor the sampling starts to ignore pixels and
aliasing become very visible.
The preferred solution is to prepare raster content (images in your case)
close to the size you intend to show them. If you must scale them down, then
use mipmapping. With the image element, you can get this by doing:
Image {
layer.enabled: true
layer.smooth: true
layer.mipmap: true
...
}
However, by enabling the layer you get an extra texture copy of your rather
large image, so it might be preferable to implement a custom QQuickItem
which returns a QSGSimpleTextureNode with a QSGTexture with mipmapping.
cheers,
Gunnar
On 22 Jan 2014, at 04:03, Joshua Kolden jos...@crackcreative.com wrote:
I’m getting boxed in with rendering bugs on two fronts. Originally I tried
to work with fonts for the following animation, but have both render
quality and font ‘subfamily’ selection bugs to deal with there. So I took
the effort to switch a lot of stuff around and use images instead, however
I’m getting aliasing artifacts now. I’m rather stuck at the moment for
rendering a good quality large font design.
This video shows the aliasing I’m talking about. There are 3 images here
one is 2048x512 and two are 512x512 for the Camera4 and C4 text logos. The
movie is captured pixel for pixel, and the images at their largest (in this
example) are smaller then the source resolution.
http://c4.dev.s3.amazonaws.com/QMLImageRenderQuality.mov
Here is an example of one of the Image invocations:
Image {
id: c4CameraImage
fillMode: Image.PreserveAspectFit
source: “path/to/c4camera.png
anchors.left: parent.left
anchors.top: parent.top
anchors.bottom: parent.bottom
smooth : true
opacity: 0.0
}
The animation is created with a number animation on the width and height of
the parent rectangles.
I’ve asked on IRC, and in the [interest] list, but one said it should just
work and the other didn’t reply.
Is this a known issue, a bug, or and I’m I doing it wrong?
Thanks,
j
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] QML Image aliasing when animating
I’m getting boxed in with rendering bugs on two fronts. Originally I tried to
work with fonts for the following animation, but have both render quality and
font ‘subfamily’ selection bugs to deal with there. So I took the effort to
switch a lot of stuff around and use images instead, however I’m getting
aliasing artifacts now. I’m rather stuck at the moment for rendering a good
quality large font design.
This video shows the aliasing I’m talking about. There are 3 images here one
is 2048x512 and two are 512x512 for the Camera4 and C4 text logos. The movie
is captured pixel for pixel, and the images at their largest (in this example)
are smaller then the source resolution.
http://c4.dev.s3.amazonaws.com/QMLImageRenderQuality.mov
Here is an example of one of the Image invocations:
Image {
id: c4CameraImage
fillMode: Image.PreserveAspectFit
source: “path/to/c4camera.png
anchors.left: parent.left
anchors.top: parent.top
anchors.bottom: parent.bottom
smooth : true
opacity: 0.0
}
The animation is created with a number animation on the width and height of the
parent rectangles.
I’ve asked on IRC, and in the [interest] list, but one said it should just work
and the other didn’t reply.
Is this a known issue, a bug, or and I’m I doing it wrong?
Thanks,
j
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML Image aliasing when animating
Yes, it also has no effect.
On Jan 21, 2014, at 11:21 PM, Rutledge Shawn shawn.rutle...@digia.com wrote:
On 22 Jan 2014, at 4:03 AM, Joshua Kolden wrote:
Image {
id: c4CameraImage
fillMode: Image.PreserveAspectFit
source: “path/to/c4camera.png
anchors.left: parent.left
anchors.top: parent.top
anchors.bottom: parent.bottom
smooth : true
Did you try antialiasing: true?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Consoles
I’d like to add my vote and reiterate this as a valid target for Qt. Consoles are becoming media centers, and a new discreet type of ‘device’ just like a tablet or phone. Although the scope of functionality of these devices is still being worked out I think we can expect a pretty clear set of non game uses. In addition to non game functions like media playing we already see, I’m sure we can expect features like Home Office control, info displays for system monitoring, interactive advertising, and other applications that require fewer interaction points and a more ‘lean back’ experience in the near future. I'm working on a large Qt project for working with images and video that is being developed for the desktops and devices that Qt supports now. Opening up consoles would be a fantastic next step despite the fact we don’t use CG. Also I think it is a 'public good' to provide open source competition for system frameworks that may otherwise be proprietary and an attempt to control mind share, like Qt has already done for the XCode and Visual Studio ecosystems. j On Jan 17, 2014, at 3:29 AM, Kevin Krammer kevin.kram...@kdab.com wrote: On Friday, 2014-01-17, 11:15:24, Laszlo Papp wrote: On Fri, Jan 17, 2014 at 11:06 AM, Kevin Krammer kevin.kram...@kdab.com wrote: On Friday, 2014-01-17, 10:52:29, Laszlo Papp wrote: Wouldn't it be useful to get a proper 3D module in place first? Although, there are still some nice 2D indie games with full of shader all around. :-) A console target does not necessarily imply games. A lot of consoles run apps these days, because they are the platforms that are in the living rooms, permanently connected to all kinds of enterainment infrastructure and usually only on stand-by and not switched off (no booting). Hmm, Interesting... I have not been aware of that the main purpose of the consoles changed these days. I have not played for a while. :) Games are almost certainly still their main purpose but the usage as a media consumtion device is already close up. They act as Bluray players, can be used as clients for a home streaming server and all console vendors have (at least in some countries), online streaming libraries/stores. Anyway, I was mostly addressing this from the perspective of Qt as an app development framework, just like on mobile devices. For app developers, especially for those who's actual product is a service, consoles would be just another platform frequently used by people, with app stores, limited variation in devices, capabilities and APIs. PS.: Well, I am not sure console as a generic platform makes much sense though when you can use a raspberry pi or more powerful embedded board to connect all kinds of entertainment structure together with more open platforms. Perhaps, that is somewhat the answer why not many people are interested in a specific proprietary platform (which was originally meant for powerful games). I don't think that is comparable. Generic platforms like the Pi are for people who build their own systems, consoles are for pure consumers. Cheers, Kevin -- Kevin Krammer | kevin.kram...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtest-qml osx
Thanks, I’ll check that out. The crashing bug as been logged: QTBUG-35984 j On Jan 6, 2014, at 11:32 PM, Chao Caroline caroline.c...@digia.com wrote: Hi, Have you checked the qt auto tests? You could have a look into qtdeclarative/tests/auto (quick) and/or qtquickcontrols/tests/auto folder. There are plenty of tests there and you can probably find some that are relevant to you. Regards, Caroline From: Joshua Kolden [jos...@crackcreative.com] Sent: Monday, January 06, 2014 5:15 PM To: Chao Caroline Cc: Alan Alpert; development@qt-project.org Subject: Re: [Development] qtest-qml osx Thanks, that’s helpful. I didn’t think to just use an import in the qml test file itself. I’ll test today, but it doesn’t seem like that would work with nested objects. If it does then great, but rather non-intuitive magic. Also, currently I’m just stubbing out qml objects to represent c++ objects that would be available to the QML object being tested in the production application. This is appropriate for unit testing, but if I could include the c++ classes in my test runner then I could do integration tests too which would be lovely. Any chance you have an example of that? Thanks, j On Jan 6, 2014, at 4:40 AM, Chao Caroline caroline.c...@digia.com wrote: Hi, The TestCase doc should refer to QtQuickTest and not QtTest indeed, please log a documentation bug for it. Also I have attached a small example to get you started, with a source component to test under src/qml and the test file under specs/qml. It should work with both qmltestrunner or a QUICK_TEST_MAIN. You don't need IMPORTPATH here. It is used when you want to load a module (only qml files or a cpp plugin), which is defined by a qmldir file (in the attached example it can be for example src/qml/qmldir containing module qml MyRectangle 1.0 MyRectangle.qml) Regards, Caroline From: Joshua Kolden [jos...@crackcreative.com] Sent: Monday, January 06, 2014 12:40 AM To: Alan Alpert Cc: Chao Caroline; development@qt-project.org Subject: Re: [Development] qtest-qml osx On Dec 16, 2013, at 10:44 AM, Alan Alpert 4163654...@gmail.com wrote: On Mon, Dec 16, 2013 at 3:47 AM, Chao Caroline caroline.c...@digia.com wrote: Thanks I didn’t realize any of this since the TestCase docs[0] don’t refer to the “Qt Quick Test Reference” docs[1]. Which I would suggest is probably a documentation bug? I’ve been able to get the simplest case of this working (despite the docs being very abstract), but I think I’m seeing a bug when used in my project. Can someone please confirm it isn't user error before I log the bug? In my environment I have source and tests separated into `src/qml`, and `specs/qml` respectively. Regardless if I use the qmltestrunner or a QUICK_TEST_MAIN macro I’m unable to include components from the src/qml path, so unless the tst_*.qml file is actually present in that path no components are loaded. This is true whether I invoke the item with a bare reference, or with `Qt.createComponent()`. I’ve tried using the -import command line option as documented, with all variations on absolute and relative paths to the `src/qml` path. I’ve also tried `IMPORTPATH`, `INCLUDEPATH`, and `QUICK_TEST_SOURCE_DIR` in the test .pro file. Production qml files are simply not accessible by tests unless I contaminate the src folder with all the tst_*.qml files (which is a non-starter on this large of a project). Thanks, j [0] - http://qt-project.org/doc/qt-5/qml-qttest-testcase.html [1] - http://qt-project.org/doc/qt-5/qtquick-qtquicktest.html On Dec 16, 2013, at 10:44 AM, Alan Alpert 4163654...@gmail.com wrote: On Mon, Dec 16, 2013 at 3:47 AM, Chao Caroline caroline.c...@digia.com wrote: Hi, Qt Quick Test is part of Qt (in the qtdeclarative repo). I think the problem here is that you are trying to run a test using qmlscene directly. QML TestCases should be launched via a C++ harness: http://qt-project.org/doc/qt-5/qtquick-qtquicktest.html The other alternative is the qmltestrunner utility. qmlscene is not expected to work, nor planned to, but ideally support will be added to the new qml utility (such support is not currently in place but wouldn't be too hard to add). -- Alan Alpert From: development-bounces+caroline.chao=digia@qt-project.org [development-bounces+caroline.chao=digia@qt-project.org] on behalf of Joshua Kolden [jos...@studiopyxis.com] Sent: Sunday, December 15, 2013 11:18 PM To: development@qt-project.org Subject: [Development] qtest-qml osx We have a fairly large qml project, and with 5.2 we are trying to switch to TDD for all components (c++, js (coffescript), QML). Qt Creator and qmlscene in 5.2 both seem to have the same issue that files
Re: [Development] qtest-qml osx
Thanks, that’s helpful. I didn’t think to just use an import in the qml test file itself. I’ll test today, but it doesn’t seem like that would work with nested objects. If it does then great, but rather non-intuitive magic. Also, currently I’m just stubbing out qml objects to represent c++ objects that would be available to the QML object being tested in the production application. This is appropriate for unit testing, but if I could include the c++ classes in my test runner then I could do integration tests too which would be lovely. Any chance you have an example of that? Thanks, j On Jan 6, 2014, at 4:40 AM, Chao Caroline caroline.c...@digia.com wrote: Hi, The TestCase doc should refer to QtQuickTest and not QtTest indeed, please log a documentation bug for it. Also I have attached a small example to get you started, with a source component to test under src/qml and the test file under specs/qml. It should work with both qmltestrunner or a QUICK_TEST_MAIN. You don't need IMPORTPATH here. It is used when you want to load a module (only qml files or a cpp plugin), which is defined by a qmldir file (in the attached example it can be for example src/qml/qmldir containing module qml MyRectangle 1.0 MyRectangle.qml) Regards, Caroline From: Joshua Kolden [jos...@crackcreative.com] Sent: Monday, January 06, 2014 12:40 AM To: Alan Alpert Cc: Chao Caroline; development@qt-project.org Subject: Re: [Development] qtest-qml osx On Dec 16, 2013, at 10:44 AM, Alan Alpert 4163654...@gmail.com wrote: On Mon, Dec 16, 2013 at 3:47 AM, Chao Caroline caroline.c...@digia.com wrote: Thanks I didn’t realize any of this since the TestCase docs[0] don’t refer to the “Qt Quick Test Reference” docs[1]. Which I would suggest is probably a documentation bug? I’ve been able to get the simplest case of this working (despite the docs being very abstract), but I think I’m seeing a bug when used in my project. Can someone please confirm it isn't user error before I log the bug? In my environment I have source and tests separated into `src/qml`, and `specs/qml` respectively. Regardless if I use the qmltestrunner or a QUICK_TEST_MAIN macro I’m unable to include components from the src/qml path, so unless the tst_*.qml file is actually present in that path no components are loaded. This is true whether I invoke the item with a bare reference, or with `Qt.createComponent()`. I’ve tried using the -import command line option as documented, with all variations on absolute and relative paths to the `src/qml` path. I’ve also tried `IMPORTPATH`, `INCLUDEPATH`, and `QUICK_TEST_SOURCE_DIR` in the test .pro file. Production qml files are simply not accessible by tests unless I contaminate the src folder with all the tst_*.qml files (which is a non-starter on this large of a project). Thanks, j [0] - http://qt-project.org/doc/qt-5/qml-qttest-testcase.html [1] - http://qt-project.org/doc/qt-5/qtquick-qtquicktest.html On Dec 16, 2013, at 10:44 AM, Alan Alpert 4163654...@gmail.com wrote: On Mon, Dec 16, 2013 at 3:47 AM, Chao Caroline caroline.c...@digia.com wrote: Hi, Qt Quick Test is part of Qt (in the qtdeclarative repo). I think the problem here is that you are trying to run a test using qmlscene directly. QML TestCases should be launched via a C++ harness: http://qt-project.org/doc/qt-5/qtquick-qtquicktest.html The other alternative is the qmltestrunner utility. qmlscene is not expected to work, nor planned to, but ideally support will be added to the new qml utility (such support is not currently in place but wouldn't be too hard to add). -- Alan Alpert From: development-bounces+caroline.chao=digia@qt-project.org [development-bounces+caroline.chao=digia@qt-project.org] on behalf of Joshua Kolden [jos...@studiopyxis.com] Sent: Sunday, December 15, 2013 11:18 PM To: development@qt-project.org Subject: [Development] qtest-qml osx We have a fairly large qml project, and with 5.2 we are trying to switch to TDD for all components (c++, js (coffescript), QML). Qt Creator and qmlscene in 5.2 both seem to have the same issue that files are missing: qmlscene test1.qml file:///x/d/qt/testDrivenQML/test1.qml:25 Type TestCase unavailable file:///Users/joshua/Qt5.2.0/5.2.0/clang_64/qml/QtTest/TestCase.qml:45 module Qt.test.qtestroot is not installed qt-labs/qtest-qml has a merge request under ‘review’ from 2 years ago!! It refers to a problem with OSX installation (OSX is our primary development environment). I have not been able to test this issue on other platforms, but noticing that both the merge request and the README install directions for qtest-qml are both very dated I thought it might be better just to ask here if this is dead, or is it supposed to work in 5.2 / OSX? Docs
Re: [Development] qtest-qml osx
On Dec 16, 2013, at 10:44 AM, Alan Alpert 4163654...@gmail.com wrote: On Mon, Dec 16, 2013 at 3:47 AM, Chao Caroline caroline.c...@digia.com wrote: Thanks I didn’t realize any of this since the TestCase docs[0] don’t refer to the “Qt Quick Test Reference” docs[1]. Which I would suggest is probably a documentation bug? I’ve been able to get the simplest case of this working (despite the docs being very abstract), but I think I’m seeing a bug when used in my project. Can someone please confirm it isn't user error before I log the bug? In my environment I have source and tests separated into `src/qml`, and `specs/qml` respectively. Regardless if I use the qmltestrunner or a QUICK_TEST_MAIN macro I’m unable to include components from the src/qml path, so unless the tst_*.qml file is actually present in that path no components are loaded. This is true whether I invoke the item with a bare reference, or with `Qt.createComponent()`. I’ve tried using the -import command line option as documented, with all variations on absolute and relative paths to the `src/qml` path. I’ve also tried `IMPORTPATH`, `INCLUDEPATH`, and `QUICK_TEST_SOURCE_DIR` in the test .pro file. Production qml files are simply not accessible by tests unless I contaminate the src folder with all the tst_*.qml files (which is a non-starter on this large of a project). Thanks, j [0] - http://qt-project.org/doc/qt-5/qml-qttest-testcase.html [1] - http://qt-project.org/doc/qt-5/qtquick-qtquicktest.html On Dec 16, 2013, at 10:44 AM, Alan Alpert 4163654...@gmail.com wrote: On Mon, Dec 16, 2013 at 3:47 AM, Chao Caroline caroline.c...@digia.com wrote: Hi, Qt Quick Test is part of Qt (in the qtdeclarative repo). I think the problem here is that you are trying to run a test using qmlscene directly. QML TestCases should be launched via a C++ harness: http://qt-project.org/doc/qt-5/qtquick-qtquicktest.html The other alternative is the qmltestrunner utility. qmlscene is not expected to work, nor planned to, but ideally support will be added to the new qml utility (such support is not currently in place but wouldn't be too hard to add). -- Alan Alpert From: development-bounces+caroline.chao=digia@qt-project.org [development-bounces+caroline.chao=digia@qt-project.org] on behalf of Joshua Kolden [jos...@studiopyxis.com] Sent: Sunday, December 15, 2013 11:18 PM To: development@qt-project.org Subject: [Development] qtest-qml osx We have a fairly large qml project, and with 5.2 we are trying to switch to TDD for all components (c++, js (coffescript), QML). Qt Creator and qmlscene in 5.2 both seem to have the same issue that files are missing: qmlscene test1.qml file:///x/d/qt/testDrivenQML/test1.qml:25 Type TestCase unavailable file:///Users/joshua/Qt5.2.0/5.2.0/clang_64/qml/QtTest/TestCase.qml:45 module Qt.test.qtestroot is not installed qt-labs/qtest-qml has a merge request under ‘review’ from 2 years ago!! It refers to a problem with OSX installation (OSX is our primary development environment). I have not been able to test this issue on other platforms, but noticing that both the merge request and the README install directions for qtest-qml are both very dated I thought it might be better just to ask here if this is dead, or is it supposed to work in 5.2 / OSX? Docs for TestCase in 5.2 imply that it’ll work the same as any QML Type. Also in a separate note, the new Qt Creator crashes consistently when trying to create a new qt quick project through the interface. Thanks for the hard work! Best, j ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] qtest-qml osx
We have a fairly large qml project, and with 5.2 we are trying to switch to TDD for all components (c++, js (coffescript), QML). Qt Creator and qmlscene in 5.2 both seem to have the same issue that files are missing: qmlscene test1.qml file:///x/d/qt/testDrivenQML/test1.qml:25 Type TestCase unavailable file:///Users/joshua/Qt5.2.0/5.2.0/clang_64/qml/QtTest/TestCase.qml:45 module Qt.test.qtestroot is not installed qt-labs/qtest-qml has a merge request under ‘review’ from 2 years ago!! It refers to a problem with OSX installation (OSX is our primary development environment). I have not been able to test this issue on other platforms, but noticing that both the merge request and the README install directions for qtest-qml are both very dated I thought it might be better just to ask here if this is dead, or is it supposed to work in 5.2 / OSX? Docs for TestCase in 5.2 imply that it’ll work the same as any QML Type. Also in a separate note, the new Qt Creator crashes consistently when trying to create a new qt quick project through the interface. Thanks for the hard work! Best, j smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
