Re: New ideas re sentinels and sharing

['Terry Brown ' via leo-editor]

On Fri, 25 Apr 2014 08:13:29 -0700 (PDT)
"Edward K. Ream"  wrote:

> - This scheme is only useful when multiple Leonine programmers work
> in a non-Leonine project.  Solo Leonine programmers in a non-Leonine
> project may as well use @shadow or @auto.

First off welcome back and good luck with the hips.  It was kind of
weired how quiet the forum got after reaching a new high of activity -
I'm way overloaded work-wise at the moment, still using Leo all the
time for doing the work, of course :)

I was confused by your post until the above statement - so it's
basically about sharing the content of ~/.leo/shadow?  But you're
thinking of adding some things, sha1 hash of public files for
example, although what that buys you over existing @shadow I'm not
following.

Although it would be cool to share other people's views of files, to me
it's not a priority - I could see each of the 3 Leo users in a 7 person
team having their *own* view of the public files all 7 are sharing.
I use the hierarchical bookmark system to have my own view of LeoPyRef
and LeoPluginsRef, for example.

On the directions for Leo front, supporting Python 3.x / Qt *5*.x
should probably get addressed at some point, even though it's kind of
annoying if we want to keep supporting Qt 4.x simultaneously.
It appears that Riverbank is not making a Python 2.7 Qt 5 combo, so
we'll have to keep 4.x compatibility to go with 2.7.

Poking around the Riverbank site I see they have a new product, 
www.riverbankcomputing.com/software/pyqtdeploy/intro
for deploying PyQt apps cross platform - an installer basically I
think, but PyQt specific.  Although pyqtdeploy itself runs in Python
3.2 / Qt 5 it deploys 2.x/3.x / 4.x/5.x.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: New ideas re sentinels and sharing

['Terry Brown ' via leo-editor]

On Sat, 26 Apr 2014 11:25:41 -0700 (PDT)
Fidel N  wrote:

> I totally agree with Terry here, I think the visual aspect of Leo
> should have more priority.

Just for clarity, my primary thought re targeting Py 3.x / Qt 5.x is
that I think that may be the most current / only target platform
(unless we move to kivy :-) in the future, Riverbank's not supplying
Py 3.x / Qt 4.x builds as far as I can see.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: spatial versioning

['Terry Brown ' via leo-editor]

On Mon, 28 Apr 2014 06:43:45 -0500
Kent Tenney  wrote:

> Standard version control is time-based, my workmethods seem
> to want space-based versioning, IE: the variations I'm considering
> are next to each other, not before and after.
> 
> What would suit me would be a tabbed editor pane. A node would
> offer the capability to create new versions of it's headline and body.
> I would select one to be 'active', the inactive versions could live
> in the UA, only the active one would be visible and written to the
> @auto file on save. Selecting another tab would trigger an
> active/inactive swap.

Adding UI elements makes this into a non-trivial task.  What would be
quick and easy would be some new commands for keys / buttons:

  body-versions-add

Add the current body text as a new entry in the nodes list of
body texts with the name "-MM-DD HH:MM:SS"

  body-versions-commit

Save the current body text as the text for the currently
displayed version

  body-versions-revert

Replace the current body text with the text for the currently
displayed version

  body-versions-delete

Delete the body version currently being viewed

  body-versions-rotate

Store the current displayed body version and switch to the next one
in the list, wrapping around if necessary

  body-versions-list

Show list of body versions for node

  body-versions-name

Change name of current body version

I guess these aren't versions in a temporal sense, just a way of managing
named alternate body texts.  And if you just keep using `body-versions-add`, 
then it does act as versioning.

Perhaps one way to get really cheap, effort wise, UI integration would
be to have these commands add a button which displays the current body
version name.

What might the v.u entry look like?

'body_vers': {
'current': 'red option',
'version': {
 'red option': ,
 '2014-04-28 09:45:32': ,
}
}

I think I would probably find a way to make subnodes work for me,
rather than this approach, but it does sound useful.

Cheers -Terry

> It seems this would be very useful, leveraging Leo's presentation
> capabilities and the utility of the UA sidecar available to each node.
> 
> Would anyone else find this interesting?
> 
> Thanks,
> Kent
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Why Leo is not yet ready for prime time (for most users)

['Terry Brown' via leo-editor]

I think why Leo behaves as it does and how it should behave are
complicated by the problem of defining what Leo is.

Config. user friendliness wise I think there's a possible middle way
solution where we make the Leoine way easy for non-technical users.

I.e. a settings menu with a hierarchy that lets you select
Settings --> Appearance --> Colors --> Backgrounds

etc.

I think we should get that far and then decide if more GUI is needed,
or if the user can be expected to edit a list of background colors.
Note providing a visual color picker would be a separate issue, I'm
just talking about whether we can ask the user to edit a Leo outline to
change scalar values or not.

Anyway, as a first step, I've just closed
https://bugs.launchpad.net/leo-editor/+bug/555014

Settings -> Open Personal Settings will now create myLeoSettings.leo if
it doesn't already exist.

Currently the created outline looks like this:

  Settings README
  @settings
  @enabled-plugins
  @keys
  @shortcuts
  
  myLeoSettings.leo personal settings file created Mon May  5 09:21:51 2014
  
  Only nodes that are descendants of the @settings node are read.
  
  Only settings you need to modify should be in this file, do
  not copy large parts of leoSettings.py here.
  
  For more information see http://leoeditor.com/customizing.html

(with no actual shortcuts defined in @shortcuts, just a comment about
how to do it).

More could be added.

Cheers -Terry

On Sat, 3 May 2014 20:15:17 -0700 (PDT)
duf...@gmail.com wrote:

> I am a long-time lurker on this newsgroup, and I have noticed that in
> the last few months there have been significant improvements to Leo,
> in the hopes of making it more accessible to the non-technical crowd.
> It was certainly a move in the right direction but, alas, I think it
> was not enough. The point of my argument is that Leo is still too 
> technically-oriented, and this alienates so many potential users. You
> just have to read the posts on this newsgroup (as I have been doing
> for a long time), to realize that people with little or no
> programming experience are bound to find major difficulties in using
> Leo, from the very beginning. Just trying to configure the simplest
> (UI-related) settings is a major challenge.
> This issue was already raised in the past, but is yet to be solved.
> 
> Why can't we (non-technical people) be relieved with having to tinker
> with the internal workings of Leo? Come to think of it, the
> overwhelming majority of modern programs are totally GUI-based, so
> that the settings can be easily changed via menus. Why can't we have
> this in Leo too, instead of having to learn technical jargon and
> manually modify settings files? I really don't get it.
> 
> Please, consider doing something radical about it (e.g. refurbishing
> the default menus with all the main commands and settings, at least),
> or realistically Leo might be bound for extinction.
> 
> All the best,
> 
> Duf
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Why Leo is not yet ready for prime time (for most users)

['Terry Brown' via leo-editor]

On Mon, 5 May 2014 10:06:45 -0700 (PDT)
duf...@gmail.com wrote:

> Thanks for the explanation, Terry.
> I think the solution lies in the middle ground that you propose, and
> which I was already looking forward to. But I thought it was going to
> be implemented months ago! Things seem to have stalled, after an
> initial flurry of activity (videocasts, etc) in the right direction.

Yes, it has definitely stalled, rather than been completed and failing
to be what you were hoping for.  I'm very busy these days... maybe next
month it won't be so bad, maybe.

Cheers -Terry

> Leo's settings can by all means remain exactly as they are, with no
> problem whatsoever, provided that there is also a more user friendly
> way of accessing them, so that the same settings can be accessed in a
> more "humanly readable" way.
> As things stand today, the situation a bit too intricate, and what
> the new user experiences is a feeling of confusion. Complexity tends
> to be overwhelming and to put off people. Also, why complexity, when
> things could be simplified with no loss?
> Hiding at least part of the complexity "under the hood" could be a
> major improvement, I believe.
> 
> 
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Using leoBridge from within Leo, or using several outlines from a "main" one

['Terry Brown' via leo-editor]

On Tue, 6 May 2014 04:34:39 -0700 (PDT)
Fidel N  wrote:

> Is there a way to put the original file again in front so the g.es
> will be executed in the window you called the script from?

c.bringToFront() ?

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: setting background color of viewrender2 pane

['Terry Brown' via leo-editor]

On Fri, 9 May 2014 13:30:33 -0700 (PDT)
nakedmind  wrote:

>  I read somewhere that QWebView 
> can be customized using html css. Is this possible?

In @settings
add / edit a 
  
  @data qt-gui-user-style-sheet

node and include

  QWebView { background: #aa; }

in the body, or #ff; or whatever you want.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Why Leo is not yet ready for prime time (for most users)

['Terry Brown' via leo-editor]

On Fri, 9 May 2014 20:13:17 -0700 (PDT)
Richard Cranium  wrote:

> Like all the non-technical people that managed to learn git?

I don't quite understand your comment, and I'm considering trying to
teach non-technical people git, so I'm curious.  Is there a context
where you see a lot of non-technical people using git?  Via git-hub, or
some other UI?  Or is it not as hard as it seems if it's explained
right?

Thanks, Terry

> On Saturday, May 3, 2014 10:15:17 PM UTC-5, duf...@gmail.com wrote:
> >
> > I am a long-time lurker on this newsgroup, and I have noticed that
> > in the last few months there have been significant improvements to
> > Leo, in the hopes of making it more accessible to the non-technical
> > crowd. It was certainly a move in the right direction but, alas, I
> > think it was not enough. The point of my argument is that Leo is
> > still too technically-oriented, and this alienates so many
> > potential users. You just have to read the posts on this newsgroup
> > (as I have been doing for a long time), to realize that people with
> > little or no programming experience are bound to find major
> > difficulties in using Leo, from the very beginning. Just trying to
> > configure the simplest (UI-related) settings is a major challenge.
> > This issue was already raised in the past, but is yet to be solved.
> >
> > Why can't we (non-technical people) be relieved with having to
> > tinker with the internal workings of Leo? Come to think of it, the
> > overwhelming majority of modern programs are totally GUI-based, so
> > that the settings can be easily changed via menus. Why can't we
> > have this in Leo too, instead of having to learn technical jargon
> > and manually modify settings files? I really don't get it.
> >
> > Please, consider doing something radical about it (e.g.
> > refurbishing the default menus with all the main commands and
> > settings, at least), or realistically Leo might be bound for
> > extinction.
> >
> > All the best,
> >
> > Duf
> >
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Getting node ids into rst output

['Terry Brown' via leo-editor]

On Sat, 10 May 2014 04:08:16 -0700 (PDT)
Marc van Grootel  wrote:

> Hi,
> 
> I tried posting before but something must've gone wrong as I can't
> find a trace of it on the list.

It came through ok - sometimes I don't see things I've posted either,
it can be a bit random.

You could use a command like this:


for nd in p.self_and_subtree():
lines = nd.b.split('\n')

for n in range(len(lines)):
if lines[n].startswith('.. NODE-ID: '):
break
else:
lines.extend(['', ''])
n = len(lines) - 1

lines[n] = '.. NODE-ID: %s' % nd.v.gnx
nd.b = '\n'.join(lines)

c.redraw()


that would add

.. NODE-ID: tbrown.20140224093559.11864

to all node bodies, updating it as needed, when you re-rerun the
script, that is.

Not sure if that exactly answers your question, but it is probably the
simplest approach to what I think you're asking.

Cheers -Terry

> Recently I started using Leo on a documentation project so I'm mainly
> usfor nd in p.self_and_subtree():
lines = nd.b.split('\n')

for n in range(len(lines)):
if lines[n].startswith('.. NODE-ID: '):
break
else:
lines.extend(['', ''])
n = len(lines) - 1

lines[n] = '.. NODE-ID: %s' % nd.v.gnx
nd.b = '\n'.join(lines)

c.redraw()
ing Leo to edit and get rst output.
> 
> A bit of context. I am using rst mostly because it's easy to write
> and it provides structured output in the form of XML. I convert this
> XML to DITA which is a topic-based documentation format. I chose Leo
> for it's outlining capabilities and cloned nodes. The outline
> structure in .leo files can be converted to DITA maps (kinda like
> table of contents) and the node content to DITA topics which are
> pulled into DITA maps to form a manual.
> 
> What I am looking for is a way to get the unique ids that Leo gives
> each node and use them to link topics to maps. This fits in very well
> with topic re-use as cloned nodes all have the same id. I looked a
> bit at the rst3 plugin code but I wondered if there is a way to get
> the node ids into the rst output without patching this plugin code.
> 
> I am curious if there is an easy way to do this.
> 
> Thanks
> --Marc
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Why Leo is not yet ready for prime time (for most users)

['Terry Brown' via leo-editor]

On Wed, 14 May 2014 08:58:33 +0300
"Ville M. Vainio"  wrote:

> Git is sometimes used to maintain e.g. design assets and
> documentation.
> 
> I guess non-technical people will learn to use git when it's
> mandatory part of their work.

:-)  My interest / surprise is that software-carpentry.org teaches git
as one of their core skills, in fact their bootcamp recipe is to
install gitbash for windows both for git and bash (sed / tr / sort /
wc / etc. etc. I assume).

Some students here might get to that this summer, but I'm curious about
getting it going locally, dreaming of a time when no one sends me Excel
spreadsheets with a note "the selected ones are colored red" :-)

Cheers -Terry

> On Mon, May 12, 2014 at 5:52 PM, 'Terry Brown' via leo-editor <
> leo-editor@googlegroups.com> wrote:
> 
> > On Fri, 9 May 2014 20:13:17 -0700 (PDT)
> > Richard Cranium  wrote:
> >
> > > Like all the non-technical people that managed to learn git?
> >
> > I don't quite understand your comment, and I'm considering trying to
> > teach non-technical people git, so I'm curious.  Is there a context
> > where you see a lot of non-technical people using git?  Via
> > git-hub, or some other UI?  Or is it not as hard as it seems if
> > it's explained right?
> >
> > Thanks, Terry
> >
> > > On Saturday, May 3, 2014 10:15:17 PM UTC-5, duf...@gmail.com
> > > wrote:
> > > >
> > > > I am a long-time lurker on this newsgroup, and I have noticed
> > > > that in the last few months there have been significant
> > > > improvements to Leo, in the hopes of making it more accessible
> > > > to the non-technical crowd. It was certainly a move in the
> > > > right direction but, alas, I think it was not enough. The point
> > > > of my argument is that Leo is still too technically-oriented,
> > > > and this alienates so many potential users. You just have to
> > > > read the posts on this newsgroup (as I have been doing for a
> > > > long time), to realize that people with little or no
> > > > programming experience are bound to find major difficulties in
> > > > using Leo, from the very beginning. Just trying to configure
> > > > the simplest (UI-related) settings is a major challenge. This
> > > > issue was already raised in the past, but is yet to be solved.
> > > >
> > > > Why can't we (non-technical people) be relieved with having to
> > > > tinker with the internal workings of Leo? Come to think of it,
> > > > the overwhelming majority of modern programs are totally
> > > > GUI-based, so that the settings can be easily changed via
> > > > menus. Why can't we have this in Leo too, instead of having to
> > > > learn technical jargon and manually modify settings files? I
> > > > really don't get it.
> > > >
> > > > Please, consider doing something radical about it (e.g.
> > > > refurbishing the default menus with all the main commands and
> > > > settings, at least), or realistically Leo might be bound for
> > > > extinction.
> > > >
> > > > All the best,
> > > >
> > > > Duf
> > > >
> > >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "leo-editor" group.
> > To unsubscribe from this group and stop receiving emails from it,
> > send an email to leo-editor+unsubscr...@googlegroups.com.
> > To post to this group, send email to leo-editor@googlegroups.com.
> > Visit this group at http://groups.google.com/group/leo-editor.
> > For more options, visit https://groups.google.com/d/optout.
> >
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Editable WYSIWYG as an evolution of the viewrendered pane plugin?

['Terry Brown' via leo-editor]

On Thu, 15 May 2014 14:19:21 +0200
dufriz  wrote:

> I have tried that plugin too. It's nice, but as far as I remember it
> does not support embedded pictures.

I think it will, depends on how it's set up, it's just an embedding of 
http://ckeditor.com/

Ok, after some time looking at old emails it finally occurred to me to
read the docs. from the plugin menu :-)

richtext.py uses these @settings:

...

@data richtext_cke_config 

Configuration info. for CKEditor, see
http://docs.ckeditor.com/#!/guide/dev_configuration the content of this
node is the javascript object passed to CKEDITOR.replace() as it’s
second argument. The version supplied in LeoSettings.leo sets up a
sensible toolbar. To enable all CKEditor toolbar features copy this
setting to myLeoSettings.leo and remove the default content, i.e. make
this node blank, then CKEditor will generate a toolbar with all
available features.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Customizing the layout

['Terry Brown' via leo-editor]

On Thu, 15 May 2014 02:32:59 -0700 (PDT)
duf...@gmail.com wrote:

> Hi,
> 
> As I'm deep into extreme customization, I would like to customize
> Leo's UI to my likings, changing the panes's colors, layout, etc.
> 
> I hope you don't mind if I ask you a few trivial questions:
> 
> 1) how can I set the active pane to have the colors I choose,
> different from the other panes (to make the active pane stand out
> visually, instead of that barely visible thin red border)?

I need to switch the default behavior from the red border mechanism to
a more generalized styling mechanism - all the pieces are in place, and
the new way will fix a scrolling bug from the red border's widget
hierarchy manipulations.  Will try and find time to do it asap.

> 2) can I have different layouts of panes within the same outline and
> switch back and forth between them? I explain: let's say that my

Yes.  So when you right click on the pane dividers you get the super
secret hidden "Free layout" menus, I /hope/ you knew about those :-)

You can save as many layouts as you want, hmm, I see because the
free-layout plugin is compulsory low level core now, it doesn't show up
in the Plugins menu, so you can't see its docs. there.  Never mind, the
docs. don't say much, I was just trying to find the name of this
command:  free-layout-load - pops up a context menu for switching
layouts, same as the right click on the pane dividers context menu
"Load Layout".

Cheers -Terry

