[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [recommenders-dev] [snipmatch] worse popup behavior
|
I think, we need to split and distribute the workload for the critical tasks.
From my end, it looks as follows:
Chen can work on SnipMatch "full" time from July. Before that date he shouldn't do any work on the (very) critical path.
The completion frontend/ui _is_ a critical thing to me.
Things like repository upload, template editing, git support etc. isn't required for M7 and might even not be needed for Juno at all (although we all would love to see it in), and thus, it all boils down to a few things:
* be able to download a zip from a repository, unpack, and index its contents.
* do this whenever the zip file on the server side changes
* have an excellent completion popup with a table viewer with dynamic contents and proposal previews as we know it from JDT
* use JDT's templates API to make it work 'smoothly', i.e, (re-) use JDT's template proposals + preview popup etc.
I think the completion popup is the most critical thing that will consume _a lot_ of time. To give an estimation: I think it will need ~3 weeks full time to do it and being sure it works afterwards :) Doug, since you know your tool best, I think this task is best located in your hands. I can assist you when it comes to details like highlighting in table viewers or using lazy content providers etc. But in its core, you (an Zi) are the pros here.
I can also assist on the search interface and automated model download, unzip, and index part. I actually planed the indexing part for mid of April.
Chen can do lot's of ui improvements like preference pages, cleanups, and start working on the "flexible repository modules" concept as warmup for the GSOC. I think there is much to do but we shouldn't rely on him doing the critical work until M7 :)
After all, I think it depends on how much time we can invest into this until M7. I'm heavily involved in the completion and code search projects. Johannes and Sebastian are working on the mining approaches. The other students have their separate projects (codesearch, annotation mining, multi-object pattern mining etc.) and cannot assist. Doug, honestly I think it's time you check in the code and start working on it to make Snipmatch happen ;)
FWIW, I agree with all your UI constraints below.
On 23.03.2012, at 15:20, Doug Wightman wrote:
> I agree that we absolutely need downloading and indexing of repositories.
>
> In terms of displaying and inserting code snippets, reusing existing
> (stable) code sounds good. However, I want to ensure that we won't
> lose the following features:
> -you still search in a search box, and you can include arguments (e.g.
> local variables) in the search query. Note: with templates, these
> arguments would then be used to pre-fill the templates.
> -the result listing updates as you type
>
> So long as we retain these two features, these changes make sense to
> me. If either is at risk, let's explicitly discuss.
>
> Given the timeframe, it might make the most sense to build each of
> these changes (repository integration + new display system) in the
> next 6 weeks: splitting the time between the two of them, then
> polishing afterwards. But Marcel is in a much better position to judge
> timeline and priorities. I really appreciate your feedback - it's
> critical that we have a strong offering for M7.
>
> I also want to hear from Chen: is this reasonable for you? Is there
> anything that you think we need to cut?
>
>
> Doug
>
>
>
>
> On Fri, Mar 23, 2012 at 8:27 AM, Chen Cheng <chengchendoc@xxxxxxxxx> wrote:
>> The only problem is the time, if we change display module now, we have too
>> much things to do, we should decide the priority
>>
>>
>> 2012/3/23 Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx>
>>>
>>>
>>> On 23.03.2012, at 11:49, Chen Cheng wrote:
>>>
>>> It seems that time is really emergency for us. About the two features:
>>>
>>> * downloading and indexing a local repository
>>>
>>> You mean current local search module, add EGit module to download snippet
>>> files from remote repository automatic. And with some preference pages,
>>> right ?
>>>
>>>
>>> Exactly.
>>>
>>>
>>> * code completion engine based on Eclipse standard features like templates
>>> and Linking mode
>>>
>>> You mean abandoned current match result display module, change to Eclipse
>>> standard features. I am not very clear what your words "templates and
>>> Linking mode" mean, but i think the new search result display will looks
>>> like Java Class Editor's content assist(see attach file assist.png), right ?
>>>
>>>
>>> Yes. I'm proposing to reuse JDT's template framework for now. With linking
>>> mode I refer to "the placeholders can be navigated by tab" feature of JDT's
>>> templates . It also offers functionality like guessing arguments for
>>> template variables.
>>>
>>>
>>> Anyway, current match result display module works, but i don't think it is
>>> a long term solution, if you mean change it. I agree.
>>>
>>>
>>> Standing by for Doug's opinion. Must be 6AM in Canada ;)
>>>
>>> Thanks
>>> Marcel
>>>
>>>
>>>
>>> 2012/3/23 Marcel Bruch <marcel.bruch@xxxxxxxxx>
>>>>
>>>> Hi Chen,
>>>>
>>>> this fix looks good to me and is good to go for EclipseCon demo. Thanks a
>>>> lot.
>>>>
>>>>
>>>> I'd like to initiate a discussion about how the whole template code
>>>> insertion & display mechanism should look like for Juno - and discuss the
>>>> important milestones.
>>>>
>>>> M6 is today. M7 is in 6 weeks and then projects do a feature freeze,
>>>> i.e., all the time is put into testing, bug fixing and small improvements.
>>>> Projects like JDT or RAP have feature freeze since M6 already. I'm a bit
>>>> concerned that we'll run out of time to deliver a stable version of
>>>> snipmatch. Doug, Zi, Cheng, how do you think about that?
>>>>
>>>> I'd propose to focus on just a few features and make them as stable as
>>>> possible for Juno.
>>>>
>>>> Features could include:
>>>> * downloading and indexing a local repository
>>>> * code completion engine based on Eclipse standard features like
>>>> templates and Linking mode
>>>>
>>>> Although I love the "insert directly in code" and the custom popup
>>>> feature very much, I think, they are not stable and fast enough yet. I'm
>>>> concerned that the success of Snipmatch depends on usability and that it
>>>> will be hard to convince package owners to include it. I'll talk to some
>>>> package maintainers at EclipseCon to learn about their requirements but
>>>> before that I'd like to know your opinions on this.
>>>>
>>>> Thanks,
>>>> Marcel
>>>>
>>>>
>>>>
>>>> On 23.03.2012, at 03:25, Chen Cheng wrote:
>>>>
>>>> Hi Marcel,
>>>>
>>>> I have fixed this issue, the popup window will not cover the inserted
>>>> code anymore, and submit source code already.
>>>>
>>>> About the other issue "Is it possible to run the code without revealing
>>>> the active editing position?", my current answer is NO, it seems that the
>>>> "scrolls" job was done by editor itself, we can not fix it easily now. But i
>>>> will add this into my TODO list and find solution in the future, in fact, we
>>>> have plan to improve the whole search result display canvas.
>>>>
>>>> 2012/3/22 Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx>
>>>>>
>>>>> Hi Chen,
>>>>>
>>>>> I experienced a serious issue for the snipmatch demo:
>>>>>
>>>>> When I trigger completion at an empty location, enter "file", wait for
>>>>> proposals and then scroll trough the proposals the popup window completely
>>>>> covers the inserted code. With that behavior, we can't see the code that
>>>>> gets inserted by snipmatch.
>>>>>
>>>>> Can you reproduce that? What can we do with this?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Marcel
>>>>>
>>>>> --
>>>>> Eclipse Code Recommenders:
>>>>> w www.eclipse.org/recommenders
>>>>> tw www.twitter.com/marcelbruch
>>>>> g+ www.gplus.to/marcelbruch
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> recommenders-dev mailing list
>>>>> recommenders-dev@xxxxxxxxxxx
>>>>> http://dev.eclipse.org/mailman/listinfo/recommenders-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Best Regards From Cheng Chen [chengchendoc@xxxxxxxxx]
>>> <assist.png>_______________________________________________
>>>
>>> recommenders-dev mailing list
>>> recommenders-dev@xxxxxxxxxxx
>>> http://dev.eclipse.org/mailman/listinfo/recommenders-dev
>>>
>>>
>>> Thanks,
>>> Marcel
>>>
>>> --
>>> Eclipse Code Recommenders:
>>> w www.eclipse.org/recommenders
>>> tw www.twitter.com/marcelbruch
>>> g+ www.gplus.to/marcelbruch
>>>
>>>
>>> _______________________________________________
>>> recommenders-dev mailing list
>>> recommenders-dev@xxxxxxxxxxx
>>> http://dev.eclipse.org/mailman/listinfo/recommenders-dev
>>>
>>
>>
>>
>> --
>> 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
Thanks,
Marcel
--
Eclipse Code Recommenders:
w www.eclipse.org/recommenders
tw www.twitter.com/marcelbruch
g+ www.gplus.to/marcelbruch
