Re: [gedit-list] Completion Status

[perriman <chuchiperriman gmail com>]

Thank you very much for explain me the idea. I write some comments under
the text

El jue, 30-07-2009 a las 22:17 +0200, Jesse van den Kieboom escribió:
> perriman schreef:
> > Hi,
> >
> > 	I'm thinking about the completion context. I write some ideas and you
> > can tell me if it is what you want:
> >
> > CompletionContext
> > -----------------
> > 	- get_capability () 
> > 		* Event how produces the completion
> > 		("standard::interactive","standard::automatic" 
> > 		or another custom call)
> > 	- set_proposals (provider, proposals_list)
> > 	- add_proposals (provider, proposals_list)
> > 	- get_proposals (provider): proposals_list
> >   
> Basicly, the idea of CompletionContext would be to provide the context 
> of completion to the providers (for instance, it could contain the 
> language) and to allow the providers to add proposals according to this 
> criteria. This could probably also be implemented without an explicit 
> extra context object (though I kind of like the abstraction). By doing 
> this, we can also allow asynchronous loading of the model, for providers 
> that might take some time. These can keep the context around and add 
> proposals whenever they are ready. This does require some way to cancel 
> a context (maybe a signal on the context object to which async providers 
> can connect).
> 
> The idea of 'capabilities' was introduced, but decided it was not a very 
> good overall solution. There is a difference between how a completion 
> was activated (e.g. by interactive, accelerator or maybe a private 
> completion popup) and what the criteria for filtering are (can be 
> language, current word, etc). Arguably, interactive completion and 
> invoking a completion with an accelerator are the same kind of 
> activation, since when you invoke it manually is just a way of forcing 
> the dialog to appear without first typing something.

OK

> > Provider
> > ---------
> > 	- populate_completion (context)
> > 		* The provider must add the proposals with
> > 		context->set_proposals
> > 	- filter_proposals (context)
> > 		* The default implementation filter by label
> > 		* The provider can overwrite it and filter the current
> > 		proposals doing something like context.get_proposals,
> > 		some filters and context.set_proposals
> > 	- completion_finished (context)
> > 		* The provider can free cached data
> >
> >   
> I remember we reached the conclusion that populating the completion 
> model, and subsequently filtering it was not a very elegant solution. 
> Ignacio has started working on a different way of populating the 
> completion model in his github branch. The idea is that we'll simply ask 
> the providers to populate the popup while in interactive mode. By 
> allowing hash functions on proposals, we can then be smart/fast on 
> removing proposals that are no longer needed, and adding new ones (thus 
> not clearing and refilling the whole model). This should make it both 
> easier for providers, and it should speed up the initial filling of the 
> model considerably.

OK. If the provider adds all the proposals at once, there is no problem
because the context can remove and add proposals from the model. If the
provider adds proposals by pieces (by example the provider reads in a
thread and adds 10 proposals, then 10 more etc), the context will remove
all the proposals in the model less the 10 first proposals added. Is it
ok or the provider must call to context.remove_proposals and
context.add_proposals by hand?


> > The completion will do:
> >
> > 1.- User press <Control>Space to show the completion 
> > 2.- Completion creates the context
> > 3.- Completion call populate_completion to all the providers
> > 4.- If the user writes some char the call filter_proposals on all
> > providers
> > 5.- If the user selects a proposal call to provider.activate_proposal
> > 6.- When the completion ends, call to completion_finished on all the
> > providers.
> >   
> I think it would be more something like the following:
> 1) User types something, or presses <Control><something>
> 2) If there is still a context active, cancel it
> 3) Completion builds the context, given the activation and criteria 
> (language, iter, ...)
>     This includes selecting the providers that match the criteria
> 4) The context asks all providers to set their solutions in the context 
> (can be sync, async)
> 5) Context proxies the proposals that are being added to the completion 
> model which inserts them in a smart way
> 
> I'm not sure about having completion_finished, is that really necessary? 
> If a provider caches something, he probably wants to keep it around for 
> the next completion anyway (since there can be many). It can free the 
> cache when it's no longer needed (e.g. on finalization).

I think completion_finished is not necessary too.

Thanks 
	Perriman

> 
> 
> Jesse
> > What do you think about?
> >
> > Perriman
> >
> >
> >
> > El mar, 28-07-2009 a las 00:37 +0200, perriman escribió:
> >   
> >> Hi all!!
> >>
> >> 	I have talking with Nacho about the completion changes. I need someone
> >> tell me what is the "context" idea with more detail. 
> >>
> >> 	Currently the completion calls to provider.get_proposals(). I think the
> >> change would be remove this call and add something like
> >> provider.populate_completion (context). The providers could call to
> >> context.add_proposals () sync or async, in a thread, etc like the
> >> provider wants.
> >>
> >> Can you explain me better what is the idea?
> >>
> >> Perriman
> >>
> >>     
> >
> > _______________________________________________
> > gedit-list mailing list
> > gedit-list gnome org
> > http://mail.gnome.org/mailman/listinfo/gedit-list
> >   
>