A thread to discuss what should be done about Tablet 83's unfriendly UI...
Personally, I'd love it if somone wrote and maintained a good UI; That's one less thing I have to get done quickly...

I voted the same as the other three people.

Well. I guess I don't have very much of a choice...

Well, when you named it Tablet 83, you didn't really leave yourself many options

Yeah, Kllrnohj is right about that. Plus, it helps define the niche that makes your product different than any other random calculation app.

I think I pointed that out a few times to him, but I may be wrong. I think for starters though, leave the tablet only stuff out of it for now, so this way it tested on all kinds of machines, then can be fine tuned to have a Tablet Optimized form.

The backend should be the high-priority right now, though.

Eh, I think it should all be in the same edition, and autodetect whether the computes is a tablet to decide whether or not lo enable the extra features.

Turning tablet support on or off would be impossible. The GUI toolkit will be the one taking care of the input methods, not the app using the GUI API. You can't turn off or on tablet support, its built into the GUI.

wxPython should just be used, as it uses whatever the native GUI API is, and so will provide the same level of tablet support as on that platform

But if there's something like a text input panel, it should be hidden on a non-tablet.

Incorrect in one simple way: Windows is Windows. wxWidgets is good, but not that good. Currently, I'll be VERY lucky if I get the Tablet PC UI coded in anything except .NET.... And even if I do, it will likely end up directly using M$ stuff. Why? Two concepts: Window handles, Automation. Both are Windoze-specific last I checked (clarify: Handles require the ability to get them, an easy task for Win32API, iffy elsewhere. Automation is based off of COM, but an absolute pain in anything except interpreted languages which pay specific attention to it). So, the options are ActivePython, IronPython, and VB 6. Of those, only ActivePython is not from M$. Two seperate releases needed; One for Tablet PC, one for Linux. Either will work on plain Windows, both can use the same backend.

That said, I think a significant portion of this thread can be summed up as "Quit being lazy, Proegssilb". I believe there's an appropriate phrase that goes something like "So shoot me".

Now the world knows why I asked about the UI. The real question is: What's most important? Few were willing to leave out an aspect of the UI, so I'll delay it until just before I get a reasonably useful release together.

Ah. Well, that's very understable now. And don't worry about the 'lazy' thing - I'm used to feature creeping.

Aren't windows "handles" just another term for hwnd or wid? (window ID) If so, you can get that in wxWidgets or GTK quite easily, and isn't Win32 specific in any way at all... (its easier to set a specific area inside of a window in GTK or wxWidgets than in .NET, and even easier to get once you know how to do it - GTK even provides a specifc class just for it )

I'm not sure what Automatoin is, but if you describe it or give me a link describing it and what its used for, I'll see if I can find an alternative

I'm not sure either, and http://en.wikipedia.org/wiki/Automation doesn't clarify it at all.

Automation is an M$ thing that allows scripting languages to use C++ objects a little easier... COM, the Windows version that Automation is based on at least, is a binary standard that defines how any two objects interact. It's a huge pain in C++, and PyCOM still requires COM/Automation, hence windoze.
The annoyance isn't Automation itself, it's that I have to be able to get an HWND and access Automation in the same place. Oh, and figure out how to tell WXPTE how to recognize math, and interpret the data received.