This question is answered.


Permlink Replies: 250 - Pages: 17 [ Previous | 1 ... 3 4 5 6 7 8 9 | Next ] - Last Post: 20 Jul 21, 17:45 Last Post By: davidekholm
RobM

Posts: 3,817
Registered: 4-Aug-2006
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 21 Jun 20, 01:09   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
Not sure if you are up to date with the skin developer docs? If not, have a look here. There are lots of hints, for example, in the code snippets
xexyl

Posts: 157
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 21 Jun 20, 01:13   in response to: RobM in response to: RobM
 
  Click to reply to this thread Reply
I've seen them but only just. Maybe I'll have to look at them again more thoroughly. But that's for another day I'm afraid. With the help of jGromit I've made more progress than I expected to make and I've also done some other fun things with the reflections filter which I've been playing with with my fractals from my own scriptable program (as in my own design) that generates fractals. The effects are stunning.

I'll follow-up tomorrow I suspect but if any of you know why the colours still aren't being registered I'm more than interested. Maybe I ought to go back to the way I had it now that everything else is working. I'll try that but not now.

Thanks and cheers mate.
JeffTucker

Posts: 8,209
Registered: 31-Jan-2006
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 21 Jun 20, 01:30   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
xexyl wrote:
Colours seem to still remain the default even after changing them.

No, when I switch styles, the Colours panel picks up the new colors. I can't vouch for what happens when you make an album, since I couldn't get through init.bsh without the filters, but I can't imagine that not working.

I simply plugged my new Reflections.jar into the zipped skin you posted earlier. Nothing fancy.

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.

Edited by: jGromit on 20-Jun-2020 19:35
JeffTucker

Posts: 8,209
Registered: 31-Jan-2006
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 21 Jun 20, 02:53   in response to: ctwist in response to: ctwist
 
  Click to reply to this thread Reply
ctwist wrote:
Anyway, it looks like jGromit has done the hard work.

Not all that difficult when you're using a good IDE. ;)
davidekholm

Posts: 3,464
Registered: 18-Oct-2002
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 21 Jun 20, 10:35   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
Just pitching in here that YES, writing the skin UI code within Netbeans is A LOT easier when your skin grows larger and larger. If you prefer interpreted code, use Groovy (.groovy extension) instead of BeanShell. Groovy is here to stay and is now 99.9% compatible with Java syntax.
xexyl

Posts: 157
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 21 Jun 20, 15:47   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
Oh sure... Well you know I still do wonder why the old skin worked and not the new. I mean almost everything was the same. What was the actual problem? That's what I am most baffled by: the same things didn't work that did work in the past.

As for colours are you saying that when you choose blue, say, the colours tab shows a blue background? Because that's very interesting. I'll have to look again - maybe I need to select the skin anew.

The jar file I'll look at too though I don't know how it could be different from mine other than it doesn't have the filters. I'll let you know. Thanks again.

And David - yeah, yeah, I know, I know, but that goes slower for me. Okay one might argue that it would save me time but this is a first and I think a large part of it is that it's been so many years and things have changed in jAlbum and I'm sure Java too (I know for example I had to add some jar files to my builds and that was only one thing that changed on the Java side). Plus I know less Java now than I did then!

My skin isn't all that large either and it was fine and it was the same thing so it doesn't add up. But we each have our own way of working, hey? For me GUIs have always been much slower and I still stand by what I said - entire applications exist that take longer to open and set up than a quick command line with tools that already exist. Classic example is mass renaming based on a regex or searching and replacing a huge set of files on a regex (or just looking for a regex or flat pattern). Anyway that's fine. I'l update the skin to have the thanks/credits/etc. (updating them!) and see what I can do about updating it here.

The reflection filter has been extended but I discovered a bug in the Phong filter that I don't remember being here. I'll perhaps show it here when I get the skin set up.
xexyl

Posts: 157
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 21 Jun 20, 15:51   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
Yup that seems to be it, reloading the skin completely: colours load fine now. Ta.

So what I have to do now is just add the thanks etc. like I had it before. I am aware of one thing I have to do in init.bsh too and then I'll be set (other than trying to figure out the bug in filter - it actually appears to be in Java 2d api but I'll have to look at it more later).
ctwist

Posts: 443
Registered: 27-Sep-2003
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 21 Jun 20, 16:42   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
When you are ready to publish, there are a few things you need to do.

skin.properties must be updated. This can be edited in "Tools / Skin developer". There are some new settings since you last published.
  • It shows that the skin works with jAlbum 9.4. This needs to be updated. In my case, I always (well nearly always) run a regression test in the oldest supported version of jAlbum. Don't claim compatibility with an old version where you will not do a regression test.
  • It shows that the skin requires Java 1.5. You should change this to at least 1.8. There's no point in allowing old unsupported insecure versions. Of course your Java compile script's parameters should match this version.
  • I recommend that you should add a skin family. This is helpful if you want to test with the current and previous version of a skin. jAlbum considers Reflections and "Reflections 2.0.1" to be different skins and it resets the variables when you change a project's skin. However, if these are in the same family, the settings will be retained.
