Posts:
8,219
Registered:
31-Jan-2006
|
|
|
Re: What has changed the past 9 years that might break a skin rebuild?
Posted:
20 Jun 20, 18:35
in response to: xexyl
|
|
|
There's no lib/Reflections.jar, so the skin won't load.
|
|
|
Posts:
157
Registered:
1-Sep-2009
|
|
|
Re: What has changed the past 9 years that might break a skin rebuild?
Posted:
20 Jun 20, 18:38
in response to: JeffTucker
|
|
|
|
Right.
You wanted to load it. Sorry. I'm very tired. Try this one instead.
|
|
|
Posts:
8,219
Registered:
31-Jan-2006
|
|
|
Re: What has changed the past 9 years that might break a skin rebuild?
Posted:
20 Jun 20, 19:13
in response to: xexyl
|
|
|
Something in the way you've busted up the UI has broken the link between the UI and the project variables. You don't even need to make an album to see the problem. Set the font size to 18, save the project, close it, and open it again. It's back to 14. In short, entries in the UI are never being passed to the core program.
I'll come back to this later - the fix should be simple.
Lots of other anachronisms to be addressed, of course, as one would expect with 10-year-old code. Time to step up to HTML5, for example. And in init.bsh, you're manually doing some things that the core can now do for you faster and cheaper, like counting objects in categories.
And if the skin isn't using the rows/cols setting (most skins don't these days), you can just disable that panel in skin.properties, then, in init.bsh, make sure you don't get multiple index pages by setting engine.setRows(0); It shouldn't actually matter, since you're doing your own iteration over the objects, rather than using the built-in iterators. But if you did use the built-in iterators, you could get rid of a lot of the vars.get("something") coding - the variables are all immediately available.
|
|
|
Posts:
157
Registered:
1-Sep-2009
|
|
|
Re: What has changed the past 9 years that might break a skin rebuild?
Posted:
20 Jun 20, 19:21
in response to: JeffTucker
|
|
|
Something in the way you've busted up the UI has broken the link between the UI and the project variables. You don't even need to make an album to see the problem. Set the font size to 18, save the project, close it, and open it again. It's back to 14. In short, entries in the UI are never being passed to the core program.
Curious. I did see something like that but that was related to scaling of images. At one point it was a call in init.bsh and that actually showed a bug so I had removed that.
I'll come back to this later - the fix should be simple.
Thanks!
Lots of other anachronisms to be addressed, of course, as one would expect with 10-year-old code. Time to step up to HTML5, for example. And in init.bsh, you're manually doing some things that the core can now do for you faster and cheaper, like counting objects in categories.
What still baffles me is that the old build worked but when recompiling the old code it did not. Still as you say it's old code and there are many different things now that could be addressed.
HTML5? Yes maybe so though I really hate web design I admit. Still I would have to take a look at it and see how much energy I have for it. I don't know if Exposure is still being developed or if Kristoffer is still here (guess not?) but that would be relevant too.
I'm intrigued about the possibilities with what the core can now do but that's a lesser matter.
And if the skin isn't using the rows/cols setting (most skins don't these days), you can just disable that panel in skin.properties, then, in init.bsh, make sure you don't get multiple index pages by setting engine.setRows(0); It shouldn't actually matter, since you're doing your own iteration over the objects, rather than using the built-in iterators. But if you did use the built-in iterators, you could get rid of a lot of the vars.get("something") coding - the variables are all immediately available.
Hmm I think it was used but I don't honestly remember now how it worked. The question is whether or not it's worth it to modernise it - probably not for such an old skin but maybe I'll consider it. I have been playing with the reflection filter to do what I had it do originally - reflect in different directions - but that's something of interest to me and I'm not sure how much modernising it full stop is.
Anyway thanks a lot for looking at the skin and any suggestions you'll have.
Cheers.
|
|
|
Posts:
443
Registered:
27-Sep-2003
|
|
|
Re: What has changed the past 9 years that might break a skin rebuild?
Posted:
20 Jun 20, 23:57
in response to: xexyl
|
|
|
I looked at the source code, and tried a few quick tweaks, but I couldn't fix the problem easily.
I know I keep referring to Mirage, but that's because I am very familiar with it.
Mirage has SkinPanel.java which defines the entire settings panel, and SkinUI.java which builds the UI from SkinPanel. You may want to replicate this. Initially, just create a single setting "fontsize" and see if it works correctly. There is a lot of other stuff in SkinUI; just ignore it. These two classes are functionally similar to Reflections.java, Album.java, Colours.java, Exposure.java, Language.java and About.java. I don't see any advantage to having so many classes.
Mirage uses MigLayout instead of RiverLayout, so some of the statements will look strange. Just ignore them; you will use your existing statements.
Some of your classes implement JComponentHolder. I don't think this is necessary, since ControlPanel implements JComponentHolder. I tried removing this, but it made no difference.
|
|
|
Posts:
157
Registered:
1-Sep-2009
|
|
|
Re: What has changed the past 9 years that might break a skin rebuild?
Posted:
21 Jun 20, 00:12
in response to: ctwist
|
|
|
I looked at the source code, and tried a few quick tweaks, but I couldn't fix the problem easily.
I'm befuddled myself but it appears that maybe jGromit has some ideas. I'll wait on those before I proceed (at least as far as fixing the problem).
I know I keep referring to Mirage, but that's because I am very familiar with it.
Quite understandable.
Mirage has SkinPanel.java which defines the entire settings panel, and SkinUI.java which builds the UI from SkinPanel. You may want to replicate this.
I have looked at it but not deeply. I might again but not just yet (as above).
Initially, just create a single setting "fontsize" and see if it works correctly. There is a lot of other stuff in SkinUI; just ignore it.
Yes that's what I would do indeed. I have done that even but not trying the same way you went about it.
These two classes are functionally similar to Reflections.java, Album.java, Colours.java, Exposure.java, Language.java and About.java. I don't see any advantage to having so many classes.
Probably not needed for some of them. These are however all from before. I actually removed one class since I took it up again. I could probably merge Exposure and Language into Album but not sure if it's worth the effort - unless it has some possible role here (which seems unlikely but as jGromit pointed out the code is really quite old and bound to have problems because of it). I've revived code before but I have never revived code as old as this and those were in C which is the way I like it.
Mirage uses MigLayout instead of RiverLayout, so some of the statements will look strange. Just ignore them; you will use your existing statements.
Right. Hence the name of the files maybe. I figured it was just short for Mirage.
Some of your classes implement JComponentHolder. I don't think this is necessary, since ControlPanel implements JComponentHolder. I tried removing this, but it made no difference.
Right. I believe I noted this uncertainty but either way I did wonder about it. This is an artefact from before too. Do you recall which classes you tried removing them from without any effect? Perhaps none of them need it even - I really don't know.
Thanks for the thoughts. I'll see what jGromit has to say before I go forward with these but I might. I have already added something else to the skin and one of the filters though; I"m playing with it but by manually setting the variables in the init.bsh file since right now it's the only way to manage it.
My day is approaching the end at least in so far as working on this type of thing. I'm taking care of my mum so I'll be awake a long while yet just not working at any computer.
Cheers.
|
|
|
Posts:
8,219
Registered:
31-Jan-2006
|
|
|
Re: What has changed the past 9 years that might break a skin rebuild?
Posted:
21 Jun 20, 00:15
in response to: ctwist
|
|
|
|
I put everything back into a single Reflections.java, along with a clean SkinModel.java, and it all behaves itself. I can't actually make an album because the filters aren't there, but things in the UI are back to behaving normally.
I replaced the JTextField variables with JSpinners - I just took a guess at correct values (it's default, minimum, maximum, and interval).
I added a StateMonitor(), just so you can see how it works - I don't think that existed the last time you waded into this, and it's much easier to deal with than the various flavors of event listeners.
I skipped the tooltips, and left just a skeleton About tab.
If you want to pursue things further, the switch to HTML5 is about a 5-minute fiddle - from what I can see, it affects only a few lines in the <head> sections of the index and slide pages, and not much else. HTML5 is notable mostly for what's not there, like superfluous type declarations, and self-closing tags. A quick example: <!DOCTYPE html>
<html lang='en'>
<head>
<meta charset='UTF-8'>
<meta name='description' content='jGromit Skins for jAlbum'>
<link rel='icon' href='https://jgromit.com/favicon.ico'>
<title>jGromit</title>
<link href='res/common.css' rel='stylesheet'>
<script>
var maxfCapt = 0;
var maxCapt = 40;
</script>
You can replace the manual object counters with jAlbum's own category counters (also relatively new). Take a look at the first few lines of the predir.bsh file in my Jupiter skin, and I think you'll quickly see how to use them - it's pretty straightforward.
|
|
|
Posts:
157
Registered:
1-Sep-2009
|
|
|
Re: What has changed the past 9 years that might break a skin rebuild?
Posted:
21 Jun 20, 00:18
in response to: JeffTucker
|
|
|
Wow, thanks a lot mate.
I didn't expect that at all. Very kind of you.
I'll take a look at this and see what I get. Much appreciated.
As for HTML5 I'll have to consider that but another day.
Thank you very much to all three of you! I'll mark it as answered once I have got it working (which might be today or else tomorrow).
Cheers.
|
|
|
Posts:
8,219
Registered:
31-Jan-2006
|
|
|
Re: What has changed the past 9 years that might break a skin rebuild?
Posted:
21 Jun 20, 00:18
in response to: JeffTucker
|
|
|
A few other random thoughts:
My code uses anonymous inner classes, so it's just add(something) rather than panelName.add("something"). May not seem like a big deal, until you want to start moving things around in the UI.
Kristoffer moved on to greener pastures about 10 years ago, so anything he was working on has been untouched since then.
|
|
|
Posts:
157
Registered:
1-Sep-2009
|
|
|
Re: What has changed the past 9 years that might break a skin rebuild?
Posted:
21 Jun 20, 00:21
in response to: JeffTucker
|
|
|
A few other random thoughts:
Few pseudo-random comments:
My code uses anonymous inner classes, so it's just add(something) rather than panelName.add("something"). May not seem like a big deal, until you want to start moving things around in the UI.
Understandable. I haven't even saved the files yet but I can imagine what you're getting at fairly well.
Kristoffer moved on to greener pastures about 10 years ago, so anything he was working on has been untouched since then.
Ah, thought he might have. Just like Carl. I'll be adding thanks to you three too in the skin properties though again I don't know when I'll get the skin into a place where I can update it here.
Anyway thanks again.
|
|
|
Posts:
157
Registered:
1-Sep-2009
|
|
|
Re: What has changed the past 9 years that might break a skin rebuild?
Posted:
21 Jun 20, 00:23
in response to: JeffTucker
|
|
|
And I could have sworn I included the filters. I jar them up with the skin classes too. Before this I had them in two different jar files but now they're together.
Anyway will be taking a look now and will update you all when I have a moment.
Edit: Oh you mean in the new jar file probably.
|
|
|
Posts:
8,219
Registered:
31-Jan-2006
|
|
|
Re: What has changed the past 9 years that might break a skin rebuild?
Posted:
21 Jun 20, 00:30
in response to: xexyl
|
|
|
Edit: Oh you mean in the new jar file probably.
Yes, I had no source code for them, so couldn't roll them into the JAR file.
|
|
|
Posts:
443
Registered:
27-Sep-2003
|
|
|
Re: What has changed the past 9 years that might break a skin rebuild?
Posted:
21 Jun 20, 00:30
in response to: xexyl
|
|
|
Right. Hence the name of the files maybe. I figured it was just short for Mirage.
Mg is short for Mirage. I use this class name prefix to prevent duplicate class names.
Some of your classes implement JComponentHolder. I don't think this is necessary, since ControlPanel implements JComponentHolder. I tried removing this, but it made no difference.
Do you recall which classes you tried removing them from without any effect? Perhaps none of them need it even - I really don't know.
Album.java and one other.
Anyway, it looks like jGromit has done the hard work. I won't do any more investigation unless you have further problems.
BTW At jGromit's suggestion, I changed Mirage's UI to use anonymous inner classes in the latest version of Mirage; much better.
|
|
|
Posts:
8,219
Registered:
31-Jan-2006
|
|
|
Re: What has changed the past 9 years that might break a skin rebuild?
Posted:
21 Jun 20, 00:33
in response to: ctwist
|
|
|
BTW At jGromit's suggestion, I changed Mirage's UI to use anonymous inner classes in the latest version of Mirage; much better.
Oh, yeah, once you make the switch, there's no going back! Just don't ever try it with an interpreted onload.bsh. TomCee and I discovered that BeanShell doesn't handle them well at all. In my first pass as switching to anonymous inner classes in Matrix, I ended up with a skin UI that took about 30 seconds to load. Agonizing.
|
|
|
Posts:
157
Registered:
1-Sep-2009
|
|
|
Re: What has changed the past 9 years that might break a skin rebuild?
Posted:
21 Jun 20, 00:52
in response to: xexyl
|
|
|
Just took a quick look and a few things I notice.
Colours seem to still remain the default even after changing them. Also when changing theme the colour selectors aren't populated with the right colours.
That being said the rest are seeming to be maintained. I had added another feature to the main filter and I have to add it to the UI again but that's okay.
I will have to add the about information back and do a few other things but is this expected with the colours?
And thanks for the tip on onload.bsh - fortunately I already only have a single 'new Reflections(...);' so I'm good there.
|
|
|
|
Legend
|
|
Forum admins
|
|
Helpful Answer
|
|
Correct Answer
|
|