Re: [Development] Request: devcontainer feature for vscodeext

Not necessarily. The Feature (devcontainer-feature.json, install.sh, and NOTES.md) could be part of the vscodeext repo and published to GitHub Container Registry using the devcontainers cli or GitHub Action. Or it could be in its own separate repository if you prefer, in which case you would likely

Re: [Development] Request: devcontainer feature for vscodeext

I think for single repo projects devcontainers work really nice to get all dependencies and tools in place. There are two usecases for the devcontainers: 1. User projects (as OP's approach) This would build and install the full qt6 stack. This could be useful if the user wants to test and build

Re: [Development] Request: devcontainer feature for vscodeext

On 1/27/25 18:07, Alex Shaw wrote: Is anyone interested in seeing this officially added to Qt? That seems interesting. Do I understand correctly that the devcontainer spec [1] would go into a repo different from vsccodeext? And vscodeext would merely announce its existence? Cheers, Joerg

[Development] Request: devcontainer feature for vscodeext

Hello. I recently discovered that Qt has an official plugin (or plugins) for Visual Studio Code. Is there any interest in adding a Devcontainer Feature to go with it? For those who don't know, devcontainers are an open specification for configuring virtual containers to use as development hosts. G

Re: [Development] Request for early MOC support for C++20 Modules

Am 16.12.2023 um 09:21 schrieb apoenitz: I haven't tried yet, but I have the gut feeling that one should be able to get away with Seems your gut feeling is right. Did a little experiment[1], and ended up with this: class MyObject :public Object { M_OBJECT public: using Object::

Re: [Development] Request for early MOC support for C++20 Modules

On Monday, 18 December 2023 07:54:07 -03 Giuseppe D'Angelo via Development wrote: > If anything I think this discussion ties up with the one about the > future of moc, and whether it should become a compiler plugin. In > principle this would bypass the problem of parsing the binary module > format

Re: [Development] Request for early MOC support for C++20 Modules

Il 15/12/23 21:33, Thiago Macieira ha scritto: Is the file format for the imported modules already standardised? Is it in the C++ standard? I don't remember seeing it there. If it's not a standard (ISO C++ standard or otherwise), we'd need to write format parsers for each compiler, which raises

Re: [Development] Request for early MOC support for C++20 Modules

On Fri, Dec 15, 2023 at 04:25:43PM +, Volker Hilsheimer via Development wrote: > > On 15 Dec 2023, at 16:19, Sune Vuorela wrote: > > > > On 2023-12-15, Elias Steurer via Development > > wrote: > >> No, I still need all the get/set/notify functions to change/get the > >> variables from the o

Re: [Development] Request for early MOC support for C++20 Modules

On Friday, 15 December 2023 11:07:44 -03 Fabian Kosmale via Development wrote: > 1. moc's parsing logic needs to learn about the relevant new keywords. moc > needs to know at the very least the module (partition)'s name. Please forgive my lack of knowledge on this and asking of very basic questio

Re: [Development] Request for early MOC support for C++20 Modules

> On 15 Dec 2023, at 16:19, Sune Vuorela wrote: > > On 2023-12-15, Elias Steurer via Development > wrote: >> No, I still need all the get/set/notify functions to change/get the >> variables from the outside. There is currently no way to do that, or am >> I missing something? Something like thi

Re: [Development] Request for early MOC support for C++20 Modules

On 2023-12-15, Elias Steurer via Development wrote: > No, I still need all the get/set/notify functions to change/get the > variables from the outside. There is currently no way to do that, or am > I missing something? Something like this > https://gitlab.com/kelteseth/ScreenPlay/-/blob/master/

Re: [Development] Request for early MOC support for C++20 Modules

x27;s not a blocker for getting support for the "easy" parts in. Fabian Von: Development im Auftrag von Elias Steurer via Development Gesendet: Freitag, 15. Dezember 2023 14:36 An:development@qt-project.org Betreff: [Development] Request for early MOC s

Re: [Development] Request for early MOC support for C++20 Modules

Von: Development im Auftrag von Elias Steurer via Development Gesendet: Freitag, 15. Dezember 2023 14:36 An: development@qt-project.org Betreff: [Development] Request for early MOC support for C++20 Modules Hi Devs, I'd like to ask about a possib

Re: [Development] Request for early MOC support for C++20 Modules

Hi, > On a related note, when moving a class to modules, it would be handy to > have a way to skip the 'Generate Missing Q_PROPERTY Members' boilerplate > code. My current classes are mostly 50% getter/setter boilerplate, and > in my opinion, this is only manageable because we split our code into

[Development] Request for early MOC support for C++20 Modules

Hi Devs, I'd like to ask about a possible roadmap update regarding C++20 modules support in moc. There was a discussion a while ago about C++20/23 support for Qt (https://lists.qt-project.org/pipermail/development/2023-May/043823.html), and I would like to know if there has been any internal

[Development] Request review patch of QQuickImage

Hi, This https://codereview.qt-project.org/c/qt/qtdeclarative/+/446349 patch has been quiet for a long time, anyone else have an opinion on it? I want to continue it. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development

[Development] Request review some patch for QQuickPalette

Hi, I have two patchs about QQuickPalette: https://codereview.qt-project.org/c/qt/qtdeclarative/+/414503 and https://codereview.qt-project.org/c/qt/qtdeclarative/+/415277/7. I submitted them three months ago and added some reviewers, but no response, I can't find someone more suitable to review

Re: [Development] Request for new module, qt/qtgrpc

Yeah, that's fine since it's what the code is originally based on. I should've mentioned :) Mårten From: Volker Hilsheimer Sent: Thursday, October 6, 2022 6:00:08 PM To: Mårten Nordheim ; development@qt-project.org Subject: Re: [Development]

Re: [Development] Request for new module, qt/qtgrpc

+1 FWIW, searching for “qtgrpc” hits https://semlanik.github.io/qtprotobuf/group__QtGrpc.html, which is generated from the sources in https://github.com/semlanik/qtprotobuf - which the readme file documents as “on hold”. Volker > On 5 Oct 2022, at 12:51, Mårten Nordheim via Development >

[Development] Request for new module, qt/qtgrpc

Hello all, As part of an ongoing effort, I'd like to request a new module, 'QtGrpc', under the 'qt/' space. It is meant to provide protobuf and gRPC support, with a generator extension to generate code which uses Qt code directly. It will initially be Tech Preview. Responsible person: Alex Bl

Re: [Development] Request qtquickdesigner-components as Qt 6 addon

On 2022 May 5, at 16:23, Thomas Hartmann mailto:thomas.hartm...@qt.io>> wrote: Hi, I would like to request the inclusion of a new module to Qt 6 as an add-on: Name of the repository: qt-labs/qtquickdesigner-components Description: Module for Qt Design Studio specific QML items Responsible pers

[Development] Request qtquickdesigner-components as Qt 6 addon

Hi, I would like to request the inclusion of a new module to Qt 6 as an add-on: Name of the repository: qt-labs/qtquickdesigner-components Description: Module for Qt Design Studio specific QML items Responsible person: Thomas Hartmann Gerrit user/email: thomas.hartm...@qt.io

[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] Request to rename module qtscxml to qtstatemachine

hort term before the FF. -- Karsten From: Development On Behalf Of Karsten Heimrich Sent: Thursday, January 21, 2021 10:50 AM To: development@qt-project.org Subject: [Development] Request to rename module qtscxml to qtstatemachine Hi, with Qt6 we removed the QtStateMachine implementation from qt

Re: [Development] Request moving project to playground area

Sorry about pursuing an old thread. but I want to know what you think of this old proposal. Over the years, Nott has had many improvements: - Macro mechanisms are removed and what remains is much like writing a normal classroom. - Many of the problems that have been resolved and used for our compa

Re: [Development] Request to rename module qtscxml to qtstatemachine

with Qt6 we removed the QtStateMachine implementation  from qtbase and moved it into qtscxml. While the name was ok when the module contained only SCXML releated code, it contains now both state machine implementations. Hence I would like to propose/request to rename the module to qtstatemachin

Re: [Development] Request to rename module qtscxml to qtstatemachine

+1 The new name reflects the content of the module much better. Regards Jarek From: Development on behalf of Edward Welbourne Sent: Thursday, January 21, 2021 11:14 AM To: Karsten Heimrich Cc: development@qt-project.org Subject: Re: [Development

Re: [Development] Request to rename module qtscxml to qtstatemachine

> On 21 Jan 2021, at 11:14, Edward Welbourne wrote: > > Karsten Heimrich (21 January 2021 10:49) wrote: >> [...] I would like to propose/request to rename the module to >> qtstatemachine to reflect the widened code base. Jira task: >> QTBUG-89837 > > Sounds like a more accessible name to me - I

Re: [Development] Request to rename module qtscxml to qtstatemachine

Karsten Heimrich (21 January 2021 10:49) wrote: > [...] I would like to propose/request to rename the module to > qtstatemachine to reflect the widened code base. Jira task: > QTBUG-89837 Sounds like a more accessible name to me - I'd have had to look up SCXML to find out what it means, where the

[Development] Request to rename module qtscxml to qtstatemachine

Hi, with Qt6 we removed the QtStateMachine implementation from qtbase and moved it into qtscxml. While the name was ok when the module contained only SCXML releated code, it contains now both state machine implementations. Hence I would like to propose/request to rename the module to qtstatema

Re: [Development] Request to move qt-labs/qhttpserver out of qt-labs

it as a > main part of Qt though. > > > Sent: Monday, February 03, 2020 at 9:29 AM > > From: "Volker Hilsheimer" > > To: "Mikhail Svetkin" > > Cc: "development@qt-project.org" > > Subject: Re: [Development] Request to mo

Re: [Development] Request to move qt-labs/qhttpserver out of qt-labs

to see it as a main part of Qt though. > Sent: Monday, February 03, 2020 at 9:29 AM > From: "Volker Hilsheimer" > To: "Mikhail Svetkin" > Cc: "development@qt-project.org" > Subject: Re: [Development] Request to move qt-labs/qhttpserver out of q

Re: [Development] Request to move qt-labs/qhttpserver out of qt-labs

> On 3 Feb 2020, at 08:15, Mikhail Svetkin wrote: > > Hello, > > I would like to make request to move qthttpserver from qt-labs namespace to a > new namespace qt-addons or qt-extensions. > > The main reason is that it is not a research project anymore. I believe that > the module is ready to

Re: [Development] Request to move qt-labs/qhttpserver out of qt-labs

Mikhail Svetkin (3 February 2020 08:15) proposed: > I would like to make request to move qthttpserver from qt-labs > namespace to a new namespace qt-addons or qt-extensions. > > The main reason is that it is not a research project anymore. I > believe that the module is ready to become a self conta

[Development] Request to move qt-labs/qhttpserver out of qt-labs

Hello, I would like to make request to move qthttpserver from qt-labs namespace to a new namespace qt-addons or qt-extensions. The main reason is that it is not a research project anymore. I believe that the module is ready to become a self contained library as part of Qt Project and a good examp

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

On Tuesday, 6 August 2019 10:48:36 PDT André Pönitz wrote: > For me, 'ACME' probably will always trigger 'ACME Corporation' as in > https://en.wikipedia.org/wiki/Acme_Corporation, but .. I think of my friend acme, maintainer of the Linux perf tool. http://vger.kernel.org/~acme/perf/ https://git.k

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 ___ Deve

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

On Mon, Aug 05, 2019 at 11:48:54PM +, Stottlemyer, Brett (B.S.) wrote: > 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'

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

On Monday, 5 August 2019 16:57:35 PDT Stottlemyer, Brett (B.S.) wrote: > 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?

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 tar

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 o

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

> On 5 Aug 2019, at 12:35, Stottlemyer, Brett (B.S.) wrote: > > 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., > DBu

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

On Mon, Aug 05, 2019 at 10:35:37AM +, Stottlemyer, Brett (B.S.) wrote: > Hi, Hi Brett. > I’d like to request a new branch (“acme”) on QtCreator. Would it be possible to use a less overloaded name? After a bit of search I think I get now what it refers to, but it surely was not my first gu

[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 propert

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

Until the link is added, you can visit the direct URL http://doc-snapshots.qt.io/qt5-5.9/qtremoteobjects-index.html ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development

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

> Date: Fri, 24 Feb 2017 14:30:20 + > From: "Stottlemyer, Brett (B.S.)" > To: Qt development mailing list > Subject: Re: [Development] Request moving project (noron) to > playground area > Message-ID: <186aed03-a598-4668-a6d7-1686b796c...@ford.com> &

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. http://doc-snapshots.qt.io/qt5-5.9/qtmodules.html#technol

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

Hi Brett, Am 24.02.2017 um 15:08 schrieb Stottlemyer, Brett (B.S.): 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.

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 projects, with code precedi

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

Hi 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. Overlas (as I understand) - Share a QObject on server and clients can be access Differences: Noron can serv an object per peer On Thu

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

Yes, please have a look at Qt Remote Objects, which has been a playground project for a while. Brett is currently working on upgrading this to a Technology Preview module for Qt. Before doing anything else with this module it’ll be good to understand what the overlap and differences between thos

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

Greetings Good idea (: it would be great to have RPC integrated into Qt... There was a similar project (Qt Remote Objects was the name if I'm not mistaken). Don't know the details, seems they are planning to provide a transparent remote API around Qt's Signal/Slot mechanism... You may want to hav

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

Project name: Noron Project description: This tool implements remote object sharing (Object Oriented RPC) in Qt. >From a technical point of view, it can compare with Java RMI or similar technologies. Noron has an advanced signaling mechanism. A property change on a peer (server or client) will imm

Re: [Development] Request moving project to playground area

> To achieve this I think it's possible to use the property system + a custom > subclass > of QObject. If you watnt to expose this objects to QML you will need to > declare a > Q_PROPERTY, so It's not convenient. Nut macro declare a static method to helping query writing as descripted in github

Re: [Development] Request moving project to playground area

On Saturday, February 04, 2017 07:05:41 AM Hamed Masafi wrote: > Why not using Q_PROPERTY instead of NUT_DECLARE_FIELD? > > A property im table is more thsn a just Qt property, that macro create > property and static field for query writing and class info about property > to add to database. To a

Re: [Development] Request moving project to playground area

Why not using Q_PROPERTY instead of NUT_DECLARE_FIELD? A property im table is more thsn a just Qt property, that macro create property and static field for query writing and class info about property to add to database. And what's the reason to have a constructor as Q_INVOKABLE? Andre right abou

Re: [Development] Request moving project to playground area

03.02.2017, 01:07, "Milian Wolff" : > On Donnerstag, 2. Februar 2017 20:38:00 CET Hamed Masafi wrote: >>  Project Name: Nut (currently renamed to ORM) >> >>  Description: ORM is a project aimed to help users working with databases. >>  Developer will write his/her own classes and ORM will generat

Re: [Development] Request moving project to playground area

Op 03/02/2017 om 10:18 schreef Jesus Fernandez: On Thursday, February 02, 2017 07:38:00 PM Hamed Masafi wrote: Declaring persistant objects in ORM is straightforward: class Comment : public Table { Q_OBJECT NUT_PRIMARY_AUTO_INCREMENT(id) NUT_DECLARE_FIELD

Re: [Development] Request moving project to playground area

On Thursday, February 02, 2017 07:38:00 PM Hamed Masafi wrote: > Declaring persistant objects in ORM is straightforward: > > class Comment : public Table > { > Q_OBJECT > > NUT_PRIMARY_AUTO_INCREMENT(id) > NUT_DECLARE_FIELD(int, id, id, setId) > NUT_DECLARE

Re: [Development] Request moving project to playground area

> What are the advantages of NUT/ORM over existing, proven technologies like > ODB? Odb is other than QtSql module, but Nut use Qt so is familiar to Qt developers. Odb has own compiler for pre-compiler declaratives and is hard to use for beginners. But Nut use macro hack and no need another tool fo

Re: [Development] Request moving project to playground area

Hamed Masafi wrote: > This project currently... : > - has code name 'Nut' and suggested name is ORM. But it may have any > other name. ORM is way too generic a name. It needs to be called at least QORM or QtORM or ORM-Qt or something, if you cannot think of a more original name. (But the name

Re: [Development] Request moving project to playground area

On Donnerstag, 2. Februar 2017 20:38:00 CET Hamed Masafi wrote: > Project Name: Nut (currently renamed to ORM) > > Description: ORM is a project aimed to help users working with databases. > Developer will write his/her own classes and ORM will generates database > schema and corresponding tables.

[Development] Request moving project to playground area

Project Name: Nut (currently renamed to ORM) Description: ORM is a project aimed to help users working with databases. Developer will write his/her own classes and ORM will generates database schema and corresponding tables. ORM can generate database migration code (create, drop and alter table an

[Development] Request for a new project to handle sf2 (soundfont) libraries

I apologize in advance for sending a duplicate to the wrong list. My email client mangled the address. I hope I have the proper list now. Hello, I have developed a library based on Qt that handles sf2 (soundfont) libraries. It is moderately well developed at this point, so I would like to intro

Re: [Development] Request for a new playground project

And then “backend” is awfully vague, could be anything other than application UI. (QPA is a kind of backend, so is ODBC.) Yes it’s a buzzword, but will it sound too dated or even more vague in 10 years? > On 15 Feb 2016, at 07:30, Petroules Jake > wrote: > > Drop the "mobile". Qt is a cross

Re: [Development] Request for a new playground project

Drop the "mobile". Qt is a cross platform project and there does not seem to be any technical reason to restrict this to mobile platforms. So, just "Backend as a Service". On Feb 14, 2016, at 3:54 AM, Guillaume Charbonnier mailto:gcharbonn...@simplisim.net>> wrote: Hi all ! Following my last

Re: [Development] Request for a new playground project

Hi all ! Following my last message regarding Qt new module for "Mobile Backend as a Service », what is the procedure to follow for creating a Qt playground project ? My project is in a very early phase, it can only support REST api of Firebase for now but I felt it could help to mutualize our e

Re: [Development] Request for a new playground project

+1 fredag 12 februari 2016 skrev Guillaume Charbonnier < gcharbonn...@simplisim.net>: > Hi all, > > Following engin.io services ramping down notification, Qt mobile > developers (like me) are lacking a MBaaS (mobile backend as a service) > that would play nicely with Qt. > I think this lack could

Re: [Development] Request for a new playground project

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:

Re: [Development] Request for a new playground project

+1 this sounds great - I'm also looking for BaaS with Qt Mobile development Am 12.02.16 um 14:57 schrieb Guillaume Charbonnier: > Hi all, > > Following engin.io services ramping down > notification, Qt mobile developers (like me) are lacking a MBaaS > (mobile backend as a servic

[Development] Request for a new playground project

Hi all, Following engin.io services ramping down notification, Qt mobile developers (like me) are lacking a MBaaS (mobile backend as a service) that would play nicely with Qt. I think this lack could be quite a big impedance for the promotion of Qt for mobile development as

Re: [Development] Request for API freeze exception to fix an important bug

On Freitag, 29. Januar 2016 08:55:54 CET Thiago Macieira wrote: > On Friday 29 January 2016 14:54:59 Andreas Hartmetz wrote: > > So, how to fix it? Simple and (very) ugly: Add API to disable the > > closing of windows in commitData(). Because session saving is IMHO > > pretty important for KDE, I'm

Re: [Development] Request for API freeze exception to fix an important bug

On Friday 29 January 2016 14:54:59 Andreas Hartmetz wrote: > So, how to fix it? Simple and (very) ugly: Add API to disable the > closing of windows in commitData(). Because session saving is IMHO > pretty important for KDE, I'm asking for an exception to add API to 5.6 > to fix it. The API isn't f

[Development] Request for API freeze exception to fix an important bug

Hello, while investigating session saving problems in KDE I found that the big underlying problem is that QGuiApplication::commitData() can't be prevented from trying to close windows. It does that to see if they refuse (ignore the close event), and if they do, it's interpreted as the applicat

Re: [Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

On 07/23/15 06:21, Knoll Lars-san wrote: > On 22/07/15 17:00, > "development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of > Thiago Macieira" > thiago.macie...@intel.com> wrote: > > > >> On Wednesday 22 July 2015 19:17:12 Takao Fujiwara wrote: >>> OK, thanks for the discussion

Re: [Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

On Wednesday 22 July 2015 21:15:18 Knoll Lars wrote: > >I don't see how that is a problem. If that were a problem, you wouldn't be > >able to ship additional, commercial-only modules or allow installation of > >MinGW. So clearly the installer is allowed to install non-Qt things too. > > > >What a

Re: [Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

On 22/07/15 17:00, "development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of Thiago Macieira" wrote: >On Wednesday 22 July 2015 19:17:12 Takao Fujiwara wrote: >> OK, thanks for the discussion and explanation. >> My main concern is the delay of committing the patches from I

Re: [Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

On 22/07/15 16:56, "development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of Thiago Macieira" wrote: >On Wednesday 22 July 2015 07:20:06 Knoll Lars wrote: >> We couldn’t easily ship it in Qt neither for both practical and legal >> reasons. The practical ones are the items

Re: [Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

On Wednesday 22 July 2015 19:17:12 Takao Fujiwara wrote: > OK, thanks for the discussion and explanation. > My main concern is the delay of committing the patches from IBus > contributors. If you would help to speed up the patch integration, it would > be great. I can contribute Qt IBus plugin at t

Re: [Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

On Wednesday 22 July 2015 07:20:06 Knoll Lars wrote: > We couldn’t easily ship it in Qt neither for both practical and legal > reasons. The practical ones are the items Thiago mentioned. The legal > reasons are that we can’t make it part of Qt without being under the CLA, > due to both the KDE Free

Re: [Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

On 22/07/15 12:17, "Takao Fujiwara" wrote: >On 07/22/15 13:49, Thiago Macieira-san wrote: >> On Wednesday 22 July 2015 12:41:11 Takao Fujiwara wrote: >>> On 07/22/15 00:49, Thiago Macieira-san wrote: On Tuesday 21 July 2015 16:00:45 Takao Fujiwara wrote: >> We don't develop gtk. We do de

Re: [Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

On 07/22/15 13:49, Thiago Macieira-san wrote: > On Wednesday 22 July 2015 12:41:11 Takao Fujiwara wrote: >> On 07/22/15 00:49, Thiago Macieira-san wrote: >>> On Tuesday 21 July 2015 16:00:45 Takao Fujiwara wrote: > We don't develop gtk. We do develop Qt4 and we know that supporting > comple

Re: [Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

On 22/07/15 06:49, "Thiago Macieira" wrote: >On Wednesday 22 July 2015 12:41:11 Takao Fujiwara wrote: >> On 07/22/15 00:49, Thiago Macieira-san wrote: >> > On Tuesday 21 July 2015 16:00:45 Takao Fujiwara wrote: >> >>> We don't develop gtk. We do develop Qt4 and we know that supporting >> >>> comp

Re: [Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

On Wednesday 22 July 2015 12:41:11 Takao Fujiwara wrote: > On 07/22/15 00:49, Thiago Macieira-san wrote: > > On Tuesday 21 July 2015 16:00:45 Takao Fujiwara wrote: > >>> We don't develop gtk. We do develop Qt4 and we know that supporting > >>> complex > >>> input methods with it was a pain and it o

Re: [Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

On 07/22/15 00:49, Thiago Macieira-san wrote: > On Tuesday 21 July 2015 16:00:45 Takao Fujiwara wrote: >>> We don't develop gtk. We do develop Qt4 and we know that supporting >>> complex >>> input methods with it was a pain and it often regressed due to lack of >>> testing. I think limiting the tes

Re: [Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

On Tuesday 21 July 2015 16:00:45 Takao Fujiwara wrote: > > We don't develop gtk. We do develop Qt4 and we know that supporting > > complex > > input methods with it was a pain and it often regressed due to lack of > > testing. I think limiting the testing is doing a disservice to our users. > > Ho

Re: [Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

On 21/07/15 09:00, "Takao Fujiwara" wrote: >On 07/21/15 15:07, Thiago Macieira-san wrote: >> On Tuesday 21 July 2015 14:36:19 Takao Fujiwara wrote: * We need at least one input context to use and test against (on Linux) when developing Qt further. Not having the plugin in qtbase wil

Re: [Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

On 07/21/15 15:07, Thiago Macieira-san wrote: > On Tuesday 21 July 2015 14:36:19 Takao Fujiwara wrote: >>> * We need at least one input context to use and test against (on Linux) >>> when developing Qt further. Not having the plugin in qtbase will lead to >>> us not testing IMEs on Linux anymore, s

Re: [Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

On Tuesday 21 July 2015 14:36:19 Takao Fujiwara wrote: > > * We need at least one input context to use and test against (on Linux) > > when developing Qt further. Not having the plugin in qtbase will lead to > > us not testing IMEs on Linux anymore, something I really want to avoid. > > I think you

Re: [Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

On 07/18/15 04:54, Knoll Lars-san wrote: > Can you explain what the advantage of moving it out would be? > > The ibus input context was originally developed by me when we ported from Qt > 4 to Qt 5. I tried to implement it with a minimum set of dependencies. It's > IMO still important to have in

Re: [Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

Can you explain what the advantage of moving it out would be? The ibus input context was originally developed by me when we ported from Qt 4 to Qt 5. I tried to implement it with a minimum set of dependencies. It's IMO still important to have in the qtbase tree for several reasons: * We need at

Re: [Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

On 2015-07-17, Takao Fujiwara wrote: > Right. ibus-qt already has the ibus module for qt4 so this request is for qt5. > I'd think it's easy to move libibusplatforminputcontextplugin.so from qtbase > to ibus-qt. Part of me would like to have as many things that uses QPA headers to stay inside Qt

Re: [Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

On 07/16/15 22:44, Eike Hein-san wrote: > > > On 07/16/2015 03:02 PM, Helio Chissini de Castro wrote: >> Hello Takao >> >> You're talking over Qt 4 only or Qt 5 is affected as well ? >> This is a full replacement of the plugin ? > > The Qt 4 plugin was never in the Qt source tree (afaik). > > The Q

Re: [Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

On 07/16/2015 03:02 PM, Helio Chissini de Castro wrote: > Hello Takao > > You're talking over Qt 4 only or Qt 5 is affected as well ? > This is a full replacement of the plugin ? The Qt 4 plugin was never in the Qt source tree (afaik). The Qt 5 plugin is, and this is upstream asking for it to

Re: [Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

Hello Takao You're talking over Qt 4 only or Qt 5 is affected as well ? This is a full replacement of the plugin ? Regards, Helio On Thu, Jul 16, 2015 at 4:29 AM, Takao Fujiwara wrote: > I maintain IBus project. > https://github.com/ibus/ibus/wiki > > Now I wish to delete qtbase/src/plugins/pl

[Development] Request to delete libibusplatforminputcontextplugin.so from qtbase

I maintain IBus project. https://github.com/ibus/ibus/wiki Now I wish to delete qtbase/src/plugins/platforminputcontexts/ibus and the I will import that module to ibus-qt package, which had been used in qt4. https://github.com/ibus/ibus-qt Thanks, Fujiwara ___

Re: [Development] Request for sandbox area: QQSM

On 23 June 2014 18:21, Stottlemyer, Brett (B.S.) wrote: > As for Replicant, yes we will need have a playground established for that. > > According to > http://qt-project.org/wiki/Creating-a-new-module-or-tool-for-Qt, I need > approval from a Qt Maintainer before I can submit a new Gerrit project.

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 Decla

Re: [Development] Request for sandbox area: QQSM

t; > mailto:bstot...@ford.com>>, > "development@qt-project.org<mailto:development@qt-project.org>" > mailto:development@qt-project.org>> Subject: > Re: [Development] Request for sandbox area: QQSM > > > Hi Brett, > > Thank you for the initiativ

Re: [Development] Request for sandbox area: QQSM

mailto:bstot...@ford.com>>, "development@qt-project.org<mailto:development@qt-project.org>" mailto:development@qt-project.org>> Subject: Re: [Development] Request for sandbox area: QQSM Hi Brett, Thank you for the initiative. I also think there is indeed a lot of unleashed

  1   2   3   >