-
Notifications
You must be signed in to change notification settings - Fork 365
Conversation
fs.makeTreeSync(alphaDirPath) | ||
atom.project.setPaths([rootDirPath]) | ||
|
||
it "defaults to set", -> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it "defaults to true", ->
Looks good to me! /cc @atom/feedback |
I feel like the solution is not in adding yet another checkbox, but in making it harder to screw up during drag and drop. Maybe it's too sensitive? Maybe there should be some kind of confirmation when moving a folder? |
So, I'm 👎 on this for now. |
I'm also 👎, and not just because I'm allergic to adding checkboxes in general. I think we can fix DnD problems with improved UX. Perhaps expanding to and highlighting the dropped item after its move so you can't lose it? |
Closing as a wontfix |
Perfect - thanks I was going to drop using atom and go back to sublime until I found this. It's a massive issue, shame on the atom team for not opening up a way to fix this with the core. |
Steps to disable drag and drop (for linux): cd ~/.atom/packages
git clone https://github.com/atom/tree-view
cd tree-view
git checkout c153f67 # git the current release
grep -rl "@draggable = true" . | xargs sed -i "s/@draggable = true/@draggable = false/g"
apm install |
Hello, I see this PR was closed because there is a better wat of solving it, yet de D&D problem is still a problem. Is this topic being debates elsewhere, so I can follow? Thanks |
Hi Jose, I modified the tree view package to do this. I've attached the package. I'm on OSX, it lives in /Users/{my username}/.atom/packages Thanks, |
How about merging this PR until the UX actually gets fixed? Don't let the perfect solution be the enemy of something that's merely good. |
Why is this wontfix? I hate drag and drop, it's almost impossible to click in the tree view without accidentally dragging and dropping some times, and there is not even any way to undo it or confirming the move. Being able to disable this is a MUST HAVE feature, even if you improve drag and drop somehow. |
There are various ways to fix it highlighted above (such as the modified tree view package I posted earlier in the thread). Agreed that this should be part of the core however. |
@ryanpalmerweb: It didn't work for me, it somehow just disabled the tree view from working completely until i removed it. The real problem is that there is NO drag-and-drop threshold at all, move one pixel while clicking and you're allready dragging, move just a few px more depending on where you clicked and you've moved a folder somewehere else, instantly and without any confirmation or visual clue where it went. Even if they insist on not allowing us to disable drag and drop completely; there NEED to be a drag and drop threshold setting (with no upper limit so that I can effectively disable it by setting it to 500px or whatever). 1 pixel threshold is ridiculous! That's less than 0.1mm movement both on screen and with my physical mouse. I'm having problems not accidentally dragging stuff when trying to click, and I'm not even 40 years old; imagine how anyone with even a little tremor would do... |
@ryanpalmerweb: thank's for sharing I'll try it and let you know. I think like @strindhaug, this is really a problem that must be solved or by incrementing threshold or adding the option on settings. |
Hi Ponyesteves, I've forked from a more recent version of tree-view. Add the contents of the attached zip to ~/.atom/packages/tree-view/ Remember that new versions of the tree-view package will overwrite it when you run an update, so it does make sense to rename the package. Thanks, |
thanks for the advice Ryan! |
Sorry to bump an old thread, but for anyone still interested in this topic (as I was).. I just added a repo that includes 2 bash scripts.
If the core dev team has no intention to implement this kind of configuration option.. to disable a feature that's unwanted by (and dangerous to) many, then having available an (innocuous) script that can universally patch any (current) release seems like a decent alternate method of delivery. |
I think like a lot of the other commenters on this thread, I don't use drag-and-drop in Atom's tree view at all. To me it is only a source of pain. Would love to be able to disable it. @benogle would you consider re-opening? The solution you envisioned hasn't happened in almost 2 years and there is no sign that it ever will. Improving drag-and-drop only makes sense if users actually want it - and as you can see above, many do not. |
@benogle I'm crying out for this, still. Multiple issues have been caused in my code by inadvertently dragging and dropping files and not realising. I have to patch every single update to the tree-view module. I don't have this issue anywhere else, on any application or operating system. |
Considering there's still been no movement on an actual fix here, and the official stance has been "It adds complexity, and we want to fix it right by making the UI better," is there now any openness to adding a simple checkbox at least until the UI is improved? As one user mentioned on another thread, it even caused him to lose work, due to accidental copy into a tmp folder. Others have abandoned Atom altogether, as it left them breaking their builds by accident. I haven't left yet, but it's certainly caused me to look around at other options quite seriously. A great many users have no desire to move files within their editor. That's what a terminal and file manager are for. As my of us have posted here, it could even be as simple as 2-3 lines of code, allowing a config-file disabling of the feature (which adds effectively no complexity to the codebase). I understand the concept of being a hackable codebase, and allowing users to do things themselves. However, if it's a common feature which requires very little effort and ongoing work, and makes the software much more productive and usable for many users, I'm not sure I understand the resistance to it. I'm just not seeing any downsides to it, beyond the mythical concept of "additional code complexity" which, let's be honest here, isn't a large issue when you're adding a handful of lines of code to a single package, which change a boolean value on the backend. It's not that the drag-disable function isn't built - there just isn't a frontend way to edit it's value. All we're asking is for a way to expose a toggle for a single boolean value which you already have in your code. |
/cc @iolsen in case we want to consider this again |
Given that we're not going to take on significant work on the tree view any time soon, adding this checkbox, while less than ideal, feels like the right thing now. I can't re-open this PR because the source repo is gone, but we'd accept a good PR adding this. I'll reopen #588. |
Fixes #588