Thread Locked This thread is locked - replies are not allowed.



Permlink Replies: 356 - Pages: 24 [ Previous | 1 ... 18 19 20 21 22 23 24 | Next ] - Last Post: 18-Nov-2017 16:56 Last Post By: davidekholm Threads: [ Previous | Next ]
RobM

Posts: 3,170
Registered: 4-Aug-2006
Re: jAlbum 14.2 beta for testing
Posted: 17-Nov-2017 00:12   in response to: jGromit in response to: jGromit
jGromit wrote:
Just keep putting up those easy lobs, eh?
I like to make things easy for you :)

David: The folder properties title field is still not showing a different coloured background to the pane itself, unless you click on the hidden area. It should match the description field, see attached.
AndreWolff

Posts: 1,713
Registered: 14-Dec-2007
Re: jAlbum 14.2 beta for testing
Posted: 17-Nov-2017 09:47   in response to: davidekholm in response to: davidekholm
davidekholm wrote:
  • Fixed behavior of the theme image selector. It's now always reflecting the representing folder image unless the skin supports separate theme images. It's never blank unless the folder doesn't contain any images.
Well David, I stop testing and implementing your theme image implementation, because you did change the implementation again in the latest jAlbum version!

You replaced the ‘Remove’ menu item by ‘Reset’, so it is no longer possible to remove the theme image.
If you apply the new ‘Reset’ function, the theme image is replaced by a theme image based on the Thumbnail, however
path = currentFolder.getProperties().get("themeImagePath"); 
returns void, even if I drag the image which corresponds with the thumbnail again to the Theme image box.

So users see a theme image in the box, but if they make the album they don’t see a theme image, because I used this code:
<%	path = currentFolder.getProperties().get("themeImagePath"); 
	imgTheme = "folderimage.jpg";
%> 
<ja:if test="<%= !isEmpty(path) %>">
<div class="themeImage">
which was correctly working in the previous version.

In my opinion the previous version with the ‘Remove’ function was the correct implementation, but I guess you got protests in the secret section of this forum.

I notice too that variables themePath, themeWidth and themeHeight are void if you put
engine.setThemeImageProcessor(new ThemeImageProcessor()); in init.htt instead of in init.bsh
I don’t want it in init.bsh, because in that case is the image always generated, which I don’t like for the reasons I told you above. I had to invent this myself, because you did not answer my questions about this topic above.

Another reason to stop with the current theme image implementation is the fact that the skin can no longer be used under version 14, because you did not implement all required code in the core of jAlbum as I advised.

Edit:
The last point can be solved via a flag
themeImageSupport= internalVersion.startsWith("15");


Edited by: AndreWolff on 17-Nov-2017 11:56

Edit:
I don’t understand why your new ‘Reset’ function does not result in a dimmed copy of the thumbnail image. It should in that case be possible to un-dim the thumbnail theme image by dragging the thumbnail image to the Theme image box and use it as Theme image.
And I do not understand why you did not implement both a 'Reset' and a 'Remove' menu item if you think that a 'Reset' function is required.

Edited by: AndreWolff on 17-Nov-2017 12:37
karlmistelberger

Posts: 580
Registered: 5-Dec-2013
Re: jAlbum 14.2 beta for testing
Posted: 17-Nov-2017 10:01   in response to: davidekholm in response to: davidekholm
davidekholm wrote:
Hi all,

I'm pleased to tell you that we've now reached "release candidate" stage, and it's going to be jAlbum 15, not 14.2 as there has been major changes. Here are updated installers for you to test: Windows , Mac and zip.


