Re: [Development] Support for your evaluation of Qt

[Ziller Eike]

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

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

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
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

[Thiago Macieira]

On Thursday 10 July 2014 23:53:20 Lisandro Damián Nicanor Pérez Meyer wrote:
> On Thursday 10 July 2014 10:07:56 Thiago Macieira wrote:
> [snip]
> 
> > Creator must be able to handle reading from the system log before logging
> > to the system is enabled for that system. On Linux, the code is already
> > there, so we have to tell distributions *not* to enable journald yet.
> 
> AFAIU from this thread, journald support should not be enabled except
> "regular users can read the output". Now what I'm missing here is: if Qt is
> built with journald support, can it be still be used if journald is *not*
> present?
> 
> Yes, I happen to be maintaining Qt for a distro in which users can still
> choose the init system.

Don't enable journald if your system doesn't use journald.

As for having journald optionally in the distro, if we can detect at runtime 
and fallback if it's not running, we should implement it.

If we can't detect, then don't enable the feature in your distro unless you're 
sure that journald will be running (excepted misconfiguration, of course).

-- 
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

[Thiago Macieira]

On Friday 11 July 2014 07:45:23 Alejandro Exojo wrote:
> It might be even worse if systemd-shim provides that directory. Is it worth
> to  try sd_journal_open() and see if it fails? Or check some other way if
> systemd actually launched the application?

No and no. 

sd_journal_open might fail because the application can't open the log file, but 
logging to the journal is the intention. We're asking that distros not enable 
logging there if the user can't open the journal, but some embedded devices 
may want exactly that. So this option is out.

Checking if the application was launched by systemd is also not an option IMHO 
because it would mean subprocesses wouldn't use journald, but instead go to 
stderr, which in turn makes that output be attributed to the parent process.

-- 
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

[Alejandro Exojo]

El Friday 11 July 2014, Lisandro Damián Nicanor Pérez Meyer escribió:
> AFAIU from this thread, journald support should not be enabled except
> "regular  users can read the output". Now what I'm missing here is: if Qt
> is built with journald support, can it be still be used if journald is not
> present?

No. Quote from: 
http://www.freedesktop.org/software/systemd/man/sd_journal_send.html

"If systemd-journald(8) is not running (the socket is not present), those 
functions do nothing, and also return 0."
 
> Yes, I happen to be maintaining Qt for a distro in which users can still 
> choose the init system.

And unfortunately, there is no clean way to test for it. There is the 
sd_booted() function, but:

"Internally, this function checks whether the directory /run/systemd/system/ 
exists. A simple check like this can also be implemented trivially in shell or 
any other language."

Which wasn't enough in my tests. Since I used systemd to boot the (developer) 
system, but I ran the app on Creator, it would return true all the time, and I 
got no output on Creator.

It might be even worse if systemd-shim provides that directory. Is it worth to 
try sd_journal_open() and see if it fails? Or check some other way if systemd 
actually launched the application?

Also, the way is done now (more after the patch on review) is to check for the 
console first, and then the decision is done. If the heuristics to find a 
console are good enough for you, having journald support is irrelevant, since 
if you are in a console you'll get the stderr printing.

-- 
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

Re: [Development] Support for your evaluation of Qt

[Christian Gagneraud]

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.

> 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

Re: [Development] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357

[Lisandro Damián Nicanor Pérez Meyer]

On Thursday 10 July 2014 10:07:56 Thiago Macieira wrote:
[snip]
> Creator must be able to handle reading from the system log before logging to
> the system is enabled for that system. On Linux, the code is already there,
> so we have to tell distributions *not* to enable journald yet.

AFAIU from this thread, journald support should not be enabled except "regular 
users can read the output". Now what I'm missing here is: if Qt is built with 
journald support, can it be still be used if journald is *not* present?

Yes, I happen to be maintaining Qt for a distro in which users can still 
choose the init system.

-- 
UNIX is basically a simple operating system, but you have to be a
genius to understand the simplicity.
  Dennis Ritchie

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

[Development] QML CheckBox, ComboBox & QObject property bindings

[Juan Navarro]

Hi; I'm trying to better understand what are de limitations of the
bindings when using QObject properties in my QML files, as it seems to
work in a different way depending on the Component used.

Say my app manages several instances of QObject* data items, which
have 3 Q_PROPERTies: text, bool and number. The C++ side will set a
QML property with one of those instances, and the QML side allows to
edit the object properties through a TextField, a CheckBox and a
ComboBox. Nothing fancy so far. Actually this is what is explained
here:
http://qt-project.org/doc/qt-5/qtqml-cppintegration-exposecppattributes.html

Problems start to appear when the C++ side changes the object
instances on the QML property: the TextField will automatically catch
the change and show the new text, but the other Components won't
update themselves.
This is a real inconvenience because I had found that this pattern of
"injecting data items into QML" really simplifies the manipulation of
data from a QML UI.

I have created a full and working example consisting of both basic
QObject property accesses and Object-Type data:
https://dl.dropboxusercontent.com/u/315932/QtItemDataTest.zip

Clicking on buttons 1, 2 & 3 and editing the fields, will show how all
values are properly stored on their corresponding data objects, but
Components won't load their corresponding values.

Could you please enlighten me about this issue?
Regards,
Juan Navarro
___
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

[Robin Burchell]

On Wed, Jul 9, 2014 at 11:43 PM, Thiago Macieira
 wrote:
> == Problematic ==
> Qt 5.3 and dev are currently able to send the output of qDebug, qWarning and
> the rest of the logging framework to somewhere other than stderr. That's done
> on Windows, BlackBerry, Android, and on Linux systems with journald.
> Additionally, there's a pending patch for OS X to use the Apple System Log [5]
> and I had a patch for MeeGo that made it go to the standard Unix syslog.
>
> We have a problem of wanting a cake and eating it too:
>
> 1) we want applications to send their logging to the system log where
> possible, which usually logs more information like the log level, time,
> application name and PID. Such a system is searchable and may allow us to add
> additional information, like the category (for category logging), file name,
> line number, function context, etc.
>
> 2) we also want to see the output when we run applications from the terminal
> or capture the output with QProcess.
>
> The absence of output causes bug reports like [2] and [4].

Let me explain why I implemented the journald-logging support the way I did.

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.

I implemented support for this because the situation as described
above is frankly unusable for us. Output was wrongly attributed to
parent processes, which made tracking down the real source of a
problem interesting at times. The other stuff we got (like categorized
warnings, a globally usable log - to view whole system effects of
things - etc, are just icing on the cake)

I wanted to send all non-interactive logging output to systemd.
Interactive output (such as running things by hand) should go to the
console, on the assumption that there is someone actively monitoring
the other end (hence the console check).

I added the environment variable workaround after this very problem
(QtCreator output) came in in Sailfish. We then adapted our Creator
setup to set the environment variable:

https://github.com/sailfish-sdk/sailfish-qtcreator/commit/cc880444b433bc3a86305601c1471ffd292c737e
https://github.com/sailfish-sdk/sailfish-qtcreator/commit/34c8fcf9d8f749796a7f43fb52997c43f286c480


> == Solutions ==
> === Heuristically determine at runtime where to send the log ===
> Which is what I'm trying to do above.
>
> On Windows, we check whether we have a console and whether stderr is not NUL.
>
> On Unix, I have implemented the same checks.
>
> We can also use the fact of whether the main application is in debug mode or
> not.

I think this is the nicest option, as said above. I may be biased, in
that I wrote the initial implementation for journal logging :-)

That having been said, as with all heuristics, I think we should
strive to make them as simple as possible, otherwise they're going to
become non-obvious.

My vote would be to just have the correct environment variable
injected. It's our knob to customize this behavior already. It's our
knob, and we're also responsible for the behavior of it, so why not
make use of it? I understand the knee-jerk reaction to modify
application \environment, but we're talking about Qt changing Qt's
behavior through a public environment variable here, not rocket
science, KILL_ALL_HUMANS, LD_PRELOAD, or anything scary
.
BR,
Robin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Support for your evaluation of Qt

[Thiago Macieira]

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.

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.

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.
-- 
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

[Thiago Macieira]

On Friday 11 July 2014 00:17:48 Alejandro Exojo wrote:
> El Wednesday 09 July 2014, Thiago Macieira escribió:
> > === Log to both ===
> > Aside from the extra overhead, this causes systems that capture both
> > stderr
> > and the system log to record and display the same message twice. That's
> > the
> > source of task [3].
> > 
> > This is not an option.
> 
> Why not? Task [3] is an issue in Qt Creator, isn't it? Why it needs to read
> the system log on Windows?

