<uvos__>
but i mean there is no usecase for a abook widget to ever open osso-addressbook to handle a url
<uvos__>
since osso-addressbook then pops up the "add contact" dialog
<freemangordon>
exactly
<uvos__>
and that makes no sense if the user clicked on the link inside the abook in the firstplace
<uvos__>
so just filter away the osso-addressbook in every uri_open call in abook
<freemangordon>
osso-addressbook is just an application
<freemangordon>
and there is no issue when user clicks link from it (already added filter)
<uvos__>
its an application that registers a osso-service
<freemangordon>
but if it is not osso-addressbook that uses the lib
<freemangordon>
then we have an issue
<uvos__>
i dont see why, every call to libhildonmime from abook-lib simply filters away the osso-addressbook service and everything works fine
<freemangordon>
no, we can't do that
<uvos__>
why not?
<freemangordon>
I mean - this is ugly hack
<uvos__>
i dont think its that ugly really
<freemangordon>
what about abook applet then?
<freemangordon>
umm...
<freemangordon>
wait
<uvos__>
what about it?
<freemangordon>
scratch that
<uvos__>
a bigger problem i see is the other direction
<freemangordon>
why should be osso-addressbook any special?
<uvos__>
i mean if you dont want it to be special
<uvos__>
you can implement something like android intents
<freemangordon>
no idea what it is
<uvos__>
android intents allow handlers to have specific purposes
<uvos__>
ie the dispach can give a hint that: this schal be used to communicate
<uvos__>
or: this shal be stored in some address book
<uvos__>
etc
<freemangordon>
we have similar already
<freemangordon>
not same, but similar
<uvos__>
well the services dont work that way
<freemangordon>
hildon-uri actions
<freemangordon>
they do
<uvos__>
afaik libhildonmime has no way of being told to only consider handlers of a certain type
<freemangordon>
yes, see the second parameter of hildon_uri_get_actions_by_uri()
<freemangordon>
so there seems to be some idea we can extend
<uvos__>
well that
<freemangordon>
but, I don't really want to go into that
<uvos__>
dosent really have that kind of granularity that android intents have at all
<freemangordon>
sure
<uvos__>
like what dose NORMAL and NEUTRAL even supposed to mean
<freemangordon>
still trying to grok :)
<uvos__>
anyhow the clean solution would be to have "open" and "store" be different actions
<uvos__>
and xdg-open only responds to "open" (obviously) and osso-addressbook only to "store"
<uvos__>
that would be copying android essentally
<uvos__>
the sliglty less clean solution (but imo not bad) would be to just hardcode filter away osso-addressbook in abook-lib
<freemangordon>
dunno, really sounds like a hack to me. that way we say osso-addressbook is the only addressbook on the system, which contradicts to what you are fighting for all the time :p
<uvos__>
this is true, and i use gnome contacts some
* freemangordon
puts his devil's advocate hat on
<uvos__>
but in the end gnome-contacts dosent use libhildonmime anyhow
<uvos__>
so it has no effect
<freemangordon>
right, but we limit osso addressbook provider
<uvos__>
this is another big problem for this whole construction of course, firefox will never choose a osso-service to handle something
<freemangordon>
it shall never I think
<uvos__>
why not?
<uvos__>
we could have speical .desktop files for osso-services
<freemangordon>
dialer shall register with xdg, no?
<uvos__>
that call libhildonmime with some parameters
<uvos__>
that then are registered with xdg
<uvos__>
anyhow not important right now
<freemangordon>
right
<freemangordon>
hmm, I wonder why is not osso-addressbook kalled for emails
<freemangordon>
*called
<uvos__>
probubly modest is just head of it in the list
<uvos__>
*ahead
<freemangordon>
That'd be really crazy if Nokia counted on that
<freemangordon>
ok, will check that when I have some time, have to run now. ttyl
dos has quit [Ping timeout: 255 seconds]
dos has joined #maemo-leste
pere has quit [Ping timeout: 258 seconds]
arno11 has joined #maemo-leste
Daanct12 has quit [Read error: Connection reset by peer]
<arno11>
Wizzup: sicelo: i tweaked transition.ini a bit (a lot in fact) and result is crazy: the UI is now really fast (even without overclock)
pere has joined #maemo-leste
Daanct12 has joined #maemo-leste
<arno11>
apt-worker is a big concern too. must be disabled i think, without overclock n900 is unusable for 5 min at least when apt-worker is running...