How to call functions from LeoPyRef.Leo

[Fidel Pérez]

Hi, I am going through something similar Matt Wilkie went through in this post.

Basically I can find interesting functions in LeoPyRef.leo but I dont know how to access them from my new leo scripts.

I dont get the difference when I have to call them using g.Functionname(), c.functionname(), or when those wont do.

How can I call the function "insertIconFromFile"?

How can I know how to call functions found in LeoPyRef.leo?

Thanks!

Pd: When I get that, I will already have a bookmarks importer from chrome/mozilla which will also import the icons of the links! x)

I will prepare some more interesting utils (import mindmap, etc) then release them together with manuals oriented to noob users.

[Fidel Pérez]

Ok, in order to print icons, the code is this:

c.editCommands.insertIconFromFile(path)

Im quoting from this Leo manual, "inserting and deleting icons" section -_-

Although I still have a mess on which functions can be called how, and where to find the list of classes that can be called such as "editCommands" and the rest that they might exist.

Thanks!

[Terry Brown]

On Mon, 20 May 2013 04:00:59 -0700 (PDT)
Fidel Pérez <fidel...@gmail.com> wrote:

> Ok, in order to print icons, the code is this:
>
> c.editCommands.insertIconFromFile(path)
>

> Im quoting from this Leo manual<http://leoeditor.com/scripting.html#import-objects>,

> "inserting and deleting icons" section -_-
>
> Although I still have a mess on which functions can be called how, and
> where to find the list of classes that can be called such as "editCommands"
> and the rest that they might exist.

I'm not aware of a general solution to the problem of finding the
various pieces of Leo's class structure. Basically there are all these
classes defined in the source, and instances of these are attached to
each other in a hierarchical network (with loops).

I've written an introspection function which lists the methods and
instance variables (and class variables) of an arbitrary object by name
and by type. I should release it. It builds its lists in a Leo
outline, so you can navigate around that outline and expand nodes by
introspection as needed.

It occurs to me that the same code could be used to search Leo's
runtime object hierarchy for you, i.e. you enter 'insertIconFromFile'
and it recursively searches for it.

Cheers -Terry

[Fidel Pérez]

Sounds great!

So, in the search results, will I be able to know how to call that function?

IE, if I find insertIconFromFile, will I be able to know that I can call it through using c.editCommands.insertIconFromFile?

[Terry Brown]

On Mon, 20 May 2013 08:47:35 -0500
Terry Brown <terry_...@yahoo.com> wrote:

> On Mon, 20 May 2013 04:00:59 -0700 (PDT)
> Fidel Pérez <fidel...@gmail.com> wrote:
>
> > Ok, in order to print icons, the code is this:
> >
> > c.editCommands.insertIconFromFile(path)
> >
> > Im quoting from this Leo manual<http://leoeditor.com/scripting.html#import-objects>,
> > "inserting and deleting icons" section -_-
> >
> > Although I still have a mess on which functions can be called how, and
> > where to find the list of classes that can be called such as "editCommands"
> > and the rest that they might exist.
>
> I'm not aware of a general solution to the problem of finding the
> various pieces of Leo's class structure. Basically there are all these
> classes defined in the source, and instances of these are attached to
> each other in a hierarchical network (with loops).

I didn't really finish the above para. The problem is that it's hard
to guess what the names of the attachment points are, and the attaching
is done in a variety of places, sometimes by factory functions which
further obscure linkages. Not a fault with Leo, just the way programs
work. So the tool I've written may be the best approach to mapping
Leo's runtime structure. Another thing it could do, try and map 'major'
classes, or at least classes from leo.core.* - i.e. ignore the built in
types.

Cheers -Terry

[Edward K. Ream]

On Mon, May 20, 2013 at 8:47 AM, Terry Brown <terry_...@yahoo.com> wrote:

On Mon, 20 May 2013 04:00:59 -0700 (PDT)
Fidel Pérez <fidel...@gmail.com> wrote:

> Although I still have a mess on which functions can be called how, and
> where to find the list of classes that can be called such as "editCommands"
> and the rest that they might exist.

I'm not aware of a general solution to the problem of finding the
various pieces of Leo's class structure.  Basically there are all these
classes defined in the source, and instances of these are attached to
each other in a hierarchical network (with loops).

I suppose you could say that there is no general solution, but the situation isn't really all that difficult.

Start with c.  We know what that is:  it is a commander object representing an open outline.

There are **official ivars** of c, all referring to wrapper classes defined in leoFrame.py:

c.frame: an instance of leoFrame.
c.frame.tree: an instance of  leoTree.

c.frame.body: an instance of leoBody.

c.frame.log: an instance of leoLog.

The tree, body and log objects have a *ctrl* objects, which are *wrapper* classes:

c.frame.tree.treeCtrl

c.frame.body.bodyCtrl

c.frame.log.logCtrl

In particular, see http://leoeditor.com/scripting.html#c-frame-body-bodyctrl for a description of the high-level text interface supported by all high-level text widgets, including the log and body classes.

