Reducing visual clutter in Tree

[john lunzer]

Directives in node headers cause a great deal of visual clutter, making it more difficult to navigate expansive trees filled primarily with @clean/@file/@edit nodes.

I suggest creating aliases for the directives @clean/@file/@edit which would obviously be @c/@f/@e .

I think you can tell just by comparing the two on one line just how much single letter aliases cuts down on visual clutter.

I know @c is in use already but as per the documentation that usage is for body only and this would be for headline only.

Please let me know what you think of this proposal. I think this enhancement would truly change the ease by which directive heavy trees, making Leo much more visually appealing.

[Terry Brown]

On Thu, 6 Aug 2015 12:25:40 -0700 (PDT)
john lunzer <lun...@gmail.com> wrote:

> Directives in node headers cause a great deal of visual clutter,
> making it more difficult to navigate expansive trees filled primarily
> with @clean/@file/@edit nodes.

I agree completely, rather than seeing:

@clean /home/tbrown/projects/pyth|
@edit /home/tbrown/misc/maps_and_|
@nosent /home/tbrown/projects/rec|

I'd like to see

𝓒 …/somecode.py
𝓔 …/file.js
𝓝 …/someelse.txt

i.e. icons for the directive and path hiding / compression.
Maybe even the …/ is too much :-)

I think this can be done without changing Leo internals or adding
aliases like @c for @clean etc. Basically you'd see the regular text
when you edit a node headline, and the succinct version otherwise.

In the past I've said I'm tired of hearing myself say I'll try things
like this and then not getting to them... I think now I'm getting to
the point of saying I'm tired of hearing myself say I'm tired of
hearing myself say... :-)

But I think if this can be done it has to be by just changing the
appearance of the nodes when they're not being edited, and having the
user edit the whole regular `@clean /home/tbrown/projects/...` text.
Otherwise the changes to Leo internals would be a huge task.

So, I'll try and have a quick hack along those lines.

Cheers -Terry

[Kent Tenney]

How about URI syntax:
auto:///home/me/file.txt
clean:///home/you/file.txt
...

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

[john lunzer]

This would be glorious. I also thought there might be a relatively simple way of simply changing the appearance and I also thought that using icons might be part of the answer! I'm super interested to see what you come up with!

[Edward K. Ream]

On Thu, Aug 6, 2015 at 3:04 PM, 'Terry Brown' via leo-editor <leo-e...@googlegroups.com> wrote:

On Thu, 6 Aug 2015 12:25:40 -0700 (PDT)
john lunzer <lun...@gmail.com> wrote:

> Directives in node headers cause a great deal of visual clutter,
> making it more difficult to navigate expansive trees filled primarily
> with @clean/@file/@edit nodes.

I agree completely, rather than seeing:

@clean /home/tbrown/projects/pyth|
@edit /home/tbrown/misc/maps_and_|
@nosent /home/tbrown/projects/rec|

I'd like to see

𝓒 …/somecode.py
𝓔 …/file.js
𝓝 …/someelse.txt

i.e. icons for the directive and path hiding / compression.
Maybe even the …/ is too much :-)

​I think this is a minor issue.

If you do it, make sure that p.isAnyAtFileNode and related methods continue to work.  In fact, altering these methods probably is the only way to retain compatibility with existing code.

Be sure to run all unit tests if you change any of these methods.  There are non-trivial implications.

EKR

[john lunzer]

I don't think it is safe to label this as minor. The way a person processes on screen text can vary greatly. There are legitimate accessibility implications for those with vision disability (tunnel vision, dyslexia). Then there are people like myself without a disability that simply struggle with "busyness" and overcrowded text. 

To help users organize and focus on relevant information, with or without disability, it is important to minimize visual redundancy. What would on the surface appear to be a "minor" issue has a gargantuan accumulative impact due to frequency of use of headline directives. If a headline directive can be represented as an icon without affecting Leo's core (minimizing the amount of work required to implement the change) then the entire Leo community stands to benefit greatly and the value of the change would be well worth the effort. 

[Terry Brown]

On Thu, 6 Aug 2015 17:28:13 -0700 (PDT)
john lunzer <lun...@gmail.com> wrote:

