[bt-devel] UI improvements

[Eeli Kaikkonen]

Jonathan Marsden wrote:

> Easier to implement, probably.  Easier for users... not so clear; it
> might be easier (more friendly) if the initial dialog height were
> "automatically" larger, on screens that have the height available.
> 
> Is doing *both* of these things a possibility?

Yes, it's possible. I wasn't completely clear: "easier" meant 
implementation. Of course it would be ideal to use all available space 
automatically, but saving the user selected size is more important IMO, 
and because of the standard reason (limited developer resources) I would 
implement saving first.

> 
>>> 2. The Bookshelf Manager initially offers to store new modules in
>>> /usr/share/sword which is not writable. I know it tells you about this
>>> after you try to add a module. How about not showing any path that is
>>> not writable.
> 
> Or, IMO better, how about prompting for credentials so you *can* write
> there... via kdesudo/gksudo/etc.  This makes the shared data space a lot
> more useful :)
> 

This is related to the "modules via package manager" problem. I wouldn't 
spend our resources in platform dependent techniques which serve a rare 
use case which can be solved another way. Even though there's a way to 
do it in a distro independent way in Linux, it should be implemented for 
all OSes, not only for those Linux distros which have PolicyKit.

>> ATM it lets people add paths which are not writable. How about
>> preventing that?
> 
> Those added paths may have modules already installed under them.  Those
> paths may be to a CDROM or DVD... etc.
> 
>> Therefore it would be best to prevent selecting a non-writable path from
>> the dropdown selector, or maybe not showing such paths at all.
> 
> Again, those paths may have modules (installed by a user with
> appropriate credentials, or burned into optical media) already
> installed, so not showing them at all is a clear loss of functionality.

We are talking about different things. I'm talking about the dropdown 
list from where the user can select where to *install* new modules. You 
are talking about the locations of *already installed* modules which the 
Sword engine uses (reads).

The misunderstanding may have been caused by a non-intuitive user 
interface. The user can edit the paths by opening a path configuration 
dialog from the Install page. It doesn't configure only the paths *where 
to install to*, but also paths *where the works are installed*. That may 
  be a bit confusing. After editing paths the user can select one of the 
possible paths from the dropdown selector. We could filter non-writable 
paths away from that selector.

> 
>> 5. A larger, but necessary, task is to do something to the display
>> window toolbars. They are a shame for us. Usability is very bad if the
>> display window is narrow. Try for example some general books with a
>> narrow window. Lexicons or Bibles are not much better.
> 
> Really?  How narrow are you thinking about here?  I tried WHNU and KJV
> with BT around 250 pixels wide and 800 pixels tall (closing the
> Bookshelf/Mag/Bookmarks windows of course), and it is still reasonably
> usable/readable for me.  That's about 20% of the width of a 1280x1024
> screen, which is pretty narrow.   Once you make BT narrow enough that
> the horizontal scroll bar appears, sure, it's awkward... but that's
> *way* narrow, even on a VGA 640x480 screen that would be very narrow!
> 

It doesn't have to be so narrow. In my opinion if the "more buttons" 
button appears, it's not easy to use anymore. And apparently you didn't 
try for example Institutes genbook. It hides the key selector altogether 
even when the display window is ~420px wide for me.

>> 6. Some people have complained that opening modules (display windows) by
>> clicking a module name isn't intuitive. Maybe we could add text to the
>> empty display area shortly describing how to open modules.
> 
> Interesting idea.  It might be more valuable to have the File Menu act
> more like a conventional file menu... and include open and close
> commands that work on (installed) modules?  File -> Open is in some
> sense "intuitive" for anyone who has used a word processor or
> spreadsheet in the last decade or so, I would think.  At the moment, the
> File menu just having Quit in it seems a bit of a waste of a top level
> menu, to me.  I was surprised by that the first time I ran BT.  Also, if
> you had a File -> Open dialog you could have an icon for it in the icon
> bar, too.
> 

Now when you say it, "File->Open a work->[module lists in submenus]" is 
not a bad idea at all. Of course it doesn't exclude the informational 
message.


--Eeli Kaikkonen