Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#59 Patch: context-menu CSS choice and 'View HTML Source', and possible fix for the temp file workaround for QWebView

retext-next
open
nobody
None
2014-02-18
2012-11-03
sdaau
No

Hello!

I just got retext from git today, and I produced a patch which can be downloaded from here:

(that is the "clean" patch; a previous version with more comments, but not complete is here: retext-contextmenucss-comments.diff)

I think it partially addresses tickets/38: CSS For Preview, Export. The changes are, first, that there is now an addition to the right-click (context) menus of both previewers - both the QTextEdit and the QWebView:

Left side of that image shows context menu and styling of QTextEdit; right side context menu and styling of QWebView. Basically,

  • At start, window.py iterates and collects all .css files it can find in the retext-git/templates directory (which already has three such files)
  • These files are added as entries of a new context submenu, "Set CSS" - along with a menu entry "Default" - for both context menus
  • A new array exists that holds the choices of CSS style of each tab
  • If the choice is 0 (Default), then the tab is styled as usual:
    ** This includes the 'same-name-css-as-html-file-in-same-folder' approach already coded - however, some path problems were fixed so it works in this context too
  • otherwise, the chosen style from the context menu is applied to the active tab

Note there is no indication anywhere, which says which choice has been made for a given tab - the "Set CSS" context menu can be used only for setting. That is why - even if an "Edit"/"View HTML code" already exists; a new "view HTML Source" was coded, which is raised through the context menu of the previewer(s). As it can be seen from the image, it shows a more verbose HTML - which also shows the differences between the QTextEdit and QWebView more drastically than "Edit"/"View HTML code": in particular, for QTextEdit, the "View HTML code" shows the .css URL, but "view HTML Source" doesn't - while it's the opposite case for QWebView.

 

In doing this, I experimented with QWebView a bit - and I think that the problem with it, is that it requires absolute paths, with a file:// prefix, to be encoded in the HTML for the link to CSS files; then again, it also requires absolute paths for loading any local HTML file, but without the file:// prefix! Some of that can be seen in this post: python - QWebView not loading external CSS - Stack Overflow

Furthermore, on my system, the temporary files from the workaround didn't get saved in /tmp (as expected); they got saved in the current working directory. However, it turns out, that as long as the CSS link is absolute and encoded with file:// prefix - then even setHTML works for the QWebView (with styling) - so the temporary files workaround should not be necessary (it is commented in the patch itself).

Anyways - the patch seems to allow individual styling of tabs, regardless if it is "New Document" in memory - or files saved on disk:

... and also, if the WebKit renderer is used, then the chosen style will also be exported to the PDF (saw a blue background in that case - but didn't see it if saving PDF with QTextEdit backend; although maybe some of the style propagates there too? Didn't check that too closely...)

 

Not sure how well this may work on other platforms (I'm on Ubuntu 11.04), or on Python 3 (I had ran retext on Python 2.7) - but I hope the patch (or some of its functionality) will make it into retext proper,

Cheers!

Discussion

  • Thanks for your work here!

    The built-in CSS themes (style_*.css) were intended to be just examples of what can be done with WpGen. Even more, those themes don't play well with ReText (as you can see from your dark-gray-text-on-dark-gray-background screenshot).

    For those needing custom CSS to be applied to preview & export we have two ways — a "local" one (filename.css) and a "global" one (styleSheet config option). I'm not sure if it's worth adding a third one. What I can do is:

    • searching for style.css in the working directory;
    • adding a GUI for selecting a global stylesheet.

    Does one of that suit you?

    In doing this, I experimented with QWebView a bit - and I think that the problem with it, is that it requires absolute paths, with a file:// prefix, to be encoded in the HTML for the link to CSS files; then again, it also requires absolute paths for loading any local HTML file, but without the file:// prefix!

    Thanks a lot, adding absolute path allowed me to (partially) drop the workaround.

     
  • sdaau
    sdaau
    2012-11-08

    Hi Dmitry,

    Thanks for the feedback!

    The built-in CSS themes (style_*.css) were intended to be just examples of what can be done with WpGen.

    Ahaa - wasn't aware of that, good to know!

    It seems I was so excited to write about the patch, I forgot to clarify some of my choices :) For one, the only reason I used those .css files, was because I could find them in the application folder (which spared me the trouble of thinking about how to allow the user the choice GUI-wise - that is also why templates/ was chosen as the directory to iterate through)

     

    For those needing custom CSS to be applied to preview & export we have two ways — a "local" one (filename.css) and a "global" one (styleSheet config option). I'm not sure if it's worth adding a third one.

    I see your point - and I cannot really defend adding a third option for a concrete usability reason, just for personal preference - but I'll try to explain why I like it:

    A "global" stylesheet makes sense to me, when I have multiple documents that I'd organise together in, say, a "site". Often, however, I write one-off documents which I'd want to have a specific style (btw, I did a small survey of free .css, rendered in ReText, which can be seen here)

    Now, the "local" option does allow for setting of individual style, and I find it perfect, for when I want to "fix" a particular style to a particular textfile. However, one small issue with it is clutter: if I have 15 .md textfiles, which I want to style with 3 .css files, I still have to have 15 individually saved .css files (on Linux, it's not much of a problem with symlinks - but on Windows, I guess you'd have to actually copy files, which makes it easier to forget which .css file of the 3 is used on which .md textfile).

    Then again, clutter is not the real issue for me - what I'd like to do is to be able to change and preview styles quickly**; meaning I want to easily change some widget in ReText, change a .css style, and be able to see the new style effected in ReText instantly. Basically, often when I need to write such one-off documents, the first thing I end up doing is basically writing a paragraph, and then start nitpicking about which style suits my mood :) As I often forget the procedure about setting .css in ReText, then I look it up - and once I see that, essentially, I'd have to symlink and restart ReText, I start thinking "well, I might as well do it in a browser" - and end up coding .css for hours (not even touching ReText here - or writing, as I originally set out to do) :)

    (**) I should note here that while the patch does allow for changing between different .css files quickly - it turns out, once a .css file is read, it is cached by QWebView (at least) - so if I change a .css file, and reload it again, no changes will be seen - until ReText is restarted. It may be possible to solve this with <meta http-equiv="expires" content="0" /> in <head> (not sure if headers like Expires:, Cache-Control: or Pragma: no-cache can be sent to QWebView)

    Thus, having a widget to change from several styles quickly - and instantly see their effect applied in Preview - is likely to get me through the "design mood" quickly, and into the actual writing.

    Since we don't specify .css files in Markdown, this implies that :

    1. the application should "know" about which .css files to apply - so maybe easiest to read them from a predefined directory (doesn't have to be templates).
    2. Any such change from within the GUI would be temporary, and would thus have to be handled on per-file basis (for permanent style choices, the filename.css local way should be used).

    Additionally, the GUI widget doesn't have to be a right-click action (that is just the first thing I thought of, which was specifically related to the Preview) - it could just as well be a drop-down menu (like "Tags" or "Symbols").

     

    What I can do is:

    searching for style.css in the working directory;
    adding a GUI for selecting a global stylesheet.

    Does one of that suit you?

    Not really - the method for specifying stylesheet files in ReText is good as it is; what I want is a quick choice and preview from several css files...

    Maybe something like this is acceptable? :

     * Have a new config option, styleSheetDir
     * If styleSheetDir doesn't exist/is empty at startup, ReText behaves as it does now, no changes
     * If styleSheetDir is set to a valid path, the application iterates in that path, and enumerates all .css files
     * The enumerated .css files are then shown in a drop-down right next to "Symbols" - "Default" is still the first option (to allow for deferring to default behavior via global style file/local "filename.css" on per-tab basis)
     * When any of several tabs (opened files) is focused, it also updates the drop-down with its current stylesheet setting (if a right-click menu is used instead of a dropdown, a checkmark next to the menu entry could indicate the current setting)
     * Once ReText is closed, any information about per-tab styling is lost - unless the users themselves made sure to create a local "filename.css"

    adding absolute path allowed me to (partially) drop the workaround.

    Glad to hear that,

    Cheers!

    PS: SourceForge just lost this reply first time I posted it; luckily I had most of it pasted in ReText :) So, trying again now...

     


Anonymous


Cancel   Add attachments