Re: [Development] [Interest] QEvent problem
Yeah. I think that is the reason. I have multiple widgets and some widgets are created in another widget. So I need to arrange these shortcuts with event filter or something like that I do not know yet. Thanks for replies. On Tue, May 26, 2015 at 8:14 PM, Matthew Woehlke < mw_tr...@users.sourceforge.net> wrote: > On 2015-05-26 09:10, Berkay Elbir wrote: > > I want to mention an issue that I have faced. I have an event filter of a > > widget and when I press "Delete" button, event types coming to event > Filter > > changes. > > > > [...] when I press "Delete" button, it sometimes [has the event type] > > KeyRelease instead of Shortcut then I press again, it [is Shortcut]. > > Do you have a QAction / QShortcut with the key sequence 'del'? Does the > behavior change based on what widget has focus? Or whether some other > widget is disabled or not? > > My first guess is that there is a QShortcut somewhere that is set to > consume the delete key, that sometimes is "active" (enabled, and in > scope w.r.t. its context given the widget that has focus) and sometimes > is not, and that is what causes the difference you are seeing. > > -- > Matthew > > ___ > Interest mailing list > inter...@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Module for Serial Buses
On Tuesday 26 May 2015 17:40:05 Viironen Kalle wrote: > On 26/05/15 19:42, "Thiago Macieira" wrote: > > > >On Tuesday 26 May 2015 15:19:26 Hausmann Simon wrote: > > > >>Good point :) > >>I was under the assumption that the concepts are too different, but if > >>they > >>aren't then maybe a joint module would make sense. > > > > > >At the very least it's a superset and QtSerialPort (the library) should > >be > >moved into the new module. It's just two classes anyway. > > > I fully agree. At some point QtSerialPort should be moved under this new > module. Problem with QtSerialPort is that it’s so tightly tied into RS-232 > functionality that its extension to support other serial buses isn’t > feasible. Fair enough. Can you give an overview of what classes you'd like to have and how QSerialPort and QSerialPortInfo would fit into the naming scheme? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Module for Serial Buses
On 26/05/15 19:42, "Thiago Macieira" wrote: >On Tuesday 26 May 2015 15:19:26 Hausmann Simon wrote: >>Good point :) >>I was under the assumption that the concepts are too different, but if >>they >>aren't then maybe a joint module would make sense. > >At the very least it's a superset and QtSerialPort (the library) should >be >moved into the new module. It's just two classes anyway. I fully agree. At some point QtSerialPort should be moved under this new module. Problem with QtSerialPort is that it’s so tightly tied into RS-232 functionality that its extension to support other serial buses isn’t feasible. -Kalle ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Module for Serial Buses
On Tuesday 26 May 2015 15:19:26 Hausmann Simon wrote: > Good point :) > > I was under the assumption that the concepts are too different, but if they > aren't then maybe a joint module would make sense. At the very least it's a superset and QtSerialPort (the library) should be moved into the new module. It's just two classes anyway. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QEvent problem
On Tuesday 26 May 2015 19:23:02 Berkay Elbir wrote: > I simplified the event handler function. This is an event handler of a > widget and there are different processes for every event case. In my > widget, I catch events and doing something in terms of them. For example, > as I said before I pressed "Delete" button of keyboard, type of event ( > e->type() ) is sometimes QEvent::KeyRelease: and sometimes > QEvent::Shortcut:. To understand this, I debugged with Visual Studio. This > is just an example of course it happens for other keyboard keys. The problem is that you may have removed the bug from the code when you pasted it. Anyway, I don't know why it would change from shortcut to the actual low-level key. Maybe someone else. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QEvent problem
I simplified the event handler function. This is an event handler of a
widget and there are different processes for every event case. In my
widget, I catch events and doing something in terms of them. For example,
as I said before I pressed "Delete" button of keyboard, type of event (
e->type() ) is sometimes QEvent::KeyRelease: and sometimes
QEvent::Shortcut:. To understand this, I debugged with Visual Studio. This
is just an example of course it happens for other keyboard keys.
I do not know why the reason is.
On Tue, May 26, 2015 at 6:03 PM, Thiago Macieira
wrote:
> On Tuesday 26 May 2015 16:10:08 Berkay Elbir wrote:
> > bool eventFilter(QObject *o, QEvent *e){
> > switch(e->type()){
> > case QEvent::MouseButtonPress:
> > case QEvent::MouseMove:
> > case QEvent::MouseButtonRelease:
> > case QEvent::Shortcut:
> > case QEvent::KeyRelease:
> >
> > }
> > return false;
> > }
> >
> > My function is like this and when I press "Delete" button, it sometimes
> > enters KeyRelease instead of Shortcut then I press again, it enters
> > Shortcut part.
> >
> > Do you know about this issue? Is this a kind of bug or I use this wrong
> way?
>
> Not sure I understand you. If you have all five cases leading to the same
> code,
> how can you even tell which one it was?
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Module for Serial Buses
Good point :) I was under the assumption that the concepts are too different, but if they aren't then maybe a joint module would make sense. Simon Original Message From: Thiago Macieira Sent: Tuesday, May 26, 2015 17:06 To: development@qt-project.org Subject: Re: [Development] New Module for Serial Buses On Tuesday 26 May 2015 15:47:04 Simon Hausmann wrote: > My first suggestion is to give the module a better name. "Bus" is an > overloaded term with many meanings and it is IMO too close to our "DBus" > module. Why not go with what your first sentence in the email used: > > "We’d like to create a new Qt module for serial buses" > > Call it the Qt module for accessing serial buses, QtSerialBus :) Agreed, but why can't this be an extension of QtSerialPort? QtSerialPort is not about just 9-pin connectors and UART, since it does support serial over USB too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Module for Serial Buses
On Tuesday 26 May 2015 15:47:04 Simon Hausmann wrote: > My first suggestion is to give the module a better name. "Bus" is an > overloaded term with many meanings and it is IMO too close to our "DBus" > module. Why not go with what your first sentence in the email used: > > "We’d like to create a new Qt module for serial buses" > > Call it the Qt module for accessing serial buses, QtSerialBus :) Agreed, but why can't this be an extension of QtSerialPort? QtSerialPort is not about just 9-pin connectors and UART, since it does support serial over USB too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QEvent problem
On Tuesday 26 May 2015 16:10:08 Berkay Elbir wrote:
> bool eventFilter(QObject *o, QEvent *e){
> switch(e->type()){
> case QEvent::MouseButtonPress:
> case QEvent::MouseMove:
> case QEvent::MouseButtonRelease:
> case QEvent::Shortcut:
> case QEvent::KeyRelease:
>
> }
> return false;
> }
>
> My function is like this and when I press "Delete" button, it sometimes
> enters KeyRelease instead of Shortcut then I press again, it enters
> Shortcut part.
>
> Do you know about this issue? Is this a kind of bug or I use this wrong way?
Not sure I understand you. If you have all five cases leading to the same code,
how can you even tell which one it was?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Module for Serial Buses
On Tuesday, May 26, 2015 01:33:59 PM Viironen Kalle wrote: > Hi, > > We’d like to create a new Qt module for serial buses. At first stage this > generic extendable module would include support for CAN-bus, but > architecture should be such that supporting also other generally used > serial buses like Flexray, i2c, SPI, 1-wire etc. would be as easy as > possible. > Motivation for this kind of generic bus module is to allow easy to use > direct Qt access to buses that are commonly used when developing embedded > and/or industrial applications with Qt. Also it would be great to see > companies working with these buses to adopt the generalised core approach > that we shall be bringing with this bus module and start developing support > for different buses directly on top of Qt framework. > For naming we have thought either QtBus or QtSerialBus. IMO name as such > should already on it’s own describe the generalised idea of the module. > Attached pdf describes the high level plan of the new module. > > All comments and feedback is warmly welcome :) My first suggestion is to give the module a better name. "Bus" is an overloaded term with many meanings and it is IMO too close to our "DBus" module. Why not go with what your first sentence in the email used: "We’d like to create a new Qt module for serial buses" Call it the Qt module for accessing serial buses, QtSerialBus :) Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QEvent problem
Hello all,
I want to mention an issue that I have faced. I have an event filter of a
widget and when I press "Delete" button, event types coming to event Filter
changes.
bool eventFilter(QObject *o, QEvent *e){
switch(e->type()){
case QEvent::MouseButtonPress:
case QEvent::MouseMove:
case QEvent::MouseButtonRelease:
case QEvent::Shortcut:
case QEvent::KeyRelease:
}
return false;
}
My function is like this and when I press "Delete" button, it sometimes
enters KeyRelease instead of Shortcut then I press again, it enters
Shortcut part.
Do you know about this issue? Is this a kind of bug or I use this wrong way?
Thanks in advance,
BE
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Support for custom Diffie-Hellman parameters in QSslSocket
For anyone following this, the change is now at: https://codereview.qt-project.org/#/c/113070 On Tue, May 26, 2015 at 12:11 PM, Mikkel Krautz wrote: > Hi Rich, > > Sorry for the clash of work -- I had this sketch done on Saturday, and > thought I would have more time during the weekend to hack on it. > However that turned out not to be the case, so I threw this out here. > I'll strive to be more communicative in the future. :-) > > WRT tests and docs: I'm aware that they're lacking, this was mainly a > sketch of the API. > > I will upload it as-is to Gerrit and get back to you, so I can get > people's comments early. > > Thanks, > Mikkel > > On Tue, May 26, 2015 at 11:34 AM, Richard Moore wrote: >> Hi Mikkel, >> >> Please could you upload your change to gerrit so I can review it properly? I >> was actually implementing this yesterday, but since you've got it done I'll >> abandon my change. If you add me as the reviewer then I'll add the other >> relevant people. The change seems mainly okay, but there are a few minor >> things need fixing (some incorrect \since statements, missing autotest >> etc.). >> >> Cheers >> >> Rich. >> >> On 25 May 2015 at 23:16, Mikkel Krautz wrote: >>> >>> Hi, >>> >>> I've been working on adding the ability to set custom DH parameters >>> for QSslSocket and I want to start discussing an API for the feature, >>> rather than jumping directly to a code review. >>> >>> I have a preliminary patch that adds a sketch of the API I'm envisioning: >>> https://gist.github.com/mkrautz/699f3c7fb22f48b7059c >>> (It's untested, but it builds...) >>> >>> Basically, what I'm envisioning is >>> >>> - An opaque (for the user) QSslDiffieHellmanParameters class. >>> - It loads DH parameters either as PEM or DER via a constructor that >>> takes a QByteArray or a QIODevice (like QSslKey). >>> - After loading, isNull() can be used to check if the DH parameters >>> were loaded, and were valid (OpenSSL backend uses DH_check -- not sure >>> what should be done on SecureTransport, if anything?). >>> - Internally, the QSslDiffieHellmanParameters object stores a >>> DER-encoded version of the parameters. (This makes it easily loadable >>> in both OpenSSL and SecureTransport) >>> - A public QSslConfiguration::setDiffieHellmanParameters() to set the >>> DH parameters. >>> - A public (but not in the public headers) >>> QSslConfiguration::diffieHellmanParameters() for internal use by the >>> backends. >>> - QSslDiffieHellmanParametersPrivate will befriend QSslContext (for >>> OpenSSL) and an equivalent for SecureTransport to allow the >>> implementations to access the DER encoded data of the >>> QSslDiffieHellmanParameters. >>> >>> I did a cursory web search for the ability to set DH parameters for >>> WinRT listeners, but I don't think that's possible -- so I haven't >>> considered that, for now... >>> >>> Let me know what you think. >>> >>> Thanks, >>> Mikkel >>> ___ >>> Development mailing list >>> Development@qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> >> ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Is QImage movable
Good, that's what i exactly wanted to know. 2015-05-26 14:56 GMT+03:00 Marc Mutz : > On Saturday 23 May 2015 19:47:28 Thiago Macieira wrote: > > On Saturday 23 May 2015 15:35:23 Иван Комиссаров wrote: > > > Hi. > > > > > > I’ve created a QVector of QImages and tried to insert an image in the > > > vector: QVector images; > > > images.insert(images.begin(), QImage()); > > > > > > I got a compiler warning saying > > > > > > "qvector.h:649:21: warning: destination for this 'memmove' call is a > > > pointer to dynamic class 'QImage'; vtable pointer will be overwritten > > > [-Wdynamic-class-memaccess]» > > > > > > This happens because QImage inherits QPaintDevice (which is virtual) > and > > > QImage is declared movable using Q_DECLARE_SHARED macro. > > > > > > Is this behavior intended? > > > > Yes. > > In Qt 6, we should probably change that to static polymorphism. E.g. > anything > with a > QPaintDevice * paintDevice() > method on can be painted-to. I ran into the polymorphism of what should be > a > value class, too, already (when implementing swap). > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt Experts > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Is QImage movable
On Saturday 23 May 2015 19:47:28 Thiago Macieira wrote: > On Saturday 23 May 2015 15:35:23 Иван Комиссаров wrote: > > Hi. > > > > I’ve created a QVector of QImages and tried to insert an image in the > > vector: QVector images; > > images.insert(images.begin(), QImage()); > > > > I got a compiler warning saying > > > > "qvector.h:649:21: warning: destination for this 'memmove' call is a > > pointer to dynamic class 'QImage'; vtable pointer will be overwritten > > [-Wdynamic-class-memaccess]» > > > > This happens because QImage inherits QPaintDevice (which is virtual) and > > QImage is declared movable using Q_DECLARE_SHARED macro. > > > > Is this behavior intended? > > Yes. In Qt 6, we should probably change that to static polymorphism. E.g. anything with a QPaintDevice * paintDevice() method on can be painted-to. I ran into the polymorphism of what should be a value class, too, already (when implementing swap). Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [Announce] Qt 4.8.7 released
We are happy to announce the release of Qt 4.8.7: http://blog.qt.io/blog/2015/05/26/qt-4-8-7-released/ Big thanks for everyone who made this possible! -- Akseli Salovaara Software Specialist The Qt Company ___ Announce mailing list annou...@qt-project.org http://lists.qt-project.org/mailman/listinfo/announce ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Support for custom Diffie-Hellman parameters in QSslSocket
Hi Rich, Sorry for the clash of work -- I had this sketch done on Saturday, and thought I would have more time during the weekend to hack on it. However that turned out not to be the case, so I threw this out here. I'll strive to be more communicative in the future. :-) WRT tests and docs: I'm aware that they're lacking, this was mainly a sketch of the API. I will upload it as-is to Gerrit and get back to you, so I can get people's comments early. Thanks, Mikkel On Tue, May 26, 2015 at 11:34 AM, Richard Moore wrote: > Hi Mikkel, > > Please could you upload your change to gerrit so I can review it properly? I > was actually implementing this yesterday, but since you've got it done I'll > abandon my change. If you add me as the reviewer then I'll add the other > relevant people. The change seems mainly okay, but there are a few minor > things need fixing (some incorrect \since statements, missing autotest > etc.). > > Cheers > > Rich. > > On 25 May 2015 at 23:16, Mikkel Krautz wrote: >> >> Hi, >> >> I've been working on adding the ability to set custom DH parameters >> for QSslSocket and I want to start discussing an API for the feature, >> rather than jumping directly to a code review. >> >> I have a preliminary patch that adds a sketch of the API I'm envisioning: >> https://gist.github.com/mkrautz/699f3c7fb22f48b7059c >> (It's untested, but it builds...) >> >> Basically, what I'm envisioning is >> >> - An opaque (for the user) QSslDiffieHellmanParameters class. >> - It loads DH parameters either as PEM or DER via a constructor that >> takes a QByteArray or a QIODevice (like QSslKey). >> - After loading, isNull() can be used to check if the DH parameters >> were loaded, and were valid (OpenSSL backend uses DH_check -- not sure >> what should be done on SecureTransport, if anything?). >> - Internally, the QSslDiffieHellmanParameters object stores a >> DER-encoded version of the parameters. (This makes it easily loadable >> in both OpenSSL and SecureTransport) >> - A public QSslConfiguration::setDiffieHellmanParameters() to set the >> DH parameters. >> - A public (but not in the public headers) >> QSslConfiguration::diffieHellmanParameters() for internal use by the >> backends. >> - QSslDiffieHellmanParametersPrivate will befriend QSslContext (for >> OpenSSL) and an equivalent for SecureTransport to allow the >> implementations to access the DER encoded data of the >> QSslDiffieHellmanParameters. >> >> I did a cursory web search for the ability to set DH parameters for >> WinRT listeners, but I don't think that's possible -- so I haven't >> considered that, for now... >> >> Let me know what you think. >> >> Thanks, >> Mikkel >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Support for custom Diffie-Hellman parameters in QSslSocket
Hi Mikkel, Please could you upload your change to gerrit so I can review it properly? I was actually implementing this yesterday, but since you've got it done I'll abandon my change. If you add me as the reviewer then I'll add the other relevant people. The change seems mainly okay, but there are a few minor things need fixing (some incorrect \since statements, missing autotest etc.). Cheers Rich. On 25 May 2015 at 23:16, Mikkel Krautz wrote: > Hi, > > I've been working on adding the ability to set custom DH parameters > for QSslSocket and I want to start discussing an API for the feature, > rather than jumping directly to a code review. > > I have a preliminary patch that adds a sketch of the API I'm envisioning: > https://gist.github.com/mkrautz/699f3c7fb22f48b7059c > (It's untested, but it builds...) > > Basically, what I'm envisioning is > > - An opaque (for the user) QSslDiffieHellmanParameters class. > - It loads DH parameters either as PEM or DER via a constructor that > takes a QByteArray or a QIODevice (like QSslKey). > - After loading, isNull() can be used to check if the DH parameters > were loaded, and were valid (OpenSSL backend uses DH_check -- not sure > what should be done on SecureTransport, if anything?). > - Internally, the QSslDiffieHellmanParameters object stores a > DER-encoded version of the parameters. (This makes it easily loadable > in both OpenSSL and SecureTransport) > - A public QSslConfiguration::setDiffieHellmanParameters() to set the > DH parameters. > - A public (but not in the public headers) > QSslConfiguration::diffieHellmanParameters() for internal use by the > backends. > - QSslDiffieHellmanParametersPrivate will befriend QSslContext (for > OpenSSL) and an equivalent for SecureTransport to allow the > implementations to access the DER encoded data of the > QSslDiffieHellmanParameters. > > I did a cursory web search for the ability to set DH parameters for > WinRT listeners, but I don't think that's possible -- so I haven't > considered that, for now... > > Let me know what you think. > > Thanks, > Mikkel > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiling for iOS, qtdeclarative and others fail
> On May 23, 2015, at 05:03, Ariel Molina wrote: > > Hi, > > I solved the problem, just want to share, > > On Wed, May 20, 2015 at 12:16 PM, Edward Sutton > wrote: > I understand the config commands used to build Qt packages are here: > > http://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config > > > I just followed your suggestion but using opensource [1], please Have a look > at my configure output [2]. > > It installed on /usr/local > • make -j8, took two hours, went OK > • cd qtbase, sudo make install, OK > • cd qtimageformats, sudo make install, OK > • cd qtquick1, sudo make install, OK > • cd qtquickcontrols, sudo make install OK > • cd qtdeclarative, FAILS: http://i.imgur.com/QOAaEgJ.png > The error is: > === BUILD TARGET xmlpatterns OF PROJECT xmlpatterns WITH CONFIGURATION Debug > === > Check dependencies > Code Sign error: No provisioning profiles found: No non–expired provisioning > profiles were found. > CodeSign error: code signing is required for product type 'Application' in > SDK 'iOS 8.3’ xmlpatterns module probably builds the “xmlpatterns” and “xmlpatternsvalidator” for the target environment (in your case iOS), and therefore tries to sign these applications. Similar for “qml.app”. > Just out of curiosity I went into these (in exact order) > • qtxmlpatterns, FAILS with same error > • qtmultimedia, qtgraphicaleffects, qtsensors, qtsvg, qtcanvas3d, > qtlocation, qtwebchannel, qtwebsockets, qt3d, OK > However I found a fix, I went into qt/xmlpatterns/tools/xmlpatterns > and did a normal non-sudo make, and it found my developer credentials. If you use sudo, the process is running as root, and root doesn’t have your “normal” user’s developer credentials installed of course. Did you build Qt with a simple “make” (as normal user, without “install”) before you tried to install? > There, make install worked. But not on the parent, qtxmlpatterns. > > So the fix i implemented is I went into /usr/local and changed ownership of > Qt-5* to my user, then did all installs without sudo, then it finds my Apple > Developer credentials, it installs cleanly. Problem solved :) > > Thank you for your time! > > Ariel > > [1] > http://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config/configure_ios_opensource > [2] http://pastebin.com/83vtcLzH > [3] Fails snapshot: http://i.imgur.com/QOAaEgJ.png > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller, Senior Software Engineer | The Qt Company Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
