[Development] [Request] Add Info to QDebug
Qt currently supports the following ‘severity’ levels for logging: Debug, Warning, Critical, Fatal and System. I propose to add the following levels: Info and Error, with associated methods qInfo() and qError(). Particularly, the Info severity can be interesting to have applications output log messages that are not warnings, but also not debug messages. Error would fit between Warning and Critical. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Feature Request] Add QtWebSockets to Qt
On further consideration, I also recommend that the open and close methods in QQmlWebSocket be public Q_INVOKABLE and any open/close testing logic in setUrl be moved to the open and close methods, reducing the need for additional error handling in the setUrl method. I also don't understand why sendTextMessage is a Q_SLOT and not a Q_INVOKABLE method. Thanks. Steve -Original Message- From: Steve Gold Sent: Friday, December 20, 2013 6:29 PM To: Development@qt-project.org Subject: Re: [Development] [Feature Request] Add QtWebSockets to Qt I don't know who gets an official vote but I am in favor of making QtWebSockets part of the official Qt repository and would like to see it included in the next 5.2.1 release. Since I consider it to be 'Qt-worthy' but almost 'QML-worthy', I recommend that a public Q_INVOKABLE disconnect() method be added to the QQmlWebSocket class with error handling and that error handling be improved in the setUrl, open, close and setTextMessage methods, among others. These methods could return a bool value, use try/catch or a combination. Let me know what you think of these suggestions. Thanks. Steve -Original Message- From: Kurt Pattyn Sent: Friday, December 20, 2013 5:07 PM To: development@qt-project.org Subject: [Development] [Feature Request] Add QtWebSockets to Qt Hi, I propose to move QtWebSockets from the playground (https://qt.gitorious.org/qtplayground/websockets/) to the official Qt repository as an add-on. As there is a need for a websockets implementation in Qt (see https://bugreports.qt-project.org/browse/QTBUG-26300 and https://bugreports.qt-project.org/browse/QTBUG-26298), QtWebSockets could be a welcome addition. The module only depends on Qt (core and network, and Qml for the Qml component). It supports the ws and wss schemes, and can be used as a client and server component. The API is modelled after QAbstractSocket and QTcpSocket, and hence should be familiar for Qt developers. The Qml module has been reviewed by Alan Alpert, and is considered 'QML-worthy'. Currently, the module builds as a Qt add-on, and can be used by adding QT += websockets. QtWebSockets passes the Autobahn Testsuite (see http://autobahn.ws/testsuite/), has extensive unit tests, and builds successfully on the Qt CI infrastructure. Performance has also been tested with AutoBahn TestSuite, and is up-to-par with all current browsers and websocketpp (even slightly faster). Please cast your votes. Cheers, Kurt ___ 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] [Request] Add Info to QDebug
On sábado, 21 de dezembro de 2013 14:23:10, Kurt Pattyn wrote: Qt currently supports the following ‘severity’ levels for logging: Debug, Warning, Critical, Fatal and System. I propose to add the following levels: Info and Error, with associated methods qInfo() and qError(). Particularly, the Info severity can be interesting to have applications output log messages that are not warnings, but also not debug messages. Error would fit between Warning and Critical. See the Gerrit submissions for the logging framework. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Quick Controls Calendar
On Fri, Dec 6, 2013 at 4:11 PM, Mitch Curtis mitch.cur...@digia.com wrote:
On 12/06/2013 03:08 PM, Mark Gaiser wrote:
On Fri, Dec 6, 2013 at 2:02 PM, Mitch Curtis mitch.cur...@digia.com
wrote:
Hello.
At the beginning of this year I started work on a Calendar for Qt Quick
Controls as a sort of side project. After removing the WIP from the
commit message, I got some feedback from developers who either a) had
also wrote a Calendar for KDE stuff or b) suggested I ask for feedback
from plasma-devel. Rather than add to the already massive list of patch
sets for that change, I thought it would be better to truly open up the
Calendar for contributions before it goes in by creating a WIP branch
for it in the Qt Quick Controls repo [1]:
wip/calendar
It'll be a throwaway branch, so every commit must be atomic and follow
all of the normal Qt commit policies [2][3]. At the end, we'll resubmit
every individual change to qtquickcontrols' dev branch.
I've been told that this is incorrect; the correct statement is:
even though this is a throw-away branch (whose commits will be re-submitted
to dev individually), the usual policies should be followed
Please feel free to submit patches or provide feedback on what's already
there. For example, it has already been suggested that there should be a
C++ backend for the models, dates, etc.
Cheers.
[1]
https://qt.gitorious.org/qt/qtquickcontrols/source/4c3196c979d9a7f46b3f37b14140026dd74bf79a
[2] http://qt-project.org/wiki/Branch-Guidelines
[3] http://qt-project.org/wiki/Commit_Policy
Hi Mitch,
It's awesome that you pull in the KDE plasma folks. I wonder who gave
you that idea? ;)
Below is my feature list that i'd like to have in that calendar.
Since i have some experience in that area i will try to help out as
much as i can.
-- QML part --
* Controls for the calendar grid
* Controls for next/forward or just a few functions. This should at
least have a nextMonth/previousMonth. Perhaps also nextYear and
previousYear for convenience.
* Controls for the day names (mon, tue, wed, thu, fri, sat, sun). And
the ability to change the name to shorter/longer variants.
* Controls for the weeknumbers that are shown in the grid.
As far as i understand the QML code, all but the weeknumbers are in.
Yep.
-- Locale --
In KDE there was already an issue with differences between the
JavaScript date object and the QDate object. I don't know the fine
details here, someone else will probably fill that in i hope. I know
there where issues, just not what exactly.
From the testing that I did with it [1], it has some differences when it's a
negative year, so the current implementation of the Calendar only allows
positive years, up to the year 275759; a significantly smaller range than
QDate [2].
-- C++ part --
This is the part where i really would like some feedback. I have a
general idea of how it should be done, but i don't know the details or
implications it might have.
It is my hope that calendar controls like Mitch is proposing now will
be extensive enough to simply swap the models to another backend.
Akonadi comes to mind. However, there should obviously be a
non-akonadi based version for default Qt usage.
My idea on that is as follows. Again, i don't know the implications of
it or if it's really viable to take this route. Feedback is very much
welcome here!
The calendar model should be based on a new model that provides some
default functionality and properties. I would say:
QAbstractCalendarModel : public QAbstractListModel { ... }
This model should provide the default - should be implemented -
properties:
* day -- INT number of the day in a current month
* isCurrentMonth -- returns true for the current month (aka, the month
you are viewing in the calendar). Returns false for the days before
and after the currently viewing month. Based on the position in the
grid you can then calculate if the entry where isCurrentMonth
returns false is before or after the current month.
* containsEvents -- true if the day contains events, false otherwise
day and isCurrentMonth should be convenience implemented in the
QAbstractCalendarModel.
Next there should be a model for core Qt calendar usage. Or in other
terms: no akonadi dependency.
That would be a class like:
QSimpleCalendarModel : public QAbstractCalendarModel { ... }
That class should probably have some basic storage in json files
somewhere? Or ini or sqlite or..? Just something so that it can be
used out of the box without any other requirements beyond Qt.
Till this point is what would probably go in Qt. Everything after this
line becomes Akonadi specific and should not be in Qt.
If a structure like the above is approved then Akonadi can be very
easily used in KDE with the Qt calendar components.
We'd just have to make out own QAbstractCalendarModel implementation
that uses akonadi data. That would be a class like:
[Development] Qt 5.2.0 compilation fails on ArchLinux
Hi all,
I'm trying to compile qt-5.2.0 on arch linux, but with/without
icu-support I get the following error:
make[3]: Entering directory
'/usr/local/src/qt-everywhere-opensource-src-5.2.0/qtbase/src/platformsupport'
LD_LIBRARY_PATH=/usr/local/src/qt-everywhere-opensource-src-5.2.0/qtbase/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
/usr/local/src/qt-everywhere-opensource-src-5.2.0/qtbase/bin/qdbusxml2cpp -i
struct_marshallers_p.h -a deviceeventcontroller_adaptor.h:
../3rdparty/atspi2/xml/DeviceEventController.xml
/usr/local/src/qt-everywhere-opensource-src-5.2.0/qtbase/bin/qdbusxml2cpp:
error while loading shared libraries: libicui18n.so.51: cannot open
shared object file: No such file or directory
Makefile:3407: recipe for target 'deviceeventcontroller_adaptor.h' failed
make[3]: *** [deviceeventcontroller_adaptor.h] Error 127
Arch Linux has icu-5.2
Any hints?
--
Wilhelm
w.me...@unix.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Quick Controls Calendar
During the testing, we've found a bunch of bugs and other issues. I'd
suggest uploading this WIP branch to codereview, like we do for any other
stuff.
Regards,
Konstantin
2013/12/21 Mark Gaiser mark...@gmail.com
On Fri, Dec 6, 2013 at 4:11 PM, Mitch Curtis mitch.cur...@digia.com
wrote:
On 12/06/2013 03:08 PM, Mark Gaiser wrote:
On Fri, Dec 6, 2013 at 2:02 PM, Mitch Curtis mitch.cur...@digia.com
wrote:
Hello.
At the beginning of this year I started work on a Calendar for Qt Quick
Controls as a sort of side project. After removing the WIP from the
commit message, I got some feedback from developers who either a) had
also wrote a Calendar for KDE stuff or b) suggested I ask for feedback
from plasma-devel. Rather than add to the already massive list of patch
sets for that change, I thought it would be better to truly open up the
Calendar for contributions before it goes in by creating a WIP branch
for it in the Qt Quick Controls repo [1]:
wip/calendar
It'll be a throwaway branch, so every commit must be atomic and follow
all of the normal Qt commit policies [2][3]. At the end, we'll resubmit
every individual change to qtquickcontrols' dev branch.
I've been told that this is incorrect; the correct statement is:
even though this is a throw-away branch (whose commits will be
re-submitted
to dev individually), the usual policies should be followed
Please feel free to submit patches or provide feedback on what's
already
there. For example, it has already been suggested that there should be
a
C++ backend for the models, dates, etc.
Cheers.
[1]
https://qt.gitorious.org/qt/qtquickcontrols/source/4c3196c979d9a7f46b3f37b14140026dd74bf79a
[2] http://qt-project.org/wiki/Branch-Guidelines
[3] http://qt-project.org/wiki/Commit_Policy
Hi Mitch,
It's awesome that you pull in the KDE plasma folks. I wonder who gave
you that idea? ;)
Below is my feature list that i'd like to have in that calendar.
Since i have some experience in that area i will try to help out as
much as i can.
-- QML part --
* Controls for the calendar grid
* Controls for next/forward or just a few functions. This should at
least have a nextMonth/previousMonth. Perhaps also nextYear and
previousYear for convenience.
* Controls for the day names (mon, tue, wed, thu, fri, sat, sun). And
the ability to change the name to shorter/longer variants.
* Controls for the weeknumbers that are shown in the grid.
As far as i understand the QML code, all but the weeknumbers are in.
Yep.
-- Locale --
In KDE there was already an issue with differences between the
JavaScript date object and the QDate object. I don't know the fine
details here, someone else will probably fill that in i hope. I know
there where issues, just not what exactly.
From the testing that I did with it [1], it has some differences when
it's a
negative year, so the current implementation of the Calendar only allows
positive years, up to the year 275759; a significantly smaller range than
QDate [2].
-- C++ part --
This is the part where i really would like some feedback. I have a
general idea of how it should be done, but i don't know the details or
implications it might have.
It is my hope that calendar controls like Mitch is proposing now will
be extensive enough to simply swap the models to another backend.
Akonadi comes to mind. However, there should obviously be a
non-akonadi based version for default Qt usage.
My idea on that is as follows. Again, i don't know the implications of
it or if it's really viable to take this route. Feedback is very much
welcome here!
The calendar model should be based on a new model that provides some
default functionality and properties. I would say:
QAbstractCalendarModel : public QAbstractListModel { ... }
This model should provide the default - should be implemented -
properties:
* day -- INT number of the day in a current month
* isCurrentMonth -- returns true for the current month (aka, the month
you are viewing in the calendar). Returns false for the days before
and after the currently viewing month. Based on the position in the
grid you can then calculate if the entry where isCurrentMonth
returns false is before or after the current month.
* containsEvents -- true if the day contains events, false otherwise
day and isCurrentMonth should be convenience implemented in the
QAbstractCalendarModel.
Next there should be a model for core Qt calendar usage. Or in other
terms: no akonadi dependency.
That would be a class like:
QSimpleCalendarModel : public QAbstractCalendarModel { ... }
That class should probably have some basic storage in json files
somewhere? Or ini or sqlite or..? Just something so that it can be
used out of the box without any other requirements beyond Qt.
Till this point is what would probably go in Qt.