> This would be glorious. I also thought there might be a relatively
> simple way of simply changing the appearance and I also thought that
> using icons might be part of the answer! I'm super interested to see
> what you come up with!

Ok, funny, I have proof of concept in my working version of Leo, so
trying to do some other work my tree looks like the attached, the "12 "
is just an illusion, it's not there when you edit the headlines. It
was simpler to add than to remove text for editing.

Cheers -Terry

[Terry Brown]

On Fri, 7 Aug 2015 08:38:37 -0500

"'Terry Brown' via leo-editor" <leo-e...@googlegroups.com> wrote:

> Ok, funny, I have proof of concept in my working version of Leo, so
> trying to do some other work my tree looks like the attached, the "12
> " is just an illusion, it's not there when you edit the headlines. It
> was simpler to add than to remove text for editing.

* for testing, not editing, I meant.

> Cheers -Terry

[john lunzer]

Great work, exciting to see a proof of concept working already!

[Terry Brown]

On Thu, 6 Aug 2015 12:25:40 -0700 (PDT)

john lunzer <lun...@gmail.com> wrote:

> Directives in node headers cause a great deal of visual clutter,
> making it more difficult to navigate expansive trees filled primarily
> with @clean/@file/@edit nodes.

Ok, I've pushed what I've got. I checked the unit tests and they
seemed unchanged. It seems to work in py3 as well as py2.

Edward, I made two commits, you can see the combined changes here:
https://github.com/leo-editor/leo-editor/compare/00cdd48...8808ae3
the changes are confined to qt_tree.py (and leoSettings.leo) and aside
from the new code itself, are very clearly walled off from default
behavior by
self.use_declutter = c.config.getBool('tree-declutter', default=False)

To make it work, copy @data tree-declutter-patterns and
@bool tree-declutter = False from leoSettings.leo to your personal
settings and change False to True. Examples below, docs. in the
@data tree-declutter-patterns node.

I did find that there are two distinct pathways in the code for editing
a node headline. Double-click, and with
@bool single_click_auto_edits_headline = True, single-click on a
selected node do one thing, and `edit-headline` does another - i.e.
they seem to use different code to construct headline editing widgets,
it would be good at some time to unify them. Because my hooks were so
small, I just applied them to both pathways.

So now we just need 16x16 pixel icons which clearly communicate the
difference between @edit, @auto, @clean, @file, and and @nosent :-)
The example code just replaces @clean with an icon.

# if the node name starts with 'peacock node DEMO', make a mess of it
RULE ^(peacock node DEMO)
REPLACE LOOK: \1
ICON Tango/16x16/emotes/face-grin.png
ICON Tango/16x16/emotes/face-wink.png
FG @solarized-magenta
BG white
FONT Times
PX 40
ITALIC 1
WEIGHT Bold

# remove @clean and use an icon
RULE ^@clean (.*)
REPLACE \1
ICON Tango/16x16/mimetypes/ascii.png

# show the last part of long filenames
RULE ^.{1,1000}/(.{20})
REPLACE …/\1

Cheers -Terry

[Edward K. Ream]

On Fri, Aug 7, 2015 at 2:18 PM, 'Terry Brown' via leo-editor <leo-e...@googlegroups.com> wrote:

Ok, I've pushed what I've got.  I checked the unit tests and they
seemed unchanged.  It seems to work in py3 as well as py2.

​Thanks for this.  When I ran the unit tests I got the following (unrelated) complaint about the recently-changed valuespace plugin:

----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\leo.repo\leo-editor\leo\core\leoTest.py", line 344, in runTest
    exec(compile(script, scriptFile, 'exec'), d)
  File "C:\leo.repo\leo-editor\leo\test\scriptFile.py", line 20, in <module>
    assert arg0 in expected or arg1 in expected,message
AssertionError:
no event arg for command vs-eval, func: vs_eval
args: ArgSpec(args=['kwargs'], varargs=None, keywords=None, defaults=None)

So the complaint is that vs-eval (and several other commands) have a "kwargs" argument instead of an "event" arg.

