Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate integration with SFOS Forum Viewer #36

Open
nephros opened this issue Jan 19, 2023 · 9 comments
Open

Investigate integration with SFOS Forum Viewer #36

nephros opened this issue Jan 19, 2023 · 9 comments
Labels
enhancement New feature or request question Further information is requested

Comments

@nephros
Copy link
Collaborator

nephros commented Jan 19, 2023

Inspired by: szopin/harbour-sfos-forum-viewer#63 (comment)

Things like:

  • User API key
  • report submission
  • file upload
  • ...

could be lifted from/done through SFV instead of a NIH implementation.

@nephros
Copy link
Collaborator Author

nephros commented Jan 19, 2023

@szopin, would you be open to implementing something like a small D-Bus api, or SFOS Share Action receiver in SFV, so that Bugger could call native SFV bits? That would be a bit cleaner (well...) than duplicating code.

@nephros nephros added enhancement New feature or request question Further information is requested labels Jan 19, 2023
@szopin
Copy link

szopin commented Jan 19, 2023

Whatever works for you is fine by me, sadly way out of my league I'm afraid. I'm happy to accept any PRs, just won't be able to help as have 0 experience with dbus outside of playing with it in terminal (action receiver first time I hear of)

@nephros
Copy link
Collaborator Author

nephros commented Jan 19, 2023

action receiver first time I hear of

Yes I dont think that's an official term, I mean the thing that sits on the other end of a Sailfish.Share ShareAction and handles the data. I don't know whether there is documentation about it anywhere, but one can look at how the email app does it:

  • /usr/share/jolla-email/email.qml (DBus interface to receive shared data)
  • /usr/share/jolla-email/pages/ShareComposerPage.qml (handling the data)

@szopin
Copy link

szopin commented Jan 19, 2023

Interesting, if it's doable from QML only then a big plus as would increase my available troubleshooting time immensely. Text data should be no problem, not sure about file uploads, for picture upload had to workaround with imgbb as they accept base64 encoded data and qml has no support for binary strings, for logs maybe some kind of online pastebin could be used and links automatically generated (don't think discourse has attachments support, looks like only images)
edit: https://pastebin.com/doc_api seems nice, also https://github.com/PrivateBin/PrivateBin/wiki/API but implementing AES just to then paste a link on a public forum is probably overkill
edit3: nvm, just noticed the logcollect branch

@nephros
Copy link
Collaborator Author

nephros commented Jan 19, 2023

Yeah I have explored a couple of avenues, in that branch and a couple of local ones.

There's issue #29 but it's stalled by the fact that I can launch email either pre-filling subject (mailto:), or adding files (ShareAction) but not both.

Tried to work around the second by faking the email body but doing things like compression or MIME-encoding in JS is painful (for the user/CPU -- there's plenty of ready-to-use JS libraries that can do it) for non-trivial string lengths/file sizes.

@nephros
Copy link
Collaborator Author

nephros commented Jan 19, 2023

something like a small D-Bus api, or SFOS Share Action receiver in SFV, so that Bugger could call native SFV bits?

A third option could be a MIME scheme handler. If SFV registered itself as a handler for either 'https://forum.sailfishos.org' or maybe a custom scheme like sfos-forum://, Bugger could call it per URL as it does now, and SFOS would present a choice of browser and SFV.
I have done something like that in one of my first SFOS hacks, youtube-dl-helper:

@szopin
Copy link

szopin commented Jan 19, 2023

If we go with this custom scheme is probably better to avoid hijacking normal links to the forum

@nephros
Copy link
Collaborator Author

nephros commented Jan 19, 2023

If we go with this custom scheme is probably better to avoid hijacking normal links to the forum

Well, it could also be a viewed as a feature...

@szopin
Copy link

szopin commented Jan 19, 2023 via email

nephros pushed a commit that referenced this issue Jan 19, 2023
Contributes-To: #36
nephros pushed a commit that referenced this issue Jan 25, 2023
Contributes-To: #36
nephros pushed a commit that referenced this issue Nov 16, 2024
Contributes-To: #36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants