| freemangordon | Wizzup: yes, with haze | 07:46 |
|---|---|---|
| freemangordon | weather app uses 70MB | 07:52 |
| freemangordon | so I am started to think this is qml | 07:53 |
| freemangordon | Wizzup: hmm, not sure if group chats do not work properly in 0.6, will checj | 07:56 |
| freemangordon | *check | 07:56 |
| freemangordon | arno11: how did you set-up the account? | 07:57 |
| freemangordon | I can confirm purple-facebook works properly though, in both pidgin and haze | 07:58 |
| dsc_ | qml did not change much since few months | 08:14 |
| freemangordon | did we check the memory usage back then? | 08:30 |
| dsc_ | Wizzup has been monitoring it and claims it has onl recently increassed | 08:35 |
| dsc_ | I also took some tests months ago but did not remember the values, but nothing out of the ordinary | 08:35 |
| dsc_ | < freemangordon> weather app uses 70MB <== how much is conversations currently? | 08:36 |
| freemangordon | 98 | 08:36 |
| dsc_ | iirc was always in this range, maybe even more | 08:37 |
| dsc_ | but not a lot more | 08:37 |
| freemangordon | this is huge | 08:37 |
| freemangordon | mem usage shall be no more than 40MB | 08:38 |
| freemangordon | (lets say) | 08:38 |
| freemangordon | OMP, which is qt as well, uses ~50 | 08:39 |
| dsc_ | hmm | 08:39 |
| freemangordon | but conversations being resident all the time shall use less | 08:39 |
| freemangordon | so, my bet is on QML engine | 08:40 |
| dsc_ | freemangordon: do you still have that hello-world example around? could you check that? | 08:40 |
| * freemangordon checks | 08:40 | |
| freemangordon | qml_hello uses 52MB | 08:42 |
| freemangordon | the other one uses 65 | 08:43 |
| freemangordon | that's the one that uses QQuickWidget | 08:45 |
| freemangordon | dsc_: ^^^ | 08:46 |
| dsc_ | there was a plan to decouple conversations such that a daemon is always running to register incoming messages, and the GUI be a seperate process that communicates with it | 08:46 |
| dsc_ | this was resident mem is low | 08:46 |
| dsc_ | this way* | 08:46 |
| dsc_ | so that is one "solution" | 08:46 |
| freemangordon | no, we shall find a way to reduce mem usage to a sane value | 08:46 |
| dsc_ | yes | 08:46 |
| freemangordon | like using qtwidgets | 08:46 |
| dsc_ | and removing the QML? | 08:47 |
| freemangordon | instead of QQuickWidget | 08:47 |
| freemangordon | not sure | 08:47 |
| freemangordon | but we shall remove QQuickWidget at least | 08:47 |
| freemangordon | this one alone gives 15MB diff in sample apps | 08:47 |
| dsc_ | hmm | 08:47 |
| arno11 | freemangordon: i can confirm it worked once (with very last tp haze update) then, catastrophical after reboot | 08:48 |
| freemangordon | and is also not recommended by qt docs | 08:48 |
| freemangordon | arno11: ok, but please, explain what did you do | 08:48 |
| freemangordon | and what is catastrophical | 08:49 |
| dsc_ | freemangordon: why do you think I made it via QQuickWidget | 08:49 |
| freemangordon | because I am looking into the code | 08:49 |
| arno11 | fresh install, update to devel + FB plugin and ui | 08:49 |
| freemangordon | https://github.com/maemo-leste/conversations/blob/master/src/mainwindow.cpp#L55 | 08:49 |
| dsc_ | yes, but why | 08:49 |
| freemangordon | no idea | 08:50 |
| dsc_ | so I can remove the widget when 10 windows are opened and only 1 is active ^^ | 08:50 |
| dsc_ | was a attempt at reducing mem footprint | 08:50 |
| freemangordon | see, I am not blaming you for qml being mem hungry :) | 08:51 |
| freemangordon | what I am saying is that we have an issue that shall be fixed | 08:51 |
| dsc_ | yes :) | 08:51 |
| freemangordon | if theat measns that we shall remove qml, so be it | 08:52 |
| freemangordon | *means | 08:52 |
| dsc_ | quite a lot of work went into that | 08:52 |
| freemangordon | sure, if you find other way, that's fine | 08:52 |
| freemangordon | but I am afraid there is no, given that simple sample app showing just a drawing takes 65MB | 08:53 |
| dsc_ | we've had this interface for a while, only now I am receiving this constraint ^^ | 08:54 |
| freemangordon | dsc_: how do you think, how usable is app that takes nearly half of the RAM? | 08:55 |
| freemangordon | also, I still don;t understand why do you take that personally | 08:56 |
| arno11 | freemangordon: i think someone (other than me) must check what's going on from a fresh install | 09:00 |
| freemangordon | arno11: please elaborate on "catastrophical" | 09:02 |
| freemangordon | ok, I will check when I have time | 09:02 |
| freemangordon | but still, I see nothing obviously wrong with the latest changes that can result in catastrophe | 09:02 |
| arno11 | i'm totally agree | 09:03 |
| freemangordon | so, please give me some details on what's going on | 09:03 |
| freemangordon | are you sure you start tp-haze properly? | 09:03 |
| arno11 | yes | 09:03 |
| freemangordon | because if account is set to be online, then TP start it for you | 09:03 |
| freemangordon | and you cannot have 2 instances running | 09:04 |
| arno11 | let me explain (a bit long) | 09:04 |
| freemangordon | ok | 09:04 |
| dsc_ | I think for the n900 it is def. a problem | 09:07 |
| dsc_ | for the d4 not so much | 09:07 |
| dsc_ | I suggest a QtWidgets only version for n900 | 09:08 |
| arno11 | from a fresh install with devel upgrade and FB plugin and ui, it worked once...then after reboot i got some weird troubles like presence-ui disappering, some apps thinking there is no network, pidgin running @100% cpu, starting PA and python3 threads | 09:08 |
| dsc_ | even if QML goes down to 50mb its still too much | 09:09 |
| dsc_ | for something that ought to just render text chats... | 09:10 |
| dsc_ | so, support to switch between QtWidgets/QtQuick | 09:10 |
| dsc_ | im not removing the QML interface completely, ill let you know right now, someone else can do that | 09:11 |
| dsc_ | technical implementation would be: 2 binaries that have different linkage | 09:12 |
| dsc_ | < dsc_> im not removing the QML interface completely, ill let you know right now, someone else can do that <== what I mean is, if it is decided to get rid of the QML interface in favor of QtWidgets, I wont do that | 09:13 |
| freemangordon | dsc_: lets not take any decisions, it my turn out it can be optimized | 09:13 |
| freemangordon | arno11: I would bet you OC too much | 09:14 |
| dsc_ | and for both cases, the daemon/client architecture could mitigate the remaining resident memory fears | 09:14 |
| arno11 | no even with boost deativated, it doesn't work | 09:14 |
| arno11 | and troubles start just after boot so overclock can't be involved | 09:15 |
| uvos__ | we could also just have sphone be the default message ui for very memory constrained devices (n900 essentally) | 09:15 |
| uvos__ | sure atm that comes with reduced feature set (no group chats, text only messaging) but its tiny | 09:16 |
| uvos__ | and i will have to maintain sphones message ui anyhow since i use it oustide of maemo | 09:16 |
| uvos__ | i think trying to reduce the memory usage of qml is a fools errand | 09:17 |
| freemangordon | arno11: no idea what's going on with your device, but I can assure you it is not related to fb plugin | 09:20 |
| freemangordon | so, if I were you, I would flash new image, install whatever needed and do not OC until proven stable | 09:21 |
| freemangordon | then I would OC to 720 and keep it like that for a week or so | 09:22 |
| freemangordon | then to 805 | 09:22 |
| freemangordon | and no more | 09:22 |
| arno11 | freemangordon: again, overclock is not in use... | 09:22 |
| uvos__ | i used to run my droid 1 (also omap3) at 1050MHz | 09:22 |
| uvos__ | :P | 09:22 |
| freemangordon | but, did you OC before it broke? | 09:23 |
| arno11 | overclock can't work on boot | 09:23 |
| uvos__ | 1ghz wasent usual on those | 09:23 |
| uvos__ | *unusual | 09:23 |
| freemangordon | yeah, there are some samples of n900 that were reported to run at 950 | 09:23 |
| freemangordon | no idea how stable and for how long :) | 09:23 |
| uvos__ | arno11: well one thing is that if you over oc you get memory corruption, which can end up as disk corruption | 09:24 |
| freemangordon | arno11: did you run the device OCed even for a while? | 09:24 |
| freemangordon | exactly | 09:24 |
| uvos__ | so you might be hosed even after removeing oc | 09:24 |
| freemangordon | right | 09:24 |
| freemangordon | arno11: and given that you flashed new image because your old one had similar symptoms, I would say it it the OC to blame | 09:25 |
| freemangordon | and you should not push to 850 | 09:25 |
| arno11 | i use 805 max | 09:25 |
| freemangordon | the same applies | 09:25 |
| freemangordon | even that is high | 09:26 |
| freemangordon | could you run fsck on the fs? | 09:26 |
| freemangordon | thoug, it might show noting | 09:26 |
| uvos__ | time for btrfs xD | 09:27 |
| freemangordon | :) | 09:27 |
| uvos__ | might actually be a good way to check a oc long term | 09:27 |
| freemangordon | arno11: really, I would recommend to start from scratch and *do not* enable OC | 09:27 |
| freemangordon | that way if you hit the same issue, we will know it is not OC to blame | 09:28 |
| arno11 | ok but i'm writing from the device and got no time to answer to all stuff... | 09:28 |
| freemangordon | I just rebooted my d4, which uses exactly the same fb/haze as your n900 | 09:28 |
| freemangordon | and it has absolutely no issue whatsoever | 09:28 |
| freemangordon | have to run, bbl | 09:33 |
| dsc_ | freemangordon: https://github.com/maemo-leste/conversations/tree/noquick | 10:42 |
| dsc_ | its a branch with all qml removed, but rtcom/TP still working | 10:42 |
| dsc_ | so could check the difference between with/without QML there | 10:42 |
| dsc_ | cmake -DCMAKE_BUILD_TYPE=Release -Bbuild . | 10:43 |
| dsc_ | make -Cbuild -j4 conversations-tiny | 10:43 |
| dsc_ | ./build/bin/conversations-tiny | 10:43 |
| Wizzup | dsc_: I get: | 10:55 |
| Wizzup | /home/user/conversations/src/chatwindow.cpp:69:20: error: ‘class Ui::ChatWindow’ has no member named ‘quick’ 69 | auto *qctx = ui->quick->rootContext(); | 10:55 |
| dsc_ | Wizzup: make -Cbuild -j4 conversations-tiny | 10:56 |
| Wizzup | ok | 10:56 |
| Wizzup | it does save some ram | 11:00 |
| Wizzup | max heap usage for just the first5 seconds is about 100MB without and 168MB with | 11:00 |
| Wizzup | but I am not sure if we need to care at this point | 11:00 |
| Wizzup | rtcom-messaging-ui on fremantle uses 6.7% memory on the n900 with some windows open, conversations is 17% on the n900 atm, QML is maybe half of that | 11:05 |
| Wizzup | there is still plenty of ram available on the n900 too | 11:05 |
| dsc_ | still, its quite easy for me to make something switch between QtWidgets/QtQuick | 11:19 |
| dsc_ | by having 2 binaries | 11:19 |
| dsc_ | so that option is available | 11:19 |
| Wizzup | I think we stay the course for now but keep this in mind | 11:19 |
| Wizzup | there's still the other 60% of memory that goes to non-qml things | 11:20 |
| Wizzup | I'd rather have a fully functional conversations with no memleaks and qml than nothing | 11:20 |
| dsc_ | :) | 11:21 |
| Wizzup | also splitting things out in two binaries at this point is also not a good idea, we're still figuring out how to it fully pt aware | 11:21 |
| Wizzup | s/pt/tp/ | 11:21 |
| dsc_ | no I meant we'd have `conversations` and `conversations-tiny`, the latter would omit linkage against Quick | 11:21 |
| dsc_ | what you just ran does not link against quick | 11:22 |
| dsc_ | so I only need to add a QTextBox for the chat | 11:23 |
| dsc_ | etc. | 11:23 |
| Wizzup | I mean, you can if you want to toy with it | 11:23 |
| dsc_ | above PR is like 70% of that hehe | 11:23 |
| dsc_ | and via `cmake -> make` it would generate those 2 targets | 11:24 |
| dsc_ | anyway I rather look into room registration right now | 11:24 |
| Wizzup | I think both are fine yes | 11:24 |
| Wizzup | wrt room registration, we'll have to join on various times from tp (reconnect due to network, or when the account is first online) | 11:24 |
| Wizzup | and I would use the local_uid as key | 11:25 |
| dsc_ | alright | 11:25 |
| Wizzup | and we might want to offer some interface to get the current channels from the tp account class | 11:25 |
| Wizzup | osso-addressbook uses 12.1% ram on n900 btw (compared to 10.3 conversations atm) | 11:27 |
| Wizzup | plus, most of qml might just be shared with other qml apps | 11:30 |
| Wizzup | https://forum.qt.io/topic/25330/memory-footprint-of-qml-applications?_=1704364377034&lang=en-US | 11:30 |
| dsc_ | < Wizzup> and we might want to offer some interface to get the current channels from the tp account class | 11:49 |
| dsc_ | ^-- u haz hint as to what method to use or shall I look? | 11:49 |
| Wizzup | doesn't exist yet | 11:50 |
| dsc_ | i know | 11:52 |
| dsc_ | https://github.com/KDE/kte-collaborative/blob/master/kte-plugin/ktpintegration/inftube.cpp#L117 | 11:53 |
| dsc_ | they are doing it by directly asking dbus | 11:53 |
| dsc_ | even though they use Tp | 11:54 |
| dsc_ | ill look | 11:54 |
| Wizzup | freemangordon: I don't think that is tp | 12:00 |
| Wizzup | they are talking to themselves there I think | 12:00 |
| arno11 | freemangordon: overclock is not involved, still the same issue, but doing expandcard then reboot, dist-upgrade then reboot, extras installing stuff then reboot, setting up an account with pidgin works (works in every cases with bitlbee and bitlbee-FB), with almost no cpu usage | 12:05 |
| Wizzup | freemangordon: whatever empathy does to read purple vars, it doesn't use dbus | 12:05 |
| arno11 | purple-facebook refuses to connect and presence-ui doesn't work | 12:05 |
| arno11 | maybe that's just an issue with my account btw | 12:05 |
| Wizzup | freemangordon: seems to deal with a tmp file /var/tmp/haze-59dFiV/accounts.xml | 12:07 |
| freemangordon | Wizzup: sorry, I am missing the context | 12:28 |
| freemangordon | arno11: please, please, try to not use "does not work" etc, explain what does not work instead | 12:29 |
| freemangordon | does purple-fb work through pidgin? | 12:30 |
| freemangordon | if it does not, then there is no point to test it with presence-ui, accounts-ui, conversation s, empathy etc | 12:31 |
| Wizzup | freemangordon: I am trying to understand how empathy gets the purple-specific settings through haze | 12:32 |
| freemangordon | ah | 12:32 |
| freemangordon | they are visible through tp interfaces | 12:32 |
| Wizzup | weird, I did dbus-montor | 12:32 |
| Wizzup | monitor | 12:33 |
| Wizzup | grepped for it with empathy running | 12:33 |
| freemangordon | sec, lemme try to find it | 12:33 |
| Wizzup | nothing matched the key names | 12:33 |
| freemangordon | yes, they register pidgin properties as connection/protocol properties | 12:33 |
| Wizzup | btw, in empathy I now see a channel with the new haze code in slack | 12:36 |
| Wizzup | but the messages come in as HandleTypeContact | 12:36 |
| arno11 | freemangordon: ?? as previoulsy mentioned, pidgin works well with purple-FB, and purple-FB + FB UI refuses to connect (with presence UI not working/displaying) | 12:36 |
| freemangordon | Wizzup: yes, how should they come? Like, how do you know who wrote? | 12:37 |
| Wizzup | freemangordon: they are part of a TextChannel that is a room | 12:37 |
| freemangordon | wait | 12:37 |
| freemangordon | how do you know who exactly typed that particular message? | 12:37 |
| freemangordon | if we are 3 peuple in a chat | 12:37 |
| freemangordon | *people | 12:37 |
| freemangordon | for example | 12:38 |
| Wizzup | freemangordon: message.sender()->id() | 12:38 |
| freemangordon | if message handle is the room handle, how do you know which of the 3 typed that message? | 12:38 |
| Wizzup | that is not the same as the channel->targetHandleType() | 12:38 |
| freemangordon | what is message? | 12:38 |
| Wizzup | any incoming message | 12:39 |
| freemangordon | sac | 12:39 |
| Wizzup | the channel facilitates the sending and receiving of messages, and the message itself contains who sends it | 12:39 |
| Wizzup | the channel reports if it is a single 1:1 or room (multi user) channel | 12:39 |
| Wizzup | it looks like in this case in haze this is not correct yet, BUT | 12:39 |
| Wizzup | somehow empathy gets it ok | 12:39 |
| Wizzup | maybe it looks at the supported interfaces | 12:39 |
| freemangordon | see https://github.com/maemo-leste-upstream-forks/telepathy-haze/blob/maemo/chimaera-devel/src/mu-channel.c#L774 | 12:40 |
| freemangordon | Wizzup: yes, empathy gets it ok | 12:40 |
| freemangordon | that's why I think I am doing it properly | 12:40 |
| freemangordon | I guess you mean TpMessage or QTpMessage (made-up qt wrapper) | 12:41 |
| freemangordon | then again, you have sender there | 12:41 |
| Wizzup | It's not correct when compared to telepathy-gabble or telepathy-irc (whatever it is called) | 12:41 |
| freemangordon | is it? | 12:41 |
| Wizzup | it doesn't matter what struct the message is in | 12:41 |
| freemangordon | right | 12:42 |
| Wizzup | so in telepathy-gabble and the telepathy-idle (irc) | 12:42 |
| freemangordon | do you have tp-gabble message structure for multi-user chat incomming message? | 12:42 |
| freemangordon | dbus would do the job as well | 12:42 |
| Wizzup | a channel that is a room has a targethandletype that is not HandleTypeContact | 12:42 |
| Wizzup | sure | 12:43 |
| freemangordon | right | 12:43 |
| Wizzup | sec | 12:43 |
| freemangordon | and it is not in case of haze as well | 12:43 |
| freemangordon | see https://github.com/maemo-leste-upstream-forks/telepathy-haze/blob/maemo/chimaera-devel/src/mu-channel.c#L136 | 12:43 |
| freemangordon | sender != target handle type, IIUC | 12:44 |
| Wizzup | empathy gets in the way so much lol | 12:44 |
| freemangordon | Wizzup: BTW, I am not saying I didn't do something stupid in tp-haze, feel free to have a look at the code | 12:45 |
| freemangordon | but i looked in idle code and they set the sender handle as contact | 12:45 |
| freemangordon | not as a room | 12:45 |
| * freemangordon checks again | 12:45 | |
| Wizzup | freemangordon: same @ conversations code :p | 12:46 |
| Wizzup | 12:45 < freemangordon> but i looked in idle code and they set the sender handle as contact | 12:47 |
| Wizzup | for every channel? | 12:47 |
| Wizzup | freemangordon: I see a lot of matches for TP_HANDLE_TYPE_ROOM in telepathy-gabble at least | 12:48 |
| Wizzup | I don't have telepathy-idle src here, but will get it | 12:48 |
| Wizzup | freemangordon: btw check your dm | 12:48 |
| freemangordon | Wizzup: ok, look at MessageReceived | 12:49 |
| freemangordon | message-sender | 12:49 |
| freemangordon | is 26 | 12:49 |
| freemangordon | I can bet this is contact handle, not room | 12:49 |
| Wizzup | of course it is | 12:49 |
| Wizzup | but look at EnsureChannel | 12:49 |
| Wizzup | dict entry( | 12:49 |
| Wizzup | string "org.freedesktop.Telepathy.Channel.TargetHandleType" | 12:49 |
| Wizzup | variant uint32 2 | 12:49 |
| Wizzup | ) | 12:49 |
| Wizzup | That is uint32 2 | 12:49 |
| Wizzup | not uint32 1, as it seems to be with haze muc | 12:50 |
| freemangordon | this is the room handle | 12:50 |
| Wizzup | yes, but with haze muc it is 1 | 12:50 |
| freemangordon | but this is for ensure_channel | 12:50 |
| Wizzup | yes, that's the point | 12:50 |
| freemangordon | umm... | 12:50 |
| Wizzup | let me explain again :) | 12:50 |
| freemangordon | this is handle, not handle type, or? | 12:50 |
| Wizzup | when we get an incoming message, the message arrives on a channel | 12:50 |
| Wizzup | ok? | 12:50 |
| freemangordon | ah, it is | 12:50 |
| freemangordon | wait, wait | 12:50 |
| Wizzup | sure | 12:50 |
| freemangordon | just a sec to check something | 12:50 |
| Wizzup | there is another thing to check, it's called channeltype, I don't know what it is | 12:52 |
| freemangordon | see https://github.com/maemo-leste-upstream-forks/telepathy-haze/blob/maemo/chimaera-devel/src/mu-channel-manager.c#L526 | 12:52 |
| Wizzup | ah no, that is just text or not | 12:52 |
| freemangordon | so I don;t know where did you gat that 1 from | 12:52 |
| freemangordon | *get | 12:53 |
| Wizzup | ok, let me log and try again | 12:53 |
| freemangordon | are you sure it is MU channel? | 12:53 |
| freemangordon | perhaps run tp-haze with all logs enabled | 12:54 |
| Wizzup | k dict entry( | 12:54 |
| Wizzup | string "org.freedesktop.Telepathy.Channel.TargetHandleType" | 12:54 |
| Wizzup | variant uint32 1 | 12:54 |
| Wizzup | ) | 12:54 |
| Wizzup | dict entry( | 12:54 |
| Wizzup | string "org.freedesktop.Telepathy.Channel.TargetHandleType" | 12:54 |
| Wizzup | variant uint32 1 | 12:54 |
| Wizzup | ) | 12:54 |
| Wizzup | rom dbus-monitor | 12:55 |
| Wizzup | i'll paste it, sec | 12:55 |
| freemangordon | what is the path? | 12:56 |
| Wizzup | see dm | 12:56 |
| freemangordon | hmm | 12:57 |
| freemangordon | where does that come from? | 12:57 |
| Wizzup | sorry? | 12:58 |
| freemangordon | member=NewChannels | 12:58 |
| freemangordon | I mean - where that target handle type comes from | 12:58 |
| freemangordon | like, I am sure I set to to room everywhere | 12:58 |
| Wizzup | cm | 12:58 |
| Wizzup | it is not impossible that the purple slack plugin does something odd | 12:59 |
| Wizzup | but conversations receives the wrong type | 12:59 |
| Wizzup | the channel is made on demand when a message is entered in it | 13:00 |
| Wizzup | also, I can't join channels from empathy, but that might again be a thing in this specific purple plugin | 13:00 |
| freemangordon | the same happens with purple-fb, channel is created on-demand | 13:00 |
| freemangordon | you can't because it is still not supported :) | 13:00 |
| Wizzup | right | 13:00 |
| Wizzup | maybe check if the handle is 1 or 2 in purple-fb | 13:00 |
| freemangordon | that's another thing to be implemented (rooms list) | 13:00 |
| freemangordon | going to | 13:01 |
| Wizzup | I think a room list is a list of joinable channels, I don't think you need that implemented to be able to join a channel | 13:01 |
| Wizzup | that is just for searching channels | 13:01 |
| dsc_ | i also came to that guessing conclusion 1hr ago | 13:02 |
| dsc_ | while looking at RoomListChannel | 13:03 |
| freemangordon | Wizzup: hmm, target handle type is 1 for fb as well | 13:03 |
| freemangordon | maybe this https://github.com/maemo-leste-upstream-forks/telepathy-haze/blob/maemo/chimaera-devel/src/mu-channel.c#L452 is wrong | 13:03 |
| * freemangordon checks idle | 13:03 | |
| Wizzup | dsc_: yeah just lmk what you need from tp and I can add it | 13:04 |
| Wizzup | dsc_: we already have a qlist of channels per account | 13:04 |
| Wizzup | so I can return those | 13:04 |
| dsc_ | Wizzup: where do you have that? | 13:05 |
| Wizzup | tp code, in TelepathyAccount class, also see hasChannel | 13:06 |
| Wizzup | but I still need to write you an iface to get them | 13:06 |
| dsc_ | Wizzup: conversations starts | 13:07 |
| dsc_ | then I'd like to ask TP what channels there are (per account) | 13:07 |
| dsc_ | er sec | 13:07 |
| dsc_ | hasChannel is empty | 13:08 |
| dsc_ | channels is empty* | 13:08 |
| dsc_ | while Tp is connected to one | 13:08 |
| dsc_ | so what do you mean? | 13:09 |
| dsc_ | :d | 13:09 |
| dsc_ | handleChannels is also not called | 13:10 |
| Wizzup | wait | 13:11 |
| freemangordon | variant uint32 2 | 13:13 |
| freemangordon | :) | 13:13 |
| freemangordon | ok, will push that | 13:13 |
| dsc_ | freemangordon: im interested in your memory measurements of this `conversations-tiny` | 13:17 |
| dsc_ | 98-(conversations-tiny) = qml overhead | 13:18 |
| freemangordon | do you still use qquickwidget? | 13:18 |
| dsc_ | no, im not linking against quick anymore at all | 13:18 |
| freemangordon | ok | 13:19 |
| freemangordon | will do later on | 13:19 |
| freemangordon | have work mtg in 10 minutes | 13:19 |
| dsc_ | but it still links rtcom/gtk/telepathy/osso | 13:19 |
| dsc_ | so its a good measurement | 13:19 |
| dsc_ | sure, thanks | 13:19 |
| freemangordon | also, I saw abook_init is called twice | 13:20 |
| freemangordon | Wizzup: please upgrade tp-haze and check if it is op now | 13:22 |
| freemangordon | *ok | 13:22 |
| freemangordon | keep in mind invites are still not implemented | 13:22 |
| Wizzup | freemangordon: now it works | 13:26 |
| freemangordon | cool | 13:26 |
| Wizzup | logging it as a channel and sending back messages | 13:26 |
| freemangordon | "as a channel"? | 13:27 |
| freemangordon | you mean mu channel I hope | 13:27 |
| Wizzup | room | 13:27 |
| Wizzup | we have to come up with the same terminology I guess | 13:27 |
| freemangordon | muc == room | 13:27 |
| Wizzup | I still use channel as analogous to room | 13:27 |
| freemangordon | i prefer muc | 13:27 |
| Wizzup | except specifically in tp context | 13:28 |
| Wizzup | but this is the #maemo-leste channel | 13:28 |
| freemangordon | this is what tp plugins use | 13:28 |
| Wizzup | not the #maemo-leste muc :) | 13:28 |
| freemangordon | heh | 13:28 |
| freemangordon | this is not TP ;) | 13:28 |
| freemangordon | in TP terms IM channels are still channels | 13:29 |
| Wizzup | yeah | 13:29 |
| Wizzup | but when I say 'logs as a channel' I mean room | 13:29 |
| Wizzup | since everything is a channel in tp so the statement wouldn't make sense otherwise | 13:30 |
| Wizzup | but I will try to do it better | 13:30 |
| freemangordon | that's why MU vs IM | 13:31 |
| freemangordon | brb | 13:31 |
| maemouw | Does Maemo Leste with Pinephone Convergence dock support route 4G connection internet to ethernet? | 13:47 |
| maemouw | Any hints would be welcome how I should route internet to Raspberry Pi2 Industrial from Pinephone? | 13:52 |
| Wizzup | the usb cable should expose usb net | 13:53 |
| Wizzup | https://leste.maemo.org/Status/USB_Peripheral | 13:53 |
| maemouw | so USBA - USB-A from Pinephone to Raspberry PI? | 13:54 |
| maemouw | *USB-A - USB-A cable | 13:55 |
| Wizzup | yes | 13:57 |
| gnarface | you might need RNDIS support compiled in the kernel and the usbnet driver loaded on the rpi? | 14:01 |
| Wizzup | yeah, we currently have rndis... | 14:01 |
| Wizzup | sicelo: should we switch back frmo rndis? | 14:01 |
| Wizzup | to what we had befofe? | 14:01 |
| Wizzup | before* | 14:01 |
| gnarface | is there something besides RNDIS that can do usb networking on these? | 14:02 |
| gnarface | i wasn't aware there were alternatives, but it would be nice to have a second option now that RNDIS is being purged from newer kernels | 14:04 |
| gnarface | i didn't need it for anything but the usbnet part | 14:04 |
| maemouw | these questions put me back to think is it possible route 4G connection to ethernet, because if so I dont have to configure Pi at all. | 14:07 |
| gnarface | maemouw: yea, routing should work like any other linux box | 14:08 |
| freemangordon | Wizzup: it is safe to delete rtcom el db, right? | 14:08 |
| dsc_ | yes | 14:08 |
| freemangordon | thanks | 14:09 |
| Wizzup | gnarface: yeah there is, the one we were using before | 14:13 |
| Wizzup | I don't recall the name, we just went for rndis for windows support, but then windows said they'd drop support for it | 14:14 |
| maemouw | gnarface: Docking bar ethernet port shows up and I am as far that here (how to ping from Pinephone with that port): https://talk.maemo.org/showthread.php?t=101354 | 14:18 |
| maemouw | that question might to to opposite direction...but anyway.. | 14:23 |
| Wizzup | btw, conversations does not yet notice new accounts if they are added after conversations is started | 14:29 |
| maemouw | actual question might be how to get that port to "in use". I am newbie with this kind of stuff..maybe I have forget some basic stuff. | 14:29 |
| Wizzup | I'll fix that now | 14:29 |
| dsc_ | Wizzup: afraid to ask but leaving a channel? :> | 14:33 |
| dsc_ | *without having a channel instance yet | 14:33 |
| dsc_ | i.e: tp is already connected to a room but conversations doesnt know it yet | 14:33 |
| dsc_ | i'd like to leave the room (without calling joinChannel manually first) | 14:34 |
| dsc_ | or maybe a different question: do we currently have other chat clients that could use telepathy? | 14:35 |
| dsc_ | if not; the state between conversations:tp could always be 1:1 without having to ask TP for its state (yes, hacky) | 14:35 |
| dsc_ | since conversations would be the only way to join a room, hence it should also know which rooms it is in | 14:36 |
| Wizzup | hang on | 14:47 |
| Wizzup | i'll dm | 14:48 |
| sicelo | Wizzup: what did we have before RNDIS? maybe should do NCM now | 15:02 |
| Wizzup | sicelo: I don't know tbh, just what I thought was 'generic' | 15:02 |
| bencoh | wait, windows is dropping support for rndis? | 15:03 |
| freemangordon | dsc_: /home/user/tmp/conversations/src/chatwindow.cpp:69:20: error: ‘class Ui::ChatWindow’ has no member named ‘quick’ | 15:04 |
| sicelo | bencoh: i doubt. but linux has. | 15:06 |
| Wizzup | freemangordon: use other make command | 15:06 |
| Wizzup | see backlog | 15:06 |
| sicelo | Wizzup: we were on ECM before. https://github.com/maemo-leste/hildon-usb-gadgets/commit/78d180f077c528552e538742f54021b33cf63c3b | 15:07 |
| bencoh | sicelo: uh | 15:07 |
| sicelo | let's go NCM ... it's successor of ECM | 15:07 |
| freemangordon | Wizzup: ok | 15:11 |
| Wizzup | freemangordon: did you find it? | 15:14 |
| Wizzup | make -Cbuild -j1 conversations-tiny | 15:14 |
| Wizzup | sicelo: fine by me | 15:25 |
| Wizzup | sicelo: btw, it seems to me that currently in leste the static ip is not longer configured | 15:25 |
| sicelo | for USB? | 15:29 |
| Wizzup | yes | 15:30 |
| Wizzup | if you connect the usb cable and just type 'ifconfig', do you see the ip assigned? | 15:30 |
| Wizzup | hm... it is | 15:30 |
| Wizzup | I must remember wrong | 15:31 |
| gnarface | oh, maemouw left... if maemo-leste doesn't have some custom tool for this someone tell him to just install ufw or something like that | 15:34 |
| Wizzup | the wiki mentions how to do it I think | 15:36 |
| Wizzup | but yeah it needs to be improved | 15:36 |
| Wizzup | ideally the dialog that pops up when you plug in would just say "share with pc" | 15:36 |
| gnarface | oh, cool | 15:36 |
| Wizzup | it does have "PC Suite mode" | 15:36 |
| Wizzup | we just never added the code to set up the routing | 15:36 |
| Wizzup | freemangordon: btw, rtcom accounts ui won't let me add accounts if my disk is 99% full even though I have 1GB free | 15:54 |
| Wizzup | not really a problem but yeah | 15:54 |
| sicelo | great @IP. was getting worried for a moment :-) | 15:55 |
| freemangordon | dsc_: so, tiny one uses 50MB on startup | 15:57 |
| freemangordon | and 60 MB when it shows the window | 15:57 |
| freemangordon | 'normal' uses 55 on startup and 80 with window | 16:00 |
| freemangordon | opening conversation makes it increase to 91MB | 16:01 |
| freemangordon | I wonder how much a simple QMainWindow app will use | 16:01 |
| Wizzup | it does clever things with multiple windows btw | 16:01 |
| Wizzup | freemangordon: btw, I saw 100MB on startup, so that's funny | 16:02 |
| freemangordon | it seems to depend on the history you have | 16:02 |
| freemangordon | I cleaned rtcom db beforehand | 16:02 |
| freemangordon | so I have only one message there | 16:02 |
| Wizzup | right | 16:02 |
| freemangordon | in the same time h-d uses ~23MB, Xorg less than 20MB | 16:04 |
| Wizzup | osso-addressbook used more ram when it was open for me on fresh n900 install with no contacts | 16:04 |
| Wizzup | to provide some perspective | 16:04 |
| freemangordon | here, with lots of contacts it uses 26MB | 16:04 |
| freemangordon | including my FB contacts with avatars | 16:05 |
| freemangordon | maybe about 40, no sure | 16:05 |
| freemangordon | all the time I am talking about RES value in top | 16:05 |
| freemangordon | not sure how correct is that | 16:06 |
| Wizzup | it won't account for shared ram I think | 16:07 |
| Wizzup | rather, it does account for it, but not for the fact that it is shared with others | 16:07 |
| freemangordon | I wonder if making it .launch will have any visible effect | 16:07 |
| freemangordon | at least GTK stuff should be stripped | 16:07 |
| Wizzup | the qml libraries are already shared through linux | 16:07 |
| freemangordon | not really | 16:07 |
| freemangordon | no other process is using qml | 16:07 |
| Wizzup | so loading a .so and now changing anything means every application will have the exact same copy open in its own ram? | 16:08 |
| Wizzup | I don't think that's how it works right | 16:08 |
| freemangordon | agree, but that's not what I am saying | 16:08 |
| freemangordon | "The non-swapped physical memory a task has used." | 16:09 |
| freemangordon | that's what RES is | 16:09 |
| freemangordon | lemme remove the swap | 16:09 |
| freemangordon | this is with no swap https://pastebin.com/ZWKPNJFz | 16:12 |
| freemangordon | adressbook is opened though | 16:13 |
| freemangordon | see osso-abook-home-applet usage | 16:13 |
| freemangordon | it also uses libabook and I have 2 contacts on the desktop | 16:13 |
| dsc_ | so the qml overhead is 20mb | 16:17 |
| freemangordon | at least | 16:17 |
| freemangordon | I will make a simple qwidgets app, to check what is qt minimum | 16:18 |
| freemangordon | simple qapplication app uses ~30MB | 16:23 |
| freemangordon | simple gui application with one QPushButton: ~42MB | 16:25 |
| dsc_ | its possible to create a custom Qt5 build with features carved out, often applied for embedded devices | 16:27 |
| dsc_ | but its a headache | 16:28 |
| freemangordon | 40 MB for qt UI application is not that bad | 16:28 |
| freemangordon | I will try to make it .launch to see if it will get better | 16:29 |
| dsc_ | :) | 16:29 |
| freemangordon | from only GTK booster we gain 1MB | 16:35 |
| Wizzup | guys I am without power, bbl | 16:36 |
| freemangordon | dsc_: https://pastebin.com/YKqq1bfW | 16:37 |
| dsc_ | freemangordon: what is .laucher? | 16:44 |
| freemangordon | dsc_: https://github.com/maemo-leste/maemo-launcher/blob/master/README | 16:46 |
| dsc_ | thats nice | 16:47 |
| freemangordon | yeah | 16:48 |
| freemangordon | unfortunately we don;t have qt booster | 16:48 |
| freemangordon | though I can try to make one :) | 16:48 |
| dsc_ | for me its not so much effort to make QtWidgets version as previously suggested | 16:50 |
| dsc_ | so thats -20mb | 16:50 |
| freemangordon | or even more | 16:50 |
| freemangordon | so to me it makes sense | 16:50 |
| freemangordon | but again, as Wizzup said, lets first have it functional | 16:51 |
| dsc_ | you'd like to get rid of qml completely? | 16:51 |
| dsc_ | for both n900 and d4? | 16:51 |
| freemangordon | perhaps, dunno | 16:51 |
| freemangordon | what do we gainfrom using it? | 16:51 |
| freemangordon | also, does it make sense to support 2 applications? | 16:52 |
| freemangordon | still, lets not focus on that now | 16:52 |
| freemangordon | lets have the functionality in place first | 16:53 |
| dsc_ | what do we gain from not using QML? | 16:53 |
| freemangordon | memory :) | 16:53 |
| dsc_ | how much? | 16:53 |
| freemangordon | given that omp uses less than half of the memory conv uses, I would say a lot | 16:54 |
| dsc_ | that's not a number | 16:54 |
| freemangordon | 45 vs 100 | 16:54 |
| dsc_ | qml uses 100mb? the overhead was 20 | 16:55 |
| dsc_ | (or more) | 16:55 |
| dsc_ | im mostly interested about what percentage it is of d4's total memory | 16:55 |
| freemangordon | with non-empty db it uses more | 16:55 |
| freemangordon | dsc_: it is not about d4 vs n900 | 16:56 |
| freemangordon | I have a tablet on my desk with 512 MB | 16:56 |
| freemangordon | n950 has 512 as well | 16:56 |
| freemangordon | if we are to support it someday | 16:57 |
| dsc_ | indeed it is not about the device, but about how much resident memory is acceptable | 16:58 |
| dsc_ | but if we gain max 20mb/30mb then one wonders how much percentage that is of total | 16:58 |
| dsc_ | my point is that if QML is not acceptable then maybe Qt in general is not acceptable | 16:59 |
| dsc_ | C/Gtk is always going to be more efficient | 16:59 |
| freemangordon | yeah, but I would trade 10MB for programming efficiency | 16:59 |
| bencoh | tbh I'd tend to think core applications should be written in c/gtk, unless <insert reason here> | 17:00 |
| freemangordon | for conversations it will be a nightmare | 17:00 |
| bencoh | indeed | 17:00 |
| freemangordon | because of the UI part | 17:00 |
| freemangordon | so I would trade some RAM | 17:00 |
| freemangordon | also, if I manage to make qt booster, then the penalty will not be that big | 17:01 |
| freemangordon | but we cannot avoid JS engine penalty, it will always allocate some amoutns of RAM, even if not needed | 17:01 |
| freemangordon | (8MB they are saying) | 17:01 |
| dsc_ | picking a framework merely on how efficient it is will always lead to C/Gtk, or some minimalist framework, or assembly... ;) | 17:02 |
| dsc_ | people use Qt for speed of development | 17:02 |
| freemangordon | agree | 17:02 |
| dsc_ | however like bencoh says it is quite core to the OS | 17:03 |
| inky | but what about the future? i remember firefox on d4 was okay till chimaera. qt js engine may become much hungrier after one release. | 17:03 |
| inky | i am afraid just recompiling same code could cause more and more memory usage. | 17:03 |
| inky | on future platforms. | 17:03 |
| freemangordon | sorry guys, ahve to leave | 17:03 |
| freemangordon | ttyl | 17:03 |
| inky | about 20 years ago i was only using very weak macihnes. gtk was always much faster than qt, i felt it. | 17:04 |
| inky | don't know about today, i think gtk4 is very heavy. | 17:04 |
| freemangordon | actually qt's js engine is google's V8 one | 17:07 |
| freemangordon | hard to predict what would happen | 17:07 |
| uvos | if anything gtk4 is heavier than qt5/6 besides qml | 17:32 |
| uvos | so gtk istent going to save you for long | 17:32 |
| uvos | the gtk booster dosent gain 1mb | 17:33 |
| bencoh | let's move to LVGL :> | 17:33 |
| uvos | that absurd it gains about 100kb per process, while takeing an to me unkown amount of memory for the deamon itself | 17:33 |
| uvos | it probubly bearly breaks even with few apps running | 17:34 |
| uvos | the 100kb is also very generously mesured | 17:34 |
| freemangordon | well, according to top it is slightly > than 1MB | 17:38 |
| freemangordon | https://pastebin.com/YKqq1bfW | 17:38 |
| uvos | we mesured this in detail before with the script that devides for shared memory regions and accounts for xorg surfaces | 17:39 |
| uvos | its essentally nothing | 17:39 |
| freemangordon | uvos: how much memory does it take for all the sybols resolution and gtk/pango/cairo statically allocated data? | 17:43 |
| freemangordon | *symbols | 17:43 |
| uvos | i dont know it in that detail | 17:44 |
| uvos | but the way we mesured it was takeing private memory, adding the shared memory regions per region devided by the number of procesies that map that region | 17:44 |
| uvos | and then adding the increase in memory usage of maemo-launcher that is incured when launching the app | 17:45 |
| uvos | the last part is the vast majoraty of the memory usage in the launcher case | 17:45 |
| uvos | because somhow launcher ends up with most of the allocations for some reason | 17:45 |
| uvos | not sure how that works | 17:45 |
| uvos | in the non launcher case you do the same, just no launcher obv | 17:46 |
| uvos | i did this back when .launches where binaries not shared lib | 17:46 |
| uvos | so you could execute them directly | 17:46 |
| freemangordon | so, how would you explain the pastebin ^^^ | 17:47 |
| freemangordon | I did that several times | 17:47 |
| uvos | wel i cant see it | 17:47 |
| uvos | its not available | 17:47 |
| freemangordon | oh, sorry | 17:47 |
| freemangordon | 12022 user 20 0 137524 42216 35772 S 0.0 4.1 0:01.55 qttest .launcher | 17:47 |
| freemangordon | 12081 user 20 0 136384 43324 36964 S 3.9 4.3 0:01.00 qttest normal | 17:47 |
| freemangordon | 43324 vs 42216 | 17:48 |
| uvos | launcher changes accounting | 17:48 |
| freemangordon | this is a simple application with one push button | 17:48 |
| uvos | you will note that the launcher will end up with more memory used after the launch | 17:48 |
| freemangordon | launcher just forks and calls main() | 17:49 |
| freemangordon | I don't see how would that increase any memory of the daemon | 17:49 |
| uvos | it dose for gtk programs, its possible it dosnt here because that happens because of somehting the booster dose | 17:49 |
| freemangordon | booster does nothing for qt (still) | 17:50 |
| freemangordon | but qt also uses gtk and pango and cairo (via gtk) | 17:50 |
| freemangordon | so all the data thise FW allocate an process startup is savesd | 17:50 |
| uvos | anyhow its using more shared memory | 17:50 |
| freemangordon | ald the glib objects etc | 17:50 |
| uvos | which is probubly meaningless | 17:50 |
| freemangordon | just imagine how much we save from not creating glib object classes | 17:51 |
| freemangordon | I would argue | 17:51 |
| uvos | well i did this mesurement in high detail on osso-xterm and came up with about 100kb | 17:51 |
| Wizzup | wasn't it more about startup speed than memory saving? | 17:51 |
| uvos | Wizzup: no it saves no speed | 17:51 |
| uvos | i also did that mesurement | 17:52 |
| uvos | that one is still on github | 17:52 |
| uvos | it saves no speed over the readahead replay case | 17:52 |
| uvos | on d4 | 17:52 |
| uvos | but it dose decrease cpu usage some, but launching is io bound so it ends up a tie in terms of speed | 17:52 |
| uvos | also it causes the libs to be in memory allready on first launch | 17:53 |
| uvos | so first launch is faster if you dont have something like systemd-readahead | 17:53 |
| freemangordon | then your measurements are broken, because it saves all the symbols resolution | 17:53 |
| freemangordon | because libs are already there, with symbols resolved | 17:53 |
| uvos | saveing symbols resolution is the reason why it takes less cpu time | 17:53 |
| uvos | but this has no effect on launch speed | 17:53 |
| freemangordon | how's that? | 17:53 |
| uvos | because the whole process is io bound | 17:53 |
| uvos | the cpu _is_ more busy but the if you go gtk_init(); return 0; in main the launcher and non launcher process will end up exiting within mesurement error time wise | 17:54 |
| uvos | but the non launcher process will have kept the cpu more busy | 17:55 |
| uvos | i gues this may not be true on n900 since the io is the same speed but the cpu is slower | 17:55 |
| uvos | anyhow launcher dose help here since we dont have systemd to help us and i keeps all the often used libs in ram | 17:56 |
| freemangordon | doing simply gtk_init() is not the usual case | 17:56 |
| freemangordon | usually you create lots of glib classes | 17:56 |
| freemangordon | and this is where it makes the difference | 17:56 |
| freemangordon | because the static memory is already allocated | 17:57 |
| freemangordon | by static I mean it is heap mamory but allocated only once per process lifetime | 17:57 |
| uvos | well the intention was to make symbol resolution the main part of the execution time | 17:57 |
| Wizzup | did we ever try ksm? | 17:57 |
| freemangordon | also, all the so symbols are resolved only once | 17:57 |
| Wizzup | or did this incur pm hit? | 17:57 |
| uvos | to maximise the launcher efect | 17:57 |
| uvos | Wizzup: i did | 17:58 |
| uvos | Wizzup: it helps some | 17:58 |
| uvos | dont remember the numbers | 17:58 |
| uvos | but maybe a couple meg on d4 at the expense of a lot of cpu time | 17:58 |
| Wizzup | seems worth doing in any case | 17:58 |
| Wizzup | hmm | 17:58 |
| uvos | n900 cant do it imo | 17:58 |
| Wizzup | a lot of cpu time? | 17:58 |
| uvos | yeah so theres 2 problems with this | 17:59 |
| uvos | i started it on boot and then stoped it after it was done with a pass, it takes a huge amount of cpu time just after boot while its doing its thing (pegging one core) | 17:59 |
| uvos | and it only helps with stuff launched while its active | 17:59 |
| uvos | it could be used on d4 since you have another core to service the user | 18:00 |
| uvos | but on n900 its going to suck | 18:00 |
| uvos | and a pass takes like 10 minutes | 18:00 |
| uvos | so in the end i dont think its usefull atm | 18:01 |
| uvos | since d4 has no problems with ram anyhoiw | 18:01 |
| uvos | anyhow so my over arching point is that yes maemo launcher helps some, but most of the ram is shared allready so it only helps a little, and you have to take into account the amount of ram used by the launcher itself devided by the launch procesies | 18:04 |
| uvos | also for speed it helps not very mutch besides being effectively a good disk catch (which is nothing to sneeze at) and maybe a bit more on devices with fast io realtive to cpu (n900) | 18:05 |
| uvos | but it aint magic | 18:05 |
| uvos | *cache | 18:06 |
| freemangordon | sure it is no magic | 18:07 |
| freemangordon | but it is not useless as well | 18:07 |
| uvos | i never said its useless, i have questioned the matiniance burde to usefullness ratio in the past (esp problems with glibc) but not the absoult merit. and besides as long as i dont have to maintain it i dont care mutch | 18:08 |
| uvos | also since qt internals change pretty rapidly i question the wisdom of trying to hack around in those internels with a boost module, but if you want to keep up with that, thats fine. | 18:09 |
| freemangordon | at least we can try | 18:09 |
| uvos | sure | 18:09 |
| freemangordon | like, having QApplication ang QWidget loaded byt the booster | 18:09 |
| uvos | sure yeah, also maybe qt has some special proparties that make it mutch more sutable to having more stuff in shm than gtk2 is | 18:10 |
| uvos | i have no idea | 18:10 |
| Wizzup | uvos: wrt ksm using a lot of cpu, was it something that could be tweaked? | 18:44 |
| uvos | i mean not really | 18:51 |
| uvos | fundamentally it needs to compute a hash of every page | 18:51 |
| uvos | thats very expensive no matter how you cut it | 18:52 |
| Wizzup | uvos: right, but if it runs every 15 mins or so | 19:34 |
| Wizzup | https://docs.kernel.org/admin-guide/mm/ksm.html#ksm-daemon-sysfs-interface | 19:35 |
| Wizzup | set to 0 to stop ksmd from running but keep merged pages, | 19:35 |
| Wizzup | would also allow for these tricks | 19:35 |
| Wizzup | btw, I think since we fixed the ants, some of the shortcuts on the home page sometimes lack an icon | 19:38 |
| Wizzup | could be completely unrelated, but when I touch them they get their icon back | 19:38 |
| Wizzup | freemangordon: should there be two create_advanced_settings_page calls in the rtcom accounts plugin | 19:46 |
| Wizzup | freemangordon: I am not seeing my advanced page params being saved somehow | 19:50 |
| Wizzup | should we perhaps call rtcom_account_item_save_settings or something | 19:50 |
| Wizzup | or does this work for the fb plugin for sure? | 19:51 |
| uvos | yes i know thats exactly the trick i used | 20:25 |
| uvos | i let it run for a while on boot and then shut it off | 20:25 |
| uvos | it uses a huge amount of cpu and power, we could not turn it on often | 20:25 |
| uvos | but i saves some ram for the allways resident applications | 20:25 |
| uvos | since we fixed the ants the gpu hangs way more often | 20:26 |
| uvos | at least here | 20:26 |
| Wizzup | hm, I only have that when I go to fullscreen in mpv or so | 20:26 |
| Wizzup | or leave fullscreen | 20:26 |
| uvos | it seams to happen randomly quite often here | 20:26 |
| Wizzup | when doing what? | 20:30 |
| uvos | seams random really, when opening the menu in xterm, when opening menus in firefox, when selecting an application in tasknav | 20:31 |
| uvos | anything that creates a surface seams to be liable to cause it | 20:31 |
| Wizzup | I never have firefox open | 20:31 |
| sicelo | i also see gpu hangs frequently... i think I've mentioned it a number of times | 20:40 |
| sicelo | no FF involved... i don't even have it installed | 20:40 |
| freemangordon | Wizzup: fb plugin works for sure | 21:26 |
| freemangordon | please just copy the code and tailor it to your needs | 21:26 |
| Wizzup | I copied it 1:1 | 21:27 |
| freemangordon | it woirks | 21:27 |
| freemangordon | *works | 21:27 |
| Wizzup | https://github.com/maemo-leste-extras/rtcom-accounts-plugin-slack | 21:27 |
| freemangordon | so, advanced page does not open? | 21:27 |
| Wizzup | it does | 21:27 |
| freemangordon | sec, I'll clone it | 21:27 |
| freemangordon | ah | 21:27 |
| freemangordon | but? | 21:27 |
| Wizzup | one sec I need to find the vim | 21:27 |
| Wizzup | basically none of the advanced settings are saved | 21:28 |
| freemangordon | how do you know that? | 21:28 |
| freemangordon | checked with mc-tool? | 21:28 |
| Wizzup | they don't end up in the .cfg file | 21:28 |
| Wizzup | https://github.com/maemo-leste-extras/rtcom-accounts-plugin-slack/blob/9a9c346e22792b8c94d4d87070968f5e5d18ea61/data/slack-advanced.glade#L95 | 21:28 |
| Wizzup | is this the field that is used to set the key? | 21:28 |
| freemangordon | yes | 21:29 |
| Wizzup | or is somehow the widget id key being parsed | 21:29 |
| Wizzup | ok | 21:29 |
| freemangordon | are you sure it is with underscore? | 21:29 |
| Wizzup | yes | 21:29 |
| freemangordon | sec, want to check something | 21:29 |
| freemangordon | Wizzup: /home/user/.local/share/telepathy/mission-control/accounts.cfg? | 21:30 |
| freemangordon | also, are there any errors if you run account-ui from console? | 21:31 |
| Wizzup | freemangordon: yes that file, and I can controlpanel | 21:31 |
| Wizzup | I can try this, in a bit, I'm going to get pulled into another work mtg | 21:32 |
| freemangordon | ok, I will try to debug in the meanwhile | 21:32 |
| freemangordon | how to register an account? | 21:32 |
| Wizzup | not possible | 21:33 |
| Wizzup | it's an organisational thing | 21:33 |
| freemangordon | heh | 21:33 |
| freemangordon | :) | 21:33 |
| Wizzup | we could request a free one for maemo | 21:33 |
| freemangordon | so, how to test? | 21:33 |
| Wizzup | but I don't think you need to register to try to save things | 21:33 |
| Wizzup | just fill in whatever | 21:33 |
| freemangordon | no, it will not save the account if you don;t login | 21:34 |
| freemangordon | IIRC | 21:34 |
| freemangordon | but ok, lemme try | 21:34 |
| Wizzup | when I typed garbage for the irc setup it worked | 21:34 |
| Wizzup | like the server was asdfasdf | 21:34 |
| freemangordon | ok | 21:34 |
| freemangordon | Wizzup: https://pastebin.com/3q3s9ghT | 21:37 |
| Wizzup | freemangordon: it is for sure | 21:42 |
| Wizzup | empathy sets the same keys, and if I set them in the cfg then it works too | 21:42 |
| freemangordon | I cannot add through empathy | 21:42 |
| Wizzup | what do you mean? | 21:43 |
| freemangordon | nothing happens when I press add button | 21:43 |
| Wizzup | freemangordon: how did you get these errors btw? G_DEBUG_MESSAGES=all accounts-ui ? | 21:50 |
| freemangordon | yes | 21:50 |
| Wizzup | freemangordon: it looks like they are with - in mc-tool | 21:52 |
| Wizzup | (bool) open-chat = true | 21:52 |
| Wizzup | (bool) open-history = true | 21:52 |
| Wizzup | so does haze just convert _ to - ? | 21:52 |
| freemangordon | seems like | 21:52 |
| freemangordon | Wizzup: why do you set https://github.com/maemo-leste-extras/rtcom-accounts-plugin-slack/blob/master/src/slack-plugin.c#L64 | 21:58 |
| freemangordon | also, if you cannot create new account, do not expose "new account" button | 21:58 |
| Wizzup | yes, this is not a pkg yet :) | 21:59 |
| freemangordon | ah, ok :) | 21:59 |
| Wizzup | g_object_set(G_OBJECT(service), | 22:01 |
| Wizzup | "display-name", "Facebook Messenger", | 22:01 |
| Wizzup | NULL); | 22:01 |
| Wizzup | you didthis | 22:01 |
| Wizzup | so what's wrong with "Slack" ? | 22:01 |
| freemangordon | Because it was "Facebook", which is misleading | 22:02 |
| freemangordon | but I suspect the default name for slack, that comes from the plugin is ok | 22:02 |
| freemangordon | that's why the reis no need to set it | 22:02 |
| freemangordon | I mean - if you don;t set it explicitly, it uses whatever is provided by the plugin | 22:03 |
| freemangordon | and usually it is fine | 22:03 |
| freemangordon | Up to you ofc | 22:04 |
| freemangordon | Wizzup: G_MESSAGES_DEBUG=all /usr/bin/rtcom-accounts-ui | 22:09 |
| Wizzup | ah ok ty | 22:23 |
| Wizzup | freemangordon: changing the _ to - makes it work | 23:01 |
| Wizzup | ty | 23:01 |
| Wizzup | freemangordon: btw you're saying that for facebook you're getting the messages you write elsewhere reported to tp? | 23:10 |
| Wizzup | say if you write it on some web client or so | 23:10 |
| Wizzup | freemangordon: also, for the slack purple plugin one can provide either a password or api-token, but I don't really know how to do this wrt rtcom ui | 23:27 |
| Wizzup | I suppose I could remove the password cap and then have password and api-token in teh advanced page | 23:27 |
| Wizzup | cool, have icons now too in slack :p | 23:55 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!