Winforms with C#, hands down. Obviously, pretty Window centric, however works fine with Mono too, even with a lot of Win32 specific hacks.

and at the same time is an indicator of the generally sad state of GUI frameworks...

Yes, that was sort of my point.

God forbid anyone uses a GUI framework that wasn't designed back when people though digital watches were a pretty neat idea...

I'm a fan of Kivy, if you're looking to get outside your comfort zone.

I'm happy to try anything, provided it actually delivers usability and maintainability. Given that I'm a big python fan, this looks quite interesting.

Does Kivy support SQlite, HTTP, and all that enterprisey stuff?

I voted for 4 options:

WPF: If you want a Windows only app and want to develop in C#. This is actually pretty nice to work with, in my (semi-limited) experience.
QT: If you want a desktop app and don't need uber platform specific control.
HTML5/js/css: If you want a web-app, use this. If you don't want a web app, don't use this. Simple as that.

I guess partially what I'm trying to ascertain is why you would pick desktop over web or vice versa.

To reveal my own bias, I've been thinking more and more that desktop development for this kind of work is a dead end.

A few years ago, it was simple. You write a windows app. Mac? Linux? meh, who cares? They're an insignificant portion of the market.

Now, though? The market is much more fragmented with tablets, phones, etc. People want their app to work on all their devices.

Granted for a certain class of desktop app, a native client makes more sense, but for your bog standard CRUD lob application? I honestly expected most people here to go for web client.

But thank you all for your opinions. Food for thought.

Does Kivy support SQlite, HTTP, and all that enterprisey stuff?

Not as far as I know. But I'm a bit at a loss why you would want your GUI framework to deal with databases and web services, in the first place.

There are countless Python modules that are dedicated to handling those things...

This reminds me of a programming test from decades back. The task is to design a house. Left unsaid is that the house is for giraffes at a zoo. Most designers fail to ask questions and generated something unusable.

Who is using the app? (Something public facing for everybody globally is different than an in-house system for three people with extensive training.)

What systems are they using? (Everyone running the latest version of Windows? Linux? Phones and tablets? Embedded devices?)

Is there a reason your clients would prefer a lightweight web interface or a native heavy interface?

Are there legal requirements, such as accessibility standards, that must be met?

How will their needs grow over the years? Are they anticipating growing to new operating systems, to mobile devices, to embedded systems, or across the Internet?

I'm tempted to go with a pure web-page solution simply because it allows the most access when implemented correctly. (hint: heavy reliance on jquery, JSON requests, and other client-side scripting does not qualify as implemented correctly. It breaks mobile devices and tends reach obsolescence prematurely.)

I'm strongly in favor of a completely decoupled frontend when it comes to business systems. It doesn't matter if they connect with a thin client, a heavy client, embedded devices, a web service, a web page, or anything else. Build the back end such that anyone can build as many front-ends as they want.

But I'm a bit at a loss why you would want your GUI framework to deal with databases and web services, in the first place.

Completely agree.

Most designers fail to ask questions and generated something unusable.

That's a very good point, and you're right in that the answer is always "it depends".

I'm strongly in favor of a completely decoupled frontend when it comes to business systems. It doesn't matter if they connect with a thin client, a heavy client, embedded devices, a web service, a web page, or anything else. Build the back end such that anyone can build as many front-ends as they want.

That's pretty much my plan. Backend will probably REST-ful.

That's a very good point, and you're right in that the answer is always "it depends".

The sad part is, its hard to simply respond saying "it depends" anymore, since the response seems to be the best response these days to a lot of questions. Quite often it makes sense and is perfectly acceptable to say "it depends", there seems to be a trend with "not-constructive" threads on SO for example and "it depend" answers. What you end up finding is they all get answers where scenarios are conjured up by the answerer, I was reading a thread the other day and one of the comments was quite amusing, a guy commented "why do all the not-constructive threads, get all the most user ratings" or something, despite threads being not-constructive, answers with information rather than "it depends" get the most point, even if that information is provided based purely on assumptions

My point is the more information a person provides the better the answers will be, I don't think there is one poster in this thread who would religiously use one tech for everything and will (hopefully) look into the requirements that project needs, sure things aren't always perfect but someone making say a new major app in raw Win32 isn't going to happen (or at least I don't see why it should happen), yet they may have selected it for a scenario they conjured up, like to understand Win32 at a low level or something.

Think of it this way, lets pretend you asked "I am going to be working on a new project, what language would you choose to make it?", the acceptable answer will be "it depends" (or really "the one you have experience with"), instead based on the information provided quite often the missing info is created by the replier and oddly enough the more informative answer gets appreciated over "it depends" despite the fact that the information provided may only make sense for one scenario.

Not trying to have a dig at you or anything, but it is kind of hard to answer something efficiently when there is little information provided, yet any detailed answer ends up somehow being correct over "it depends" :S I think for questions like these it is important to mention requirements or risk being given answers / scenarios that you cant relate to

I'm tempted to go with a pure web-page solution simply because it allows the most access when implemented correctly. (hint: heavy reliance on jquery, JSON requests, and other client-side scripting does not qualify as implemented correctly. It breaks mobile devices and tends reach obsolescence prematurely.)

This hurts my soul. How does one have a pure web-page solution without the aforementioned? Are you referring to the days of Netscape 1.0?