Hmm, it sounds strange because other things connect just fine and GTS’s documentation shows curl commands to explain how to authenticate a client application. I also am the owner of my instance so I know there is nothing extra.
But, GTS does have some internal server-side checks and Tooter might trip there somehow. Is there anything I can do to obtain more info on Tooter’s process? Maybe I can open an issue with the GTS developers, if nothing else works.
I tried both with the dbus method names (and the service path /openUrl) with the correct desktop entries and that led to the app not launching from lipstick at all. I tried with the DBUSadapater in QML (which is what I had working) and it was a bit better, though if I leave the entries in desktop, the app does not launch from lipstick. It will work fine (with either) from a terminal.
I tried the minimal QML only version copying the notes app, but also wound up with an app that won’t launch from lipstick.
EDIT: [Fix] attempt a version of dbus using the main desktop file · poetaster/harbour-tooter@8fa1f0f · GitHub
contains the changes I made to the cpp though they are currently not used.
When the app is launched from the comandline or sdk, the QML dbus adapter can be seen to work, but that app won’t launch.
The masto api is implemented in harbour-tooter/qml/lib/Mastodon.js at master · poetaster/harbour-tooter · GitHub and that’s a fairly old hack.
There may be something amiss/aged in
registerApplication
generateAuthLink
getAccessTokenFromAuthCode
Sailfish Office has a good example for implementing org.freedesktop.Application:
In fact Tomi’s whole commit there is pretty golden
Ok, that confuses the issue even more so 
I see DBusActivatable=true and the declaration/instantiation in the main.cpp, the method from the notes app seems a good deal less work (ie. just desktop file + QML). Why is this preferable?
EDIT: tried this as well and I still can’t launch the app. There was an issue with naming (the harbour prefix idiocy) but I don’t believe that’s in play.
[Fix] attempt the soffice dbus approach · poetaster/harbour-tooter@0a90210 · GitHub contains the copy implementation from soffice though the cpp is not active. Does not seem to matter what I do, the app does not launch from lipstick.
EDIT: SDK 5.0.0.62, makes no difference what target device I use, the app does not start from lipstick with either:
X-Maemo-Service=de.poetaster.tooterb
X-Maemo-Object-Path=/de/poetaster/tooterb/openUrl
X-Maemo-Method=de.poetaster.tooterb.openUrl
or
X-DBusActivatable=true
Runs fine from a terminal though.
Maybe dbus-monitor would help see what it’s trying to call. I know it needs to be aligned with the Sailjail org and app name, as any service that doesn’t conform to that won’t be visible from outside the sandbox. But that looks fine.
I’ll give that a try. What I have working is a second, open-url desktop file (with service) which is not harbour conform but works. In either case, just for testing I’ve been using the QML method
DBusAdaptor {
id: dbus
bus: DBus.SessionBus
service: 'de.poetaster.tooterb'
iface: 'de.poetaster.tooterb'
path: '/de/poetaster/tooterb'
xml: '<interface name="de.poetaster.tooterb">
<method name="openUrl">
<arg name="url" type="s" direction="in">
<doc:doc><doc:summary>url to open</doc:summary></doc:doc>
</arg>
</method>
<method name="Open">
<arg name="url" type="s" direction="in">
<doc:doc><doc:summary>url to open</doc:summary></doc:doc>
</arg>
</method>
</interface>'
function openUrl(u) { ...}
With variations of service, iface, path and none of if makes a difference. If I use any means of declaring dbus methods in the primary desktop file, lipstick won’t launch it. And I’ve double checked there are not stale files around.
One clue I had earlier was that the App name cannot have a dash, so I dealt with that (this is some time ago…
OrganizationName=de.poetaster
ApplicationName=tooterb
In any case, one can see the DBus methods with introspection, regardless what’s in the desktop file. The open-url one just facilitates the mime type/scheme handling.
[defaultuser@Phone22 ~]$ gdbus introspect --session --dest de.poetaster.tooterb --object-path /
node / {
interface org.freedesktop.DBus.Introspectable {
methods:
Introspect(out s xml_data);
signals:
properties:
};
interface org.freedesktop.DBus.Peer {
methods:
Ping();
GetMachineId(out s machine_uuid);
signals:
properties:
};
node de {
};
node org {
};
};
There is a fundamental issue with your links. Status/replies, etc that I get from my instance do not have the same status_ids as the originals. You produce links to the originals it seems. This means there is no way for me to actually link to a boost as I would fetch it via my account.
Link from the account view:
[D] openUrl:43 - openUrl called via DBus:https://mastodon.gamedev.place/authorize_interaction?uri=https%3A%2F%2Ficosahedron.website%2F%40YkkPanels%2F117196325096728556
[D] openUrl:51 - https://icosahedron.website/@YkkPanels/117196325096728556
[D] openUrl:55 - 117196325096728556
[D] openUrl:56 - YkkPanels
[D] onSearchChanged:201 - @YkkPanels
Link from my instance:
] expression for status_link:38 - https://icosahedron.website/users/YkkPanels/statuses/117196325096728556
[D] expression for status_link:39 - ["https:","","icosahedron.website","users","YkkPanels","statuses","117196325096728556"]
[D] expression for status_link:40 - 7
[D] onTriggered:136 - Scrolling to status_id: 117196325375904151 at index 0
The last line status id, 117196325375904151 is the one for my mastodon instance. Your links are generic, which is fine for a web browser but won’t work with tooter.
The only thing I can do with your links is to send people to the persons profile since I can launch search for the @ which at least get’s you in the vicinity. So, when a link from your view is resolved, I present the search field filled with @username and the results can immediately be clicked. Not really idea.
I’m not sure if the plugin can do much differently and remain compatible with browsers. It does receive that other ID, but can’t really pass it on, and instead relies on the authorize_interaction controller to resolve it. Even when I add the ap: scheme there isn’t really anywhere to put it then either.
Maybe you can do something like this?
GET /api/v2/search?q=<encoded url>&type=statuses&resolve=true&limit=1
Which I think should return you that local ID.
That’s true, though it is a a downside of the account integration.
I’m not even sure what that is? Tooter does oauth once and then stores a token so it doesn’t use that. The mastodon API implementation from tooter is ancient so it’s probably just not covered. v2 stuff is generally an add on in the workerscripts.
I’ll try to add something along these lines.
Announcing version 1.4.2 with fixes for redundant links, other bug fixes, and somewhat better integration with mastodon links from the account plugin. The latter only from chum coming to a store near you…
Amazing, thank you for your hard work!
Does this mean that you cracked somehow how to open the posts from the account plugin? Or as you explained, does it only open the profile of the person who posted?
It’s still opening to the user search with the user who was found displayed. I wanted to get other fixes out, so I’m still working on the ‘search for post’ variant …
Highly appreciated, Tooter is in daily use here!
I’ve become a bit of a fedi junky, I’ll admit
Please report if you are missing translations, please. I’ve had one report so far … THANKS!
@poetaster aren’t you from Germany? What about a german translation then?
I’m hoping for a Swedish translation.
It is mainly there. It is just a bit off. Can check it tomorrow if no firefighting (systemwise) gets in between
There IS a German translation. I’m not sure why they wouldn’t be active. EDIT: found it.