[03:01] <pero> i've lost my the Unity Webapps extension in Chromium - yet everything seems installed ok - any way to get it back?
[08:08] <tsdgeos> my clock indicator is gone again
[08:09]  * tsdgeos manually starts it
[08:46] <Cimi> tsdgeos, hey :)
[08:54] <tsdgeos> Cimi: ho
[09:06] <Cimi> tsdgeos, I had a look yesterday
[09:06] <Cimi> tsdgeos, and basically it's like your work plus something else
[09:07] <Cimi> for example highlghtIndex
[09:07] <Cimi> tsdgeos, I'm wondering if it really makes sense to share a common interface... filter grid is lot more complex
[09:09] <tsdgeos> Cimi: well, if you don't have a common interface how am i supposed to implement a new renderer (let's say one that displays stuff in a circle)?
[09:09] <tsdgeos> just by magicly going over all the code and random guessing stuff?
[09:10] <Cimi> tsdgeos, but the common interface is raised in complexity because of the filtegrid
[09:10] <Cimi> tsdgeos, I will have to add dummy stuff to the carousel just to match the interface
[09:10] <tsdgeos> no
[09:10] <tsdgeos> you have dummy stuff in your interface
[09:10] <Cimi> whatever
[09:10] <Cimi> I meant, it's not used
[09:10] <tsdgeos> yes
[09:10] <Cimi> you have APIs that do nothing
[09:11] <tsdgeos> it's not used now either
[09:11] <tsdgeos> Cimi: what's the other solution?
[09:11] <tsdgeos> have lots of if (FilterGrid) ?
[09:11] <Cimi> :\
[09:11] <Cimi> I dunno
[09:12] <Cimi> that's why I am asking your opinion
[09:12] <tsdgeos> or just end up with warnings like now because we access stuff that doesn't exist
[09:12] <tsdgeos> my opinion is that the common interface makes sense
[09:12] <tsdgeos> we need to properly define it
[09:12] <tsdgeos> i.e. if property moo only makes sense if you support filtering or something
[09:13] <tsdgeos> then we need to make it clear in the doc of that common interface
[09:38] <tsdgeos> Cimi: afaiu that was also Saviq's position, but you may want to check with him
[09:38] <Cimi> ok
[09:40] <Saviq> Cimi, tsdgeos, yes, even if not used, we should have a common interface, just to avoid changing it in one place and forgetting about other places, like we had already
[09:40] <Saviq> after all, noop on part of an API is just a special case
[09:41] <tsdgeos> +1
[09:44] <Saviq> Mirv, hey, we got a fix in upstream Qt that would fix unity8's FTBFS with 5.2
[09:45] <Saviq> Mirv, we could distro-patch if you think it worth it https://codereview.qt-project.org/#change,71208
[09:45] <Saviq> Mirv, or wait until a second beta or something
[09:48] <Saviq> Mirv, there's one more related in review: https://codereview.qt-project.org/#change,71327
[09:52] <Cimi> i'll do that then
[09:52] <tsdgeos> man https://code.launchpad.net/~unity-team/unity8/trunk/+activereviews is starting to look scary again
[10:08] <Mirv> Saviq: oh cool. the RC should on Tuesday
[10:08] <Mirv> Saviq: I can put it in as a patch
[10:10] <Mirv> Saviq: btw webkit, sensors, location, multimedia also in qt5-beta2 PPA. had to disable the device pixel ratio patch of qtwebkit again as it didn't apply.
[10:16] <tsdgeos> hmmm
[10:17] <tsdgeos> are we using VideoInfo.qml?
[10:19] <tsdgeos> or AppInfo.qml?
[10:20] <Saviq> tsdgeos, probably not
[10:20] <Saviq> tsdgeos, VInfo was reading .nfo files - so no
[10:20] <Saviq> tsdgeos, AppInfo, yes - it's part of the app preview
[10:21] <Saviq> or hmm
[10:22] <Saviq> tsdgeos, it *was* part of the app preview, looks like it's moved to Header, since, I think
[10:23] <tsdgeos> :D
[10:23] <tsdgeos> so kill both?
[10:23] <tsdgeos> or?
[10:23] <Saviq> yeah, if you can confirm they're not used
[10:23] <Saviq> kill with fire
[10:25] <Saviq> Mirv, right, the second patch should be merged by Tuesday, too
[10:25] <Saviq> tsdgeos, they're going into 5.2, right ↑? (/me doesn't know the stable vs. release targets in Qt's gerrit)
[10:26] <tsdgeos> Saviq: the one that is merged will be in 5.2.0
[10:26] <tsdgeos> the one that is still being discussed seems like it'll be in 5.2.0 too
[10:26] <tsdgeos> or at least it's the branch i'm targetting
[10:26] <Saviq> tsdgeos, yup, cool beanz
[10:26] <tsdgeos> Saviq: at this moment release -> 5.2.0 stable -> 5.2.1 dev -> 5.3.0
[10:27] <Saviq> tsdgeos, ah, got it
[11:04] <nic-doffay> Saviq, any bugs you can recommend for me to take a look at?
[11:06] <tsdgeos> nic-doffay: how's the filter expansion one going? needs review or still wip?
[11:10] <nic-doffay> tsdgeos, I just need to do a small change to keep it in line with the sdk
[11:10] <nic-doffay> but it's basically ready to land ages ago.
[11:10] <tsdgeos> nic-doffay: no no, i mean the dash animation expansion, no the filtering in the header
[11:10] <tsdgeos> sorry :D
[11:11] <Saviq> nic-doffay, https://code.launchpad.net/~nicolas-doffay/unity8/filter-selector/+merge/191145/comments/450251 that says it isn't ready ;)
[11:12] <Saviq> tsdgeos, Cimi what's the deal with the InverseMouseArea? did you find a workaround until Daniel's "deliver touch through sendEvent" gets in?
[11:12] <Cimi> I did not wrk on it
[11:13] <Saviq> tsdgeos, ah, you only did a "don't filter if disabled"
[11:14] <tsdgeos> Saviq: ¿?
[11:14] <Saviq> Cimi, mhm, k - we'll probably distro-patch Daniel's patch when it gets in
[11:14] <Saviq> tsdgeos, https://code.launchpad.net/~aacid/ubuntu-ui-toolkit/ima_do_not_filter_disabled/+merge/194830
[11:14] <nic-doffay> Saviq, I've addressed those.
[11:14] <tsdgeos> ah yes
[11:14] <tsdgeos> Saviq: that was a different fix altogether
[11:14] <nic-doffay> Saviq, oh wait..
[11:14] <nic-doffay> :P
[11:14] <tsdgeos> Saviq: if you had two InverseMouseArea they would fight eachother
[11:14] <Saviq> nic-doffay, yeah :P
[11:14] <tsdgeos> which was awful :D
[11:14] <Saviq> tsdgeos, oh the blood
[11:15] <tsdgeos> Saviq: now they only fight eachother if they are both enabled, which is "understandable" as you have two mouseareas where both say they are the topmostitem
[11:15] <tsdgeos> so well, fix your software :D
[11:15] <Saviq> yeah, of course
[11:15] <Saviq> nic-doffay, please make sure to reply to review comments so that people don't have to find what's fixed by themselves
[11:18] <nic-doffay> Saviq, sure
[11:19] <nic-doffay> Saviq, either way it looks like I'll be busy with those changes.
[11:20] <Saviq> nic-doffay, I'm ok with not having the expansion fixed completely, but getting stuck in the filters is bad
[11:20] <Saviq> nic-doffay, so we need to make the best we can to improve the situation while we don't have the whole expansion thing sorted out
[11:20] <nic-doffay> Saviq, there's no reason why those changes can't be done today.
[11:20] <nic-doffay> Aside from the icon depending on design.
[11:21] <Saviq> nic-doffay, k
[11:21] <nic-doffay> Saviq, for the filter selection I just plan on using inverse mouse areas to dismiss/block selection of the other drop downs.
[11:22] <Saviq> nic-doffay, yeah, we need to have IMA fixed for that, too
[11:22] <nic-doffay> Saviq, that's what I was concerned about.
[11:22] <nic-doffay> Hopefully it will function ok.
[11:22] <tsdgeos> no mirco today?
[11:23] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/remove_unused_info_files/+merge/195365
[11:51] <Saviq> tsdgeos, thanks
[12:27] <mzanetti> Saviq: the click package upgrading feels a bit like BAMF :)
[12:28] <mzanetti> as we have a different appId, different .desktop file and need to guess if its just an upgrade or in fact a different app :)
[12:29] <Saviq> mzanetti, you shouldn't care about that
[12:29] <Saviq> mzanetti, just store appid://..../current-user-version
[12:29] <mzanetti> Saviq: but when an app gets started I get the full appid
[12:29] <mzanetti> and still need to figure what it is
[12:30] <Saviq> mzanetti, well, just strip the version number, no?
[12:30] <mzanetti> Saviq: yeah... but then I need to open the .desktop file to read the icon etc
[12:30] <mzanetti> and for that I need the full version again
[12:30] <Saviq> mzanetti, right, that should be the desktop file parser's job, shouldn't it...
[12:31] <Saviq> mzanetti, but yeah, while we don't have it
[12:31] <Saviq> mzanetti, shouldn't be too difficult to just find the matching .desktop file?
[12:31] <Saviq> as there can (well, should...) only be one
[12:32] <Saviq> fail-safe - find the latest one alphabetically
[12:35]  * Saviq wonders if QStandardPaths::locate supports wildcards
[12:37] <Saviq> nope :/
[12:41] <tsdgeos> mzanetti: https://bugreports.qt-project.org/browse/QTBUG-32251 should we discard this one?
[12:41] <tsdgeos> Saviq: like?
[12:41] <Saviq> tsdgeos, like *
[12:41] <tsdgeos> it does i've been told it could do * stuff
[12:41] <tsdgeos> i actually even wrote code i think :D
[12:42] <Saviq> tsdgeos, hmm maybe locateAll does not?
[12:42] <tsdgeos> hmm
[12:42] <tsdgeos> ok, actually not
[12:43] <tsdgeos> waht i did was
[12:43] <tsdgeos> const QStringList localeDirs = QStandardPaths::locateAll(QStandardPaths::GenericDataLocation, QString("locale"), QStandardPaths::LocateDirectory);
[12:43] <tsdgeos> taht is kind of a *
[12:43] <tsdgeos> but not really
[12:43] <tsdgeos> i.e. it returns all subdirs of QStandardPaths::GenericDataLocation containing a subdir named "locale"
[12:44] <Saviq> tsdgeos, http://pastebin.ubuntu.com/6420982/ is what I tried
[12:44] <Saviq> tsdgeos, hrm subdirs?
[12:44] <Saviq> tsdgeos, so ~/.local/share/*/locale?
[12:45] <tsdgeos> yep
[12:45] <tsdgeos> or not
[12:45] <tsdgeos> wait
[12:45] <tsdgeos> i'm speaking shit here :D
[12:45] <Saviq> yeah you are ;D
[12:46] <tsdgeos> what it does is return the subirs of /usr/share/locale/
[12:46] <Saviq> that'd be wrong ;)
[12:46] <Saviq> then it doesn't do what the docs say it does :D
[12:47] <tsdgeos> true
[12:47] <Saviq> ("/home/michal/.local/share/locale", "/usr/share//locale")
[12:47] <Saviq> tsdgeos, that's what it does ;D
[12:47] <tsdgeos> because i'm speaking shit again
[12:47] <tsdgeos> sorry
[12:47] <Saviq> so no, not what you said :D
[12:47] <tsdgeos> don't listen to me again :D
[12:47] <Saviq> tsdgeos, don't worry, it's Friday ;)
[12:48] <tsdgeos> it's weird it doesn't support * though
[12:48] <tsdgeos> since it's written by the KDE guy that wrote KStandardDirs
[12:48] <tsdgeos> and that supports *
[12:48] <tsdgeos> i do
[12:48] <tsdgeos> list = KGlobal::dirs() -> findAllResources("appdata", "*.kgm");
[12:48] <tsdgeos> in one of my kde apps
[12:49] <tsdgeos> Saviq: maybe QStandardPaths::ApplicationsLocation is /usr/bin and that's why it doesn't return stuff?
[12:49] <Saviq> tsdgeos, no, that's $GenericDataLocation/applications
[12:50] <Saviq> tsdgeos, so ~/.local/share/applications, /usr/share/applications
[12:50] <Saviq> tsdgeos, if I use the full file name, it works
[12:51] <tsdgeos> let me ask david
[12:51] <tsdgeos> oh, he's not online
[12:52] <Saviq> mzanetti, on that note... (how) do we remove pinned items for apps that are removed?
[12:55] <mzanetti> Saviq: we don't right now
[12:55] <Saviq> mzanetti, yeah I'm not sure what we should do TBH
[12:56] <Saviq> mzanetti, whether we should do anything, for that matter (other than ignoring invalid entries - and pick them back up when installed again)
[12:56]  * greyback thinks version string in appId is more trouble than it's worth
[12:56] <mzanetti> +1
[12:57] <mzanetti> Saviq: do we actually use the version field somewhere or do we just work around it everywhere?
[12:57] <greyback> and it break the existing ability to watch for app installs/updates/removals by inotify on the desktop file directories
[12:57] <mzanetti> it kinda defeats the purpose of the appId, because it doesn't identify an app
[12:57] <Saviq> greyback, mzanetti, the reason for having them in is being able to install multiple versions at the same time
[12:57] <Saviq> in a multi-user environment
[12:58] <Saviq> you don't want other users to upgrade your apps
[12:58] <mzanetti> mhm
[12:58] <greyback> doesn't each user have their own .local directory
[12:58] <Saviq> greyback, only for the .desktop files
[12:58] <mzanetti> for the rest too actually
[12:58] <Saviq> greyback, the apps are installed in /opt
[12:58] <mzanetti> in /opt/.click/user/...
[12:58] <Saviq> s/installed/unpacked/
[12:59] <mzanetti> at least the icon file is located there, not where the main thing is unpacked
[12:59] <Saviq> # ls /opt/click.ubuntu.com/
[12:59] <Saviq> com.ubuntu.developer.mzanetti.ubuntu-authenticator
[12:59] <Saviq> com.ubuntu.developer.mzanetti.xbmcremote
[12:59] <Saviq> com.ubuntu.developer.rick-rickspencer3.franglish
[12:59] <mzanetti> ls /opt/click.ubuntu.com/.click/users/phablet/
[12:59] <mzanetti> com.ubuntu.developer.alecu.qr-code         com.ubuntu.developer.mzanetti.ubuntu-authenticator  com.ubuntu.developer.ogra.fruity-pops
[12:59] <mzanetti> com.ubuntu.developer.elopio.xbmcwebremote  com.ubuntu.developer.mzanetti.xbmcremote
[13:00] <mzanetti> so it's linked (without version information) to a user specific dir
[13:00] <Saviq> right
[13:01] <Saviq> that looks internal to the click system, though
[13:02] <Saviq> another reason is having per-version data directories, so that app upgrades don't b0rk your data
[13:02] <mzanetti> Saviq: what you mean with data directories?
[13:03] <mzanetti> .cache ?
[13:03] <Saviq> mzanetti, .local/share/ rather
[13:03] <Saviq> .cache is not for data ;P
[13:03] <greyback> so should we should agree in shell to drop version string from appId everywhere? Since per user session, only one version of an app can be installed
[13:04] <mzanetti> I think it would be better to drop it everywhere in unity than just having regexps on ever interface the launcher has to the outside
[13:04] <Saviq> greyback, mzanetti, sure, I don't think it helps us anywhere shell-side
[13:05] <Saviq> and it hurts us where we store/match it
[13:05] <mzanetti> yeah
[13:05] <greyback> +1
[13:06] <Saviq> we should talk to cjwatson / barry about this
[13:06] <Saviq> maybe even upstart shouldn't care about them
[13:07] <mzanetti> yeah... I do see the reason why we install it in different directories. but the fact that the version is inserted in the appId seems to cause only issues
[13:07] <Saviq> that I agree with
[13:09] <greyback> would be handy of upstart adopted it too. I think it makes sense, as the session upstart is only able to launch 1 version anyway. Would make my life nicer too :)
[13:10] <greyback> that still leaves us with the problem: how can shell know if a click app was updated? Watching the desktop file directories isn't quite enough really.
[13:10] <greyback> similarly when app removed
[13:11] <mzanetti> greyback: the update issue would go away, no?
[13:11] <greyback> mzanetti: are we proposing drop the version string from the desktop file name in the .local ?
[13:12] <greyback> if yes, then we're golden
[13:12] <greyback> but then what about system apps. Ahh
[13:12] <mzanetti> greyback: the .desktop filename is "appId".desktop
[13:13] <mzanetti> greyback: what's the problem with system apps?
[13:14] <greyback> mzanetti: let me recap: we're using "$appId.desktop" files. appId includes version string. On update, the desktop file is removed and a new one with different file name created
[13:15] <mzanetti> yes
[13:15] <mzanetti> because appId changes
[13:15] <greyback> we plan to watch via inotify the desktop file directories for the deletion and creation?
[13:15] <mzanetti> greyback: not really, no
[13:16] <greyback> mzanetti: oh, how does shell know if app updated or removed?
[13:17] <mzanetti> greyback: yeah, well, we could do that to determine if an app is removed. but it still wouldn't help us in the upgrade case as it would go away and a *different* one appears
[13:17] <greyback> mzanetti: exactly. That's my concern.
[13:17] <mzanetti> so yes. once the upgrade leaves the file alone, watching it might be an option to determine removal of an app
[13:18] <mzanetti> assuming an upgrade wouldn't remove it and then recreate it a few seconds later
[13:23] <greyback> I think easier solution is just to have the desktop file name use the app Id minus the version string. Since desktop file is placed in a user specific directory, the versioning is irrelevant data in that context. The app install directory can keep the version string though.
[13:24] <mzanetti> greyback: yes, that would happen too if we decide to ditch the version field completely (except click system internal)
[13:25] <greyback> mzanetti: yep. Must see what click people would think of the idea
[13:26] <mzanetti> yes
[13:37]  * greyback hates when texlive needs an update
[13:39] <mzanetti> haha
[13:41] <mzanetti> Saviq: can you drive this version number discussion with the click guys?
[13:41] <Saviq> mzanetti, yeah, I will
[13:41] <Saviq> mzanetti, actually, let's just file a bug
[13:46] <Saviq> mzanetti, greyback, bug #1251635
[13:46] <Saviq> please add your comments if you have something to add
[13:56] <nic-doffay> Saviq, I think there's an issue with the inverse mouse area. I've included it as a child of the filter delegate as you can see in this pastebin: http://pastebin.ubuntu.com/6421305/
[13:56] <nic-doffay> The problem is the last InverseMouseArea swallows everything.
[13:56] <nic-doffay> So the first filter in the list cannot be clicked.
[13:56] <nic-doffay> Am I making sense?
[13:57] <Saviq> nic-doffay, you need to only enable the InverseMouseArea when the filter is expanded
[13:57] <Saviq> nic-doffay, although there's https://code.launchpad.net/~aacid/ubuntu-ui-toolkit/ima_do_not_filter_disabled/+merge/194830
[13:57] <Saviq> nic-doffay, which you're probably hitting if you have multiple IMAs
[14:01] <nic-doffay> Saviq, that's probably it then.
[14:13] <mterry> Saviq, who's upstart savvy that we can poke for my set-mir-socket branch?
[14:14] <Saviq> mterry, I poked ogra yesterday, at least to point at someone else if he does not want to, but seems I didn't get his attention
[14:15] <mterry> Saviq, poking him in #ubuntu-touch
[14:30] <Saviq> nic-doffay, standup
[14:40]  * kgunn wonders if this is why people resist updating...rebooting
[14:59] <Cimi> tsdgeos, so both FilterGrid and Carousel are inside Components. I wanted to write a DashRenderer so instead inheriting from Item they were subclassing DashRenderer
[15:02] <tsdgeos> right
[15:02] <tsdgeos> so we talked with Saviq about this the other day
[15:03] <tsdgeos> damn i half broke my s key when cleaning the shit under it
[15:03] <tsdgeos> left me try to reassemble it
[15:03] <tsdgeos> better
[15:03] <tsdgeos> Cimi: the conclusion we reached is that from a separation point of view
[15:04] <tsdgeos> what made more sense is having the DashBaseRender in Dash/
[15:04] <tsdgeos> and then you do a DashFilterGrid that is a DashBaseRender and contains a FilterGrid and forward the neccessary signals/properties
[15:04] <tsdgeos> Saviq: am i right that is that on what we agreed?
[15:04] <tsdgeos> Saviq: am i right that is that on what we agreed?
[15:04] <tsdgeos> sorry :D
[15:05] <Saviq> tsdgeos, unfortunately, yes
[15:05] <Saviq> tsdgeos, Cimi, but that's the only way for us to separate the FilterGrid and Carousel from the Dash indeed
[15:05] <Saviq> those two should remain agnostic, since we might push them to the SDK at some point
[15:06] <Cimi> Carousel in sdk :'(
[15:06] <Cimi> I fear terrible abuse of it
[15:07] <dednick> mhr3: hm.. through a very lucky random set of events, I think the dash is getting away with dee updates coming through directly from glib. not that it shouldn't be fixed though.
[15:08] <Saviq> Cimi, might
[15:08] <Saviq> Cimi, not will
[15:37] <mhr3> dednick, how come?
[15:38] <mhr3> also, not liking being lucky
[15:48] <dednick> mhr3: erm, dunno, looks like it's only reset which issues immediate deleteLater calls on a model items remove seems seems to go through some other chain. Not sure when reset gets called on dee model. think it's only if underlying model changes.
[15:48] <dednick> mhr3: that's a qt model reset i'm talkin about
[15:48] <mhr3> right
[15:48] <mhr3> it can happen though
[15:49] <mhr3> and actually first synchronization should trigger a reset
[15:49] <mhr3> although at that point the model is empty
[15:49] <mhr3> so perhaps there's nothing to deleteLater
[15:50] <dednick> mhr3: yah.
[15:50] <dednick> mhr3: can sync change?
[15:50] <mhr3> a simple call to DeeListModel::setModel() to change the model would trigger a reset
[15:51] <dednick> mhr3: indeed. but we presumably aren't using that.
[15:51] <dednick> when it's not empy i mean
[15:51] <mhr3> at least not in the common paths
[15:52] <mhr3> i just hate knowing about races...
[15:52] <mhr3> why did you tell me about it? :P
[15:52] <dednick> anyway. it's still wrong, and we're just lucky
[15:52] <mhr3> yea
[15:52] <dednick> mhr3: hehe. i didnt. you waved your hand
[15:52] <mhr3> heh, see, and i was right, there's no bug in dee
[15:53] <mhr3> it's qt that's buggy :P
[15:53] <dednick> mhr3: hehe, yeah
[15:55] <dednick> anyway, i've pimped the even sending mech so you only really need 1 extra line to send the event. slicker'than'snot.
[15:55] <dednick> still sucks though..
[16:06] <mhr3> dednick, i'd rather see a patch to qt's deleteLater tbh
[16:12] <dednick> mhr3: hm. it still doesn't get away from the fact that qt does not support what they call "alien context". That linked bug showed another issue seemingly not realted to deleteLater.
[16:15] <dednick> mhr3: however, i dont really agree with that assessment, seeing as it is actually the same context...
[16:16] <mhr3> dednick, the other bug mentions use cases with moving qobjects between threads... i don't think we care about that
[16:16] <mhr3> dednick, so right now i'd see deleteLater as the *only* problem
[16:16] <dednick> mhr3: oh right. well i think you're supposed to call moveToThread or something in that case...
[16:17] <mhr3> yea, whatev, we don't care
[16:21] <mhr3> tsdgeos, question - all of our QAbstractItemModel implementations don't implement parent(), columnCount() nor index(), how the hell is it possible that it compiles seeing that all of those are pure virtual?
[16:22] <tsdgeos> mhr3: because we are implemnting QAbstractListModel ?
[16:22] <mhr3> aaaaaah
[16:22] <mhr3> stupid four letters inside a long word
[16:22] <mhr3> my brain optimizes that out :)
[17:41] <Cimi> Saviq, in many files I'm noticing the lack of import Ubuntu.Components but still using for example units.gu()
[18:03] <axisys> I wanted to enable 3d widows with ccsm and that's when I lost the alt+ctlr+arrow functionality.. removed ccsm and compiz-plugin-extras since then..
[18:03] <axisys> even the workspace switch does not work when pick a running application from different workspace
[18:04] <axisys> keyboard shortcut shows the right setting.. but no worky
[18:04] <axisys> something needs reset/restore .. lets hope I dont need to re-install ubuntu
[18:04] <bschaefer> axisys, hello, so are you having problems with Ctrl+Super+RIght/Left?
[18:05] <bschaefer> axisys, take a look in ccsm -> Desktop Wall -> Keybindings
[18:05] <axisys> Ctrl+Alt+Right/Left
[18:05] <axisys> bschaefer: so reinstall ccsm ?
[18:05] <axisys> Ctrl+Super+RIght/Left works
[18:05] <bschaefer> axisys, yeah opps, Alt+Ctrl :)
[18:05] <bschaefer> Take a look in Desktop Wall plugin
[18:06] <axisys> i was hoping to restore back to initial unity without re-installing ccsm
[18:06] <bschaefer> axisys, its all stored in a binary :(, so you'll have to go through ccsm or possibly gconf?
[18:07] <bschaefer> ccsm isn't that bad
[18:07] <axisys> if I hit Alt+Ctrl+right/left I get C or D in the terminal :-(
[18:07] <bschaefer> Yeah sounds like Compiz doesn't have a grab on those keys
[18:07] <axisys> ok re-installing ccsm
[18:08] <bschaefer> axisys, im guessing what happened, when you enabled 3d windows, it had some hotkeys that Desktop Wall shared, and removed them
[18:08] <bschaefer> so you'll just have to go back and poke Desktop Walls keybindings back to default
[18:10] <axisys> ccsm installed.. I see Desktop Wall is disabled.. like you hinted
[18:10] <axisys> ok.. its back!!
[18:10] <axisys> bschaefer: thanks a lot
[18:10] <bschaefer> axisys, np!
[18:11] <axisys> I guess need to install compiz-plugins-extras for wobbly window?
[18:11] <axisys> I am asucker for wobbliness :-)
[18:11] <axisys> a sucker
[18:11] <bschaefer> axisys, yeah I believe its in there :)
[18:12] <bschaefer> axisys, just pay attention when you see a keybinding conflict
[18:13] <axisys> wobbly window is back too
[18:13] <bschaefer> yay!
[18:14] <axisys> one last thing I need is rotate workspace instead of slide.. that's what broke the workspace switch keybinding last time
[18:14] <bschaefer> hmm rotate workspace?
[18:14] <axisys> I don't need 3d windows
[18:14] <bschaefer> you mean the cube?
[18:14] <axisys> bschaefer: right
[18:14]  * bschaefer doesn't recal if that plays nicely with other plugins
[18:15] <bschaefer> axisys, what you'll want to look at doing is going into the cube and changing the hot keys
[18:15] <bschaefer> so it doesn't conflict with the Desktop Wall plugin
[18:15] <axisys> bschaefer: cube or right swithcer
[18:15] <bschaefer> but...I think the cube might disable the Desktop Wall
[18:16] <axisys> so no cube then.. np
[18:16] <bschaefer> let me take a look to see if its a hard depend
[18:16] <axisys> I am looking for a animated way to switch workspace
[18:16] <bschaefer> but thats what im thinking
[18:18] <bschaefer> axisys, well you'll have to replace the desktop wall with that, there should be some more but i've not really used them :(
[18:19] <axisys> bschaefer: that's fine.. I maily needed wobbly window.. I can live without the rest
[18:19] <axisys> bschaefer: thanks for your help
[18:19] <bschaefer> axisys, cool, and np! You can always attempt to reset everything back to default in CCSM
[18:19] <bschaefer> if things go wrong again
[18:19] <bschaefer> in ccsm -> Preferences -> Reset To Default
[18:20] <axisys> bschaefer: can you do it from cli
[18:20] <bschaefer> cli?
[18:20] <bschaefer> command line?
[18:20] <axisys> bschaefer: command line / terminal
[18:20] <bschaefer> axisys, not that  I know of
[18:20] <axisys> bschaefer: thanks
[18:20] <bschaefer> as all the settings are stuff into a binary :(
[18:21] <axisys> :-)
[19:02]  * greyback__ eow
[23:42] <crass> I just upgraded from 13.04 to 13.10, and now keepassx is always goes to fullscreen
[23:42] <crass> I think this is due to a change in unity, can anyone confirm this?