21–30 of 58 posts
I'm sure some day I'll love Client Apps again, maybe when Microsoft isn't killing the little guy.
Also, the knowledge required to deploy apps to each of your target platforms are fairly different, and tend to be developed to the exclusion of each other. A great Mac OS software engineer is unlikely to know Windows inside and out, and a Windows guru isn't likely to know or care much about Linux. Linux folks are, well, an altogether different bunch.
The idea often appeals to me but I quickly get turned off by the practical realities involved, particularly when getting the app to both look reasonable and work on several platforms. That said, I've been thinking about XUL/Firefox addons for some simple configuration things.
If you value your sanity, put the XUL handbook down and step away slowly. Of the handful of completely failed software projects I've worked on, most have involved XUL and the Mozilla runtime stack in some major way.
The complexity of XUL isn't worth it for the payoff, IMHO. Stick with something simple like Shoes or Tk, or go for Qt or WxWindows if you need a rich widget set. Don't let the fact that XUL looks kind of like HTML mislead you into thinking it'll be easy to build on and deploy.
Earlier quoted context omitted.
GUIs just aren't interesting to create -- there's nothing challenging about creating them. For desktop apps, the normal thing to do these days isn't even to code them -- you drag and drop together a UI in something like Glade, Interface Builder, or whatever Visual Studio packages, and hook up handlers to talk to the core logic. It's mostly grunt work. The same is true about web interfaces, of course, but they at leas…
> For desktop apps, the normal thing to do these days isn't even to code them -- you drag and drop together a UI in something like Glade, Interface Builder, or whatever Visual Studio packages, and hook up handlers to talk to the core logic. It's mostly grunt work... [t]he same is true about web interfaces... I wish it were true for web interfaces... something like balsamiq.com, but it would output html (or haml, etc.…
I have a number of years experience working with Tcl, and also a bit of Tk, which fits the bill nicely for that kind of thing. However... yeah, doing client apps is not "where it's at" compared to web apps. I never thought I would say that. Web apps were, once upon a time, sort of ugly and boring compared to all the cool stuff you could do with 'real' apps. But with things like Rails, and the ability to easily deploy…
GUIs just aren't interesting to create -- there's nothing challenging about creating them. For desktop apps, the normal thing to do these days isn't even to code them -- you drag and drop together a UI in something like Glade, Interface Builder, or whatever Visual Studio packages, and hook up handlers to talk to the core logic. It's mostly grunt work. The same is true about web interfaces, of course, but they at leas…
Oh, so very wrong. Yes, technically, the mechanics of making a GUI are not hard, but it's much like good technical writing. Deciding what goes where, what goes in, what stays, out; these are hard choices. Just look at almost any random shareware VB app. Fugly.
Earlier quoted context omitted.
GUIs just aren't interesting to create -- there's nothing challenging about creating them. For desktop apps, the normal thing to do these days isn't even to code them -- you drag and drop together a UI in something like Glade, Interface Builder, or whatever Visual Studio packages, and hook up handlers to talk to the core logic. It's mostly grunt work. The same is true about web interfaces, of course, but they at leas…
"GUIs just aren't interesting to create -- there's nothing challenging about creating them. For desktop apps, the normal thing to do these days isn't even to code them -- you drag and drop together a UI in something like Glade, Interface Builder, or whatever Visual Studio packages, and hook up handlers to talk to the core logic. It's mostly grunt work." Oh, so very wrong. Yes, technically , the mechanics of making a…
I got into programming via the games route, and until pretty recently, that meant to-the-metal C, C++ and the libraries close to the system. (and when I started to teach myself to program, I hadn't heard of the internet) I've always tried to stay on top with other tech as well though, including the web, and now that I've given up game programming, my consulting work is about 50% client-side (C/Win32, C/UNIX, C++/MFC,…
to add on: this is why i'm very happy with .NET. the overlap between web apps in ASP.NET and client based apps is large. no mac or linux, obviously. recently i've started building a small windows app again, and i've been so pleased by how quickly and smoothly it's been - even though it's been years since i've worked on a windows app.
when i first saw this post title - i instantly thought in my head, hey - doesn't rescuetime do that?! i absolutely love their product. i'd work for them in a heartbeat if my skillz were better.
i don't think client-based apps are dying, at all. if anything, rescuetime is showing that they are on the rebound. good work, guys.
Earlier quoted context omitted.
GUIs just aren't interesting to create -- there's nothing challenging about creating them. For desktop apps, the normal thing to do these days isn't even to code them -- you drag and drop together a UI in something like Glade, Interface Builder, or whatever Visual Studio packages, and hook up handlers to talk to the core logic. It's mostly grunt work. The same is true about web interfaces, of course, but they at leas…
"GUIs just aren't interesting to create -- there's nothing challenging about creating them. For desktop apps, the normal thing to do these days isn't even to code them -- you drag and drop together a UI in something like Glade, Interface Builder, or whatever Visual Studio packages, and hook up handlers to talk to the core logic. It's mostly grunt work." Oh, so very wrong. Yes, technically , the mechanics of making a…
Most coders simply aren't meticulous enough when it comes to interfaces. "Slap a button on the window" or "just throw an item in the menu" without thought are not usable solutions.
This is especially problematic in client-side software where marketing is only interested in bullet-point features. The accessibility and workflow behind these features tend to be suspect at best, downright unusable at worst.
I wish more coders would be interested in these things. The people I talk to about interfaces are either disinterested hackers who'd rather work on backend code, or artists with no conceptual grasp of the technical underpinnings of GUI. Ugh.