=== jalcine_ is now known as Guest16861
=== Guest16861 is now known as jalcine
=== jalcine is now known as Guest57006
=== Guest57006 is now known as jalcine
[07:52] <dholbach> good morning
[08:03] <dholbach> hey dpm
[08:04] <dpm> morning dholbach
[08:04] <dpm> good morning all
[08:13] <dholbach> dpm, did you see my comment on https://bugs.launchpad.net/ubuntu-devices-help/+bug/1425025?
[08:13] <ubot5> Launchpad bug 1425025 in Help for Ubuntu for devices "Automatically load translated pages according to the user language" [High,Triaged]
[08:14] <dholbach> dpm, it'd basically add a placeholder index.html for now, which could later be filled with more content
[08:14] <dholbach> (that's the branch I pushed)
[08:18]  * dpm reads now
[08:19] <dpm> dholbach, you're apologizing for fixing someone else's bug?
[08:19]  * dpm hugs dholbach
[08:19] <dpm> you can have all my bugs! :-)
[08:20] <dpm> but yes, now seriously, I think that's what we need to start tackling that bug
[08:20] <dholbach> ok
[08:20] <dholbach> I'll propose the merge
[08:20] <dholbach> dpm, https://code.launchpad.net/~dholbach/ubuntu-devices-help/1425025-partial/+merge/251217 - all yours :)
[08:22] <dholbach> just pushed a small change to it
[08:23] <dpm> dholbach, reviewed and commented
[08:23] <davidcalle> Good morning all
[08:23] <dpm> morning davidcalle o/
[08:24] <dholbach> dpm, I don't quite know how this is going to work in the 'web' case
[08:24] <dpm> dholbach, we can do the same as we did on help.ubuntu.com, and set up Apache to load the right page according to the browser language
[08:24] <dholbach> dpm, pointing your browser to    community.ubuntu.com/devices-help (or some such)    will get you index.de.html in the case of a German user?
[08:24] <dpm> yeah, that's the idea
[08:24] <dholbach> ok
[08:25] <dholbach> in that case, I'll revert the last change to it
[08:25] <dpm> dholbach, http://www.w3.org/International/questions/qa-apache-lang-neg
[08:25] <dholbach> thanks
[08:25] <dholbach> dpm, I'll make sure to document that
[08:26] <dpm> davidcalle, is the table on https://developer.ubuntu.com/en/start/ubuntu-for-devices/image-channels/ correct? it seems we're not pointing to any of the rtm channels
[08:26] <dpm> nor to any devel-proposed one
[08:28] <davidcalle> dpm, it's been changed to this version after discussion on a bug report, iirc it has saviq +1.
[08:28] <dpm> yeah, I remember some discussion and the change, but I wasn't sure
[08:29] <dpm> I'll double-check with pmcgowan too
[08:29] <davidcalle> dpm, yes please :)
[08:49] <nik90> dpm: hi good morning :)
[08:50] <dpm> hey morning nik90
[08:50] <nik90> dpm: I had a look at https://bugs.launchpad.net/ubuntu-clock-app/+bug/1324636, and I don't the proposed solution would work. I added a comment yesterday night after looking into it.
[08:50] <ubot5> Launchpad bug 1324636 in Ubuntu Clock App "Return localized city names" [Medium,Triaged]
[08:50] <nik90> dpm: on the other hand, I fixed https://code.launchpad.net/~nik90/ubuntu-clock-app/predefined-world-city-translation-fix/+merge/251180
[08:53] <dpm> nik90, cool
[08:53] <dpm> nik90, is tr() the same translation method as upstream Qt?
[08:54] <nik90> dpm: I believe they use qsTr() if I recall
[08:54] <nik90> dpm: but I checked with mzanetti for the c++ translation
[08:54] <dpm> nik90, ah, yes. So where does tr() come from?
[08:55] <nik90> dpm: it looks like mzanetti is away on irc, I will check with him when he is online in a few hours hopefully
[08:56] <dpm> I'll add a comment to the MP
[08:56] <dpm> and to the other bug
[08:56] <dholbach> dpm, https://code.launchpad.net/~dholbach/ubuntu-devices-help/1426011/+merge/251222
[08:56] <dholbach> once that's landed I'm going to blog about the initiative again
[08:56] <nik90> dpm: hmm the official docs suggest using tr() http://qt-project.org/doc/qt-4.8/i18n-source-translation.html
[08:57] <nik90> dpm: but yeah I i will check with mzanetti the difference between tr() and qsTr() later
[08:57] <dpm> yeah, that won't work
[08:57] <dpm> we're using gettext
[08:58] <nik90> ah ok
[09:04] <dpm> nik90, ok, commented on both
[09:05] <nik90> dpm: thnx
[09:09] <dholbach> gracias dpm
[09:13] <dpm> yw :)
[09:53] <JamesTait> Good morning all; happy Friday, and happy Strawberry Day! :-D
[10:18] <dholbach> dpm, can you maybe check later on if the translations of ubuntu-devices-help are set up correctly?
[10:18] <dholbach> just to make sure that everything's in place if people want to help out
[10:19] <dpm> dholbach, I can do it now, give me a min
[10:19] <dholbach> yeeeeeehaw!
[10:19] <dholbach> I'm sure you can do it 45 seconds!
[10:22] <dpm> dholbach, done, all set up :). However, I've noticed one thing: on these type of strings translations will break if they translate "Title:" right? We might need to filter it out somehow -> https://translations.launchpad.net/ubuntu-devices-help/trunk/+pots/help/ca/1/+translate
[10:23] <dholbach> dpm, the problem is: we want the title translated too, right?
[10:23] <dpm> yeah, but not the word "Title:"
[10:24] <dholbach> right
[10:24] <dholbach> of course, that'd confuse pelican
[10:24] <dholbach> I'll file a bug
[10:24] <dpm> another option would be to add a translator comment to ask not to translate it, but I couldn't find a way to add that to markdown text
[10:25] <dholbach> yeah, me neither
[10:26] <dpm> so I think the safest option is to filter out the metadata when creating the .pot file and re-adding it to the translated files, which already sounds ugly while I'm saying it
[10:27] <dholbach> yes, it's not easy
[10:27] <dholbach> anyway, I'll file a bug
=== rmescandon is now known as rmescandon|afk
=== MacSlow is now known as MacSlow|lunch
[11:37] <gventuri> rpadovani: popey: we have a design update for the calculator ready
[11:37] <nik90> pmcgowan: can you add https://bugs.launchpad.net/ubuntu-clock-app/+bug/1354466 to the canonical-devices-system-image project
[11:37] <popey> oh!
[11:37] <ubot5> Launchpad bug 1354466 in Ubuntu Clock App "Cities and Countries are not translatable in the timezone selection dialog" [High,In progress]
[11:37] <gventuri> popey: rpadovani: we need some time to go through it together
[11:37] <gventuri> popey: rpadovani: yeah sorry, it took more time than i thought
[11:37] <gventuri> as usual
[11:37] <popey> gventuri: we had the calculator meeting yesterday. we can certainly find a slot to discus
[11:37] <nik90> mzanetti: can you ping me when you got some time, just need a minute or two to clear up a question
[11:38] <gventuri> popey: cool
[11:38] <mzanetti> nik90, hit me
[11:38] <popey> gventuri: afternoons are usually better for rpadovani i believe. when's good for you?
[11:38] <gventuri> popey: the updates are already online, but I find it useful when we can have some face-to-face time
[11:38] <nik90> mzanetti: can you take a look at dpm's comment about tr() not being compatible with gettext() that ubuntu uses at https://code.launchpad.net/~nik90/ubuntu-clock-app/predefined-world-city-translation-fix/+merge/251180/comments/623265
[11:39] <gventuri> popey: rpadovani: today is good for me
[11:39] <gventuri> or next week
[11:39] <popey> gventuri: 4pm?
[11:39] <nik90> mzanetti: I see that the pot file does indeed grab the strings for translation, so may be it already works.
[11:39] <gventuri> popey: we have a meeting 4-5pm today, sorry
[11:39] <nik90> mzanetti: but we were not sure if qsTr() or anything else should be used
[11:39] <gventuri> popey: mondau?
[11:39] <gventuri> monday
[11:40] <mzanetti> nik90, well, qsTr() is only in qml
[11:40] <popey> gventuri: let me mail everyone to see if we can organise it.
[11:40] <mzanetti> nik90, seeing that the translations are in the po files I guess tr should be working too
[11:40] <mzanetti> nik90, should be easy to test I guess
[11:40] <popey> I'll do that now. gventuri who (other than you) from design needs inviting?
[11:40] <mzanetti> nik90, if it doesn't well, change it to 18n.tr()  or gettext()
[11:41] <nik90> mzanetti: is i18n.tr() valid in c++?
[11:41] <gventuri> kerry.malone@canonical.com
[11:41] <mzanetti> nik90, I don't know...
[11:41] <gventuri> popey: kerry.malone@canonical.com
[11:41] <nik90> mzanetti: ok
[11:41] <popey> gventuri: ok
[11:41] <gventuri> popey: she is the visual/interaction designer
[11:42] <nik90> dpm: as mzanetti says, the pot file is indeed updated with the citiy and country names and thereby it should appear translated on the device even while using tr()
[11:42] <dpm> nik90, the extraction into the .pot file at build time will work, but loading the translations at runtime won't
[11:42] <nik90> dpm: ah
[11:42] <mzanetti> ah, right...
[11:42] <mzanetti> you'd probably need to load the translated file with a QTranslator...
[11:42] <mzanetti> however, I guess using gettext() or whatever the other is, might be easier
[11:43] <dpm> +1
[11:43] <nik90> dpm: I took a look at http://bazaar.launchpad.net/~ubuntuone-control-tower/unity-scope-click/trunk/view/head:/libclickscope/click/highlights.cpp#L127, .. do I so mark strings as __string__ ?
[11:43] <mzanetti> and I just figured my latest branch of reminders uses tr() too
[11:44] <nik90> adding #define _(value) dgettext(GETTEXT_PACKAGE, value) to the header file shouldn't be an issue
[11:44] <nik90> mzanetti: yeah we should gettext to do the translation in other parts of the app, so it would be easier to keep to it
[11:44] <nik90> s/should/use
[11:44] <dpm> nik90, you can use gettext("I want this to be translated"), but traditionally, the _("I want this to be translated") alias is used, as it's quicker to type
[11:45] <mzanetti> nik90, ack
[11:45] <mzanetti> ah nice!
[11:45] <mzanetti> imo that helps in this particular case
[11:45] <mzanetti> the _()
[11:45] <mzanetti> makes it much more readable
[11:45] <nik90> dpm: oh...that's simple then...I can just "tr()" with "_()" in qtc
[11:46]  * nik90 tries it out now...will update dpm, mzanetti in a few minutes
[11:46] <dpm> essentially, yes, but you have to make sure that _() is indeed an alias to the gettext.gettext() function :)
[11:46] <dpm> or dgettext
[11:46] <nik90> sure
=== rmescandon|afk is now known as rmescandon
[12:00] <nik90> dpm: I imported libintl.h and then used gettext("string"), while it compiles fine, it doesn't seem to update the pot file. I also tried #define _(value) dgettext(GETTEXT_PACKAGE, value) and then used _("string") and set -DGETTEXT_PACKAGE=\"${PROJECT_NAME}\", but that doesn't work either
[12:00] <nik90> I set -DGETTEXT_PACKAGE=\"${PROJECT_NAME}\" in the CMakeList file as they did in http://bazaar.launchpad.net/~ubuntuone-control-tower/unity-scope-click/trunk/view/head:/libclickscope/click/CMakeLists.txt
[12:03] <dpm> the .pot file generation is independent from the code
[12:04] <dpm> it's just a rule that uses xgettext to scan all files for common i18n patterns. So probably the po/CMakeLists.txt file needs an update
[12:04] <dpm> do you have a link to the branch you're working on?
[12:05] <nik90> well do you want me to push it with gettext() calls?
[12:05] <nik90> 1 sec let me upload it
[12:06] <dpm> nik90, so essentially, it's this rule that puts the translations into the .pot file: http://bazaar.launchpad.net/~nik90/ubuntu-clock-app/predefined-world-city-translation-fix/view/head:/po/CMakeLists.txt#L17
[12:06] <dpm> and the --keywords argument
[12:06] <dpm> if you used gettext(), it might not be a recognized argument, whereas I would think _() should be recognized by default
[12:07] <dpm> if not, you might need to explicitly add --keyword=_
[12:07] <dpm> but I'm pretty sure that's already taken care of by default
[12:07] <dpm> and it's not necessary to add the _ keyword
[12:07] <nik90> I pushed it
[12:08] <nik90> but yeah I tried _( as well
[12:08] <nik90> maybe I should add --keyword=gettext ?
[12:09] <dpm> nik90, yeah, you either do that, or uncomment the _() definition and use _() calls instead of gettext()
[12:10] <dpm> I'd suggest the second option, and if that still does not work, we can look at it
[12:12] <nik90> dpm: hmm gettext() calls + --keyword=gettext option worked...I see the pot file update. When I switched to the other one, it removes the marked strings from the pot file.
[12:13] <nik90> dpm: I will switch to _() and push it so that we can debug from the same codebase
[12:14] <dpm> nik90, ok, cool. You might want to explicitly add --keyword=_ to try, perhaps I'm wrong and it's not added by default, which could solve the problem
[12:15] <nik90> sure, trying now
[12:15] <nik90> dpm: yup adding --keyword=_ did the trick
[12:17] <dpm> excellent
[12:21] <dpm> oh wow, I'm not sure it's because of the porting guide, but I'm recently seeing more ports than usual
[12:21] <dpm> here's a blast from the past: https://twitter.com/vishne0/status/571169328688697344
[12:22] <nik90> :)
[12:31] <nik90> popey: hey, does the welcome wizard fall under unity8?
[12:32] <popey> yes
[12:32] <nik90> thnx
[12:48] <nik90> zsombi: ping
[12:49] <zsombi> nik90: pong
[12:49] <nik90> zsombi: that was a quick fix for the alarms issue, thnx. I need your advice on bug 1387210
[12:49] <ubot5> bug 1387210 in Ubuntu UX "[Indicators] Deep link to alarm item doesn't work properly" [Medium,Triaged] https://launchpad.net/bugs/1387210
[12:50] <nik90> zsombi: I am not sure how indicator-datetime will know which alarm id to pass to the clock app to open when a user clicks on it in the indicator
[12:50] <nik90> zsombi: is the alarm ID stored along with the other alarm properties like recurrence, name etc ?
[12:51] <zsombi> nik90: the alarm id is stored in cookie, but that si not exposed to QML
[12:52] <nik90> zsombi: what about the alarm Index? since that's what I use to edit/open a particular alarm
[12:52] <zsombi> nik90: that's not good, as that may change as well, depending on teh alarm times...
[12:53] <zsombi> nik90: it is valid until you change and save the alarm date
[12:53] <nik90> zsombi: I basically need indicator to pass some sort of alarm id so that clock can open the correct alarm
[12:53] <nik90> zsombi: well even if the user changes the alarm date, i-dt should receive the updated alarm id? no?
[12:53] <zsombi> nik90: not the index...
[12:54] <nik90> zsombi: ok..any ideas?
[12:54] <zsombi> nik90: we could expose the cookie, but that woudl mean you must import 1.2
[12:54] <zsombi> Ubuntu.Components I mean
[12:55] <nik90> zsombi: well, at some point I need to import 1.2 to get the new list items, so that's not an issue
[12:55] <zsombi> nik90: or do you plan to fix it still on RTM image?
[12:55] <zsombi> nik90: ah, ok... it's a variant type, so you might be able to use that
[12:55] <nik90> zsombi: well considering that the entire platform will switch to vivid in about 3-4 weeks time (from lucas's email), I don't mind waiting until then
[12:56] <zsombi> nik90: ok, but submit me a bug, so I can justify the API change
[12:56] <nik90> zsombi: but i-dt will also have access to this id, correct? if not then it wont help me
[12:56] <zsombi> nik90: you can say to charles that the alarm ID he should pass is the QOrganizerItemId
[12:56] <nik90> ah ok
[12:57] <nik90> perfect thnx. I will report the bug now
[12:58] <zsombi> kalikiana: t1mp: the last of the ListItem containers is also ready: https://code.launchpad.net/~zsombi/ubuntu-ui-toolkit/100-captions/+merge/251248
[12:59] <nik90> zsombi: You fixed bug 1195353 ! Woohoo thnx a lot.
[12:59] <ubot5> bug 1195353 in ubuntu-ui-toolkit (Ubuntu) "SDK should provide support to rearrange items in a ListView" [Medium,Triaged] https://launchpad.net/bugs/1195353
[13:00] <zsombi> nik90: yep :) in staging right now
[13:02] <nik90> zsombi: bug 1426361 as you requeste
[13:02] <ubot5> bug 1426361 in ubuntu-ui-toolkit (Ubuntu) "Alarms API should expose a unique permanent alarm ID that clock app can use to open an alarm" [Undecided,New] https://launchpad.net/bugs/1426361
[13:02] <nik90> s/requeste/requested
[13:03] <zsombi> nik90: thx!!!
=== _salem is now known as salem_
=== MacSlow|lunch is now known as MacSlow
=== rmescandon is now known as rmescandon|lunch
[13:57] <zsombi> nik90: question -  what will be the format you will receive teh ID from i-dt? variant?
[13:58] <nik90> zsombi: hmm not sure, I still need to discuss that with charles
[13:58] <zsombi> nik90: asking as comparition with two variants won't work :/
[13:58] <zsombi> in QML at least
[13:59] <nik90> zsombi: well wouldn't I be just calling alarmmodel.get(alarmID) and then the comparison actually is done by the alarms api in c++?
[14:00] <zsombi> nik90: the get() function requires an index, but then I need to provide an other version also
[14:00] <nik90> zsombi: yeah you would need to expose another function similar to get() that takes the ID instead of the index
[14:00] <nik90> that was my understanding from our discussion before
[14:01] <zsombi> nik90: and the problem is that a simple QVariant might not be good enough... as that one holds the QOrganizerItemId....
[14:02] <zsombi> and not the ID itself...
[14:02] <zsombi> so a value cast woudl be needed, and you most probably will get a string, not a variant
[14:02] <zsombi> nik90: ^
[14:02] <nik90> zsombi: oh ok
[14:03] <zsombi> nik90: so let me know what type you need
[14:03] <nik90> zsombi: ok. I will discuss with charles and let you know
[14:04] <zsombi> nik90: you can live the notes in teh bug, I'll check it on Monday
[14:04] <nik90> zsombi: ack.
[14:04] <zsombi> nik90: thx
[14:06] <nik90> np
=== rmescandon|lunch is now known as rmescandon
[14:58] <mzanetti> In reminders I'm setting alarms (actually organizer items) so that the phone rings and they show up in the datetime indicator
[14:59] <mzanetti> however, pressing on those entries opens the calendar app instead of reminders
[14:59] <mzanetti> anyone know how (or if possible at all) to change that?
[15:10] <mzanetti> zsombi, ^^
[15:10] <mzanetti> popey, hey, I see an update of Terminal and FileManager.
[15:10] <mzanetti> popey, but they're armhf only :'(
[15:10] <popey> ooh, thanks for the reminder
[15:11] <popey> zbenjamin: bzoltan_ when do we get fat package support in the SDK? :)
[15:11] <popey> mzanetti: I upload jenkins-made clicks - I'm not going to manually craft fat packages.
[15:11] <bzoltan_> popey:  s/do/did/
[15:11] <popey> hahah
[15:12] <popey> how?
[15:12] <popey> You're my hero.
[15:12] <bzoltan_> popey: Magic :) For qmake project it "just" (tm) works
[15:12] <popey> gah
[15:12] <bzoltan_> popey:  sadly with cmake it is close to impossible
[15:13] <popey> balls
[15:13] <bzoltan_> popey: that happens when you play with non native formats :( Shame .. really is
[15:13] <popey> dpm: ^
[15:13] <popey> all core apps are cmake, bzoltan_ tells me we're boned for fat packages in core apps
[15:13] <popey> this makes me a very sad puppy
[15:14] <mzanetti> bzoltan_, popey: You should note though that the fat package support is not supported on krillin
[15:14] <popey> (╯°□°)╯︵ ┻━┻
[15:14] <mzanetti> creating fat packages with sdk+qmake will likely not work for krillin
[15:18] <bzoltan_> mzanetti:  háähh??? How come?
[15:19] <mzanetti> bzoltan_, well... 15.04 has Qt 5.4, while RTM has Qt 5.3
[15:19] <mzanetti> you can't compile with 5.4 and then run on 5.3
[15:19] <mzanetti> only the other way round
[15:19] <bzoltan_> mzanetti: hmm... it must be possible.
[15:19] <charles> zsombi, nik90, looking at scrollback now
[15:19] <mzanetti> bzoltan_, it is possible, if you avoid the changed symbols
[15:20] <mzanetti> bzoltan_, like don't use qdebug for example
[15:20] <bzoltan_> mzanetti:  Qt must be ABI compatible between minor releases
[15:20] <mzanetti> bzoltan_, upwards only
[15:20] <mzanetti> not downwards
[15:20] <bzoltan_> mzanetti: ohhh hack
[15:20] <mzanetti> so compiling with 5.1 is still supposed to run on 5.4
[15:20] <mzanetti> but not the other way round.
[15:20] <mzanetti> which kinda makes sense I'd say
[15:21] <bzoltan_> mzanetti:  RTM will be on 5.4 soon
[15:21] <mzanetti> yep, that'll solve this problem
[15:21] <bzoltan_> mzanetti:  and ... anyway, I kow loads of sensible things what sucks big time :D
[15:22] <bzoltan_> mzanetti:  anyhow.. it is question of weeks and RTM will be on Vivid
[15:22] <mzanetti> not sure I get what you're trying to say with that
[15:23] <mzanetti> yeah... I don't think it makes much sense backport stuff at this point... rtm will be updated soon enough
[15:23] <mzanetti> just saying, if you create a fat package with the SDK *now*, people getting their bq phones in march won't be able to run them
[15:26] <bzoltan_> mzanetti: I am affraid that it is not about fat packaging, but in general your app is busted if you use the 15.04 chroots instead of 14.10
[15:27] <mzanetti> yeah
[15:27] <bzoltan_> mzanetti: for the RTM the official channel is 14.10 what does not support qmake projects at all... so it does not have fat packaging
[15:27] <mzanetti> it's about building with a 15.04 chroot
[15:27] <mzanetti> yep.
[15:27] <bzoltan_> mzanetti:  what is not supported for krillin ab ovo
[15:28]  * bzoltan_ wished so many times to have a RTM bootsrap instead of faking the RTM with Utopic
[15:28] <mzanetti> bzoltan_, yeah, all makes sense to me. I just wanted to tell popey that at this point in time, he needs to be careful with publishing fat packages
[15:29] <popey> i build in 14.10 kits fwiw
[15:31] <bzoltan_> popey:  good, that is a safe land
[15:33] <bzoltan_> mzanetti: popey: if people would be more interested about the static Kits instead of the fragile and unstable bootstrapping I could make RTM images with qmake+fat support.
[15:33] <charles> nik90, zsombi, https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/1426363/comments/1
[15:33] <ubot5> Launchpad bug 1426363 in indicator-datetime (Ubuntu) "I-dt should send the alarm QOrganizerItemId to the clock app when the user clicks on an alarm shown in the indicator" [Undecided,Incomplete]
[15:53] <popey> sverzegnassi: see my comment on that merge?
[15:53] <popey> did I break it? :)
[16:50] <popey> \o/ https://swordfishslabs.wordpress.com/2015/02/27/json-profiles-in-ubuntu-terminal-app/
[16:59] <Mirv> cool, the terminal really rocks nowadays and that json customization support is an icing on the cake
[17:00] <ogra_> i really want a QML widget that i can hand a path to a comman to exec now
[17:00] <ogra_> (a terminal widget)
[17:00] <ogra_> packaging things like htop or irssi into a click would be trivial if we had that
[17:00] <ogra_> or mutt :)
[17:08] <zbenjamin> popey: you can manually create fat packages btw
[17:12] <zbenjamin> popey:     http://pastebin.ubuntu.com/10451877/
[17:14] <zbenjamin> ogra_: can't you use the component used for the terminal?
[17:14] <zbenjamin> ogra_: would be awesome to have that avail as a systemwide library
[17:27] <popey> ogra_: after we add an option to switch custom keyboards on and off, the next item planned is a terminal component
[17:27] <popey> so devs can package up mutt+terminal and put in the store
[17:27] <popey> it will be a stripped down terminal, probably no tab support
[17:28] <popey> JET - Just Enough Terminal.
[17:32] <zsombi> mzanetti: I am not surprised to be honest...
[17:32] <zsombi> mzanetti: about the "alarms" created from Reminders
[17:34] <zsombi> mzanetti: as long as Alarms uses QtOrganizer, you will see this happening :/
[17:35] <zsombi> mzanetti: we had one "hack" with charles, but that was just pretending that we've fixed it... so we REALLY need a proper backend for teh alarms...
[17:38] <charles> at one point we talked about adding a crud dbus api to indicator-datetime for manipulating the alarms s.t. we wouldn't have to go through QtOrganizer and EDS
[17:38] <charles> alarms via qtorganizer/eds has been far, far more problematic than it's been worth IMO
[17:39] <charles> even after nik90, renatu, zsombi, and I have worked on different pieces of the toolchain for a long time now, we /still/ get alarms that fail to make it through the pipeline correctly
[17:43] <nik90> charles, zsombi: hmm yes the new backend is definitely work looking at this point after all the work that has been done to get it working. TBH I would rather work on that before starting on the clock app timer functionality since the last time I discussed this with bill filler, he said the clock app timer will also require waking up by an external service
[17:43] <nik90> using the alarms api. May be with one good simple backend we can achieve both alarms and timer.
[17:43] <nik90> s/work/worth
[17:44] <zbenjamin> popey: \o/ a terminal component?
[17:44] <zbenjamin> popey: awesome! i can use one for script output in the SDK :)
[17:45] <zsombi> charles: that's why we should reload the brainstorming about the dbus API
[17:47] <zsombi> nik90: charles: yes, the same backend coudl do the job. From toolkit's point, a separate interface may be required, but that's a different sorry
[17:47] <nik90> zsombi: yeah same backend, different interface but indicator-datetime again doing the job of ringing the audio notification in both the cases
[17:48] <zsombi> yes
[17:49] <nik90> zsombi: btw did you move? Usually its really late now in your place and you're offline by now
[17:49] <zsombi> charles: do you have any ideas in mind, or should I pull a set of requirements for the timers/alarms?
[17:50] <zsombi> nik90: nope, I just turned on my laptop and my IRC client was on :D
[17:51] <zsombi> charles: nik90: I will build a blueprint on Monday about some requirements we all can contribute to and I think the next thing to be done will be to work on that
[17:52] <nik90> zsombi: +1..I will chip in as well and ensure all requirements that I know of are in there
[17:52] <zsombi> nik90: I count on you :)
[17:52] <nik90> hehe :P
[17:53] <nik90> anyways I am off to preparing dinner .. have a nice weekend everyone!
[17:54] <popey> zbenjamin: :)
[17:56] <zsombi> nik90: same
[18:00] <mzanetti> zsombi, so what I actually do is to use QtOrganizer directly. and what happens is that it opens the calendar.
[18:00] <zsombi> mzanetti: we know... we also use qtorganizer :/
[18:00] <zsombi> mzanetti: and that's the problem
[18:00] <mzanetti> so my question was more if you happen to know where the to-be-opened app can be specified
[18:01] <zsombi> mzanetti: I don't think that is specified anywhere
[18:01] <zsombi> mzanetti: yet indicator opens the Alarms for QtOrganizerTodo events... i guess charles can help you on that
[18:01] <mzanetti> why does alarms open the clock app then instead of the calendar app too? Is that the "hack" you mentioned?
[18:01] <mzanetti> right
[18:02] <zsombi> mzanetti: do you see Alarms in your app as well?
[18:02] <mzanetti> no
[18:02] <zsombi> mzanetti: that's a pleasant surprise tbh...
[18:03] <mzanetti> hmm... it's been a while... let me check if I filter them away myself
[18:03] <mzanetti> just to be sure
[18:04] <charles> zsombi, mzanetti, yeah opening the clock app for calendar events on the phone is a bug, I'm looking at that code and the fix seems straightforward
[18:05] <mzanetti> erm... works here (on rtm that is)...
[18:05] <mzanetti> my issue is that it opens the calendar instead of reminders :)
[18:05] <zsombi> charles: the only problem is to identify which alarm you open... I don't have anything else on my disposal than QtOrganizerItemId :/
[18:05] <charles> no wait
[18:08] <charles> yeah, I was jumping to conclusions just now and reading the code wrong :/
[18:08] <charles> so about identifying which alarm to open
[18:10] <charles> zsombi, I'm not saying that we can't use that -- I'm saying that, since datetime isn't using the qtorganizer library, it would be faster if you can give me an example of an .ical snippet and point to the id that needs to be used
[18:11] <mzanetti> zsombi, I just checked. I don't get the calendar entries. so all working fine there
[18:11] <zsombi> charles: right, it would be :)
[18:11] <zsombi> mzanetti: huhh... I am still surprized it does :D
[18:12] <charles> for opening /calendars/ to the right place, I had a hard time getting this to work with evolution on the desktop
[18:12] <charles> what it prefers is if you send it a time string as an argument
[18:12] <mzanetti> zsombi, hmm... well, I do set a filter on the collectionId I create... maybe I would get them without that, but seems like the expected thing to me, no?
[18:13] <charles> on desktop, to open the calendar to the right place, datetime uses calendar:///?startdate=%Y%m%dT%H%M%SZ
[18:13] <mzanetti> charles, there's maybe a misunderstanding here :)
[18:13] <zsombi> mzanetti: yes... however the QtOrganizer API allows to get all Todos if you don't specify a collectionId... so others will get the Alarms and reminders in one shot
[18:14] <mzanetti> charles, what I'm trying to do is to open the reminders app (not a reminder in the calendar) when you press on an entry in the datetime indicator that I created with the reminders app
[18:15] <charles> mzanetti, ahhh
[18:16] <renatu> charles, hi, did you have time to look at my fix? https://code.launchpad.net/~renatofilho/qtorganizer5-eds/fix-1424924/+merge/251129
[18:18]  * charles tries the novel idea of reading scrollback before saying anything else
[18:21] <zsombi> charles: :D
[18:21] <charles> okay so (1) zsombi, nik90, I agree we should reload the discussion for alarm create/read/update/delete via dbus, with a mind to eliminating some of the middlemen in the toolchain
[18:21] <zsombi> charles: +10000
[18:21] <zsombi> charles: I will create a BM on monday so we can log teh ideas
[18:22] <zsombi> s/BM/BP
[18:22] <charles> (2) mzanetti, zsombi, unfortunately there's not currently a way to add in another app, e.g. the reminders app. But yes this does dovetail with the other discussion of pulling up the right alarm in clock-app
[18:23] <charles> in both cases (clock-app and reminders) likely we'll want to pass some url into the ical s.t. the menu can pass it to url_dispatch when clicked
[18:23] <mzanetti> yep, that'd be ideal
[18:24] <charles> that was the original plan, that datetime would just be a blind pass-through, dispatching whatever url was sent to it (at least, after doing basic sanity checks)
[18:25] <charles> we'd probably want calendar-app to be the fallback if that URL was missing, to play nicely with calendars imported from google
[18:25] <charles> zsombi, ack, we'll talk on monday
[18:26] <charles> mzanetti, is there a bug yet tracking the reminders support for datetime menu clicks?
[18:26] <charles> s/reminders/arbitrary app/
[18:28] <mzanetti> charles, hmm... seems so... don't know. maybe I'm doing something wrong
[18:28] <charles> ?
[18:28] <mzanetti> charles, but when I click on an entry I created, it opens the calendar app
[18:29] <mzanetti> ah
[18:29] <mzanetti> I misread
[18:29] <mzanetti> sorr
[18:29] <mzanetti> sorry
[18:29] <mzanetti> no, I haven't filed a bug yet
[18:33] <charles> actually it looks like datetime does have residual code for this, we're just not currently using it from the things created by calendar-app or clock-app:
[18:33] <charles> http://bazaar.launchpad.net/~indicator-applet-developers/indicator-datetime/trunk.15.04/view/head:/src/actions-live.cpp#L137
[18:34] <charles> if we have a URL for the item, we dispatch it... otherwise if it was generated by clock-app, we launch clock-app... otherwise calendar-app
[18:34] <charles> so all we have to do for reminders is to get that URL populated
[18:35] <charles> that, though, needs some work
[18:36] <charles> right now those are stored in an alarm-specific way in ical for historic reasons
[18:37] <charles> instead, we might want to re-abuse the 'categories' section of ical because that's a place where we can add arbitrary key/value pairs
[18:38] <charles> that way reminders wouldn't have to create alarm attachments just to shoehorn in a url
[18:38] <charles> I'm open to suggestions on this, I see using 'categories' as less bad, but still clumsy
[18:40] <charles> renatu, looking at https://code.launchpad.net/~renatofilho/qtorganizer5-eds/fix-1424924/+merge/251129 now
[18:40] <renatu> charles, thanks :D
[18:41] <charles> ah, well http://www.kanzaki.com/docs/ical/url.html would be better than either 'categories' or 'alarms' for this :)
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== _salem is now known as salem_