Draggable blocks, experiment #2! Oh my goodness!

Okay, some of you may remember that last year I played with draggable blocks and hit a few major roadblocks.

I got some inspiration this weekend, and made some significant advances. See my new Blocklister experiment. Compared to last year’s ‘Draggy’ experiment, it has several advantages: It’s not tied to the list field of the tiddler receiving the blocks. It allows for multiple sections of independently-functioning drop zones in the same tiddler.

The use case is for writers. Create building blocks of text, that can be moved from tiddler to tiddler by dragging, and reordered within tiddlers by dragging.

I still have a couple issues, listed in the Caveats tiddler. Maybe @saqimtiaz or @EricShulman would be willing to Zoom with me so I can explain what I have done and what is most needed. If so, I might be persuaded to make another donation to TW development to get this figured out. I have a version that is “good enough” for me, but I think this is something others would like to use, too. I really think this stuff is exciting! After you try it out, you may too. Feedback welcome.

7 Likes

Great illustration of the concept @DaveGifford, thanks for sharing.

I have being keen to develop something similar.

I could make suggestions and even give some help addressing your outstanding issues, but to do so will need to be in bite size steps.

What is your current status ?

Hi @TW_Tones!

Funny you should ask. I played with it again last night, and found the list-tagged-draggable to be the solution I needed for me. It solves the first and last of the five items in my caveats tiddler. I know how to do the CSS so it works with dark palettes. And since I use <$link>*</$link> in my blocks, I don’t need to see the handle. But it is as easy as opening the tiddler and changing the itemTemplate. And the recursion issue is not an issue for me. It could only become an issue if you transclude draggable lists within draggable lists within draggable lists, which I don’t. So for me, the issues are basically solved.

I made a version with your name written all over it. Try it out at:

https://giffmex.org/experiments/blocklist.template2.html

1 Like

I continue to look at this work of yours, I was going to say for

  1. I need to figure out how to tweak the relink plugin so that renaming a block tiddler also renames it in the sectionfield field of the state tiddler. I have a feeling relink is only set up to relink from non-system tiddlers.
  • I use relink with system tiddlers a lot.
  • I see you have gone to the Relink Plugins configuration tab and add sectionfield there.
  • I am excited myself to make use of the new sub Plugin Relink titles because I believe this will specifically help with system tiddlers.

Renames tiddlers with titles derived from Relinked tiddler

Highly customizable relinking of tiddler titles related to the renamed tiddler.

  • Rename a hierarchy of subtiddlers when renaming a root tiddler.
  • Make custom filter rules to rename other tiddlers the way you want when Relinking.
  • Integrates with other plugins for plugin-specific rules.
  • Relink allows “Third Party Integration”
1 Like

Funny how talk.tiddlywiki seems to know just what I need at the moment. I want to play some more with drag and drop and wanted to find useful examples. I didn’t see this when it came out, and probably wouldn’t have cared that much. But today, there it is in “Suggested Topics”. This looks very useful, and I will probably be playing with it over the next weeks. Thanks for sharing.

Regarding this caveat:

Once you add a tiddler to a blocklist drop zone, the only way to remove it is to open the state tiddler for that blocklist and delete it from its sectionfield field. Not ideal. But to help ease the pain, I have a sidebar tab with a list of the state tiddlers, each with an area to edit their sectionfield fields.

I have a suggestion that I don’t quite know how to implement, but expect it would be reasonably straightforward. On the start of the drag, add an additional drop-zone with a trashcan icon and some sort of “Remove” instructions. If the tiddler is dropped on that, it’s simply removed from the blocklist.

2 Likes

Well, good on you! Honestly I forgot I created that. And this year, even. It is all yours. I hope you get more traction out of it than I did! Blessings.

1 Like

I have some experiments with draggable list in Demo of a new WYSIWYG editor: slate-write (unstable alpha stage)

It was difficult to handled Drag list item · udecode/plate · Discussion #1491 · GitHub

But as long as you are not deal with multi-level list, it won’t be a problem.

1 Like

See also this related item Drag and Drop Payloads not titles (next step)

I have done this drop on trash to remove in the past at least for titles, other methods include;

  • x icons like on the open tab
  • drop again to remove

I dont know how to display the trash on drag. But you can just have it near your list. It is a seperate drop zone with a remove action.

  • sounds like a good case for a custom widget

I have also made existing buttons and tag pills allow drag and drop with remove.

I think it probably can be done, modeled on what is already done in the sortable list widget. When I have time (Ha!), I’ll play around with it.

Indeed.

Is that in any shape to – and in any location to – share?

I will have a look around; however I am working on the aforementioned widget.

Here is a snippit of my working code for a drop on button to remove;

   \procedure remove-actions()
      <$action-listops $tiddler=<<targetTiddler>> $field=<<targetField>> $subfilter="-[<actionTiddler>]"/>
   \end remove-actions
   \procedure remove-button()
      <$droppable actions=<<remove-actions>> >
         <$button tooltip="Drop list item here to remove" actions=<<remove-actions>> class="tc-btn-boxed" >{{$:/core/images/delete-button}} remove</$button>
     </$droppable>
   \end remove-button

I have a couple of issues to solve;