| pero | i've lost my the Unity Webapps extension in Chromium - yet everything seems installed ok - any way to get it back? | 03:01 |
|---|---|---|
| === Zhenech_ is now known as Zhenech | ||
| tsdgeos | my clock indicator is gone again | 08:08 |
| * tsdgeos manually starts it | 08:09 | |
| Cimi | tsdgeos, hey :) | 08:46 |
| tsdgeos | Cimi: ho | 08:54 |
| Cimi | tsdgeos, I had a look yesterday | 09:06 |
| Cimi | tsdgeos, and basically it's like your work plus something else | 09:06 |
| 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:07 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| tsdgeos | then we need to make it clear in the doc of that common interface | 09:13 |
| tsdgeos | Cimi: afaiu that was also Saviq's position, but you may want to check with him | 09:38 |
| Cimi | ok | 09:38 |
| 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:40 |
| tsdgeos | +1 | 09:41 |
| Saviq | Mirv, hey, we got a fix in upstream Qt that would fix unity8's FTBFS with 5.2 | 09:44 |
| 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:45 |
| Saviq | Mirv, there's one more related in review: https://codereview.qt-project.org/#change,71327 | 09:48 |
| 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 | 09:52 |
| Mirv | Saviq: oh cool. the RC should on Tuesday | 10:08 |
| Mirv | Saviq: I can put it in as a patch | 10:08 |
| 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:10 |
| tsdgeos | hmmm | 10:16 |
| tsdgeos | are we using VideoInfo.qml? | 10:17 |
| tsdgeos | or AppInfo.qml? | 10:19 |
| 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:20 |
| Saviq | or hmm | 10:21 |
| Saviq | tsdgeos, it *was* part of the app preview, looks like it's moved to Header, since, I think | 10:22 |
| 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:23 |
| 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:25 |
| 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:26 |
| Saviq | tsdgeos, ah, got it | 10:27 |
| nic-doffay | Saviq, any bugs you can recommend for me to take a look at? | 11:04 |
| tsdgeos | nic-doffay: how's the filter expansion one going? needs review or still wip? | 11:06 |
| 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:10 |
| Saviq | nic-doffay, https://code.launchpad.net/~nicolas-doffay/unity8/filter-selector/+merge/191145/comments/450251 that says it isn't ready ;) | 11:11 |
| 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:12 |
| Saviq | tsdgeos, ah, you only did a "don't filter if disabled" | 11:13 |
| 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:14 |
| 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:15 |
| nic-doffay | Saviq, sure | 11:18 |
| nic-doffay | Saviq, either way it looks like I'll be busy with those changes. | 11:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| tsdgeos | Saviq: https://code.launchpad.net/~aacid/unity8/remove_unused_info_files/+merge/195365 | 11:23 |
| Saviq | tsdgeos, thanks | 11:51 |
| mzanetti | Saviq: the click package upgrading feels a bit like BAMF :) | 12:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| Saviq | fail-safe - find the latest one alphabetically | 12:32 |
| * Saviq wonders if QStandardPaths::locate supports wildcards | 12:35 | |
| Saviq | nope :/ | 12:37 |
| 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:41 |
| Saviq | tsdgeos, hmm maybe locateAll does not? | 12:42 |
| tsdgeos | hmm | 12:42 |
| tsdgeos | ok, actually not | 12:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| Saviq | tsdgeos, so ~/.local/share/applications, /usr/share/applications | 12:50 |
| Saviq | tsdgeos, if I use the full file name, it works | 12:50 |
| tsdgeos | let me ask david | 12:51 |
| tsdgeos | oh, he's not online | 12:51 |
| Saviq | mzanetti, on that note... (how) do we remove pinned items for apps that are removed? | 12:52 |
| mzanetti | Saviq: we don't right now | 12:55 |
| Saviq | mzanetti, yeah I'm not sure what we should do TBH | 12:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 12:59 |
| mzanetti | so it's linked (without version information) to a user specific dir | 13:00 |
| Saviq | right | 13:00 |
| Saviq | that looks internal to the click system, though | 13:01 |
| 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:02 |
| mzanetti | .cache ? | 13:03 |
| === pstolowski is now known as pstolowski|lunch | ||
| 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:03 |
| 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:04 |
| Saviq | and it hurts us where we store/match it | 13:05 |
| mzanetti | yeah | 13:05 |
| greyback | +1 | 13:05 |
| Saviq | we should talk to cjwatson / barry about this | 13:06 |
| Saviq | maybe even upstart shouldn't care about them | 13:06 |
| 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:07 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| mzanetti | greyback: what's the problem with system apps? | 13:13 |
| 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:14 |
| 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:15 |
| === alan_g is now known as alan_g|lunch | ||
| greyback | mzanetti: oh, how does shell know if app updated or removed? | 13:16 |
| 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:17 |
| mzanetti | assuming an upgrade wouldn't remove it and then recreate it a few seconds later | 13:18 |
| 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:23 |
| mzanetti | greyback: yes, that would happen too if we decide to ditch the version field completely (except click system internal) | 13:24 |
| greyback | mzanetti: yep. Must see what click people would think of the idea | 13:25 |
| mzanetti | yes | 13:26 |
| * greyback hates when texlive needs an update | 13:37 | |
| mzanetti | haha | 13:39 |
| 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:41 |
| Saviq | mzanetti, greyback, bug #1251635 | 13:46 |
| ubot5 | bug 1251635 in click (Ubuntu) "drop version numbers from users' .desktop file names" [Undecided,New] https://launchpad.net/bugs/1251635 | 13:46 |
| Saviq | please add your comments if you have something to add | 13:46 |
| 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:56 |
| 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 | 13:57 |
| nic-doffay | Saviq, that's probably it then. | 14:01 |
| === pstolowski|lunch is now known as pstolowski | ||
| mterry | Saviq, who's upstart savvy that we can poke for my set-mir-socket branch? | 14:13 |
| 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:14 |
| mterry | Saviq, poking him in #ubuntu-touch | 14:15 |
| === alan_g|lunch is now known as alan_g | ||
| Saviq | nic-doffay, standup | 14:30 |
| * kgunn wonders if this is why people resist updating...rebooting | 14:40 | |
| 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 | 14:59 |
| tsdgeos | right | 15:02 |
| tsdgeos | so we talked with Saviq about this the other day | 15:02 |
| 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:03 |
| tsdgeos | what made more sense is having the DashBaseRender in Dash/ | 15:04 |
| === rachelliu_ is now known as rachelliu | ||
| 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:04 |
| 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:05 |
| Cimi | Carousel in sdk :'( | 15:06 |
| Cimi | I fear terrible abuse of it | 15:06 |
| 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:07 |
| Saviq | Cimi, might | 15:08 |
| Saviq | Cimi, not will | 15:08 |
| === alan_g is now known as alan_g|tea | ||
| mhr3 | dednick, how come? | 15:37 |
| mhr3 | also, not liking being lucky | 15:38 |
| === alan_g|tea is now known as alan_g | ||
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| mhr3 | it's qt that's buggy :P | 15:53 |
| dednick | mhr3: hehe, yeah | 15:53 |
| 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.. | 15:55 |
| mhr3 | dednick, i'd rather see a patch to qt's deleteLater tbh | 16:06 |
| 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:12 |
| dednick | mhr3: however, i dont really agree with that assessment, seeing as it is actually the same context... | 16:15 |
| 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:16 |
| mhr3 | yea, whatev, we don't care | 16:17 |
| 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:21 |
| 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 :) | 16:22 |
| === jono is now known as Guest50394 | ||
| Cimi | Saviq, in many files I'm noticing the lack of import Ubuntu.Components but still using for example units.gu() | 17:41 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:10 |
| 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:11 |
| bschaefer | axisys, just pay attention when you see a keybinding conflict | 18:12 |
| axisys | wobbly window is back too | 18:13 |
| bschaefer | yay! | 18:13 |
| 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:14 | |
| 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:15 |
| 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:16 |
| 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:18 |
| 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:19 |
| 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:20 |
| axisys | :-) | 18:21 |
| * greyback__ eow | 19:02 | |
| === Pici is now known as Guest25996 | ||
| === Guest25996 is now known as Pici | ||
| 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? | 23:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!