Proposal: Removal of Substance

Spark Spark Dev
1

I would like to propose to concentrate all development regarding the Look and Feel of Spark on JTattoo. Currently the code base includes Substance as second LaF provider. Substance is not maintened any more and causes functional bugs in Spark. This combination is IMHO reason enough to remove Substance from the code tree.

Together with the removal of Substance, the code should be reviewed for all hard coded images that break skining (lot’s of light blue stuff around) and adapt the code for maximum efficency with respect to JTattoo.

One word about the selection process for JTattoo. This LaF was selected during the 2.6.0 development push after discovering the bugs caused by Substance. The old LaF Synthetica instisted on a commercial license and was subsequently removed from the code base. JTattoo provided several “good looking” skins that went well with the hard coded images and provided good support during the integration into 2.6.0.

2

What about Insubstantial? It is a fork of Substance and updates are fairly recent (November), though it is only the maintenance updates as i get it, but maybe they will fix the problems there are. Btw, what are the problems with the current Substance in Spark? I understand that keeping one LnF is easier to maintain, but LnF is often very important to some people. It’s not a secret, that JTattoo doesn’t cut it for me. Have tried to live with some skins and keep getting back to Substance. I won’t argue to death if most of developers decide to stay with JTattoo only. Will have to live with that

3

What makes Substance better than JTattoo? Is it about the dark themes? Or what is it?

4

I think Jason is the one who likes darker skins. I prefer light ones (like Substance BusinessBlue). It’s the visual appear which is hard to describe (like with women:)). The curves, the gradients, the better blending into the interface, the effects (button hover and press, menu hover). JTattoo skins sometimes looks like from 2000, no blending of titlebar and menu, tabs and other controls sometimes look to flat for my taste, current tab sometimes has dark background which is weird for me. Some skins (like Luna) has striking, jarring colors.

Wondering, can i just throw the newer substance jar somewhere in the source code and recompile it to try it out? Or will it take many lines of code to change?

5

My five cents would be to make sure we don’t break any of the skinning capabilities introduced and available now. There is a lot of change happening regarding what makes up a contemporary user interface design, especially in light of the move to touch interfaces now even on Windows and likely very soon on Mac and Linux too.

For Spark to continue to be viable we would need an option to also port it to Android, iOS, Firefox OS, and Ubuntu OS, all of them requiring touch interfaces. Spark offers too many options to really create an easy to use touch interface, so that we would have to look at removing some things no longer needed, such as skin variants.

Making Spark leaner by removing unnecessary code and reduding the memory footprint would be a pre-requisit to use it on mobile platforms and operating systems. In my view moving forward requires a break with some of the past.

6

No matter how lean Spark can be made, it is still java and i really doubt it will be good on mobile (well, looking how many cores and ram mobile gets with every iteration, maybe it won’t be a problem soon:)). To make Spark Mobile we would have to create completely new application designed for mobile. Should we start designing desktop version as a mobile one?

7

I agree with the need to go for touch devices. In that respect, we need to cut the front end of Spark away and use the Java core as backend. It would make sense to freeze Spark 2 series in a certain state and concentrate on Spark 3 as a multi plattform touch aware client. Some team members showed around amazing stuff on GWT-mGWT. This would make Spark a web app (not Flex based like SparkWeb) with hopefully a responsive design. Very interesting train of thought. But I have not seen a “emerging standard” and GWT seems to be less cool. Take a look into this thread: https://groups.google.com/forum/#!topic/angular/9P4RD3IbQwk and Adam Benders comments.

8

Why Spark Mobile or Touch has to be Java? It’s not Java what makes Spark sparking It’s the design and the features. This can be translated into a project using different platforms/languages. Unless you want one installer to work on every mobile paltform. Well, i don’t buy that multiplatform gimmick much. Spark looks a bit different on Linux, sometimes behaves differently and needs different libraries or such for this and that. And it needs different installers, because noone wants to use just jars. Anyway, we can’t make 2.7.0 out of the gates and talking about 3. By the time we release Spark Touch, touch will be out of fashion and some holographic gui will be the mainstream

9

Just my two cents –

I personalyl like the darker themes better…

With substance, it just… feels more “refined” ??? (probably not a good way to describe it). I’ve had no real issues with substance other than switching back to a JTattoo LaF afterwards (causes buttons to not work, until spark restart… possibly a drawing issuing…)

Wroot – I looked a bit the other day when I merged JTattoo 1.6.7 into my dev branch… I couldn’t find an easy location for where the Substance stuff was coming from… I can see it builds a Jar and puts into the lib (i think) directory of target/, but not sure where the source comes from (if it is source)… I’ll look more soon and report back…

I think the JTattoo “old-nish” is really a root of AWT and Swing (Java default library windowing stuff) being… well… horribly old and outdated.

Java 7 now includeds JavaFX with has some very powerful and very sweet looking windowing options… but this would be a massive undertaking to convert over I think (I have zero experience with JavaFX, only downloaded their demos from oracle and played around).

Java 8 (release date later this year i think) is supposed to include a lot of windowing nice-ness to dramatically update awt and swing… but seeing that we are currently building for java7 and preping for that release, and since j8 still wont be out for a while, then this wouldn’t be smart to start working towards that library (yet).

