Posts:
157
Registered:
1-Sep-2009
|
|
|
|
Re: What has changed the past 9 years that might break a skin rebuild?
Posted:
21 Jun 20, 19:30
in response to: JeffTucker
|
|
|
Colours seem to still remain the default even after changing them.
ETA: Just did a quick sanity check - I commented out all of the filter stuff in init.bsh so I could generate an album, and the style color choices successfully migrated to res/styles.css.
What I just discovered however is that if the user updates the colours the defaults are still used. I discovered also that if I went to the old css files (under styles/ subdirectories) - i.e. empty - white is used (and the .jap files seem unused). I'm not sure if that's expected nowadays but I'm not sure either how to fix it (at least yet).
I just read some comments here that I somehow missed yesterday and I'll comment on them:
- As for the filters I was thinking (though this of course unrealistic it's just what was going on in my mind at the time) that since I gave the class files you could integrate those. Unreasonable to expect that of course.
- The lack of tooltips I noticed yeah. I'll add those back.
- The About I just used the old About class to simplify it. I did add to the skin.properties to 'thanks' and 'credits' you, Chris and Rob, however, and again thanks much.
- The other things you mentioned I haven't yet addressed either. I can only do so much web related things in a day though before I get tired of it so I might be done with this for today.
I also fixed the filter issue. It was having changed the stage when to filter in init.bsh (in the call to engine.addFilter - I had changed it to something different the other day but it has to be done after scaling and that caused the error).
Oh a note on colours: if I add a System.out.println statement of the background colour in init.bsh, say, the user updated colour is shown there. However in the generated stylesheet it shows the old colour. I guess there's a problem in the syntax in the template. I have:
background-color: ${backgroundColour};
But for some reason it's not updated in the generated album (shows the default in the css file). Any ideas? Thanks. |
|
|
Posts:
8,219
Registered:
31-Jan-2006
|
|
|
Posts:
157
Registered:
1-Sep-2009
|
|
|
|
Re: What has changed the past 9 years that might break a skin rebuild?
Posted:
21 Jun 20, 19:35
in response to: JeffTucker
|
|
|
|
Thanks!
And yes that sounds about right with documentation. I don't know if that's good or bad. Some of the time I think it's good but I know it's actually bad.
|
|
|
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, 19:45
in response to: xexyl
|
|
|
|
|
Colours seem to still remain the default even after changing them.
ETA: Just did a quick sanity check - I commented out all of the filter stuff in init.bsh so I could generate an album, and the style color choices successfully migrated to res/styles.css.
What I just discovered however is that if the user updates the colours the defaults are still used.
To repeat, I'm not seeing that problem. Without being able to look over your shoulder, I don't know what you're doing wrong. In the UI, if I choose the red style, I get what you see in the first screenshot. When I make the album and look at the output styles.css, I see the correct color being used.
This is with the original, empty CSS files. The colors for the red style are being grabbed from the red.jap file in the skin.
I'm attaching my version of the skin, with the filters stuff commented out so it will generate an album. It installs as ReflectionsJG.
Edited by: jGromit on 21-Jun-2020 14:04 - replaced jaskin |
|
|
Posts:
157
Registered:
1-Sep-2009
|
|
|
|
Re: What has changed the past 9 years that might break a skin rebuild?
Posted:
21 Jun 20, 19:48
in response to: JeffTucker
|
|
|
Colours seem to still remain the default even after changing them.
ETA: Just did a quick sanity check - I commented out all of the filter stuff in init.bsh so I could generate an album, and the style color choices successfully migrated to res/styles.css.
What I just discovered however is that if the user updates the colours the defaults are still used.
To repeat, I'm not seeing that problem. Without being able to look over your shoulder, I don't know what you're doing wrong. In the UI, if I choose the red style, I get what you see in the first screenshot. When I make the album and look at the output styles.css, I see the correct color being used.
Right. I get this too. I mean:
If the user chooses a theme, red as you say, and then they modify the background colour. That is updated in the skin settings but in the generated album it stays the default. Does that make more sense? I'll take a look at the files though. |
|
|
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, 20:07
in response to: xexyl
|
|
|
|
The problem is those non-empty CSS files. I just zeroed them out, repackaged the .jaskin, and attached it, above. If I choose green, then change the background color to purple, and then make the album, the CSS shows purple, as it should.
|
|
|
Posts:
157
Registered:
1-Sep-2009
|
|
|
|
Re: What has changed the past 9 years that might break a skin rebuild?
Posted:
21 Jun 20, 20:29
in response to: JeffTucker
|
|
|
|
Strange.
I had tried that. Just did again and the generated css file has an empty background colour (the colour I modified) in the res/styles.css file.
But maybe it's something like what I noticed yesterday - I could swear yesterday the colours were not populated properly but then they were this morning. I'll get back to this another time. Maybe look at it tomorrow or the next day. Once that's sorted I'll mark it as answered.
Enjoy the rest of your day (this is assuming that I don't reply again today) and thanks again.
Cheers.
|
|
|
Posts:
157
Registered:
1-Sep-2009
|
|
|
|
Re: What has changed the past 9 years that might break a skin rebuild?
Posted:
22 Jun 20, 16:05
in response to: JeffTucker
|
|
|
The problem is those non-empty CSS files. I just zeroed them out, repackaged the .jaskin, and attached it, above. If I choose green, then change the background color to purple, and then make the album, the CSS shows purple, as it should.
You're absolutely right that it works there. For some reason on my build though I get in the css file (without the css files as I have them now):
background-color: ;
Now what's extra curious about this is that if I add in the printVars() function I wrote in init.bsh the following line:
System.out.println(backgroundColour);
...and I keep the default for say red I get:
#770000
And indeed the colours are set to the preset colours (here referring to the colour selectors). And if I update it to say #ff0000 I get as you'd expect #ff0000.
However in the generated stylesheet it's empty (as above). So to recap this when the css files are empty the colours are still populated right in the skin ui but the stylesheet doesn't reflect it. The skin UI shows the right colours and the init.bsh shows it too but the stylesheet isn't generated properly.
I tried your version and it worked however. It isn't the init.bsh as I copied the one you had to my skin directory and it still had the same problem with the empty css files.
Any thoughts? Also Chris since I got the css file with Java variables idea from your skin Mirage do you have any ideas why this might be the case? In the reflections.htt file I have for the variables:
background-color: ${backgroundColour};
Something is very odd here and the only thing I can think of is that I added some things to the Reflections.java file as there were some missing things. I can try and roll back those changes to see if that makes any change but I'm thinking it's something else, somehow, though maybe not from what I've seen.
Maybe another syntax (there are several I believe?) for the variables here would be of help. Before with the old java files when I updated a variable it was shown in the skin ui but not in the init.bsh (so wasn't updated properly); now it is updated properly but not being shown in the generated album still. In fact if I empty out the css files and do not update the colours in the skin ui it's also still empty: it's as if not having the css file with the variables is making it empty (as if the variables were empty themselves like with no setting even though they are set).
To humour this I might throw this in an IDE and see if I see anything but I cannot imagine what that might be. Anyway any thoughts any of you?
Thanks. |
|
|
Posts:
443
Registered:
27-Sep-2003
|
|
|
|
Re: What has changed the past 9 years that might break a skin rebuild?
Posted:
22 Jun 20, 16:24
in response to: xexyl
|
|
|
|
I have seen similar behaviour in the past. It seems that if the skin processes a template file too early, this may happen before some variables have been populated. I assume that jAlbum runs multiple threads and depending on the PC's speed and number of CPU cores, a thread may finish after another thread that depends on it, or maybe jAlbum does some initialisation after init.bsh has finished.
To avoid such problems, some Mirage album initialisation (including processing templates) is done in predir.bsh instead of in init.bsh.
|
|
|
Posts:
8,219
Registered:
31-Jan-2006
|
|
|
|
Re: What has changed the past 9 years that might break a skin rebuild?
Posted:
22 Jun 20, 16:56
in response to: ctwist
|
|
|
I've never seen that problem. I use predir.bsh and postdir.bsh only for things that are folder-specific. For album-wide stuff, init.bsh and finally.bsh.
As a first step, however, I would clean up reflections.htt and rename it common.css. Then remove the explicit call to process that template from index.htt - it's not necessary if you're using the normal common.css mechanism. Just remember that your index.htt and slide.htt now need to load res/common.css instead of res/styles.css.
While you're at it, move the template processing call for functions.htt from index.htt to init.bsh. This is something that's done once, for the entire album, so it has no business being in index.htt, which gets called for every folder.
In init.bsh, delete this, which is not needed: if (!resDirectory.exists())
resDirectory.mkdirs();
|
|
|
Posts:
8,219
Registered:
31-Jan-2006
|
|
|
|
Re: What has changed the past 9 years that might break a skin rebuild?
Posted:
22 Jun 20, 17:00
in response to: JeffTucker
|
|
|
|
There is one bit of variable weirdness that you should tuck away in your memory somewhere, since it's undocumented, and will bite you. Say your skin UI has a variable called somethingSIze. Now say you need to adjust the user's setting for some reason, based on some other factors. So, in init.bsh, you change the value of somethingSize.
In common.css, that new, changed value will be used, as expected. But in other template files, like index.htt or some other template like mypage.htt, the original, unchanged value will persist. Guaranteed to make you a little crazy if you're not aware of it. The trick is simply to define a new variable in init.bsh, like somethingSizeAdjusted, and use that in all of the templates. That works reliably.
|
|
|
Posts:
157
Registered:
1-Sep-2009
|
|
|
|
Re: What has changed the past 9 years that might break a skin rebuild?
Posted:
22 Jun 20, 21:30
in response to: JeffTucker
|
|
|
There is one bit of variable weirdness that you should tuck away in your memory somewhere, since it's undocumented, and will bite you. Say your skin UI has a variable called somethingSIze. Now say you need to adjust the user's setting for some reason, based on some other factors. So, in init.bsh, you change the value of somethingSize.
In common.css, that new, changed value will be used, as expected. But in other template files, like index.htt or some other template like mypage.htt, the original, unchanged value will persist. Guaranteed to make you a little crazy if you're not aware of it. The trick is simply to define a new variable in init.bsh, like somethingSizeAdjusted, and use that in all of the templates. That works reliably.
Well this was it. Naturally. I actually thought about something like this but never got to it. Fortunately you did mention it. I think I have updated all variables but maybe I've missed one. Looking at the list of what I have it appears to be and checking the generated files seem to have the updated values too.
Thanks for the tip and all the other help - all of you!
I still am unsure on when I will update the skin but maybe I ought to. Anyway you're all in thanks and credits. I have discovered an interesting problem with one of the filters but only when scaling the images to a certain dimensions and only with one setting enabled. I'll worry about that another time though - committing to my repo and then will probably be done with jAlbum for the day.
Thanks again, and cheers. |
|
|
Posts:
157
Registered:
1-Sep-2009
|
|
|
|
Re: What has changed the past 9 years that might break a skin rebuild?
Posted:
22 Jun 20, 21:38
in response to: xexyl
|
|
|
|
Oh a couple other things:
The reason I called mkdirs() on that directory is that in the past this proved to be a problem (though I think with a different skin of mine - one I deleted because it uses Adobe Flash and that's a nightmare in so many ways).
As for the other template processing you mention that should be in init.bsh (I think you said there) it errored out so for now I kept it in the file it's already in. I see what you mean however. Maybe another beanshell file would be the key but I don't know and right now I'm not too bothered by it.
I now have a postdir.bsh file, the stylesheet is under res/common.css and the init.bsh sets variables and the other files use those variable names instead.
Edited by: xexyl on 22-Jun-2020 12:38
Set it to answered. Thanks to you all (but more than the others jGromit)!
|
|
|
Posts:
8,219
Registered:
31-Jan-2006
|
|
|
|
Re: What has changed the past 9 years that might break a skin rebuild?
Posted:
22 Jun 20, 22:22
in response to: xexyl
|
|
|
The reason I called mkdirs() on that directory is that in the past this proved to be a problem....
Yes, the jAlbum core is vastly improved over what it was like some years ago, and some of the workarounds aren't needed any longer. That's usually because some pushy, annoying, temperamental skin developer has beaten David about the head and shoulders and gotten him to fix things. Glad I'm not one of those. 
Thanks to you all (but more than the others jGromit)!
You're welcome! Post back if you get stumped. And you will  |
|
|
Posts:
157
Registered:
1-Sep-2009
|
|
|
|
Re: What has changed the past 9 years that might break a skin rebuild?
Posted:
22 Jun 20, 23:47
in response to: JeffTucker
|
|
|
The reason I called mkdirs() on that directory is that in the past this proved to be a problem....
Yes, the jAlbum core is vastly improved over what it was like some years ago, and some of the workarounds aren't needed any longer. That's usually because some pushy, annoying, temperamental skin developer has beaten David about the head and shoulders and gotten him to fix things. Glad I'm not one of those.
Ah I see. I'll maybe remove it then. And I don't know if it's bad to be annoying when it leads to the improvement of code. I'm a developer of a MUD and although I had to at times deal harshly with problem players they could be a blessing in a way - they were certain to find bugs. Then again I was too because it's just the way my mind thinks. Still I don't think getting a developer to fix something is a bad thing. Maybe you're not being serious here though. That would be my literal thinker syndrome if you're not.
Thanks to you all (but more than the others jGromit)!
You're welcome! Post back if you get stumped. And you will
Not as stumped as a tree I'm sure. But thanks for the comment there. I don't know how much I will be developing beyond this. I looked at it again because of my image filters. Because I had the thought that it would be really cool to take my fractals and reflect them. And indeed it is very cool. But then the changes over the years - not just jAlbum but probably also Java and maybe even other platform things - made it harder for this to go so well. I therefore did manual work on the matter (updating init.bsh repeatedly).
Then I discovered a strange bug in a call to the WritableRaster method getDataElements(). It's curious because it only shows itself when adding the light prior to reflection is ticked and only with scaling to certain dimensions. Get a class cast exception that is really strange:
java.lang.ClassCastException: class [I cannot be cast to class [B ([I and [B are in module java.base of loader 'bootstrap')
at java.desktop/sun.awt.image.ByteInterleavedRaster.getDataElements(Unknown Source)
at xexyl.jalbum.filters.light.PhongFilter.filter(PhongFilter.java:241)
at xexyl.jalbum.filters.light.PhongFilter.filter(PhongFilter.java:337)
at xexyl.jalbum.filters.effects.ReflectionFilter.filter(ReflectionFilter.java:251)
at se.datadosen.jalbum.AlbumBean.processFilters(AlbumBean.java:4240)
at se.datadosen.jalbum.AlbumBean$StandardImageProcessor.processImage(AlbumBean.java:6024)
at se.datadosen.jalbum.AlbumBean$StandardImageProcessor.processImages(AlbumBean.java:5856)
at se.datadosen.jalbum.AlbumBean$ImageProcessingTask.call(AlbumBean.java:5786)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
I find that very odd though. It does seem to have something to do with scaling of images but why I don't know. I'll worry about that in time - or not. Knowing me I will worry about it because even if it requires a workaround I hate bugs in my code whether that's directly or indirectly in my code. I don't remember this from before. But then maybe I never happened across the scaling issue. Or maybe it wasn't a problem then. I don't know but will worry about it in time. I have looked at the WritableRaster API on that method but so far nothing has popped into my head as far as why it might be happening.
Anyway thanks again so much and I really have marked my question as answered now (I did before but it appears it didn't register when I did it by editing the message. That or there was some other problem).
I'll reply back if I come across any problems. Maybe to get the skin 'ready' for republication. But at least the skin now works properly.
Cheers mate. Take care and thanks again. You too Rob and Chris. Much appreciated! Stay safe in this crazy world we live in too. |
|
|
|
Legend
|
|
Forum admins
|
|
Helpful Answer
|
|
Correct Answer
|
|