> preferred working mode is having a full-page body text pane, which
> occupies the whole visual space presently used by the three standard
> panes. That would be the layout only for the 'composing' mode (when I
> am editing the body text of a node). Now, when I need to look at the
> outline tree, the body text pane would need to be downsized and put
> on the side of the screen, so I can see the outline. This way, the
> layout for that outline would not be static, but dynamic. This
> switching between the layouts, according to the 'modes' that I
> define, would have to be managed via key bindings, in a toggling way.
> Is this something that can be easily accomplished? Could someone
> please point me in the right direction on how to do it? Is this
> something that has to be defined on a per-outline basis, or could I
> implement it as a default for all my outlines?
> 
> Thanks
> 
> Dufriz
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Customizing the layout

['Terry Brown' via leo-editor]

On Thu, 15 May 2014 07:40:46 -0700 (PDT)
nakedmind  wrote:

> hi terry,
> 
> is there a way with the free-layout plugin to quickly maximize a view
> pane and restore it to original size later?

No, although that's a good idea, I'll make a note.  Right now you'd
have to make two layouts and switch between them.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

active pane styling switch to stylesheets

['Terry Brown' via leo-editor]

I've just pushed a switch from the old active pane border highlighting
code to a stylesheet based approach which makes it possible to do
different appearance things beyond border colors.

The default behavior is intended to be the same, it looks the same to
me, the active pane has a thin red border.  But now that's caused by
the following stylesheet code:

/* focused pane border highlight */
QTextEdit#log-widget, LeoQTreeWidget#treeWidget, QTextEdit#richTextEdit { 
  border-style: @focused-border-style;
  border-width: @focused-border-width; 
  border-color: @focused-border-unfocus-color; 
}
QTextEdit:focus#log-widget, LeoQTreeWidget:focus#treeWidget, 
QTextEdit:focus#richTextEdit { 
  border-style: @focused-border-style;
  border-width: @focused-border-width; 
  border-color: @focused-border-focus-color; 
}

Background color etc. could be styled as well, probably most easily
in @data qt-gui-user-style-sheet

Edward - I know your dealing with other things at the moment, but
please let me know if this scheme doesn't work for your settings /
environment etc. so I can fix it, always hard to know how these changes
impact local settings.  Same for everyone else of course - let me know
if this doesn't allow you to do what you were doing before.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: active pane styling switch to stylesheets

['Terry Brown' via leo-editor]

On Thu, 15 May 2014 13:29:54 -0500
"Edward K. Ream"  wrote:

> On Thu, May 15, 2014 at 12:38 PM, 'Terry Brown' via leo-editor
> 
> > Edward - I know your dealing with other things at the moment, but
> > please let me know if this scheme doesn't work for your settings /
> > environment etc. so I can fix it, always hard to know how these
> > changes impact local settings.  Same for everyone else of course -
> > let me know if this doesn't allow you to do what you were doing
> > before.
> 
> I don't see any change except that during startup the tree pane has a
> thin red border.  This changes to my default thicker blue border after
> startup is complete.  Not a big deal, obviously, but it's a little
> inconsistent.

Thanks for the feedback.  *If* you want to fiddle with it, you could
delete / set to False any `@bool use_focus_border` you have in your
local settings, and copy 

.../leo/config/leoSettings.leo#@settings-->Qt Gui
(appearance)-->active frame border styles

to you local settings and edit the values there to your blue / thicker
border.  I suspect that you have `@bool use_focus_border` set True in
local settings so you're still using the old code, which it would be
good to eliminate, but which I didn't remove because I'm trying to be
as non-disruptive as possible.

I guess a console / log output warning about the old code running might
be a good transitional strategy.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: active pane styling switch to stylesheets

['Terry Brown' via leo-editor]

On Fri, 16 May 2014 02:10:14 -0700 (PDT)
duf...@gmail.com wrote:

> Thanks indeed, Terry, for picking up and fulfilling my request so
> soon!
> 
> Could you please provide some basic step-by-step instructions on how
> to apply these changes?

So to get the new code you just need to be running the latest version
from:

http://leoeditor.com/download.html

option 2. (when Edward next updates the documentation the information
will all be on that page, currently it's still popping out to the old
page, http://www.greygreen.org/leo/http://www.greygreen.org/leo/
but that page has the current info., so that's ok.

Then

Settings -> Open Personal Settings



Under the @settings node, create a node `@data qt-gui-user-style-sheet`

In that, put something like:

/* focused pane border highlight */
QTextEdit#log-widget, LeoQTreeWidget#treeWidget, QTextEdit#richTextEdit { 
  background: blue;
}
QTextEdit:focus#log-widget, LeoQTreeWidget:focus#treeWidget, 
QTextEdit:focus#richTextEdit { 
  background: red;
}

Also, to be sure the old red-border code's not running, create a node
under @settings, `@bool use_focus_border = False`

I think you mentioned changing the background color, as shown above,
but if you want to change the border, you can 

Settings -> Open Global Settings

find the node there, `active frame border styles` and copy it and its
children under your @settings node in your personal settings, and edit
the values in the children as needed, they're:

@string focused-border-style = solid
@string focused-border-width = 1px
@string focused-border-focus-color = red
@string focused-border-unfocus-color = white

Two notes:

 - long term this should just be a matter of going to the menu item
   `Settings -> Appearance -> Active pane` or something, but we're not
   there yet.

 - if you want the full flexibility of and appearance tweaks Qt allows,
   you're always going to have to deal with some complexity, knowing
   the style-sheet syntax, essentially.

http://qt-project.org/doc/qt-4.8/stylesheet-reference.html

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: moving file tabs

['Terry Brown' via leo-editor]

On Fri, 16 May 2014 11:53:13 -0400
Jacob Peck  wrote:

> This has been fixed as of commit 60d085a68b8a...
> 
> It involves a dirty hack to force QT to redraw the tabs though.
> Perhaps someone more versed in PyQt could fix up my code?

In general, I think you should not just call the parent method, but
return its value as well, i.e.

return super(...)

rather than just

super(...)

but I don't think that was the problem in this case, the problem here
is that I don't understand super().  Specifically:
https://docs.python.org/2/library/functions.html#super

My reading of the text agrees with what you did,

super(QtGui.QTabBar, self).mouseReleaseEvent(event)

but the example code implies, to me,

super(qtTabBarWrapper, self).mouseReleaseEvent(event)

which seems like an annoying way of saying

super(self.__class__, self).mouseReleaseEvent(event)

which is also annoying and seems to have been cleaned up in 3.x

So a minimal change to get the correct behavior without your hack
triggering a redraw hack was

- super(QtGui.QTabBar,self).mouseReleaseEvent(event)
+ super(qtTabBarWrapper,self).mouseReleaseEvent(event)

but I haven't done this because I'm hoping someone will explain what
seems to me like the contradiction between the text and example at
https://docs.python.org/2/library/functions.html#super

Cheers -Terry

> Particularly the following bit: 
> https://github.com/leo-editor/leo-editor/blob/master/leo/plugins/qtGui.py#L7155-7163
> 
> Hope this helps!
> -->Jake
> 
> 
> On 5/16/2014 10:58 AM, Kent Tenney wrote:
> > I have multiple Leo files open as tabs. I seem to recall
> > being able to drag the tabs to reorder them, I am unable to.
> >
> > - am I remembering wrong?
> > - is there a setting involved?
> >
> > * Ubuntu 14.04 current trunk *
> >
> > Thanks,
> > Kent
> >
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: moving file tabs

['Terry Brown' via leo-editor]

On Mon, 19 May 2014 07:16:31 -0500
"Edward K. Ream"  wrote:

> :-)  I never have wanted to use super because I prefer::
> 
> aClassName.aFunctionName(self, args...)

That's what I usually do too :-)

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: active pane styling switch to stylesheets

['Terry Brown' via leo-editor]

On Mon, 19 May 2014 08:11:40 -0500
"Edward K. Ream"  wrote:

> On Fri, May 16, 2014 at 8:52 AM, 'Terry Brown' via leo-editor
>  wrote:
> 
> > option 2. (when Edward next updates the documentation the
> > information will all be on that page, currently it's still popping
> > out to the old page,
> > http://www.greygreen.org/leo/http://www.greygreen.org/leo/ but that
> > page has the current info., so that's ok.
> 
> I'm lost.  What documentation am I supposed to be updating?

None, I updated the relevant docs. in .../leo/docs, they just won't
show up on the website until you next "push" the sphinx output there.
Nothing urgent so I figured I'd just let it happen next time you did
something else with the docs.

Cheers -Terry

> http://www.greygreen.org/leo/http://www.greygreen.org/leo/ just points
> to http://codemostly.blogspot.com/ and I don't see anything related to
> this topic there.
> 
> Edward
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Customizing the layout

['Terry Brown' via leo-editor]

On Mon, 19 May 2014 10:31:08 -0500
"Edward K. Ream"  wrote:

> On Thu, May 15, 2014 at 10:23 AM, nakedmind
>  wrote:
> > On Thursday, May 15, 2014 10:50:15 PM UTC+8, Terry wrote:
> 
> >> Right now you'd have to make two layouts and switch between them.
> 
> > And it will be better if one can bind it to a keyboard shortcut.
> 
> I had forgotten about saving layouts.  Very slick.
> 
> If the free layout code would create separate commands for each
> available layout name there would be an easy way of binding those
> layouts to keystrokes.  I'll look into this next.

I think the "(un)zoom current pane to full size" functionality is the
best answer to the OP's request, it's a common feature of such
interfaces and obviously missing.  I will try and add it at soon.

However, "If the free layout code would create separate commands for
each available layout name" would also be very slick, to allow
keybindings for particular layouts.

So `free-layout-load` pops up a keyboard friendly context menu of all
available layouts, maybe `free-layout-load-`
could just immediately load the layout.

Cheers -Terry

> Edward
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: active pane styling switch to stylesheets

['Terry Brown' via leo-editor]

On Mon, 19 May 2014 10:20:54 -0500
"Edward K. Ream"  wrote:

> Just rebuilt LeoDocs.leo#Leo's Documentation-->Users Guide and upped
> them.

Ok, maybe something I don't know about the doc. build system, but I
expected

.../leo/doc/LeoDocs.leo#Leo's Documentation-->Installing & running
Leo-->@rst html/download.html

to show up at

leoeditor.com/download.html

Am I missing something?

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Editable WYSIWYG as an evolution of the viewrendered pane plugin?

['Terry Brown' via leo-editor]

On Mon, 19 May 2014 21:08:22 -0700 (PDT)
nakedmind  wrote:

> 
> 
> On Thursday, May 15, 2014 10:06:04 PM UTC+8, Terry wrote:
> >
> > On Thu, 15 May 2014 14:19:21 +0200 
> > dufriz > wrote: 
> >
> > > I have tried that plugin too. It's nice, but as far as I remember
> > > it does not support embedded pictures. 
> >
> > I think it will, depends on how it's set up, it's just an embedding
> > of http://ckeditor.com/ 
> >
> >
> The richtext plugin is nice and i think will be super useful to me. 
> However, instead of manually having to open and close the editor, i
> think it could be better and more convenient to define a @richtext
> node which will automatically select the richtext editor as its body
> editor. No need to manually open/close the richtext editor. The html
> source can be saved as an attribute of the node.

Here are the docs. - I think it already does what you're proposing.

Leo.plugins.richtext

richtext.py - Rich text editing

This plugin allows you to use CKEditor to edit rich text in Leo. Text
is stored as HTML in Leo nodes.

richtext.py provides these Alt-X commands (also available from Plugins
-> richtext menu):

cke-text-close
  Close the rich text editor, unhide the regular editor.
cke-text-open
  Open the rich text editor, hide the regular editor.
cke-text-switch
  Switch between regular and rich text editor.
cke-text-toggle-autosave
  Toggle autosaving of changes when you leave a node. Be careful not to
  convert plain text (e.g. source code) to rich text unintentionally.
  As long as you make no edits, the original text will not be changed.
  Unless autosaving is enabled, you must confirm saving of edits each
  time you edit a node with the rich text editor.

@rich in the headline or first few lines (1000 characters) of a node or
its ancestors will automatically open the rich text editor. @norich
cancels this action. Manually opened editors are not affected.

richtext.py uses these @settings:

@bool richtext_cke_autosave = False
Set this to True for rich text edits to be saved automatically.

BE CAREFUL - plain-text nodes will be converted to rich text without
confirmation if you edit them in rich text mode when this is True.

@data richtext_cke_config 

Configuration info. for CKEditor, see
http://docs.ckeditor.com/#!/guide/dev_configuration the content of this
node is the javascript object passed to CKEDITOR.replace() as it’s
second argument. The version supplied in LeoSettings.leo sets up a
sensible toolbar. To enable all CKEditor toolbar features copy this
setting to myLeoSettings.leo and remove the default content, i.e. make
this node blank, then CKEditor will generate a toolbar with all
available features.

To make a button to toggle the editor on and off, use:

@button rich
  c.k.simulateCommand('cke-text-switch')

Cheers -Terry

> Eric 
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Editable WYSIWYG as an evolution of the viewrendered pane plugin?

['Terry Brown' via leo-editor]

On Mon, 19 May 2014 08:51:23 -0500
"Edward K. Ream"  wrote:

> On Thu, May 15, 2014 at 9:06 AM, 'Terry Brown' via leo-editor
>  wrote:
> 
> > I think it will, depends on how it's set up, it's just an embedding
> > of http://ckeditor.com/
> 
> The richtext editor works for me on Linux (14.04) but not on Windows
> 7.  Rather than filling the body pane it fills only a part of it.
> Worse, the editor is not enabled.

For the 'only part of it' part, I just noticed there's a button in the
editor with four arrows pointing NW, NE, SE, SW that fully expands the
editor in the window, seems to be on by default for me, but that's the
only way I see less than the full body pane filled with edit.  For the
second question, do you mean it does not have focus, or is it that the
editor is non-responsive?  All I am thinking of is bad settings in the
@data richtext_cke_config node, but that would fail in Ubuntu too.

Anyone else having issues in Win 7?  Py 2 or 3 or both?

Cheers -Terry

> I'm pretty sure that I had troubles with richtext.py on Windows 7
> previously.  Do you know whether such problems have ever been
> resolved?  Googling doesn't show any obvious discussion, but I would
> have thought we discussed this awhile back.
> 
> Edward
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Editable WYSIWYG as an evolution of the viewrendered pane plugin?

['Terry Brown' via leo-editor]

On Tue, 20 May 2014 22:29:16 -0700 (PDT)
nakedmind  wrote:

> On Tuesday, May 20, 2014 7:30:46 PM UTC+8, Terry wrote:
> >
> >
> > Here are the docs. - I think it already does what you're proposing. 
> >
> > Awesome! thanks. 
> 
> One more thing. No keyboard shortcut to switch to the editor pane
> from the outline pane? Hitting enter does not work. Alt-b does not
> also. 

Hmm, Leo's core key handling would have to be aware of the plugin for
that to work.  A work around might be to bind `cke-editor-open` to
something and use that, although it would be nicer if it was either
Enter or Alt-B.

I wonder if it would be sense for Leo's select body code to use a hook
or something similar to find the body widget, so that plugins could
change the meaning of "the body widget" more easily.  Will make a note.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Editable WYSIWYG as an evolution of the viewrendered pane plugin?

['Terry Brown' via leo-editor]

On Tue, 20 May 2014 08:17:03 -0500
"Edward K. Ream"  wrote:

> On Mon, May 19, 2014 at 8:51 AM, Edward K. Ream 
> wrote:
> 
> 
> > The richtext editor works for me on Linux (14.04) but not on Windows
> > 7.  Rather than filling the body pane it fills only a part of it.
> > Worse, the editor is not enabled.
> >
> > I'm pretty sure that I had troubles with richtext.py on Windows 7
> > previously.  Do you know whether such problems have ever been
> > resolved?  Googling doesn't show any obvious discussion, but I would
> > have thought we discussed this awhile back.
> 
> The original thread was:
> https://groups.google.com/forum/#!topic/leo-editor/0zJI2CQaMyw
> 
> Afaik, the issue has never been resolved.

Just tried on a fresh Win 7 Py 2.7 install and failed to reproduce,
cke-editor-open opened a full pane functional editor.  Are you still
using the same install of Win 7 you were back then?

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Editable WYSIWYG as an evolution of the viewrendered pane plugin?

['Terry Brown' via leo-editor]

On Wed, 21 May 2014 19:19:32 -0700 (PDT)
nakedmind  wrote:

> 
> 
> On Thursday, May 22, 2014 12:16:45 AM UTC+8, Edward K. Ream wrote:
> >
> > On Wed, May 21, 2014 at 10:11 AM, nakedmind 
> > > wrote: 
> > > On Wednesday, May 21, 2014 7:20:44 PM UTC+8, Terry wrote: 
> > >> 
> > >> I wonder if it would be sense for Leo's select body code to use
> > >> a hook or something similar to find the body widget, so that
> > >> plugins could change the meaning of "the body widget" more
> > >> easily.  Will make a note. 
> > >> 
> > > 
> > > I don't know if it's related but I've had this idea for a while
> > > now. 
> > What if 
> > > you can have multiple body editors for different data like
> > > ordinary 
> > text, 
> > > rich text, image, etc. 
> > > There is a global dictionary that maps node directives to body
> > > editors. Plugins can add new node directives and select which
> > > existing body 
> > editors 
> > > to use by just 
> > > updating the global dictionary. Or plugins can add new body
> > > editors. So 
> > if 
> > > create a plugin that introduces a @pdf node directive and a 
> > corresponding 
> > > pdf viewer, I can just update the global dictionary and leo will
> > > know 
> > that 
> > > nodes with headlines starting with the aforementioned directive
> > > will use 
> > my 
> > > plugin's pdf viewer. The body editor may even be an external 
> > application. 
> >
> > Not a bad idea.  In effect, this would be a generalization of the 
> > viewrendered or viewrendered2 plugins.  At present, these plugins
> > have this logic hard coded. 
> >
> > It's surprisingly complicated to switch the rendering widget 
> > dynamically.  It's conceivable that a more general approach would
> > be less complex/buggy, but I wouldn't get my hopes up :-) 
> >
> > Edward 
> >
> 
> I'd like to take a stab at this once I get some free time. Can you
> give some pointers as to where in leo's code I should start hacking.
> I have limited knowledge on leo's code but i'm pretty experienced
> with pyqt. 
> 
> Eric

I'm going to repost a repost of an old post about how I think Leo's
body editor(s) should ideally integrate.

Two old threads:

https://groups.google.com/forum/#!msg/leo-editor/M-8TcxYAUpI/OovFbolHAzoJ

https://groups.google.com/d/msg/leo-editor/IBnrAH2xIQI/OdQ-kzt2cjcJ

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Free range body editors

['Terry Brown' via leo-editor]

Another bump, but I fully appreciate the magnitude of this task.  Would
make a good sprint, once we switch to 36 hour days and there's time to
get everything done again :-}

