Posts:
4,065
Registered:
18-Oct-2002
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
2 May 20, 10:13
in response to: JeffTucker
|
|
|
I'll have to leave this until tomorrow, but it's still downright byzantine. I can still paste a title into a comment field, for example.
This doesn't seem like an improvement, to me. This introduces a new level of complexity, and a bunch of opportunities for screwing up. And I'm not at all clear about what the benefit is, for 99.99% of jAlbum users.
This gives me a strong feeling we have two very different experiences. Let me show you what I see using this video. You then show me what YOU see:
http://jalbum.net/download/beta/multi-paste.mp4
The way I see it, this IS indeed a true time-saver for those who want to apply the same metadata to multiple images, isn't it? |
|
|
Posts:
4,065
Registered:
18-Oct-2002
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
2 May 20, 10:29
in response to: JeffTucker
|
|
|
I'll have to leave this until tomorrow, but it's still downright byzantine. I can still paste a title into a comment field, for example.
Only if you enter a target text field and select Paste, then it behaves as an ordinary textual copy/paste operation just like if you'd copied the metadata into the clipboard as a text string. I can disable this ability, but why? Titles, comments, creators etc are also strings. The ODD behavior was to also paste the same metadata into other fields while you have ONE target field focused. |
|
|
Posts:
4,071
Registered:
4-Aug-2006
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
2 May 20, 13:14
in response to: davidekholm
|
|
|
I'm seeing it on my Mac, much better than before. |
|
|
Posts:
8,023
Registered:
31-Jan-2006
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
2 May 20, 14:45
in response to: RobM
|
|
|
Better on the second attempt. But I suspect most users are adding things like Creator and Copyright in another application (Lightroom, e.g.), and we already have some pretty decent tools for copying Title and Comment to other objects.
But I'm noticing some other things in the Detail view that need help:
- Use CTRL-A to select all of the thumbnails. Now try to select just one thumbnail again. In effect, you almost have to get out of the Detail view to do it. It's OK if you CTRL-click one object, then click another object - then you're back to just one selected.
- The Added field - what is that trying to pick up? I thought it would be "when added to the project," but it's clearly not. It's not editable, either. If it were actually the date the object was added to the project, it would be nice to be able to alter it, to affect "new" markers, for example.
- Right-click an object, and choose Details, Copy. Now choose several other objects, right-click, and choose Details, Paste. It appears to be grabbing only Comment, unless I'm missing something.
- Right-click an object. Unlike the "regular" view, there are no context menu items for Comment (remove, copy, paste) or Title. The new capability is perhaps more direct, but once again, things are very inconsistent between different views.
|
|
|
Posts:
4,065
Registered:
18-Oct-2002
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
2 May 20, 21:18
in response to: JeffTucker
|
|
|
Better on the second attempt. But I suspect most users are adding things like Creator and Copyright in another application (Lightroom, e.g.), and we already have some pretty decent tools for copying Title and Comment to other objects.
Could be, but many users like to be able to use one tool for many tasks.
But I'm noticing some other things in the Detail view that need help:
- Use CTRL-A to select all of the thumbnails. Now try to select just one thumbnail again. In effect, you almost have to get out of the Detail view to do it. It's OK if you CTRL-click one object, then click another object - then you're back to just one selected.
You can click between two thumbnails to deselect everything, but I agree with you that simply single-clicking with the left mouse button on an item without holding down CTRL or SHIFT should deselect all other items.
* The Added field - what is that trying to pick up? I thought it would be "when added to the project," but it's clearly not. It's not editable, either. If it were actually the date the object was added to the project, it would be nice to be able to alter it, to affect "new" markers, for example.
I could make it editable. It's representing when that item is first appearing in an album build.
* Right-click an object, and choose Details, Copy. Now choose several other objects, right-click, and choose Details, Paste. It appears to be grabbing only Comment, unless I'm missing something.
Ah, I haven't updated that tool since the introduction of the Details view. I should probably simply disable that context menu item when in Details view mode. |
|
|
Posts:
8,023
Registered:
31-Jan-2006
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
2 May 20, 21:37
in response to: davidekholm
|
|
|
I could make it editable. It's representing when that item is first appearing in an album build.
That's close to "normal:" is it not using the "when added" date in albumfiles.txt? Both Laza and I have "newness" indicators that are based on the "when added to the project" date, so I was expecting this field to show the same thing. And in some of my skins, I've included a Make New and Make Old button, so that objects can be made to appear new, or can be buried (an old image that was just added to the project, but that isn't really "new"). That's why I thought it could be editable. |
|
|
Posts:
4,065
Registered:
18-Oct-2002
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
4 May 20, 07:48
in response to: JeffTucker
|
|
|
I could make it editable. It's representing when that item is first appearing in an album build.
That's close to "normal:" is it not using the "when added" date in albumfiles.txt?
It should, but that number isn't usually written until that folder is visited during an album build
Both Laza and I have "newness" indicators that are based on the "when added to the project" date, so I was expecting this field to show the same thing. And in some of my skins, I've included a Make New and Make Old button, so that objects can be made to appear new, or can be buried (an old image that was just added to the project, but that isn't really "new"). That's why I thought it could be editable.
I see no danger in making this field editable. I'll fix that in the next version. |
|
|
Posts:
8,023
Registered:
31-Jan-2006
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
4 May 20, 14:10
in response to: davidekholm
|
|
|
That's close to "normal:" is it not using the "when added" date in albumfiles.txt?
It should, but that number isn't usually written until that folder is visited during an album build
Until that file is written, perhaps the field should be blank, or show the current time, rather than the fictitious 1-1-1970 date (or in my time zone, 12-31-1969).
There's a also a problem of delayed feedback. Add a few images. Choose one of my skins, like Neptune. Open an image for editing, open the Neptune custom UI panel on the right, and click Make Old, which resets the date added to 1-1-70 (zero milliseconds), or click Make New, which resets it to the current system time. Then come back to the Explore view. The Added date doesn't get updated until you hit F5. |
|
|
Posts:
4,065
Registered:
18-Oct-2002
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
4 May 20, 20:11
in response to: JeffTucker
|
|
|
jAlbum 20.1b3 now available at http://jalbum.net/download/beta/jalbum-core.jar
Changes:
- Displays a blank "When added" field if date hasn't been written yet (happens on first folder visit during album builds)
- "When added" and "Last modified" are now editable
- The selection manager has been updated to automatically deselect other items if you click on an item without holding down SHIFT or CTRL. Previously (since the dawn of time) jAlbum would leave other items selected if you clicked on an already selected item. This change has been made to comply with the behavior or Explorer and Finder and to ensure that you will safely know that single clicking on an item (without CTRL or SHIFT) will guarantee that that item and no other items are selected (good for the new multi-paste behavior)
|
|
|
Posts:
8,023
Registered:
31-Jan-2006
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
4 May 20, 20:20
in response to: davidekholm
|
|
|
- The selection manager has been updated to automatically deselect other items if you click on an item without holding down SHIFT or CTRL. Previously (since the dawn of time) jAlbum would leave other items selected if you clicked on an already selected item. This change has been made to comply with the behavior or Explorer and Finder and to ensure that you will safely know that single clicking on an item (without CTRL or SHIFT) will guarantee that that item and no other items are selected (good for the new multi-paste behavior)
Oops, that has an unintended consequence. Select five items. Now try to click and drag them somewhere. 
Shift-click still works to drag a group of items, but that may be too high a price to pay. Not sure what the best behavior would be.
ETA: The problem is that the former behavior was fine in the non-detail view, where there's plenty of "between the thumbnails" space, but in the detail view, it's less obvious how to de-select a group. On balance, I think I'd vote for "back to the way it was," but I wonder how others feel.
The Added behavior is now much better. 
Edited by: jGromit on 04-May-2020 14:30 |
|
|
Posts:
8,023
Registered:
31-Jan-2006
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
4 May 20, 20:52
in response to: JeffTucker
|
|
|
|
I've just been tinkering with File Explorer, and its behavior is very good. Select 10 items. Now click on one of them, and it switches to selecting just that one. But if you select 10 items, then click and hold, you can drag all 10 somewhere else. Don't know how tough it would be to emulate that....
|
|
|
Posts:
4,065
Registered:
18-Oct-2002
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
4 May 20, 22:50
in response to: JeffTucker
|
|
|
Oops. How come I didn't spot that during testing?
... and now I get jAlbum's classic behavior in Finder, but Explorer does it the way it was intended. The logic seems to look for mouse-release events that are fired straight after a mouse-pressed event with no mouse drag events in between. I'll try to emulate that. |
|
|
Posts:
4,065
Registered:
18-Oct-2002
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
5 May 20, 00:48
in response to: davidekholm
|
|
|
Try b4 now.
I found a (really I assume) old bug: Sometimes when dragging objects around, only one of the objects stay selected after a completed drag. I'll look into that tomorrow (actually later today  ) |
|
|
Posts:
8,023
Registered:
31-Jan-2006
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
5 May 20, 01:00
in response to: davidekholm
|
|
|
Try b4 now.
Yes, that seems to be well-behaved.
Then again, I started drinking almost 90 minutes ago, so what do I know about proper behavior? |
|
|
|
Legend
|
|
Forum admins
|
|
Helpful Answer
|
|
Correct Answer
|
|
