[ANN] New plugin - printing.py

[Jacob Peck]

Hello all,

I've added a new plugin to Leo, that adds printing support when using
the Qt GUI. Available from rev 5779.

Here's the docscring:

'''Supports printing from the Qt GUI.

Jacob M. Peck, 2013

Commands
========

This plugin supports the following twelve commands:

print-selected-node
-------------------

Opens up the print dialog to print the selected headline and node.

print-preview-selected-node
---------------------------

Opens up the print preview dialog to preview the selected headline
and node.

print-selected-node-body
------------------------

Opens up the print dialog to print the selected node body.

print-preview-selected-node-body
--------------------------------

Opens up the print preview dialog to preview the selected node body.

print-expanded-node
-------------------

Opens up the print dialog to print the expanded contents of the
selected node, with top-level headline.

print-preview-expanded-node
---------------------------

Opens up the print preview dialog to preview the expanded contents
of theselected node, with top-level headline.

print-expanded-node-body
------------------------

Opens up the print dialog to print the expanded node body.

print-preview-expanded-node-body
--------------------------------

Opens up the print preview dialog to preview the expanded node
body.

print-marked-nodes
------------------

Opens up the print dialog to print all marked nodes in the current
outline, with headlines.

print-preview-marked-nodes
--------------------------

Opens up the print preview dialog to preview all marked nodes in \
the current outline, with headlines.

print-marked-node-bodies
------------------------

Opens up the print dialog to print the bodies of all marked nodes
in the current outline.

print-preview-marked-node-bodies
--------------------------------

Opens up the print preview dialog to preview the bodies of all
marked nodes in the current outline.

Settings
========

- ``@string printing-font-family = DejaVu Sans Mono``
The font family for printing. A monospaced font is recommended.

- ``@string printing-font-size = 12``
The font size for printing bodies, in px. Due to limitations
of PyQt, the size of headlines cannot be changed.
'''

To use it, be sure to add `printing.py` to your @enabled-plugins.

Future work may have more printing modes available, and I intend on
doing a blog post on the leoblog about creating custom printing modes in
scripts.

This addresses bug 1132804:
https://bugs.launchpad.net/leo-editor/+bug/1132804

-->Jake

[Kent Tenney]

It just works! Nice.
Being able to preview is great, less paper wasted.

I rely entirely on command completion as a memory aid, too
bad the info listing commands also start with 'print'. I would
think that 'list-<attribute>' would have nicely disambiguated the
situation now we have print.

Too late?

> --
> 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?hl=en-US.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Jacob Peck]

On 5/15/2013 9:04 AM, Kent Tenney wrote:
> It just works! Nice.
> Being able to preview is great, less paper wasted.
>
> I rely entirely on command completion as a memory aid, too
> bad the info listing commands also start with 'print'. I would
> think that 'list-<attribute>' would have nicely disambiguated the
> situation now we have print.
>
> Too late?
>

I agree completely w/r/t 'list-<attribute>', but it most likely is too
late. Those are probably in use by some script somewhere. :(

Thanks for the comments, though! To be fair, this whole thing was crazy
simple to throw together - Qt does *all* the heavy lifting. Just throw
together an HTML string, wrap it in a QTextDocument, and call print_,
and Bob's your uncle. I can see why Leo uses PyQt now... it's awesome.
-->Jake

[Fidel Pérez]

Thank you for this plugin, very useful!

[Jacob Peck]

On 5/15/2013 9:12 AM, Fidel Pérez wrote:

Thank you for this plugin, very useful!

Thanks, Fidel.  Glad you like it :)

-->Jake

--

[Edward K. Ream]

On Wed, May 15, 2013 at 7:41 AM, Jacob Peck <gates...@gmail.com> wrote:

I've added a new plugin to Leo, that adds printing support when using the Qt GUI.  Available from rev 5779.

Excellent work.  Many thanks for this contribution.

Edward

[Kent Tenney]

I'm going to push a little here.

command completion is one of Leo's best features, making
it manageable to work with hundreds of commands. It's
usefulness depends on the quality of command names.

