On 9/24/2015 5:49 PM, Alan Alpert wrote:
> The point of versioning isn't to prevent different runtime outcomes,
> that's not possible as you have showed. But there's an implicit
> compile step when you run a QML file at program startup, and the
> versioning system prevents that from failing. Get
On 9/21/2015 10:51 PM, Alan Alpert wrote:
> I found part of the previous discussion, see my essay from 2012 which
> explains the versioning system:http://alan.imagin-itis.net/?p=322
Not a new discussion, indeed :)
> Now in the next minor version of Qt, say we add a QQmlFlange class to
> QtQml. A a
On 9/21/2015 8:25 PM, Giuseppe D'Angelo wrote:
> I totally agree that one can't just "import the latest" without
> breaking code, just please don't use a language mis-feature
> (unqualified properties propagating down) to support it :-) My 2 c,
We have had Q_OBJECTs which have properties that c
On 9/21/2015 6:51 PM, Alan Alpert wrote:
> On Mon, Sep 21, 2015 at 3:36 AM, Hausmann Simon
> wrote:
>> or Go, then we can see that the approach of automatically always importing
>> the latest version is known to cause more headaches
>> than do good. Very quickly the users want to be able to _pin_
WARNING: Flammable reply ahead.
On 9/21/2015 9:07 AM, Nurmi J-P wrote:
That would a massive improvement, but it boils down to the same
problem. It can only be like that if Qt and QML version numbers match.
We cannot sprinkle qtquick versions to the base classes in qtbase.
As a third party dev
Hi,
A huge +1 on this, BT support on Windows is long overdue.
While there is certainly more inertia in the windows desktop version
than probably any other Qt supported platform, Microsoft itself is
trying to nudge people into quicker upgrade cycles, and while Win8 has
certainly gotten a pushba
Hi,
Looking at the sensor list in the current sensors module, I noticed one
missing: humidity. I'm doing some sensor synthesis and nowadays
higher-end Android devices also come with humidity sensors, so it would
be great to have this as well. On Android at least there seems to be no
reason why
That's great news! I'm sure that it'll go a long way helping those who
want to evaluate it, but don't compile Qt on a daily basis. Now off to
play with it a bit myself :)
Best regards,
Attila
On 4/20/2015 11:04 PM, Nurmi J-P wrote:
>> On 20 Apr 2015, at 21:20, Nurmi J-P wrote:
>>
>> Maybe I sh
Without actually looking at the sources... How hard (or, rather, what)
is the 5.6 dependency? It would help a great deal if it was available
for at least for 5.5.
Best regards,
Attila Csipa
On 4/17/2015 6:13 PM, Nurmi J-P wrote:
>> On 16 Apr 2015, at 23:01, Nurmi J-P wrote:
&g
> hear if anyone has experience of what development of large
> apps with Xamarin is like vs. Qt for mobile?
>
>
> On 16 April 2015 at 11:32, Attila Csipa wrote:
>> IANAL but using "for Android" should be fine w both Google and Qt (just
>> stick the TM notice in yo
name would
IMO go a long way to understand what this is about, especially as it can
be confusing as to how it relates to other Qt modules and technologies.
Best regards,
Attila Csipa
On 4/13/2015 3:58 PM, Nurmi J-P wrote:
>> On 13 Apr 2015, at 14:13, Harri Pasanen wrote:
>>
>>
On 4/13/2015 3:00 PM, Nurmi J-P wrote:
> Indeed. UIs have come a long way since the days of Windows 95 and
> others where it was sufficient to draw buttons and checkboxes a bit
> differently. These days, UIs are full of little transitions and
> effects. When those things are missing or slightly
On 21-Apr-14 18:14, Thiago Macieira wrote:
> Em seg 21 abr 2014, às 15:31:57, Yves Bailly escreveu:
>> 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 sui
rom a user accessible
directory/source, you're likely ok. This is especially tricky on mobile
- in my (IANAL) reading, Ministro is OK, but bundling the Qt libs within
apps is a grey area at best unless you take extra precautions regarding
the disclaimers/instructions.
Best regards,
Attila Csipa
On
On 16/01/13 17:36, Mohamed Fawzi wrote:
I am certainly not against the idea of a faster/more efficient static way of
choosing resources but it cannot depend on a predetermined directory ordering.
I believe we should rather focus the immediate efforts on a subset of the
problem, like handling m
On 16/01/13 02:43, Alan Alpert wrote:
> I was talking about just UI. For features we have existing APIs, like
> http://doc.qt.digia.com/qtmobility/qsysteminfo.html#hasFeatureSupported
> (couldn't find the Qt 5 ex-mobility docs) which could be exposed to
Not part of even Qt Essentials, so not somet
On 15/01/13 18:27, Nurmi J-P wrote:
> What do you think about exposing the underlying operating system and/or
> platform name in QML?
> ...
> Which one of these proposals do you like the most, or are you against the
> whole idea?
In my eyes the real question is that comes after this one - once y
On 15/01/13 12:22, Mohamed Fawzi wrote:
>
>> - Which real world problems do we address? [By "real world" I
>>explicitly do include handset makers, and potential single-
>>platform interest in that area, but it's definitely not
>>restricted to those]
> Dynamic interfaces, with transition
On 10-Jan-13 17:26, Alan Alpert wrote:
>> The Qt
>> heritage so far was, to maximize portability level, to "test for
>> features" - something sadly currenly NOT possible in an easy way in QML.
> The Qt heritage so far was desktop, where cross-device compatibility
> meant "make sure it'll still work
On 10-Jan-13 04:25, Alan Alpert wrote:
> So I'll try to replace "cross-platform" now with "cross-device".
\> but I still prefer run-time). Android has the same problem, I have a
> lot of apps on my Nexus 7 which either literally or metaphorically do
> not work on that device. There are also apps th
On 08-Jan-13 18:54, Alan Alpert wrote:
>> It seems to me that this is a problem which can/should be solved at the
>> build system level.
>
> I had the impression that it shouldn't be solved at the build system
> level (even though it can be). That breaks QML as an interpreted
> language, whic
On 08-Jan-13 02:03, Alan Alpert wrote:
> What I suggest is a path based swap-out like Plasma has, but a little
> more generic than being tied into the Plasma Package format. Here's
> the basic algorithm for swapping, where platformSelectors is an
> ordered list of selectors specified for the platfo
On 17-Dec-12 00:20, Alan Alpert wrote:
>> I don't necessarily care how different a shiny new API implementation is and
>> if the fact that my application runs on it is purely coincidental based on
>> how I use those APIs, but not having a way to say "YES, I know you bumped an
>> API version, YES, I
know there are potential
incompatibilities, and YES, I tested it, and YES, it still works" is
super-frustrating.
On 13-Dec-12 20:10, Alan Alpert wrote:
> On Wed, Dec 12, 2012 at 3:03 PM, Attila Csipa wrote:
>
>> Yes, I agree on the principle, but the implementation gets in the
On 12/12/12 23:01, Alan Alpert wrote:
> Major version means high-level incompatibilty, so if you import QtQml
> 2.0 now don't expect it to just work with QtQml 3.0. Minor version
> means features, which actually means some low-level incompatibilty
> because it's a different language to C++. So Q
On 12/12/12 12:22, Sorvig Morten wrote:
> On Dec 11, 2012, at 4:25 AM, Alan Alpert <4163654...@gmail.com> wrote:
>> import Qt 5.0
>>
>> Which imports all QML modules in the Qt Essentials released with 5.0.0
If the idea is to import the essentials, then call it that: "import
QtEssentials (from Qt)
On 07/04/2012 12:00 PM, d3fault wrote:
>
> > This is a bit of a red herring. You can do everything in the .ui you can
> > do in C++ exactly because there is not that much you can do with it. You
> > can have a fully static QML (without any JS) for the same purpose, but
> > that would make no sense
On 07/04/2012 10:17 AM, d3fault wrote:
> Lorn, so you think it should be allowed that Qt Modules are not
> interoperable?
>
> Also, did QML in the Trolltech days have javascript hacked on and
> forced-JIT in the design? There's a 3rd option that I intentionally
> didn't mention that is actually
28 matches
Mail list logo