Because that's the way to do it on Windows. It's been established for 15 or 20 
years that applications log via OutputDebugString. GUI applications can't 
write to the console unless they AllocConsole or attach to an existing one -- 
and attaching is only permitted since Windows XP.

The big problem I found when implementing this is that systemd and launchd 
will capture your stdout and stderr into the system log. So if we log to both, 
then the message appears duplicated in the syslog for all applications 
launched by those tools.

> 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.

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.

> 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.

> > === Heuristically determine at runtime where to send the log ===
> > On Unix, I have implemented the same checks.
> > 
> > We can also use the fact of whether the main application is in debug mode
> > or not.
> 
> 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.

> 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.

> I thought that it was agreed/known to Qt Creator developers that
> QT_LOGGING_TO_CONSOLE might be gently defaulted to true for applications run
> by Creator.

It isn't. Creator devs are skeptical about modifying the environment by 
default. It's bad enough that it modifies PATH during the build process -- that 
means if you build with a Qt whose tools are in /usr/bin, you lose any 
overrides you placed in PATH (such as icecc).

> > Note: if journald is writing to volatile storage, regular users can't read
> > the log. Therefore, system logging is not available.
> > 
> > Linux distributions should not enable journald logging unless regular
> > users
> > can read the output.
> 
> I think users can read their user journal, independently of the storage.
> This is as user nobody:
> 
> $ systemd-journalctl
> Showing user generated messages only. Users in the group 'adm' can see all
> messages. Pass -q to turn this message off.

$ systemd-journalctl 
No journal files were found.

Like I said, it depends on the journald configuration. Distributions should not 
enable journald unless they also configure journald in a way that users can 
read back what they've logged.

-- 
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

[Thiago Macieira]

On Friday 11 July 2014 00:27:51 Alejandro Exojo wrote:
> Would it be too problematic to make the environment variable 
> (QT_LOGGING_TO_CONSOLE, which already is in use) accept also a "2" for
> logging  to both sources?

Problematic, no. It can be easily implemented.

But it's an option we discarded. It makes no sense to log to both 
destinations. If you're using a tool that can read the syslog, then it doesn't 
matter which one it was sent to, but it will be a problem if you send to both. 
If you're using a tool that can't, then you want to send to stderr only.

> To me, the really interesting feature of providing such code inside of Qt
> is  to enable it without having to touch legacy/third party code. Having it
> for your application is also nice, but you'll likely need to override it
> somehow to integrate it with your configuration or UI.

If you have legacy, set to 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

[Development] Trying to fix qtmultimedia on Hurd

[Lisandro Damián Nicanor Pérez Meyer]

As you might know Debian has a Hurd port and almost all Qt5 is building there, 
except for QtMultimedia.

The problem lies on V4L support. We tested that the rest of the compilation 
works by adding a v4l header to the gstreamer test (yes, it's a hammer-like 
solution) and thus disabling all gstreamer including v4l.

Of course this is not the best solution, so I filled [0]. Yoan kindly showed 
me where to start with and I came up with [1]. I think this is really WIP but 
I wanted to do a first attempt to see what you think should be 
modified/added/removed/whatever.

I would love if you could take a look at it.

Thanks, Lisandro.

[0] 
[1] 

-- 
Outside of a dog, a book is man's best friend.
Inside of a dog, it's too dark to read.
 -- Groucho Marx

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357

[Alejandro Exojo]

El Thursday 10 July 2014, Koehne Kai escribió:
> Provide a define QT_LOG_TO_CONSOLE  that let QCoreApplication.h record
> whether it should log to console (QT_LOG_TO_CONSOLE=1), to the system
> (QT_LOG_TO_CONSOLE=0), or both (QT_LOG_TO_CONSOLE=2). 

Would it be too problematic to make the environment variable 
(QT_LOGGING_TO_CONSOLE, which already is in use) accept also a "2" for logging 
to both sources?

To me, the really interesting feature of providing such code inside of Qt is 
to enable it without having to touch legacy/third party code. Having it for 
your application is also nice, but you'll likely need to override it somehow 
to integrate it with your configuration or UI.

-- 
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

Re: [Development] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357

[Alejandro Exojo]

El Wednesday 09 July 2014, Thiago Macieira escribió:
> === Log to both ===
> Aside from the extra overhead, this causes systems that capture both stderr
> and the system log to record and display the same message twice. That's the
> source of task [3].
> 
> This is not an option.

Why not? Task [3] is an issue in Qt Creator, isn't it? Why it needs to read 
the system log on Windows?

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).

It's not hard at all to do it on your application if you want to fine tune it. 
Actually, I never expected to see the journald logging in Qt, but having it 
IMHO it's a boon, since you can use the feature for 3rd party applications.

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.

> === Heuristically determine at runtime where to send the log ===
> On Unix, I have implemented the same checks.
> 
> We can also use the fact of whether the main application is in debug mode
> or not.

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.

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.

> == Summary of systems ==
> System services on Linux with journald:
>  - default stderr: captured into system log
>  - system logging: available
>  - is stderr useful: yes, for launching from terminal

Note that you can teach systemd to ignore stderr/stdout if wanted. If the app 
is written with Qt, that can be a sane default.
 
> And then some desktop Linux distributions decided to enable journald. The
> effect of that is task [6]: Qt Creator shows no output because it goes to
> journald.

But this comment is/was in the code:

"We use isatty to catch the obvious case of someone running something 
interactively. We also support environment variables for Qt Creator use (...)"

I thought that it was agreed/known to Qt Creator developers that 
QT_LOGGING_TO_CONSOLE might be gently defaulted to true for applications run 
by Creator.

That environment variable seems like "API" to me, and a useful one that 
Creator could use. Of course they couldn't predict some distributions would 
pass -journald to configure.


>From the other messages:

> * Support for journald in the pre-built Qt binaries:
> Disabled.

Probably will be that way for a long time. If Qt binaries are built with and 
old Ubuntu, they just don't have libsystemd-journal.

> Note: if journald is writing to volatile storage, regular users can't read
> the log. Therefore, system logging is not available.
> 
> Linux distributions should not enable journald logging unless regular users
> can read the output.

I think users can read their user journal, independently of the storage. This 
is as user nobody:

$ systemd-journalctl
Showing user generated messages only. Users in the group 'adm' can see all 
messages. Pass -q to turn this message off.

-- 
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

Re: [Development] Support for your evaluation of Qt

[Christian Gagneraud]

On 10/07/2014 11:19 p.m., Mitch Curtis wrote:
>
> On 07/10/2014 12:20 PM, Ch'Gans wrote:
>> On 09/07/14 19:53, Andrea Barna wrote:
>>> Hi,
>>>
>>> I am Andrea from Digia Qt, I have recently taken over the Qt
>>> businessin your region.
>> Hi Andrea,
>>
>> All the best for your new position!
>>
>>> I noticed that you downloaded the trial version of Qt last year and
>>> Iwas wondering whether the evaluation went well.
>>>
>>> It would be helpful to understand why you were evaluating Qt, and
>>> learn more about what type of application you are developing.
>> I downloaded your evaluation version of Qt to see how different it is
>> from the open source one. I am especially interested in embedded and
>> industrial application and as such I was curious about your "Boot to Qt"
>> technology.
>> I was not really surprised to discover that your proprietary "Boot to
>> Qt" technology is based on the open-source Yocto project [1], and I
>> think that instead of keeping this technology closed, you should be the
>> official maintainer of the Qt5 Yocto layer (lot of work is needed there,
>> and you have handles in-house), I think you should contact the Linux
>> Foundation [2], they will be glad to see you being a major actor in the
>> open-source embedded Linux world.
>>
>>   > Furthermore is there anything that Digia–Qt can help you with?
>>
>> Definitely yes: please open up your open source based
>> commercial/proprietary boot to Qt technology.
>> I am not asking that because I am an open-source fanatic, I am asking
>> that because this is the only reliable and efficient way to get Qt
>> massively adopted on the embedded/industrial Linux market, I think that
>> Digia should be a (publicly visible) key actor in this sector.
>>
>> Maybe one day you will be able to replace your "Code once, run
>> everywhere" with "Code once, run everywhere, without pain!".
>> Getting Qt5 + Yocto + OpenGL-ES running across different ARM SoCs is a
>> real pain.
>>
>> Best regards,
>> Chris
>>
>> PS: No disrespect to you, Digia, Nokia, TrollTech and all the Qt trolls,
>> hat off and thumb up to all you guys! I am just tired to see a beautiful
>> open-source SW community being permanently fooled by professional
>> closed-source HW company. Please don't be part of this masquerade!
>>
>> PS2: I've CC'ed the Qt developer mailing list (public archived available
>> [3]), hoping this could be useful to someone, somehow, someday.
>>
>> [1] https://www.yoctoproject.org/
>> [2] http://www.linuxfoundation.org/about/contact
>> [3] http://lists.qt-project.org/pipermail/development/
>>
>
> I'm curious how you think Digia can fund future development of things 
> like Boot to Qt if they give it away for free?

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.

