Re: Icons with relative paths

[spike]

Since we need an argument to distinguish between document and theme
relative paths, I'm using the absence of that argument to set legacy
mode. For absolute paths it doesn't make any difference. I just need to
test for absolute or relative.

The devil is, of course, in the details. I keep overthinking things and
wandering off on tangents, or I think I'd be done already. It really
shouldn't be complicated.

On 2022-07-18 19:41, tbp1...@gmail.com wrote:
> You can add a new parameter to the method call, say use_legacy = True.  
> Then all existing code will work as always with the default value of 
> use_legacy.  You add a new code branch for when use_legacy is False so you 
> can get what you want in that case.  Tests for file existence will work 
> with relative paths or absolute paths, and you can easily determine which 
> you have.  I may be missing something (I often do), but it doesn't sound 
> very tricky.
> 
> On Monday, July 18, 2022 at 7:16:47 PM UTC-4 spike wrote:
> 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/5b1147a7-dae3-061d-f845-2fc756ee3e12%40runbox.com.

Re: Icons with relative paths

[tbp1...@gmail.com]

You can add a new parameter to the method call, say use_legacy = True.  
Then all existing code will work as always with the default value of 
use_legacy.  You add a new code branch for when use_legacy is False so you 
can get what you want in that case.  Tests for file existence will work 
with relative paths or absolute paths, and you can easily determine which 
you have.  I may be missing something (I often do), but it doesn't sound 
very tricky.

On Monday, July 18, 2022 at 7:16:47 PM UTC-4 spike wrote:

