[07:31] veebers, mzanetti: my GoogleHangout-plugin keeps telling me I need to update... can't connect atm [07:57] larsu: ping [08:02] dednick: good morning [08:02] larsu: morning. you in europe at the moment? seems a bit early for you. :) [08:03] dednick: yep, I'm in Europe (and will stay here for the time being) [08:04] larsu: ah ic. [08:04] larsu: aanyway. what was the consensus about the icons on friday? are we going for a uri for everything from now? [08:05] dednick: yep, uris. We don't have them for everything yet, though [08:06] dednick: unitymenumodel has that, except in the action state of the root menu item, which I'm not sure how to solve yet [08:07] dednick: because I don't know which things in an action might be icons, unless I teach unitymenumodel about indicators [08:08] larsu: larsu. yeah. not the best option though. i guess. [08:08] larsu: er, not an option for enforce icon format on server side? [08:09] would require changing all indicators though... [08:10] we could just say the indicators may only use icon names in there, without fallbacks [08:10] but someone will probably need something more complicated at some point... [08:10] Saviq: hi! Unity8 published [08:11] dednick: can you just assume they're icon names for now? Or did you already stumble across a weird one? [08:11] sil2100: Saviq is on IOM [08:11] mzanetti: ok, thanks, I was just informing anyway [08:11] larsu: getting a gthemedicon [08:11] from power [08:12] larsu: could write something in unity8 which operates on top of the unitymodel which knows indicators. [08:13] sil2100, thanks [08:15] 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] dednick: how about I give you a js function to do it for now? Or do you have a c++ plugin anyway? [08:16] Mirv: https://code.launchpad.net/~sil2100/cupstream2distro-config/media_extra_package/+merge/177328 <- can you review? ;) [08:16] larsu: i dont have anything at the moment. js would be good. [08:16] sil2100: so we are autoreleasing? [08:16] dednick: okay, will do that today. (bbiab) [08:18] tsdgeos: yes, although we're autoreleasing to the ubuntu-unity/next PPA right now [08:18] nice :-) [08:23] Mirv: you think it's ok? [08:30] 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:31] s/stateAction/actionState [08:35] sil2100: looks good to allow, even though the package is not yet in archives yet [08:36] Mirv: yes, it's a new package, but it's part of an existing source package in the archives [08:37] So it's cool [08:37] yep, found the address-book-app [08:37] Mirv: thanks! I'll redeploy and re-run ;) [08:38] Mirv: eeek! [08:39] One moment [08:39] Mirv: eek! [08:42] Mirv: I modified the wrong stack, but I fixed it now ;) [08:42] * sil2100 needs coffee [08:42] * mzanetti too [08:44] sil2100: ah... I just stared at the diff, too [08:44] Not sure why I thought 'media' instead o 'phone' o_O [08:48] larsu: still need me to check out that issue? [08:53] mzanetti: yeah, that'd be great [08:53] larsu: ok. can you give me short summary how to reproduce it? [08:54] mzanetti: yep. Grab my qmenumodel branch at lp:~larsu/qmenumodel/add-unitymenumodel [08:54] mzanetti: are you on saucy? [08:54] larsu: yes [08:55] mzanetti: awesome, then you can just do the cmake dance to build it [08:55] mzanetti: I think it only builds in-tree. Complain to renato about that one please :P [08:55] larsu: done with building [08:55] larsu: btw... built out of source [08:56] no complains [08:56] mzanetti: cool. he fixed it, then [08:56] mzanetti: just start the included example: qmlscene -I libqmenumodel/ examples/unityqmlmenumodel.qml [08:56] mzanetti: it's the sound menu, but a bit rough :) [08:57] 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] but it doesn't... [08:58] larsu: I don't see anything in the second entry [08:58] larsu: its just an empty grey rectangle [08:58] larsu: http://wstaw.org/m/2013/07/29/plasma-desktopaC8715.png [08:59] mzanetti: that's right: the one right under "Mute" [08:59] mzanetti: it says 0.75, that's your volume in [0,1] [08:59] larsu: right... got it [08:59] larsu: ok. on it [09:00] mzanetti: thanks! [09:00] dednick: fine by me, but there's a small problem: we need to deserialize the icon before doing the gvariant -> qvariant conversion [09:01] dednick: so once it's in actionState, it's really too late [09:01] dednick: I'm considering hacking it into unitymenumodel, despite the ugliness: if (key == "icon) deserialize(icon) [09:07] larsu: i'm reversing the qvariant serialization ;) [09:07] dont know if that's wise though... [09:09] dednick: ya... not so wise. These might be bytearrays with raw image data. Converting them all the time is a tad wasteful [09:09] dednick: should be okay for now though, as everything is themed afaik [09:11] guys, waiting for the phablet image download to finish, any quick review you awnt me to tackle meanwhile? [09:17] larsu: is there no way to tell that the GVariant from g_icon_serialise is a gicon type? [09:17] dednick: no, it doesn't contain a header [09:17] larsu: actually. why is the icon in the action? why not in the menu? [09:19] dednick: because it might change [09:19] menus are immutable [09:19] larsu: ah. ok [09:22] dednick: the more I think about it, the more I'm of the opinion that unitymenumodel should just know about indicators [09:22] dednick: this will make your life much easier [09:22] larsu: i think it's going to be used for other things though... [09:22] dednick: and since you're the only consumer right now, it makes a lot of sense [09:22] dednick: ya, maybe the settings app. That's okay though [09:23] larsu: problem is that i dont do a key=="icon". i just get the actionState variant. [09:23] dednick: ya. That's why I'm proposing what I'm proposing right now: [09:24] UnityIndicator { name: "" } [09:24] you'll then have indicator.icon, indicator.label, indicator.menu [09:24] where menu is a qabstractitemlist [09:24] larsu: i think the notifications are also using gmenumodel. [09:24] err, model [09:25] dednick: what? I hope not.... [09:25] larsu: i mean dialogs. [09:25] or something. MacSlow ^ [09:25] dednick: even so, this would be additional API [09:25] so no worries there [09:25] ok [09:26] larsu: found it [09:26] larsu: so what happens is this: [09:26] larsu: the QML file starts up and the model for the listview is model is UnityMenuModel(0xa58980) [09:26] dednick: okay, I'll crib your indicator-file loading code then and hack it this afternoon. Can you wait that long? [09:26] larsu: then you click the item which calls submenu() [09:27] larsu: in there you do a new MenuModel() and set the listview's model to: UnityMenuModel(0xac0700) [09:27] dednick, larsu: notifications a not yet using gmenumodel... but are meant to do soon to support recently added requirements from Design [09:27] larsu: then I press the volume key and guess which model emits the dataChanged: UnityMenuModel(0xa58980) [09:27] dednick, larsu: what's wrong with that? [09:27] MacSlow: what requirements are those? [09:27] mzanetti: FACEPALM! [09:28] mzanetti: thanks a lot man, I must've been braindead to not think of that [09:28] larsu: :) [09:28] larsu, password-entry... listview (for wifi-spots) [09:28] larsu: no problem [09:28] larsu: btw. a few hints on debugging: [09:28] larsu: yeah, think afternoon should be ok. [09:28] larsu: you can have for _EVERY_ property a onPropertynameChanged which you can print() stuff [09:29] larsu: you can also print() objects in QML. It'll print the class name and the memory address [09:29] just like qDebug() in c++ would do [09:29] mzanetti: ah, cool! [09:30] mzanetti: but onPropertyNameChanged only works if I have a NOTIFY on my property, right? [09:30] MacSlow: we show a list of wifi spots in the notification? [09:31] larsu, Design requires that yes [09:31] 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] larsu, it's not supported right now... but I've to make it happen [09:31] 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:32] mzanetti: right, that makes sense :) [09:32] larsu, what was the initial issue you/dednick pinged me about? [09:32] larsu, that's still not clear to me [09:32] 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:33] MacSlow: we were just trying to find other consumers of qmenumodel [09:33] MacSlow: just wanted to know what was goint to be using qmenumodel [09:33] larsu: I dont know if UnityIndicator belongs in qmenumodel. [09:33] doesnt sound right [09:33] larsu, dednick: ah ok [09:33] mpt: what is this madness that MacSlow is talking about? (notifications that contain the list of wifi spots) [09:34] larsu, dednick: https://wiki.ubuntu.com/Networking#wifi-connecting-prompted [09:35] 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] larsu: also, without fully studying the whole code, I have a feeling you're leaking the submenu [09:35] I might be wrong tho... but it looks like [09:35] 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:36] larsu: are you proposing we dont give it bus info? that it parses it itself? [09:36] larsu: re you cribbing the file loading. [09:36] MacSlow: I thought you said in a notification, that looks like a dialog to me... [09:36] dednick: yep [09:38] mzanetti: I thought I was parenting it to the parent model. Let me check. [09:39] 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] larsu, I know... but it has to happen in a notification. It's not my decision [09:43] nonsense [09:43] mpt: ya, unping. I misunderstood, sorry. [09:45] 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] dednick: alternatively, we can also move unitymenumodel into unity8 [09:45] dednick: which is something I've thought of before, but dismissed it because there might be other consumers soon [09:46] 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] mpt: "those controls" being that full dialog? [09:47] larsu, a scrolling list in the first case, and two labelled text fields in the second. [09:48] larsu, other examples of that component can be found in . [09:48] 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] 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:49] mpt: these all look like dialogs to me, I don't know why we would drag that information through the notification framework [09:49] larsu, exactly. The only difference between these and sheets is that these don't take up the full screen. [09:50] (Because they are simple enough to do that, and showing context of the app behind them helps.) [09:52] 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] mpt: do these have _anything_ in common with notifications? Like, should they be queued like notifications are? [09:52] larsu, no, they appear immediately modal to the parent surface [09:53] 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] 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] MacSlow, I don't see why they should block notifications at all. They're unrelated. [09:54] MacSlow: who made the decision to do these as notifications? Maybe there's a reason we're overlooking [09:54] dednick: and you'd supply one that calls g_icon_deserialize() from unity8? [09:55] larsu: yep. [09:55] 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] ok [09:55] MacSlow, I'm sitting next to mpt now ;) [09:55] Saviq, aoh.. :) [09:55] Saviq, well then [09:55] Saviq, I just shut up then :) [09:55] perfect :) [09:55] MacSlow, we'll try and find some time to chat then [09:55] MacSlow: thanks for bringing this to our attention :) [09:56] larsu: UnityMenuModel { ... actionStateParser: RootActionParser {} } [09:56] 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] 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:57] larsu: only setback is we don't keep the gicon serialisation code in one place. [09:57] larsu: but it's only a few lines, so should be ok. [09:58] larsu: should i give it a go. i've got some time and know what i need :) [09:58] 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:59] dednick: there's a function in unitmenumodel that handles most cases already. I'll paste it for you when I have the ActionStatePArser patch [10:02] 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:03] 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:05] larsu, so I thought the app sending an interactive notification with system-dialog-hint would be a good enough solution [10:09] 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] Saviq: thanks for clearing up were this is coming from. [10:10] 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] Saviq: the whole menu model stuff is already pretty far out there, now we're adding dialogs [10:10] Saviq: soon we'll have dbus-toolkit! [10:10] larsu, it's there already, isn't it... [10:11] larsu, and we can say that we're only supporting password (SIM-PIN, too) and wifi selection - and only support those [10:12] 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] Saviq: yeah, that's the approach we took with the indicators as well. [10:12] Saviq: so that network list in the dialog is dynamic? [10:13] Saviq: that'll make piping it through notifications ... interesting [10:13] larsu, dynamic in the sense that the backend needs to fill it, yes, and update it periodically, I'd say [10:13] larsu, but no [10:13] larsu, we want to fire an interactive notification through notifications [10:13] Saviq: ah right. That's much more sensible and doesn't require gmenumodel at all [10:13] larsu, but then *menumodel takes over [10:14] ah, so this is where I might disagree [10:14] (not enirely sure yet, just heard about this half an hour ago) [10:14] larsu, it just felt that trying to shoe-horn it through the notifications interfaces [10:14] larsu, would be more of a hack then using *menumodel [10:15] larsu, we agreed with tedg in OAK that would be a sane solution [10:16] 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] although that might be premature optim, as we're controlling the whole thing anyway [10:18] 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:19] Saviq: I'm not sure I fully understand yet. If there's a gmenumodel-based interface, where do notifications come into play? [10:20] 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] 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] Saviq: why not dbus: com.canonical.untiy.DisplayDialog("my.dbus.name", "/path/to/menumodel")? [10:21] larsu, I don't see how that's different from using notifications for it [10:22] larsu, except that we need to reimplement a bunch of priority / timeout considerations [10:22] larsu, that we already have for notifications [10:22] larsu, and then build an interaction between dialogs and notifications [10:22] larsu, that one is more important than others [10:23] larsu, and then there's the fact that the password entry is still spec'ed as a snap decision [10:23] larsu, so that they can queue on screen [10:23] 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] larsu, yay :) [10:24] MacSlow, ↑ [10:24] Saviq: it's a bit hacky, but very practical :) [10:24] larsu, exactly ;) [10:24] Saviq: sorry to stir up so much confusion, it just sounded really weird when I first read it [10:24] * MacSlow reads [10:24] MacSlow: tl;dr: keep calm, carry on. [10:24] :) [10:30] 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:31] 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] larsu, we can make the buttons part of the UI or part of the model, whichever's best [10:32] 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:33] Saviq: the connect button is redundant in a touch ui [10:34] Saviq: if you go the notification route, the model should only contain the list of access points [10:34] Saviq: the "cancel" button would be the standard ui for dismissing a system-modal notification [10:34] larsu, that's not the ultimate design [10:35] larsu, that's a branch to look at then lp:~larsu/qmenumodel/add-unitymenumodel ? [10:35] MacSlow: yes, but I recommend for you to wait a bit if you can until we get its API stable and merged [10:36] Saviq: I hope so :P [10:36] larsu, ok... I'll keep fixing some ap-tests in the meantime [10:38] larsu, problem is, we don't have the ultimate ones [10:38] 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:39] Saviq: I thought you were sitting next to mpt right now :P [10:39] larsu, I am [10:39] larsu, but in a session [10:39] Yes, but we're in a plenary and talking would be rude [10:39] and IRC isn't.... kind of... [10:39] mpt: isn't that connect button redundant in a touch ui? [10:39] Saviq: hehe, right :) [10:40] Saviq, another example at , without any fancy controls [10:40] just buttons [10:40] mpt, right [10:41] Saviq, I don't think they're "system" dialogs, really. I'd expect an unprivileged app to be able to use them. === sil2100_ is now known as sil2100 [10:56] hmm [10:58] 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 === MacSlow is now known as MacSlow|lunch === pete-woods1 is now known as pete-woods [10:58] pete-woods, right, comm fail *again* [10:58] MacSlow|lunch, ↑ [10:59] pete-woods, interface with MacSlow for this please [10:59] Saviq: sure :) === hikiko is now known as hikiko_lunch === MacSlow|lunch is now known as MacSlow === hikiko_lunch is now known as hikiko [12:03] Saviq, pete-woods: ok... noted [12:04] 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" === alan_g is now known as alan_g|lunch [12:07] 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:08] pete-woods, that's the very rough cut... atm I'm trying to get a proof-of-concept going [12:09] MacSlow: okay, thanks for the run-down! [12:09] 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] pete-woods, np yw [12:09] 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:10] pete-woods, certainly... I'm new to it myself and it'll take me some days for sure... so a week is reasonable. === _salem is now known as salem_ [12:22] 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:23] MacSlow: render-menumodel.qml uses the (old) qmenumodel api. Try examples/unitemenumodel.qml instead. [12:24] MacSlow: it shows you the sound menu from your system (if you [12:24] 're running saucy) [12:25] larsu, hm... now getting "UnityMenuModel is not a type", I'm probably not correctly exposing the compiled branch [12:26] MacSlow: `qmlscene -I libqmenudemodel/ examples/unitymenumodel` from the root of the repository [12:26] MacSlow: unitymenumodel.qml of course [12:27] larsu, hm... still getting this: module "QMenuModel" plugin "qmenumodel-qml" not found === jhodapp|afk is now known as jhodapp [12:30] MacSlow: does `find . -name libqmenumodel-qml.so` return ./libqmenumodel/QMenuModel/libqmenumodel-qml.so? [12:32] larsu, doh... my bad... I used a build-directory... with the correct path it works [12:32] MacSlow: ah, right, I always build it in-tree because out-of-tree didn't work a while ago [12:34] larsu: indicator-network doesn't seem to be exporting a root action. [12:34] larsu: is that a known? [12:35] dednick: on the desktop or the device? [12:35] larsu: at least device. [12:35] dednick: on the desktop: definitely known (it doesn't use the new indicator stack on the desktop yet) [12:36] dednick: ah, okay. Probably known, but not to me :) [12:36] dednick: I'll pester tedg about it [12:36] larsu: ok. desktop indicator - phone profile [12:37] dednick: ya, no such thing yet. tedg is working on it afaik [12:37] larsu: yeah, he added it a little while ago. guess just not finished yet. [12:45] larsu: how do we update action states? eg mute [12:48] 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:49] dednick: in the case of mute, it will toggle it [12:49] larsu: volume slider? [12:50] Cimi: ping === dednick is now known as dednick|afk [12:51] dednick: right, for that you do, because it's a custom item (unitymenumodel doesn't know what to do) [12:52] 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:59] 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?! [13:01] MacSlow: indicators are more complex than what you need. export-menu.py should give you a rough idea [13:02] 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:03] MacSlow: if you've never worked with actions/menus before, you should read https://wiki.gnome.org/HowDoI/GAction [13:04] MacSlow: but why do you need to do that? I was under the impression your notifications are a consumer of that stuff? [13:04] larsu, sure... but I need to see the whole picture to understand what I'm doing on the renderer-side... [13:09] mzanetti, hey dude [13:09] mzanetti, how about this for the calendar? http://paste.ubuntu.com/5925202/ [13:09] Cimi: hi [13:09] Cimi: I pinged you first so first my questions :P [13:10] Cimi: whats the best way to theme a TextField? [13:10] 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] Cimi: I just need to color the background darker [13:10] mzanetti, ouch [13:10] mzanetti, why we need that? [13:10] mzanetti, we have a palette to follow... === dednick|afk is now known as dednick [13:11] mzanetti, I think you'll have to specify a separate delegate for the textfield in case :-\ [13:12] dednick: and something like model.actionState.value to get the current state? [13:12] 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] dednick: or model.action.state [13:12] mzanetti, yes [13:12] Cimi: I need that because design tells me to [13:12] dednick: and then model.action.changeState('newState') [13:12] larsu: yeah. [13:13] larsu: at the moment we need to pass around the model and curent index to each menu item, which isn't the best. [13:14] larsu, how would text-entry fields look like in the unitymenumodel... do they fit at all? [13:15] dednick: agreed, I'll do it like that [13:17] 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] larsu, what about normal buttons and listviews? [13:19] larsu, if those are missing also, is work to support them underway? [13:20] MacSlow: would be possible, but I'm sensing you're going down a wrong path... [13:20] MacSlow: the menu model stuff should really only be used for list-like things [13:21] MacSlow: the buttons could come from the notification actions, for example === alan_g|lunch is now known as alan_g [13:24] 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] larsu: not sure how relevant it is with the changes, but here are the ActionStateParser changes i made. http://pastebin.ubuntu.com/5925259/ [13:25] larsu, I'm just trying to get the whole picture... and see what it takes to get it done. [13:25] larsu: i override with a custom impl in unity8 and parse out the icon key. [13:26] dednick: thanks! Will have a look at it in a bit [13:27] 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] MacSlow: text entries are not supported right now, but it would be trivial to add them [13:28] larsu, ok [13:30] 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:31] larsu, well all the "specs" I have are two hand-drawn mockups from mpt :) [13:32] Hey now. There's at least four. [13:32] :-) [13:33] mpt: hehe. Don't worry about them, they're fine (except for that connect button). We're just talking implementation ;) [13:35] larsu: you think you'll have time to get to that action stuff today? [13:36] dednick: I'm still on ubiquity because today has turned out to be a massive ping-fest for me. I'll try. [13:37] larsu: :) ok [13:37] dandrader: is this about each app increasing memory by 4kb every few seconds? [13:38] mzanetti, probably [13:39] dandrader: I debugged that one already a bit some time ago. it happens also with an empty Item {} in qmlscene [13:39] mzanetti, but the size of the increase is not constant. if you're interacting with complex content it grows faster [13:39] dandrader: => its the qpa [13:39] dandrader: oh. in that case its probably another one [13:39] mzanetti, yes. I tried with an empty Item{} as well late last friday [13:40] 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] and it does grow there indeed [13:40] 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:41] mzanetti, did you find where in the qpa? or you didn't go deeper in it? [13:42] mzanetti, I do hope it's only one bug :) [13:42] dandrader: I stopped there :/ [13:42] dednick: no, that'd be awesome. I'm swamped today. [13:42] dandrader: yeah... would be good if its the same one [13:44] 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:45] dandrader: hm... so its two.. [13:45] :/ [13:48] larsu: see what happens when you move back to europe?! [13:48] dednick: lol. I will move back if it stays like this :) [13:48] first half of your day is going to be dealing with the europeans, then later the US. :) === dednick is now known as dednick|lunch [13:49] we just need to move to new zealand one by one :) [13:53] oh noes... than the ones still in europe need to deal with the new zealand ones during night [14:07] Cimi: the diff reads ok [14:10] mzanetti, shall I push? [14:11] mzanetti, feels less safe than refreshing the model… but maybe still works [14:11] Cimi: I didn't test it, just read through the diff. It reads sane enough I'd say [14:11] Cimi: well, add tests for it [14:11] mzanetti, tests work [14:11] mzanetti, but you could possible do pretty creasy stuff [14:12] mzanetti, I don't think will actually happen [14:12] crazy [14:12] Cimi: you mean by doing bad things with the api? [14:12] Cimi: like setting min > max etc? [14:12] maybe or just changing model or minimum/maximum date on the fly [14:13] Cimi: the model shouldn't be accessible from the outside I'd say [14:13] Cimi: and changing minimum/maximum on the fly should work fine I think [14:13] from the code it should === 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 [14:56] Cimi: I guess I'm going to give the theming a shot. Can you help me to get started? [15:17] mzanetti, hey [15:17] Saviq: ho [15:17] mzanetti, I just remembered a thing we need to investigate quickly [15:17] Saviq: shoot [15:18] mzanetti, which is returning objects/pointers from QAbstractItemModel::data() [15:18] Saviq: don't :P [15:18]