This is. a very fascinating, powerful, tool for TW mentioned in another thread …
It is amazing (best with mouse & keyboard) … You just drag things around in a grid of buttons to get stuff like …
I hope we can learn how to use it well.
And encourage @EricShulman to go on with it.
TT
One thing I forgot to mention is how to create a new pasteup tiddler:
Assuming you have installed TiddlyTools/PasteUp and TiddlyTools/PasteUp/View, all you need to do is create a new tiddler in the usual manner, and give it a tag of “pasteup”. Then press done. A blank PasteUp layout will be shown, with a default button grid (30 rows x 25 columns).
To add items to your new PasteUp tiddler, just click the “lock” button (upper-left corner above the layout area). You can then use drag-and-drop interactions to highlight a rectangle and click on that rectangle to open the modal “field editor” dialog.
You can also click on the layout heading (e.g., “New Tiddler” or whatever name you gave your tiddler) to view and interact with the layout “field table”. Click “add a field”, enter a new field name and (optionally) a field value. Then press the “+” button to add the field to the table.
Note that this does NOT automaticaly place the new field in the layout. Once at least one field is defined, you can check the “show layout/styles” checkbox to enter top/left/bottom/right/layer numbers and (optionally) CSS styles for each field. You can also drag a field name from the table and drop it on the field grid to place it in the layout.
enjoy,
-e
Can’t get it to work in Firefox. Works okay in Brave.
I just installed FireFox on my Windows desktop… and TiddlyTools PasteUp works for me.
I’d like to figure out why you “can’t get it to work in FireFox”… can you give me some more info?
-e
What OS are you using?
Win10
What version of FireFox?
Latest
How do you know PasteUp didn’t work?
Drag doesn’t initiate AFAICT. On Brave, drag gets immediate feedback that you’re dragging. Doesn’t happen at all on Firefox. No errors in console, btw.
Firefox:
Brave:
Firefox behaviour seen in that gif matches my experience in testing right now.
Firefox 140.0.4 on Linux.
Elements can be moved only by tedious stepping of resizing opposite corners
Dragging elements works in Chromium 140.7 on the same system.
My initial test with Firefox was flawed. When I re-did the test, I saw the same problem (dragging a field doesn’t move it).
After much debugging, it seems that the problem is caused by Firefox having default handling for dragging a button element, which “eats” drag events before they can “bubble up” to be handled by the $draggable widget that surrounds the button.
This actually affected TWO different PasteUp button drag interactions:
The solution was to change two instances of $button widgets to div elements wrapped in $eventcatcher $click=... handlers. This allows those divs to continue to process their click events, but allows the drag events to bubble up as needed.
I’ve updated TiddlyTools/PasteUp, so it should now work correctly with FireFox. Please test to verify that this particular problem is now corrected and, of course, continue to test for any other problems that might be lurking about.
enjoy,
-e
@EricShulman. A small request.
Would it be easy to make the “slider” longer?
On Print, particularly, it is too short to be accurate on size …
Only if easy!
It is a brilliant tool.
TT
done. The sliders for grid modal preview, PasteUp/view, and PasteUp/print now all use the default width for “input[type=range]” as determined by your browser.
Note that this is not the “full width” as you indicated in your drawing, but should be more than enough for accurate scaling. Also note that all sliders now go from 25% to 200% in 5% increments (rather than 1% increments, which I feel are too “fiddly” for consistent zoom sizing).
enjoy,
-e
That’s working in firefox now, behaving the same as Chromium anyway.
I’m seeing 25-200% in 1% increments (both firefox and chromium)
Here is something I noticed in playing around with the rotation tranform CSS - exaggerating the examples you have to 45°, the corners are clipped. The amount seems to be worse on the text rather than images, but is a bit visually messy at best, and a big limitation and loss of expected information on screen at worst.
Is this an unavoidable limitation?
Umm… yeah… I goofed on that. I used step=5 when the correct attribute name is increment=5.
… and I’ve re-considered: depending upon your paste up content, 1% increments may be useful/needed.
So I just removed the erroneous attribute and the $range sliders now use 1% increments (the default).
Regarding rotations: this is an “unavoidable limitation” of the underlying “button grid” layout mechanism.
All field styles (such as rotation transforms) are applied to their respective field content, but not to the containing field rectangle that sits on top of the button grid. The result, as you have seen, is that the corners of rotated content can get clipped to the boundaries of the field rectangle. The workaround solution is to adjust the field rectangle size (and position) to make it large enough to fit the rotated content without clipping.
-e
good news! I have figured out how to permit rotated content to overflow its containing field rectangle, while preventing it from overflowing the overall layout grid boundaries.
Note that this change makes it hard to force rotated content to clip to the boundaries of its field rectangle, but I think it’s still an improvement over the previous “always clip” handling.
Give your rotated content test another try and see if the results better fit what you would expect.
Let me know what you think.
-e
overall, I think that’s much better.
Some notes
Screenshot shows the grid item I selected. I attempted to drag it onto (approximately) your left eye - outside the “active grid”, but still within the rotated item and not yet onto the background grid. The error is shown. (Screenshot is from Chromium, same behavior in Firefox)
Exactly how did you produce the first problem (where the layout grid doesn’t take up the whole tiddler width). In my tests, the rotated item is clipped to all the edges of the layout grid.
The second problem has been FIXED:
The “move” was actually attempting to do a “copy/replace item” action (where you drag an item from another PasteUp layout and drop it onto an item in the current PasteUp layout). There were 2 errors:
-e
simply zooming out via PasteUp’s own zoom
The second problem looks resolved.
The upshot of overlapping the grid to the right, and the fix of being able to drag onto itself, is now being able to drag completely off the grid!
“move” handling has been updated:
Previously, moving a field above or to the left of the layout grid was prevented by forcing the new field position to be a minimum of top=1 and left=1, but moving a field below or to the right of the layout grid was permitted, but was supposed to be clipped for rendering. However this clipping no longer occurs since the “overflow:hidden” CSS was removed to allow the new rotation rendering to work.
Unfortunately, as you noted, removing the overflow restriction has made it possible to move the field entirely off the layout grid. To address this, moving a field below or to the right of the layout grid is now being prevented by forcing the new field position to be a maximum of right=“cols” (layout grid width) and bottom=“rows” (layout grid height)… similar to the handling that was already in place for the top/left field position.
Note that, while this change ensures that a field’s position cannot be moved outside the bounds of the layout grid, it still won’t prevent the “bleed over” rendering that can occur when a field is rotated and the layout grid is zoomed out (i.e., less than 100%). I’m still looking for a solution to that issue, but nothing comes to mind.
-e
P.S. Much thanks for continuing to push the limits and find the edge cases for the PasteUp handling. It’s definitely helping me to make the code more robust.
I’m happy to help. Even though I don’t use PasteUp currently, it’s one of the tools (like many of them) on tiddlytools I keep in my mental back pocket for future potential use.
From testing the latest: moving off the grid is fixed in both FF and Chromium for me, but playing with transform: scale in the CSS brings back the difference between the item’s active grid and the item itself - with an area that cannot be selected nor dragged to.
I set transform:scale(3); for this screenshot to exaggerate the effect. (noticed it first with the rotation set again, but once I realised it was scale I took that out to simplify the example)
