This question is answered.


Permlink Replies: 250 - Pages: 17 [ 1 2 3 4 5 | Next ] - Last Post: 20 Jul 21, 17:45 Last Post By: davidekholm
xexyl

Posts: 157
Registered: 1-Sep-2009
What has changed the past 9 years that might break a skin rebuild?
Posted: 15 Jun 20, 22:58
 
  Click to reply to this thread Reply
I never thought I would return but I have and I see that a great deal has changed since my departure. But what's perplexing me is some problems with the skin I still have being rebuilt; when installing the one on this site it all works okay. However I have some additions - primarily to the filters associated with the skin - that I would like to add but after rebuilding parts that work fine do not work when rebuilt. In particular variables are not being found (and yes I did indeed have SkinModel and SlideModel java files and classes).

I did fix a problem where I could not run setSkinUI on window (due to a change in jAlbum I guess - I had to get JavaFX) and I was hoping (but not at all expecting) it would solve this problem Here is a place it does not work after recompiling but which does in the current skin (which can be found at http://jalbum.net/skins/skin/Reflections) but do not if I recompile:

font-size: <%= fontsize + 3 %>px;


Found in reflections.htt. The variable fontsize isn't found. I tried changing it to skin. and that didn't work either nor anywhere else it might have been. But actually that's only after obliterating all but the processing of templates in init.bsh since otherwise variables that are in the skin are not found. I am baffled because originally the only change is additional variables but variables that I haven't touched (nor any part of it e.g. that of above) are no longer found either.

Another problem is after updating the style the .jap file doesn't seem to take effect so that the colours remain the same.

I am very preoccupied at this time but I would rather like to get this resolved at some point in the near future if at all possible.

Anyone can give me some ideas? As you see it's been a long time so i'm rather out of the loop as far as what's changed that might be causing the problems. Oh and yes I changed from CompiledScript to CompiledBase but maybe I have to do more than I did, I don't really know.

I can offer up some files if that's helpful but there are quite a few (rather modular) and I will have to also do some modifications before I can do that (to remove debuting changes etc.) but I'm happy to do that.

Thank you.

Edited by: xexyl on 15-Jun-2020 14:35
RobM

Posts: 3,820
Registered: 4-Aug-2006
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 15 Jun 20, 23:51   in response to: xexyl in response to: xexyl
Helpful
  Click to reply to this thread Reply
So much has changed in nine years ;)
There are several skin developers that compile skins using Netbeans and at least one using Eclipse. For Netbeans and the way skins are usually compiled see https://jalbum.net/forum/thread.jspa?threadID=54799&tstart=0

There is more developer information and general help in the form of a wiki

I can't guarantee a helpful response, but uploading or making your source files available might get a response.
xexyl

Posts: 157
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 16 Jun 20, 00:05   in response to: RobM in response to: RobM
 
  Click to reply to this thread Reply
Yes I imagine indeed so much has changed - it would be a surprise if it had not!

NetBeans/etc.: Well I don't use it but I did go through that guide on the forum and it helped solve the mystery of the window.setSkinUI() call not working in the java files. It would be so slow to use it though; I'm a command line user and it's a lot easier and more efficient to edit code and also build and jar up files etc.

I know that some compile their java too for example jGrommit (spelling?) and even in that case he (or she? I believe he) has source code included. Yet nothing really jumped out as obvious because like I said the things that aren't working haven't even changed. I happen to be the one who helped with getting RPMs made for jAlbum and I might still have the original build in which case I could try using that and see if the skin works there. I know I have at least one build of that I just haven't tried it yet (I did buy a licence for the current release last week).

I will see about working the source code a bit so that I can then get a stack trace. The trouble is it doesn't seem to make sense as I already said. I mean why would the variable I mentioned - included in Slide and SkinModel classes as well as the actual place it's used - suddenly not be found in BeanShell scripts? That doesn't make sense to me and why would showing that the variable isn't found here and is found there be useful? Well of course it can be but you I imagine know what I mean.