Cheers -Terry

On Wed, 18 Apr 2012 17:34:13 -0500
Terry Brown  wrote:

> On Wed, 18 Apr 2012 11:13:35 -0500
> Terry Brown  wrote:
> 
> > bump :)
> > 
> > On Fri, 16 Dec 2011 22:24:42 -0600
> > Terry Brown  wrote:
> > 
> > > I suspect that if body editors could be made just slightly more
> > > flexible it would open up whole new ways of using Leo.  It seems
> > > they just need two or three things to make them really flexible.
> > > 
> > >  - a flag to indicate whether the tree pane should select the body
> > >editor's node then the body editor has is focused.  To see an
> > >example of editing bodies without the tree selecting the node
> > > you're editing, see the stickynotes plugin
> 
> Ahem, that should be:
> 
>   - a flag to indicate whether the tree pane should select the body
> editor's node when the body editor is focused.  To see an
> example of editing bodies without the tree selecting the node
> you're editing, see the stickynotes plugin
> 
> > >  - a flag to indicate whether the body editor should track the
> > > node currently selected in the tree
> > > 
> > >  - it needs to not care about what it's contained in, GUI wise.  I
> > >don't know how much work's involved in this.
> > > 
> > > I'll try and contribute to things moving in this direction when I
> > > have time, just throwing it out there for others to think on.
> > > 
> > > If you could have a body editor edit the node indicated by an
> > > UNL, it would basically be a clone...
> > > 
> > > Cheers -Terry
> > > 
> > 
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Editable WYSIWYG as an evolution of the viewrendered pane plugin?

['Terry Brown' via leo-editor]

On Thu, 22 May 2014 09:25:24 -0500
Kent Tenney  wrote:

> I can't tell if this thread is hinting that tabbed body panes would
> be feasible, I sure hope so.
> 
> I think _persistent_ tabbed body panes could be much more than
> another cool bell/whistle, I think they could unleash a new paradigm
> in editing.

Unless of course you use bookmarks, which are basically hierarchical
tabbed body panes :-)

Cheers -Terry

> On Thu, May 22, 2014 at 9:01 AM, 'Terry Brown' via leo-editor
>  wrote:
> > On Wed, 21 May 2014 19:19:32 -0700 (PDT)
> > nakedmind  wrote:
> >
> >>
> >>
> >> On Thursday, May 22, 2014 12:16:45 AM UTC+8, Edward K. Ream wrote:
> >> >
> >> > On Wed, May 21, 2014 at 10:11 AM, nakedmind
> >> > > wrote:
> >> > > On Wednesday, May 21, 2014 7:20:44 PM UTC+8, Terry wrote:
> >> > >>
> >> > >> I wonder if it would be sense for Leo's select body code to
> >> > >> use a hook or something similar to find the body widget, so
> >> > >> that plugins could change the meaning of "the body widget"
> >> > >> more easily.  Will make a note.
> >> > >>
> >> > >
> >> > > I don't know if it's related but I've had this idea for a while
> >> > > now.
> >> > What if
> >> > > you can have multiple body editors for different data like
> >> > > ordinary
> >> > text,
> >> > > rich text, image, etc.
> >> > > There is a global dictionary that maps node directives to body
> >> > > editors. Plugins can add new node directives and select which
> >> > > existing body
> >> > editors
> >> > > to use by just
> >> > > updating the global dictionary. Or plugins can add new body
> >> > > editors. So
> >> > if
> >> > > create a plugin that introduces a @pdf node directive and a
> >> > corresponding
> >> > > pdf viewer, I can just update the global dictionary and leo
> >> > > will know
> >> > that
> >> > > nodes with headlines starting with the aforementioned directive
> >> > > will use
> >> > my
> >> > > plugin's pdf viewer. The body editor may even be an external
> >> > application.
> >> >
> >> > Not a bad idea.  In effect, this would be a generalization of the
> >> > viewrendered or viewrendered2 plugins.  At present, these plugins
> >> > have this logic hard coded.
> >> >
> >> > It's surprisingly complicated to switch the rendering widget
> >> > dynamically.  It's conceivable that a more general approach would
> >> > be less complex/buggy, but I wouldn't get my hopes up :-)
> >> >
> >> > Edward
> >> >
> >>
> >> I'd like to take a stab at this once I get some free time. Can you
> >> give some pointers as to where in leo's code I should start
> >> hacking. I have limited knowledge on leo's code but i'm pretty
> >> experienced with pyqt.
> >>
> >> Eric
> >
> > I'm going to repost a repost of an old post about how I think Leo's
> > body editor(s) should ideally integrate.
> >
> > Two old threads:
> >
> > https://groups.google.com/forum/#!msg/leo-editor/M-8TcxYAUpI/OovFbolHAzoJ
> >
> > https://groups.google.com/d/msg/leo-editor/IBnrAH2xIQI/OdQ-kzt2cjcJ
> >
> > Cheers -Terry
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "leo-editor" group. To unsubscribe from this group and stop
> > receiving emails from it, send an email to
> > leo-editor+unsubscr...@googlegroups.com. To post to this group,
> > send email to leo-editor@googlegroups.com. Visit this group at
> > http://groups.google.com/group/leo-editor. For more options, visit
> > https://groups.google.com/d/optout.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Simple Test that consistently causes Gtk-CRITICAL error messages

['Terry Brown' via leo-editor]

On Sat, 22 Mar 2014 14:53:46 -0700 (PDT)
SegundoBob  wrote:

> I've finally discovered a test that for me causes a Gtk-CRITICAL
> error consistently.

Doesn't do so for me in Ubuntu 14.04.  But I've seen Gtk-CRITICAL
errors before, makes me wonder if the problems in the Ubuntu
Qt <-> Gtk level, i.e. a particular uncommon but correct action in Leo
PyQt was firing the error before, but isn't now, because Ubuntu fixed
something in their PyQt, or in the way the window manager triggers GTk
actions, or some "below Leo" level thing.

I guess this makes sense up to the point where you say "I still see
them in 14.04".

... hmm, I guess I can try Unity instead of Xfce, but that would only
confirm my "below Leo" level theory.

Cheers -Terry

> I use my demo file for my "delete all children" function:  
> delAllChildren.leo  (attached).
> 
> Edit delAllChildren.leo with only plugin mod_scripting.py enabled.
> Select node "@button dac" and hit Ctrl-B to execute the
> delete-all-children.  No Gtk-CRITICAL errors occur.  Now click the
> "dac" button.  This causes Gtk-CRITICAL errors to occur:
> 
> $ leomy delAllChildren.leo
> 
> ** isPython3: False
> Leo 4.11 final, build 042b3a51ba03 (branch: master), 2014-03-19
> 13:56:51 Python 2.7.5, qt version 4.8.4
> linux2
> setting leoID from os.getenv('USER'): 'bob06'
> load dir: /home/ldi/git/leo-editor/leo/core
> global config dir: /home/ldi/git/leo-editor/leo/config
> home dir: /home/bob06
> reading settings
> in /home/ldi/git/leo-editor/leo/config/leoSettings.leo reading
> settings in /home/bob06/.leo/myLeoSettings.leo Found /help
> Abbreviations off
> reading settings in /home/ldi/git/leo_misc/delAllChildren.leo
> Abbreviations off
> 
> (python:2660): Gtk-CRITICAL **: IA__gtk_widget_get_direction:
> assertion 'GTK_IS_WIDGET (widget)' failed
> 
> (python:2660): Gtk-CRITICAL **: IA__gtk_widget_get_direction:
> assertion 'GTK_IS_WIDGET (widget)' failed
> 
> --
> 
> For me, whenever I click the "dac" button, I get the two errors
> above; and whenever I execute the same code with Ctrl-B, I don't get
> the errors.  With all plugins disabled, there is no "dac" button and
> hence no errors.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Simple Test that consistently causes Gtk-CRITICAL error messages

['Terry Brown' via leo-editor]

On Thu, 22 May 2014 15:24:25 -0500
"'Terry Brown' via leo-editor"  wrote:

> On Sat, 22 Mar 2014 14:53:46 -0700 (PDT)
> SegundoBob  wrote:
> 
> > I've finally discovered a test that for me causes a Gtk-CRITICAL
> > error consistently.
> 
> Doesn't do so for me in Ubuntu 14.04.  But I've seen Gtk-CRITICAL
> errors before, makes me wonder if the problems in the Ubuntu
> Qt <-> Gtk level, i.e. a particular uncommon but correct action in Leo
> PyQt was firing the error before, but isn't now, because Ubuntu fixed
> something in their PyQt, or in the way the window manager triggers GTk
> actions, or some "below Leo" level thing.
> 
> I guess this makes sense up to the point where you say "I still see
> them in 14.04".
> 
> ... hmm, I guess I can try Unity instead of Xfce, but that would only
> confirm my "below Leo" level theory.

Nope, doesn't do it in Unity either.

> Cheers -Terry
> 
> > I use my demo file for my "delete all children" function:  
> > delAllChildren.leo  (attached).
> > 
> > Edit delAllChildren.leo with only plugin mod_scripting.py enabled.
> > Select node "@button dac" and hit Ctrl-B to execute the
> > delete-all-children.  No Gtk-CRITICAL errors occur.  Now click the
> > "dac" button.  This causes Gtk-CRITICAL errors to occur:
> > 
> > $ leomy delAllChildren.leo
> > 
> > ** isPython3: False
> > Leo 4.11 final, build 042b3a51ba03 (branch: master), 2014-03-19
> > 13:56:51 Python 2.7.5, qt version 4.8.4
> > linux2
> > setting leoID from os.getenv('USER'): 'bob06'
> > load dir: /home/ldi/git/leo-editor/leo/core
> > global config dir: /home/ldi/git/leo-editor/leo/config
> > home dir: /home/bob06
> > reading settings
> > in /home/ldi/git/leo-editor/leo/config/leoSettings.leo reading
> > settings in /home/bob06/.leo/myLeoSettings.leo Found /help
> > Abbreviations off
> > reading settings in /home/ldi/git/leo_misc/delAllChildren.leo
> > Abbreviations off
> > 
> > (python:2660): Gtk-CRITICAL **: IA__gtk_widget_get_direction:
> > assertion 'GTK_IS_WIDGET (widget)' failed
> > 
> > (python:2660): Gtk-CRITICAL **: IA__gtk_widget_get_direction:
> > assertion 'GTK_IS_WIDGET (widget)' failed
> > 
> > --
> > 
> > For me, whenever I click the "dac" button, I get the two errors
> > above; and whenever I execute the same code with Ctrl-B, I don't get
> > the errors.  With all plugins disabled, there is no "dac" button and
> > hence no errors.
> > 
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Customizing the layout

['Terry Brown' via leo-editor]

On Thu, 15 May 2014 07:40:46 -0700 (PDT)
nakedmind  wrote:

> hi terry,
> 
> is there a way with the free-layout plugin to quickly maximize a view
> pane and restore it to original size later?
> 
> eric

Just pushed, there's now a command:

  free-layout-zoom

which (un)zooms the current pane.  Also accessible via context menu on
pane dividers, although it really needs a key-binding to be useful.

NOTE: renamed the command free_layout_restore to free-layout-restore
while I was there.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Customizing the layout

['Terry Brown' via leo-editor]

> Just pushed, there's now a command:
> 
>   free-layout-zoom

p.s. it's the users responsibility to unzoom when necessary, i.e. if
you zoom the tree pane and then hit enter twice so you're editing the
body, you're editing a body you can't see, but unzooming at any point
fixes this.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

launchpad bugs to github

['Terry Brown' via leo-editor]

Someone started looking at moving the launchpad bugs to github, what
was the conclusion reached?

Thanks, Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: @auto 'Refresh from disk' issue

['Terry Brown' via leo-editor]

On Fri, 23 May 2014 08:12:03 -0500
Kent Tenney  wrote:

> I've also been seeing this with real files, if changed outside
> Leo, refresh from disk fails, the .py file has it's contents
> duplicated.

I *think* this is a known issue, certainly needs fixing.

https://github.com/leo-editor/leo-editor/issues/9

is similar but probably unrelated, maybe the @auto specific report is
on launchpad still.

Cheers -Terry

> A minimal @auto file:
> 
> @auto z.py
>  pass
> @others
>  foo
> class foo:
>@others
>def __init__():
>   pass
> 
> - save Leo file, creates z.py
> - refresh from disk z.py
> 
> log:
> 
> saved: foo.leo
> created: /home/ktenney/develop/z.py
> saved: foo.leo
> reading: @auto z.py
> 
> Error: @auto did not import @auto z.py perfectly
> The clean-all-lines command may help fix whitespace problems
> first mismatched line: 15 (original) = 3 (imported)
> 
> Original file...
> 
> 
> Imported file...
> 
>1 u'def __init__():\n'
>2 u' pass\n'
>3 u'class foo:\n'
>4 u'def __init__():\n'
>5 u' pass\n'
> 
> errors inhibited read @auto /home/ktenney/develop/z.py
> 
> finished
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Tabbed body editing (was Re: Editable WYSIWYG as an evolution of the viewrendered pane plugin?)

['Terry Brown' via leo-editor]

On Thu, 22 May 2014 10:12:45 -0500
Kent Tenney  wrote:

> OK. It's been a while since I was up to speed on bookmarks,
> I don't remember them as realizing my desires, but

I just pushed

(a) a fix to a dumb glitch in bookmarks.py that meant you had to click
an invisible 10x8 box in the bookmarks window to add the first
bookmark, and

(b) an extension to the docs, pasted below

Bookmarks for tabbed body editors
+

Create a new outline with the following nodes, as simple top level nodes::

aardvarks
apples
autos
bats
bison
bunting
@bookmarks

(pro-tip, with the paste_as_headlines plugin active, you can just copy
the above and use `Edit -> Paste as headlines`, you'll need to promote
them to top level again though).

Select the ``@bookmarks`` node and then Alt-X `bookmarks-show`, which
should create a new empty pane above the body pane.  Select the
``aardvarks`` node and click in the new empty pane, repeat for the
``bats`` node.

Squish the new empty pane up so it's just high enough to hold the two
bookmarks, or "tabs", and then right click a pane divider and save this
layout as "Tabs" or whatever you want to call it.

So now you have two tabs which jump between two nodes.  Click the ``aardvarks`` 
tab, then
select the ``apples`` node.  Now shift-click the ``aardvarks`` tab.
Now you are entering sub tabs of the ``aardvarks`` tab.  You might want
to repeat the ``aardvarks`` tab at this level, just select the node and
click in the empty space in the bookmarks pane to repeat it here.  You
could add ``autos`` at this level too.

How the 'tabs' are displayed (one or more levels at once etc.) and how
you edit them are described in the earlier parts of these docs.  For
example at the top level the first time you click the ``aardvarks`` tab
it just shows you the ``aardvarks`` node, it requires a second click to
see its subtabs (aardvarks, apples, and autos), because the top level
``aardvarks`` tab is both a bookmark and an organizer node.  If you
want it to be just and organizer node, alt-click it to edit the
bookmark node itself, and delete the body text (UNL) there.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Layout Menu

['Terry Brown' via leo-editor]

On Sat, 24 May 2014 08:13:04 -0700 (PDT)
Chris George  wrote:

> Hello,
> 
> I have a couple of questions.
> 
> 1. Is there a better way to access the layout menu than trying
> repeatedly to right click on the narrow bit of border between windows?

No, partly because the context of which narrow border you clicked is
needed to reference the panes you want to work on.  "Add below", "Split
left vertically", etc. are relative to the border you selected.
Thinking about it, I guess there could be a command that cycles through
the borders using a key, so that you can select the one you want that
way, and then pop up the context menu with another key.

Also the context free commands could be made accessible as targets for
keybinding, currently there's 

free-layout-load
Open context menu for loading a different layout,
conventient keyboard shortcut target.
free-layout-load-
Load the named layout
free-layout-restore
Use the layout this outline had when it was opened.
free-layout-zoom
Zoom or unzoom the current pane

> 2. Is the a way to save these setting, to make them persistent across 
> sessions?

Yes, the Save and Load layout menu items in the context menu.  The last
layout saved or loaded for an outline will be used for that outline in
subsequent sessions.  Note that layouts are stored in g.app.db and
c.db, so they don't travel with the outline, just apply to it when it's
running on your machine.  Unless you use context-menu embed layout, of
course.

> 3. Is it just me or does everyone get the following message when
> trying to use the 'Window', 'Toggle Split Direction' option?

No, it happens to me too, and is a bug.  I think it's basically the
same as the context menu's "Rotate all" option, which isn't well named,
seeing it really just toggles between +0 degrees and +90 degrees.  So I
guess the fix is to make the old 'Window', 'Toggle Split Direction'
command call free_layout's "Rotate all", which should probably be
renamed.

Just because it's easy, I'm going to add a

free-layout-context-menu 

command to open the free layout context menu using the first border in
the top level splitter as the context, that will at least give keyboard
access to the menu for commands which don't require selecting a border
for context.  In future maybe there'll be an option to select which
border is used for this command's context.

Cheers -Terry

> exception executing command
> Traceback (most recent call last):
>   File "/home/chris/Working/leo/leo-editor/leo/core/leoCommands.py",
> line 535, in doCommand
> val = command(event)
>   File "/home/chris/Working/leo/leo-editor/leo/plugins/qtGui.py",
> line 5152, in toggleSplitDirection
> r1 = getRatio(w1)
>   File "/home/chris/Working/leo/leo-editor/leo/plugins/qtGui.py",
> line 5128, in getRatio
> sizes = w.sizes()
> RuntimeError: wrapped C/C++ object of type NestedSplitter has been
> deleted
> 
> Thanks,
> 
> Chris
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Layout Menu

['Terry Brown' via leo-editor]

On Sat, 24 May 2014 11:37:20 -0500
"'Terry Brown' via leo-editor"  wrote:

> Just because it's easy, I'm going to add a
> 
> free-layout-context-menu 
> 
> command to open the free layout context menu using the first border in
> the top level splitter as the context, that will at least give
> keyboard access to the menu for commands which don't require
> selecting a border for context.

Pushed.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Layout Menu

['Terry Brown' via leo-editor]

On Sat, 24 May 2014 10:22:00 -0700 (PDT)
Chris George  wrote:

> Thanks Terry,
> 
> Is there a way to increase the thickness of the clickable border?

myLeoSettings.leo
  @settings
@data qt-gui-user-style-sheet

 QSplitter::handle:horizontal {
 width: 20px;
 }

 QSplitter::handle:vertical {
 height: 20px;
 }

Seems you shouldn't need the ::handle part but it was inconsistent when
I took that out.

Cheers -Terry

> Chris
> 
> On Saturday, May 24, 2014 9:53:17 AM UTC-7, Terry wrote:
> >
> > On Sat, 24 May 2014 11:37:20 -0500 
> > "'Terry Brown' via leo-editor"  > > wrote: 
> >
> > > Just because it's easy, I'm going to add a 
> > > 
> > > free-layout-context-menu 
> > > 
> > > command to open the free layout context menu using the first
> > > border in the top level splitter as the context, that will at
> > > least give keyboard access to the menu for commands which don't
> > > require selecting a border for context. 
> >
> > Pushed. 
> >
> > Cheers -Terry 
> >
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Layout Menu

['Terry Brown' via leo-editor]

On Sat, 24 May 2014 16:31:11 -0700 (PDT)
Chris George  wrote:

> I was thinking a little more about this. Would it not make sense to
> split off all of the functions that do not require the context into
> their own gui? For example, everything below zoom pane could be on
> the main menu as a settings item. Zoom pane itself should be part of
> the context menu for the pane it is invoked from instead of applying
> to the pane to the right of the splitter menu. I see now why some
> items need the context, but many of the items on the menu do not.
> 
> What do you think?

I think you're probably right, have made a note.

Cheers -Terry

> Chris
> 
> On Saturday, May 24, 2014 11:25:35 AM UTC-7, Terry wrote:
> >
> > On Sat, 24 May 2014 10:22:00 -0700 (PDT) 
> > Chris George > wrote: 
> >
> > > Thanks Terry, 
> > > 
> > > Is there a way to increase the thickness of the clickable border? 
> >
> > myLeoSettings.leo 
> >   @settings 
> > @data qt-gui-user-style-sheet 
> >
> >  QSplitter::handle:horizontal { 
> >  width: 20px; 
> >  } 
> >
> >  QSplitter::handle:vertical { 
> >  height: 20px; 
> >  } 
> >
> > Seems you shouldn't need the ::handle part but it was inconsistent
> > when I took that out. 
> >
> > Cheers -Terry 
> >
> > > Chris 
> > > 
> > > On Saturday, May 24, 2014 9:53:17 AM UTC-7, Terry wrote: 
> > > > 
> > > > On Sat, 24 May 2014 11:37:20 -0500 
> > > > "'Terry Brown' via leo-editor"  > > > > wrote: 
> > > > 
> > > > > Just because it's easy, I'm going to add a 
> > > > > 
> > > > > free-layout-context-menu 
> > > > > 
> > > > > command to open the free layout context menu using the first 
> > > > > border in the top level splitter as the context, that will at 
> > > > > least give keyboard access to the menu for commands which
> > > > > don't require selecting a border for context. 
> > > > 
> > > > Pushed. 
> > > > 
> > > > Cheers -Terry 
> > > > 
> > > 
> >
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Simple Test that consistently causes Gtk-CRITICAL error messages

['Terry Brown' via leo-editor]

On Sun, 25 May 2014 15:44:14 -0700 (PDT)
SegundoBob  wrote:

> Terry,
> 
> The Gtk-CRITICAL errors are printed to stderr by Gtk/Glib code.
> Hence, they never appear in the Leo-Editor log pane.  They only
> appear on the console.  Hence, to do the tests you must start
> Leo-Editor from a console and then you must look for the errors on
> the console.
> 
> This is so obvious to me that I may have failed to communicate it to
> you and others.

No worries :-) it was obvious to me too.  I'm fairly positive I've seen
Leo trigger these messages in the past, I've certainly seen them from
more apps. than just Leo, but I think they're very much a combination
of interactions between Ubuntu versions, window managers, desktop
themes, etc. etc.

Cheers -Terry


> Respectfully,
> SegundoBob
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Hiding node-type markers. Proposing: type-dependent icons

['Terry Brown' via leo-editor]

On Tue, 27 May 2014 15:47:49 -0700 (PDT)
duf...@gmail.com wrote:

> >From what I have read of the documentation (I am not through yet,
> >and my 
> reading so far has been very cursory, I admit), the different types
> of nodes are identified by explicit markers in the node names, so
> that certain nodes begin with @file, @auto, etc. followed by the
> filename, for instance.
> 
> Is it possible to have the marker part (e.g. @file) hidden from the
> node name?
> 
> Also, could the node icons could be used to indicate visually the
> node types, so that the different types of nodes would be visually 
> differentiated by different icons, and those explicit marker could be
> made (optionally) redundant?
> 
> These considerations arise from the fact that it is not very
> pleasant, while scanning through the node names, to come across the
> @file, @auto, etc. markers.

Something very much along these lines has been proposed before, and I
would like to try exactly what you proposed, different icons to
indicate hidden '@auto ' etc.  To make it a doable cosmetic change, and
not a major revamp of core Leo, my plan would be to have the @auto etc.
hidden when viewing the tree, but appear when you're editing a headline.

No timeline though :-/

Cheers -Terry

> Forgive me if there is already a solution to all this. I am still 
> learning...
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Hiding node-type markers. Proposing: type-dependent icons

['Terry Brown' via leo-editor]

On Wed, 28 May 2014 06:43:50 -0700 (PDT)
duf...@gmail.com wrote:

> Thinking along the same lines, it just occurred to me: wouldn't it be
> more rational take the node type marked altogether out of the
> headline? After all, it is metadata. So, the headline would display
> only the text of the headline.

That moves from optional cosmetic change to major revamp of Leo's
internals, so I don't see happening, hopefully the "hidden for display,
shown for editing" compromise gets most of the value here.

Leo's use of text markers like "@auto" is very fundamental to its
design.

Cheers -Terry

> The node type could be conveneiently managed either via a menu
> command (e.g. set node type) or directly via a key binding. 
> And then there is the icons, as proposed above.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Hiding node-type markers. Proposing: type-dependent icons

['Terry Brown' via leo-editor]

On Wed, 28 May 2014 10:11:04 -0400
Jacob Peck  wrote:

> I think replacing them with icons and showing them on edit would be a 
> good enhancement, especially with an easy way to define custom icons
> via @settings :)

Definitely thinking of @settings to control styling.  Something like
regex changes of text, '^auto ' -> '' etc., and also regex triggered
styling, 

  '^@auto ': icon: path/to/icon; font-weight: bold; color: red;

etc.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Customizing the layout

['Terry Brown' via leo-editor]

On Wed, 28 May 2014 20:32:22 -0700 (PDT)
duf...@gmail.com wrote:

> Terry, I know that you are busy, but... is there any chance you could 
> implement some of these changes in the *default* settings (after
> Edward's approval, of course):
> 
> 1) as mentioned above, defining the background color of the currently 
> active pane as different from the default background color of the
> other panes. The red line can stay, of course. At least for me, what

Perhaps you could run an informal poll on the list here to get input on
this.  Personally I don't have / want any active frame highlighting,
but I'm ok with turning it off anyway, so I don't have an opinion.
See if there's a consensus that something like dimming the background of
inactive panes would be ok with most people.

> 2) defining a default keybinding for easily toggling on and off the 
> full-screen mode of the current body text. If I understand your posts 
> correctly, the commands for this functionality are now in place, so
> it would just be a matter of making the keybinding available by
> default.

To which currently unused key would you like it bound?  It's always a
challenge to find unused keys.

You're referring to the new free-layout-zoom command, which I'm finding
very useful :-) for zooming not only the body but also the log (long
messages) and the tree (long headlines).
 
> Please don't underestimate the impact that such small improvements
> can make on the UI usability and likability.
> I would also make other suggestions, but I am not sure to what extent
> my constant nagging for UI improvements would be welcome... ;)

Preference tweaking is tricky, seeing preferences are personal - I
think you said you were uncomfortable messing with the settings, but I
encourage you to try some changes, Settings -> Personal settings
creates a file "myLeoSettings.leo" in $HOME/.leo, if you mess it up
completely you can always delete it and start fresh.  For example for
the current items you could do the following in that file.

Add, under the @settings node, a node

@data qt-gui-user-style-sheet

with this body content:

QTextEdit#log-widget, LeoQTreeWidget#treeWidget, QTextEdit#richTextEdit { 
  background: pink;
}
QTextEdit:focus#log-widget, LeoQTreeWidget:focus#treeWidget, 
QTextEdit:focus#richTextEdit { 
  background: green;
}


and in the node @settings / @keys / @shortcuts add something like

free-layout-zoom = Ctrl-Alt-L

to the body to bind pane zoom to Ctrl-Alt-L

Cheers -Terry

> Thanks
> 
> Dufriz
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

@rclick now support submenus

['Terry Brown' via leo-editor]

Looks like @rclick isn't well doc'ed, :-/ but it lets you add context
menu items (right-click) to your custom @buttons.  Anyway, it now
supports submenus, any @rclick node with no non-whitespace body text
will generate a submenu of its @rclick children.  Any number of levels.

By "general utility scripts" collection attached to a button was
generating a two column menu full screen height, something needed to
change :-)

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Recent Errors

['Terry Brown' via leo-editor]

On Sat, 7 Jun 2014 06:59:05 -0700 (PDT)
Chris George  wrote:

> Hello,
> 
> Over the last couple of days I have been getting the following error
> at start-up:

Do you use the leoscreen plugin?  I use it constantly, but didn't know
if anyone else did :-)  It's unix only leo / terminal communication, if
anyone's wondering.

Anyway, if you don't, just remove it from your enabled plugins.  If you
do, my first guess is that your system (no longer?) has the executable
`screen` installed / on the path.

Cheers -Terry


 
> hook failed: after-create-leo-frame,  0x3bad668>, leo.plugins.leoscreen
> Traceback (most recent call last):
>   File "/home/chris/Working/leo/leo-editor/leo/core/leoPlugins.py",
> line 336, in callTagHandler
> result = handler(tag,keywords)
>   File "/home/chris/Working/leo/leo-editor/leo/plugins/leoscreen.py",
> line 176, in onCreate
> leoscreen_Controller(c)
>   File "/home/chris/Working/leo/leo-editor/leo/plugins/leoscreen.py",
> line 214, in __init__
> self._get_output()  # prime output diffing system
>   File "/home/chris/Working/leo/leo-editor/leo/plugins/leoscreen.py",
> line 284, in _get_output
> self.screen_cmd(['hardcopy -h "%s"'%self.tmpfile])
>   File "/home/chris/Working/leo/leo-editor/leo/plugins/leoscreen.py",
> line 242, in screen_cmd
> stderr=subprocess.PIPE)  # screen's behavior
>   File "/usr/lib/python2.7/subprocess.py", line 709, in __init__
> errread, errwrite)
>   File "/usr/lib/python2.7/subprocess.py", line 1326, in
> _execute_child raise child_exception
> OSError: [Errno 2] No such file or directory
> 
> 
> Leo 4.11 final, build abc4475ab1b3 (branch: master), 2014-06-07
> 06:46:29
> 
> Python 2.7.6, qt version 4.8.5
> linux2
> 
> 
> Chris
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Why Leo is not yet ready for prime time (for most users)

['Terry Brown' via leo-editor]

On Mon, 9 Jun 2014 06:31:03 -0700 (PDT)
Todd Mars  wrote:

> 
> 
> There is no reason why the settings cannot be made user friendly,
> other than the work involved.
> Simply enumerating the specific problems from the beginning, and
> designing a friendly user interface to perform the tasks.
> When that is done, a good programmer can do it.

Bear in mind that that are ~1100 nodes in the Leo @settings tree.  So
at least ~1000 settings that can be set, some of which have complex
values.  If Leo's settings are going to be handled in a Leonine way,
it's a matter of making the use of Leo to manage common settings user
friendly enough that it's no barrier to newbies.  So a hierarchical
Settings menu which lands you in the right place, and a @settings
editing environment documented and tuned for easy editing (color, font,
file, and directory selection tools for example).

But you're right, ultimately it's just a matter of finding time.

Cheers -Terry

> Todd.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Why Leo is not yet ready for prime time (for most users)

['Terry Brown' via leo-editor]

On Mon, 9 Jun 2014 10:42:36 -0500
"'Terry Brown' via leo-editor"  wrote:

> But you're right, ultimately it's just a matter of finding time.

Baby steps, I just added color and font selection tools to LeoSettings,
with the intent they be automatically copied into myLeoSettings when
the latter's created (as is already the case for @enabledplugins).

Unfortunately I also added a DateTime picker tool, and testing that
reminded me I'm out of time for now :-}

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Leo settings revamp (was Re: Why Leo is not yet ready for prime time (for most users))

['Terry Brown' via leo-editor]

On Mon, 9 Jun 2014 10:06:09 -0700 (PDT)
duf...@gmail.com wrote:

> As an alternative to a restructuring of the settings, I propose a 
> menu-based simplified access to the settings, which will let the user 
> zoom-in to the relevant part of the settings file. The  most commonly
> used settings (font color and size, background color, etc.) would
> have an entry in the menu, and upon clicking on an entry you would be
> able to edit that part directly.

That is the current plan :-)

E.g. from the Settings menu:

Settings -> Appearance -> Fonts

would open myLeoSettings.leo at the appropriate place (copying nodes in
from LeoSettings.leo if needed), so the user would be looking at a node
with the following children:

@string body-text-font = Courier New
@string log-text-font = Courier New
@int body-text-font-size = 17px
@int log-text-font-size = 12px

etc. - something along those lines.  The "pick-font" button I just
added is just a convenience so the user can find font names on their
system easily.

The body of the node with those children would have some simple
instructions, probably "Click the reload-styles button after making
changes here".

Once the infrastructure's set up we should be able to build out the
Settings menu entries quite quickly.  By infrastructure I mean the
Settings -> Appearance -> Fonts entry knowing which node to copy from
LeoSettings to myLeoSettings, if it's not already copied, where the
stylesheet needs to be, etc. etc.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: v5.x roadmap -- Ideas, priorities, etc.

['Terry Brown' via leo-editor]

On Mon, 9 Jun 2014 11:36:06 -0700 (PDT)
duf...@gmail.com wrote:

> Although I am not one of the developers, I think it's not out of
> place if I suggest that it's about time we start focusing on planning
> the next release, which as I understand would be v5.0. 
> In fact, it would be nice to start laying down a tentative roadmap
> for the 5.x series of releases, so the developers can discuss the
> priorities, and better focus on them.

Great idea and thanks for taking the initiative.

One item to consider - supporting PyQt5.  Not really sure how much work
or benefit is involved, but eventually PyQt4 will be a legacy thing,
even though I'm sure it will be around for many years to come.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Leo settings revamp (was Re: Why Leo is not yet ready for prime time (for most users))

['Terry Brown' via leo-editor]

On Tue, 10 Jun 2014 06:33:48 -0500
"Edward K. Ream"  wrote:

> On Mon, Jun 9, 2014 at 12:20 PM, 'Terry Brown' via leo-editor
>  wrote:
> 
> > E.g. from the Settings menu:
> >
> > Settings -> Appearance -> Fonts
> >
> > would open myLeoSettings.leo at the appropriate place (copying
> > nodes in from LeoSettings.leo if needed), so the user would be
> > looking at a node with the following children:
> >
> > @string body-text-font = Courier New
> > @string log-text-font = Courier New
> > @int body-text-font-size = 17px
> > @int log-text-font-size = 12px
> >
> > etc. - something along those lines.  The "pick-font" button I just
> > added is just a convenience so the user can find font names on their
> > system easily.
> >
> > The body of the node with those children would have some simple
> > instructions, probably "Click the reload-styles button after making
> > changes here".
> >
> > Once the infrastructure's set up we should be able to build out the
> > Settings menu entries quite quickly.  By infrastructure I mean the
> > Settings -> Appearance -> Fonts entry knowing which node to copy
> > from LeoSettings to myLeoSettings, if it's not already copied,
> > where the stylesheet needs to be, etc. etc.
> 
> A clever idea.  However, I don't understand how this would work.  Are
> the "copied" nodes actually cross-file clones?

No, just a one time "copy on demand" from leoSettings.leo to
myLeoSettings.leo.  Currently Settings -> Personal settings creates
myLeoSettings.leo if it doesn't exist, copying @enabledplugins from
leoSettings.leo and creating a stub @keys -> @shortcuts node.

So we could add an ID of some sort to nodes in leoSettings.leo, so they
could be used by a data structure like this:

[
("Appearance", [
("Fonts", "FONT_SETTINGS"),
("Colors", "COLOR_SETTINGS"),
("Active frame", "ACTIVE_FRAME"),
]),
("Layout", [
("Tabs", "TAB_SETTINGS"),
("Width", "WIDTH_SETTINGS"),
]),
("Abbreviations", [
etc. etc.
]),
]

I.e. a list of tuples making up menu and sub-menu items under the
Settings Menu:

Appearance
   Fonts
   Colors
   Active frame
Layout
   Tabs
   Width
etc.

which, when selected, search myLeoSettings.leo for the relevant entry
and, if it's not there already, copy it over from leoSettings.leo.

So the actual settings mechanism is exactly as it is now, it's just
easier to navigate and more automated in the "only what you need"
leoSettings.leo to myLeoSettings.leo copying.

It's the simplest thing that could possibly work(TM) :-)

The ID could be handled any number of ways, gnx, UNL, uA, but I'm
inclined to just use text at the bottom of the organizer nodes, which
would be used to present instructions for preference editing.  E.g.
(using '|' to indicate body text lines, all other lines are node
headlines):

  Font settings
  | After you've changed the font settings below, click the
  | reload-styles button to update the appearance of Leo.
  | You can use the pick-font button to find font names on
  | your system.
  |
  | SETTINGS_NODE: FONT_SETTINGS
  @string body-text-font = Courier New
  @string log-text-font = Courier New
  @int body-text-font-size = 17px
  @int log-text-font-size = 12px

