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…
I don’t think we should force old users. But completely new ones. Why not. Luna was selected to resemble old Synthetica skin from 2.5.8 version. This was way long ago, so maybe we shouldn’t be so attached to that old striking blue theme.
please open an issue for the patch and move it into the community trunk.Let’s see, if we can get some response by users abuout. I’ll do a small test in my dev team.
The ticket is already there SPARK-1539, though it has two patches. One for Substance update and one changes how Spark applies new skin (it restarts Spark). I think they should have two separate tickets.
I’ll split those out to two separate tickets when I get home tonight. I was refering to a patch that preps for a next release (cleanup version numbers, etc).
ok. i split out the two patches to their own tickets. SPARK-1539 of the (in)substance patch/update and SPARK-1544 which is still a wip. SPARK-1538 is another library update from the (in)substance project - the Trident library that handles animations and what-not. SPARK-1539 and SPARK-1538 should both be ready for testing in the Trunk and beta builds, however I do not have commit access to push it in. Perhaps you or someone with commit access could push them to Trunk? Thanks
I’ll ask Tim Jentz to review and apply, if ok. Please make sure that the LaF related issues are flaged in Jira with the componentn “Look and Feel”. It helps to get those things tight…