These wrapper classes have a widget ivar, which is a reference to the corresponding Qt widget object.  For example::

    import PyQt4.QtGui as QtGui
    w = c.frame.body.bodyCtrl.widget
    g.es(w)
    g.es(isinstance(w,QtGui.QTextBrowser)

yields::

    (LeoQTextBrowser) 62418136

    True

As shown, the LeoQTextBrowser class is a real (subclass of) QTextBrowser.

HTH.  I've made a note to discuss official ivars in more detail in the scripting chapter.

Edward

[Terry Brown]

On Mon, 20 May 2013 14:11:02 -0500
"Edward K. Ream" <edre...@gmail.com> wrote:

> On Mon, May 20, 2013 at 8:47 AM, Terry Brown <terry_...@yahoo.com>wrote:
>
> > On Mon, 20 May 2013 04:00:59 -0700 (PDT)
> > Fidel Pérez <fidel...@gmail.com> wrote:
> >
>
> > Although I still have a mess on which functions can be called how, and
> > where to find the list of classes that can be called such as
> "editCommands"
> > and the rest that they might exist.
>
> I'm not aware of a general solution to the problem of finding the
> > various pieces of Leo's class structure. Basically there are all these
> > classes defined in the source, and instances of these are attached to
> > each other in a hierarchical network (with loops).
> >
>
> I suppose you could say that there is no general solution, but the
> situation isn't really all that difficult.

But how does that help with the example of wanting to find
insertIconFromFile? You need to know it's a member of editFileCommandsClass, which isn't an unreasonable requirement. But where's editFileCommandsClass attached? c.editFileCommands, which also seems reasonable, but c.<class name without Class> is not a general recipe for finding things, it only works in a handful of cases. c.frame.body.getSelectedText() is a good example. It's easy to find if you already know where it is, but it's not c.frame.body.bodyCtrl.getSelectedText(). I know it's something I spend of lot of time searching through, although I don't think it's a fault with Leo, just a complexity problem.

The search function is proving a lot harder than the Leo outline based
introspector, which only descends into nodes when you explicitly ask it
to.

Cheers -Terry

> Start with c. We know what that is: it is a commander object representing
> an open outline.
>
> There are **official ivars** of c, all referring to wrapper classes defined
> in leoFrame.py:
>
> c.frame: an instance of leoFrame.
> c.frame.tree: an instance of leoTree.
> c.frame.body: an instance of leoBody.
> c.frame.log: an instance of leoLog.
>
> The tree, body and log objects have a *ctrl* objects, which are *wrapper*
> classes:
>
> c.frame.tree.treeCtrl
> c.frame.body.bodyCtrl
> c.frame.log.logCtrl
>
> In particular, see

> http://leoeditor.com/scripting.html#c-frame-body-bodyctrlfor a

[Terry Brown]

On Mon, 20 May 2013 14:33:49 -0500
Terry Brown <terry_...@yahoo.com> wrote:

> The search function is proving a lot harder than the Leo outline based
> introspector, which only descends into nodes when you explicitly ask it
> to.

Hmm, here's the latest output:

for insertIconFromFile

c.editCommands.insertIconFromFile

ok, great... for getSelectedText

c.miniBufferWidget.getSelectedText
c.abbrevCommands.w.getSelectedText
c.bufferCommands.w.getSelectedText
c.chapterCommands.w.getSelectedText
c.controlCommands.w.getSelectedText
c.debugCommands.w.getSelectedText
c.editCommands.w.getSelectedText
c.editFileCommands.w.getSelectedText
c.frame.body.getSelectedText
c.frame.log.getSelectedText
c.frame.miniBufferWidget.getSelectedText
c.gui.bodyTextWidget.getSelectedText
c.helpCommands.w.getSelectedText
c.k.w.getSelectedText
c.keyHandlerCommands.w.getSelectedText
c.killBufferCommands.w.getSelectedText
c.leoCommands.w.getSelectedText
c.macroCommands.w.getSelectedText
c.miniBufferWidget.__class__.getSelectedText
c.rectangleCommands.w.getSelectedText
c.registerCommands.w.getSelectedText
c.searchCommands.w.getSelectedText
c.spellCommands.w.getSelectedText

but this takes a really long time, I need to work out what's the
bottleneck. It searches breadth first, and searches to the depth n+1
where n is the depth at which it finds the first hit.

Of course those searches were started at 'c' - perhaps you need to
start a little more specifically, but there are 551 ivars on c... so
that's not that easy. Ahem, including

universalCallback instancemethod
universallCallback instancemethod

Cheers -Terry

[Fidel Pérez]

Hehehe great outcome about the inserticonfromfile!!

Well its good for starters and giving an idea, from there is just easy to make a script which wraps them all with g.es(xxx)

and the one which shows the result is the one!

[Edward K. Ream]

On Mon, May 20, 2013 at 2:33 PM, Terry Brown <terry_...@yahoo.com> wrote:>

>  I suppose you could say that there is no general solution, but the situation isn't really all that difficult.

But how does that help with the example of wanting to find
insertIconFromFile?  You need to know it's a member of editFileCommandsClass, which isn't an unreasonable requirement.  But where's editFileCommandsClass attached?

You have to know about subcommanders.  See c.initObjects.  Yes, initing commanders is very complicated...

EKR

[Fidel Pérez]

I am working on a general solution which, to my understanding, will represent a big step towards solving this for new users.

On Sunday, May 19, 2013 12:43:50 PM UTC+2, Fidel Pérez wrote:

[Fidel Pérez]

Another quick question on the same topic:

How to call a function within a plugin?

For instance:

makeScriptButton within tkGui.py ?

[Edward K. Ream]

On Tue, May 21, 2013 at 8:00 AM, Fidel Pérez <fidel...@gmail.com> wrote:

Another quick question on the same topic:

How to call a function within a plugin?

Great question.

The best solution, in general, is to create a per-commander controller class.  See::

    leoPlugins.leo#Plugins-->  Templates-->
    Template for plugins with per-commander controller class

Then, in event handlers, the code will be something like this::

def handle_event(keywords):

    c = keywords.get('c')
    if c:

        << handle the event >>

There are many examples of this pattern in leoPlugins.leo.  Just search for .get('c') or .get("c")

HTH

Edward

[Fidel Pérez]

Appreciate it. This will go in the manual too.

Thanks!

On Sunday, May 19, 2013 12:43:50 PM UTC+2, Fidel Pérez wrote: