[07:05] <tsdgeos> morning
[08:39] <tsdgeos> larsu: ping
[08:57] <mzanetti> greyback: ping
[08:57] <mzanetti> greyback: https://code.launchpad.net/~dandrader/unity-api/splash/+merge/233288/comments/575802
[08:57] <mzanetti> shall we wait for daniel or throw the splash stuff out of the silo and try to get orientationlock landed alone?
[08:59] <greyback> mzanetti: I say wait.
[09:00] <mzanetti> ok
[09:10] <larsu> tsdgeos: hey
[09:10] <tsdgeos> larsu: commented on the bug, emblems was the wrong thing that is missing, is attributes icons
[09:11] <larsu> tsdgeos: okay thanks. I'll have a look
[10:17] <mzanetti> dandrader: good morning
[10:17] <mzanetti> dandrader: can you update this one please? https://code.launchpad.net/~dandrader/unity-api/splash/+merge/233288/comments/575802
[10:18] <dandrader> mzanetti, what should I exactly do?
[10:18] <mzanetti> dandrader: bump the changelog in unity-api
[10:19] <mzanetti> dandrader: and then update the version in unity8's debian/control to match that version
[10:19] <mzanetti> dandrader: example: https://code.launchpad.net/~mzanetti/unity-api/dashActive/+merge/235273
[10:19] <mzanetti> dandrader: https://code.launchpad.net/~mzanetti/unity8/async-dashcommunicator/+merge/235272
[10:20] <mzanetti> dandrader: https://code.launchpad.net/~unity-team/qtmir/fix-some-lifecycle-bugs/+merge/234087
[10:20] <mzanetti> so I guess you need to change the depends in the related qtmir branch too
[10:29] <dandrader> mzanetti, all done
[10:30] <mzanetti> dandrader: thanks
[11:09] <greyback_> dandrader: heya, about the qWarning/qCWarning
[11:10] <greyback_> there are some messages that I think should not be categorized, in case there's a filter in place that surpresses all categorized messages
[11:10] <dandrader> greyback_, I commented on the mp
[11:11] <dandrader> greyback_, you can suppress only the debug messages for instance. like "qtmir.*.debug=false"
[11:11] <greyback_> dandrader: sure, but what if we ship qtmir.*=false - which I think is reasonable to do
[11:11] <greyback_> since nearly all of our debug/warning output is informational at best
[11:12] <dandrader> greyback_, say I want to silence all qtmir messages, *including warnings*, because it's bitching about something I don't care right now as I'm working on some unity8 thingy. I wanna be able to do it
[11:13] <dandrader> greyback_, we are only losing flexibility by using qWarning instead of qCWarning
[11:13] <greyback_> dandrader: sadly I don't care about you that much :D I'm more concerned with a user's desktop, they tap an icon and nothing happens because the desktop file is missing - I want to be sure that message is printed somehow
[11:13] <dandrader> greyback_, we can do less with it
[11:14] <dandrader> greyback_, then don't silence qtmir warnings on the final configuration. or make it a critical message
[11:14] <dandrader> and don't silence critical messages :)
[11:15] <dandrader> greyback_, what if we have -DQT_NO_DEBUG and I want the user to know that a desktop file is missing?
[11:15] <greyback_> dandrader: I don't like it, it relies on the right configuration being set, which I think is too easy to get wrong. I think some messages should not be filterable
[11:15] <dandrader> greyback_, should we use std::cout for it then?
[11:15] <greyback_> dandrader: but we don't set that.
[11:15] <greyback_> we have control over the compile flags for our app
[11:16] <greyback_> we don't have control over the warning/debug config
[11:18] <greyback_> dandrader: shall we ask a third party? To give a deciding vote?
[11:19] <dandrader> greyback_, yeah. I don't think your reasoning for using qWarning instead of qCWarning makes sense
[11:20] <greyback_> dandrader: who would you like to nominate?
[11:20] <dandrader> mzanetti
[11:21] <greyback_> mzanetti: you have been chosen to enact a peace treaty between myself and dandrader!
[11:21] <greyback_> when you've 2 mins, let us know
[11:22] <facundobatista> Holas
[11:22] <greyback_> o/
[11:22] <mzanetti> :D
[11:22] <mzanetti> greyback_: shoot :D
[11:23] <greyback_> mzanetti: topic is qWarning versus qCWarning - and the Debug equivalents
[11:23] <greyback_> I tend to use qWarning for messages that I think are of interest to a final user - i.e. they are messages which cannot be filtered
[11:24] <greyback_> dandrader: want to state your case?
[11:25] <dandrader> A warning is a warning. The qC version of log messages (debug, warning and critical) give more flexibility as you can filter them by level and category
[11:26] <dandrader> whereas with the original versions you can either install a message handler (thus filtering only by level) or disable all of them (by adding -DQT_NO_DEBUG)
[11:27] <dandrader> if someone wants to override any log filtering then it should not use the logging system in the first place.
[11:27] <mzanetti> so Imo we want to see real warnings in the logs without messing around with filters...
[11:27] <mzanetti> so I guess if we have a default filter that allows some certain category
[11:27] <mzanetti> then I would probably align it for qCDebug
[11:28] <mzanetti> but really depends on the default installed filter I guess
[11:28] <mzanetti> there probably is value to still suppress those warnings if you want to debug something else...
[11:29] <dandrader> greyback_ wants to give a message to the *final user*. Is loggging the right medium for it?
[11:29] <greyback_> all I want is to be able to print stuff, and be reasonably certain it is actually printed (-DQT_NO_DEBUG and custom message handlers aside)
[11:29] <mzanetti> dandrader: I guess "final user" is QA in this case
[11:29] <mzanetti> if you ask QA to send you a log, what do you want to have in there without asking them fiddle with filters
[11:30]  * mzanetti still didn't fully understand the QMessageLogger filtering
[11:30] <mzanetti> looked a bit weird the one time I tried tbh
[11:31] <greyback_> I had planned to ship qtmir filtering everything, since nearly all the messages are informational. And just use unfiltered messages for things user would care about
[11:31] <mzanetti> sounds reasonable
[11:32] <mzanetti> well, either that, or defining a category that is (and stays) enabled
[11:32] <greyback_> if you create a category that is always enabled, then why bother making it a category at all?
[11:32] <dandrader> I tried to shutdown all the qtmir babbling and filtered out all of it. but the babbling continued, although on a lower volume, because random parts of its logging use the old qMessage instead of qCMessage. so the only way to shut it off was to -DQT_NO_DEBUG it, but that meant recompiling it all
[11:33] <greyback_> dandrader: random parts? Have you pastein, I'd like to see what comes out.
[11:33] <dandrader> but them I lost my own logging which I was interested into. So I had to resort to use plain printf () or std::cout ofr it
[11:33] <dandrader> for it
[11:34] <dandrader> greyback_, just grep for qDebug, qWarning etc in qtmir
[11:34] <mzanetti> well, we all agree that plain qDebug() should eventually be migrated to qCDebug
[11:35] <mzanetti> its really just about error cases in which you are interested always (99% of the cases)
[11:35] <greyback_> dandrader: well sure. But I was more interested in the realistic output
[11:35] <dandrader> greyback_, I even had a branch to change it all to qCStuff, but for some weird reason it made application_manager test crash on destruction :-/ so will have to get back to it latedr
[11:35] <greyback_> eww
[11:35] <greyback_> that's unexpected
[11:35] <greyback_> anyhoo
[11:36]  * greyback_ rests his case and awaits the right honourable judge mzanetti's verdict
[11:37] <mzanetti> if I have to judge something I guess I'm with Daniel :D better flexibility in the long run. a little more effort to make it clean now though
[11:37] <mzanetti> http://tinyurl.com/ldtjvmj
[11:37] <dandrader> aside from losing flexibility when using qWarning instead of qCWarning, we also end up with a heterogeneous logging
[11:38] <dandrader> oh, there should be a utf8 char with a judge's hammer
[11:38] <mzanetti> haha
[11:38] <mzanetti> true
[11:39]  * greyback_ files an appeal
[11:39] <mzanetti> popey: is there ^
[11:39] <mzanetti> ?
[11:39] <greyback_> j/k
[11:39] <mzanetti> I'm sure popey will figure something :D
[11:39] <greyback_> just wish I shouted OBJECTION at some stage
[11:39] <greyback_> always wanted to do that
[11:40] <dandrader> if someone decides to filter out all warnings it's because he does not to see any warning messages
[11:40] <mzanetti> :D
[11:40] <popey> hmm
[11:40] <dandrader> if you want to still print out your message even if the user disabled warnings, then your message should not be a warning
[11:41] <popey> (╯°□°)╯︵ ┻━┻
[11:41] <popey> we should print that
[11:41] <tsdgeos> Mirv: how is https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1371472 going?
[11:41] <mzanetti> :D
[11:43] <greyback_> dandrader: ok pushed
[11:43] <mzanetti> greyback_: now one for you: http://bazaar.launchpad.net/~macslow/unity-notifications/dont-filter-newline/revision/219 vs http://paste.ubuntu.com/8402690/
[11:44] <mzanetti> greyback_: first one fails with new tags (e.g. "div"). latter one fails with broken xml
[11:46] <greyback_> mzanetti: regexp to parse html is bad practice. Using the XML parser is better IMO
[11:46] <mzanetti> +1
[11:46] <mzanetti> however, it fails with this for example: "<b>So broken</i>"
[11:46] <mzanetti> greyback_: while the regexp actually does it right
[11:47] <greyback_> mzanetti: is broken input likely?
[11:47] <mzanetti> hmm... notifications
[11:47] <greyback_> if it's broken going in, why should we try fix it?
[11:47] <greyback_> crap goes in, crap comes out
[11:47] <mzanetti> I tend to agree...
[11:47] <dandrader> greyback_, thanks. your thoughts on these: https://code.launchpad.net/~gerboland/qtmir/desktopFileReader/+merge/235223/comments/575368 https://code.launchpad.net/~gerboland/qtmir/desktopFileReader/+merge/235223/comments/575362
[11:48] <greyback_> dandrader: second one I've addressed - I just removed the comments
[11:48] <greyback_> dandrader: first one is doing what it's supposed to do IMO - but message is categorized now
[11:49]  * greyback_ doesn't mind noisy tests
[11:50] <dandrader> greyback_, ok, will make a separate MP on that subject later. this review was contentious enough already
[11:50] <greyback_> dandrader: :D
[11:50] <greyback_> always good to have a third party to settle the wa
[11:50] <greyback_> +r
[11:52] <Mirv> tsdgeos: gonna add a landing for it now. should it go to rtm first?
[11:55] <Mirv> well there's zero silos available for either utopic or rtm
[11:58] <Mirv> I think utopic is frozen at the moment, so rtm first might be the way to go
[12:53] <kodiak11> OK giving Unity a shot (Ubuntu user since 4.10, XFCE user since sundown of Gnome 2.32...) -  Are silly gadgets like CPU utilization and thermal monitors coming to Unity at any point?
[13:11] <MacSlow> tedg, hey there...
[13:14] <tedg> MacSlow, Howdy!
[13:15] <MacSlow> tedg, I was wondering if you meant gnome-settings-daemon in you comment here... https://code.launchpad.net/~macslow/indicator-sound/synchronous-notification/+merge/229061/comments/575109
[13:16] <tedg> MacSlow, I think I meant unity-settings-deamon? I mean th g-s-d fork that we did.
[13:17] <tedg> seb128, Could probably help with the name ^
[13:17] <tedg> It's u-s-d, not sure what the U is :-)
[13:17] <seb128> tedg, name is correct
[13:17] <seb128> tedg, https://code.launchpad.net/unity-settings-daemon
[13:17] <tedg> MacSlow, seb128 is your hero! ^
[13:17] <tedg> :-)
[13:17] <MacSlow> tedg, just trying to figure out where to look for the notification-relevant code... and compare to see if there are potential issues or not for your described scenario
[13:18] <MacSlow> seb128, thx... now that you said it, it seems obvious :)
[13:19] <MacSlow> tedg, anyway I will look into it and provide my findings as feedback on the MP
[13:25] <mzanetti> seb128: hey, here's something for you: https://code.launchpad.net/~mzanetti/ubuntu-system-settings/update-reset-launcher/+merge/234309
[13:26] <seb128> mzanetti, they, thanks, adding to my review list
[13:26] <mzanetti> seb128: one note: the required change in unity-schemas did not make it to rtm yet
[13:26] <mzanetti> seb128: its released to proposed though
[13:26] <seb128> k
[13:29] <seb128> mzanetti, we don't publish the launcher config anymore for the greeter/lock screen benefits?
[13:29] <mzanetti> seb128: not atm, as we don't have split greeter anyways currently
[13:29] <mzanetti> seb128: that will come back, but the main config will stay dconf
[13:29] <seb128> mzanetti, "currently"
[13:29] <mzanetti> seb128: accountservice will be a read-only copy of the current state inside the user account
[13:30] <seb128> right, which means we should still write there no?
[13:30] <mzanetti> if you reset dconf, the user's launcher plugin will notice and sync over to AS
[13:30] <mzanetti> that's the plan at least
[13:31] <seb128> k
[13:35] <MacSlow> tedg, see https://code.launchpad.net/~macslow/indicator-sound/synchronous-notification/+merge/229061 and hopefully approve that MP if you're happy with it. Thanks in advance!
[13:37] <tedg> MacSlow, Okay, so notify-osd can handle the fact that they're two synchronous ones?
[13:37] <tedg> there are
[13:38] <MacSlow> tedg, yes... to notify-osd it just two sync. notifications coming in... and first come first served
[13:38] <tedg> MacSlow, K, cool.
[13:42] <MacSlow> tedg, btw... volume-notification from those branches at work here... https://www.youtube.com/watch?v=rwEYLXNaL0Q
[14:04] <dandrader> kodiak11, there's indicator-multiload
[14:06] <kodiak11> dandrader:  ah - cool - I see I need to add repos - I poked around but was a bit lost
[14:09] <MacSlow> mterry, could you take a look at (review)  https://code.launchpad.net/~macslow/unity-notifications/synchronous-notification/+merge/234476 when you have a free slot?
[14:10] <mterry> MacSlow, what is the value hint about?
[14:11] <MacSlow> mterry, it's a way to pass a 0-100 number to a notification in order to make it display a indicator-bar (think: volume, brightness etc)
[14:11] <mterry> MacSlow, I'll look at it today, sure
[14:12] <mterry> MacSlow, it doesn't need a x-canonical prefix?
[14:12] <MacSlow> mterry, great thanks... it's one of three related branches... but I don't want to dump all three on one person... they can be dealt with on an individual basis
[14:13] <MacSlow> mterry, that has legacy-reasons
[14:14] <MacSlow> mterry, if the hint-name would be changed it would break existing apps using synchronous notifications with attached values.
[14:15] <mterry> MacSlow, ah ok, this is an old hint
[14:15] <MacSlow> mterry, correct
[14:18] <MacSlow> mterry, fyi... this is what it looks like when all three related branches are at work... https://www.youtube.com/watch?v=mi-Z2Rn7Fxo
[14:19] <mterry> MacSlow, nice
[14:20] <kodiak11> dandrader:  I found this and thought it was useful - thanks for the lead!  http://askubuntu.com/questions/30334/what-application-indicators-are-available
[14:21] <dandrader> kodiak11, yw
[14:24] <mhall119> saviq and thostr still on holiday?
[14:30] <dandrader> greyback_, a tiny one: https://code.launchpad.net/~dandrader/qtmir/optionalTestsBuild/+merge/235467
[14:31] <greyback_> mhall119: saviq is anyway
[14:43] <cwayne> Cimi: any chance of that card-visual-tweaks branch landing this week?
[14:44] <dandrader> greyback_, thanks for the quick review!
[14:44] <greyback_> dandrader: does the job :)
[14:46] <greyback_> mzanetti: when you get time, I left comment here: https://code.launchpad.net/~mzanetti/unity8/async-dashcommunicator/+merge/235272
[14:46] <mzanetti> greyback_: I have to keep the dep to AppManager
[14:46] <mzanetti> hmm... maybe not
[14:46] <greyback_> mzanetti: why>
[14:47] <mzanetti> but seems fragile
[14:47] <mzanetti> greyback_: because if I connect to the interface when the app is suspended, it'll hang unity
[14:47] <mzanetti> greyback_: so I use AppMan to make sure it is in state running
[14:47] <greyback_> mzanetti: it should not hang with an async dbus call
[14:47] <mzanetti> greyback_: no, but the connect
[14:48] <greyback_> hmm
[14:48] <greyback_> lemme try something
[14:48] <mzanetti> ack
[14:50] <tsdgeos> mhall119: anything we can help you with while Saviq is enjoying his holidays?
[15:36] <tsdgeos> mterry: what can we do about https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1372515 ?
[15:37] <mterry> tsdgeos, hrm
[15:37] <mterry> tsdgeos, make it smaller seems least intrusive -- I don't want to drop the whole pad down to fit a second line
[15:37] <mterry> tsdgeos, or have translators test their translations and get creative to let them fit...  but we can at least try a technical solution first
[15:39] <tsdgeos> mterry: you're not going to get translators to test the translations
[15:39] <mterry> tsdgeos, :)
[15:39] <tsdgeos> you have to be god to be were a string is
[15:39] <mterry> tsdgeos, I know, they just do it in LP
[15:39] <tsdgeos> and even if they wanted
[15:39] <mterry> tsdgeos, true
[15:39] <tsdgeos> unless you know how to code and check the code and try to infer where the string is ending
[15:39] <tsdgeos> sometimes is a huge amount of work
[15:39] <tsdgeos> not in this case, but
[15:40] <tsdgeos> mterry: i think having that "shrink my size label" in the SDK would be a great idea actually
[15:40] <tsdgeos> for cases where not much can be done
[15:40] <tsdgeos> and you don't really mind if it's 17px or 15px font size
[15:41] <mterry> tsdgeos, yeah... I'm not sure what font metrics info we have available to us to do that in qml, but I'm sure it's possible
[15:41] <tsdgeos> mterry: we have the implicitWidth
[15:41] <tsdgeos> oyu can try playing with it
[15:42] <mterry> tsdgeos, yeah but I don't want to have to set the size, test width, change size, etc.  We'd want to assign size once based on the metrics of the string and width available, right?
[15:42] <tsdgeos> mterry: yeap, i am not sure there's something like that available
[15:43] <mterry> :-/
[15:43] <tsdgeos> tbh i have some code that does that in kde
[15:43] <mterry> tsdgeos, maybe we can change size fast enough that it doesn't matter -- or just keep the label invisible until we settle
[15:43] <tsdgeos> and it actually ends up setting sizes and chaging
[15:43] <tsdgeos> since fonts are not linear
[15:43] <tsdgeos> in point size vs size
[15:43] <tsdgeos> it seems to be the only way to do it
[15:46] <tsdgeos> man qmluitests have gone all crazy :S
[16:15]  * greyback_ annoyed unity8-autopilot brings in lots of qt4
[18:00]  * greyback_ eod
[18:04] <kodiak11> Is there a quick guide on customizing / making the most use of Unity for new users to Unity but obviously not to Linux
[18:04] <kodiak11> Coming from the XFCE world and attempting to give Unity a fair shake
[18:14] <dandrader> kodiak11, #ubuntu-desktop is the appropriate channel for that. Here we essentially talk about Unity for phone an tablet
[18:15] <dandrader> until that new codebase also comes to encompass the desktop as well
[18:15] <kodiak11> oh snap
[18:16] <kodiak11> when are you giving me a dang phone???  (US Verizon customer_)
[18:36] <racarr> Hi guys my new hobby is https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1328839
[18:36] <racarr> so first I am trying to figure out, how a Qt app is supposed to escape this fullscreen state...and it seems like
[18:36] <racarr> platform api is missing a counterpart to
[18:36] <racarr> ua_ui_window_request_fullscreen
[18:36] <racarr> e.g. there is no ua_ui_window_leave_fullscreen or ua_ui_window_show_normal or whatever
[18:37] <racarr> does anyone know otherwise, or know how an app is supposed to leave
[18:37] <racarr> fullscreen
[19:48] <yecril71pl> Hello, can I have a non-breaking space under [Shift [Space]]?
[19:51] <yecril71pl1> Can I have a non-breaking space under [Shift [Space]]?