On an iPhone 4, when a gallery is displayed in Safari, and then one of the thumbnail clicked on, you can return to the thumbnail-only display by clicking on the thumbs navigation icon.

However, if you click on the one of the thumbnails, view one or more full-screen images, and then click on the Hide Info button before clicking on the thumbs navigation icon, when you do click on that thumbs nav icon, the screen goes blank and nothing seems to happen.

At least this seems to be the case with me. (JB 1.0.2, via the skin in jAlbum, but I thought I'd report it here.)

Bill

Opera is 11.64.

Yep, image 2 (and 1) fill the screen when it resized smaller. However, the image fills the screen when it's maximized, too. That is, I can no longer reproduce the problem. Don't know what to say...

Bill

Steven,

Thanks for your reply. I'm pretty sure I follow what you're saying. And I certainly don't want to use FILL; it may have uses, but not for me.

However, consider the following, please.

I reconfigured my typical Firefox add-ons to match - pretty much - the viewing window in Opera. I opened my test page, http://www.billanddot.com/aspect-test/ , in both browsers, hid the thumbnails and info, and took full desktop screen shots. Here they are:

http://www.billanddot.com/firefox-desktop.jpg
http://www.billanddot.com/opera-desktop.jpg

The fact that the browser bars and suchlike take up about the same space is one thing. But regardless, what I don't understand, what I can't get my head around, is how there's extra room at the bottom of that image 2 in Opera. The image is MUCH larger than my monitor can handle without scroll bars. So what perplexes me is why Opera doesn't make it bigger - in my particular case - such that it consumes the full height available (as is the case with Firefox and the other browsers). If Opera made it taller, such that it took up the full height, it would have to make it wider. Well, there is plenty of left- and right-side room left over; that is, while preserving the aspect ratio of that image, if Opera were to make it taller, it would have no problem, in terms of available space, with the concomitant increased width that would bring. So why doesn't it (ala Firefox, et al.)?

You follow me? It sure seems like a bug to me, either in Opera or in what Juicebox is telling it to do.

Bill

Here's a test gallery for you, with a mere two images: http://www.billanddot.com/aspect-test/ . These are not resized (not my usual practice - this is only a test); the first image is 2592 x 1944 and the second is 3888 x 2592.

If I look at this page on my (32-bit Vista) PC's (1440 x 900) monitor, and click the Hide Thumbnails button, I encounter no quirks in the latest versions of IE, Firefox, Safari, and Chrome. However, if I do this in Opera, image 2/2 does not take up the full height of the browsing window.

Pick one:

A) The software (JB) works as intended, and I don't really understand what's supposed to be happening in this case.
B) There's a tiny bug in JB, and only Opera strictly enforces some standard that the other browsers let slide.
C) There's a tiny bug in Opera, manifesting itself only in rare circumstances.
D) None of the above.
E) Some or all of the above.

Cheers,

Bill

130

(3 replies, posted in Juicebox-Pro Support)

However - if I understand the poster's intent - it IS possible to accomplish the same thing by using Juicebox (with Pro Options) in jAlbum. Save a gallery set up the way you like it as the Default in jAlbum, and then when you plop images as the start of a new gallery, you'll be all set. It's what I've been doing off and on for the last week, converting my web picture pages from using some old software to JB-Pro via jAlbum.

Bill

131

(496 replies, posted in Juicebox-Pro Support)

Steven wrote:

@wspollack