Reflections is considered to be a legacy skin, so it no longer appears in the skins page. After publishing, you should ask Anders to restore it to the active skin list.

Edited by: ctwist on 21-Jun-2020 11:25
xexyl

Posts: 157
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 21 Jun 20, 16:48   in response to: ctwist in response to: ctwist
 
  Click to reply to this thread Reply
ctwist wrote:
When you are ready to publish, there are a few things you need to do.
I'm glad you said this because I did think of it before but I totally forgot - plus the newer things:

settings.properties must be updated. This can be edited in "Tools / Skin developer". There are some new settings since you last published.

I guess you mean skin.properties?

- It shows that the skin works with jAlbum 9.4. This needs to be updated. In my case, I always (well nearly always) run a regression test in the oldest supported version of jAlbum. Don't claim compatibility with an old version where you will not do a regression test.

Yup, this is from the old. I think it 'might' work there but I don't have an older version besides that to test and I'd rather just set it to the most up-to-date version. This way it's just the most current. Besides I believe in keeping software updated.

- It shows that the skin requires Java 1.5. You should change this to at least 1.8. There's no point in allowing old unsupported insecure versions. Of course your Java compile script's parameters should match this version.

Yes. Actually I don't know what version it requires but I did disable setting to 1.5. I'm not sure what version I even have but I don't specify a version in the building now. I'll have to verify what versions I have (Linux, macOS).

- I recommend that you should add a skin family. This is helpful if you want to test with the current and previous version of a skin. jAlbum considers Reflections and "Reflections 2.0.1" to be different skins and it resets the variables when you change a project's skin. However, if these are in the same family, the settings will be retained.

How does this work?

Reflections is considered to be a legacy skin, so it no longer appears in the skins page. After publishing, you should ask Anders to restore it to the active skin list.

Thanks!
JeffTucker

Posts: 8,209
Registered: 31-Jan-2006
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 21 Jun 20, 17:04   in response to: ctwist in response to: ctwist
 
  Click to reply to this thread Reply
ctwist wrote:
  • It shows that the skin requires Java 1.5. You should change this to at least 1.8. There's no point in allowing old unsupported insecure versions. Of course your Java compile script's parameters should match this version.

I've been compiling my skins to the JDK 11 binary, which means they will work with jAlbum 17 or better. In skin.properties, versions after Java 8 finally dropped the 1.something label, so the required Java version is just 11.
xexyl

Posts: 157
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 21 Jun 20, 17:06   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
jGromit wrote:
ctwist wrote:
  • It shows that the skin requires Java 1.5. You should change this to at least 1.8. There's no point in allowing old unsupported insecure versions. Of course your Java compile script's parameters should match this version.

I've been compiling my skins to the JDK 11 binary, which means they will work with jAlbum 17 or better. In skin.properties, versions after Java 8 finally dropped the 1.something label, so the required Java version is just 11.


Ahh that's why the 1.5 didn't work. 11. Updating that now. Thanks!
ctwist

Posts: 443
Registered: 27-Sep-2003
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 21 Jun 20, 17:44   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
xexyl wrote:
ctwist wrote:
  • I recommend that you should add a skin family. This is helpful if you want to test with the current and previous version of a skin. jAlbum considers Reflections and "Reflections 2.0.1" to be different skins and it resets the variables when you change a project's skin. However, if these are in the same family, the settings will be retained.

How does this work?

When you change a project's skin, jAlbum's normal behaviour is to reset all the skin variables to their default values. When Tiger was released, it replaced Turtle but it used some of the same skin variables. These skins have the same skin family, so when a user changes the skin from Turtle to Tiger, jAlbum retains the Turtle skin variables that also exist in Tiger.

This feature is also useful when a developer changes a skin and wants to compare the results of the old and new versions. Rename the old version of Reflections to whatever name you want (e.g. ReflectionsOld) and of course the new version is named Reflections. Now, when you are doing a regression test, you can change the project's skin from Reflections to ReflectionsOld and all the skin settings' values will be retained.

You can use any name for the skin family; just use a sensible name so that it does not match any other developer's skin family.
xexyl

Posts: 157
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 21 Jun 20, 18:17   in response to: ctwist in response to: ctwist
 
  Click to reply to this thread Reply
Ah okay.

That's more than I expected as far as what it allows but what I was getting at is how do I set it up? I guess there's a variable that's set in the skin.properties but maybe not? I didn't see anything from a quick search.
ctwist

Posts: 443
Registered: 27-Sep-2003
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 21 Jun 20, 18:31   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
Use the skin.properties editor that I mentioned earlier.
xexyl

Posts: 157
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 21 Jun 20, 18:34   in response to: ctwist in response to: ctwist
 
  Click to reply to this thread Reply
Right. It shows all the possible variables.

Done. But is there a link (I didn't see one that I recall) to what all the skin variables mean? This way I know if it supports full site etc.

I thought I looked for this and I have a vague memory that I saw it but if so I don't know. Under developer centre I'm sure but where I don't know.
Legend
Forum admins
Helpful Answer
Correct Answer

Point your RSS reader here for a feed of the latest messages in all forums