Re: [gedit-list] Completion Status

[Jesse van den Kieboom <jesse icecrew nl>]

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.
> 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.
> 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).


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
>