[jsword-devel] BibleDesktop Enhancements

[DM Smith]

This all sounds good to me. It is always good to allow the user  
simple, obvious control.

See below for history and individual responses.

On Jul 22, 2008, at 12:39 AM, Adam Thomas wrote:

> I have some enhancements I would to add to BibleDesktop and wanted  
> to run them by the group. I am currently running Windows XP.

When I started development on BD/JSword, so was I. I also had Linux  
available for testing. I then got a Mac Mini to test BD on. Then my PC  
died and rather than buying new hardware, I got Parallels to install  
Windows on the Mac.

I test on a regular basis on the Mac (home) and Linux (work machine),  
but infrequently on Windows. So it is very good to have a developer to  
test regularly on Windows.

>
>
> When I first start BD, after the splash screen disappears, the main  
> DB window attempts to center and maximize itself.

Not quite. It has a built in initial limit of 1280 x 960. IIRC, it  
originally was 800x600. We increased for the sake of larger monitors.

At that time all monitors were 4x3.

We chose these dimensions, because we figured (wrongly, it seems) that  
most everyone would have at least a 1280x1024 monitor.

We chose 960, because 1024 interfered with the task bar on WinXP. We  
also had to guess as to the height of the window decorations, even  
though people could make the title bar bigger. We assumed that  
everyone would dock it top or bottom and not left or right. Thus we  
assumed that we had the full 1024 horizontal to work with. I'm not  
sure that there was a way to determine in a cross-platform kind of  
way, what the usable screen space is.

When the app starts up, it checks the actual screen size to determine  
whether 1280x960 is bigger than the available monitor. If both  
dimensions are bigger, it tries to go full screen (full screen is a  
platform dependent feature). There is something wrong with this logic.  
On a laptop with a 1280x1024 screen, it will not try to go full  
screen, but part of it will be under the taskbar. It probably should  
have checked to see if any dimension is >= to the actual and if so,  
then try to go full screen.

On Win98, WinXP, and maybe Win variants, full screen works well,  
taking into account the task bar and other docked items.

On the Mac, one can only resize by using the left, bottom corner. One  
can move only by grabbing the title bar. Also the Dock (Mac's task  
bar) is much larger than Windows'. So when this problem happens on the  
Mac, it is more severe.



> The problem is that the window is not correctly centered (it's  
> slightly to the left) and the bottom portion (status bar) of the BD  
> window is behind my Windows Taskbar due to improper maximizing. I  
> also don't like the fact that BD assumes I want it to take over my  
> entire screen and maximizes itself.

First impressions are important!

It only does the above behavior until the user changes Tools >>  
Options >> Application >> Maximum|Minimum Window Width.

This option is badly named. It should just be Window Width and Window  
Height.

Anyway, with your changes, this option should not be needed and should  
be removed.

As to centering, I don't know why it would be off center horizontally.  
It may be due to the window decoration being in the computation when  
it shouldn't? However, this would be a platform dependent behavior.


>
>
> What I propose:
>
> * The first time BD is run, after the splash screen disappears, the  
> main BD window centers itself and resizes it's window width and  
> height to a percentage (ie. 75%) of the screen, rather than assume  
> fullscreen. This also has the added benifit of shaping the window  
> rectangularly on widescreen lcds (newer) and squarely on crt (old  
> style) displays, in other words the aspect ratio of the window fits  
> the monitor it is running on.

I like the idea that it is based upon the dimensions of the screen,  
maintaining that aspect ratio.

I'm not sure that 75% is appropriate for all screen sizes. It  
certainly would be safe and on screens that are too small the first  
impression would be that BD opens way too small, resulting in the user  
immediately resizing the window.

The following would be the outcome:
Screen         BD
800x600      600x450
1024x768    768x576
1280x1024  960x768
1600x1200  1200x900
1680x1050  1260x787.5 (My current 16x9 desktop monitor)
1920x1200  1440x900 (My high res 16:9 17" laptop screen)

On 800x600 and 1024x768, currently BD will go full screen because it's  
default of 1280x960 is too big. The reason for this decision was  
because Java does not have any precision with the sizing of a window.  
On a small screen, mistakes are more obvious and harder to deal with.

I think that on 800x600 we still need to go full screen. Your call on  
larger screens.


>
>
> * Then the user can manually maximize the main BD window if they  
> desire.
>
> * Finally, BD will persist (remember) window placement and size so  
> that when BD is started next time, it can pull the previous settings  
> from persisted info. If the user manually maximized the BD window,  
> it gets maximized the next launch.

Placement is a funny thing. It is not the same on all OSes. On Linux,  
a user can choose from among many Window managers. And they can have  
different placement policies. here are some examples:
* The application can request where the window is placed.
* The user always has to place the window. Typically, the window will  
start to come up and it will track the mouse until it is clicked.
* The window manager randomly picks a location for the window.
* The window manager layers the window relative to the previous one  
that was opened.
* The window manager tiles the window, based upon others that are on  
the screen.

This can be more complicated if there are more than one screen. Either  
actual or virtual.


> I have already implemented the changes locally, except for the  
> persisting size and position. Is there already a persistence  
> mechanism in BD, or should I use a generic .properties file?

We have a typical pattern for persisting data. But we don't have a  
persistence mechanism. We do use property files for this kind of  
thing. I would like to suggest a generic repository for layout info.  
Or that your file would become that repository.

Ultimately, it would also be good to have it remember the layout of  
the main screen.

>
>
> Let me know what you think of these proposals.

!!!!

>
>
> By the way, is there a particular reason why you didn't simply use  
> "win.setLocationRelativeTo(null)" to center the window in the  
> "centerWindow" method of GuiUtil?

I don't remember whether that was that way when I started on BD/JSword  
(we were several releases away from 1.0 at the time).

My guess, and we can test it, is that most window managers will honor  
the placement of a window if told what to do, but all bets are off  
when it is left entirely up to them.

>
>
> I'll generate a formal patch file so you can test the functionality  
> yourself, if/when you approve my changes.

Please do.

I've gotten our bug tracker up and running. Please get an account,  
open an issue and attach your patches to it. Right now, it is not  
sending me notifications of changes, so please also post here.

In Him,
	DM