Re: [Development] Nominating Uli Schlachter (psychon) for Approver
On 01/17/2013 08:17 AM, Thiago Macieira wrote: > On quinta-feira, 17 de janeiro de 2013 08.05.10, Samuel Rødal wrote: >>> I have never heard of Uli's name before and I cannot find any email from >>> him to this mailing list. Maybe all of the discussion on XCB was held on >>> IRC and there was nothing relevant to post to the rest of us. Also, he >>> has less than 50 reviews to his name, including changes that he was CC'ed >>> on but did not vote. >> >> Do we have any guidelines on how many reviews and/or contributions >> should precede approver status? > > We should find a rule of thumb, I'd say. Right now, it's very subjective. > > I'm more concerned that I can't recall ever seeing an email from him to this > mailing list. Well, most of the discussion around the xcb platform plugin has been happening on irc, and not so much on mailing lists. Typically when Uli has been involved in discussions between more than two parties it has been in the #xcb channel on FreeNode. -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Uli Schlachter (psychon) for Approver
On quinta-feira, 17 de janeiro de 2013 08.05.10, Samuel Rødal wrote: > > I have never heard of Uli's name before and I cannot find any email from > > him to this mailing list. Maybe all of the discussion on XCB was held on > > IRC and there was nothing relevant to post to the rest of us. Also, he > > has less than 50 reviews to his name, including changes that he was CC'ed > > on but did not vote. > > Do we have any guidelines on how many reviews and/or contributions > should precede approver status? We should find a rule of thumb, I'd say. Right now, it's very subjective. I'm more concerned that I can't recall ever seeing an email from him to this mailing list. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Uli Schlachter (psychon) for Approver
On 01/16/2013 05:47 PM, Thiago Macieira wrote: > On quarta-feira, 16 de janeiro de 2013 16.36.01, Robin Burchell wrote: >> Hi, >> >> I'd like to nominate Uli (psychon on IRC) for Approver status. >> >> Uli has some specialist knowledge that is often hard to find in any >> appreciable quality: he knows X11. He has helped out quite a bit when >> asked with reviewing, contributing to, and bouncing ideas off code >> around the xcb plugin as well as helping figure out bugs elsewhere in >> the libX11/xcb world that have hit us, from what I've heard. >> >> His dashboard can be found at:h >> ttps://codereview.qt-project.org/#dashboard,1001141 >> >> Would anyone like to second? > > Patches submitted: > https://codereview.qt-project.org/#q,owner:psychon%2540znc.in,n,z > > Reviews he's participated in: > https://codereview.qt-project.org/#q,reviewer:psychon%2540znc.in,n,z > > I have never heard of Uli's name before and I cannot find any email from him > to > this mailing list. Maybe all of the discussion on XCB was held on IRC and > there was nothing relevant to post to the rest of us. Also, he has less than > 50 reviews to his name, including changes that he was CC'ed on but did not > vote. Do we have any guidelines on how many reviews and/or contributions should precede approver status? > I'd say that nominating for approver is a bit too early on those two > conditions. However, I'll lift my concerns if the people working on X11 say > that his expertise is needed for the continued progress of the codebase. He's definitely provided a lot of valuable input around the xcb platform plugin, so I for one would certainly trust him to approve changes in that area. +1 from me. -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: expose the OS/platform in QML
On 01/17/2013 04:34 AM, Shawn Rutledge wrote: > On Wed, Jan 16, 2013 at 08:37:27AM -0800, Alan Alpert wrote: >> I can't find the current docs, but the mobility APIs already exposed a >> wealth of system information in the SystemInfo plugin: >> http://doc.qt.digia.com/qtmobility/qml-systeminfo.html . The right >> place for all this more device general stuff is there, we can just >> bring that back in Qt 5 (if it isn't already). I really think that >> SystemInfo is a much better place for this than Screen, which is >> supposed to encapsulate the screen you're currently running on (not >> the whole device!). It also has a lot of other useful device >> information. > I didn't mean the Screen object would have irrelevant stuff; my point > is that there should be a specific import for the system-level stuff, and > Screen and Window could probably be part of that same module because > they aren't 100% portable (although they are mostly portable). As > it is, Screen is in the Window module. But if you can get Screen > you already can have enough information to optimize the UI for > tablet/phone/desktop use cases (provided that the Screen object becomes > complete enough, which it currently isn't); e.g. if the screen is over > 5 inches then maybe it should have a tablet-optimized layout rather than > phone-optimized, and if it doesn't have touch then you know there will > probably be a mouse instead. Unless you are trying to make a pixel-perfect > replica that looks like it was made with native widgets, you shouldn't > need the OS, windowing system, device name etc. But that is what J-P is trying to do: Create a pixel perfect replica for the OS. > > It's kindof like the question how do you identify the type of an object > in QML or JS? One common answer is don't try, because the question you should > probably be asking instead is, does the object have the properties I need? > The fewer assumptions the code makes, the easier it is to port to different > component sets and QtQuick versions. It's the same with trying to tailor > a UI specifically for some specific device that's only going to be sold for > one year and used for two; you can bet that code will have a short life, > and waste your time later if the app is worth porting to the next device. > Personally I don't like rewriting things over and over again. > > The SystemInfo plugin has a bit more than "everyone" needs, but > I agree the minority-use-case stuff could go in there. But then it > needs to be a Qt essential module so that app developers can depend on it. > Some features will never work on every platform (brightness and contrast > etc.), only on some. Others just need attention to make them work everywhere > that they can. It seems like a mixed bag, and the docs don't make clear > what you can depend on and what you can't. "Mobility" is also a misnomer > on a desktop machine. If you want to write a QML app or component set > that still runs everywhere Qt runs in 5 years, I doubt you want to be using > that module in its current form. > > ___ > 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] Proposal - QtSerialPort graduation from the Playground
Hi, Even though I haven't accumulated many merit points in the dev list yet, I would like to make a very short review. On Thu, Jan 10, 2013 at 5:47 PM, Laszlo Papp wrote: > API headers: > > http://qt.gitorious.org/qtplayground/qtserialport/blobs/master/src/serialport/serialport.h > http://qt.gitorious.org/qtplayground/qtserialport/blobs/master/src/serialport/serialportinfo.h > The API is nice, makes good use of Qt's features one would expect: Inherits from QIODevice, good use of signals and slots. The only complain I have is the need for QT_USE_NAMESPACE_SERIALPORT, but I suspect it might be because of the playground status. I've used it on x86 (Windows) and ARM9 (Linux) with Qt4 and it's working perfectly. I'm yet to try SerialPortInfo myself but the API is just as nice. Speaking as a user of this library, I would really like this to be included in 5.1 You have my +1, for whatever it's worth. I did mention it was short right? Kind Regards, Thiago A. Correa ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: expose the OS/platform in QML
On Wed, Jan 16, 2013 at 10:34 AM, Shawn Rutledge wrote: > On Wed, Jan 16, 2013 at 08:37:27AM -0800, Alan Alpert wrote: >> I can't find the current docs, but the mobility APIs already exposed a >> wealth of system information in the SystemInfo plugin: >> http://doc.qt.digia.com/qtmobility/qml-systeminfo.html . The right >> place for all this more device general stuff is there, we can just >> bring that back in Qt 5 (if it isn't already). I really think that >> SystemInfo is a much better place for this than Screen, which is >> supposed to encapsulate the screen you're currently running on (not >> the whole device!). It also has a lot of other useful device >> information. > > I didn't mean the Screen object would have irrelevant stuff; my point > is that there should be a specific import for the system-level stuff, and > Screen and Window could probably be part of that same module because > they aren't 100% portable (although they are mostly portable). As > it is, Screen is in the Window module. But if you can get Screen > you already can have enough information to optimize the UI for > tablet/phone/desktop use cases (provided that the Screen object becomes > complete enough, which it currently isn't); e.g. if the screen is over > 5 inches then maybe it should have a tablet-optimized layout rather than > phone-optimized, and if it doesn't have touch then you know there will > probably be a mouse instead. Unless you are trying to make a pixel-perfect > replica that looks like it was made with native widgets, you shouldn't > need the OS, windowing system, device name etc. I agree the Screen object is a good place for information about the screen. But there's no problem with having the windowing system specific stuff in a Window import, and the non-windowing system stuff in a Platform import (both of which should be "mostly portable"). The main thing you need other than Screen info is input method info. It's not just that "phone" is a small screen and "desktop" is a large screen. People assume "phone" means capacitive touchscreen and "desktop" means keyboard and mouse (that's not always true, and it would be better to separate out hardware input from hardware output). So to property optimize your UI you need more information than even a complete Screen object gives you. > It's kindof like the question how do you identify the type of an object > in QML or JS? instanceof support in QML is on the todo list (still only gets done when there's time to do it ;) ). > One common answer is don't try, because the question you should > probably be asking instead is, does the object have the properties I need? > The fewer assumptions the code makes, the easier it is to port to different > component sets and QtQuick versions. It's the same with trying to tailor > a UI specifically for some specific device that's only going to be sold for > one year and used for two; you can bet that code will have a short life, > and waste your time later if the app is worth porting to the next device. > Personally I don't like rewriting things over and over again. There is not currently a holy grail pattern for flexible UI design across all devices (which really complicates the issue of what functionality that hypothetical pattern needs). Once we've found that pattern we can add whatever it takes to support "Write once. Deploy Everywhere" again. Maybe what we need is to write a hypothetical QML mockup of what a truly cross-platform, non-trivial application looks like? > The SystemInfo plugin has a bit more than "everyone" needs, but > I agree the minority-use-case stuff could go in there. The SystemInfo plugin has more than you need for pure UI considerations. I'd agree that anything necessary for writing a flexible UI, like screen info, should go somewhere more accessible. > But then it > needs to be a Qt essential module so that app developers can depend on it. > Some features will never work on every platform (brightness and contrast > etc.), only on some. Others just need attention to make them work everywhere > that they can. It seems like a mixed bag, and the docs don't make clear > what you can depend on and what you can't. "Mobility" is also a misnomer > on a desktop machine. If you want to write a QML app or component set > that still runs everywhere Qt runs in 5 years, I doubt you want to be using > that module in its current form. Of course it needs to change, and the general idea was that all the "Mobility" APIs would join Qt as essentials or addons where appropriate. The only snag is that almost all the mobility developers then left development for unrelated reasons, so I think they mostly became addons. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compile Qt-4.8.2 with QPA on windows
On Thu, Jan 17, 2013 at 12:37:40AM +0800, Thiago Macieira wrote: > On quarta-feira, 16 de janeiro de 2013 12.34.39, Amogh Kudari wrote: > > Hi All, > > > > I wanted to know whether is it possible to compile QT 4.8.2 with QPA > > on Windows ? > > QPA for non-Linux systems (besides Blackberry) is only supported in Qt 5. > > There was a time, before Qt 5, that QPA actually compiled on Mac OS X. The > "cocoa" plugin is still there, but I wouldn't write an application with that. > > There is no Windows plugin. So even if the rest of the code compiles and > works > on Windows (which is extremely unlikely), you'll still need to write the > plugin yourself. In addition to what Thiago said, the reason there is a -qpa flag on Windows is to allow for cross-compiling of other platforms on Windows hosts - if supported by the target platform. Rafael -- Rafael Roquetto | rafael.roque...@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
Re: [Development] Proposal: expose the OS/platform in QML
On Wed, Jan 16, 2013 at 08:37:27AM -0800, Alan Alpert wrote: > I can't find the current docs, but the mobility APIs already exposed a > wealth of system information in the SystemInfo plugin: > http://doc.qt.digia.com/qtmobility/qml-systeminfo.html . The right > place for all this more device general stuff is there, we can just > bring that back in Qt 5 (if it isn't already). I really think that > SystemInfo is a much better place for this than Screen, which is > supposed to encapsulate the screen you're currently running on (not > the whole device!). It also has a lot of other useful device > information. I didn't mean the Screen object would have irrelevant stuff; my point is that there should be a specific import for the system-level stuff, and Screen and Window could probably be part of that same module because they aren't 100% portable (although they are mostly portable). As it is, Screen is in the Window module. But if you can get Screen you already can have enough information to optimize the UI for tablet/phone/desktop use cases (provided that the Screen object becomes complete enough, which it currently isn't); e.g. if the screen is over 5 inches then maybe it should have a tablet-optimized layout rather than phone-optimized, and if it doesn't have touch then you know there will probably be a mouse instead. Unless you are trying to make a pixel-perfect replica that looks like it was made with native widgets, you shouldn't need the OS, windowing system, device name etc. It's kindof like the question how do you identify the type of an object in QML or JS? One common answer is don't try, because the question you should probably be asking instead is, does the object have the properties I need? The fewer assumptions the code makes, the easier it is to port to different component sets and QtQuick versions. It's the same with trying to tailor a UI specifically for some specific device that's only going to be sold for one year and used for two; you can bet that code will have a short life, and waste your time later if the app is worth porting to the next device. Personally I don't like rewriting things over and over again. The SystemInfo plugin has a bit more than "everyone" needs, but I agree the minority-use-case stuff could go in there. But then it needs to be a Qt essential module so that app developers can depend on it. Some features will never work on every platform (brightness and contrast etc.), only on some. Others just need attention to make them work everywhere that they can. It seems like a mixed bag, and the docs don't make clear what you can depend on and what you can't. "Mobility" is also a misnomer on a desktop machine. If you want to write a QML app or component set that still runs everywhere Qt runs in 5 years, I doubt you want to be using that module in its current form. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Spurious Flickering on Mac OS X Moutain Lion (Qt 4.8, OpenGL, QML 1.1)
Hello, Qt Developers. I'm new to this list, and did not get a chance to introduce myself before these: https://codereview.qt-project.org/#change,42191 https://codereview.qt-project.org/#change,42190 I am currently porting a Mac/Pc/Linux Qt 4.8 + OpenGL + QML 1.1 application from Mac OS X 10.6.8 to 10.8.2. Its entire graphical interface is drawn inside a custom declarative view instance initialized with a main QML item containing a mix of custom OpenGL items and standard QML 1.1 items. Rendering runs smoothly on Snow Leopard and on all the other supported platforms, but exhibits intermittent flickering when built and run on Mountain Lion. I've tried toggling various things and poking around the initialization of the declarative view and widget, but nothing helped, so far. This problem is pretty hard to diagnose, so I was hoping to get help from someone in here that would have experienced similar behavior with Qt 4.8 on 10.8, or get advice on what to inspect, check, or watch for, in order to get rid of the flickering. I also wonder if the application relies on undefined behavior on the other platforms, or if there indeed is a bug in Qt 4.8 on Mountain Lion regarding our specific use case. I've uploaded a screen recording exhibiting the problem here: http://vimeo.com/manctl/skanect-mountain-lion-flicker What you see on this video is a main QML ListView that displays the different application screens in a custom VisualItemModel, one by one. Scrolling this list will reveal new screens and hide old ones, triggering ItemSceneHasChanged events on all their items. Some of these screen items are custom OpenGL items that call custom OpenGL context initialization & shutdown code when entering and leaving scenes, in order to preserve GPU memory. This is when flickering seems to kick in. The application also flickers at startup, probably because of the same problem. I am sorry that I could not find more time to produce any minimal code reproducing the issue just now, but will try to. Meanwhile, anything helps! Cheers, Nicolas ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: expose the OS/platform in QML
On Wed, Jan 16, 2013 at 9:14 AM, Mohamed Fawzi wrote: > > On 16 Jan 2013, at 17:37, Alan Alpert <4163654...@gmail.com> > wrote: > >> On Wed, Jan 16, 2013 at 2:22 AM, Rutledge Shawn >> wrote: >>> On 16 Jan 2013, at 8:21 AM, Bache-Wiig Jens wrote: >>> True. It is exactly what we would use to implement the platform selector. But it can also be more powerful than that because it makes it possible to implement your own platform selectors if you disagree with whatever mechanism we come up with. (i.e you can create a loader that takes dpi, os, orientation and resolution into account) >> >> It's still not clear to me how this is intended to co-exist with the >> platform selector thread. If we implement the static selector approach >> for QML like discussed in the other thread, then you can use that in >> loaders (because you can have it apply automatically to the source URL >> passed to the Loader). So you would not need to expose the OS/platform >> to QML at all in order to implement these selectors. How would OS, DPI >> etc. be used in QML then? > > Well getting information on the current system is generally available on all > platforms, and can be useful, for example as way to cope with something > not handled by selectors. > I can understand your fear of it being misused, and the problem is real, > still I think that it is more an education problem (making clear that > selectors > are the superior alternative, and explain why). > If we have a good selector method I believe people will use it. We haven't actually defined what selectors handle yet, but I got the impression that all of these details will be handled by selectors. If they are all handled by selectors then the 'education problem' becomes one of telling users: "Never use this API, everything it does can be done better using selectors". In that scenario, I think it really is better to not have the runtime exposure at all. Perhaps we should reconvene this thread after we agree on what selectors cover? Or would that be too late? There's a clear need for better cross-platform and cross-device support in QML (for Qt 5.1 ideally), but I don't think that means we should rush in two competing implementations. Better to examine the use cases and tailor the two APIs so that they holistically support the existing needs. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Platform Content Selection
On Wed, Jan 16, 2013 at 5:16 AM, Mohamed Fawzi wrote: > > On 16 Jan 2013, at 10:54, Thomas Hartmann wrote: > >> Hi, >> [...] >>> I assume the selected content is also in the app local dir, but you >>> have a special way to access it without tripping the selector code. >>> Note that selector code, at least in the QML engine, can't be strictly >>> limited to the running app's local dir, because QML modules might want >>> to use selection too (on files in their plugin local dir). >> >> Yes we identified this issue, too. > > The main reason we left it (and also a detailed selector definition) out > is that as soon as you add libraries a problem comes in: > selectors are global, and if you allow user defined selectors > (which I am inclined to have), then one might have clashes > (same selector name used in a different way) when using several libraries The only use case I can think of for libraries to define selectors is to make them available in the application, like if a SystemInfo library added a bluetooth selector if the device had bluetooth. This usecase requires the selectors to be global. So long as libraries are clear and upfront about the selectors they enable, application developers can manage it fine themselves. Like we have with symbol names in C++. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Platform Content Selection
On Wed, Jan 16, 2013 at 1:54 AM, Thomas Hartmann
wrote:
> Hi,
>
> Am 16/01/2013 02:23, schrieb Alan Alpert:
>> On Tue, Jan 15, 2013 at 8:22 AM, Mohamed Fawzi
>> wrote:
>>> I had a long discussion with Thomas, and we came up with yet another
>>> solution :)
>>>
>>> This is in a way closer to the initial mail of Alan:
>>
>> Very close actually. But with better integration for non-QML applications ;)
>> .
>>
>>> 1) special place for application local stuff
>>> 2) global ordered list of selectors
>>
>> I assume working out the details of the selectors would be a separate
>> thread. Or did you have specific selectors in mind? The implementation
>> is useful even if selectors aren't agreed on, because this sort of
>> infrastructure is necessary for individual platforms to implement
>> their selections tightly in QML.
>
> No we did not work out the selectors in detail.
>
> The static selectors should probably be based on the platform.
> Android would define "android" and "touch".
> IOS would define "ios" and "touch".
> Windows would define "windows" and "desktop"
>
> There might be platforms where touch/desktop is ambiguous or decided at
> runtime. (Think of Windows 8 and one of these tablet/netbook hybrids).
>
> Those propably would define "windows RT" but no touch and no desktop.
>
> For the dynamic/runtime selectors I think they should be expendable by
> users, since we cannot foresee all use cases.
>
> We would provide some dynamic selectors like "retina" or the resolution
> ("800x600").
When you say dynamic selectors, do you mean selectors which are
determined at runtime or executed at runtime?
Determined at runtime, probably when the app starts up, and used in
the initial loading of the QML files will work fine. And app devs
could modify the stringlist if they need to.
Executed at runtime, as in changing from MyLayout-landscape.qml to
MyLayout-portrait.qml, won't work. At least not yet.
I'm fine with the former style of run-time selectors, but we'd need to
clarify that the 'runtime' selectors are still a fixed selection when
you evaluate URLs and not dynamic. It also makes them virtually
identical to the static selectors from a QML perspective.
>>> 3) some selectors are static (probably from the make spec), other dynamic
>>> 4) 2 URLs: direct access to local application stuff, and access with
>>> selectors
>>
>> I assume the selected content is also in the app local dir, but you
>> have a special way to access it without tripping the selector code.
>> Note that selector code, at least in the QML engine, can't be strictly
>> limited to the running app's local dir, because QML modules might want
>> to use selection too (on files in their plugin local dir).
>
> Yes we identified this issue, too.
> One quick idea was to use a ./ prefix to indicate that the resolution
> is relative.
> Actually also in the case of application code their might be cases where
> a relative path is shorter/easier to maintain than an application
> specific absolute one.
>
> So we probably need to support relative urls.
>
> But I think encouraging one absolute directory for all the application
> specific data , that might eventually also support bundling, is the
> right way. In a way I see this very similar to qrc urls (starting with ":").
>
> We could even allow including several directories. This makes lookup
> slightly harder and could lead to conflicts, but then every library
> would just use its name as a namespace. (e.g res:components/ and
> res:application/)
I prefer the single directory (at least to start), because it's
trivial for applications to do multiple directories themselves once we
have that. If you have an app content directory containing
"components" and "application" folders, it already works with
"res:components" and "res:application". On some platforms we might
have to bundle all the "multiple" directories into one single
application local directory anyways.
>
>
>>> 5) selectors are appended to the file name before the extension, special
>>> separator "_" not valid in base file name
>>
>> We allow UTF8 URLs, I don't think there's a separator not valid in
>> base file names for QML currently. But we could easily lock out a
>> particular character once you turn this feature on.
>
> If we enable the feature just for urls starting with e. g. "res:" we
> cannot break existing code. So using either "-" or "_" should be safe.
Yes, adding a selector scheme would be perfectly safe. My concern with
that approach is that
A) It makes it the exception, not the common case. Selection makes
sense as the common case because in practice, you won't have a
icon-369dpi.png unless you want to swap that out somehow.
B) It makes it incongruous with QML type selection, which doesn't have
a URL and so has to be implicitly res: (if the engine is so set).
Note that these arguments are about how it looks in QML. The QtCore
implementation could use res:, and QML could automatically prepend
that (if the engine is so set).
>
>>
Re: [Development] Proposal: expose the OS/platform in QML
On 16 Jan 2013, at 17:37, Alan Alpert <4163654...@gmail.com> wrote: > On Wed, Jan 16, 2013 at 2:22 AM, Rutledge Shawn > wrote: >> On 16 Jan 2013, at 8:21 AM, Bache-Wiig Jens wrote: >> >>> True. It is exactly what we would use to implement the platform selector. >>> But it can also be more powerful than that because it makes it possible to >>> implement your own platform selectors if you disagree with whatever >>> mechanism we come up with. (i.e you can create a loader that takes dpi, os, >>> orientation and resolution into account) > > It's still not clear to me how this is intended to co-exist with the > platform selector thread. If we implement the static selector approach > for QML like discussed in the other thread, then you can use that in > loaders (because you can have it apply automatically to the source URL > passed to the Loader). So you would not need to expose the OS/platform > to QML at all in order to implement these selectors. How would OS, DPI > etc. be used in QML then? Well getting information on the current system is generally available on all platforms, and can be useful, for example as way to cope with something not handled by selectors. I can understand your fear of it being misused, and the problem is real, still I think that it is more an education problem (making clear that selectors are the superior alternative, and explain why). If we have a good selector method I believe people will use it. > >>> >>> I wonder how useful it is to know the platform plugin though. I.e I don't >>> really care if I am on wayland or x11 or when writing QML. If I did, I >>> would probably we writing a C++ extension. >>> >>> What I primarily care about is if I am on "mac", "windows", "linux", >>> "android" or "iOS". This is information I would use quite often and only >>> exposing that would be a good start. >> >> Where should we put that information? Orientation, resolution etc. will be >> in Screen. I wonder if this gives us another reason to rename the Window >> module to something more inclusive like System or Device. Then it will make >> sense to expose all the device-specific stuff in the same module. I want to >> rename it anyway to avoid having the present situation that you import >> QtQuick.Window in order to create a Window (and get some other stuff that >> comes along for the ride). > > I can't find the current docs, but the mobility APIs already exposed a > wealth of system information in the SystemInfo plugin: > http://doc.qt.digia.com/qtmobility/qml-systeminfo.html . The right > place for all this more device general stuff is there, we can just > bring that back in Qt 5 (if it isn't already). I really think that > SystemInfo is a much better place for this than Screen, which is > supposed to encapsulate the screen you're currently running on (not > the whole device!). It also has a lot of other useful device > information. I agree with idea of using SystemInfo. > […] Fawzi ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Uli Schlachter (psychon) for Approver
On quarta-feira, 16 de janeiro de 2013 16.36.01, Robin Burchell wrote: > Hi, > > I'd like to nominate Uli (psychon on IRC) for Approver status. > > Uli has some specialist knowledge that is often hard to find in any > appreciable quality: he knows X11. He has helped out quite a bit when > asked with reviewing, contributing to, and bouncing ideas off code > around the xcb plugin as well as helping figure out bugs elsewhere in > the libX11/xcb world that have hit us, from what I've heard. > > His dashboard can be found at:h > ttps://codereview.qt-project.org/#dashboard,1001141 > > Would anyone like to second? Patches submitted: https://codereview.qt-project.org/#q,owner:psychon%2540znc.in,n,z Reviews he's participated in: https://codereview.qt-project.org/#q,reviewer:psychon%2540znc.in,n,z I have never heard of Uli's name before and I cannot find any email from him to this mailing list. Maybe all of the discussion on XCB was held on IRC and there was nothing relevant to post to the rest of us. Also, he has less than 50 reviews to his name, including changes that he was CC'ed on but did not vote. I'd say that nominating for approver is a bit too early on those two conditions. However, I'll lift my concerns if the people working on X11 say that his expertise is needed for the continued progress of the codebase. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compile Qt-4.8.2 with QPA on windows
On quarta-feira, 16 de janeiro de 2013 12.34.39, Amogh Kudari wrote: > Hi All, > > I wanted to know whether is it possible to compile QT 4.8.2 with QPA > on Windows ? QPA for non-Linux systems (besides Blackberry) is only supported in Qt 5. There was a time, before Qt 5, that QPA actually compiled on Mac OS X. The "cocoa" plugin is still there, but I wouldn't write an application with that. There is no Windows plugin. So even if the rest of the code compiles and works on Windows (which is extremely unlikely), you'll still need to write the plugin yourself. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: expose the OS/platform in QML
On Wed, Jan 16, 2013 at 2:22 AM, Rutledge Shawn wrote: > On 16 Jan 2013, at 8:21 AM, Bache-Wiig Jens wrote: > >> True. It is exactly what we would use to implement the platform selector. >> But it can also be more powerful than that because it makes it possible to >> implement your own platform selectors if you disagree with whatever >> mechanism we come up with. (i.e you can create a loader that takes dpi, os, >> orientation and resolution into account) It's still not clear to me how this is intended to co-exist with the platform selector thread. If we implement the static selector approach for QML like discussed in the other thread, then you can use that in loaders (because you can have it apply automatically to the source URL passed to the Loader). So you would not need to expose the OS/platform to QML at all in order to implement these selectors. How would OS, DPI etc. be used in QML then? >> >> I wonder how useful it is to know the platform plugin though. I.e I don't >> really care if I am on wayland or x11 or when writing QML. If I did, I would >> probably we writing a C++ extension. >> >> What I primarily care about is if I am on "mac", "windows", "linux", >> "android" or "iOS". This is information I would use quite often and only >> exposing that would be a good start. > > Where should we put that information? Orientation, resolution etc. will be > in Screen. I wonder if this gives us another reason to rename the Window > module to something more inclusive like System or Device. Then it will make > sense to expose all the device-specific stuff in the same module. I want to > rename it anyway to avoid having the present situation that you import > QtQuick.Window in order to create a Window (and get some other stuff that > comes along for the ride). I can't find the current docs, but the mobility APIs already exposed a wealth of system information in the SystemInfo plugin: http://doc.qt.digia.com/qtmobility/qml-systeminfo.html . The right place for all this more device general stuff is there, we can just bring that back in Qt 5 (if it isn't already). I really think that SystemInfo is a much better place for this than Screen, which is supposed to encapsulate the screen you're currently running on (not the whole device!). It also has a lot of other useful device information. >> Second, it would be useful to know if I am on a "phone", "tablet" or >> "desktop" platform. ( can already guess by the resolution but perhaps it >> would be convenient to abstract it a bit. > > That's a short-term classification, and anyway other types of devices are > coming. In a couple of years it will probably seem quite anachronistic to > make a distinction between just those three. What's a Galaxy Note, a phone > or a tablet? It's both. The trend is that even laptops are getting > touchscreens and touch UIs, and desktop machines without touch are being > minimized. What's more important is the physical size of the screen, how > many physical pixels are in a virtual pixel (although I still think that's a > dubious concept), whether you have multiple touch support, and if so, how > many fingers. Finding out about the touch support needs to be in this > System/Device/whatever module too (probably as a property of the Screen). > Likewise I plan to add the orientation from the accelerometer soon. > > OTOH we need to encourage app authors to write as generic code as possible to > make them as portable as possible. We can expose more information, but using > it to customize the UI should really be discouraged. Otherwise it could turn > out like the web javascript nightmare, having to customize for different > browsers, especially before HTML 5. So from that perspective maybe exposing > too much is wrong, because it will enable this scenario. We need to encourage generic code with powerful generic components, but we also need to enable specific code. There is the usecase of someone trying to get their app "out" as much as possible (cross-platform is a plus) and there's the usecase of someone writing for a specific device or device family (where Qt is still a benefit *if* it has cross-device support). This is another advantage of the separate SystemInfo plugin. The functionality is available, but it's not there by default so you have to actually need it before you start using it. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Runtime Platform Content Selection
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 multiple image resolutions within .qrc files. that could be handled nicely in the current proposal by adding -highres for example to the images. I se no reason why this "new" URL handler should not look into .qrc files. It also wouldn't hurt to check how other platforms are doing it for inspiration, as there are some precedents/prior art addressing this for several years now. iOS has the @2x and -568h naming conventions ( http://www.vigorouscoding.com/2012/03/naming-conventions-for-image-resources-in-ios/ ), Android has http://developer.android.com/guide/practices/screens_support.html , etc Best regards, Attila ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Uli Schlachter (psychon) for Approver
On Wed, Jan 16, 2013 at 4:36 PM, Robin Burchell wrote: > :h > ttps://codereview.qt-project.org/#dashboard,1001141 I'm incompetent and can't write mail apparently. That should be: https://codereview.qt-project.org/#dashboard,1001141 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Nominating Uli Schlachter (psychon) for Approver
Hi, I'd like to nominate Uli (psychon on IRC) for Approver status. Uli has some specialist knowledge that is often hard to find in any appreciable quality: he knows X11. He has helped out quite a bit when asked with reviewing, contributing to, and bouncing ideas off code around the xcb plugin as well as helping figure out bugs elsewhere in the libX11/xcb world that have hit us, from what I've heard. His dashboard can be found at:h ttps://codereview.qt-project.org/#dashboard,1001141 Would anyone like to second? BR, Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Runtime Platform Content Selection
On 16 Jan 2013, at 10:28, Bache-Wiig Jens wrote: > > On Jan 15, 2013, at 1:39 PM, Mohamed Fawzi wrote: > >> In the Platform Content Selection thread some saw runtime selection as not >> needed. >> I disagree, as I think it could be very useful in some occasions >> (high_res/low_res, different orientation,…). >> I do not believe that having a separate binary for all those things is the >> correct choice. >> Still the issues with runtime selection are different enough (and making the >> discussion on the static part unclear) that they warrant a different >> discussion. > > I completely agree with you and I realised I already started that discussion > in a separate thread: Proposal: expose the OS/platform in QML Yes I saw, and as it is already longer I think we can continue the rest of the discussion there > > If you have direct access to os, platform and any platform specific details > in qml you can make your own decisions about which files to load or use at > runtime. All within the boundaries of pure QML prototyping. It is fairly > clear to me from a component development perspective that we already need > this in 5.1 and I do not think we will be able to agree on any fixed > directory structure that would suit the needs of every developer. I.e if I > want a touch and a desktop UI, I will simply pick the right files at runtime > by checking the Platform.formFactor property in my Loader. If I want to make > the distinction on resolution or OS, I do that instead. But it is critical > that we make these properties available to QML to enable such choices. This > is a simple and pragmatic addition to QML that makes it possible to solve any > immediate issues already. Optimisations, language enhancements or build > system improvements can be added later. I agree that access to this OS information is useful, and I have nothing against it. Still I find selector based approach better in the normal case. The selectors could be defined in part by exactly the values returned by the functions you propose. Dynamic selectors could be easily handled in C++ libs, by adding some selector to the namespace of the library of the default environment. > > 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 multiple image resolutions within .qrc files. that could be handled nicely in the current proposal by adding -highres for example to the images. I se no reason why this "new" URL handler should not look into .qrc files. Fawzi > > Regards, > Jens > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Help needed with failing test: tst_qaccessibility::bridgeTest() on Windows
Hi David, Onsdag 16. januar 2013 14.13.43 skrev David Faure: > Hi Jan Arve, > > This test has failed the last 3 times I've been trying to merge an unrelated > change to qtbase, and I remember seeing similar failures before too. > > Autotest `tst_qaccessibility' failed :( > > Testing tst_QAccessibility > QtQA::App::TestRunner: Process exited with exit code 0xC005 > (STATUS_ACCESS_VIOLATION) > QtQA::App::TestRunner: test failed, running again to see if it is flaky... > * Start testing of tst_QAccessibility * > Config: Using QTest library 5.1.0, Qt 5.1.0 > PASS : tst_QAccessibility::initTestCase() > [...] > PASS : tst_QAccessibility::accelerators() > QtQA::App::TestRunner: Process exited with exit code 0xC005 > (STATUS_ACCESS_VIOLATION) > QtQA::App::TestRunner: test failure could be reproduced twice > consecutively QtQA::App::TestRunner: end tst_qaccessibility: 13 seconds, > exit code 3221225477 > > Build log: http://testresults.qt- > project.org/ci/QtBase_dev_Integration/build_00101/win32- > msvc2010_Windows_7/log.txt.gz > > The next method is bridgeTest(), which is a Windows-specific test. > Could you take a look? > Thanks. Friedemann fixed the issue (in the release branch) so it took some time to trickle into stable and will hopefully make it to dev as well now. (fix) https://codereview.qt-project.org/#change,44856 (release->stable) https://codereview.qt-project.org/#change,44901 (stable->dev) https://codereview.qt-project.org/#change,44924 Greetings Frederik -- Best regards, Frederik Gladhorn Senior Software Engineer - Digia, Qt Visit us on: http://qt.digia.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtGraphicalEffects
Hello, You may also add the documentation people (https://qt-project.org/wiki/Category:Developing_Qt::Documentation) for documentation changes. Cheers, Jerome P. Documentation Engineer - Digia, Qt Fra: development-bounces+jerome.pasion=digia@qt-project.org [development-bounces+jerome.pasion=digia@qt-project.org] på vegne av Sletta Gunnar [gunnar.sle...@digia.com] Sendt: 15. januar 2013 16:12 To: Thomas Senyk Cc: Emne: Re: [Development] QtGraphicalEffects On Jan 15, 2013, at 2:28 PM, Thomas Senyk wrote: > Hi, > > is anyone feeling somewhat responsible for QtGraphicalEffects? Yes, I do. Feel free to add me as reviewer for anything you do there. The original author and maintainer of the project has left the Qt community, so there is nobody actively looking after the module, but I try to keep an eye on it every once in a while. And I have a few bugfixes that I plan to do there in the near future also. cheers, Gunnar ___ 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] Platform Content Selection
On 16 Jan 2013, at 10:54, Thomas Hartmann wrote:
> Hi,
>
> Am 16/01/2013 02:23, schrieb Alan Alpert:
>> On Tue, Jan 15, 2013 at 8:22 AM, Mohamed Fawzi
>> wrote:
>>> I had a long discussion with Thomas, and we came up with yet another
>>> solution :)
>>>
>>> This is in a way closer to the initial mail of Alan:
>>
>> Very close actually. But with better integration for non-QML applications ;)
>> .
yup, initially We had another selection algorithm, but then I looked again at
yours,
and found it better. The only think that I don't like so much is that the
implementation
might scale quadratically with the number of selectors, but keeping an explicit
list of current matches, and shortcutting when empty/with only an element
(which should be most of the time), should speed it up.
>>
>>> 1) special place for application local stuff
>>> 2) global ordered list of selectors
>>
>> I assume working out the details of the selectors would be a separate
>> thread. Or did you have specific selectors in mind? The implementation
>> is useful even if selectors aren't agreed on, because this sort of
>> infrastructure is necessary for individual platforms to implement
>> their selections tightly in QML.
>
> No we did not work out the selectors in detail.
>
> The static selectors should probably be based on the platform.
> Android would define "android" and "touch".
> IOS would define "ios" and "touch".
> Windows would define "windows" and "desktop"
>
> There might be platforms where touch/desktop is ambiguous or decided at
> runtime. (Think of Windows 8 and one of these tablet/netbook hybrids).
>
> Those propably would define "windows RT" but no touch and no desktop.
>
> For the dynamic/runtime selectors I think they should be expendable by
> users, since we cannot foresee all use cases.
>
> We would provide some dynamic selectors like "retina" or the resolution
> ("800x600").
>
>
>>> 3) some selectors are static (probably from the make spec), other dynamic
>>> 4) 2 URLs: direct access to local application stuff, and access with
>>> selectors
>>
>> I assume the selected content is also in the app local dir, but you
>> have a special way to access it without tripping the selector code.
>> Note that selector code, at least in the QML engine, can't be strictly
>> limited to the running app's local dir, because QML modules might want
>> to use selection too (on files in their plugin local dir).
>
> Yes we identified this issue, too.
The main reason we left it (and also a detailed selector definition) out
is that as soon as you add libraries a problem comes in:
selectors are global, and if you allow user defined selectors
(which I am inclined to have), then one might have clashes
(same selector name used in a different way) when using several libraries
> One quick idea was to use a ./ prefix to indicate that the resolution
> is relative.
> Actually also in the case of application code their might be cases where
> a relative path is shorter/easier to maintain than an application
> specific absolute one.
shorter yes, easier, I am not so sure, global search and replace
can work pretty well…
>
> So we probably need to support relative urls.
I am not so sure about this, yes they have advantages, but I think
that it is possible also to live without them (they would clash with the
namespace proposal below).
>
> But I think encouraging one absolute directory for all the application
> specific data , that might eventually also support bundling, is the
> right way. In a way I see this very similar to qrc urls (starting with ":").
>
> We could even allow including several directories. This makes lookup
> slightly harder and could lead to conflicts, but then every library
> would just use its name as a namespace. (e.g res:components/ and
> res:application/)
I prefer this last approach: I would use the first component of the url as
namespace.
It would select a given directory, and a given set of selectors.
This way selectors are not global but connected to the given namespace.
The namespaced selectors should be prepended to the (hopefully few, and static
only)
global selectors.
>
>
>>> 5) selectors are appended to the file name before the extension, special
>>> separator "_" not valid in base file name
>>
>> We allow UTF8 URLs, I don't think there's a separator not valid in
>> base file names for QML currently. But we could easily lock out a
>> particular character once you turn this feature on.
>
> If we enable the feature just for urls starting with e. g. "res:" we
> cannot break existing code. So using either "-" or "_" should be safe.
I find Alan's reason for "-" compelling, no reason to like "_" more it was just
a choice we came up with.
>
>>>
>>> As lookup lookup algorithm I would use what was proposed by Alan, *but*
>>> adding the selectors to the filename, before the extension, not as extra
>>> directory
>>>
>>> The main advantage of this is that we expect just *few* special fi
[Development] Help needed with failing test: tst_qaccessibility::bridgeTest() on Windows
Hi Jan Arve, This test has failed the last 3 times I've been trying to merge an unrelated change to qtbase, and I remember seeing similar failures before too. Autotest `tst_qaccessibility' failed :( Testing tst_QAccessibility QtQA::App::TestRunner: Process exited with exit code 0xC005 (STATUS_ACCESS_VIOLATION) QtQA::App::TestRunner: test failed, running again to see if it is flaky... * Start testing of tst_QAccessibility * Config: Using QTest library 5.1.0, Qt 5.1.0 PASS : tst_QAccessibility::initTestCase() [...] PASS : tst_QAccessibility::accelerators() QtQA::App::TestRunner: Process exited with exit code 0xC005 (STATUS_ACCESS_VIOLATION) QtQA::App::TestRunner: test failure could be reproduced twice consecutively QtQA::App::TestRunner: end tst_qaccessibility: 13 seconds, exit code 3221225477 Build log: http://testresults.qt- project.org/ci/QtBase_dev_Integration/build_00101/win32- msvc2010_Windows_7/log.txt.gz The next method is bridgeTest(), which is a Windows-specific test. Could you take a look? Thanks. -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: expose the OS/platform in QML
On 16 Jan 2013, at 8:21 AM, Bache-Wiig Jens wrote:
> True. It is exactly what we would use to implement the platform selector. But
> it can also be more powerful than that because it makes it possible to
> implement your own platform selectors if you disagree with whatever mechanism
> we come up with. (i.e you can create a loader that takes dpi, os, orientation
> and resolution into account)
>
> I wonder how useful it is to know the platform plugin though. I.e I don't
> really care if I am on wayland or x11 or when writing QML. If I did, I would
> probably we writing a C++ extension.
>
> What I primarily care about is if I am on "mac", "windows", "linux",
> "android" or "iOS". This is information I would use quite often and only
> exposing that would be a good start.
Where should we put that information? Orientation, resolution etc. will be in
Screen. I wonder if this gives us another reason to rename the Window module
to something more inclusive like System or Device. Then it will make sense to
expose all the device-specific stuff in the same module. I want to rename it
anyway to avoid having the present situation that you import QtQuick.Window in
order to create a Window (and get some other stuff that comes along for the
ride).
> Second, it would be useful to know if I am on a "phone", "tablet" or
> "desktop" platform. ( can already guess by the resolution but perhaps it
> would be convenient to abstract it a bit.
That's a short-term classification, and anyway other types of devices are
coming. In a couple of years it will probably seem quite anachronistic to make
a distinction between just those three. What's a Galaxy Note, a phone or a
tablet? It's both. The trend is that even laptops are getting touchscreens
and touch UIs, and desktop machines without touch are being minimized. What's
more important is the physical size of the screen, how many physical pixels are
in a virtual pixel (although I still think that's a dubious concept), whether
you have multiple touch support, and if so, how many fingers. Finding out
about the touch support needs to be in this System/Device/whatever module too
(probably as a property of the Screen). Likewise I plan to add the orientation
from the accelerometer soon.
OTOH we need to encourage app authors to write as generic code as possible to
make them as portable as possible. We can expose more information, but using
it to customize the UI should really be discouraged. Otherwise it could turn
out like the web javascript nightmare, having to customize for different
browsers, especially before HTML 5. So from that perspective maybe exposing
too much is wrong, because it will enable this scenario.
> And eventually I might want to know even more. Such as the desktop
> environment I am using on linux,
Yeah we already have that info, we can easily expose it.
> +1 for the idea from me. But not exactly as proposed.
>
> I think we can start with just the "os" part and add other things later. And
> I think we need might need a different set of attributes from each platform.
> What if we make it possible to query the platform plugin for platform
> specific details, i.e like:
>
> I.e if (Platform.os == "iOS" &&
> Platform.property("deviceType") == "iphone" &&
> Platform.property("deviceVersion") == "3G") ...
>
> This way the platform plugins could add all the platform dependent properties
> in a clean fashion. There are plenty of things like the current GNOME theme
> and such that could be added which it would not really make sense to pollute
> the API with.
Yes dynamic properties seem like a good idea for things that will not always be
there.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML Runtime / data file deployment
On Dec 24, 2012, at 8:22 AM, Alan Alpert <4163654...@gmail.com> wrote: > For those interested in the matter, the discussion has now moved to > codereview. > > https://codereview.qt-project.org/#change,43539 adds the QQmlApplicationEngine > https://codereview.qt-project.org/#change,43540 adds the qml tool using it > > The one thing missing from QQmlApplicationEngine is the resolution of > different paths for different platforms. I'd be interested in ideas on > how best to expose that, it might even be part of a more general > device-independent code discussion. But I think that can wait for the > next patch to QQmlApplicationEngine, it's still useful for the cases > where you know your platform/path already. I startet mapping out a solution to this a while ago but was unable to find something workable: I ended up using a preprocessor macro which does not work from QML. I'll post it here anyway, perhaps someone else can pick it up and find a better solution. The core of the problem (with this solution) seems to be setting a data path at build time, reading and overriding it at deploy time, and then finally reading it at runtime from C++ and QML. A different approach exist in the form of qFindTestData(qtestcase.cpp), which searches various locations for data files. Here's my proposal: 1) The app author places the data files in a designated directory and adds an entry to the .pro file: APPDATAPATH = $$PWD/data 2) At runtime the path and files can be found again using a QAPPDATAPATH macro QString filePath = QAPPDATAPATH + "/myfile"; QFile file(filePath); file.open(QIODevice::ReadOnly) // We only guarantee read access. (If we can get away from a macro to something nicer like "QDesktopServices::AppDataLocation" we should definitively do that. The challenge is how to set it at app compile time.) 3) Moving the files and setting AppDataLocation is done at the build and/or deployment stage. This will vary depending on the Qt configuration and platform. Some cases (where I know the details): - developer builds: No copying required. AppDataLocation points directly to APPDATAPATH in the source dir. - prefix builds: The contents of APPDATAPATH is copied during "make install" and AppDataLocation is set to the install location. - iOS/Xocde integration: Add files to "Resources" folder in project. Set AppDataLocation to point to "Resources" in the app bundle. - macdeployqt: Copy files to the app bundle. Set AppDataLocation like the Xcode case. AppDataLocation needs to be set at build/deploy time, for example using qt.conf similar to how we set the plugin path today. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Platform Content Selection
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 something you can really count
on. And there are plenty of gray areas where UI and features can overlap
- multimedia, sensors, etc.
> QML. Having to access sensors through Loader wrappers may not be an
> elegant proposition, but it's realistic. If you used C++ you would
> need to have a shell class or something in order to have an #ifdef
> that selects whether to create the dummy or real implementation. QML
> has Loader as it's mechanism for selecting whether to create things.
My gut feeling is that when you ask an application developer to write
configuration specific wrappers for your cross-platform application
framework as a standard procedure, the ideal solution might have not
been found yet.
> This is *exactly* what I'm trying to improve with some form of static
> content selection. In that real life example, it would be an
> improvement to only have to duplicate the file(s) using
> maximumLineCount, not the whole QML UI (realistically, you'd probably
> abstract it into a component making it only one file). With some form
> of static content selection you can pick, like with ifdefs, the
> version of that particular component which will work (the version with
> the property on desktop, the version without the property on N900).
> And you only have to maintain two differing source files instead of
> two whole sets for one little property.
The problem is that this would be (sort of) OK but goes against the
workflow and is really a painful thing to do as it feels out of place
for several reasons:
* Maintainability. The structure can get pretty messy, especially if you
have orthogonal selectors. Android vs iOS vs Blackberry. OK, 3 files.
Tablet vs Phone. Umm, ok, 6 files... Landscape vs portrait... 12... Add
multiple versions of the OS/platform you want to support...
Combinatorial explosion. You can of course reuse *some* parts, but in
this case reuse is not coming as a natural pattern, but something you
force on yourself. Surely we can do better than "only two
(*combinations) files to maintain for one little property difference" :)
* Verbosity. QML has a nice clean syntax. Now it gets littered with
Loader boilerplate instead of one-line selectors
* Transparency. You don't see whats happening behind the Loader
statements, (i.e. what exactly is the functional difference) without
opening the actual file. If I would see a Text{} with an ifdef, I'd know
what's going on, but if I just see MyText {}... You get the idea. Also,
IDEs highlight ifdefs, which is not possible here even if you are
checking constants
* No refactor support. You have your QtQuick 1.0 Text {} element, and
discover the extra property... It's actually quite annoying to put it in
a separate file/wrapper, new file, copypaste, Loader boilerplate, etc.
To sum it up - I'm not emotionally attached to a preprocessor style
ifdef (and the ability to select source files is also a good thing), but
*some* simpler code selection mechanism that works intra-QML would be
more than welcome.
Best regards,
Attila
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Platform Content Selection
Hi,
Am 16/01/2013 02:23, schrieb Alan Alpert:
> On Tue, Jan 15, 2013 at 8:22 AM, Mohamed Fawzi
> wrote:
>> I had a long discussion with Thomas, and we came up with yet another
>> solution :)
>>
>> This is in a way closer to the initial mail of Alan:
>
> Very close actually. But with better integration for non-QML applications ;) .
>
>> 1) special place for application local stuff
>> 2) global ordered list of selectors
>
> I assume working out the details of the selectors would be a separate
> thread. Or did you have specific selectors in mind? The implementation
> is useful even if selectors aren't agreed on, because this sort of
> infrastructure is necessary for individual platforms to implement
> their selections tightly in QML.
No we did not work out the selectors in detail.
The static selectors should probably be based on the platform.
Android would define "android" and "touch".
IOS would define "ios" and "touch".
Windows would define "windows" and "desktop"
There might be platforms where touch/desktop is ambiguous or decided at
runtime. (Think of Windows 8 and one of these tablet/netbook hybrids).
Those propably would define "windows RT" but no touch and no desktop.
For the dynamic/runtime selectors I think they should be expendable by
users, since we cannot foresee all use cases.
We would provide some dynamic selectors like "retina" or the resolution
("800x600").
>> 3) some selectors are static (probably from the make spec), other dynamic
>> 4) 2 URLs: direct access to local application stuff, and access with
>> selectors
>
> I assume the selected content is also in the app local dir, but you
> have a special way to access it without tripping the selector code.
> Note that selector code, at least in the QML engine, can't be strictly
> limited to the running app's local dir, because QML modules might want
> to use selection too (on files in their plugin local dir).
Yes we identified this issue, too.
One quick idea was to use a ./ prefix to indicate that the resolution
is relative.
Actually also in the case of application code their might be cases where
a relative path is shorter/easier to maintain than an application
specific absolute one.
So we probably need to support relative urls.
But I think encouraging one absolute directory for all the application
specific data , that might eventually also support bundling, is the
right way. In a way I see this very similar to qrc urls (starting with ":").
We could even allow including several directories. This makes lookup
slightly harder and could lead to conflicts, but then every library
would just use its name as a namespace. (e.g res:components/ and
res:application/)
>> 5) selectors are appended to the file name before the extension, special
>> separator "_" not valid in base file name
>
> We allow UTF8 URLs, I don't think there's a separator not valid in
> base file names for QML currently. But we could easily lock out a
> particular character once you turn this feature on.
If we enable the feature just for urls starting with e. g. "res:" we
cannot break existing code. So using either "-" or "_" should be safe.
>>
>> As lookup lookup algorithm I would use what was proposed by Alan, *but*
>> adding the selectors to the filename, before the extension, not as extra
>> directory
>>
>> The main advantage of this is that we expect just *few* special files, all
>> files are close and reorganising the directory structure is easy.
>
> It's not so great if there are many special files, I originally
> considered the difference between a file name distinction or a
> directory distinction and thought there wasn't any. Now I can see a
> real advantage to the file name approach though, when combined with
> the special separator we can drastically reduce the potential
> incompatibility!
Also it is a lot easier to maintain. Changing the directory structure
would be a nightmare, otherwise. Also it is very easy to check all the
variants a single file has, because they are not spread around in
different directories.
> One problem with introducing this is that there's no runtime version
> selection of the QML language, so it could break existing applications
> (if we can't solve this problem it just becomes opt-in on the engine
> instance instead of appearing magically, which isn't a big loss). If
> we use a separator not valid in QML type names, like "-", then there
> will be no existing cases where someone already had a type named, for
> example, Foo-touch.qml. Then the conflict scope is greatly lessened.
> If we provide that direct access URL then the conflict scope is
> lessened even further and an effective workaround is provided (because
> the only time it's inconvenient to provide a URL is QML type
> selection). With that level of compatibility with existing QML, I
> think it could be turned on in QQmlApplicationEngine by default
> (existing deployed apps still aren't affected, but anyone brining
> their QML to the new creator te
Re: [Development] Proposal: expose the OS/platform in QML
On Jan 16, 2013, at 9:22 AM, Bache-Wiig Jens wrote: >>> >>> Second, it would be useful to know if I am on a "phone", "tablet" or >>> "desktop" platform. ( can already guess by the resolution but perhaps it >>> would be convenient to abstract it a bit. >> >> These days you can't really tell from the resolution :) But I don't >> think Qt currently has a way to distinguish xcb/wayland running on a >> tablet vs a desktop, or eglfs running on a phone vs a tablet. How would >> a typical Android application make the latter distinction? > > Yes, and that was exactly my point. We need an abstract way for a platform to > tell us if it is one of those formFactors without us guessing or knowing > exactly which device type it is. I would probably rename "phone" to > "handheld" as and iPod Touch is obviously the same form factor as well. Or the other way around; "phone" is what most handheld devices are, and the iPod Touch is a special case which we can treat as a "phone" for ui layout purposes. (And, are tablets not "handheld" ?) In any case, this (Platform.os and Platform.property) looks like a really useful API. +1 from me. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OpenGL in Qt 5.1 and onwards
On 01/16/2013 09:58 AM, Sean Harmer wrote: > On Wednesday 16 January 2013 08:12:37 Samuel Rødal wrote: >> On 01/15/2013 05:05 PM, Sean Harmer wrote: >>> On Tuesday 15 January 2013 16:37:38 Samuel Rødal wrote: On 01/15/2013 02:43 PM, Sean Harmer wrote: > Hi, > > On Monday 07 January 2013 10:00:47 Sean Harmer wrote: >> On Monday 07 January 2013 08:28:35 Sletta Gunnar wrote: >>> On Dec 18, 2012, at 2:34 PM, Sean Harmer wrote: Hi, I would like to start a discussion on the future level of support for OpenGL enablers in Qt for those that are interested. So here goes... I would like to add in a bunch more OpenGL enablers but am not sure on where >>> to best put them. Some things I have in mind are: >>> Hi Sean, >>> >>> Late reply, but I think all in all this is great. >> >> No problem and Happy New Year! >> >>> I would like to draw the >>> line at 3D scene graph and model loaders and similar as I think this >>> falls >>> outside the scope of the module, but anything that makes OpenGL easier >>> to >>> use has my vote. >>> 1) Classes that contain member functions for all OpenGL functions of a given version and profile. E.g. no need to use GLEW or similar. WIP version of this at https://codereview.qt-project.org/#change,35408 This needs resubmitting against dev of course which I will do after some refactoring of the underlying code-generator and trying an experiment with a different inheritance hierarchy. Where should this live? It fits in nicely with obtaining pointers to such objects directly from QOpenGLContext. However, it does add size to QtGui so some people may object to this being located there. The vast majority of functions are inline. The other option is to put it into a Qt3D OpenGL-enabler library and create the objects via some factory class. At present I have a bunch of other WIP patches based upon this work but they could be refactored to resolve the necessary GL functions themselves. Using these classes would make the others easier to implement but not impossible without. >>> >>> How much does this add to the library size when they are not used? One >>> scenario for QtGui is to "give an OpenGL and an OpenGL context only". >>> I'm >>> thinking especially about embedded and low-end where library size >>> might >>> still matter. Could/should we put these behind an ifdef? Either >>> !QT_OPENGL_ES or something else? >> >> I'll get some numbers put together and report back shortly but the code >> already has a #ifdef QT_OPENGL_ES_2 to remove the desktop >> version-specific >> and extension classes. > > New version of the corresponding patch against dev is at: > > https://codereview.qt-project.org/#change,44783 > > I have the numbers for a size comparison now. For a release build of > QtGui > from the dev branch on 64-bit Linux I have: > > -rwxr-xr-x 1 sean_harmer users 4084848 Jan 14 11:01 libQt5Gui.so.5.0.1 > > With all of the extension and OpenGL versions classes in this grows to > > -rwxr-xr-x 1 sean_harmer users 4781168 Jan 14 15:42 libQt5Gui.so.5.0.1 > > A delta of 696,320 bytes. > > Gunnar/Samuel, I guess it is up to you guys whether to allow this into > QtGui or not. There are some knobs we can tweak to reduce the size > somewhat though so this is an absolute upper limit: > > 1) Don't bother including classes for legacy versions of OpenGL > (1.0-2.1). > This eliminates approximately one half of the inheritance hierarchy in > the > classes introduced for OpenGL versions. This should be fine to live with > as > QOpenGLFunctions already makes most common functions available. Also, > new > code should really not be using these legacy API's. So really these are > just there for completeness. Could leave them in the source but have > them > compiled out by default via a #ifdef. Sounds good to me to not include anything pre-QOpenGLFunctions. Then again I'm still not sure it's all worth to have in QtGui. Maybe a QtOpenGLEnablers module would be better? If so there might be less harm to have the earlier versions too. >>> >>> Well yes we could put these into an enablers library as part of Qt3D for >>> example. Hmm actually it would be better as a new small module so that >>> QtQuick can use them. This would mean no access from QOpenGLContext >>> though. I would also need to refactor the other patches to resolve needed >>> symbols themselves.> > 2) Do not include all extension classes
Re: [Development] Runtime Platform Content Selection
On Jan 15, 2013, at 1:39 PM, Mohamed Fawzi wrote: > In the Platform Content Selection thread some saw runtime selection as not > needed. > I disagree, as I think it could be very useful in some occasions > (high_res/low_res, different orientation,…). > I do not believe that having a separate binary for all those things is the > correct choice. > Still the issues with runtime selection are different enough (and making the > discussion on the static part unclear) that they warrant a different > discussion. I completely agree with you and I realised I already started that discussion in a separate thread: Proposal: expose the OS/platform in QML If you have direct access to os, platform and any platform specific details in qml you can make your own decisions about which files to load or use at runtime. All within the boundaries of pure QML prototyping. It is fairly clear to me from a component development perspective that we already need this in 5.1 and I do not think we will be able to agree on any fixed directory structure that would suit the needs of every developer. I.e if I want a touch and a desktop UI, I will simply pick the right files at runtime by checking the Platform.formFactor property in my Loader. If I want to make the distinction on resolution or OS, I do that instead. But it is critical that we make these properties available to QML to enable such choices. This is a simple and pragmatic addition to QML that makes it possible to solve any immediate issues already. Optimisations, language enhancements or build system improvements can be added later. 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 multiple image resolutions within .qrc files. Regards, Jens ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] OpenGL in Qt 5.1 and onwards
On Wednesday 16 January 2013 08:12:37 Samuel Rødal wrote: > On 01/15/2013 05:05 PM, Sean Harmer wrote: > > On Tuesday 15 January 2013 16:37:38 Samuel Rødal wrote: > >> On 01/15/2013 02:43 PM, Sean Harmer wrote: > >>> Hi, > >>> > >>> On Monday 07 January 2013 10:00:47 Sean Harmer wrote: > On Monday 07 January 2013 08:28:35 Sletta Gunnar wrote: > > On Dec 18, 2012, at 2:34 PM, Sean Harmer wrote: > >> Hi, > >> > >> I would like to start a discussion on the future level of support for > >> OpenGL enablers in Qt for those that are interested. So here goes... > >> > >> I would like to add in a bunch more OpenGL enablers but am not sure > >> on > >> where > > > >> to best put them. Some things I have in mind are: > > Hi Sean, > > > > Late reply, but I think all in all this is great. > > No problem and Happy New Year! > > > I would like to draw the > > line at 3D scene graph and model loaders and similar as I think this > > falls > > outside the scope of the module, but anything that makes OpenGL easier > > to > > use has my vote. > > > >> 1) Classes that contain member functions for all OpenGL functions of > >> a > >> given version and profile. E.g. no need to use GLEW or similar. WIP > >> version of this at > >> > >> https://codereview.qt-project.org/#change,35408 > >> > >> This needs resubmitting against dev of course which I will do after > >> some > >> refactoring of the underlying code-generator and trying an experiment > >> with > >> a different inheritance hierarchy. > >> > >> Where should this live? It fits in nicely with obtaining pointers to > >> such > >> objects directly from QOpenGLContext. However, it does add size to > >> QtGui > >> so > >> some people may object to this being located there. The vast majority > >> of > >> functions are inline. The other option is to put it into a Qt3D > >> OpenGL-enabler library and create the objects via some factory class. > >> > >> At present I have a bunch of other WIP patches based upon this work > >> but > >> they could be refactored to resolve the necessary GL functions > >> themselves. Using these classes would make the others easier to > >> implement > >> but not impossible without. > > > > How much does this add to the library size when they are not used? One > > scenario for QtGui is to "give an OpenGL and an OpenGL context only". > > I'm > > thinking especially about embedded and low-end where library size > > might > > still matter. Could/should we put these behind an ifdef? Either > > !QT_OPENGL_ES or something else? > > I'll get some numbers put together and report back shortly but the code > already has a #ifdef QT_OPENGL_ES_2 to remove the desktop > version-specific > and extension classes. > >>> > >>> New version of the corresponding patch against dev is at: > >>> > >>> https://codereview.qt-project.org/#change,44783 > >>> > >>> I have the numbers for a size comparison now. For a release build of > >>> QtGui > >>> from the dev branch on 64-bit Linux I have: > >>> > >>> -rwxr-xr-x 1 sean_harmer users 4084848 Jan 14 11:01 libQt5Gui.so.5.0.1 > >>> > >>> With all of the extension and OpenGL versions classes in this grows to > >>> > >>> -rwxr-xr-x 1 sean_harmer users 4781168 Jan 14 15:42 libQt5Gui.so.5.0.1 > >>> > >>> A delta of 696,320 bytes. > >>> > >>> Gunnar/Samuel, I guess it is up to you guys whether to allow this into > >>> QtGui or not. There are some knobs we can tweak to reduce the size > >>> somewhat though so this is an absolute upper limit: > >>> > >>> 1) Don't bother including classes for legacy versions of OpenGL > >>> (1.0-2.1). > >>> This eliminates approximately one half of the inheritance hierarchy in > >>> the > >>> classes introduced for OpenGL versions. This should be fine to live with > >>> as > >>> QOpenGLFunctions already makes most common functions available. Also, > >>> new > >>> code should really not be using these legacy API's. So really these are > >>> just there for completeness. Could leave them in the source but have > >>> them > >>> compiled out by default via a #ifdef. > >> > >> Sounds good to me to not include anything pre-QOpenGLFunctions. Then > >> again I'm still not sure it's all worth to have in QtGui. Maybe a > >> QtOpenGLEnablers module would be better? If so there might be less harm > >> to have the earlier versions too. > > > > Well yes we could put these into an enablers library as part of Qt3D for > > example. Hmm actually it would be better as a new small module so that > > QtQuick can use them. This would mean no access from QOpenGLContext > > though. I would also need to refactor the other patches to resolve needed > > symbols themselves.> > >>> 2) Do not include all extension classes. We could identify
Re: [Development] Proposal: expose the OS/platform in QML
>> >> Second, it would be useful to know if I am on a "phone", "tablet" or >> "desktop" platform. ( can already guess by the resolution but perhaps it >> would be convenient to abstract it a bit. > > These days you can't really tell from the resolution :) But I don't > think Qt currently has a way to distinguish xcb/wayland running on a > tablet vs a desktop, or eglfs running on a phone vs a tablet. How would > a typical Android application make the latter distinction? Yes, and that was exactly my point. We need an abstract way for a platform to tell us if it is one of those formFactors without us guessing or knowing exactly which device type it is. I would probably rename "phone" to "handheld" as and iPod Touch is obviously the same form factor as well. jens ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
