You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Storage: Make file explorer a Droppable area for NEW resources #298
This works nicely. But I need to open the counterpart ticket for this - making the resources dragable :)
Can you link the PR for this ticket? I want to know if you used teh solid-ui dragable function or not
This works nicely. But I need to open the counterpart ticket for this - making the resources dragable :) Can you link the PR for this ticket? I want to know if you used teh solid-ui dragable function or not
Sorry I was trying to be good about linking tickets and somehow I missed a few. I have linked it now. Because we are using web components and the drag/drop widget has UI attached I could not really use that. I moved the data logic for the actual store calls to solid-ui here SolidOS/solid-logic#354. And then the UI stuff is in the folder-pane source code.
While working on the drag function: #300 I realized this implementation is of raw files. We need still the usual drop of a URL say from one storage to another.
From AI:
The current container handlers do more than extract dropped files:
Behaviour
Current implementation
makeDropTarget
Local file drops
Supported
Supported through callback
Resource URL drops
Not handled
Parses URI lists and plain-text URLs
Permission/busy checks
Included
Must be added
Directory rejection
Included
Missing; callback receives only files
Highlight across nested elements
Drag-depth tracking
No equivalent
Listener cleanup
Managed by Lit
No disposer returned
What would need changing
Attach the helper once to the content div, avoiding duplicate listeners on rerenders.
Keep the existing upload event and shared upload flow—not the legacy uploader.
Preserve directory detection, permission checks, busy rejection, and highlighting through additional event handling.
Remove or coordinate the existing listeners so drops are not processed twice.
The main limitation: the helper’s callbacks receive URLs or files, not the original drag event. That prevents directory inspection through dataTransfer.items inside the callback. Its listeners also accept every drag unconditionally.
Recommendation: improve makeDropTarget in solid-ui first with an acceptance guard, original-event access, and cleanup support. Otherwise, keeping the current handlers is simpler than wrapping the helper to restore existing behaviour.
Separately, accepting a resource URL requires deciding what dropping means: copy, move, or link. makeDropTarget only extracts URLs; it performs none of those operations.
I think I know the answer to this, when we drag and drop a resource we are expecting the resource to be copied. So the existing one remains and a new one gets created in the new location? To note: .meta and .acl can not be copied. .meta is created only by the server so it will be recreated naturally as the server sees fit (which I can get details for what happens here if needed), .acl would not be moved so we have options here for permissions.
What do we want to do about permissions? Should we a) move without permissions silently, b) notify users that the permissions are not being copied c) ask user if they want them copied. (which means we would read the permissions and recreate)
What do we want to do if there are collisions? Should we a) just overwrite the existing resources silently, b) inform user, c) ask user what they want to happen (and if they want to use a different name ... do we prompt them for the name or just add (1) or (copy) or something to it like other apps? Here because we can't rename, if this is our choice, I think that we should allow them to give a name, because in other apps once it's named you can rename it.
I believe this is a completely new feature which needs proper discussion(#307). We will keep it in the backlog for later. The initial task is complete.
changed the title [-]Storage: Make file explorer a Droppable area[/-][+]Storage: Make file explorer a Droppable area for NEW resources[/+]on Nov 12, 2026
Activity
[-]Make file explorer a Droppable area[/-][+]Storage: Make file explorer a Droppable area[/+]timea-solid commentedon Nov 8, 2026
This works nicely. But I need to open the counterpart ticket for this - making the resources dragable :)
Can you link the PR for this ticket? I want to know if you used teh solid-ui dragable function or not
SharonStrats commentedon Nov 8, 2026
Sorry I was trying to be good about linking tickets and somehow I missed a few. I have linked it now. Because we are using web components and the drag/drop widget has UI attached I could not really use that. I moved the data logic for the actual store calls to solid-ui here SolidOS/solid-logic#354. And then the UI stuff is in the folder-pane source code.
timea-solid commentedon Nov 10, 2026
While working on the drag function: #300 I realized this implementation is of raw files. We need still the usual drop of a URL say from one storage to another.
From AI:
The current
container handlersdo more than extract dropped files:makeDropTargetWhat would need changing
content div, avoiding duplicate listeners on rerenders.shared upload flow—not the legacy uploader.The main limitation: the helper’s callbacks receive URLs or files, not the original drag event. That prevents directory inspection through
dataTransfer.itemsinside the callback. Its listeners also accept every drag unconditionally.Recommendation: improve
makeDropTargetinsolid-uifirst with an acceptance guard, original-event access, and cleanup support. Otherwise, keeping the current handlers is simpler than wrapping the helper to restore existing behaviour.Separately, accepting a resource URL requires deciding what dropping means: copy, move, or link.
makeDropTargetonly extracts URLs; it performs none of those operations.No code changed.
SharonStrats commentedon Nov 10, 2026
Here are some decisions we need to make.
To note: .meta and .acl can not be copied. .meta is created only by the server so it will be recreated naturally as the server sees fit (which I can get details for what happens here if needed), .acl would not be moved so we have options here for permissions.
timea-solid commentedon Nov 12, 2026
I believe this is a completely new feature which needs proper discussion(#307). We will keep it in the backlog for later. The initial task is complete.
[-]Storage: Make file explorer a Droppable area[/-][+]Storage: Make file explorer a Droppable area for NEW resources[/+]