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