Cheers -Terry

> That is, suppose you present these nodes to the user, and they make
> changes to the nodes.  How are the nodes in the various files
> updated?
> 
> And where do the "copied" nodes appear?  In a separate, newly created
> outline?  In a leoSettings.leo?
> 
> Edward
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Support for Qt5 has begun

['Terry Brown' via leo-editor]

On Thu, 12 Jun 2014 16:03:27 -0500
"Edward K. Ream"  wrote:

> On Thu, Jun 12, 2014 at 3:38 PM,   wrote:
> > Just to get it right, do you advise us to uninstall PyQt4 and
> > install PyQt instead?
> > To do so would be no trouble at all for me, so no problem.

To answer dufriz, I'd say don't change anything right now, just keep
using the current Leo so you're testing the new code, for Qt4 for now.

> On Windows, it is very easy to install PyQt5 just for some versions of
> Python.  I'm not so sure about Linux.

I couldn't get more than one Qt running in Windows when I tried, I was
aiming for Qt4+Py2.7 and Qt5+Py3.4 but whichever one I installed last
always seemed to break the other one (DLL load failure).

So I wouldn't encourage anyone to mess with multiple Qt installs in
Windows unless they're ok with things breaking.

> I have just converted the last few bits of code that are different
> between Qt4 and Qt5.  Most involve the new, simplified, Qt5 signals.
> Everything now appears to work.  All differences are marked with "if
> isQt5:"

Great, now I can develop the Qt5/Py3.4 + Py2.7 windows app. I'm
working on :-)  I.e. the UI is in Qt5/Py3.4, but it calls an app. whose
python API is 2.7 only.

Cheers -Terry

> I'll up the changes as soon as all tests pass.
> 
> Edward
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Support for Qt5 has begun

['Terry Brown' via leo-editor]

On Thu, 12 Jun 2014 17:55:45 -0500
"Edward K. Ream"  wrote:

> On Thu, Jun 12, 2014 at 11:54 AM, Edward K. Ream
>  wrote:
> 
> > The last task will be hook up connections again when using Qt5.
> 
> Actually, there were a few more items, but as of rev dc9568360f7d...
> just about everything appears to be working.  Some notes:

Great, it's running for me, Py 3.4, Qt 5.3.0, Win 7.  Great timing,
just when I needed to work in that environment with Leo :-)

Minor non-import thing, line 464 in qtGui.py, QWheelEvent.delta() is
now QWheelEvent.angleDelta(), to separate it from the new
QWheelEvent.pixelDelta().

Cheers -Terry

> 1. The new signal code is much simpler than the old.  I haven't
> attempted to use the new code with PyQt4, though in one or two places
> the new style seems to be in use already...
> 
> 2. The viewrendered.py plugin now works with PyQt5, at least enough to
> put up help messages.  More advanced features (like movies) need to be
> tested.
> 
> 3. Several other plugins need to be revised, including (I suspect)
> viewrendered2.py.
> 
> Please report any problems/crashes immediately.  Aside from revising
> imports in plugins I don't plan any more work on this project.
> 
> Edward
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

log window version numbers

['Terry Brown' via leo-editor]

Hey Jacob, I think you've worked on this most recently?

Latest Leo, in Ubuntu / Py 2.7.4 Qt 4 it says

Leo Log Window
Leo 4.11 final, build dc9568360f7d (branch: master), 2014-06-12 18:00:40
Python 2.7.6, qt version 4.8.6
linux2

But in Win7 / Py 3.4 Qt 5 it says

Leo 4.11 final, build 6240, 2013-11-06
Python 3.4.1, qt version 5.3.0
Windows 7 AMD65 ...

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Support for Qt5 has begun

['Terry Brown' via leo-editor]

On Thu, 12 Jun 2014 18:00:22 -0500
"Edward K. Ream"  wrote:

> On Thu, Jun 12, 2014 at 4:15 PM, Terry Brown
>  wrote:
> 
> > I couldn't get more than one Qt running in Windows when I tried, I
> > was aiming for Qt4+Py2.7 and Qt5+Py3.4 but whichever one I
> > installed last always seemed to break the other one (DLL load
> > failure).
> 
> Did you uninstall Qt4 using the uninstall.exe in site-packages/PyQt4?
> That should zap the dll's.

At the time, I wanted Qt4 in Py 2.7 for Leo, and Qt 5 in Py 3.4 for the
GUI part of my app., but of course now it doesn't matter :-)

BTW, in the interlude I looked at Sublime Text, Notepad++, and ScITE,
but they all have dysfunctional outlining - they collapse all ok to
see the classes and top-level functions, but when I expand a class I
don't want all its methods expanded - defeats the whole point of
outlining :)

Cheers -Terry

> > So I wouldn't encourage anyone to mess with multiple Qt installs in
> > Windows unless they're ok with things breaking.
> 
> Always good advice :-)
> 
> > Great, now I can develop the Qt5/Py3.4 + Py2.7 windows app. I'm
> > working on :-)  I.e. the UI is in Qt5/Py3.4, but it calls an app.
> > whose python API is 2.7 only.
> 
> Please keep us informed :-)
> 
> Edward
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: log window version numbers

['Terry Brown' via leo-editor]

On Thu, 12 Jun 2014 20:25:29 -0400
gatesphere  wrote:

> Was your Win7 copy not checked-out from git?  There's some fall-back 

Ha, I guess that explains it - I got it from

https://github.com/leo-editor/leo-editor/archive/master.zip

which includes .gitignore, but not .git.

Ok - no obvious alternative then, thanks for the explanation.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: require pyqt version >= 4.5

['Terry Brown' via leo-editor]

On Sat, 14 Jun 2014 09:47:33 -0700 (PDT)
"Edward K. Ream"  wrote:

> My guess is that few people will be affected, and those that are can
> easily upgrade.  For example, my installed version of pyqt is 4.7 on
> Windows and 4.8.6 on Ubuntu.  (It's 5.3.0 on Windows with Python 3.4).

I don't think we should do anything that would break support for Ubuntu
12.04 which is supported until April 2017.  Happily, pyqt4 in 12.04 is
currently at 4.9 :-)

So no objection from me, I suspect 4.4 was a long time ago.

Cheers -Terry

> Please speak up *immediately* if you have any objections with this
> proposal.
> 
> Requiring "modern" (>=4.5) versions of pyqt would allow new-style 
> connections of events.  This would simplify the code by replacing
> code such as::
> 
> if isQt5:
> action.triggered.connect(func)
> else:
> action.connect(act, Qt.SIGNAL('triggered()'),func)
> 
> by just:
> 
> action.triggered.connect(func)
> 
> Code such as this appears in *many* places in Leo's core.  You could
> say that such code should also appear in plugins, but several plugins
> *already* use new-style connections, which is another reason to
> suppose that few people will object.
> 
> Speak now or live with the consequences.
> 
> Edward
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Terry, please check todo.py with PyQt5

['Terry Brown' via leo-editor]

On Sat, 14 Jun 2014 10:19:44 -0700 (PDT)
"Edward K. Ream"  wrote:

> I made a number of changes, but not enough, it seems.  todo works
> with PyQt4 but not 5.  For example, icons don't appear in headlines.

I'll take a look when I can.

todo.py doesn't work with Python 3, well, it does, but it can't read
datetime objects pickled in 2.x, which is annoying.  I have not been
able to find any 3.x code that will read a 2.7 datetime pickle,
although maybe I haven't tried in 3.4, I think there were some changes
in pickle recently.

Current plan is to have todo.py convert dates to string
representations in 2.x, and report files that need running through 2.x
when they're encountered in 3.x

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Good luck with the hips

['Terry Brown' via leo-editor]

June 19th, I thought it was a couple of days closer, but anyway, best
wishes with the new hips - both at once, or one at a time?

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Support for Qt5 has begun

['Terry Brown' via leo-editor]

PyQt5 conversion seems mostly straight forward, apart from the parts
that are not straight forward :-}

Trying to work out what's going on in todo.py, let's use a simple test
case, just running the 'insert-icon' command on an outline with a
single node.

'insert-icon' uses g.app.gui.runOpenFileDialog, and *Py*Qt 5 has changed the 
return value for QFileDialog.getOpenFileNames() from 
  [list of file names]
to
  [[list of file names], ]

Ok, no big deal.

Here's a trap though:

-def setter(pri=pri): o.setPri(pri)
-self.connect(w, QtCore.SIGNAL("clicked()"), setter)
+def setter(pri=pri):
+o.setPri(pri)
+if isQt5:
+w.clicked.connect(setter)
+else:
+self.connect(w, QtCore.SIGNAL("clicked()"), setter)

The old form calls setter() with no parameters, the new form calls
setter with `bool is_checked`, seeing buttons can be checked or
unchecked when they're clicked.

I think the best solution is to change setter() to be
  def setter(checked, pri=pri): ...
which will work in both Qt4 and Qt5, basically the old style .connect()
let you select whether that parameter got passed or not, but I think
everything's cleaner if we just make the callbacks match the basic
definition of the signals.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Terry, please check todo.py with PyQt5

['Terry Brown' via leo-editor]

On Sat, 14 Jun 2014 13:20:01 -0500
"'Terry Brown' via leo-editor"  wrote:

> On Sat, 14 Jun 2014 10:19:44 -0700 (PDT)
> "Edward K. Ream"  wrote:
> 
> > I made a number of changes, but not enough, it seems.  todo works
> > with PyQt4 but not 5.  For example, icons don't appear in headlines.
> 
> I'll take a look when I can.
> 
> todo.py doesn't work with Python 3, well, it does, but it can't read
> datetime objects pickled in 2.x, which is annoying.  I have not been
> able to find any 3.x code that will read a 2.7 datetime pickle,
> although maybe I haven't tried in 3.4, I think there were some changes
> in pickle recently.
> 
> Current plan is to have todo.py convert dates to string
> representations in 2.x, and report files that need running through 2.x
> when they're encountered in 3.x

Woohoo - finally found a way around this, there's a special encoding
`bytes` that can be used, at least in 3.4, not sure about earlier 3.x
series.

-g.trace('can not unpickle %s=%s' % (attr,val))
-return val
+try:
+# for python 2.7 in python 3.4
+val2 = pickle.loads(binString, encoding='bytes')
+return val2
+except 
(pickle.UnpicklingError,ImportError,AttributeError,ValueError,TypeError):
+g.trace('can not unpickle %s=%s' % (attr,val))
+return val

Cheers -Terry

> Cheers -Terry
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: output of rst3 to node instead of external file

['Terry Brown' via leo-editor]

On Mon, 16 Jun 2014 08:02:08 -0700 (PDT)
daniel  wrote:

> Hi,
> 
> I searched the group for a way to have the output of rst3 directly to
> a node in the tree, not to an external file, but did not find
> anything.
> 
> Just to make it clear, I have a "@rst myfile.html" node with rst text
> in it. When I run the rst3 command I get the html external file
> alright. But what I would like to do is to have the html output sent
> to a new node in the tree, not a file.  Anyone has an idea on how to
> get that?

You can make a button with this code:

https://github.com/leo-editor/snippets/blob/master/rst2html_node.py

Cheers -Terry

> Cheers!
> 
> Daniel
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: LEO: A Learning Environment Organizer

['Terry Brown' via leo-editor]

On Wed, 18 Jun 2014 14:50:57 -0700 (PDT)
Fidel N  wrote:

> Hi all. I found yet another "LEO" software, this time is a Machine
> learning software. I will call the other one LEO, and ours is 'Leo
> editor'
> 
> I wanted to post it here because I found it very interesting.

That is very interesting.  I use CMapTools occasionally when I want to
analyze a problem.  I would say a concept map is something more than a
mind-map, which has a set tree structure.  Freemind is the mind-map
software most widely used, I used it before switching to Leo.

Cheers -Terry

> LEO is a mind-map-like structure that learns from data and transforms
> it into concept maps. (That is one of the projects, its also used
> like a normal concept map, same as Leo editor). But its funny that
> they also called Leo to an outlining tool.
> Then they use that for machine learning, and for e-learning, for
> classes with people.
> Here 
> is
>  
> an article about it, here is an example concept
> map developed with it. Another here. 
> 
> I bet they spent much time trying to build a structure that is
> probably far less capable than Leo editor for that purpose.
> They develop static nodes, Leo nodes are dynamic.
> Well hope someone finds this interesting, I sure did.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Is there a way to move button toolbar to the continuation of the menubar?

['Terry Brown' via leo-editor]

On Fri, 20 Jun 2014 06:43:15 -0700 (PDT)
Zoltan Benedek  wrote:

> Hi,
> 
> It would be nice if I could move the script button toolbar to the
> menubar, after the Help menu. There is a lot of free space, and I
> could get one more line for the work space.
> In some office programs you can change the position of toolbars, but
> I have never seen a way to have the toolbar immediately after the
> menubar
> 
> I tried to move by the mouse, but remains undetached.
> 
> If it is not possible to do that, is there a shortcut to remove and
> add the button toolbar?

I've just added the following commands:

  gui-all-hide
  gui-all-show
  gui-iconbar-hide
  gui-iconbar-show
  gui-menu-hide
  gui-menu-show
  gui-minibuffer-hide
  gui-minibuffer-show
  gui-statusbar-hide
  gui-statusbar-show

The minibuffer unhides itself if you attempt to use it (Alt-X).

Cheers -Terry

> Thanks
> Zoltan
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Scripts for importing your mindmaps from MindJet and Freemind

['Terry Brown' via leo-editor]

On Sat, 21 Jun 2014 03:43:08 -0700 (PDT)
Fidel N  wrote:

> Hi, I just made two scripts for importing from MindJet and Freemind.
> I really think those two should be in the menu "File -> import ->"
> Because when a new user comes to Leo, he most likely comes from any
> other of the most famous outliners (IE freemind or mindjet).
> So it will feel very good to import their mindmaps with two clicks. I
> know for sure I would have loved it.

https://github.com/leo-editor/leo-editor/issues/32

:)

Cheers -Terry
 
> For importing your MindJet mindmap, first you have to export it to
> CSV, using the following options:
> - Select the 'outline' layout when exporting
> - Tick all the options but the 'inlcude topic properties'
> 
> Now you are ready to import your mindmap to Leo with this script.
> Copy it and paste it into a node, replace the path with your mindmap
> path, and execute the script (with the hotkey control + B):
> 
> #Your currently selected node will be replaced with the outline you
> are importing.
> #Replace the path with the path of your file:
> 
> 
> file_path = 'D:/exmample/mymindmap.csv'
> 
> 
> max_chars_in_header = 80 #Nodes with more characters than that (or
> with line jumps) will be inserted as bodies instead of as header.
> 
> 
> #INSTRUCTIONS FOR EXPORTING FROM MINDJET: You need a csv file
> exported from MindJet. When exporting, make sure you:
> # - Use the layout "outline"
> # - Tick all the options but "inlcude topic properties"
> 
> 
> 
> 
> import csv
> 
> 
> def get_row_level(row):
> count = 0
> while count<=len(row):
> if row[count]:
> return count+1
> else:
> count = count+1
> return -1
> 
> 
> def get_row_string(row):
> count = 0
> while count<=len(row):
> if row[count]:
> return row[count]
> else:
> count = count+1
> return None
> 
> 
> reader = csv.reader(open(file_path))
> 
> 
> initial_level = c.p.level()
> last_created_level = c.p.level()
> last_created_node = c.p.copy()
> 
> 
> 
> 
> for row in list(reader)[1:]:
> new_level = get_row_level(row) + initial_level
> get_row_string(row)
> if new_level > last_created_level:
> last_created_node =
> last_created_node.insertAsLastChild().copy() last_created_node.b =
> get_row_string(row) last_created_level = last_created_level+1
> elif new_level == last_created_level:
> last_created_node = last_created_node.insertAfter().copy()
> last_created_node.b = get_row_string(row)
> elif new_level < last_created_level:
> 
> for item in last_created_node.parents():
> if item.level() == new_level-1:
> last_created_node = item.copy()
> break
> 
> 
> last_created_node =
> last_created_node.insertAsLastChild().copy() last_created_node.b =
> get_row_string(row) last_created_level = last_created_node.level()
> 
> for p in c.p.unique_subtree():
> if len(p.b.splitlines())==1:
> if len(p.b.splitlines()[0]) p.h = p.b.splitlines()[0]
> p.b = ""
> else:
> p.h = "@node_with_long_text"
> else:
> p.h = "@node_with_long_text"
> 
> 
> c.redraw()
> 
> If you are coming from Freemind, you just have to export your
> freemind mindmap into html, then use this script.
> Copy and paste this script into a node, replace the path inside it
> with the path where you have your mindmap.html file, then run the
> script (hotkey control + B)
> 
> 
> #Your currently selected node will be replaced with the outline you
> are importing.
> #Replace the path with the path of your file:
> 
> file_path = 'D:/exmample/mymindmap.mm.html'
> 
> 
> max_chars_in_header = 80 #Nodes with more characters than that (or
> with line jumps) will be inserted as bodies instead of as header.
> 
> 
> #INSTRUCTIONS FOR EXPORTING FROM FREEMIND: Export your outline into
> html, then you can use this script.
> 
> 
> import lxml.html
> 
> 
> global outline_dict
> 
> 
> outline_dict = {}
> 
> 
> global count
> count = 0
> 
> 
> def element_to_node(parent_node, element ):
> global count
> global outline_dict
> count = count+1
> my_actual_count = int(count)
> 
> 
> if len(list(element.iterchildren())):
> # if
> len(list(list(element.iterchildren())[0].iterchildren())):
> 
> 
> outline_dict[str(my_actual_count)] = {}
> outline_dict[parent_node]['children'].append(str(my_actual_count))
> if len(list(list(element.iterchildren())[0].iterchildren())):
> outline_dict[str(my_actual_count)]['string'] =
> list(list(element .iterchildren())[0].iterchildren())[0].text
> else:
> outline_dict[str(my_actual_count)]['string'] =
> list(element. iterchildren())[0].text
> outline_dict[str(my_actual_count)]['children'] = list()
> if len(list(element.iterchildren()))>1:
> for child in
> list(element.iterchildren())[1].iter

Re: Scripts for importing your mindmaps from MindJet and Freemind

['Terry Brown' via leo-editor]

