Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

Olivier Goffart schreef op 20-2-2015 om 12:32: > On Friday 20 February 2015 11:15:32 BogDan wrote: >> I fully agree with you, but, sadly, I think it will not be possible in 5.x. > We started supporting C++98 during the course of Qt 4.x. > We dropped MSVC 6, in Qt 4.5 (despite there was still people

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

Olivier Goffart schreef op 20-2-2015 om 11:38: > On Friday 20 February 2015 11:26:31 Daniel Teske wrote: > [...] >> That's one area. The others are too replace trivial interfaces with a low >> amount of virtual functions by a std::function properties. This can simplify >> code if e.g. the different

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

Bo Thorsen schreef op 20-2-2015 om 09:03: > Andrés question about how this would change the API is a lot more > interesting. I so far haven't seen a single case where someone has > described how access to lambdas might improve the API. If they are > there, I'd love to see them, because maybe thi

Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

Daniel Teske schreef op 19-2-2015 om 13:29: > Hi, > > Standard C++ is evolving in a unprecedented pace at the moment. Both C++11 and > C++14 added a lot of new good features. C++17 is planned to be a big step > again. > > Qt needs to evolve together with C++ or it will be a outdated toolkit stuck i

Re: [Development] JSON 64 bit int

Marc Mutz schreef op 11-2-2015 om 16:11: > On Wednesday 11 February 2015 14:04:59 Bo Thorsen wrote: >> Den 11-02-2015 kl. 13:27 skrev Giuseppe D'Angelo: >>> On 11 February 2015 at 12:12, Bo Thorsen wrote: It's so easy to say we just follow the standard. But I have two current projects wh

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

Marc Mutz schreef op 10-2-2015 om 14:19: > On Tuesday 10 February 2015 13:05:32 Olivier Goffart wrote: >> I think using a QMap is fine in most case. > Sorry, no. > > I know you don't believe me. Maybe you believe your own eyes: > > https://www.youtube.com/watch?v=ApLLVY6MZaI&list=PLHxtyCq_WDLXFAEA-

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

Mathias Hasselmann schreef op 8-2-2015 om 22:28: Am 08.02.2015 um 14:28 schrieb Marc Mutz: c. Using QMap. As Alex Stepanov put it: every use of a map should be discussed in a face-to-face meeting with your manager. Since we don't have that, I'd change this to: Everyone wishing to use

Re: [Development] Deprecating modules with 5.5

Knoll Lars schreef op 5-2-2015 om 16:28: > But we don’t have much of a choice, if we want to deliver an up to date > web engine. Perhaps it is time to ask the question then: do we want to do that? Do we really need to? It seems to me, that it isn't really possible to do. Not in a way that doesn'

Re: [Development] Deprecating modules with 5.5

Knoll Lars schreef op 3-2-2015 om 10:51: > > So Qt 5.6 can drop mingw support? > There are currently no plans in dropping mingw. But webengine is currently > not supported on that compiler. > So I guess that does mean that it will no longer be Tier 1 then. André _

Re: [Development] RFC: Improved Q_ENUM

Dmitry Volosnykh schreef op 16-12-2014 09:35: While I cannot come up with direct application of toString() feature in the projects I am involved in by the moment (except for debugging), I really like it, and remember myself being in a need in such features some time ago. So, me also would like

Re: [Development] The dark side of QtMultimedia

Thiago Macieira schreef op 17-11-2014 01:48: > Why do you want to render video non-fullscreen anyway on a device with > a small screen? Once the user clicks the play button, go to full > screen with rotation support. What a short-sighted comment. I really respect you, but this comment really mi

Re: [Development] The dark side of QtMultimedia

Cristian Adam schreef op 11-11-2014 13:43: On Tue, Nov 11, 2014 at 1:29 PM, Gianluca > wrote: Dear Lars, I'm using Qt from more than 10 years, and I like so much the Qt library that I always want to contribute in some way. I cannot afford at the moment

Re: [Development] The dark side of QtMultimedia

Gianluca schreef op 11-11-2014 13:29: > > Dear Lars, > I’m using Qt from more than 10 years, and I like so much the Qt library that > I always want to contribute in some way. I cannot afford at the moment to put > myself in working at the Qt code, so often I think to buy a commercial > license o

Re: [Development] Is QMap Broken

Tomasz Siekierda schreef op 6-11-2014 09:10: > To store 2 items at a single position in list/ vector, you can use > QPair, like this: QLIst >() Better yet, just use a struct then. QPair in my experience results in badly readable code. Who will ever remember down the line what was first, and what

Re: [Development] QConfig update.

Thiago Macieira schreef op 16-10-2014 09:17: > On Thursday 16 October 2014 08:51:52 André Somers wrote: >> Exactly the same way moc already parses header files now? My idea was to >> explore if it were possible to build on what moc already can do. You >> might have noticed

Re: [Development] QConfig update.

Thiago Macieira schreef op 15-10-2014 17:34: > I'm not sure you got my meaning. How is a config editor tool in Qt > Creator going to read & write those files? Why would you need a tool like that for such a format? > How is the code generator going to read the QTypedSettings source > header to ge

Re: [Development] QConfig update.

Milian Wolff schreef op 14-10-2014 18:35: > >> QConfig and QConfigGroup *does not* support setting a default value on the >> getter, I know that this is used in a lot of places but this can cause >> inconsistencies: >> >> Main.cpp >> >> QConfig c; >> c.value("window-width", 800); >> >> MainWindow.c

Re: [Development] QSettings refactor updates

Thiago Macieira schreef op 11-10-2014 10:25: > On Friday 10 October 2014 21:27:58 Tomaz Canabrava wrote: >> I tougth about having a changed() signal on the QConfig / QConfigGroup >> classes, is the QConfigWatcher a better approach? > Put it in a separate class. QConfig (Group) should not be a QObje

Re: [Development] QSettings refactor updates

Milian Wolff schreef op 11-10-2014 16:44: > On Friday 10 October 2014 21:26:11 Tomaz Canabrava wrote: >> On Fri, Oct 10, 2014 at 6:35 AM, Milian Wolff wrote: >>> On Friday 10 October 2014 06:22:12 Tomaz Canabrava wrote: Em 10/10/2014 06:18, "Oswald Buddenhagen" < oswald.buddenha...@

Re: [Development] New company name for Qt part of Digia and unified web site

> Op 17 sep. 2014 om 18:05 heeft Thiago Macieira > het volgende geschreven: > >> On Wednesday 17 September 2014 14:06:15 André Somers wrote: >> Absolutely. FOSS users have, by definition, every right to modify the >> source code. So yes, the current qt.io si

Re: [Development] New company name for Qt part of Digia and unified web site

Milian Wolff schreef op 17-9-2014 13:46: True. But do we agree that saying FOSS users don't have the "full rights to modify source codes" is wrong, or at least misleading? I guess so, considering you say "That's*also* nonsense" (emphasis mine). Absolutely. FOSS users have, by definition, every r

Re: [Development] New company name for Qt part of Digia and unified web site

Milian Wolff schreef op 17-9-2014 12:38: > On Tuesday 16 September 2014 12:11:26 Knoll Lars wrote: >> Hi everybody, >> >> I’m happy to tell you that we’re making significant progress towards the >> new unified web page that I’ve first been talking about at the contributor >> summit. We just launche

Re: [Development] [Interest] Direct-lookup translation, even for English (was Re: get english translation)

Thiago Macieira schreef op 4-9-2014 20:59: > On Thursday 04 September 2014 20:31:49 Andre Somers wrote: >> That sounds rather short-sighted to me. >> It means that an inconsistency is introduced for no good reason at all. >> If you want to have something that works for English only, it would be >>

Re: [Development] [Interest] Direct-lookup translation, even for English (was Re: get english translation)

Kobus Jaroslaw schreef op 3-9-2014 08:25: >> Actually, some of the i18n features of Qt _requires_ you to provide an >> English translation. >> This is the case for the plural forms, where the engineer typically writes. >> tr("Found %n item(s)", 0, m_numberOfItemsFound); >> And Qt will pick the sin

Re: [Development] QStorageInfo

Knoll Lars schreef op 29-8-2014 13:17: > But let's also add things in order. Local vs remote seems to be the > use case that most people need so let's solve that first. Other > attributes can be added later. Cheers, Lars I did not mean to suggest that this all be added right now. I was just wo

Re: [Development] QStorageInfo

Bo Thorsen schreef op 29-8-2014 13:29: > Den 29-08-2014 12:46, André Somers skrev: >> Thiago Macieira schreef op 29-8-2014 06:32: >>> Could be, but I want to be really clear that it should only be local, >>> remote and unknown. I don't want other types like &quo

Re: [Development] QStorageInfo

Иван Комиссаров schreef op 29-8-2014 13:01: > Иван Комиссаров > > 29 авг. 2014 г., в 14:46, André Somers написал(а): > > Thiago Macieira schreef op 29-8-2014 06:32: >>> Could be, but I want to be really clear that it should only be local, >>> remote and unkno

Re: [Development] QStorageInfo

Thiago Macieira schreef op 29-8-2014 06:32: > Could be, but I want to be really clear that it should only be local, > remote and unknown. I don't want other types like "removable > magnetic", "removable optical", "removable solid state", "virtual > regular filesystem", "virtual special", etc. J

Re: [Development] QStorageInfo

Thiago Macieira schreef op 25-8-2014 17:09: > On Monday 25 August 2014 13:46:12 André Somers wrote: >> ?? schreef op 25-8-2014 13:24: >>> Can you provide an usecase why you need this feature? >> Sure. In our product, we support having the user choose wher

Re: [Development] QStorageInfo

?? schreef op 25-8-2014 13:24: Can you provide an usecase why you need this feature? Sure. In our product, we support having the user choose where to put his database. However, we only support doing that on a local file system, as experience has shown us that using our database sys

Re: [Development] QOptional

André Somers schreef op 21-8-2014 16:33: > Thiago Macieira schreef op 21-8-2014 16:14: >> I'd like to deprecate QVariant's internal >> nullability concept and make it rely on carrying a QOptional for a type to be >> null. >> >> If we don't

Re: [Development] QOptional

Thiago Macieira schreef op 21-8-2014 16:14: > On Thursday 21 August 2014 11:15:01 Julien Blanc wrote: >> Do you mean that you would change QSqlRecord::value to return, instead >> of a QVariant that can be null, a QVariant holding either an optional or >> a non-optional object ? I don’t see any adva

Re: [Development] New class for QtWidgets: ColumnResizer

Saether Jan-Arve schreef op 15-6-2014 01:17: > With the above caveats in mind, I am therefore wondering if it isn't a better > API to either strictly limit it to QGroupBox+QFormLayout hierarchies or > create a separate QWidget subclass that ensures this. > That would make it much less useful, IMH

Re: [Development] New class for QtWidgets: ColumnResizer

Ziller Eike schreef op 13-6-2014 09:51: > On Jun 12, 2014, at 6:51 PM, Oswald Buddenhagen > wrote: > >> On Thu, Jun 12, 2014 at 04:08:17PM +0200, Aurélien Gâteau wrote: >>> Olivier Goffart wrote: But just wondering if it would not be better to have that as an API within QGridLayout such

Re: [Development] Request for a sandbox area: Replicant

Stottlemyer, Brett (B.S.) schreef op 31-5-2014 00:57: > > I'd like to officially request a sandbox for: Replicant > > What is it? > Replicant is a Qt library for Inter Process Communication (IPC). It is meant > as an alternate to QtDBus, but with a very different usa

Re: [Development] Qmake Ninja generator

Thiago Macieira schreef op 19-5-2014 18:20: > Em seg 19 maio 2014, às 17:01:05, André Somers escreveu: >> Adam Strzelecki schreef op 19-5-2014 12:38: >>>> I would recommend using CMake - it has a stable Ninja generator, which >>>> _does_ make building Qt proje

Re: [Development] Qmake Ninja generator

Adam Strzelecki schreef op 19-5-2014 12:38: >> I would recommend using CMake - it has a stable Ninja generator, which >> _does_ make building Qt projects much faster on Windows. > I wonder if can CMake build Qt SDK itself? > > It is somehow parallel to Qmake, isn't it. If so, would it make sense to

Re: [Development] Adding support for version number comparisons

Keith Gardner schreef op 14-5-2014 15:45: Well, if you use a virtual, you'd simply subclass to handle the specific format for your project. I haven't thought about using inheritance to simplify the compare but I think that would provide the best compromise. What are your thoughts abo

Re: [Development] Adding support for version number comparisons

Keith Gardner schreef op 14-5-2014 14:28: I think that makes sense, but it would be nice if it would be easy for the user of the class to extend the version checking himself for non-numerical sections of the version string. That could be done in several ways I think, for instanc

Re: [Development] Adding support for version number comparisons

Keith Gardner schreef op 13-5-2014 22:31: imo, the cases which are fully under the user's control (internal version checking) should be handled solely numerically (even without considering any pre-releases), which basically means a minimalistic semver(-like) implementation which

Re: [Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]

Simon Hausmann schreef op 30-4-2014 11:36: > On Wednesday 30. April 2014 11.19.45 André Somers wrote: >> Simon Hausmann schreef op 30-4-2014 10:51: >>>> - objects can be put in the context in c++ >>> Ah, setContextProperty? Yeah, we could warn against that.

Re: [Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]

Simon Hausmann schreef op 30-4-2014 10:51: > >> - objects can be put in the context in c++ > Ah, setContextProperty? Yeah, we could warn against that. > Could you, or somebody else, elaborate a bit on why this is bad practice? To my (admittedly naive) eyes, it seems like a good and simple way, av

Re: [Development] Question about Qt's future

Hartmann Thomas schreef op 28-4-2014 11:32: > Hi, > > yes, writting C++ inline in QML would be another "tooling nightmare". Also > what is the problem with: > > MouseArea { > onClicked: companion.mouseAreaClicked(); > } > > If tooling creates the companion object for you (In a wizard) and cod

Re: [Development] Question about Qt's future

Olivier Goffart schreef op 22-4-2014 13:01: > On Tuesday 22 April 2014 12:20:58 Oswald Buddenhagen wrote: >> On Mon, Apr 21, 2014 at 02:52:25PM +0200, Roland Winklmeier wrote: >>> If I want to access this methods from QML I would have to derive them >>> from QObject and register it in the QML conte

Re: [Development] Harmonizing the Qt 5.x Documentation

Thomas McGuire schreef op 3-4-2014 10:47: > Hi, > > On Thursday 03 April 2014 08:02:16 Rutledge Shawn wrote: >> On 2 Apr 2014, at 6:07 PM, Ariel Molina wrote: >>> The current state of Qt docs is very sad, making online searches near to >>> useless. All Google searches refer either to broken pages,

Re: [Development] One 'qt' branch to rule 'em all!

Diego Iastrubni schreef op 1-4-2014 14:17: > I agree. > > As we move to a more linear development cycle, we can finally drop > git and update to svn, "where we are going we don't need branches" > anyway. I'd actually like to suggest an upgrade to CSV then. André _

Re: [Development] About ALIAS in Q_PROPERTY

Svetkin Mikhail schreef op 11-3-2014 04:12: Explain: I was creating custom widgets with the help of Qt-designer. And I have noticed I have to duplicate my code, if I want to edit properties of the widget in qt-designer property editor. Simple Example: I'm not a fan. You end up with a QProperty

Re: [Development] Binary Compatibility question (KDE)

Tony Van Eerd schreef op 27-2-2014 21:06: > Sorry, there is probably a KDE email list or something that I should post > this to, but I know it is very closely related to Qt: > > On http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B > there is: > > You cannot... > > - For ex

Re: [Development] Remove OSX 10.6 Build?

Hi, > Op 20 jan. 2014 om 17:36 heeft Kurt Pattyn het > volgende geschreven: > > The CI system is still building for OSX 10.6. > Given the fact that OSX is at version 10.9 now, shouldn’t the build for 10.6 > be removed, and ideally replaced with a build for OSX 10.9? Why should it be one to the

Re: [Development] Coding style proposal

Poenitz Andre schreef op 3-1-2014 12:33: > André Somers wrote: >> Poenitz Andre schreef op 2-1-2014 23:49: >>> Jiergir Ogoerg wrote: >>>> Ironically, not even the IDE (QtCreator) sorts them out, in my example >>>> parse...() is the 1st in the list, and lo

Re: [Development] Coding style proposal

Poenitz Andre schreef op 2-1-2014 23:49: > Jiergir Ogoerg wrote: >> Ironically, not even the IDE (QtCreator) sorts them out, in my example >> parse...() is the 1st in the list, and locale() is the last one (16th). > There's a "Sort alphabetically" check box in the context menu of > whatever-that-co

Re: [Development] Weird offseting in QDataStream

Andreas Aardal Hanssen schreef op 8-11-2013 13:28: On 08 Nov 2013, at 12:41, Yves Bailly > wrote: ]I would recommend against using QDataStream for anything else than reading back what was written using QDataStream. This is what I called a step backward. It's jus

