Re: [gedit-list] Completion Status

[Jesse van den Kieboom <jessevdk gnome org>]

perriman wrote:
> 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?
>   
Here it gets a bit tricky. The provider does not care about how the 
underlying model is implemented, the only thing  it knows, is that when 
it's done (and it needs to let the context know), the only visible items 
from him in the completion model are the ones he has been adding.

The question as you rightly put it here is how to do this. I can think 
of two possible solutions:

1) The checking for keep/remove/add stuff is only done on the first 
batch of proposals from each provider. This might be a bit inefficient 
for async providers, since a lot of items might not have changed, but 
will be removed and added again because they are added in later batches.
2) Add new proposals in every batch and mark unchanged proposals at the 
same time. When the provider finishes, delete all the items that should 
no longer be present. The disadvantage of this is that when a provider 
takes maybe 2 seconds to fully load, and the sets of proposals are very 
different, you will have many proposals which do not really belong to 
the current criteria.

I'm not sure which solution is best, and maybe there are other 
possibilities too. We could try implementing both strategies (should not 
be too difficult) and see what works best.


Jesse
>   
> > > 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.
>   
That said, we will probably need a way for providers to signal the 
context that they are finished adding proposals (gsc_context_finished or 
something).

> 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
> > >   
> > >       
>
> _______________________________________________
> gedit-list mailing list
> gedit-list gnome org
> http://mail.gnome.org/mailman/listinfo/gedit-list
>