gistfile1.txt

00:32 <@ebassi> desrt: since you're working on GtkApplication, it'd be nice to have your thoughts on bug 722856
00:32 < Services> Bug http://bugzilla.gnome.org/show_bug.cgi?id=722856 normal, Normal, ---, gtkdev, UNCONFIRMED, API to 
communicate loading state
00:32 < desrt> ebassi: saw that.... not sure i agree that gtkapplication has a role here.
00:32 <@ebassi> desrt: also to make up some sort of startup notification protocol for wayland
00:33 <@ebassi> desrt: well, we're centralising the application story into one class, so I'd say the Application class would 
be well suited for that; also because it's the application that knows if a window is effectively ready to be 
shown
00:34 < desrt> ebassi: but it's not about the application -- it's about the window
00:34 <@ebassi> but a GtkApplicationWindow method would also be enough, I guess
00:34 < desrt> right.
00:34 < desrt> why isn't _present() good enough here?
00:34 < desrt> you want to be able to present a window that's not ready yet, and then fill it in some more and then say 
"okay... now really ready!"?
00:35 <@ebassi> desrt: it may take some time to get the content up

00:35 <@ebassi> desrt: regardless of the window state
00:35 < desrt> ebassi: and why don't you just delay showing the window until you're ready?
00:35 <@ebassi> desrt: because between the show() called on my window, and the compositor actually showing stuff recursively, 
there's some arbitrary amount of time
00:36 <@ebassi> the compositor does not really have semantics on how ready your window is
00:36 <@mclasen> the wait is not between you calling show and the window being ready
00:36 <@ebassi> it just sees a MapNotify
00:36 <@mclasen> but between you clicking 'launch' and the window showing up
00:37 < desrt> ebassi: right... so why is the window mapping itself if it's not ready?
00:37 < desrt> by the time you call present() you should be in a situation where you can correctly render the first frame 
exactly as you want it to look
00:37 < desrt> and if that's not possible then this is a metter of the frame sync protocol or something like that... not a 
matter of dbus signalling
00:38 < desrt> *matter
00:39 <@ebassi> desrt: there's still a delay between the map request sent by the app, the window manager's mapping, the first 
expose event, and the drawing. also you don't want to block the mapping/drawing, because otherwise the first 
frame will be background color, and then the rest of the content will follow in the next couple of frames
00:40 <@ebassi> the whole issue is that the application's idea of "ready" and the window manager's idea of "ready" are not 
equivalent
00:40 < desrt> ebassi: this is something that we need to fix in gdk, then
00:40 <@ebassi> and as far as I know all the ways we have to tell the windowing system that we are "ready" are based on the 
window manager's idea of ready, not on the app's
00:41 < desrt> it seems that the real bug here is "it's not possible to draw a GtkWindow correctly on the first frame after 
show()"
00:41 <@ebassi> desrt: it's more the case of "it's not possible to prevent the compositor from painting the window until a 
certain condition is satisfied"
00:42 < desrt> ebassi: imho this is not something that the app should have to opt into via GtkApplication. this should work 
properly for all windows all the time, as a matter of course