EKR

[Terry Brown]

p.s. here's a real life example of with and without the change
(attached images).

So in this case it's the "show end of path" part that's contributing
more than the "make @clean into an icon" part, although in an
active_path directory tree where you only have directory names and file
names and not long paths, the latter would be a big improvement, IMO,

Cheers -Terry

[Terry Brown]

On Fri, 7 Aug 2015 14:43:52 -0500
"Edward K. Ream" <edre...@gmail.com> wrote:

> ​Thanks for this.  When I ran the unit tests I got the following
> (unrelated) complaint about the recently-changed valuespace plugin:

Thanks for the reminder, fixed and pushed.

Cheers -Terry

[john lunzer]

Your implementation of this feature is also far more powerful than I could have ever imagined. The coloring/italic/bold/size options are equally as remarkable in their ability create instant differentiation between nodes. See attached image for a simple example. I've already tested it on some of my exceptionally larger .leo files and the removal of @clean plus the highlighting of "class" nodes is simply amazing. I am grateful for your work Terry. 

I'm having a few issues. One is that the conversions do not seem to take place until a certain action occurs in the tree. I can always get the conversions to happen from expanding a node (but not contracting a node). It also seems like sometimes the tree scrolls to a center a specific node after some conversions. 

Additionally and this is purely a curiosity, if this feature remained the way it is I'd be perfectly happy, would it be possible (and straightforward) to implement selected node foreground and background colors, it's slightly disorienting to lose the foreground color when the node is highlighted. 

I had some crashing as well but I can't reproduce it now. I'll wait until it happens again before I post my stack trace unless you're really curious. Bravo again!

[Terry Brown]

On Fri, 7 Aug 2015 14:15:01 -0700 (PDT)
john lunzer <lun...@gmail.com> wrote:

> between nodes. See attached image for a simple example. I've already
> tested it on some of my exceptionally larger .leo files and the
> removal of @clean plus the highlighting of "class" nodes is simply
> amazing. I am grateful for your work Terry.

Neat, I hadn't thought of highlighting that sort of thing.

> I'm having a few issues. One is that the conversions do not seem to
> take place until a certain action occurs in the tree. I can always
> get the conversions to happen from expanding a node (but not
> contracting a node). It also seems like sometimes the tree scrolls to
> a center a specific node after some conversions.

Not sure about the scrolling, but yep, there's no forced update, and I
haven't played with it long enough to decide if that's annoying. When
you've just edited "@clean /some/path/here/then/foo.txt" do you want it
to immediately become "✎ …/foo.txt"? OTOH I haven't seen any issues
with speed yet, so probably no big deal to force an update.

> Additionally and this is purely a curiosity, if this feature remained
> the way it is I'd be perfectly happy, would it be possible (and
> straightforward) to implement selected node foreground and background
> colors, it's slightly disorienting to lose the foreground color when
> the node is highlighted.

This is where it gets tricky. I wasn't going to do the FG/BG/FONT
stuff originally, I was going to let you set a "style_class" attribute
on the widget so that:

QTreeWidget[style_class~='clean_node'] {
background-color: @solarized-red;
}

would let you do any kind of styling you wanted. But QTreeWidgetItem
is part of a generic model view controller such that it's the "same"
QTreeWidgetItem used for all nodes, it's only the data that changes.
It seems there must be an underlying real per-node widget that you
could style, but I'm not seeing how you get at it.

So I think the answer is there isn't a specific QTreeWidgetItem for
which to set the :selected style. But I'm not 100% sure on this.

> I had some crashing as well but I can't reproduce it now. I'll wait
> until it happens again before I post my stack trace unless you're
> really curious. Bravo again!

For sure send any reproducible stack traces.

I'm glad you prodded me into finally trying this, the idea's come up
more than once over several years.

Cheers -Terry

[Terry Brown]

On Fri, 7 Aug 2015 21:10:31 -0500

"'Terry Brown' via leo-editor" <leo-e...@googlegroups.com> wrote:

> > It also seems like sometimes the tree scrolls to
> > a center a specific node after some conversions.
>
> Not sure about the scrolling,