Feel free to update the scripts at
https://github.com/leo-editor/snippets/tree/master/issue_attach/32
if you can.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Inaccuracies with @shadow

['Terry Brown' via leo-editor]

On Mon, 23 Jun 2014 07:26:58 +1200
David McNab  wrote:

[snip]
> However, with numerous Python files, @shadow has been inaccurately
> writing out files. The main inaccuracies have been to do with indent
> levels for significant blocks of code (a massive dealbreaker in
> Python), which unless resolved makes Leo unusable in my team
> environment.
> 
> Has anyone else had issues with inaccuracies in @shadow read/write?

I usually find myself using @auto, when I have used @shadow it's seemed
ok, although I've always had a feeling it hasn't been tested in the
field enough to be sure it can handle all the needed permutations.

It might be worth sharing some examples of failing code in the hope
that one or two fixable flaws are all that's keeping it from doing what
you need (i.e. not altering code :-)

I'd also point out that UNL based approaches e.g. the bookmarks.py
plugin, let you have multiple task specific views of a set of files
loaded with @auto and @edit and other non-intrusive forms, so that
might be an option.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: New to Leo Editor and feeling lost...

['Terry Brown' via leo-editor]

On Tue, 24 Jun 2014 07:18:55 -0500
"Edward K. Ream"  wrote:

> How did you install Leo?  Would it be convenient to install using git?

Remember that you can get the latest version "from git" as

https://github.com/leo-editor/leo-editor/archive/master.zip

i.e. just a simple .zip download.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: New to Leo Editor and feeling lost...

['Terry Brown' via leo-editor]

On Tue, 24 Jun 2014 09:55:32 -0400
Alec Burgess  wrote:

> On 2014-06-24 9:06, 'Terry Brown' via leo-editor wrote:
> > Remember that you can get the latest version "from git" as
> >
> > https://github.com/leo-editor/leo-editor/archive/master.zip
> >
> > i.e. just a simple .zip download.
> Is this address discoverable?
> 
> https://github.com/leo-editor/leo-editor/archive/   gives a 404
> and https://github.com/leo-editor/leo-editor/ doesn't contain a link
> to the master.zip (afaict).

Intended discovery would be via

http://leoeditor.com/download.html

which currently points to

http://www.greygreen.org/leo/

where the above link is "Latest".

The links at greygreen should just be integrated into the
http://leoeditor.com/download.html page, greygreen's no longer serving
any purpose here.  Which I've already done in LeoDocs.leo...

Edward - I think you need to refresh the docs. on leoeditor.com,
they're not showing the latest version, e.g.
leo/doc/LeoDocs.leo#Leo's Documentation-->Installing & running Leo-->@rst 
html/download.html-->Snapshots

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: New to Leo Editor and feeling lost...

['Terry Brown' via leo-editor]

On Tue, 24 Jun 2014 17:07:01 -0700 (PDT)
Scott Koga-Browes  wrote:

> Hi - thanks for the advice. I am now running the version available on 
> github (at -
> https://github.com/leo-editor/leo-editor/archive/master.zip
> 
> ). Unfortunately the problem seems to remain...

I'm wondering if Edward noticed the problem's in
leo/plugins/lineNumbers.py, I missed that the first time.  Docstring

"Over-rides two methods in leoAtFile.py to write #line directives after
node sentinels. This allows compilers to give locations of errors in
relation to the node name rather than the filename. Currently supports
only perl and perlpod."

Scott - is this a plugin you deliberately enabled?  I haven't heard of
it, but I don't use Perl either.

I suspect it's almost never used, and is no longer working.

Cheers -Terry

> Log as follows - 
> 
> Leo 4.11 final, build 6240, 2013-11-06
> Python 2.7.5, PyQt version 4.8.6
> darwin
> 
> exception writing: /Users/spkb/Documents/Leo Editor/scokobro-site.txt
> Traceback (most recent call last):
>   File
> "/Users/spkb/Downloads/leo-editor-master/leo/core/leoAtFile.py", line
> 3105, in write
> at.writeOpenFile(root,nosentinels=nosentinels,toString=toString) File
> "/Users/spkb/Downloads/leo-editor-master/leo/core/leoAtFile.py", line
> 3662, in writeOpenFile at.putOpenNodeSentinel(root)
>   File 
> "/Users/spkb/Downloads/leo-editor-master/leo/plugins/lineNumbers.py",
> line 51, in putLineNumberDirective
> oldOpenNodeSentinel(self,v,inAtAll,inAtOthers,middle)
> TypeError: putOpenNodeSentinel() takes at most 4 arguments (5 given)
> 
> 
> Regards - SPKB
> +
> 
> On Tuesday, 24 June 2014 21:19:00 UTC+9, Edward K. Ream wrote:
> >
> > On Mon, Jun 23, 2014 at 9:27 PM, Scott Koga-Browes
> > > wrote: 
> > > First, hello everyone - and thanks in advance for your time and
> > > help! 
> >
> > Hi Scott.  Welcome aboard :-) 
> >
> > > I managed to install Leo and do the basics, open, create, save,
> > > edit 
> > files 
> > > etc. However it seems(to me) that many of the functions mentioned
> > > in the opening tutorial just don't work (for me). For instance,
> > > this morning I 
> > came 
> > > back to Leo after a few weeks and tried to use the @file
> > > directive to 
> > create 
> > > an external (I also tried @auto) - but I received this error
> > > message ... 
> > > 
> > > exception writing: /Users/spkb/Documents/Leo
> > > Editor/scokobro-site.txt 
> > [snip] 
> >
> > > TypeError: putOpenNodeSentinel() takes at most 4 arguments (5
> > > given) 
> >
> > My apologies for the problems you are having. My guess is that your 
> > sources aren't in synch with each other. 
> >
> > How did you install Leo?  Would it be convenient to install using
> > git? That way you will always have the very latest sources.  We
> > expect the core developers to run all unit tests before upping
> > changes, and in practice it is very rare to have any problems using
> > the bleeding edge code. 
> >
> > In the future, when reporting any problem with Leo, please report
> > the platform and version number reported by Leo at the start of the
> > log pane.  Thanks. 
> >
> > Edward 
> >
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Calling a leo class function from the minibuffer

['Terry Brown' via leo-editor]

On Wed, 25 Jun 2014 11:03:09 -0700 (PDT)
Fidel N  wrote:

> Hello:
> 
> Im starting to use AHK to send commands to Leo. So far I create a

AHK may stand for: AutoHotkey, a programming language for creating Windows 
scripts and applications

> @command in the outline, then call it from AHK, using the minibuffer.
> 
> But there are beginning to be to many commands, so it would be more 
> convenient to create a class in Leo and call directly the class
> functions.
> 
> So, to sum up, is there a way to run from the minibuffer something
> like: g.es("hello")

There's the `eval-expression` command, but I'm not sure what it does.
I.e. it asks for an expression and displays "2+2 -> 4" if given "2+2",
but it says g.es("hello") is invalid.

Maybe run your automation from Leo and have it call AHK to do the
non-Leo parts ;-)

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Installing Leo Mint

['Terry Brown' via leo-editor]

On Wed, 25 Jun 2014 11:26:03 -0700 (PDT)
duf...@gmail.com wrote:

> I have just installed the latest Linux Mint (v17, Mate), and it's the
> first Linux installation that I am actually planning to use, after
> having tried and tested many other distros.
> I am having difficulties in finding Leo in the repository.

Leo hasn't made it into the Ubuntu and related repositories, mostly
lack of developer time and developer knowledge, I don't know anything
about building packages.  At one time Ville had a PPA for some releases
of Leo, but those would be stale by now.

Anyone who wants to lead the charge on getting Leo into the Ubuntu
repos., that would be great.

Chris's instructions cover using the current development version, I
think there was a typo, should have been:

  mkdir leo
  cd leo
  git clone https://github.com/leo-editor/leo-editor.git

And you can also just grab
https://github.com/leo-editor/leo-editor/archive/master.zip
and set up a script file to run launchLeo.py for that.

I guess this is all assuming some degree of familiarity with Linux
scripts (bash etc.).

Cheers -Terry

> >From the Synaptic Package Manager's search box I type in "Leo", but
> >none of 
> the results seems to be the right one. 
> Likewise, the search results in the Software Manager do not point to 
> anything that resembles Leo.
> 
> I don't know where else to look for it.
> I have noticed that some users on this forum use Leo on Linux, and at
> least one (Chris) uses Linux Mint.
> 
> Could you please provide some instructions?
> 
> Also, will the PyQt dependencies be downloaded and installed
> automatically by the Package/Software manager? In Windows I did it
> manually without any problems, but in Linux this is supposed to be
> automatic, as far as I understand. Only, I am not sure.
> 
> Any help will be appreciated.
> 
> Thanks
> 
> Dufriz
> 
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Installing Leo Mint

['Terry Brown' via leo-editor]

On Wed, 25 Jun 2014 20:07:19 +0100
dufriz  wrote:

> On Wed, Jun 25, 2014 at 7:53 PM, 'Terry Brown' via leo-editor
> 
> > Leo hasn't made it into the Ubuntu and related repositories, mostly
> > lack of developer time and developer knowledge, I don't know
> > anything about building packages.  At one time Ville had a PPA for
> > some releases of Leo, but those would be stale by now.
> >
> > I guess this is all assuming some degree of familiarity with Linux
> > scripts (bash etc.).
> 
> That is what I feared. This pretty much settles the question for me:
> I am staying on Windows, at least as far as Leo is concerned.
> 
> It's quite surprising, though, that a premiere open-source piece of
> software like Leo is not included in Linux repositories. I would have
> expected Linux repositories to be the first place to look for it!
> Too bad.

It's tragic if Leo ends up keeping someone stuck in Windows :-}
Would you be comfortable with a copy paste recipe of I'm guessing about
five lines which should install Leo?

Don't try this because I haven't tested it, but it would be something
like:

[open a shell terminal window]
sudo apt-get install python-qt4 python-qscintilla2 python-enchant 
sudo apt-get install unzip wget python-docutils python-pygments
mkdir $HOME/Leo
cd $HOME/Leo
wget https://github.com/leo-editor/leo-editor/archive/master.zip
unzip master.zip

I'm just spinning up a Qemu virtual system to test it on.

Any comments on the steps above, anyone?  If this works it could go on
the Leo install docs.

Cheers -Terry


-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Calling a leo class function from the minibuffer

['Terry Brown' via leo-editor]

On Wed, 25 Jun 2014 12:17:40 -0700 (PDT)
Fidel N  wrote:

> Haha thanks for the suggestion Terry.
> 
> Yes, AHK stands for AutoHotkey, a windows automation system.
> 
> And the main thing is its the other way around. AHK sniffs around my 
> actions, then points to Leo commands to complete them.
> So if I want to add my selected text (outside Leo) as a child of
> currently Leo selected node, AHK helps me call a command in Leo.

Hmm, I'd probably use a Leo button, 

  import time
  from PyQt4 import QtGui
  cb = QtGui.QApplication.clipboard()
  text = cb.text(mode=cb.Selection)
  nd = p.insertAfter()
  nd.h = text[:12]
  nd.b = "{text}\n\n# copied {time}".format(text=text, time=time.asctime())
  c.redraw()

Put that on a button and it will suck in the text selected in another
app. as long as Qt and the other app. are doing things the same way,
OpenOffice with it's java world view etc. might not cooperate, haven't
tried.

Use `mode=cb.Clipboard` to get text actually copied in the other app.
and not just selected.

Apologies to Edward for making it qt4 specific, I think his recent work
makes it easy to write code that works with qt4 and qt5.

If your use case means you don't want to find and click on the Leo
window, I'd either use leoserver or mod_http (plugins), both of which
allow you to communicate remotely with a running Leo, but you'd have to
do something to invoke a command to send the data.

Cheers -Terry

> Therefore, I still must find a way of 
> 
> If there is no way of calling scripts in Leo in a 'command line'
> fashion, I guess I will do this through clipboard... hell actually im
> going to do it that way:
> 
> AHK will send to clipboard the following:
> 
> Leo Command
> g.es('hello')
> 
> Then I will have a command in Leo that will be:
> 
> #ahk-run-clipboard
> commands = c.gui.getTextFromClipboard()
> 
> commands_list = commands.splitlines()
> commands_list.pop(0)
> commands = commands_list.join('\n')
> exec(commands)
> 
> Not very computer-literate but will do the job, unless anyone points
> out any other way hehe.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: current commander

['Terry Brown' via leo-editor]

On Thu, 26 Jun 2014 02:41:01 -0700 (PDT)
Fidel N  wrote:

> well found out I can solve it by using "c" as an argument in the
> functions defined in the other Leo window.
> 
> Then I can call those functions from other leo windows using their
> 'c' as argument.

Ok, good, I don't remember exactly where I ended up with that.  Just
poking around now, I believe, for the tabbed interface,

g.app.gui.frameFactory.masterFrame.currentWidget().leo_c

is the currently visible c.  But it would be nice to have
g.current_commander() which worked with both the tabbed and un-tabbed
interfaces.  Although maybe the concept makes no sense for un-tabbed
and detached tab interfaces, just a question of window manager focus.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Support for Qt5 has begun

['Terry Brown' via leo-editor]

On Sun, 15 Jun 2014 11:53:07 -0500
"'Terry Brown' via leo-editor"  wrote:

Another instance of this trap:
  https://github.com/leo-editor/leo-editor/commit/ecca25af

I think searching for all occurrences of clicked() and triggered() with
both kinds of quotes would find these.  In the above fix I didn't
follow my own advice, "make the callbacks match the basic definition of
the signals", hmmm.

Cheers -Terry

> Here's a trap though:
> 
> -def setter(pri=pri): o.setPri(pri)
> -self.connect(w, QtCore.SIGNAL("clicked()"), setter)
> +def setter(pri=pri):
> +o.setPri(pri)
> +if isQt5:
> +w.clicked.connect(setter)
> +else:
> +self.connect(w, QtCore.SIGNAL("clicked()"),
> setter)
> 
> The old form calls setter() with no parameters, the new form calls
> setter with `bool is_checked`, seeing buttons can be checked or
> unchecked when they're clicked.
> 
> I think the best solution is to change setter() to be
>   def setter(checked, pri=pri): ...
> which will work in both Qt4 and Qt5, basically the old
> style .connect() let you select whether that parameter got passed or
> not, but I think everything's cleaner if we just make the callbacks
> match the basic definition of the signals.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Is there a way to move button toolbar to the continuation of the menubar?

['Terry Brown' via leo-editor]

On Fri, 20 Jun 2014 11:39:17 -0500
"'Terry Brown' via leo-editor"  wrote:

> I've just added the following commands:
> 
>   gui-all-hide
>   gui-all-show
>   gui-iconbar-hide
>   gui-iconbar-show
>   gui-menu-hide
>   gui-menu-show
>   gui-minibuffer-hide
>   gui-minibuffer-show
>   gui-statusbar-hide
>   gui-statusbar-show

and now

  gui-tabbar-hide
  gui-tabbar-show

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Inaccuracies with @shadow

['Terry Brown' via leo-editor]

On Mon, 23 Jun 2014 07:26:58 +1200
David McNab  wrote:

> However, with numerous Python files, @shadow has been inaccurately
> writing out files. The main inaccuracies have been to do with indent
> levels for significant blocks of code (a massive dealbreaker in
> Python), which unless resolved makes Leo unusable in my team
> environment.

Hmm, I'm editing a LaTeX doc. and using @shadow just to see how it
goes, I could be using @file, but I've just noticed that @shadow was
losing the nesting structure until I added `@others` at all the right
places, which I don't think you need in @file, so not sure if that
would help you or be too onerous.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Is there a way to move button toolbar to the continuation of the menubar?

['Terry Brown' via leo-editor]

On Thu, 26 Jun 2014 13:54:32 -0500
"'Terry Brown' via leo-editor"  wrote:

> >   gui-minibuffer-show
> >   gui-statusbar-hide
> >   gui-statusbar-show  
> 
> and now
> 
>   gui-tabbar-hide
>   gui-tabbar-show

...and, realizing that show and hide commands are bad candidates for
key bindings, there are now toggle versions of each command.  So the
complete list is:

gui-all-hide
gui-all-show
gui-all-toggle
gui-iconbar-hide
gui-iconbar-show
gui-iconbar-toggle
gui-menu-hide
gui-menu-show
gui-menu-toggle
gui-minibuffer-hide
gui-minibuffer-show
gui-minibuffer-toggle
gui-statusbar-hide
gui-statusbar-show
gui-statusbar-toggle
gui-tabbar-hide
gui-tabbar-show
gui-tabbar-toggle

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Support for Qt5 has begun

['Terry Brown' via leo-editor]

On Fri, 27 Jun 2014 09:24:03 -0700 (PDT)
"Edward K. Ream"  wrote:

> On Friday, June 27, 2014 11:17:01 AM UTC-5, Edward K. Ream wrote:
> >
> >
> > Just added an "event" arg (the first arg) for several "clicked" 
> > callbacks.  The find buttons now work again ;-) 
> >
> > I'll do the same for "triggered" next.
> >
> 
> Done at the latest rev.  However, some callbacks are defined using
> lambda. I didn't change these and some of them (detach tab, for
> instance) appear to work.
> 
> Terry, when you get a chance, please review all the triggered
> callbacks. Thanks.

I've made a note.

I think it's generally a bool 'checked' arg. rather than the event
object that's passed in these cases, e.g.:
http://qt-project.org/doc/qt-5/qabstractbutton.html#clicked
but that doesn't stop adding an arg. named 'event' fixing things.

I think the lambda cases are either more robust or will produce a
runtime error more convincingly, but I'll have a look at them.

Of course the problem would never have arisen if Qt wasn't also trying
to support legacy languages like C++  ;-)  (kidding).

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: problems with the minibuffer

['Terry Brown' via leo-editor]

On Sat, 28 Jun 2014 07:47:24 -0500
"Edward K. Ream"  wrote:

> On Fri, Jun 27, 2014 at 6:07 AM, Zoltan Benedek 
> wrote:
> > Hi,
> >
> > Recently I've tried some commands in the minibuffer and got some
> > problems:
> 
> These have been fixed at rev ba20f6dbaa86.  They were introduced June
> 20 at rev 288847b40e3.
> 
> I'm glad this bug happened.  To find it, I had to zero in on the
> offending rev using a divide & conquer strategy.  This is super easy
> to do using git checkout.  Once I could see the buggy code, it was

