Comment by ~reedwade on ~reedwade/wee-matter
The channel data that mattermost give us do not include any preference information.
{ "id": "3zxxaxsbjprmtqdjgz98zr6wba", "create_at": 1620804972576, "update_at": 1620804972576, "delete_at": 0, "team_id": "", "type": "G", "display_name": "bartoot, reedwade, stacyharper", "name": "efecc40ae910586233b5c4f03809c0ef062f4da2", "header": "", "purpose": "", "last_post_at": 1620804980984, "total_msg_count": 1, "extra_update_at": 0, "creator_id": "", "scheme_id": null, "props": null, "group_constrained": null }
So we have to make another extra query on load do determine them.
Then we could rely on the preferences_changed event
{ "event": "preferences_changed", "data": { "preferences": [ { "user_id": "cddn4idgqpgpdd61ph16rppo7e", "category": "group_channel_show", "name": "3zxxaxsbjprmtqdjgz98zr6wba", "value": "false" } ] }, "broadcast": { "omit_users": null, "user_id": "cddn4idgqpgpdd61ph16rppo7e", "channel_id": "", "team_id": "" }, "seq": 14 } { "event": "preferences_changed", "data": { "preferences": [ { "user_id": "cddn4idgqpgpdd61ph16rppo7e", "category": "group_channel_show", "name": "3zxxaxsbjprmtqdjgz98zr6wba", "value": "true" }, { "user_id": "cddn4idgqpgpdd61ph16rppo7e", "category": "channel_open_time", "name": "3zxxaxsbjprmtqdjgz98zr6wba", "value": "1620809951275" } ] }, "broadcast": { "omit_users": null, "user_id": "cddn4idgqpgpdd61ph16rppo7e", "channel_id": "", "team_id": "" }, "seq": 8 }
The
value
here is the toggle boolean that we could rely on to hide/show the buffer.I'm sorry but I will not implement this as it look like lot of complexity and lot of initial http queries for a very little feature. Maybe you could ask the Mattermost team to add the information in the
/api/v4/users/" + user_id + "/teams/" + team_id + "/channels
endpoint response, and then it will be easy to do.Feel free to implement it and send a patch if you feel I'm wrong.
Comment by ~reedwade on ~reedwade/wee-matter
The issue was that group_added is a different event than direct_added. We now handle both the same way so group channel invitation now works.
REPORTED
RESOLVED FIXEDComment by ~reedwade on ~reedwade/wee-matter
If we can't distinguish and manipulate closed channels lets just add something to ignore them from the wee-mater side.
Some kind of muted_channels configurable array and two mute and unmute command should be enough.
Let's try not to complexify the code base a lot. Maybe weechat got a way to do it natively.
Need futher investigations !
Comment by ~reedwade on ~mil/sxmo-tickets
Plus, we recently add hidpi support. Maybe it still require device agnosticisation :D
You'll find the xorg monitor config in sxmo-utils:config/xorg
Comment by ~reedwade on ~mil/sxmo-tickets
Oh wait ! Another issue was double causing mine !
This actually solves the issue :D
Comment by ~reedwade on ~mil/sxmo-tickets
It would prevent touch screen usage as you would not cancel the click when touching out of the menu window.
Comment by ~reedwade on ~mil/sxmo-tickets
Yes this line display herself in some menus. I think we do some kind of
type $KEYBOARD
somewhere without> /dev/null
and this cause this crappy line.
Comment by ~reedwade on ~reedwade/wee-matter
REPORTED
RESOLVED IMPLEMENTEDComment by ~reedwade on ~mil/sxmo-tickets
This patch still is nice to have, ty. It make the bug less annoying :D
Comment by ~reedwade on ~mil/sxmo-tickets
It works for me yeah