Re: [Development] Weird offseting in QDataStream

Eskil Abrahamsen Blomfeldt schreef op 8-11-2013 11:20: > > QDataStream supports reading and writing floats and doubles, but it > might use more bytes than necessary to represent them in the stream. > > The main use case of QDataStream is to serialize Qt data in a portable, > binary form with the co

Re: [Development] Weird offseting in QDataStream

Olivier Goffart schreef op 8-11-2013 10:57: > On Friday 08 November 2013 10:42:16 Yves Bailly wrote: > >> I can understand this for high-level Qt objects, but what about lower-level >> data? Does this mean I can't use QDataStream to read a file written by >> some other program, and/or can't use it

Re: [Development] Weird offseting in QDataStream

Yves Bailly schreef op 8-11-2013 10:42: > Le 08/11/2013 10:29, Christian Ehrlicher a écrit : >> Am 08.11.2013 10:15, schrieb Yves Bailly: >>> Le 08/11/2013 10:05, Giuseppe D'Angelo a écrit : On 8 November 2013 10:01, Yves Bailly wrote: > As a float is 4 bytes, I would expect the second f.

Re: [Development] Weird offseting in QDataStream

Christian Ehrlicher schreef op 8-11-2013 10:29: Am 08.11.2013 10:15, schrieb Yves Bailly: Le 08/11/2013 10:05, Giuseppe D'Angelo a écrit : On 8 November 2013 10:01, Yves Bailly wrote: As a float is 4 bytes, I would expect the second f.pos() to display "4"... but it displays "8", as if QDataSt

Re: [Development] async operation error guidance

Frank Osterfeld schreef op 5-11-2013 17:41: > On Nov 5, 2013, at 5:12 PM, Tony Van Eerd wrote: > >> Most of BlackBerry's APIs are async. >> We are looking at moving some of these APIs into Qt. >> Just as one example, WiFi Direct. >> >> I have been attempting to come up with some solid guidelines o

Re: [Development] Disabling exception support in QtCore?

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, Olivier Goffart wrote: I dislike allowing this via the signal-slot mechanism because I see throwing from a slot as incompatible wi

Re: [Development] QtTest for everybody

Op 7-10-2013 21:27, Thiago Macieira schreef: > On segunda-feira, 7 de outubro de 2013 22:50:49, Dmitry Ashkadov wrote: >> The topic about exceptions for slots and signals has inspirited me to >> pay your attention to QtTest. QtTest is a good unit-test framework, but >> it is focused to Qt. I think

Re: [Development] [RFC] What to do about overloaded signals/slots?

Hi, > Op 5 okt. 2013 om 20:47 heeft Olivier Goffart het > volgende geschreven: > > > There is the same problem if one use pointer to member function in > QtConcurrent[1] or in other third party API (boost::bind) > Which means adding an overload can be a source incompatible change regardless

Re: [Development] [RFC] What to do about overloaded signals/slots?

> Op 5 okt. 2013 om 18:24 heeft Olivier Goffart het > volgende geschreven: > > I would also like to remind that adding overloads to functions is not source > compatible, as it may break a connection using the function poitner syntax. > Overloaded signals and slots should be avoided. > Well,

Re: [Development] Heads up: QtAlgorithms to be deprecated in 5.2

Op 13-9-2013 22:16, Giuseppe D'Angelo schreef: > Hello, > > https://codereview.qt-project.org/#change,43441 (currently waiting for > a review) is going to mark most of the QtAlgorithms functions as > deprecated. > > The decision about this has already happened some time ago: > http://www.mail-arc

Re: [Development] A QtCore class for event-driven jobs

Op 11-9-2013 17:19, David Faure schreef: >> Couldn't such a class be part of the hopefully coming QtConcurrent >> replacement? > Can we forget about threads for a second? No, I'd rather not forget that huge pink elephant in the room... In this age of multi-core systems being the norm rather than e

Re: [Development] Making QScopedPointer scoped (again)

Op 5-9-2013 7:55, Olivier Goffart schreef: > On Wednesday 04 September 2013 18:45:45 Alexandr Akulich wrote: >> Hi all. >> >> Im totally agree with Stephen, because such change definitely complicate >> source reading. >> When one read "ScopedPointer", then one naturally expect that stored object >>