> I can kludge it, but it introduces some subtle but potentially nasty
> bugs. It really needs to be fixed properly in the next major update.
>
>
> I suppose adding a 'pathType' parameter to insertIconFromFile would 
> work. If the parameter is missing then it uses legacy mode and issues a 
> deprecation warning to the log.
>
> Splitting the "insert-icon" command and menu option isn't a problem
> since it isn't meant to be scripted.
>
>
> On the data side, a new attribute is needed for document relative paths,
> 'docRelPath', with absolute paths in the other two attributes to mimic
> the current behaviour when using legacy code.
>
> The problems with this are that the legacy paths are possibly invalid 
> and legacy code directly modifying icon data won't know to update the 
> new path, putting them out of sync. New code can't necessarily fix it 
> because the updated absolute paths may still be invalid. This is 
> especially troublesome when sharing outlines between users with 
> different Leo versions. On the other hand the 'relPath' attribute 
> suffers from the same problems.
>
>
> On 2022-07-18 14:36, tbp1...@gmail.com wrote:
> > I'm all in favor of improving features, but please find a way to make
> > them continue to work with existing code. It seems to me that the
> > easiest way to go about this would be to make the code fall back to a
> > document or outline-relative path if it can't find the icon files in
> > the other standard places it already looks for.
> > 
> > On Monday, July 18, 2022 at 4:23:06 PM UTC-4 spike wrote:
> > 
> >> g.os_path_exists works with relative paths but 
> >> c.editCommands.insertIconFromFile forces relative paths to be
> >> relative to the Leo theme directory. Document relative paths are
> >> rejected.
> >> 
> >> Running the following command from Leo's Python Console tab fails: 
> >> c.editCommands.insertIconFromFile('./icons/xfsm-lock.png', p=p)
> >> 
> >> This works, but only for theme icons: 
> >> c.editCommands.insertIconFromFile('light/checkbox_checked.svg',
> >> p=p)
> >> 
> >> This also works, but forces an absolute path: import os
> >> 
> >> 
> c.editCommands.insertIconFromFile(os.path.abspath('./icons/xfsm-lock.png'),
> >>
> >>
> >> 
> p=p)
> >> 
> >> c.editCommands.insertIconFromFile calls appendImageDictToList,
> >> which then calls g.app.gui.getTreeImage, which requires relative
> >> paths to be relative to the current Leo theme. Document-relative
> >> paths are rejected with an unhelpful "can not load image: None"
> >> message in the log.
> >> 
> >> There are three possible use cases for icons, but the current logic
> >> only supports two of them. 1) Theme relative path. This is used by
> >> the "to-do" plugin, which seems to be why the icon feature exists
> >> in the first place. 2) Document relative path. Useful but
> >> unsupported. 3) System relative path. Supported, limited use, but
> >> not portable.
> >> 
> >> 
> >> As it stands the current implementation is incomplete. If there are
> >> no objections I will work on a fix.
> >> 
> >> TO DO: * The 'relPath' attribute needs to be replaced by an
> >> 'isThemeIcon' flag. Old icon data needs to be automatically updated
> >> to the new format on file load. Theme paths should also respect the
> >> current theme.
> >> 
> >> * I'm debating adding an option to
> >> c.editCommands.insertIconFromFile or making a new
> >> insertThemeIconFromFile function for theme icons.
> >> 
> >> * The insert-icon command should get a companion insert-theme-icon 
> >> command so that the Open dialog starts in the right folder.
> >> 
> >> * The to-do plugin needs to be updated to the new API.
> >> 
> >> * There should also be a visible indicator when an icon file is
> >> missing or unreadable. I'm thinking a red 'x' in a white box, like
> >> web browsers do.
> >> 
> >> * Test cases need to be written.
> >> 
> >> * Then documentation.
> >> 
> >> 
> >> I'm still new to Leo coding, so I'll probably have questions.
> >> 
> >> Thank you for your patience.
> >> 
> >> 
> >> On 2022-07-18 08:04, tbp1...@gmail.com wrote:
> >>> Typically, either you write code and try different paths
> >>> depending on whether your file is in one place or another, or a
> >>> Leo method does the
> >> same
> >>> thing for you, in which case you need to know where Leo is going
> >>> to look. For example, in the part of the Cheatsheet you mention:
> >>> 
> >>> fn = g.os_path_finalize_join(g.app.loadDir, '..', 'Icons',
> >>> 'Tango', '16x16', 'status', 

Re: Icons with relative paths

[spike]

I can kludge it, but it introduces some subtle but potentially nasty
bugs. It really needs to be fixed properly in the next major update.


I suppose adding a 'pathType' parameter to insertIconFromFile would 
work. If the parameter is missing then it uses legacy mode and issues a 
deprecation warning to the log.


Splitting the "insert-icon" command and menu option isn't a problem
since it isn't meant to be scripted.


On the data side, a new attribute is needed for document relative paths,
'docRelPath', with absolute paths in the other two attributes to mimic
the current behaviour when using legacy code.

The problems with this are that the legacy paths are possibly invalid 
and legacy code directly modifying icon data won't know to update the 
new path, putting them out of sync. New code can't necessarily fix it 
because the updated absolute paths may still be invalid. This is 
especially troublesome when sharing outlines between users with 
different Leo versions. On the other hand the 'relPath' attribute 
suffers from the same problems.



On 2022-07-18 14:36, tbp1...@gmail.com wrote:

I'm all in favor of improving features, but please find a way to make
them continue to work with existing code.  It seems to me that the
easiest way to go about this would be to make the code fall back to a
document or outline-relative path if it can't find the icon files in
the other standard places it already looks for.

On Monday, July 18, 2022 at 4:23:06 PM UTC-4 spike wrote:

g.os_path_exists works with relative paths but 
c.editCommands.insertIconFromFile forces relative paths to be

relative to the Leo theme directory. Document relative paths are
rejected.

Running the following command from Leo's Python Console tab fails: 
c.editCommands.insertIconFromFile('./icons/xfsm-lock.png', p=p)


This works, but only for theme icons: 
c.editCommands.insertIconFromFile('light/checkbox_checked.svg',

p=p)

This also works, but forces an absolute path: import os

c.editCommands.insertIconFromFile(os.path.abspath('./icons/xfsm-lock.png'),




p=p)


c.editCommands.insertIconFromFile calls appendImageDictToList,
which then calls g.app.gui.getTreeImage, which requires relative
paths to be relative to the current Leo theme. Document-relative
paths are rejected with an unhelpful "can not load image: None"
message in the log.

There are three possible use cases for icons, but the current logic
only supports two of them. 1) Theme relative path. This is used by
the "to-do" plugin, which seems to be why the icon feature exists
in the first place. 2) Document relative path. Useful but
unsupported. 3) System relative path. Supported, limited use, but
not portable.


