[bt-devel] bt-devel Digest, Vol 53, Issue 14

[Eeli Kaikkonen]

Dylon Edwards wrote:
>
> I'll do my best - instead of having multiple windows floating around the MDI
> that require you to resize each of them individually, implement a feature
> that would allow them to be "anchored" together.  Once anchored, resizing
> one causes any others connected to it, along the side being resized, to
> resize as well; this would be similar to the drag handle on the
> Mag/Bookshelf sidebar. 

OK, now I understand. And again: I have though about that already :)

It just needs much work. QSplitter is simple to use but placement and 
resizing algorithms and UI implementations for them are difficult. Not 
impossible or too difficult, but someone should have much free time.

> They would be placed on a grid with horizontal and
> vertical axes, and each window could have a different size.  You could have
> one window on one axis, while having 3 on another.  I would suggest either
> having only one layer used for anchoring windows (which would be placed
> behind all the others), or creating a feature, like the Slots and Signals
> connector in Qt Designer, that would allow an arrow to be dragged from the
> active module window to the one you wish to anchor it to.  Newly opened
> module windows would default to being unanchored (in case you want to look
> at a map or something, and don't want the sizes and positions of your
> currently opened modules to be affected).
>   

Splitters could even make a tabbed interface reasonable. In the current 
window system it's mostly the manual mode which makes tabs a bad choice. 
In automatic mode the windows are resized when the main window is 
resized, and splitters would be like automatic mode. Therefore, if the 
user had several sets  of windows inside tabs, they would not be messed 
up after resizing the main window. The window sizes would still be 
problem but maybe not too big one. I mean, if user wants to read only 
one translation in one tab but has four modules in another he has to 
decide whether he wants large main window and unnecessarily large window 
for one module, or small main window and too small windows for several 
modules. Resizing the main window would resize all subwindows, even 
invisible ones in all tabs, and moving to another tab could bring need 
to resize again.

It's quite difficult to imagine how this would work in practice. Users 
could learn quickly how to use it and find their way of working or they 
could find this continually annoying. Opinions?

Initial placement is another important issue. Naturally clicking a 
module in the list would open the module in new subwindow in the current 
tab and the placement and size would be calculated automatically. But it 
should also be possible to drag and drop a module to a wanted place. 
Algorithm for that is not simple. If there is one old window it must be 
cut to half either horizontally or vertically and the new window placed 
on top of either half. But what if there are two rows of windows like this:

|1|2|3|
|  4  |

and user wants the fifth like this:

|  5  |
|1|2|3|
|  4  |

or like this:

|1|2|3|5|
|  4  |5|

Splitting and sizing is not the problem but offering the possibility to 
choose the exact placement.

One could argue that we don't have such sophisticated system now and do 
fine without it. But if we don't have a manual mode where windows can be 
moved and resized freely we have to make sure that the user gets what he 
wants.

We have to remember also that the subwindow widgets should probably be 
re-implemented with our own code instead of the current Qt solution. Not 
a small task, either.

> I would imagine many people, such as myself previous to your last message,
> don't know about Clucene's syntaxed searches.  Since Clucene already does
> the hard work, it shouldn't be too dificult to implement radioboxes that
> cause BT to perform certain types of searches by parsing the user's input
> string and formatting it to the specified syntax before searching for it.
> That would make things easier for everyone and spare the user from having to
> enter extra words, such as "them AND in AND mind AND to AND be AND subject"
> (Titus 3:1, KJV - a random verse I chose to make a point).  Don't you think
> it would be much easier just to check a radiobox that searched for "them in
> mind to be subject" than having to manually type AND between each word?
>   
Choosing between "and" and "or" searches is a common feature for many 
search UIs and would make sense.

There's the "Help..." button besides the search string area, but I know 
that nobody reads the manual :)

Maybe radiobuttons really are worth implementing. I would use "0 All 
words 0 Some words 0 Lucene syntax" so that the advanced users could 
choose the full syntax. "Lucene syntax" is perplexing but could also 
guide some people to find more information - hopefully with the quick 
help button :) But on the other hand the "OR" search already has the 
full lucene syntax.

What Martin thinks about this?



--Eeli