I read something yesterday that made me wonder if it's possible to change init.bsh to be compiled Java but I haven't tried that yet. Is that an option / do you know if anyone else has tried that? If that were to work if I could do the same thing in the template file (can I?) that would be fine on my behalf.

Any thoughts there? And thank you for the reply (I will check the links in a min). I hope to get back to replies shortly after but I've been very busy taking care of my mum and I'm just knackered a lot of the time from it.

Thanks for the feedback so far!
RobM

Posts: 3,820
Registered: 4-Aug-2006
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 16 Jun 20, 00:38   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
xexyl wrote:
NetBeans/etc.: Well I don't use it but I did go through that guide on the forum and it helped solve the mystery of the window.setSkinUI() call not working in the java files. It would be so slow to use it though; I'm a command line user and it's a lot easier and more efficient to edit code and also build and jar up files etc.
I'm very much a GUI user, I only use the command line if I have to. There are a few command line experts, though they don't code for skins.
I know that some compile their java too for example jGrommit (spelling?) and even in that case he (or she? I believe he) has source code included. Yet nothing really jumped out as obvious because like I said the things that aren't working haven't even changed. I happen to be the one who helped with getting RPMs made for jAlbum and I might still have the original build in which case I could try using that and see if the skin works there. I know I have at least one build of that I just haven't tried it yet (I did buy a licence for the current release last week).
jGromit, is a he. I used his guide to compile my skins GUIs.
I will see about working the source code a bit so that I can then get a stack trace. The trouble is it doesn't seem to make sense as I already said. I mean why would the variable I mentioned - included in Slide and SkinModel classes as well as the actual place it's used - suddenly not be found in BeanShell scripts? That doesn't make sense to me and why would showing that the variable isn't found here and is found there be useful? Well of course it can be but you I imagine know what I mean.
I take it your skinModel is compiled; there has been a reported problem with non-compiled files and Windows 10.
I read something yesterday that made me wonder if it's possible to change init.bsh to be compiled Java but I haven't tried that yet. Is that an option / do you know if anyone else has tried that? If that were to work if I could do the same thing in the template file (can I?) that would be fine on my behalf.
Never tried it. We only compile the skin GUIi as that saves time when the skin is loading.
The other thing though, is that languages other than bash are now supported, like JavaScript and Gooey.
Any thoughts there? And thank you for the reply (I will check the links in a min). I hope to get back to replies shortly after but I've been very busy taking care of my mum and I'm just knackered a lot of the time from it.
Hopefully someone else might have an idea.

Edited by: RobM on 15-Jun-2020 23:39
No lies, just files!
ctwist

Posts: 443
Registered: 27-Sep-2003
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 16 Jun 20, 01:42   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
Mirage is the skin that is compiled in Eclipse. All of the Java code is compiled, including init.bsh.

One thing that has changed is tighter scripting rules for variables. Details are in http://jalbum.net/forum/thread.jspa?threadID=55131.
ctwist

Posts: 443
Registered: 27-Sep-2003
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 16 Jun 20, 01:55   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
xexyl wrote:
NetBeans/etc.: ......... It would be so slow to use it though; I'm a command line user and it's a lot easier and more efficient to edit code and also build and jar up files etc.
Oooo - I disagree with that.
  • Eclipse identifies errors as you write the code. It doesn't just flag syntax errors; it flags logic errors such as dead code, failing to initialise a variable, memory leaks, uncaught exceptions, etc, etc. All this is identified when you compile, and this saves a lot of wasted testing effort.
  • Eclipse has code helpers; e.g. it generates try/catch for each required exception handler.
  • Eclipse automatically compiles a class when you save it and also compiles any dependent classes.
  • Eclipse can export to a jar file; very easy.
I would never go back to the dark ages.
JeffTucker

Posts: 8,216
Registered: 31-Jan-2006
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 16 Jun 20, 02:16   in response to: ctwist in response to: ctwist
 
  Click to reply to this thread Reply
ctwist wrote:
xexyl wrote:
NetBeans/etc.: ......... It would be so slow to use it though; I'm a command line user and it's a lot easier and more efficient to edit code and also build and jar up files etc.
Oooo - I disagree with that.

