I think your best bet is to start by studying how the existing find and
copy actions are implemented. But I'll be first to admit that the
learning curve for this code is very very steep, and even though I've
worked on parts of it over last few years, I often have to re-learn it
myself whenever I come back to it.
Ali Ok wrote:
Hi Pawel,
I guess I'm not sure what is the end goal of your
changes. If you
would like to submit your feature as an enhancement patch, it's not
likely to be accepted if it uses internal APIs (even more so if it uses
reflection to gain access to APIs). If your goal is to create an
add-on plugin, you can use whatever APIs you like, but your work is not
going to reach nearly as many users.
My goal is a patch. You said, it is not likely to be accepted if it
uses internal APIs, but how could it be? If you mean I have to use some
Platform-Debug API or other JDT-Debug API, is it possible to go deep
without using Reflection API? You are right about externel plugin and
its usage. So, the sentence before is the important question.
As long as you're implementing the feature within Platform Debug, you
won't need to worry about access internal APIs. For features you
mentioned that have to do with type or name pattern matching, IMO it
would be better handled through filtering or a search, rather than a
specialized expand action.
JDT and Platform Debug are separate and the trade
off is that if you
write the feature in Platform Debug you'll have access to the internals
of the viewers, but you won't be able to access the java type
information. And the other way around if you write the feature for
JDT.
I don't think I will need Java type information if the type is modeled
within Platform Debug APIs. What do you think?
To summarize, this is a student proposal and most things are uncertain.
You(Eclipse Developers) are the ones who should say me "It is better to
do this, instead of that". Like a lot of unexperienced people, I am not
sure which way I should go. You can guide me.
Thanks for your help.
You're welcome.
-Pawel
On Mon, Mar 30, 2009 at 10:22 PM, Pawel
Piech <pawel.piech@xxxxxxxxxxxxx>
wrote:
Ali Ok wrote:
Hi,
I would like to implement this. I haven't implemented before. The video
or the pictures were about current "variables view".
I first thought about "specialized Copy action" like you said, however
current copy action already copies what has expanded in the view. So
the problem is, expanding the variables.
If you(or someone else) are willing to mentor me, I can change the
proposal to "specialized Copy action", if that is the best.
I'm afraid I don't have the time this year to participate in GSoC as a
mentor, but I'll be happy to answer quick questions on the mailing
list. BTW, I also expect to leave soon on family leave for a few weeks.
We've also talked in platform debug team about debug view search
action, which would search N levels deep. In principle it would be
very similar to the Copy N levels action that we're referring to here.
The copy vs. expand is a question of consistency with other UI, and
thus usability.
One major problem that you're going to encounter
is that if you would
like to make your feature work with any debugger (and thus be
applicable in the Platform Debug project), you cannot make your feature
dependent on the debug model information. So features like "exapand
static variables" are not practical to implement, and also are more
appropriately solved with view filters rather than expand action
variants. Really the only variants of your feature that I can see
being practially implemented is "copy n levels" and "copy
(exclude/include matches of regexp).
I was thinking of using reflection API for expanding operations, or the
mechanism used in current expand (+) buttons. Will this operation
depends on debugger?
I guess I'm not sure what is the end goal of your changes. If you
would like to submit your feature as an enhancement patch, it's not
likely to be accepted if it uses internal APIs (even more so if it uses
reflection to gain access to APIs). If your goal is to create an
add-on plugin, you can use whatever APIs you like, but your work is not
going to reach nearly as many users.
I think Platform-Debug and JDT-Debug is different, right? This button
will be available in Java debugging process. So, the main problem here
is, I have forgotten writing this to my proposal .
Support for other languages will be impossible using just Java
Reflection API. So, other languages are not going to be supported.
I will update my proposal after some confirmation from you.
JDT and Platform Debug are separate and the trade off is that if you
write the feature in Platform Debug you'll have access to the internals
of the viewers, but you won't be able to access the java type
information. And the other way around if you write the feature for
JDT.
Cheers,
Pawel
Thanks for the comments,
On Mon, Mar 30, 2009 at 7:24 PM, Pawel
Piech <pawel.piech@xxxxxxxxxxxxx>
wrote:
Hi Ali,
I wasn't sure what GSoC stood for until now, so now I unserstand that
this is a proposal for work you would like to perform rather than
something you've alreay implemented.
My suggestion is that rather than implementing a specialized expand
action, you should implement a specialized Copy action. I would create
a single "Copy Special..." action which opens a dialog where you can
specify additional parameters.
One major problem that you're going to encounter is that if you would
like to make your feature work with any debugger (and thus be
applicable in the Platform Debug project), you cannot make your feature
dependent on the debug model information. So features like "exapand
static variables" are not practical to implement, and also are more
appropriately solved with view filters rather than expand action
variants. Really the only variants of your feature that I can see
being practially implemented is "copy n levels" and "copy
(exclude/include matches of regexp).
Cheers,
Pawel
Ali Ok wrote:
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
|