The current situation is both non-intuitive for folks looking
for information ('print-xxx is not standard, 'list-' or 'show-' is)
and confusing for someone wanting to send to a printer.

If at all possible, I think this should be changed.

Thanks,
Kent

[Matt Wilkie]

Hi Kent,

I agree with the principle, that command completion is aided by good quality names, but I don't understand why you think "print-xxx" as a command to send something to a printer is not standard. Can you elaborate?

-matt

[Terry Brown]

On Wed, 15 May 2013 16:03:47 -0700
Matt Wilkie <map...@gmail.com> wrote:

> Hi Kent,
>
> I agree with the principle, that command completion is aided by good
> quality names, but I don't understand why you think "print-xxx" as a
> command to send something to a printer is not standard. Can you elaborate?

I think Kent meant the older commands

print-all-uas
print-bindings
print-buttons
print-commands
print-focus
print-node-uas
print-plugin-handlers
print-plugins-info
print-settings

would be better named list- or show-, so as no to intermingle with the
new print-(to the printer) commands.

Cheers -Terry

[gatesphere]

On 5/15/2013 9:35 PM, Terry Brown wrote:
> On Wed, 15 May 2013 16:03:47 -0700
> Matt Wilkie <map...@gmail.com> wrote:
>
>> Hi Kent,
>>
>> I agree with the principle, that command completion is aided by good
>> quality names, but I don't understand why you think "print-xxx" as a
>> command to send something to a printer is not standard. Can you elaborate?
> I think Kent meant the older commands
>
> print-all-uas
> print-bindings
> print-buttons
> print-commands
> print-focus
> print-node-uas
> print-plugin-handlers
> print-plugins-info
> print-settings
>
> would be better named list- or show-, so as no to intermingle with the
> new print-(to the printer) commands.
>
> Cheers -Terry

As a concession, I could rename all of my print- commands to printing-
(name of the plugin) or printer- , but I generally agree that the older
ones would make more sense now as list- or display-. I can definitely
see why they were named print- previously, as print has a connotation
among programmers to mean "to the screen" rather than "to the printer".
I'd rather not rename my print- commands, though... they're already
pretty long, and just descriptive enough, I think.

-->Jake

[gatesphere]

Thanks!  Glad I could help.  Have any suggestions for further printing modes that should be canonical?

-->Jake

[Kent Tenney]

I thought of other prefixes, 'printing-' imposes a keystroke penalty,
I would be ok with 'prn-' but I think that went away with dos
'lp' is another reference to a printer, but that goes way way back ...

[Jacob Peck]

On 5/16/2013 7:27 AM, Kent Tenney wrote:
> I thought of other prefixes, 'printing-' imposes a keystroke penalty,
> I would be ok with 'prn-' but I think that went away with dos
> 'lp' is another reference to a printer, but that goes way way back ...

Hah, yeah... though `lp` is still relatively familiar to those of us who
are unix sysadmins.

As for prn-, I feel that shortcuts like that are icky when we have full
tab completion. I'd rather be verbose and explanatory than short and
cryptic. But printing- just feels wrong. So does printer-.

Just my $0.02 (for the nth time!)
-->Jake

[Terry Brown]

On Thu, 16 May 2013 09:41:58 -0400
Jacob Peck <gates...@gmail.com> wrote:

> On 5/16/2013 7:27 AM, Kent Tenney wrote:
> > I thought of other prefixes, 'printing-' imposes a keystroke penalty,
> > I would be ok with 'prn-' but I think that went away with dos
> > 'lp' is another reference to a printer, but that goes way way back ...
> Hah, yeah... though `lp` is still relatively familiar to those of us who
> are unix sysadmins.
>
> As for prn-, I feel that shortcuts like that are icky when we have full
> tab completion. I'd rather be verbose and explanatory than short and
> cryptic. But printing- just feels wrong. So does printer-.

I vote for using print-* for the new print commands (i.e. leaving them
as they are), and changing the old print- commands to show-, list-, or
even help-, depending on what Edward prefers - perhaps `show` is the
most descriptively accurate.

Cheers -Terry

[Fidel Pérez]

Being a noob myself, I would have appreciated to find the lists of commands within the help-

(I like Terry's idea).

Would have been very useful, since its difficult to find when noob.

[Matt Wilkie]

Being a noob myself, I would have appreciated to find the lists of commands within the help-

(I like Terry's idea).

Would have been very useful, since its difficult to find when noob.

 

Something I've thought would be useful is if the status area or mini-buffer showed the name of the commands that are being executed by menus and buttons as they are being used. This would aid learning a great deal, I think, similar to the way some programs show the keyboard shortcut commands for menu items in parenthesis or tool tip when hovered over.

-matt

[Fidel Pérez]

Im thinking something similar and planning to do so, a pane which will:

- Detect user events and show possible hotkeys according to what he can do from there (can get the "events hook" leo already has and whenever one of those is triggered, the pane changes to show useful hotkeys)

- Its going to be integrated with AHK and show a list of different windows the user is working with, so by clicking them the user directly goes to them

- User press control -> the hotkeys filtered by the ones which have control on them + possible actions from where the user is standing will appear.

The key press detection is going to be with AHK (so only for windows), and I will setup a easy - hotstrings and macro building (just drag and dropping nodes into the desired automation) plus it will also be able to manage external windows to the program... well many more plans but the basics are those ^^

The hotstrings will be associtated to the current "main" leo file, so when the user is using his "writting books Leo file" he will have his hotstrings different than when he is surfing the web for instance.

Hopefully in one or two months will be able to begin to show this project.

[Edward K. Ream]

On Thu, May 16, 2013 at 9:14 AM, Terry Brown <terry_...@yahoo.com> wrote:

> As for prn-, I feel that shortcuts like that are icky when we have full
> tab completion.  

I agree.  The beauty/genius of tab completion is that commands can be as long as needed.

> I vote for using print-* for the new print commands (i.e. leaving them

as they are), and changing the old print- commands to show-, list-, or
even help-, depending on what Edward prefers - perhaps `show` is the
most descriptively accurate.

For now, I see no great harm in having "print" mean two different things.  The "old" print commands send their output to the log pane; the new "print" commands print to the console.  This is a harmless situation.

In fact, tab completion easily allows one to specify the desired print command, no matter how many new ones are added.  The genius of tab completion is that one does *not* have to remember *any* commands, except how they start.  So having 20 commands start with "print-" is really no big deal, even if the commands don't all "print" in the same way.

Edward