(with the possible exception of some really thin borders that seem to have appeared around the thumbnails, but I'm ignoring that for now)

Add the word 'closeups' to your filters to ensure that the drop-shadows are applied only to your main images and not the thumbnails.

filter1 class=XBorderFilter shWidth=23 shTrans=10 shDrop=soft shCol=black bgCol=#E6D4BA shDir=SE closeups
filter2 class=XBorderFilter shWidth=23 shCol=#E6D4BA bgCol=#E6D4BA shDir=NW closeups

That did the trick. Thanks again.

Bill

132

(496 replies, posted in Juicebox-Pro Support)

wspollack wrote:
Steven wrote:

The default drop-shadow will barely be visible (if at all) on a background color of #222222.
Try using a background color of #ffffff (with all other settings default) and the drop-shadow should be visible. (It is quite subtle, even on a white background.)

Um, yeah, okay, "subtle." Can we agree that that capability needs work? And - I may be stretching things here - that it should have some setting capabilities in the main interface, as opposed to fiddling with the CSS file?

Thanks for the response, in any case.

Well, for now, I've settled on using the Juicebox skin in jAlbum, as it facilitates uploads to my server and - most importantly - has that Hi-Res link to the full-size originals capability built in, when opening an image in a new window.

Back to the drop shadow issue. With a nudge in the right direction from both you and EarlyOut (see http://jalbum.net/forum/thread.jspa?threadID=41926 ), I now use two User Variables in the skin's Settings -> Advanced box:

filter1 class=XBorderFilter shWidth=23 shTrans=10 shDrop=soft shCol=black bgCol=#E6D4BA shDir=SE
filter2 class=XBorderFilter shWidth=23 shCol=#E6D4BA bgCol=#E6D4BA shDir=NW

I like this, and it appears to work nicely, as long as you don't step on it with other Juicebox settings (e.g., I removed frameWidth, imageFrameColor, and imagePadding from the Pro Options area).

Using those two filter calls and Pro Options of...

galleryTitlePosition=NONE
textColor=FFFFFF
imagePreloading=NEXT
showImageNav=FALSE
maxThumbColumns=50
showAutoPlayButton=TRUE
showInfoButton=TRUE
showNavButtons=TRUE
showBackButton=TRUE
backButtonText=<a href="http://www.billanddot.com/index.htm" target="_top"><img src="http://www.billanddot.com/house.gif" width="24" height="24" alt="Home (Bill &amp; Dot's Excellent Pages)"></a>
backButtonUrl=http://www.billanddot.com/
backButtonPosition=OVERLAY

...I've regenerated and uploaded a new version of http://www.billanddot.com/victory-xct/ , which is the gallery I've been experimenting with, and I think it's all set now as my default for jAlbum (with the possible exception of some really thin borders that seem to have appeared around the thumbnails, but I'm ignoring that for now).

Bill

133

(496 replies, posted in Juicebox-Pro Support)

Some comments on Juicebox-Pro vs. SimpleViewer-Pro, and some philosophical comments. As other posters have pointed out, this is not meant to denigrate your work; I like JB, and I want to use it.

What I especially like about JB, vs. SV:

- You can set the preload to one image.
- Non-flash - remote device vs. large screen based on browser size.
- You can embed URLs in comments (which Flash doesn't allow).

What I especially like about SV, vs. JB:

- You can put thumbs on the left.
- You can create drop shadows.
- You can link to Hi-Res (i.e., full-size) images, for separate-page viewing.

Now, before you go telling me about playing with CSS files, let me go into my philosophical position. Yes, I've been told about the extended capabilities of messing outside the regular gallery interface. And I appreciate your telling me about these capabilities, as I might actually use that information.

But I don't want to. If I wanted to roll my own, I could just use a text editor, and write all the HTML and CSS I was capable of writing, and dispense with JB, SV, et al., completely. I don't have the time or expertise to do that, at least not in all cases. What I want, OTOH, is a program that does it all, using a nice interface. I don't want to have to go "outside" that interface; I want all of my possible choices and options right there.

So, I hope that this is your ultimate goal, too. While you've told me that such-and-such a capability is possible outside of the gallery-building interface, you haven't said something like, "But in a future release we plan to incorporate such-and-such capability into the standard interface." And I wonder about that. In the meantime, I think my default family-gallery program will continue to be SV, and JB will be my experimental-only program.

Thanks for listening,

Bill

134

(496 replies, posted in Juicebox-Pro Support)

As a result of reading this forum, I just upgraded from 1.0.0 to 1.0.2. I'd like to have the capability (maybe an option) of having the program check for - and then, given the okay by the user, download, and then install - a new version when it's fired up. More and more programs seem to have this capability these days, and I find that very convenient.

Bill

135

(496 replies, posted in Juicebox-Pro Support)

Steven wrote:

@wspollack

When the user clicks on the 'Open Image in New Window' button, Juicebox will open the corresponding linkURL in the 'config.xml' file. (If the linkURL is empty, Juicebox will simply open the imageURL itself.)
You can, therefore, include a 'Hi-Res' folder of larger-sized images and use the linkURL entries in the 'config.xml' file to point to them. (This would have to be done manually as there is currently no automated way to achieve this.)

Steven,

Thanks for the tip. Maybe I'll write some script, in an attempt to make this less cumbersome.

Bill

136

(496 replies, posted in Juicebox-Pro Support)

I'd like to be able to have full-size images for the "Open Image in New Window" navigation function. That is, rather than simply open the currently viewed image in another window (or tab), I'd like that function to link to an original image. SimpleViewer can do this, with its "Hi-Res" subdirectory of images, and I'd like the same sort of thing here.

I realize I can have an original full-size image opened in a new window if I set the image limitations to some value larger than the pixels of my largest images. However, this would require that these large images be downloaded every time that someone views the gallery in normal mode, slowing down loading.

I also realize that implementing my suggestion would require that more space be used when building the gallery, but that's okay with me.

Currently - testing - I have the images initially resized at a 1024 max. Opening in a new window, and then clicking on that image, really doesn't make it much larger. I'd like viewers (family members, mostly) to be able to save the original-sized images, in case they want to make large prints.

Bill

I did my first playing around with the Save and Load Preset capability today. I saved a gallery I was finished with as a preset, shut down the program, and later on ran the program again. I then did this:

- New Gallery.
- Browsed to and then loaded some images.
- Loaded the preset.
- Clicked on Customize.

The first image is shown (naturally), and super-imposed at the top of the program's window - on that and all subsequent images - appears to be (sort of) the html code I entered on my saved preset for using an image for the Back Button. I closed the program and re-ran a few times, and this happens each time I load that preset.

I took a screen shot of that situation, and I've posted it here: http://www.billanddot.com/JuiceboxBuild … loaded.jpg . (This sort of thing would be a tad easier if we were allowed to upload pics here, as part of our posting. But I digress.)

I then shut down the program, ran it again, and this time opened the existing gallery - the one I saved as a preset. The actual entry in that gallery's Back Button Text is this:

<a href="http://www.billanddot.com/index.htm" target="_top"><img src="http://www.billanddot.com/house.gif" width="24" height="24" alt="Home (Bill &amp; Dot's Excellent Pages)"></a>

Cheers,

Bill

138

(496 replies, posted in Juicebox-Pro Support)

I'd like an option to leave the Back Button text or image visible and functional when the Back positioning is OVERLAY and the Hide Information nav button is invoked. While the Back Button position can be TOP, using that positioning cuts down on the size of the main image (when the nav buttons are positioned in OVERLAY, anyway), so is not a desirable solution for me. And of course the nav buttons themselves are still visible when hiding information; in OVERLAY, the Back area is at the same height as the nav buttons, and I think typically will be over on the left - just as the nav buttons will be over on the right - and so will not interfere with viewing the main image any more than the nav buttons. That is, I'd like an option such that Hide Information works only on the "lower" info, e.g., the caption.

Cheers,

Bill

Steven,

Okay, will do, momentariyly. Thanks for the explanation.

Bill

I'm not sure whether you consider this a feature or a bug - my opinion is the latter - but when clicking the "Hide Information" navigation button, the Back Button area disappears. At least this is what happens on my main testing gallery, which uses a small image for "back" purposes, and it and the navigation area are positioned as OVERLAYs.

I'd like the back information to remain visible (or at least an option for this) when hiding the caption display.

Cheers,

Bill

Felix wrote:

thanks for the report. Have replicated and added to our bug list.

Excellent. FYI, I've now changed the layout of that gallery a bit, so the problem no longer manifests itself there.

Bill

142

(496 replies, posted in Juicebox-Pro Support)

Steven wrote:

The default drop-shadow will barely be visible (if at all) on a background color of #222222.
Try using a background color of #ffffff (with all other settings default) and the drop-shadow should be visible. (It is quite subtle, even on a white background.)

Um, yeah, okay, "subtle." Can we agree that that capability needs work? And - I may be stretching things here - that it should have some setting capabilities in the main interface, as opposed to fiddling with the CSS file?

Thanks for the response, in any case.

143

(496 replies, posted in Juicebox-Pro Support)

Felix wrote:

2) Drop-shadow capability for the main image.

The Juicebox main image does have a drop shadow by default. To modify the drop-shadow CSS, check the themeing section here: http://juicebox.net/support/theming/ The main image drop shadow is defined by the ".jb-dt-main-frame .jb-dt-main-image" entry.

.jb-dt-main-frame .jb-dt-main-image {
    -moz-box-shadow: 0px 0px 10px rgba(0, 0, 0, .4);
    -webkit-box-shadow: 0px 0px 10px rgba(0, 0, 0, .4);
    box-shadow: 0px 0px 10px rgba(0, 0, 0, .4);
    border-color: White;
}

I'm going to have to dispute this "by default" statement. I just generated a new gallery, didn't change any defaults at all when creating it, and (in Preview mode) I don't see any drop shadow. My page background is #222222, the image has no border or frame or anything at all - just the straightforward "as is" image against the gallery background.

Did I misunderstand your statement?

Bill

1) When holding down the scroll bar in the Images portion of JuiceboxBuilder Pro, the thumbnails seem to flicker for me (slow downward movement) or disappear completely (more rapid downward scrolling), until I'm done using the scroll bar. Is this just me, intended operation, O/S problem, etc.?