As it stands the current implementation is incomplete. If there are
no objections I will work on a fix.

TO DO: * The 'relPath' attribute needs to be replaced by an
'isThemeIcon' flag. Old icon data needs to be automatically updated
to the new format on file load. Theme paths should also respect the
current theme.

* I'm debating adding an option to
c.editCommands.insertIconFromFile or making a new
insertThemeIconFromFile function for theme icons.

* The insert-icon command should get a companion insert-theme-icon 
command so that the Open dialog starts in the right folder.


* The to-do plugin needs to be updated to the new API.

* There should also be a visible indicator when an icon file is
missing or unreadable. I'm thinking a red 'x' in a white box, like
web browsers do.

* Test cases need to be written.

* Then documentation.


I'm still new to Leo coding, so I'll probably have questions.

Thank you for your patience.


On 2022-07-18 08:04, tbp1...@gmail.com wrote:

Typically, either you write code and try different paths
depending on whether your file is in one place or another, or a
Leo method does the

same

thing for you, in which case you need to know where Leo is going
to look. For example, in the part of the Cheatsheet you mention:

fn = g.os_path_finalize_join(g.app.loadDir, '..', 'Icons',
'Tango', '16x16', 'status', icon) if g.os_path_exists(fn): 
c.editCommands.insertIconFromFile(path=fn)


g.os_path_exists() works with relative paths as wel as absolute
paths.

It would be helpful if you explain just how you are trying to use
these icons. If it is via a Leo setting, which settings? If via
code you have written, please show the code. On Monday, July 18,
2022 at 5:55:21 AM UTC-4 spike wrote:


On 2022-07-17 11:29, Félix wrote:

Thanks for the examples spike, but you replied to me only
instead of

reply

all, so your examples are not showing in the thread.

Here is the example spike provided: (see attachments)

On the other hand, i've looked at the 'unknownattributes' of
the nodes,

and

indeed the paths provided for the icons is not relative to
the Leo

file,

but are instead complete paths that will not work anywhere
else: such

as

*/home/keith/tmp/test/icons/blablabla.png*

instead of *icons/blablabla.png*

Lastly, i tried using / setting / finding out 

Re: Icons with relative paths

[tbp1...@gmail.com]

I'm all in favor of improving features, but please find a way to make them 
continue to work with existing code.  It seems to me that the easiest way 
to go about this would be to make the code fall back to a document or 
outline-relative path if it can't find the icon files in the other standard 
places it already looks for. 

On Monday, July 18, 2022 at 4:23:06 PM UTC-4 spike wrote:

> g.os_path_exists works with relative paths but 
> c.editCommands.insertIconFromFile forces relative paths to be relative 
> to the Leo theme directory. Document relative paths are rejected.
>
> Running the following command from Leo's Python Console tab fails:
> c.editCommands.insertIconFromFile('./icons/xfsm-lock.png', p=p)
>
> This works, but only for theme icons:
> c.editCommands.insertIconFromFile('light/checkbox_checked.svg', p=p)
>
> This also works, but forces an absolute path:
> import os
>
> c.editCommands.insertIconFromFile(os.path.abspath('./icons/xfsm-lock.png'), 
>
> p=p)
>
> c.editCommands.insertIconFromFile calls appendImageDictToList, which 
> then calls g.app.gui.getTreeImage, which requires relative paths to be 
> relative to the current Leo theme. Document-relative paths are rejected 
> with an unhelpful "can not load image: None" message in the log.
>
> There are three possible use cases for icons, but the current logic only 
> supports two of them.
> 1) Theme relative path. This is used by the "to-do" plugin, which seems 
> to be why the icon feature exists in the first place.
> 2) Document relative path. Useful but unsupported.
> 3) System relative path. Supported, limited use, but not portable.
>
>
> As it stands the current implementation is incomplete. If there are no 
> objections I will work on a fix.
>
> TO DO:
> * The 'relPath' attribute needs to be replaced by an 'isThemeIcon' flag. 
> Old icon data needs to be automatically updated to the new format on 
> file load. Theme paths should also respect the current theme.
>
> * I'm debating adding an option to c.editCommands.insertIconFromFile or 
> making a new insertThemeIconFromFile function for theme icons.
>
> * The insert-icon command should get a companion insert-theme-icon 
> command so that the Open dialog starts in the right folder.
>
> * The to-do plugin needs to be updated to the new API.
>
> * There should also be a visible indicator when an icon file is missing 
> or unreadable. I'm thinking a red 'x' in a white box, like web browsers do.
>
> * Test cases need to be written.
>
> * Then documentation.
>
>
> I'm still new to Leo coding, so I'll probably have questions.
>
> Thank you for your patience.
>
>
> On 2022-07-18 08:04, tbp1...@gmail.com wrote:
> > Typically, either you write code and try different paths depending on
> > whether your file is in one place or another, or a Leo method does the 
> same
> > thing for you, in which case you need to know where Leo is going to look.
> > For example, in the part of the Cheatsheet you mention:
> > 
> > fn = g.os_path_finalize_join(g.app.loadDir,
> > '..', 'Icons', 'Tango', '16x16', 'status', icon)
> > if g.os_path_exists(fn):
> > c.editCommands.insertIconFromFile(path=fn)
> > 
> > g.os_path_exists() works with relative paths as wel as absolute paths.
> > 
> > It would be helpful if you explain just how you are trying to use these
> > icons. If it is via a Leo setting, which settings? If via code you have
> > written, please show the code.
> > On Monday, July 18, 2022 at 5:55:21 AM UTC-4 spike wrote:
> > 
> >> On 2022-07-17 11:29, Félix wrote:
> >>> Thanks for the examples spike, but you replied to me only instead of
> >> reply
> >>> all, so your examples are not showing in the thread.
> >>>
> >>> Here is the example spike provided: (see attachments)
> >>>
> >>> On the other hand, i've looked at the 'unknownattributes' of the nodes,
> >> and
> >>> indeed the paths provided for the icons is not relative to the Leo 
> file,
> >>> but are instead complete paths that will not work anywhere else: such 
> as
> >>> */home/keith/tmp/test/icons/blablabla.png*
> >>>
> >>> instead of *icons/blablabla.png*
> >>>
> >>> Lastly, i tried using / setting / finding out about icons on nodes as I
> >>> was totally unaware that this was a thing... i could not find anything
> >> ...
> >>> Where / how did you get those icons and icon attributes? searching for
> >>> 'icons' in the documentation yields some other unrelated stuff... Like
> >> can
> >>> you take screenshots on how you set those?
> >>>
> >>> (sorry i'm totally ignorant about those 'node icons' that you speak of,
> >>> although i can see they exists in your screenshots and that the
> >> attributes
> >>> are there in the .leo file.)
> >>>
> >>> Félix
> >>>
> >>>
> >>>
> >>> On Sunday, July 17, 2022 at 7:46:03 AM UTC-4 Edward K. Ream wrote:
> >>>
>  On Sat, Jul 16, 2022 at 9:50 PM Robert-Felix 
> >> wrote:
> 
>  Leo uses relative paths for most stuff so moving the leo file and your
> > 'project' or 'resources' folder to accompany it 

Re: Icons with relative paths

[spike]

g.os_path_exists works with relative paths but 
c.editCommands.insertIconFromFile forces relative paths to be relative 
to the Leo theme directory. Document relative paths are rejected.


Running the following command from Leo's Python Console tab fails:
 c.editCommands.insertIconFromFile('./icons/xfsm-lock.png', p=p)

This works, but only for theme icons:
 c.editCommands.insertIconFromFile('light/checkbox_checked.svg', p=p)

This also works, but forces an absolute path:
 import os

c.editCommands.insertIconFromFile(os.path.abspath('./icons/xfsm-lock.png'), 
p=p)


c.editCommands.insertIconFromFile calls appendImageDictToList, which 
then calls g.app.gui.getTreeImage, which requires relative paths to be 
relative to the current Leo theme. Document-relative paths are rejected 
with an unhelpful "can not load image: None" message in the log.


There are three possible use cases for icons, but the current logic only 
supports two of them.
1) Theme relative path. This is used by the "to-do" plugin, which seems 
to be why the icon feature exists in the first place.

2) Document relative path. Useful but unsupported.
3) System relative path. Supported, limited use, but not portable.


As it stands the current implementation is incomplete. If there are no 
objections I will work on a fix.


