| MacSlow | veebers, mzanetti: my GoogleHangout-plugin keeps telling me I need to update... can't connect atm | 07:31 |
|---|---|---|
| dednick | larsu: ping | 07:57 |
| larsu | dednick: good morning | 08:02 |
| dednick | larsu: morning. you in europe at the moment? seems a bit early for you. :) | 08:02 |
| larsu | dednick: yep, I'm in Europe (and will stay here for the time being) | 08:03 |
| dednick | larsu: ah ic. | 08:04 |
| dednick | larsu: aanyway. what was the consensus about the icons on friday? are we going for a uri for everything from now? | 08:04 |
| larsu | dednick: yep, uris. We don't have them for everything yet, though | 08:05 |
| larsu | dednick: unitymenumodel has that, except in the action state of the root menu item, which I'm not sure how to solve yet | 08:06 |
| larsu | dednick: because I don't know which things in an action might be icons, unless I teach unitymenumodel about indicators | 08:07 |
| dednick | larsu: larsu. yeah. not the best option though. i guess. | 08:08 |
| dednick | larsu: er, not an option for enforce icon format on server side? | 08:08 |
| dednick | would require changing all indicators though... | 08:09 |
| larsu | we could just say the indicators may only use icon names in there, without fallbacks | 08:10 |
| larsu | but someone will probably need something more complicated at some point... | 08:10 |
| sil2100 | Saviq: hi! Unity8 published | 08:10 |
| larsu | dednick: can you just assume they're icon names for now? Or did you already stumble across a weird one? | 08:11 |
| mzanetti | sil2100: Saviq is on IOM | 08:11 |
| sil2100 | mzanetti: ok, thanks, I was just informing anyway | 08:11 |
| dednick | larsu: getting a gthemedicon | 08:11 |
| dednick | from power | 08:11 |
| dednick | larsu: could write something in unity8 which operates on top of the unitymodel which knows indicators. | 08:12 |
| Saviq | sil2100, thanks | 08:13 |
| larsu | dednick: yeah that'd work, but then we'd duplicate the icon-unpacking code in unitymenumodel (even though it's only a couple of lines, really) | 08:15 |
| larsu | dednick: how about I give you a js function to do it for now? Or do you have a c++ plugin anyway? | 08:15 |
| sil2100 | Mirv: https://code.launchpad.net/~sil2100/cupstream2distro-config/media_extra_package/+merge/177328 <- can you review? ;) | 08:16 |
| dednick | larsu: i dont have anything at the moment. js would be good. | 08:16 |
| tsdgeos | sil2100: so we are autoreleasing? | 08:16 |
| larsu | dednick: okay, will do that today. (bbiab) | 08:16 |
| sil2100 | tsdgeos: yes, although we're autoreleasing to the ubuntu-unity/next PPA right now | 08:18 |
| tsdgeos | nice :-) | 08:18 |
| sil2100 | Mirv: you think it's ok? | 08:23 |
| dednick | larsu: actually, i think it might be best if I write a root stateAction wrapper for unity8 which knows about its format. I htink i need it anyway to work with the old format of the action. | 08:30 |
| dednick | s/stateAction/actionState | 08:31 |
| Mirv | sil2100: looks good to allow, even though the package is not yet in archives yet | 08:35 |
| sil2100 | Mirv: yes, it's a new package, but it's part of an existing source package in the archives | 08:36 |
| sil2100 | So it's cool | 08:37 |
| Mirv | yep, found the address-book-app | 08:37 |
| sil2100 | Mirv: thanks! I'll redeploy and re-run ;) | 08:37 |
| sil2100 | Mirv: eeek! | 08:38 |
| sil2100 | One moment | 08:39 |
| sil2100 | Mirv: eek! | 08:39 |
| sil2100 | Mirv: I modified the wrong stack, but I fixed it now ;) | 08:42 |
| * sil2100 needs coffee | 08:42 | |
| * mzanetti too | 08:42 | |
| Mirv | sil2100: ah... I just stared at the diff, too | 08:44 |
| sil2100 | Not sure why I thought 'media' instead o 'phone' o_O | 08:44 |
| mzanetti | larsu: still need me to check out that issue? | 08:48 |
| larsu | mzanetti: yeah, that'd be great | 08:53 |
| mzanetti | larsu: ok. can you give me short summary how to reproduce it? | 08:53 |
| larsu | mzanetti: yep. Grab my qmenumodel branch at lp:~larsu/qmenumodel/add-unitymenumodel | 08:54 |
| larsu | mzanetti: are you on saucy? | 08:54 |
| mzanetti | larsu: yes | 08:54 |
| larsu | mzanetti: awesome, then you can just do the cmake dance to build it | 08:55 |
| larsu | mzanetti: I think it only builds in-tree. Complain to renato about that one please :P | 08:55 |
| mzanetti | larsu: done with building | 08:55 |
| mzanetti | larsu: btw... built out of source | 08:55 |
| mzanetti | no complains | 08:56 |
| larsu | mzanetti: cool. he fixed it, then | 08:56 |
| larsu | mzanetti: just start the included example: qmlscene -I libqmenumodel/ examples/unityqmlmenumodel.qml | 08:56 |
| larsu | mzanetti: it's the sound menu, but a bit rough :) | 08:56 |
| larsu | mzanetti: click on the first item, and you should see the sound menu itself. Second item is the volume. Changing the volume on your system should change the number in there | 08:57 |
| larsu | but it doesn't... | 08:57 |
| mzanetti | larsu: I don't see anything in the second entry | 08:58 |
| mzanetti | larsu: its just an empty grey rectangle | 08:58 |
| mzanetti | larsu: http://wstaw.org/m/2013/07/29/plasma-desktopaC8715.png | 08:58 |
| larsu | mzanetti: that's right: the one right under "Mute" | 08:59 |
| larsu | mzanetti: it says 0.75, that's your volume in [0,1] | 08:59 |
| mzanetti | larsu: right... got it | 08:59 |
| mzanetti | larsu: ok. on it | 08:59 |
| larsu | mzanetti: thanks! | 09:00 |
| larsu | dednick: fine by me, but there's a small problem: we need to deserialize the icon before doing the gvariant -> qvariant conversion | 09:00 |
| larsu | dednick: so once it's in actionState, it's really too late | 09:01 |
| larsu | dednick: I'm considering hacking it into unitymenumodel, despite the ugliness: if (key == "icon) deserialize(icon) | 09:01 |
| dednick | larsu: i'm reversing the qvariant serialization ;) | 09:07 |
| dednick | dont know if that's wise though... | 09:07 |
| larsu | dednick: ya... not so wise. These might be bytearrays with raw image data. Converting them all the time is a tad wasteful | 09:09 |
| larsu | dednick: should be okay for now though, as everything is themed afaik | 09:09 |
| tsdgeos | guys, waiting for the phablet image download to finish, any quick review you awnt me to tackle meanwhile? | 09:11 |
| dednick | larsu: is there no way to tell that the GVariant from g_icon_serialise is a gicon type? | 09:17 |
| larsu | dednick: no, it doesn't contain a header | 09:17 |
| dednick | larsu: actually. why is the icon in the action? why not in the menu? | 09:17 |
| larsu | dednick: because it might change | 09:19 |
| larsu | menus are immutable | 09:19 |
| dednick | larsu: ah. ok | 09:19 |
| larsu | dednick: the more I think about it, the more I'm of the opinion that unitymenumodel should just know about indicators | 09:22 |
| larsu | dednick: this will make your life much easier | 09:22 |
| dednick | larsu: i think it's going to be used for other things though... | 09:22 |
| larsu | dednick: and since you're the only consumer right now, it makes a lot of sense | 09:22 |
| larsu | dednick: ya, maybe the settings app. That's okay though | 09:22 |
| dednick | larsu: problem is that i dont do a key=="icon". i just get the actionState variant. | 09:23 |
| larsu | dednick: ya. That's why I'm proposing what I'm proposing right now: | 09:23 |
| larsu | UnityIndicator { name: "" } | 09:24 |
| larsu | you'll then have indicator.icon, indicator.label, indicator.menu | 09:24 |
| larsu | where menu is a qabstractitemlist | 09:24 |
| dednick | larsu: i think the notifications are also using gmenumodel. | 09:24 |
| larsu | err, model | 09:24 |
| larsu | dednick: what? I hope not.... | 09:25 |
| dednick | larsu: i mean dialogs. | 09:25 |
| dednick | or something. MacSlow ^ | 09:25 |
| larsu | dednick: even so, this would be additional API | 09:25 |
| larsu | so no worries there | 09:25 |
| dednick | ok | 09:25 |
| mzanetti | larsu: found it | 09:26 |
| mzanetti | larsu: so what happens is this: | 09:26 |
| mzanetti | larsu: the QML file starts up and the model for the listview is model is UnityMenuModel(0xa58980) | 09:26 |
| larsu | dednick: okay, I'll crib your indicator-file loading code then and hack it this afternoon. Can you wait that long? | 09:26 |
| mzanetti | larsu: then you click the item which calls submenu() | 09:26 |
| mzanetti | larsu: in there you do a new MenuModel() and set the listview's model to: UnityMenuModel(0xac0700) | 09:27 |
| MacSlow | dednick, larsu: notifications a not yet using gmenumodel... but are meant to do soon to support recently added requirements from Design | 09:27 |
| mzanetti | larsu: then I press the volume key and guess which model emits the dataChanged: UnityMenuModel(0xa58980) | 09:27 |
| MacSlow | dednick, larsu: what's wrong with that? | 09:27 |
| larsu | MacSlow: what requirements are those? | 09:27 |
| larsu | mzanetti: FACEPALM! | 09:27 |
| larsu | mzanetti: thanks a lot man, I must've been braindead to not think of that | 09:28 |
| mzanetti | larsu: :) | 09:28 |
| MacSlow | larsu, password-entry... listview (for wifi-spots) | 09:28 |
| mzanetti | larsu: no problem | 09:28 |
| mzanetti | larsu: btw. a few hints on debugging: | 09:28 |
| dednick | larsu: yeah, think afternoon should be ok. | 09:28 |
| mzanetti | larsu: you can have for _EVERY_ property a onPropertynameChanged which you can print() stuff | 09:28 |
| mzanetti | larsu: you can also print() objects in QML. It'll print the class name and the memory address | 09:29 |
| mzanetti | just like qDebug() in c++ would do | 09:29 |
| larsu | mzanetti: ah, cool! | 09:29 |
| larsu | mzanetti: but onPropertyNameChanged only works if I have a NOTIFY on my property, right? | 09:30 |
| larsu | MacSlow: we show a list of wifi spots in the notification? | 09:30 |
| MacSlow | larsu, Design requires that yes | 09:31 |
| mzanetti | larsu: right... but if your property can change and does not have a NOTIFY signal you should think of that as a bug :) | 09:31 |
| MacSlow | larsu, it's not supported right now... but I've to make it happen | 09:31 |
| larsu | MacSlow: I don't even know what to to say to that...... :P (in that case you're right: gmenumodel is a good fit) | 09:31 |
| larsu | mzanetti: right, that makes sense :) | 09:32 |
| MacSlow | larsu, what was the initial issue you/dednick pinged me about? | 09:32 |
| MacSlow | larsu, that's still not clear to me | 09:32 |
| mzanetti | larsu: if it doesn't change, mark it as CONSTANT in the property definition. that avoids those messages "property foobar does depend on non-notifyable property" | 09:32 |
| larsu | MacSlow: we were just trying to find other consumers of qmenumodel | 09:33 |
| dednick | MacSlow: just wanted to know what was goint to be using qmenumodel | 09:33 |
| dednick | larsu: I dont know if UnityIndicator belongs in qmenumodel. | 09:33 |
| dednick | doesnt sound right | 09:33 |
| MacSlow | larsu, dednick: ah ok | 09:33 |
| larsu | mpt: what is this madness that MacSlow is talking about? (notifications that contain the list of wifi spots) | 09:33 |
| MacSlow | larsu, dednick: https://wiki.ubuntu.com/Networking#wifi-connecting-prompted | 09:34 |
| larsu | dednick: we can put it into unity8 as well, I don't care where it lives. It just shouldn't use unitymenumodel for the top-level menu | 09:35 |
| mzanetti | larsu: also, without fully studying the whole code, I have a feeling you're leaking the submenu | 09:35 |
| mzanetti | I might be wrong tho... but it looks like | 09:35 |
| larsu | dednick: which means it shares quite some code with unitymenumodel, which is why I was thinking of putting it there in the first place | 09:35 |
| dednick | larsu: are you proposing we dont give it bus info? that it parses it itself? | 09:36 |
| dednick | larsu: re you cribbing the file loading. | 09:36 |
| larsu | MacSlow: I thought you said in a notification, that looks like a dialog to me... | 09:36 |
| larsu | dednick: yep | 09:36 |
| larsu | mzanetti: I thought I was parenting it to the parent model. Let me check. | 09:38 |
| dednick | larsu: hmmmm.... we need to find the files to know what to load in the first place and fetch priority etc. dont think it's necessary to change that mech. | 09:39 |
| MacSlow | larsu, I know... but it has to happen in a notification. It's not my decision | 09:39 |
| mpt | nonsense | 09:43 |
| larsu | mpt: ya, unping. I misunderstood, sorry. | 09:43 |
| larsu | dednick: I don't know enough about your current architecture to make an informed decision here... I'm just trying to keep all the GVariant/GIcon handling in one codebase | 09:45 |
| larsu | dednick: alternatively, we can also move unitymenumodel into unity8 | 09:45 |
| larsu | dednick: which is something I've thought of before, but dismissed it because there might be other consumers soon | 09:45 |
| mpt | larsu, when I showed those wireframes to Oren he said, "Oh, snap decisions, ask Mirco if they can contain those controls", so I asked MacSlow, and he said no. | 09:46 |
| larsu | mpt: "those controls" being that full dialog? | 09:46 |
| mpt | larsu, a scrolling list in the first case, and two labelled text fields in the second. | 09:47 |
| mpt | larsu, other examples of that component can be found in <https://wiki.ubuntu.com/SecurityAndPrivacySettings#SIM_PIN>. | 09:48 |
| MacSlow | mpt, in the meantime I've been asked to make it possible to add the needed controls to a notification via a new extension and gmenumodel ... not sure if you got notified about that yet | 09:48 |
| mpt | MacSlow, no I hadn't. It seems like the sort of thing that would make app developers wonder what substances we'd been taking. :-) | 09:48 |
| larsu | mpt: these all look like dialogs to me, I don't know why we would drag that information through the notification framework | 09:49 |
| mpt | larsu, exactly. The only difference between these and sheets is that these don't take up the full screen. | 09:49 |
| mpt | (Because they are simple enough to do that, and showing context of the app behind them helps.) | 09:50 |
| MacSlow | mpt, larsu: I'm not too happy to have been tasked with this to be honest... it still doesn't feel right... conceptually... visuals a similar... but that's it | 09:52 |
| larsu | mpt: do these have _anything_ in common with notifications? Like, should they be queued like notifications are? | 09:52 |
| mpt | larsu, no, they appear immediately modal to the parent surface | 09:52 |
| MacSlow | mpt, larsu: as far as I can tell... they should not timeout... they should block any notifications... anything else I might be missing? | 09:53 |
| dednick | larsu: how about having an ActionStateParser object property on the model? have a default one which just spits out GVariant -> QVariant straight conversion, but can be overridden by custom impl. submodels will just use the default, or can pass in a QmlComponent to override | 09:53 |
| mpt | MacSlow, I don't see why they should block notifications at all. They're unrelated. | 09:53 |
| larsu | MacSlow: who made the decision to do these as notifications? Maybe there's a reason we're overlooking | 09:54 |
| larsu | dednick: and you'd supply one that calls g_icon_deserialize() from unity8? | 09:54 |
| dednick | larsu: yep. | 09:55 |
| MacSlow | mpt, larsu: then please talk to Saviq regarding this, but he's busy at the IOM atm though... not sure how much time he has. | 09:55 |
| mpt | ok | 09:55 |
| Saviq | MacSlow, I'm sitting next to mpt now ;) | 09:55 |
| MacSlow | Saviq, aoh.. :) | 09:55 |
| MacSlow | Saviq, well then | 09:55 |
| MacSlow | Saviq, I just shut up then :) | 09:55 |
| larsu | perfect :) | 09:55 |
| Saviq | MacSlow, we'll try and find some time to chat then | 09:55 |
| larsu | MacSlow: thanks for bringing this to our attention :) | 09:55 |
| dednick | larsu: UnityMenuModel { ... actionStateParser: RootActionParser {} } | 09:56 |
| larsu | dednick: that sounds like the solution with the best tradeoffs (least work and not as ugly as the hacks I thought of in the beginning). I like it :) | 09:56 |
| MacSlow | Saviq, mpt, larsu: when you schedule anything (mumble, hangout) please sent me an invite... I'd like to make sure I follow what's going on with this. | 09:56 |
| dednick | larsu: only setback is we don't keep the gicon serialisation code in one place. | 09:57 |
| dednick | larsu: but it's only a few lines, so should be ok. | 09:57 |
| dednick | larsu: should i give it a go. i've got some time and know what i need :) | 09:58 |
| larsu | dednick: yeah, but I can live with that. It won't change that much I guess, and we'll probably need that code in unity anyway | 09:58 |
| larsu | dednick: there's a function in unitmenumodel that handles most cases already. I'll paste it for you when I have the ActionStatePArser patch | 09:59 |
| Saviq | larsu, just to recap - notifications were meant to only be used to trigger the dialog, we can just build a completely separate backend for them, but a big set of it is going to be exactly the same as notifications | 10:02 |
| Saviq | larsu, and also, at least the password entry dialogs have been snap decisions in the spec - I haven't seen any "system dialogs" spec to tell me otherwies | 10:03 |
| Saviq | larsu, so I thought the app sending an interactive notification with system-dialog-hint would be a good enough solution | 10:05 |
| Saviq | larsu, I understand that's abusing the notifications spec, but we're already doing a *lot* of that (as in canonical's notifications are barely compatible with freedesktop ones anyway) | 10:09 |
| larsu | Saviq: thanks for clearing up were this is coming from. | 10:09 |
| larsu | Saviq: I'm okay with abusing the spec, it's shitty anyway. The problem I see is that we're piping more and more UI through the bus | 10:10 |
| larsu | Saviq: the whole menu model stuff is already pretty far out there, now we're adding dialogs | 10:10 |
| larsu | Saviq: soon we'll have dbus-toolkit! | 10:10 |
| Saviq | larsu, it's there already, isn't it... | 10:10 |
| Saviq | larsu, and we can say that we're only supporting password (SIM-PIN, too) and wifi selection - and only support those | 10:11 |
| Saviq | larsu, but really whatever else we do is still going to be building another solution to a problem we've already solved for indicators | 10:12 |
| larsu | Saviq: yeah, that's the approach we took with the indicators as well. | 10:12 |
| larsu | Saviq: so that network list in the dialog is dynamic? | 10:12 |
| larsu | Saviq: that'll make piping it through notifications ... interesting | 10:13 |
| Saviq | larsu, dynamic in the sense that the backend needs to fill it, yes, and update it periodically, I'd say | 10:13 |
| Saviq | larsu, but no | 10:13 |
| Saviq | larsu, we want to fire an interactive notification through notifications | 10:13 |
| larsu | Saviq: ah right. That's much more sensible and doesn't require gmenumodel at all | 10:13 |
| Saviq | larsu, but then *menumodel takes over | 10:13 |
| larsu | ah, so this is where I might disagree | 10:14 |
| larsu | (not enirely sure yet, just heard about this half an hour ago) | 10:14 |
| Saviq | larsu, it just felt that trying to shoe-horn it through the notifications interfaces | 10:14 |
| Saviq | larsu, would be more of a hack then using *menumodel | 10:14 |
| Saviq | larsu, we agreed with tedg in OAK that would be a sane solution | 10:15 |
| Saviq | larsu, the added benefit of using notifications IMO would be that the application sending the dialog request could fall back to its own UI when the interactive notification was triggered, when the frontend didn't support system dialogs | 10:16 |
| Saviq | although that might be premature optim, as we're controlling the whole thing anyway | 10:16 |
| Saviq | larsu, and sure, we just limit it to the two-three types of dialog that we're meant to support now - exactly same as we do with indicators | 10:18 |
| larsu | Saviq: I'm not sure I fully understand yet. If there's a gmenumodel-based interface, where do notifications come into play? | 10:19 |
| Saviq | larsu, we need *some* way for the app/service that wants to display a dialog, to tell the shell "hey - I want to display a dialog" | 10:20 |
| Saviq | larsu, and then the UI of the dialog itself - which meant sense to me to use the thing that we're using anyway - *menumodel | 10:20 |
| larsu | Saviq: why not dbus: com.canonical.untiy.DisplayDialog("my.dbus.name", "/path/to/menumodel")? | 10:20 |
| Saviq | larsu, I don't see how that's different from using notifications for it | 10:21 |
| Saviq | larsu, except that we need to reimplement a bunch of priority / timeout considerations | 10:22 |
| Saviq | larsu, that we already have for notifications | 10:22 |
| Saviq | larsu, and then build an interaction between dialogs and notifications | 10:22 |
| Saviq | larsu, that one is more important than others | 10:22 |
| Saviq | larsu, and then there's the fact that the password entry is still spec'ed as a snap decision | 10:23 |
| Saviq | larsu, so that they can queue on screen | 10:23 |
| larsu | Saviq: fair enough. The biggest issue I had was with dubs-tk anyway, but you're not doing that, so I'm kind of okay with your approach | 10:23 |
| Saviq | larsu, yay :) | 10:23 |
| Saviq | MacSlow, ↑ | 10:24 |
| larsu | Saviq: it's a bit hacky, but very practical :) | 10:24 |
| Saviq | larsu, exactly ;) | 10:24 |
| larsu | Saviq: sorry to stir up so much confusion, it just sounded really weird when I first read it | 10:24 |
| * MacSlow reads | 10:24 | |
| larsu | MacSlow: tl;dr: keep calm, carry on. | 10:24 |
| Saviq | :) | 10:24 |
| MacSlow | Saviq, larsu: I'm still trying to make sense of it (how it'll actually work) doing a proof-of-concept thing as I never used qmenumodel before | 10:30 |
| Saviq | larsu, btw, you know *menumodel best, how would you structure the model for a dialog like so https://lh4.googleusercontent.com/goPxF-p_6nxA8PM8vdawkie6HVW4ubTJ-hi_ajOHKUs2IQH34uvqIFLofNPP37GUj7enLg_f9kgaT8kegrKvWa3WyISjMmhGs4kRb8Uw_JWFt0v9Af0fC26f ? | 10:31 |
| Saviq | larsu, we can make the buttons part of the UI or part of the model, whichever's best | 10:31 |
| larsu | MacSlow: use unitymenumodel instead. dednick and I are currently working out some kinks with it, after that you should be able to just use it (as we're using the same thing in the network menu) | 10:32 |
| larsu | Saviq: the connect button is redundant in a touch ui | 10:33 |
| larsu | Saviq: if you go the notification route, the model should only contain the list of access points | 10:34 |
| larsu | Saviq: the "cancel" button would be the standard ui for dismissing a system-modal notification | 10:34 |
| Saviq | larsu, that's not the ultimate design | 10:34 |
| MacSlow | larsu, that's a branch to look at then lp:~larsu/qmenumodel/add-unitymenumodel ? | 10:35 |
| larsu | MacSlow: yes, but I recommend for you to wait a bit if you can until we get its API stable and merged | 10:35 |
| larsu | Saviq: I hope so :P | 10:36 |
| MacSlow | larsu, ok... I'll keep fixing some ap-tests in the meantime | 10:36 |
| Saviq | larsu, problem is, we don't have the ultimate ones | 10:38 |
| Saviq | mpt, do we have a spec for system dialogs? I expect three ATM - wifi selection, wifi password (after disconnection) and SIM-PIN entry (when you've exchanged the SIM, for example) | 10:38 |
| larsu | Saviq: I thought you were sitting next to mpt right now :P | 10:39 |
| Saviq | larsu, I am | 10:39 |
| Saviq | larsu, but in a session | 10:39 |
| mpt | Yes, but we're in a plenary and talking would be rude | 10:39 |
| Saviq | and IRC isn't.... kind of... | 10:39 |
| larsu | mpt: isn't that connect button redundant in a touch ui? | 10:39 |
| larsu | Saviq: hehe, right :) | 10:39 |
| mpt | Saviq, another example at <https://wiki.ubuntu.com/AccountPrivileges#Phone>, without any fancy controls | 10:40 |
| mpt | just buttons | 10:40 |
| Saviq | mpt, right | 10:40 |
| mpt | Saviq, I don't think they're "system" dialogs, really. I'd expect an unprivileged app to be able to use them. | 10:41 |
| === sil2100_ is now known as sil2100 | ||
| sil2100 | hmm | 10:56 |
| pete-woods1 | Saviq, mpt: I'm interested in any developments / decisions regarding the "system dialogs" - I've been asked to help out with the daemon that triggers the "networks available" prompt | 10:58 |
| === MacSlow is now known as MacSlow|lunch | ||
| === pete-woods1 is now known as pete-woods | ||
| Saviq | pete-woods, right, comm fail *again* | 10:58 |
| Saviq | MacSlow|lunch, ↑ | 10:58 |
| Saviq | pete-woods, interface with MacSlow for this please | 10:59 |
| pete-woods | Saviq: sure :) | 10:59 |
| === hikiko is now known as hikiko_lunch | ||
| === MacSlow|lunch is now known as MacSlow | ||
| === hikiko_lunch is now known as hikiko | ||
| MacSlow | Saviq, pete-woods: ok... noted | 12:03 |
| pete-woods | MacSlow: so what is it you're working on with regards to this? basically what I'm looking for is Unity to implement some sort of (dbus?) interface that lets me go "hey! pick a network" | 12:04 |
| === alan_g is now known as alan_g|lunch | ||
| MacSlow | pete-woods, atm the idea is to introduce a new hint to the notification-system,which will allow passing the UI using unitymenumodel (which isn't in lp:qmenumodel yet) the whole communication of UI and triggering application will happen via DBus | 12:07 |
| MacSlow | pete-woods, that's the very rough cut... atm I'm trying to get a proof-of-concept going | 12:08 |
| pete-woods | MacSlow: okay, thanks for the run-down! | 12:09 |
| MacSlow | pete-woods, so in your case - once it implemented/tested/landed - you'd be triggering one such notification using the new hint (probably named something like "x-canoncial-system-dialog") | 12:09 |
| MacSlow | pete-woods, np yw | 12:09 |
| pete-woods | MacSlow: but the impression I'm getting there is I should probably park it for a week maybe? 'til you've got something landed? | 12:09 |
| MacSlow | pete-woods, certainly... I'm new to it myself and it'll take me some days for sure... so a week is reasonable. | 12:10 |
| === _salem is now known as salem_ | ||
| MacSlow | larsu, dednick: I'm trying out the exportmenu.py/render-menumodel.qml from lp:~larsu/qmenumodel/add-unitymenumodel but get numerous "ReferenceError: linkSubMenu is not defined"-errors... what am I missing? | 12:22 |
| larsu | MacSlow: render-menumodel.qml uses the (old) qmenumodel api. Try examples/unitemenumodel.qml instead. | 12:23 |
| larsu | MacSlow: it shows you the sound menu from your system (if you | 12:24 |
| larsu | 're running saucy) | 12:24 |
| MacSlow | larsu, hm... now getting "UnityMenuModel is not a type", I'm probably not correctly exposing the compiled branch | 12:25 |
| larsu | MacSlow: `qmlscene -I libqmenudemodel/ examples/unitymenumodel` from the root of the repository | 12:26 |
| larsu | MacSlow: unitymenumodel.qml of course | 12:26 |
| MacSlow | larsu, hm... still getting this: module "QMenuModel" plugin "qmenumodel-qml" not found | 12:27 |
| === jhodapp|afk is now known as jhodapp | ||
| larsu | MacSlow: does `find . -name libqmenumodel-qml.so` return ./libqmenumodel/QMenuModel/libqmenumodel-qml.so? | 12:30 |
| MacSlow | larsu, doh... my bad... I used a build-directory... with the correct path it works | 12:32 |
| larsu | MacSlow: ah, right, I always build it in-tree because out-of-tree didn't work a while ago | 12:32 |
| dednick | larsu: indicator-network doesn't seem to be exporting a root action. | 12:34 |
| dednick | larsu: is that a known? | 12:34 |
| larsu | dednick: on the desktop or the device? | 12:35 |
| dednick | larsu: at least device. | 12:35 |
| larsu | dednick: on the desktop: definitely known (it doesn't use the new indicator stack on the desktop yet) | 12:35 |
| larsu | dednick: ah, okay. Probably known, but not to me :) | 12:36 |
| larsu | dednick: I'll pester tedg about it | 12:36 |
| dednick | larsu: ok. desktop indicator - phone profile | 12:36 |
| larsu | dednick: ya, no such thing yet. tedg is working on it afaik | 12:37 |
| dednick | larsu: yeah, he added it a little while ago. guess just not finished yet. | 12:37 |
| dednick | larsu: how do we update action states? eg mute | 12:45 |
| larsu | dednick: you shouldn't need to. Call listview.model.activate(index) like in the example, that will activate the action with the right parameter | 12:48 |
| larsu | dednick: in the case of mute, it will toggle it | 12:49 |
| dednick | larsu: volume slider? | 12:49 |
| mzanetti | Cimi: ping | 12:50 |
| === dednick is now known as dednick|afk | ||
| larsu | dednick: right, for that you do, because it's a custom item (unitymenumodel doesn't know what to do) | 12:51 |
| larsu | dednick|afk: I just realized that there's no way to do that yet, because that's passed as a role, not as a property | 12:52 |
| MacSlow | larsu, what can I use to define my own model on the bus... to get closer to my use-case? Just looking at the indicators' sources?! | 12:59 |
| larsu | MacSlow: indicators are more complex than what you need. export-menu.py should give you a rough idea | 13:01 |
| larsu | MacSlow: basically, you need an action group and a menu model, export both somewhere on the bus and feed their object paths into UnityMenuModel | 13:02 |
| larsu | MacSlow: if you've never worked with actions/menus before, you should read https://wiki.gnome.org/HowDoI/GAction | 13:03 |
| larsu | MacSlow: but why do you need to do that? I was under the impression your notifications are a consumer of that stuff? | 13:04 |
| MacSlow | larsu, sure... but I need to see the whole picture to understand what I'm doing on the renderer-side... | 13:04 |
| Cimi | mzanetti, hey dude | 13:09 |
| Cimi | mzanetti, how about this for the calendar? http://paste.ubuntu.com/5925202/ | 13:09 |
| mzanetti | Cimi: hi | 13:09 |
| mzanetti | Cimi: I pinged you first so first my questions :P | 13:09 |
| mzanetti | Cimi: whats the best way to theme a TextField? | 13:10 |
| dednick|afk | larsu: i'm wondering if it would have been better to stick with the QActionState approach to the actions. (ie have the model return an ActionState object for the role, which you activate with). | 13:10 |
| mzanetti | Cimi: I just need to color the background darker | 13:10 |
| Cimi | mzanetti, ouch | 13:10 |
| Cimi | mzanetti, why we need that? | 13:10 |
| Cimi | mzanetti, we have a palette to follow... | 13:10 |
| === dednick|afk is now known as dednick | ||
| Cimi | mzanetti, I think you'll have to specify a separate delegate for the textfield in case :-\ | 13:11 |
| larsu | dednick: and something like model.actionState.value to get the current state? | 13:12 |
| mzanetti | Cimi: well In that case its probably easier to use a UbuntuShape and a Label... given that I don't need to actually edit the text | 13:12 |
| larsu | dednick: or model.action.state | 13:12 |
| Cimi | mzanetti, yes | 13:12 |
| mzanetti | Cimi: I need that because design tells me to | 13:12 |
| larsu | dednick: and then model.action.changeState('newState') | 13:12 |
| dednick | larsu: yeah. | 13:12 |
| dednick | larsu: at the moment we need to pass around the model and curent index to each menu item, which isn't the best. | 13:13 |
| MacSlow | larsu, how would text-entry fields look like in the unitymenumodel... do they fit at all? | 13:14 |
| larsu | dednick: agreed, I'll do it like that | 13:15 |
| larsu | MacSlow: in upstream GMenuModel, that doesn't exist. But we have some extensions that allows you to set custom menu items, which can be anything that client and server agree upon (but we don't have a text entry yet) | 13:17 |
| MacSlow | larsu, what about normal buttons and listviews? | 13:17 |
| MacSlow | larsu, if those are missing also, is work to support them underway? | 13:19 |
| larsu | MacSlow: would be possible, but I'm sensing you're going down a wrong path... | 13:20 |
| larsu | MacSlow: the menu model stuff should really only be used for list-like things | 13:20 |
| larsu | MacSlow: the buttons could come from the notification actions, for example | 13:21 |
| === alan_g|lunch is now known as alan_g | ||
| MacSlow | larsu, well... I'm glad for any insight on the subject I can gather... but on the other hand there's also the Design-requirement I've to fulfil ... so if text-entries are unsupported (and out-of-concept) then the whole approach (of using qmenumodel) has to be questioned still. | 13:24 |
| dednick | larsu: not sure how relevant it is with the changes, but here are the ActionStateParser changes i made. http://pastebin.ubuntu.com/5925259/ | 13:24 |
| MacSlow | larsu, I'm just trying to get the whole picture... and see what it takes to get it done. | 13:25 |
| dednick | larsu: i override with a custom impl in unity8 and parse out the icon key. | 13:25 |
| larsu | dednick: thanks! Will have a look at it in a bit | 13:26 |
| larsu | MacSlow: you're asking me something I cannot answer right now. I haven't even properly thought about it. I'm just saying it sounds wrong to me. | 13:27 |
| larsu | MacSlow: text entries are not supported right now, but it would be trivial to add them | 13:27 |
| MacSlow | larsu, ok | 13:28 |
| larsu | MacSlow: I'd be glad to help out, but I'd need to (a) get a list of the requirements and (b) think about it :) | 13:30 |
| MacSlow | larsu, well all the "specs" I have are two hand-drawn mockups from mpt :) | 13:31 |
| mpt | Hey now. There's at least four. | 13:32 |
| mpt | :-) | 13:32 |
| larsu | mpt: hehe. Don't worry about them, they're fine (except for that connect button). We're just talking implementation ;) | 13:33 |
| dednick | larsu: you think you'll have time to get to that action stuff today? | 13:35 |
| larsu | dednick: I'm still on ubiquity because today has turned out to be a massive ping-fest for me. I'll try. | 13:36 |
| dednick | larsu: :) ok | 13:37 |
| mzanetti | dandrader: is this about each app increasing memory by 4kb every few seconds? | 13:37 |
| dandrader | mzanetti, probably | 13:38 |
| mzanetti | dandrader: I debugged that one already a bit some time ago. it happens also with an empty Item {} in qmlscene | 13:39 |
| dandrader | mzanetti, but the size of the increase is not constant. if you're interacting with complex content it grows faster | 13:39 |
| mzanetti | dandrader: => its the qpa | 13:39 |
| mzanetti | dandrader: oh. in that case its probably another one | 13:39 |
| dandrader | mzanetti, yes. I tried with an empty Item{} as well late last friday | 13:39 |
| dednick | larsu: i might just do some prelim work with it after lunch. just get some stubs and such in so I can move on my side. I'll push a diff on you later so you at least have a headstart later. | 13:40 |
| dandrader | and it does grow there indeed | 13:40 |
| dednick | larsu: but if you'd rather just do it yourself let me know and i'll find something else to do for the next day or so. | 13:40 |
| dandrader | mzanetti, did you find where in the qpa? or you didn't go deeper in it? | 13:41 |
| dandrader | mzanetti, I do hope it's only one bug :) | 13:42 |
| mzanetti | dandrader: I stopped there :/ | 13:42 |
| larsu | dednick: no, that'd be awesome. I'm swamped today. | 13:42 |
| mzanetti | dandrader: yeah... would be good if its the same one | 13:42 |
| dandrader | mzanetti, hmmm actually it's more than one. The constant growth without user interactions happens only on the device (thus blame likely on qpa) whereas increases due to user interaction also happen on x86, although to a lesser extent... | 13:44 |
| mzanetti | dandrader: hm... so its two.. | 13:45 |
| mzanetti | :/ | 13:45 |
| dednick | larsu: see what happens when you move back to europe?! | 13:48 |
| larsu | dednick: lol. I will move back if it stays like this :) | 13:48 |
| dednick | first half of your day is going to be dealing with the europeans, then later the US. :) | 13:48 |
| === dednick is now known as dednick|lunch | ||
| mhr3_ | we just need to move to new zealand one by one :) | 13:49 |
| mzanetti | oh noes... than the ones still in europe need to deal with the new zealand ones during night | 13:53 |
| mzanetti | Cimi: the diff reads ok | 14:07 |
| Cimi | mzanetti, shall I push? | 14:10 |
| Cimi | mzanetti, feels less safe than refreshing the model… but maybe still works | 14:11 |
| mzanetti | Cimi: I didn't test it, just read through the diff. It reads sane enough I'd say | 14:11 |
| mzanetti | Cimi: well, add tests for it | 14:11 |
| Cimi | mzanetti, tests work | 14:11 |
| Cimi | mzanetti, but you could possible do pretty creasy stuff | 14:11 |
| Cimi | mzanetti, I don't think will actually happen | 14:12 |
| Cimi | crazy | 14:12 |
| mzanetti | Cimi: you mean by doing bad things with the api? | 14:12 |
| mzanetti | Cimi: like setting min > max etc? | 14:12 |
| Cimi | maybe or just changing model or minimum/maximum date on the fly | 14:12 |
| mzanetti | Cimi: the model shouldn't be accessible from the outside I'd say | 14:13 |
| mzanetti | Cimi: and changing minimum/maximum on the fly should work fine I think | 14:13 |
| Cimi | from the code it should | 14:13 |
| === alan_g is now known as alan_g|tea | ||
| === dednick|lunch is now known as dednick | ||
| === alan_g|tea is now known as alan_g | ||
| mzanetti | Cimi: I guess I'm going to give the theming a shot. Can you help me to get started? | 14:56 |
| Saviq | mzanetti, hey | 15:17 |
| mzanetti | Saviq: ho | 15:17 |
| Saviq | mzanetti, I just remembered a thing we need to investigate quickly | 15:17 |
| mzanetti | Saviq: shoot | 15:17 |
| Saviq | mzanetti, which is returning objects/pointers from QAbstractItemModel::data() | 15:18 |
| mzanetti | Saviq: don't :P | 15:18 |
| Saviq | mzanetti, except there's a related issue - dataChanged() signals | 15:18 |
| Saviq | mzanetti, if you use get(int index) | 15:18 |
| Saviq | mzanetti, even if you send a "blanked" dataChanged, 'cause the underlying object changed | 15:19 |
| mzanetti | Saviq: not following | 15:19 |
| Saviq | the thing you got out of get(int index) is going to be outdated | 15:19 |
| mzanetti | ah | 15:19 |
| * mzanetti thinks | 15:19 | |
| mzanetti | Saviq: no... is it? | 15:20 |
| mzanetti | Saviq: you get a pointer to that object | 15:20 |
| mzanetti | Saviq: so the contents of that should update even before you get the dataChanged() from the model | 15:20 |
| Saviq | mzanetti, that's only if dataChanged() means that data *inside* the object changed | 15:20 |
| mzanetti | Saviq: and ideally the thing you return in get() is QObject with PROPERTIES and NOTIFY signal too | 15:20 |
| Saviq | mzanetti, and not that the object itself changed | 15:21 |
| mzanetti | right... I see | 15:21 |
| * mzanetti thinks more | 15:21 | |
| Saviq | granted, if it did, a remove() and add() is probably the better thing to do anyway | 15:21 |
| mzanetti | Saviq: yeah... not only the better. its the way to do it | 15:21 |
| Saviq | mzanetti, that's why I said we need a little investigation ;) | 15:21 |
| mzanetti | Saviq: its a different object, not the same that changed | 15:21 |
| mzanetti | Saviq: you think we have bugs in our code related to this? | 15:22 |
| Saviq | mzanetti, and is it written down somewhere that we shouldn't be doing QVariant(QObject*) ? | 15:22 |
| Saviq | mzanetti, no, but we're inconsistent | 15:22 |
| Saviq | mzanetti, not that Qt is consistent... | 15:22 |
| Saviq | mzanetti, as in there's modelData in some, and get() on some others | 15:22 |
| mzanetti | Saviq: I don't think that's written down somewhere... Its just me avoiding that because of prior experiences | 15:22 |
| Saviq | relying on either can lead to issues | 15:23 |
| Saviq | if we're not consistent | 15:23 |
| mzanetti | Saviq: get() and modelData are different things | 15:23 |
| mzanetti | Saviq: modelData is a role name for QQmlListModel (yes, talking 5.1 already :P) | 15:24 |
| Saviq | mzanetti, yeah, and this role is a ListElement (or whatever it ends up to be) - probably not a pointer, though? | 15:25 |
| Saviq | and a copy instead | 15:25 |
| mzanetti | Saviq: no... this role a string | 15:25 |
| Saviq | mzanetti, modelData? | 15:25 |
| mzanetti | Saviq: QQmlListModel also has get() which indeed returns the ListElement | 15:25 |
| mzanetti | Saviq: yes, modelData is the roleName for the string data in simple QML string based models | 15:26 |
| mzanetti | Saviq: anyways, we're talking about the get() here | 15:26 |
| Saviq | mzanetti, but for a ListModel { ListElement { } } modelData works too, not? | 15:26 |
| mzanetti | Saviq: I don't think so... if it does, I never used it. | 15:27 |
| mzanetti | Saviq: in this case you define the role names yourself in the ListElement and afaik modelData doesn't do anything | 15:27 |
| Saviq | mzanetti, right, so modelData is just for QStringListModel (or JavaScript lists) | 15:28 |
| mzanetti | Saviq: exactly | 15:28 |
| Saviq | mzanetti, in which case it will return whatever you put in that list | 15:28 |
| mzanetti | Saviq: but yes, get() returns the ListElement. and I guess thats just a QVariant | 15:28 |
| mzanetti | Saviq: there is no pointer involved there | 15:28 |
| mzanetti | Saviq: might be wrong... would need to check the code... could also be that you get a QQmlListElement* or the like | 15:29 |
| Saviq | mzanetti, you can have model: [ { }, { } ], which will make modelData a JS object | 15:29 |
| mzanetti | Saviq: anyways, you're not suffering from our QVariant(QObject*) issue | 15:29 |
| mzanetti | Saviq: thing is, those JS objects don't have self defined methods that could collide with QVariants methos - which is the real problem for our issue | 15:30 |
| Saviq | mzanetti, ok, let's say I can live with a QObject* get(int index), then ;) | 15:30 |
| mzanetti | ok | 15:30 |
| mzanetti | Saviq: is there something more to come? | 15:31 |
| mzanetti | 'cause I'm still waiting :D | 15:31 |
| Saviq | mzanetti, no, I'm still not 100% convinced, but for now, in new code, I'll advocate for get() ;) | 15:32 |
| mzanetti | Saviq: important thing is, if you do this, make contents of that object Q_PROPERTY + NTOFIYable | 15:33 |
| Saviq | mzanetti, of course | 15:33 |
| mzanetti | Saviq: the change vs add/remove is a good point too. I for one wouldn't probably do the changed in that case anyways, but I can see how one could fall into that trap when trying to be clever | 15:33 |
| Saviq | mzanetti, yeah, if you want to replace the item in-place, preventing a transition | 15:34 |
| mzanetti | Saviq: well, to be precise, if you do not want to a transition its still the same object in which case you should indeed change the contents instead of the pointer to it | 15:35 |
| mzanetti | Saviq: so when writing clean code this isn't an issue. just if someone tries to be clever/lazy | 15:35 |
| Saviq | mzanetti, yeah | 15:35 |
| mzanetti | Saviq: good ol c++ would have beaten you up if doing such stuff | 15:36 |
| Saviq | mzanetti, OTOH at the point when you have a get(index) method, what use are roles :/ | 15:36 |
| Saviq | they're just a burden at that point | 15:36 |
| mzanetti | Saviq: implementation of the model is way simpler if you don't need that get() stuff | 15:36 |
| mzanetti | Saviq: so the get will only be used if really needed | 15:37 |
| mzanetti | Saviq: well... I've seen people that always try to write the longest possible code... so don't assume anything... but in general I think everyone would choose the roleName approach as long as possible | 15:38 |
| Saviq | mzanetti, what I mean is: if your model is backed, say, by QList<QObject*> | 15:41 |
| Saviq | mzanetti, if those objects have their own NOTIFY | 15:42 |
| Saviq | mzanetti, you'd in theory need to "forward" the NOTIFYs to dataChanged | 15:42 |
| mzanetti | Saviq: right... I see. well. yeah. its not a real issue except maybe not compliant with the styleguide | 15:43 |
| === alan_g is now known as alan_g|reboot | ||
| Saviq | mzanetti, what I mean exposing them as properties is a drawback in the case when you don't support them to be changeable | 15:44 |
| mzanetti | Saviq: sure... in that case you can make them CONSTANT too. in that case its not even an issue because you don't need to update anyways | 15:44 |
| mzanetti | Saviq: its only an issue if you would need to update but only emit dataChanged but not the NOTIFY signal in the object | 15:45 |
| Saviq | mzanetti, or actually... the data for roles shouldn't really be available as properties, should it | 15:45 |
| mzanetti | or the other way round | 15:45 |
| Saviq | mzanetti, the object should only exist in the model after it's set up | 15:45 |
| mzanetti | Saviq: in Xbmcremote I have such a use case | 15:45 |
| mzanetti | Saviq: I have the list of movies for example which uses the role names | 15:46 |
| mzanetti | Saviq: on long-press it expands, pushes a new page for example and then passes the Object* into that to display all the details | 15:46 |
| mzanetti | Saviq: which also contain stuff that was in the rolenames too, like title for example | 15:46 |
| mzanetti | Saviq: if you're trying to make a guide line out of it, I'd say it should be like this: | 15:47 |
| mzanetti | if you either use the roleNames or the properties for the QObject* get(), once you start with any of them, make it complete | 15:47 |
| mzanetti | Saviq: ^^ I think this would be most save general way to go | 15:48 |
| === jhodapp is now known as jhodapp|lunch | ||
| mzanetti | but not half roleNames, half properties | 15:48 |
| mzanetti | duplicating is less of an issue I'd say | 15:48 |
| mzanetti | given the model's data() will only return the property anyways | 15:49 |
| mzanetti | making sense? | 15:49 |
| Saviq | mzanetti, that really sounds to me like "if you have a get(), don't use roles no more" | 15:50 |
| Saviq | mzanetti, as supporting both is duplicating work | 15:50 |
| mzanetti | Saviq: so usually I'd rather accept more work below/inside and API than above it | 15:51 |
| mzanetti | Saviq: and I'd accept having to fill in the data() even if its a bit of more efforts if it makes the usage of the model on QML side easier and less fail-prone | 15:51 |
| mzanetti | Saviq: probably its starting to get a matter of taste... but so far I always tried to keep it to this^ | 15:52 |
| Saviq | mzanetti, I'm starting to think, for stuff that's available through data(), unless you expect them to change, of course, they shouldn't be properties unless needed for some reason - and yeah, they should be CONSTANT when you need them, but they don't change | 15:53 |
| Saviq | mzanetti, SomethingModel should be friend of Something, and just access protected members directly | 15:53 |
| Saviq | mzanetti, where there are no properties on Something, that is | 15:54 |
| mzanetti | Saviq: as I said... I see use cases where you would want both | 15:54 |
| Saviq | mzanetti, and if you actually do have NOTIFY-able properties, you need to make sure to emit dataChanged() onChanged for all of them, that are exposed as roles | 15:55 |
| mzanetti | Saviq: in your case I would need to write the delegates in the Movies list half with role names, half with model.get(index).propertyName | 15:55 |
| Saviq | mzanetti, my last point explained that you can have both | 15:55 |
| seb128 | hum | 15:55 |
| Saviq | mzanetti, but we shouldn't make it a general approach to expose everything on Something as props, if you don't need them on Something and/or don't expect them to change | 15:56 |
| seb128 | can I pass an object/component to a custom component? | 15:56 |
| mzanetti | yeah... ok... I wouldn't write the friend stuff into a guideline tho... it really depends on what Something is... it might already have public getters | 15:56 |
| Saviq | mzanetti, yeah, if it does - of course you should use it | 15:57 |
| mzanetti | Saviq: I agree... keep it to roleNames as long as possible | 15:57 |
| seb128 | I've a GSettings {} on my page and I pageStack.push(qml, {...}) ... can I give the GSettings through the push? | 15:57 |
| seb128 | or do I need to add a new GSettings in my subpage? | 15:57 |
| Saviq | seb128, push(qml, { prop: gsettingsId }) should work | 15:57 |
| mzanetti | Saviq: so you're saying we will have roleNames for everything and for some stuff you need you can have additionally the property thing, provided you make it clean with dataChanged and everything,, right? | 15:58 |
| Saviq | seb128, where prop is the property you want to set on qml | 15:58 |
| Saviq | mzanetti, yeah, keep props to a minimum | 15:58 |
| Saviq | mzanetti, if you can, make it CONSTANT | 15:58 |
| mzanetti | Saviq: ack. | 15:58 |
| mzanetti | Saviq: sure... but that's not only related to this particular case | 15:59 |
| Saviq | mzanetti, yeah indeed :) | 15:59 |
| Saviq | mzanetti, I think what I'm trying to say is: don't make it into a property if your only use is to expose it in a model | 15:59 |
| mzanetti | yeah... don't even make a get() for the model then | 15:59 |
| Saviq | mzanetti, well, sometimes we need a get() to call methods on the object | 15:59 |
| mzanetti | true... | 16:00 |
| Saviq | mzanetti, but we shouldn't put the props on the object | 16:00 |
| Saviq | mzanetti, if they're not really needed there | 16:00 |
| mzanetti | unless there is a use case like the details page in xbmcremote | 16:00 |
| mzanetti | ok. | 16:00 |
| mzanetti | we agree 100% I think | 16:00 |
| Saviq | mzanetti, yeah, you need a use case for each property | 16:00 |
| mzanetti | ack | 16:00 |
| seb128 | Saviq, hum, what type would be prop in my new qml? variant? | 16:00 |
| Saviq | seb128, variant is obsolete | 16:00 |
| Saviq | seb128, but it can just be GSettings | 16:00 |
| Saviq | seb128, "var" is to be used everywhere you used variant until now (but obviously best make it explicit what's it supposed to be) | 16:01 |
| Saviq | mzanetti, can you please summarize in https://docs.google.com/a/canonical.com/document/d/1gd87Wo_CSB0DpFWLpTKIIXQfdmFncrq0PHSr9H2PTnk/edit | 16:02 |
| seb128 | Saviq, that works, thanks! | 16:02 |
| Saviq | seb128, cheers | 16:02 |
| Saviq | o/ | 16:02 |
| mzanetti | oh boy... I'm writing the guideline now... the only one standing up against it | 16:02 |
| === dandrader is now known as dandrader|afk | ||
| mzanetti | what happened to this world | 16:03 |
| tsdgeos | :FD | 16:03 |
| * tsdgeos has found the problem with gerry's code | 16:07 | |
| tsdgeos | now i just need to decided how to fix it :D | 16:07 |
| Saviq | tsdgeos, btw, what's the status of input for apps in unity-mit? | 16:08 |
| Saviq | *mir | 16:08 |
| Saviq | tsdgeos, did we get anywhere? | 16:08 |
| tsdgeos | Saviq: hmmm | 16:10 |
| tsdgeos | so | 16:10 |
| tsdgeos | what i found now | 16:10 |
| tsdgeos | is a bug in a class called InputArea Gerry uses in its test demo shell to shape which parts of the shell should "eat" the input and which no | 16:10 |
| tsdgeos | that bug should be fixable | 16:11 |
| tsdgeos | without him | 16:11 |
| tsdgeos | now, that class/item InputArea is not used anywhere in unity8-integrate-mir | 16:12 |
| tsdgeos | thus it is very well possible that that is making the shell "intercept" the presses to all of the apps | 16:12 |
| tsdgeos | but i've been mostly cntered in the InputArea bug that Gerry told me to have a look than in the other thing | 16:12 |
| tsdgeos | Saviq: so basically apps don't get input at all in unity-mir or? | 16:13 |
| Saviq | tsdgeos, yeah | 16:14 |
| tsdgeos | it may well be the fact that no InputArea is used in the shell | 16:14 |
| tsdgeos | since the comment in the mir code says | 16:14 |
| Saviq | tsdgeos, just flash from s-jenkins:8080/job/ubuntu-touch-phablet-image-saucy-mir | 16:14 |
| Saviq | tsdgeos, and you'll see | 16:14 |
| tsdgeos | if no inputarea is given alll the surface takes the input | 16:14 |
| tsdgeos | Saviq: i'll have a look at it tomorrow once i fix the InputArea thing, fried brain atm | 16:17 |
| Saviq | tsdgeos, sure | 16:17 |
| === dandrader|afk is now known as dandrader | ||
| Saviq | mzanetti, "make all of the QObject*’s properties NOTIFYable and emit the changed signal" ← we only want that for mutable props, we should default to CONSTANT | 16:21 |
| mzanetti | Saviq: better now? | 16:23 |
| mzanetti | actaully that was supposed to be an n... :) | 16:23 |
| mzanetti | Saviq: "if the property is exposed through a role..." didn't the line above say that it must be? | 16:24 |
| Saviq | mzanetti, right I don't think we should expose everything through roleNames - not if you don't need it in the model | 16:25 |
| mzanetti | Saviq: well, which basically spoils the whole guideline | 16:25 |
| mzanetti | Saviq: because its just: Do whatever it requires | 16:25 |
| mzanetti | except the naming convention on get() | 16:26 |
| Saviq | mzanetti, yeah, but then you need to know what it requires in the first place | 16:26 |
| mzanetti | and the hint that you need to pay attention to keep stuff in sync | 16:26 |
| mzanetti | Saviq: ok... well, I'm fine with flexible guidelines, you know that | 16:26 |
| Saviq | mzanetti, I think we were just unnecessarily trigger-happy with Q_PROPERTY everywhere | 16:26 |
| Saviq | mzanetti, what it boils down to: limit roleNames to what you actually need in the model | 16:28 |
| Saviq | mzanetti, limit properties to what you actually need in the model | 16:28 |
| Saviq | s/model/object/ | 16:28 |
| Saviq | mzanetti, default to CONSTANT unless you know that you can get updated | 16:28 |
| Saviq | mzanetti, sounds about right? | 16:29 |
| mzanetti | Saviq: hmm... ok.. I'd say it still depends on the use case... in the xbmcremote it makes sense to have everything in the data() and only something in the properties in addition... | 16:29 |
| mzanetti | Saviq: hmm... defaulting to constant... haven't thought about that | 16:29 |
| mzanetti | Saviq: so far it was always pretty clear to me if something will ever change or not | 16:30 |
| mzanetti | Saviq: if something might change but someone "defaulted" to constant it's a bit of an issue I think | 16:30 |
| Saviq | mzanetti, if something "might change" you'll know, right? | 16:30 |
| Saviq | mzanetti, it's not like you would not know if something "might change" | 16:30 |
| mzanetti | Saviq: it would be safer to default to adding the signal... might be useless code, but safer | 16:30 |
| Saviq | mzanetti, useless code, useless memory | 16:31 |
| mzanetti | true. | 16:31 |
| mzanetti | yay for guidelines | 16:31 |
| Saviq | mzanetti, so no, default to CONSTANT | 16:31 |
| Saviq | mzanetti, you will know well enough when you need to be mutable | 16:31 |
| Saviq | mzanetti, can you imagine a case where you, writing MyObject and a corresponding MyModel, wouldn't know whether it can change or not? | 16:32 |
| Saviq | mzanetti, anyway you can always change it if needed | 16:33 |
| mzanetti | Saviq: no... thats what I said... hence I found the "default to CONSTANT" a bit weird. | 16:33 |
| Saviq | mzanetti, still do, or? ;) | 16:33 |
| mzanetti | Saviq: then I thought, ok, this might be a guidline for people who don't know such stuff and thought, defaulting to CONSTANT might be more fail-prone than defaulting to NOTIFY | 16:34 |
| mzanetti | but you're right... that wastes resources | 16:34 |
| mzanetti | so... It's again me thinking to hell with the guideline. | 16:34 |
| Saviq | lol | 16:34 |
| mzanetti | if one doesn't know shit we can't prevent him from doing bullshit | 16:34 |
| Saviq | mzanetti, remember, it's a *guide* | 16:34 |
| Saviq | mzanetti, not a *rulebook* | 16:35 |
| mzanetti | right | 16:35 |
| Saviq | mzanetti, even our chat above indicates we haven't thought about that before | 16:35 |
| Saviq | mzanetti, if we had read it somewhere before, we'd know the answers already ;) | 16:36 |
| Saviq | or at least knew where to look for them | 16:36 |
| Cimi | mzanetti, I totally missed your ping :) | 16:36 |
| mzanetti | Saviq: hmm... I'd say my opinion is pretty much the same as I figured myself when writing xbmcremote | 16:36 |
| mzanetti | :P | 16:36 |
| Saviq | mzanetti, but now it's written down for people that didn't have an opinion yet ;) | 16:37 |
| mzanetti | Saviq: but you know... I'm the kind of guy that doesn't ready stuff anyways but always tries to figure stuff himself until understood | 16:37 |
| Cimi | mzanetti, was chatting with jouni at that time and didn't see it | 16:37 |
| mzanetti | s/ready/read/ | 16:37 |
| Saviq | mzanetti, yeah, but imagine you're a new starter | 16:37 |
| Saviq | mzanetti, reading through this would save you some brain cycles | 16:38 |
| mzanetti | Saviq: then you shouldn't write our dbusmenu model | 16:38 |
| mzanetti | Saviq: anyways... I see your point | 16:38 |
| Saviq | mzanetti, if anything, it would save you time during reviews ;) | 16:39 |
| mzanetti | true... that could be | 16:39 |
| Saviq | *you* as in mzanetti, not the new starter | 16:39 |
| mzanetti | Cimi: so... what would be required to theme a TextField black? more than 10 lines of code? | 16:40 |
| Cimi | mzanetti, think so | 16:40 |
| Cimi | mzanetti, because afaics you either ship a theme | 16:41 |
| Cimi | mzanetti, and override the color | 16:41 |
| Cimi | mzanetti, or you write a delegate | 16:41 |
| Cimi | mzanetti, I think somewhere in the textfield delegate code there's a colour: Theme.palette.... | 16:41 |
| Cimi | so you either replace the whole delegate | 16:42 |
| Cimi | or pass a different colour through the palette | 16:42 |
| mzanetti | Cimi: can't I do something like: style.background.color: Theme { background.color: "black" } | 16:45 |
| mzanetti | pseudo-code ^^ | 16:45 |
| mzanetti | but you get what I mean I hope | 16:45 |
| Saviq | mzanetti, ok, I wrote a paragraph above yours, can you read through? | 16:46 |
| mzanetti | Saviq: sure | 16:47 |
| mzanetti | Saviq: yeah. looks good. replaces the other one tho | 16:48 |
| Saviq | mzanetti, that's what it was meant to do :) | 16:49 |
| mzanetti | yeah | 16:49 |
| mzanetti | ok. looks good | 16:49 |
| Saviq | mzanetti, just kept your as reference for a bit | 16:49 |
| mzanetti | Saviq: fixed the last sentence | 16:50 |
| Saviq | mzanetti, thanks | 16:51 |
| Saviq | mzanetti, but actually, doesn't QML unwrap them automagically? | 16:52 |
| mzanetti | Saviq: only for stuff that is known to QVariant | 16:52 |
| mzanetti | Saviq: for other stuff you'd need variant.value<T>() | 16:53 |
| mzanetti | Saviq: and exactly that <T> misses QML | 16:53 |
| Saviq | mzanetti, yeah but to wrap something in a QVariant, don't you need to register it anyway? | 16:53 |
| mzanetti | Saviq: so it somehow forwards stuff which fails in case of name collisions | 16:53 |
| mzanetti | Saviq: not for * | 16:53 |
| mzanetti | Saviq: as you can always wrap an integer in a QVariant | 16:54 |
| Saviq | mzanetti, but couldn't that, then, be our guideline isntead? | 16:54 |
| mzanetti | Saviq: good point... | 16:54 |
| Saviq | instead of the get() | 16:54 |
| mzanetti | Saviq: I'm not sure if I have tried it or not | 16:54 |
| Saviq | mzanetti, ok, let's revisit, then | 16:54 |
| mzanetti | Saviq: are you hacking together testcode for this already? | 16:56 |
| Cimi | mzanetti, nope | 16:57 |
| Saviq | mzanetti, no, you are ;) | 16:57 |
| Saviq | mzanetti, I know you won't be able to stay away - me? there's Guinness awaiting ;P | 16:57 |
| mzanetti | Saviq: heh | 16:57 |
| Cimi | mzanetti, you basically don't access the delegate | 16:58 |
| mzanetti | Saviq: enjoy. you ok with me putting it on the todo for tomorrow morning? | 16:58 |
| Saviq | mzanetti, sorry, I'll grab one for you :) | 16:58 |
| Saviq | mzanetti, of course | 16:58 |
| mzanetti | Saviq: ok. I'll check it out | 16:58 |
| Saviq | o/ talk to you tomorrow guys | 17:05 |
| === alan_g is now known as alan_g|EOD | ||
| dandrader | mzanetti, ping | 17:10 |
| mzanetti | dandrader: hey | 17:10 |
| dandrader | mzanetti, are you able to run unity8 under valgrind (memcheck tool)? both on my desktop and on my laptop the window shows up only for a split second during startup | 17:11 |
| mzanetti | dandrader: need to check | 17:11 |
| dandrader | the process keeps running normally but the window is nowhere to be seen | 17:11 |
| mzanetti | dandrader: same here | 17:13 |
| dandrader | mzanetti, ok, thanks | 17:13 |
| === dandrader is now known as dandrader|lunch | ||
| === jhodapp|lunch is now known as jhodapp | ||
| === dandrader|lunch is now known as dandrader | ||
| === racarr is now known as racarr|lunch | ||
| === ritz is now known as ritz|dead | ||
| === dandrader_ is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === racarr|lunch is now known as racarr | ||
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