2) When moving one or more images around - again, in the Images section - I can't see any indication of what images that I have selected. This is not a big deal when dragging one image, to reposition it; you just drag it near the top or bottom of the images, and wait for scrolling to commence. This is of slightly bigger consequence when selecting multiple images - Ctrl-click on the second through Nth image - to move; you have no indication which images are selected (until you actually start to drag them, at which time you can see ghostly thumbnails of the images being moved). Usually, when you're selecting something, you'll get a border with a changed color, or something along those lines, to indicate that you have indeed Ctrl-clicked it.

The above pertain to Windows Vista Home Premium SP2.

Cheers,

Bill

Addendum: of course, if you're viewing that page on a monitor with a very high resolution, you may not encounter a problem (because the overlay area may be narrowed down in size). I'm using a monitor with 1440 x 900 resolution, and one of my Firefox add-ons reports that - what with a two-line taskbar menu area, etc. - the browser itself is using an area of 1456 x 856 (which doesn't seem right, given the monitor's 1440 max width).

In any event, you may have to resize the browser window to replicate this problem.

Bill

Okay, I've discovered the problem here. Your image of 2 of 16, for instance, does have a hyperlink ("Juicebox") in the caption, and it works fine. Unlike you, however, when I put a link in:

- I left the Caption -> Max Caption Height at 100... AND
- Had a multi-line caption... AND
- Had the link on the caption's first line... AND
- Like you, was using caption OVERLAY.