TO DO:
* The 'relPath' attribute needs to be replaced by an 'isThemeIcon' flag. 
Old icon data needs to be automatically updated to the new format on 
file load. Theme paths should also respect the current theme.


* I'm debating adding an option to c.editCommands.insertIconFromFile or 
making a new insertThemeIconFromFile function for theme icons.


* The insert-icon command should get a companion insert-theme-icon 
command so that the Open dialog starts in the right folder.


* The to-do plugin needs to be updated to the new API.

* There should also be a visible indicator when an icon file is missing 
or unreadable. I'm thinking a red 'x' in a white box, like web browsers do.


* Test cases need to be written.

* Then documentation.


I'm still new to Leo coding, so I'll probably have questions.

Thank you for your patience.


On 2022-07-18 08:04, tbp1...@gmail.com wrote:

Typically, either you write code and try different paths depending on
whether your file is in one place or another, or a Leo method does the same
thing for you, in which case you need to know where Leo is going to look.
For example, in the part of the Cheatsheet you mention:

 fn = g.os_path_finalize_join(g.app.loadDir,
 '..', 'Icons', 'Tango', '16x16', 'status', icon)
 if g.os_path_exists(fn):
 c.editCommands.insertIconFromFile(path=fn)

g.os_path_exists() works with relative paths as wel as absolute paths.

It would be helpful if you explain just how you are trying to use these
icons.  If it is via a Leo setting, which settings?  If via code you have
written, please show the code.
On Monday, July 18, 2022 at 5:55:21 AM UTC-4 spike wrote:


On 2022-07-17 11:29, Félix wrote:

Thanks for the examples spike, but you replied to me only instead of

reply

all, so your examples are not showing in the thread.

Here is the example spike provided: (see attachments)

On the other hand, i've looked at the 'unknownattributes' of the nodes,

and

indeed the paths provided for the icons is not relative to the Leo file,
but are instead complete paths that will not work anywhere else: such as
*/home/keith/tmp/test/icons/blablabla.png*

instead of *icons/blablabla.png*

Lastly, i tried using / setting / finding out about icons on nodes as I
was totally unaware that this was a thing... i could not find anything

...

Where / how did you get those icons and icon attributes? searching for
'icons' in the documentation yields some other unrelated stuff... Like

can

you take screenshots on how you set those?

(sorry i'm totally ignorant about those 'node icons' that you speak of,
although i can see they exists in your screenshots and that the

attributes

are there in the .leo file.)

Félix



On Sunday, July 17, 2022 at 7:46:03 AM UTC-4 Edward K. Ream wrote:


On Sat, Jul 16, 2022 at 9:50 PM Robert-Felix 

wrote:


Leo uses relative paths for most stuff so moving the leo file and your

'project' or 'resources' folder to accompany it along should keep
everything working fine. whatever you had going on...



Leo's path expressions
 should suffice
for any conceivable purpose :-)

Edward




Sorry about the misdirected reply. I'll try to do better in future.

Thanks for reposting test file attachment. I'm posting a shot of the
menu option as well as the 'good.png' and 'bad.png' example screenshots.


The documentation is sparse and doesn't give much information. Most of
what I know about this feature comes from trial-and-error and looking at
Leo's source code. I'm still figuring things out.


https://leoeditor.com/commands.html#miscellaneous-commands lists four
minibuffer commands 

Re: "Chapters" Dropdown Can Now Be Placed At Left Of IconBar

[Edward K. Ream]

On Mon, Jul 18, 2022 at 11:09 AM tbp1...@gmail.com 
wrote:

> And the default was False anyway, but having it in leoSettings.leo at
> least means that someone might notice it there.
>

Yes.  All official settings should be documented in 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS3j3vJNyJYuLxGteufz%2BZ0Vq0%2BXzwEzvRiMNZzvr4Xc%3DQ%40mail.gmail.com.

Re: "Chapters" Dropdown Can Now Be Placed At Left Of IconBar

[tbp1...@gmail.com]

And the default was False anyway, but having it in leoSettings.leo at least 
means that someone might notice it there.

On Monday, July 18, 2022 at 12:03:06 PM UTC-4 Edward K. Ream wrote:

> To use the new feature, add a new node to the @settings tree in your 
>> myLeoSettings.leo outline with this text:
>>
>> @bool chapter-dropdown-left = True
>>
>
> Rev 2e1dbd9 adds `@bool chapter-dropdown-left = False` to leoSettings.leo, 
> retaining legacy operation by default.
>
> 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/6949fb04-00ce-4797-b898-9d2a203a3fafn%40googlegroups.com.

Developer's Notebook - Placing The "Chapters" Dropdown On The Left Of The Iconbar

[tbp1...@gmail.com]

In this Developer's Notebook, I want to share how I arrived at the new code 
to place the "Chapters" dropdown at the left of the Iconbar instead of the 
usual right.  Mainly there are a couple of tricks that I have found useful 
and would like to pass on to others who haven't come across them.

As background, a user had asked if this could be done.  I have written a 
few Leo plugins and a bit of infrastructure (e.g., the highlighting of the 
current line in the body), so I have some general knowledge about Leo.  But 
I don't know much about most of the details.  One helpful skills for a Leo 
developer is finding a good starting point.  All the Leo code can be found 
in the LeoPyRef outline.

@edward made a comment on the issue discussion page about the Iconbar being 
involved.  I figured that the Iconbar would be attached somehow to c.frame, 
and so I started searching.  I like to search using the Nav bar because it 
gives results that are easy to scan.  I searched for *frame.ic* and found 
this:

Official Ivars
c.frame.iconBar

Here was a starting point.  I explored it in my Workbook outline.  
Searching for *iconbar* I found *QtIconBarClass*, which seemed a likely 
find.

Next I looked for the most characteristic thing I could think of, which is 
the label *Chapters:* for the Chapters dropdown list.  I found this:

tt.createControl (defines class LeoQComboBox)
frame = QtWidgets.QLabel('Chapters: ')

A glance at the code shows that it is here that the label and dropdown are 
created and added to the Iconbar.  They are added with a Qt method: 
addWidget().  Presumably we would like to use something like 
insertWidget(position, 
widget) if there is such a method. So we need to find the Qt class involved 
so we can look up its methods.

In a node in the workbook, I got the class:

f = c.frame
icb = f.iconBar
g.es(type(icb))

Running this with CNTL-b gave as we had surmised earlier . 

This is a Leo class. Searching for its code, we find this in its 
constructor:

self.w = c.frame.top.iconBar  # A QToolBar

We also find a method addWidget(), which calls the same method on the 
*QToolBar.  
*So we look up *QToolbar* on the internet and look through its API page.  
But there is no method like *insertWidget()*. Here is a very useful trick 
for working with Qt classes - they have many more methods than are listed 
on the API page.  All widgets inherit the methods of the generic Qt Widget, 
and sometimes other specialized methods as well.  The page for the API of a 
widget usually has a link to their inherited methods.  It can be somewhat 
overwhelming because there are so many, but in the list we find 

QAction  *QToolBar::insertWidget(
QAction  **before*, QWidget 
 **widget*)

We can insert our widget before something that is a kind of *action*, but 
what is that and how do we find the right one?  It turns out that the 
QToolbar has a method actions().  Presumably the actions[0] item will be 
the left-most one on the IconBar, but it would be good to check.  We can 
get its type by modifying our test code like this:

f = c.frame
icb = f.iconBar
ibw = icb.w
actions = ibw.actions()
g.es(actions[0])

>From this we learn that our actions[0] item is of type *leoIconBarButton*. 
Searching for its constructor in LeoPyRef  discloses that it has a property 
*text*. By changing the *g.es()* line to 

g.es(actions[0].text)

we see that its label is *script-button*, so it is indeed the first item on 
the IconBar.  So we can change instances of addWidget(w) to 
insertWidget(actions[0], 
w).

This turned out to be the solution (with a little more checking and 
structuring).

I hope these notes will be helpful even if they were a little on  the long 
side.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/5dda940c-67a6-48a7-b8cf-836e58e13cf6n%40googlegroups.com.

Re: "Chapters" Dropdown Can Now Be Placed At Left Of IconBar

[Edward K. Ream]

> To use the new feature, add a new node to the @settings tree in your
> myLeoSettings.leo outline with this text:
>
> @bool chapter-dropdown-left = True
>

