Enable seamless, if crude, file attachment capability #1544
No reviewers
Labels
No Label
bug
build
dependencies
developers
documentation
duplicate
enhancement
formatting
invalid
legal
mobile
obsolete
packaging
performance
protocol
question
refactoring
regression
security
test
translation
usability
wontfix
No Milestone
No project
No Assignees
1 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Bitmessage/PyBitmessage-2024-12-05#1544
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "sgj3/attachments"
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?
See PR #1540.
This is just a placeholder. I will look into https://bitmessage.org/wiki/Extended_encoding and the src/messagetypes and improve my branch accordingly. For what it's worth, the attachment functionality in this PR already works, even if it is crude and limited.
Notice the new ability to create draft PR.
No matter which attachment method you use, you should probably check the file size, because of bitmessage message size limit: https://bitmessage.org/wiki/Protocol_specification#object
attaching files did work here. good job!
However, this is the chance to win the filepicker war.
on many Linuces, you get dozens of filepickers which drive yo nuts. On KDE there is one central filepicker which is ignored by all the loudmouths out there. However, a patch for pyBM was already posted. KDE users will hate non-compliant filepickers such as the Gnome3 one. ideally we should have the patch ready for cherrypicking. seems, in Qt5 , that QtWidgets.QFileDialog.getOpenFileName() automatically honours the KDE filepicker via the "portal..." env setting. time to quit Qt4 !
using github web site, you can quickly merge this PR into your own fork onto a cherry-branch or sth
works like a charm ! CHERRY 1