From the top of the page, as you hover/slide the mouse down alongside or within the main image - and this will depend on assorted border settings, etc. - either at the top of the image or shortly thereafter, the mouse pointer changes from a pointer to a finger. This is in keeping with its use as a clicker to show the next image.

As the mouse nears the bottom of the image, it changes from a finger back to a plain ol' mouse pointer. Only at that point can it be used to click on a hyperlink (and only then will it show the URL of a hyperlink when hovered). However, if the caption overlay area is too tall, the top of this area - and the first line, in my case - will intrude into the area in which the mouse is next-image-capable, not hyperlink-capable.

This problem is eliminated, of course, if BELOW_IMAGE or BOTTOM is chosen for the Caption -> Caption Position.

What I think should be changed in Juicebox, if at all possible, is to have the mouse revert to a regular browser-page mouse (from a click-me-for-the-next-or-prior-image mouse) at the top of the OVERLAY area (as opposed to some percentage down the page).

If you want to see an example of the problem, look at image 13 at http://www.billanddot.com/victory-xct/ .

Cheers,

Bill

I put up a gallery, and in one of my captions included an <A HREF... </A> string. When published, this resulted in an underlined link, and when hovered over it the mouse pointer changed to its finger-like icon. However, clicking on this didn't do anything.

You folks tried putting a link up in a caption? Is this theoretically supported?

Cheers,

Bill

I've done a lot of work on this, and here is the latest summary:

I've disabled, one by one, each of my Firefox (12.0) add-ons. Then I'd test this problem, then enable the disabled add-on, disable the next one, and repeat. You can see a list of the 11 enabled add-ons I started this test with here: http://www.billanddot.com/firefox-add-ons.jpg . But, as I'll attempt to explain below, I don't think this is an add-on problem.