Re: [Development] Making QScopedPointer scoped (again)

Op 3-9-2013 11:31, Oswald Buddenhagen schreef: > On Tue, Sep 03, 2013 at 10:02:52AM +0200, Stephen Kelly wrote: >> Again, this is what std::unique_ptr is for. We should not try to turn >> QScopedPointer into an attempt at a NIH std::unique_ptr. Where people have a >> need for a std::unique_ptr, the

Re: [Development] Qt for iOS - iOSStyle

Op 13-3-2013 18:43, Bache-Wiig Jens schreef: Exactly. Being able to do pixel perfect layouts within the Qt Quick designer is one of the arguments against an IOS QStyle implementation. I would like to be able to see and run my apps _exactly_ as they would look on the device, without having to

Re: [Development] [Qt-interest] QMultiHash

Op 7-3-2013 10:24, pengliang(??) schreef: Hi All QMultiHashhh; I need to find some key and change their values. I found If I use QmutableHashIteratorit , its bool *findNext *( const T &/value/) Its parameter is a value, not a key. So I need to : While(it.hasNext()) { It.next(

Re: [Development] Evolving Qt's multithreading API

Op 5-3-2013 8:41, Thiago Macieira schreef: > On terça-feira, 5 de março de 2013 08.38.17, André Somers wrote: >> I'd appreciate a reply on the point that when using a QFutureWatcher, >> you don't know if the future is already done or not at the moment you >&g

Re: [Development] Evolving Qt's multithreading API

Op 4-3-2013 23:56, Thiago Macieira schreef: > On segunda-feira, 4 de março de 2013 14.49.15, Thiago Macieira wrote: >>> I think the proposed API addition is actually quite natural. It is not >>> without precedent (QTimer::singleShot()), and would result in quite >>> simple, readable code. >> I disa

Re: [Development] Evolving Qt's multithreading API

Op 4-3-2013 16:17, Sze Howe Koh schreef: > On 2 March 2013 18:17, Andre Somers wrote: >> Actually, how do you feel about adding an optional _then_ argument to >> the list of arguments of the functions in QtConcurrent and whatever is >> decided to replace the QtConcurrent::run feature? Such a _then

Re: [Development] QtDriveInfo module in Playground

Op 1-3-2013 11:52, Konstantin Ritt schreef: > 2013/3/1 André Somers : >> Op 1-3-2013 10:22, Иван Комиссаров schreef: >> >> I don't think it's a good idea to try to fix QStorageInfo. >> >> The main argument is that QStorageInfo is a monitor+info provider

Re: [Development] QtDriveInfo module in Playground

Op 1-3-2013 10:22, ?? schreef: I don't think it's a good idea to try to fix QStorageInfo. The main argument is that QStorageInfo is a monitor+info provider, but monitor should depend on a DBus in Linux; however info provider doesn't require that. Also, monitor requires internal th

Re: [Development] QtDriveInfo module in Playground

Op 1-3-2013 8:38, Иван Комиссаров schreef: > Hello, i would like to request a repository in a playground for my QDriveInfo > module. > > This class allows to retrieve information about a system volumes - like > available size, filesystem, filesystem flags and so on. > > Right now, repo is located

Re: [Development] Evolving Qt's multithreading API

Op 22-2-2013 14:31, Corentin Jabot schreef: >> On second thought, I'm not sure if this would be commonly needed. We >> can make it start immediately instead, BUT this requires a guarantee >> that the first thread can always connect the finished() signal, before >> the new thread runs and finishes.

Re: [Development] Evolving Qt's multithreading API

Op 22-2-2013 11:57, Sze Howe Koh schreef: > On Feb 22, 2013 12:33 AM, "Olivier Goffart" wrote: >> Some more common use case would be (pseudo-code) >> >> auto watcher = new QFutureWatcher; >> QObject::connect(watcher, SIGNAL(finished()), myObject, SLOT(doStuff())); >> watcher->setFuture(QThrerad::r

Re: [Development] Evolving Qt's multithreading API

Op 20-2-2013 15:45, Sze Howe Koh schreef: > Hi all, > > Some time ago there was some talk about improving Qt's multithreading > API. I'm summarizing them here to stop them from fading into > obscurity, and to see if there's any interest in following them up. There is also a proposal posted here: ht

Re: [Development] Qt 5.1 feature set and freeze date

Op 13-2-2013 18:24, Jake Petroules schreef: QtWindowsExtras is something I plan to contribute to heavily. What things would folks like to see in there besides the image conversion functions? I suggested Windows 7 task bar features a little while back, and I believe that there is a Windows count

Re: [Development] QML and QAbstractListModel

Op 14-1-2013 11:07, Alberto Mardegan schreef: > On 01/14/2013 09:29 AM, André Somers wrote: >> I am not fan of this change. I think the API of QAIM is already very >> complex. Adding more methods that basically only sort-of mirror existing >> methods but for a more confined

Re: [Development] QML and QAbstractListModel

Op 10-1-2013 17:46, Alberto Mardegan schreef: > Hi all! > I'd like to make C++ models more usable from QML; in the net there > are several blog posts illustrating how to achieve that, but IMHO it > would be better if at least some of these handy features were in > QAbstractListModel itself: > >

Re: [Development] Non-movable Qt build

Op 2-1-2013 13:42, Thiago Macieira schreef: > On quarta-feira, 2 de janeiro de 2013 10.53.03, Yves Bailly wrote: >> Does anyone knows where I could find the source code of the "official" >> installer, or at least some information about what it does? Because the >> installer does relocate the binari

Re: [Development] QtQuick1 (Qt4 and Qt5)

Op 26-12-2012 23:33, Alan Alpert schreef: > On Wed, Dec 26, 2012 at 11:58 AM, Thiago Macieira > wrote: >> On quarta-feira, 26 de dezembro de 2012 20.38.58, Alberto Mardegan wrote: >>> Hi all! >>> I've a few API additions to propose to the QML FolderListModel class, >>> which is present in thre

Re: [Development] QAction-like API for QML

Op 20-12-2012 12:11, Shawn Rutledge schreef: > So ultimately at that company all the abstract actions you would have > wanted to create would still have to be converted into gui-oriented > actions anyway, right? How would you avoid writing code to bridge or > augment them into actions which can

Re: [Development] QAction-like API for QML

Op 20-12-2012 11:40, Shawn Rutledge schreef: > On 19 December 2012 09:13, André Somers wrote: >> Well, I disagree with that view of what an action represents. To me, the >> core of an action really is bundling a bit of state with a trigger for >> something to happen (I

Re: [Development] QAction-like API for QML

Op 20-12-2012 11:10, Bache-Wiig Jens schreef: >>> I find the idea of adding a new QCoreAction base class that is shared >>> between QML Action and QAction and only carries a small subset of >>> properties an unnecessary layer of abstraction. The idea of QAction is to >>> have the convenience of

Re: [Development] Integrating QAction and the upcoming QML Action (was QAction-like API for QML)

Op 19-12-2012 12:46, Stephen Kelly schreef: > On Wednesday, December 19, 2012 08:57:31 André Somers wrote: > >> My preference is D, obviously. I think it makes a lot of sense to be >> able to use actions in core, non-GUI layers of the application. > Qt is primarily for creati

Re: [Development] QAction-like API for QML

Op 19-12-2012 11:52, Rutledge Shawn schreef: > On 19 Dec 2012, at 9:13 AM, André Somers wrote: > >> Op 14-12-2012 8:45, Bache-Wiig Jens schreef: >>> What I would propose is that we keep the QAction exactly as it is and make >>> it possible to use it from QML as we

Re: [Development] QAction-like API for QML

Op 14-12-2012 8:45, Bache-Wiig Jens schreef: > I have been lurking in the discussion a bit but I guess it is time for me to > pitch in. It is hard to keep up with 10 different threads at once. :) > > I find the idea of adding a new QCoreAction base class that is shared between > QML Action and QA

Re: [Development] Read binary file

Op 19-12-2012 8:54, Yuriy Rusinov schreef: > Dear colleagues ! > > I have to read binary file via Qt. In console application I make > > I think you'd be better of asking this in inter...@qt-project.org. This list is about the development *of* Qt itself, not the development *with* Qt. André _

Re: [Development] Integrating QAction and the upcoming QML Action (was QAction-like API for QML)

Op 18-12-2012 20:34, Shawn Rutledge schreef: > On 18 December 2012 20:05, Mark wrote: >> On Tue, Dec 18, 2012 at 6:46 PM, Alan Alpert <4163654...@gmail.com> wrote: >>> D) QCoreAction is added to Core or Gui and has even less >>> functionality, QQuickAction and QAction/QGuiAction build on top of >>

Re: [Development] If you're waiting for reviews from me...

Op 19-12-2012 0:18, Marc Mutz schreef: > ... please cut me some slack while I handle the attached non-maskable > interrupt :) > Oh dear, you're in for a long-term project indeed! Congrats! André ___ Development mailing list Development@qt-project.org ht

Re: [Development] [Qt-creator] gerrit-speak

Op 14-12-2012 9:30, Koehne Kai schreef: >> -Original Message- >> From: development-bounces+kai.koehne=digia@qt-project.org >> [mailto:development-bounces+kai.koehne=digia@qt-project.org] On >> Behalf Of Donald Carr >> Sent: Thursday, December 13, 2012 10:16 PM >> To: Jenssen Tim >>

Re: [Development] QAction-like API for QML

Op 11-12-2012 21:59, Alan Alpert schreef: > On Tue, Dec 11, 2012 at 10:49 AM, Shawn Rutledge > wrote: >> On Tue, Dec 11, 2012 at 09:48:22AM -0800, Alan Alpert wrote: >>> Why can't this be QML-only? For the set of controls exposed in >>> C++-only we have a C++-only Action API. When we add a set of

Re: [Development] Settings API for QML

Op 11-12-2012 16:37, Bache-Wiig Jens schreef: >> To get the discussion going, here's my suggestion for that API: >> PersistentSettings >> { >> property bool loadOnStartup: true >> property bool saveOnExit: true >> function load() >> function save() >> } > I would also consider an ev

Re: [Development] QAction-like API for QML

Op 11-12-2012 4:39, Alan Alpert schreef: > QAction served widgets well as an abstraction for an "Action" which is > exposed to the UI in a platform specific manner. This was shared > between menus and toolbars and some other things. I think we'll need > something similar for QML, so that the QtQuic

Re: [Development] New mailing list: web_AT_qt-project.org created

Hi, Op 26-11-2012 12:12, Verma Gurudutt schreef: Hi I am really happy to inform you all that new mailing list web_AT_qt-project.org is created now. We will be discussing open governance model of web development related stuffs for qt-project.org here and proposal for this was made few days

Re: [Development] Proposing new mailing list: qt-l...@qt-project.org

Op 20-11-2012 16:04, Tanilkan Sinan schreef: > Hi, > > I would like to propose that we establish the mailing list: > qt-l...@qt-project.org, to take over for the previous qt-l10n list. > > We believe there are people who are interested in localization, that do not > follow the developer mailing l

Re: [Development] Common base class for all socket types

Op 6-11-2012 10:26, d3fault schreef: > "a common base class is an interesting idea. But it’s a moot point > since we have to maintain binary compatibility until Qt 5. So > QAbstractSocket cannot change. We’ll revisit the issue when Qt 5 > development starts, but that’s a long way in the future". (

Re: [Development] Proposal: Time to decide what security policy the Qt Project will use (not Trolltech/Nokia/Digia)

Op 25-10-2012 9:18, d3fault schreef: < a big re-itteration of yet the same arguments> Indeed, time for a conclusion. Oh wait: Lars already gave that conclusion: http://lists.qt-project.org/pipermail/development/2012-October/007511.html Sorry that the conclusion doesn't match your ideas of the ide

Re: [Development] RFC: Qt Security Policy

Op 19-10-2012 3:50, slfj sfjie schreef: Also, the guy didn't even disagree with me. He pretty much reiterated the first post and said absolutely nothing. You disagreed with me for a little bit (CVE/Mitre), but getting around those problems is trivial by setting up a security-priv...@qt-proje

Re: [Development] highlight/background colour of active tabs

Op 18-10-2012 19:36, Randolph D. schreef: > Hello > > in the tab widget several tabs have a background colour of dark-grey > and the active forground tab has the background colour of light-grey. > > This is misleading, as all apps with a mainframe have the colour of > light grey, so the active ta

<    1   2   3   4   >