Re: Thought experiments

[lewis]

As I promised Terry, a re-post for clarity 

*Reason for suggesting 'LEO-mode'*

There have been numerous references to the Rendered Pane/s over the course 
of many recent discussions. A few examples:
- Integrated view
- EP
- viewrendered pane, VR
- Unified views

But to be honest they all feel a little clunky, especially at first use. 
Why? It may be that they are software type terms. *This is definitely not a 
criticism.* I'm suggesting the entry should be more polished than  
view-rendered or the proposed  vr-toggle-full-screen.
Almost seems like it's not appreciated how really good Viewrendered is, *as 
the approach is so low-key*.

Imagine a renamed VR. Let's call it 'LEO mode'
The entry into this window should be a pleasure for the user. Switching to 
'LEO mode' really can be fun, like a well wrapped gift.
Leo's UI is good and it's features are quite remarkable. Dream about how 
polished and beautiful Leo can become.

Again I see other advantages as

- It reinforces the Leo name
- it's a lead-in for Org mode users
- simple, easily explained term
- compact in commands/buttons

*Details*
Can the default switch to [Leo-mode] be a button, or menu entry, in the 
perfect position? :)  Or for power users, via the Contextmenu plugin, 
hovering over the node,
 Right-click [menu]>LEO-mode>Full screen
 >Floating
 >Option A

Once you are in LEO-mode, then you can tweak and modify as your code and 
writing preferences require. All to your heart's content.

*Summary*
The name and UI of the 'viewrendered pane' needs careful thought and design 
just as the complex machinery underneath does. I have made a case to 
promote a powerful set of Leo features.
Regardless of your thoughts I'm certain the rendering outcome will be a key 
feature for the next release.

Maybe I have posted this in the wrong topic but 'Thought experiment' seemed 
like a good place.

Regards
Lewis


On Saturday, March 25, 2017 at 3:56:58 PM UTC+11, lewis wrote:
>
> Terry Brown wrote:
>>
>>
>> *I'm not sure if I understood Lewis's post or not.  *
>>
>
> I didn't get my point across, I'll post again later.
>  
>

-- 
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: Thought experiments

[lewis]

Terry Brown wrote:
>
>
>
>
>
>
> *I'm not sure if I understood Lewis's post or not.  I wonder if it was a 
> humorous way of pointing out that Leo already has solutions to most of the 
> actual problems / workflows that these other tools address. Different 
> solutions, but no reason to think there's one best solution. [snip]*
>

I didn't get my point across, I'll post again later. Yes Leo already does 
have solutions to most of 
the actual problems / workflows that these other tools address.
 

>
>
>
>
> *But following in the vein of your comments and what I think Lewis was 
> saying, that's ok - Leo's current UI is good.  As a piece of software (the 
> hidden relationships, perhaps), I think Leo should be (is?) flexible enough 
> to support multiple editing components.*

*Cheers -Terry *
>

Yes, Leo's UI is good, and Leo's features are quite remarkable. However the 
UI can maybe improve in small ways.

I really liked the panel work 
 
you posted.

Regards
Lewis

 

-- 
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: Thought experiments

[xgid]

I really like the path this is taking: the most power is in the simplest 
way!

The only thing that does not fit in with my current view is this one:
​​
>
> 2. A new directive, say *@rendertree* would tell VR to render the node 
> and its subtree.  This makes visible and explicit what would otherwise be a 
> VR option.
>

As I see them, directives (@auto, @url, @language or whatever) are the way 
of giving Leo some meta-data about the (otherwise raw) contents of a node 
or group of nodes and/or the relations between them. In other words, I see 
them as a "typing system": an @url node is different kind of node than the 
rest, and so on. This is also valid for the @others directive, being this 
one a way of saying Leo that a sub-tree is to be treated as a whole and 
equivalent to its plain-text being placed where the @others is now.

In this sense, I don't fully see the point of the *@rendertree *directive, 
being this one only related with the rendering of nodes in the VR pane. It 
is not talking about properties of this nodes any more!
Wouldn't it be enought to have a different command, something like "
*vr-render-subtree*" or whatever?

I have many @auto for Markdown files where I would like to have the 
possibility of rendering just the body pane of the current node (as is now 
the VR pane) *or* *rendering a whole group of nodes *interchangeably, 
without having to insert @rendertree directives and move them up and down 
the tree to achieve this...

I would even understand if it was instead a "*vr-render-outline*" command 
which rendered always the *whole outline on the left* and having to use the 
hoist/dehoist commands if I want to see the rendering of only a part of the 
outline... but I don't understand the reasons for an *@rendertree *
directive.

What's the use case you have in mind?

-- 
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: Thought experiments

[Edward K. Ream]

On Friday, March 24, 2017 at 6:36:15 AM UTC-5, Edward K. Ream wrote:

Leo will soon have commands that make it easy to show/hide...everything 
> except the VR pane.
>

Only one new command is needed. See #446: add vr-toggle-full-screen 
. 

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: 63d3229: VR renders LaTex (python 2 only)

[Edward K. Ream]

