Updated things to the latest release of Substance LaF which has been taken under the Insubstance project. Current version is 7.2.1 released about 7 months ago. The project is currenrtly looking for a new maintainer, so whatever that will mean. I know we are possibly looking to stip Substance out… but perhaps an updated version will fix the previous issues? And some of it’s LaF’s do look good
Apply the patch.
Copy “substance.jar” to “~/spark/codebase/build/lib/dist/”
Enjoy
PS: You have to compile spark from source to get the updated Substance to work. Simply copying “substance.jar” over to your Spark installation will not do it. SPARK-substance-7.2.1-Update.patch.zip (1085 Bytes) substance.jar (1945681 Bytes)
I never found the time to look into this (Insubstantial) I think we can still have a ticket for this in JIRA. We can close this later if not needed. I will try to test few issues existing in the current Substance skins. SPARK-1538 is related to this?
First impression is that Spark starts faster with updated Substance skins. Probably just my imagination Also i see that some skins have prettier rounded corners, though they are rather rough (pixels seen), but that’s ok. Also input fields changed, but no drastic changes (at least in my favorite BlueSteel skin).
I have checked one issue. With older Substance skins file transfer progress wasn’t shown correctly and the were no Open and Open Folder links shown after the transfer. Seems that 7.2.1 fixes that.Of course it is still impossible to quickly go from Substance skin to JTatoo. Spark freezes after pressing Apply. Have to press Save and restart Spark. If i remember other Substance related issues, will check them later.
Btw, after your patch, spark defaults to some JTatoo skin, but not the Luna. Also i have tried to apply 1538 patch later and there is a conflict about versions.txt file, because i have already applied 1539 (substance 7.2.1) and it have changed this file.
SPARK-1538 was created to update the Trident (animation) library in Spark… it’s part of the Insubstantial project as well now, so might as well update while we’re at it. It includes a slew of bugfixes and the like…
Yes, BlueSteel looks very nice now, especially with those rounded corners! When sitting at typing distance from the monitor, the pixels on the corner aren’t as noticable, at least to me. Perhaps swing doesn’t have proper anti-aliasing or something, or just not implemented in this version of Substance. There have been quite a deal of closed tickets [in Substance project] that regard fixing memory leaks and what-not, so performance and reactiveness should have improved. I’m hoping someone picks it up and keeps improving it.
Regarding the Spark freezing when switching from Substance skin to JTattoo skin… yes I’ve noticed the “Change Now/Apply” button causes a freeze. I’ve also noted that even in JTattoo, clicking the “Change Now/Apply” button does not always cause each window element to properly pick up the new theme (probably depends when they get redrawn in memory). Sometimes text highlight for example will stay on the old color scheme, or window backgrounds, etc.
Perhaps it may be worth making Spark auto-logout/back-in upon clicking the “Change Now” button in order to guaruntee all window elements reflect each LaF or Color change? This would make clicking the “Change Now” button expensive, but perhaps would make for a better UX since they wont get the freeze from Substance or partial LaF’s applied from JTattoo?
Stange on the default skin change. I don’t see anything in the SPARK-1539 patch file that would have changed this? I myself have been running the Fast LaF for a while and have gotten pretty fond of it… did it perhaps default to that?
And the merge conflict will be due to my current workflow… and I’m not sure how to get around it unless someone has a suggestion? Since I’m posting patches, then I don’t know which patches will be applied in which order, or if they will be applied at all (refactored, rejected, etc). So I can’t really continue to work from my working directory since then each patch would compound on the previous. Instead I’ve been making a new local copy of the Trunk and working from that to create each patch independent of each other. This will cause a merge conflict, but in Git at least it would be auto-resolved and merged. Does SVN not have this ability? Or should I change my workflow somehow?
And for everyone who doesn’t want to bother patching just to see the new Substance look… here’s BusinessBlueSteel with Spark main window on colored desktop background, and About Box on Spark’s inner white panel. As you can see, the White background color accentuates the pixels on the corners, but on a colored background, they aren’t noticable.
Yes, i think Change Now button should iniciate log out/login or Spark restart, but with a dialog warning about that, so people won’t use their current chats, etc. But what about Apply button. Well, maybe not many will press that when changing skins.
Actually it was Metal (first in the list) skin and skin selection was showing blank, so it probably went with the first in the list. After i have played with the compiled Spark version (i have set it to Substance BlueSteel), i have launched my common Spark client (uses same profile) and it also defaulted to Metal skin. It seems that on first launch after going to new Substance, Spark is not able to find something (old Substance skins? mabe the name have changed) and defaults to first one. Probably won’t happen to those who uses JTattoo skins.
Oh Ok, I think I see what’s happening here. The new Substance packages from Insubstance project have different names. So when you fire up the new version after you applied the patch, your user profile’s preferences are updated to save the new LaF package name. When you fire up your non-patched version, those LaF package names don’t exist… causing Spark to freak out and display the system default LaF.
Here’s a real ugly hacky patch to restart spark on new LaF applied. It may be worthwhile to review how we do the LaF change as-is. At an initial glance, if the “Change Now” button is clicked, it has a bunch of the windowing components in Spark refresh. Perhaps some get missed or fail for some reason… causing the noticed issues.
Anyways, this patch is horrible and shouldn’t be used by the casual reader. It just shows more-or-less how a forced restart of spark would work. hacky_restart_on_new_LaF.patch.zip (1581 Bytes)
This can only be applied if you are building Spark from source code. You would need to download the SVN Trunk from http://www.igniterealtime.org/downloads/source.jsp then apply the patch in my original post. Then you can copy the new substance.jar file to your source code’s build/lib/dist directory (replacing the existing one).
This is just an update to some of the theme’s Spark can do. It does add a few new untested ones. These are under review and there is no guaruntee of stability or anything.
Updated slightly less hacky patch. Works a bit better and UX flow is better… still needs improvement… but I’m tired and have work early in the morning! slightly_less_hacky_restart_on_new_LaF.patch.zip (2020 Bytes)
Thanks for the work on (in)Substance. It’s your decision to pursue Substance LaF. I just can restate that the team that did 2.6.0 development was at some point that unhappy about bug hunting Substance that we introduced JTattoo. Unless Insubstance significantly improved the code, I would assume that you will have numerous “hacks” to get it to work in Spark… I would rather consider to create JTattoo skins that look like the desired LaF than making (in)Substance work. Only my 5 ct…
I think I recall someone saying at some point that their company runs a custom LaF built off JTattoo… so perhaps it’s not that hard. Looking at Substance though, it’s quite the codebase… not sure if we’d be able to make JTattoo do some of the same things without major changes.
I took a gander for other possible LaF libs, and there aren’t really any others that are good or better than what we’ve got (besides those nice synthetica ones they won’t let us have!).
This fall I was going to try to organize a team at my University to attempt a JavaFX port of Spark’s GUI. This will be a massive undertaking and possibly can’t be finished in a semester’s time with volunteers, so no promises here (everything from spark’s SwingWorker impelentation to JOptionPane popups, to just about all threading and GUI components would need to be ported to the JavaFX framework). However, the new graphics libs in JavaFX 2.2.x+ are pretty nice and I find more responsive feeling and more modern/native-system looking than Swing programs (just based on my personal experience). JavaFX is “themeable” from good 'ol CSS too… so creating intricate designs should be easier and more possible. JavaFX is becomeing/has become the next gen java GUI library, and so far I like what I see. Anyways, I digress.
For the here and now, I’d support some testing of the new (in)Substance library integration, and if it does not cut the mustard, then we yank it for the 2.7.0 release (or 2.7.1 release if we want to try it out in a release for a short while… ). The version in the patch includes over 86 closed tickets in github’s tracker… many of which are bugfixes, resource usage fixes (mem leaks), and other tweaks.
Only problem is I"m unsure how to test the specific issues reported before… other than send myself some files on two instances of Spark and see if it works LOL. Integrating the new (in)Substance was reletively straightforward actually once I figured out Spark’s LaF engine… no “hacks” were needed. I never integrated Substance into Spark before, so I’m not sure if my process this time around was easier than it has been before. The Substance jar file is a custom jar which bundles laf-widget and laf-plugin projects into the same jar (they are needed by Substance and all now part of the inSubstantial project).
Can you name a few issues that required those hacks? Other than visial issue during the file transfer (which is working fine with the current Substance) i can’t remember anything significant. As Jason mentioned there were some memory leak fixes and other bugfixes. It seems Spark starts a bit faster now. JTattoo just looks so plain, imho, so having a choice is good. JTattoo is still here and still the default.
^ Although I still support a change of the default JTattoo LaF to something other than Luna – Luna looks too “Win XP” for me, and in an office with almost all win7 machines now (except a few win2000’s still kicking around… gah…), it looks out of place with the new Aero elements and what-not.
I think one of the silver-colored JTattoo LaF’s might be a good candidate for default… I’m partial to the Fast LaF at the moment (I rolled our latest internal release of Spark out with Fast as the default and no issues so far LaF related). I think a changed default LaF might be good for the next release… something visual that users will see and distinguishes it from previous versions that are now years old. I don’t like the highlighting text color of Aluminim otherwise that’d be my choice.
A silver LaF default would also be in-line with the direction Openfire has gone with their default UI scheme… tying the products together a little better.
Off topic – @Walter – I’ve prepared most of a patch to ready Spark for 2.7.0 release build (updated ant build script, version numbering, install4j files, readme files, etc. I don’t think we want to track those changes in Jira as an “issue”… or do we? Should I just post the patch in the forums or open a ticket for it… I guess that’s what I’m asking.
No, i don’t know the prepping for next version process, but i think Guus just does it in the SVN (version tags, etc.) and doesn’t create tickets for this. That’s for Openfire. But i don’t remember such things for Spark.
But even if the change the default skin, the ones using Spark already would still have Luna as default after the upgrade?
OK I’ll wait for Walter’s response before posting the patch to avoid any confusion…
Yes - upgraded Spark clients would still use whatever LaF is already set as default (either the defaulted Luna or user selected). We could probably build something in to force an update to the new defautled LaF on first Boot of new Spark if we wanted to… not sure if that’s good or bad from a UX standpoint…
