<dsc_>
Wizzup: we'll have to look at rtcom/telepathy stuff soon
<Wizzup>
yep
inky_ has quit [Ping timeout: 250 seconds]
<bencoh>
this all looks very cool and promising :)
<uvos>
allso needs discussion about other things
<Wizzup>
hm?
<uvos>
like notification esp the light, how mces state is to be managed wrt rinnger, display behvior etc.
<uvos>
like i know your going to say telepathy handles everything, but thats a _terrible_ solution
<uvos>
take for instance the light
<uvos>
some app enables the notification pattern
<uvos>
some other app also wants to notify and and toggels it on
<uvos>
mce just ignores that
<uvos>
now who is repsonable for turning off the light?
<uvos>
right
<Wizzup>
I'll look in ida and see what fremantle does
<uvos>
so on sane operating systems the gobal notification que takes care of this
<uvos>
every notification being taged with "wants a pattern"
<uvos>
and the light stays on as long as at least one notification is in the que
<uvos>
Wizzup: ok
<Wizzup>
it'll probably be similar to what modest does too
<Wizzup>
since that cooperates already in fremantle afaik
<uvos>
well...
<uvos>
Wizzup: but looking at how maemo lacks stuch a que, and also looking at how suspiciously modest is the only thing not telephathy and gets its own special pattern, it seams the solution they have
<uvos>
is just telepathy handels everything
<uvos>
and other applications are impossible
<Wizzup>
oh, chat/im pattern being different from email? maybe yeah
<uvos>
is what i suspect
<uvos>
yeh
<uvos>
its just broken i think
<uvos>
architecturally
<Wizzup>
in any case I think we can just postpone this for a bit since we need to get the backend working before we worry about this detail
<uvos>
(the way notifications work in general)
<bencoh>
uvos: I have notifications and custom led status working for pidgin on fremantle
<uvos>
bencoh: ok well wheres the code to hildonized pidign then?
<uvos>
your not just adding another pattern are you?
<uvos>
like modest dose
inky_ has joined #maemo-leste
<d4irc>
think ill make an irssi theme next
_inky has joined #maemo-leste
<uvos>
not to be a drag here but is theaming really important?
<d4irc>
not really :P
<Wizzup>
as long as he has fun doing it I think it's great
<asriel>
just found a cheap n900 on the internet, going to buy it tomorrow and get maemo leste on it :D
<uvos>
asriel: great :)
<asriel>
those things are somehow expensive now
<uvos>
yeah a d4 is cheaper and mutch better ususally
<uvos>
or a pp even
<uvos>
unless you get a very good deal
<asriel>
pp is nice, i've seen that keyboard :P
<asriel>
still yet to hold it
<asriel>
the d4 is nice, but it's verizon exclusive so can't even find a listing here :\
<uvos>
you can often buy it on us ebay and have it shiped
<uvos>
at least in germany this comes out cheeper than a local n900
<Wizzup>
right yeah all the ones I get I either carried with me or shipped
<Wizzup>
s/get/got/
<Wizzup>
uvos but yes in general there is a lot to figure out tp wise as well
<Wizzup>
notifications is just scratching the surface I think
<uvos>
yeah
<uvos>
but my immidate concern is shareing state with sphone ofc
<Wizzup>
there's sending messages, making sure the ui knows when to show new messages, account management, etc
<uvos>
this mostly touches nottifications
<Wizzup>
right, but conversations sending I don't think will go through the sphone sms layer, but rather the standard tp layer since then it's the same code for all protocols
<Danct12>
asriel: i can give you my n900 but i'm using it as a email client :P
<Wizzup>
otherwise there needs to be special sphone case and then other protocols
<Danct12>
also the keyboard membrane is a bit messed up too :)
<Wizzup>
I'm going to make sure I don't miss my bus, bbl
<Danct12>
also i have the pinephone keyboard
<Danct12>
does any of the ml devs have the pinephone pro/keyboard offer?
<uvos>
no
<uvos>
i think parazyd was thinking about buying
<dsc_>
i want a pinephone pro :(
<asriel>
sadly we'll have to wait for a few months for the explorer edition :(
<Danct12>
who doesn't? i personally like it because it's my pinebook pro inside a phone, and i use it as my on the go laptop so i know how powerful the thing is
<Danct12>
a weird thing pine64 does but at least it's done
<Danct12>
asriel, if you're gonna buy it.. watch out for the keyboard and the magnet :P
<Danct12>
i recommend bringing a fridge magnet with you, as well as a fat32 formatted sd card, that should help to determine if there is a magnet on the back case
<Danct12>
the keyboard one is unfortunately hard to watch out, but maybe try to touch buttons or something and see if it wobbles a lot
<asriel>
Danct12: i'll let you know when i buy it, thanks for the tips!
<bencoh>
uvos: the pidgin notify plugin send an IM notification
<bencoh>
or at least I had it set that way
<bencoh>
(I don't remember if it was by default)
<bencoh>
uvos: pidgin itself comes from the maemo (extras iirc) repository
<bencoh>
uvos: as for the pidgin-notify, I patched it, lemme check
<Wizzup>
Danct12: we didn't ask I think
inky has joined #maemo-leste
inky_ has quit [Ping timeout: 256 seconds]
_inky has quit [Ping timeout: 268 seconds]
<bencoh>
uvos: looks like I used notify_send_dbus_mce_message(MCE_ACTIVATE_VIBRATOR_PATTERN,"PatternChatAndEmail");
<bencoh>
and notify_send_dbus_mce_message(MCE_ACTIVATE_LED_PATTERN,"PatternCommunicationIM");
<bencoh>
I wonder where I got that from though
<uvos>
bencoh: right
<uvos>
bencoh: but doing so is broken
<bencoh>
probably, but why?
<bencoh>
I mean, I guess there is a reason why I didn't commit that yet :D
<Wizzup>
so they override is the problem
<bencoh>
s/yet/back then/
<uvos>
becasue this activates a pattern in mce, until you call DeactivatePattern on the same pattern
<Wizzup>
in general 5 diff apps cannot all have their own pattern state if they share a pattern
<uvos>
but there is nothing telling oyu you own this pattern
<Wizzup>
is uvos' point
<bencoh>
hmm
<uvos>
so if some other app activated the pattern too
<uvos>
and then deactivates it
<uvos>
the pattern wont show while the message is still unread
<bencoh>
ah
<Wizzup>
that said I do not have a good sense od how this works exactly in fremantle
<bencoh>
I see
<uvos>
i gues mce could do what is esseantly refererance counting
<bencoh>
I'm not certain the pattern is supposed to still show once there was any user activity actually
<uvos>
and only deactivate the pattern when its been deactivated as often as it has been activated
<uvos>
but thats not how it works atm or histroricly
<bencoh>
I mean, I think the devs had in mind that user would take his phone, check notifications, and ... basically that's it
<uvos>
bencoh: a app disables the pattern for any number of reason
<uvos>
s
<uvos>
you could have looked at the message on a different device for instane
<bencoh>
so basically once you open the window mosaic (forgot how that thing is called ... launcher?), it goes off
<bencoh>
(I think)
<uvos>
the notfications are hidden as soon as you enable the display anyhow
<uvos>
but thats not the point
<bencoh>
uvos: in theory yeah
<bencoh>
ah, so that happens once you enable display? :)
<uvos>
no
<uvos>
mce just stops showing it then
<bencoh>
yeah
<uvos>
its still activated
<bencoh>
*nods*
<uvos>
the only real way to solve it in all cases is to have a gobal notification que
<bencoh>
I just mean that it being activated or not doesn't really bear any sense hildon-wise
<bencoh>
but now I see what you meant by "it's broken"
<bencoh>
it basically forbids any external (remote) action
<bencoh>
(like a message being read from another device)
_inky has joined #maemo-leste
<uvos>
i also think its broken that the device cant continue to notfy untill all notifications are cleared
<bencoh>
dunno
<bencoh>
the notifications stay there
<bencoh>
but the light goes off
<uvos>
right i mean the light
<uvos>
not the windows
<bencoh>
I think that part is fine, kinda
<bencoh>
the point is to get the user to "check his phone"
<Wizzup>
it depends on what you expect yeah
<bencoh>
up to him to read everything (or not)
<uvos>
even then its incosistant
<Wizzup>
you do not want blinkie blinkie after turning/unlocking once
<bencoh>
I wouldn't want it at least
<uvos>
even if you do expect that (i dont) becasue there are several notification classes its broken
<uvos>
because you have to check on im message
<uvos>
but also one email
<uvos>
etc
<bencoh>
I mean, maybe I left that notification there on purpose, because I wanna get back to it
<uvos>
for the light to turn off
<uvos>
because some stuff is a different pattern (farily randomly really)
<bencoh>
but I still want to notice that I received *another* notification
<bencoh>
here I have a different light pattern for IM/phone/sms
<bencoh>
(purple / blue / cyan)
<bencoh>
(more pink than purple)
<bencoh>
in that regard it's pretty effective
<uvos>
there is also email
<bencoh>
email == chat I think
<uvos>
and "PatternCommonNotification"
<bencoh>
but I might be wrong
<uvos>
that looks teh same as PatternCommunicationIM
<bencoh>
(maybe that's only for vibrations)
<bencoh>
ah
<uvos>
ot the behavior is very inconsistant
<uvos>
depending on what the app decides to use
<uvos>
no PatternCommunicationIM and PatternCommunicationEmail are seperate
<bencoh>
anyway, hildon offers a way to configure every of those patterns, and applications are supposed to choose a class that matches them the most
<bencoh>
it might be the same for leds, yeah
<uvos>
so worst case you have to clear one of eatch PatternCommunicationIM PatternCommunicationSMS PatternCommunicationEmail PatternCommonNotification
<uvos>
before the light turns off
<bencoh>
err different* I meant
<uvos>
if you have one sms one email and one im message and one something
<bencoh>
uvos: I'm pretty certain we wouldn't want that as a user
<uvos>
you have to clear all of those
<bencoh>
honestly I want my phone to just go back to no-led-state until the next event happens
<uvos>
if you have one telegram message one irc message one whatsapp message and one skype message
<uvos>
you have to clear one one
<uvos>
this is terrible imo
* bencoh
headscratches
<uvos>
*only one
<bencoh>
uvos: leds are just a mean of saying to the user "something happened, check it up"
<uvos>
bencoh: sure if you want to use it like that thats fine
<bencoh>
with the exception that we have some order of precedence
<uvos>
what im saying it works like this in the current system _sometimes_ depending on the type of message you got
<bencoh>
ie phone > sms > im
<uvos>
even ignoreing sms and phone there are still 3 seperate patterns to contend with
<bencoh>
so receiving an event with a higher priority will override the pattern
<uvos>
no it wont
<bencoh>
it does
<bencoh>
I mean, I use it as a daily phone
<uvos>
it will _hide_ the lower priorty pattern
<bencoh>
yeah
<uvos>
not remove it
<bencoh>
sorry
<uvos>
so you have to clear every pattern
<bencoh>
it disappears once I open my phone
<bencoh>
so the user doesn't really care
<bencoh>
again, the desactive thing isn't really visible to the user because there is no other application to it
<bencoh>
deactivate*
<bencoh>
(admittedly this is bad for multi-device apps)
<uvos>
either your missundersanding me
<uvos>
or leste is missing a piece
<uvos>
ok lets say you get an sms and an email and an im message.
<uvos>
then the pattern sms will show
<bencoh>
omdeed
<bencoh>
indeed*
<uvos>
you turn on the device
<uvos>
all patterns are hidden
* bencoh
nods
<uvos>
then you click the sms notification
<uvos>
sms pattern is deactivated
<uvos>
you lock the device
<uvos>
now the im will show
<bencoh>
I dont think it does
<Wizzup>
I don't think it does on fremantle
<bencoh>
I'm pretty sure it doesn't
<uvos>
ok
<Wizzup>
but it might be the case on leste
<uvos>
then something is missing
<Wizzup>
or something sphone does or does not do :p
<bencoh>
yeah
<Wizzup>
conversations on leste is a _big_ program
<uvos>
sphone isent involved :P
<uvos>
it dosent even do the light yet
<bencoh>
I might be wrong, but I don't think so, because I often leave notifications open
<Wizzup>
ah ok then, where do you see this problem then?
<Wizzup>
bencoh: yeah no, I know this is how it works
<bencoh>
like, not long ago I didn't open the Phone notification, it still showed in that lockscreen under the slider
<bencoh>
but I got no light
<uvos>
yeah with modest + updates
<uvos>
@wizzup
Twig has joined #maemo-leste
<Wizzup>
ok, so it might be a modest porting problem causing it not to behave like fremantle
<Wizzup>
that said I don't use modest on fremantle (anymore)
<uvos>
or something is supposed to clear all notifications
<uvos>
when something happens
<uvos>
would make more sense
<uvos>
because otherwise modest would have to clear all patterns
<uvos>
that sounds very broken
<bencoh>
either that, or one of the closed apps on fremantle deactivate led patterns altogether
<bencoh>
(closed and/or not ported)
<uvos>
yeah no way modest calling deactivate on all possible patterns is the plan here :P
<bencoh>
nah :)
<Wizzup>
there is rtcom notifications ui that we lack entirely
<bencoh>
it should be one of the UI daemons anyway, if at all (like mce)
<bencoh>
(not necessarily UI, but you got my point)
<bencoh>
(I really wonder what does it on fremantle though, assuming we understand it properly)
<uvos>
dbus-montior -s
<uvos>
:P
<Wizzup>
we can find out using dbus -- yeah uvos beat me ot it
<Wizzup>
unless mce does it internally in some tklock stuff
<uvos>
no
<uvos>
i changed mces internal api
<uvos>
so i was forced to look at everything that touches it
<uvos>
we could have mce do this ofc
<uvos>
but i dont think is a great solution
<uvos>
(clearing the notification on a different device or the remote party deleating the message that caused the notfication is sill broken_
<uvos>
)
<uvos>
if we do
<Wizzup>
I agree that some other place for notifications is useful, but I also think (like I said before) I'd rather tackle it when we're ready for it
<uvos>
idk i kinda think implementing something new is easier than implementing the same misake and then implementing something new anyways
<uvos>
but sure...
<Wizzup>
I agree yes, but I'm not at that point yet I mean
<Wizzup>
we might run into more info a month from now
<uvos>
ok
<uvos>
i might end up just doing it anyways for telegram-desktop and sphones benefit
<Wizzup>
also with many different chat programs I'd probably want to silence some altogether
<uvos>
(ie implement a notification deamon/window that implements the xdg apis)
<Wizzup>
who knows, I might get you on the telepathy (or libpurple) train eventually :P
<bencoh>
if anything we could even move to growl (or any other notification system)
<uvos>
heh
<uvos>
im not opossed to to telepathy at all
<bencoh>
but I doubt we'll go that way
<uvos>
just to depending to hard on _anything_
<uvos>
you could say i have fear of abandoment :P
<bencoh>
I'd love to see everything integrated with telepathy, but I still have doubts regarding how it would handle medias (ie, anything beyond text and audio/video calls)
<uvos>
bencoh: this? Growl is a deprecated[1] global notification system and pop-up notification implementation for the Mac OS X and Windows[2] operating systems.
<bencoh>
uvos: oh, I thought it had been ported to linux, my bad
<bencoh>
yeah, usually nokia was among the ones writing it
<bencoh>
or trying to push it forward
<bencoh>
(unfortunately they stopped in the middle, but that's another story)
<uvos>
either way supporting now non standard maemo stuff and standart xdg suff at the same time is hard/impossible when they both expect the same dbus call to do different things
<Wizzup>
yes, we can work on fixing that of course
<Wizzup>
wrt notify
inky has quit [Ping timeout: 250 seconds]
inky has joined #maemo-leste
vectis has quit [Ping timeout: 265 seconds]
vectis has joined #maemo-leste
<sicelo>
bencoh: that twmn really looks nice! wonder how/if it would work on wayland
<sicelo>
dsc_: looks really great - i only miss the timestamp, i.e. i'd rather have time instead of date, if i couldn't have both
<dsc_>
sicelo: thanks, I accidentally typed `datestr` instead of `hourstr`, as such there is a date there that should be `hh:mm` instead :P
<dsc_>
ill change it
<dsc_>
I also need to make it so that it *does* show the date on day changes (just how whatsapp does it)
<dsc_>
(nobody is telling me what to make in terms of UI, if anyone has an idea/example I'd be happy to re-create it)
<uvos>
i think the ui is fine
<sicelo>
i think you've done a great job with being 'true' to hildon styling that we're used to.
xes has quit [Quit: WeeChat 3.0.1]
<uvos>
both what you showed origionally and the whatsapp clone
<dsc_>
cool
xes has joined #maemo-leste
<uvos>
btw
<uvos>
how are you handling having multiple chats open at the same time
<uvos>
with sphone i ran into the issue that libhildon uses a global for the stacked windows stack
<uvos>
so an application can have only one stack
Twig has quit [Ping timeout: 264 seconds]
mardy has quit [Quit: WeeChat 2.8]
<dsc_>
uvos: right, but I dont think you, or me, have to do anything to facilitate hildon in supporting multiple stacked windows, other than spawning mulitple QMainWindow's of course
<dsc_>
it just doesnt work right now because Wizzup messed up somewhere (c)(tm)
<dsc_>
i.e: if your application spawns X windows, and sets the 'stacked window property', it should work, I think...
<dsc_>
X amount of windows*
<uvos>
dsc_: well i my case i use libhildon1
<uvos>
not qt
<uvos>
so they also messed up
<uvos>
yeah in theroy there is no reason for this in h-d itself
<dsc_>
but to answer your question: I'm not spawning multiple windows currently
<uvos>
ok
<dsc_>
but I do plan to after Wizzup says it is fixed :P
[TheBug] has quit [Ping timeout: 250 seconds]
[TheBug] has joined #maemo-leste
xmn has joined #maemo-leste
SystemError has joined #maemo-leste
System_Error has quit [Killed (NickServ (GHOST command used by SystemError))]