Re: Leo 5.7b1 released

[Matt Wilkie]

> I don't understand what your complaint is.  Copy and paste of links do 
> work in many cases.  It doesn't work in Leo itself, though, because Leo's 
> body pane contains only text.
>

I think he means at least one url should be spelled out, e.g. 
http://leoeditor.com, so that people who only see the plain text version 
still have something they can follow.

matt

-- 
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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Mermaid flowcharts from Leo subtree in Leo Vue

[Matt Wilkie]

*applause*

-- 
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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: [QA]Advices for Leo documentation in Chinese translated version?

[Matt Wilkie]

Great news! I'm not sure I can help, but I will cheer you on :-)

Matt

-- 
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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Leo's 5.7 docs are complete

[Matt Wilkie]

Thanks for the work on reorganizing the install docs! and finding a way to 
incorporate the new PyPi method. Install docs are indeed the most 
important, and the hardest to get right. I often dread this part ;-) 

Some thoughts:

Installing Leo with Pip section has Python 2 and Python 3 mixed up. I 
created a branch, `install-docs-mhw` and committed an alternative wording 
to try:
https://github.com/leo-editor/leo-editor/commit/557fe936f8202720fc42dc5564ab5402bea2231d

I just focused on the one section. I think there's something more that can 
be done overall, like moving Mini/Anaconda to the top since that is what 
we' d like people to do by default if they can (right?). But other than 
thinking "there's room for improvement" I haven't actually tried writing it 
yet.

matt

-- 
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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Leo 5.7b1 released

[ne1uno]

QQQ
Leo 5.7b1 is now available on SourceForge and on GitHub. As always, many thanks 
to all 
...
Links
Leo's home page
Documentation
Tutorials
Video tutorials
Forum
Download
Leo on GitHub
LeoVue
What people are saying about Leo
A web page that displays .leo files
More links
QQQ

a plain text copy of parts of your post.
notice there is nothing resembling a link

this forces anyone to bookmark or use right now the google redirect link
in some applications the links might travel?
I know I often will copy text in a note, more annoying also copy links extra 
step
but usually don't bookmark google redirect links or save them with a note
too long, no guarentee they will work in the future, 
don't want to share them for various reasons, it's no longer a plain link

google you may not have noticed tricks you into thinking the link is plain
by showing only the link in the status bar or on mouseover using the title=

a few in the forum make a point of showing at least a few plain links in their 
posts
maybe you could add one or two links to the announcements 
github and leoeditor maybe?


posted/edited with a mobil browser useragent on desktop,
no idea how the quoted text is going to show
there is no option but to top quote

google never misses an opportunity to show you only what it wants to
not that they're evil or anything, just a little too quick to take liberties 
and shortcuts
notice no forward button or tooltips in android. improving by removing? who 
knows for sure

-- 
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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: An avalanche of new thoughts

[Edward K. Ream]

On Thu, Feb 1, 2018 at 1:40 PM, Joe Orr  wrote:

> Not sure I understand what you mean by use browser as graphics backend,
> just wanted to note that it is definitely possible to make a desktop app
> with browser technology (Electron).  Just need to wrap the backend in node.
>

​Thanks for the confirmation. Your comments make this approach more likely.

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Mermaid flowcharts from Leo subtree in Leo Vue

[Joe Orr]

Added a new feature which might be worth a look.

Mermaid is a markup language for creating and viewing diagrams such as 
flowcharts and Gannt charts. Leo Vue already support Mermaid, but I added a 
new directive that will create an interactive flowchart from the subtree of 
a node. Because of Leo's clone nodes, these flowcharts can be more complex 
than simple trees. 

1.5 min overview video 

Also added couple more things: Kanban summary nodes, inherit language 
directives.

Joe Orr




-- 
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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Leo Vue

[Joe Orr]

Matt,

Thanks for the note. I think the project at the least shows the power of 
the web development system. 

I'm mostly just adding features that I personally want to use. I think 
there are plenty more possibilities, and others more knowledgable about Leo 
will no doubt have some ideas.

Joe

