December 21st, 2010
Over the past 6 years I’ve hosted a number of my open-source projects on Java.net. Over the last two-three years the site admins kept talking about moving the hosting forward, enhancing both the visual and the backend functionality of the site. I have no insight into the complexity of the existing infrastructure and the amount of resources available. It thus thus be foolish – and pointless – to speculate on the reasons for the glacial pace at which things are happening.
After a lot of promises, early November brought the rather hostile announcement (emphasis mine):
This is an opt-in migration – we have thousands of junk, test, and abandoned projects on the site and we intend to leave them behind. Any project owner can request that we move their projects, and any community leader can request that we move specific projects in the community. Any project that is not specifically requested by name via the opt-in form by November 30, 2010 will be purged when the CollabNet site goes dark. We will be keeping tarballs of the CollabNet contents and will be able to distribute them after the site goes dark, however projects that request migration are our top priority.
Aptly named “Move it or loose it“, this is quite a threatening statement that makes not one, not two, but three direct references to the projects that will not opt-in to the migration. Even though i’ve put the development and maintenance of my projects on hold, i still want to have the sources, binaries, documentation and the source history available for interested developers. And so i promptly added all my projects to the opt-in form.
Fast forward three weeks after the deadline date. A couple of days ago a comment was left on my blog (thanks Eugene) – Substance look-and-feel is nowhere to be found. It’s no longer at substance.dev.java.net and certainly not on the new java.net/projects. Let’s look at my new profile page that lists some of the projects that i asked to migrate. Looks like java.net/projects/substance is the winner, except that it leads to an error page. Most of the project links on my profile page lead to errors, and some lead to the subset of the original content. Every page takes minutes to load, and i have no idea if the old forum postings and binaries will ever make it through. Top priority indeed.
So here’s the deal. Over the next few days i will upload all the sources, documentation and additional materials to my GitHub page. However, it will be up to you to build the binaries, run sample applications and browse the downloaded documentation. I simply don’t have time to untangle this horrible migration mess that was unilaterally forced on me and my users.
And yes, i know that Java.net was a free service, and that the same exact thing may happen to GitHub in five years. I’m not that naive.
August 9th, 2010
I’ve just published the final releases for the following projects:
Flamingo 5.0 release contains:
- New scroller panel component
- New color selector popup
- Full right-to-left (RTL) support
- Toggle menu buttons
- Dock icon for ribbon frame on Mac
- Dynamic resize of ribbon components
Substance 6.1 release contains:
- Platform specific keyboard shortcuts
- New Mariner skin
- New Office Black 2007 skin
- Better visual integration in Substance Flamingo plugin for ribbon under all core Substance skins
Trident 1.3 is mainly maintenance release with a few minor API additions to the repaint timelines. Flamingo uses Trident for some of the animations, and you will need to add the latest Trident jar to the classpath. If you’re running your Flamingo-based application under Substance, add the latest Substance Flamingo plugin jar to the classpath for consistent visual appearance and animation effects.
Here are a few screenshots of these libraries in action. New Mariner skin in Substance:
New Office Black 2007 skin in Substance that is targeting the Flamingo ribbon component:
Scrolling support for Flamingo popup menus:
Color selector popup for Flamingo command buttons:
Full right-to-left support in Flamingo ribbon:
July 22nd, 2010
I’ve just published the release candidates for the following projects:
Flamingo 5.0 release candidate contains:
- New scroller panel component
- New color selector popup
- Full right-to-left (RTL) support
- Toggle menu buttons
- Dock icon for ribbon frame on Mac
- Dynamic resize of ribbon components
Substance 6.1 release candidate contains:
- Platform specific keyboard shortcuts
- New Mariner skin
- New Office Black 2007 skin
- Better visual integration in Substance Flamingo plugin for ribbon under all core Substance skins
Trident 1.3 is mainly maintenance release with a few minor API additions to the repaint timelines. Flamingo uses Trident for some of the animations, and you will need to add the latest Trident jar to the classpath. If you’re running your Flamingo-based application under Substance, add the latest Substance Flamingo plugin jar to the classpath for consistent visual appearance and animation effects.
The final releases for all the projects are scheduled for August 9. Only bugs will be fixed until that date.
June 6th, 2010
Trident aims to be a general-purpose animation library for Java applications. However, most of the time people talk and refer to animations in the context of pixels on the screen, be it for transitions between different states, rollover effects, smooth scrolling of large content and what not. Trident comes with built-in support for Java based UI toolkits. The three UI specific requirements are addressed by the core Trident library:
- Automatically respecting the threading rules of the UI toolkits
- Providing property interpolators for classes that represent graphical objects of the UI toolkits
- Repainting application windows that have continuous animations
Today i’m going to talk about the last point – repainting application windows. Trident has two special timelines – org.pushingpixels.trident.swing.SwingRepaintTimeline and org.pushingpixels.trident.swt.SWTRepaintTimeline. These are simple utility timelines that can be used to continuously repaint the contents of the specific window / component on every timeline pulse. For example, if you have a continuous emulation of fireworks, you can have “worker” timelines updating the model objects that represent the firework volleys, and one repaint timeline that updates the entire screen based on the current state of all firework volley model objects. This allows you to separate the model updates from the view updates.
However, as Rob Eden pointed out to me this week, these two classes repaint the window / component on every timeline pulse. This can result in unnecessary repaints if the model updates are not done on every timeline pulse as well. In the “snake” example, the model is updated only when the mouse is moving. Once the mouse has stopped moving and all rollover timelines are done, there are no changes to the model, and continuously repainting the screen consumes unnecessary CPU resources.
To address this, both SwingRepaintTimeline and SWTRepaintTimeline now have three new APIs:
- setAutoRepaintMode(boolean) – by default the auto repaint mode is true. Application that wishes to control the repaint will call this method with false.
- forceRepaintAtNextPulse() – will make the repaint() / redraw() call when the next pulse is fired. This will throw an exception if the timeline is in auto-repaint mode.
- setRepaintRectangle(Rectangle) – allows to dynamically change the rectangle to be repainted. Can be used if the bounds of the view that represents the specific model can change dynamically (e.g. when the user resizes the application window).
The snake examples for both Swing and SWT have been updated to show the recommended usage of the first two APIs. Click the button below to run the WebStart version of the Swing demo:
If you’re interested in testing this functionality in your application, take the latest 1.3dev drop (code named Diamond In The Sky) for a spin.
Thanks for stopping by. My name is Kirill Grouchnikov and I am a user interface engineer. I currently work at Google on the