This question is answered.


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

Posts: 8,109
Registered: 31-Jan-2006
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 18 Jun 20, 16:34   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
To repeat, we can't see what you're doing. All the explanations in the world don't change that.
xexyl

Posts: 181
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 18 Jun 20, 16:36   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
Right. I was only clarifying what I was trying to say as far as what's going on rather than to show anything. I'll have to consider that later on - unless I sort it out. I have some ideas but I'll look into it when I have more time. I have to head off for a bit now. Ta and cheers mate.
xexyl

Posts: 181
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 19 Jun 20, 01:22   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
Quickly as it's time for me to leave for the day -

I had a little while and I did make progress. Namely that the default colours are now registered right in the generated album. They still aren't reflected in the skin UI and if the user updates them that's not reflected either but I don't have the time right now to look at it further. I do have some ideas and the files are also now in a position where they could be shared if necessary.

But that's for another time. Goodnight / day / whatever it is where you are.

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

Posts: 181
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 19 Jun 20, 20:06   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
Albums are generated but there are still some problems. I'm going to post another message here with some files.
xexyl

Posts: 181
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 19 Jun 20, 20:09   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
Attachment green.css (66 bytes)
Attachment Reflections.java (730 bytes)
Attachment SkinModel.java (1.4 KB)
Attachment Colours.java (553 bytes)
Attachment Album.java (910 bytes)
In my previous post I had the problem that recompiling my skin caused errors when making the album. This I resolved on my own but now I'm really at odds. Notes about the files uploaded (what's changed etc.):

  • I've removed unnecessary code like setting tooltips and the like. Thus if you don't see me adding something to the panels that's why. In other words I only have the variable declarations/initialisations and the constructors. I hope I managed to do this throughout (maybe I shouldn't bother but I figure less redundancy is better). I've not removed imports though. If you believe more context would help I'm happy to provide.

  • Styles: I'm only including the green style files since the same problem is for each style. For green.jap I haven't changed it; green.css was empty but looking at the Mirage skin I saw it includes the String for the colours. Changing this makes it so the generated album is the right default colours but (a) it doesn't show up in the skin UI; and (b) even if the user changes the colours the default is used anyway (this applies to all other variables that the user changes).

  • Colours.java: I'm only including one colour since it's the same for each colour type (background etc.). That is the only colour in the green.css/green.jap files too.

  • SkinModel.java and SlideModel.java: The only change is that I added the colour variables to it and as JColorSelector. Maybe they should be String; I don't know. I've some ideas on this but since I've missed a lot I'd rather just show and ask. At one point I had the colour variables here as String but at that point I don't think I had the css files as they are and in any event it didn't seem to help (at the time anyway). I'm only including one because they're exactly the same (simplified it) other than class name.

  • Album.java: As I noted the settings here you can edit but it doesn't register when building the album.

  • I don't know if the classes that implement JComponentHolder and extend CompiledBase actually need to do that. I changed CompiledScript to CompiledBase as the former is deprecated. This doesn't seem to be related to the problems.

  • onload.bsh simply has:
    new Reflections(engine);
    
    .

  • init.bsh: This sets up filters and the building of the album. However by using System.out.println() I have noticed that indeed variables/settings that the user modifies remain the default. I don't think this file has any relevancy but I can attach it if necessary.

  • Every class is in a single jar file but as you'll see the filters are in their own package. I'm not including the filter source files and they're not relevant.

Everything used to work. The reason the album couldn't be generated before is that I had the skin in a java package and the beanshell could no longer find the variables. After removing the package album compilation works. For filters it doesn't appear to matter but I don't refer to any variables there - just functions.

To recap the problems:

1. When selecting the style / theme in the skin the colours aren't updated in the UI; the default colours are registered for the building of the album. If the user updates the colours this is shown in the UI but it doesn't show up in the album.

2. Variables that are updated by the user remain the default in the generated album (colours and otherwise). Printing the values in init.bsh confirm this (but just like with colours it appears in the UI to have been changed).

Any ideas would be greatly appreciated.

Thank you.
xexyl

Posts: 181
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 19 Jun 20, 20:10   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
Attachment green.jap (30 bytes)
And the other styles file.
JeffTucker

Posts: 8,109
Registered: 31-Jan-2006
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 20 Jun 20, 04:48   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
I don't really have the energy to wade into someone else's messy code, but a few quick observations....