I think I see that, but I don't this it needs a declutter matching
node. With A with child B expanded at 1/4 down tree, edit B, then move
left to contract A, then move right again to expand A re-revealing B -
tree scrolls to center on B. So I don't think that's new, if that's
what you were referring to.

Cheers -Terry

[Terry Brown]

On Fri, 7 Aug 2015 14:15:01 -0700 (PDT)
john lunzer <lun...@gmail.com> wrote:

> One is that the conversions do not seem to take place until a certain
> action occurs in the tree. I can always get the conversions to happen
> from expanding a node (but not contracting a node). It also seems
> like sometimes the tree scrolls to a center a specific node after
> some conversions.

I think these issues are fixed in the latest push. It was tricky to
get the update to work, it's done on idle so you're outside any redraw
loop.

Cheers -Terry

[Terry Brown]

Also just pushed some icons for different @<file> types, with support
for the leo_dark_0 theme. See updated rules in
leo/config/leoSettings.leo#@settings-->Tree operation-->@data tree-declutter-patterns

Cheers -Terry

On Sat, 8 Aug 2015 08:59:35 -0500

"'Terry Brown' via leo-editor" <leo-e...@googlegroups.com> wrote:

[john lunzer]

Awesome, thanks for the quick updates, I'll check them out soon (at the latest on Monday).

[john lunzer]

Just pulled the most recent changes. Auto-update works great and the new icons look good. I'll be certain to let you know if I come across any issues.

[john lunzer]

Not sure if you had come across this but different rules can co-exist. For example along with all the @file type directives I have .py files specifically bolded and both the rule for adding the icon and the rule for bolding co-exist without issue. This just keeps getting better! I assume there could be some issues if the rules affected the same style aspects.

[Terry Brown]

On Sat, 8 Aug 2015 10:45:37 -0700 (PDT)
john lunzer <lun...@gmail.com> wrote:

> Not sure if you had come across this but different rules can
> co-exist. For example along with all the @file type directives I
> have .py files specifically bolded and both the rule for adding the
> icon and the rule for bolding co-exist without issue. This just keeps
> getting better! I assume there could be some issues if the rules
> affected the same style aspects.

The rules are just applied in sequence. Only gotcha is that if the
first rule replaces `@clean ` with something else, subsequent rules
that match `@clean ` won't fire - but I can't see when that would be a
problem, and you can control the order.

Cheers -Terry

[john lunzer]

I've actually been thinking about this for a long time, but I've wanted to implement parts of the to-do plugin on purely text based input.

So a task that wasn't done would start with [ ]

A task that was finished would be [*]

and a task that was cancelled would be [x]

Can I access the task icons in the same way that you're access the icons currently with declutter?

[Terry Brown]

On Sat, 8 Aug 2015 17:09:56 -0700 (PDT)
john lunzer <lun...@gmail.com> wrote:

> I've actually been thinking about this for a long time, but I've
> wanted to implement parts of the to-do plugin on purely text based
> input.
>
> So a task that wasn't done would start with [ ]
> A task that was finished would be [*]
> and a task that was cancelled would be [x]
>
> Can I access the task icons in the same way that you're access the
> icons currently with declutter?

Sure, so the rules would be:

RULE ^\[ ] (.*)
REPLACE \1
ICON cleo/chkboxblk.png
RULE ^\[\*] (.*)
REPLACE \1
ICON cleo/chkblk.png
RULE ^\[[xX]] (.*)
REPLACE \1
ICON cleo/xblk.png

`cleo` was the name of the plugin that preceeded `todo`, if you didn't
know.

Also I just updated the rules in leoSettings.py, they do the same
thing, I just eliminated an editing artifact. They were like

RULE ^@(clean) (.*)
REPLACE \2

and are now like

RULE ^@clean (.*)
REPLACE \1

Cheers -Terry

[john lunzer]

