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

[Martin Gruner]

Hi Dylon,

welcome to BT! Glad to hear you are eager to invest your time and 
skills for this project.

I won't comment your suggestions in detail. You have good ideas, and as you 
can see from our Feature Requests Tracker and also the wiki, other people had 
good ideas as well.

You may already know that software development is more than "adding a bunch of 
cool features". That's the challenge we're facing: to get a sustainable, well-
coordinated development going on. Currently, the next major step is to prepare 
the 1.7 final release (see 
http://devel.bibletime.info/wiki/Development_Plan). We didn't get 
everything in that we wanted, but currently we should focus on stability and 
consistency, instead of adding new features which may introduce more bugs.

Another step we should take in future (imo) is to add automated software 
testing ("unit testing"). I made a start with this, but it needs to be much 
improved.

So: if you are interested in being part of our team with a medium or long term 
vision, you are more than welcome. =)

God bless,

mg

Am Dienstag, 16. September 2008 22:26:53 schrieb 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
>
> _______________________________________________
> bt-devel mailing list
> bt-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/bt-devel