1 < ebassi> as usual, the meeting agenda is here: http://live.gnome.org/GTK%2B/Meetings
   2 < ebassi> • Release date for 3.0
   3 < ebassi> • Pending tasks
   4 < ebassi> • Wevsite update
   5  * mclasen thought we had more
   6 < tristan> pending tasks includes a few items
   7 < kris> there's a bunch of subpoints below pending tasks
   8 < Company> that's because "pending tasks" has more
   9 < tristan> :)
  10 < mclasen> oh, ok
  11 < garnacho_> too late to add one more for pending tasks?
  12 < Company> we basically only have "pending tasks" ;)
  13  * mclasen follows the link
  14 < Company> garnacho_: go ahead
  15 < ebassi> yeah, writing the sub-points takes time :-P
  16 < mclasen> should we start with pending tasks, or just go top-down ?
  17 < Company> i guess deciding on the release date after pending tasks is a good idea
  18 < tristan> seems to make sense to do "release date" after pending tasks
  19 < ebassi> +1
  20 < mclasen> ok, so pending tasks first
  21 < ebassi> • treeview refactor
  22 < ebassi> which I guess is for tristan and kris
  23 < martyn> right
  24 < kris> yes so tristan did a lot of work on this
  25 < garnacho_> hrm, lost the lgo password
  26 < kris> and move all cell allocation/rendering/etc code into GtkCellArea/GtkCellAreaContext and related classes
  27 < kris> which can be re-used by other widgets, for example icon view, combo box
  28 < mclasen> so, what is the plan here, land this all in one big drop ?
  29 < tristan> yup, dont mean to interrupt... I (we) think it's ready to land
  30 < kris> we think it is about ready to land
  31 < tristan> treeview-refactor branch at least
  32 < kris> if somebody would like to review the new GtkCellArea* classes that would be great
  33 < kris> i tried to keep up with tristan :)
  34 < tristan> icon-view-refactor is a small diff... would be nice to get a review
  35 < kris> and reviewed a good amount of code, especially the changes impacting tree view
  36 < tristan> and then there's combo-refactor which would be also nice to get a review
  37 < kris> We can land this for GtkTreeView, without changing API in GtkTreeView, so the end-user impact is neglectible
  38 < mclasen> not changing widget apis is very good news indeed
  39 < mclasen> how about cell renderers ?
  40 < tristan> adds one or 2 apis but doesnt change anything
  41 < kris> cell renderers already got API extensions for hfw some months ago
  42 < kris> no changes apart from that
  43 < tristan> on a semi-related note I've been wanting to change cell-renderer (text cell renderer) properties a bit
  44 < tristan> because setting "wrap-width" in terms of pixels is just uncomfortable... but anyway
  45 < mclasen> kris: does the refactoring relate to your treeview-ng plans at all ?
  46 < kris> mclasen: a big part of treeview-ng was actually refactoring
  47 < kris> mclasen: so that's basically done by this work
  48 < mclasen> ok, nice
  49 < kris> another part of treeview-ng is re-considering all the validation machinery
  50 < kris> and I think that will happen in the near future as well, as doing height-for-width properly in GtkTreeView will require a re-consideration of that code anyway
  51 < mclasen> I see
  52 < kris> a height-for-width implementation is something we are not sure we will get done for 3.0
  53 < kris> but all the API and groundwork should be in place so that it can be done at a later stage without API-compatible changes
  54 < mclasen> I already stated my vague concern about the general direction of this work (ie duplicating a lot of the widget machinery for cell renderers)
  55 < mclasen> but I'll basically defer to you as the treeview authority, kris
  56 < kris> but this code duplication is not new, is it?
  57 < tristan> unifying all of that stuff would imply separating size negotiation tactics from widgets, in a way
  58 < tristan> because widgets are 1 for 1
  59 < tristan> cell renderers need alignments etc
  60 < tristan> ofcourse cell rendering using widgets is doable somehow, I wont argue that
  61 < mclasen> kris: true, it is not new. but cell renderers were much more limited so ar
  62 < Company> did you do any tests on multiple thousand row treeviews?
  63 < mclasen> now we get containers there, and focus navigation, and ...
  64 < kris> mclasen: focus navigation was first hidden in GtkTreeView, so that is not especially new
  65 < tristan> and icon view
  66 < Company> mclasen: i think for 4.0 we want to get rid of cell renderers
  67 < mclasen> kris: as I said, this is just a vague feeling, and may be entirely unjustified
  68 < Company> mclasen: we'll otherwise grow 2 different toolkits - one based on GtkWidget, one based on GtkCellRenderer
  69 < mclasen> if you think this is the way forward, by all means, lets get it merged
  70  * Company waits for GtkCellRendererTreeView
  71 < kris> we have not really added any new capabilities to cell renderers
  72 < mclasen> with GtkCellRendererCombo, we are already using cell renderers recursively...
  73 < kris> I think for a large extent, the work can be seen as splitting code out of GtkTreeViewColumn and making it suitable for height-for-width
  74 < Company> the problem is that so far widgets couldn't be used the way cell renderers are
  75 < Company> because they have GDK windows and all that mess, but that'll be going away
  76 < tristan> a possible future I could see, is GtkCellRendererWidget
  77 < tristan> if widgets can be usable to render cells, that could obsolete all the renderers
  78 < mclasen> lets not get too distracted by 4.0 stuff in this meeting, though
  79 < ebassi> or make GtkCellRenderer an interface implementable by Widget
  80 < tristan> ebassi, or that yes
  81 < tristan> the cell-area semantics take care of something not done by normal containers
  82 < mclasen> kris,tristan: is there a list of branches that need review, do we need to look for volunteers to do that ?
  83 < tristan> and that is cell alignments mostly
  84 < tristan> context of requesting a group of rows etc
  85 < kris> mclasen: I think it would be good if somebody would review the API of the new GtkCellArea* classes, which are in treeview-refactor
  86 < kris> mclasen: and we need a volunteer for combo-refactor I guess
  87 < kris> mclasen: I can have a look at combo-refactor as well, but I have not been maintaining for the last few years
  88 < tristan> that would be good, combo-refactor also introduces GtkTreeMenu
  89 < mclasen> whats the timeline for getting reviews done and moving on the merges ?
  90 < tristan> which we can keep private or expose, but I've written all the docs for it as a clean exposable class
  91  * mclasen would like to do a close to api-final snapshot this week
  92 < kris> I am about done with treeview-refactor
  93 < ebassi> tristan: I'm not so sure about TreeMenu for 3.0
  94 < kris> so it depends on how quick somebody can have a look at GtkCellArea*
  95 < kris> and at combo-refactor
  96  * mclasen would be much more comfortable to keep the treemenu private for now
  97 < Company> kris: i think if you and tristan agree on CellArea, then it's ok to merge
  98 < kris> i guess then we can consider merging treeview-refactor this week, so it will make mclasen's snapshot
  99 < kris> what about combo-refactor?
 100 < mclasen> I agree about merging the treeview-refactor
 101 < mclasen> and I can try to look over the combo-refactor branch
 102 < tristan> the diff of gtkcombobox.c is mostly api removals
 103  * mclasen is at least as interested in the iconview-refactor
 104 < tristan> I originally went with a "clean house" in combobox.c but got bitten by merges
 105 < mclasen> is iconview-refactor ready ?
 106 < tristan> yes.
 107 < tristan> icon-view-refactor was easier than I expected
 108 < kris> I think iconview-refactor doesn't do any API-incompatible changes, does it?
 109 < tristan> and it removes all the box[] arrays and hand dealing with renderers
 110 < tristan> no it doesnt
 111 < kris> treeview-refactor is most important to land, since it adds a good bunch of API
 112 < tristan> it's clean
 113 < mclasen> that only cellareafies the icon view ? does it also hfw it ?
 114 < tristan> mclasen, internally it does to an extent, but it doesnt hfw it completely
 115 < tristan> by that I mean... that all icons always had the same width
 116 < tristan> so, the width of an icon is determined by its smallest icon
 117 < mclasen> might be good to have mitch testdrive the iconview-refactor, he's had some fun with icon views in the gimp...
 118 < tristan> cells in the area require only the height for that width
 119 < tristan> that applies to a manually set "item-width" too
 120 < tristan> but things I'd like to do:
 121 < tristan>   - Let icon view return proper min/nat widths
 122 < tristan>   - handle icon view with a fixed number of columns in a hfw way
 123 < Company> oh that reminds me
 124 < Company> did we agree on the get_foo apis never needing to return more than screen width/height?
 125 < Company> get_preferred_foo()
 126 < Company> so that iconview can actually stop computing height for width once it hits a certain size
 127 < tristan> that's still a theory ... but I agree
 128 < Company> so that my home dir in an iconview actually resizes before i alt-tab?
 129 < tristan> for a treeview or icon view that needs to answer height-for-arbitrary-width...
 130 < tristan> it only needs to calculate screen height for that width yes
 131 < tristan> this is under the assumption that views not in a scrolled window are not super huge (taller than the screen)
 132 < Company> why?
 133 < tristan> views that are in a scrolled window, the scrolled window is only concerned with "whether the height will fit the allocation"
 134 < tristan> i.e. if it needs a vscrollbar or not
 135 < tristan> after that it gives the view an allocation
 136 < Company> even if i stuff a treeview into the toplevel directly
 137 < tristan> the allocation is different than the request
 138 < tristan> with an allocation you push the adjustment values as you caluclate the million rows in the background
 139 < Company> what does it help you that the natural height is 1892034839 pixels?
 140 < tristan> Company, I think we agree here
 141 < Company> i'll add code that manually clamps it then
 142 < tristan> I'm not arguing, just explaining why its not needed to calculate more than screen height for a request
 143 < Company> so we can test that it works
 144 < tristan> ok, so ... lets move on... we land treeview-refactor in the next days ? I wait for a go-ahead for combo-refactor and icon-view-refactor ?
 145 < ebassi> sounds okay to me
 146 < tristan> what should I do for "privatizing treemenu" ?
 147 < tristan> remove index from gtk-docs.sgml ?
 148 < tristan> and gtk.symbols/gtk3-sections.txt ?
 149 < ebassi> just put it in an non-installed header, and prefix every function in the header with '_'
 150 < ebassi> and remove it from the API reference
 151 < ebassi> (if it's used internally)
 152 < tristan> alright, I'll do that
 153 < ebassi> if not, just move it to a separate branch
 154 < tristan> ebassi, it's what does the combo-box menu
 155 < ebassi> okay, then the privatization of the symbols should be enough
 156 < ebassi> right, do we have other issues with this?
 157 < kris> Company: I will also test the new code with a very large tree view btw (a bit late reply)
 158 < ebassi> (mclasen dropped :-/)
 159 < ebassi> any takers for reviewing combo-box-refactor?
 160 < mclasen> GRR
 161 < Company> there we go :)
 162 < kris> ebassi: mclasen said he would have a look
 163  * mclasen hit an awesome patch of rawhide instability
 164 < mclasen> at-spi triggering iptables which in turn run into some selinux kernel oops...
 165 < ebassi> kris: thought it was for icon-view-refactory -- but sounds okay :-)
 166 < kris> ebassi: i will probably have a look as well, but that will defintely not be before next week
 167 < krh> mclasen: did you at least get the kms enabled oops? :)
 168 < mclasen> the screen continued to look shiny, it just stopped responding...
 169 < mclasen> what decisions did I miss ?
 170 < krh> oh, it should bounce back to a very unshiny kms textmode
 171  * krh shuts up
 172 < mclasen> krh: thats what happened after my first few reboots...
 173 < ebassi> mclasen: nothing much
 174 < mclasen> still discussing tree/icon/combo refactor ?
 175 < tristan> mclasen, we know that nobody ever wants to look at combo-box code...
 176 < ebassi> mclasen: finishing now with a missing reviewer
 177 < tristan> and are looking for volunteers
 178 < mclasen> I will try to take a look
 179 < mclasen> and we agree to land the tree and iconview parts this week ?
 180 < ebassi> right, we should probably jump to the next item
 181 < mclasen> or just treeview ?
 182 < ebassi> treeview was agreed
 183 < mclasen> ok
 184 < mclasen> let move on
 185 < ebassi> iconview depended on a reviewer
 186 < tristan> we agreed on treeview, icon-view is really not such a big deal to review
 187 < Company> treeview, release, then iconview i'd say
 188 < tristan> and it doesnt break api either so, its not blocking 3.0 technically
 189 < Company> because then it's easy to pinpoint cellarea vs iconview issues with "were they in the release?"
 190 < mclasen> makes sense
 191 < mclasen> next topic was gdk-backend ?
 192 < ebassi> yes
 193 < mclasen> so, to sum that up, I've been toiling to implement the plan that alex layed out on the list a few weeks ago
 194 < mclasen> the goal is to enable having multiple backends in gdk at the same time
 195 < mclasen> and pick one at runtime
 196 < mclasen> I guess alex motivation was his html5 backend
 197 < mclasen> but we will need something like this for x/wayland coexistence too
 198 < Company> and we can do quartz/x11 on OS X
 199 < mclasen> true
 200 < pbor> does it close this bug https://bugzilla.gnome.org/show_bug.cgi?id=97081 ?
 201 < Company> which should make kris happy
 202 < mclasen> pbor: technically not
 203 < pbor> (not that I care, just looking through bugs)
 204 < Company> i'd close it - because it has the same result
 205 < mclasen> but practically, yes
 206  * mclasen is out for 30 seconds
 207 < ebassi> I guess backend maintainers need to jump in and see what the backend branch requires
 208 < mclasen> the work on the branch is not quite finished
 209 < mclasen> what has been done so far includes changing things around so that there is only libgtk.so
 210 < Company> the only issue i have with that work is that we found quite a few GDK APIs that suck
 211 < mclasen> thats one point I wanted to discuss today - do we need a separate libgdk.so ?
 212 < Company> other than that, it's just something that needs to happen in an API-compatible way
 213 < mclasen> ebassi: I think you had some concerns about the fate of libgdk ?
 214 < mclasen> the other work that has happend in the branch so far is mainly
 215 < ebassi> it was mostly a concern about dependencies; if I wanted to have a gdk backend for clutter then it would have been nice not to bring the whole gtk on top
 216 < mclasen> - hide class and instance structures
 217 < mclasen> - add vfuncs for anything thats currently done in ad hoc ways via windowing functions implemented in each backend
 218 < mclasen> ebassi: I'd be open to unroll that unification one level
 219 < mclasen> ie we could have libgdk.so and libgtk.so
 220 < mclasen> just no more libgdk-x11.so vs libgdk-win32.so vs...
 221 < ebassi> mclasen: sounds fine to me
 222 < Company> we could also still do that, as we basically only need one entry point ("open a display")
 223 < mclasen> right
 224 < Company> but i'd rather not get into the loadable modules business...
 225 < mclasen> that entry point is gdk_display_manager_get() in the branch
 226 < mclasen> thats the function that decides which backend to instantiate
 227 < mclasen> that is the singleton we rely on
 228 < tristan> I guess a minor point, it's nice if backend maintainers can still maintain a backend not included in libgdk
 229 < ebassi> I've noticed that GdkDisplay is not abstract
 230 < ebassi> tristan: that would mean adding extension points
 231 < mclasen> ebassi: oh, we could certainly make those abstract
 232 < tristan> i.e. able to link libgtk to mycustomgdkbackend
 233 < mclasen> tristan: its not possible now, really
 234 < ebassi> tristan: but the objects rely on a lot of internal API
 235 < Company> tristan: NO
 236 < krh> tristan: I'd ver very wary about exposing so much internal api
 237 < Company> tristan: that way we double our exposed api
 238 < ebassi> it would mean making internal API public
 239 < mclasen> in terms of api/abi breaks, what is left to do is
 240 < krh> and with git, everybody can just clone gtk and hack away
 241 < krh> it's what I do ;)
 242 < mclasen> - turn gdkcursor into an object and make it opaque
 243 < tristan> ok, I'll shut up :)
 244 < mclasen> - decided what to do with a lot of the sucky apis that are left for virtualization
 245 < Company> gdkcursor is my job, once i can compile without warnings again
 246 < mclasen> let me list some of the 'sucky' apis (and what I thought we might do with them)
 247 < mclasen> gdk_atom_... - should really generic, ie not depend on backends
 248 < krh> mclasen: don't you want that to hook into the X atoms?
 249 < mclasen> krh: yes, we have functions that translate gdkatom <> x atom
 250 < ebassi> krh: we already have code to turn an X11 atom to/from Gdk atom
 251 < Company> mclasen: why do we have gdk atoms even?
 252 < mclasen> we already needed that because x atoms are per display
 253 < Company> mclasen: can't we just use strings?
 254 < krh> mclasen: so how can it not depend on the backend?
 255 < Company> krh: all functions that take GdkAtoms are virtualized
 256 < Company> krh: and the x11 ones do get_xatom_for_gdk_atom
 257 < mclasen> currently each backend implements its own functions for turning strings into gdkatomes
 258 < mclasen> I think we should lift them to the generic gdk code
 259 < mclasen> anyway, moving on 
 260 < Company> mclasen: why not use strings?
 261 < mclasen> gdk_error_trap_... - really only does anything on X
 262 < mclasen> dunno, don't really want to discuss each api at length right now
 263 < Company> just making sure i don't miss things
 264 < mclasen> gdk_keyval_from/to_name - should probably just be generic as well
 265 < mclasen> osx and win32 already have their own tables for that, the x backend uses the xlib api for it atm
 266 < mclasen> then there is a bunch of text encoding stuff like utf8_to_string, utf8_to_compound_text, etc
 267 < mclasen> I
 268 < mclasen> I'd tend to say anything touching compound text should be x-specific api
 269 < Company> that
 270 < Company> or we should have a generic dnd api (or a text atom) that does this text magic automatically
 271 < Company> ie move things from GtkSelection t gdk selection code
 272 < mclasen> possibly, but probably not before 3.0...
 273 < mclasen> then there is the foreign window stuff
 274 < mclasen> gdk_window_foreign_new_for_display etc
 275 < mclasen> I think that should also be backend-specific
 276 < krh> I think that should be X specific
 277 < krh> or backend specific
 278 < Company> mclasen: you mean gdk_x11_window_foreign_new_for_display() ?
 279 < mclasen> yeah, returning a GdkWindow
 280 < mclasen> not good ?
 281 < mitch> i think there should be a generic window handle object for native/foreign windows
 282 < Company> yes, my idea exactly
 283 < krh> no
 284 < Company> mitch: GdkWindow
 285 < krh> yea, that's good
 286 < mclasen> the last in my list of sucky apis is gdk_spawn...
 287 < krh> not a GdkNativeWindow wrapper around whatever the gd-backend native type is
 288 < mitch> Company: yes, but the things need to be passed around, no?
 289 < mclasen> only the X implementation is not a straight wrapper around g_spawn
 290 < mclasen> and it only sets display
 291 < Company> dunno
 292 < mclasen> so I'd like to deprecate/remove it in favor of g_spawn and/or g_app_launch ...
 293 < Company> that works
 294 < Company> just don't make it backend specific
 295 < tristan> huh ? you mean to get a foreign window you need to be the one who launched the foreign process ?
 296 < tristan> what have I missed ?
 297 < Company> because that'd require ifdefs where none were necesary before
 298 < ebassi> gchar **gdk_x11_set_environment (const gchar * const orig_env[])
 299 < Company> tristan: you're mixing 2 topics up
 300 < tristan> oh /me sees gdk_spawn, sorry
 301 < pbor> I do not like killing, gtk_spawn: then you are just pushing apps to do ifdef themself or be buggy when it comes to screen handling
 302 < mclasen> ebassi: GdkAppLaunchContext does that already for you...
 303 < mclasen> pbor: g_app_info_new_from_commandline, no ifdefs
 304 < pbor> is that new?
 305 < pbor> I do not see it in the docs
 306 < pbor> anyway ok, as long as there is a "right" way to do it, I take back my concern :)
 307 < mclasen> http://library.gnome.org/devel/gio/2.27/GAppInfo.html#g-app-info-create-from-commandline
 308 < Company> mclasen: also, if we move the error trap apis to x11, we should rename them sanely
 309 < Company> mclasen: pop_ignored() => pop()
 310 < mclasen> I don't know if we really want to move them to x11
 311 < Company> and invent a better name for pop_ignored()
 312 < mclasen> that would mean lots of ifdefs in gtk
 313 < Company> socket and plug do that
 314 < Company> and selection
 315  * mclasen finds 8 source files with error_trap in them in gtk/
 316 < mclasen> less than I expected
 317 < Company> most of them are *-x11.c :p
 318 < mclasen> no
 319 < kris> ah ja sucky GDK APIs
 320 < mclasen> so, that sums up my collection of sucky gdk apis
 321 < mclasen> I'm looking for some guidance for how to proceed with this work
 322 < mclasen> we probably won't get parallel backends working for 3.0
 323 < mclasen> but I'd like to get the abi/api changes in place
 324 < Company> hrm
 325 < kris> having things like atom, text conversion, selection, etc. generic like you mention sounds like a good plan
 326 < krh> mclasen: but it can happen for 3.x?
 327 < mclasen> one concern is that I haven't kept quartz/win32 in sync on the branch
 328 < Company> depending on the release date, we should at least get the basics done
 329 < mclasen> so there will be fallout for other backends if we merge now
 330 < Company> because currently we regress
 331 < Company> in that it's not possible to install multiple gtks
 332 < kris> mclasen: how many changes did you make?
 333 < krh> Company: good point
 334 < Company> kris: the vfuncization is quite a bit of (bring) work
 335 < kris> mclasen: if you think I can sync up quartz in an hour or 2, I can look at that before the end of the week
 336 < Company> *boring
 337 < mclasen> kris: more like an evening, I guess
 338 < ebassi> krh: 135 files changed, 6686 insertions(+), 5493 deletions(-)
 339 < ebassi> (against master)
 340 < mclasen> dangit, +1000
 341 < krh> ebassi: kr<TAB>?
 342 < mclasen> but the code gets much cleaner, so its worth the extra lines
 343 < ebassi> yeah, sorry - 'twas for kris :-)
 344 < Company> mclasen: we can get the lines back if we remove some more useless apis! ;)
 345 < kris> mclasen: ok, then it depends really on how quick I get the final pixel nitpicking done for treeview-refactor
 346 < kris> mclasen: which I had schedule for one or two evenings starting tomorrow
 347 < mclasen> kris: I can probably get a bunch of the conversion done blindly
 348 < mclasen> I'll just have to rely on you to make things build and work afterwards...
 349 < kris> that's not a problem, I've done that for rendering-cleanup as well
 350 < mclasen> ok, I can sink some time into catching up the other backends then
 351 < mclasen> Company: can you help out with dealing with some of the sucky apis ?
 352 < Company> mclasen: when i know about them, yes
 353 < mclasen> Company: and do you think that installing multiple gdks in parallel is a very common thing ?
 354  * mclasen has never heard of it
 355 < mclasen> Company: do you know about them now that I've listed them ?
 356 < Company> mclasen: nope, don't think so - but i don't see why parrallel installed gdk are so far off from once we get gdk-backend merged
 357 < Company> mclasen: "know about them" == have a clue what the apis are ncecessary and used for
 358 < Company> mclasen: ie i still don't understand the selection code
 359 < Company> mclasen: also, how api-break happy are we for those apis?
 360 < Company> get-them-right vs get-them-to-continue-working
 361 < kris> the selection api is also on my list of apis to learn to understand ;)
 362  * mclasen thinks that dnd+selection is in for some high-level review for gtk4
 363 < pbor> Company: I'd say let's see case by case: rarely used apis -> fix properly, common apis -> evaluate pro/cons
 364 < mclasen> yeah
 365 < Company> pbor: in general gdk api's are the first case ;)
 366  * mclasen already 'broke
 367 < mclasen> ' one api by moving set_sm_client_id to X11 specific
 368 < mclasen> I guess nobody will ever notice
 369 < krh> I guess the parallel installable gdk/gtk is less interesting since an application can only link to one of them
 370 < mclasen> yeah, its really only for installer-doesnt-use-X kind of situations
 371 < Company> true
 372 < mclasen> and in that case, you can just as well install the app-specific gtk somewhere else...
 373 < krh> and you can still do it by just renaming the libraries
 374 < Company> krh: i guess we don't regress then
 375 < krh> which is an appropriate ad-hoc hack for the installer case
 376 < mclasen> ok, how does this fit in our schedule ?
 377 < krh> mclasen: I guess there are two things here: gdk-backend and fixing the broken APIs
 378 < mclasen> yeah
 379 < krh> gdk-backend seems doable for 3.0
 380 < mclasen> I'll switch the gdk-backend branch back to separate libgdk
 381 < krh> but the interesting thing to do for 3.0 is fixing the broken apis
 382 < mclasen> then we need the cursor work done
 383 < mclasen> I think that is doable this week
 384 < mclasen> fixing remaining sucky apis will probably take longer
 385 < mclasen> so would have to be deferred until the xmas snapshot
 386 < Company> yes, cursor is easy
 387 < pbor> if they do not affect 99% of apps, it is not a problem
 388 < Company> cursor is only gdk_cursor_ref/unref vs g_object_ref/unref
 389 < Company> and we can keep them deprecated if we want to
 390 < mclasen> Company: I think we probably want cursor_ref/unref in place for now, as deprecated #defines ?
 391 < Company> right
 392 < pbor> so to move on, there are few other api issues open I think (though mostly minor?)... /me pastes a list he prepared in the mean time
 393 < pbor>  - review api issues in bugzilla that are on the 3.0 milestone
 394 < pbor>  - what's the status with GtkApplication?
 395 < pbor>  - what happen to GPeriodic and the corresponding gtk business?
 396 < pbor>  - Alex's radio
 397 < pbor>  - Are there still api issues open related to Style? GdkColor?
 398 < pbor> also while working on pygobject some issues showed up
 399 < pbor>  - does scrollview_new still needs param?
 400 < pbor>  - GtkBuildable seems super broken: it is an interface but none of its implementors implement all its methods
 401 < ebassi> for GPeriodic, I think we need to back it out
 402 < mclasen> pbor: thanks for the list
 403 < ebassi> I haven't had much time for porting clutter, and we still need some reviewing for that
 404 < pbor> ebassi: that was kind of my implied point :)
 405 < ebassi> GtkApplication is still pending on the action API that desrt was working on
 406 < mclasen> ebassi: since we haven't gotten the gtk integration done, its not big loss to back it out
 407 < ebassi> though generally I think we can punt that for the time being
 408 < mclasen> yeah, gtkapplication is useful as it is now
 409 < ebassi> since apps have been ported and they work already
 410 < mclasen> even if incomplete
 411  * Company votes YES on gperiodic backout
 412 < mclasen> now sure what is broken about GtkBuildable ?
 413 < mclasen> does it not work ?
 414 < tristan> pbor, is it language bindings your concerned about for buildable ?
 415 < mclasen> so we tell desrt to try again for gtk4 ?
 416 < pbor> mclasen: well, it works because the few callers assume that some of the function are safe to call just under some conditions
 417 < pbor> which kind of defeats the point of an interface
 418 < tristan> that's not exactly true
 419 < tristan> how so ?
 420 < mclasen> who do you expect to call buildable functions ?
 421 < ebassi> mclasen: for GPeriodic, yes
 422 < pbor> tristan: it came up in laguage bindings because for a bit pygobject enforced the if an object implements an interaface all its method must have an implementation up the hierarchy
 423 < pbor> thought now the enforcing has been removed
 424 < mclasen> sounds like an unwarranted assumption on their part
 425 < pbor> sure, that's why the enforcing has been removed
 426 < tristan> right, I have noticed some places where the implementations fail to chain up to parent classes
 427 < tristan> but those are class-specific bugs
 428 < tristan> i.e. get_internal_child() has to chain up
 429 < pbor> tristan: it is not about chain up, look at container: it is buildable but it only implements some methods
 430 < tristan> sure
 431 < tristan> and that is a problem because... ?
 432 < pbor> and container's derivative do not implement them
 433 < mclasen> moving up the list, scrolled_window_new could certainly loose those arguments
 434 < mclasen> but I guess that would be a painful api break this late in the game
 435 < tristan> gtk_buildalbe_* *apis* are safe to call
 436 < tristan> pbor, and why would a containers derivative have to implement something that it trusts the container's implementation to take care of ?
 437 < pbor> anyway, let's drop the buildable thingie... it is not even an api issue
 438 < tristan> I'd love to drop the "constructor" stuff... if we could drop uimanagers... but we still cant do that :(
 439 < mclasen> I think we dropped the ball for scrolledwindow and have to live with NULL, NULL for a little longer 
 440 < pbor> ok
 441 < ebassi> right, moving on: GtkRadioGroup?
 442 < mclasen> I think it is in the little gain, big pain category of api breaks
 443 < mclasen> so, I did some work on that; desrt wasn't really happy with it
 444 < mclasen> since he wanted to have buttons backed by actions as models
 445 < mclasen> and only group the models
 446 < mclasen> there is a branch where we tried to work out the necessary button changes for that idea
 447 < mclasen> but it is not complete
 448 < ebassi> I think that'll have to wait, now
 449 < mclasen> yeah, I guess so too
 450 < mitch> from my pov,e.g. in gimp there are at least 4 ways to construct button groups
 451 < mclasen> I may still land a small part of the button branch
 452 < mitch> and they all make sense
 453 < mitch> forcing them into a GtkRadioGroup would make things more complicated in some cases
 454 < mclasen> (the part about having a indicator-style property on GtkButton)
 455 < mclasen> so, what else is left on the 3.0 api issues list ?
 456 < pbor> mmm, to be honest I was happy enough with alex original proposal
 457 < pbor> anything is better than GList as is now
 458 < mitch> garnacho_: what about the remaining input issued?
 459 < garnacho_> mclasen: I've yet to land my xi2 patches
 460 < mclasen> yes, you do
 461 < mitch> heh
 462 < garnacho_> can do that tonight
 463 < mclasen> ok
 464 < Company> mclasen: i still have an open question about removing GtkStyle and GdkColor completely
 465  * mitch wants get_source_event
 466 < mclasen> I can't see us doing that at this point, really
 467 < mclasen> we are not even there yet in terms of having replacements for all color properties
 468 < Company> i don't see the usefulness at all in keeping them
 469 < Company> because everybody that is porting must do the expose => draw port
 470 < mitch> if you want that, i want gtkhbox and gtkvbox gone :P
 471 < Company> which touches all the style functions
 472 < Company> note that gtk_paint_foo() are breaking API
 473 < garnacho_> Company: I think most people has ported by now to that, because it's only changing one parameter :/
 474 < Company> garnacho_: most people = only gnome
 475  * mclasen just doesn't believe we can do big api removals at this point
 476 < Company> garnacho_: and mitch
 477 < mclasen> the concern is not third party stuff, but just gnome three dot oh
 478 < Company> garnacho_: neither mozilla nor openoffice nor inkscape nor transmission did
 479 < Company> mclasen: do we have an idea how big the 3.0 impact is?
 480 < Company> mclasen: do we need to activate fredp magic again? :)
 481 < garnacho_> Company: right, but telling them it was just a bump in the rollercoaster... :)
 482 < mclasen> you mean the impact of removing gtkstyle and gdkcolor ?
 483 < Company> mclasen: yeah
 484 < pbor> maybe we should try coccinelle on gnome :)
 485 < mclasen> I don't, and I really don't think we can do it anymore
 486 < mclasen> people are going into xmas break now
 487 < mitch> so let's break a bit :P
 488 < mitch> ha ha
 489 < mclasen> we can't afford to loose half of january for playing catchup with last-minute gtk api breaks
 490 < Company> our very own xmas break \o/
 491 < mitch> mclasen: at this point in time, i give in and agree
 492 < krh> yeah, xmas api break
 493 < mclasen> it will all be deprecated
 494 < tristan> where are we right now then, somewhere in the middle of "last minute breaks" ?
 495 < mclasen> and we can take our time to port gtk internally to the new stuff
 496 < garnacho_> mclasen: and I have a patch to reduce the code behind it to a minimum
 497 < mclasen> and we will survive ignoring gtkstyle until 4.0 '
 498 < mclasen> just like we did with GtkList and GtkText and whatnot
 499 < mitch> mclasen: oh btw, do we have removal of all sealed members on the 3.0 blocker list?
 500 < mclasen> mitch: the gdk-backend branch does a good bunch of that for gdk
 501 < mclasen> since it hides all instance and class structs for good
 502 < mitch> yes but gtk is much worse
 503 < Company> yeah, if we actually port stuff to GdkRGBA and style context internally
 504 < Company> stuff should look reasonably contained
 505 < Company> at least if we don't also support GdkColor everywhere
 506 < mclasen> mitch: I haven't actively followed the sealing work, really
 507 < mclasen> mitch: not sure if jjardon is around
 508 < mitch> mclasen: but it is indeed a blocker
 509 < mclasen> yes, I agree
 510 < mclasen> we should do that
 511 < mclasen> any volunteers ?
 512 < mitch> grep GSEAL gtk/*.h | wc
 513 < mitch>     195     940   10520
 514 < mitch> 195 members to go
 515 < mclasen> not too bad
 516 < mitch> indeed
 517 < mitch> i'm off for xmas vacation, so we must chain jjardon back to the keyboard
 518 < mclasen> I'll see what I can done by Monday
 519 < martyn> mclasen: so what's the ETA for for 3.0 then, are we delaying things?
 520 < martyn> mitch: :)
 521 < jjardon> not all the widgets are ported, sorry lack of time :/
 522 < mclasen> ok, time to bring that topic up, I guess
 523 < mclasen> release date
 524 < mitch> jjardon: real jobs suck :)
 525 < Company> mclasen: i'd like to do a feature freeze
 526 < mitch> martyn: sorry :P
 527 < jjardon> mitch: indeed ;)
 528 < Company> mclasen: that way things can settle and we can fix messes that we still encounter
 529 < mclasen> Company: a little late for that...
 530 < Company> lik the extension event stuff from today
 531 < martyn> mitch: grmbl
 532 < mclasen> or do you mean, delay the official 3.0 ?
 533  * martyn gets mitch to clean the toilets
 534 < Company> mclasen: indeed, but we're still actively doing features
 535 < mitch> haha
 536 < mclasen> and instead realease something like 2.99 in early january ?
 537 < Company> mclasen: yeah, delay the official 3.0
 538 < Company> yeah
 539 < mitch> i'm all for delaying
 540 < mclasen> whats the general feeling on that ?
 541 < krh> mclasen: if missed the conclusion on gdk-backed vs gtk 3.0
 542 < krh> s/if/I
 543 < tristan> delay++, api freeze soonish
 544 < Company> we need to stop people from bringing up gdk-backend and tree menus and cell areas and more gdk cleanup and
 545 < mitch> 4 more weeks in the new year (after xmas break) woulb be really good for the shape of 3.0
 546 < mclasen> krh: I think the conclusion was to try and get the api/abi changes landed
 547 < tristan> wait, what is the release date before delaying it ?
 548 < ebassi> delaying two or three weeks and do a feature freeze around xmas sounds good to me
 549 < krh> mclasen: excellent
 550 < ebassi> tristan: the endgame for 3.0 was end of this month
 551 < garnacho_> I guess delaying should be fine as long as we're (close to) api stable anyway
 552 < Company> tristan: "this year" was what we told release-team
 553 < mclasen> tristan: the original plan was 'end of year'
 554 < tristan> right
 555 < mclasen> so we will have to deliver something that is api stable and feature frozen, more or less
 556 < mclasen> at that date
 557 < martyn> I don't think we should really care what we told people or what the plan was, we should make sure it is right
 558 < tristan> I think delay official 3.0 is important
 559 < martyn> it's done when it's done
 560 < mclasen> I think calling it 2.99 and holding out for a few weeks is ok
 561 < mitch> yes we must not rush it out, or pain is guaranteed
 562 < tristan> yeah, still feature/api frozen by that time
 563 < martyn> we can alleviate this with the 2.99 as mclasen says
 564 < mitch> tristan: minus missing api that is discovered late, and we will have that :(
 565 < mclasen> practically, the difference between 2.99/3.0 vs 3.0/3.0.1 is probably small
 566 < Company> 2.99/3.0 allows api breaks
 567 < Company> if deemed necessary
 568 < mclasen> but since we have been pushing hard with features and api changes until late in the game, giving things some time to settle might be good
 569 < Company> "oops, forgot this tiny thing" kind of failures :)
 570 < mitch> and nothing keeps us from making a real soon 3.2 if we find something is really b0rk
 571 < mclasen> I will take this to the release team, I guess
 572 < jjardon> about gseal work, we still dont have a clear history about gtkadjustment
 573 < mclasen> don't really want to surprise them with that
 574 < mclasen> we can probably also use the weeks we win to sort out some of the theming fallout
 575 < mclasen> garnacho_: how has style-context been received so far ?
 576  * mclasen saw jimmac pull out some hair earlier today...
 577 < mitch> i think it's great since i understand it :)
 578 < garnacho_> mclasen: yeah, he found out some real bugs
 579 < tristan> a couple of things I wanted to look at before freezing up: "changing the minimum-for-minimum" strategy for toplevel windows discussion we had last month on gtk-devel-list
 580 < garnacho_> so far reception seems positive, only one crazy engine dev asking for widget pointers back :P
 581 < ebassi> garnacho_: are we allowed to mock this guy? :-)
 582 < tristan> ... being an api breaker (as things might work differently implicitly)
 583 < garnacho_> ebassi: I'll be polite and not embarrass him :)
 584 < mclasen> tristan: I don't recall the outcome of that discussion, tbh
 585 < garnacho_> but "i need to connect to signals" wasn't a compelling argument
 586 < tristan> mclasen, what do you think about that one... we make labels return a very small minimum width by default
 587 < tristan> and then we say that one should set a minimum width of the toplevel window
 588 < tristan> so as to avoid rediculously large heights
 589 < tristan> it's basically moving all the per-widget compensation to the top-level
 590 < tristan> hp said that the reasonable window width could be a complex guess one shot on the top-level
 591 < tristan> I dont know
 592 < tristan> but I remember owen felt very strongly about this
 593 < tristan> as it stands the minimum width of a label by default is much wider than it's actual minimum width... so that minimum-for-minimum on the toplevel doesnt give you a whacky size
 594 < mclasen> so you want to make things so that windows by themselves snap to a very narrow, tall shape ?
 595 < mclasen> and expect people to force a reasonable size by putting a min width on the window ?
 596 < tristan> that's the general idea, the author decides a decent ratio for the window instead of tinkering with individual label sizes to get the size right
 597 < tristan> I think its very late in the game for such a change, I know havoc had an idea to make the ratio decent by default
 598 < mclasen> as a general idea, avoiding label-level tinkering seems right
 599 < Company> hrm
 600 < mclasen> but as you say, scary change late in the game
 601 < Company> can't we default windows to screen-ratio?
 602 < Company> ie if the screen is 4:3, make the window as close to 4:3 as possible?
 603 < mclasen> it might be less scary if we could somehow make this opt-in by some policy property on the window
 604 < tristan> right, something like that, it requires a bisection of height-for-width requests initially if a manual width is not explicitly set
 605 < tristan> mclasen, make label's implied minimum width change depending on a top-level window setting ?
 606 < tristan> possibly
 607 < mclasen> no, that doesn't sound right :-(
 608 < mclasen> but I see we are beyond the 2 hour mark
 609 < mclasen> anything we need to nail down today, still ?
 610 < mclasen> website update ?
 611 < ebassi> xi2 stuff?
 612 < mclasen> martyn: whats your thought on that ?
 613 < mclasen> what xi2 stuff ?
 614 < mclasen> oh turning it on by default ?
 615 < martyn> mclasen: there isn't really anything to cover
 616 < garnacho_> mclasen: yes, I put it late in the list
 617 < martyn> I think the website design which we went through a few months back is really quite comprehensive
 618 < mclasen> I guess the question is, do you want to go ahead with the new website when we release 2.99, or wait for 3.0 ?
 619 < mclasen> garnacho_: I saw it; I think I said earlier that I am not opposed to changing the default
 620 < garnacho_> oh, didn't imply that :)
 621 < garnacho_> alright
 622 < garnacho_> will push that patch as well
 623 < garnacho_> err s/imply/infer/
 624 < martyn> crap
 625 < martyn> damn machine rebooted
 626 < martyn> about the website ...
 627 < martyn> I was really just checking for a release date to co-inside with the official release
 628 < jjardon> I'd say wait for GTK+3
 629 < martyn> since we're delaying the release until late ? January, we can revisit this in a later meeting I think
 630 < mclasen> lets make that a little more concrete
 631 < martyn> from my point of view, the work for the website is really just a switch over
 632 < mclasen> I'll say I do the 2.99 release in the first week of January
 633 < mclasen> should we plan for 3.0 one month after that ?
 634 < martyn> mclasen: first week in Feb?
 635 < mclasen> yes
 636 < martyn> sure makes sense to me
 637 < ebassi> mclasen: sounds like a plan
 638 < martyn> though I would also be happy with only 2 to 3 weeks personally, but you know me, we release a lot on the Tracker team ;)
 639 < mclasen> oh tracker
 640 < mclasen> good point
 641 < martyn> uh oh what did I say
 642 < mclasen> did you want to merge that rewritten search engine ?
 643 < martyn> mclasen: done
 644 < mclasen> or did you do it and I didn't notice :-)
 645 < mclasen> good work
 646 < martyn> mclasen: np
 647 < jjardon> for the record, GNOME api freeze is on Jan 31 
 648 < ebassi> we're special :-)
 649 < mclasen> ok, we'll beat that by declaring 2.99 api frozen except for emergencies
 650 < jjardon> :)
 651 < mclasen> anything else for today, or should we wrap up ?
 652 < martyn> mclasen: there was the case where you wanted to have the work as a backend for nautilus too with some integration in GIO perhaps (IIRC)
 653 < pbor> gnome does not have much api to freeze anymore
 654 < mclasen> should there be another meeting before xmas ?
 655 < martyn> mclasen: did you want that done before 3.0 ?
 656 < mclasen> martyn: didn't expect it, no
 657 < martyn> ok
 658 < mclasen> that was more medium-term talk
 659 < martyn> let's leave it for now
 660 < ebassi> mclasen: 21 or 28?
 661 < mclasen> I'll be gone on 28, I think
 662 < mclasen> we can also just play it by ear and see if there's anything to discuss next week
 663 < ebassi> sounds good to me
 664 < mclasen> ok then
 665 < mclasen> time to stop
 666  * mclasen is hungry
 667 < ebassi> right
 668 < tristan> time to sleep
 669 < ebassi> thanks everyone
 670 < mclasen> later
 671 < pbor> 'night
 672 < martyn> thanks all
 673 < martyn> good night
 674 < ebassi> as usual, minutes on the list and log on the wiki as soon as I can