On the side, Qt3 (yes this is not a mistake, it is a three) is 
officially supported by Yocto (courtesy of Intel) for the sake of LSB 
compliance...
http://git.yoctoproject.org/cgit/cgit.cgi/meta-qt3/tree/README

Chris


>
>>> I look forward to hearing about your project. >
>>> Best Regards,
>>> Andrea
>>>
>>> Andrea Barna | Junior Sales Executive
>>> Digia Norway AS, Sandakerveien 116, PoBOX 23 Nydalen, 0410 Oslo, Norway
>>> Email: andrea.ba...@digia.com | Phone : +47 210 80 420 | Fax : +47 
>>> 21080439
>>> http://qt.digia.com |Qt Blog: http://blog.qt.digia.com/ |Qt 
>>> Facebook: www.facebook.com/qt  |Qt Twitter: @QtbyDigia
>>>
>>> --
>>> PRIVACY AND CONFIDENTIALITY NOTICE
>>> This message and any attachments are intended only for use by the 
>>> named addressee and may contain privileged and/or confidential 
>>> information. If you are not the named addressee you should not 
>>> disseminate, copy or take any action in reliance on it. If you have 
>>> received this message in error, please contact the sender 
>>> immediately and delete the message and any attachments accompanying 
>>> it. Digia Plc does not accept liability for any corruption, 
>>> interception, amendment, tampering or viruses occurring to this 
>>> message.
>>> -
>>>
>

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/develop

Re: [Development] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357

[Shawn Rutledge]

On 10 July 2014 19:17, Thiago Macieira  wrote:
> On Thursday 10 July 2014 16:50:22 Shawn Rutledge wrote:
>> What if we use qtlogging.ini (or equivalent on other systems) to
>> control whether the logs go to the system log or not?  I agree that
>> every ordinary KDE user doesn't need to have unread logs taking up
>> disk space, but maybe developers would like to turn on output to the
>> journal permanently for after-the-fact diagnosis when something
>> unexpectedly crashes or misbehaves.
>
> That doesn't solve the problem of the default. What do we do when
> qtlogging.ini isn't present?

I don't think it would need to go to the journal by default.  If users
don't know how to turn it on, they probably don't need the feature
either.  We just need to make it easy to turn on.

> And how do you debug an application that got installed on a system that
> already has qtlogging.ini?

Edit it and run the application again and try to reproduce the bug
again?  Being able to debug after something has already happened is a
rare privilege anyway.  If you expect problems you can turn on the
logging in advance though.

Or maybe it could be configured on a per-application basis in addition
to the defaults.  Maybe we invent a standardized easy way that an app
can allow its own QSettings to control the logging, like have a
standard [qtlogging] section.  We could make it opt-in by requiring
that you call a method on your QSettings object to enable the standard
logging section, and after that, users will be able to edit the
settings file and turn on logging categories just as they can in
qtlogging.ini.  Or it could be always-available if that doesn't bother
anybody...

>> On Windows I never liked CONFIG += console, because it's never in the
>> .pro by default (usually not in manual tests or examples, and not in
>> Creator-generated pro files either) and yet I would like to always
>> have qDebug output in the console when the app is running in a
>> console.  So detecting whether the app is running in a console and
>> automatically sending debug output there would mean that we no longer
>> need that flag in the .pro, right?  If it's technically possible, we
>> should have done that years ago.
>
> I don't think it's possible at all. If the application was compiled to the GUI
> subsystem, it *has* no stdout and stderr. We can open a new console window,
> but I don't think you can write to an existing one.

I thought so, but I'm glad Ossi found a possible strategy. ;-)

>> I also don't like Creator's default "run in terminal" checkbox because
>> again I don't get to choose which terminal, and the one it chooses is
>> always 80x25, white background, has no search feature, etc.  So I have
>> to remember to turn off the checkbox because the default is not what I
>> want.  IMO the Application Output pane should have enough features
>> that it can be treated as the console in which the app is running.
>> What is missing, that we don't already do this?
>
> Colour support, TTY support, job control, etc. TTYs on Unix are much more
> complex than pipes.

What are the use cases?  Somehow I don't usually need more than what
the Creator output pane already provides... except that categorized
logging opens up a possibility to control what you see there.

But even if we go that far, it's not so hard to find some code for a
terminal that we could use (there's even a certain QtQuick one I
happen to know of ;-)  And some people would like having a terminal
window in Creator anyway; I've seen it in other IDEs.  But of course
it would add more bloat.

Anyway just being able to see and manage the logging output in Creator
does not preclude running the application in a terminal if that's what
you want to do, right?  But IMO it should not be the default, and it
wouldn't hurt if it was more configurable.
___
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

[Thiago Macieira]

On Thursday 10 July 2014 19:34:59 Oswald Buddenhagen wrote:
> On Thu, Jul 10, 2014 at 10:17:52AM -0700, Thiago Macieira wrote:
> > On Thursday 10 July 2014 16:50:22 Shawn Rutledge wrote:
> > > On Windows I never liked CONFIG += console, because it's never in the
> > > .pro by default (usually not in manual tests or examples, and not in
> > > Creator-generated pro files either) and yet I would like to always
> > > have qDebug output in the console when the app is running in a
> > > console.  So detecting whether the app is running in a console and
> > > automatically sending debug output there would mean that we no longer
> > > need that flag in the .pro, right?  If it's technically possible, we
> > > should have done that years ago.
> > 
> > I don't think it's possible at all. If the application was compiled to the
> > GUI subsystem, it *has* no stdout and stderr. We can open a new console
> > window, but I don't think you can write to an existing one.
> 
> "windows is stupid, but it can't be that stupid, can it?" => google =>
> 
> AttachConsole(ATTACH_PARENT_PROCESS)
> GetStdHandle(STD_ERROR_HANDLE)
> (and _open_osfhandle(h) if one cares for stdio)

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?
-- 
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

[Oswald Buddenhagen]

On Thu, Jul 10, 2014 at 10:17:52AM -0700, Thiago Macieira wrote:
> On Thursday 10 July 2014 16:50:22 Shawn Rutledge wrote:
> > On Windows I never liked CONFIG += console, because it's never in the
> > .pro by default (usually not in manual tests or examples, and not in
> > Creator-generated pro files either) and yet I would like to always
> > have qDebug output in the console when the app is running in a
> > console.  So detecting whether the app is running in a console and
> > automatically sending debug output there would mean that we no longer
> > need that flag in the .pro, right?  If it's technically possible, we
> > should have done that years ago.
> 
> I don't think it's possible at all. If the application was compiled to the 
> GUI 
> subsystem, it *has* no stdout and stderr. We can open a new console window, 
> but I don't think you can write to an existing one.
> 
"windows is stupid, but it can't be that stupid, can it?" => google =>

AttachConsole(ATTACH_PARENT_PROCESS)
GetStdHandle(STD_ERROR_HANDLE)
(and _open_osfhandle(h) if one cares for stdio)
___
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

[Thiago Macieira]

On Thursday 10 July 2014 07:56:28 Koehne Kai wrote:
> Provide a define QT_LOG_TO_CONSOLE  that let QCoreApplication.h record
> whether it should log to console (QT_LOG_TO_CONSOLE=1), to the system
> (QT_LOG_TO_CONSOLE=0), or both (QT_LOG_TO_CONSOLE=2). 
> 
> Qmake can wrap this into convenience CONFIG arguments:
> 
> CONFIG+=log_to_console log_to_system

It's easier to set an AA flag.

http://qt-project.org/doc/qt-5/qcoreapplication.html#setAttribute
http://qt-project.org/doc/qt-5/qt.html#ApplicationAttribute-enum

PS: doc team, the second link above is unreadable.
-- 
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

[Thiago Macieira]

