Re: [gedit-list] Completion
- From: chuchi <jbarbero quiter com>
- To: Jesse van den Kieboom <jesse icecrew nl>
- Cc: gedit <gedit-list gnome org>
- Subject: Re: [gedit-list] Completion
- Date: Tue, 14 Apr 2009 11:13:22 +0200
Hi Jesse,
I will try to do some test with plugins and providers to test all API. I paste the eclipse ContentAssist API reference if you want take a look. IMO, It is the best completion mechanism and it has been used for years and, If you know eclipse, you can see the power of that design. Anyway I'm happy if I can share providers between plugins and I can configure where I want to see the proposals.
El mar, 14-04-2009 a las 10:38 +0200, Jesse van den Kieboom escribió:
Perriman wrote:
> Hi all,
>
> With the new changes Do we need the add_provider and the
> remove_provider? Currently there are no reasons to register providers,
> only passing them on the gtk_source_completion_popup function is enough.
> The only reason for that function is store the auto_providers, the
> providers list is not used (only for check if the provider is registered
> when popup function is called but it is not necessary).
>
Let me explain the rationale of the decisions we made regarding
providers and triggers. There are basicly 3 types of 'triggers' that are
useful:
1) Keybinding
2) Autocomplete
3) Custom invocation
Providers will be able to specify on what kind of event they should be
included in the popup. They will specify whether they react to the
global keybinding, and/or to the auto-complete-while-typing. This
already covers many of the use cases for completions. Furthermore, you
can easily switch between providers in the popup, showing only the
proposals for that particular provider. Use case 3) is for example when
you tab to a snippet placeholder, and want to show a list of possible
default choices. Such a provider will neither respond to the general
keybinding, nor to the auto-complete-while-typing, and will be invoked
by calling gsc_show_completion. We found that all use cases are covered
by implementing this like described, instead of building a special
trigger framework. Note that plugins can still install their own
keybindings, just as they do now, in ways provided already by Gtk+.
> Sincerely, I don't like very much the changes. Currently the completion
> decides that all proposals go to the "All" page. Why the completion
> decides that? I don't like to have all proposals in the "All" page, I
> want only my two pages with their proposals. I think the user (plugins
> or application) must configure an "All" page if he wants that feature.
>
I disagree here, if you don't want some completions to be shown at all,
then you arguably do not really want that particular plugin. We will add
API that allows a provider to be ignored in the 'All' event.
> I remember again we will need to show proposals in the same event from
> different plugins. Currently I have four plugins for gedit using
> completion:
>
> 1.- Document words completion - With three providers: words completion,
> Open Documents Completion, Recent Documents Completion
> 2.- Snippets completion (Symbol completion and symbol goto)
> 3.- Symbols completion
> 4.- Universe commands completion
>
> If I like to show 1, 2, 3 y 4 in the same <control>space event, I cannot
> do it. I will need 4 keybindings (and other for open/recent documents
> provider) or create an unique plugin managing all providers (a lot of
> unnecessary dependencies). We will find these problems in a near future.
>
Why, if you have these plugins, and you want to show them all, then that
is perfectly fine.
> If you don't like the trigger/proposal registration, another way of
> implement the completion is using the "population" technique like the
> popup menu or something like that. It is only an idea because the
> provider is losing the sense slowly.
>
Provider is not losing sense at all, it groups proposals in a meaningful
way and provides ways to show customized context information about them.
For what it is worth, in the context of gedit, you actually _will_ be
able to show any combination of providers, even if they are provided by
different plugins, by means of the GeditMessageBus.
> That is only my opinion, you can do what you want, of course :)
>
> Regards,
> 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
|
Jesús Barbero Rodríguez
Departamento de Análisis y Programación - Desarrollo tecnológico
Zoco Gran Santander, 1ª Planta ■ 39011 Peñacastillo ■ Santander ■ ESPAÑA
Tel.: +34 902 233 323 ■ Fax: +34 902 234 280
|
AVISO LEGAL: Este mensaje contiene información destinada exclusivamente al usuario de destino, pudiendo contener información confidencial o protegida legalmente. Si, por un error de envío o transmisión, ha recibido este mensaje y usted no es el destinatario del mismo, por favor, notifique de este hecho al remitente y no use, informe, distribuya, imprima, copie o difunda este mensaje bajo ningún medio . Cualquier opinión en él contenida, es exclusiva de su autor y no representa necesariamente la opinión de Quiter Servicios Informáticos, S.L.
LEGAL WARNING: This e-mail and any attachment, contain information intended solely for the addressee and may contain confidential information or legally protected data. If you are not the intended recipient, please notify the sender and do not use, disclose, distribute, copy, print or rely on this e-mail under any circumstances. The views and opinions expressed are the authorŽs own and do not necessarily reflect those of Quiter Servicios Informáticos, S.L.
|
|
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]