Re: Reloading visual settings
On Wed, 17 Sep 2014 14:10:41 -0500 "Edward K. Ream" wrote: > > In myLeoSettings.leo, somewhere under @settings, showing only > > organizer nodes for the @values nodes, not the @value nodes > > themselves: > > > > @theme default > > @bool theme_is_dark = False > > theme settings [snip] > This seems like a natural organization. > > However, many settings are duplicated. At present, Leo can't honor > such duplicate settings. I'll talk about possible solutions below. I'm not sure how much the problem needs solving. Having later in document order override themes earlier in document order seems ok to me, as long as it's clear what's happening. So for example the Reload Styles command could narrate something like this in the log window: Loading settings for "default" theme. Applying changes from "big fonts" theme. Applying changes from "dark 0" theme. Note: effects from earlier themes may be overridden by later themes. The hierarchical menu to present the user with the right tree piece to edit for "colors" or "fonts" could be similarly chatty, and would need to be somewhat clever, it's narration might look something like: Looking for color settings. Color settings found in theme "default". Found theme "big fonts", which does not include color settings. Found theme "dark 0", which overrides color settings from theme "default". Editing color settings in theme "dark 0". Does the .config() machinery allow you to work out where each value was defined? I seem to remember that it does. Hmm, I hadn't thought of concatenating all stylesheets, other than the user stylesheet. It might be a problem if theme A and B stylesheets are conctenated in that order, but B assumes it's modifying Qt's default behavior, not Qt's default behavior + the effects of A. I suspect it might be useful to see how they work in the wild before we try anything too clever. Cheers -Terry > > So the user has the default theme installed, with modifications from > > the "greens" color modifying theme, and then they've installed a > > dark theme which is probably overriding most of the other two. I > > don't see any problem with this arrangement, apart from keeping the > > user aware of what's going on, an perhaps suggesting they move the > > first two out of @settings for simplicity. > > How about a "global" setting that would specify which theme/themes, if > any, to use. Something like @data themes, where the body lists the > themes in which their stylesheets are concatenated. This instantly > will provide safety and flexibility. > > There are at least two solutions to the problem of duplicate settings > in different @theme trees: > > 1. Namespaces for settings. This would be neat, but it seems like an > heroic solution. It would not be easy to do, imo. > > 2. Scripts (config methods), much like the script in the 'stylesheet & > source' node. Here is my present thinking. > > Suppose, first of all, that Leo's config code initially ignores @theme > (singular) trees. This does away with duplicates. Heh, heh. > > Next, when the configuration code finds the (presumably unique) > @themes (plural) node, a new config method, say config.create_theme, > would do the following: > > 1. Find all the @theme trees mentioned in the the body of the @themes > node. > > I see no particular reason to require that all @theme trees be > children of the @themes node, though that wouldn't be an odious > requirement... > > 2. For each @theme tree, config.create_theme would a) parse all the > "inner" settings in the @theme tree and b) create an **internal theme > stylesheet** > > 3. Create the final themes stylesheet by concatenating all internal > theme stylesheets. > > To summarize, @theme nodes present special challenges because Leo > lacks settings namespaces. As a workaround, Leo's config code could > ignore @theme trees, while a new create_theme method would compose a > theme stylesheet by processing all the nodes mentioned in the body of > an @themes node. > > These are just first thoughts, but they show the problem is tractable, > following the ideas behind your theme-creating script. > > Your comments? > > Edward > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Leo stylesheets now predefine all colors defined in leoColors.py, and more...
On Thursday, September 18, 2014 1:29:43 PM UTC-5, Edward K. Ream wrote: > Leo style sheets now support all colors names in Leo's color_db, defined in leoColor.py. leoSettings.leo now has a flashy new color chooser. Clicking the pick-color-name button puts a combo box into the icon area that lists all the names in Leo's color db. Selecting any name puts that color in the background of the combo box. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Leo stylesheets now predefine all colors defined in leoColors.py, and more...
On Thu, Sep 18, 2014 at 3:25 PM, Jacob M. Peck wrote: > Here's a semi-interactive Leo colormap: > http://leo-editor.github.io/snippets/colormap.html > > Hover over a color to get Leo's internal name for it. :) Thanks. I'll add this link to the discussion of colors 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 post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Leo stylesheets now predefine all colors defined in leoColors.py, and more...
Nice work! These colors are (mostly) the same as: http://www.yourhtmlsource.com/stylesheets/namedcolours.html Here's a semi-interactive Leo colormap: http://leo-editor.github.io/snippets/colormap.html Hover over a color to get Leo's internal name for it. :) -->Jake -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Leo stylesheets now predefine all colors defined in leoColors.py, and more...
Leo style sheets now support all colors names in Leo's color_db, defined in
leoColor.py.
For example, the following setting works without any explicit definition of
mistyrose2.
@color head-bg = @mistyrose2
These colors are (mostly) the same as:
http://www.yourhtmlsource.com/stylesheets/namedcolours.html
I think this is an important addition to stylesheets. I don't expect any
problems because it was so easy to do. But one never knows...
The new print-style-sheet command prints the top-level stylesheet to the
console.
One nice feature of using the color_db is that the substitution code puts
the color name in comments in the style sheet. For example::
QPushButton[button_kind="at-button"] {
/* Buttons created by @button nodes. */
background-color: #CAE1FF /* lightsteelblue1 */;
}
Note that the "Color Definitions" node in LeoSettings.leo now defines just
two colors: LeoGreen and LeoYellow.
Edward
P.S. Terry, following your comments, ssm.expand_css_constants no longer
calls ssm.find_constants_defined. The old code could be turned back on
quickly if you like.
EKR
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
Re: Incorrect text highlighted using Find commands
On Thu, Sep 18, 2014 at 10:04 AM, Edward K. Ream > On Thu, Sep 18, 2014 at 4:16 AM, lewis wrote: >> it logs a message: backwardsHelper bad index: i = 0, j = 8762 Fixed at rev 9a42be0, Leo build: 20140918102605 Keep those reports coming ;-) This is the time to fix as many problems as 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 http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
The --trace-plugins command-line arg and related leoBridge setting
The new --trace-plugins command-line argument makes a lot easier for people trying to understand why a particular plugin didn't load. It eliminates the need to set tracing variables in Leo's core--an important advantage. As a happy side effect, this setting simplifies the corresponding tracing conditions in the affected core code. Furthermore, the tracePlugins keyword argument has now been added in various places to the leoBridge module. Suppose example, suppose leo_bridge_test.py contains:: '''A minimal Leo bridge application''' # This can not be run locally! import leo.core.leoBridge as leoBridge b = leoBridge.controller( gui='nullGui',loadPlugins=True, silent=False,tracePlugins=True,verbose=False) g = b.globals() path = g.os_path_finalize_join(g.app.loadDir,'..','doc','LeoDocs.leo') assert g.os_path_exists(path) c = b.openLeoFile(path) assert c assert c.rootPosition() The following script will run this file:: g.cls() import sys import subprocess path = r'c:\Users\edreamleo\test\leo_bridge_test.py' assert g.os_path_exists(path) proc = subprocess.Popen([sys.executable,path]) proc.communicate() And the output will be:: ** isPython3: False Leo 4.11 final, build 20140918100332, Thu Sep 18 10:03:32 CDT 2014 Git repo info: branch = master, commit = cc2a8585870e Python 2.7.2, LeoGui: dummy version Windows 7 AMD64 (build 6.1.7601) SP1 reading settings in C:\leo.repo\leo-editor\leo\config\leoSettings.leo reading settings in c:\Users\edreamleo\.leo\myLeoSettings.leo loadOnePlugin: failed to load module leo.plugins.plugins_menu Plugin leo.plugins.bookmarks does not support nullGui gui Plugin leo.plugins.contextmenu does not support nullGui gui Plugin leo.plugins.nav_qt does not support nullGui gui Plugin leo.plugins.quicksearch does not support nullGui gui loadOnePlugin: failed to load module leo.plugins.richtext reading settings in C:\leo.repo\leo-editor\leo\doc\LeoDocs.leo loadOnePlugin: failed to load module leo.plugins.plugins_menu loadOnePlugin: plugin leo.plugins.mod_scripting already loaded Plugin leo.plugins.bookmarks does not support nullGui gui Plugin leo.plugins.contextmenu does not support nullGui gui Plugin leo.plugins.nav_qt does not support nullGui gui Plugin leo.plugins.quicksearch does not support nullGui gui loadOnePlugin: failed to load module leo.plugins.richtext Finally, recent code changes have eliminated duplicate console messages when using the nullGui, as is typical when using the Leo bridge. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Incorrect text highlighted using Find commands
On Thu, Sep 18, 2014 at 4:16 AM, lewis wrote: > OK search now correctly highlights the correct text in the @edit > html\conf.py node. Thanks for this confirmation. > I went F3 all the way to the end and then F2 back up the tree. When it > reaches the node Web pages-->TOC-->@edit html\leo_toc.html.txt > line 4: .. sphinx-quickstart on Mon Mar 30 16:39:02 2009. > it logs a message: backwardsHelper bad index: i = 0, j = 965 > and the node Web pages-->@edit html\conf.py > line 137: # The name for this set of Sphinx documents. If None, it > defaults to > it logs a message: backwardsHelper bad index: i = 0, j = 8762 I'll look at this today. > Yes I am running windows Ok. I'll make the previous hack a windows-only affair. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Caution: mass updates to plugins
Several recent revs today have updated about 20 plugins. All tests pass and indeed most changes actually involve comments. Nevertheless, these changes may have broken one or more plugins in some way. I apologize for this, but imo the changes were overdue. Clearly, they should be done before the a1 release. Please report any new problems with plugins immediately. I plan no further mass changes to plugins. Here is a summary of the changes: 1. Changed the style guide for plugins in the node leoPlugins.leo#Plugins--> Templates. 2. Many plugins have been brought up to the revised "style code": - Smallish << docstring >> sections have been moved to the top-level node, where they are more visible. - Smallish << imports >> sections have been moved to the top-level node, where they are more visible. - Unused/underused << version history >> sections have been eliminated, moving author attributions to the top-level node. I have retained longer << version history >> sections, but you could say that such sections have been deprecated. - Leo directives now appear at the end of the top-level node (and hence the end of the external file.) - All top-level init methods now have a proper docstring. 3. The bookmarks.py plugin (and maybe others) now calls g.assertUi to ensure it fails gracefully when using a null gui. This is a real bug fix. 4. All changed plugins now pass pylint. Most changes were minor: unused imports and the like. To repeat, these changes were necessary, imo, but they carry a risk. Please report any problems immediately. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Delayed loading of large nodes
On Wed, Sep 17, 2014 at 3:03 PM, Fidel N wrote:
> it works great here, thanks for this Edward
Thanks for the report. Maybe the code is beta quality now ;-)
> With the update, also noticed the big blue square surrounding the selected
> widget, its also great. Those things improve usability big time IMO :D
I assume you mean the selected tree node. It's a new setting::
@color tree-item-selected-bg = @LightSteelBlue1
You can change the color by changing this setting in myLeoSettings.leo.
About colors: LightSteelBlue1 is defined in leoSettings.leo. As
mentioned in leoSettings.leo, you can see the list of available Qt
colors (case ignored by Qt) by running this script:
from leo.core.leoQt import QtGui
aList = sorted([g.u(z) for z in QtGui.QColor().colorNames()])
print('\n'.join(aList))
I'm not sure whether these colors depend on platform. It would be
good if Leo color settings automatically knew about the colors in
Leo's color database in leoColor.py, but at present they do not. Not
sure when that will happen...
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
Re: launchLeo failed
On Wed, Sep 17, 2014 at 9:01 PM, F.S. wrote: > Well this is the first time I am running the files from git repo. In the > past this was never a problem. But now I got the following message from the > github downloaded version: [snip] > File "c:\Users\h\proj\pkgs\leo-editor\leo\core\leoApp.py", line 1912, in > readGlobalSettingsFiles > g.app.forgetOpenFile(c.fileName()) > AttributeError: 'NoneType' object has no attribute 'fileName' Thanks for this report. The is a recent blunder, arising only when leoSettings.leo or myLeoSettings.leo does not exist. It should be fixed at rev f59edcd, Leo build: 20140918062023 Please report any further problems. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
Re: Incorrect text highlighted using Find commands
OK search now correctly highlights the correct text in the @edit html\conf.py node. I went F3 all the way to the end and then F2 back up the tree. When it reaches the node *Web pages-->TOC-->@edit html\leo_toc.html.txt* line 4:* .. sphinx-quickstart on Mon Mar 30 16:39:02 2009.* it logs a message: backwardsHelper bad index: i = 0, j = 965 and the node Web pages-->@edit html\conf.py line 137: *# The name for this set of Sphinx documents. If None, it defaults to* it logs a message: backwardsHelper bad index: i = 0, j = 8762 Yes I am running windows *Leo Log WindowLeo 4.11 final, build 20140917180028, Wed Sep 17 18:00:28 CDT 2014Git repo info: branch = master, commit = f541849d6c09Python 3.4.1, PyQt version 4.8.6Windows 7 AMD64 (build 6.1.7601) SP1* Regards Lewis On Thursday, September 18, 2014 9:08:25 AM UTC+10, Edward K. Ream wrote: > > > Are you running on Windows? Stripping '\r' worries me greatly on the Mac. > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