First, I don't understand why you're intent upon "modularizing" any of this. It's a small skin with a small UI. All you need is Reflections.java and SkinModel.java.

Then, the first sign of trouble. In Album.java, you have this:
JTextField fontsize = new JTextField("14", 3);
But in SkinModel.java, we see this:
public int fontsize=14;
Does this set off any alarm bells? It certainly should. ;)

The quick fix is not to use a JTextField to allow the user to enter an integer. Use a JSpinner. That way, you don't have to do any validation to make sure the user hasn't entered 425983 as the font size, or worse, mydog as the font size. It will always be an int.

(I still haven't completely cured both David and Laza of making this mistake, and their stuff still includes text fields being used to accept integer inputs. It's always a bad idea.)

So, in Reflections.java:
JSpinner fontsize = new JSpinner(new SpinnerNumberModel(14, 10, 48, 1));
Color fields are a little weird, however. For the UI, you want to be able to pull up the standard color selectors, so in Reflections.java, you would have:
JColorSelector backgroundColour = new JColorSelector("Background", new JTextField(7));
But in the templates, it's easiest to deal with colors as simple strings, so in SkinModel.java:
public String backgroundColour;
 
or
 
public String backgroundColour = "#eeeeee";
If you don't specify a default, you could, for example, use an event listener to detect the selected style and use that to populate the field.

There are at least half a dozen different ways of passing style-specific things like colors to the album's CSS. For starters, stick to what you see in Minimal. A common.css template is automatically processed by the jAlbum core, with the result landing in res/common.css, so that's the place to put anything that isn't style-dependent. You can then use files like dark.css to add the style-specific stuff. No need for Java-style declarations there - again, just look at what Minimal is doing.

And while you're perfectly free to keep banging your head against the wall when it comes to American English spelling, you're just setting yourself up for CSS problems, since this is going to fail:
body: {
     colour: ${colour};
}
RobM

Posts: 3,889
Registered: 4-Aug-2006
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 20 Jun 20, 12:56   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
jGromit wrote:
And while you're perfectly free to keep banging your head against the wall when it comes to American English spelling, you're just setting yourself up for CSS problems, since this is going to fail:
body: {
     colour: ${colour};
}
For me, there are two reasons for sticking to the American spelling in the code. It is shorter, so less typing is required. It avoids the possibility of typing the English spelling when it must be the American.

But I always use the English spelling in the texts.properties file, so the GUI shows 'colour', not 'color'.
ctwist

Posts: 651
Registered: 27-Sep-2003
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 20 Jun 20, 16:55   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
I had a quick look at your files. At this point, I don't have any additional suggestions. If you still have problems after implementing jGromit's suggestions, I will have another look.

One more suggestion (unrelated to anything else in this thread):

You have a widgets.htt file that seems to completely redefine widget colours, but just for the black style. Mirage also redefines widget colours, but for all styles. This is done in widgets.css, which is much smaller than your widgets.htt (i.e. simpler and less susceptible to changes to the widgets code). There are also a few lines in common.css. You may want to consider changing your approach. For more information, search for "widget" in the skin developer forum.
xexyl

Posts: 181
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 20 Jun 20, 17:20   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
I have gone ahead and made those changes (comments below) but still the problem remains. I'll try explaining it differently.

Let's say that the user wants the font size to be 16. It defaults at 14. They input 16. Now when they click 'Make album' in init.bsh if you print out that variable it is the default 14. So the change the user made has no effect whatever in the album. Similarly if the user ticks (or unticks) one of the checkboxes whatever the default is what is used in the album generation. Also if they change the colours the default colours are used instead.

The UI shows the changes made but it has no effect in the generated album.

As for colours in general the trouble is twofold:

  • Changing the colours (using the colour selector) has no effect for the generated album (as above).
  • In the past when choosing a different theme - say from the default black to green - the colours would be updated in the UI. Now however it's not displayed and instead it only is used in the generated album. So whereas if you were to pick the green theme in the UI the background colour would be a shade of green. Now however they all show black (in the UI!). But until I made the change that the CSS file has (it used to be empty and the .jap file was the one that was key) it used the default in the generated album (in fact white background). The colours were here also not updated in the UI (when selecting a different theme).

In other words it should be updated in the UI when the theme is changed but it does not. It used to work with the style.jap files.