On Monday, January 22, 2018 at 1:13:49 PM UTC-5, Matt Wilkie wrote:
>
> This is seriously nice work Joe. Thanks for the demo, sharing, and most of 
> all: inspiring!
>
> Matt
>
> On Mon, Jan 1, 2018 at 3:08 PM, Joe Orr  
> wrote:
>
>> The Leo HTML viewer is now Leo Vue - added more Vue integration.
>>
>> https://github.com/kaleguy/leovue
>>
>> Added:
>> * Search
>> * Static Site Generation
>> * Clickable Section Links
>> * Ability to put Vue components in Content (e.g. Diagrams, Maps, Charts, 
>> Table, others)
>> * Vue components can read JSON and CSV data from nodes
>> * Nested Presentations with Reveal.js
>>
>> - Joe
>>
>> -- 
>> 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+...@googlegroups.com .
>> To post to this group, send email to leo-e...@googlegroups.com 
>> .
>> Visit this group at https://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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: An avalanche of new thoughts

[Joe Orr]

Not sure I understand what you mean by use browser as graphics backend, 
just wanted to note that it is definitely possible to make a desktop app 
with browser technology (Electron).  Just need to wrap the backend in node.

Joe

On Wednesday, January 31, 2018 at 12:12:01 PM UTC-5, Edward K. Ream wrote:
>
> Something totally unexpected happened today after reviewing the ancient 
> items in leo/doc/leoToDo.txt.  I see new directions for Leo, and new ways 
> to think about old issues.
>
> *Background*
>
> This particular avalanche was triggered by reading Kent's request for 
> "node pipes".  I have just created #667 
>  for this request. 
> The actual trigger was realizing how badly I had misunderstood Kent's 
> request.  Kent made his request explicitly in terms of the demo at the 
> bottom of Light Table's main page . Kent wasn't 
> asking for a way to pipe data into p.b. That's trivial.  Instead, he was 
> asking for a way to "inject" data into the gui itself.  For example, one 
> might want to inject data into the body pane's *gui*, that is, 
> c.frame.body.wrapper.  That's considerably harder.  And a whole lot niftier.
>
> The "snow pack" of the avalanche consisted of lengthy discussions in 
> leo/doc/leoToDo.txt.  In particular, Offray complains at length that 
> software is way too hard to develop. Software is too sclerotic.
>
> *Flexible vs sclerotic*
>
> I asked myself: how can Light Table be so flexible?  My answer (perhaps 
> bogus?) was that Light Table is based on html/javascript/css. As a result, 
> Light Table, through the js DOM, has full access to the visual components.  
> This shaky conclusion has had many interesting results.
>
> I then asked myself, what parts of Leo are flexible, and which are 
> sclerotic?
>
> - *Flexible*: Leo's scripting API and related DOM.
>
> Both are much better than good enough, and both are easily and fully 
> extensible.
>
> - *Flexible*: Leo's plugin mechanism.
>
> Again, plugins are much better than just good enough, and plugins have 
> unlimited flexibility.
>
> - *Flexible*: Leo's abstract panes.
>
> The console gui plugin drives Leo's tree, body and log panes without any 
> interaction at all between Leo's commands and the actual body code.  That 
> is, all of Leo's commands are insulated from the details of the particular 
> gui in effect.
>
> - *Sclerotic*: Leo's @shortcuts nodes mix all pane bindings together.
>
> Instead, Leo could use @data -shortcut nodes that are inheritable.  
> Like this:
>
>- @data text-shortcuts: definitions for *all *text widgets, unless 
> overridden in children.
>  - @body-shortcuts (overrides for the body pane)
>  - @minibuffer-shortcuts
>
> This would provide a way of defining *key tables* for each *individual 
> *widget.  
> This would greatly simplify Leo's internal processing.
>
> - *Sclerotic*: Leo's concrete gui code.
>
> Terry has made Leo's gui more flexible than it was, but Qt seems to be 
> showing signs of age.  In contrast, web development continues to gain 
> momentum.  Joe Orr's LeoVue project highlights what can be done with 
> off-the-shelf web components. Imo, Leo is always going to be a desktop app, 
> but I am thinking that Leo might use a browser as the graphics back end.
>
> Leo could simulate the js DOM with a new Leonine API.  For example, it 
> would be possible to simulate  getElementByName by searching through Leo's 
> Qt widgets, using widget.parent(), widget.children() and widget.objectName()
>
> - *Partially sclerotic*: Leo's rendering tools.
>
> The rst3 command is flexible, but uses horribly complex code in the 
> background.  Similarly remarks apply to the VR and VR2 plugins.  Perhaps we 
> are suffering from vue.js envy. The soon-to-be-created new rendering 
> enhancement requests suggest possible ways forward.
>
> - *Partially sclerotic*: Leo's attribute handling.
>
> The newly renamed #588 Make node attributes visible, with support in 
> Leo's core  aims to 
> make attributes more flexible *and* more visible. Along with type-related 
> Leo directives, it might be good to make rendering-type "bits" visible in 
> all headlines.
>
> *Summary*
>
> There is a lot to chew on here. The overall goal is render Leo's gui in 
> the niftiest, most flexible manner possible. It may be that web/javascript 
> tools will be the new path forward.
>
> I will be creating about 30 new enhancement requests as time allows.  They 
> may suggest new ways to make Leo more flexible.
>
> All comments welcome.  Please try to avoid dissertations ;-)
>
> 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 

