Demo: Draggable & Resizable Containers in TiddlyWiki (built on extended eventcatcher)

#1

Some years ago I published a demo of a Floats plugin that creates draggable, resizable containers in TiddlyWiki. At the time there wasn’t much interest, so the development went its own way as a custom plugin that I’ve been using regularly over the years. The downside is that it became too tightly integrated with my other plugins to be easily shared.

As part of exploring potential improvements to the eventcatcher widget, I decided to rewrite the same functionality completely from scratch. It’ll probably be a few weeks before I can continue working on this, so I’m sharing it here in case it’s useful or interesting to others.

Background

If you’re curious, here’s the very first demo from way back.

The new version is written almost entirely in WikiText, with a little help from:

  • An extended version of the eventcatcher widget (which I think could be a core candidate)
  • New $:/info/ tiddlers that report window dimensions, via the Window Resize plugin (also a core candidate)
  • (Optional) the Links Context Menu plugin, which lets you right-click a tiddler link and open it directly in a float

Demo: TiddlyWiki v5.3.8 — a non-linear personal web notebook

To Do

  • Make float persistence configurable (how many remembered, across reloads, etc.)
  • Minimize / restore
  • Headerless floats
  • Pinning
  • Keyboard shortcuts to hide/restore all floats
  • Size & position as percentages of the window size
  • Snap-to-grid
  • Keep floats visible within the window (on resize or when opened from context menu)
6 Likes
#2

This looks really promising and is worth developing. I remember seeing a demo of a similar feature on the forum before, but it seemed very complex and required a lot of wikitext. I’ve since forgotten how it was done.

If this could become a core feature, that would be even better. If not, it would still be a great plugin.

As a side note, I don’t think the core needs to stay tiny. While a small core is a nice advantage on the surface, most users want more features.

#3

Wonderful!

Maybe this is exactly what you refer to but, specifically, the main demo tiddler HelloThere unexpected expands vertically from merely being relocated. The wikis top menu covers any closing X button so the expanded float gets stuck in this expanded mode. Other floating tids seem to behave properly, without being expanded vertically. [Win 11, Brave]

1 Like
#4

Please try using the “Reset floats” button and try again, and let me know if the problem still happens. I think I forgot to delete the state tiddler when preparing the demo, so its remembering prior settings that no longer apply. Thank you.

Ah, happy you mentioned that. I never use the menubar plugin so would not have noticed. Will need to increase the z-index of the floats.

#5

The Reset does close the float but even if the first thing I do on the page is to click Reset Floats and only thereafter click the Open HelloThere, the behaviour persists, i.e as soon as I drag the opened HelloThere is expands vertically to full screen length.

#6

Odd. I don’t see the same behaviour on Chrome, Edge or Firefox on Windows.

#7

Hm, I get it on both Brave, FF and Edge (so I guess it’s Win11?). This is what it looks like:

Edit: Win 11 home ed.

image
image1920×859 202 KB

#8

Extremely odd. And other floats behave normally?

If so, try opening a different float and moving it first.

#9

If I open another tiddler, via right-click menu, e.g QuickStart and thereafter HelloThere via the button, I still get the faulty behaviour for the latter.

If I open HelloThere via right-click menu it behaves as it should. It still behaves properly if I, when it is still open, now click the float HelloThere button.

Feel free to write up a list of tests, and I can follow them to report the results.

#10

Using Firefox latest on macOS Sequoia, right clicking links works and selecting float correctly opens a draggable window. Great. Clicking on the X in the window to close it does close it but I can no longer click on anything and have to reload the wiki.

#11

Testing on Chrome on Android, I am seeing problems similar to what you both are reporting. That is encouraging because it suggests the culprit is whatever last minute changes I made since I last tested on Android a couple of days ago.

Not entirely sure when I will get back to this, but ill report back once I do. Thank you everyone for the testing and feedback.

#12

I am getting this too on Chrome in Windows. Dragging the float slightly upwards suddlenly stretches the top of the tiddler above the top of the screen, so that the tiddler title and close button are not on screen.

#13

Since I have been playing with modals, I am interested in this as a possible alternative to them. I will be watching this thread.

#14

I’m seeing the same thing, but only for HelloThere launched initially from the button. Others launched from the context menu are fine.

Win 11 Pro / Chrome 138.

#15

The floating window is nice, but only slightly more compact than the existing open in new window option.

It would be really useful if you could float the edit mode.

On Linux, Firefox, it behaves somewhat erratically. I realised if you want it to resize correctly you first have to hover over an edge until it turns into a double arrow. Then click once. After that, that side will change when you drag the double arrow, no matter which side you are dragging. It’s like it’s one click behind in responsiveness.

#16

I won’t have time to work on this for a few weeks, but when I get the chance I will update the demo with the last version that was tested to work well with Chrome on Android. I recall optimizing the CSS after that and may have stripped out some needed bits accidentally.

However, I don’t think that will fix the odd behaviour with the HelloThere tiddler opened in a float, I suspect the Windows 10 vs 11 thoughts are a red herring. My suspicion is that its due to the specified height of the float when opened with that button (which specifies 800px as height), being too large in relation to the available vertical space. When a drag is initiated, this triggers the logic for positioning floats which tries to accomodate the float within the boundaries of the viewport. If so, then this is related to the missing logic that will be needed to handle the window being resized which may hide open floats, and still needs thinking through.

If you are interested, you can try editing the tiddler Floats and change the $height parameter to 200 and then try clicking the “Open HelloThere in a float” button.

Update: I have updated the demo with the older and better tested CSS and changed the size that the float opens at for the HelloThere tiddler. Hopefully this mitigates some of the issues, and I will have a look at whatever remains when I next have opportunity to work on this.

1 Like
#17

Hi @saqimtiaz , thank you very much for this, as you know I already was a great fan of the first float experiment. Especially your ToDos make me hoprfull, that it could present a solution for some issues working with tw as a classroomscreen.
But I still have some more wishes I would like to add to your list:

  • the possibility to use floats to reorder the storylist by dragging them between tiddlers
  • store sets of floats like pinboards
  • a config to make tiddlers disappear in the storyriver when the are open as floats
  • a config to decide whether floats move relative to the storyriver or stay on a fixed position.

So thanks and best wishes Jan

#18

Great work, Saq (new eventcatcher looks good, too!).

No issues here, Win10, FF, drag, drop, resize, right-click launch, rinse, repeat…

:trophy: