[00:48] <xclaesse> I wrote a simple .desktop file that I've put in ~/.local/share/applications but unity's dash does not find it
[00:48] <xclaesse> why?
[00:51] <RAOF> xclaesse: Anything special about the .desktop file? The various Steam .desktops in ~/.local/share/applications work for me.
[01:06] <xclaesse> RAOF, nothing special, I just want to launch my python script from unity's launchers
[01:07] <RAOF> You could always try logging out and back in again. Presumably unity watches that path, but maybe reloading the scopes will fix it
[01:07] <RAOF> ?
[01:17] <xclaesse> RAOF, ah I understand
[01:18] <xclaesse> it does not accept if the exec binary is in ~/.local/bin
[01:18] <RAOF> Is ~/.local/bin in your path?
[01:21] <xclaesse> RAOF, I set the path in my .bashrc for that
[01:21] <xclaesse> it's probably not in unity's path
[01:21] <xclaesse> ok, setting the full path to the python script and it works
[01:21] <xclaesse> would be nice to have it relative though
[01:23] <sarnold> did you try to use "bar" or ".local/bin/bar" or "~/.local/bin/bar" or "/home/foo/.local/bin/bar" ?
[01:30] <xclaesse> sarnold, ah ".local/bin/bar" works
[01:31] <xclaesse> cool :)
[01:31] <xclaesse> ok, next step: add an action in the context menu
[08:45] <seb128> good morning desktopers!
[09:04] <Laney> morning!
[09:08] <seb128> Laney, good morning, how are you?
[09:08] <Laney> seb128: alright thanks, although I think my arm got bruised when I gave blood last night
[09:08] <Laney> so that hurts a bit
[09:08] <Laney> you?
[09:10] <seb128> I'm good thanks!
[09:15] <RAOF> pitti: Good morning!
[09:16] <pitti> hey RAOF, how are you?
[09:16] <RAOF> pitti: You've got a merge request and a bug for umockdev awaiting you :)
[09:16] <pitti> RAOF: thanks for your umockdev fixes
[09:16] <pitti> RAOF: no, I don't :)
[09:16] <RAOF> :)
[09:16] <pitti> RAOF: it's all in 0.4.7, I uploaded that to Debian and it'll autosync in a few hours
[09:16] <RAOF> Bitchn.
[09:17] <RAOF> So, by the time I'm ready to propose this Mir branch, the valgrind tests should not fail in umockdev :)
[09:19] <Laney> robru: Was using sbuild
[09:28] <seb128> didrocks, btw on fully updated trusty I can still tap "alt" in g-c-c
[09:28] <seb128> works in a guest session as well
[09:28] <didrocks> seb128: hum, let me try today
[09:28] <seb128> not sure what's the difference between our systems
[09:28] <didrocks> still not working and update today
[09:29] <didrocks> yeah, as Laney confirms, I'm wondering
[09:29] <didrocks> I'll try a guest later
[09:29] <seb128> needs debugging by somebody having the issue
[09:29] <seb128> hint hint hint ;-)
[09:29] <didrocks> heh, I'll have a look
[09:47] <seb128> mhr3, hey
[09:48] <seb128> mhr3, just as a FYI, the gvfsd-http leaks/non closing fds issues should be fixed in trusty, I would appreciate if you could verify/confirm during the cycle
[09:49] <seb128> larsu, hey
[09:49] <seb128> larsu, how is GTK 3.10 going?
[09:49] <seb128> larsu, still working on it/on what specific issues?
[09:52] <larsu> seb128: yes. I have a hard time figuring the update-manager list view issue out
[09:53] <seb128> larsu, that doesn't seem a blocker ... maybe we could just upstream that one?
[09:53] <seb128> larsu, and gently ping mclasen/Company saying it's a blocker to get the update in Ubuntu
[09:54] <seb128> well, not a blocker for the ppa I mean
[09:54] <larsu> maybe it's this one: https://bugzilla.gnome.org/show_bug.cgi?id=712220
[09:54] <ubot2> Gnome bug 712220 in GtkScrolledWindow "GtkScrolledWindow has incorrect minimal size" [Normal,Unconfirmed]
[09:54] <seb128> larsu, did you notice that it takes the correct space if you expend the details t the bottom?
[09:54] <larsu> ya
[09:54] <larsu> which is the weirdest part :-/
[09:55] <larsu> seb128: okay, let me push that back. Then I'd only consider the scrollbar theme thing to be a blocker
[09:56] <seb128> larsu, right, I was going to say the same
[09:56] <larsu> I assume this is something that needs to be fixed in the theme though
[09:56] <larsu> I'll investigate :)
[09:58] <seb128> larsu, I would assume it's something to be fix in GTK/o-s code
[09:58] <seb128> but let's see
[09:58] <larsu> o-s ?
[09:58] <seb128> overlay-scrollbars
[09:58] <larsu> ah :)
[09:59] <mhr3> seb128, cool, got a link to a bgo bug?
[10:00] <seb128> mhr3, https://bugzilla.gnome.org/show_bug.cgi?id=706225#c7
[10:00] <ubot2> Gnome bug 706225 in general "gvfsd-http crashed with signal 5 in g_cancellable_make_pollfd()" [Major,Resolved: duplicate]
[10:01] <seb128> mhr3, https://bugzilla.gnome.org/show_bug.cgi?id=695652#c44
[10:01] <ubot2> Gnome bug 695652 in HTTP Transport "Indefinite hang in run_sync_state_machine() on close()" [Normal,Resolved: fixed]
[10:01] <seb128> mhr3, I've commented on that second bug to see if we can get some of the fixes cherrypicked in the serie used in saucy
[10:01] <seb128> so we can SRU
[10:02] <seb128> mhr3, the commit Dan backported to fc19 seems to be https://git.gnome.org/browse/libsoup/commit/?id=96da2df64c9dd8cc52e97ce73e54615d6b520664
[10:22] <seb128> larsu, do you need help on GTK for anything? Like do you want me to spend some time to see if I can get a small testcase example of the update-manager issue?
[10:25] <larsu> seb128: I've already found one: the test case in overlay-scrollbar
[10:25] <larsu> convergence!
[10:25] <seb128> lol
[10:26] <seb128> Laney, so new webkitgtk isn't happy on arm64 :/
[10:26] <seb128> ../Source/WTF/wtf/dtoa/utils.h:64:2: error: #error Target architecture was not detected as supported by Double-Conversion.
[10:27] <seb128> Laney, it also made powerpc unhappy
[10:29] <Laney> seb128: yeah, checking it
[10:29] <Laney> I see the arm64 fix I think
[10:29] <Laney> ppc test building on partch
[10:29] <Laney> probably a missing #if somewhere
[10:32] <seb128> mhr3, don't run away like that :p
[10:32] <seb128> mhr3, did you get my reply?
[10:32] <mhr3> seb128, saw the commit link as last thing
[10:32] <mhr3> my internet died :/
[10:32] <seb128> mhr3, ok, so you got it all, 2 bugs and 1 commit
[10:32] <mhr3> using phone data now
[10:33] <mhr3> seb128, when is that going to work with ubuntu phones btw? :)
[10:33] <seb128> what? sharing datas?
[10:33] <mhr3> yep, usb tethering
[10:33] <mhr3> or wifi
[10:34] <mhr3> or bluetooth :)
[10:34] <seb128> mhr3, don't seem to be on the els prd list, so maybe not this cycle :/
[10:34] <mhr3> strangely sharing my phone's wifi over usb is my most used feature on android
[10:35] <mhr3> mostly caused bcm wifi sucks so bad
[10:37] <mhr3> seb128, anyway, i'm not sure whether it's the same issue, the bug is mentioning something that got broken and is now fixed
[10:37] <mhr3> afaik the fd leaking has been there since at least 12.10
[10:38] <seb128> mhr3, well, Ross it's easy to reproduce the issue, so should be easy to test on trusty?
[10:40] <mhr3> seb128, well, it should be easy to see on errors.ubuntu.com :)
[10:40] <mhr3> last time i checked that bug was high on the list
[10:41] <seb128> mhr3, yeah, it's first or second on gvfs issues for saucy, which is what made me comment upstream/ping about it yesterday
[10:41] <seb128> mhr3, I'm trying to work a bit on the e.u.c list every day
[10:42] <mhr3> seb128, great, it's an awesome source of data
[10:42] <mhr3> makes bug prioritization a walk in park :)
[10:54] <seb128> hum
[10:54] <seb128> I don't trust lightdm on trusty anymore, I swear it's doing weird stuff on user switches sometimes
[10:54] <seb128> I just had my session closed when logging out of a guest session
[10:57] <seb128> mhr3, is that normal that dash filters change (e.g new category got added) during the session?
[11:01] <mhr3> seb128, yes
[11:01] <seb128> mhr3, that's weird :p
[11:01] <mhr3> seb128, well, categories should be stable, sources will get added
[11:02] <seb128> mhr3, I've "news" added to the categories
[11:02] <seb128> e.g if I do
[11:02] <seb128> - log into a guest session
[11:02] <seb128> - open the dash
[11:02] <seb128> - look at filters
[11:02] <seb128> it starts with "aide" (help)
[11:02] <mhr3> oh right
[11:02] <seb128> - type something in the search entry, clean it
[11:03] <seb128> -> "actualité" (news) is added to the categories
[11:03] <mhr3> if a category has 0 sources it's not displayed, and since later a source is added, it becomes visible
[11:03] <seb128> ok, I see
[11:03] <seb128> that's a bit weird since it changes the layouting of the filters
[11:03] <seb128> thanks
[11:04]  * seb128 also noticed that turning the online data makes the dash snappy to return results again and is pondering to just do that
[11:04] <mhr3> seb128, but if it was there all the time it'd be even worse (returning no results ever)
[11:06] <seb128> shrug
[11:07] <seb128> mhr3, so I set 'remote-content-search' to 'none' ... I did a query "pdf", which listed me some pdf I opened recently (great)
[11:07] <seb128> mhr3, now I open the dash again, type "pdf" and it lists no file, the "files" filter is off (I didn't change), dispite having 'files.scopes' in the 'always-search' gsettings
[11:08] <mhr3> sounds like a bug
[11:08] <seb128> mhr3, do you think it's the same issue than the one from yesterday?
[11:08] <mhr3> might very well be
[11:08] <seb128> :/
[11:08] <mhr3> seb128, can you get bustle log for that?
[11:09] <mhr3> and attach it to the bug you opened
[11:09] <seb128> mhr3, oh, it works if I see the "remote-content-search' back to 'all'
[11:09] <seb128> mhr3, can you reproduce if you change the key to none?
[11:09]  * mhr3 tries
[11:12] <mhr3> seb128, nope
[11:12] <seb128> :-(
[11:12] <mhr3> anyway, the bustle log should help
[11:13] <mhr3> just try to describe very precisely what you did and what you saw
[11:13] <mhr3> there'll be a mismatch somewhere
[11:13] <mhr3> seb128, perhaps even record a video while capturing the log
[11:14] <seb128> mhr3, is that going to "leak" all my dash content? not sure I want to put all my filenames online :p
[11:14] <mhr3> seb128, mark it private then
[11:33] <seb128> larsu, I keep (ab)using your merge request to discuss GTK 3.10 issues, let me know if you prefer moving to a bug? (e.g should we rather use https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1171587)
[11:33] <ubot2> Launchpad bug 1171587 in gtk+3.0 (Ubuntu) "update to GTK 3.9 and the issues to resolve for it" [Wishlist,Confirmed]
[11:33] <seb128> in fact that would make sense, let me comment on that bug ;-)
[11:37] <larsu> seb128:  I don't mind either way
[11:37]  * larsu is bisecting the o-s issue
[11:37] <larsu> I hate o-s
[11:40]  * seb128 hugs larsu
[11:41] <Laney> talk to desrt about that
[11:41] <seb128> you can always try to ping that italian guy who wrote it :p
[11:41] <seb128> but I bet the reply is going to be "it was working, it's a bug in GTK"
[11:42] <larsu> I'm sure he'll be happy about that :)
[11:42] <seb128> to his defence that's what happened with GTK 3.8 and he was right :p
[11:42] <larsu> seems like the same here
[11:42] <seb128> the bug that make o-s buggy by then was an annoying one in GTK which impacted on other apps as well
[11:43] <larsu> 7 steps left. If only gtk built faster :)
[11:48] <pitti> -j8 FTW!
[11:48] <pitti> (and build in tmpfs)
[11:48] <seb128> larsu, just doing git bisect&make ought to not be that slow
[11:49] <larsu> seb128: slow enough to annoy me :)
[11:50]  * larsu is not a very patient person
[12:30] <seb128> bregma, hey, could you get somebody assigned to https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1047517? that's the most reported unity issue on e.u.c/saucy
[12:30] <ubot2> Launchpad bug 1047517 in unity (Ubuntu) "compiz crashed with SIGSEGV in g_mount_spec_to_dbus_with_path() ... from unity::IconLoader::Impl::IconLoaderTask::LoaderJobFunc()" [High,Confirmed]
[12:31] <bregma> seb128, we'll discuss it today
[12:31] <seb128> bregma, thanks
[12:51] <seb128> mhr3, I've added bustle and video on https://bugs.launchpad.net/ubuntu/+source/unity-scope-home/+bug/1223933 ... let me know if you need more info or if you prefer a new bug since that's not strictly the same issue
[12:51] <ubot2> Launchpad bug 1223933 in libunity "sometimes the dash home list "no result matching your query" string" [Undecided,Triaged]
[12:52] <mhr3> seb128, thx
[12:56] <mhr3> seb128, hm, it doesn't even try to search files
[12:57] <mhr3> pstolowski, the log is odd ^^
[12:58] <mhr3> pstolowski, home scope sends query to apps scope, and then the same query to the scopes scope (even though that's supposed to be apps child)
[12:59] <pstolowski> mhr3, oh, if it's the case then it's indeed odd, looking
[13:00] <mhr3> oh wait
[13:00] <mhr3> nevermind
[13:00] <mhr3> it's the apps master querying its children
[13:02] <mhr3> pstolowski, nonetheless, later it doesn't send the query to files (which is in always-search according to seb)
[13:02] <mhr3> later == when there's an actual search string
[13:02] <mhr3> seb128, btw is the files scope running?
[13:02] <mhr3> pgrep unity-files-daemon?
[13:02] <seb128> mhr3, I guess so, the file lens is working
[13:03] <mhr3> hm, interesting
[13:03] <seb128> yeah, it's running
[13:04] <pstolowski> seb128, but judging from your description, gsettings get com.canonical.Unity.Lenses home-lens-default-view doesn't show files.scope now?
[13:05] <seb128> pstolowski,
[13:05] <seb128> ['help.scope', 'help-askubuntu.scope', 'help-texdoc.scope', 'help-yelp.scope', 'news.scope', 'news-googlenews.scope', 'news-yahoostock.scope', 'applications.scope', 'applications-applications.scope', 'applications-scopes.scope']
[13:05] <seb128> which matches the filters showed active on the ui
[13:06] <seb128> is it supposed to use the "always-search" ones as well? (that has apps/music/video/files)
[13:06] <pstolowski> seb128, right, and you never de-selected files in previous searches?
[13:06] <seb128> no
[13:06] <pstolowski> ah wait, it's not surfacing
[13:07] <pstolowski> so right, always-search should be used
[13:13] <mhr3> seb128, just to make sure, can you paste the value of always-search as well?
[13:16] <seb128> mhr3, http://paste.ubuntu.com/6415785/
[13:17] <mhr3> great, thx
[13:17] <seb128> yw
[13:17] <pstolowski> seb128, and is this now reproducible on every search?
[13:17] <seb128> pstolowski, yes, it's stucked in that buggy situation
[13:18] <seb128> I've not tried to manually click on filters or restart processes though
[13:18] <seb128> in case you guys need more debug infos
[13:18] <seb128> but it's not going away by using the dash or typing stuff in the entry
[13:19] <pstolowski> seb128, mhr3 ok, I suspect filter state handler in home scope got confused, grr
[13:28] <pstolowski> seb128, i'll look at this, probably next week
[13:29] <seb128> pstolowski, ok, let me know if you need more debug infos/want me to build a special versions with extra prints for example
[13:29] <Sweetshark> seb128: So I checked the libs that LO brings its own copies, for the debian sync and MIR dance. libodfgen needs 0.0.3 which is not in debian exp. yet, libmwaw is uptodate in universe/just needs MIR, libmdds is outdated in universe, needs a sync of 0.9.1 from in debian experimental, libcmis needs 0.4.1 which is not in experimental yet. libenotyek and libfreehand are new with 4.2 -> lets postpone those.
[13:29] <seb128> I wonder if my config is special in any regards
[13:30] <seb128> Sweetshark, ok, should we do the libmdds sync?
[13:32] <Sweetshark> seb128: yep, would be one thing of the list.
[13:33] <Sweetshark> so on big bertha doing a release build of LibreOffice takes 30min. Building a package takes 106min. as xz compression of the result takes ages :/
[13:36] <pstolowski> seb128, what would definitely help is if you run home scope with HOME_SCOPE_VERBOSE=1 env var set; and capture all the output from start till when the problem shows up (there will be lots of output, so just 2>&1 to a logfile)
[13:37] <seb128> pstolowski, ok, I can do that
[13:37] <pstolowski> seb128, so just kill home-scope and re-run it from a terminal
[13:43] <seb128> pstolowski|lunch, mhr3: it's trivial to reproduce here
[13:44] <mhr3> seb128, good, you'll be asked to send your laptop to poland then ;)
[13:45] <seb128> mhr3, pstolowski|lunch: I wonder if that's a locale stuff, I restarted the home scope with the debug env, I typed "pdf" and I had files, then I did "esc" ... the filters changes with "actualité" ("news" in french) added as the first category and files&folders got unselected at the same time
[13:45] <seb128> mhr3, pstolowski|lunch: http://ubuntuone.com/3tC2suxeWymsYaBbFkjGhf is the log
[13:46] <seb128> see l1337
[13:46] <seb128> is that normal that this query is only apps scope?
[13:47] <seb128> l1321: 13:43:07.936785Z unity-scope-home: search-util.vala:180: Setting sources filter files-gdrive.scope: false
[13:48] <seb128> l1318 I mean
[13:48] <seb128> the files-local.scope is set to false
[13:56] <Sweetshark> s/of/off/
[14:32] <pstolowski> seb128, no, it got confused after esc. thanks for the log, I think I have all the needed info
[14:34] <seb128> pstolowski, great, yw
[14:35] <desrt> good morning
[14:35] <desrt> let's drop overlay-scrollbars
[14:38] <desrt> larsu tells me i get free steak if this happens... so... soon, please?
[14:39] <larsu> desrt: only of you had verifiable influence on that decision ;)
[14:40] <desrt> larsu: butterfly effect, dude
[14:40] <larsu> heh
[14:40] <larsu> not really verifiable
[14:40] <ogra_> given you dont have wings, how do you do that ?
[14:41] <ogra_> fart and it will change eventually ?
[14:42] <seb128> desrt, good morning
[14:43] <desrt> seb128: hey.  i'd be happy if you could now say "we will get rid of them, but only because desrt asked so nicely"
[14:43] <seb128> desrt, let's not start trolling, new GTK is making me less happy by the day, I could start ranting soon :p
[14:43]  * seb128 just opened https://bugzilla.gnome.org/show_bug.cgi?id=712302
[14:43] <ubot2> Gnome bug 712302 in GtkFileChooser "GtkPlacesSideBar showing "Desktop" or not shouldn't be a by-application setting" [Normal,Unconfirmed]
[14:43] <seb128> wth GNOME
[14:43] <desrt> oh.  this is fun :)
[14:43] <larsu> uh oh. I guess I should stop ranting then...
[14:44] <desrt> seb128: if i fix this bug, will you let larsu drop overlay-scrollbars? :)
[14:44] <seb128> they made the default to be "don't show a desktop, because GNOME3 doesn't have one"
[14:44] <seb128> and the solution is to patch every app
[14:44] <ogra_> just use QtFilechooser ;)
[14:45] <desrt> seb128: i guess you want XSETTINGS stuff here
[14:45] <seb128> desrt, no dropping of anything
[14:45] <seb128> desrt, yeah, but isn't xsettings being killed because it doesn't work in wayland?
[14:45] <larsu> desrt: why not a gsetting? The file chooser already has a schema (and federico said so in that commit)
[14:45] <seb128> larsu, because schemas are not by desktop
[14:46] <seb128> larsu, e.g a xfce user wants that item, an Unity user wants it, a GNOME3 doesn't
[14:46] <larsu> argh, right
[14:46] <desrt> well.... in fairness, it sort of makes sense to bind this to the "icons on desktop" setting that already exists
[14:46] <desrt> if the user turns off viewing their desktop then that should be the indication not to show it in the chooser
[14:46] <desrt> regardless of environment
[14:47] <larsu> good idea, but this is a nautilus setting, no?
[14:47] <desrt> no
[14:47] <seb128> I was going to say
[14:47] <desrt> i think it's in org.gnome.desktop.interface
[14:47] <desrt> org.gnome.desktop.background show-desktop-icons false
[14:47]  * desrt was close
[14:48] <larsu> is that installed on an xfce desktop?
[14:49] <seb128> no
[14:49] <seb128> neither on win32
[14:49] <seb128> nor macOS
[14:49]  * desrt already raised this point in the bug
[14:49] <larsu> we need an equivalent to shell-shows-menubar
[14:49] <desrt> adding XSETTINGS back to gtk seems to be popular these days....
[14:53] <kenvandine> dobey, my wife is angry with you!  :-p
[14:53] <kenvandine> she couldn't figure out how to buy music anymore... she's on precise
[14:57] <seb128> larsu, kenvandine, charles, tedg, Laney, let's skip the settings meeting, I don't think anyone worked on this week (I didn't see any activity and CI is down), seems everybody is busy catching up with other topics/start of cycle work
[14:57] <seb128> cyphermox, attente, didrocks: ^
[14:57] <charles> seb128, ack
[14:58] <cyphermox> ok
[14:58] <attente> sure
[14:58] <cyphermox> seb128: btw, looking at wpa...
[14:58] <seb128> cyphermox, hey! oh, thanks ;-)
[14:59] <kenvandine> +1
[15:00] <cyphermox> seb128: it's that bug that failed to retrace everywhere in all cases
[15:00] <cyphermox> something broke maybe in libnl
[15:13] <desrt> seb128: be happy.  this problem will be solved by end of day.
[15:14] <seb128> desrt, thanks a lot for dealing with it!
[15:14] <desrt> seb128: so... about those overlay-scrollbars.....
[15:14] <desrt> ;)
[15:15] <seb128> desrt, *lalalalala*
[15:15] <seb128> ;-)
[15:16] <desrt> geesh.  you do a nice thing, and this is what happens
[15:16] <desrt> seb128: *the keg* is on the line here
[15:16] <desrt> seb128: in fairness, probably larsu would treat you as well...
[15:16]  * larsu confirms
[15:16] <seb128> you don't want me to get fired, do you? ;-)
[15:17] <desrt> 'accepting bribes'
[15:20] <mdeslaur> I think getting rid of scrollbars entirely is more sane than getting rid of overlay-scrollbars :P
[15:21] <larsu> mdeslaur: and how do you show how far along a document you are?
[15:21] <seb128> larsu, mdeslaur: let's stop trolling, friday is tomorrow :p
[15:21] <mdeslaur> larsu: oh, you leave the indication there, you just don't pop anything up over it :P
[15:21] <seb128> larsu, btw I just tested on raring, seems to be that the thumb behaves/looks the same way
[15:22] <seb128> larsu, the orange portion was not animated, it was just always there to show the position
[15:22]  * mdeslaur suspends further trolling until tomorrow
[15:22] <larsu> mdeslaur: ah, that would have been part of the "scrollbar" term for me. I totally agree then
[15:22] <larsu> seb128: cool. Thank you. I guess I misremembered
[15:24] <larsu> seb128: this is what I meant: http://vimeo.com/30210146
[15:28] <seb128> larsu, is that the orange/grey line and the way it's displayed/fading away?
[15:28] <larsu> seb128: yes, the gray one is missing for me when using 3.8
[15:35] <seb128> larsu, work in a saucy vm (sorry got sidetracked while the vm was loading)
[15:36] <seb128> larsu, let me downgrade gtk on trusty and see
[15:43] <seb128> larsu, I'm testing with "nautilus /usr/share", works fine on trusty with the trusty GTK (you just need to aim close from the border and slowly)
[15:44] <larsu> seb128: do you get the gray bar as well?
[15:46] <seb128> larsu, yes
[15:46] <larsu> meh :/
[15:46] <larsu> seb128: thanks for testing that,
[15:48] <seb128> larsu, http://ubuntuone.com/5VrE9JH4FuK1VIMIZrSvxG
[15:48] <seb128> larsu, that's trusty with the trusty gtk version
[15:49] <larsu> seb128: weirdly enough, I don't get that with upstream gtk 3.8. Might be one of our patches.
[15:54] <seb128> larsu, I don't really see which patch in our stack could make a difference there :/
[15:55] <larsu> me neither. I'll find out after I get the trough visible at all
[15:55] <seb128> larsu, what application are you testing with?
[15:56] <larsu> seb128: the tester inside of overlay-scrollbars source tree
[15:56] <larsu> tests/test-os
[16:00] <seb128> larsu, that test app is weird/buggy
[16:00] <larsu> how so?
[16:00] <seb128> larsu, http://ubuntuone.com/4fHJW2VMDIXLYhQDoGxlMN
[16:01] <seb128> is that how it looks like for you?
[16:01] <larsu> ya, it seems to be the bug that we also see in update-manager
[16:01] <larsu> I patched the tester :)
[16:01] <seb128> larsu, that screenshot is using GTK 3.8...
[16:02] <seb128> how did you patch it ?
[16:02] <larsu> then it's definitely not the same bug :D
[16:02] <larsu> http://paste.debian.net/65856/
[16:02] <larsu> I made it so that there's only one listview
[16:02] <larsu> good enough for testing
[16:03] <seb128> larsu, ok, I do get the grey bar/animation on that as well
[16:03] <seb128> just wanted to rule out the test to be buggy
[16:03] <seb128> I'm going to let you debug then, let me know if I can help for anything else
[16:03] <larsu> yep. Thanks a lot for testing!
[16:05] <seb128> yw!
[16:24] <happyaron> seb128: I did some analysis on bug 1221593 (my last comment), and can only pick up it again next week cuz I'm at Changsha for the meeting from today to the weekend.
[16:24] <ubot2> Launchpad bug 1221593 in ibus (Ubuntu) "ibus-ui-gtk3 crashed with SIGABRT in _g_log_abort()" [High,Triaged] https://launchpad.net/bugs/1221593
[16:25] <seb128> happyaron, hey, thanks ... is the issue fixed in 1.5.4?
[16:26] <pitti> mterry: so the icon theme uninstallability is fixed, now https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-deja-dup/14/? failed with a test failure; would you mind having a look?
[16:26] <seb128> happyaron, I wonder if the error is worth asserting on, what would happen if we only g_warning there? would it pick the config once the daemon writes it?
[16:27] <happyaron> seb128: I haven't tested the latest patchset ofr 1.5.4, anyway it's not fully a part of the released version of ibus, but need some patch that fujiwara apply to F19.
[16:27] <happyaron> seb128: not tested yet, but that's worth to try.
[16:28] <seb128> happyaron, why is fujiwara not upstream those changes? do they still have them in f20?
[16:29] <happyaron> seb128: fujiwara cannot commit those changes directly, need code review from phuang (original author of ibus). So all the distros are carrying fujiwara's patches for certain features/fixes.
[16:30] <happyaron> it's more obvious since gnome decides to do the integration.
[16:30] <seb128> happyaron, is that because phuang is not active for reviews?
[16:30] <seb128> k
[16:30] <seb128> happyaron, thanks for the update
[16:30] <happyaron> seb128: he's active, but not that interested on those kindia integrations.
[16:30] <happyaron> he cares more about the framework
[16:30] <seb128> ok
[16:31] <seb128> happyaron, can you check, next week, what happens if we just return in that function instead of asserting?
[16:31] <happyaron> seb128: sure
[16:31] <seb128> happyaron, that might be good enough as a solution
[16:31] <seb128> happyaron, thanks
[16:32] <happyaron> with pleasure
[16:34]  * seb128 shakes the fist to lightdm in trusty
[16:57] <desrt> seb128: got patches up for the GtkPlacesSidebar issue
[16:57] <desrt> testing appreciated
[16:57] <seb128> desrt, excellent, thanks
[16:57] <desrt> (they seem to work in my jhbuild)
[16:57] <seb128> desrt, I was about to go for some exercice but I do that next once I'm back
[16:57] <desrt> cool
[16:58] <desrt> looks like they'll go upstream pretty quickly so i don't know if there is much value in patching them in our packages except for local testing
[17:12] <pitti> desrt: hey, how are you?
[17:12] <desrt> good.
[17:12]  * desrt is doing job #1 today
[17:12] <pitti> desrt: I pushed an updated patch to -shim, FYI
[17:13] <desrt> oh.  great.
[17:13] <pitti> desrt: oh, what's that?
[17:13]  * desrt checked last night, didn't see it
[17:13] <desrt> pitti: making seb happy
[17:13] <pitti> "watch latest BBT episode"?
[17:13] <pitti> ooh
[17:13] <pitti> desrt: no, did it this moring
[17:13] <pitti> morning, too
[17:13] <pitti> some 11 hours ago
[17:14] <pitti> desrt: if you are happy with it, could we just do a version 5?
[17:14]  * desrt would have preferred a chance to review it
[17:14] <desrt> although i suppose that's inconsistent with my previous hopes of passing off maintainership to you :)
[17:14] <pitti> desrt: ah, I thought you were content with our discussion how to do it yesterday
[17:15] <pitti> desrt: but it's not yet released or uploaded or anything
[17:15] <pitti> desrt: it's git, so we can change it :)
[17:15] <desrt> pitti: i'm pretty strong into the "no non-trivial commits without code review" mindset these days
[17:15] <pitti> desrt: ok, noted for the future
[17:15] <pitti> desrt: (good thing!)
[17:15] <desrt> looks more or less fine, though... i'd only have minor tweaks to it
[17:15] <pitti> I should try that with my projects too, I just find it hard to find someone who wants to bother with reading apport or umockdev patches
[17:16] <desrt> printf("%u", getpid()) is possibly undefined, for example
[17:16] <desrt> if sizeof(pid_t) != sizeof(int)
[17:16] <desrt> but i guess in our case they're the same
[17:16] <pitti> desrt: undefined?
[17:16] <pitti> ah
[17:16] <desrt> pitti: if you had a platform where pid_t was a long, for example
[17:17] <pitti> so that would need an (unsigned) cast
[17:17] <desrt> then passing the result of getpid() directly as the argument for "%u" would be an error
[17:17] <pitti> as there's no printf macro for pid_t
[17:17] <desrt> yes.  you'd normally want a cast in this case.
[17:17] <desrt> i'd also have used g_strdup_printf() instead of mucking around with the static buffer
[17:17] <desrt> and i'd have written 'GError *error' instead of 'GError* error'
[17:17] <desrt> as i said -- all minor complaints :)
[17:18] <desrt> probably not worth changing
[17:18] <pitti> nah, I'll do it anyway
[17:18] <desrt> i assume you tested it and it works?
[17:18] <pitti> yes, of course
[17:18] <desrt> awesome :)
[17:18] <pitti> desrt: ah, I avoided g_strdup_printf(), mostly out of a habit
[17:18] <desrt> i'll wait for your tweaks, then i'll do a release (and tarball)
[17:18] <desrt> pitti: if this was some tight inner loop, i'd agree
[17:18] <pitti> if I can get away without dynamic memory allocation, I do it usually; but I'm happy to change it
[17:19] <desrt> but one extra malloc() _per lifetime of the entire system_.... probably not an issue :)
[17:19] <pitti> no, but it doesn't actually make the code any easier, to the contrary
[17:20] <desrt> pitti: it's not about making the code easier
[17:20] <pitti> it introduces at least three lines more
[17:20] <desrt> similar to your dynamic memory aversion i have an aversion to formatting strings into fixed-sized buffers
[17:20] <pitti> desrt: heh, fair enough
[17:20] <desrt> i'm pretty sure you got it right in this case, though
[17:21] <desrt> but that's the nice thing with g_strdup_printf -- you don't have to convince yourself
[17:21] <desrt> one more nit: your critical is probably actually a warning
[17:22] <desrt> critical == programmer errors
[17:22] <desrt> warning == things that should not have happened, but are not the fault of the programmer of this process
[17:23] <pitti> desrt: http://paste.ubuntu.com/6416828/ (built-tested, but not yet runtime-tested; doing now)
[17:23] <desrt> that said, the critical may be nice from the standpoint that we will soon be using apport to report criticals
[17:24] <desrt> but ya... probably better as a warning to be more 'proper'
[17:24] <pitti> desrt: thanks for the warning/critical heads-up
[17:24] <pitti> desrt: err, sorry, wrong diff
[17:25] <desrt> pitti: seems you could have avoided the boolean if you wanted to
[17:25] <desrt> but looks good
[17:25] <pitti> desrt: http://paste.ubuntu.com/6416837/
[17:25] <desrt> (even if it's the wrong diff) :)
[17:25] <pitti> desrt: yeah, I committed the style changes first, then --amend'ed the g_strdup_printf change
[17:25] <pitti> that's the complete one now
[17:26] <desrt> looks good to me
[17:26] <pitti> desrt: success> I try to free it ASAP; at some point someone might have an exit path in the if() condition
[17:26] <desrt> pitti: fair enough
[17:26] <desrt> you know about this gcc cleanup attribute?
[17:26] <pitti> desrt: I do
[17:26] <desrt> we should use it more :)
[17:27] <pitti> yeah, it's magic!
[17:27] <desrt> in cases like this where the software will only run on ubuntu (or debian some day maybe) we could totally rely on it
[17:27] <pitti> desrt: systemd upstream uses it a lot, I guess it's not really a distro thing but more like a "gcc" thing?
[17:27] <desrt> ya
[17:27] <desrt> my point is that ubuntu/debian are built using gcc...
[17:28] <desrt> ie: we don't have to worry about trying to build with msvc or so
[17:28] <pitti> hehe, yes
[17:28] <desrt> or suncc or whatever
[17:30] <pitti> desrt: ok, runtime-test thumbs up; good to push?
[17:30] <desrt> yes.  please do.
[17:31] <pitti> there
[17:31] <desrt> k.  lemme do the 'release' :)
[17:33] <desrt> okay.  done.
[17:34] <desrt> thanks!
[17:38] <pitti> desrt: mind putting the tarball to https://people.gnome.org/~desrt/ so that we have an "official" orig?
[17:39] <desrt> pitti: already did
[17:39] <pitti> desrt: "once and for all" -> famous last words! *cough*
[17:39] <desrt> :)
[17:39] <pitti> desrt: ah, cheers; reload helped
[17:39] <desrt> i think i also had "should" in there ;)
[17:39]  * pitti hugs desrt
[17:41]  * pitti goes to package/upload/update SRU
[17:48] <pitti> RAOF: FYI: [ubuntu/trusty] umockdev 0.4.7-1 (Accepted)
[18:31]  * Laney gives up staring at webkit's code
[18:35] <seb128> Laney, still looking at webkit? did that eat your day?
[19:17] <mfisch> I just confirmed an odd bug. The screen will not lock while you have a notification menu open (like session or battery)
[19:17] <mfisch> https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/941618
[19:17] <ubot2> Launchpad bug 941618 in gnome-screensaver (Ubuntu) "Screen not locking when hovering mouse over notification applets" [Medium,Confirmed]
[19:17] <mfisch> gnome-screensaver cannot get the focus
[19:19] <sarnold> mfisch: take a look at bug 49579  -- it's probably a duplicate
[19:19] <ubot2> Launchpad bug 49579 in gnome-screensaver (Ubuntu) "screen doesn't lock when some menu is open" [Low,Triaged] https://launchpad.net/bugs/49579
[19:20] <sarnold> mfisch: this is something we're expecting Mir to fix for us; fixing it in X11 seems neigh-on impossible.
[19:20] <mfisch> sarnold: looking, I just grabbed a log
[19:21] <mfisch> a 5 digit bug # even
[19:22] <mfisch> sarnold: yes, a dupe, thanks
[19:32] <bschaefer> happyaron, ping
[19:36] <seb128> bschaefer, it's like 3am for him, I doubt he's online
[19:37] <bschaefer> seb128, thanks, ill have to try to catch him tomorrow morning
[19:37] <seb128> mfisch, that's not weird, welcome to Xorg ... surprising you just discover that today ;-)
[19:37] <mfisch> seb128: only discovered on our hacked up GSS that lets you send lock signals via dbus
[19:37] <seb128> bschaefer, he's away for a Kylin meeting I think, back next week, you might let some ping context in case he looks at IRC in between (or email should work)
[19:38] <mfisch> seb128: but "Mir fixes" works for me
[19:38] <seb128> mfisch, yeah, Mir should fix it, I'm sure the security team is going to make sure of that ;-)
[19:38] <bschaefer> seb128, I see thanks again for the info :). cool ill just send him an email!
[19:38] <seb128> bschaefer, just curious, what's the topic? im-config stuff again?
[19:39] <bschaefer> seb128, no its actually more of a question about preedit windows, more about I want to ask someone who uses IMs
[19:39] <bschaefer> like, how important that box is, as im fixing up XIM in nux
[19:39] <seb128> bschaefer, "preedit"?
[19:39] <bschaefer> when you typing in any IM you get preedit text, thats showing you what has been typing so far but is not real text yet
[19:40] <seb128> oh
[19:40] <seb128> I'm sure they want that
[19:40] <bschaefer> and each IM has a preedit box that shows you suggestions of the next char you want
[19:40] <seb128> isn't that working in the dash?
[19:40] <bschaefer> seb128, its working, but im running into problems getting it in a nice position
[19:40] <bschaefer> as with XIM, it only uses the X windows position
[19:40] <bschaefer> so for the dash it wont be below the text entry, it'll be at the bottom left of the Dash
[19:41] <seb128> bschaefer, you are trying with ibus?
[19:41] <bschaefer> seb128, as the goal is remove all the Ibus code from nux, and depend only on XIM
[19:41] <bschaefer> seb128, XIM support all IMEs
[19:41] <seb128> yeah, that would be nice
[19:41] <seb128> Kylin uses fcitx
[19:41] <seb128> that's a topic for vUDS next week
[19:41] <bschaefer> yes very much, the one problem is the preeidt window wont be super nice in ibus
[19:42] <seb128> ibus/fcitx for Ubuntu
[19:42] <seb128> is it better in fcitx?
[19:42] <bschaefer> seb128, yup it'll all work fine, XIM is an abstraction that all IMes implement
[19:42] <bschaefer> X Input Method
[19:42] <bschaefer> all the IMes have the XIM client code, so all of them work
[19:42]  * bschaefer gets  a list
[19:42] <seb128> right, sorry for the question, I'm just trying to figure out if that's ibus specific/if fcitx does better
[19:43] <seb128> bschaefer, don't bother with a list, we care about ibus and fcitx ... and we need to pick one
[19:43] <bschaefer> seb128, right, well the only difference between switching from IBus directly to using XIM
[19:43] <bschaefer> is this preedit window box isn't in the same place
[19:43] <bschaefer> but all will work fine
[19:43] <seb128> ok
[19:44] <seb128> I'm sure we can address that specific issue in some way
[19:44] <seb128> in any case Kylin is the main user
[19:44] <bschaefer> right, i've tried work arounds, but XIM is a bit old and kind of late getting into X to begin with...
[19:44] <bschaefer> yup, and fcitx will work much better in Nux
[19:44] <bschaefer> cause i've actually implemented the rendering of preedit text (this isn't the case atm)
[19:44] <seb128> knowing that they don't use ibus, we need to switch away from requiring it
[19:45] <bschaefer> yup!
[19:45] <bschaefer> which as soon as I can get this branch landed we can remove anything ibus related in nux
[19:45] <bschaefer> and unity
[19:45] <seb128> \o/
[19:45]  * bschaefer and remove those evil ibus AP tests...
[19:45] <seb128> so you are saying fcitx works better than ibus UI wise in Unity?
[19:45] <seb128> btw it would be nice if you can join that session next week
[19:46] <bschaefer> yeah i can join in, umm right now ibus works better
[19:46]  * seb128 has no clue about input methods framework (as most of the team), yet we have to pick one :/
[19:46] <bschaefer> because we implemented ibus directly in nux
[19:46] <bschaefer> yup
[19:46] <seb128> right
[19:46] <bschaefer> im not really sure, both work very well overall (in my eyes at lease)
[19:46] <seb128> is that statement still true once you land the xim support?
[19:46] <bschaefer> when we move to XIM, they will all look the same
[19:46] <seb128> great
[19:47] <bschaefer> the only difference will be the preedit window the IMe renderes
[19:47] <seb128> so at least Unity is not a blocker in the decision
[19:47] <bschaefer> renderers, which they are in charge of
[19:47] <bschaefer> what would be a blocker?
[19:47] <seb128> the UI you are talking about is e.g http://www.emacswiki.org/pics/static/IBusModeScreenShot.png right?
[19:48] <bschaefer> seb128, yup that little box with the suggestions
[19:48] <seb128> blocker would be: users of that framework can't use the dash
[19:48] <bschaefer> oo, well they can :), so yeah thats good
[19:48] <seb128> great
[19:48] <bschaefer> seb128, the only thing, with the dash the preedit box in fullscreen will be outside of the screen :(
[19:48] <seb128> the real solution for that is to add the prediction UI to unity...
[19:48] <seb128> (sure you like that ;-)
[19:49] <bschaefer> which is one question i wanted to ask, how important that suggestion is box really is to normal users
[19:49] <bschaefer> seb128, well the problem, is we can't control its location
[19:49] <bschaefer> only the IMe does
[19:49] <bschaefer> (for some reason)
[19:49] <seb128> I'm not using those input method but I guess it's a basic feature so important
[19:49] <bschaefer> and its location is based on the bottom left corner of the X window
[19:49] <bschaefer> yes very much so
[19:49] <bschaefer> ill have to come up with a work around...
[19:50] <bschaefer> so far a few have failed
[19:50] <seb128> bschaefer, oh, I'm sure you can
[19:50] <bschaefer> seb128, atm, its a problem in any gtk app as well, if you use XIM
[19:50] <seb128> bschaefer, http://hedayatvk.files.wordpress.com/2013/01/d8b9daa9d8b3e2808cd8b5d981d8add987-d8a7d8b2-2013-01-16-021756.png
[19:50] <seb128> bschaefer, that's what gnome-shell is doing
[19:50] <bschaefer> if the window is maxed, the preedit box is placed outside the screen
[19:50] <bschaefer> that looks nice
[19:50] <seb128> bschaefer, if they can, it's technically doable
[19:51] <bschaefer> seb128, it is, the problem
[19:51] <bschaefer> nux doesn't have a nice IME interface
[19:51] <bschaefer> the only one we really have access to is XIM
[19:51] <seb128> right
[19:51] <bschaefer> so, the real soultion would be to implement an IME interface for nux, and write client code in each IME
[19:51] <seb128> that might be a "next generation desktop" topic
[19:51] <seb128> e.g unity8
[19:51] <bschaefer> well unity8 IIRC uses malit?
[19:51] <bschaefer> i can't spell it :)
[19:52] <bschaefer> which has all that stuff put in with QT
[19:52] <seb128> don't ask me
[19:52] <bschaefer> sooo hopefully when we move over to unity8 we will have no more problems with IMs
[19:52] <seb128> I still don't understand how much an osk integrates/replaces IM framework
[19:52] <seb128> we still need to support physical keyboard
[19:53] <seb128> you can't just dynamically change the physical layout on those ;-)
[19:53] <bschaefer> o right...that'll be interesting, luckly QT has an IM interface, and I know (think?) fcitx supports it at lease
[19:53] <seb128> right
[19:53] <seb128> one step at the time
[19:53] <bschaefer> yup, having that already solidified is a huge step
[19:53] <bschaefer> from there you just need to make sure each IME support that toolkit
[19:53] <seb128> it would be good for the lts to put the popover dialog in the dash rather than at the corner
[19:54] <seb128> not sure how easily that's to hack though
[19:54] <bschaefer> hmm well with XIM the pop up will be at the bottom left corer atm
[19:55] <bschaefer> im guessing the only workaround will be to hacky, and possible regression causers
[19:55] <bschaefer> ie. having to re-implement the text entry to be an Xwindow it self
[19:55] <bschaefer> but yeah, one step at a time, i should get it merged first :)
[19:56] <seb128> right, let's get it working first, then we can do UI tweaks
[19:56] <bschaefer> sounds good!
[19:56] <seb128> but I guess it's not going to be trivial to get some popup on top of the dash
[19:57] <seb128> e.g we would maybe need to make that UI be display by unity itself
[19:57] <seb128> which starts being more work than we want for the LTS
[19:57] <seb128> so yeah, maybe just having it at the corner is good enoug
[19:57] <seb128> h
[19:57] <bschaefer> right, im just worried about regression potential for the LTS
[19:57] <seb128> check with happyaron ;-)
[19:57] <bschaefer> i would much rather play it safe :)
[19:57] <bschaefer> yup, ill send him an email!
[19:58] <seb128> (which is what you were going to do, sorry for distracting you)
[19:58] <bschaefer> no worries :)
[19:58] <seb128> but yeah, play safe sounds good
[19:58] <seb128> we are struggling on what to do with the indicators/keybindings as well
[19:59] <bschaefer> yeah i was reading that topic...its a complicated problem...
[19:59] <seb128> indeed
[19:59] <bschaefer> is there also a session for this in vUDS?
[20:00] <seb128> not yet, I'm pondering putting one
[20:00] <seb128> we still have free slots
[20:00] <seb128> there is one from the Kylin guys about ibus/fcitx
[20:00] <bschaefer> wouldn't be a bad idea, as thats something to talk about worst case it'll be short
[20:00] <seb128> I'm also unsure how the indicator/keybinding stuff can be resolved over a session
[20:00] <seb128> right
[20:01] <seb128> I was thinking about putting one
[20:01] <seb128> I'm probably going to do that (setting it after the ibus/fctix one so we can discuss based on the output of that one)
[20:01] <bschaefer> yeah, ill make that one, unless i over sleep haha (joking)
[20:01] <seb128> ;-)
[20:01] <bschaefer> that would be good, if the slots align nicely :)
[20:02] <seb128> yeah, I've scheduling powers so I can make that happen ;-)
[20:03] <bschaefer> :)
[20:09] <desrt> seb128: any other gtk nags?
[20:10] <seb128> desrt, nags, or nags for you?
[20:10] <desrt> :)
[20:10] <desrt> anything that i could do to make your life easier?
[20:10] <seb128> desrt, https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1171587 comment #3 (#4 as well)
[20:10] <ubot2> Launchpad bug 1171587 in gtk+3.0 (Ubuntu) "update to GTK 3.9 and the issues to resolve for it" [Wishlist,Confirmed]
[20:11] <desrt> seb128: fwiw, dunno what the deal with u-s-d is, but you're probably going going to need to manually pick that patch at least
[20:11] <seb128> desrt, I think larsu is on the other ones (out of update-manager one, but that's not a blocker)
[20:12] <desrt> although the failure mode if you don't pick the patch will be for it to fail in the direction that we find favourable, ie: desktop will be shown
[20:12] <desrt> but we should probably do it anyway to support people who manually disable the desktop
[20:12] <seb128> desrt, yeah, I'm going to pick that patch this week. robert_ancell sent me an email that he has an u-s-d test version ready, but he's on vac for a week now
[20:12] <desrt> seb128: parallel-installable with g-s-d i hope
[20:12] <seb128> yeah
[20:12] <desrt> neat
[20:12] <seb128> we still have arguments about the details though
[20:13] <seb128> he wants to rename/migrate the gsettings keys
[20:13]  * desrt finds a new wishlist bug about the "...when ~/Desktop is not empty" thing
[20:13] <seb128> I argue that there is enough compat that it's not needed
[20:13] <seb128> not speaking about external users/internet documentation
[20:15] <desrt> that's very tricky
[20:16] <desrt> gsettings-desktop-schemas upstream has been less.... stable than i'd have hoped
[20:16] <desrt> in general, i think ubuntu-desktop-schemas would be an extremely good idea
[20:16] <desrt> for various extras we have
[20:17] <desrt> instead of all of the hacking we do to check "is component X installed?  use it's gsettings, if so..."
[20:17] <seb128> right, but I think in practice it's going to be less work this cycle to enforce stability there/add back keys for compat reasons if they drop them than to fork/migrate the keys
[20:17] <desrt> now that we have a proper g-c-c fork, these sorts of "add UI elements if..." checks are pointless
[20:17] <desrt> seb128: as long as the changes that we patch back are purely additive
[20:18] <desrt> (ie: we only do it when upstream is removing settings outright)
[20:18] <desrt> because otherwise we may end up causing compatibility issues for gnomebuntu
[20:18] <seb128> right
[20:18] <seb128> I think that in practice it should be an easy this cycle
[20:18] <desrt> from that standpoint i understand why robert wants what he wants
[20:18] <seb128> which makes less migration work for the LTS
[20:18] <desrt> but i agree that the changes should not be too much, and they're usually strictly additive
[20:18] <seb128> we can revisit next cycle if needed
[20:19] <seb128> desrt, btw, we have https://launchpad.net/gsettings-ubuntu-touch-schemas
[20:19]  * desrt is honestly looking forward to being able to run ubuntu again :)
[20:20] <seb128> which is what you suggested, for unity8
[20:20] <desrt> good
[20:20] <desrt> this is how gsettings is meant to be used
[20:20] <seb128> unitu7 is in sitting in the middle of 2 worlds
[20:20] <desrt> ya...
[20:20] <seb128> unity*
[20:20] <desrt> in general, i really like the way new things are going
[20:20] <desrt> it's going to be very very much cleaner
[20:20] <seb128> right
[20:20] <seb128> I wonder how much "different desktops on a same distro" is going to stay true though
[20:21] <seb128> the GTK/Desktop stuff showing it why today
[20:21] <desrt> this was a stupid change, imh
[20:21] <desrt> +o
[20:21] <seb128> the xsettings logic is sort of a strech
[20:21] <desrt> the trivial work that i did today should have just been done from the start
[20:21] <desrt> and this isn't about different desktops on the same distro
[20:21] <desrt> this is about different desktops using the same toolkit
[20:21] <seb128> right, they screwed other OSes on the way
[20:21] <desrt> which is a problem that gtk chooses to have.... we just have to remind from time to time that this is their choice
[20:21] <desrt> and showing up with patches is always the nicest way to do that ;)
[20:21] <seb128> I guess it's rather the discussion" GTK is the GNOME toolkit"
[20:22] <desrt> gtk is only the gnome toolkit insofar as non-gnome people don't show up offering to do work
[20:22] <desrt> today a non-gnome person (me) showed up with patches.  they got applied almost straight away.
[20:22] <desrt> these patches didn't benefit gnome in any way at all
[20:22] <seb128> yeah, as long as they are fine taking the code to accommodates other OSes
[20:23] <desrt> which, again, is a choice that gtk made
[20:23] <seb128> right
[20:23] <seb128> I'm pretty happy about the outcome ;-)
[20:23] <desrt> it's supposed to be a cross-platform toolkit.  that includes linux-outside-of-gnome too.
[20:23] <seb128> I was unsure how Bastien would respond when you asked
[20:26] <desrt> seb128: you duped :p
[20:27] <desrt> https://bugzilla.gnome.org/show_bug.cgi?id=711040
[20:27] <ubot2> Gnome bug 711040 in GtkFileChooser "GtkFileChooser: Desktop entry missing" [Normal,Unconfirmed]
[20:28] <seb128> desrt, heh, I listed it myself in https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1171587/comments/3 that doesn't count ;-)
[20:28] <ubot2> Launchpad bug 1171587 in gtk+3.0 (Ubuntu) "update to GTK 3.9 and the issues to resolve for it" [Wishlist,Confirmed]
[20:28] <seb128> but yeah, I should maybe have reused that one
[20:28] <desrt> you were so upset that you wanted it to be two bugs? :)
[20:29] <seb128> let's say that I didn't want to spam that poor-contributor's bug with my ranting :p
[20:29] <desrt> the rest look like a bunch of theme issues
[20:29] <desrt> (sigh)
[20:29] <desrt> would be really nice if our theme was maintained...
[20:30] <seb128> right
[20:30] <seb128> well, it's not
[20:30] <seb128> the overlay-scrollbar bugs larsu is working on is not a theme issue
[20:30] <desrt> ah.  surprising.
[20:30] <seb128> it's an issue with the rendering optimisation alex did
[20:30] <desrt> ah.  that makes sense as well, i suppose.
[20:30]  * desrt freaking loves the new alex stuff, btw
[20:30] <seb128> to give some credit where it's due, the 3.8 issues we had with scrollbars turned you to be a GTK bug
[20:31] <desrt> that item was on my todo list for a while (larsu and i chatted about how we'd do it when we were in copenhagen)
[20:31] <seb128> and one where users were vocal about in other softwares as well
[20:31] <desrt> and then alex just came with code
[20:31] <larsu> desrt: which item?
[20:31]  * larsu doesn't feel thrilled about alex' optimizations today
[20:31] <desrt> larsu: changing how the scrolling works
[20:31] <seb128> larsu, not drinking Berlin beers tonight? ;-)
[20:31] <desrt> pure cairo-based.... no more GdkWindow hackery
[20:32] <larsu> seb128: that was Tuesday. Can't have beer every night :)
[20:32] <seb128> ;-)
[20:32]  * desrt wants to drink a $22 beer...
[20:32] <seb128> desrt, talk to attente
[20:32] <desrt> :)
[20:32] <larsu> desrt: ah, right. The thing I'm fought with is a change that leads up to that
[20:33] <seb128> attente, congrats on getting the compiz key grabbing working btw, seems user feedback of the ppa is good ;-)
[20:33] <larsu> I think I've found the issue, but was too exhausted to go on further earlier today
[20:33] <attente> seb128, thanks
[20:33] <desrt> is this the one where it only works when the user changes the keybinding after logging in?
[20:33] <seb128> desrt, he fixed that!
[20:33] <desrt> oh.  good
[20:33] <seb128> ;-)
[20:33] <desrt> because that sounded ridiculous :)
[20:33]  * desrt was about to offer ways to trick gsettings into reporting change notifications :)
[20:33] <seb128> desrt, we seem to be on parity with gnome-shell now :p
[20:34] <attente> that problem was stressful..
[20:34] <desrt> attente: maybe i should buy you a $22 beer :p
[20:34] <seb128> (which doesn't mean bug free)
[20:34] <seb128> desrt, yeah, you should
[20:34] <desrt> seb128: gnome-shell has bugs?
[20:34] <desrt> weird!!!
[20:34]  * seb128 would if he was in Canada
[20:34] <attente> it becomes more like a $1022 beer
[20:34] <seb128> huuuum, maybe I'm stepping out
[20:35] <desrt> attente: because you want to buy 40 of them?
[20:35] <seb128> attente, I bet you can't drink those 40 beers in one night
[20:35]  * attente adds the cost of the flight
[20:35] <attente> :P
[20:35] <desrt> ah
[20:35] <seb128> if you can I'm paying for them
[20:35] <attente> at that point you might as well be in belgium i suppose...
[20:35] <desrt> seb128: stop that
[20:36] <desrt> seb128: we finally have a guy who knows about keyboard and input method and you want to kill him with alcohol poisoning
[20:36] <seb128> yeah, that's not cool
[20:36]  * seb128 stops
[20:36] <seb128> attente, come to Berlin next year, we can have good beers there as well
[20:36] <seb128> you can ask larsu ;-)
[20:36]  * larsu confirms
[20:36] <desrt> seb128: he'll be in strassbourg next year...
[20:36] <seb128> \o/
[20:37] <desrt> i guess the beer there is probably also okay :)
[20:37] <seb128> yeah, people coming to France!
[20:37] <larsu> what a coincidence: so will I!
[20:37] <seb128> ;-)
[20:37] <larsu> the world is such a small place
[20:37] <attente> fun times :)
[20:39] <seb128> ok, on that note I'm calling it a day
[20:39] <desrt> seb128: good night
[20:39] <seb128> thanks, you too!
[20:39] <attente> nite seb128 :)
[20:40] <seb128> attente, thanks, you too ;-)
[20:40] <desrt> larsu: did you check that your appmenu patch works?
[20:40] <seb128> larsu, you should call it a day as well, tomorrow is friday need to keep going until the W.E ;-)
[20:40] <larsu> seb128: I already did. Just hanging around on irc :)
[20:40] <larsu> desrt: yes
[20:41] <desrt> cool.  i just ACK'd it
[20:42] <larsu> thanks.
[20:42] <desrt> which is meaningless since i removed myself from the product strategy team....
[20:42] <larsu> you can do that now, eh?
[20:42] <desrt> oops!
[20:42] <larsu> I'm not on that team either…
[20:42] <desrt> you're directly in the indicators team, though
[20:42] <larsu> right
[20:42]  * desrt was indirectly before, via PS
[20:43] <larsu> being in PS makes your inbox blow up
[20:44] <desrt> ya.  this is why i left :)