[be] [task #9428] help file updates

[Teus Benschop]

URL:
  <http://savannah.nongnu.org/task/?9428>

                 Summary: help file updates
                 Project: Bibledit
            Submitted by: teus
            Submitted on: Tue 26 May 2009 04:55:06 PM CAT
         Should Start On: Tue 26 May 2009 12:00:00 AM CAT
   Should be Finished on: Tue 26 May 2009 12:00:00 AM CAT
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

> Yes, I prefer a one similar to the ubuntu one for debian. Html right now
> is preferred, because we don't use DocBook XML yet for creating the
> documentation. Thanks for your offer to create that information.

OK.  Tell me whether the page at
http://computeroptions.net/sword/bibledit_debian.html meets your needs.
 It ended up longer than the Ubuntu one, mostly because it does not
refer people to an external page for instructions on adding a repository.

Now we have a GUI/command line example.  How can a user extract from the
GUI-oriented description of how to add a repo on that help page I just
wrote, that the quick way to do it is something like:

  su -c "echo 'deb http://ftp.debian.org/debian/ testing main' \
    >/etc/apt/sources.list.d/testing.list && \
    apt-get update && apt-get install bibledit"

I don't think many people, even those who have fairly decent command
line skills, would be able to extract this command from the GUI info.
Yet it is *much* shorter and simpler to cut and paste this one command
line from a web page window into a shell window, than to do all the GUI
steps ... you just select the command text, ctrl-c, middle-click on the
shell window, and press Enter.

If we need to avoid typing even just the password into the shell window,
because people *really* don't like using the shell, we could even use:

  gksu "bash -c 'echo \'deb http://ftp.debian.org/debian/ testing main\'
    >/etc/apt/sources.list.d/testing.list &&
    apt-get update && apt-get install bibledit ' "

so the users get a pretty GUI password dialog, not a shell one :)

One last variation: no terminal window need even be opened... The user
hits Alt-F2, types gksu into the dialog box that opens and clicks OK.
Then the user selects the command, ctrl-c, and then middle clicks to
paste it into the Run: field and clicks the OK button.  That's fast,
truly minimal typing, and the user never even *sees* a command shell
this way.

Nevertheless, my proposed help page follows your advice to specify only
the GUI approach, and does not include any shell commands to use :)

> Yes, it would be faster, but some users are new to Linux, or even those
> not very new to it, and they prefer the information to be given to them
> step by step and use the GUI. It is only that compiling from source must
> have the command line, so the new users cannot escape from that.

I somewhat disagree with this last sentence.

Idea #1: You could put a small script on the web site and have users
click on a link to it; appropriately set up, I think this could be made
to untar and compile the app with no user typing at a command line.

Idea #2: Worst case, they'd have to download and save the script file,
and then use their GUI file manager (Nautilus or whatever they use) to
make it executable and then double click on it to execute it.  No
command line use at all would be needed, and stuff still gets compiled!
 I just tested this approach here... it works fine.

Idea #3: Using the Alt-F2 gksu idea from earlier to copy and paste the
command text to do the untar and compile and install -- users could
compile and install the tarball sources without even seeing a shell
window ... although if it fails, troubleshooting without such a window
could be awkward :)

But the whole idea of novices who are uncomfortable at the command-line
compiling anything from a source tarball seems rather strange; it should
not, generally speaking, be necessary for end users to do this.

> It would be a great help if packages were described for them how to
> use that. This would keep them all in the GUI, so they would never
> have the command line in front of them.

See above for (a) using packages and (b) compiling the source tarball,
both without a command line (shell window) in front of them :)

Using existing packages is better for end users, of course, for all of
the Linux distributions that have packages available.  That's why I'm
doing this packaging work!  But realistically, you probably won't get
up-to-date Bibledit packages for many less popular Linux distributions,
without doing a lot of packaging yourself.

Incidentally, speaking of easily installing packages: we can now embed
apt-urls into web pages.  So, once we have the packages in the official
repositories for current Debian and Ubuntu versions, the install
instructions become very close to just "click on this link; when asked
what to do with it, select "Use Gdebi Package Installer" (which is the
default) and click OK".  apt:bibledit?refresh=yes is an example of such
a URL.

Until then, we need to have info on adding a PPA or the Debian testing
repository first.

I suspect using apt-url's could be a better (cleaner, shorter) approach
than describing use of Synaptic or gnome-app-install; if I get inspired
I'll test my theory!  I hope webkit handles apt-urls in basically the
same way Firefox does...






    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?9428>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/