Basically no matter what the user changes the generated album doesn't use anything but the defaults. Even when I just recompiled the skin and kept everything the same from the past the skin suddenly stopped working in that way. I have changed some things and same problem - it isn't updated (though in the UI it appears to be updated).

jGromit wrote:
I don't really have the energy to wade into someone else's messy code, but a few quick observations....
Then I appreciate it more. It's messy because it's old and who knows what was going on then? Also I was less familiar with Java at the time. But now it's even more so because it's been so long. I have cleaned it up some but it still could use work.

First, I don't understand why you're intent upon "modularizing" any of this. It's a small skin with a small UI. All you need is Reflections.java and SkinModel.java.

Simple: it's easier to organise. But actually the UI is a slight bit more complicated than it seems. It's actually the attached file; it's just I felt to make it easier to read through it'd be not necessary to have the extra variables (since it does take time and energy etc. - and again I appreciate the time and energy).

The problem is the same for all variables: whatever is changed by the user when generating albums it goes back to the default (as if it was never changed).


Then, the first sign of trouble. In Album.java, you have this:
JTextField fontsize = new JTextField("14", 3);
But in SkinModel.java, we see this:
public int fontsize=14;
Does this set off any alarm bells? It certainly should. ;)
Right. Actually I've fixed that already. At least I thought I had. Let's see. Yes I did on Thursday; I don't know why that isn't here. Anyway that part is fixed.

The quick fix is not to use a JTextField to allow the user to enter an integer. Use a JSpinner. That way, you don't have to do any validation to make sure the user hasn't entered 425983 as the font size, or worse, mydog as the font size. It will always be an int.

At the time I did not know about it is my belief. I probably also believed that having the maximum field length be part of it. Of course that wouldn't help with a very high number or as you say the strings. Thanks for the tip.


(I still haven't completely cured both David and Laza of making this mistake, and their stuff still includes text fields being used to accept integer inputs. It's always a bad idea.)

Yes well I find that even better since you said you didn't really understand the OO model (I think I saw that somewhere in the forum). Mind you I'm not big on OO but that's the way Java is anyway. I can see the appeal but I much prefer procedure programming / top-bottom / etc.

In C I would be doing this all and more and differently but I'm not as familiar with Java as I am C.


So, in Reflections.java:
JSpinner fontsize = new JSpinner(new SpinnerNumberModel(14, 10, 48, 1));

I've gone ahead and made the change but as I said the change is still not registered for the generated album. Also I don't know if this is a problem on my end or more generally but I could type text in the field too.

Color fields are a little weird, however. For the UI, you want to be able to pull up the standard color selectors, so in Reflections.java, you would have:
JColorSelector backgroundColour = new JColorSelector("Background", new JTextField(7));
But in the templates, it's easiest to deal with colors as simple strings, so in SkinModel.java:
public String backgroundColour;
 
or
 
public String backgroundColour = "#eeeeee";
If you don't specify a default, you could, for example, use an event listener to detect the selected style and use that to populate the field.
That's how I had it but it seems to not make any difference. However I think we're thinking of a different problem.

There are at least half a dozen different ways of passing style-specific things like colors to the album's CSS. For starters, stick to what you see in Minimal. A common.css template is automatically processed by the jAlbum core, with the result landing in res/common.css, so that's the place to put anything that isn't style-dependent. You can then use files like dark.css to add the style-specific stuff. No need for Java-style declarations there - again, just look at what Minimal is doing.

I think there's still some confusion in what I'm getting at; for the generated album after doing what I did in the css file it does use those colours. But when changing the theme it doesn't show up in the UI; and when the user changes the colours the default is still used just like all other variables. For the variables you can see in the UI the changes made but they aren't updated for the album itself.


And while you're perfectly free to keep banging your head against the wall when it comes to American English spelling, you're just setting yourself up for CSS problems, since this is going to fail:
body: {
     colour: ${colour};
}

Yeah I know that :) I just use both is all. Where I have to use the American spelling I do but where I don't I use the British way. Yes it's probably slightly more confusing but then it'd be more confusing to just use the American spelling full stop in my typing etc. Anyway thanks for the reminder (maybe I didn't know after all).
xexyl

Posts: 181
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 20 Jun 20, 17:23   in response to: RobM in response to: RobM
 
  Click to reply to this thread Reply