Re: Terry: missing @data path-demangle setting

[Terry Brown]

On Thu, 1 Feb 2018 08:25:56 -0800 (PST)
"Edward K. Ream"  wrote:

> You mention this setting in this post 
> ,
> but I have never seen it in leoSettings.leo.  Could you add it?

:) I think that 2008 code was written for the Tk interface... so it
probably went away in the Qt interface.  I guess it could be
recreated.  Ideally it would be GUI independent, although not sure if
the LeoUI API supports menu item deletion / editing.  But the original
code mentions Tk.delete_range.

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: [QA]Advices for Leo documentation in Chinese translated version?

[Edward K. Ream]

On Thu, Feb 1, 2018 at 8:28 AM, OMlalala  wrote:

I want to make Chinese version Doc for spread the perfect Leo, any advice?
>
​
That's great news.  Please tell us when you have the docs ready.  I'll put
a link to them on Leo's home page.

Please feel free to ask any question you may have.  All of Leo's devs want
to help you in any way we can.

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Terry: missing @data path-demangle setting

[Edward K. Ream]

You mention this setting in this post 
, but 
I have never seen it in leoSettings.leo.  Could you add it?

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Please review leoToDo.txt

[Edward K. Ream]

I have spent several days revising @file ../doc/leoToDo.txt. You can find 
this node in LeoPyRef.leo, or your local leoPy.leo file.

leoToDo.txt now contains "Unlikely" and "Won't Do" nodes at the top level. 
Please review these two outlines if you don't see your favorite project on 
the list of Leo's 62 open enhancement items 
.
 
I am always happy to add more items.

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Reference for #667: unite Leo with wikis

[Edward K. Ream]

On Thursday, February 1, 2018 at 4:00:23 AM UTC-6, Edward K. Ream wrote:

The following consists of edited versions of old emails from Bernhard 
> Mulder, Miles Fidelman and HansBKK.  I am creating this post to offload 
> lengthy details from #668 
> .
>

And another idea... 

*Offray*

It would help to make Leo more visible in Wiki space could be if Leo can 
export/import to/from a Wiki. Perhaps like the @file or @url directives.

-- 
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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Reference for #667: unite Leo with wikis

[Edward K. Ream]

On Thursday, February 1, 2018 at 4:00:23 AM UTC-6, Edward K. Ream wrote:
>
> The following consists of edited versions of old emails from Bernhard 
> Mulder, Miles Fidelman and HansBKK.  I am creating this post to offload 
> lengthy details from #668 
> .
>
 

