[bt-devel] Development after 1.7

Martin Gruner mg.pub at gmx.net
Wed Feb 11 10:04:07 MST 2009


Hi Eeli,

> Sounds good enough. We just have to learn how to use svn more
> efficiently. I have not abandoned the idea of distributed version
> control, but the time is not yet right for changing that. If we get
> more developers this may be topical within one or two years.
> Meanwhile, read e.g.
> http://betterexplained.com/articles/intro-to-distributed-version-control-il
>lustrated/

Thanks for the link - will read.

> As for my own part - I have thought about the instmgr. Concurrent
> install has some usability problems with the current UI. If there are
> installs from several sources it's very natural to do them
> concurrently, but that means leaving some of them out of sight in the
> dialog because the exact order can't be predicted (because the
> download time can't be predicted). I believe the current engine
> implementation works reliably even though it could be technically
> better. It would be more useful to change some things in the sword
> engine than to do complicated things in our code. But I don't want to
> do that, at least atm.
>
> Would it be better to wait for feedback from users and get back to it
> later? Concurrent install would be great for hardcore users but I
> don't see it as a core feature. We have gained a huge usability
> improvement from threads in form of non-blocking gui and I'm quite
> satisfied with the situation.

That is ok for me. We should keep the issue in our planning list, though. 
Maybe at a later point.

> Instead, I could use my time for KDE->Qt port. I think we all want
> eagerly have something for Windows/Mac as soon as possible.

Sure.

> >  2. bug report dialog
>
> I would prefer a Help menu "Online" with submenus "Report bugs (opens
> a browser)" etc. They would just open a page in a system browser, in
> this case the sourceforge bugs page.

Yes, why not. A bug report dialog is not a must-have, it could also be left 
out completely. But it would be user friendly to direct them to our sf page.

> ...And there are some items in
> http://devel.bibletime.info/wiki/BibleTime1Refactoring (which is an
> orphaned page, BTW, after the Main Page edit - it should be fixed).
> Let's use and edit that.

Ok. We must be careful though not to try to achieve too much for a release.

mg



More information about the bt-devel mailing list