Downloaded and installed zip. Built album Tiger using v14.1.11. Rebuilt using v15rc1. Making changes resulted in rebuild of all jpegs. :-(
jGromit

Posts: 7,488
Registered: 31-Jan-2006
Re: jAlbum 14.2 beta for testing
Posted: 17-Nov-2017 14:11   in response to: davidekholm in response to: davidekholm
davidekholm wrote:
Fixed behavior of the theme image selector. It's now always reflecting the representing folder image unless the skin supports separate theme images. It's never blank unless the folder doesn't contain any images.

The switch from Remove to Reset is a surprise, but makes sense, given how the core actually works. I assume the Reset button is going to get some sort of graphic in the released version, rather than the current blank to the left of the tooltip.

Tests out just fine. It's true that a folder can't have no theme image - if the skin tells jAlbum to generate theme images, there will be one for every folder, no matter what. Whether or not the skin chooses to use it is entirely up to the skin. I can imagine a skin with options like, "use a theme image only at the top level," or "use the top-level theme image for all folders." With a custom UI, the skin could also offer the "don't use a theme image for this folder" option.

Here's a quickly slapped-together example, using Minimal as its basis. The size of the theme image is controlled by a checkbox on the About tab (dumb location, but this is just for testing). Unchecked, and the theme image is 1600x200 - checked, it switches to 1600x400. Again, not a real-world example, but just for demo purposes.

A quick demo album. At the top level, the theme image is included in the gallery. The folder thumbnail is different from the theme image used for that folder, and the folder theme image is excluded from the gallery.

https://jgromit.jalbum.net/simpleTI/

The magic is in skin.properties (to tell jAlbum that it supports separate theme images), onload.bsh (to set the size), init.bsh (to trigger production of theme images), and index.htt (to generate the folder-level CSS). Most of the index.htt CSS could be planted in common.css, instead, but not the selection of the background image URL, which has to point to the current folder.

Edit: The CSS call for ${themeHeight} also needs to stay in index.htt, rather than common.css, because it's folder-specific. It doesn't even exist when common.css is being processed. You could use a skin variable derived from folderImageSize instead, of course, and plant it in common.css.
RobM

Posts: 3,170
Registered: 4-Aug-2006
Re: jAlbum 14.2 beta for testing
Posted: 17-Nov-2017 14:36   in response to: jGromit in response to: jGromit
jGromit wrote:
I can imagine a skin with options like, "use a theme image only at the top level," or "use the top-level theme image for all folders." With a custom UI, the skin could also offer the "don't use a theme image for this folder" option.
A way of updating the gui so that the affected theme image thumbnails are greyed out, giving visual feedback to the user, would be nice.
davidekholm

Posts: 3,562
Registered: 18-Oct-2002
Re: jAlbum 14.2 beta for testing
Posted: 17-Nov-2017 18:57   in response to: RobM in response to: RobM
RobM wrote:
jGromit wrote:
Just keep putting up those easy lobs, eh?
I like to make things easy for you :)

David: The folder properties title field is still not showing a different coloured background to the pane itself, unless you click on the hidden area. It should match the description field, see attached.


Thanks. Now fixed if you update the beta core file.
davidekholm

Posts: 3,562
Registered: 18-Oct-2002
Re: jAlbum 14.2 beta for testing
Posted: 17-Nov-2017 19:15   in response to: AndreWolff in response to: AndreWolff
AndreWolff wrote:
You replaced the ‘Remove’ menu item by ‘Reset’, so it is no longer possible to remove the theme image.

True. A "Remove" may be added later on popular demand. What we have now is a good default behavior so users don't need do perform two drag operations just to get the same theme image as representing folder image (like the vast majority is ok with)

If you apply the new ‘Reset’ function, the theme image is replaced by a theme image based on the Thumbnail, however
path = currentFolder.getProperties().get("themeImagePath"); 
returns void,

Or rather "null". Yes it should. That API is designed to only deliver a path if a different theme image has been explicitly set. To not have to care whether a theme image has been explicitly set, i.e. to simply get the image that shows in the theme image selector, use the JAlbumUtilities.getThemeObject(AlbumObject folder) API call. It only returns null if the folder you pass as argument is empty.

even if I drag the image which corresponds with the thumbnail again to the Theme image box.

