On Monday, September 15, 2014 8:22:46 PM UTC-5, Terry wrote: > > On Mon, 15 Sep 2014 16:47:32 -0500 > "Edward K. Ream" <[email protected]> wrote: > > > On Mon, Sep 15, 2014 at 9:30 AM, 'Terry Brown' via leo-editor > > <[email protected]> wrote: > [snip] > > I don't see the font-resizing code. Is it in the repo anywhere? > > Nav panel search LeoPyRef.py for `deltas` >
Ok. All the matches are in ssm.expand_css_constants, which looks like it is working perfectly. To continue the status report, I have successfully transitioned to the new, fully parameterized style sheet. However, I dare not push it just yet. Considerable cleanup, and resulting debugging, is still to come. Some notes: 1. The first several pushes of leoSettings.leo will retain the original @data qt-gui-plugin-style-sheet node (disabled) and any settings that have just become no-longer used. Yes, it will be an inconvenience for existing users to have to use different settings names, but imo there was no real choice: it is essential that a single, uniform, consistent set of names be used. Changing settings names will not be all *that* odious because... 2. The new settings scheme will moot the need for leo10pt.leo, leo12pt.leo and all the rest. Instead, all font sizes are now defined in terms of three intermediate settings: @string font-size, @string medium-font-size and @string small-font-size. Changing just these three settings will suffice to change *all* the font sizes used in Leo. 3. Syntax errors. Most users, and certainly all newbies, will never have to touch, or even look at, @data qt-gui-plugin-style-sheet. This is a really good thing, because the slightest syntax error silently messes up everything that follows. It took *hours* for me to find a colon that should have been a semicolon. Being able to switch component node in and out of the @data qt-gui-plugin-style-sheet helped isolate the problems without having to do divide and conquer using text cut/paste. But still, no Leo user should be subjected to this kind of torture. This morning I thought to google *validate* qt style sheets rather than *check* qt style sheets. I found this: http://qt-project.org/doc/qt-5/stylesheet-designer.html However, the assertion that Qt Designer actually helps validate style sheets is, ahem, suspect. The only errors it detects are mismatched curly braces. Sheesh. Imagine how productive we would be if Python didn't tell us where the syntax errors were! 4. Other kinds of debugging. When things don't look right, I execute this script:: c.styleSheetManager.print_style_sheet() This prints the complete stylesheet to the console. What I mainly look for are lines like:: background-color: @some-setting An @value as the value of a setting indicates that no substitution took place, that is, that there is no node:: @string some-setting = aValue Any user that wants to roll their own @data node will want to be aware of this technique. 5. Overriding setting using @data qt-gui-**user**-style-sheet. Using this additional style sheet probably should be deprecated. Indeed, @data qt-gui-**plugin**-style-sheet now takes care to define almost everything that any user would want to define. That being so, myLeoSettings.leo should contain overrides of only the @color and @string nodes in leoSettings.leo. There should be no need to use @data qt-gui-**user**-style-sheet unless one wants to do something very unusual. Indeed, an interesting stylesheet question arises. Suppose, as is the case, that in effect @data qt-gui-**user**-style-sheet is appended after @data qt-gui-**plugin**-style-sheet. The question is, what happens?? Does each selector in the user style sheet *completely* replace the corresponding selector of the plugin style sheet, or do only the individual fields of each selector in the user style sheet replace the corresponding field of the selector in the plugin style sheet. The answer to this arcane question makes a big difference. If selectors are completely replaced, then each selector in @data qt-gui-**user**-style-sheet must contain *all* the corresponding information in @data qt-gui-**plugin**-style-sheet. This obscures what is being overridden. I haven't managed to answer this question yet, because there are so many other confounding factors. Maybe later today, when things settle down a bit. In short, I expect to work a few more hours before pushing the new version of leoSettings.leo. The new version will retain disabled versions of the old @data node, so in an emergency Leo's existing users will be able to revert to the old way. Edward P.S. Debugging this beast is really tricky. I suspect that the reason that @color nodes did not appear to work for you (Terry) was that there was some kind of confounding error in effect. This happened to me for a time, but now @color nodes work again and I'll be converting from @string back to @color where possible. Followed by more debugging & testing, of course... All this difficulties show just how vital this project is for newbies. It's important, Terry, for you and I to invest as much effort as needed to this... 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