This test didn't help solve the problem. I really think this is a timing problem within Firefox, and so because some of these add-ons may be more "intensive" than others, I think this may effect how often I have to Refresh Firefox in order to see the partial-image-load problem. And this is why, I think, that I can't duplicate this problem in Firefox's Safe Mode: Firefox then has too little extra work to do, and so responds too quickly for this timing issue to show up.

In case you haven't followed me, I first noticed this problem doing a Gallery -> Preview. However, other times, this works fine, i.e., that first image loads fully. (I've never had a problem with partial loading looking at images 2 - N.) This led me to experiment with using Firefox's Refresh on the local file that Juicebox sent as the URL to Firefox. Pressing Refresh repeatedly - that is, right after I can see that that first image has just finished loading - reveals that the problem sometimes manifests itself, and sometimes doesn't. And that leads me to believe that this is mostly a Firefox problem, because pressing Refresh has nothing to do with Juicebox at that point, right? I suppose it could conceivably have something to do with the actual code that Juicebox generates, and how Firefox interprets that code.

Now, to show you exactly what I'm talking about, I made a video of this situation, and uploaded it to YouTube. It's 35 seconds long, is in real time (no video editing), and is here: http://www.youtube.com/watch?v=NNKp0UHMYs8 . What you will see here, replete with mouse movements and clicks, is:

- I invoke Gallery -> Preview, and Firefox (already running) doesn't completely load that first image;
- I then switch my attention from Juicebox to Firefox, and repeatedly press the Refresh button;
- Most of the time the local page/first image is refreshed fine, and the image loads fully, but a couple times the image does not load fully;
- On the last such partial-load, I hover the mouse (but do not click anything) over the bottom thumbnail area, which hovering magically results in the completion of that partial load (i.e., the image is now fully loaded).

Fin.

I'm not about to disable all my add-ons when I want to preview a gallery; if the preview doesn't load that first image fully, all I have to do is move the mouse down to the thumbnails. So it's not a really big deal. Nevertheless, I'm convinced that there is a bug, somewhere, in Firefox itself, or in the way Firefox handles the code generated by Juicebox, or some combination of this. So I'm reporting it, but I'm done working to isolate it, because I really can't and I haven't got the time.

Hope this helps,

Bill

I emailed that first image last night, but I really don't think that it's relevant. The image partially loads... but to different degrees. It strikes me as some sort of timing issue, bug, quirk, etc. in Firefox 12.0.

When I do a Gallery -> Preview, virtually all the time (or maybe actually all the time), that first image loads, from its top down, maybe a fifth of the way. If I press Firefox's Refresh button, the image re-loads, but maybe to a slightly different point, e.g., maybe this time a quarter of the way down.

I have discovered this: in order to complete the picture's loading, it's sufficient to hover the mouse over ANY thumbnail. And - this is new - another way to complete the loading is to hover the mouse of an UNUSED area in that top area of FF, the area where a new tab would appear (i.e., hover anywhere to the right of the tab that's being used for the preview page).

Doing this hovering somehow "unfreezes" whatever is being "frozen" during the initial load.

Bill

EDIT: I just deleted that first image from the gallery. Now, a Gallery -> Preview reveals the same problem with the formerly-second-but-now-first image. The partial loading doesn't always happen, but it happens most of the time.

EDIT2: Pressing the Windows key also allows the load to complete.

EDIT3: I just did a screen-capture for you folks. Here's what it looks like when it "sticks" at a partial load, before hovering over the thumbnail area, pressing the Windows key, etc.: http://www.billanddot.com/partial-load.jpg

EDIT4: I CANNOT get FF to exhibit this problem in its Safe Mode (i.e., add-ons, of which I have a lot, disabled). So, this MAY be a problem with a specific add-on, or else it's still a bug somewhere that involves a timing issue (and having the add-ons disabled just makes FF process the page faster, perhaps avoiding - but not solving - the problem). I will experiment with individual add-ons disabled in a bit...

150

(496 replies, posted in Juicebox-Pro Support)

I'd like to see navigation choices for going to the first and last images. Currently, you can do this via keyboard-control keys Home and End; I like that, but there's no way for the end-user to know about those keys, so I think having them as navigation-bar choices would be beneficial.

Bill