I'll second that, WRT NetBeans. Saves mounds of time. No need to wait for a compiler error when the IDE gives you obvious red marks, along with their causes, in the source code.

And why would I want to be reduced to pounding out obscure text on a command line when I can do a compile with one click? (And the .jar file lands in the "live" skin in jAlbum, to boot - no need to move files around.)

I spent many long years during my so-called career living on the command line. But that was in the Pleistocene Era.
xexyl

Posts: 157
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 16 Jun 20, 02:21   in response to: ctwist in response to: ctwist
 
  Click to reply to this thread Reply
Nevertheless people have entire GUIs for seemingly complex tasks that I can write simple command lines in 10 seconds and get it done long before I even have time to find let alone download and install another program.

Your link on tighter script rules might be a key. I'll take a look and thanks.

On an IDE I did humour it though and did go through with it and no errors at all. It's something else that's going on.

Thanks for your feedback. I'll probably have to look at it in the morning though. Have to go take care of my mum and then get my head down after that.

Cheers.
xexyl

Posts: 157
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 16 Jun 20, 02:25   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
Btw jGromit - I don't have to run any obscure command lines.

Wrote my own build scripts etc. Always do that. If I ever need to do something more than once I tend to automate it. Sometimes I automate it just for fun.

For example where you're talking about copying the jar file to another directory (in your NetBeans post) my script does everything automatically in a couple seconds or less. Type one short command and it's done. That's how I did it before too. Compiler errors? No problem for me either.

Anyway appreciate the feedback but will have to get back to it tomorrow. Have to go take care of my mum.

Cheers.
JeffTucker

Posts: 8,216
Registered: 31-Jan-2006
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 16 Jun 20, 04:22   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
xexyl wrote:
Type one short command and it's done.

I don't have to type anything. One click, and it's done.

If you enjoy writing scripts to automate things, that's fine. But if you think what you're doing is easier or more efficient, you're just kidding yourself. The automated tools are already there - there's no need to reinvent them.
xexyl

Posts: 157
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 16 Jun 20, 16:16   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
jGromit wrote:
xexyl wrote:
Type one short command and it's done.

I don't have to type anything. One click, and it's done.

If you enjoy writing scripts to automate things, that's fine. But if you think what you're doing is easier or more efficient, you're just kidding yourself. The automated tools are already there - there's no need to reinvent them.


But see why would I go through the effort to do mass rename of files for example? I already have the tools and knowledge to do that with a simple pipeline. Thing is I'm far more comfortable at the command line than GUIs. Mind you I also am a participant and winner of the IOCCC - you know of it maybe? I have even fixed bugs after obfuscating the code - without any problems or using any beautifiers!

Anyway that's neither here nor there. I'll reply to the posts more thoroughly now I have time. I have comments on jAlbum and that's what I'm here for.

But: I did humour it and did use NetBeans (using your guide) and the same result I'm afraid. But that's for another post here!

Edited by: xexyl on 16-Jun-2020 07:17

Edited by: xexyl on 16-Jun-2020 07:18
xexyl

Posts: 157
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 16 Jun 20, 16:24   in response to: ctwist in response to: ctwist
 
  Click to reply to this thread Reply
ctwist wrote:
xexyl wrote:
NetBeans/etc.: ......... It would be so slow to use it though; I'm a command line user and it's a lot easier and more efficient to edit code and also build and jar up files etc.
Oooo - I disagree with that.
  • Eclipse identifies errors as you write the code. It doesn't just flag syntax errors; it flags logic errors such as dead code, failing to initialise a variable, memory leaks, uncaught exceptions, etc, etc. All this is identified when you compile, and this saves a lot of wasted testing effort.
  • Eclipse has code helpers; e.g. it generates try/catch for each required exception handler.
  • Eclipse automatically compiles a class when you save it and also compiles any dependent classes.
  • Eclipse can export to a jar file; very easy.
I would never go back to the dark ages.