Heh - read the docs. for `git bisect` :-)  Doesn't get easier than that
(although I've used it with an invalid bug test, doesn't work well
then :-)

Cheers -Terry

> obvious what the fix was.  My usual strategy of tracing the flow of
> focus-related calls did not work in this case.
> 
> Edward
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: unit testing increases number of registered handlers

['Terry Brown' via leo-editor]

On Mon, 30 Jun 2014 02:15:17 -0700 (PDT)
Fidel N  wrote:

> def on_idle(tag, keywords):
> g.es("iddle timer")
> 
> g.registerHandler("idle", on_idle)
> 
> g.enableIdleTimeHook(idleTimeDelay=5000)

Edward alluded to some of this in his response, but I'd say:

Never heard of the idleTimeDelay parameter, not sure I believe it
works that way, what if someone else started it with a delay of
1000, or it's just being called on idle by Qt's definition of idle,
so it could be a doc. bug.  I do this:

import time
c._todo_1_next = time.time() + 60  # fire once every 60 sec.

then the hook code looks like this

def check(tag, keywords, c=c):
if keywords['c'] != c:
return
now = time.time()
if now < c._todo_1_next:
   return
c._todo_1_next = now + 60

so although it's called once for every outline (c) open, it only fires
for the one it was defined in (it was defined by a @script in on
particular outline).

Cheers -Terry
 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: unit testing increases number of registered handlers

['Terry Brown' via leo-editor]

On Mon, 30 Jun 2014 11:44:59 -0500
"Edward K. Ream"  wrote:

> On Mon, Jun 30, 2014 at 4:31 AM, Fidel N  wrote:
> 
> > Still, idle is not yet useful because of firing several times the
> > command and not respecting the time.
> 
> Let's investigate the second problem (not respecting idle time).

But even if the idle time was respected, are there really separate idle
times for each registered hook?  Or just the first to init. idle time
events (which I think is in core) gets to specify the time?

I'm not sure the arg. makes sense, unless the idle time hook firing
code's more sneaky than I think it is.

Cheers -Terry

> What happens for you if you change::
> 
>timer.start(1000)
> 
> to::
> 
> timer.start(0)
> 
> in @file ../plugins/qtGui.py-->Gui wrapper-->
> class LeoQtGui-->Idle Time (qtGui)-->
> qtGui.setIdleTimeHook & setIdleTimeHookAfterDelay
> 
> Edward
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Does anyone use g.app.afterHandler (for idle-time processing)?

['Terry Brown' via leo-editor]

On Tue, 1 Jul 2014 05:06:27 -0700 (PDT)
"Edward K. Ream"  wrote:

> Leo's idle-time handling is a bit of a mess.  I'm thinking of
> simplifying it by putting most of the logic in qtGui.py.  This makes
> sense, imo, because idle-time handling is inherently platform/gui
> dependent.  I'll do this regardless of the choices I am about to
> discuss...
> 
> I have a half memory that someone wanted g.app.afterHandler, maybe
> for use by a plugin.  However Leo's sources don't use it, and I don't
> see how it could be useful without replacing the default idle-time
> event handler, g.idleTimeHookHandler, with something else.  And I
> don't see how the default idle-time event handler can be replaced
> without monkey-patching the Leo's code, which would mean that extra
> flexibility of g.app.afterHandler would not be needed anyway.
> 
> In short, the code seems to promise more flexibility than actually
> exists. There are two ways forward:
> 
> 1. Simplify the code by *always* using g.idleTimeHookHandler as the
> one and only idle-time hook.  This would be reasonable.

I'd do this unless someone can point out why it's insufficient.

> 2. Generalize the code by having the timer callback call a
> user-settable event handler, held in g.app.afterHandler, or better, 
> g.app.idleTimeEventHandler, with g.idleTimeHookHandler as the default
> value.

Not sure I entirely follow, but this seems like an approach which will
require careful use to avoid one on idle hook disabling another.

Cheers -Terry

> As I write this, I see that g.idleTimeHookHandler is a ridiculous
> name.  A hook is an event handler, so the name should either be
> g.idleTimeHook or g.idleTimeEventHandler.  I prefer the latter.
> 
> Your comments please.
> 
> Edward
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Using leo for documentation (rst3 html)

['Terry Brown' via leo-editor]

On Tue, 1 Jul 2014 10:54:25 -0700 (PDT)
Todd Mars  wrote:

> Another request!
> I've found a delay timer to execute code is very useful.  For
> example, if I stopped typing for 5 seconds,
> It would execute 'Alt-X Ctrl-P' and execute the last command which in
> my case is to produce my HTML (rst3)
> so I can look at it.
> This would help editing, making it more interactive editing in the
> rst3.

Ha, interesting idea.

https://github.com/leo-editor/snippets/blob/master/on_typing_idle.py

executes `g.es('do stuff')` whenever 5 seconds passes since the last
keystroke in the body editor.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

issues/bugs from launchpad to github - volunteers?

['Terry Brown' via leo-editor]

Hi all,

Any volunteers to move the issues/bugs from launchpad to github?
I think someone did an initial assessment but I can't remember the
conclusion.  It would be nice to get them all in one place.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Qt's triggered() signal

['Terry Brown' via leo-editor]

I've done some experiments and it seems that Qt can send its
triggered(checked) signal to callables that accept zero or more
arguments.

  foo.triggered.connect(lambda: do_something())
and
  foo.triggered.connect(lambda checked: do_something())

both work, it must either check or try/except the number of arguments
the slot will take, and include its checked bool if the slot takes
more than zero arguments.

Bottom line, you need to account for the checked argument unless your
slot accepts zero arguments, this is a bit inconsistent, which is why
I'm pointing it out, in particular an unexpected bool as the first
argument to a bound method gives you an invalid self value.  That in
itself seems odd, you usually can't displace the self on a bound
method, but these are SIP(?) bindings to the underlying C++ library, so
the rules are different.

The old style connect syntax allowed you to specify whether the checked
arg was included or not, that's why this needs case by case auditing
for the new style connections.

Background: checked refers to whether the thing that generated the
signal had an option checkbox checked when it was triggered, as menu
items and buttons may sometimes do.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Qt's triggered() signal

['Terry Brown' via leo-editor]

On Wed, 2 Jul 2014 09:09:57 -0500
"Edward K. Ream"  wrote:

> On Tue, Jul 1, 2014 at 7:12 PM, 'Terry Brown' via leo-editor
>  wrote:
> > I've done some experiments and it seems that Qt can send its
> > triggered(checked) signal to callables that accept zero or more
> > arguments.
> 
> Thanks for this research.  The following remarks are based on:
> 
> http://qt-project.org/doc/qt-5/qabstractbutton.html#signals
> 
> The signature of the checked signal is::
> 
>void clicked(bool checked = false)
> 
> so it seems that from the *python* point of view, the callback might
> be called with either zero or one arguments.  This should be true
> regardless of implementation.

This is getting a bit abstract :-) as we know what we need to know, but
I agree with your above statement that a callback with that signature
could be *called* with zero or one arguments.  But you can *define* the
callback to accept zero or more arguments, and somehow Qt knows to call
it with one arg. when it accepts one or more args, and to call it with
zero when it only accepts zero.

I.e. Qt can successfully callback either

  def cb():
or
  def cb(checked):

so somehow it's deciding whether to call it with zero or one args,
calling the first form with an arg is an error, the first one does not
have the signature (checked=False)

Anyway, going forward we know what to do - in some cases it may make
more sense to account for the checked arg in the callback definition,
in others it might be better to strip it in a lambda.  The latter when
you want to invoke the cb method from other places in the code and it
becomes intrusive to have to pass a dummy placeholder variable to match
the signature starting with a 'checked' arg.

Cheers -Terry

> The "checked" argument is not necessary because there is a
> checkState() getter.
> 
> My conclusions:
> 
> 1. The callback's signature should match the documented signature, as
> you have said previously.
> 
> 2. It doesn't matter whether the callback is defined using lambda or
> def, provided the signature is correct.
> 
> Edward
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: issues/bugs from launchpad to github - volunteers?

['Terry Brown' via leo-editor]

On Wed, 2 Jul 2014 08:16:43 -0700 (PDT)
Fidel N  wrote:

> Hi Terry, I also remember that was talked a while ago.
> You guys probably knew about this, but just in case, I found a batch 
> exporter from Launchpad into excel (half of the work):
> 
> https://answers.launchpad.net/launchpad/+question/216825

Cool, I think the key finding there is the existence of a python API
for launchpad: https://help.launchpad.net/API 

I assume there's one for github issues, although maybe not.

But even if there is, it seems like something someone must have
addressed before.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Using leo for documentation (rst3 html)

['Terry Brown' via leo-editor]

On Wed, 2 Jul 2014 10:44:08 -0500
"Edward K. Ream"  wrote:

> On Tue, Jul 1, 2014 at 1:39 PM, 'Terry Brown' via leo-editor
>  wrote:
> > On Tue, 1 Jul 2014 10:54:25 -0700 (PDT)
> > Todd Mars  wrote:
> 
> >> I've found a delay timer to execute code is very useful.  For
> >> example, if I stopped typing for 5 seconds,
> >> It would execute 'Alt-X Ctrl-P' and execute the last command which
> >> in my case is to produce my HTML (rst3)
> >> so I can look at it.
> 
> > Ha, interesting idea.
> 
> Another brilliant idea from Leo's users.
> 
> This would make a good extension to Ctrl-P (repeat-complex-command)::
> 
> Alt-x whatever
> repeat-complex-command-repeatedly :-)
> 
> Ctrl-G (keyboard-quit) would presumably cancel the repeats.
> 
> Terry, do you want to do this, or should I?

You saw what I posted here:
https://github.com/leo-editor/snippets/blob/master/on_typing_idle.py

so it would just be a matter of packaging - I would think the turn off
would have to be more specific than Ctrl-G, which the user may be using
for other things.

Also might be more useful to allow something other than just
repeat-complex-command, seeing the user may be using that for other
things too.

Seemed that the use case was:

Edit a document using any of Leo's features including Alt-X and Ctrl-G
(potentially), and, when no typing has occurred for a set time, run a
command or script or something *once* to render the doc.

I have no plans to do more with it, the script I posted could be used
to make a couple of buttons to start and stop the monitoring.

Cheers -Terry


> Edward
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: spatial versioning

['Terry Brown' via leo-editor]

On Thu, 3 Jul 2014 18:30:32 -0500
Kent Tenney  wrote:

> p.gnx is not currently writable, would it be a big
> deal to make it writeable? If not globally, for
> @auto tree nodes?

So wow, p.v.gnx is a property which only supports get, which is why you
can't write to it, which wasn't a surprise.  What is a surprise to me,
it's not just returning a hidden variable, it's calling
g.app.nodeIndices.toString(v.fileIndex), where v.fileIndex
is a tuple like ('tbrown', '20140703203404', 26811)
i.e. username, start of session timestamp, count of gnxs created in
session.

So it looks like making it writeable would be a big deal.  Although
g.app.nodeIndices.toString() shouldn't take long to execute, I do
wonder how much total CPU time it takes, given how often it must be
called.  Well, having said that, maybe it's not called that much.
Other than serialization, you're usually dealing with in memory objects
directly.

Still, interesting I'd never looked at such a fundamental piece of Leo.

Kent - you could write to it like this:

p.v.fileIndex = (p.v.fileIndex[0], my_info, p.v.fileIndex[2])
my_info = p.v.fileIndex[1]

although that trashes the timestamp and jeopardizes the uniqueness.

I think you should aim to use UNLs instead, seeing they can easily
persist in @auto etc.

Cheers -Terry


> Thanks,
> Kent
> 
> On Thu, Jul 3, 2014 at 7:46 AM, Edward K. Ream 
> wrote:
> > On Thu, Jul 3, 2014 at 6:40 AM, Kent Tenney 
> > wrote:
> >> The version I'm developing on is using a back end with a bunch of
> >> dependencies, but I'll see about simplifying it, Sqlalchemy +
> >> sqlite should be sufficient. (someone with sql chops could
> >> eliminate sqlalchemy)
> >>
> >> Dang, I've been testing choices development with regular nodes,
> >> but day to day I'm always working in <@auto somefile.py> trees,
> >> and gnx is ephemeral. Maybe a hash of UNL would work for primary
> >> key instead of gnx
> >  ...
> >
> > Interesting coincidence of several recent trains of thought:
> >
> > 1. Recently I removed almost all clones from leoProjects.txt and
> > leoNotes.txt.  You could call it a matter of housekeeping, but I'm
> > moving towards a workflow in which clones exist only until a project
> > is done.  So they are becoming more ephemeral.
> >
> > 2. ArmageDOOM mentioned this link on #leo:
> >  https://news.ycombinator.com/item?id=7511979
> >
> > One of the comments was that Leo's file format "hadn't taken off".
> > Without gnx's, Leo's external files would be identical (or nearly
> > so) with org mode.  No, this doesn't really make @auto processing
> > any easier, because even org mode sentinels will be unacceptable to
> > most non-Leonine users.
> >
> > 3.  I recently realized that clones are a bit of a nuisance for
> > find/change.  The more clones I have, the more duplicates there are
> > when using F3 (find-next)
> >
> > For all these reasons, I am beginning to wonder whether clones can
> > somehow be put a little more behind the scenes.
> >
> > To be sure, clones (vnodes) are likely always to exist as a basic
> > capability, but if clones can be made just slightly more "ephemeral"
> > then gnx's might not be needed in external files.  For example, I
> > wonder whether my work flow could be based on a combination of
> > Terry's bookmarks and (perhaps) automatically generated (and thus
> > more ephemeral) clones.
> >
> > In this context, your comments about hashing the UNL fits right into
> > the zeitgeist.  Bookmarks are, iirc, just unl's...
> >
> > In short, this could be an important new direction for Leo.  No, we
> > aren't going to get rid of clones.  No, we aren't going to get rid
> > of sentinels.  But there might be important benefits if we can
> > convert sentinels to org-mode format, and if we can make clones
> > more of the plumbing than the porcelain (to use git terminology).
> >
> > In short, it looks like you are leading the way again, Kent.
> >
> > Edward
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "leo-editor" group. To unsubscribe from this group and stop
> > receiving emails from it, send an email to
> > leo-editor+unsubscr...@googlegroups.com. To post to this group,
> > send email to leo-editor@googlegroups.com. Visit this group at
> > http://groups.google.com/group/leo-editor. For more options, visit
> > https://groups.google.com/d/optout.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: spatial versioning

['Terry Brown' via leo-editor]

On Fri, 4 Jul 2014 07:32:19 -0500
Kent Tenney  wrote:

> the problem with UNLs is they don't allow choices which involve
> changing the headline. If I change the name of a method, I don't
> want to lose the choices for the implementation of that method.
> 
> Thanks for doing the work re: gnx setting. The code you provided
> works a champ.

As long as you don't go from

Node A ('ktenney', '20110117134522', 7)
Node B ('ktenney', '20140807232334', 7)

to

Node A ('ktenney', 'init_vars', 7)
Node B ('ktenney', 'init_vars', 7)

or something like that.

Also changing gnxs might break pointers to nodes from other places.

You could just 

  p.v.u.setdefault('space_vers', {})['id'] = uuid.uuid4()

or more readable

  if 'space_vers' not in p.v.u:
  p.v.u['space_vers'] = {}
  p.v.u['space_vers']['id'] = uuid.uuid4()

using the space_vers `namespace` assuming you'll want to store more
than one thing on the node.  Like the index of the version you're
currently viewing, I guess.

Oh, doh, but that's not helping at all with the @auto stuff.

> The idea would be a table in the companion db which, on closing
> the Leo file would generate key/value pairs  @auto tree UNL / gnx
> on opening the Leo file and after parsing the @auto file, the
> @auto tree gnx's would be reverted to the previous ones, simulating
> the persistence of regular nodes. No collision issues.

And doh again, really should have read the whole email before I started
replying :-}

Sounds like you're on a reasonable path.

@shadow has persistent uas and gnxs.

Cheers -Terry