On Thursday 10 July 2014 16:50:22 Shawn Rutledge wrote:
> What if we use qtlogging.ini (or equivalent on other systems) to
> control whether the logs go to the system log or not?  I agree that
> every ordinary KDE user doesn't need to have unread logs taking up
> disk space, but maybe developers would like to turn on output to the
> journal permanently for after-the-fact diagnosis when something
> unexpectedly crashes or misbehaves.

That doesn't solve the problem of the default. What do we do when 
qtlogging.ini isn't present?

And how do you debug an application that got installed on a system that 
already has qtlogging.ini?

> On Windows I never liked CONFIG += console, because it's never in the
> .pro by default (usually not in manual tests or examples, and not in
> Creator-generated pro files either) and yet I would like to always
> have qDebug output in the console when the app is running in a
> console.  So detecting whether the app is running in a console and
> automatically sending debug output there would mean that we no longer
> need that flag in the .pro, right?  If it's technically possible, we
> should have done that years ago.

I don't think it's possible at all. If the application was compiled to the GUI 
subsystem, it *has* no stdout and stderr. We can open a new console window, 
but I don't think you can write to an existing one.

> I also don't like Creator's default "run in terminal" checkbox because
> again I don't get to choose which terminal, and the one it chooses is
> always 80x25, white background, has no search feature, etc.  So I have
> to remember to turn off the checkbox because the default is not what I
> want.  IMO the Application Output pane should have enough features
> that it can be treated as the console in which the app is running.
> What is missing, that we don't already do this?

Colour support, TTY support, job control, etc. TTYs on Unix are much more 
complex than pipes.

-- 
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

[Thiago Macieira]

On Thursday 10 July 2014 11:05:03 Tobias Hunger wrote:
> Hi Thiago,
> 
> Basically I agree with your statements, but I do not think we can rely
> on journald at this time.

Agreed.

> The first problem is of course systemd itself: Ubuntu is one of the
> biggest distros out
> there and we can not reasonably assume that to be running systemd
> before 14.04 is
> at the end of its life-cycle. Considering that this is a long term
> support release that
> will be a while. But even when systemd is in use journald might be disabled
> or misconfigured -- as you already said yourself. I hope gnome and KDE
> starting to depend
> on systemd user sessions will get that sorted out soon, but at this
> time those changes are
> not yet deployed in distributions.

I'm not asking that distributions turn journald on if they don't want to. 
Journald is optional.

However, they *can't* turn it on until we figure out how to read back what gets 
logged there. At this point, the showstopper is in journald itself.

> So I think being able to rely on logging to journald is still a long
> time off. So what is the fallback? Stderr again?

Yes. If you don't turn journald on (it's optional), then we always fall back 
to stderr.

> Adding Journald into the picture will also make retrieving warnings
> from remote machines
> a lot more difficult. Currently we rely on SSH and/or gdbserver to
> retrieve all application
> output on Unix systems. I am not sure at this time how that would work
> if the application
> starts sending output to the journal. So having a way to force stderr
> in favor of system logs
> would be greatly appreciated.

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.

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.

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.

> PS: Creator not supporting getting logs from system logs on Unix systems
> is not a bug, it is a feature nobody requested so far:-)

Yup.
-- 
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

[Thiago Macieira]

On Thursday 10 July 2014 08:13:09 Koehne Kai wrote:
> > -Original Message-
> > From: development-bounces+kai.koehne=digia@qt-project.org
> > [...]
> > Here's what I propose:
> > 
> > Heuristically determine at runtime. On all platforms (including Windows),
> > use only the fact that a terminal is present. If a terminal is present,
> > write to it using stderr. Otherwise, write to the system log.
> > 
> > * Implications for Qt Creator:
> > 1) it must be able to read from the system log for desktop debugging
> > (especially when running applications without "Run in terminal"). That's
> > already done on Windows. It will be necessary to add support for journald
> > (Linux) and asl (OS X).
> 
> Well, actually your latest patch that checks for "stderr!=/dev/null" will
> just work fine with current Qt Creator. That's for journal/Linux at least,
> haven't had a look yet how asl works.

The latest patch does not match the proposal.

I want to remove the stderr check for Unix and for Windows, which means 
Creator should check the system logs.

> Qt Creator needs to continue listening to stderr in any case: You still want
> to see stdout/stderr, after all. It's true that Qt Creator can in theory
> profit from additional information piped through systemd, but integrating
> both streams also has it's issues: E.g. the order of qDebug/stderr messages
> is no longer consistent, and interleaving lines might need special
> attention (though I guess we handle that already for stdout/stderr).

Agreed it must continue to read.

As for the synchronisation, journald gives you the message's absolute 
timestamp, so you'll just need to do the same for each line read via QProcess.

> > 2) remote debugging: per platform, it needs to be decided whether we can
> > access the log on the remote device. If so, that's the best situation. If
> > it isn't, then we need to force Qt to log to stderr.
> > 
> >  2a) set QT_LOGGING_TO_CONSOLE=1 in the environment
> >  2b) force the allocation of a terminal (if using ssh, pass the -t option)
> 
> See above. Unless stderr somehow ends up in the system log too we need to
> anyway have the terminal.

Addressed above.

> > I recommend advising Linux distributions to disable journald logging at
> > least until Creator is updated. And the support for asl on OSX should be
> > held until the same time.
> 
> I agree (though I'm not sure whether Qt Creator is the blocker, or if it's
> enough to handle the issue in Qt. See above).

Creator must be able to handle reading from the system log before logging to 
the system is enabled for that system. On Linux, the code is already there, so 
we have to tell distributions *not* to enable journald yet. For OS X, it's 
putting a hold on https://codereview.qt-project.org/82922.

-- 
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

[Thiago Macieira]

On Thursday 10 July 2014 07:53:29 Keith Gardner wrote:
> > Currently, the QVersion::compare has an overload to pass a functor that
> 
> performs the suffix comparison.  Are you suggesting having a "default" in
> the operators that can be overwritten?

No global state, please.
-- 
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] How to have equivalent of function over-riding in Qml

[m...@rpzdesign.com]

Please do share when you get to the bottom of this.

md

On 7/10/2014 8:55 AM, travik wrote:
> Ok!. That's cool and it is Qml's implementation of VTable, I guess!.
> Thanks a lot again. Let me try it and come back.
> 
> 
> 
> ___
> 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] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357

[Shawn Rutledge]

What if we use qtlogging.ini (or equivalent on other systems) to
control whether the logs go to the system log or not?  I agree that
every ordinary KDE user doesn't need to have unread logs taking up
disk space, but maybe developers would like to turn on output to the
journal permanently for after-the-fact diagnosis when something
unexpectedly crashes or misbehaves.

There is already a discoverability problem about the available
categories, so I was thinking we need a nice tool to manage
qtlogging.ini (a widget-based app or a menu-driven console app).  This
tool could turn on and off the system logging too.  Maybe it could be
a feature of qtdiag instead of a separate tool (since logging is a
kind of diagnostic device).

On Windows I never liked CONFIG += console, because it's never in the
.pro by default (usually not in manual tests or examples, and not in
Creator-generated pro files either) and yet I would like to always
have qDebug output in the console when the app is running in a
console.  So detecting whether the app is running in a console and
automatically sending debug output there would mean that we no longer
need that flag in the .pro, right?  If it's technically possible, we
should have done that years ago.

I never want a separate pop-up console otherwise because it's an
annoyance and has too few features.  A log viewer which allows
searching and filtering would be far more useful.  So another idea is
what about including with the Qt SDK a widget-based log viewer, with
UI for turning the categories on and off, and also some searching and
filtering features?  If you are using it, the logging output would be
redirected there instead of stderr or the console... but the question
is how do you use it: by having it start the application?  or have UI
to select and attach to already-running applications?

I also don't like Creator's default "run in terminal" checkbox because
again I don't get to choose which terminal, and the one it chooses is
always 80x25, white background, has no search feature, etc.  So I have
to remember to turn off the checkbox because the default is not what I
want.  IMO the Application Output pane should have enough features
that it can be treated as the console in which the app is running.
What is missing, that we don't already do this?

Or if we write a log viewer tool, Creator could use that as the
Application Output pane instead of needing to write a separate one.
Or maybe it's just a matter of packaging Creator's output pane into a
standalone log viewer tool, and add more filtering features to both.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Make Qt WebEngine an add-on

[Konstantin Ritt]

Hi,

2014-07-10 17:03 GMT+03:00 Zeno Albisser :

> Other than that we had some blog posts earlier this year and we do have a
> wiki page here: http://qt-project.org/wiki/QtWebEngine
> We are currently focusing on getting all the desktop platforms
> (Linux/Mac/Win) up and running.
>
>
http://qt-project.org/wiki/QtWebEngine isn't really informative ;)

Regards,
Konstantin


>
> - Zeno
>
> --
> Zeno Albisser
> Senior Software Engineer - Digia, Qt+47 406 03 455
> Visit us on: http://qt.digia.com
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Make Qt WebEngine an add-on

[Zeno Albisser]

Hi,

On 03/07/14 13:11, Konstantin Ritt wrote:


Any public documents to read about the Qt WebEngine completeness 
state, limitations/know issues, TODOs, and so on?
Sorry for the late reply. We accept bug reports in jira as every other 
project or module.
Other than that we had some blog posts earlier this year and we do have 
a wiki page here: http://qt-project.org/wiki/QtWebEngine
We are currently focusing on getting all the desktop platforms 
(Linux/Mac/Win) up and running.


- Zeno

--
Zeno Albisser
Senior Software Engineer - Digia, Qt
+47 406 03 455
Visit us on: http://qt.digia.com

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Adding support for version number comparisons

[Kobus Jaroslaw]

Just looking at the topic of that thread, I suggest to name it: QVersionNubmer. 
QVersion may suggest some more, like description of the version or provide an 
info about different set of features.

From: development-bounces+jaroslaw.kobus=digia@qt-project.org 
[development-bounces+jaroslaw.kobus=digia@qt-project.org] on behalf of 
Keith Gardner [kreios4...@gmail.com]
Sent: 10 July 2014 14:53
To: Olivier Goffart
Cc: 
Subject: Re: [Development] Adding support for version number comparisons

On Thu, Jul 10, 2014 at 7:31 AM, Olivier Goffart 
mailto:oliv...@woboq.com>> wrote:
On Monday 02 June 2014 13:24:55 Richard Moore wrote:
> On 2 June 2014 13:12, Keith Gardner 
> mailto:kreios4...@gmail.com>> wrote:
> > On Mon, Jun 2, 2014 at 2:36 AM, Simon Hausmann 
> > mailto:simon.hausm...@digia.com>>
> >
> > wrote:
> >> I suggest a name that is more centric towards the _function_ of the
> >> class,
> >> comparison of different software versions.
> >
> > QVersionInformation was also proposed as a name in the code review.  I
> > don't have a problem with changing the name other than it is really long
> > for a simple class.
>
> How about QVersionComparator?

How about qVersionCompare(const QString&, const QString&)?
Yes, that's a function. Is there really the need for a class to hold just a
version string?

And there could be an overload with a SuffixComparator.

(or is qCompareVersion an even better name?)

Currently, the QVersion::compare has an overload to pass a functor that 
performs the suffix comparison.  Are you suggesting having a "default" in the 
operators that can be overwritten?

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Adding support for version number comparisons

[Kobus Jaroslaw]

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 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

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.

Later, we could provide a method for reading from and writing to string a 
QVersion instance, like:

QString QVersion::toString(const QStringList &labels) const; - this method 
would substitute a number for a preliminary segment with a string taken from 
labels. So, if e.g. my project's convention for naming of preliminary versions 
is like:

QStringList labels << "alhpa" << "beta" << "rc";

than QVersion would produce:

"5.4.0.alpha" for QVersion("5.4.0.*0").toString(labels);
"5.4.0.beta.1" for QVersion("5.4.0.*1.1").toString(labels);
"5.4.0.beta.2" for QVersion("5.4.0.*1.2").toString(labels);
"5.4.0.rc.1" for QVersion("5.4.0.*2.1").toString(labels);
"5.4.0.rc.2" for QVersion("5.4.0.*2.2").toString(labels);

For reading (e.g. QVersion::fromString(const QString &versionString, const 
QStringList &labels);) it would be symmetric. The advantage would be that we 
may discover invalid versions passed to that method (e.g. if our project 
doesn't know anything about "theta", and it's not on the list, we can detect it 
and return invalid version, instead of creating useless version object).

If you would like to see how it behaves, there is some implementation for it 
(the extension of a tool class for installer framework) here: 
https://codereview.qt-project.org/#/c/89604/
It doesn't implement toString() and fromString() which would take a QStringList 
yet, but it's trivial to implement it quickly. The rest of the mentioned 
approach is implemented. The class is inside a framework, but is doesn't 
dependent on it, so you may try to compile it and run outside.

Regards

Jarek


From: development-bounces+jaroslaw.kobus=digia@qt-project.org 
[development-bounces+jaroslaw.kobus=digia@qt-project.org] on behalf of 
Keith Gardner [kreios4...@gmail.com]
Sent: 10 July 2014 14:21
To: Thiago Macieira
Cc: 
Subject: Re: [Development] Adding support for version number comparisons

On Sat, May 31, 2014 at 2:00 PM, Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:
Em sex 09 maio 2014, às 11:36:08, Keith Gardner escreveu:
> I have been working on adding a class to QtCore (QVersion) to support
> storing version numbers, convert to/from QString, and having comparison
> operators.  My goal was to provide an API to assist in the following use
> cases:
>
>- Plugin loading where there are multiple versions on the same system.
>- File format validation.
>- Executing an already installed command line application where the
>behavior is dependent on the called application's version.
>- Performing software installations and updates.
>- QMake support for version number comparisons.
>
> Please share other potential use cases where this might be useful.

Ok, since we can't seem to agree, let's settle on the maximum common
denominator: QVersion will only compare the numeric part of a version number.
By default, two versions with the same numeric part will compare equally,
regardless of any suffixes that may be present.

Therefore, by default, given:
QVersion a("5.3.0");
QVersion b("5.3.0pl1");
QVersion c("5.3.0beta1");

a != b != c;// since they aren't equal

QVersion::compare(a, b) == 0;
QVersion::compare(b, c) == 0;


In the review of the cha

Re: [Development] Adding support for version number comparisons

[Keith Gardner]

On Thu, Jul 10, 2014 at 8:09 AM, Olivier Goffart  wrote:

> On Thursday 10 July 2014 07:53:29 Keith Gardner wrote:
> > On Thu, Jul 10, 2014 at 7:31 AM, Olivier Goffart 
> wrote:
> > > On Monday 02 June 2014 13:24:55 Richard Moore wrote:
> > > > On 2 June 2014 13:12, Keith Gardner  wrote:
> > > > > On Mon, Jun 2, 2014 at 2:36 AM, Simon Hausmann  wrote:
> > > > > > I suggest a name that is more centric towards the _function_ of
> the
> > > > > > class, comparison of different software versions.
> [...]
> > > > How about QVersionComparator?
> > >
> > > How about qVersionCompare(const QString&, const QString&)?
> > > Yes, that's a function. Is there really the need for a class to hold
> just
> > > a version string?
> > >
> > > And there could be an overload with a SuffixComparator.
> > >
> > > (or is qCompareVersion an even better name?)
>
> > Currently, the QVersion::compare has an overload to pass a functor that
> > performs the suffix comparison.  Are you suggesting having a "default" in
> > the operators that can be overwritten?
>
> I suggest not having any new classes. Just a function. (or a couple of
> functions)
>

Sorry for the confusion.  I was talking about a function pointer similar to
qInstallMessageHandler.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Adding support for version number comparisons

[Olivier Goffart]

On Thursday 10 July 2014 07:53:29 Keith Gardner wrote:
> On Thu, Jul 10, 2014 at 7:31 AM, Olivier Goffart  wrote:
> > On Monday 02 June 2014 13:24:55 Richard Moore wrote:
> > > On 2 June 2014 13:12, Keith Gardner  wrote:
> > > > On Mon, Jun 2, 2014 at 2:36 AM, Simon Hausmann  wrote:
> > > > > I suggest a name that is more centric towards the _function_ of the
> > > > > class, comparison of different software versions.
[...]
> > > How about QVersionComparator?
> > 
> > How about qVersionCompare(const QString&, const QString&)?
> > Yes, that's a function. Is there really the need for a class to hold just
> > a version string?
> > 
> > And there could be an overload with a SuffixComparator.
> > 
> > (or is qCompareVersion an even better name?)

> Currently, the QVersion::compare has an overload to pass a functor that
> performs the suffix comparison.  Are you suggesting having a "default" in
> the operators that can be overwritten?

I suggest not having any new classes. Just a function. (or a couple of 
functions)

-- 
Olivier 

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How to have equivalent of function over-riding in Qml

[travik]