> These emails are quite old. Bernhard died about 10 years ago. The wiki 
> world has surely changed since then.  Updated comments would be 
> appreciated. Feel free to comment as you like, here, or in a separate 
> thread.
>
> *Bernhard Mulder*
>
> It ought to be possible to unite Leo with wiki features.
>
> tiddlywiki  provide formatting features 
> mentioned in [a dead SourceForge link].
>
> moinmoin  has started to use a graphical 
> interface for editing in the latest version.
>
> Maybe Leo can be split up into three components:
>
> 1. A storage component is responsible for storing nodes. Currently, this 
> is just memory, but databases like shelve, Zope or sqlite should also be 
> possible.
>
> 2. The control component is responsible for converting from the internal 
> format to external files which can be processed by existing compilers, 
> searching within a document, and the like.
>
> 3. A display component is responsible for interfacing with the user. If 
> can be [Qt], but it can also be something like the tiddlywiki interface, 
> which immediately shows the formatting applied to text.
>
> As an intermediate step, maybe we could allow mixing RST processing with 
> regular program text.  Leo would produce two documents out of a source 
> file: a version for the compiler in plain ascii, and an HTML file for 
> reading the source.
>
> *Miles Fidelman*
>
> Here are some details about my Smart Notebooks 
> 
>  
> project:
>
> The basic model is synchronized copies of documents, linked by an 
> asynchronous pub-sub channel. Think of a personal Wiki (like TiddlyWiki) 
> linked to copies of itself. Compose a document, email copies to 
> collaborators. Everyone saves a local copy, which link to each other via a 
> pub-sub protocol to distribute updates.  All in JavaScript, embedded in the 
> "smart documents" - nothing special to install.
>
> Andy Oram wrote a background piece 
> 
>  
> for O'Reilly Radar.
>
> *HansBKK*
>
> Leo could push Leo-derived content to DokuWiki 
>  as a platform for "wiki-publishing" 
> to enable collaborative/community editing of content.  See Leo 
> doc-generation and Wiki integration - GitIt and Pandoc. 
> 
>
> I've also talked about the markup syntax/doc generation tool Txt2tags 
> 
> .
>
> The Gitit wiki platform, like 
> DokuWiki, also uses plain-text files rather than a database back-end, and 
> integrates with git, mercurial, and darcs .
>
> Gitit also incorporates the Pandoc for its markup syntax, therefore 
> enabling not only markdown but rST as a master source input format, while 
> DokuWiki has its own, unique, markup syntax.
>
> I may be worthwhile to switch my "master source" content syntax from 
> Txt2tags to rST. The only downsides are that Gitit is a Haskell project 
> rather than Python, and one thing I like about Txt2tags is its support for 
> conversion to AsciiDoc, rather than Pandoc's direct output to full-blown 
> DocBook XML - but apparently even that's in the works in Pandoc's dev 
> version.
>
> 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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: Reference for #667: unite Leo with wikis

[Edward K. Ream]

On Thursday, February 1, 2018 at 4:00:23 AM UTC-6, Edward K. Ream wrote:

I am creating this post to offload lengthy details from #668 
> .
>

Oops.  The title of this thread should be "Reference for #668: unite Leo 
with wikis"

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Reference for #667: unite Leo with wikis

[Edward K. Ream]

The following consists of edited versions of old emails from Bernhard 
Mulder, Miles Fidelman and HansBKK.  I am creating this post to offload 
lengthy details from #668 
.  His ideas continue 
to be inspiring.

These emails are quite old. Bernhard died about 10 years ago. The wiki 
world has surely changed since then.  Updated comments would be 
appreciated. Feel free to comment as you like, here, or in a separate 
thread.

*Bernhard Mulder*

It ought to be possible to unite Leo with wiki features.

tiddlywiki  provide formatting features mentioned 
in [a dead SourceForge link].

moinmoin  has started to use a graphical 
interface for editing in the latest version.

Maybe Leo can be split up into three components:

1. A storage component is responsible for storing nodes. Currently, this is 
just memory, but databases like shelve, Zope or sqlite should also be 
possible.

2. The control component is responsible for converting from the internal 
format to external files which can be processed by existing compilers, 
searching within a document, and the like.

3. A display component is responsible for interfacing with the user. If can 
be [Qt], but it can also be something like the tiddlywiki interface, which 
immediately shows the formatting applied to text.

As an intermediate step, maybe we could allow mixing RST processing with 
regular program text.  Leo would produce two documents out of a source 
file: a version for the compiler in plain ascii, and an HTML file for 
reading the source.

*Miles Fidelman*

Here are some details about my Smart Notebooks 

 
project:

The basic model is synchronized copies of documents, linked by an 
asynchronous pub-sub channel. Think of a personal Wiki (like TiddlyWiki) 
linked to copies of itself. Compose a document, email copies to 
collaborators. Everyone saves a local copy, which link to each other via a 
pub-sub protocol to distribute updates.  All in JavaScript, embedded in the 
"smart documents" - nothing special to install.

Andy Oram wrote a background piece 

 
for O'Reilly Radar.

*HansBKK*

Leo could push Leo-derived content to DokuWiki 
 as a platform for "wiki-publishing" to 
enable collaborative/community editing of content.  See Leo doc-generation 
and Wiki integration - GitIt and Pandoc. 


I've also talked about the markup syntax/doc generation tool Txt2tags 

.

The Gitit wiki platform, like 
DokuWiki, also uses plain-text files rather than a database back-end, and 
integrates with git, mercurial, and darcs .

Gitit also incorporates the Pandoc for its markup syntax, therefore 
enabling not only markdown but rST as a master source input format, while 
DokuWiki has its own, unique, markup syntax.

I may be worthwhile to switch my "master source" content syntax from 
Txt2tags to rST. The only downsides are that Gitit is a Haskell project 
rather than Python, and one thing I like about Txt2tags is its support for 
conversion to AsciiDoc, rather than Pandoc's direct output to full-blown 
DocBook XML - but apparently even that's in the works in Pandoc's dev 
version.

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Reference for #667: node pipes

[Edward K. Ream]

The following contains back discussion of node pipes.  It consists of 
edited versions of old emails. I am creating this post to offload lengthy 
details from #667 .

I don't understand all the implications of this discussion. Feel free to 
comment as you like, here, or in a separate thread.

*Kent*

The editor envy resulting from the demo on Light Table 
 main page, has me revisiting a feature that's been 
percolating.

Sending output to the log pane is very useful, it's how Leo talks back.

Executing from the command line means one space for input and output.

Executing in a Leo node and writing to the log improves on this by 
providing different spaces for input and output.

Could Leo generalize this concept such that any node could be designated as 
a destination for output?

Given multiple visible nodes, akin to Terry's stickynotes, or Ville's 
recent grid suggestion [EKR: see the Won't Do section of 
leo/doc/leoToDo.txt] Leo could duplicate the power of simultaneous feedback 
shown by Light Table.

Reminds me of the power graph database folks talk about, where you can 
define nodes and edges to be whatever you want.

The nodes could be sources or sinks. Sources: code or commands ... Sinks: 
standard out, tail -f logfile, network traffic, introspection ...

The edges would define handlers for the content of the sources, format the 
results and send to the sinks.

So, as I write code in one node, I can see a node displaying stdout, 
another watching a log file, another showing docstrings, another showing 
test results ...

*Ville*

The 'ileo workbook' concept is relevant; it allowed you to easily reference 
other nodes in your scripts (wb.foo meant node with headline 'foo').

It's nice in theory, but the rigid UI model where we show only one node at 
a time made it hard to visualize. Tabula or grid would make it more 
concrete and intuitive - you could show input, output and the manipulator 
script at the same time. Or make small nodes with intermediate results etc.

How this would relate to 'pipeline'?  You would have explicit way to say 
what nodes are input, when nodes are output and what are the scripts that 
transform input to output. Editing inputs or scripts would ping you somehow 
that outputs are out of date, allowing you to easily press button to 
recalculate outputs.

-- 
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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Re: An avalanche of new thoughts

[Edward K. Ream]

On Wed, Jan 31, 2018 at 11:12 AM, Edward K. Ream 
wrote:

- *Sclerotic*: Leo's concrete gui code.
>
> Terry has made Leo's gui more flexible than it was, but Qt seems to be
> showing signs of age.
> ​[snip]​
>
>
> Leo could simulate the js DOM with a new Leonine API.  For example, it
> would be possible to simulate  getElementByName by searching through Leo's
> Qt widgets, using widget.parent(), widget.children() and widget.objectName()
>

​Terry's NestedSplitter class in ​leo/plugins/nested_splitter.py already
has similar code. ns.get_splitter_by_name, the local "hunter" function in
ns.add_adjacent, and ns.find_child all do a dynamic search.

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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.