> Come to think of it, the table in the companion db could also
> trivially save the ua of the @auto tree nodes, ... at which point the
> @auto tree nodes are as rich a data store as a regular node.
> 
> If the file had been edited outside Leo since Leo saw it last, the
> nodes in the db could be tagged as obsolete, or new records created
> accordingly.
> 
> If the db were updated on changes instead of on closing, less would be
> lost in a crash.
> 
> I'll ruminate this approach until the reason it won't work rears it's
> ugly.
> 
> [-:
> 
> On Thu, Jul 3, 2014 at 8:50 PM, 'Terry Brown' via leo-editor
>  wrote:
> > On Thu, 3 Jul 2014 18:30:32 -0500
> > Kent Tenney  wrote:
> >
> >> p.gnx is not currently writable, would it be a big
> >> deal to make it writeable? If not globally, for
> >> @auto tree nodes?
> >
> > So wow, p.v.gnx is a property which only supports get, which is why
> > you can't write to it, which wasn't a surprise.  What is a surprise
> > to me, it's not just returning a hidden variable, it's calling
> > g.app.nodeIndices.toString(v.fileIndex), where v.fileIndex
> > is a tuple like ('tbrown', '20140703203404', 26811)
> > i.e. username, start of session timestamp, count of gnxs created in
> > session.
> >
> > So it looks like making it writeable would be a big deal.  Although
> > g.app.nodeIndices.toString() shouldn't take long to execute, I do
> > wonder how much total CPU time it takes, given how often it must be
> > called.  Well, having said that, maybe it's not called that much.
> > Other than serialization, you're usually dealing with in memory
> > objects directly.
> >
> > Still, interesting I'd never looked at such a fundamental piece of
> > Leo.
> >
> > Kent - you could write to it like this:
> >
> > p.v.fileIndex = (p.v.fileIndex[0], my_info, p.v.fileIndex[2])
> > my_info = p.v.fileIndex[1]
> >
> > although that trashes the timestamp and jeopardizes the uniqueness.
> >
> > I think you should aim to use UNLs instead, seeing they can easily
> > persist in @auto etc.
> >
> > Cheers -Terry
> >
> >
> >> Thanks,
> >> Kent
> >>
> >> On Thu, Jul 3, 2014 at 7:46 AM, Edward K. Ream
> >>  wrote:
> >> > On Thu, Jul 3, 2014 at 6:40 AM, Kent Tenney 
> >> > wrote:
> >> >> The version I'm developing on is using a back end with a bunch
> >> >> of dependencies, but I'll see about simplifying it, Sqlalchemy +
> >> >> sqlite should be sufficient. (someone with sql chops could
> >> >> eliminate sqlalchemy)
> >> >>
> >> >> Dang, I've been testing choices development with regular nodes,
> >> >> but day to day I'm always working in <@auto somefile.py> trees,
> >> >> and gnx is ephemeral.

Re: spatial versioning

['Terry Brown' via leo-editor]

On Fri, 4 Jul 2014 11:03:08 -0500
Kent Tenney  wrote:

> >@shadow has persistent uas and gnxs.
> 
> and done in an interesting way: the @shadow 
> organizer node ua contains the gnx of the file.
> 
> @shadow doesn't parse .py, so it doesn't meet my needs

Hmm, I often load files in Leo using the leoserver script to load them
from the command line, which pulls them in as @edit nodes.  The if it
was a python file and I want it parsed, I just change 'edit' to 'auto'
and use "refresh from disk".  There are some issues with refresh from
disk but it works in this context.  Longwinded way of saying you could
use @auto to load and parse the file and the switch it to @shadow.

But if there isn't one already, we should have a command that performs
"@auto" parsing on the selected node.  It could also be used if you
write a bunch of little stub function definitions in one node and then
want them parsed into separate nodes for easy navigation.

Cheers -Terry

> Could the @auto  organizer ua be convinced to persist the
> gnx's of the last parsed file?
> 
> ... and, thanks for the reminder, I'll see if c.db will be sufficient
> 
> 
> 
> On Fri, Jul 4, 2014 at 10:00 AM, 'Terry Brown' via leo-editor
>  wrote:
> > On Fri, 4 Jul 2014 07:32:19 -0500
> > Kent Tenney  wrote:
> >
> >> the problem with UNLs is they don't allow choices which involve
> >> changing the headline. If I change the name of a method, I don't
> >> want to lose the choices for the implementation of that method.
> >>
> >> Thanks for doing the work re: gnx setting. The code you provided
> >> works a champ.
> >
> > As long as you don't go from
> >
> > Node A ('ktenney', '20110117134522', 7)
> > Node B ('ktenney', '20140807232334', 7)
> >
> > to
> >
> > Node A ('ktenney', 'init_vars', 7)
> > Node B ('ktenney', 'init_vars', 7)
> >
> > or something like that.
> >
> > Also changing gnxs might break pointers to nodes from other places.
> >
> > You could just
> >
> >   p.v.u.setdefault('space_vers', {})['id'] = uuid.uuid4()
> >
> > or more readable
> >
> >   if 'space_vers' not in p.v.u:
> >   p.v.u['space_vers'] = {}
> >   p.v.u['space_vers']['id'] = uuid.uuid4()
> >
> > using the space_vers `namespace` assuming you'll want to store more
> > than one thing on the node.  Like the index of the version you're
> > currently viewing, I guess.
> >
> > Oh, doh, but that's not helping at all with the @auto stuff.
> >
> >> The idea would be a table in the companion db which, on closing
> >> the Leo file would generate key/value pairs  @auto tree UNL / gnx
> >> on opening the Leo file and after parsing the @auto file, the
> >> @auto tree gnx's would be reverted to the previous ones, simulating
> >> the persistence of regular nodes. No collision issues.
> >
> > And doh again, really should have read the whole email before I
> > started replying :-}
> >
> > Sounds like you're on a reasonable path.
> >
> > @shadow has persistent uas and gnxs.
> >
> > Cheers -Terry
> >
> >> Come to think of it, the table in the companion db could also
> >> trivially save the ua of the @auto tree nodes, ... at which point
> >> the @auto tree nodes are as rich a data store as a regular node.
> >>
> >> If the file had been edited outside Leo since Leo saw it last, the
> >> nodes in the db could be tagged as obsolete, or new records created
> >> accordingly.
> >>
> >> If the db were updated on changes instead of on closing, less
> >> would be lost in a crash.
> >>
> >> I'll ruminate this approach until the reason it won't work rears
> >> it's ugly.
> >>
> >> [-:
> >>
> >> On Thu, Jul 3, 2014 at 8:50 PM, 'Terry Brown' via leo-editor
> >>  wrote:
> >> > On Thu, 3 Jul 2014 18:30:32 -0500
> >> > Kent Tenney  wrote:
> >> >
> >> >> p.gnx is not currently writable, would it be a big
> >> >> deal to make it writeable? If not globally, for
> >> >> @auto tree nodes?
> >> >
> >> > So wow, p.v.gnx is a property which only supports get, which is
> >> > why you can't write to it, which wasn't a surprise.  What is a
> >> > surp

Re: spatial versioning

['Terry Brown' via leo-editor]

On Fri, 4 Jul 2014 15:36:47 -0500
Kent Tenney  wrote:

> as simple as that routine is, it's too complex for me to
> remember and apply consistently. I would rather spend
> many many hours coming up with a way to avoid those
> 5 seconds of effort.

http://xkcd.com/1205/

:-) Cheers -Terry

> On Fri, Jul 4, 2014 at 2:38 PM, 'Terry Brown' via leo-editor
>  wrote:
> > On Fri, 4 Jul 2014 11:03:08 -0500
> > Kent Tenney  wrote:
> >
> >> >@shadow has persistent uas and gnxs.
> >>
> >> and done in an interesting way: the @shadow 
> >> organizer node ua contains the gnx of the file.
> >>
> >> @shadow doesn't parse .py, so it doesn't meet my needs
> >
> > Hmm, I often load files in Leo using the leoserver script to load
> > them from the command line, which pulls them in as @edit nodes.
> > The if it was a python file and I want it parsed, I just change
> > 'edit' to 'auto' and use "refresh from disk".  There are some
> > issues with refresh from disk but it works in this context.
> > Longwinded way of saying you could use @auto to load and parse the
> > file and the switch it to @shadow.
> >
> > But if there isn't one already, we should have a command that
> > performs "@auto" parsing on the selected node.  It could also be
> > used if you write a bunch of little stub function definitions in
> > one node and then want them parsed into separate nodes for easy
> > navigation.
> >
> > Cheers -Terry
> >
> >> Could the @auto  organizer ua be convinced to persist the
> >> gnx's of the last parsed file?
> >>
> >> ... and, thanks for the reminder, I'll see if c.db will be
> >> sufficient
> >>
> >>
> >>
> >> On Fri, Jul 4, 2014 at 10:00 AM, 'Terry Brown' via leo-editor
> >>  wrote:
> >> > On Fri, 4 Jul 2014 07:32:19 -0500
> >> > Kent Tenney  wrote:
> >> >
> >> >> the problem with UNLs is they don't allow choices which involve
> >> >> changing the headline. If I change the name of a method, I don't
> >> >> want to lose the choices for the implementation of that method.
> >> >>
> >> >> Thanks for doing the work re: gnx setting. The code you provided
> >> >> works a champ.
> >> >
> >> > As long as you don't go from
> >> >
> >> > Node A ('ktenney', '20110117134522', 7)
> >> > Node B ('ktenney', '20140807232334', 7)
> >> >
> >> > to
> >> >
> >> > Node A ('ktenney', 'init_vars', 7)
> >> > Node B ('ktenney', 'init_vars', 7)
> >> >
> >> > or something like that.
> >> >
> >> > Also changing gnxs might break pointers to nodes from other
> >> > places.
> >> >
> >> > You could just
> >> >
> >> >   p.v.u.setdefault('space_vers', {})['id'] = uuid.uuid4()
> >> >
> >> > or more readable
> >> >
> >> >   if 'space_vers' not in p.v.u:
> >> >   p.v.u['space_vers'] = {}
> >> >   p.v.u['space_vers']['id'] = uuid.uuid4()
> >> >
> >> > using the space_vers `namespace` assuming you'll want to store
> >> > more than one thing on the node.  Like the index of the version
> >> > you're currently viewing, I guess.
> >> >
> >> > Oh, doh, but that's not helping at all with the @auto stuff.
> >> >
> >> >> The idea would be a table in the companion db which, on closing
> >> >> the Leo file would generate key/value pairs  @auto tree UNL /
> >> >> gnx on opening the Leo file and after parsing the @auto file,
> >> >> the @auto tree gnx's would be reverted to the previous ones,
> >> >> simulating the persistence of regular nodes. No collision
> >> >> issues.
> >> >
> >> > And doh again, really should have read the whole email before I
> >> > started replying :-}
> >> >
> >> > Sounds like you're on a reasonable path.
> >> >
> >> > @shadow has persistent uas and gnxs.
> >> >
> >> > Cheers -Terry
> >> >
> >> >> Come to think of it, the table in the companion db could also
> >> >

Re: Standarized file importing, and keeping Leo updated

['Terry Brown' via leo-editor]

On Sun, 6 Jul 2014 02:04:11 -0700 (PDT)
Fidel N  wrote:

> Is there a way I could still import files that way, without having to
> touch LeoPyRef?
> Having that file uncompatible with the main Leo repo keeps me away
> from making pull requests and such, since whenever I want to suggest
> something, that line gets in the way. And I cant update Leo quickly
> because then I have to edit that line again, etc.

In similar cases I've used a @script node in my local (personal,
i.e. not part of Leo) .leo files to alter Leo's behavior via monkey
patching.

Hmm, this example turned out less interesting than I thought:

class LeoInternalClass:
def seven(self, x):
print(7,x)

lic1 = LeoInternalClass()
lic2 = LeoInternalClass()

print("pre-patch")
lic1.seven('1')
lic2.seven('2')

def new_seven(self,x):
print("seven",x)

LeoInternalClass.seven = new_seven

print("\nPatch class and lic2 instance")
lic2.seven = lambda x, self=lic2: new_seven(self, x)

lic3 = LeoInternalClass()

lic1.seven('1')
lic2.seven('2')
lic3.seven('3')

def newer_seven(self,x):
print("3+4",x)

LeoInternalClass.seven = newer_seven

lic4 = LeoInternalClass()

print("\nPatch class again")
lic1.seven('1')
lic2.seven('2')
lic3.seven('3')
lic4.seven('4')

Basically, patch the class, all current and future instances affected
*unless* the instance has been patched.  Patch the instance, and
patches to the class are irrelevant.

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Standarized file importing, and keeping Leo updated

['Terry Brown' via leo-editor]

On Sun, 6 Jul 2014 14:16:18 -0700 (PDT)
Fidel N  wrote:

> Thank you both. Already tried both ways; And failed but already very
> close.
> 
> Edward, how is Leo supposed to know that my "leopyref.leo" file now
> will be leopy.leo? Where do I have to tell Leo to search for leopy
> instead of leopyref?
> 
> 
> Terry, I like your solution very much, but my lack of python
> knowledge let me on the edge here.
> It was already "fun" enough to reach the class and the function
> itself:
> 
> c.frame.tree.treeWidget.urlDrop
> 
> But when I replace that function with my (actually working in Leo)
> one, it throws this error:
> http://i.imgur.com/5ZvRFJ5.png
> I know I reached the one I wanted because in other windows, where I
> didnt replace it, it works as usual.

I'm guessing you left out my lambda: part.  Maybe this is a better way
to do it:

import types
class LeoInternalClass:
def seven(self, x):
print(7,x)

lic1 = LeoInternalClass()
lic2 = LeoInternalClass()

print("pre-patch")
lic1.seven('1')
lic2.seven('2')

def new_seven(self,x):
print("seven",x)

# patch the class
LeoInternalClass.seven = new_seven

print("\nPatch class and lic2 instance")

# and patch the object (normally do only one)

# either lic2.seven = lambda x, self=lic2: new_seven(self, x)
# or, without futzing with arguments
lic2.seven = types.MethodType(new_seven, lic2)

lic3 = LeoInternalClass()

lic1.seven('1')
lic2.seven('2')
lic3.seven('3')

def newer_seven(self,x):
print("3+4",x)

LeoInternalClass.seven = newer_seven

lic4 = LeoInternalClass()

print("\nPatch class again")
lic1.seven('1')
lic2.seven('2')
lic3.seven('3')
lic4.seven('4')

types.MethodType() is much cleaner than that lambda thing.

Cheers -Terry

> Thanks again!
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Using leo for documentation (rst3 html)

['Terry Brown' via leo-editor]

On Mon, 7 Jul 2014 09:59:09 -0700 (PDT)
Todd Mars  wrote:

> 
> >
> > The Repeats: It is to perform a command when the user stops typing,
> > right?
> >
>  
> --If the user has not type, nothing is done.
> --If the user has typed, then the timer starts.  If there was a timer 
> already, it's just reset to the delay time.
> --when the timer fires, the command is executed. 
> 
> just checking thanks Todd since I initiated this thing.

That was basically what it did, I just updated
https://github.com/leo-editor/snippets/blob/master/on_typing_idle.py

with these changes:
https://github.com/leo-editor/snippets/commit/ab239e1

so that's now exactly what it does, or exactly what I expect it to do,
not tested :-)

Cheers -Terry

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: How to Ctrl-C a script started by Ctrl-B?

['Terry Brown' via leo-editor]

On Mon, 7 Jul 2014 18:55:11 -0700 (PDT)
SegundoBob  wrote:

> Does anyone know how to cancel a Leo-Editor script that is started by 
> Ctrl-B?

I'm not sure if it can be done from Leo, I think the Ctrl-B scripts are
run in the same process as Leo itself.  Would a solution involving
sending the signal from the unix/linux command line be relevant to
you?  Although that may kill Leo completely, so I'm not sure it would
help.

Cheers -Terry

> I know how to use Ctrl-C to cancel a python script that is run from
> the command line:
> 
> import sys
> import time
> 
> idx = 0
> try:
> while True:
> print '{0}\r'.format(idx),
> sys.stdout.flush()
> idx += 1
> time.sleep(1)
> except KeyboardInterrupt:
> print '\nKeyboardInterrupt'
> print('Bye')
> 
> 
> But this does not work for a Leo-Editor script started by Ctrl-B.
> 
> Since Leo-Editor is a PyQt4 application, I tried some of the
> solutions suggested here:
> 
> http://stackoverflow.com/questions/4938723/what-is-the-correct-way-to-make-my-pyqt-application-quit-when-killed-from-the-co
> 
> But they don't work.
> 
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: about @auto

['Terry Brown' via leo-editor]

On Tue, 8 Jul 2014 08:18:04 -0500
Kent Tenney  wrote:

> Wondering about current status and potential direction:

I'm wondering what the difference between @auto with persistence and
@shadow is... is @shadow not trusted enough or has limitations that
need addressing?

I'm not aware of a solution for @auto persistence which would look much
different than @shadow.

Cheers -Terry

> There have been a couple of mentions of @auto nodes
> gaining persistence, what are the chances of this happening
> in core? Something like persistent UAs, such that
> @auto  would store the UAs of the tree, putting
> them in it's UA.
> 
> I'll start on scaffolding outside Leo to persist @auto nodes
> if this isn't going to happen, but core would be nice.
> #cough#(someone else does the work)#cough#
> 
> I think there would be potential benefits beyond my
> particular proclivities. No other tool offers
> the power of transparently bringing the power of a
> database to code in this way.
> 
> There is also a pretty old bug in 'refresh from disk'
> just saying ...
> https://groups.google.com/forum/#!topic/leo-editor/Qp4D74Ig_jY
> https://bugs.launchpad.net/leo-editor/+bug/1259127
> 
> Thanks,
> Kent
> 
> PS
> I've realized another reason @file doesn't interest me other
> than the problem with sentinels when editing outside Leo.
> 
> I place a lot of value on structuring with Leo, the huge benefit
> of hierarchical arrangement of headline/body pairs. Content
> that lives in the Leo file gains value through the power of outlining.
> 
> However, when working with source code, I consider the correct
> structure to be that provided by the language: declarations,
> functions, classes, methods ... exactly what @auto does, no more, no
> less.
> 
> Of course this is a matter of taste, not correctness.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: How to Ctrl-C a script started by Ctrl-B?

['Terry Brown' via leo-editor]

On Tue, 8 Jul 2014 12:52:40 +0300
"Ville M. Vainio"  wrote:

> Yeah, just press ctrl-c in the terminal you used to launch Leo

I was thinking more of locating the pid and sending a signal with
'kill', in the case where you didn't have the launching terminal
available :-)

Cheers -Terry

>  On Jul 8, 2014 5:21 AM, "'Terry Brown' via leo-editor" <
> leo-editor@googlegroups.com> wrote:
> 
> > On Mon, 7 Jul 2014 18:55:11 -0700 (PDT)
> > SegundoBob  wrote:
> >
> > > Does anyone know how to cancel a Leo-Editor script that is
> > > started by Ctrl-B?
> >
> > I'm not sure if it can be done from Leo, I think the Ctrl-B scripts
> > are run in the same process as Leo itself.  Would a solution
> > involving sending the signal from the unix/linux command line be
> > relevant to you?  Although that may kill Leo completely, so I'm not
> > sure it would help.
> >
> > Cheers -Terry
> >
> > > I know how to use Ctrl-C to cancel a python script that is run
> > > from the command line:
> > >
> > > import sys
> > > import time
> > >
> > > idx = 0
> > > try:
> > > while True:
> > > print '{0}\r'.format(idx),
> > > sys.stdout.flush()
> > > idx += 1
> > > time.sleep(1)
> > > except KeyboardInterrupt:
> > > print '\nKeyboardInterrupt'
> > > print('Bye')
> > >
> > >
> > > But this does not work for a Leo-Editor script started by Ctrl-B.
> > >
> > > Since Leo-Editor is a PyQt4 application, I tried some of the
> > > solutions suggested here:
> > >
> > >
> > http://stackoverflow.com/questions/4938723/what-is-the-correct-way-to-make-my-pyqt-application-quit-when-killed-from-the-co
> > >
> > > But they don't work.
> > >
> > >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "leo-editor" group.
> > To unsubscribe from this group and stop receiving emails from it,
> > send an email to leo-editor+unsubscr...@googlegroups.com.
> > To post to this group, send email to leo-editor@googlegroups.com.
> > Visit this group at http://groups.google.com/group/leo-editor.
> > For more options, visit https://groups.google.com/d/optout.
> >
> 

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.