Ok!. That's cool and it is Qml's implementation of VTable, I guess!.
Thanks a lot again. Let me try it and come back.



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Adding support for version number comparisons

[Keith Gardner]

On Thu, Jul 10, 2014 at 7:31 AM, Olivier Goffart  wrote:

> On Monday 02 June 2014 13:24:55 Richard Moore wrote:
> > On 2 June 2014 13:12, Keith Gardner  wrote:
> > > On Mon, Jun 2, 2014 at 2:36 AM, Simon Hausmann <
> simon.hausm...@digia.com>
> > >
> > > wrote:
> > >> I suggest a name that is more centric towards the _function_ of the
> > >> class,
> > >> comparison of different software versions.
> > >
> > > QVersionInformation was also proposed as a name in the code review.  I
> > > don't have a problem with changing the name other than it is really
> long
> > > for a simple class.
> >
> > How about QVersionComparator?
>
> How about qVersionCompare(const QString&, const QString&)?
> Yes, that's a function. Is there really the need for a class to hold just a
> version string?
>
> And there could be an overload with a SuffixComparator.
>
> (or is qCompareVersion an even better name?)
>
> Currently, the QVersion::compare has an overload to pass a functor that
performs the suffix comparison.  Are you suggesting having a "default" in
the operators that can be overwritten?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Adding support for version number comparisons

[Olivier Goffart]

On Monday 02 June 2014 13:24:55 Richard Moore wrote:
> On 2 June 2014 13:12, Keith Gardner  wrote:
> > On Mon, Jun 2, 2014 at 2:36 AM, Simon Hausmann 
> > 
> > wrote:
> >> I suggest a name that is more centric towards the _function_ of the
> >> class,
> >> comparison of different software versions.
> > 
> > QVersionInformation was also proposed as a name in the code review.  I
> > don't have a problem with changing the name other than it is really long
> > for a simple class.
> 
> How about QVersionComparator?

How about qVersionCompare(const QString&, const QString&)? 
Yes, that's a function. Is there really the need for a class to hold just a 
version string?

And there could be an overload with a SuffixComparator.

(or is qCompareVersion an even better name?)
-- 
Olivier 

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Adding support for version number comparisons

[Keith Gardner]

On Sat, May 31, 2014 at 2:00 PM, Thiago Macieira 
wrote:

> Em sex 09 maio 2014, às 11:36:08, Keith Gardner escreveu:
> > I have been working on adding a class to QtCore (QVersion) to support
> > storing version numbers, convert to/from QString, and having comparison
> > operators.  My goal was to provide an API to assist in the following use
> > cases:
> >
> >- Plugin loading where there are multiple versions on the same system.
> >- File format validation.
> >- Executing an already installed command line application where the
> >behavior is dependent on the called application's version.
> >- Performing software installations and updates.
> >- QMake support for version number comparisons.
> >
> > Please share other potential use cases where this might be useful.
>
> Ok, since we can't seem to agree, let's settle on the maximum common
> denominator: QVersion will only compare the numeric part of a version
> number.
> By default, two versions with the same numeric part will compare equally,
> regardless of any suffixes that may be present.
>
> Therefore, by default, given:
> QVersion a("5.3.0");
> QVersion b("5.3.0pl1");
> QVersion c("5.3.0beta1");
>
> a != b != c;// since they aren't equal
>
> QVersion::compare(a, b) == 0;
> QVersion::compare(b, c) == 0;
>
>
In the review of the change, a potential issue with this form of compare
with the operators when using QVersion as the key in a QMap.  Here is the
scenario:
QVersion a("5.3.0alpha");
QVersion b("5.3.0beta");
a != b; //true
a < b; // false

QMap map;
map[a] = foo1;
map[b] = foo2;

With the example, map[a] now is set to "foo2" which is incorrect since 'a'
!= 'b'.  This is not an issue with QHash since the suffix
is included into the hashing of a QVersion.  How should we resolve this
conflict with ordering without applying a semantic compare to the suffix?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] task based programming in Qt/C++ using continuation and modern C++

[Milian Wolff]

On Wednesday 09 July 2014 21:02:32 .. ink .. wrote:
> greetings and hope its acceptable to post what i am about to post here and
> apologies if it is not.
> 
> Through my usage of Qt/C++, i came about a nicer way to run a simple tasks
> asynchronously while
> living within Qt and i decided to share it with the world through my github
> account here[1].
> 
> Just though i should post it here in a hope that this kind of API will find
> its way to Qt's official API.
> 
> The "old" way of deriving from Qthread and manually setting up
> signals/slots works but not always ideal
> for simple tasks as it involves a lot of manually setting this up.

Please take a look at the KDE ThreadWeaver Framework, which you can easily use 
in any Qt5 application without any other dependencies. It is a proven 
technology which supports job/task-based parallel programming with many 
features.

http://kde.org/announcements/kde-frameworks-5.0.php
http://api.kde.org/frameworks-api/frameworks5-apidocs/threadweaver/html/index.html

Bye
-- 
Milian Wolff
m...@milianw.de
http://milianw.de
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Support for your evaluation of Qt

[Mitch Curtis]

On 07/10/2014 12:20 PM, Ch'Gans wrote:
> On 09/07/14 19:53, Andrea Barna wrote:
>> Hi,
>>
>> I am Andrea from Digia Qt, I have recently taken over the Qt
>> businessin your region.
> Hi Andrea,
>
> All the best for your new position!
>
>> I noticed that you downloaded the trial version of Qt last year and
>> Iwas wondering whether the evaluation went well.
>>
>> It would be helpful to understand why you were evaluating Qt, and
>> learn more about what type of application you are developing.
> I downloaded your evaluation version of Qt to see how different it is
> from the open source one. I am especially interested in embedded and
> industrial application and as such I was curious about your "Boot to Qt"
> technology.
> I was not really surprised to discover that your proprietary "Boot to
> Qt" technology is based on the open-source Yocto project [1], and I
> think that instead of keeping this technology closed, you should be the
> official maintainer of the Qt5 Yocto layer (lot of work is needed there,
> and you have handles in-house), I think you should contact the Linux
> Foundation [2], they will be glad to see you being a major actor in the
> open-source embedded Linux world.
>
>   > Furthermore is there anything that Digia–Qt can help you with?
>
> Definitely yes: please open up your open source based
> commercial/proprietary boot to Qt technology.
> I am not asking that because I am an open-source fanatic, I am asking
> that because this is the only reliable and efficient way to get Qt
> massively adopted on the embedded/industrial Linux market, I think that
> Digia should be a (publicly visible) key actor in this sector.
>
> Maybe one day you will be able to replace your "Code once, run
> everywhere" with "Code once, run everywhere, without pain!".
> Getting Qt5 + Yocto + OpenGL-ES running across different ARM SoCs is a
> real pain.
>
> Best regards,
> Chris
>
> PS: No disrespect to you, Digia, Nokia, TrollTech and all the Qt trolls,
> hat off and thumb up to all you guys! I am just tired to see a beautiful
> open-source SW community being permanently fooled by professional
> closed-source HW company. Please don't be part of this masquerade!
>
> PS2: I've CC'ed the Qt developer mailing list (public archived available
> [3]), hoping this could be useful to someone, somehow, someday.
>
> [1] https://www.yoctoproject.org/
> [2] http://www.linuxfoundation.org/about/contact
> [3] http://lists.qt-project.org/pipermail/development/
>

I'm curious how you think Digia can fund future development of things 
like Boot to Qt if they give it away for free?

>> I look forward to hearing about your project. >
>> Best Regards,
>> Andrea
>>
>> Andrea Barna | Junior Sales Executive
>> Digia Norway AS, Sandakerveien 116, PoBOX 23 Nydalen, 0410 Oslo, Norway
>> Email: andrea.ba...@digia.com | Phone : +47 210 80 420 | Fax : +47 21080439
>> http://qt.digia.com |Qt Blog: http://blog.qt.digia.com/ |Qt Facebook: 
>> www.facebook.com/qt  |Qt Twitter: @QtbyDigia
>>
>> --
>> PRIVACY AND CONFIDENTIALITY NOTICE
>> This message and any attachments are intended only for use by the named 
>> addressee and may contain privileged and/or confidential information. If you 
>> are not the named addressee you should not disseminate, copy or take any 
>> action in reliance on it. If you have received this message in error, please 
>> contact the sender immediately and delete the message and any attachments 
>> accompanying it. Digia Plc does not accept liability for any corruption, 
>> interception, amendment, tampering or viruses occurring to this message.
>> -
>>

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Support for your evaluation of Qt

