First off, let me thank Dubya and the remainder of the inexplicable idiots once again for the passage of the Energy Policy Act of 2005. Not only does this further line the coffers of the oil industry, but it also includes the asinine provision of moving the Daylight Savings time switch up three weeks. Why? Because people will supposedly be awake for more of the daylight hours, so they'll use less lights at home to see.
Let's just take a second to let this stupidity sink in.
Evidently Congress believes they can will the sun to stay out longer during the day. Not only that, but this idea has actually been tried in Australia during the Sydney Olympics. The result? A greater spike in morning electricity usage. Great job.
So not only does this not save energy, it completely screws with every computer in the known freaking world. I've been running ragged trying to patch a number of legacy servers, some to no avail, because they all expect the first week in April to be when DST changes happen. The past two months have been a sleepless blur. Now servers both at home and abroad will be off by an hour. International financial transactions are most likely to be at risk, since foreign DST changes will be different and servers are likely to go unpatched. This may cause enough disruption to make the so-called Y2K bug absolutely minuscule in comparison.
So nice job Bush Administration. Not only do you ignore things that might actually make a difference such as the Kyoto Treaty, but you pass bills that actually harm both the environment, business and industry and then call them "energy policy acts." Brilliant.
Monday, March 05, 2007
Tree on my Table
While I'm deciding on if I should just trash this whole "indy developer" routine I made such a horrible attempt at, I decided to dedicate more time to ConsultComm development.
Desktop integration with Java has been, and continues to be, horrible. It is slowly getting better, but even basic elements are absent or work terribly. The system tray icon works, but isn't any more polished than when it was an incubator project with the JDIC. Now, I'm not trying to be critical of the original System Tray author - he did a fine job. I just expected Sun to make it actually 100% usable.
One thing people have always expected to have was a tree layout for the windowing toolkit with multiple columns for each row. It's not a new concept - TableTrees are in nearly every file browser out there. But for some reason Swing just hasn't had it. Sure, there have been Sun-created articles and tutorials, but no official components. I made one for ConsultComm and have since attempted to make it into a stand-alone component, but it's a good deal of work.
Supposedly the table/tree is making it's way into JSR 296, but those can take a while. I doubt we'll see it soon.
You may notice that I wrote a JDIC component back in the day - SystemInfo. I initially just wanted to donate the code and be done, but was encouraged to make an incubator project out of it. I did so, but quickly became frustrated with Sun's collaboration & project repository Web application and just gave up. Hence the current unusable state the project is in. It appears Sun has now made a separate... something alongside the JDIC mess called "SwingLabs." All the links seem to run in a circle between the JDIC project repository and the SwingLabs site... so I'm not precisely clear on their relationship to each other. But it appears SwingLabs is trying to "productize" or at least "centralize" the disparate desktop components and APIs into a single, coherent package.
In SwingLabs' main package called SwingX they have a new component called JXTreeTable that appears to offer the basic functionality originally put forth in way back in 2003 (probably earlier) with Philip Milne's article. It's fairly basic, but I'm attempting to integrate it into ConsultComm. Relying on a (hopefully) more stable and independent UI codebase should accelerate development. Who knows? I may just fix up SystemInfo if I am able to glean the time. Then again... maybe not. Doing desktop integration via JNI is an insane headache.
Desktop integration with Java has been, and continues to be, horrible. It is slowly getting better, but even basic elements are absent or work terribly. The system tray icon works, but isn't any more polished than when it was an incubator project with the JDIC. Now, I'm not trying to be critical of the original System Tray author - he did a fine job. I just expected Sun to make it actually 100% usable.
One thing people have always expected to have was a tree layout for the windowing toolkit with multiple columns for each row. It's not a new concept - TableTrees are in nearly every file browser out there. But for some reason Swing just hasn't had it. Sure, there have been Sun-created articles and tutorials, but no official components. I made one for ConsultComm and have since attempted to make it into a stand-alone component, but it's a good deal of work.Supposedly the table/tree is making it's way into JSR 296, but those can take a while. I doubt we'll see it soon.
You may notice that I wrote a JDIC component back in the day - SystemInfo. I initially just wanted to donate the code and be done, but was encouraged to make an incubator project out of it. I did so, but quickly became frustrated with Sun's collaboration & project repository Web application and just gave up. Hence the current unusable state the project is in. It appears Sun has now made a separate... something alongside the JDIC mess called "SwingLabs." All the links seem to run in a circle between the JDIC project repository and the SwingLabs site... so I'm not precisely clear on their relationship to each other. But it appears SwingLabs is trying to "productize" or at least "centralize" the disparate desktop components and APIs into a single, coherent package.
In SwingLabs' main package called SwingX they have a new component called JXTreeTable that appears to offer the basic functionality originally put forth in way back in 2003 (probably earlier) with Philip Milne's article. It's fairly basic, but I'm attempting to integrate it into ConsultComm. Relying on a (hopefully) more stable and independent UI codebase should accelerate development. Who knows? I may just fix up SystemInfo if I am able to glean the time. Then again... maybe not. Doing desktop integration via JNI is an insane headache.
Subscribe to:
Posts (Atom)