Okay but some thoughts on this too.

  • I have my own build environment. It's in a way an IDE except it doesn't identify invalid keywords etc. But then I don't really need that. I'm used to compiling by a simple command rather than having to find a button to click (and I'm much faster typing than using the mouse).

  • I grant you that it's interesting to have it automatically compile when you save a file but I think that would actually annoy me - I often edit more than one file at a time (I have several files open in one vim - text - window, for example). It's just the way these things work in my head.

  • Exporting to a jar my build script does too.

  • Dark ages for me would be GUI except that it's more like - well dark ages refers to past doesn't it ? :)

Anyway that's just how my mind works just as it's how your mind works. Now that that's out of the way I can go back to jAlbum though and I have some comments particularly to do with variables.
xexyl

Posts: 157
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 16 Jun 20, 16:35   in response to: ctwist in response to: ctwist
 
  Click to reply to this thread Reply
ctwist wrote:
Mirage is the skin that is compiled in Eclipse. All of the Java code is compiled, including init.bsh.
Now this is interesting: init.bsh is compiled. How did you do this exactly? Because this might be one workaround (that I alluded to above). Because variables are recognised in the classes just not in the BeanShell files. Also did you do this for template files - and if so how?

One thing that has changed is tighter scripting rules for variables. Details are in http://jalbum.net/forum/thread.jspa?threadID=55131.

Okay now at first I was thinking this might be key but now I don't know: the thing is that the same template lines fail in the new build but do not in the old build. I already included an example place but here's it again - maybe you have an idea?

font-size: <%= fontsize + 3 %>px;


Mind you there's a workaround to that but the concept is what's problematic. It cannot find the variable. Is this also possible to compile somehow? Because again it seems the variable is seen in the class files.

There's another curious thing: in the old build the .jap hints for styles updates the colours selected in the skin but in the new build it does not. Can you think of any reason that might be and is there any other way to fix that? I believe I can use StateMonitor (if that was it?) as to update the variables when the style is changed (and the Matrix skin shows that itself). Is that right?

Any ideas with these things? Because clearly it's a variable issue but why the old one works okay with the same thing as the new - that does not work - is something that's perplexing me.

So to recap:

  • The .jap files for the styles is not working in the new build. What might be the reason for that and is the StateMonitor the best way to fix that? Ideally I would have the hint files work as that's easiest but if not possible that's okay I guess in the end.

  • Why would the variables work in the old build but not in the new when the same lines are used? Can the templates be compiled too?

  • How did you manage to compile init.bsh? I have some thoughts but to save me the frustration it would be nice to have some hints (I presume it was your skin anyway).

  • Any other thoughts that you might have.

Also I want to thank you all for the thoughts including on IDEs - it's much appreciated even if IDEs don't do it for me. I know that you find it easier and that's fine of course. We just have different ways of thinking but in the end you trying to help is what matters and is much appreciated! That goes for both of you on the IDE and also for Rob too.
JeffTucker

Posts: 8,216
Registered: 31-Jan-2006
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 16 Jun 20, 16:35   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
xexyl wrote:
Mind you I also am a participant and winner of the IOCCC - you know of it maybe? I have even fixed bugs after obfuscating the code - without any problems or using any beautifiers!

In that case, none of this should present any problems for you.

Best of luck.
xexyl

Posts: 157
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 16 Jun 20, 16:38   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
jGromit wrote:
xexyl wrote:
Mind you I also am a participant and winner of the IOCCC - you know of it maybe? I have even fixed bugs after obfuscating the code - without any problems or using any beautifiers!

In that case, none of this should present any problems for you.

Best of luck.


Hmm no :) That's not true at all nor how it works at all.

The point is my mind considers obscurity differently. However there has to be something that's changed over the years that made the same thing not work. As ctwist(?) said there have been changes with variables and I think that's probably related somehow. But why it works in the old and not the new is the thing that remains the mystery.

Also that code was my code - all my code - and although the skin is mine jAlbum is not. Also that code was fresh in my mind. This is years gone. Big differences mate. See what I mean?
Legend
Forum admins
Helpful Answer
Correct Answer

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