Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Minor API Change Requests for TM RemoteCDT Integration

Hi Martin,

As you can see the division to the public and internal in the
launcher-related classes is not particularly good. I think at the
beginning most of the UI component were intended to be internal, but we
haven't followed this principle and now it's a mess. The internal
AbstractCDebuggerTab and public CDebuggerTab is a good example. Moreover
in some of my remote launch configurations I am subclassing the
non-public classes, because I have been too lazy to write my own UI from
scratch. I believe that most of the CDT extensions do the same.
At the same time I would prefer to minimize the number of public UI
components. It is not easy to support it, for example, the Eclipse Debug
team is very reluctant to do it. Maybe this is the right time to
reorganize the launch plugin structure instead of opening more and more
classes to public. 
Do you have a description of your launch configuration components? It
would be helpful to understand what are you trying to do and come up
with a common solution.


PS It would be nice to hear the opinion of the original owner of the
launch plugin, Dave Inglis.

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Oberhuber, Martin
Sent: 22 March 2007 17:24
To: CDT General developers list.
Subject: [cdt-dev] Minor API Change Requests for TM RemoteCDT

Dear CDT Committers,

as you might be aware, the TM project provides a CDT integration, which
allows remote debugging through gdb / gdbserver, including automatic
upload and remote launching of gdbserver itself.

Our integration currently needs to use CDT "internal"
classes or methods in three cases. According to the Europa Coordinate
Release planning meeting [1], I thus request API changes in the CDT in
order to allow our plugin work through official channels.

I think that all three requests are really small and reasonable, so I
hope this can be done. 

API inconsistency: AbstractCDebuggerTab

Request CLaunchConfigurationTab.setDialogShell()

GDBDebuggerPage should be API

Once committers agree that this is something you want, the
implementation should be doable within minutes since it is just a simple
"move" refactoring or applying my patch.

[1] For reference, see section "Using Non-APIs" in

Martin Oberhuber
Wind River Systems, Inc.
Target Management Project Lead, DSDP PMC Member
cdt-dev mailing list

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

Back to the top