[Ch'Gans]

On 09/07/14 19:53, Andrea Barna wrote:
> Hi,
>
> I am Andrea from Digia Qt, I have recently taken over the Qt
> businessin your region.

Hi Andrea,

All the best for your new position!

> I noticed that you downloaded the trial version of Qt last year and
> Iwas wondering whether the evaluation went well.
>
> It would be helpful to understand why you were evaluating Qt, and
> learn more about what type of application you are developing.

I downloaded your evaluation version of Qt to see how different it is 
from the open source one. I am especially interested in embedded and 
industrial application and as such I was curious about your "Boot to Qt" 
technology.
I was not really surprised to discover that your proprietary "Boot to 
Qt" technology is based on the open-source Yocto project [1], and I 
think that instead of keeping this technology closed, you should be the 
official maintainer of the Qt5 Yocto layer (lot of work is needed there, 
and you have handles in-house), I think you should contact the Linux 
Foundation [2], they will be glad to see you being a major actor in the 
open-source embedded Linux world.

 > Furthermore is there anything that Digia–Qt can help you with?

Definitely yes: please open up your open source based 
commercial/proprietary boot to Qt technology.
I am not asking that because I am an open-source fanatic, I am asking 
that because this is the only reliable and efficient way to get Qt 
massively adopted on the embedded/industrial Linux market, I think that 
Digia should be a (publicly visible) key actor in this sector.

Maybe one day you will be able to replace your "Code once, run 
everywhere" with "Code once, run everywhere, without pain!".
Getting Qt5 + Yocto + OpenGL-ES running across different ARM SoCs is a 
real pain.

Best regards,
Chris

PS: No disrespect to you, Digia, Nokia, TrollTech and all the Qt trolls, 
hat off and thumb up to all you guys! I am just tired to see a beautiful 
open-source SW community being permanently fooled by professional 
closed-source HW company. Please don't be part of this masquerade!

PS2: I've CC'ed the Qt developer mailing list (public archived available 
[3]), hoping this could be useful to someone, somehow, someday.

[1] https://www.yoctoproject.org/
[2] http://www.linuxfoundation.org/about/contact
[3] http://lists.qt-project.org/pipermail/development/


>
> I look forward to hearing about your project. >
> Best Regards,
> Andrea
>
> Andrea Barna | Junior Sales Executive
> Digia Norway AS, Sandakerveien 116, PoBOX 23 Nydalen, 0410 Oslo, Norway
> Email: andrea.ba...@digia.com | Phone : +47 210 80 420 | Fax : +47 21080439
> http://qt.digia.com |Qt Blog: http://blog.qt.digia.com/ |Qt Facebook: 
> www.facebook.com/qt  |Qt Twitter: @QtbyDigia
>
> --
> PRIVACY AND CONFIDENTIALITY NOTICE
> This message and any attachments are intended only for use by the named 
> addressee and may contain privileged and/or confidential information. If you 
> are not the named addressee you should not disseminate, copy or take any 
> action in reliance on it. If you have received this message in error, please 
> contact the sender immediately and delete the message and any attachments 
> accompanying it. Digia Plc does not accept liability for any corruption, 
> interception, amendment, tampering or viruses occurring to this message.
> -
>

-- 
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

[Development] About inheriting QBlitterPaintEngine from QGL2PaintEngineEx class

[haithem rahmani]

Hi,

When running Qt-5 on top of the directfb qpa plugin,  some benchmarks are
quite slow.
(http://smashcat.org/av/canvas_test)

 I've found that the 2D painting ops are going through the
QBlitterPaintEngine class
that is inheriting the QRasterPaintEngine class, which is doing all the
painting via CPU.

Qt provides another paintEgine class, QGL2PaintEngineEx, that is doing the
same paintings via the GPU.

So I want to know whether is possible to make the QBlitterPaintEngine
inherit this QGL2PaintEngineEx
instead of QRasterPaintEngine and got things working correctly or not?

PS: the eglfs qpa plugin is going through the QRasterPaintEngine class too.

regards
Haithem.
___
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

[Tobias Hunger]

Hi Thiago,

Basically I agree with your statements, but I do not think we can rely
on journald
at this time.

The first problem is of course systemd itself: Ubuntu is one of the
biggest distros out
there and we can not reasonably assume that to be running systemd
before 14.04 is
at the end of its life-cycle. Considering that this is a long term
support release that
will be a while. But even when systemd is in use journald might be disabled or
misconfigured -- as you already said yourself. I hope gnome and KDE
starting to depend
on systemd user sessions will get that sorted out soon, but at this
time those changes are
not yet deployed in distributions.

So I think being able to rely on logging to journald is still a long
time off. So what is
the fallback? Stderr again?

Adding Journald into the picture will also make retrieving warnings
from remote machines
a lot more difficult. Currently we rely on SSH and/or gdbserver to
retrieve all application
output on Unix systems. I am not sure at this time how that would work
if the application
starts sending output to the journal. So having a way to force stderr
in favor of system logs
would be greatly appreciated.

Best Regards,
Tobias

PS: Creator not supporting getting logs from system logs on Unix systems
is not a bug, it is a feature nobody requested so far:-)
___
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

[Denis Shienkov]

Perhaps, it makes sense to select an output message sink in runtime?
E.g. before QCoreApplication, by means of specify some QLogging flags, to
override the installMessageHandler and so on?

Maybe make sense to introduce a some pre-defined qInstallMessageHandler's()
or something others functions, like:

qInstallMessageDestination(enum MessageDestinationFlag)

, where

enum MessageDestinationFlag
{
MessageToConsole,
MessageToDebugger,
MessageToSystemLog,

   and etc.
}

For example, then user can select manually what output need:

int main()
{
qInstallMessageDestination(MessageToConsole | MessageToSystemLog);

QCoreApplication app;
}

Besides, in Windows there are four various directions of a  messages output:

1) To the Console

2) To the Debug output, using the OutputDebugString function:
http://msdn.microsoft.com/ru-ru/library/windows/desktop/aa363362%28v=vs.85%29.aspx

3) To the SystemLog (Journal), using the
RegisterEventSource:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363678%28v=vs.85%29.aspx
&&
ReportEvent:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363679%28v=vs.85%29.aspx

functions (as already was made in  QtService from qt-solutions).

4) Using WPP Software Tracing feature:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff556204%28v=vs.85%29.aspx


Thus, I prefer that the user himself chose where he wants to print out the
log messages.


Best regards,
Denis







2014-07-10 12:03 GMT+04:00 Dmitriy Purgin :

> Sorry for my vague statements :)
>
> Actually I wasn't talking about logging to file as a default for
> Windows. On the contrary I think this has to be done by each
> application individually -- someone needs as you rightly say 10 lines
> of code just to make sure everything went okay, others need a large
> logging facility with rotation, archiving, severity of messages and
> maybe even mirroring some messages to a database. There's no universal
> solution here, the former would complain about dependencies, the
> latter would extend the existing logger or invent their own.
>
> What I'm trying to say is that logging to file seems to be more common
> approach on Windows than logging to Event Log accessed from the
> Control Panel -> Administrative unless it is a service or application
> produced by Microsoft :) Access to Event Log by end-user can really be
> restricted by Domain Policies which affects mostly enterprise users,
> though I totally agree that those who are affected should do something
> about it.
>
> Cheers
>
> 2014-07-10 12:46 GMT+06:00 Koehne Kai :
> >
> >
> >> -Original Message-
> >> From: development-bounces+kai.koehne=digia@qt-project.org
> >> [...]
> >> On the contrary, the end-user on Windows expects the application logs
> to be
> >> in a file somewhere near the executable if it's not a system service.
> So in my
> >> opinion the logs shouldn't write into system unless explicitly asked to.
> >
> > I think logging to a file is a useful option. But I disagree that it
> should be the default, at least for Windows.
> >
> > First, you've the problem to find a file 'somewhere near the executable'
> that you can write to. For end-users, you don't necessarily have write
> permissions to Program Files, and even if you have it, you don't want data
> to be put there, either. The only place that should always work would
> probably be %localappdata%.
> >
> > But even if you manage to do that: You need to take care of concurrent
> accesses (multiple instances of your application might run). Then someone
> comes along and complains about his user directory hitting the quota, so
> you've to implement some cleanup/rotation ... It gets quite a big task.
> >
> > Then there's the IDE side: You can adapt Qt Creator, but Visual Studio
> etc won't know a thing about your log file.
> >
> > Despite all its limits (one global buffer, only plain string logging,
> only one debugger/viewer can attach ...), the Windows system log is the
> recommended way to log debugging information for GUI applications. I'm not
> arguing against adding such a file based backend, but it should be the
> default.
> >
> >> Moreover afaik not every enterprise user has access to System Logs on
> >> Windows.
> >
> > First time I hear this  (and I don't think we have had a lot complains
> about it so far?). Anyway, this is one of the things where I'd rather tell
> people to fix their policies ( I know, I know, it's a hard fight ...).
> Also, you can just run your application in the debugger (as long as you've
> the rights to do this ;), or implement a simple log-to-file in 10 lines of
> code yourself.
> >
> > Regards
> >
> > Kai
> ___
> 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] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357

