<freemangordon>
this renders launcher scrolling on n900 with > 40 fps, please test. If there are no regressions I'll push to -devel
System_Error has quit [Remote host closed the connection]
<freemangordon>
on d4 fps increases from ~55 to ~75
System_Error has joined #maemo-leste
<Wizzup>
morning
<Wizzup>
so the problem for rtcom-accounts-ui is that the account indeed starts with an '@', so the 'full' address of the account is '@username:hostname.tld'
<Wizzup>
we could concievably skip validating it like sander said, and just have user be username nad the server be hostname.tld, but I don't think this makes sense since for example for jabber we force the account to be the 'user@hosntame.tld'
<Wizzup>
freemangordon: so we have separate server and username fields already, btu the validation as far as I can see it, is done on the *account* property
<Wizzup>
freemangordon: re: hd above, this should have a better saturation shader, or?
arno11 has joined #maemo-leste
<Wizzup>
freemangordon: or do you just test launcher scrolling?
<freemangordon>
saturation shader is the same
<Wizzup>
oh
<freemangordon>
but it is not applied on every frame ;)
<Wizzup>
ok, so this might still have the delay when starting start menu, or?
<freemangordon>
yes
<Wizzup>
or was that delay also the reason
<Wizzup>
ok
<freemangordon>
but scrolling is ok
<freemangordon>
start menu?
<arno11>
freemangordon: launcher scrolling is ok now but the rest of the UI is still slow compared to no-blur
<freemangordon>
what is "rest of UI"?
<Wizzup>
start menu and hildon menu I think
<arno11>
hsm, the 'opened window' menu
<freemangordon>
start menu == entering launcher?
<freemangordon>
please...
<arno11>
in fact everywhere blur is visible
<freemangordon>
we have:
<freemangordon>
task navigator
<freemangordon>
launcher:
<freemangordon>
desktop edit
<Wizzup>
I meant to type status menu
<freemangordon>
and h-s-s menu
<Wizzup>
not start menu
<freemangordon>
*h-s-m
<freemangordon>
ok
<Wizzup>
but arno and I might be talking about different things too
<arno11>
so...task navigator is slow
<arno11>
and hsm and all sub menus
<freemangordon>
it is *slower*
<freemangordon>
no slow
<freemangordon>
for n900 25 fps is not *slow*
<arno11>
it is under 25 fps and laggy
<freemangordon>
right
<freemangordon>
but it is the same in fremantle
<Wizzup>
and then from my side: the main pain point is the responsiveness of the status menu ,when you touch it, it can take 3-4 seconds for it to appear
<arno11>
yes quite the same
<Wizzup>
same for the power menu
<Wizzup>
this went away with arno's transitions
<freemangordon>
it is not blur that makes it slow
<freemangordon>
because blur takes 250 ms (in theory)
<Wizzup>
indeed, but it's gone with the other transitions so it's not in h-s-m
<freemangordon>
sure, but we have to check which change makes it faster
<Wizzup>
yeah
<freemangordon>
but, first, lets confirm for few hours I did not regress something with those chages in h-d
<Wizzup>
I suspect because hsm is on top of something, maybe it takes time to snap it's current background and then blur it
<Wizzup>
but I might not understand how it works
<freemangordon>
will check
<freemangordon>
Wizzup: but, I need my n900 booting :p
<arno11>
freemangordon: imo hsm is quite ok compared to the task manager which is unresponsive (need to click 2-3 times to switch windows)
<arno11>
and zoom animation is laggy
<arno11>
huge diff with the launcher
<Wizzup>
freemangordon: right
<Wizzup>
arno11: I don't have this unresponsiveness nithe task manager I think
<Wizzup>
I think what happens if you might click on a window before the animation is done?
<arno11>
even if i wait, that's a lot slower than no-blur
<freemangordon>
arno11: I don;t see such issue with tasknav as well
<arno11>
ok let me have a look again
<freemangordon>
but, my n900 battery went flat
<freemangordon>
so cant test ATM
<freemangordon>
have to run, ttyl
<Wizzup>
freemangordon: ok, when you have some time, pls see my messages above re: matrix
pere has quit [Ping timeout: 255 seconds]
arno11 has quit [Quit: leaving]
arno11 has joined #maemo-leste
<arno11>
Wizzup: freemangordon: i took time to test and the changes are ok and improve things a bit compared to stock H-D and transitions. but still a way slower than no-blur (in term of speed and responsiveness)
<arno11>
on my device with no blur and no overclock, the ui feels as fast as my redmi proot
<dsc_>
< Wizzup> so the problem for rtcom-accounts-ui is that the account indeed starts with an '@', so the 'full' address of the account is '@username:hostname.tld'
<dsc_>
the Matri *username* starts with @, not the mission-control account
<dsc_>
afaik account can be anything
<dsc_>
its just a rtcom UI display string
Wikiwide has joined #maemo-leste
<Wizzup>
dsc_: yes, you said that yesterday and I touched on it above too
<Wizzup>
10:13 < Wizzup> we could concievably skip validating it like sander said, and just have user be username nad the server be hostname.tld, but I don't think this makes sense since for example for jabber we force the account to be the 'user@hosntame.tld'
<Wizzup>
also the way the rtcom account plugins work the account param has to make sense
<Wizzup>
only in mc-tool it doesn't
<Wizzup>
note to self: fix the power button being used to unlock to then show the power menu
<Wizzup>
very annoying, I really press 'power off' bi accident more than a few times a month because uf it
<dsc_>
Wizzup: for IRC it is idle/irc/accountname0
<dsc_>
from the top of my head
<dsc_>
and not idle/irc/accountname@server.tld0
<dsc_>
right?
Livio has joined #maemo-leste
Wikiwide has quit [Remote host closed the connection]
Wikiwide has joined #maemo-leste
<inky>
folks, pmos has no forum to post there, and chat is silent about it, so anyway, i would like to share with you these screenshots, because uvos told me to check powertop status. i also tried to compare to powertop on maemo but the versions are very different, and powertop on maemo doesn't show percentages.
<inky>
so apparently constantly runtime-1c28000.serial, runtime-musb-hdrc.2.auto, runtime-1c28c00.serial runtime-1c22e00.codec, Radio device : hci_uart_h5. processes take 100% of cpu time each. in pmos.
<sicelo>
for pmos, you can make an issue on gitlab and post there, or in their matrix room (they have dozens)
<freemangordon>
Wizzup: so, where is plugin code?
<inky>
oh! gitlab is an idea. matrix i don't use. maybe one day i could setup a xmpp gateway to it. but so far my experience with matrix was frustrating.
<freemangordon>
I think we can use current API with no changes, just by setting some properties
Wikiwide has quit [Remote host closed the connection]
<freemangordon>
but how's that possible given there is swap?
<arno11>
(the issue first appeared with 6.1.48 iirc btw)
<freemangordon>
this is 6.1.8
<Wizzup>
arno11: what is your swap size
<arno11>
2 x 1GB actually
<freemangordon>
it was booting happily with 768MiB on emmc
<Wizzup>
that is fine, but if it is related to oom then this is a good thing to look into @ happily
<Wizzup>
what if we install earlyoom or something?
<Wizzup>
(as test)
<Wizzup>
I am booting again
<freemangordon>
how is swap enabled?
<freemangordon>
fstab
<arno11>
(it was booting happily with emmc only for a short period btw)
<arno11>
yes fstab
<freemangordon>
with 6.1 I had no issues whatsoever
<freemangordon>
I'll revert swap to emmc to see if it fixes boot issue
<arno11>
i already tried
<arno11>
same story
<freemangordon>
and?
<freemangordon>
with 6.1?
<arno11>
yes
<freemangordon>
so we run OOM with swap?
<freemangordon>
that does not make sense
<arno11>
6.1 or 6.6, same boot issues
<arno11>
like i said, first troubles appeared with 6.1 and emmc 7 months ago
<freemangordon>
but, now it failed to boot with 6.1.8
<freemangordon>
do you say this is something userland?
<arno11>
yes
<freemangordon>
could it be VM settings related?
<arno11>
i already tried to remove them
<freemangordon>
ok, seems Wizzup has some ideas
<arno11>
ok
<Wizzup>
booted ok this time
<Wizzup>
when h-d started I used the slider to turn off the screen
<Wizzup>
not sure if it is related
<arno11>
hard to say, the issue is so random, difficult to say what helps or not, until 4-5 reboots
<freemangordon>
ok, does not boot with 6.1 and swap on emmc
<freemangordon>
lemme revert VM settings
<Wizzup>
right there is /etc/sysctl.d/n900-perf.conf.leste
<freemangordon>
mhm
<Wizzup>
well without .leste
<freemangordon>
umm....
<freemangordon>
could you have a look at /var/lib/n900-pm?
<Wizzup>
do you mena /etc/init.d/n900-pm?
<Wizzup>
I don't see /var/lib/n900-opm
<freemangordon>
sorry, /var/log
<Wizzup>
I don't have this file
<Wizzup>
btw, /etc/init.d/leste-config has code to change nr_requests for mmcblk0/1, wonder if this is related to emmc slowness
<freemangordon>
how's that?
<freemangordon>
oh, does it?
<Wizzup>
freemangordon: what writes this file for you in /var/log/
<freemangordon>
no idea
<freemangordon>
I guess it is /etc/init.d/n900-pm
<freemangordon>
oh, maybe this is sopmething I have to remove
<Wizzup>
I don't think we have a n900 pm package yet
<Wizzup>
since starting it causes lot sof problems
Wikiwide has quit [Remote host closed the connection]
<Wizzup>
so you file you probably made by yourself
<arno11>
i already tried to remove nr_request
Wikiwide has joined #maemo-leste
<arno11>
true for n900-pm
<arno11>
i meant the nr_request stuff from leste-config
<arno11>
in fact i tried to remove almost every custom n900 stuff, with no more succes on boot
<arno11>
the real question for me is why this issue happens randomly. why so much diff between boots
<freemangordon>
first boot after removing custom VM stuff here (and nr_requests) is ok
<arno11>
for me too (sometimes), but you must try to reboot 3-4 times to be sure
<freemangordon>
sure will do
<arno11>
ok
<freemangordon>
also, to improve responsiveness we shall put h-d (and systemui) in a special cgroup
<freemangordon>
that's what fremantle does
<arno11>
ah ok interesting
<arno11>
for nr request and vm, the issue appeared long time before btw
<arno11>
for cgroup: maybe that's why TS latency feels better
<freemangordon>
mhm
<arno11>
*on fremantle
<Wizzup>
I would like to use cgroups yes :)
<arno11>
bbl
<freemangordon>
second boot in a row, no issue whatsoever
<freemangordon>
lemm eupgrade the kernel
Wikiwide has quit [Remote host closed the connection]
Wikiwide has joined #maemo-leste
Wikiwide has quit [Remote host closed the connection]
<Wizzup>
it might be worth installing earlyoom, it's a daemon that will kill processes if you get near oom
<Wizzup>
(for debugging)
Wikiwide has joined #maemo-leste
<freemangordon>
Wizzup: I don;t think we have OOM
<freemangordon>
but lemme confirm it
<freemangordon>
upgrading to 6.6 now, lemme see if it will boot ok
<freemangordon>
with default VM settings/nr_requests
<arno11>
sometimes i get 6 freezes with default vm and nr request btw
<arno11>
*6-8 freezes
<freemangordon>
on boot?
<arno11>
but with 6.6
<arno11>
don't remember exactly with 6.1
<arno11>
bbl
Livio has joined #maemo-leste
<freemangordon>
66 boots fine too
<Wizzup>
maybe try a few more times for good measure
<Wizzup>
I will also try
<freemangordon>
will do
<Wizzup>
I will try too
<Wizzup>
btw, looks like maybe sapwood-server is not stopped properly and tries to restart while rebooting
<Wizzup>
same for him
<Wizzup>
but I did type 'reboot' in ssh, so..
<freemangordon>
might
<freemangordon>
be
<freemangordon>
that could be the reason for slow reboot/poweroff
Livio has quit [Ping timeout: 258 seconds]
<freemangordon>
second boot in a row with no issue, 6.6
<Wizzup>
trying to boot with sysctl and nr_requests disabled too
<arno11>
looking @irc logs, i asked to remove custom vm stuff few weeks ago, because it seems to help on boot, and enabling them from usersspace causes no issue and speed up things. but definitely not the root cause
<arno11>
i currently boot without them for a while but still get troubles
<freemangordon>
what troubles?
<arno11>
freezes
<freemangordon>
temporal?
<arno11>
nope
<freemangordon>
can;t repro here
<arno11>
same troubles as usual
<freemangordon>
did you remove nr_requests change?
<arno11>
yes
<arno11>
uh, actually not
<freemangordon>
I think it is nr_requests
<freemangordon>
that breaks it
<arno11>
iirc i got freeze without it but it was better
<arno11>
could explain at least emmc troubles
<Wizzup>
first boot was good for me too
<arno11>
let me try as well
arno11 has left #maemo-leste [#maemo-leste]
<freemangordon>
Wizzup: BTW, if we renice Xorg h-d and system-ui to some sane priorities, we get a very responsive system
<Wizzup>
did you try this with renice, or?
<freemangordon>
yes
<Wizzup>
ok
<freemangordon>
fremantle does something through ohm/cgroups/nice
<Wizzup>
we might need to enable some cgroup stuff in kernel if not already
<freemangordon>
at least Xorg is stared with dsmetool -n 8, but I am not sure what 'nice 8' means to dsme
<freemangordon>
we already have some cgroups support
<freemangordon>
but I have no idea how to use it
<Wizzup>
what do you mean 'we already have some cgroups support'
<freemangordon>
see /sys/fs/cgroup
<Wizzup>
ok, I see what you mean
<freemangordon>
elogind does things
<Wizzup>
ok, I think we should do this through openrc
<Wizzup>
but I will check kernel
<freemangordon>
ok
<freemangordon>
anyway, I think nr_requests shall be removed
<freemangordon>
lemme check VM stuff
<Wizzup>
agree @ nr_requests
<Wizzup>
I have two good boots as wlel so far
<Wizzup>
# CONFIG_BLK_CGROUP_IOLATENCY is not set
<Wizzup>
# CONFIG_BLK_CGROUP_IOCOST is not set
<Wizzup>
# CONFIG_BLK_CGROUP_IOPRIO is not set
<Wizzup>
# CONFIG_BFQ_CGROUP_DEBUG is not set
<Wizzup>
# CONFIG_CGROUP_PIDS is not set
<Wizzup>
# CONFIG_CGROUP_RDMA is not set
<Wizzup>
others are set
<freemangordon>
maybe we want CONFIG_BLK_CGROUP_IOPRIO
<Wizzup>
we have this:
<Wizzup>
CONFIG_CGROUP_FREEZER=y
<Wizzup>
CONFIG_CGROUP_DEVICE=y
<Wizzup>
CONFIG_CGROUP_PERF=y
<Wizzup>
CONFIG_CGROUP_CPUACCT=y
<freemangordon>
sounds like something useful :)
<Wizzup>
CONFIG_CGROUP_WRITEBACK=y
<Wizzup>
CONFIG_CGROUP_SCHED=y
<Wizzup>
so we can play with some other stuff first maybe
<freemangordon>
yeah
<freemangordon>
have to check what fremantle does
<Wizzup>
we should decide what goes in what I think
<freemangordon>
we may want to either take ohmd or see if we can achieve the same in elogind
<freemangordon>
well, we already have fremantle settings
<Wizzup>
what are they?
<Wizzup>
I also think nr requests should go
<Wizzup>
will reboot again but two successes in a row so far
<Wizzup>
and previously it failed 4 times in a row
<Wizzup>
I also removed sysfs
<freemangordon>
see /usr/share/policy/etc/rx51
<freemangordon>
syspart.conf
<freemangordon>
I don;t know if elogind implements systemd cgroups support
<Wizzup>
on fremantle?
<freemangordon>
no, in devuan
<freemangordon>
in fremantle it is ohmd plugin that does the job
<Wizzup>
I meant /usr/share/policy/etc/rx51
<freemangordon>
yes
<freemangordon>
syspart.conf
<Wizzup>
on fremantle
<freemangordon>
yes
<Wizzup>
ok
<freemangordon>
/usr/share/policy/etc/rx51/syspart.conf on fremantle
<freemangordon>
so, if elogind is not able to distribute processes to various cgroups based on some rules, we shoudl either take ohmd or bite the bullet and go to systemd
<freemangordon>
unless I am missing something
<Wizzup>
ok, my fremantle has been off for weeks
<Wizzup>
let me try
<Wizzup>
freemangordon: why?
<Wizzup>
why not use openrc?
<Wizzup>
we have it right now
<freemangordon>
how would it distribute user started processes?
<Wizzup>
it looks like cgroups more recently has been taken over by systemd
<freemangordon>
yes, and IIUC all that code is disabled in elogind
<Wizzup>
gotta love these people
<freemangordon>
arno11: why is page-cluster 8?
<freemangordon>
this is 128KiB IIUC
<Wizzup>
freemangordon: in any case /sys/fs/cgroup is well populated with both openrc and elogind, so I think we can at least test this relatively easily
<freemangordon>
Wizzup: it is populated, bu we have no idea how
<Wizzup>
what do you mean?
<Wizzup>
most of this is set up by kernel initially
<freemangordon>
how do you assign process to cgroup?
<arno11>
freemangordon: see issue 737, cssu/tmo stuff
<Wizzup>
the only thing I see is elogind directory with my ssh login cgroup
<freemangordon>
so, who says that h-d shall have higher CPU shares that let's say a browser?
<Wizzup>
A process can be migrated into a cgroup by writing its PID to the target cgroup’s “cgroup.procs” file. Only one process can be migrated on a single write(2) call. If a process is composed of multiple threads, writing the PID of any thread migrates all threads of the process.
<freemangordon>
Wizzup: that's clear
<Wizzup>
seems to me like dsme and openrc should just put the processes in their right cgroup
<Wizzup>
and that's it
<freemangordon>
the question is - who moves processes between cgroups and based on what criteria?
<Wizzup>
nobody moves things, you just assign them at start
<freemangordon>
based on?
<Wizzup>
on what starts it?
<Wizzup>
and what is started?
<freemangordon>
no, that won;t fly
<Wizzup>
in any case I suggest we defer this until later - connui-cell, rtcom accounts, etc
<freemangordon>
how do you assigh mediaplayer higher prio that ssh?
<Wizzup>
that's something that is true for any cgroup software, systemd or not
<freemangordon>
arno11: so, because I was there, I cna assure you that the *only* thing that maskes sense to change is swappiness
<Wizzup>
it could perhaps be based on .desktop or something, but we weren't talking about OMP
<freemangordon>
Wizzup: with systemd you can assign rules baesd on which to move process to a cgroup
<freemangordon>
when you want to connect to a room
<Wizzup>
but it's probably just with a different handle type
<dsc_>
is wrong
<dsc_>
because it only does `ensureTextChat`
<dsc_>
?
<dsc_>
it needs to take into account the type
<freemangordon>
wait
<freemangordon>
I think the logic is wrong there
<freemangordon>
you should not be allowed to write to a chat if you don;t have channel
<dsc_>
exactly
<freemangordon>
and you don;t do 'ensureChannel" only when you want to send a message
<freemangordon>
you should do ensureChannel(room) when a chat window is created
<freemangordon>
agree?
<dsc_>
im thinking
<Wizzup>
lol
<dsc_>
so you're only in a channel when you are in the chat window
<Wizzup>
I don't agree at all
<freemangordon>
or vice versa
<dsc_>
i.e: you join a channel on IRC only when you open the chat window
<dsc_>
seems weird
<Wizzup>
this is just a convenience function to write a message, regardless of whether the Tp::TextChannel exists or not
<Wizzup>
if it doesn't exist ,it makes it for you
<Wizzup>
whether it's correct for multi user rooms I don't know
<Wizzup>
but the logic is sane
<freemangordon>
then you shoudl pass channel type somehow
<dsc_>
i agree Wizzup but im wondering what fmg thinks
<freemangordon>
no, wait
<freemangordon>
the end result of that now is that messages get lost
<dsc_>
that also yes
<dsc_>
:P
<freemangordon>
because you write them, press enter and conversations tries to send them
<Wizzup>
the matrix specific hack? yes
<freemangordon>
no, in general
<Wizzup>
why?
<freemangordon>
but when it cannot send them, for whatever reason, the message gets lost
<Wizzup>
there's a closure there
<Wizzup>
sure we need to handle not being able to send messages in general
<Wizzup>
but the problem is not there
<freemangordon>
that's part of the problem
<freemangordon>
if you cannot connect to a channel, why should ypou be allowed to write a message?
<Wizzup>
???
<freemangordon>
try it in fremanlte
<Wizzup>
it will allow me to send a sms to anything or anyone
<freemangordon>
to write a message to contact that's not online
<Wizzup>
regardless of whether it will work or not
<freemangordon>
sms is anotehr story, as sms has no concept of presence
<Wizzup>
again, very basic, just handle the failure of channel creation
<dsc_>
hmm
<Wizzup>
there's nothing wrong with the logic there: it will create a channel when you try to write something
<freemangordon>
and your message is gone :)
<Wizzup>
nope
<Wizzup>
It's not going to make 100000000 channels for all potential users
<freemangordon>
umm.... do you have that number of chat windows opened?
<Wizzup>
you just want the text box disabled in certain cases
<Wizzup>
that's all fine, but it's so unrelated to what we're discussing i'm a little tired
<Wizzup>
disregard the idea that ever, ever, ever, it is a good idea to map open window to a channel
<Wizzup>
just forget about it now, it's a stupid idea and it doesn't work
<freemangordon>
how it is not related? ensureChannel(room) user has to know the channel type that has to be created
<Wizzup>
we can check for an open window whether it makes sense to allow to send a message
<Wizzup>
that's about it
<Wizzup>
this check is there because if you offline/online you lose all the channels
<freemangordon>
where that message comes from?
<freemangordon>
anyway, lets go back to ensureChannel
<dsc_>
i got my answer
<freemangordon>
it is manager's job to provide the correct handle type
<dsc_>
i was just wondering if `ensureTextChat` covered both handle types
<dsc_>
which it doesnt
<dsc_>
but
<freemangordon>
right, but that's true regardless of matrix or not
<dsc_>
we've had this for a long time, at which point I concluded that some managers are just accepting those wrong handle types regardless
<freemangordon>
I don;t see how would that be correct
<Wizzup>
yes they are, and for room we already have open channels anyway since we re-open them immediately upon online
<dsc_>
or ehm, not the wrong handle type, but e.g `ensureTextChat` for something that is a group
<Wizzup>
so this branch is never hit for channels
<Wizzup>
it already exists, so there's np
<dsc_>
Wizzup: aaah yes that makes sense
<freemangordon>
ok, but if you want to join a room, then there will be
<freemangordon>
no?
<Wizzup>
then you must use the "join channel" widget
<freemangordon>
yes
<Wizzup>
and until then you won't get a window
<freemangordon>
have to go for a while, ttyl
<Wizzup>
I'm not arguing the code is perfect, I'm arguing that really this doesn't pertain to what we were trying to solve - the validation of the matrix account is rtcom accounts ui ;)
<dsc_>
discussing about this, like this, is hard with telepathy being telepathy.
<dsc_>
thats why I would prefer a github issue
<dsc_>
fmg can just throw in some cheap statements like "just make it properly" but its not so simple some times, and IRC is not a medium where I have time to explain it in full
<dsc_>
because chat goes at 200kmph :P
<dsc_>
bbl
<sicelo>
you can use GH issue of course :-)
<dsc_>
i will, if someone posts an issue
Livio has quit [Ping timeout: 265 seconds]
Livio has joined #maemo-leste
<freemangordon>
dsc_: my statements may look cheap, but my experience tells me that adding protocol-specific workarounds usually just covers more serious issues, which will bite us, inevitably. But, lets see what I can do with rtcom account ui issue as it is way easier to solve
<freemangordon>
Wizzup: so, you want that @ before username?
<freemangordon>
I mean, can we just as the user to not write it?
<freemangordon>
*ask
<Wizzup>
freemangordon: well it seems to be the proper way to write the matrix address
<freemangordon>
also, I registered matrix account, what packages do I need install to be able to test account ui?
<Wizzup>
I can't say I like it but it is what they decided
<freemangordon>
telepathy-tank?
<Wizzup>
I think you just install the repo I linked
<Wizzup>
it will pull in telepathy-tank
<freemangordon>
ah, ok
<Wizzup>
What is a MXID?
<Wizzup>
Matrix user IDs (MXID) are unique user IDs. They are in the format @username:homeserver.tld (this format is used to avoid confusing them with email addresses.) They are intended to be fairly hidden (although right now they are not) - instead you will find and identify other users via 3PIDs.
<freemangordon>
wait, we have chatbot in the channel?!?
<Wizzup>
actually it does also have server, interesting
<Wizzup>
[Protocol jabber]
<Wizzup>
param-account=s required register
<Wizzup>
param-password=s register secret
<Wizzup>
param-server=s
<Wizzup>
(gabble)
<freemangordon>
ok, lemme build it and see
<Wizzup>
so you make an account using mc-tool initially (I didn't test creating accounts yet, just editing)
<freemangordon>
Makefile.am: error: required file './AUTHORS' not found
<Wizzup>
if you try to make it through the UI it will force you throug the 'sign up' button which I don't think works yet)
<Wizzup>
ah yes touch it
<Wizzup>
apologies
<Wizzup>
(touch AUTHORS)
<freemangordon>
yeah
<Wizzup>
back in 5-10 minutes
<freemangordon>
Wizzup: what is 'device' field?
<Wizzup>
the protocol supports multiple devices at the same time
<Wizzup>
so just a name for the device, but I suppose it also plays some role in e2ee
<Wizzup>
we can make it Maemo for now and allow editing through advanced
Livio has quit [Ping timeout: 252 seconds]
<freemangordon>
Wizzup: ok, so I am going to implement +
<freemangordon>
...
<freemangordon>
@ character property
<Wizzup>
ok, what is the property set on
<freemangordon>
Wizzup: do you know, what is the name of '@' in email address?
<Wizzup>
edit/login widget?
<Wizzup>
it is called 'at'
<freemangordon>
yeah, I know it is at
<freemangordon>
but, ....
<freemangordon>
what type of separator it is
<freemangordon>
like, something short for "@ is a separator between username and domain'
<freemangordon>
like 'at_char' or 'account_separator' or...
<freemangordon>
dunno how to name the property
<freemangordon>
PROP_AT_CHAR seems stupid to me
<Wizzup>
separator char
<Wizzup>
user/server separator
<freemangordon>
user-domain-separator?
<freemangordon>
is that ok?
<Wizzup>
sure
<freemangordon>
ok, thanks
<dsc_>
freemangordon: to answer a earlier thing; waiting on the alias event in createChannelCB
<dsc_>
please consider:
<dsc_>
1) this is after potentially doing join/create, both also http calls, which take time so waiting on the alias event will take in total how long in the blocked loop..
<freemangordon>
right, but this is not really "blocked", events are being processed
<freemangordon>
also, you can do it by using lambda in the same function
<freemangordon>
in createChannelCB that is
<dsc_>
2) a nested event loop, will still work "as a normal Qt eventloop", this means that after join/create, there is a Quotient::Room *room object, which has signals/slots attached that fire *inside the nested eventloop*, which in turn actually *call* createChannelCB
<freemangordon>
so no need of some fancy signal/slots
<dsc_>
at which point you have some recursion thing
<dsc_>
or at least some spaghetti to sort out
<dsc_>
both are not "impossible" problems
<freemangordon>
I understand, but how do you attach to an object you still don't have access to?
<dsc_>
but they show that I cannot quickly answer you
<dsc_>
i may have forgotten all the details
<dsc_>
or I just cannot context switch so fast
<dsc_>
github issues exist for a reason
<dsc_>
anyway, issue #2 was particularly annoying
<dsc_>
< freemangordon> right, but this is not really "blocked", events are being processed <== right
<freemangordon>
how is that different if the initisl call blocks?
<freemangordon>
*initial
<freemangordon>
it is still the same
<dsc_>
i dont follow sorry
<dsc_>
issue please
<freemangordon>
so, you have an initial call to libwhatever that establishes a channel with matrix
<freemangordon>
then you have another http call that does some other magic (like getting alias)
<freemangordon>
correct?
<dsc_>
you're asking about "what happens inside a nested Qt loop when the manager is trying to do bookkeeping between maybe-fully-synchronized Quotient::Room objects and the manager state"
<freemangordon>
no
<freemangordon>
see ^^^
<dsc_>
right, the alias comes in automatically
<dsc_>
but nevertheless its an async 'event'
<dsc_>
under-the-hood it does some HTTP calls, but thats up to the lib
<dsc_>
initially you just have the room->id()
<freemangordon>
where that comes from?
<freemangordon>
client side?
<dsc_>
from the Matrix server API
<dsc_>
so you call create
<dsc_>
or join
<freemangordon>
ok, so you have at least one http call :)
<dsc_>
sure, multiple probably
<freemangordon>
exactly
<dsc_>
god knows what libquotient does
<dsc_>
it logs in
<freemangordon>
exactly
<dsc_>
actually those are so-called 'sync' calls
<dsc_>
they fetch state, like what rooms you are in
<freemangordon>
and it is even worse than doing local loop, as most-probably the lib just blocks
<freemangordon>
mhm
<dsc_>
no
<dsc_>
the lib is Qt
<freemangordon>
how do you know?
<dsc_>
i looked at the code ^^
<freemangordon>
regardless
<dsc_>
it returns a JoinRoomJob *job
<freemangordon>
with id?
<dsc_>
Quotient::JoinRoomJob*
<dsc_>
no
<freemangordon>
yes, buit it has id that is retreived from the servers
<freemangordon>
no?
<dsc_>
the resulting of the job will have an id
<dsc_>
yeah
<dsc_>
room->id()
<dsc_>
it returns Quotient::Room*
<freemangordon>
so, before you get Quotient::Room*, there has been at least one http call
<freemangordon>
correct?
<dsc_>
what flow are we discussing right now?
<dsc_>
there is join, or join+create, or just "nothing"
<freemangordon>
auto *job = m_connection->createRoom(visibility, alias, alias.replace("#", ""), topic, invites);
<freemangordon>
so, when createRoom() call returns, do you have id or not?
<dsc_>
let me check
<dsc_>
well yes if it returns ofc
<dsc_>
room_id = joinJob->roomId();
<freemangordon>
so, it got that id from the servers, so there is at least one http call
<freemangordon>
which blocked
<dsc_>
yes
<dsc_>
no
<dsc_>
well yes, because we actively spawn an eventloop
<dsc_>
but generally it doesnt block
<freemangordon>
how's that? it was wunning local loop?
<freemangordon>
so it has issued the calls but not waiting for reply
<freemangordon>
so, if we want the result, we must wait
<freemangordon>
anyway, lemme finish what I am doing
<dsc_>
what do you mean
<freemangordon>
(rtcom accounts ui)
<dsc_>
"we must wait"
<dsc_>
we are waiting, no?
<freemangordon>
QEventLoop().exec()
<freemangordon>
yes
<freemangordon>
we are
<dsc_>
ok, just checking
<dsc_>
<freemangordon> dsc_: my statements may look cheap <== to be clear, you asked me "why didnt you look for help" which I find cheap yes, I wrote a long markdown document before starting this Matrix work
<dsc_>
and then you say "why dont you just do it properly"
<Wizzup>
guys, the current thing works well :)
<dsc_>
can we *please* focus on the technical stuff
<dsc_>
yes
<dsc_>
i cant deal with that, sorry
<dsc_>
ill go play some videogames :P
<dsc_>
bbl
Blasius_ has joined #maemo-leste
leste has quit [Ping timeout: 252 seconds]
lel has quit [Ping timeout: 252 seconds]
lel has joined #maemo-leste
n900 has quit [Ping timeout: 252 seconds]
joerg has quit [Ping timeout: 248 seconds]
Blasius has quit [Ping timeout: 248 seconds]
LeePen has quit [Ping timeout: 248 seconds]
jrayhawk has quit [Ping timeout: 248 seconds]
aat596_ has joined #maemo-leste
aat596 has quit [Ping timeout: 252 seconds]
Blikje has quit [Ping timeout: 272 seconds]
aat596_ is now known as aat596
joerg has joined #maemo-leste
n900 has joined #maemo-leste
Blikje has joined #maemo-leste
jrayhawk has joined #maemo-leste
<Wizzup>
lel: test
<freemangordon>
Wizzup: " create_account_cb: account could not be created: missing required parameter 'user'"
<freemangordon>
now, we set 'account' property, that is in the shape of "@userrname:server.com"
<freemangordon>
what else does it want?
<freemangordon>
IIUC it should require either account or username/server, but not both
<Wizzup>
freemangordon: tank.manager says user as required too