Tuesday, February 10, 2009

wxWidgets sucks...

... but even though it sucks, I can't really blame it. I think the problem is endemic when using pretty much any large toolkit, especially younger ones or ones that are built on top of other toolkits.

First, some background. wxWidgets is a windowing library to allow people to quickly and easily develop GUI applications. It's cross platform and in general built on top of other toolkits. This means that the layers of toolkits upon toolkits is often at least two levels deep, exponentially increasing the likelyhood that bugs in one layer will foul up things elsewhere.

These sorts of interactions are causing me huge difficulties with the display and input windows in the client. After much soul searching, I have what appears to be three choices going forward, each with various pros and cons, none of which are ideal. In short:

1) Use the native wxTextCtrl class. Pros - some minimal screen reader support, cut/paste works, already mostly working. Cons - scrolling doesn't work worth a shit, different performance on different windows versions, urls are unreadable for at least some people, no way to disable beeping on backspace, and easily a third of the style flags and other functions don't work or don't work correctly, often with no workaround. Further, the god damned thing intercepts certain keystrokes, specifically Control-C, before I can get at them, and there appears to be no workaround for this.

2) Use the scintilla derived display class. Pros - someone else maintains it. Cons - pain in the ass to get working, manual url and cut/paste handling, bigger, vastly more complicated than my application requires, and inability to configure simple, important things like the background color.

3) Write my own. Pros - it will do exactly what I want, when I want, with the interface that I want. Should be fast and small. Cons - I have to do all the work.

After all the crap I've been through in the last month trying to get the default text controls to do incredibly simple, obvious things, I'm heavily leaning toward option 3 at this point. In the time I've spent trying to get existing controls to work, I could have without question written my own custom primitive. Or rather, I now know enough to write my own. The road would have been rockier in the beginning.

I think this is a prime example of why I rail against toolkits in general. They are very risky; there's no guarantee that what you're using will work, or can be made to work the way you want it to. In this case, I have lost a huge amount of time trying to work around toolkit limitations.

Option 3, here I come.

3 comments:

Anonymous said...

can't wait to try it

Dennis Towne said...

Update - I got the beginnings of a renderer up and working today, and it's currently playable but very limited. Tonight I'm hoping to get scrolling and line breaking done.

There's lots of difficult stuff left to do though; variable width fonts, url tagging and copy/paste are all going to be non-trivial.

Dennis Towne said...

Update: for item 1, intercepting of keystrokes and beeping, it appears you can get in fact work around both of these by grabbing the raw KEY_DOWN events and masking out the problem ones. This requires you to set up a sort of state machine to trap out all cursor movement, but it can in fact be done.

While my success with option 3 has been wonderful, I still use the wxTextCtrl class for the input window. It's now a viable option now that I've figured out how to mask the beeping and fix the colors.