On Friday, March 24, 2017 at 9:37:15 AM UTC-5, Edward K. Ream wrote:
>
> It renders LaTeX using mathjax 
> in a QtWebKitWidgets.QWebView. 
>
> This is *experimental code*, and *only works with Python 2*. On my 
> Windows 10 machine, it hangs when using Python 3. I have no idea why.
>
> Even on a fast machine, it takes several seconds to render Maxwell's 
> equations:
>

On Linux, rendering is *much *faster than on Windows and works for both 
Python 2 and 3.

Rev 20601c disables rendering only on Windows and only when using Python 3.

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: 63d3229: VR renders LaTex (python 2 only)

[Edward K. Ream]

On Friday, March 24, 2017 at 9:37:15 AM UTC-5, Edward K. Ream wrote:
>
> It renders LaTeX using mathjax 
> in a QtWebKitWidgets.QWebView. 
>
> This is *experimental code*, and *only works with Python 2*. On my 
> Windows 10 machine, it hangs when using Python 3. I have no idea why.
>

I should have added that VR plugin avoids the hang by not rendering when 
g.isPython3 is True. Not great, but better than hanging ;-)

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.

63d3229: VR renders LaTex (python 2 only)

[Edward K. Ream]

It renders LaTeX using mathjax 
in a QtWebKitWidgets.QWebView. 

This is *experimental code*, and *only works with Python 2*. On my Windows 
10 machine, it hangs when using Python 3. I have no idea why.

Even on a fast machine, it takes several seconds to render Maxwell's 
equations:

\begin{align}
  \nabla \times \vec{\mathbf{B}} -\, \frac1c\, 
\frac{\partial\vec{\mathbf{E}}}{\partial t} & = 
\frac{4\pi}{c}\vec{\mathbf{j}} \\
  \nabla \cdot \vec{\mathbf{E}} & = 4 \pi \rho \\
  \nabla \times \vec{\mathbf{E}}\, +\, \frac1c\, 
\frac{\partial\vec{\mathbf{B}}}{\partial t} & = \vec{\mathbf{0}} \\
  \nabla \cdot \vec{\mathbf{B}} & = 0
\end{align}
yielding the attached image. I'll be testing on Ubuntu next.
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: Thought experiments

[Edward K. Ream]

​​
On Fri, Mar 24, 2017 at 6:36 AM, Edward K. Ream  wrote:

> ​
​​
Leo will soon have commands that make it easy to show/hide the body pane or
everything except the VR pane.

​Consideration of hidden relationships continues to clarify matters.

In particular, the VR pane should be enhanced in several ways.  Some of
these ways the VR2 plugin already does:

1. At present, the VR pane renders an entire node the same way, namely as
indicated by the first @language directive.​
​ Instead, the VR plugin should be re-architected to that it composes its
results from multiple pieces (delimited by @language) in the same node. Not
a huge thing, but it makes the rendering compatible in spirit of (the
hidden relationships in) the body pane.


2. A new directive, say *@rendertree* would tell VR to render the node and
its subtree.  This makes visible and explicit what would otherwise be a VR
option.

3. Support for rendering @language latex.  I am about to up code to render
such nodes as plain text rather than the default.  Next, I'll add the
actual rendering.

​
​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: Thought experiments

[Edward K. Ream]

On Fri, Mar 24, 2017 at 8:10 AM, 'Terry Brown' via leo-editor <
leo-editor@googlegroups.com> wrote:


> I'm not sure if I understood Lewis's post or not.


​Neither do I.
​


> Different solutions, but no reason to think there's one best solution.
>

​The questions I am interested in.  First, what's best for Leo.  Second,
how best to connect, literally and figuratively, with other programs.
​


> > Leo will soon have commands that make it easy to show/hide the body
> > pane or everything except the VR pane.  These commands will give Leo
> > the essence of Quiver's Preview, Presentation and Full Screen modes.
> > Ditto for Jupyter notebook views.
>
> I have a problem with your use of the word "the" :-)


​Heh.
​


> I think Leo should be (is?)
> ​ ​
> flexible enough to support multiple editing components.


​Do what seems best to you.  That will work, providing we don't reimagine
what body panes, possibly plural, do.

The odd
> example using
> ​[pub/sub] without an instance points towards the possibility of
> storing listeners on `c`, in appropriate cases, without modifying other
> Leo code.  Or at least keeping the modifications more localized /
> possibly even in a plugin.
>

​There might be some g.app objects that might like to subscribe. Other than
that, keeping pub/sub data in the Commander or subcommander ​

​seems natural.

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: Thought experiments

['Terry Brown' via leo-editor]

On Fri, 24 Mar 2017 06:36:13 -0500
"Edward K. Ream"  wrote:

I'm not sure if I understood Lewis's post or not.  I wonder if it was a
humorous way of pointing out that Leo already has solutions to most of
the actual problems / workflows that these other tools address.
Different solutions, but no reason to think there's one best solution.

> Leo will soon have commands that make it easy to show/hide the body
> pane or everything except the VR pane.  These commands will give Leo
> the essence of Quiver's Preview, Presentation and Full Screen modes.
> Ditto for Jupyter notebook views.

