mirror of
https://github.com/cypht-org/cypht.git
synced 2026-04-25 13:05:53 +03:00
[GH-ISSUE #216] Add drag/drop within the same account #179
Labels
No labels
2fa
I18N
PGP
Security
Security
account
advanced_search
advanced_search
announcement
api_login
authentication
awaiting feedback
blocker
bug
bug
bug
calendar
config
contacts
core
core
devops
docker
docs
duplicate
dynamic_login
enhancement
epic
feature
feeds
framework
github
github
gmail_contacts
good first issue
help wanted
history
history
imap
imap_folders
inline_message
installation
keyboard_shortcuts
keyboard_shortcuts
ldap_contacts
mobile
need-ssh-access
new module set
nux
pop3
profiles
pull-request
question
refactor
release
research
saved_searches
smtp
strategic
tags
tests
themes
website
wordpress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/cypht#179
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Yamakasi on GitHub (Aug 9, 2017).
Original GitHub issue: https://github.com/cypht-org/cypht/issues/216
Originally assigned to: @mercihabam on GitHub.
Would it be an idea to add de possibillity to drag/drop messages within the same account between folders ?
@marclaporte commented on GitHub (Apr 2, 2020):
I hope we can support drag and drop messages even between accounts
@marclaporte commented on GitHub (Jul 4, 2021):
@jasonmunro Are you OK if we use https://github.com/SortableJS/Sortable ? This is our usual tool in Tiki.
Thanks!
@dumblob commented on GitHub (Jul 4, 2021):
Or maybe one of the following:
https://github.com/bevacqua/dragula
https://github.com/mindplay-dk/zero-drag
@andonov85 commented on GitHub (Jul 8, 2021):
It looks like moving data between lists, so SortableJS looks appropriate to me.
@marclaporte commented on GitHub (Jan 14, 2022):
https://github.com/mindplay-dk/zero-drag/commits/master
Last commit 2018. IMO, that disqualifies it.
@marclaporte commented on GitHub (Jan 14, 2022):
https://github.com/SortableJS/Sortable/blob/master/Sortable.js is indeed bigger than https://github.com/bevacqua/dragula/blob/master/dist/dragula.js
Last commit in 2020-09 (15 months is not a disqualifier but a concern)
https://github.com/bevacqua/dragula/commits/master
Another topic: should we use minified version?
@marclaporte commented on GitHub (Jan 15, 2022):
Here is what Sortable says: (not an objective point of view)
https://vimeo.com/311584137
@marclaporte commented on GitHub (Jan 15, 2022):
Using the data from:
Both are very popular in terms of watches, forks and stars.
SortableJS: pull requests: 14 open vs 456 closed
Dragula: pull requests: 51 open vs 134 closed
SortableJS: issues: 338 open vs 1262 closed
Dragula: issues: 97 open vs 406 closed
In general, for pull requests and issue management, SortableJS has more activity and is better maintained.
SortableJS has had 99 committers vs 33 for Dragula.
One more factor: we have a front-end developer (@andonov85) who knows SortableJS well, and can support it.
So IMO SortableJS wins here, even if heavier.
@marclaporte commented on GitHub (Jan 15, 2022):
So I did a bit more research. Here is a good way to discover options:
https://github.com/search?o=desc&q=drag-and-drop&s=stars&type=Repositories
The top 2 most starred (SortableJS and Dragula) have been discussed above.
3rd most starred is:
https://github.com/Shopify/draggable
https://www.openhub.net/p/draggable-library
It has an impressive demo: https://shopify.github.io/draggable/
But in 2019 "Draggable is no longer maintained by its original authors." "Maintence of this repo has been passed on to new collaborators and is no longer worked on by anyone at Shopify." "We are still looking for more maintainers!"
Source:
github.com/Shopify/draggable@84b8a5f54c4th most starred is:
https://github.com/taye/interact.js
https://www.openhub.net/p/interact_js
5th most starred is:
https://github.com/haltu/muuri
https://www.openhub.net/p/muuri
@dumblob commented on GitHub (Jan 15, 2022):
I've opened my stash and typed "drag" and this is what I got (except for those mentioned in this thread already)
https://github.com/desandro/draggabilly
https://github.com/catc/displace
https://github.com/gtramontina/draggable.js
https://github.com/giraysam/viiny-dragger
https://github.com/yckart/DragValue.js
Feel free to take a look at them (some are so small that they don't even need any maintenance nor development any more - they are 100% stable with zero missing features and no known bugs).
@marclaporte commented on GitHub (Jan 16, 2022):
@andonov85 What do you think?
@andonov85 commented on GitHub (Jan 19, 2022):
I like https://github.com/desandro/draggabilly, in fact its author is a creator of other very cool libraries https://desandro.com/, so this is my favorite on the list of smaller size libs.
Comparable to https://github.com/SortableJS/Sortable I think their size is proportional to the features they offer out of the box. We use almost all the features of Sortablejs, with a simple configuration and without the need for additional code, which we will eventually have to write again for the library that does not offer these features. I put this as a great advantage of Sortablejs, along with the others that @marclaporte has described above.
@dumblob commented on GitHub (Jan 19, 2022):
I don't think the difference in size is a disaster but what you wrote seems to me out of context here in Cypht. We have 40k+ installations and only quite few (hundreds?) are through Tiki IMHO.
So IMHO we should focus only on Cypht alone as our context when deciding how Cypht will behave (especially on devices connected through constrained network connections).
IMHO >80% of all the mentioned libraries in this thread adhere to the requirements (in this order):
Everything else seems debatable.
Because Cypht is lightweight not just by itself, but more importantly bandwidth-wise on client, I'd say the next most important parameter really is size. It's not about potential features Cypht might use in the future (this is one of the historically biggest SW fallacies). Nor about features we can use right now "because we can" (i.e. because the library has it and it's easy to implement/use it) - that's also wrong as it burdens future maintenance & development (due to the general feeling/consensus to maintain a kind of backwards compatibility - be it UX-wise or UI-wise or API-wise or just expectations-wise despite the given functionality was originally a nice-to-have it's always enormously painful to change or remove it).
So I'm still undecided on which one to choose. I'm though confident that in case of Sortablejs we need more compelling arguments to outweight the size requirements of Cypht usage scenarios (not Tiki usage scenarios).
Maybe this whole discussion is a straw man and it'd be easy for Cypht to just wrap the few calls Cypht will use from some tiny lib fitting Cypht use cases to promote the dragging functionality into an internal quasi-modular API in a way so that Tiki can easily throw away the tiny lib and instead provide a shim wrapper on top of Tiki's Sortablejs. Or maybe some other solution...
Note it's never "either or". The world is not black & white. We should thus not try to find a one-size fits all solution but something which makes it easy to optimize for both projects (Cypht & Tiki) individually without compromising each other.
Thoughts? Suggestions?
@marclaporte commented on GitHub (Jan 19, 2022):
I acknowledge your point of view.
There are many other features in Cypht that could use some attention (like filters!). The time we invest here takes away from other things we can improve.
I am against picking libs that have seen no commits in over 1 year. I know some will say it's because they are feature-complete. But active projects are much more likely to adapt if and when we need them to.
All the proposed options have been looked at and I think the current proposal with SortableJS is "good enough". It is easy to change later if desired.
@marclaporte commented on GitHub (Jan 19, 2022):
@dumblob I like https://github.com/desandro/draggabilly because it's lightweight and active but @andonov85 informed me it doesn't support multidrag which is something we want right away (ex.: pick 4 emails, and move to a folder). It also doesn't support cloning (lower priority but some could want drag-copy of emails)
@dumblob commented on GitHub (Jan 20, 2022):
I'm fine with accepting Sortablejs as a temporary solution ("temporary" should be part of a comment in the source code of the corresponding PR).
I also fully understand how uneasy and tedious it feels if someone is such a protester as I'm here (I've managed mid-size dev teams for several years in my past).
Let me first apologize for forgetting that the first requirement "seamless UX on touch devices" encompasses multidrag and thus the percentage I've used
>80%is plain wrong.Multidrag is super difficult to get right on mobile devices (there are multiple ways to achieve it, but from my experience libs generally do get it wrong 😢).
So thank you @andonov85 and @marclaporte very much for pointing this out!
Now let me emphasize a few things.
I feel the preference for the black & white solutions here in this thread. I'm in no way a fan of those. They lead to highly compromised solutions and unnecessary suffering (in this case it's mainly the ~40k end users on low bandwidth connections - Cypht currently sends maybe about 140k JS on first connection). Please use your (technical, social, research, ...) abilities to find smooth solutions which fit both/all projects (incl. their user bases) instead of (unconsciously or not) sharpen the distinction between such options.
My experience clearly suggests any "project activity" measure is an utterly wrong assumption especially speaking of such (very) small SW libs.
We absolutely do not want the libs to change in any way in the future. By definition that only brings more work for us. Thus we should put some non-negligible effort into ensuring we will not need them to adapt/change/whatever in the future.
Note, we don't talk security bugs here as that doesn't apply in our case.
Reality is much more complex and more often than not (especially with such smaller projects we're discussing here) these feature-complete projects offer better and faster support unlike projects which still develop their libs and thus have a plan which is by definition a prioritization question, unknown deadlines, larger community involvement (i.e. slow), more difficult to make PRs for them (because the code is more complex and usually must maintain certain level of backwards compatibility), etc.
The main killer feature of Sortablejs (multidrag) never worked on mobile devices and it still doesn't. This is a recurring topic in the Sortablejs tracker. The most recent bug is ~1 year old with zero response from devs. I.e. this clearly shows "project activity" has nothing to do with our use case in Cypht.
The best workaround is to simply defer loading of Sortablejs (to save bandwidth) and let it load only on non-mobile devices.
We need to be active to really see through the dense nest of arguments and capabilities of individual libraries. In that vein I've now asked about multidrag in several drag lib repos. Let's see what'll come out of this.
displaceis out of question.That's why I'm still undecided.
@marclaporte commented on GitHub (Jan 25, 2022):
@dumblob Thank you for the detailed insight on multidrag and touch.
@marclaporte commented on GitHub (Nov 5, 2023):
@jacob-js Please do a deep dive on this.
Some guidance: https://dev.tiki.org/How-to-pick-a-software-library
@mercihabam commented on GitHub (Nov 15, 2023):
I don't perceive this as a bug; for me, it's functioning as intended. The issue is summarized as follows:
Multidrag prevents scrolling through the list of items; instead of scrolling, it triggers the drag-and-drop effect on an item.
In my opinion, this is a matter of preference — whether you consider it a bug or not. Even in a non-multidrag scenario, scrolling through the list will still produce the 'dragging and dropping' effect unless you perform the scroll outside of the relevant list.
However, if you label the feature as multidrag-non-single drag, we could categorize this as a bug. As long as Multidrag can also function for a single element, I don't see a need to restrict the selection of that element beforehand.
@marclaporte commented on GitHub (Nov 16, 2023):
Deep dive analysis is happening here: https://dev.tiki.org/Decision-Analysis-for-Drag-and-Drop-Library-for-usage-in-Tiki-and-Cypht