Re: [Development] Nominating Sona Kurazyan as maintainer of qt5compat

+1 from me. Her help and support on Qt Remote Objects has been great. Brett ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development

[Development] Request: feature branch for Qt Remote Objects

Hi, I’ve been trying to use Gerrit tags for developing a large feature in [QtRO]( topic:"serialization" (status:open OR status:merged) (repo:qt/qtremoteobjects) ). However, the changes are getting larger, and it is getting hard to review new vs old changes between patchsets. In addition, I’m

Re: [Development] State of "binary JSON" in 5.15+?

On 4/15/21, 3:45 PM, "Development on behalf of Elvis Stansvik" wrote: With the risk of muddling things even more, but the way I understood > Think geographic data, where I can prefetch at low-priority, and load/process data on-demand as location changes. was that his use case was:

Re: [Development] State of "binary JSON" in 5.15+?

Apologies if this was already sent, I meant to send yesterday and found it in a still open window. On 4/14/21, 12:53 AM, "Development on behalf of Thiago Macieira" wrote: No, that was it. I assume you're caching templates which you need to modify slightly for each reply, not

Re: [Development] State of "binary JSON" in 5.15+?

On 4/13/21, 5:23 PM, "Development on behalf of Thiago Macieira" wrote: Are you sure you can't just use a memory cache? Your requirement sounds that your JSON snippet is small enough that it will not hit the 128 MB limit any time soon but large enough that reparsing it is not

Re: [Development] State of "binary JSON" in 5.15+?

On Tuesday, 13 April 2021 07:29:48 PDT Lars Knoll wrote: The binary JSON support is deprecated and only there for backwards compatibility. It had some issues (e.g. it couldn’t handle large JSON files), that’s why we deprecated it. It’s gone in Qt 6. I guess the docs need some

[Development] State of "binary JSON" in 5.15+?

Hi, I was at the Contributor’s Summit where it was discussed, so I know there were good reasons to deprecate the binary json format. The actual changes looks to have been done in https://codereview.qt-project.org/c/qt/qtbase/+/265312. IIUC, the original intent was that parsing the JSON

Re: [Development] QProperty and library coding guide

On 7/24/20, 11:09 AM, "Development on behalf of Thiago Macieira" wrote: ... what QProperty really is: sub-scope of a class. We don't want a different this pointer, we just want to scope. Is QProperty really a sub-scope? Many of the examples are not tied to objects (QObject or

Re: [Development] QProperty and when evaluation occurs

Hi Arno, On 7/23/20, 4:14 PM, "Arno Rehn" wrote: I think much of the confusion stems from the fact that you can get notifications (i.e. callbacks) without evaluating the whole binding. From what I grok from the code, you can subscribe to "dirty" flag changes with

Re: [Development] QProperty and when evaluation occurs

Hi Volker, On 7/23/20, 3:13 PM, "Volker Hilsheimer" wrote: But why would we calculate the volume if nobody cares about the volume? :) Qt Remote Objects. I've got a headless service on one device, and a remote UI for interacting with it. When signals are emitted (property change or

Re: [Development] QProperty and when evaluation occurs

Hi Thiago, On 7/23/20, 4:54 PM, "Development on behalf of Thiago Macieira" wrote: If a property is connected to a slot that doesn't support lazy evaluation, then the entire chain must be re-evaluated as soon as any of the properties is marked dirty. QProperty needs to do that

[Development] QProperty and when evaluation occurs

Hi, I'm still trying to wrap my head around this concept, and starting a new thread to distinguish from the technical implementation discussion. The two obvious cases: * Immediate evaluation. This is the current signal-based handling (ignoring queued for the moment). * Evaluate-on-Read (EoR).

Re: [Development] QProperty and library coding guide

Hi Ulf, > QProperty's main feature is accepting lazily evaluated bindings in place of a plain value. It can also notify eagerly if you use the subscribe() and onValueChanged() methods, but you'd usually avoid that as best as you can. I must be missing something. I tend to think of eventloops

Re: [Development] QProperty and library coding guide