Rev 2e1dbd9 adds `@bool chapter-dropdown-left = False` to leoSettings.leo,
retaining legacy operation by default.

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS1gv4gjAuUKjQc2MhawB%2BJye8451Y-kyr7FvsWNeyLAmQ%40mail.gmail.com.

"Chapters" Dropdown Can Now Be Placed At Left Of IconBar

[tbp1...@gmail.com]

With the new merge of the devel branch, you can locate the "chapters" 
dropdown at the left of the Iconbar.  This is useful if you use chapters a 
lot, since it prevents the dropdown from being truncated off the end of the 
toolbar when there are many script buttons, or the Leo window is narrow.

To use the new feature, add a new node to the @settings tree in your 
myLeoSettings.leo outline with this text:

@bool chapter-dropdown-left = True

This feature was requested by @jbobian in issue 2722 
.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/0c6eab22-c427-4a67-981a-5c07db0e9219n%40googlegroups.com.

Re: Icons with relative paths

[tbp1...@gmail.com]

Typically, either you write code and try different paths depending on 
whether your file is in one place or another, or a Leo method does the same 
thing for you, in which case you need to know where Leo is going to look.  
For example, in the part of the Cheatsheet you mention:

fn = g.os_path_finalize_join(g.app.loadDir,
'..', 'Icons', 'Tango', '16x16', 'status', icon)
if g.os_path_exists(fn):
c.editCommands.insertIconFromFile(path=fn)

g.os_path_exists() works with relative paths as wel as absolute paths.  

It would be helpful if you explain just how you are trying to use these 
icons.  If it is via a Leo setting, which settings?  If via code you have 
written, please show the code.
On Monday, July 18, 2022 at 5:55:21 AM UTC-4 spike wrote:

> On 2022-07-17 11:29, Félix wrote:
> > Thanks for the examples spike, but you replied to me only instead of 
> reply
> > all, so your examples are not showing in the thread.
> > 
> > Here is the example spike provided: (see attachments)
> > 
> > On the other hand, i've looked at the 'unknownattributes' of the nodes, 
> and
> > indeed the paths provided for the icons is not relative to the Leo file,
> > but are instead complete paths that will not work anywhere else: such as
> > */home/keith/tmp/test/icons/blablabla.png*
> > 
> > instead of *icons/blablabla.png*
> > 
> > Lastly, i tried using / setting / finding out about icons on nodes as I
> > was totally unaware that this was a thing... i could not find anything 
> ...
> > Where / how did you get those icons and icon attributes? searching for
> > 'icons' in the documentation yields some other unrelated stuff... Like 
> can
> > you take screenshots on how you set those?
> > 
> > (sorry i'm totally ignorant about those 'node icons' that you speak of,
> > although i can see they exists in your screenshots and that the 
> attributes
> > are there in the .leo file.)
> > 
> > Félix
> > 
> > 
> > 
> > On Sunday, July 17, 2022 at 7:46:03 AM UTC-4 Edward K. Ream wrote:
> > 
> >> On Sat, Jul 16, 2022 at 9:50 PM Robert-Felix  
> wrote:
> >>
> >> Leo uses relative paths for most stuff so moving the leo file and your
> >>> 'project' or 'resources' folder to accompany it along should keep
> >>> everything working fine. whatever you had going on...
> >>>
> >>
> >> Leo's path expressions
> >>  should suffice
> >> for any conceivable purpose :-)
> >>
> >> Edward
> >>
> >
> Sorry about the misdirected reply. I'll try to do better in future.
>
> Thanks for reposting test file attachment. I'm posting a shot of the 
> menu option as well as the 'good.png' and 'bad.png' example screenshots.
>
>
> The documentation is sparse and doesn't give much information. Most of 
> what I know about this feature comes from trial-and-error and looking at 
> Leo's source code. I'm still figuring things out.
>
>
> https://leoeditor.com/commands.html#miscellaneous-commands lists four 
> minibuffer commands that do the same things as the menu options.
>
> CheatSheet.leo, available from the "Help" menu, has a short example 
> script under "Learning to be a leo Developer->Code academy->CA: icons"

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/efba739f-2ce9-419d-aa53-2bbd75b4524an%40googlegroups.com.