That's by design. Dragging the same image as the representing folder image onto the theme image selector provides the same effect as right clicking the theme image selector and selecting "Reset". It means that you don't want a separate theme image. From now on, the theme image selector will follow whatever you drag onto the representing folder selector.

So users see a theme image in the box, but if they make the album they don’t see a theme image, because I used this code:
<%	path = currentFolder.getProperties().get("themeImagePath"); 
	imgTheme = "folderimage.jpg";
%> 
<ja:if test="<%= !isEmpty(path) %>">
<div class="themeImage">
which was correctly working in the previous version.

Use my new JAlbumUtilities.getThemeObject API instead. It follows the behavior of the UI perfectly. Later down the road we can add a "Remove" option to the context menu of the theme image selector so one is able to exclude theme images for certain folders. I consider those the exceptions though.

In my opinion the previous version with the ‘Remove’ function was the correct implementation, but I guess you got protests in the secret section of this forum.

No, that's just a conspiracy theory. I've been very transparent with this design. It's prioritizing the behavior of the now updated Tiger skin, which is our default skin. In not against providing a way to explicitly tell that you don't want a theme image for a certain folder in the future. I've explained how I intend to solve that with a "Remove" option, but it's not coming in the closest release.

I notice too that variables themePath, themeWidth and themeHeight are void if you put
engine.setThemeImageProcessor(new ThemeImageProcessor()); in init.htt instead of in init.bsh

There is no init.htt in jAlbum. Did you perhaps mean index.htt? That should work, but I recommend to put it in init.bsh or init.js depending if you use BeanShell or JavaScript as scripting language.

I don’t want it in init.bsh, because in that case is the image always generated, which I don’t like for the reasons I told you above. I had to invent this myself, because you did not answer my questions about this topic above.

You can either us the implementation I posted to control what folders to generate theme images for or not or subclass the existing ThemeImageProcessor and adjust what folders it applies to.

I don’t understand why your new ‘Reset’ function does not result in a dimmed copy of the thumbnail image. It should in that case be possible to un-dim the thumbnail theme image by dragging the thumbnail image to the Theme image box and use it as Theme image.
And I do not understand why you did not implement both a 'Reset' and a 'Remove' menu item if you think that a 'Reset' function is required.

Well, we can go on for years to polish the UI behavior too, but eventually one has to get things out the door too.

davidekholm

Posts: 3,562
Registered: 18-Oct-2002
Re: jAlbum 14.2 beta for testing
Posted: 17-Nov-2017 19:17   in response to: karlmistelberger in response to: karlmistelberger
karlmistelberger wrote:
davidekholm wrote:
Hi all,

I'm pleased to tell you that we've now reached "release candidate" stage, and it's going to be jAlbum 15, not 14.2 as there has been major changes. Here are updated installers for you to test: Windows , Mac and zip.

