On Sun, Mar 25, 2012 at 10:02 AM, Marcel Bruch <
marcel.bruch@xxxxxxxxx> wrote:
>
> 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
>
>
>
> _______________________________________________
> recommenders-dev mailing list
>
recommenders-dev@xxxxxxxxxxx
>
http://dev.eclipse.org/mailman/listinfo/recommenders-dev
>
_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev
