<norayr>
it's interusting, how hildonized gtk app would behave if run under sxmo or just i ion't know, windowmaker, mate or gnome3.
elastic_dog has quit [Ping timeout: 255 seconds]
elastic_dog has joined #maemo-leste
joerg has quit [Ping timeout: 256 seconds]
joerg has joined #maemo-leste
macros_ has quit [Ping timeout: 248 seconds]
macros_ has joined #maemo-leste
pere has quit [Ping timeout: 256 seconds]
Twig has joined #maemo-leste
<freemangordon>
uvos: I don;t see anything terribly broken when executing libnotify tests
<freemangordon>
there are some issues (like, it seems test-replace-widget does not work correctly), test markup does not work as it should, but in general it is more or less fine
<freemangordon>
could you please share the code that does not work correctly for you?
pere has joined #maemo-leste
pere has quit [Ping timeout: 252 seconds]
<Wizzup>
norayr: I don't think it would behave well at all since it relies on hildon window manager to draw all the things and manage interactions
pere has joined #maemo-leste
xmn has quit [Ping timeout: 256 seconds]
lexik has quit [Ping timeout: 252 seconds]
lexik has joined #maemo-leste
Livio has joined #maemo-leste
Livio has quit [Changing host]
Livio has joined #maemo-leste
<sicelo>
nice! found my uSD card with Leste (N900). still has kernel 5.1
<sicelo>
i wonder if upgrade will be seamless
<Wizzup>
beowulf?
<Wizzup>
should be, assuming the dsme no lg reboots file exists
<Wizzup>
I mean you'll have to reboot for sure after the upgrade
<sicelo>
n900 battery depleted. i'll look shortly
<Wizzup>
yeah fwiw the n900 I have here is without battery, but I have a serial
<Wizzup>
I -think- I brought my lab psu
<Wizzup>
have to check
<Wizzup>
otherwise I can't test for you right now
<Wizzup>
but I am pretty sure this just worked on the n900
Pali has joined #maemo-leste
<sicelo>
yes beowulf. oddly, wlan not working at all, i.e. nothing showing up even with scans
<sicelo>
but will let it charge a bit and tinker further
<Wizzup>
there was a problem a while ago, but like 1+ years ago
joerg has quit [Read error: Connection reset by peer]
joerg has joined #maemo-leste
<sicelo>
Wizzup: forgot now, but what to do with "The following signatures were invalid: EXPKEYSIG 2700BD8E6604EC2E Maemo Leste Extras Signing Key <spam1@wizzup.org>"
<sicelo>
fixed
<sicelo>
now going to fight with the pvr changes, mmm
<sicelo>
ah, will do that one. for now was updating the other stuff (kernel, etc.)
<sicelo>
looks to be working. thanks
<sicelo>
hildon-meta-n900 is held back though. safe to force install, or i should let it be?
<Wizzup>
sicelo: you must always do dist-upgrade
<Wizzup>
fwiw
<Wizzup>
sicelo: I don't know what would hold it back, but you want it
<sicelo>
man, those locale files warned that "Generating locales (this might take a while)...
<sicelo>
and it is really taking a long while :p
<sicelo>
ok, hildon-meta's problem:
<sicelo>
The following packages have unmet dependencies: hildon-meta : Depends: hildon-desktop (>= 1:2.2.182) but it is not going to be installed
<sicelo>
weird though, as my h-d is higher version than that
<Wizzup>
sicelo: yes, it looks like some -dev pkgs would perhaps make this happen
<Wizzup>
I think I helped someone with this in irc a few months ago
<Wizzup>
I don't remember my conclusion :(
<sicelo>
it's still that ti-omap3-sgx issue actually. ended up force uninstalling it (ti-omap3-sgx), which nuked a number of packages including h-d itself. then hildon-meta-n900 installs fine and reinstalls the nuked packages
<Wizzup>
sicelo: meh, ok
<sicelo>
huhu, x won't start :-p
<Wizzup>
sicelo: and all upgrades complteed?
<Wizzup>
completed?
<sicelo>
yes
<sicelo>
i have usb-net, so i suppose it's a resolvable issue
<sicelo>
~$ cat /etc/powervr.d/hildon-desktop.ini
<sicelo>
[hildon-desktop]
<sicelo>
WSEGL_UseHWSync=0
<sicelo>
this is correct?
<Wizzup>
let me check
<Wizzup>
well actually, what is the error from X
<Wizzup>
check in /tmp
<Wizzup>
sicelo: I have that file and it boots ok for me
<Wizzup>
sicelo: it's loading a driver that should not exist
<Wizzup>
remove the pvrsvg ddx
<sicelo>
xserver-xorg-video-pvrsgx ?
<Wizzup>
yup nuke it
<sicelo>
ok. any way to start h-d now without reboot of whole device?
<Wizzup>
su - user
<Wizzup>
/usr/bin/hildon-desktop.launch
<Wizzup>
but reboot is probably easier :)
<Wizzup>
well, that assumes X is running
<Wizzup>
you could try to type 'openrc' and hope it does the right thing
<Wizzup>
(as root)
<sicelo>
i already rebooted, and h-d is up now. thanks
<Wizzup>
:)
<buZz>
oh man, i'm so hyped
<buZz>
next week i'm receiving my BT receiver chip for my headphones
<buZz>
the current one has the range of a wet blanket
<buZz>
so hopefully that will improve, but the new BT radio also does MP3 playback from SD , and FM receiving :D :D
<buZz>
gonna add a telescopic antenna i think ^_^ just for lolz
<Wizzup>
I should try to sit in my car one of these days and connect the d4 over bluetooth to it
<Wizzup>
would be kinda fun to make it work on some levels
<buZz>
oh it works :P
<buZz>
i used 'blueman' to connect it earlier
<Wizzup>
I think the module isn't even loaded right?
<Wizzup>
and then there's call audio routing which probably involves capturing it on cpu and then rerouting it
<buZz>
yeah not sure, the alsa(pulse?) mixer does show something can be routed -to- BT
<buZz>
or from?
<Wizzup>
not sure if that just works, unlikely :)
<buZz>
never know until we try :P
<sicelo>
btw what's the contacts application? want to install it on the n900
<Wizzup>
osso-addressbook
<Wizzup>
I'm adding it to the meta (already made the change locally)
<sicelo>
thax
<sicelo>
Wizzup: so yes, list-operators doesn't work on N900. mmm
<sicelo>
but i saw it works on d4
<sicelo>
so the breakage is probably in ofono's isimodem side
<buZz>
whats a list-operator in osso-addressbook context?
<Wizzup>
sicelo: what about the mdbus script?
<Wizzup>
err using mdbus2*
<Wizzup>
buZz: think it's unrelated
<Wizzup>
sicelo: how does it error?
<Wizzup>
sicelo: what if you run Scan first?
<buZz>
oh, ok
<Wizzup>
(to scan for operators)
<sicelo>
it doesn't error. it just doesn't return anything :-)
<sicelo>
mmm, now it works. wut!
<Wizzup>
sicelo: yeah so maybe you just need to tell it to scan first
<sicelo>
i was scanning before too (in pmOS)
<Wizzup>
maybe it just takes some more time?
<sicelo>
btw, looks like some unnecessary kernel configs have been enabled for N900. there's now bq27000-battery/ , twl4030_ac/ , and twl4030_usb/ in /sys/class/power_supply/
<Wizzup>
it's a shared kernel
<sicelo>
all of them aren't needed (nor do they work)
<Wizzup>
(with droid4, etc)
<sicelo>
yes @shared. but d4 definitely doesn't need them either :)
<sicelo>
i'll check modem again on pmOS
<sicelo>
i wonder what makes white LED keep showing up in Leste now.
<Wizzup>
I think it's an omap2plus defconfig thing
<Wizzup>
sicelo: leste userspace probably?
* sicelo
checks LED settings
<Wizzup>
sicelo: I mean, when do you see it?
<Wizzup>
I think by default it will do the blinking to show it's online
<Wizzup>
s/online/turned on/
<sicelo>
yes. i have turned it off now
<Wizzup>
:)
norayr has left #maemo-leste [Error from remote client]
norayr has joined #maemo-leste
uvos has joined #maemo-leste
<uvos>
the bluetooth call audio might work
<uvos>
its implemented in hw with no cpu involvement
<uvos>
its just a question if the register state is correct
<uvos>
i use bluetooth all the time on d4 for headphones
<Wizzup>
is that documented somewhere?
<uvos>
the main issue i have is that it blocks idle
<Wizzup>
right
<uvos>
i dont think so
<uvos>
but its just a matter of modprobeing the module
<uvos>
and using it via bluez/pulse
<uvos>
i also use blueman, but you could use any ui/cli
<Wizzup>
btw, another thing I forgot, although I think you thought about it, we haven't implemented 'mute' yet for calls
<uvos>
yeah
<uvos>
the mute button dosent go anywhere at all
<uvos>
atm
<uvos>
freemangordon: try using org.freedesktop.Notifications with a button array
<uvos>
iirc the code in h-d looks like it should do it
<uvos>
but it just dosent do anything
<freemangordon>
with 'actions'?
<freemangordon>
I don;t think actions are supported
<uvos>
the main problem with me describing the issues with it
<uvos>
is that i was playing around wiht it like 1 year ago
<freemangordon>
I can;t imagine how an array of buttons shoudl look like in task switcher
<uvos>
the window just has buttons?
<freemangordon>
sure, but it is tiny
<freemangordon>
even on d4
<uvos>
a window with actions becomes "real"?
<freemangordon>
no
<freemangordon>
this yellow note
<uvos>
the yellow note is wrong for a presistance message anyhow
<freemangordon>
this is a 'window' created by hildon-hom,e
<freemangordon>
no, why is that?
<uvos>
if you mean the banner
<uvos>
the toast
<freemangordon>
not the banner
<uvos>
not sure what the yellow window is for you
<freemangordon>
but the note in the switcher the size of a window rhumbnail
<uvos>
h-d opens a "fake" window
<freemangordon>
*thumbnail
<uvos>
for a notification
<freemangordon>
hit is h-h, but yeah
<freemangordon>
*it is
<uvos>
its not yellow
<Wizzup>
yes but it is typically on top of another window
<Wizzup>
and it doesn't support interaction other than activating it
<freemangordon>
well, depends on the theme
<Wizzup>
it's yellow in the normal theme but yeah
<uvos>
ok
<freemangordon>
and yes, as Wizzup said
<uvos>
anyhow, this window could simply be interactive
<uvos>
if actions are set
<freemangordon>
it is
<freemangordon>
if you click it, it executes the 'default' action
<uvos>
besides dissmissing it/ activateing the primary action
<freemangordon>
if no action was set
<uvos>
yes i know
<Wizzup>
not sure how this would work UX wise
<freemangordon>
ok, but how do you imagine, UI wise, to have multiple action in that window?
<Wizzup>
you activate it, and then you get a dialog?
<freemangordon>
Wizzup: exactly my point
<uvos>
it becomes a "real" window with some text (the desciption)
<uvos>
and x buttons
<freemangordon>
hmm
<freemangordon>
ok, this is 'good to have' feature, but I don;t see the lack of it as critical
<uvos>
well sphone kinda needs it
<freemangordon>
hmm...
<uvos>
really i dont linke this way of notification anyhow
<uvos>
but thats a different issue
<freemangordon>
for missed calls?
<freemangordon>
or, why it needs multiple actions?
<uvos>
but you need to be able to reply or ignore a sms for isntance
<freemangordon>
you ignor it by clicking the 'X'
<uvos>
that really dosent work well
<freemangordon>
sure it does
<uvos>
the x is way to small without a stylus
<freemangordon>
not really
<uvos>
(wich is a whloe nother issue)
<uvos>
imo it is
<Wizzup>
what does sphone need it for?
<freemangordon>
tasknav is smart enough to know when you wnt to click on the X
<uvos>
i want to/have (in a branch) replaced the sms recived window
<uvos>
with a notification
<Wizzup>
n900 phone app didn't need it, and I never felt like I missed something
<freemangordon>
:nod:
<uvos>
i think this is a really bad way of going about it
<uvos>
its missing a lot if you come form another plaform
<freemangordon>
uvos: no, really, it works ok
<Wizzup>
well in our case conversations would just handle all texts
<uvos>
notifications can be really ritch there
<freemangordon>
uvos: sure, but that's another story
<freemangordon>
like, we may consider re-writing maemo notifications, but we first have to define what we want, then do UI/UX, code, test,etc
<freemangordon>
I don;t really see that as such a high prio now
<freemangordon>
the questions is - can sphone live with current implementation, albeit not the best one around
<freemangordon>
does it lack some functionality?
<uvos>
not how its implemented atm
<freemangordon>
why?
<uvos>
because it uses actions :P
<freemangordon>
how many?
<uvos>
2
<freemangordon>
this is supported
<freemangordon>
'close' and 'click'
<uvos>
yeah but not those
<uvos>
2
<uvos>
since those 2 dont map well to other notification servers
<freemangordon>
the only thing that is defined in specs is the 'default' action
<uvos>
yes i know
<uvos>
but adding multiple actions to the array in the dbus call
<uvos>
causes all other notification servers to add buttons
<freemangordon>
maybe there is a bug
<freemangordon>
sorry, but that's how they implement it
<uvos>
yeah but that causes issues
<freemangordon>
I was not able to find any UI guidelines in the specs
<uvos>
for any app that wants to be cross platform
<uvos>
well you need to support more than 2 actions anyhow
<uvos>
per spec so....
<freemangordon>
why is that?
<uvos>
not sure how your going to do that
<uvos>
besides adding buttons
<freemangordon>
not really, only the 'default' is a must
<freemangordon>
lemme check
<freemangordon>
"The server will provide the specified actions to the user. Even if this cap is missing, actions may still be specified by the client, however the server is free to ignore them. "
<uvos>
ok fine its optional
<uvos>
still, in practice its used alot
<freemangordon>
but yeah, I understand...
<freemangordon>
ok, I will have a look at the code, maybe there is a bug if you specify actins in the dbus call
<freemangordon>
*actions
<freemangordon>
uvos: still, does sphone need more that 2 actions?
<freemangordon>
and if yes, what are those actions
<uvos>
not atm, atho i was thinking to also remove the special rinnging window
<freemangordon>
I need usecase to be able to think of UI/UX
<uvos>
and replaceing that with a notification
<freemangordon>
not really a good idea
<uvos>
that needs at least 3
<Wizzup>
if it does the notification, do we that in tklock too?
<uvos>
why not? it would work pretty well on desktop
<freemangordon>
no, that's really bad idea
<uvos>
(sphone also targets desktop)
<freemangordon>
this is not desktop, but phone
<uvos>
no its linux
<freemangordon>
you should be able to pick-up immediately
<uvos>
sphone is a generic linux application and it will stay that way
<uvos>
and why, excatly?
<freemangordon>
sure, but that does nto change the fact that we are talking phones here
<uvos>
also wdym pick-up immidatly?
<uvos>
you can on any notification server i know
<uvos>
(besides hildon)
<freemangordon>
uvos: sorry, but this is not that simple
<uvos>
since you get a raised allways on top window
<freemangordon>
there are gestures, for example
<uvos>
?
<freemangordon>
how do yo pick-up or mute if you count on notification server?
<Wizzup>
if you put the phone face down it will mute
<freemangordon>
or, if you rais, it will answer
<uvos>
i will never support that
<freemangordon>
*raise
<freemangordon>
why?
<freemangordon>
this is more than convenient
<uvos>
"how do yo pick-up or mute if you count on notification server?" ?
<uvos>
the server pops up a window with Person, call, accecpt, mute, hangup
<freemangordon>
and a basic feature since middle 90s maybe
<uvos>
i dont want sphone to have to deal with sensor input
<uvos>
and it mapps poorly to the range of devices i want it work on
<freemangordon>
ok, so you want laptop, not a phone
<uvos>
no i want an app thats scalable and maintainable
<freemangordon>
and clse to useless
<freemangordon>
*close
<freemangordon>
anyway
<Wizzup>
how is this different from earpiece sensor btw?
<uvos>
sphone dosent have to do anything wiht the earpiece sensor
<freemangordon>
you mean proximity?
<uvos>
its not in sphone at all
<uvos>
mce dose this on its own
<freemangordon>
right
<uvos>
anyhow the cancle via fliping over
<uvos>
and the notification server has nothing to do with eatch other
<uvos>
some utility could very well hangup the call on flip while useing a notification server
<uvos>
for the rinnging ui
<freemangordon>
ok, for me is hard to imagine a dialer that does not control its own "pick-up/hang" UI/UX
<uvos>
idealy it would handle the least possible
<uvos>
speaking of witch
<uvos>
nice to have: xdg dbus menu spec support
<uvos>
that would allow telegram, network manager and the like to how native looking dialogs (like icd) when activated with hildon-status-menu
<uvos>
*show
<uvos>
that way nm-applet would be a perfect native looking replacement for icd
<uvos>
if desired
<freemangordon>
uvos: a side of that: do you recall that qt5 issue where there is a white background in one of the widgets insted of teh correct color?
<uvos>
freemangordon: yeah so it looks like the hildon themes/ elements violate qt5's color spec
<Wizzup>
there is also text colours being wrong
<Wizzup>
in the notification text for example (if you set an alarm this is obvious)
<freemangordon>
I think in qalendar
<Wizzup>
clock ui also works
<uvos>
its allo over the place
<freemangordon>
Wizzup: so, this is what I meant
<uvos>
so whats happening here
<uvos>
is that hildon stuff uses BaseText over windowColor
<uvos>
wich is wrong
<uvos>
sec let me pull up the doc
<Wizzup>
I think we can fix these widgets, we control them in our plugin
<uvos>
QPalette::Text must be used over QPalette::Base
<uvos>
freemangordon: no
<uvos>
freemangordon: mainly in qt4 it was different
<freemangordon>
that's what I am saying
<freemangordon>
as we ported from qt4
<uvos>
ok
<uvos>
QPalette::WindowText needs to be over QPalette::Window
<uvos>
but hildon widgets use transparent backgrounds often
<uvos>
this messes this up
<freemangordon>
Wizzup: do you want to look at this?
<freemangordon>
uvos: back to libnotify: how do you think, if a notification gets updated, do we want another...ummm..how it is called... that 'note' that appears for a few seconds?
<uvos>
not sure what you mean
<freemangordon>
sec
<uvos>
are we talking tost notifications or presistant ones?
<uvos>
A Toast is a non modal, unobtrusive window element used to display brief, auto-expiring windows of information to a user. Android OS makes relatively heavy use of them.
<uvos>
(yellow banner)
<uvos>
(in hildon)
<freemangordon>
no
<freemangordon>
sec
<uvos>
by note you mean that thing that flies into the hildon button?
<freemangordon>
just a sec to provide you with a video, maybe
<uvos>
ok
<freemangordon>
ugh, VM got busted
<uvos>
maybe just discrbe what you mean, or provide a dbus call that shows it
<freemangordon>
yes, I will provide dbus call, need a minute to restart the VM
<Wizzup>
freemangordon: the yellow banner has the problem too, it might be a good test
<uvos>
thats wierd anyhow
<uvos>
why dose the application render the text at all
<freemangordon>
for couple of seconds a notification pops
<freemangordon>
then it get hidden and task switcher button starts to "breathe"
<freemangordon>
so, my question is about that notification
<uvos>
right
<uvos>
(behavior)
<freemangordon>
if a notification get updated (title/body/icon gets changed), shall I re-display that short notice?
<uvos>
probubly not, but i cant think of a real usecase atm
<Wizzup>
16:29 < freemangordon> Wizzup: do you want to look at this?
<freemangordon>
maybe a countdown timer?
<Wizzup>
I can add it to my list, not sure if I will look now
<freemangordon>
ok
<uvos>
freemangordon: def dont want a new flying notification thing for that
<uvos>
that would be annyoing
<freemangordon>
ok
<freemangordon>
this is how it behaves now (no new flying window)
<uvos>
great
<uvos>
sounds sane to me, unless you find a usecase
<freemangordon>
just the content of the yellow (or whatever) not window gets updated
<freemangordon>
*note window
<uvos>
right
<freemangordon>
ok, I will try to fix the markup as well
<uvos>
freemangordon: i would also argue btw
<uvos>
that non persistant notifications with a short expiry time
<uvos>
ought to be the yellow banner things, maybe
<freemangordon>
they are, afaik
<uvos>
that dosent work then
<uvos>
try notify-send -t 100 test
<freemangordon>
ok, will do
<freemangordon>
where to find notify-send?
<uvos>
libnotify-bin: /usr/bin/notify-send
<freemangordon>
uvos: I see flying wondow for a split second
<uvos>
freemangordon: yes
<uvos>
freemangordon: i was suggesting a yellow banner instead
<freemangordon>
ah, no
<freemangordon>
yellow banner is another story
<freemangordon>
to me flying window is consistent behaviour
<uvos>
ok, i was just mentioning that i think its more appropritate for this type of notification
<uvos>
so maybe it would be nice to have it switch according to the input it gets
<freemangordon>
if you do notify-send -t 1000 test you will see it is fine
<uvos>
sure yeah
<freemangordon>
100ms is not really a good use-case
<uvos>
i never said its wrong
<uvos>
well but a 1000ms or so thing is pretty ususal
<freemangordon>
ok, lemme push what I have done so far
<uvos>
and mostly the yellow banners are used for those
<uvos>
so switching it for <5sec or so would make desktop apps beahve more like hildon ones
<freemangordon>
but, I think for 1000 ms case it behaves correctly
<freemangordon>
hmm...
<freemangordon>
yeah, maybe not a bad idea
<freemangordon>
not, it will break UX
<uvos>
for what?
<freemangordon>
the are hildon UI guidelines
<freemangordon>
what you mean is hildon note
<uvos>
desktop apps dont follow those anyhow
<uvos>
so idk if its relevant
<freemangordon>
yeah, but hildon-home (the server) should
<uvos>
could you like the relevant section
<uvos>
im not sure how hildon-home would do so
<uvos>
it just depends how its used then no?
<freemangordon>
the point is that notifications specs are implemented with that flying window
<freemangordon>
hildon native API allows for those yellow banners
<freemangordon>
also, those flying windows are actually clickble
<freemangordon>
*clickable
<uvos>
so are the banners
<freemangordon>
dunno
<uvos>
they are
<uvos>
anhow sure but i find that for low timeout notifications having the window is a bit wierd
<freemangordon>
no, I meant "dunno if this is agood idea"
<uvos>
but its not a huge deal
<freemangordon>
well, but that windows is a flying one :)
<freemangordon>
well, yellow banners are dialogs actually
<freemangordon>
so, still 'window'
<uvos>
i mean the window after the flying one
<freemangordon>
ok, lemme see if I can fix the markup
<uvos>
having that for a split seciond is a bit wierd
<freemangordon>
no, it does not appear while we have a flying window
<uvos>
sure but if the timout is just longer than the animation
<uvos>
also other notification servers will display the message to the user for exactly timeout amount of time
<freemangordon>
only after that flying winde is gone, we have a window in the task-switcher
<uvos>
while the annimation here is fixed
<uvos>
and then the message is hidden
<freemangordon>
it is not
<freemangordon>
it gets hidden after the timeout
<freemangordon>
try with 1000
<freemangordon>
flying window gets shown for 1s and then it flies away
<freemangordon>
and no window is created in the task switcher
<uvos>
hmm but its wierd
<uvos>
try with 10s
<freemangordon>
I see no UX/UI issue with how it behaves
<freemangordon>
this is how it is supposed to :)
<uvos>
i gues there is some maximum
<freemangordon>
what for?
<uvos>
after which is turns into a window
<uvos>
like a persisant notification
<uvos>
thats a bit wierd
<uvos>
seams to be about 3s
<freemangordon>
5s
<uvos>
its not a big deal however
<freemangordon>
:nod:
<uvos>
still i think it would make hildon and non hildon apps behave more consistantly if we had some heuristic (the 5sec maybe) that is displayed as a banner
<Wizzup>
uvos: did you see bencoh's feedback on it?
<freemangordon>
Wizzup: where?
<Wizzup>
in irc, I'll have to search
<Wizzup>
he tried it out and had some feedback IIRC
<Wizzup>
starts at '11:50 < bencoh> I just tested twinkle on droid4 .... UI-wise it's horrible, but apart from that looks like it works :)'
<Wizzup>
12:29 < bencoh> alright, so ... the status icon works, the application-specific status menu works too, but once the menu has been used, restoring the application from the icon breaks, until next application restart
<Wizzup>
that I recall
pere has quit [Ping timeout: 256 seconds]
vagag has left #maemo-leste [#maemo-leste]
joerg has quit [Ping timeout: 248 seconds]
joerg has joined #maemo-leste
* bencoh
nods
<uvos>
i cant repo that
<uvos>
with twinkle
<uvos>
it works fine here
<freemangordon>
bencoh: I'll ping you these days for instructions how to test, ok?
<uvos>
also works fine with all other apps i have tested so far
<uvos>
so not sure whats happening on your end
<bencoh>
freemangordon: regarding that status menu thing? sure :)
<uvos>
its provides nothing that the glib envvars dont also provide
<uvos>
and is really a dozy when debuging modules
<uvos>
since you have no idea why you have no output
<freemangordon>
is it part of the same PR?
<uvos>
no
<freemangordon>
ok
<uvos>
im asking you do do this
<uvos>
*to do
<freemangordon>
ah, sorry, I misread what you asked for
<freemangordon>
ok, sure thing
<freemangordon>
uvos: I wonder if we want to support makup in notifications
<uvos>
probubly yes
<uvos>
but its not cricitaly important atm
<freemangordon>
in order to properly support it, I shall add either libxml dependency or some other parser
<uvos>
at least strip formating
<freemangordon>
which means parser :)
<uvos>
sure
<freemangordon>
formatting is not an issue
<freemangordon>
issue comes with hyperlink, or rather the fact that pango markup parser fails when string sontains hyperlink
<freemangordon>
but well, ok, I will see if I can do it with GMarkupParseContext
<freemangordon>
as specs say that unsupported tags shall be stripped
joerg has quit [Ping timeout: 252 seconds]
joerg has joined #maemo-leste
pere has joined #maemo-leste
<freemangordon>
uvos: what do you think, does "Notification servers that do not support these tags should filter them out. " mean that tags themselves shall be filtered or both tags and text in between?
<freemangordon>
this is about markup
<freemangordon>
and specifically about hyperlink
<freemangordon>
if it is about <a>link</a>, shall I remove both 'a' tag and 'link' text or only 'a' tag and leave teh text?
<freemangordon>
I read that like both 'a' and 'link' shall be removed, but want someone to confirm
Twig has quit [Remote host closed the connection]
<sicelo>
i would say tags only
<sicelo>
"<a href=''>Click here</a> to continue" becomes meaningless if the text is gone with the tag
<uvos>
freemangordon: i agree that the spec saies to remove the entire block shal be removed
<uvos>
but i also agree with sicelo that removeing just the tags is probubly more usefull in practice
<uvos>
*freemangordon: i agree that the spec saies to remove the entire block
<Wizzup>
I'm not sure if we want to do any parsing if we can avoid it