Downloaded and installed zip. Built album Tiger using v14.1.11. Rebuilt using v15rc1. Making changes resulted in rebuild of all jpegs. :-(


Yes, I'm sorry about this inconvenience. It will happen when making the move from older versions to v15, but it should hopefully not happen anymore thereafter. I've taken measures to avoid it.
davidekholm

Posts: 3,562
Registered: 18-Oct-2002
Re: jAlbum 14.2 beta for testing
Posted: 17-Nov-2017 19:20   in response to: jGromit in response to: jGromit
jGromit wrote:
davidekholm wrote:
Fixed behavior of the theme image selector. It's now always reflecting the representing folder image unless the skin supports separate theme images. It's never blank unless the folder doesn't contain any images.

The switch from Remove to Reset is a surprise, but makes sense, given how the core actually works. I assume the Reset button is going to get some sort of graphic in the released version, rather than the current blank to the left of the tooltip.


It should show as a context popup menu if you right click the control.

Tests out just fine. It's true that a folder can't have no theme image - if the skin tells jAlbum to generate theme images, there will be one for every folder, no matter what. Whether or not the skin chooses to use it is entirely up to the skin. I can imagine a skin with options like, "use a theme image only at the top level," or "use the top-level theme image for all folders." With a custom UI, the skin could also offer the "don't use a theme image for this folder" option.

True. I'll probably add a "Remove" option too to the context menu, but the default behavior should be to always suggest a theme image.

Here's a quickly slapped-together example, using Minimal as its basis. The size of the
...

Thanks!
AndreWolff

Posts: 1,713
Registered: 14-Dec-2007
Re: jAlbum 14.2 beta for testing
Posted: 17-Nov-2017 19:32   in response to: davidekholm in response to: davidekholm
davidekholm wrote:
There is no init.htt in jAlbum. Did you perhaps mean index.htt? That should work, but I recommend to put it in init.bsh or init.js depending if you use BeanShell or JavaScript as scripting language.
Yes I did mean index.htt
And it does not work, you can test it with enclosed jaskin file
AndreWolff

Posts: 1,713
Registered: 14-Dec-2007
Re: jAlbum 14.2 beta for testing
Posted: 17-Nov-2017 19:41   in response to: davidekholm in response to: davidekholm
davidekholm wrote:
True. A "Remove" may be added later on popular demand.
I guess I am not popular enough to get this request implemented
AndreWolff

Posts: 1,713
Registered: 14-Dec-2007
Re: jAlbum 14.2 beta for testing
Posted: 17-Nov-2017 19:44   in response to: davidekholm in response to: davidekholm
davidekholm wrote:
To not have to care whether a theme image has been explicitly set, i.e. to simply get the image that shows in the theme image selector, use the JAlbumUtilities.getThemeObject(AlbumObject folder) API call. It only returns null if the folder you pass as argument is empty.
I told you already earlier, that I don't understand your API documentation, so this is no solution for me.
AndreWolff

Posts: 1,713
Registered: 14-Dec-2007
Re: jAlbum 14.2 beta for testing
Posted: 17-Nov-2017 19:47   in response to: davidekholm in response to: davidekholm
davidekholm wrote:
Well, we can go on for years to polish the UI behavior too, but eventually one has to get things out the door too.
Yes I understand that, but you see no problem in replacing at the very last moment a 'Remove' option into a 'Reset' option!
jGromit

Posts: 7,488
Registered: 31-Jan-2006
Re: jAlbum 14.2 beta for testing
Posted: 17-Nov-2017 20:00   in response to: davidekholm in response to: davidekholm
Attachment ss003390.png (47.1 KB)
davidekholm wrote:
It should show as a context popup menu if you right click the control.

Ah, got it. With only option, however (see screenshot), it makes for rather a strange-looking context menu. It looks like there's something missing ;)

True. I'll probably add a "Remove" option too to the context menu, but the default behavior should be to always suggest a theme image.

That would be simpler than the skin using a custom UI checkbox, "Don't use a theme image for this folder." The skin could just check for the existence of themePath. I suspect it will end up being a fringe case, in any event, one of those things that appeals to a skin developer, but that no user ever changes.

Not using a theme image in only certain folders might also create some awkward layout choices for a skin. What should be there, a blank box with some sort of background color? Same size as the theme image would be? In both Gromit and Matrix (as currently written), not using a theme image intentionally produces a very different layout.
AndreWolff

Posts: 1,713
Registered: 14-Dec-2007
Re: jAlbum 14.2 beta for testing
Posted: 17-Nov-2017 20:04   in response to: jGromit in response to: jGromit
jGromit wrote:
And BTW, if you're producing a responsive page, putting your theme image in as a regular <img> is the road to heartache.
Not for me
In short, as the viewport narrows, you want the theme image to remain the same height
Why?

But I let the user decide, if he likes to use the theme image as background, he gets it, see this example album.

But if he likes to handle as an image he gets it too, see this example album.
Legend
Forum admins
Helpful Answer
Correct Answer

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