Re: [Development] new debugsupport module and API
On 19/05/14 15:39, Ulf Hermann ulf.herm...@digia.com wrote: Please don't. quick1 is especially usefull on platforms without any OpenGL. And quick1 can be built without qtdeclarative. Most of the current dependencies are optional, and even qtwebkit depending on qtdeclarative is artificial in qt.pro. qtwebkit certainly builds and runs without it in Qt 5.3.0-rc1. Maybe we just shouldn't touch quick1 anymore for things like refactoring and cleanup. I'll leave it alone for now. You'll still be able to use the debug client with quick1 applications, of course. Yes, let’s please leave qtquick1 alone. Trying to merge it’s QML parser with the parser in qtdeclarative doesn’t give any benefits, just adds a lot of work. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] new debugsupport module and API
On Thu, May 15, 2014 at 11:41 AM, Olivier Goffart oliv...@woboq.com wrote: On Monday 12 May 2014 11:48:21 Ulf Hermann wrote: Hi, we currently have several implementations of the QML debug protocol used to transmit data between a debugger or profiler and the application being debugged or profiled. I'm proposing a generalized debugsupport module to address various issues with those. In particular: Unrelated, but there is also the private qmljs library, which contains the qml parser, which is duplicated all over the place (qtquick1, qtdeclarative, qtcreator, kdevelop) (And I was also considering using it for a code browser ;-) ) Maybe that library also belong in the same repository, qmlhelpers ? -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development For what it's worth and with my KDevelop hat on, having access to different qml tooling would be very welcome. We don't like forking the code off. Also we'll be reviewing our side of these issues in the KDE SDK meeting this summer [1], maybe somebody would like to come and say hi. Furthermore, I'm also planning to attend the Qt Contributor Summit, it might be a good idea to have a session about QML/Quick tools creation. Cheers! Aleix [1] http://dot.kde.org/2014/05/27/randa-moving-kde-forward ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] new debugsupport module and API
On Thu, May 15, 2014 at 09:16:38AM -0700, Thiago Macieira wrote: Em qui 15 maio 2014, às 11:28:28, Oswald Buddenhagen escreveu: This code does not belong into Qt Base, if you accept that the library is an improvement over the 6 copies we have all over the place, the question is only where, not if. if you insist on making it a separate repository, we'll have a tiny repo which is an additional dependency of quick1 and declarative, and which just adds additional burden to any release-related activities. i wonder who'd benefit from *that*. Since quick1 depends on declarative through the dependency on qtwebkit and qttools, the library could be directly on qtdeclarative for now. Please don't. quick1 is especially usefull on platforms without any OpenGL. And quick1 can be built without qtdeclarative. Most of the current dependencies are optional, and even qtwebkit depending on qtdeclarative is artificial in qt.pro. qtwebkit certainly builds and runs without it in Qt 5.3.0-rc1. Regards, Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] new debugsupport module and API
Please don't. quick1 is especially usefull on platforms without any OpenGL. And quick1 can be built without qtdeclarative. Most of the current dependencies are optional, and even qtwebkit depending on qtdeclarative is artificial in qt.pro. qtwebkit certainly builds and runs without it in Qt 5.3.0-rc1. Maybe we just shouldn't touch quick1 anymore for things like refactoring and cleanup. I'll leave it alone for now. You'll still be able to use the debug client with quick1 applications, of course. regards, Ulf ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] new debugsupport module and API
On Wed, May 14, 2014 at 11:20:10PM +0200, André Pönitz wrote: This code does not belong into Qt Base, if you accept that the library is an improvement over the 6 copies we have all over the place, the question is only where, not if. if you insist on making it a separate repository, we'll have a tiny repo which is an additional dependency of quick1 and declarative, and which just adds additional burden to any release-related activities. i wonder who'd benefit from *that*. nor should it be advertised as a re-usable framework. that decision is orthogonal to the physical location. or seen from a different angle, it would be harder to hide it if it was a separate module (well, not really, we did that with qtjsbackend). but then, i'd totally advocate a git submodule. there would be complaining how badly this stuff is integrated into the git ui, and we'd have to make a few adjustments here and there, but overall the solution is workable. then i could finally get rid of the three copies of the qmake evaluator, too ... ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] new debugsupport module and API
On Monday 12 May 2014 11:48:21 Ulf Hermann wrote: Hi, we currently have several implementations of the QML debug protocol used to transmit data between a debugger or profiler and the application being debugged or profiled. I'm proposing a generalized debugsupport module to address various issues with those. In particular: Unrelated, but there is also the private qmljs library, which contains the qml parser, which is duplicated all over the place (qtquick1, qtdeclarative, qtcreator, kdevelop) (And I was also considering using it for a code browser ;-) ) Maybe that library also belong in the same repository, qmlhelpers ? -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] new debugsupport module and API
On Thursday 15. May 2014 11.41.36 Olivier Goffart wrote: On Monday 12 May 2014 11:48:21 Ulf Hermann wrote: Hi, we currently have several implementations of the QML debug protocol used to transmit data between a debugger or profiler and the application being debugged or profiled. I'm proposing a generalized debugsupport module to address various issues with those. In particular: Unrelated, but there is also the private qmljs library, which contains the qml parser, which is duplicated all over the place (qtquick1, qtdeclarative, qtcreator, kdevelop) (And I was also considering using it for a code browser ;-) ) Maybe that library also belong in the same repository, qmlhelpers ? Given the divergence of grammar between QtQuick1 and QtQml I suggest we keep the static qmldevtools library in the qtdeclarative repository. Anything need it maybe can depend on qtdeclarative? Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] new debugsupport module and API
Em qui 15 maio 2014, às 11:28:28, Oswald Buddenhagen escreveu: This code does not belong into Qt Base, if you accept that the library is an improvement over the 6 copies we have all over the place, the question is only where, not if. if you insist on making it a separate repository, we'll have a tiny repo which is an additional dependency of quick1 and declarative, and which just adds additional burden to any release-related activities. i wonder who'd benefit from *that*. Since quick1 depends on declarative through the dependency on qtwebkit and qttools, the library could be directly on qtdeclarative for now. -- 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 debugsupport module and API
On Tuesday 13 May 2014 21:58:29 André Pönitz wrote: On Tue, May 13, 2014 at 05:30:43PM +0200, Ulf Hermann wrote: Please create a new module. This doesn't need to be in qtbase. Is anyone opposed to keeping this in a separate qtdebugsupport.git repository, then? I am. At the very least, this is still missing an explanation what actual problems this is going to solve, and a few _plausible_ scenarios where this code will be reused. A couple of users actually asking for such a framework would already help to understand the need. Hey Andre, let me (re-)raise two valid use cases for this new repository: GammaRay and KDevelop (as previously mentioned by Kai). But I guess people out there working on any other IDE might want to use it eventually, if they add support for QML. Momentics comes into mind there. Once the need to have it is established, the implementation can be discussed. I would like to see such a debugsupport module. Bye -- Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin Milian Wolff | milian.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] new debugsupport module and API
On Wed, May 14, 2014 at 11:37:45AM +0200, Milian Wolff wrote: On Tuesday 13 May 2014 21:58:29 André Pönitz wrote: On Tue, May 13, 2014 at 05:30:43PM +0200, Ulf Hermann wrote: Please create a new module. This doesn't need to be in qtbase. Is anyone opposed to keeping this in a separate qtdebugsupport.git repository, then? I am. At the very least, this is still missing an explanation what actual problems this is going to solve, and a few _plausible_ scenarios where this code will be reused. A couple of users actually asking for such a framework would already help to understand the need. Hey Andre, let me (re-)raise two valid use cases for this new repository: GammaRay and KDevelop (as previously mentioned by Kai). But I guess people out there working on any other IDE might want to use it eventually, if they add support for QML. Momentics comes into mind there. Once the need to have it is established, the implementation can be discussed. I would like to see such a debugsupport module. That's a clear vote. I'd still like to try to set expectations right: I understand the proposition _sounds_ good, and the code actually _looks_ good. But it doesn't _do_ anything sensible, nor does it help when trying to do anything sensible. What's currently proposed to be moved into Qt Base is several thousand lines of pure infrastructure for things like packet and connection handling. _There is no actual debugging or profiling service included_. The communication protocol used is completely ad-hoc, and not used by anything else in the world. This infrastructure supports _only_ services that run _inside_ the application it examines, i.e. a profiler based on this framework shares address space, including heap, network connection etc. with the object it claims to profile, _while using resources of this object for its own operations_. Unless special measure are taken, the service will remain and be accessible in the deployed application. There is no build-in security. This infastructure cannot be used to interface classical profiling/debugging tools like Valgrind, GDB, etc. It does _not_ simplify IDE integration: First, it can as-is only be used with Qt based clients/IDEs. This won't be much of a problem for KDevelop or GammaRay, but e.g. Momentics would have to wrap or essentially re-do the client side in Java. Second, Qt based frontends do not get a free ride either. Exemplified by Qt Creator: The amount of code needed to use that framework in the debugger plugin to make QML debugging work is in the same order as the amount of code we have for the direct GDB and LLDB interfaces. And to put it into proportion, plugin/debugger/qml/* is roughly 1.5 the size plugins/designer, the Qt Designer integration. I maintain that this framework is completely over-engineered. It does not work like typical tools in the field, nor does it help to write such tools. I believe there is not a single use case where it gives any benefit over a direct implementation of whatever kind of communication/data extraction is needed. This code does not belong into Qt Base, nor should it be advertised as a re-usable framework. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] new debugsupport module and API
-Original Message- From: André Pönitz [mailto:apoen...@t-online.de] [...] Consolidation of various incarnations of the code might make sense, exporting would need a good reason. One of the reasons for the different incarnations of the client side of the debug API in Qt Creator qtdeclarative is that it's not public API, and we usually try to avoid using private Qt API in Qt Creator. Instead, we just copied it. An alternative to making it exported API would be putting it in a git submodule that Qt modules Qt Creator use ... Anyhow, what's wrong with making it a proper Qt Addon instead? We have the infrastructure for this already. Btw, I can easily see other IDE's (KDevelop) and tools (GammaRay) profiting from this infrastructure too. Wouldn't a unified way to inspect/talk to a running Qt application be helpful? One thing Andre raised though was whether we should continue running our own (albeit improved) proprietary protocol, or try to integrate into / implement TCF: http://wiki.eclipse.org/TCF My main point was not to go for TCF, but that we should not go further down the NIH route _before checking out existing alternatives *and* establishing they don't fit the purpose_. Understood. Still, I'm wondering whether adopting (parts of) TCF buys us anything else then using something documented. This advantage could be e.g. marrying the Qt services then with a stock TCF service/infrastructure, or reusing an existing TCF implementation internally. There's also adb (Android Debug Bridge), though the protocol itself is AFAIK not properly documented (short of http://blogs.kgsoft.co.uk/2013_03_15_prg.htm, which starts with Yet, the internal logics of ADB are very complex. Compounded with the lack of documentation, it is extremely difficult to understand how it works and how it is actually implemented. - not very encouraging). Anyhow ... let's keep in mind that the current infrastructure / protocol is there and is working. Ulf obviously wants to clean it up extend it, but switching to an entire different protocol with different semantics isn't exactly a free ride. Maybe it's worthwhile in the long run, but we're not in a situation where we start from scratch, and just wonder whether we should use an established protocol, or invent our own one. Regards Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] new debugsupport module and API
One thing Andre raised though was whether we should continue running our own (albeit improved) proprietary protocol, or try to integrate into / implement TCF: http://wiki.eclipse.org/TCF TCF has different messaging semantics. In particular it has message types (Request, Response, Event) and rules on the order in which those have to occur. All the plugins would have to play by those rules and the server and client would have to expose a slightly different interface. Also, TCF is way more complex than what we currently have and mandates various things we don't actually need, e.g. a locator service. It also proposes standardized interfaces for various common services, e.g. RunControl, which of course are different to what we currently have. If we want to be compatible with other tools we'll have to implement that. If not, we can as well stick to our own protocol. Another intersting possibility would be the gdb remote protocol because if we get the server stub right we could get native QML/JS debugging in gdb and lldb by using that. However, the protocol is very crude and not really meant for anything but debugging. So we'd have to somewhat misuse it to implement things like the QML profiler on top of it. There is a File I/O interface that could be used to fetch the data and the client can send custom packets using Python scripts, but do we really want that? Of course using gdb remote would also necessitate changes in all the plugins so that they output gdb commands and replies. So, to conclude: Implementing the server side of TCF would be a lot of work and we should clearly know what we're trying to achieve before we do that. Implementing the gdb remote protocol would be easier and have an immediate use case, but if we don't want to put a whole lot of strange hackery into that we should restrict it to QML/JS debugging and not make it a general purpose facility. Please create a new module. This doesn't need to be in qtbase. Yes, I think so, too. There is no real reason to further bloat qtbase. regards, Ulf ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] new debugsupport module and API
Please create a new module. This doesn't need to be in qtbase. Is anyone opposed to keeping this in a separate qtdebugsupport.git repository, then? regards, Ulf ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] new debugsupport module and API
Ulf Hermann: Is anyone opposed to keeping this in a separate qtdebugsupport.git repository, then? With what compatibility promises regarding code and protocol? Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] new debugsupport module and API
Is anyone opposed to keeping this in a separate qtdebugsupport.git repository, then? With what compatibility promises regarding code and protocol? I would promise source and binary compatibility and backwards as well as forward compatibility of the protocol. At the same time I would publicly state that we'll consider replacing the whole affair with TCF or something similar in Qt6 and deprecating the the debugsupport module then. We in fact already have to maintain protocol compatibility so that older and newer tools can debug different versions of Qt. We can as well make that explicit: The protocol format is not going to change in Qt5 anymore. In order for qtdeclarative to depend on qtdebugsupport we need it as an essential module which has to provide source and binary compatibility. (Alternately we could restart the discussion about submodules, but I'll only do that as last resort ...) At the same time I know that this suffers from a serious case of NIH and I would like to drop it at some point. However, we should really not further complicate it. Retrofitting TCF into the current architecture would be a major mess. With my refactoring I tried to keep the changes to existing plugins minimal while reducing code duplication. That of course retains bad architectural decisions of the past which are incompatible with any state of the art debugging framework. The most important incompatibility revolves around the need for proper asynchronous messaging: The protocol should track messages from client and server and associate them with each other as commands and results, so that you can send multiple commands in a row without waiting for replies in between. The V4 debug service does that on its own, but it should really be done by the server for all services. A good architecture that supports this kind of interaction looks different than one that doesn't. In addition to that a good architecture that does that on a client which sends commands and receives results (and possibly asynchronous events) looks different than an architecture for a mostly reactive server. That means, once we do it properly, there won't be much of a point in keeping server and client in the same library anymore. I propose to clean it up a little now and redo it from scratch in Qt6. regards, Ulf ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] new debugsupport module and API
On Tue, May 13, 2014 at 05:30:43PM +0200, Ulf Hermann wrote: Please create a new module. This doesn't need to be in qtbase. Is anyone opposed to keeping this in a separate qtdebugsupport.git repository, then? I am. At the very least, this is still missing an explanation what actual problems this is going to solve, and a few _plausible_ scenarios where this code will be reused. A couple of users actually asking for such a framework would already help to understand the need. Once the need to have it is established, the implementation can be discussed. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] new debugsupport module and API
Hi, we currently have several implementations of the QML debug protocol used to transmit data between a debugger or profiler and the application being debugged or profiled. I'm proposing a generalized debugsupport module to address various issues with those. In particular: 1. Code duplication --- We currently have implementations of QPacketProtocol in: - qtdeclarative/src/plugins/qmltooling/shared/ - qtdeclarative/tools/qmlprofiler - qtquick1/src/declarative/debugger - qt-creator/src/libs/qmldebug We have differently named but functionally largely identical implementations of the qml debug client and connection in: - qtdeclarative/tests/auto/qml/debugger/shared - qtdeclarative/tools/qmlprofiler - qtquick1/src/declarative/debugger - qt-creator/src/libs/qmldebug We also have 2 server implementations, in qtquick1 and qtdeclarative. The debug clients and servers share a lot of functionality regarding connection handling and notifying their plugins about various conditions. Those plugins for servers and clients can share the same base class as they all expose the same interface to the server or client. Currently we have 6 of those base classes. 2. Missing flexibility -- Currently a TCP connection is used for any kind of debugging or profiling. This is potentially wasteful and dangerous as TCP has a certain overhead and the protocol itself doesn't care about security. Providing a connection over a QLocalSocket at least as an option seems to be a good idea. The debug server is currently tied into QtQml, even though it has technically nothing to do with QML. It's a general purpose tool for interacting with an application over a defined interface. It should live in a more appropriate place so that we can use it in other contexts if the need arises. 3. Messy implementation --- Many of the client implementations are badly written, potentially leak memory, don't properly handle errors, expose too many details of the underlying connection and provide subtly different interfaces to their plugins. It's also a bad idea to specify the interface between the debug server and client in terms of an arcane binary protocol full of magic numbers and with a colorful history (e.g. the protocol version is unusable; we practically never do service advertisement; in order to extend the protocol you can only add things to the end of messages, but you can never change any existing parts; service versions are transmitted as floats). Hiding the mess behind a clean C++ interface will make it much easier to work with and enables us to eventually replace the protocol with something less crazy. The following changes create a debugsupport module with public API in qtbase: https://codereview.qt-project.org/#change,85098 https://codereview.qt-project.org/#change,85099 https://codereview.qt-project.org/#change,85100 https://codereview.qt-project.org/#change,85101 https://codereview.qt-project.org/#change,85102 https://codereview.qt-project.org/#change,85103 I also have some WIP changes for qtdeclarative to use debugsupport: https://codereview.qt-project.org/#change,84103 https://codereview.qt-project.org/#change,84527 And for QtCreator: https://codereview.qt-project.org/#change,84526 QtQuick1 will get the same treatment. -- Ulf Hermann, Software Engineer - Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] new debugsupport module and API
Hi, I guess using a TCP connection would still be possible, but not be the defaut anymore for local debugging/profiling? Kind Regards, Thomas Hartmann From: development-bounces+thomas.hartmann=digia@qt-project.org [development-bounces+thomas.hartmann=digia@qt-project.org] on behalf of Ulf Hermann [ulf.herm...@digia.com] Sent: 12 May 2014 11:48 To: development@qt-project.org Subject: [Development] new debugsupport module and API Hi, we currently have several implementations of the QML debug protocol used to transmit data between a debugger or profiler and the application being debugged or profiled. I'm proposing a generalized debugsupport module to address various issues with those. In particular: 1. Code duplication --- We currently have implementations of QPacketProtocol in: - qtdeclarative/src/plugins/qmltooling/shared/ - qtdeclarative/tools/qmlprofiler - qtquick1/src/declarative/debugger - qt-creator/src/libs/qmldebug We have differently named but functionally largely identical implementations of the qml debug client and connection in: - qtdeclarative/tests/auto/qml/debugger/shared - qtdeclarative/tools/qmlprofiler - qtquick1/src/declarative/debugger - qt-creator/src/libs/qmldebug We also have 2 server implementations, in qtquick1 and qtdeclarative. The debug clients and servers share a lot of functionality regarding connection handling and notifying their plugins about various conditions. Those plugins for servers and clients can share the same base class as they all expose the same interface to the server or client. Currently we have 6 of those base classes. 2. Missing flexibility -- Currently a TCP connection is used for any kind of debugging or profiling. This is potentially wasteful and dangerous as TCP has a certain overhead and the protocol itself doesn't care about security. Providing a connection over a QLocalSocket at least as an option seems to be a good idea. The debug server is currently tied into QtQml, even though it has technically nothing to do with QML. It's a general purpose tool for interacting with an application over a defined interface. It should live in a more appropriate place so that we can use it in other contexts if the need arises. 3. Messy implementation --- Many of the client implementations are badly written, potentially leak memory, don't properly handle errors, expose too many details of the underlying connection and provide subtly different interfaces to their plugins. It's also a bad idea to specify the interface between the debug server and client in terms of an arcane binary protocol full of magic numbers and with a colorful history (e.g. the protocol version is unusable; we practically never do service advertisement; in order to extend the protocol you can only add things to the end of messages, but you can never change any existing parts; service versions are transmitted as floats). Hiding the mess behind a clean C++ interface will make it much easier to work with and enables us to eventually replace the protocol with something less crazy. The following changes create a debugsupport module with public API in qtbase: https://codereview.qt-project.org/#change,85098 https://codereview.qt-project.org/#change,85099 https://codereview.qt-project.org/#change,85100 https://codereview.qt-project.org/#change,85101 https://codereview.qt-project.org/#change,85102 https://codereview.qt-project.org/#change,85103 I also have some WIP changes for qtdeclarative to use debugsupport: https://codereview.qt-project.org/#change,84103 https://codereview.qt-project.org/#change,84527 And for QtCreator: https://codereview.qt-project.org/#change,84526 QtQuick1 will get the same treatment. -- Ulf Hermann, Software Engineer - Digia, Qt ___ 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 debugsupport module and API
I guess using a TCP connection would still be possible, but not be the defaut
anymore for local debugging/profiling?
The QDebugServer so far supports four kinds of connections and it's
possible to add more. You can use local or tcp connections and both
allow you to establish them in either direction. E.g. the QDebugClient
can open a QDebug{Local|Tcp}ServerConnection and the QDebugServer can
connect to that using the respective client connection.
The QQmlDebugServer (which wraps a QDebugServer) parses an additional
command line argument name and will use a QDebugLocalServerConnection
if it's found. QtCreator doesn't support that, yet, but it would be easy
to add it.
So, currently the default is still TCP and we can't really change that
for applications using older versions of Qt. However, we can make
QtCreator detect if the application supports local connections and use
them where possible.
regards,
Ulf
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] new debugsupport module and API
-Original Message- From: development-bounces+kai.koehne=digia@qt-project.org we currently have several implementations of the QML debug protocol used to transmit data between a debugger or profiler and the application being debugged or profiled. I'm proposing a generalized debugsupport module to address various issues with those. In particular: [...] First of all: I'm all for the idea of making the current protocol a properly exported API + using it for more than just QtDeclarative! One thing Andre raised though was whether we should continue running our own (albeit improved) proprietary protocol, or try to integrate into / implement TCF: http://wiki.eclipse.org/TCF Just like our current infrastructure, TCF (Target Communication Framework) allows you to announce communicate with individual plugins. Being designed for embedded devices, the idea is that the Service Manager runs as a separate process on the device - that's different from our current approach, where the server is actually in-process. The protocol is also much more advanced (read: complicated) than what we've provided so far ... For one, everything is defined in JSON, while we happily send around QByteArray's so far. I'm wondering how popular TCF is these days, and whether plugin into the TCF infrastructure/protocol would actually help our use cases. Can we e.g. plug in into an exising TCF server from inside the executable, to provide our own services? And how would the setup be for desktop, where there's no default TCF server running? Maybe someone with more insight into TCF cares to comment on this :) Regards Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] new debugsupport module and API
Em seg 12 maio 2014, às 11:48:21, Ulf Hermann escreveu: The following changes create a debugsupport module with public API in qtbase: https://codereview.qt-project.org/#change,85098 https://codereview.qt-project.org/#change,85099 https://codereview.qt-project.org/#change,85100 https://codereview.qt-project.org/#change,85101 https://codereview.qt-project.org/#change,85102 https://codereview.qt-project.org/#change,85103 Please create a new module. This doesn't need to be in qtbase. -- 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 debugsupport module and API
On Mon, May 12, 2014 at 08:39:37AM -0700, Thiago Macieira wrote: Em seg 12 maio 2014, às 11:48:21, Ulf Hermann escreveu: The following changes create a debugsupport module with public API in qtbase: Please create a new module. This doesn't need to be in qtbase. given that the two quick implementations will depend on it, it makes little sense to split it out, given what else is in qtbase. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] new debugsupport module and API
On Mon, May 12, 2014 at 02:54:23PM +, Koehne Kai wrote: -Original Message- From: development-bounces+kai.koehne=digia@qt-project.org we currently have several implementations of the QML debug protocol used to transmit data between a debugger or profiler and the application being debugged or profiled. I'm proposing a generalized debugsupport module to address various issues with those. In particular: [...] First of all: I'm all for the idea of making the current protocol a properly exported API + using it for more than just QtDeclarative! Consolidation of various incarnations of the code might make sense, exporting would need a good reason. One thing Andre raised though was whether we should continue running our own (albeit improved) proprietary protocol, or try to integrate into / implement TCF: http://wiki.eclipse.org/TCF My main point was not to go for TCF, but that we should not go further down the NIH route _before checking out existing alternatives *and* establishing they don't fit the purpose_. I mentioned TCF just as a potential candidate, as it showed some promise a while ago and we even had some code for it on the Creator side. I don't know anything about TCF's current state and mind share, though. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] new debugsupport module and API
Em seg 12 maio 2014, às 19:35:24, Oswald Buddenhagen escreveu: On Mon, May 12, 2014 at 08:39:37AM -0700, Thiago Macieira wrote: Em seg 12 maio 2014, às 11:48:21, Ulf Hermann escreveu: The following changes create a debugsupport module with public API in qtbase: Please create a new module. This doesn't need to be in qtbase. given that the two quick implementations will depend on it, it makes little sense to split it out, given what else is in qtbase. Neither implementation is in qtbase, so I don't see the logic in that argument. Yes, it *can* be in qtbase, but I don't see why it *should* be. I want to hear a reason of why it should. In that light: QtXml is there for historical reasons: there was code that needed it (including QtDBus). It can probably be moved out now. QtOpenGL and QtConcurrent are also historical and can probably be moved out too. Especially since those three aren't getting almost any updates, it makes sense to do it. QtDBus needs to stay because the XCB plugin needs it for some D-Bus protocols (notifications, the new systray protocol, etc.) The rest of the libraries in qtbase are really base stuff. -- 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
