As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
When you are considering an upgrade in a development tool, how important is backwards-compatibility to you? Would you still purchase Visual Studio 2010 if it required significant changes to your source code? Where is the tipping point for you in terms of trading backwards compatibility for new features?
While you asked this from the point of view of the developer, I think it would be a more interesting question in reference to the software you develop. So I'm going to answer that question instead. :)
Hardware and software that's backwards compatible (and, more importantly, future-compatible) provides a sense of security to your users, especially when buying or upgrading platforms like Windows. If nothing else, Windows is known for its meticulous attention to backwards compatibility. You can run programs written over a decade ago on Windows Vista with only minor problems, provided they were "well written" (i.e. don't use undocumented APIs).
On the other hand, strict attention to backwards compatibility can tie your hands when you're attempting to introduce new features or to revolutionize the platform. Apple knew it had a dying OS, and in one of its most daring moves, it purchased NeXT and decided to make NeXTSTEP the new MacOS. One of the key things that sold people on the transition was the backwards-compatible layer Classic. Again when Apple decided to switch to Intel chips, a mechanism for running PowerPC apps on Intel called Rosetta, along with the Universal Binaries, allowed people to freely move between PowerPC and Intel without fear of application loss.
One interesting thing is that with the transition to Intel the Classic environment disappeared, but nobody really cares because they had the preceding 5 years to transition away from Mac OS 9. So it is possible to eventually drop support for legacy systems as long as you have an easy way to migrate to the new system and give your users ample time to do so.
In a development tool, if it doesn't provide total backward compatibility with my previous code, I won't buy it and I doubt anyone would. Frankly, there's no point. If I already have a compiler that works to build my source code into executable code that works for me, then I'll use that. Why bother changing my code to conform with what is obviously to the toolmaker not a standard? If they force source code changes from one version to the other, why would they bother to make the next version compatible?
100% backwards compatibility with source is a requirement. The only situation where this isn't a total requirement is when the incompatible bits are extensions; i.e. API changes that are specific to the tool, such as Eclipse plugins, etc. Even then, I'd like compatibility, but I realize that it can't be completely expected. But if you provide an API for base application / tool development, and can't be bothered to maintain compatibility; well, then, you clearly aren't serious about your tools, and I won't pay serious money for them.
For home projects, backwards compatibility really isn't important. For the office/enterprise, it's absolutely critical.
It depends on what environments you need to support and what third-party tools are used that may or may not be compatabile.
For example, where I work we upgraded everyone to VS2008 from VS2005 except for our BI group as the SQL Server BI tools were not compatible with VS2008. Once they were updated, they upgraded to VS2008.
When looking at VS specficially, keep in mind that VS2008 can target .NET 2.0, .NET 3.0, and .NET 3.5. The trick is to realize that it actually targets .NET 2.0 SP1 and .NET 3.0 SP1. As such, upgrading the IDE should not require you to make changes to your code.
In genreal if you are developing a platform which will be constantly used by a lot of other users to build their own products, and you plan to develop the application for a long time then it is important. See the PHP, Python, Eclipse and other open source projects who put a lot of importance into backwards compatibility. It is also importan when developing services or other open apis used in the n-tier architecture. You can have all applications in an enterprise breaking all the time when you change your services.
Now, If you are building a shrink wrap application or a bussiness application then it is not so important, beacuse each version is separate from its predecessors.
Since lot of changes are happening in the Software and Hardware field, I think it is a good idea to be open for new changes and better tools while you architect your solution. For example we didnt have multi core processors and high end graphics cards or network card back in 90s, So naturally the optimization goals of the compilers and tools were different. But at the same time Visual studio like tools are doing their best to accommodate the old frameworks and apps.
I think if we are looking forward for a better world, we should be open to a constant change until this industry is super matured. (May not happen in our life time though :) )
Define "significant changes". I'd go for it if the changes could be made with a carefully crafted "search & replace" even if they were extensive.
However, that's what I would do. Any company I've worked for would balk at any changes to existing code.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 13 years ago.
I am currently working in a .Net project but from university I have also a good background in Java. Recently I am asking myself, if multi plattform languages (like Java, or VM based like Scala) aren't on the rise?
Lets have a look at Suns WORA write once, run anywhere principle, which had been rephrased to write once, TEST everywhere because in the past especially desktop applications were/are still a Windows domain. But the last years there were quite some changes like
Linux has improved hugely in driver support and usabilty
Mac OS is getting even more popular
native look & feel thanks to SWT/JFace for Java
Rich Client Frameworks (RCP and Netbeans) that save a lot of time and provide rich experience
So, creating applications targeted on multi plattforms should be a reasonable way to go. For example, why should a small/mid-sized company pay a lot of money for windows/mac when it can use Linux (honestly, when you are not a gamer you dont need windows ;) ). And of couse then those companies would prefer software that runs on their machines (maybe the CEO a has MAC because he can afford it but needs the same apps.) Eclipse RCP can provide for example and then it really is WORA.
I like working on C# right now, but in 1-2 years when I want to have my own little company I will use Linux and the development will probably focus on what I've just written. I just wanted to know what others are thinking (maybe I change my mind).
Please don't start a war on Linux vs. Windows vs Mac (I use the first two). Its only about if multi-plattform is a good way for the future, or if you gain more by the advantages of a single platform (special features).
I work for a Qt consultancy company that's been writing multiplatform applications for a few years and I work on KDE's port to OSX and previously at a company providing a client for Windows/Linux/Mac.
The obvious benefits you get from supporting multiple platforms are:
Goodwill from niche communities (including blogging, word of mouth support)
Your developers can work on whatever platform they like so you can recruit them more easily
Your application will probably be slightly less buggy as you'll be testing on multiple platforms
The downsides:
Packaging/distribution/support becomes a big of a pain
Some platforms can get easily neglected
You don't tend to hook into the backend features of the OS as well
If writing a GUI application then you tend to end up with something that doesn't really meet the HIG of any platform unless you have quite a lot of platform-specific tweaking or have a toolkit that helps with this (e.g. Qt)
I still think it's worthwhile and agree with you that it's the future of applications. Really, there is enough good, high-level technologies that there's no need to limit your market to a single platform's users and Linux is a huge in emerging markets so being able to run your application there will be more and more important as time goes on.
Cross-platform solutions I've seen used to good effect:
Adobe Air
C# (with .NET or Mono)
Qt
Java
Web applications (obviously)
Yes, this is happening, but it's a very slow process.
You can trace the trend back to the UCSD Pascal P-system from the early 80's. In the 90's we got the JVM, and in the naughties we got the CLR. These newer VMs each support many languages from third parties. Python, for example, has long had its own VM, but also comes in a version that runs on the JVM, called Jython, and another one that runs on .NET's CLR, called Iron Python.
Other VMs exist that are targeted by multiple languages. The Parrot VM was created initially for Python and Perl 6. The Reia language runs on Erlang's BEAM VM. I'm sure there are other examples.
On top of that, there are many languages that have been cross-platform for a decade or two, like Smalltalk, early versions of Perl, Ruby, etc.
This is all a kind of long-term tectonic shift. It's driven by the fact that computers are getting faster, while many tasks we use computers for don't need to get faster. So, we can use high-level languages to write programs to do these tasks, where it wouldn't have made sense in the past. In the early 80s, the successful new word processors were written in assembly language. In the 90s's, C. Today, Javascript.
Check out mono http://www.mono-project.com/Main_Page if you like C#
Use SWT (http://www.eclipse.org/swt/) if you prefer java
YMMV
If you are going to spend hundreds of thousands (or millions) of dollars developing an application, it makes sense for it to be capable of running on as many machines as possible. Just a few years ago, platforms had many platform-sepcific features, but that distinction is rapidly disappearing with the availability of cross-platform compilers like Mono.
All depends of the activity domain of the software that you develop...
If end users are or plan to use multi-pateform so you must care about it ! If not, you can develop on the plateform used by your customers !
Of course, some peope would say : even if all customers are on Windows, the development is more productive on MacOS... but it's an other question !
In general, your users will generally prefer an app that looks and behaves like a native application. Many of the cross-platform frameworks are really very good at emulating the native look and feel. Just be aware that if your app doesn't feel native (maybe through some quirk in your toolkit of choice), critics will beat you over the head about it forever.
Also, The issue of using cross-platform toolkits really depends on the application domain you're targeting. For example, if you're working with video, creating a cross-platform app with a good user experience is very, very challenging. On the other hand, CRUD (Create-Update-Delete) apps commonly used inside of enterprises are excellent candidates for developing with cross-platform languages/toolkits.
Also, one reason that Java is very popular for applications deployed inside of enterprises is the ease with which you can deploy updates (via Java Web Start - I think C# has a similar update technology too). However, once you step outside of the walls of the business most users will shy away from Java Web Start apps.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have noticed some developers picking up new skills and moving from one platform to the other? How do they do it? How do they justify for the lack of experience in the said platform they get the job?
Is it based on relevance to their previous experience? do they get certified in the target platform and work at a junior level accepting a pay cut? is it simpler if you are into contracting/consulting? Or is it simply a matter of projecting the resume correctly?
Actually, a lot of seemingly different platforms are really very similar, if you understand what goes on "under the hood," as it were. Though I've barely touched a Microsoft platform for well over a decade, for example, I have little difficulty developing things there because deep knowledge of computer systems in general is quite transferable.
For me, moving from LAMP to .Net was a work necessity. The consulting company I work for needed a PHP guy right away which is how I got in, but that project completed abruptly and they did not have an PHP work on the horizon.
In the closing weeks of the PHP project, I took an online O'Reilly course in C# and worked closely with a more experienced developer on a Windows application for the same client. Once the PHP gig completed I was able to start right away on a .Net project and I've had .Net clients ever since.
The key for me was flexibility. I let my employer know immediately that I was interested in different technologies and platforms and have taken the initiative by requesting access to courses and taking advantage of our yearly book allowance to explore different areas. When opportunities arise for investigating new directions like Mobility (PDAs, specialty devices and tablets) I jumped at the chance.
If your employer doesn't have policies which promote this type of self-directed expansion, then try to build a type of application you are familiar with in a new platform. Once you have you have a decent grasp of the tech, get involved with open source projects in your target platform and look for paid outside opportunities (i.e. Craigslist, elance, etc.) while you are still learning.
Most likely it is a result of circumstances. In these touch economic times being able to move outside your comfort zones is crucial
I really haven't seen a lot of reluctance on anybody's part to put developers on platforms that are new to them. Changes in computer language tend to be far more worrisome to managers than platform changes.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Our group is currently reviewing our toolset and looking for new defect/issue tracking software in additional to source control, and project management software.
For issue tracking, we've looked at bugzilla, fogbugz, bugtracker.net, sourcegear fortres, and bugnet.
I'm not satisfied with the list we've come up with, so I'm curios to know what others are using.
We're looking for Active directory integration for security, although we'd settle for a windows app, a web interface may be preferential, visual studio integration is also a bonus. We need to prioritize defects, mark the version the defect was found in, mark the version the defect was fixed in, and hopefully be able to maintain a discussion around each issue/defect. We'd also like to categorize items as defect, enhancement request, etc. and document workarounds for defects.
Very similar question:
https://stackoverflow.com/questions/101774/what-is-your-bug-task-tracking-tool
Try Unfuddle. If you use their version control hosting (SVN and Git options) with their issue tracker, you get some good integration stuff going on. For example, you can enter a note in your commit message such as "fixes #384: Too much foo in the bar"*, and you not only get that turned into a hyperlink to the issue, but it also marks the ticket as fixed with a link back to the changeset. All good stuff. This is a web-based solution that is hosted by Unfuddle themselves, in a SaaS-type fashion.
Other than that, +1 for Trac which I've used in the past and like very much. It's quite an immature project feature-wise, although it's got a very healthy community around it that has developed plug-ins to do a lot of extra stuff (like the AD authentication you wanted). It also has similar integration with a number of source control systems, but it's much less feature-rich than the Unfuddle stuff. That is to say, you get to use an extended wiki syntax in your commit messages which is parsed by Trac when it's display to create links. It doesn't do any of the two-way stuff that Unfuddle does. Trac is available to host in-house; alternatively, if you want it hosted, there's a list of places that will do so on Trac's wiki.
*I can't remember the exact format off the top of my head.
On our current project, we've amazingly used 6 different tracking tools (2 versions of PVCS), mostly commercial. Here's my opinion on the ones that we've used. I've listed them in order of my most favored to least.
Serena Teamtrack - We use a web client. The interface is intuitive. Performance will vary across installations, but comparing with our same data in each tool, this works the fastest. It also works in Firefox.
HP Quality Center - This is also web based, but it is IE only. On the upside, it's well organized, easy to use, and full-featured. It has reasonable performance for us as well.
It has an odd feature where there isn't a save button. It saves automatically for you. To force a save, you have to navigate to another ticket. Also when you first use it, it has to install so many DLLs that it is practically a thick client. That being the case, IE sometimes gets locked up (usually when trying to reinitialize a session after session expiration). Once locked up, you occasionally have to kill IE to regain control.
Bugzilla - I didn't use this as thoroughly as the other tools, so this isn't a fair comparison. We used it briefly for some internal tickets. I suppose the big upside is the (lack of) cost. IMO, I just didn't find the interface as nice and easy to use as the other tools. Its been awhile so I apologize for lack of specifics for why I'm relegating it below the others.
Siebel - There wasn't much to like about their defect tracking tool apart from that it is better than PVCS. The interface seems hokey. It's as if the Siebel interface has a set of user interface controls and it tries to force all square pegs into its round holes. Another downside is that it uses lengthy generated IDs so its hard to reference them or search by them. Along with that, the ticket IDs aren't sequenced.
Merant PVCS - We had separate databases and used both the web client and thick client. Its been awhile now, so the details are fading. I recall there were bugs in the tool and they weren't getting fixed, for instance reports couldn't display certain fields. Performance was bad. It took a long time to load. It was slow to navigate through tickets.
Issue tracking for support is a different problem from tracking issues during development.
Trac http://trac.edgewall.org/ is a very capable tool which supports a number of large open source projects. You can find Trac hosting at places like http://www.wush.net
If you need more workflow and custom security, you'll want to look at JIRA which is from Atlassian http://www.atlassian.com. Atlassian has a number of products which you might also find useful.
For Issue tracking in a support setting, try RT http://bestpractical.com/rt. RT is deceptively simple, but I've seen it used in the largest environments and it does a good job making sure you are accountable to every you make a support commitment to.
An off-site (www) hosted solution with all the features you mentioned is NetResults Tracker
We use bugzilla, it suits us perfectly. We haven't investigated too many others because honestly it does everything we need and then some.
We don't use Visual Studio so I can't speak for integration compatibility.
Try out HappyFox ( http://www.happyfox.com), an issue and bug tracking software. The clean interface and automation features help you track and resolve bugs smoothly. HappyFox is free for a 2 member and priced economically for larger teams.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 13 years ago.
Improve this question
... or
How can I convince my organization to ditch Internet Explorer 6?
Having to maintain Internet Explorer 6 compatibility when developing web applications is a nightmare - but until my client decides to ditch it as the official browser, I am stuck with it. I am trying to convince our system administrators to change. I've seen a long list of arguments against using Internet Explorer 6 in any environment, and I am trying to anticipate their arguments rebuttals.
So far, the only perceived advantages I can see in Internet Explorer 6 are:
Central management through group policies
Legacy application compatibility
Both of these are addressed by Internet Explorer 7 or later (AFAIK).
Are there any advantages that Internet Explorer 6 has that are not already addressed by Internet Explorer 7 or later?
Internet Explorer 6 has been around for ages, and the vast majority of websites and web applications work correctly with it.
In order to change to a different browser (which, BTW, will probably be Internet Explorer 7), you need to, first of all, do a cost benefit analysis to justify this decision to everyone's bosses.
A really high level summary:
Cost:
Test all web applications.
Check all third-party websites actually work in the new browser.
Check all other software, to see if there are any underlying issues with moving to a new browser.
Benefits:
Multi tabs?
Honestly, I can't see this happening, unless a corporation is doing a desktop refresh which happens periodically.
Why bother changing if IE does what it's supposed to do: browse the internet. The so-called benefits of newer browsers, which to us actually mean something, have little to no value in the minds of the people who run the corporate environments you describe.
In other words: ignorance and/or apathy
I wouldn't exactly call it a "favourite" among any organisations. In my mind, it's simply that large companies consider it a big effort to upgrade everyone to IE7 (or in fact IE8 now that it's recently been released). It's a benefit versus cost decision that many executives seem to think has the simple answer that it just doesn't matter to the business. This may even be the truth in many cases if there's no system set up for automatically upgrading the (possibly vast number of) computers on the network. Many people (including myself) would argue having even a moderately decent browser (i.e. IE7 onwards, Firefox, or Safari) is would be a worthwhile thing for any business. The fact that IE8 has just been released, which now makes IE6 outdated by two versions is certainly going to encourage companies to start upgrading. The problem here is that as long as there's a significant market share for IE6, the vast majority of web designers are going to keep on designing sites to be compatible with IE6, regardless of it's poorness as a browser. Finally, if you're really keen on getting everyone to upgrade from IE6, I ought to point you to the Stop living in the past website. Perhaps if you campaign strongly enough within your organisation, you may just convince the people who make the decisions to upgrade, though I wouldn't like to bet on it...
The switch from IE6 is a painful one, because they would have to apply it to every single computer in the company.
Depending on the number of exployees, that becomes a logistical nightmare.
Also, they will commonly use whatever browser comes with the default install of the OS they use for new computers.
Changing default programs introduces unknown risk, and the benefit of switching must outweigh that risk. Currently the hassle of attempting to upgrade every single computer probably outweighs the convenience of having a better browser, especially when most of the users will not take advantage of any of the new features.
Unless they find any strong business case or advantage I don't think a company will agree to spend time on upgrading. What is the use? Also Internet Explorer 6 is little faster than the new versions and business users (who don't care about the version as long as it does the job) may complain.
If you are a developer then you have the reason to have all/latest browsers installed.
I thought mine was the only one to use Internet Explorer 6 ;-)
We actually have a bunch of legacy applications on our intranet, some written in house, others that we quite a lot of money for, which don't work well on IE7 (or IE8, or Firefox, or Safari, or ...)
Yes, Mercury, I'm looking at you...
IE6 market share is rapidly dropping, so I'd expect that in a year or so authors of AJAX UI libraries will stop testing against IE6 (just like now they don't test against IE5.5). When that happens corporations will have no choice, but to adapt.
What are the compelling features of MFC? Why would you select it for a new project?
MFC was a good option 10 years ago. It is still a good wrapper over Win32 API but unfortunately obsolete.
Qt is a better option with one big advantage - it is platform-independent. With MFC you're doomed to Windows.
I still use MFC for all kinds of applications. MFC got a bad rap from it's early implementations, but it is excellent now. I find it quite a bit more convenient than WTL as well. Plus the GUI tools in Visual Studio are already setup to make it easy to rapidly develop GUIs with MFC, mapping controls to variables, DDX, etc.
For desktop applications that I intend for wide distribution I still go with native Windows applications, usually in MFC, because we're still not at a point where you can depend on your customers to have the version of .NET that you'll be using installed and asking them to install it will cause you to lose sales, not to mention the customer service headache when they run into problems installing .NET as a result of trying to get your app to run.
The advantage of MFC is that it's still nicer than coding to bare win32 and you can distribute a native .exe that doesn't require a 23-50Mb runtime like .Net.
Now, if you're concerned about those things there are better alternatives out there: C++ Builder, WxWidgets, etc. But some places won't consider non-Microsoft tools.
You could sort of reword the question, why would you select C++ over C# for a desktop app. C++ still offers speed advantages which matter for some applications (I work for a company that creates software for electronic trading. Speed matters a lot).
If you are going to develop a desktop app aimed for Windows only in C++, then MFC is the most mature choice, with lots of free code based on MFC on the internet, lots of knowledge.
Apart from win32 api itself, MFC is the only mainstream Windows programming technology that is still alive and well in 2011 after 15+ years. Back in 2001 everybody said 'MFC is dead, it's all Winforms now'; in 2005 everybody said 'MFC is dead, it's all XAML now'; now it's 2011 and Winforms and XAML are dead (OK XAML maybe not really dead, but way past its prime) and MFC is still being updated with the latest developments (ribbon, Aero extensions, Win7 API's etc).
Of course, that doesn't guarantee anything for the future, but over those 15+ years, a lot of MFC code written, and it will remain in use for the next decade or decades. It may not be the prettiest tech but it's well-understood (its good and bad points) and is not a moving target like other hype technologies are, meaning that people who actually want to get stuff done can sort of rely on it (well more than on the alternatives, anyway).
(same goes for C++, btw)
Here's a possibility - imagine an application that would require a large amount of memory, say a graphics program, a game or maybe some high performance business application. It's no secret that .NET applications hog memory - in such a case, you may want a lean MFC app for the core of your application. You can always load up and use .NET components, controls, etc through either COM callable wrappers or directly through C++/CLI.
That all being said - MFC is a pain. Consider WTL instead - you can still call into .NET if you need to, the same way as I mentioned above for MFC. WTL is a lot nicer than MFC :-)
Apparently it is still a good choice for applications for windows-based hand-held devices, such as point-of-sale devices. In these, resources are limited so things like memory management become more significant.
Quick Tour Of New MFC Functionality
I hear they have a new ribbon control. If you're into this sort of complexity. Here's a screenshot of a newly generated app:
(source: msdn.com)
Really, it's just a widget update. So do we need more widgets?
The existing windows API is entirely C based. If you want to use C++ (and you probably should) then MFC is the logical choice if you wish to stay native (i.e. not using .NET).
MFC is just a set of object-orientated classes over the top of the C API. Plus quite a few additional "helper" classes that make it easier to do everyday tasks.
I think not.. MFC would lose out in
Level of abstraction
Development Time
Troubleshooting time
Learning curve for new developers
Future proofing (although now that's questionable.. with something new coming up every 3-4 years)
Finding good people who know their MFC
Easy to use controls
The only place where MFC would probably sneak past is if you have some very performance intensive applications like you have things on screen that need to be redrawn every 10 msec or 1 sec. "Managed" apps still haven't managed to jump past that hurdle.
MFC was an important step in the evolution, but now better options are available.
On design & technical merits alone? Sorry to be categorical, but none. It's a poor design, a hugely leaky abstraction where you have to fall back to Win32 API programming, misuses C++ egregiously, and is firmly targeted on yesterday's technology: you won't get a modern (or even an attractive!) user experience out of an MFC app. If you can get C# developers and you don't have serious hardware limitations, go with WinForms.
External factors such as the availability of competence for hire, training programmes and third party components, on the other hand, can still extend its lifespan, at least for some kinds of applications: small & simple, targeted for special applications with reasonably few users, preferably in-house.
If you are developing Windows CE and mobile apps in C++, as Einar has already mentioned, MFC is a good choice. If you make this choice, MFC then also becomes a reasonable choice for the desktop as you can use the same code across desktop and hand-held devices. MFC remains a good perfomance / easy to implement combinitation in this scenario. Personally, I use MFC in conjunction with Stingray libraries in these enivornments which gives a very good interface, good performance and is quick and easy to implement.
I would say that speed and footprint are good reasons over .NET.
It's probably true that you'll find it difficult to locate good MFC programmers, but thats just as much because the modern languages promote lazy programming techniques and most programming courses gravitate towards them as they are easier to teach.
I've written cross platform code for years so when I need to write something I always have a very thin abstraction layer between it and the system calls for almost everything except posix calls. That way you can code it go MFC but quite easily convert it a different API later if needed. My base set of c++ libraries that I use for everything does this with a small System class. I currently have it using MFC for Windows and I also have it using XWindows for Linux and a native Mac version as well. And later on when I port it for a handheld it should be quite painless.
If you want to take a peek, it's LGPL'ed and is at:
http://code.google.com/p/kgui/