[Koehne Kai]

> -Original Message-
> From: development-bounces+kai.koehne=digia@qt-project.org
> [...]
> Here's what I propose:
> 
> Heuristically determine at runtime. On all platforms (including Windows), use
> only the fact that a terminal is present. If a terminal is present, write to 
> it
> using stderr. Otherwise, write to the system log.
> 
> * Implications for Qt Creator:
> 1) it must be able to read from the system log for desktop debugging
> (especially when running applications without "Run in terminal"). That's
> already done on Windows. It will be necessary to add support for journald
> (Linux) and asl (OS X).

Well, actually your latest patch that checks for "stderr!=/dev/null" will just 
work fine with current Qt Creator. That's for journal/Linux at least, haven't 
had a look yet how asl works.

Qt Creator needs to continue listening to stderr in any case: You still want to 
see stdout/stderr, after all. It's true that Qt Creator can in theory profit 
from additional information piped through systemd, but integrating both streams 
also has it's issues: E.g. the order of qDebug/stderr messages is no longer 
consistent, and interleaving lines might need special attention (though I guess 
we handle that already for stdout/stderr).

> 2) remote debugging: per platform, it needs to be decided whether we can
> access the log on the remote device. If so, that's the best situation. If it 
> isn't,
> then we need to force Qt to log to stderr.
> 
>  2a) set QT_LOGGING_TO_CONSOLE=1 in the environment
>  2b) force the allocation of a terminal (if using ssh, pass the -t option)

See above. Unless stderr somehow ends up in the system log too we need to 
anyway have the terminal.
 
> I recommend advising Linux distributions to disable journald logging at least
> until Creator is updated. And the support for asl on OSX should be held until
> the same time.

I agree (though I'm not sure whether Qt Creator is the blocker, or if it's 
enough to handle the issue in Qt. See above).

> * Implications for unit tests:
> Except for the unit tests testing logging to the system log in the first 
> place,
> QT_LOGGING_TO_CONSOLE=1 should be set. I think QtTest itself should do
> that.
> 
> * Support for journald in the pre-built Creator binary:
> 1) new plugin, link to libsystemd-journal.so.0. If the library isn't present 
> in the
> target system, the plugin won't load.
> 
> 2) dlopen libsystemd-journal.so.0. If it isn't present, then Qt can't very 
> well
> be logging to it.
> 
> 3) use QProcess to run journalctl -f
> 
> * Support for journald in the pre-built Qt binaries:
> Disabled.
> --
> 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
___
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

[Dmitriy Purgin]

Sorry for my vague statements :)

Actually I wasn't talking about logging to file as a default for
Windows. On the contrary I think this has to be done by each
application individually -- someone needs as you rightly say 10 lines
of code just to make sure everything went okay, others need a large
logging facility with rotation, archiving, severity of messages and
maybe even mirroring some messages to a database. There's no universal
solution here, the former would complain about dependencies, the
latter would extend the existing logger or invent their own.

What I'm trying to say is that logging to file seems to be more common
approach on Windows than logging to Event Log accessed from the
Control Panel -> Administrative unless it is a service or application
produced by Microsoft :) Access to Event Log by end-user can really be
restricted by Domain Policies which affects mostly enterprise users,
though I totally agree that those who are affected should do something
about it.

Cheers

2014-07-10 12:46 GMT+06:00 Koehne Kai :
>
>
>> -Original Message-
>> From: development-bounces+kai.koehne=digia@qt-project.org
>> [...]
>> On the contrary, the end-user on Windows expects the application logs to be
>> in a file somewhere near the executable if it's not a system service. So in 
>> my
>> opinion the logs shouldn't write into system unless explicitly asked to.
>
> I think logging to a file is a useful option. But I disagree that it should 
> be the default, at least for Windows.
>
> First, you've the problem to find a file 'somewhere near the executable' that 
> you can write to. For end-users, you don't necessarily have write permissions 
> to Program Files, and even if you have it, you don't want data to be put 
> there, either. The only place that should always work would probably be 
> %localappdata%.
>
> But even if you manage to do that: You need to take care of concurrent 
> accesses (multiple instances of your application might run). Then someone 
> comes along and complains about his user directory hitting the quota, so 
> you've to implement some cleanup/rotation ... It gets quite a big task.
>
> Then there's the IDE side: You can adapt Qt Creator, but Visual Studio etc 
> won't know a thing about your log file.
>
> Despite all its limits (one global buffer, only plain string logging, only 
> one debugger/viewer can attach ...), the Windows system log is the 
> recommended way to log debugging information for GUI applications. I'm not 
> arguing against adding such a file based backend, but it should be the 
> default.
>
>> Moreover afaik not every enterprise user has access to System Logs on
>> Windows.
>
> First time I hear this  (and I don't think we have had a lot complains about 
> it so far?). Anyway, this is one of the things where I'd rather tell people 
> to fix their policies ( I know, I know, it's a hard fight ...). Also, you can 
> just run your application in the debugger (as long as you've the rights to do 
> this ;), or implement a simple log-to-file in 10 lines of code yourself.
>
> 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

[Koehne Kai]

> -Original Message-
> From: development-bounces+kai.koehne=digia@qt-project.org
> [mailto:development-bounces+kai.koehne=digia@qt-project.org] On
> Behalf Of Thiago Macieira
> Sent: Wednesday, July 09, 2014 11:44 PM
> To: development@qt-project.org
> Subject: [Development] Cake and eating it too for qDebug printing to system
> log - https://codereview.qt-project.org/89357
> 
> == Problematic ==
> Qt 5.3 and dev are currently able to send the output of qDebug, qWarning
> and the rest of the logging framework to somewhere other than stderr.
> That's done on Windows, BlackBerry, Android, and on Linux systems with
> journald.
> Additionally, there's a pending patch for OS X to use the Apple System Log [5]
> and I had a patch for MeeGo that made it go to the standard Unix syslog.
> 
> We have a problem of wanting a cake and eating it too:
> 
> 1) we want applications to send their logging to the system log where
> possible, which usually logs more information like the log level, time,
> application name and PID. Such a system is searchable and may allow us to
> add additional information, like the category (for category logging), file 
> name,
> line number, function context, etc.
> 
> 2) we also want to see the output when we run applications from the
> terminal or capture the output with QProcess.
> 
> The absence of output causes bug reports like [2] and [4].
> 
> == Solutions ==
> === Log to both ===
> Aside from the extra overhead, this causes systems that capture both stderr
> and the system log to record and display the same message twice. That's the
> source of task [3].
> 
> This is not an option.
> 
> === Log to stderr only ===
> That results in loss of information, since the system logs are richer and more
> searchable.
> 
> What's more, on Windows that would result in no output at all for GUI
> applications. I can't find a lot of information on whether GUI applications
> launched from an open command prompt would show anything. IIRC, they
> don't.
> 
> This is not an option.
> 
> === Log to system logs only ===
> This causes reports like [4]. But note that the bug is actually in Creator, 
> for
> failing to read the log store and display the data, like it does on Windows 
> with
> the debug output.
> 
> This is an option.
> 

We might consider also deferring the decision to the application:

=== Defer decision to application ===

Provide a define QT_LOG_TO_CONSOLE  that let QCoreApplication.h record whether 
it should log to console (QT_LOG_TO_CONSOLE=1), to the system 
(QT_LOG_TO_CONSOLE=0), or both (QT_LOG_TO_CONSOLE=2). 

Qmake can wrap this into convenience CONFIG arguments:

CONFIG+=log_to_console log_to_system

And individual (system) mkspecs might set a default, so e.g. Windows might get 
QT_LOG_TO_CONSOLE=2 for gui apps.

If nothing is set, let the heuristic kick in ...

Regards

Kai
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development