I have a problem with your use of the word "the" :-)  I'd like support
for multiple edit and render panes.

But following in the vein of your comments and what I think Lewis was
saying, that's ok - Leo's current UI is good.  As a piece of software
(the hidden relationships, perhaps), I think Leo should be (is?)
flexible enough to support multiple editing components.  I think more
use of a publish / subscribe approach might be key to that - for new
components moving forward, no need to refactor the existing tree / body.

I wrote this stupidly simple class for publish / subscribe last night:
https://gist.github.com/tbnorth/602ccb3bfa5b0f4c4527ea64c28b7dd3
it may be insufficient, but it will do as a starting point.  The odd
example using it without an instance points towards the possibility of
storing listeners on `c`, in appropriate cases, without modifying other
Leo code.  Or at least keeping the modifications more localized /
possibly even in a plugin.

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: Thought experiments

[Edward K. Ream]

​​
​​
On Thu, Mar 23, 2017 at 5:53 AM, Edward K. Ream  wrote:

The recent discussions about UI issues should focus on what we want, not
> how that will happen.
>
> You might think that a piece of paper is our most important design tool
> when thinking about UI's.  But the *layout* of frames and widgets isn't
> so important.  Instead, it is the *hidden* relationships that matter.
>

​The last paragraph is a major Aha.

The UI can express (or obscure) those hidden relationships, but that's
*secondary.* The UI will "emerge" only when the hidden relationships are
fully understood.

*tl;dr:* *Leo's present UI is good enough!* It needs only *tiny* tweaks!

I thought about hidden relationships all day yesterday. At first I was
confused the relationship between rendering, syntax coloring and images.
Now I see:

- @language directives already replace the kind of drop-down menus used in
Jupyter and Quiver.
- Syntax coloring has nothing to do with images and/or math symbols.

In the first draft of this post I said this:

- The presence of the VR pane *itself* is a useful hidden relationship. If
the VR pane exists, Leo should show the body pane as "raw" text. Otherwise,
Leo should render @language latex sections *in the body pane*.
- Leo should render @language latex sections in the body pane if the VR
pane does not exist.

But no, that's making things *way *too difficult. We don't want to
complicate the body pane! The simplest thing that could possibly work is
this:

1. The body pane always shows *raw* (unrendered) text, just as at present.
2. The VR pane is where all rendering happens, just as at present.
3. Leo should have commands that show/hide the body pane and/or everything
except the VR pane.

Point 3 instantly gives us Quiver's Preview, Presentation and Full Screen
modes. The VR2 plugin gives the ability to render multiple nodes (a node
and its subtree). The VR plugin should do likewise.

My high school math teacher, Dr. Moore (yes, she had a PhD in mathematics),
talked about having "our head save our heals" :-)  Keeping Leo's present UI
(including Terry's excellent EP work) will save weeks or months of tricky
(and useless!) work:

A. No need to insert pictures/symbols in body text. More importantly, no
need to *remember* pictures/symbols when saving/loading files, and no need
to *keep track* of pictures/symbols when rearranging text.  This is a big
win all by itself.

B. No need to (somehow!) figure out how to render/syntax color sections (in
the same node) delimited by different @language directives. No need to
complicate the syntax colorer. Leo will syntax color @language latex in the
body pane as always.

C. No need for hacks telling whether body text should be rendered or not.

*​Summary*

​Terry has said previously that we don't need to render text in the body
pane. Now I understand why, in detail.

Leo will soon have commands that make it easy to show/hide the body pane or
everything except the VR pane.  These commands will give Leo the essence of
Quiver's Preview, Presentation and Full Screen modes. Ditto for Jupyter
notebook views.

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

Re: Thought experiments

[Edward K. Ream]

On Thu, Mar 23, 2017 at 5:13 PM, lewis  wrote:

> Has there been any thoughts given to promoting Leo's great new feature?
> May I suggest a simple menu/button/toggle called `'*LEO mode*'`  and use
> it for switching into what were being referred to as LEP's but now EP's
>

​Let's promote it after we know what it is ;-)  Terry's work is a good
start. There are other considerations which I'll be writing about later
today.

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: Unified views? Unify the outline and body panes?

[Edward K. Ream]

On Thu, Mar 23, 2017 at 11:07 AM, Edward K. Ream 
wrote:

>
> On Thu, Mar 23, 2017 at 10:49 AM, Edward K. Ream 
> wrote:
>
>> On Thu, Mar 23, 2017 at 10:30 AM, 'Terry Brown' via leo-editor <
>> leo-editor@googlegroups.com> wrote:
>>
>>>
>>> The code is in the branch
>>> https://github.com/tbnorth/leo-dev-tbnorth/tree/leo_edit_pane
>>
>>
>> ​Thanks.  I'll make no changes.
>>
>
> ​I don't see the leo/core/editPane directory when I do a git clone.
>

​Mystery solved.  The url above is for the entire leo-dev-tbnorth repo.
After cloning the repo, I had to do a git checkout leo_edit_pane.

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.