Hi, > item->width.setBinding([]() { return otherItem->height(); }); ... > item->widthSetBinding([]() { return otherItem->height(); }); ... > See the definition of Q_PRIVATE_QPROPERTY for the different methods we generate into the structs. It sounds like there are two overlapping elements to

Re: [Development] QProperty and library coding guide

Hi Ulf, > QProperty is the way to enable QML-style bindings in C++. It gives you a > powerful way of expressing relations between properties in a succinct > way. You can assign a binding functor directly to a QProperty. Any > QProperties the functor accesses are automatically recorded. Whenever >

Re: [Development] Switch the main "Qt Build System"

Hi Alexandru, Thanks for the quick reply. On 6/8/20, 12:09 PM, "Alexandru Croitor" wrote: The current CMake configurations can be found in qt5.git/coin/platform_configs/qtsvg.yaml (and many other .yaml files there, it's just copy-pasted). Ahh, I didn't understand what these module

Re: [Development] Switch the main "Qt Build System"

Hi Alexandru, On 6/8/20, 9:45 AM, "Development on behalf of Alexandru Croitor" wrote: The CMake ports are built in Coin with the most important configurations (Linux, Windows, macOS, Android, iOS, qemu Linux). Are the "official" cmake configs for CI in the qt5 git repo yet

Re: [Development] Metatype system in Qt6

Apologies for reviving an old thread, but this just came up in a code review (https://codereview.qt-project.org/c/qt/qtremoteobjects/+/287828 if anyone is curious). On 12/5/19, 11:56 AM, "Development on behalf of Olivier Goffart" wrote: That's a source incompatible change, and the

[Development] How do you build dev/qt6?

Building HEAD for qtbase, qtdeclarative and qtremoteobjects is failing to compile. At this point in time, I’m getting an error in building qtdeclarative: /code/qt6/qtdeclarative/src/quick/scenegraph/util/qsgplaintexture.cpp:50:11: fatal error: 'QtGui/private/qopengltextureuploader_p.h' file

Re: [Development] Request a new branch for Qt Creator

On 8/6/19, 1:49 PM, "André Pönitz" wrote: .. by now I think we can simply side step this issue of finding a name for a branch, as I think we shouldn't have a branch to start with. Fair enough, we will target master. Regards, Brett ___

Re: [Development] Request a new branch for Qt Creator

On 8/5/19, 3:03 PM, "Tor Arne Vestbø" wrote: This sounds a bit like a standalone tool? Or one that wouldn’t necessarily need to be in the Qt Creator repository? Can you expand a bit on why a branch is needed? There is a standalone component (that can be deployed to an embedded

Re: [Development] Request a new branch for Qt Creator

Before I address André's specific questions, let me add a little more context. We have a few plugins for QtC that were developed with KDAB starting about 5 years ago with the development of Qt Remote Objects. We've actually had several developers from The Qt Company reviewing the code outside

[Development] Request a new branch for Qt Creator

Hi, I’d like to request a new branch (“acme”) on QtCreator. The too short version: ACME is a simulation tool, allowing you to create a project that can run in QtCreator and quickly implement interfaces (e.g., DBus, QtRemoteObjects, etc) to feed other components. You can directly edit

Re: [Development] Deprecation/removal model going into Qt 6

On 6/2/19, 12:02 PM, "Stottlemyer, Brett (B.S.)" wrote: This discussion reminds me of Python 2 vs. Python 3, and I think there are some important lessons to consider from Python. FYI, I know Qt has been through version updates as well, and Qt 4 -> Qt 5 was not that long ago.

Re: [Development] Deprecation/removal model going into Qt 6

On 6/1/19, 9:10 AM, "Development on behalf of Philippe" wrote: I second a recent quote from Lars Knoll : > Qt has always had a somewhat different philosophy. Make C++ easy to use, > no need to use Java. The fact is that 95% of the source code our users >write will not be

[Development] Issues (temporary) with gerrit and code.qt.io

Hi all, Passing this one for general awareness. I've been hit by https://bugreports.qt.io/browse/QTQAINFRA-2980. The referenced issue is closed but with a note "I assume it will take awhile to finish." The symptoms, as I understand it, are that various mirrors are not current. I was able

Re: [Development] Qt online SDK security problems

On 4/18/19, 5:51 AM, "Development on behalf of André Pönitz" wrote: There is no latest *and* safest version of any non-trivial code base that's under active feature development no matter what Google, Microsoft, Apple, ("long time ago" Nokia) say. ... When you mix

Re: [Development] Nominating Brett Stottlemeyer for Approver status

I'm the maintainer for QtRO (per the wiki page) already. But I only have +2 rights on the remote objects module, none of the others (which I didn't realize until later was unusual). Thanks for the nomination (and votes). If approved, I'll certainly treat the

Re: [Development] Change ANGLE 3rd party source from Google to Microsoft

On 8/3/18, 5:06 AM, "Development on behalf of Oliver Wolff" wrote: Hi, Is everyone ok with this change? The ANGLE update from Google (which uses a revision that still supports MSVC 2015) would be ready (https://codereview.qt-project.org/#/c/233385/), but we would like to

[Development] QtCS 2018 - Qt Remote Objects session

I’ve posted notes from the session: https://wiki.qt.io/QtCS2018_RemoteObjects Thanks to everyone who participated, and feel free to update if you see anything I missed. Regards, Brett ___ Development mailing list Development@qt-project.org

Re: [Development] Repository Request: qt/licensing

On Wednesday, May 23, 2018 9:43 AM Thiago Macieira wrote: > On Wednesday, 23 May 2018 10:31:17 -03 Kai Koehne wrote: > > Well, the whole point of the exercise is to allow customers to > > configure Qt under commercial terms from git, so any non-shared git module > > doesn't help. > > You can

Re: [Development] Repository Request: qt/licensing

On 5/18/18, 10:36 AM, "Development on behalf of Kai Koehne" wrote: Hi, I'd like to request the creation of a repository "qt/licensing" on codereview.qt-project.org. This will become an optional

Re: [Development] How to run QtBase autotests on a remote machine?

On 4/12/18, 2:07 AM, "Development on behalf of Maurice Kalinowski" wrote: > > > Some tests shall need more than the binary; e.g. data files to act on. > > > [Kalinowski Maurice] > Check for testdata

[Development] Module "" () : on QtRemoteObjects

Hi list, I saw some traffic on QtBase showing the above error staging from Gerrit (which I thought was fixed). I'm seeing the same thing on the Qt Remote Objects module. Is this expected? Is there anything trick other than retry? The specific change is

Re: [Development] When will Qt Remote Objects become an official Qt module?

On 7/18/17, 11:09 AM, "Development on behalf of Vincent Hui" wrote: > I plan to use Qt Remote Objects in my project. Therefore, I would like to > know when Qt Remote Objects will become an official Qt

Re: [Development] Proposal for Qt 5.10 platforms and configurations changes

> Please refer to Qt 5.9 Supported platforms -> > http://doc-snapshots.qt.io/qt5-5.9/supported-platforms.html That page has the following for QNX: “QNX 6.6.0, 7.0 (armv7le and x86)” As QNX 7.0 includes 64-bit support, are aarch64le and x86_64 supported on 5.9? If not, can they be added for

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

nt] Focusing bug fixes to 5.9 branch and patch releases during H1/17 On Tue, Apr 11, 2017, at 06:16 PM, Stottlemyer, Brett (B.S.) wrote: > On Tuesday, April 11, 2017 11:14 AM, Simon Hausmann wrote: > > I think that what you are asking for is reasonable. I think the set of > >

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

On Tuesday, April 11, 2017 11:14 AM, Simon Hausmann wrote: > I think that what you are asking for is reasonable. I think the set of sha1s > of qt5.git satisfy that requirement to the best of the project's ability. In this case I think they do not, based on all of the commits to the 5.8 branches

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

> On 4/11/17, 9:49 AM, "Development on behalf of Tuukka Turunen" > wrote: > Now that there are no patch releases planned, the benefit from pushing to 5.8 > then merging to 5.9 does not exist. I feel there should always be a stable HEAD that you can push a fix to and

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

> On 4/11/17, 7:36 AM, "Development on behalf of Tuukka Turunen" > wrote: > every fix that would have been part of 5.8.1 and more – a lot more. The reason for pushing to the 5.8 branch is because it *is* stable. And since it has "... a lot more", the 5.9 branch is not

Re: [Development] Wishes for C++ standard or compilers

On 3/20/17, 7:02 AM, "Development on behalf of Olivier Goffart" wrote: > >It's true that you cannot serialize a type if you don't have some > persistent >identifier such as the name. This has

Re: [Development] Request moving project (noron) to playground area

> On 2/24/17, 9:29 AM, "André Hartmann" wrote: > >Hi Brett, > > Have a look at http://doc-snapshots.qt.io/ Didn’t even know that was there. I was excited for a moment, but for some reason QtRO isn’t included in the TP section.

Re: [Development] Request moving project (noron) to playground area

> On 2/24/17, 4:05 AM, "Hamed Masafi" wrote: > > Hi Hi Hamed > I'd seen Qt Remote Objects. But is has not any document. I read wiki > and some information and compiled source and examples. I hope Berrit > add some information. I imagine QtRO evolved like most

Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

On 1/22/17, 10:51 AM, "Simon Hausmann" wrote: >Hi, > >I have scheduled a new build of the current master branch against qt's dev >branch: > >http://testresults.qt.io/coin/integration/playground/qtremoteobjects/tasks/web_playground_qtremoteobjects_1485097792522 > > >5 out

Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

On 1/13/17, 3:22 AM, "Simon Hausmann" wrote: >I scheduled a test build in the CI against 5.8 (as dev continues to be broken). What are the implications for feature freeze if dev is still broken? >There are few issues: > >1) namespaced build doesn't work Fixed >2)

Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

On 1/18/17, 1:52 AM, "Tuukka Turunen" wrote: >> > >When QtRO becomes part of Qt, would you continue as the maintainer of the >module and have adequate time to polish it so that it can be fully supported >in the upcoming Qt releases? > >Yours, > > Tuukka Sure,

Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

On 1/16/17, 10:14 AM, "Development on behalf of Oswald Buddenhagen" wrote: >of course, it may be that this task is too complex to get right, in >which case qt bindings for specific systems are a more

Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

On 1/13/17, 10:09 AM, "Development on behalf of Oswald Buddenhagen" wrote: >for my taste, there are way too many inconclusive/irrelevant details in >this description. a more layer-oriented approach

Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

On 12 January 2017 at 08:39, Lars Knoll wrote: >From the discussion so far I didn't hear too many things that speak against a >TP, the code duplication with moc is one of the issues that fall into the >'flagged and need to be resolved before moving out of TP' category for me. How >about the

Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

On 1/11/17, 11:50 AM, "Development on behalf of Oswald Buddenhagen" wrote: >> >but my naive understanding of rpc implementations is that you actually >> >want to create some idl (is this what .rep is

Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

On 1/11/17, 4:43 AM, "m...@kdab.com on behalf of Marc Mutz" <m...@kdab.com on behalf of marc.m...@kdab.com> wrote: >Hi Brett, > >On Wednesday 11 January 2017 01:42:38 Stottlemyer, Brett (B.S.) wrote: >> With this picture in mind, the key to getting it to work

Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

On 1/10/17, 7:42 PM, "Stottlemyer, Brett (B.S.)" <bstot...@ford.com> wrote: >On 1/10/17, 7:11 AM, "Development on behalf of Oswald Buddenhagen" ><development-bounces+bstottle=ford@qt-project.org on behalf of >oswald.buddenha...@qt.io> wrote: &g

Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

On 1/10/17, 7:11 AM, "Development on behalf of Oswald Buddenhagen" <development-bounces+bstottle=ford@qt-project.org on behalf of oswald.buddenha...@qt.io> wrote: >On Tue, Jan 10, 2017 at 01:42:12AM +, Stottlemyer, Brett (B.S.) wrote: >> The processin

Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

On 1/9/17, 10:54 AM, "Development on behalf of Oswald Buddenhagen" wrote: >i had a quick look at the repo: >- there is still copy of moc's c++ parser in there. not much to do about > it at this

[Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

As the maintainer for the Qt Remote Objects (QtRO) playground project, I would like to officially request moving it from a playground project to a Qt project. For now (Qt 5.9), I’d like to keep it as a Tech Preview, as there are some elements of the API we would still like to extend, and we’d

Re: [Development] QDataStream: blackbox or document all versions?

On 9/24/16, 11:58 PM, "Development on behalf of Thiago Macieira" wrote: >A thread[1] on the interest mailing list started when someone asked for the >docs for the current format of the QDataStream

Re: [Development] Which changes are suitable for 5.6?

On 9/7/16, 4:26 AM, "Development on behalf of Olivier Goffart" wrote: >But in the end, we want our users to upgrade. So they >can reconsider the reason they cannot upgrade while weighing the new features/

Re: [Development] commas in ctor-init-lists

On 6/1/16, 5:27 PM, "Development on behalf of Marc Mutz" wrote: ... >Semicolons and commas are visually *designed* to be >trailing. And consequently every C++ text book uses trailing commas. The pros that

Re: [Development] Qt Coding Guidelines

On 3/17/16, 6:24 AM, "Development on behalf of Mathias Hasselmann" wrote: > >Actually having the Qt code style as public document proved to be >extremely useful in the past to quickly shutdown this

[Development] API Change in QtRemoteObjects

Hello, For those of you using the QtRemoteObjects playground module (QtRO for short), some changes went in over the holidays that changed the public API. So you will need to update your code when you update to any version of master past 16959709b59db45c07385ecc13b76061de851edf (or see the

Re: [Development] [QtCS] QtRemoteObjects Session Summary

Hi Alan. Hi Simon. On 6/10/15, 4:23 PM, Alan Alpert 4163654...@gmail.com wrote: On Wed, Jun 10, 2015 at 6:52 AM, Simon Hausmann simon.hausm...@theqtcompany.com wrote: On Tuesday, June 09, 2015 01:23:29 PM Alan Alpert wrote: A brief overview of planned features: -QML API -Protocol Layer

Re: [Development] QtRemoteObjects - POD types derive from QObject

On Monday, February 16, 2015 1:25 PM Roland Winklmeier wrote: a while ago the QtRemoteObjects project was started in the playground area. I had followed the discussions closely, because I'm running a project which has a perfect use case for QtRemoteObjects. I haven't had much time to look into

Re: [Development] QtRemoteObjects (was Replicant)

On Wednesday, October 22, 2014 6:17 AM Simon Hausmann wrote: On Tuesday 21. October 2014 12.56.41 Stottlemyer, Brett wrote: Again, I like the idea of remote objects working outside of Qt. Yes, protocol buffers are self-describing, but that is because there is a template. You haven't solved

Re: [Development] QtRemoteObjects (was Replicant)

On Monday, October 20, 2014 6:45 AM Simon Hausmann wrote: I wasn't trying to suggest using protocol buffers as a wholesale replacement for MOC generated code. I was thinking only of the piece for marshalling Properties and Signal arguments for QueuedConnection calls, and the return value.

Re: [Development] QtRemoteObjects (was Replicant)

On Monday, October 20, 2014 7:49 AM Branislav Katreniak wrote: What about removing the hard dependency of type safe replicas on the rep language and rep compiler? Can we extend moc compiler? In theory, yes. When we write the server objects, we already have the QObject with all the

Re: [Development] QtRemoteObjects (was Replicant)

On Tuesday, October 21, 2014 8:19 AM Simon Hausmann wrote: The QTime is literally the result of string copypaste from the token in the header file into the moc generated C++ code. There's no type lookup, resolution or analysis involved :) But that's the point, isn't it? The type itself

Re: [Development] QtRemoteObjects (was Replicant)

On Monday, October 20, 2014 2:32 AM Simon Hausmann wrote: So what would a .proto file look like for a Q_OBJECT? That's not evident to me yet. However a .proto file could be written (manually) that describes the messages needed to allow calling into QObjects. Basically a schema for what

Re: [Development] QtRemoteObjects (was Replicant)

On Sunday, October 19, 2014 10:12 AM Simon Hausmann wrote: I'm very fond of the idea of Qt making it very easy to talk to other applications living in other processes on potentially other machines (devices). Me too ;-) I think if we want to address this in Qt, then we should take three

Re: [Development] QtRemoteObjects (was Replicant)

On Friday 17 October 2014 11:31:10 Sumedha Widyadharma wrote: Do you think it would be possible to use run-time introspection à la QtWebChannel and dynamic signals/slots to get rid of the pre-processor? (see: http://doc.qt.digia.com/qq/qq16-dynamicqobject.html) I can't speak to

[Development] QtRemoteObjects (was Replicant)

Qt Devs, I know I've been silent for a while after the discussing Replicant and QQSM at the Qt Contributors Summit. If you aren't aware, QQSM was renamed to DSM (Declarative State Machine) and has been incorporated into QML. It is already merged and will be released with Qt 5.4. The 2nd

Re: [Development] Qt6, Qt7 roadmap?

*- ?? Cross-process signals/slots (pretty please? ;-)) Take a look at Replicant. QtRemoteObjects (a.k.a. Replicant) hasn't been pushed anywhere public yet. Ossi established the playground, but I'm still making some changes before I push it. Brett

Re: [Development] Semantics of QState when state machine execution is stopped

Kevin Funk wrote: I presume that changing the semantics here (i.e. triggering QAbstractState::onExited when the machine is stopped) isn't appropriate, as it may break existing applications, but I'm not exactly sure. I think it would be far less risk of breaking existing applications to

Re: [Development] Request for sandbox area: QQSM

Volker Krause wrote: Based on the suggestions we got at QtCS we would like to try to get QQSM directly into qtdeclarative. Yes, that was the consensus at QtCS, which sounds perfect to me. BTW, since QQSM (Qt QML State Machine) is kind of icky to say, I've started warming to DSM (for

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

Thiago wrote (in a different thread): I think the answer is pretty clear: because there are 10 other RPC solutions and this needs to be harmonised. And, to be honest, a Qt-only solution is not the most ideal. I think we should use an RPC that is available in other toolkits. Oswald wrote

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

Are you aware of QxtRPCService as well? http://libqxt.bitbucket.org/doc/0.6/qxtrpcservice.html André, Nope. Didn't know about that one. It is Signals only, not Properties and Slots as well, though. Thanks! Brett ___ Development mailing list

Re: [Development] Request for sandbox area: QQSM

Oswald wrote: this sounds wrong to me. why would you need a sandbox, i.e., something isolated, when it's pretty clear that this is one of the key missing features of qml/quick? you should aim at bringing this into the qtdeclarative repository, possibly directly into one of the

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

I am *HUGELY* interested in this.  We do lots of IPC, and across physical devices, and his design issues really hit home for us.  Part of the reason for our interest is we've implemented similar things, and the design-approach-overlap is uncanny.  (That's a CAN bus joke.) … This is

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

This cross process stuff is starting to feel like 1996 and remote procedure RPC calls, now using QT signals and slots. drool again for effect. One could review the history of microsoft and the fine RPC mechanisms that turned out to be mostly unusable, or maybe just unused. Keep the

[Development] Request for sandbox area: QQSM

Hi list, My name is Brett Stottlemyer. I work for Ford Motor Company, and Ford has graciously agreed to let us contribute some of the cool stuff we've developed back to Qt. We aren't quite done with everything yet (still waiting on the Corporate CLA), but I will be at Qt Contributors Summit

[Development] Request for a sandbox area: Replicant

Hi list, My name is Brett Stottlemyer, here with my 2nd sandbox request. I work for Ford Motor Company, and Ford has graciously agreed to let us contribute some of the cool stuff we've developed back to Qt. We aren't quite done with everything yet (still waiting on the Corporate CLA), but I

Re: [Development] Request for sandbox area: QQSM

Welcome to the community. Thanks! I just have a question: does QQSM build on top of the QStateMachine framework, or does it replace completely? If the latter, is there any plan to integrate them again? Hi Thiago. Sorry I wasn't clear. This uses the QStateMachine framework directly.

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

Sorry for the formatting guys. Corporate email is Outlook, so I'm manually trying to be polite and bottom post. Hello Brett Hi Thiago I again support the creation of the repository. We'll have to discuss whether this can become part of the Qt standard release because of the overlap in