00:42 <@ebassi> the example of iOS and the loading image comes to mind
00:42 < desrt> ebassi: right. we should fix that.
00:42 < desrt> wayland has "every frame perfect" as a goal, right?
00:42 < desrt> this seems to be an obvious violation of that....
00:42 < desrt> and it really should be addressed at that level
00:43 <@ebassi> desrt: every frame is "perfect" in the sense that every frame is well defined, not that every frame has 
"meaning"
00:43 < desrt> ebassi: if what you're talking about is not possible with stock wayland, it ought to be.
00:44 < desrt> this definitely belongs at that level (as per cosimo's 3rd suggestion)
00:44 <@ebassi> yes, that would be the point
00:44 <@ebassi> so yes, a GdkWindow method would be fine
00:44 < desrt> ebassi: in any case this is far outside of my area... this is one for mclasen or Jasper or owen or krh, etc.
00:45 * mclasen not sure how frame-perfect has anything to do with startup notification
00:45 < Jasper> For the case of a Twitter client, no, you put up a window with a spinner in it.
00:45 <@mclasen> clearly, the window should be perfect when it shows up
00:45 <@mclasen> startup notification is about what happens before that time
00:45 < Jasper> You don't wait 30 seconds for the Twitter servers to timeout because of high load.
00:45 <@ebassi> Jasper: unless the compositor places a spinner on top of an image loaded from the application bundle
00:46 < desrt> Jasper: depends on the environment... the convention in ebassi's case could well be that applications aren't 
expected to show their window until they have something meaningful... leaving the OS-provided spinner to show 
in the meantime
00:46 <@ebassi> while the application loads its assets
00:46 < Jasper> ebassi, splash screens are making a comeback?
00:46 <@ebassi> Jasper: when an underpowered platform you have, splash screens not so bad you'll find
00:46 < desrt> Jasper: which could be nicer than *user clicks* [first spinner screen] *app starts* [second spinner screen from 
app] *data is here* [meaningful content]
00:46 < Jasper> ebassi, ah, right, you're still stuck with PVR, right?
00:46 <@ebassi> nope
00:46 <@ebassi> but ARM yes
00:47 < Jasper> desrt, the other case is focus stealing prevention.

00:47 < Jasper> desrt, you want your window to be mapped as soon as possible even if it doesn't have any content.
00:47 <@ebassi> Jasper: that's debatable
00:47 < desrt> Jasper: no sure i agree... focus stealing needn't have an expiry date
00:47 <@ebassi> you want *something* on screen
00:47 <@ebassi> not necessarily the app's window
00:48 <@ebassi> bonus points if it's consistent
00:48 < desrt> there's definite 'feeling of responsiveness' gains to be had from the graphical shell bringing up a window 
(even if empty) immediately after the user releases the mouse button
00:49 < Jasper> desrt, right, but if I start Janetter from the overview, and then switch back to Firefox and keep typing, and 
after 30 seconds the window shows up, it's going to get shoved behind with one of those "Janetter is ready" 
notifications
00:49 < Jasper> desrt, yeah
00:50 < Jasper> desrt, I suppose it doesn't matter if it's the app's window or not, but that's really not possible with X11, 
unless we play some cool tricks
00:50 < desrt> it could be cheated in the compositor
00:50 < desrt> well... you'd need tricks to prevent clicks on that window from doing unintended things
00:50 < Jasper> Mp a dummy frame window, let the user move it, restack it, resize it, and then magically swap it out with the 
app's window with the correct position/stack/size after placement
00:50 < desrt> also: in a non-device scenario, trying to guess the size and position of the window at startup would be annoying
00:51 < Jasper> But that wouldn't work for GIMP
00:51 < Jasper> Or any app with 17 windows on startup.
00:52 * desrt imagines firefox not presenting itself until after the start page has been downloaded and rendered
00:52 < desrt> could be a fun experience :)
00:53 < desrt> would be mostly useful for local start pages (about:blank, etc.)
00:53 < desrt> the delay might be too obnoxious in the case of the network
00:53 <@ebassi> org.freedesktop.Shell.SetApplicationState(id, { "state": "loading", "size": "400x300" }); then 
SetApplicationState(id, { "state": "ready" });
00:54 < desrt> ebassi: it would already potentially be very late into the startup process by the time that first message was 
sent
00:54 < desrt> two things that may be interesting:
00:55 < desrt> - a way for apps to let the desktop environment know what size its window will be next time you start it
00:55 < desrt> - a way for apps to modify the content of the spinner window (adding progress information, for example)

without replacing it entirely
00:55 < desrt> so you could have a smooth transition from the generic "loading firefox" spinner to the same window with the 
same spinner but an additional label or progress bar for "waiting for www.google.com" or so
00:56 <@ebassi> sounds good
00:56 < desrt> i still think this doesn't belong on dbus :)
00:57 < desrt> well... maybe the first one does
00:57 <@ebassi> I'm not sold on dbus either; my actual proposal was the 3rd one
00:57 < desrt> since that's more application-state
00:57 < desrt> would also be a fun way to solve the miserable save-my-geometry problem that we've been trying to tackle for so 
long
00:58 < desrt> could have a flag that causes GtkApplication to take note of the geometry of your GtkApplicationWindows and 
save it into the OS on shutdown in a way that the system can use to properly size the spinner window on next 
launch -- which Gtk could then in turn use for the initial geometry
00:59 < desrt> could easily shove that into the platform data of the activation message
00:59 < desrt> (or have gtk get it out of the window server via the same protocol it uses to find out about its spinner window 
for purposes of modifying it)