Re: [Development] Problem comiling with option -qtnamespace and -qtlibinfix in Mac OS X 10.9.4
Hi Oswald thank you for the response. You were right: It seems that the known bug for the -qtlibinfix option has corrupted my directory when trying it for the first time. Running ./configure -qtamespace for a second time combined with a make clean is not sufficient to repair it. Building from a completely emtpy build dir with qtnamespace this time was successful. Thank you and best regards Hauke Am 08.07.14 11:22, schrieb Oswald Buddenhagen: On Tue, Jul 08, 2014 at 07:12:37AM +0200, Hauke Krüger wrote: I have problems compiling Qt-5.3.1 from the sources in Mac OS X 10.9.4 when specifying the option -qtnamespace and -qtlibinfix. https://bugreports.qt-project.org/browse/QTBUG-35604 1) Option with unspecified namespace: Running configure without -qtnamespace: [...] 2) Option with specified Option -qtnamespace - In the terminal, running ./configure -qtnamespace rtproc - make in the directory qt-everywhere-opensource-src-5.3.1/qtbase does not work: During the compilation of e.g. src/network, I see the following compiler error: [...] The main difference: Instead of -I../../lib/QtCore.framework/Versions/5/Headers/5.3.1/QtCore, the include path is set to .../lib/QtCore.framework/Headers/5.3.1/QtCore where the headers are not located. i don't know why compiling with a namespace would do that. i didn't think it has any effect except setting a #define. did you start with an empty build dir both times? if not, it's more likely that this somehow leads to the failure. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QSharedMemory POSIX implementation
Hi all, I find QSharedMemory very useful, and I'm extensively using it for cross platform IPC. I noticed in the code (qsharedmemory_unix.cpp) there are two implementations for that class, one using System V IPC and the other using POSIX IPC (mmap). On both Linux and Mac versions of Qt, the System V primitives are used and there is no way to compile Qt using the POSIX implementation (-posix-ipc option is not available in configure). Is there any reason why the System V implementation is preferred? I'd like to switch to the POSIX one to overcome limits in some platforms where the maximum shared memory allowed is only 4MB. Thanks, Calogero -- Calogero Mauceri Software Engineer Applied Coherent Technology Corporation (ACT) www.actgate.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] How to have equivalent of functions over-riding in Qml
Hi,
the problem is that your Derived.qml isn't actually derived from Base.qml,
since you're using 'Item'instead of 'Base' as a root item. This will work:
Base.qmlItem {function method1() {}}
Derived.qmlBase { id: base}
SomeOtherQml.qml...Derived { id: derived1}...Calling derived1.method1() now
will call the function in Base. If you add an identical function in Derivedwill
then lead to function method1() of Derived being called.
Regards,Martin
travik ravikiran.tallapa...@wipro.com , 7/9/2014 3:45 PM:
Hi, I would like to have equivalent of compile time polymorphism in in
Qml. a.k.a function overriding.
I know inheritance can be obtained by including the base-class in derived
class. (A realisation of the principle called inheritance by composition)
I also want to have some default implementations of the baseclass to be
available and invoked, in case the derived class does not provide its own
implementation.
In Qml sense, a method is function. So
Base.qml
-
Item
{
function method1()
{
}
}
Derived.qml (in same folder as base.qml)
--
Item
{
Base
{
id: base
}
}
SomeOtherQml.qml
---
..
Derived { id: derived1 ... }
.. else where in this file,
derived1.method1() - should call, Base::method1, because derived1 does
not re-implement it (in the sense of inheritance)
___
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] QSharedMemory POSIX implementation
On Wednesday 09 July 2014 16:17:38 Calogero Mauceri wrote: Hi all, I find QSharedMemory very useful, and I'm extensively using it for cross platform IPC. I noticed in the code (qsharedmemory_unix.cpp) there are two implementations for that class, one using System V IPC and the other using POSIX IPC (mmap). On both Linux and Mac versions of Qt, the System V primitives are used and there is no way to compile Qt using the POSIX implementation (-posix-ipc option is not available in configure). Is there any reason why the System V implementation is preferred? I'd like to switch to the POSIX one to overcome limits in some platforms where the maximum shared memory allowed is only 4MB. Warning: here there be dragons. That code path has probably not been compiled in years. Just patch your Qt to enable it. Note that POSIX memory sharing like that runs a huge risk. Never accept shared memory segments from untrusted applications, since they can crash you: all you need to do is use a file-backed segment of memory (as opposed to anonymous mmap) and then shrink the file. Linux is getting an extension to prevent that, called memory sealing, but I'm guessing Linux isn't your problem OS. -- 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] QSharedMemory POSIX implementation
On 7/9/2014 5:22 PM, Thiago Macieira wrote: On Wednesday 09 July 2014 16:17:38 Calogero Mauceri wrote: Hi all, I find QSharedMemory very useful, and I'm extensively using it for cross platform IPC. I noticed in the code (qsharedmemory_unix.cpp) there are two implementations for that class, one using System V IPC and the other using POSIX IPC (mmap). On both Linux and Mac versions of Qt, the System V primitives are used and there is no way to compile Qt using the POSIX implementation (-posix-ipc option is not available in configure). Is there any reason why the System V implementation is preferred? I'd like to switch to the POSIX one to overcome limits in some platforms where the maximum shared memory allowed is only 4MB. Warning: here there be dragons. That code path has probably not been compiled in years. Just patch your Qt to enable it. Note that POSIX memory sharing like that runs a huge risk. Never accept shared memory segments from untrusted applications, since they can crash you: all you need to do is use a file-backed segment of memory (as opposed to anonymous mmap) and then shrink the file. Linux is getting an extension to prevent that, called memory sealing, but I'm guessing Linux isn't your problem OS. Thanks Thiago for your quick reply. I did not know the POSIX implementation was not supported. My main problems are on Mac systems, the default shared memory settings there are very restrictive. I'll need to modify them somehow from my application. Thanks, Calogero -- Calogero Mauceri Software Engineer Applied Coherent Technology Corporation (ACT) www.actgate.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] How to have equivalent of functions over-riding in Qml
Thanks for the very quick reply. Thank you for clarifying my understanding of correct derivation in Qml Regards, R.kiran ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Guidelines for reporting bugs in Qt
Am 03.07.2014 16:31, schrieb Friedemann Kleint: Hi, as a result of internal discussions at Digia, I have updated http://qt-project.org/wiki/ReportingBugsInQt a bit. The motivation behind this is that we want the bug reports as good as possible since many roles in the Qt project deal with them (developers, code reviewers, release managers, people trying to check for regressions, ...) and thus it is important that bug reports are easy to understand and to reproduce. I would like to have more opinions on the guidelines at http://qt-project.org/wiki/ReportingBugsInQt . Is there anything missing that would make fixing bugs easier in the modules you maintain? Once we have the guidelines in a good shape, they will be shown prominently on the JIRA-landing page. Regards, Friedemann Hi Friedemann, good initiative! The text looks mostly good. Some minor things I just fixed myself. In addition, some wording is outdated. We neither have Trolls nor Merge-Requests anymore. And then there's a logic problem: The text demands to attach files with a name containing the bug's number while creating the report. This is not possible as you won't know the number before you created the report. Instead, the text should recommend to attach such files in a second step, after creating the bare report. Thanks, Robert -- Robert Löhning, 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
[Development] Compiling qtmultimedia on OS X
Can anyone help me with compiling the qtmultimedia plugin on OS X? I’m getting objective-c related errors and I’m stumped. I posted details on the forum: (http://qt-project.org/forums/viewthread/44802/) Warm regards, Mike ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSharedMemory POSIX implementation
On Wednesday 09 July 2014 17:32:29 Calogero Mauceri wrote: I did not know the POSIX implementation was not supported. I think it should be supported and you should be able to choose which implementation you want at runtime. Room for contribution :-) -- 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] 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. === 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. == Summary of systems == - default stderr: what is stderr connected to when launched from the GUI menu - system logging: if there's an API and whether non-privileged users can read from the log - is stderr useful: whether there are conditions under which writing to stderr is useful Android: - default stderr: /dev/null - system logging: available - is stderr useful: barely, it requires a rooted device BlackBerry: - default stderr: /dev/null - system logging: available - is stderr useful: I don't know, it's possible d5a4732c applies to non-BB QNX only OS X and iOS: - default stderr: captured into system log - system logging: available - is stderr useful: yes on OS X, running applications from the terminal SailfishOS: - default stderr: captured into the wrong system log - system logging: available - is stderr useful: yes, for remote debugging applications Current Linux desktops with journald: - default stderr: captured into ~/.xsession-errors - system logging available: available - is stderr useful: yes, for launching from terminal [when Linux desktops start using user-mode systemd, it will be as below] System services on Linux with journald: - default stderr: captured into system log - system logging: available - is stderr useful: yes, for launching from terminal Unix without journald: - default stderr: irrelevant - system logging: not available (non-root users may not be able to read it) - is stderr useful: yes, mandatory Windows GUI apps: - default stderr: NUL - system logging: available - is stderr useful: yes Windows console apps: - default stderr: console - system logging: available - is stderr useful: yes == History == In the dawn of time, qDebug printed to stderr. But then came Windows with GUI applications that don't have a console and stderr is NUL. So Qt applications that did not use CONFIG += console would use OutputDebugString, which we'd detect by the use or not of Qt's WinMain function. That was the first system log API. During Qt 5.0 development, we added logging to BlackBerry's slog2. That was unconditional: all applications, all output. Similarly for the Android port: when it was introduced, it unconditionally logged to the the Android log. But in Qt 5.1, there was a commit (289120f8) that added an environment variable allowing logging to stderr. During 5.2 development, we stopped using WinMain and instead tried to detect whether the application has a console window or not. The first two patch sets of 7fb3906 [1] only checked for the console, but PS3 added a check for whether stderr was valid even if no console window was present. For 5.3, we added support for journald on Linux, mostly intended for SailfishOS. Support was like on Android at the time: an environment variable was needed to write to stderr; otherwise, it went to journald. For 5.3.1,
Re: [Development] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357
On Wednesday 09 July 2014 14:43:36 Thiago Macieira wrote: === 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. === 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. 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). 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) 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. * 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
Re: [Development] Cake and eating it too for qDebug printing to system log - https://codereview.qt-project.org/89357
On Wednesday 09 July 2014 14:43:36 Thiago Macieira wrote: Current Linux desktops with journald: - default stderr: captured into ~/.xsession-errors - system logging available: available - is stderr useful: yes, for launching from terminal [when Linux desktops start using user-mode systemd, it will be as below] 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. -- 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
I feel the urge to give my two cents on that. At least on unix desktop platforms, I expect to get stderr output on the console. So, detecting its presence is certainly a good approach. When there is no console, I probably don't care about the logs at all. I *may* care about error/warning messages, granted that the application manages its outputs diligently, which is often not the case. One argument is that the system logging offers better rotating search facilities, which is true, but the logs would still be cluttered by probably useless messages. There are tons of signal/slot missing throughout KDE applications, as a end user what can I possibly do about it ? I do not have a huge ~/.xsession-error file, but for those who have, I think it's a problem for distributions to solve, not Qt. On the other end, I usually have a large /home partition and relatively small root partition, so, of to evil, I would prefer my home to be cluttered. I think that's true for most Linux installations; Depending on its features or importance to the system or to the user an application is either important, in which case some log should be conserved or unimportant logs should certainly be dropped. A think an application should be assumed to be unimportant ( not to log to the system's journal) by default. The choice should be given both to the developer ( with an api) and maintainers/end user (environment variable) to modify this behavior. As for Qt Creator, my opinion is that the logs of an in-development application become irrelevant the second you press the rebuild button and so its output should always go to stderr only. For platforms which offer no or poor console support, not-in-development applications logs should arguably go to the system journal to be forever forgotten : I don't expect end-users to know how access those logs, even less to provide the developers with them when something goes wrong. Corentin 2014-07-10 1:20 GMT+02:00 Thiago Macieira thiago.macie...@intel.com: On Wednesday 09 July 2014 14:43:36 Thiago Macieira wrote: Current Linux desktops with journald: - default stderr: captured into ~/.xsession-errors - system logging available: available - is stderr useful: yes, for launching from terminal [when Linux desktops start using user-mode systemd, it will be as below] 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. -- 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
On Thursday 10 July 2014 02:54:12 Corentin Jabot wrote: At least on unix desktop platforms, I expect to get stderr output on the console. So, detecting its presence is certainly a good approach. When there is no console, I probably don't care about the logs at all. I *may* care about error/warning messages, granted that the application manages its outputs diligently, which is often not the case. As we discussed on IRC: *if* you care about the warnings, then you want to find them. And reading ~/.xsession-errors is not acceptable. Mine has close to 1.2 million lines in 7 days of uptime (roughly 7000 lines per hour), in an output that doesn't log application name, PID, TID or function name. We can turn those on with the logging framework, but they're not easily searchable. One argument is that the system logging offers better rotating search facilities, which is true, but the logs would still be cluttered by probably useless messages. There are tons of signal/slot missing throughout KDE applications, as a end user what can I possibly do about it ? Hence the searchability. $ journalctl -l /home/thiago/obj/qt/qt5/qtbase/bin/qdbusviewer -- Logs begin at Wed 2014-07-09 16:14:48 PDT, end at Wed 2014-07-09 19:23:29 PDT. -- Jul 09 19:23:29 tjmaciei-mobl4 qdbusviewer[36992]: Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) $ journalctl -l QT_CATEGORY=default -- Logs begin at Wed 2014-07-09 16:14:48 PDT, end at Wed 2014-07-09 19:23:29 PDT. -- Jul 09 19:23:29 tjmaciei-mobl4 qdbusviewer[36992]: Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) I can even search for which Qt categories are getting logged: $ journalctl -F QT_CATEGORY default I do not have a huge ~/.xsession-error file, but for those who have, I think it's a problem for distributions to solve, not Qt. Agreed. But we have to integrate with the mechanisms that the distros provide. A think an application should be assumed to be unimportant ( not to log to the system's journal) by default. The choice should be given both to the developer ( with an api) and maintainers/end user (environment variable) to modify this behavior. I disagree. I think the application should log and then the log system can decide whether to keep it or throw it away. The one thing I'm missing here is a user-configurable log system. If I'm a developer of a Qt application and I'm using the system Qt, I want to get my logs and not clutter the system. Which is where the recommendation comes from: Linux distributions should not enable a logging system that regular users can't access. As for Qt Creator, my opinion is that the logs of an in-development application become irrelevant the second you press the rebuild button and so its output should always go to stderr only. Yes and no. Creator must show it, but I don't think it matters to the user where it got the output from. If Creator can read from the log, it can get more information than just plain pipes. It could, for example, allow you to jump to the source line that produced the line in question. Granted, that could be done with a proper message formatting too, but it would be harder because stdout and stderr are just plain buffers (they're not even line buffered), whereas the log would be properly packetised. For platforms which offer no or poor console support, not-in-development applications logs should arguably go to the system journal to be forever forgotten :I don't expect end-users to know how access those logs, even less to provide the developers with them when something goes wrong. That's the case on Windows: GUI apps have stderr connected to the blackhole and the OutputDebugString buffer is only 32k in size. Use it or lose it. But again: it can be used. Hence the suggestion to use the system log. -- 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
Thanks for the very quick reply.
Thank you for clarifying my understanding of correct derivation in Qml
Regards,
R.kiran
Hi In continuation of the previous post - I now got it working to invoke
the base class / derived class implementations correctly from extenal
place.
Now the question is: Can I have my derived class, call the base class
implementation as part of its functionality?
C++ equivalent would be something like this:
class Base
{
public:
void method1()
{
std::cout Base::method1().. std::endl;
}
};
class Derived: public Base
{
public:
void method1()
{
std::cout Derived::method1()..pre.. std::endl;
// Derived class uses the base class implementation fully
// and does something extra on its own.. true case of extending the
// functionality, if I may say so!
Base::method1();
std::cout Derived::method1()..post.. std::endl;
}
};
Qml Equivalent would be (to the extent I have figured out)
Base.qml
Item
{
function method1()
{
console.log(Base::method1()...)
}
}
Derived.qml (in the same folder as Base.qml)
---
Base
{
function method1()
{
console.log(Derived::method1()...)
}
}
I tried this, it ended up in recursive loop, obviously!!
Derived.qml
---
Base
{
id: myBase
function method1()
{
console.log(Derived::method1()...pre)
// myBase.method1() // --- calls the same method recursively
// Base.method1() // --- this line gives undefined object,
naturally!
console.log(Derived::method1()...post)
}
}
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
