< ebassi> as usual, the meeting agenda is here: http://live.gnome.org/GTK%2B/Meetings < ebassi> • Release date for 3.0 < ebassi> • Pending tasks < ebassi> • Wevsite update * mclasen thought we had more < tristan> pending tasks includes a few items < kris> there's a bunch of subpoints below pending tasks < Company> that's because "pending tasks" has more < tristan> :) < mclasen> oh, ok < garnacho_> too late to add one more for pending tasks? < Company> we basically only have "pending tasks" ;) * mclasen follows the link < Company> garnacho_: go ahead < ebassi> yeah, writing the sub-points takes time :-P < mclasen> should we start with pending tasks, or just go top-down ? < Company> i guess deciding on the release date after pending tasks is a good idea < tristan> seems to make sense to do "release date" after pending tasks < ebassi> +1 < mclasen> ok, so pending tasks first < ebassi> • treeview refactor < ebassi> which I guess is for tristan and kris < martyn> right < kris> yes so tristan did a lot of work on this < garnacho_> hrm, lost the lgo password < kris> and move all cell allocation/rendering/etc code into GtkCellArea/GtkCellAreaContext and related classes < kris> which can be re-used by other widgets, for example icon view, combo box < mclasen> so, what is the plan here, land this all in one big drop ? < tristan> yup, dont mean to interrupt... I (we) think it's ready to land < kris> we think it is about ready to land < tristan> treeview-refactor branch at least < kris> if somebody would like to review the new GtkCellArea* classes that would be great < kris> i tried to keep up with tristan :) < tristan> icon-view-refactor is a small diff... would be nice to get a review < kris> and reviewed a good amount of code, especially the changes impacting tree view < tristan> and then there's combo-refactor which would be also nice to get a review < kris> We can land this for GtkTreeView, without changing API in GtkTreeView, so the end-user impact is neglectible < mclasen> not changing widget apis is very good news indeed < mclasen> how about cell renderers ? < tristan> adds one or 2 apis but doesnt change anything < kris> cell renderers already got API extensions for hfw some months ago < kris> no changes apart from that < tristan> on a semi-related note I've been wanting to change cell-renderer (text cell renderer) properties a bit < tristan> because setting "wrap-width" in terms of pixels is just uncomfortable... but anyway < mclasen> kris: does the refactoring relate to your treeview-ng plans at all ? < kris> mclasen: a big part of treeview-ng was actually refactoring < kris> mclasen: so that's basically done by this work < mclasen> ok, nice < kris> another part of treeview-ng is re-considering all the validation machinery < 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 < mclasen> I see < kris> a height-for-width implementation is something we are not sure we will get done for 3.0 < 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 < 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) < mclasen> but I'll basically defer to you as the treeview authority, kris < kris> but this code duplication is not new, is it? < tristan> unifying all of that stuff would imply separating size negotiation tactics from widgets, in a way < tristan> because widgets are 1 for 1 < tristan> cell renderers need alignments etc < tristan> ofcourse cell rendering using widgets is doable somehow, I wont argue that < mclasen> kris: true, it is not new. but cell renderers were much more limited so ar < Company> did you do any tests on multiple thousand row treeviews? < mclasen> now we get containers there, and focus navigation, and ... < kris> mclasen: focus navigation was first hidden in GtkTreeView, so that is not especially new < tristan> and icon view < Company> mclasen: i think for 4.0 we want to get rid of cell renderers < mclasen> kris: as I said, this is just a vague feeling, and may be entirely unjustified < Company> mclasen: we'll otherwise grow 2 different toolkits - one based on GtkWidget, one based on GtkCellRenderer < mclasen> if you think this is the way forward, by all means, lets get it merged * Company waits for GtkCellRendererTreeView < kris> we have not really added any new capabilities to cell renderers < mclasen> with GtkCellRendererCombo, we are already using cell renderers recursively... < 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 < Company> the problem is that so far widgets couldn't be used the way cell renderers are < Company> because they have GDK windows and all that mess, but that'll be going away < tristan> a possible future I could see, is GtkCellRendererWidget < tristan> if widgets can be usable to render cells, that could obsolete all the renderers < mclasen> lets not get too distracted by 4.0 stuff in this meeting, though < ebassi> or make GtkCellRenderer an interface implementable by Widget < tristan> ebassi, or that yes < tristan> the cell-area semantics take care of something not done by normal containers < mclasen> kris,tristan: is there a list of branches that need review, do we need to look for volunteers to do that ? < tristan> and that is cell alignments mostly < tristan> context of requesting a group of rows etc < kris> mclasen: I think it would be good if somebody would review the API of the new GtkCellArea* classes, which are in treeview-refactor < kris> mclasen: and we need a volunteer for combo-refactor I guess < kris> mclasen: I can have a look at combo-refactor as well, but I have not been maintaining for the last few years < tristan> that would be good, combo-refactor also introduces GtkTreeMenu < mclasen> whats the timeline for getting reviews done and moving on the merges ? < tristan> which we can keep private or expose, but I've written all the docs for it as a clean exposable class * mclasen would like to do a close to api-final snapshot this week < kris> I am about done with treeview-refactor < ebassi> tristan: I'm not so sure about TreeMenu for 3.0 < kris> so it depends on how quick somebody can have a look at GtkCellArea* < kris> and at combo-refactor * mclasen would be much more comfortable to keep the treemenu private for now < Company> kris: i think if you and tristan agree on CellArea, then it's ok to merge < kris> i guess then we can consider merging treeview-refactor this week, so it will make mclasen's snapshot < kris> what about combo-refactor? < mclasen> I agree about merging the treeview-refactor < mclasen> and I can try to look over the combo-refactor branch < tristan> the diff of gtkcombobox.c is mostly api removals * mclasen is at least as interested in the iconview-refactor < tristan> I originally went with a "clean house" in combobox.c but got bitten by merges < mclasen> is iconview-refactor ready ? < tristan> yes. < tristan> icon-view-refactor was easier than I expected < kris> I think iconview-refactor doesn't do any API-incompatible changes, does it? < tristan> and it removes all the box[] arrays and hand dealing with renderers < tristan> no it doesnt < kris> treeview-refactor is most important to land, since it adds a good bunch of API < tristan> it's clean < mclasen> that only cellareafies the icon view ? does it also hfw it ? < tristan> mclasen, internally it does to an extent, but it doesnt hfw it completely < tristan> by that I mean... that all icons always had the same width < tristan> so, the width of an icon is determined by its smallest icon < mclasen> might be good to have mitch testdrive the iconview-refactor, he's had some fun with icon views in the gimp... < tristan> cells in the area require only the height for that width < tristan> that applies to a manually set "item-width" too < tristan> but things I'd like to do: < tristan> - Let icon view return proper min/nat widths < tristan> - handle icon view with a fixed number of columns in a hfw way < Company> oh that reminds me < Company> did we agree on the get_foo apis never needing to return more than screen width/height? < Company> get_preferred_foo() < Company> so that iconview can actually stop computing height for width once it hits a certain size < tristan> that's still a theory ... but I agree < Company> so that my home dir in an iconview actually resizes before i alt-tab? < tristan> for a treeview or icon view that needs to answer height-for-arbitrary-width... < tristan> it only needs to calculate screen height for that width yes < tristan> this is under the assumption that views not in a scrolled window are not super huge (taller than the screen) < Company> why? < tristan> views that are in a scrolled window, the scrolled window is only concerned with "whether the height will fit the allocation" < tristan> i.e. if it needs a vscrollbar or not < tristan> after that it gives the view an allocation < Company> even if i stuff a treeview into the toplevel directly < tristan> the allocation is different than the request < tristan> with an allocation you push the adjustment values as you caluclate the million rows in the background < Company> what does it help you that the natural height is 1892034839 pixels? < tristan> Company, I think we agree here < Company> i'll add code that manually clamps it then < tristan> I'm not arguing, just explaining why its not needed to calculate more than screen height for a request < Company> so we can test that it works < 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 ? < ebassi> sounds okay to me < tristan> what should I do for "privatizing treemenu" ? < tristan> remove index from gtk-docs.sgml ? < tristan> and gtk.symbols/gtk3-sections.txt ? < ebassi> just put it in an non-installed header, and prefix every function in the header with '_' < ebassi> and remove it from the API reference < ebassi> (if it's used internally) < tristan> alright, I'll do that < ebassi> if not, just move it to a separate branch < tristan> ebassi, it's what does the combo-box menu < ebassi> okay, then the privatization of the symbols should be enough < ebassi> right, do we have other issues with this? < kris> Company: I will also test the new code with a very large tree view btw (a bit late reply) < ebassi> (mclasen dropped :-/) < ebassi> any takers for reviewing combo-box-refactor? < mclasen> GRR < Company> there we go :) < kris> ebassi: mclasen said he would have a look * mclasen hit an awesome patch of rawhide instability < mclasen> at-spi triggering iptables which in turn run into some selinux kernel oops... < ebassi> kris: thought it was for icon-view-refactory -- but sounds okay :-) < kris> ebassi: i will probably have a look as well, but that will defintely not be before next week < krh> mclasen: did you at least get the kms enabled oops? :) < mclasen> the screen continued to look shiny, it just stopped responding... < mclasen> what decisions did I miss ? < krh> oh, it should bounce back to a very unshiny kms textmode * krh shuts up < mclasen> krh: thats what happened after my first few reboots... < ebassi> mclasen: nothing much < mclasen> still discussing tree/icon/combo refactor ? < tristan> mclasen, we know that nobody ever wants to look at combo-box code... < ebassi> mclasen: finishing now with a missing reviewer < tristan> and are looking for volunteers < mclasen> I will try to take a look < mclasen> and we agree to land the tree and iconview parts this week ? < ebassi> right, we should probably jump to the next item < mclasen> or just treeview ? < ebassi> treeview was agreed < mclasen> ok < mclasen> let move on < ebassi> iconview depended on a reviewer < tristan> we agreed on treeview, icon-view is really not such a big deal to review < Company> treeview, release, then iconview i'd say < tristan> and it doesnt break api either so, its not blocking 3.0 technically < Company> because then it's easy to pinpoint cellarea vs iconview issues with "were they in the release?" < mclasen> makes sense < mclasen> next topic was gdk-backend ? < ebassi> yes < 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 < mclasen> the goal is to enable having multiple backends in gdk at the same time < mclasen> and pick one at runtime < mclasen> I guess alex motivation was his html5 backend < mclasen> but we will need something like this for x/wayland coexistence too < Company> and we can do quartz/x11 on OS X < mclasen> true < pbor> does it close this bug https://bugzilla.gnome.org/show_bug.cgi?id=97081 ? < Company> which should make kris happy < mclasen> pbor: technically not < pbor> (not that I care, just looking through bugs) < Company> i'd close it - because it has the same result < mclasen> but practically, yes * mclasen is out for 30 seconds < ebassi> I guess backend maintainers need to jump in and see what the backend branch requires < mclasen> the work on the branch is not quite finished < mclasen> what has been done so far includes changing things around so that there is only libgtk.so < Company> the only issue i have with that work is that we found quite a few GDK APIs that suck < mclasen> thats one point I wanted to discuss today - do we need a separate libgdk.so ? < Company> other than that, it's just something that needs to happen in an API-compatible way < mclasen> ebassi: I think you had some concerns about the fate of libgdk ? < mclasen> the other work that has happend in the branch so far is mainly < 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 < mclasen> - hide class and instance structures < mclasen> - add vfuncs for anything thats currently done in ad hoc ways via windowing functions implemented in each backend < mclasen> ebassi: I'd be open to unroll that unification one level < mclasen> ie we could have libgdk.so and libgtk.so < mclasen> just no more libgdk-x11.so vs libgdk-win32.so vs... < ebassi> mclasen: sounds fine to me < Company> we could also still do that, as we basically only need one entry point ("open a display") < mclasen> right < Company> but i'd rather not get into the loadable modules business... < mclasen> that entry point is gdk_display_manager_get() in the branch < mclasen> thats the function that decides which backend to instantiate < mclasen> that is the singleton we rely on < tristan> I guess a minor point, it's nice if backend maintainers can still maintain a backend not included in libgdk < ebassi> I've noticed that GdkDisplay is not abstract < ebassi> tristan: that would mean adding extension points < mclasen> ebassi: oh, we could certainly make those abstract < tristan> i.e. able to link libgtk to mycustomgdkbackend < mclasen> tristan: its not possible now, really < ebassi> tristan: but the objects rely on a lot of internal API < Company> tristan: NO < krh> tristan: I'd ver very wary about exposing so much internal api < Company> tristan: that way we double our exposed api < ebassi> it would mean making internal API public < mclasen> in terms of api/abi breaks, what is left to do is < krh> and with git, everybody can just clone gtk and hack away < krh> it's what I do ;) < mclasen> - turn gdkcursor into an object and make it opaque < tristan> ok, I'll shut up :) < mclasen> - decided what to do with a lot of the sucky apis that are left for virtualization < Company> gdkcursor is my job, once i can compile without warnings again < mclasen> let me list some of the 'sucky' apis (and what I thought we might do with them) < mclasen> gdk_atom_... - should really generic, ie not depend on backends < krh> mclasen: don't you want that to hook into the X atoms? < mclasen> krh: yes, we have functions that translate gdkatom <> x atom < ebassi> krh: we already have code to turn an X11 atom to/from Gdk atom < Company> mclasen: why do we have gdk atoms even? < mclasen> we already needed that because x atoms are per display < Company> mclasen: can't we just use strings? < krh> mclasen: so how can it not depend on the backend? < Company> krh: all functions that take GdkAtoms are virtualized < Company> krh: and the x11 ones do get_xatom_for_gdk_atom < mclasen> currently each backend implements its own functions for turning strings into gdkatomes < mclasen> I think we should lift them to the generic gdk code < mclasen> anyway, moving on < Company> mclasen: why not use strings? < mclasen> gdk_error_trap_... - really only does anything on X < mclasen> dunno, don't really want to discuss each api at length right now < Company> just making sure i don't miss things < mclasen> gdk_keyval_from/to_name - should probably just be generic as well < mclasen> osx and win32 already have their own tables for that, the x backend uses the xlib api for it atm < mclasen> then there is a bunch of text encoding stuff like utf8_to_string, utf8_to_compound_text, etc < mclasen> I < mclasen> I'd tend to say anything touching compound text should be x-specific api < Company> that < Company> or we should have a generic dnd api (or a text atom) that does this text magic automatically < Company> ie move things from GtkSelection t gdk selection code < mclasen> possibly, but probably not before 3.0... < mclasen> then there is the foreign window stuff < mclasen> gdk_window_foreign_new_for_display etc < mclasen> I think that should also be backend-specific < krh> I think that should be X specific < krh> or backend specific < Company> mclasen: you mean gdk_x11_window_foreign_new_for_display() ? < mclasen> yeah, returning a GdkWindow < mclasen> not good ? < mitch> i think there should be a generic window handle object for native/foreign windows < Company> yes, my idea exactly < krh> no < Company> mitch: GdkWindow < krh> yea, that's good < mclasen> the last in my list of sucky apis is gdk_spawn... < krh> not a GdkNativeWindow wrapper around whatever the gd-backend native type is < mitch> Company: yes, but the things need to be passed around, no? < mclasen> only the X implementation is not a straight wrapper around g_spawn < mclasen> and it only sets display < Company> dunno < mclasen> so I'd like to deprecate/remove it in favor of g_spawn and/or g_app_launch ... < Company> that works < Company> just don't make it backend specific < tristan> huh ? you mean to get a foreign window you need to be the one who launched the foreign process ? < tristan> what have I missed ? < Company> because that'd require ifdefs where none were necesary before < ebassi> gchar **gdk_x11_set_environment (const gchar * const orig_env[]) < Company> tristan: you're mixing 2 topics up < tristan> oh /me sees gdk_spawn, sorry < 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 < mclasen> ebassi: GdkAppLaunchContext does that already for you... < mclasen> pbor: g_app_info_new_from_commandline, no ifdefs < pbor> is that new? < pbor> I do not see it in the docs < pbor> anyway ok, as long as there is a "right" way to do it, I take back my concern :) < mclasen> http://library.gnome.org/devel/gio/2.27/GAppInfo.html#g-app-info-create-from-commandline < Company> mclasen: also, if we move the error trap apis to x11, we should rename them sanely < Company> mclasen: pop_ignored() => pop() < mclasen> I don't know if we really want to move them to x11 < Company> and invent a better name for pop_ignored() < mclasen> that would mean lots of ifdefs in gtk < Company> socket and plug do that < Company> and selection * mclasen finds 8 source files with error_trap in them in gtk/ < mclasen> less than I expected < Company> most of them are *-x11.c :p < mclasen> no < kris> ah ja sucky GDK APIs < mclasen> so, that sums up my collection of sucky gdk apis < mclasen> I'm looking for some guidance for how to proceed with this work < mclasen> we probably won't get parallel backends working for 3.0 < mclasen> but I'd like to get the abi/api changes in place < Company> hrm < kris> having things like atom, text conversion, selection, etc. generic like you mention sounds like a good plan < krh> mclasen: but it can happen for 3.x? < mclasen> one concern is that I haven't kept quartz/win32 in sync on the branch < Company> depending on the release date, we should at least get the basics done < mclasen> so there will be fallout for other backends if we merge now < Company> because currently we regress < Company> in that it's not possible to install multiple gtks < kris> mclasen: how many changes did you make? < krh> Company: good point < Company> kris: the vfuncization is quite a bit of (bring) work < 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 < Company> *boring < mclasen> kris: more like an evening, I guess < ebassi> krh: 135 files changed, 6686 insertions(+), 5493 deletions(-) < ebassi> (against master) < mclasen> dangit, +1000 < krh> ebassi: kr? < mclasen> but the code gets much cleaner, so its worth the extra lines < ebassi> yeah, sorry - 'twas for kris :-) < Company> mclasen: we can get the lines back if we remove some more useless apis! ;) < kris> mclasen: ok, then it depends really on how quick I get the final pixel nitpicking done for treeview-refactor < kris> mclasen: which I had schedule for one or two evenings starting tomorrow < mclasen> kris: I can probably get a bunch of the conversion done blindly < mclasen> I'll just have to rely on you to make things build and work afterwards... < kris> that's not a problem, I've done that for rendering-cleanup as well < mclasen> ok, I can sink some time into catching up the other backends then < mclasen> Company: can you help out with dealing with some of the sucky apis ? < Company> mclasen: when i know about them, yes < mclasen> Company: and do you think that installing multiple gdks in parallel is a very common thing ? * mclasen has never heard of it < mclasen> Company: do you know about them now that I've listed them ? < 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 < Company> mclasen: "know about them" == have a clue what the apis are ncecessary and used for < Company> mclasen: ie i still don't understand the selection code < Company> mclasen: also, how api-break happy are we for those apis? < Company> get-them-right vs get-them-to-continue-working < kris> the selection api is also on my list of apis to learn to understand ;) * mclasen thinks that dnd+selection is in for some high-level review for gtk4 < pbor> Company: I'd say let's see case by case: rarely used apis -> fix properly, common apis -> evaluate pro/cons < mclasen> yeah < Company> pbor: in general gdk api's are the first case ;) * mclasen already 'broke < mclasen> ' one api by moving set_sm_client_id to X11 specific < mclasen> I guess nobody will ever notice < krh> I guess the parallel installable gdk/gtk is less interesting since an application can only link to one of them < mclasen> yeah, its really only for installer-doesnt-use-X kind of situations < Company> true < mclasen> and in that case, you can just as well install the app-specific gtk somewhere else... < krh> and you can still do it by just renaming the libraries < Company> krh: i guess we don't regress then < krh> which is an appropriate ad-hoc hack for the installer case < mclasen> ok, how does this fit in our schedule ? < krh> mclasen: I guess there are two things here: gdk-backend and fixing the broken APIs < mclasen> yeah < krh> gdk-backend seems doable for 3.0 < mclasen> I'll switch the gdk-backend branch back to separate libgdk < krh> but the interesting thing to do for 3.0 is fixing the broken apis < mclasen> then we need the cursor work done < mclasen> I think that is doable this week < mclasen> fixing remaining sucky apis will probably take longer < mclasen> so would have to be deferred until the xmas snapshot < Company> yes, cursor is easy < pbor> if they do not affect 99% of apps, it is not a problem < Company> cursor is only gdk_cursor_ref/unref vs g_object_ref/unref < Company> and we can keep them deprecated if we want to < mclasen> Company: I think we probably want cursor_ref/unref in place for now, as deprecated #defines ? < Company> right < 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 < pbor> - review api issues in bugzilla that are on the 3.0 milestone < pbor> - what's the status with GtkApplication? < pbor> - what happen to GPeriodic and the corresponding gtk business? < pbor> - Alex's radio < pbor> - Are there still api issues open related to Style? GdkColor? < pbor> also while working on pygobject some issues showed up < pbor> - does scrollview_new still needs param? < pbor> - GtkBuildable seems super broken: it is an interface but none of its implementors implement all its methods < ebassi> for GPeriodic, I think we need to back it out < mclasen> pbor: thanks for the list < ebassi> I haven't had much time for porting clutter, and we still need some reviewing for that < pbor> ebassi: that was kind of my implied point :) < ebassi> GtkApplication is still pending on the action API that desrt was working on < mclasen> ebassi: since we haven't gotten the gtk integration done, its not big loss to back it out < ebassi> though generally I think we can punt that for the time being < mclasen> yeah, gtkapplication is useful as it is now < ebassi> since apps have been ported and they work already < mclasen> even if incomplete * Company votes YES on gperiodic backout < mclasen> now sure what is broken about GtkBuildable ? < mclasen> does it not work ? < tristan> pbor, is it language bindings your concerned about for buildable ? < mclasen> so we tell desrt to try again for gtk4 ? < pbor> mclasen: well, it works because the few callers assume that some of the function are safe to call just under some conditions < pbor> which kind of defeats the point of an interface < tristan> that's not exactly true < tristan> how so ? < mclasen> who do you expect to call buildable functions ? < ebassi> mclasen: for GPeriodic, yes < 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 < pbor> thought now the enforcing has been removed < mclasen> sounds like an unwarranted assumption on their part < pbor> sure, that's why the enforcing has been removed < tristan> right, I have noticed some places where the implementations fail to chain up to parent classes < tristan> but those are class-specific bugs < tristan> i.e. get_internal_child() has to chain up < pbor> tristan: it is not about chain up, look at container: it is buildable but it only implements some methods < tristan> sure < tristan> and that is a problem because... ? < pbor> and container's derivative do not implement them < mclasen> moving up the list, scrolled_window_new could certainly loose those arguments < mclasen> but I guess that would be a painful api break this late in the game < tristan> gtk_buildalbe_* *apis* are safe to call < tristan> pbor, and why would a containers derivative have to implement something that it trusts the container's implementation to take care of ? < pbor> anyway, let's drop the buildable thingie... it is not even an api issue < tristan> I'd love to drop the "constructor" stuff... if we could drop uimanagers... but we still cant do that :( < mclasen> I think we dropped the ball for scrolledwindow and have to live with NULL, NULL for a little longer < pbor> ok < ebassi> right, moving on: GtkRadioGroup? < mclasen> I think it is in the little gain, big pain category of api breaks < mclasen> so, I did some work on that; desrt wasn't really happy with it < mclasen> since he wanted to have buttons backed by actions as models < mclasen> and only group the models < mclasen> there is a branch where we tried to work out the necessary button changes for that idea < mclasen> but it is not complete < ebassi> I think that'll have to wait, now < mclasen> yeah, I guess so too < mitch> from my pov,e.g. in gimp there are at least 4 ways to construct button groups < mclasen> I may still land a small part of the button branch < mitch> and they all make sense < mitch> forcing them into a GtkRadioGroup would make things more complicated in some cases < mclasen> (the part about having a indicator-style property on GtkButton) < mclasen> so, what else is left on the 3.0 api issues list ? < pbor> mmm, to be honest I was happy enough with alex original proposal < pbor> anything is better than GList as is now < mitch> garnacho_: what about the remaining input issued? < garnacho_> mclasen: I've yet to land my xi2 patches < mclasen> yes, you do < mitch> heh < garnacho_> can do that tonight < mclasen> ok < Company> mclasen: i still have an open question about removing GtkStyle and GdkColor completely * mitch wants get_source_event < mclasen> I can't see us doing that at this point, really < mclasen> we are not even there yet in terms of having replacements for all color properties < Company> i don't see the usefulness at all in keeping them < Company> because everybody that is porting must do the expose => draw port < mitch> if you want that, i want gtkhbox and gtkvbox gone :P < Company> which touches all the style functions < Company> note that gtk_paint_foo() are breaking API < garnacho_> Company: I think most people has ported by now to that, because it's only changing one parameter :/ < Company> garnacho_: most people = only gnome * mclasen just doesn't believe we can do big api removals at this point < Company> garnacho_: and mitch < mclasen> the concern is not third party stuff, but just gnome three dot oh < Company> garnacho_: neither mozilla nor openoffice nor inkscape nor transmission did < Company> mclasen: do we have an idea how big the 3.0 impact is? < Company> mclasen: do we need to activate fredp magic again? :) < garnacho_> Company: right, but telling them it was just a bump in the rollercoaster... :) < mclasen> you mean the impact of removing gtkstyle and gdkcolor ? < Company> mclasen: yeah < pbor> maybe we should try coccinelle on gnome :) < mclasen> I don't, and I really don't think we can do it anymore < mclasen> people are going into xmas break now < mitch> so let's break a bit :P < mitch> ha ha < mclasen> we can't afford to loose half of january for playing catchup with last-minute gtk api breaks < Company> our very own xmas break \o/ < mitch> mclasen: at this point in time, i give in and agree < krh> yeah, xmas api break < mclasen> it will all be deprecated < tristan> where are we right now then, somewhere in the middle of "last minute breaks" ? < mclasen> and we can take our time to port gtk internally to the new stuff < garnacho_> mclasen: and I have a patch to reduce the code behind it to a minimum < mclasen> and we will survive ignoring gtkstyle until 4.0 ' < mclasen> just like we did with GtkList and GtkText and whatnot < mitch> mclasen: oh btw, do we have removal of all sealed members on the 3.0 blocker list? < mclasen> mitch: the gdk-backend branch does a good bunch of that for gdk < mclasen> since it hides all instance and class structs for good < mitch> yes but gtk is much worse < Company> yeah, if we actually port stuff to GdkRGBA and style context internally < Company> stuff should look reasonably contained < Company> at least if we don't also support GdkColor everywhere < mclasen> mitch: I haven't actively followed the sealing work, really < mclasen> mitch: not sure if jjardon is around < mitch> mclasen: but it is indeed a blocker < mclasen> yes, I agree < mclasen> we should do that < mclasen> any volunteers ? < mitch> grep GSEAL gtk/*.h | wc < mitch> 195 940 10520 < mitch> 195 members to go < mclasen> not too bad < mitch> indeed < mitch> i'm off for xmas vacation, so we must chain jjardon back to the keyboard < mclasen> I'll see what I can done by Monday < martyn> mclasen: so what's the ETA for for 3.0 then, are we delaying things? < martyn> mitch: :) < jjardon> not all the widgets are ported, sorry lack of time :/ < mclasen> ok, time to bring that topic up, I guess < mclasen> release date < mitch> jjardon: real jobs suck :) < Company> mclasen: i'd like to do a feature freeze < mitch> martyn: sorry :P < jjardon> mitch: indeed ;) < Company> mclasen: that way things can settle and we can fix messes that we still encounter < mclasen> Company: a little late for that... < Company> lik the extension event stuff from today < martyn> mitch: grmbl < mclasen> or do you mean, delay the official 3.0 ? * martyn gets mitch to clean the toilets < Company> mclasen: indeed, but we're still actively doing features < mitch> haha < mclasen> and instead realease something like 2.99 in early january ? < Company> mclasen: yeah, delay the official 3.0 < Company> yeah < mitch> i'm all for delaying < mclasen> whats the general feeling on that ? < krh> mclasen: if missed the conclusion on gdk-backed vs gtk 3.0 < krh> s/if/I < tristan> delay++, api freeze soonish < Company> we need to stop people from bringing up gdk-backend and tree menus and cell areas and more gdk cleanup and < mitch> 4 more weeks in the new year (after xmas break) woulb be really good for the shape of 3.0 < mclasen> krh: I think the conclusion was to try and get the api/abi changes landed < tristan> wait, what is the release date before delaying it ? < ebassi> delaying two or three weeks and do a feature freeze around xmas sounds good to me < krh> mclasen: excellent < ebassi> tristan: the endgame for 3.0 was end of this month < garnacho_> I guess delaying should be fine as long as we're (close to) api stable anyway < Company> tristan: "this year" was what we told release-team < mclasen> tristan: the original plan was 'end of year' < tristan> right < mclasen> so we will have to deliver something that is api stable and feature frozen, more or less < mclasen> at that date < 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 < tristan> I think delay official 3.0 is important < martyn> it's done when it's done < mclasen> I think calling it 2.99 and holding out for a few weeks is ok < mitch> yes we must not rush it out, or pain is guaranteed < tristan> yeah, still feature/api frozen by that time < martyn> we can alleviate this with the 2.99 as mclasen says < mitch> tristan: minus missing api that is discovered late, and we will have that :( < mclasen> practically, the difference between 2.99/3.0 vs 3.0/3.0.1 is probably small < Company> 2.99/3.0 allows api breaks < Company> if deemed necessary < 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 < Company> "oops, forgot this tiny thing" kind of failures :) < mitch> and nothing keeps us from making a real soon 3.2 if we find something is really b0rk < mclasen> I will take this to the release team, I guess < jjardon> about gseal work, we still dont have a clear history about gtkadjustment < mclasen> don't really want to surprise them with that < mclasen> we can probably also use the weeks we win to sort out some of the theming fallout < mclasen> garnacho_: how has style-context been received so far ? * mclasen saw jimmac pull out some hair earlier today... < mitch> i think it's great since i understand it :) < garnacho_> mclasen: yeah, he found out some real bugs < 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 < garnacho_> so far reception seems positive, only one crazy engine dev asking for widget pointers back :P < ebassi> garnacho_: are we allowed to mock this guy? :-) < tristan> ... being an api breaker (as things might work differently implicitly) < garnacho_> ebassi: I'll be polite and not embarrass him :) < mclasen> tristan: I don't recall the outcome of that discussion, tbh < garnacho_> but "i need to connect to signals" wasn't a compelling argument < tristan> mclasen, what do you think about that one... we make labels return a very small minimum width by default < tristan> and then we say that one should set a minimum width of the toplevel window < tristan> so as to avoid rediculously large heights < tristan> it's basically moving all the per-widget compensation to the top-level < tristan> hp said that the reasonable window width could be a complex guess one shot on the top-level < tristan> I dont know < tristan> but I remember owen felt very strongly about this < 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 < mclasen> so you want to make things so that windows by themselves snap to a very narrow, tall shape ? < mclasen> and expect people to force a reasonable size by putting a min width on the window ? < 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 < 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 < mclasen> as a general idea, avoiding label-level tinkering seems right < Company> hrm < mclasen> but as you say, scary change late in the game < Company> can't we default windows to screen-ratio? < Company> ie if the screen is 4:3, make the window as close to 4:3 as possible? < mclasen> it might be less scary if we could somehow make this opt-in by some policy property on the window < tristan> right, something like that, it requires a bisection of height-for-width requests initially if a manual width is not explicitly set < tristan> mclasen, make label's implied minimum width change depending on a top-level window setting ? < tristan> possibly < mclasen> no, that doesn't sound right :-( < mclasen> but I see we are beyond the 2 hour mark < mclasen> anything we need to nail down today, still ? < mclasen> website update ? < ebassi> xi2 stuff? < mclasen> martyn: whats your thought on that ? < mclasen> what xi2 stuff ? < mclasen> oh turning it on by default ? < martyn> mclasen: there isn't really anything to cover < garnacho_> mclasen: yes, I put it late in the list < martyn> I think the website design which we went through a few months back is really quite comprehensive < 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 ? < mclasen> garnacho_: I saw it; I think I said earlier that I am not opposed to changing the default < garnacho_> oh, didn't imply that :) < garnacho_> alright < garnacho_> will push that patch as well < garnacho_> err s/imply/infer/ < martyn> crap < martyn> damn machine rebooted < martyn> about the website ... < martyn> I was really just checking for a release date to co-inside with the official release < jjardon> I'd say wait for GTK+3 < martyn> since we're delaying the release until late ? January, we can revisit this in a later meeting I think < mclasen> lets make that a little more concrete < martyn> from my point of view, the work for the website is really just a switch over < mclasen> I'll say I do the 2.99 release in the first week of January < mclasen> should we plan for 3.0 one month after that ? < martyn> mclasen: first week in Feb? < mclasen> yes < martyn> sure makes sense to me < ebassi> mclasen: sounds like a plan < 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 ;) < mclasen> oh tracker < mclasen> good point < martyn> uh oh what did I say < mclasen> did you want to merge that rewritten search engine ? < martyn> mclasen: done < mclasen> or did you do it and I didn't notice :-) < mclasen> good work < martyn> mclasen: np < jjardon> for the record, GNOME api freeze is on Jan 31 < ebassi> we're special :-) < mclasen> ok, we'll beat that by declaring 2.99 api frozen except for emergencies < jjardon> :) < mclasen> anything else for today, or should we wrap up ? < 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) < pbor> gnome does not have much api to freeze anymore < mclasen> should there be another meeting before xmas ? < martyn> mclasen: did you want that done before 3.0 ? < mclasen> martyn: didn't expect it, no < martyn> ok < mclasen> that was more medium-term talk < martyn> let's leave it for now < ebassi> mclasen: 21 or 28? < mclasen> I'll be gone on 28, I think < mclasen> we can also just play it by ear and see if there's anything to discuss next week < ebassi> sounds good to me < mclasen> ok then < mclasen> time to stop * mclasen is hungry < ebassi> right < tristan> time to sleep < ebassi> thanks everyone < mclasen> later < pbor> 'night < martyn> thanks all < martyn> good night < ebassi> as usual, minutes on the list and log on the wiki as soon as I can