While you’re immersed in how this functions. Maybe you could ID the offending part of the Clipboard module that adds those horizontal (and vertical) offsets!
It needs an offset. And it probably needs to be scaled… maybe by screen resolution but not the distance of the click from some basepoint in the Type column.
I think I might know what the issue is, I’ll confirm after I mess with my addon a bit more
The basics of the drag and drop functionality are implemented, now to add more “tool” items like column names to pull from and allow reordering / deletion of elements.
Another small update: I implemented blank boxes in between each element which serve as drag destinations to allow elements to be dragged to any position within the event builder area.
Instead of a gramplet, have you considered making this a View mode with the pallettes of Editing Tools being gramplets?
So if a Editing gramplet is active, the form is in design mode. But if other gramplets (like a drag’n’drop pallette; e.g., Collections Clipboard or Vantu5z’s experimental interactive Search) are active, the form is in data entry mode. The layout would be fixed … so the drag’n’drop is restricted to the data.
A view would let a lot more screen space to be used for the forms.
A maximize/minimize gadget would be useful too. Where the current set of active split bars (toolbar, navigator, sidebar, Bottombar) is remembered but then hidden in Maximized mode and restored with a single click.
I like the idea of having things all be in one page. I will consider changing this once everything has been designed. I will probably try out a few different locations for everything and see which works best.
Also I figured I would upload a short demo of some of the features so far, so here is a short video (ignore the random error in the middle I will fix it eventually)
Wow, its a big job is done!
Quick update since it has been a while: the current task which is taking me so long is figuring out a way to save the settings in the event builder so that everything reappears in the correct order and so that everything can be read in the correct order. This is just taking a while because of the way GTK works but it is on its way.
I’m also experimenting with some better ways to do this than my current path, I think sorting and list comprehensions could actually be the way to go.
I encourage you to not shift paths. You can always do a 2nd version after a feedback cycle.
There’s always a “better way” that calls to you after going partway into a project.
We have some GREAT addons that are very usable but unreleased. Usually because the developer decided the experiment revealed a better way to achieve the goal… but it required a complete re-write.
I ended up switching, just because the new way makes the programming easier. I was running into issues with complexity and confusing myself because of the possibility of deeply nested widgets and gtk not returning widgets in positional order. I just switched it so that now I basically iterate through, grab the positional order, and then move to the next layer instead of going directly to the next layer when it is encountered, making the program loop out of order and reconstruction a nightmare.
I created a github repo with my code as I am working so I don’t lose everything unintentionally haha- you can follow my progress here: GitHub - rentheroot/Gramps-Updated-Forms: Forms addon updates
Please add a 2024 copyright for yourself at the top of any module you have changed. And also to the .gpr.py registration file.
You can also add a README.md file (which could be a summary of the initial posting for this thread and a hotlink to the discussion) then set the help_url for the .gpr.py files to point at
help_url="https://github.com/rentheroot/Gramps-Updated-Forms/README.md"
5 of the outstanding 29 Pull Requests stagnating in the GitHub queue are related to the Forms addon.
Could you take the time to push them to release? It will be important to learning how addon PRs can become ‘stuck’ so that your release will not suffer the same fate.
It would also make certain that you have the most current tweaks in your base code. And it would keep those stagnated PRs from being suppressed when your enhanced version enters the queue. Finally, you might help point out any problems with 5.1 addon PRs cascading into the 5.2 addons too.
This should be directed to the team that can publish addons : Sign in to GitHub · GitHub
Personally, I won’t be publishing them since none seem to be actually ready for publishing.
One thing to note about the form file in the Form gramplet - any field name change will break existing entries for that form name. For instance, I used a preliminary US1950 form template and when the final was published, every one of my entered US1950 entries broke (attribute name changes broke the relationship to the field). I ended up copying the old form template to the custom template and renaming it as the best solution. There is no process to update an existing attribute to match a new form.
Individual status below:
PR is on master, not gramps52. Open question in comments:
You have two different PRs for FormUS, this one and #542. Is this one to be applied on top of the other, or does it supersede the other (which should be deleted)? I ask because some of the changes in #542 seem to be undone by this one.
PR is on master, not gramps52. The last comment on this is from @Nick-Hall . An earlier comment is:
> Hi Paul
> I am sending this on behalf of my father. He was in an accident and is unable to respond himself. About the form_us.xml changes. He said that the Would War 2 form had been completed and checked to ensure that the changes would not effect any data that had already been input and should be released. The other form was a census and should not be released and disregarded completely. He hopes this is useful.
PR is on master, not gramps52. The last comment on this PR is asking for review:
A revised version of the form is at /World%20War%20II%20Draft%20Registration%20Card. If someone/anyone/everyone could take a look at it and make suggestions to improve it would be helpful.
PR is on master, not gramps52. The last comment on this PR is from @Nick-Hall . It is still tagged as Work-In-Progress, which to me means it is not ready for publishing.
PR is on gramps51 not gramps52.
All good points. But @Nick-Hall tackled the yoeman’s work flushing core PRs out of the queue for Gramps 5.2.3. Since the add-ons queue is only a small stoppage, this is a good opportunity to clear it.
(Particulaly since the major registration changes to support the 5.2 Addon Manager are fresh in our experience.)
Let me take a look at them and see what I can do!
I will also look into possible solutions for creating a way to allow forms to be updated without breaking previous links / entries. I think a database cleanup tool style solution may be an option. The tool can keep track of previous form versions and the differences between them, then run a check on the database to see if any of the previous form versions are still persisting. It can then change the names of the problematic attributes.
