Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [recommenders-dev] [DISCUSS] Solution about snipmatch's search result display module


On 25.03.2012, at 09:45, Chen Cheng wrote:

Hi Marcel,

Wish a nice trip in  Washington :-)

2012/3/25 Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx>
Hi,

> So, we want to change current solution. But, do we *have to* extend JDT's content assist ? Is it the *only* solution?

maybe I confused you guys more than I helped. Let me try to sort out things that may have made a wrong impression ;)

JFace has a basic content assist framework that provides base implementations for all aspects of code completion.
This framework is extended by JDT with many features. But to be clear, I'm not advocating for using JDT's content assist completely but a very small subset of their system, namely, org.eclipse.jdt.internal.ui.text.template.contentassist.TemplateProposal and its related classes. The content assist popup etc. still needs to be written by ourselves. We may integrate the org.eclipse.jface.text.contentassist.ContentAssistant but we may not have to!

So, if we can implement a smart, fast enough search result display canvas, it is enough, right ?

In my opinion: yes.

Not necessary *have to* re-use org.eclipse.jface.text.contentassist.ContentAssistant,This is actually what i want.

 Using a framework like JFace content assist makes sense if things reach a certain level of complexity and require extensibility. I think it's not yet needed (for Eclipse 4.2). 

 

From my view point it's all not that complicated ;)

We need:
* a popup text widget that consumes user input and triggers search  (already there)
* a popup that display search results (for a given search input) in a table below with some minimal highlighting
* a class that creates TemplateProposal from SnipMatch's code snippets.
 
Even this TemplateProposal class is not necessary,we have already our data model, can do what TemplateProposal  do.


This may become more tricky. Template insertion into the current editor is quite complex stuff. Since snipmatch is basically using JFace template language, reusing these templates wouldn't  be a bad decision.  But I think we can postpone this decision a bit :)


* proposal preview popup (this is what we might reuse form JDT here)

I am not very clear how to re-use the preview popup without JDT's content assist, but this component is easy even if we create our own.


Same as above. It's the nitty-gritty details that might already by solved by JDT. But we'll see how this works out.



All in all, I'm speaking about, say 10 classes, just to give you a feeling of the overall complexity I expect.
 
I've unfortunately no time until Wednesday. But then I can take a look on the content assist thing.

An idea on how to continue:
Chen, can you look into how to create a JFace TableViewer popup with changing contents, i.e, a TableViewer in Shell object that get's triggered instead of snipmatch's current completion popups? It should take the code snippets data structure we already have and display the summary in it. If you progress fast you can look into http://wiki.eclipse.org/JFaceSnippets#Snippet010OwnerDraw .  OwnerDraw is needed to render the variables in the proposal's display text properly.

Yes, this is what i am doing. I am trying to find solution about creating a Shell with Table in it to display snipmatch search result.


Great! Looking forward to learn from your experiences.


 

From this, it should actually be a small step to replace the current popup code. Adding a listener to the TableViewer to respond to selection changes, to "return pressed", and one to the window for "escape pressed" and "that's it" - in a basic version - in theory. You know that in theory there is no difference between theory and reality, right? :-)

Actually, it is what i am thinking :-D

what exactly? no difference between theory and reality? ;)

Best,
Marcel


 

Best wishes from Washington.



Doug, I will add this search result re-write job into my GSoC proposal, and update the time schedule. We will be concentrate in this part of job before May 1.
 


On 25.03.2012, at 00:15, Chen Cheng wrote:

If possible, we can choose re-build a fast enough, JDT content assist similar search result component, rather than re-use JDT's content assist mechanism. During my survey job, i found JDT's content assist is really not so applicable with SnipMatch's scene here. It will be so hard if we force to fit into JDT content assist, or even can not find a clear solution.

Marcel might be on his flight now, let's wait for his voices.



--
Best Regards From Cheng Chen [chengchendoc@xxxxxxxxx]
_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev


Back to the top