RobM wrote:
For me, there are two reasons for sticking to the American spelling in the code. It is shorter, so less typing is required. It avoids the possibility of typing the English spelling when it must be the American.

Right but as all good typists do instinctively I roll on to the next letter as I'm typing the one. I sometimes will hit more than one letter almost at the same time. But a letter doesn't make any difference as far as time to type. I mean I know it might seem like it would and maybe over time but the thing is it's also a mental hangup.


But I always use the English spelling in the texts.properties file, so the GUI shows 'colour', not 'colour'.

Fair enough.
xexyl

Posts: 181
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 20 Jun 20, 17:25   in response to: ctwist in response to: ctwist
 
  Click to reply to this thread Reply
ctwist wrote:
I had a quick look at your files. At this point, I don't have any additional suggestions. If you still have problems after implementing jGromit's suggestions, I will have another look.

I gave more information on this in reply to his message and maybe that'll give you more ideas. Thanks.

One more suggestion (unrelated to anything else in this thread):

You have a widgets.htt file that seems to completely redefine widget colours, but just for the black style. Mirage also redefines widget colours, but for all styles. This is done in widgets.css, which is much smaller than your widgets.htt (i.e. simpler and less susceptible to changes to the widgets code). There are also a few lines in common.css. You may want to consider changing your approach. For more information, search for "widget" in the skin developer forum.


Thanks. I'll have to look into that later maybe. For now I'd like to get the updates in the UI by the user to be registered in the generated album.

And to all of you thank you for the help thus far. I'm just bemused as it used to work the way I had it but something must have changed. Fwiw the problems occur under both macOS and Linux. Don't have access to Windows and I consider myself fortunate there (but that's another matter entirely).
JeffTucker

Posts: 8,109
Registered: 31-Jan-2006
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 20 Jun 20, 17:35   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
xexyl wrote:
Let's say that the user wants the font size to be 16. It defaults at 14. They input 16. Now when they click 'Make album' in init.bsh if you print out that variable it is the default 14. So the change the user made has no effect whatever in the album. Similarly if the user ticks (or unticks) one of the checkboxes whatever the default is what is used in the album generation. Also if they change the colours the default colours are used instead.

Unless the variables are being defined again in init.bsh, I don't know how I would make that happen even if I wanted to.

Bits and pieces of code, screenshots, and descriptions of the behavior just aren't going to cut it. We need the skin, the whole skin, including source files.
JeffTucker

Posts: 8,109
Registered: 31-Jan-2006
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 20 Jun 20, 18:00   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
jGromit wrote:
If you don't specify a default, you could, for example, use an event listener to detect the selected style and use that to populate the field.

A correction: You can use the stylename.jap method of doing this. I always forget about that because I don't use it in my skins (and haven't, for over a decade). Long explanation. But it does work.
xexyl

Posts: 181
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 20 Jun 20, 18:07   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
Attachment Reflections.zip (133.9 KB)
jGromit wrote:
xexyl wrote:
Let's say that the user wants the font size to be 16. It defaults at 14. They input 16. Now when they click 'Make album' in init.bsh if you print out that variable it is the default 14. So the change the user made has no effect whatever in the album. Similarly if the user ticks (or unticks) one of the checkboxes whatever the default is what is used in the album generation. Also if they change the colours the default colours are used instead.

Unless the variables are being defined again in init.bsh, I don't know how I would make that happen even if I wanted to.


Yes I'm baffled too. I don't set it in init.bsh; in fact the print statements come before anything else (except engine set thumb size / rows / cols).

Bits and pieces of code, screenshots, and descriptions of the behavior just aren't going to cut it. We need the skin, the whole skin, including source files.

Attached. The filters are separate and don't refer to any of the skin variables though the init.bsh calls them. If you really think you need hem I can attach them but one of them in particular is rather large (I could remove the comments from it to decrease the size but still would be large). Let me know and thanks much for whatever help you can provide and have already provided.

Thanks and no rush on my behalf. I'm just appreciative you're having a go at it.

Edited by: xexyl on 20-Jun-2020 09:11
Have to fix the file. I forgot that that was working changes. I will re-attach in a minute.

Edited by: xexyl on 20-Jun-2020 09:14
Correct file uploaded.
Legend
Forum admins
Helpful Answer
Correct Answer

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