Sounds great as well...while I'd like something for Mobile, I also need
something accessible for non-Mobile so the two can easily integrate.(E.g mobile
applications and desktop applications integrating for a shared experience).
$0.02
Ben
On Friday, February 12, 2016 10:10 AM, ekke wrote:
Question: How does this affect the reading list for the Qt Certifications?
It's been a while since I looked at it, but are the two reading lists not the
same?I'd probably suggest going more that direction - what's good for the
technologies that Qt uses and how can one improve oneself to help in w
On Thursday, October 10, 2013 9:26 AM, Olivier Goffart
wrote:
> On Thursday 10 October 2013 15:14:02 André Somers wrote:
> > Op 10-10-2013 14:53, Olivier Goffart schreef:
> > > On Thursday 03 October 2013 10:38:59 Thiago Macieira wrote:
> > >> On quinta-feira, 3 de outubro de 2013 10:36:44, Oli
Just FYI - from what I am aware from building the Linux Kernel from time to
time there is some CAN support there too.
So you might want to add that to your list as well, or at least look at it.
$0.02
Ben
>
> From: Denis Shienkov
>To: development@qt-project.or
> From: Thiago Macieira
>To: development@qt-project.org
>Sent: Thursday, May 2, 2013 11:09 AM
>Subject: Re: [Development] kdelibs coding style
>On quinta-feira, 2 de maio de 2013 16.12.00, Daniel Teske wrote:
>> > I tried to compromise, but it seems like we don't want to compromise.
>> Apparentl
Having participated in the discussion on the Interests list...
Aside from what Andre' said...
> From: Joerg Bornemann
>To: Friedemann Kleint
>Cc: development@qt-project.org
>Sent: Friday, April 26, 2013 11:35 AM
>Subject: Re: [Development] Qt5 combined source package - Perl dependency
>On 2
FYI - having observed and read the conversation on the Interests list, these
are not people using git that are complaining.
They are people that are pulling the source archives for releases from the
website; no git involved.
For example:
http://download.qt-project.org/official_releases/qt/5.0/5.
> From: Thiago Macieira
> To: development@qt-project.org
> Cc:
> Sent: Tuesday, February 26, 2013 10:46 AM
> Subject: Re: [Development] Evolving Qt's multithreading API
>
> On terça-feira, 26 de fevereiro de 2013 07.03.37, BRM wrote:
>> Personally, I can
I've been sitting silent on this, but I am quite in favor of having an easy to
understand approach to using QThreads, which the proposal in this thread seems
to be.
> From: Thiago Macieira
> To: development@qt-project.org
> Sent: Monday, February 25, 2013 11:06 AM
> Subject: Re: [Development]
> From: Niko Sams
> Sent: Sunday, January 6, 2013 3:49 PM
> Subject: [Development] Gdb pretty printers for Qt 5
> years ago I started working on gdb pretty printers for Qt 4 that allow
> printing eg. QString or QList values. Similar to what QtCreator does
> but with one big difference: it also wo
> From: Ahumada Sergio
> To: development
> Sent: Wednesday, December 12, 2012 2:19 AM
> Subject: Re: [Development] Qt Playground - Updating Daemon/Service Support
>
>>
>> As I know others have expressed interest in helping out, here's the
>> bug report in case you want to join/watch:
> From: Alan Alpert <4163654...@gmail.com>
>Sent: Tuesday, December 11, 2012 2:46 PM
>Subject: Re: [Development] Controlling QML Imports
>
>On Tue, Dec 11, 2012 at 7:52 AM, Thiago Macieira wrote:
>> On terça-feira, 11 de dezembro de 2012 15.44.37, Aaron J. Seigo wrote:
>>> > > > loading of nativ
> From: Jedrzej Nowacki
>Subject: Re: [Development] Running Qt auto-tests offscreen
>On Friday 7. December 2012 16.55.41 Thiago Macieira wrote:
>> On sexta-feira, 7 de dezembro de 2012 11.04.27, Samuel Rødal wrote:
>> > In the end, maybe we could even use this for a subset of the tests in
>> > th
> From: d3fault
> Sent: Friday, November 30, 2012 11:25 PM
> Subject: Re: [Development] Branching 5.0
>
> On 11/30/12, Thiago Macieira wrote:
>> He says that the converse usually holds true. First of all, converses
>> usually
>> do not hold true. Conditions that are both necessary and suffic
> From: Alan Alpert <4163654...@gmail.com>
> Sent: Thursday, November 29, 2012 11:52 AM
> Subject: Re: [Development] Comparing two reals in Qt code
>
> On Thu, Nov 29, 2012 at 6:53 AM, Sean Harmer wrote:
>> On Thursday 29 November 2012 15:01:05 Dominik Holland wrote:
>>> Hi all,
>>>
>>> last
> From: BRM
> Sent: Monday, November 26, 2012 9:39 PM
> Subject: Re: [Development] Qt Playground - Updating Daemon/Service Support
>> From: Matt Broadstone
>> Subject: Re: [Development] Qt Playground - Updating Daemon/Service Support
>> On Mon, Nov 26, 2012 at 1:4
> From: Lukas Geyer
> Subject: Re: [Development] Qt Playground - Updating Daemon/Service Support
> Am 27.11.2012 11:03, schrieb Sascha Cunz:
>> [...]
>>> The difference is that 'operate' and 'configure' are
> two different tasks
>>> and thus usually require two different interfaces.
>>> The
- Original Message -
> From: Sascha Cunz
> Subject: Re: [Development] Qt Playground - Updating Daemon/Service Support
>
>> All services/daemons must be able to interface with other processes:
> Here, I almost agree :-)
>
>> (a)- a "client-process" can
> "request-a-client-operation"
> From: Matt Broadstone
>Subject: Re: [Development] Qt Playground - Updating Daemon/Service Support
>On Mon, Nov 26, 2012 at 1:48 PM, BRM wrote:
>> From: Charley Bay
>Is there any word on whether you guys get a spot in playground?
Since Thiago +1'd, I think I'm g
> From: Charley Bay
>Subject: Re: [Development] Qt Playground - Updating Daemon/Service Support
>
>
>Hi, Matt--
>
>
>thoughts:
>>
>>
>>a) I think the only reason the old QtService uses a template based approach
>>is to support the different types of Q*Application. It would be quite useful
>>to
gt;>>>>> equivalent
>>>
>>>
>>>+1
>>>
>>>IMHO this would be a cross-platform useful module that I'd vote to
>>>ultimately end-up within "Qt-proper".
>>>
>>>
>>>Disclosure: I traded emai
t;IMHO this would be a cross-platform useful module that I'd vote to ultimately
>>end-up within "Qt-proper".
>>
>>
>>Disclosure: I traded emails with BRM off-list, and would like to help.
>>
>>--charley
>
>Would you guys like to get into your
> From: Matt Broadstone
>On Mon, Nov 26, 2012 at 10:13 AM, Thiago Macieira
>wrote:
>
>On segunda-feira, 26 de novembro de 2012 06.59.23, BRM wrote:
>>> I am following up to some e-mails I sent on the feedback/interests/dev
>>> lists[1] and blogs[2] over a ye
I am following up to some e-mails I sent on the feedback/interests/dev lists[1]
and blogs[2] over a year ago for updating the QtService Component.
I would like to open a new Qt Playground project to create a new equivalent for
Qt5 that is more natively integrated.
Synopsis: QtService Componen
> From: "shane.kea...@accenture.com"
> Sent: Tuesday, November 13, 2012 11:12 AM
> Subject: RE: [Development] Proposal: New list of Qt 5 reference / Tier 1
> platforms
>> Win8 support would be nice to add, but please do not drop WinXP.
>> MS may be dropping official, public support for WinXP
> From: Koehne Kai
> Friedemann said he'd like to have msvc 2010 64 bit as reference platform,
> maybe replacing msvc 2010 32 bit. Problems I see is that we don't test it
> right now in the CI system, and that e.g. qtwebkit has currently problems on
> windows 64 bit.
Agree with comments alrea
- Original Message -
> From: Alan Alpert <4163654...@gmail.com>
> On Thu, Nov 8, 2012 at 12:49 PM, BRM wrote:
>>> From: Alan Alpert <4163654...@gmail.com>
>>
>>> To: development
>>> Cc:
>>> Sent: Thursday, November 8,
> From: Alan Alpert <4163654...@gmail.com>
> To: development
> Cc:
> Sent: Thursday, November 8, 2012 12:57 PM
> Subject: [Development] Another method of registering QML types
>
> Currently, there is no way to register QML files as types from C++.
> This is the exact same functionality that qml
> From: Thiago Macieira
> Sent: Tuesday, October 23, 2012 1:03 PM
> Subject: Re: [Development] New proposal for the tool naming
>
> On terça-feira, 23 de outubro de 2012 16.33.05, Ziller Eike wrote:
>> >> So that if you happen to have a "real" qmake instead of
> the wrapper in
>> >> the
>> >
> From: Thiago Macieira
>Subject: Re: [Development] New proposal for the tool naming
>On segunda-feira, 22 de outubro de 2012 21.21.17, André Pönitz wrote:
>> On Mon, Oct 22, 2012 at 09:08:38AM -0700, Thiago Macieira wrote:
>> > On segunda-feira, 22 de outubro de 2012 15.45.56, Oswald
>> > Budden
The more I read the various related threads, the more I think if qt-project is
to do anything it should be to define to LSB/FHS how to configure Qt. I don't
necessarily see consensus; but I do see a lot of questions that have gone
unanswered. There seems to be a lot of objection to user tool nam
> From: Konstantin Ritt
> Sent: Sunday, October 21, 2012 5:56 AM
> Subject: Re: [Development] New proposal for the tool naming
>>> > The easiest way to achieve that is probably to create a solution
> based on
>>> > files and you create a ~/.config/qconfig-maemo5 which shadows the
> one in
>>>
FWIW, +1 - with one modification - reflect at least the minor version in the
install path - so $prefix/libexec/qt5.0, if not $prefix/libexec/qt5.0.0.
I think there is probably a simple rule we could maintain: Keeping the names of
developer visible tools the same is, IHMO, a must. Tools that are
> From: Oswald Buddenhagen
>Subject: [Development] renaming qmake for everyone (was: Re: Co-installation &
>library naming rules=)
>[changed the subject to get some attention ... from a quick survey i
>don't have the impression that many people grasp that this thread is
>very much relevant for t
> From: Sorvig Morten
>Subject: Re: [Development] Behavior changes in Qt
>On Oct 11, 2012, at 4:06 PM, BRM wrote:
>>>
>>
>> How about opt-in (via configure or extra flags) until the next major release?
>> I don't think doing the opt-in/opt-out/manda
- Original Message -
> From: Sorvig Morten
> Subject: Re: [Development] Behavior change: A sane and consistent QPainter
> coordinate system in Qt 5
>
>
> On Oct 11, 2012, at 1:57 PM, Samuel Rødal
> wrote:
>>
>> It's unfortunate to potentially cause some extra trouble for a subset
>
FWIW, +1.
Ben
- Original Message -
> From: Hausmann Simon
> To: Thiago Macieira ; "development@qt-project.org"
>
> Cc:
> Sent: Friday, September 28, 2012 4:22 AM
> Subject: Re: [Development] Branching for Qt 5 repositories
>
>
> Sounds great, especially the branch names. +1
>
>
> From: "marius.storm-ol...@nokia.com"
> Subject: Re: [Development] Qt 5 beta
> On 31/08/2012 07:29, ext Thiago Macieira wrote:
> Remember that 7z was fairly unknown at one point too, but has caught on
> due to its extremely powerful compression, and is now well known and
> accessible anywhere.
> From: Jonas M. Gastal
>To: development@qt-project.org; BRM
>Sent: Thursday, August 30, 2012 4:02 PM
>Subject: Re: [Development] Qt 5 beta
>
>On Thursday 30 August 2012 11:48:38 BRM wrote:
>> tar.bz2 is pretty common, along with tar.gz.
>> tar.xy, OTOH, is quite
- Original Message -
> From: Thiago Macieira
> To: development@qt-project.org
> Sent: Thursday, August 30, 2012 1:07 PM
> Subject: Re: [Development] Qt 5 beta
>
> On quinta-feira, 30 de agosto de 2012 17.30.58, Laszlo Papp wrote:
>> > I'd rather not bring back .tar.bz2.
>> It is ok, if
> From: Oswald Buddenhagen
> Subject: Re: [Development] Setting up time-based releases for the project
> On Tue, Aug 07, 2012 at 11:00:26AM +0200, ext Thiago Macieira wrote:
>> My recommendation is that master be one of the two stable branches.
> That's
>> what people cloning from Git should g
> From: Sean Harmer
> On Monday 16 July 2012 07:21:23 Thiago Macieira wrote:
>> On segunda-feira, 16 de julho de 2012 15.12.15, Sean Harmer wrote:
>> > On Monday 16 July 2012 07:08:38 Thiago Macieira wrote:
>> > > I'm asking for Qt 5.0: what should we tell Linux distributors
> to
>> > > conf
I have not yet become a contributor (hope to in the future once I can find
time), but I 100% agree.
At the very least, it will give something to point to when it comes to working
with forum and list administrators when the rare occurrence requires a process
to rebuke or remove people.
I'd cert
> From: Thiago Macieira
>On quarta-feira, 16 de maio de 2012 16.56.05, Robin Burchell wrote:
>> That isn't how reality works. You cannot tell me (as a volunteer) what
>> I ought to be spending my time on any more than I can tell you what
>> color to paint your livingroom. My interests dictate wha
> From: Donald Carr
> Please provide a link to your poll when citing it so that people can
> look at empirical data:
>
> http://qt-project.org/forums/viewthread/16693/
>
> must be the wrong poll, since that shows QML components being a
> primary point of concern. This is out of a sample set of
> From: d3fault
> So, I'm supposed to want to contribute an upgraded C++ GUI API ("Yes,
> the Qt Widgets module we have in Qt 5 is right now marked as ‘done’,
> which means we don’t have anybody actively working on new features for
> the module at this point in time. But this can change any day i
> From: "jan-arve.saet...@nokia.com"
>ext Corentin Jabot wrote on 2012-05-02:
>
>>
>> bool
>> QServiceManager::setInterProcessMethod(QService::InterProcessMethod);
>>
>> enum QService::InterProcessMethod {
>> Native,
>> LocalSocket,
>> DBus
>> }
>>
>Wouldn't
>
> From: Thiago Macieira
> Subject: Re: [Development] QString::fromAscii & toAscii's future
> On terça-feira, 24 de abril de 2012 07.33.41, BRM wrote:
>> Question: is there are reason not to support the US-Extended ASCII
>> (128-255)? I know it's not used of
- Original Message -
> From: Robin Burchell
> 2012/4/24 Thiago Macieira :
>> My recommendation is a variant of options 3: we document that it accepts
> only
>> US-ASCII and that it has undefined behaviour when the input isn't
> US-ASCII
>> compliant. That way, we can make it be equal
> From: Joerg Bornemann
> On 05/03/2012 16:49, ext BRM wrote:
>
>> So why start a situation that could lead to that kind of interdependencies
> within Qt or Qt applications?
>
> I wasn't proposing anything like this; was just curious. :)
> I'm strictly ag
> From: Joerg Bornemann
>On 01/03/2012 16:43, ext BRM wrote:
>
>> For years, Microsoft advocated the use of simply including the "windows.h"
>> header file. However, this ultimately led to a very very big problem - one
>> that ended up with circular depen
> From: Olivier Goffart
>On Thursday 01 March 2012 12:44:47 Mathias Hasselmann wrote:
>> Sadly, considering the slowness of g++ and the complexity of Qt, I doubt
>> this is a reasonable approach for Qt.
>That's what pre-compiled header are for.
Not everyone uses pre-compiled headers, nor should
> From: Thiago Macieira
>On quinta-feira, 1 de março de 2012 12.44.47, Mathias Hasselmann wrote:
>> > According to the book it is. But in practice it happens all the time, and
>> > we know it.
>>
>> To which book? C++ compilers and IDEs give zero support in enforcing
>> direct includes. Consider
Just FYI - this is probably a better question for the qt-interests list as this
list is focused on Qt5 at the moment (and post 5.0 after that).
$0.02
BRM
>
> From: 陳敏華
>To: development@qt-project.org
>Sent: Tuesday, February 28, 2012 10:58
> From: "shane.kea...@accenture.com"
> To: bm_witn...@yahoo.com; lincoln.ram...@nokia.com; david.fa...@kdab.com
> Cc: development@qt-project.org
> Sent: Friday, February 24, 2012 10:46 AM
> Subject: RE: [Development] (long) thoughts on categorized logging (qLog)
>> well, it probably shouldn't be
> From: Lincoln Ramsay
> On 02/23/2012 09:48 PM, ext David Faure wrote:
>>> # write output to a file (in the user's home directory)
>>> logging.output.file = file.txt
>>
>> I suppose Windows users would expect relative paths to be "in the CWD,
> which
>> is usually the executable's director
> From: Olivier Goffart
> On Tuesday 21 February 2012 14:03:26 Marc Mutz wrote:
>> On Tuesday February 21 2012, Marc Mutz wrote:
>> > On Tuesday February 21 2012, Marc Mutz wrote:
>> > > Hi,
>> > >
>> > > The QString header contains a ### about removing sprintf() in
> 5.0, but
>> > > it's
> From: Thiago Macieira
> On terça-feira, 21 de fevereiro de 2012 09.59.49, Marc Mutz wrote:
>> A tangential question: should QRect be QBasicRect (in which case
> it
>> would probably have a class invariant of right()-left()==width() instead
>> of width()-1 as now. If there is a plan to move
- Original Message -
> From: Thiago Macieira
> On segunda-feira, 20 de fevereiro de 2012 12.42.49, David Faure wrote:
>> > Do you imagine something in the qLog config file? An environment
>> > variable? A C++ API?
>>
>> I think "something in the qLog config file" is the best option.
> From: "lars.kn...@nokia.com"
> On 2/16/12 6:21 PM, "ext Girish Ramakrishnan"
>
> wrote:
>
>> Hi Lars,
>>
>> On Thu, Feb 16, 2012 at 5:03 AM, wrote:
>>> On 2/16/12 12:16 PM, "ext Giuseppe D'Angelo"
> wrote:
>>>
On 15 February 2012 22:56, Sean Harmer
> wrote:
> On 15/02/2012
> From: Lincoln Ramsay
>To: BRM
>On 02/16/2012 02:14 AM, ext BRM wrote:
>>> This fails the "do nothing quickly" test so the cost of leaving
>>> such statements in shipping code is high, even when the categories
>>> are disabled.
>>&g
> From: "lars.kn...@nokia.com"
> On 2/15/12 12:11 PM, "ext Olivier Goffart" wrote:
>> On Wednesday 15 February 2012 22:02:10 craig.sc...@csiro.au wrote:
>>> On 15/02/2012, at 8:58 PM,
>>>
>> wrote:
>>> > On 2/15/12 10:28 AM, "ext Thiago Macieira"
>
>>> >
>>> > wrote:
>>> >> On quarta-f
> From: Lincoln Ramsay
> To: development@qt-project.org
> Cc:
> Sent: Tuesday, February 14, 2012 8:05 PM
> Subject: Re: [Development] QLog ( Work on qDebug and friends)
>
> On 02/15/2012 01:47 AM, ext BRM wrote:
>> I'd much rather see a Category obj
elopment-bounces+kai.koehne=nokia@qt-project.org
>> [mailto:development-bounces+kai.koehne=nokia@qt-project.org] On
>> Behalf Of ext BRM
>> Sent: Tuesday, February 14, 2012 3:00 PM
>> To: development@qt-project.org
>> Subject: Re: [Development] QLog ( Work on q
- Original Message -
> From: "kai.koe...@nokia.com"
>> -Original Message-
>> From: development-bounces+kai.koehne=nokia@qt-project.org
>> [mailto:development-bounces+kai.koehne=nokia@qt-project.org] On
>> Behalf Of Ramsay Lincoln (Nokia-MP/Brisbane)
>> Sent: Monday, F
> From: "shane.kea...@accenture.com"
>T he current default behaviour of Qt sockets is that they allocate an
>unbounded
> amount of memory if the application is not reading all data from the socket
> but
> the event loop is running.
> In the worst case, this causes memory allocation failure res
> From: "casper.vandonde...@nokia.com"
> On 2/9/12 10:44 PM, "ext BRM" wrote:
>>> From: "casper.vandonde...@nokia.com"
>
>>> Just to add what I think to Marius' comments:
>>> 1. Doxygen would need some extra features,
> From: "wolfgang.b...@nokia.com"
> The controlling of the category will be done using a configuration file.
> QLog contains a private class that creates a file watcher for the
> configuration
> file.
> So not only if you start the application but during runtime as well the
> category
> filter
> From: "casper.vandonde...@nokia.com"
>Just to add what I think to Marius' comments:
>1. Doxygen would need some extra features, the major one being QML, but also
>being able to use index files to easily link for instance the Creator docs to
>the Qt docs.
Why would Doxygen need QML itself? O
> From: Olivier Goffart
> On Thursday 09 February 2012 10:42:07 Thiago Macieira wrote:
>> On Thursday, 9 de February de 2012 10.07.16, Jedrzej Nowacki wrote:
>> > Hi,
>> >
>> > Does anybody know why we have separation between QMetaTypeId and
>> >
>> > QMetaTypeId2 classes?
>>
>> Becaus
> From: "kai.koe...@nokia.com"
>> -Original Message-
>> From: Beck Wolfgang (Nokia-MP/Brisbane)
>> I think this was a very good idea so I've tried it but I've run into one
>> important
>> problem.
>> If I use this trick I have to call the overloaded function in QMessageLogger:
>> e.g.
>>
- Original Message -
> From: "kai.koe...@nokia.com"
> To: wolfgang.b...@nokia.com; development@qt-project.org
> Cc:
> Sent: Tuesday, February 7, 2012 2:26 AM
> Subject: Re: [Development] QLog ( Work on qDebug and friends)
>
> Hi Wolfgang,
>
> how about making the category a distinct typ
> From: David Faure
> To: development@qt-project.org; Diego Iastrubni
> Cc:
> Sent: Sunday, February 5, 2012 5:54 PM
> Subject: Re: [Development] Work on qDebug and friends
>
> On Sunday 05 February 2012 10:50:48 BRM wrote:
>> > From: Diego Iastrubni
>> &
> From: Diego Iastrubni
>On Fri, Feb 3, 2012 at 1:10 PM, David Faure wrote:
>
>Once this goes in I'll add support for %pid%, %processname% and %timestamp%,
>>and we'll be all set :)
>
>You meant %threadid% of course... right?
Wouldn't having both available be useful?
Ben
> From: David Faure
> On Friday 03 February 2012 10:51:50 kai.koe...@nokia.com wrote:
>> Finally I came around to actually implement something:
>>
>> http://codereview.qt-project.org/#change,15129
>>
>> The idea is that you can customize the output by setting the
>> QT_DEBUG_PATTERN environm
- Original Message -
> From: "wolfgang.b...@nokia.com"
> To: robin...@viroteck.net; david.fa...@kdab.com
> Cc: development@qt-project.org
> Sent: Thursday, February 2, 2012 6:00 PM
> Subject: Re: [Development] QLog ( Work on qDebug and friends)
>
> I think we can change the current QLog.
,
> whatever else) can be left to an external library. I think the
> _gathering_ of all that data (as an extension to qDebug) does belong in
> core, of course, but I think we should not go towards setting up a whole
> complicated output mechamism now.
+1 agreed.
> I think you a
> From: David Faure
> On Wednesday 01 February 2012 10:02:00 BRM wrote:
>> I would also suggest that the plugins use a standard public interface class
>> such as QAbstractLogFacility, like QTcpSocket uses QAbstractSocket - so
>> that people can add their own cust
Getting caught up again...
- Original Message -
> From: Lincoln Ramsay
> On 01/31/2012 05:08 PM, ext Jordi Pujol wrote:
>> - Crazy idea : allow logging to a socket ? ( remote log/debug )
>> - More than one logging file ? One file for every category / group of
>> categories
>> - Log
Sorry, I'm a little late to the conversation - got behind a bit...
> From: Thiago Macieira
>On Monday, 30 de January de 2012 16.32.38, Olivier Goffart wrote:
>> On Monday 30 January 2012 16:13:48 Thiago Macieira wrote:
>> > We definitely want:
>> > - the language support library (chapter 18)
>>
> From: David Faure
>To: craig.sc...@csiro.au
>Cc: development@qt-project.org
>Sent: Monday, December 19, 2011 3:40 AM
>Subject: Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version
>
>On Saturday 17 December 2011 09:01:35 craig.sc...@csiro.au wrote:
>> On 16/12/2011, at 10:37 P
81 matches
Mail list logo
