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
Attached FilesTo refer to attachments on a page, use attachment:filename, as shown below in the list of files. Do NOT use the URL of the [get] link, since this is subject to change and can break easily.
You are not allowed to attach a file to this page.