Re: [Development] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357
On Friday 11 July 2014 14:32:51 Joerg Bornemann wrote: > BTW QTestLib did log to both until 5.2.1. > See 7fab8eb56b9309734d1b34d3d935d6a4cf14ce6e To be clear: since 5.2.0 until 5.2.1. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357
On Friday 11 July 2014 08:59:35 Alejandro Exojo wrote: > > I agree. Which is why my proposal email does not talk about debug mode. > > Oh, I'm confused then. It does in the Patch Set 6, no? The commit does not match the proposal. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357
On Friday 11 July 2014 09:13:30 Hunger Tobias wrote: > > Note that it's also possible to query the system log remotely too. I > > believe > > that is done on Android, isn't it? From all I can find on the > > Internet, in > > order to enable capture of stderr, you need to have a rooted device. > > AFAIK android is not using systemd/journald, so what we do there does > not directly apply to the situation here. It does because we use a logging system very similar to journald and the criteria to choose when to use that or when to use stderr is the same. Instead of sd_journald_send, we use __android_log_print. That's the only difference. > > I meant that each plugin for remote systems needs to decide how it's > > going to > > approach this problem. If it can access the remote log, all the > > better. If it > > can't, the best way is to use ssh -t -- with the added benefit that > > it causes > > stdio to become line-buffered. If ssh is not getting used, make sure the > > environment variable is set. > > Sure, we can come up with case-by-case ways to get to data. > > But I really want to keep the simple remote debugging use case working. > That currently requires sshd and gdbserver to be installed on the device > and I would personally prefer not to have additional dependencies on top > of that. That's there. I've given you two possible solutions to get the log sent to stderr in those cases. > I found some documentation on how to configure journald to forward its > logs to a pre-configured remote machine, which does not fit our use > case. We need to access the logs from the machine of the developer and > that will rarely be the central log server (I hope;-). At least > journalctl can produce machine readable output, so we might get away by > just retrieving that by running journalctl -o json. That is way more > data than what we currently get via stderr, so this will need more > bandwidth than the current approach. That might already be prohibitive > on some hardware. But without code that is just speculation. Right. That would be a third option, but it would also require figuring out what the target system is doing. Maybe for remote debugging we don't want to mess with journald or something else. Suppose you were ssh'ing into an OS X machine. Then we're not talking about journald, but about asl. > > And there's another advantage: if Creator is able to query the system > > log, it > > is also able to print the output of an already-running application > > that you > > attached the debugger to. > > I see why you would want journal data in your output, but I do see a > problems making that work for remote debugging/running. Even sailfish is > apparently forcing output to stderr when starting applications on-device > via Qt Creator. When I wrote the paragraph above, I was thinking of local debugging and attaching to already-running processes, processes that Creator did not launch. For local debugging, it's more reasonable. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
> ___
> From: Keith Gardner [kreios4...@gmail.com]
> Sent: 11 July 2014 14:34
> To: Kobus Jaroslaw
> Cc:
> Subject: Re: [Development] Adding support for version number comparisons
>
> On Thu, Jul 10, 2014 at 8:47 AM, Kobus Jaroslaw
> mailto:jaroslaw.ko...@digia.com>> wrote:
> Hi All,
>
> With the current state of QVersion (patchset 35) I see the following issues:
> 1. operator<() doesn't take the suffix into account (mentioned below)
> 2. There is no handling of sub version (you cannot differentiate 5.0.0, 5.0
> and 5 - they are all equal)
>
> The idea which could resolve these issues would be not to keep the suffix
> inside a QVersion class. I understand that there is a need for version
> numbers consisting of some labels for preliminary versions. That's why the
> idea is to provide a mechanism for preliminary versioning system in first
> place, and then resolve the labels problem with a simple number/string
> substitution.
>
> The problem is that the suffix does not represent just preliminary versions.
> Some projects use the suffix to represent releases as well. E.g. OpenSSL
> 1.0.1h Other projects store the git SHA in the version suffix that has
> nothing to do > with the version number.
>
> The conclusion was that the suffixes are semantic dependent and there are too
> many semantics out there to come up with one solution. Simple number/string
> substitution implies that there is a version semantic already in place.
>
Yes. That's why I leave transforming of exact suffix version into a numerical
version (and vice versa) for the user. Then comparison is done on simple
numerical format, and there is no need for user to write his comparator.
Of course, in addition we could try to think of a sensible substitution for
not-preliminary versions, too, to handle OpenSSL 1.0.1h -like cases.
>
> The mentioned mechamism for preliminary versions would operate also on
> numbers, but one segment of the QVersion would be distinct. This distinct
> segment (call it preliminary segment) would be the indication for the
> comparator to treat that segment (and followed segments) in a special way
> (i.e. if we compare the preliminary segment with normal one, we say that
> preliminary is always less than normal one, even if its numerical value is
> greater). For now, in QString version for a QVersion, I will use "*" for this
> distinction.
>
> Example:
>
> All below are preliminary versions:
>
> "5.4.0.*0" - the very first alpha version for the upcomming "5.4.0" release.
> "5.4.0.*1.1" - beta 1 release
> "5.4.0.*1.2" - beta 2 release
> "5.4.0.*2.1" - rc 1 release
> "5.4.0.*2.2" - rc 2 release
>
> And finally there is:
>
> "5.4.0" - we plan to release that, no preliminary marker
>
> How would this handle an alpha release marker as mentioned above? Also would
> "-alpha" and "alpha" have the same weight or would one have priority over the
> other?
In my implementation "-" has the same meaning as "." - it's just different kind
of separator (format arg of some methods). If you would ask e.g. "alpha" vs
"=alpha", then it's just treated as a different label. Important is only
position on the passed list, e.g.:
QString versionFoo("5.4.0.*0");
QString versionBar("5.4.0.*1");
QStringList myProjectSemantic << "alpha" << "=alpha";
QStringList yourProjectSemantic << "=alpha" << "alpha";
versionFoo.toString(myProjectSemantic); // would result in "5.4.0.alpha" - we
take index 0 from the stringlist
versionFoo.toString(yourProjectSemantic); // would result in "5.4.0.=alpha"
versionBar.toString(myProjectSemantic); // would result in "5.4.0.=alpha" - we
take index 1 from the stringlist
versionBar.toString(yourProjectSemantic); // would result in "5.4.0.alpha"
>
> There are also projects that use a suffix of "-1" to indicate a second
> release with the same version number. How would the number/string
> substitution support this?
>
As mentioned above, "-" is a different separator - not sure if it will work for
you. If your release is 5.4.0 and then you have 5.4.0-1 it would mean it's the
same as 5.4.0.1 with a different formatting.
>
> Later, we prepare for "5.4.1", we release in meantime:
>
> "5.4.1.*0", and so on...
>
> So, I propose to keep inside QVersion only segments and index of the
> preliminary segment, and drop suffix.
>
> I do think your approach has its merits but it makes too many assumptions
> about how the suffix is structured. Check out Semantic Versioning
> (http://www.semver.org) and compare how they structure their suffixes to some
> of your assumptions. I want to emphasize the examples in Rule 10 show how
> crazy the suffixes can be and how some of the content cannot be used in
> ordering.
OK. Will analyse it later more. With a quick look the current implementation
also doesn't fulfil all requirements from this document, so I just wonder which
of them are the most important for us. (Example: there can be separat
Re: [Development] QTabletEvent in QML
On Fri, Jul 11, 2014 at 11:58 AM, Rutledge Shawn wrote: > > On 11 Jul 2014, at 10:34 AM, Dean Floyd wrote: > > > I have been using the Wacom Cintiq HD 24 Touch for some of my research > efforts, and I have tried to use MultiPointTouchArea to handle the touch > events, however, this has not lead to a great deal of success. To remedy > the situation, I decided to use the Wacom SDK to intercept these events and > create my own QML component to do what MultiPointTouchArea usually does, > which isn't awfully fast with the signal emitting and all, but sufficiently > smooth - I use touch events to control a camera in a 3D scene graph. > > Yeah there is QTBUG-39572 for Linux, but if you are using the Wacom SDK I > suppose you must be on Windows. We plan to get touch working with Wacom > touch devices. I guess your Cintiq is different than the Bamboo > relative-touch device (more like a touchpad) which I test with sometimes. I'm actually on a Macintosh, and some of the boys here are on Windows. By Wacom SDK, I meant the Feel Multi Touch API. MultiPointTouchArea receives touch events generated by the Magic TrackPad on iMac, but not from Cintiq. Do you think this is still related to QTBUG-39572? > Now, I would like to draw using the Wacom Pen, and, although I can do > this through QWidget::tabletEvent(), I was not able to find a suitable QML > component which offers the same tabletEvent() functionality. I see some > examples using MouseArea to draw with a pen, but I would like to be able to > distinguish between a mouse and a pen device. In other words, I would like > to intercept QTabletEvent events within QML. Is there a way to do this? If > not, could somebody confirm that this is not possible? I would highly > appreciate any help. Thank you. > > No there is no support for QTabletEvents in QtQuick 2 yet. I experimented > with it during a hackathon last year; the patch which adds support for them > is > > https://codereview.qt-project.org/#/c/74202/ > > Splendid! I will surely take a look at it. If I manage to further your efforts on this account, I will most certainly send you patches. > But after you've got the events in QtQuick, what next? We are also > missing public API for creating and manipulating polylines and "ink" > objects. You could take the events individually and then try to use Canvas > in QML, or implement your own means of using QPainterPath in C++, or use > Qt.labs.shapes from > > https://codereview.qt-project.org/#/admin/projects/playground/scenegraph I only need the x, y, pressure, and tilt information from the pen. Then I intend to go back to C++, and use our own rendering libraries. There are various reasons why we must use QtQuick, in lieu of QtWidgets. Now I gather this is not possible with QtQuick. Thanks for confirming this. I looked at Krita, and it appears they are using Wintab for Windows, and the linux-related drivers and libraries for Linux to intercept pen events. I did not find anything suitable for Macintosh there. Does Krita handle pen events in Macintosh? Alternatively, I could use the Cocoa framework to handle the pen events, but I do not wish to enter a world of pain by trying to mix QtQuick and Cocoa. Ideally, we would like to have a QML component that intercepts tabletEvents() akin to QtWidgets. Thank you for your elaborate answer, and help! Dean Floyd EPFL ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357
On 11-Jul-14 14:14, Joerg Bornemann wrote:
> Here's the code. Maybe I missed something.
Ossi showed me what I missed.
We cannot just change stdout unconditionally.
So no reason to not do this, as long as the application call is prefixed
with "start /wait" to run it in the foreground.
---snip---
#include
#include
#include
#include
#include
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
HANDLE h = GetStdHandle(STD_OUTPUT_HANDLE);
if (h == INVALID_HANDLE_VALUE || h == NULL) {
if (!AttachConsole(ATTACH_PARENT_PROCESS))
return 1;
h = GetStdHandle(STD_OUTPUT_HANDLE);
int fd = _open_osfhandle((intptr_t)h, _O_TEXT);
if (fd <= 0)
return 2;
*stdout = *_fdopen(fd, "w");
setvbuf(stdout, NULL, _IONBF, 0 );
}
printf("Hello World from GUI app!\n");
QMetaObject::invokeMethod(&a, "quit", Qt::QueuedConnection);
return a.exec();
}
---snap---
Joerg
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
On Thu, Jul 10, 2014 at 8:47 AM, Kobus Jaroslaw wrote: > Hi All, > > With the current state of QVersion (patchset 35) I see the following > issues: > 1. operator<() doesn't take the suffix into account (mentioned below) > 2. There is no handling of sub version (you cannot differentiate 5.0.0, > 5.0 and 5 - they are all equal) > > The idea which could resolve these issues would be not to keep the suffix > inside a QVersion class. I understand that there is a need for version > numbers consisting of some labels for preliminary versions. That's why the > idea is to provide a mechanism for preliminary versioning system in first > place, and then resolve the labels problem with a simple number/string > substitution. > The problem is that the suffix does not represent just preliminary versions. Some projects use the suffix to represent releases as well. E.g. OpenSSL 1.0.1h Other projects store the git SHA in the version suffix that has nothing to do with the version number. The conclusion was that the suffixes are semantic dependent and there are too many semantics out there to come up with one solution. Simple number/string substitution implies that there is a version semantic already in place. > > The mentioned mechamism for preliminary versions would operate also on > numbers, but one segment of the QVersion would be distinct. This distinct > segment (call it preliminary segment) would be the indication for the > comparator to treat that segment (and followed segments) in a special way > (i.e. if we compare the preliminary segment with normal one, we say that > preliminary is always less than normal one, even if its numerical value is > greater). For now, in QString version for a QVersion, I will use "*" for > this distinction. > > Example: > > All below are preliminary versions: > > "5.4.0.*0" - the very first alpha version for the upcomming "5.4.0" > release. > "5.4.0.*1.1" - beta 1 release > "5.4.0.*1.2" - beta 2 release > "5.4.0.*2.1" - rc 1 release > "5.4.0.*2.2" - rc 2 release > > And finally there is: > > "5.4.0" - we plan to release that, no preliminary marker > How would this handle an alpha release marker as mentioned above? Also would "-alpha" and "alpha" have the same weight or would one have priority over the other? There are also projects that use a suffix of "-1" to indicate a second release with the same version number. How would the number/string substitution support this? > > Later, we prepare for "5.4.1", we release in meantime: > > "5.4.1.*0", and so on... > > So, I propose to keep inside QVersion only segments and index of the > preliminary segment, and drop suffix. > I do think your approach has its merits but it makes too many assumptions about how the suffix is structured. Check out Semantic Versioning ( http://www.semver.org) and compare how they structure their suffixes to some of your assumptions. I want to emphasize the examples in Rule 10 show how crazy the suffixes can be and how some of the content cannot be used in ordering. You do bring up some good points and I will need to think on them for a bit. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357
On 11-Jul-14 01:18, Thiago Macieira wrote: > Logging to both is a problem if you have something that is able to read from > both. On Windows, all debuggers and IDEs read from both. Therefore, the option > is out. That's not true. Visual Studio displays output from OutputDebugString in its debug output pane. The stderr/stdout output is printed to the console window that gets opened when you run your console application. The output is separated and that makes perfect sense. Qt Creator could have a separate output pane for OutputDebugString and we're good. BTW QTestLib did log to both until 5.2.1. See 7fab8eb56b9309734d1b34d3d935d6a4cf14ce6e BR, Joerg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357
On 10-Jul-14 20:03, Thiago Macieira wrote:
> That means we can replace the GetConsoleWindow() call with
> AttachConsole(ATTACH_PARENT_PROCESS). If it succeeds or if it returns
> ERROR_ACCESS_DENIED, we have a console.
>
> For the Windows folks around: should we do this?
I've just played around with this and unfortunately channel redirection
does not work with this approach.
myapp > foo.txt
starts myapp in the background like "myapp &" on *nix would do.
The log is written to the console window and doesn't appear in the file.
cmd /c myapp > foo.txt
Blocks the shell as expected but redirection still doesn't work.
Here's the code. Maybe I missed something.
---snip---
#include
#include
#include
#include
#include
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
if (!AttachConsole(ATTACH_PARENT_PROCESS))
return 1;
HANDLE h = GetStdHandle(STD_OUTPUT_HANDLE);
int fd = _open_osfhandle((intptr_t)h, _O_TEXT);
if (fd <= 0)
return 2;
*stdout = *_fdopen(fd, "w");
setvbuf(stdout, NULL, _IONBF, 0 );
printf("Hello World from GUI app!\n");
QMetaObject::invokeMethod(&a, "quit", Qt::QueuedConnection);
return a.exec();
}
---snap---
Joerg
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Support for your evaluation of Qt
On 11/07/14 18:50, Ziller Eike wrote:
>
> On Jul 11, 2014, at 6:21 AM, Christian Gagneraud wrote:
>
>> On 11/07/2014 11:22 a.m., Thiago Macieira wrote:
>>> On Friday 11 July 2014 10:05:03 Christian Gagneraud wrote:
Boot To Qt for Embedded Linux (Not talking about android here), is based
on Yocto (which is open-source), there exists a Qt5 layer (Dedicated
Yocto sub-project), and I think that Digia should be the official
maintainer of this project. Digia could work hand and hand with Silicon
Company like Intel, Texas Instrument, Freescale, Xilinx (these companies
maintain their own SoC specific Yocto layers). Everyone would win if the
Qt5 Layer was in a good shape and tested on platform based on the
above-mentioned SoC's manufacturers.
Today, these SoC manufacturers provide SDKs (Linux kernel + cross
toolchain + demo image) and few provide a SDK that contains Qt5. I think
it is Digia's role to help spread the Qt technology on embedded Linux.
>>>
>>> Participating in Yocto by maintaining the Qt5 layer and working on Boot to
>>> Qt
>>> are orthogonal to each other.
>>>
>>> Digia could do both if it wanted to.
>>
>> Well at least before they started "Boot to Qt w/ Android", working on
>> boot to Qt implied polishing the Yocto Qt5 layer or writing another one
>> from scratch. They obviously did some work on that and it's a pity that
>> nothing have been given back to the community. That was my point.
>>
>>> Or someone else could do the maintaining of the Qt 5 layer in Yocto. I don't
>>> see the problem with that either: the Qt Project has a lot of people from
>>> different companies collaborating together. We don't depend on Digia doing
>>> everything.
>>
>> No, Qt doesn't depend on Digia, but Digia depends on Qt!
>> When you look at their "Qt Enterprise Embedded", it's Qt, QtCreator,
>> QtSimulator, GNU, Linux, Android, with a pinch of "Enterprise
>> plug-in's and add-on's" all well packed together.
>
> You should have a look at commit reality in Qt:
> http://www.macieira.org/~thiago/qt-stats/current/qt-all.employer.relative.png
> and Qt Creator:
> http://www.macieira.org/~thiago/qt-stats/current/creator.employer.relative.png
It looks like you got a point! ;)
According to these stats, 70% of Qt commits (qt-all.employer.relative)
go to Digia, 80% of QtCreator commits (creator.employer.relative) go to
Digia.
That's quite impressive I have to say and I would like to take this
opportunity to give a big thanks to all of you.
I think Thiago was more about the Open Governance side of Qt, and I was
just trying to point to the fact that the core business of Digia is Qt,
so getting Qt widespread is good for Digia and so having an easily
accessible "Boot to Qt" is good for Qt, so at the end it's good for
Digia too.
If you look at https://github.com/meta-qt5/meta-qt5/graphs/contributors,
you won't find any Digia traces, which is quite surprising when you
think that this is the key technology behind Digia's "Qt Enterprise
Embedded".
I even beat you all, with my single 3 lines commit
So now, let's have a look at https://qt.gitorious.org/qt-labs/simulator,
or maybe not
I'm not here to start an argument, I was more looking for an open
discussion. Outside of Android, Embedded Linux is very important, it is
everywhere, in your car, your fridge, your watch, your phone, your
weight scale, your house alarm system, your home router, ... , the more embedded Linux system using Qt out
there, the more likely Digia will have business opportunity, please
don't follow Silicon Vendors in their closeness habits, embrace the Open
Source philosophy, it works!
Chris
>
> Br, Eike
>
>>
>>> Besides, IIRC the Boot to Qt project was trying to use the Android base
>>> layer
>>> because that's the best BSP that most silicon vendors provide. Notably, the
>>> vendors not participating in Yocto.
>>
>> They might have switched to Android (Well, apparently not really [1],
>> Yocto is used both for targeting Android and "Pure" Embedded Linux), but
>> AFAIK you can boot to Qt in less than 0.5s with a bare embedded Linux
>> (using Yocto or similar), whereas it takes 10 times longer with Android.
>>
>> Having said all these, Digia has its own business model, maybe I was
>> expecting Digia to behave much like Nokia, my mistake.
>>
>> Chris
>>
>> [1]
>> http://linuxgizmos.com/qt-embedded-gui-adds-yocto-recipes-hops-up-emulator/
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>
--
QtCreator/qmakeparser.cpp:42
// Parser ///
#define fL1S(s) QString::fromLatin1(s)
namespace { // MSVC2010 doesn't seem to know the semantics of "static" ...
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Support for your evaluation of Qt
On 11/07/14 18:50, Ziller Eike wrote:
>
> On Jul 11, 2014, at 6:21 AM, Christian Gagneraud wrote:
>
>> On 11/07/2014 11:22 a.m., Thiago Macieira wrote:
>>> On Friday 11 July 2014 10:05:03 Christian Gagneraud wrote:
Boot To Qt for Embedded Linux (Not talking about android here), is based
on Yocto (which is open-source), there exists a Qt5 layer (Dedicated
Yocto sub-project), and I think that Digia should be the official
maintainer of this project. Digia could work hand and hand with Silicon
Company like Intel, Texas Instrument, Freescale, Xilinx (these companies
maintain their own SoC specific Yocto layers). Everyone would win if the
Qt5 Layer was in a good shape and tested on platform based on the
above-mentioned SoC's manufacturers.
Today, these SoC manufacturers provide SDKs (Linux kernel + cross
toolchain + demo image) and few provide a SDK that contains Qt5. I think
it is Digia's role to help spread the Qt technology on embedded Linux.
>>>
>>> Participating in Yocto by maintaining the Qt5 layer and working on Boot to
>>> Qt
>>> are orthogonal to each other.
>>>
>>> Digia could do both if it wanted to.
>>
>> Well at least before they started "Boot to Qt w/ Android", working on
>> boot to Qt implied polishing the Yocto Qt5 layer or writing another one
>> from scratch. They obviously did some work on that and it's a pity that
>> nothing have been given back to the community. That was my point.
>>
>>> Or someone else could do the maintaining of the Qt 5 layer in Yocto. I don't
>>> see the problem with that either: the Qt Project has a lot of people from
>>> different companies collaborating together. We don't depend on Digia doing
>>> everything.
>>
>> No, Qt doesn't depend on Digia, but Digia depends on Qt!
>> When you look at their "Qt Enterprise Embedded", it's Qt, QtCreator,
>> QtSimulator, GNU, Linux, Android, with a pinch of "Enterprise
>> plug-in's and add-on's" all well packed together.
>
> You should have a look at commit reality in Qt:
> http://www.macieira.org/~thiago/qt-stats/current/qt-all.employer.relative.png
> and Qt Creator:
> http://www.macieira.org/~thiago/qt-stats/current/creator.employer.relative.png
It looks like you got a point! ;)
According to these stats, 70% of Qt commits (qt-all.employer.relative)
go to Digia, 80% of QtCreator commits (creator.employer.relative) go to
Digia.
That's quite impressive I have to say and I would like to take this
opportunity to give a big thanks to all of you.
I think Thiago was more about the Open Governance side of Qt, and I was
just trying to point to the fact that the core business of Digia is Qt,
so getting Qt widespread is good for Digia and so having an easily
accessible "Boot to Qt" is good for Qt, so at the end it's good for
Digia too.
If you look at https://github.com/meta-qt5/meta-qt5/graphs/contributors,
you won't find any Digia traces, which is quite surprising when you
think that this is the key technology behind Digia's "Qt Enterprise
Embedded".
I even beat you all, with my single 3 lines commit
So now, let's have a look at https://qt.gitorious.org/qt-labs/simulator,
or maybe not
I'm not here to start an argument, I was more looking for an open
discussion. Outside of Android, Embedded Linux is very important, it is
everywhere, in your car, your fridge, your watch, your phone, your
weight scale, your house alarm system, your home router, ... , the more embedded Linux system using Qt out
there, the more likely Digia will have business opportunity, please
don't follow Silicon Vendors in their closeness habits, embrace the Open
Source philosophy, it works!
Chris
>
> Br, Eike
>
>>
>>> Besides, IIRC the Boot to Qt project was trying to use the Android base
>>> layer
>>> because that's the best BSP that most silicon vendors provide. Notably, the
>>> vendors not participating in Yocto.
>>
>> They might have switched to Android (Well, apparently not really [1],
>> Yocto is used both for targeting Android and "Pure" Embedded Linux), but
>> AFAIK you can boot to Qt in less than 0.5s with a bare embedded Linux
>> (using Yocto or similar), whereas it takes 10 times longer with Android.
>>
>> Having said all these, Digia has its own business model, maybe I was
>> expecting Digia to behave much like Nokia, my mistake.
>>
>> Chris
>>
>> [1]
>> http://linuxgizmos.com/qt-embedded-gui-adds-yocto-recipes-hops-up-emulator/
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>
--
QtCreator/qmakeparser.cpp:42
// Parser ///
#define fL1S(s) QString::fromLatin1(s)
namespace { // MSVC2010 doesn't seem to know the semantics of "static" ...
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357
Looks like there are many different uses cases and point of views, we may not reach an agreement. I agree that the default settings should be as unified as possible, but, on the other and, each platform having different capabilities, it make sense to set the default behavior on a platform-per-platform basis; there are only 2 or 3 possible choices after-all. II the documentation states explicitly what the behavior is on each platform and that the behavior is to be expected on that platform, I don't think people will get confused. I really think we need a way to override the log output in the application with an api such as Denis proposed, in addition to the existing environment variable. Having a global or per-application file may be to much, things should be kept simple. I still don't think qt creator should read the output from the journal when it can avoid it. Reading the system log + stdout, merging both in a sane way ( which means qt creator will have to time stamp the output from stdout) looks overly complicated to me. The extra information the journal provide will be lost anyway since Qt Creator's output is very basic (but, sufficient most of the time). And if the order in which each line is displayed is inaccurate, it could make the debugging much harder. The extra work of reading the journal may also create a delay in the output, which is annoying when debugging. The debugging with an other IDE should also work out-of-the-box. It's not that debugging should be handled specifically, more like debugging should not be handled differently, compared to any another application, and the burden should not be put on the IDE. That being said, if it comes to this, I have no problem with Qt creator setting QT_LOGGING_TO_CONSOLE by default. As for attaching windows applications to their parent's console automatically, that would be really neat. 2014-07-11 11:25 GMT+02:00 Robin Burchell : > On Fri, Jul 11, 2014 at 11:13 AM, Hunger Tobias > wrote: > > I see why you would want journal data in your output, but I do see a > > problems making that work for remote debugging/running. Even sailfish is > > apparently forcing output to stderr when starting applications on-device > > via Qt Creator. > > Don't let our existing solution limit you. There may be better > solutions, we were time-constrained, and now resource-constrained > (i.e. we have to pick and choose what we put effort into..) so we > haven't looked into changing this any more, as far as I know. > ___ > 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] QTabletEvent in QML
On 11 Jul 2014, at 10:34 AM, Dean Floyd wrote: > I have been using the Wacom Cintiq HD 24 Touch for some of my research > efforts, and I have tried to use MultiPointTouchArea to handle the touch > events, however, this has not lead to a great deal of success. To remedy the > situation, I decided to use the Wacom SDK to intercept these events and > create my own QML component to do what MultiPointTouchArea usually does, > which isn't awfully fast with the signal emitting and all, but sufficiently > smooth - I use touch events to control a camera in a 3D scene graph. Yeah there is QTBUG-39572 for Linux, but if you are using the Wacom SDK I suppose you must be on Windows. We plan to get touch working with Wacom touch devices. I guess your Cintiq is different than the Bamboo relative-touch device (more like a touchpad) which I test with sometimes. > Now, I would like to draw using the Wacom Pen, and, although I can do this > through QWidget::tabletEvent(), I was not able to find a suitable QML > component which offers the same tabletEvent() functionality. I see some > examples using MouseArea to draw with a pen, but I would like to be able to > distinguish between a mouse and a pen device. In other words, I would like to > intercept QTabletEvent events within QML. Is there a way to do this? If not, > could somebody confirm that this is not possible? I would highly appreciate > any help. Thank you. No there is no support for QTabletEvents in QtQuick 2 yet. I experimented with it during a hackathon last year; the patch which adds support for them is https://codereview.qt-project.org/#/c/74202/ But after you've got the events in QtQuick, what next? We are also missing public API for creating and manipulating polylines and "ink" objects. You could take the events individually and then try to use Canvas in QML, or implement your own means of using QPainterPath in C++, or use Qt.labs.shapes from https://codereview.qt-project.org/#/admin/projects/playground/scenegraph I tried to use the latter approach. It depends whether you want to create vector shapes that can be manipulated later, in small quantities and unfortunately without antialiasing; or to have an art-oriented painting program, in which case you might want to try Krita. It will be ported to Qt 5 eventually. But I'm thinking more about vector drawing... We don't have polylines (sequences of lines, arcs, Bezier curves etc.) in Qt Quick because we need to figure out how to render them antialiased (maybe even without relying on MSAA) and also animatable. But what would the code look like to apply an animation to one of the control points within a polyline? You wouldn't want every point to be a QObject just to be able to make the occasional binding; and usually the points would come from non-QML data sources like sequences of tablet events, or SVG paths. A JS API for appending points to a path is not enough. An even stickier problem is how to serialize the Item graph in memory (after you have drawn some new shapes with your tablet) into a QML file. I tried and got a hacky incomplete solution working, but it became evident that QML just isn't designed for that. So if you want to create a vector drawing program in the short term, you need to create your own C++ model anyway. So then you might as well handle the tablet events in C++ too. To integrate with Qt Quick you could wrap the whole drawing renderer into a QQuickItem subclass which implements its own updatePaintNode() to render the vector shapes, or have one of those per shape. So there are several problems left to solve, and then maybe there's a chance Qt.labs.shapes could be converted into something worth shipping with Qt. Maybe we could even build a complete framework for vector drawing applications. I would like to, because as was just discussed in another thread, GraphicsView is at this point the easier solution to code up this type of use case, but it's older and isn't really the way forward for the future. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357
On Fri, Jul 11, 2014 at 11:13 AM, Hunger Tobias wrote: > I see why you would want journal data in your output, but I do see a > problems making that work for remote debugging/running. Even sailfish is > apparently forcing output to stderr when starting applications on-device > via Qt Creator. Don't let our existing solution limit you. There may be better solutions, we were time-constrained, and now resource-constrained (i.e. we have to pick and choose what we put effort into..) so we haven't looked into changing this any more, as far as I know. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357
On Thu, Jul 10, 2014 at 7:14 PM, Thiago Macieira wrote: > I'm not asking that distributions turn journald on if they don't want to. > Journald is optional. Good to have that fact stated clearly:-) > It's there in two ways: > > 1) Option -t to ssh, which forces the allocation of a TTY and, thus, logging > to stderr > 2) The environment variable > > Note that it's also possible to query the system log remotely too. I believe > that is done on Android, isn't it? From all I can find on the Internet, in > order to enable capture of stderr, you need to have a rooted device. AFAIK android is not using systemd/journald, so what we do there does not directly apply to the situation here. > I meant that each plugin for remote systems needs to decide how it's going to > approach this problem. If it can access the remote log, all the better. If it > can't, the best way is to use ssh -t -- with the added benefit that it causes > stdio to become line-buffered. If ssh is not getting used, make sure the > environment variable is set. Sure, we can come up with case-by-case ways to get to data. But I really want to keep the simple remote debugging use case working. That currently requires sshd and gdbserver to be installed on the device and I would personally prefer not to have additional dependencies on top of that. I found some documentation on how to configure journald to forward its logs to a pre-configured remote machine, which does not fit our use case. We need to access the logs from the machine of the developer and that will rarely be the central log server (I hope;-). At least journalctl can produce machine readable output, so we might get away by just retrieving that by running journalctl -o json. That is way more data than what we currently get via stderr, so this will need more bandwidth than the current approach. That might already be prohibitive on some hardware. But without code that is just speculation. > And there's another advantage: if Creator is able to query the system log, it > is also able to print the output of an already-running application that you > attached the debugger to. I see why you would want journal data in your output, but I do see a problems making that work for remote debugging/running. Even sailfish is apparently forcing output to stderr when starting applications on-device via Qt Creator. Does somebody have experience with reading data from journald remotely? Best Regards, Tobias ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QTabletEvent in QML
I have been using the Wacom Cintiq HD 24 Touch for some of my research efforts, and I have tried to use MultiPointTouchArea to handle the touch events, however, this has not lead to a great deal of success. To remedy the situation, I decided to use the Wacom SDK to intercept these events and create my own QML component to do what MultiPointTouchArea usually does, which isn't awfully fast with the signal emitting and all, but sufficiently smooth - I use touch events to control a camera in a 3D scene graph. Now, I would like to draw using the Wacom Pen, and, although I can do this through QWidget::tabletEvent(), I was not able to find a suitable QML component which offers the same tabletEvent() functionality. I see some examples using MouseArea to draw with a pen, but I would like to be able to distinguish between a mouse and a pen device. In other words, I would like to intercept QTabletEvent events within QML. Is there a way to do this? If not, could somebody confirm that this is not possible? I would highly appreciate any help. Thank you. Kind regards, Dean Floyd EPFL ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357
> -Original Message- > From: development-bounces+kai.koehne=digia@qt-project.org > [...] > Some background: on Sailfish, we launch all major system services (and > UI) through systemd services (& user session for the UI parts). Those > processes may then choose to execute processes of their own (the most > prominent example being the UI environment which will launch applications > in response to user input). With a default setup, systemd will log everything > sent to stderr of systems-launched processes, and child-launched processes > will have their stderr output attributed to the systemd service which > launched them. Out of curiosity: Would an opt-in solution (the application explicitly has to tell Qt to log to journal, e.g. through an API, maybe even through qtlogging.ini file) work for your use case? I'm wondering whether such a setup wouldn't be a good one for desktop distributions, too. I can see that e.g. warning and errors from kwin are best kept in journald. Not sure whether that means though that you necessarily want all spurious warnings and messages from every single KDE app in there. Regards Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357
El Friday 11 July 2014, Thiago Macieira escribió: > On Friday 11 July 2014 00:17:48 Alejandro Exojo wrote: > > Logging to the console _and_ journald has proven very useful to us. We > > did it specifically for an application using Qt's API, and developers > > can code, press Run (in Creator), and see the output in the same window > > with all the QT_MESSAGE_PATTERN goodness. Afterwards, if it's too noisy, > > or if you disabled some category, you can check the logs on journald (we > > logged all categories, even the disabled ones, to the journal, since we > > had or own message handler). > > You can still install your handler to do that. We're talking about the > default and I'd like to have a consistent behaviour across different OS. > It makes my implementation simpler. Yes, but as you noted in the changelog/commit message, this is a behaviour change, and this way the default message handler could be a little less useful. Since qInstallMessageHandler returns the pointer to the default message handler, one could wrap it to "decorate" it. We did that to check if we wanted stderr or not, and then call the default message handler of 5.2 or not. Then we did our journal logging. In 5.2 that always printed to stderr with the nice formatting of QT_MESSAGE_PATTERN, etc. which is very convenient. If the heuristic is good enough for all the use cases (seems at a first glance, but I want to be 100% sure, and I don't see the one on debug build), no problem. But otherwise, the only way to force the default message handler to do its thing on stderr is the environment variable, which is kind of odd, since we might want to set it in the application code to notify the library code of what we want. > > Only downside is that you might need to collect what your application > > outputs to stderr from a non-Qt library. Then yes, you might get > > duplicated messages. > > There you go. That's the default on OS X and will probably become the > default on Linux if the desktops switch to user-mode systemd. Yep, now I see it. You're right is OK as a default. > > I see this as two orthogonal things. Why would one prefer the console on > > a debug build? You might need to put the program in debug mode on the > > target hardware (only device where you have the peripherals), and need > > the enriched system logging and the debug symbols. > > I agree. Which is why my proposal email does not talk about debug mode. Oh, I'm confused then. It does in the Patch Set 6, no? > > This is the most inconvenient change, since you might need to change the > > systemd unit file to set the QT_LOGGING_TO_CONSOLE environment variable > > to have the built in journald logging. > > If we did it like that and if you ran debug-mode applications in your > system. That's not a common situation. And besides, systemd will capture > stderr anyway, just will less information. But why would that be uncommon? If you have an app that crashes on a certain environment, you might want to have both the better system logging and the debug symbols, isn't it? I know the matrix of use cases is large, and is not possible to please everyone with the defaults, but the check for a debug build really confuses me. :) So, would you see as good another patch that hints/bypasses the checks through an application attribute? Or the environment variable? Sorry if I'm being a bit picky. After more thought, yes, I think the defaults are sound. But I would be a bit more confident if there is some "knob" I can touch, as Robin said. But I'm so much more a Qt user than a developer, so we all want those knobs to play with. :-) -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
