Posts:
8,320
Registered:
31-Jan-2006
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
5 May 20, 13:43
in response to: davidekholm
|
|
|
|
Only one little oddity that I've noticed. In the regular File name view, create a folder, and also have three images at the top level - pic1, pic2, and pic3. Click and drag pic1 into the folder. Now, pic2 is highlighted. There shouldn't really be any object selected at this stage.
|
|
|
Posts:
4,310
Registered:
4-Aug-2006
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
5 May 20, 23:13
in response to: davidekholm
|
|
|
Some observations purely as a result of messing about doing general drag and drop testing, these things happen in previous versions, so are not specifically beta comments.
In details view when moving an item so it becomes the first item, there is no bar/line(as you see moving item 3 to 2 for example) to indicate when to drop the moved item. The item can be dropped as the first object though.
If you drag an object, say an image, onto its parent folder in the project pane you get an error, But if you copy and paste the image in the same folder you get a copy. Both actions are really the same, so maybe the error should be replaced with a copy?
You can use thumbnail/more context menu to do a ‘Save as’ to the file system. It works for images but not videos, folders etc. why? A keyboard modifier, like CMD/CTRL, allowing you to drag and drop copies of files from jAlbum would be nice. Related, dragging the folder thumbnail/theme image from jAlbum to the file system removes the image from jAlbum, but pressing F5 does not update the thumbnail or theme images.
Click on an image or folder to select it, now click in a space to deselect it. Now hold shift key down and click on a different object, all objects from the previously clicked item to the last one clicked are selected. Could be a bit of a surprise as the previously clicked image is remembered if you switch projects and then go back to it, quitting jAlbum does forget the first clicked item. |
|
|
Posts:
4,255
Registered:
18-Oct-2002
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
6 May 20, 12:20
in response to: JeffTucker
|
|
|
Only one little oddity that I've noticed. In the regular File name view, create a folder, and also have three images at the top level - pic1, pic2, and pic3. Click and drag pic1 into the folder. Now, pic2 is highlighted. There shouldn't really be any object selected at this stage.
I agree, but that's an ancient bug. Now basically fixed in the current beta. |
|
|
Posts:
8,320
Registered:
31-Jan-2006
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
6 May 20, 14:46
in response to: davidekholm
|
|
|
Only one little oddity that I've noticed. In the regular File name view, create a folder, and also have three images at the top level - pic1, pic2, and pic3. Click and drag pic1 into the folder. Now, pic2 is highlighted. There shouldn't really be any object selected at this stage.
I agree, but that's an ancient bug. Now basically fixed in the current beta.
We used to refer to those as "edge effects." You'd have a nice, clean routine for dealing with something of length i, but then at least half the code was dedicated to dealing with what happens at item[0] or item[i - 1]. |
|
|
Posts:
4,255
Registered:
18-Oct-2002
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
7 May 20, 10:23
in response to: JeffTucker
|
|
|
We used to refer to those as "edge effects." You'd have a nice, clean routine for dealing with something of length i, but then at least half the code was dedicated to dealing with what happens at item[0] or item[i - 1].
Yes, that's typical for robust code. Half of the code deals with corner cases.
|
|
|
Posts:
4,255
Registered:
18-Oct-2002
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
7 May 20, 13:10
in response to: RobM
|
|
|
Some observations purely as a result of messing about doing general drag and drop testing, these things happen in previous versions, so are not specifically beta comments.
In details view when moving an item so it becomes the first item, there is no bar/line(as you see moving item 3 to 2 for example) to indicate when to drop the moved item. The item can be dropped as the first object though.
Noted. I think I pass on fixing that one this time though cause it would require rewriting a layout manager (code hell)
If you drag an object, say an image, onto its parent folder in the project pane you get an error, But if you copy and paste the image in the same folder you get a copy. Both actions are really the same, so maybe the error should be replaced with a copy?
I think I've addressed the error now (ObjectNotSerializable)
You can use thumbnail/more context menu to do a ‘Save as’ to the file system. It works for images but not videos, folders etc. why?
Takes time to implement, but good idea.
A keyboard modifier, like CMD/CTRL, allowing you to drag and drop copies of files from jAlbum would be nice.
Good idea. Now implemented in the new beta. Try it out! (note, the folder tree always moves files, ignore the "+" sign when dragging to it - old bug)
Related, dragging the folder thumbnail/theme image from jAlbum to the file system removes the image from jAlbum, but pressing F5 does not update the thumbnail or theme images.
Noted
Click on an image or folder to select it, now click in a space to deselect it. Now hold shift key down and click on a different object, all objects from the previously clicked item to the last one clicked are selected. Could be a bit of a surprise as the previously clicked image is remembered if you switch projects and then go back to it, quitting jAlbum does forget the first clicked item.
Noted. Mac and Windows seems to start the select range from the 1:st object in these cases. It's a true corner case though. |
|
|
Posts:
4,255
Registered:
18-Oct-2002
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
7 May 20, 18:00
in response to: davidekholm
|
|
|
|
Hi. Please try b7 now. I've now worked on copy-drag behavior. The cursor now correctly reflects the operation (move or copy/link) as you drag items. This includes the folder tree, which previously showed a copy cursor even it it always moved items. You now get the behavior the cursor indicates during a drag operation.
To clarify: jAlbum has previously responded to holding down CTRL or ALT while dragging files from the file system. This has changed the way files are added. You can now get similar behavior when dragging items within jAlbum. Hold down CTRL (ALT on Mac) to make a copy of the dragged files instead of moving them.
Edited by: davidekholm on 07-May-2020 22:29
|
|
|
Posts:
8,320
Registered:
31-Jan-2006
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
7 May 20, 22:39
in response to: davidekholm
|
|
|
|
What happens seems to depend upon the sequence of moves. If nothing is selected, and I hold down CTRL, then click and drag the file, it's copied. But if I select the file by clicking on it, then hold down CTRL and drag the file, nothing happens at all. I confess that I don't understand why those two actions should be different.
|
|
|
Posts:
4,310
Registered:
4-Aug-2006
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
8 May 20, 11:55
in response to: JeffTucker
|
|
|
What happens seems to depend upon the sequence of moves. If nothing is selected, and I hold down CTRL, then click and drag the file, it's copied. But if I select the file by clicking on it, then hold down CTRL and drag the file, nothing happens at all. I confess that I don't understand why those two actions should be different.
Using Alt on the Mac works as described, regardless of the order of selection or keypress. |
|
|
Posts:
4,255
Registered:
18-Oct-2002
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
8 May 20, 12:55
in response to: JeffTucker
|
|
|
What happens seems to depend upon the sequence of moves. If nothing is selected, and I hold down CTRL, then click and drag the file, it's copied. But if I select the file by clicking on it, then hold down CTRL and drag the file, nothing happens at all. I confess that I don't understand why those two actions should be different.
They should give the same result, but the painting of the "+" sign seems to be buggy. Java's Drag and drop support is a hell to work out  . I've now made my best attempts to ensure that the painting is right. It's not 100% solid on either Mac or Windows (different oddities), but it at least works better than in the previous beta, so try b8 now. |
|
|
Posts:
8,320
Registered:
31-Jan-2006
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
8 May 20, 14:46
in response to: davidekholm
|
|
|
|
That seems more solid.
Truth be told, in both File Explorer and Finder, I still occasionally run into little bits and pieces of odd click-and-drag behavior, and files sometimes land in unintended places.
|
|
|
Posts:
181
Registered:
5-Dec-2013
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
9 May 20, 08:22
in response to: davidekholm
|
|
|
We used to refer to those as "edge effects." You'd have a nice, clean routine for dealing with something of length i, but then at least half the code was dedicated to dealing with what happens at item[0] or item[i - 1].
Yes, that's typical for robust code. Half of the code deals with corner cases.
More opinion on coding:
"Working on a system you hate is not how anybody should have to spend his time. Redefine internal interfaces, restructure modules, refactor copy-pasted code, and simplify your design by reducing dependencies. You can significantly reduce code complexity by eliminating corner cases, which often result from improperly coupled features."
https://www.oreilly.com/content/7-ways-to-be-a-better-programmer-in-2014/#three
"In the long run every program becomes rococo — then rubble."
https://www.youtube.com/watch?v=mrY6xrWp3Gs |
|
|
Posts:
4,255
Registered:
18-Oct-2002
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
9 May 20, 10:29
in response to: karlmistelberger
|
|
|
We used to refer to those as "edge effects." You'd have a nice, clean routine for dealing with something of length i, but then at least half the code was dedicated to dealing with what happens at item[0] or item[i - 1].
Yes, that's typical for robust code. Half of the code deals with corner cases.
More opinion on coding:
"Working on a system you hate is not how anybody should have to spend his time. Redefine internal interfaces, restructure modules, refactor copy-pasted code, and simplify your design by reducing dependencies. You can significantly reduce code complexity by eliminating corner cases, which often result from improperly coupled features."
https://www.oreilly.com/content/7-ways-to-be-a-better-programmer-in-2014/#three
"In the long run every program becomes rococo — then rubble."
https://www.youtube.com/watch?v=mrY6xrWp3Gs
I can tend to agree with those quotes in general. When your code is littered with if/else statements and repeated code sections, then it's time to take a "helicopter view" of the task and rewrite the code. Maintaining code is a constant task of rewriting and deleting old stuff to make for code that can grow. This said, some type of code inherently needs to deal with many corner cases to be robust. Think about code interacting with the user or network for instance. There are a good number of odd behaviors that can emerge from both humans and shaky networks, badly written ftp servers and such. |
|
|
Posts:
181
Registered:
5-Dec-2013
|
|
|
|
Re: jAlbum 20.1 beta for testing
Posted:
9 May 20, 13:37
in response to: davidekholm
|
|
|
Think about code interacting with the user or network for instance. There are a good number of odd behaviors that can emerge from ... humans
Windows 10 was out for a year when I readily succeeded freezing a modern notebook by invoking Edge, visiting some common websites such as jalbum.net , zeit.de and others in their own tab and switching between these. In the end MS even refrained from eating their own dog food an chose Chromium's rendering engine, which is derived from KHTML. 
KDE has done lot of refactoring in the last few years and came up with pretty robust components such as Dolphin. |
|
|
|
Legend
|
|
Forum admins
|
|
Helpful Answer
|
|
Correct Answer
|
|