Just delightful. Leo feels immensely more personalized and dynamic with the declutter feature (as if it already didn't feel that way). Let's not forget to get this into the documentation eventually.

[john lunzer]

Been playing around and I got some new examples. I have rules for the @path plugin:

# Add Icon to folders, remove forward slashes

RULE ^/(.*)/$

REPLACE \1

ICON Tango/16x16/places/folder_inv.png

# Add icon to path folders / remove @path

RULE ^@path (.*)

REPLACE \1

ICON Tango/16x16/places/folder_path_inv.png

I think I till don't have write access to Leo's repository so I can't upload the path icon and inverted icons. Maybe I should request write access though, as I do plan within the next month to release a new plugin that I'd like to push to the repository.

Terry, I've noticed that the Icons butt right up against the status boxes. Is there any way to add a pixel or two (whichever looks best) of buffer between them?

[Andrea Nuvola]

Hi,

just posting some "declutting" icons I've made in case they might be useful to others. I personally find it easier to distinguish small icons based on color rather than shape. The color palette used is Solarized. The icons are in six different styles/sizes (see attached example pic).

Cheers,

Andrea

On Friday, August 7, 2015 at 4:25:40 AM UTC+9, john lunzer wrote:

Directives in node headers cause a great deal of visual clutter, making it more difficult to navigate expansive trees filled primarily with @clean/@file/@edit nodes.

[john lunzer]

Super cool. I dig these. I also dig your styles for your script buttons and expand/collapse icons? How did you accomplish that coolness?

[Terry Brown]

On Mon, 10 Aug 2015 04:43:50 -0700 (PDT)
john lunzer <lun...@gmail.com> wrote:

> Terry, I've noticed that the Icons butt right up against the status
> boxes. Is there any way to add a pixel or two (whichever looks best)
> of buffer between them?

I've just pushed the addition of a setting
@int tree-icon-separation = 1
which controls icon separation in pixels.

I also just pushed a fix to a hard crash of Leo when declutter is
active and you find two successive search hits in headlines, I think
what was happening was (quoting commit):

When search results are found in headlines headkey2 fires
(on the second search hit in a headline), and full_redraw()
for declutter takes the headline out of edit mode, and Leo crashes,
probably because the find code didn't expect to leave edit
mode. So don't update when a QLineEdit has focus

I guess I'm not sure if it's the find code or just the editing code in
general, the fix should handle all cases.

Cheers -Terry

[Andrea Nuvola]

Hi John,

I use my own icons for the expanded/collapsed nodes. I attach them here, in case you want to use them.

The color are from the Solarized palette (I am a Solarized fan!).

In order to set the collapsed/expanded node icons, you can add the following sections

to a theme settings tree or directly in the node @data qt-gui-plugin-style-sheet in your personal settings.

Just set the icon paths according to your preferences.

//----------

QTreeView::branch:closed:has-children{

   image: url("C:/Users/C/.leo/icons/nodes/closed.png");

}

QTreeView::branch:open:has-children{

   image: url("C:/Users/C/.leo/icons/nodes/open.png");

}

//----------

Or, in Linux,

//----------

QTreeView::branch:closed:has-children{

   image: url("/home/c/.leo/icons/nodes/closed.png");

}

QTreeView::branch:open:has-children{

   image: url("/home/c/.leo/icons/nodes/open.png");

}

//----------

Similarly, I use the following settings for the buttons (assuming the Solarized colors are defined in your settings).

//----------

QPushButton {

padding: 5px;

color: @solarized-cyan; 

background: @solarized-base03;

border: 1px solid @solarized-cyan;

border-top-color: @solarized-cyan;

border-bottom-color: @solarized-cyan;

}

QPushButton:hover {

padding: 5px;

color: @solarized-orange; 

background: @solarized-base03;

border: 1px solid @solarized-orange;

border-top-color: @solarized-orange;

border-bottom-color: @solarized-orange;

}

//----------

Cheers,

Andrea

[john lunzer]

Thank you for that! Very nice.

[john lunzer]

Thanks for the pixel buffer! I've found a pixel buffer of 7 to be good. 

Anyway I found an instance in which the headline/icons won't update. On the use of edit-headline-long. If you press cancel nothing will happen, but if you hit enter then the headline will go back to normal and never update until the next update event (doesn't need to be the same headline).

[john lunzer]

Terry, the rule for showing the last part of filenames can be improved to better support windows users:

# show the last part of long filenames

RULE ^.{1,1000}([/\\])(.{30})

REPLACE …\1\2

The first capture group with faithfully respect the use of backslashes in windows paths. (I like 30 instead of 20, no need to change that though) 

[john lunzer]

Just pushed @path/active-path icons in the latest commit. Check the updated tree-declutter-patterns in leoSettings.leo for the accompanying rules. No need to use them of course but I think they make a big difference when using active-path.

[Terry Brown]

On Wed, 12 Aug 2015 04:57:16 -0700 (PDT)
john lunzer <lun...@gmail.com> wrote:

> Just pushed @path/active-path icons in the latest commit. Check the
> updated tree-declutter-patterns in leoSettings.leo for the
> accompanying rules. No need to use them of course but I think they
> make a big difference when using active-path.

Like the way you handle removed files.

Also, kudos for collapsing leoSettings.leo again before pushing, so
that it looks right when opened.

Cheers -Terry

[john lunzer]

Also, kudos for collapsing leoSettings.leo again before pushing, so that it looks right when opened. 

If that happened it was purely by accident :) Though I will certainly remember to do so in the future.

[john lunzer]

I've discovered a visual glitch when using the rules for the task icons. After the icon has been added by the declutter feature if I then attempt to edit the headline again by making it shorter (backspace or delete) the original headline seems to get "burned in" behind the editable headline box so that the end of the original headline still shows. Interestingly if I make a change and then press Ctrl + z (undo) then everything seems fine and the original headline is no longer "burned in" in the background.

[Terry Brown]

On Mon, 17 Aug 2015 05:09:55 -0700 (PDT)
john lunzer <lun...@gmail.com> wrote:

> I've discovered a visual glitch when using the rules for the task
> icons. After the icon has been added by the declutter feature if I
> then attempt to edit the headline again by making it shorter
> (backspace or delete) the original headline seems to get "burned in"

Thought that was going to be a tough one but seemed simple after all,
very lightly tested but seems to be fixed (and pushed).

Cheers -Terry

[john lunzer]

When I save a Leo outline all of my icons disappear? The next headline update will restore them. Anyone seeing similar behavior?

[Terry Brown]

On Mon, 31 Aug 2015 08:37:25 -0700 (PDT)
john lunzer <lun...@gmail.com> wrote:

> When I save a Leo outline all of my icons disappear? The next
> headline update will restore them. Anyone seeing similar behavior?

No, although I can see how that could happen. The visual-declutter
code clears all the icons it inserted based on rules before the save,
so that you're not left with a file riddled with "virtual" icons mixed
with icons you may have added manually yourself and want to keep. I.e.
if you disable the declutter code, all it's icons should disappear. You
would think it would need to put them back after the save, but I'm not
seeing them disappear.

Hmm, so based on the code I would expect the problem you report,
because of
leo-editor/leo/core/LeoPy.leo#Code-->Qt gui-->@file ../plugins/qt_tree.py-->qtree.Drawing-->qtree.full_redraw & helpers-->qtree.clear_visual_icons

But I don't see the problem. The solution would be to add
self.declutter_update = True
to the above clear_visual_icons() - can you try that and see if the
problem goes away?

Cheers -Terry

[john lunzer]

This does fix the problem and does not appear to break anything else. The behavior is that for a brief moment during the save the icons disappear but then come right back.

[john lunzer]

Sorry to dredge up an old topic, Terry is there any reason this change can't be folded into the code base? I continue changing it every time I update Leo.

[Terry Brown]

On Tue, 2 Feb 2016 05:11:36 -0800 (PST)
john lunzer <lun...@gmail.com> wrote:

> Sorry to dredge up an old topic, Terry is there any reason this
> change can't be folded into the code base? I continue changing it
> every time I update Leo.

Sure - I still haven't seen it, so my guess is that I have a plugin
installed that's triggering the update by triggering a node selection
event, or something like that, but the code shouldn't be relying on
that. So yes, fold it in.

Cheers -Terry
terry_...@yahoo.com

> > > > > >> > >>> > >> > that yu're access the icons currently with