[09:31] <alan_g> duflu: I saw camako's comment about mir_window_type_popover. The design doc says "The popup type was previously called Menu" which doesn't match the comments in our header. Do you have an opinion on the correct name?
[09:31] <duflu> alan_g: It appears I missed that. So no opinion
[09:31] <duflu> yet
[09:32] <alan_g> The description of https://code.launchpad.net/~mir-team/mir/no-window-type-overlay/+merge/314749
[09:33] <duflu> alan_g: Traditionally in toolkits there have always been multiple separate menu types (which helps with behaviour and animations)... popup != dropdown
[09:34] <duflu> alan_g: Sounds like it belongs in a different MP anyway
[09:35] <duflu> Or three different menu classes: https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472629520
[09:35] <alan_g> Sure, I was tempted to just do away with mir_window_type_popover (which is trivial) but then wondered if that was a good direction.
[09:35] <duflu> alan_g: I'm pretty sure we need to separate them because decoration and animation may be different
[09:35] <alan_g> "Examples of popups include menus, combo boxes, walkthrough hints, and popovers" (Mir and Unity: Surfaces, input, and displays (v0.3)_
[09:36] <duflu> Oh dear
[09:36] <duflu> Yes a combo box may be a popover and may be similar to a menu
[09:36] <alan_g> But at the moment mir_window_type_popover and menu are synonyms
[09:37] <duflu> alan_g: I think it's an interesting question but not a blocker for that particular MP
[09:37] <duflu> which just landed
[09:38] <alan_g> That MP landed. I was wondering how best to sort out mir_window_type_popover/menu which is also wrong.
[09:39] <duflu> alan_g: This is why display servers generally don't get involved in toolkit design :)
[09:40] <alan_g> I guess a toolkit designer/user would be the best to ask. ;)
[09:41] <alan_g> duflu: thanks for the chat. At least I know there isn't an easy right solution.
[09:41] <duflu> alan_g: I know we need to distinguish the different menu types. That's all
[09:42] <duflu> I think I know anyway. Maybe we need a subtype
[09:44] <alan_g> I'll see what attente thinks when he wakes up
[09:49] <duflu> cimi: zesty Unity8 now has the new input rate logic. Feels a bit nicer but we're not finished yet
[09:51] <duflu> Although I would like to get a kernel fix for the usbhid regression....
[10:18] <hikiko> hey Trevinho
[10:18] <hikiko> ping :)
[10:19] <hikiko> here?
[10:21] <hikiko> I think there's a problem with the design you suggest in the gcc review: if I use the tool, unity won't switch profile in real-time but in next reboot
[10:21] <hikiko> :s/gcc/ucc
[10:22] <hikiko> also, if the user modifies the lowgfx profile, he wont have the default settings anymore
[10:23] <hikiko> next restart*
[10:24] <hikiko> also that profile is generated by the .ini isn't it?
[10:26] <hikiko> the tool runs once at startup as far as I understand it
[10:28] <hikiko> I probably should change unity to use that tool as well, but we still need to switch to lowgfx instantly
[10:29] <hikiko> and overwriting the settings seems to be the easiest way
[10:42]  * alan_g wonders how that's relevant to #ubuntu-mir
[10:45] <hikiko> oh noes
[10:45] <hikiko> LOL
[10:45] <hikiko> sorry....
[10:45] <hikiko> I thought I am in #ubuntu-desktop
[10:45] <hikiko> thanks alan_g :p
[10:46] <alan_g> hikiko: how's it going in U7 land?
[10:49] <hikiko> alan_g, fine :) I am trying to finish all the remaining priority tasks to focus on porting chromium on mir
[10:51] <alan_g> A great way to start the new year. (I hope)
[14:04] <attente> alan_g: hey. gtk does differentiate between the different popup types when creating those widgets, so if it helps you to differentiate between them, we could pass them to you: https://developer.gnome.org/gdk3/stable/gdk3-Windows.html#GdkWindowTypeHint
[14:06] <alan_g> attente: I'm not sure how much it would help us (it is really unclear if Mir needs different behaviour). But if a shell is doing server-side decorations it would likely matter.