showCompleter added to leoQtBody
Ville M. Vainio
In the interest of drawing some attention to getting the ui side
working (keyhandling mostly), I now moved the gui part of the
completer to core (qtGui.py).
So basically, you can now test the completer by running (ctrl+b) the
following script:
w = c.frame.body
def sel(arg):
print "selected",arg
w.showCompleter(['hello', 'helloworld', 'foobar', 'bazman'], sel )
As you can see, it still needs a bit of work - namely, pressing
"enter" should trigger the call to 'sel' instead of inserting linefeed
to the text body. This can be done by redirecting all keypresses to
completer widget instead of body control when completer is active.
--
Ville M. Vainio
http://tinyurl.com/vainio
VR
On 23 Dez., 15:20, "Ville M. Vainio" <vivai...@gmail.com> wrote:
> As it appears, testing the completer requires quite a bit of setup work.
>
> In the interest of drawing some attention to getting the ui side
> working (keyhandling mostly), I now moved the gui part of the
> completer to core (qtGui.py).
What is the chosen strategy/ tactic to move parts of a specific
GUI-Implementation into the generic Leo-Core?
Kind regards,
Viktor
Ville M. Vainio
> What is the chosen strategy/ tactic to move parts of a specific
> GUI-Implementation into the generic Leo-Core?
It's a choice of semantics - I tend to call the gui plugin part of the
"core" (as opposed to actual plugins for "optional functionality").
Moving this to "core" allows creating a Tk specific implementation as
well, instead of catering for different guis in plugins itself (or,
more commonly, making the plugin "qt only").
VR
On 23 Dez., 15:33, "Ville M. Vainio" <vivai...@gmail.com> wrote:
> On Wed, Dec 23, 2009 at 4:28 PM, VR <viktor.ransm...@gmail.com> wrote:
> > What is the chosen strategy/ tactic to move parts of a specific
> > GUI-Implementation into the generic Leo-Core?
>
> It's a choice of semantics - I tend to call the gui plugin part of the
> "core" (as opposed to actual plugins for "optional functionality").
>
> Moving this to "core" allows creating a Tk specific implementation as
> well, instead of catering for different guis in plugins itself (or,
> more commonly, making the plugin "qt only").
Thanks for the clarification. - I just updated to r2559 and found out
in
parallel that no leo/core/ files were changed/ updated ...
Kind regards,
Viktor
Edward K. Ream
> As it appears, testing the completer requires quite a bit of setup work.
>
> In the interest of drawing some attention to getting the ui side
> working (keyhandling mostly), I now moved the gui part of the
> completer to core (qtGui.py).
Imo the completions provided by exuberant ctags are not nearly good
enough. I particularly am concerned that a) too many useless
completions are offered and b) no completions for ivars are given.
I doubt that the hacks that Leo uses (effectively!) for completion
within Leo itself can be generalized. At present, I consider the
OpenKomodo/codeintel scheme to be the gold standard. This is a massive
package, but it is worth studying because it delivers the goods.
Edward
Ville M. Vainio
> Imo the completions provided by exuberant ctags are not nearly good
> enough. I particularly am concerned that a) too many useless
> completions are offered and b) no completions for ivars are given.
What do you mean by useless completions?
Currently, if the class can't be determined, it just offers expansions
for all functions. This can be fixed by improving class guessing
strategy (which is trivial ATM).
Ivar scanning can be added to codewise - it already supports scintilla
api files in addition to exuberant ctags. Exuberant ctags is just a
mechanism that provides us "cheap" code analysis (for multiple
languages, not just python).
> I doubt that the hacks that Leo uses (effectively!) for completion
> within Leo itself can be generalized. At present, I consider the
> OpenKomodo/codeintel scheme to be the gold standard. This is a massive
> package, but it is worth studying because it delivers the goods.
I agree about quality of OpenKomodo completers - on the other hand,
that is a bit besides the point. Here, I'm just talking about fixing
the key handling to allow QCompleter based scheme to work properly.
When it does, codewise completer can be used as "good enough"
completer until the huge project of incorporating komodo code analysis
is done (if ever - having SOME sensible completion scheme in place
would serve us for years). Best is the enemy of good.
Edward K. Ream
> On Thu, Dec 24, 2009 at 11:03 PM, Edward K. Ream <edre...@gmail.com> wrote:
>
>> Imo the completions provided by exuberant ctags are not nearly good
>> enough. I particularly am concerned that a) too many useless
>> completions are offered and b) no completions for ivars are given.
>
> What do you mean by useless completions?
My apologies for the clumsy way I changed topics here. What happened
was that I haven't been convinced that the advice that can be offered
based on ctags would be good enough.
> Currently, if the class can't be determined, it just offers expansions
> for all functions. This can be fixed by improving class guessing
> strategy (which is trivial ATM).
Atm = at the moment?
> Ivar scanning can be added to codewise - it already supports scintilla
> api files in addition to exuberant ctags. Exuberant ctags is just a
> mechanism that provides us "cheap" code analysis (for multiple
> languages, not just python).
I am encouraged that the advice can, indeed, be improved. Imo, the
ctags data is what is at issue here. Until I am convinced that it is
good enough, the gui issues seem secondary, particularly because the
gui issues are difficult to get right.
> I agree about quality of OpenKomodo completers - on the other hand,
> that is a bit besides the point. Here, I'm just talking about fixing
> the key handling to allow QCompleter based scheme to work properly.
I felt I had to voice my concerns sometime, and those concerns would
always be "ot" of the present discussion.
> When it does, codewise completer can be used as "good enough"
> completer until the huge project of incorporating komodo code analysis
> is done (if ever - having SOME sensible completion scheme in place
> would serve us for years). Best is the enemy of good.
I agree completely.
Edward