Open rsjaffe opened 11 months ago
I will need some help with integrating as I never did this. Right now the GitHub repository is very outdated as I use a simple text editor to edit the code and have to manually upload the source to GitHub. I am not sure what the best way is, if I should update the master with my code or the copy-release branch with only the changed files of the plugin directory (both are outdated currently). However, the description of the Wiki (changes, usage & options) are up-to-date.
I am pretty much done with the changes I intended. And of course it is up to you what you want to integrate. I am of course looking forward to any questions you might have or to discuss certain aspects/intentions (and I am sure there are some very bad decisions even to me after all that time ;-)
However, there is one topic I am currently struggling and cannot find a solution for. It is the crop/orientation issue. The orientation can only be retrieved with getDevelopSettings. The only place where I could get this working is in the main while loop in Client.lua. In any of the sub-routines or ClientUtilities it fails. So I updated a variable constantly in the main loop. This worked... as long as you do not delete a photo. There must be a Lr issue. When I check the existence of a photo with getTargetPhoto or even getFlag (for example) the check is positive. But when retrieving orientation immediately afterwards it sometimes throws an error. I assume there must be a slight delay for getDevelopSettings until all information is retrieved and in this short time in-between the photo is gone and error occurs. I could not find any solution to this. If I reduce the update interval the error is less frequent obviously, but still occurs.
In addition I am too dump to get the crop function right (so to honor orientation and feel more natural with sliders, i.e. CropBottom starts at 0 and moves up when moving slider up, CropTop starts with 1 and is going down when moving slider down; similar for Left/Right). Several times now, I corrected it with a lot of effort and when I checked, it worked. But some time later I found it faulty. This time I think it was the new update which may have changed something. However I still need some work... or you can do this much quicker, as I maybe got stuck in a dead end and cannot find out... ;-)
I am looking forward to your feedback and ideas how we should proceed with this... :-)
I'm going to put in place a fine-tuning option inspired by your work but implemented differently. It will "hijack" the current Limits process, allowing me to do this with minimal code changes. Changes coming from Lightroom (e.g., settings from a new picture, person using mouse to move controls on-screen) will trigger recalculation of the limits if they are out of current bounds. This will make the computational load minimal.
As to the crop, I am going to not make any changes currently. Adding more functions to the connection loop will increase the load on Lightroom, and I'll need a major reason to do so. Lightroom is already stressed by the amount of work MIDI2LR does, and I've repeatedly had to make changes to accommodate Lightroom's problems. Since I haven't received many complaints about the crop idiosyncracies, I have that as a lower priority issue.
Your work on this program and others can be made easier by using a few specialized tools. I find the following very useful:
It was only through using the debugger that I finally figured out why Lightroom was throwing errors when a Profile changed when changing to the Masking subpanel. By stepping through each variable, I found that the error no longer occurred, indicating that it was simply the rate of requests (or not yielding to Lightroom) that caused the problem. I then included the yield statements to make the problem go away. Without a debugger, I don't know how long it would have taken me to get to that step.
I'm starting work on integrating your stuff into the main branch. I may need to have some discussions with you about the intent of some of the changes as I go about this, and probably will "cherry-pick" your changes into the rsjaffe/MIDI2LR/develop branch one-by-one.
Should I use your master branch as the source of the updates?