[sword-devel] roadmap for Windows frontend(?)

[Daniel Glassey]

Chris Little wrote:
> On Wed, 9 Apr 2003, Christian Renz wrote:
> 
> 
>>From an UI point of view, I'd say I don't really like the small window
>>to open up new desktops -- I prefer MDI or a mixed approach
>>(e.g. Opera 7's tabs and windows). And of course on Mac OS
>>(Classic/X), you'd want to put all of the master window's
>>functionality in the menu bar. But of course, that's a whole different
>>discussion. 
>>
>>I _do_ like the ideas of customized desktops (or "projects") with a
>>selection of modules that can be saved/restored etc. very much -- way
>>to go, Chris!
> 
> 
> The BibleCS 2.0 prototype is all Troy's work, so way to go Troy.  One 
> issue is that the whole MDI interface was specifically one of the 
> interfaces being avoided.  Troy can explain his reasons for that, though 
> perhaps there are different ways of looking at it.  (i.e. is the 
> Bible/Commentary/LD window itself a "document" in the MDI sense or is the 
> desktop (with multiple Bible/Commentary/LD windows) the "document"?)

It's a cool prototype :).
But, the main problem I see with the 'small window to open new desktops' 
model is that it is non-standard on any platform. Something like it 
could be available for power users, but normal users should get an 
interface that they recognise or can intuitively use.


>>While I am using MSVC++ myself (and the student version is somewhat
>>affordable), I would vote against using MFC. A Sword 2.0 is going to
>>take a lot of work on the UI, and I feel it's not really worth the
>>effort to put it into something that's not portable.
> 
> 
> GnomeSword, BibleTime, and BibleCS are all essentially non-portable and
> took a lot of time & effort to write.  We need to maximize what we offer
> our Windows users, especially since they are the largest market share
> among our users.  If (and that's a big if) everything that can be done
> with MFC (or VCL or any other platform-specific framework) cannot be done
> with wxWindows, then wxWindows shouldn't be used for development.

I think it should be that if wxWindows can't do everything that we want 
to do then it is a problem. The same applies for VCL or MFC. wxWindows 
is not far from MFC, it uses standard windows controls, and has a 
similar API (which is why one of it's big points is for porting MFC apps 
to linux). Anyway, if necessary, platform specific code can be done if 
other stuff in the w32 api is needed.

> I actually think that using MSVC alone would be the greatest benefit (or 
> more accurately, using anything other than Borland).  Using a platform's 
> standard compiler relieves so many headaches.

mutter mutter msvc6 giving annoying useless stl warnings and not 
compiling good c++ code and stuff mutter mutter ;)

>>There are other platform-independent toolkits as well, although probably
>>not as complete as wxWindows, and probably not available in Unicode.
> 
> 
> What are the Unicode capabilities of wxWindows?  Are we going to be able 
> to fully internationalize the interface with Unicode?

yes (usual caveat that win9x doesn't do unicode in it's standard 
controls so you won't get it there with anything)

Regards,
Daniel