Im all for removing and simplifying things… if JTattoo is the way to go, then lets go. But, I think we should probably look into making our own custom LaF for it (as Walter has mentioned prior).

I don’t think any of my users even are aware that there are multiple LaF options inside the config for spark… most just use it as it comes… which means Luna.

As part of my work with migrating us to the new JTattoo 1.6.7 i’m going to reorganize the LaF drop down menu so that they are in a more sensible order (Default should be first, currently Luna is in the middle) and try to strip out some of the ones that just plain don’t work such as the “Windows Classic, Metal, Nimbus” etc… they don’t work for me on XP, Win7, Win8, nor Fedora 17…

Another option (but a large undertaking) would be for IgniteRealtime to adopt the Substance codebase and become the new maintainers… although this would require someone with time and knowledge of making LaF’s work well…which I don’t have (i’m a server guy… lol… GUI’s are a luxury for us! lol)

10

I think Spark Mobile might not be a great idea… It would certainly get userbase… however we would be competing directly against some very good, free (FOSS and free as in beer) products that beat us to market by a long shot.

On android, I use Xabber and it is in constant development and is a pretty well featured product.

Another problem woudl be maintaining across mutliple platforms…

naitive for android is Android SDK (modified Java – no awt or swing, plus other differences)

naitive for iphone – objective-c (ewww!)

naitive for blackberry - ???

naitive for windows phone – c++

All devices will run HTML5 content and javascript content (i think), but then this is a radically different product than what we currently offer and requires radically different skillsets (i’m not a web guy for example and my html would be laughed at).

Plus, adding an app to any of the aforementioned App stores costs money (with Google being cheapest i think)… I personally know some iphone devs and it sounds like a nightmare working with Apple… updates taking 3-4 weeks to be reviewed for 1 liner changes, etc.

It can be done, and would be nice. but i think its a pivot away from our core.

11

lol… i’d be perfectly content with a simple jar file lol

minecraft on windows is an exe but it really just lauches the minecraft jar file… on linux and mac minecraft only hands out jar files i think (which create the .minecraft directory for file storage and properties files).

12

Not sure if thats a fork of the original project that we included, or a naming conflict?.. our Substance is:

org.jvnet.substance.skin.Substance

and thats:

org.pushingpixels.substance

maybe they are compatible?

13

wroot – try compiling Spark – then replace the Substance.jar file in the lib/ directory… see what happens…

heads up – no new LaF’s will show up, only the existing ones… they have to be enabled in the

src / java / org / jivesoftware / spark / ui / themes / ThemePanel.java

before compiling.

here’s the file link to my branch:

https://github.com/SnakeDoc/Spark-Unofficial/blob/SnakeDoc_Development/src/java/ org/jivesoftware/spark/ui/themes/ThemePanel.java

14

I probably opened too big a can of worms. All Walter wanted to know is whether he can remove ‘Substance’ and I support that.

There is a lot of other stuff out there, but there is significant value in Spark and its code base; the biggest one being the ability to use it as a solid base to create an Enterprise grade client that you can adapt to really make it fit into a specific solution. This applies to all platforms and we should not underestimate the work put into the Java code base. I am not in favor of revolutions, but in order to move forward we likely have to break with some of the past and splitting the logic from the UI even more would be a good step.

1 Like
15

Well, aou may want to take a look at the Java reach in the mobile world. It is not exactly zero nor similar to Nokia’s smartphone market share. The GUI of Spark is not the complex part of the code. 2.6.3 slimmed down the client a fair bit. An HTML5 frontend might work for a Spark like GUI. Webkit borwsers on are around on all smartphones delivering great Javascript performance on smartphones. It’s a different story than the removal of Substance for sure. And it is splitting up the technology base for the client by moving to Java-Javascript-HTML5-CSS. There are frameworks around for that e.g. http://nextinterfaces.com, just as an example (just Googled it up)

16

i think this is a good conversation to have and the right place for it!

Java is ubiquitious in enterprise and makes perfect sense for an enterprise-y product.

17

Jason wrote:

“Windows Classic, Metal, Nimbus” etc… they don’t work for me on XP, Win7, Win8, nor Fedora 17…
Classic works on XP and Win7. Though it has some quirks with different colors for hover over menus in some places. I thought maybe Classic takes less resources Maybe someone prefers such stripped down version of LaF?

18

Jason, thanks for the tips. Will take a look and try to compile. Though i’m not a coder at all. Just a sysadmin

19

hmm… for me when i select any of those LaF’s the “apply” button is greyed out and wony allow me to apply the skin… ? might just be me though… my computers are known to do whatever they want lol

20

“Just a sysadmin”

Hey! SysAdmin’s keep the world running as we’ve come to know it!

Technically my job title is SysAdmin lol… even though now I mostly do BizDev stuff… but that’s my roots lol…

I’ll see if i can try fiddle with it when I have time… been super busy lately… but this is on my to-do list. At the least, the package names will either have to be refactored in the Insubstantial you found to match what we currently have (quick 'n dirty hack) if licensing permits, or refactor our codebase to use the new packages…

for testing just to see if it works, it may be quicker to refactor the insubstantial project and see what happens, but I wouldn’t rely on that for production… if insubstantial is actively maintained (appears so) and it fixes some of the bugs we’ve had, then i’m all for including it… the substantial LaF’s “feel” more refined to me out of the box…