Build & Maintain Help Across Desktops

Forum Forums General Tips and Tricks Build & Maintain Help Across Desktops

  • This topic has 101 replies, 6 voices, and was last updated Dec 21-10:27 pm by BobC.
Viewing 7 posts - 91 through 97 (of 97 total)
  • Author
  • #30990


    BobC, here is a near-final copy of the script. It is pre-configured to use zim.

    1) Save the script as / usr / local / bin / bobHelpnotes
    2) chmod +x
    3) launch "bobHelpnotes" (no quotes) to begin a trainingmode run

    Optionally, you can create a file
    ~ / .config / Helpnotes / knowntitles
    containing a list of the windowtitles that you want to specifically provide helpdocs for, one per line… and altogether skip trainingmode, instead using this launchstring :

    bobHelpnotes --onlyknown

    • This reply was modified 1 year, 4 months ago by skidoo.

    I drafted the following a day or two ago, but chose to hold back posting it until you had the script in hand, available for use. Some of the details (regarding the design details) are difficult to just talk about ~~ they need to been experienced in hands-on use.

    for the standard programs we use a lot, maybe we could just provide default settings. For example, if I hit the super help key in geany, I am likely wanting help with geany

    Somehow, it seems like we’re still not on the same page.
    You seem to be dwelling on keybinds.
    That would (should) be handled by a simple one-liner (or 3-liner) script.
    Many posts back, I showed “just set a keybind to exec ‘xdotool getwindowfocus getwindowname’ and pass the output to zim launchstring”
    On-demand, context-sensitive, popup help.

    Reiterating what I had envisioned (and had presented in the WIP ‘script header coments’ post), my “bobHelpnotes” script is intended to be a long-running script which continually monitors and autodetects changes in context. It oh-so-helpfully (or, as testing has confirmed, “sometimes oh-so-annoyingly”) automagically — triggered by each windowtitle change event, no keybind(s) involved — displays the helpviewer. If a previously-drafted note matching the context exists, that note is automatically displayed. If no note yet exists for the current context, the script prompts to ask how to proceed. The user may choose:
    — (one-time, just this time) dismiss the prompt, or
    — create a new note matching this context, or
    — in the future, always ignore this exact “context” (based on titlestring of the current window), or
    — always ignore contexts where the titlestring beginswith ____, or
    — always ignore contexts where the titlestring endswith ____

    ^—— no wildcard globbing or regex required by the end user (handled internally by the script)

    Toward suiting the limited scope usage you have proposed (i.e. notes only for a select grounp of programs, containing only lists of keybind:action lookup pairs), you would launch as “bobHelpnotes –onlyknown”. In this mode, you would not (will not) be subjected to ongoing “what do to?” prompts. By prepopulating a configfile with desired matchstrings, you can altogether avoid ever using the “peppered with popups” mode. However, you (or I, or any end user) can avoid initially hand-editing the configfiles by launching “bobHelpnotes” (no commandline options passed) and, via responses to prompts, let the script handle the chore (?) of populating the lists. I felt compelled to provide easy access from within the script (via prompt choice) for opening and editing the “ignored” list. For now, any edits to the other (endswith, beginswith) lists must be performed manually. Edits? Yeah, as in, hindsight “oops, darn it, setting a rule ‘ignore beginswith XYZ’ produces a too-greedy (or not greedy enough) matching result”.

    Unless the external helpviewer performs “remember, and restore, last ScrollTo position“, I would NOT choose to store keyind:action lists in my notes ~~ I don’t welcome the prospect of, eternally, having to scroll past a pagelong block (list) of key:action pairs prior to jotting additional notes. A related consideration is the possibility (likelihood) that a new user or casual user may not think to scroll down to discover that a given note contains “more than just keybinds list”. FWIW, when settng up (curating) a snapshotted system for use by others, I might searchreplace create a separate copy of the bobHelpnotes script, populate a separate directory with notes containing only keybind:action pairs, and session autostart that “other” script (in –onlyknown mode).

    For example, if I hit the super help key in geany, I am likely wanting help with geany

    Oh man, that’s an ironic example. Due to my continually-running script approach, the script logic must consider “whatif the scenario is: a moment ago, Jojo chose create+show a new note and, the windowchange event is that of the geany window displaying said note?” (It would be ridiculous for the script to prompt, recursively, “no helpnote yet exists for newnote_-_Geany. Would you like to create one?”)



    One thing I like about the script that runs from rofi is that it reads plain text files which are stored in a lib folder lets say the i3-user-guide just drop the guide into to lib folder run the and it is automatically added to the guide list and you can search for say =floating and it will show you floating entries in the list below and you can scroll the list. (This works good But not perfect)

    I have my beloved antiX-Debian-helps-plus-tips file which holds commands , install tips etc as most dedicated Linux users would have in some form. Their is no auto updating of the helps which you have tried to do and for the most part seams to work. So in this case I just update the files in the lib folder as I learn new things and add more help files as I find them. One thing I wish you could do with cheeet is copy and paste to the prompt line especially with commands like i3 gaps Dependencies saves typing or opening a text editor.

    But overall I find cheeet has made using help docs that much easier and saves me time. You can also adjust the size of the rofi screen to what ever size you want even full screen.

    I wish I had your talent with scripting & coding so I could make the scripts work better at 61 that’s not going to happen to many toasted brain cells.

    Installing i3 with Gaps——-
    Dependencies for i3 gaps——–

    sudo apt install gcc make dh-autoreconf libxcb-keysyms1-dev libpango1.0-dev libxcb-util0-dev xcb libxcb1-dev libxcb-icccm4-dev libyajl-dev libev-dev libxcb-xkb-dev libxcb-cursor-dev libxkbcommon-dev libxcb-xinerama0-dev libxkbcommon-x11-dev libstartup-notification0-dev libxcb-randr0-dev libxcb-xrm0 libxcb-xrm-dev libxcb-shape0-dev

    ==== Tips antiX ==== = antiX Control Centre (GUI)

    cli-antiX = package & kernel installer (prompt)

    antiX-cli-cc = antiX Control Centre (prompt)

    source ~/.bashrc = reload bash

    etc etc

    T430 i7-3632QM 16gb , antiX-19.2.1-runit_x64-base Hannie Schaft 29 March 2020 , 5.8.16-antix.1-amd64-smp


    “reads plain text files”

    Yes, different from what I posted for BobC, that’s the way I will be using it.
    Here’s another copy of the script, pre-configured for use with geany as the external helpviewer.

    1) Save the script as / usr / local / bin / bobHelpnotes
    2) chmod +x
    3) launch "bobHelpnotes" (no quotes) to begin a trainingmode run

    BobC, a last-minute change (missing from the posted the zim variant):
    in the custom rule dialog: removed incorrect “Tip” and added a Cancel button
    (user must explicitly close, cannot accidentally close, the custom rule dialog)


    What a difference a day makes!

    skidoo, thanks for your efforts here. I will download and install onto a fresh system and will let it suggest filenames and try pasting in my text. I’m hoping that way I’ll see it run as you envisioned it, rather than in my likely feeble, old school, simplistic mode. For me, something like this is a must have app. I keep trying and using many programs and apps, and the more of them I use, the more difficult remembering hotkeys and tricks for each becomes.

    Thanks again, and I’ll have at it this weekend…


    Consider: the (dialog)window titled ‘About leafpad’
    displayed when a person using leafpad has clicked Help-}About
    represents a good example of a granular “context”

    (autocreated while using trainingmode) would be a suitable place to plant the list of leafpad keybinds|accelerators.


    At least I now understand more of what you are trying to create. LOL, recursive helpnotes, might not be very helpful!

    But need to try it to see, I suppose.

    I will have to try it and find out. Maybe I will like it…

Viewing 7 posts - 91 through 97 (of 97 total)
  • You must be logged in to reply to this topic.