I agree about the problem, but not so much about the solution :-) For
common functionality, there should be common UI. We just need to
figure out a proper mechanism for hiding functionality that is not
available, which is in a way what Eclipse is all about...
Mikhail Khodjaiants wrote:
Yes. Do you think it is
possible? I have heard many complains about UI components (views,
actions, etc) that are visible but not supported.
Do you mean to say that these breakpoint should not be in
org.eclipse.cdt.debug.core/ui?
Mikhail Khodjaiants wrote:
You may also want to take a look at bug 212316. It has a patch for
platform that allows the user to change the breakpoint type that is
created with a double-click in the editor. It was too late (or too
much ) for platform in 3.4, but I am going to press for this feature in
3.5.
Plus, there is another feature of CDT breakpoints which allows them to
have target-specific attributes. See bug 211533. I don't know if you
will be able to use it directly for catchpoints, because they will
require entirely new breakpoint types, but it may give you ideas for
design. In general, I think this is a very difficult problem (enabling
breakpoint creation actions based on context), because breakpoints can
be created before a debug session is active. A rather simple solution
may be to create a new command set for these new breakpoint actions and
have this command set disabled by default.
Cheers,
Pawel
Mikhail Khodjaiants wrote:
All action should use "visibleWhen" to check if catchpoints are
supported in general by the underlying context.
I also think event types can be contributed via an extension point, but
this is open for discussion, of course.
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Elena Laskavaia
Sent: Tuesday, April 08, 2008 3:21 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] catchpoints
This is the most tricky part. Short answer is for gdb is close to
impossible to do.
For example to know if gdb support catchpoints you not only need to
start gdb but you also have to start program. I was thinking making ui
(i.e. Add catchpoint... dialog) always show up and let backed return not
supported operation in attempt to use particular unsupported event
catchpoint.
As what is showing up in the dialog as events: I think we let debugger
plugin to contribute events, so technically if debugger does not
contribute anything it won't show up.
Mikhail Khodjaiants wrote:
Speaking seriously, please make sure the UI for this functionality
doesn't appear if a backend doesn't support it.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
--
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.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
