< ebassi> as usual: meeting agenda is available on the wiki at http://live.gnome.org/GTK%2B/Meetings < ebassi> • magic expand (bug: 628902) < ebassi> • fate of the tutorial and examples < ebassi> • Deprecate / remove gtk_init_add / remove* API (bug: 629955) < ebassi> • ::destroy - up or down ? (bug: 630690) < ebassi> • Deprecation of glib gettext macros (bug: 624186) < ebassi> • GtkComboBoxText subclass to supersede "text" convenience API (bug: 612396) ‣ GtkComboBoxEntryText needed? < ebassi> • Miscellaneous < federico> Company: ah, got it < federico> Company: let me build my copy with that patch < federico> Company: thanks :) < mitch> ebassi: i lost track, what happened to getting rid of GdkColor and adding an alpha-enables color type? < mitch> enabled* < ebassi> mitch: mmh, no idea < mitch> garnacho was on that iirc < Company> it was pending on the themeing api changes < Company> no clue what happened with that < mitch> yeah < mitch> let's bug the right people next week? < Company> => hackfest < Company> yeah * mclasen fiddles with 2 parallel meetings < mclasen> should we start ? < mclasen> so, magic expand < mclasen> I spent some time on the widget-expand-3 branch yesterday < mclasen> and added compute_expand implementations to all the containers where it made sense < mclasen> unless there's serious doubt about the general idea, I'd like to merge whats on that branch < mclasen> and work on the window resizability later < mclasen> I tried to do that too, but thats a little trickier < federico> can we add to the agenda something about multiroot-filechooser? < ebassi> federico: sure < federico> ebassi: thanks < ebassi> mclasen: I have no objections on that < mclasen> oh, another agenda addition from me: gtkwrapbox removal < Company> remove it < Company> nobody uses the wrapbox and it's gtk3 only < Company> less bloat! < mclasen> the big remover speaks :-) < ebassi> heh < Company> do more with less! < ebassi> dunno, having it in master without any user was a bit premature, probably * desrt wouldn't mind sneaking in a quick hide vs. show chat < mclasen> but yeah, it is probably best to keep it out if we don't have any user < ebassi> so I don't see any problem in getting it out < ebassi> we can still move it to libegg < Company> :) < Company> i agree with merging the expand stuff btw < mclasen> anybody against removing gtkwrapbox ? < ebassi> mclasen: actually, something I'd like to discuss at the hackfest, is copy the LayoutManager API we have in Clutter, with delegate layout managers outside of widgets < ebassi> at the hackfest or here < mclasen> just a pity for all the work tristan put into it, but on the flip side, he doesn't have to fix all the bugs it has... < tristan> awww, it has so many bugs ? (it did need to handle expand better, for rows/cols) < mclasen> ebassi: sounds like a good hackfest topic < ebassi> mclasen: okay < mclasen> tristan: just assuming a fixed bug/loc ratio... * ebassi scribbles it down < tristan> anyway, lets throw it out if nobody uses it is my take < federico> Company: the patch works perfectly, thanks! it was making me panic < ebassi> ACTION: remove WrapBox from master, eventually move it to libegg < ebassi> tristan: do you mind doing the removal or you need somebody else to do it? < Company> federico: we should probably have added it to 2.20 in retrospect < tristan> ebassi, no I dont mind at all, I was just leaving at least a week to see what people say. < tristan> I'll do that tomorrow then. < federico> Company: definitely * federico mails distributor-list * mclasen lost track. next topic is what ? < ebassi> simple one: fate of tutorial + examples < ebassi> tutorial: die, die, die < ebassi> examples: which ones? < ebassi> if they are the ones in the tutorial, then: die, die, die < ebassi> I'd actually move some of the content of the tutorial into the API reference < ebassi> e.g. packing theory should go in GtkContainer + GtkBox < mclasen> I was talking abou thte examples from the tutorial, yes < ebassi> signal connection should probably go in GtkWidget < Company> a new tutorial would be nice, but i suppose i'm the wrong one to complain about that < ebassi> Company: tutorials in general suck; I much prefer the cookbook style approach, nowadays < ebassi> far more useful < Company> but the old one makes people do stuff wrong < mclasen> and yes, I would also liketo see us move new examples into the api docs < ebassi> mclasen: I'll do the tutorial surgery if you want < mclasen> cool, thanks < mclasen> one nice thing to learn from the gio docs is that it is good to have examples actually built as part of make dist (and just xincluded in the docs) < ebassi> mclasen: yes < mclasen> guarantees they don't get outdated < Company> i liked that < Company> the examples were so outdated, i'd have had to spend lots of time to fix them ;) < jhs> about tutorial -> devdoctools hackfest *might* be a place to get into this < Company> jhs: that's in berlin, right? < tristan> tutorials are a pain to maintain, I still wish bitrotting Glade tutorials got merged to the virtually nonexistent user docs < Company> it is < jhs> Company: yes, 2-5th of december iirc < Company> jhs: i can definitely take a train to get there for 1 or 2 days < jhs> Company: http://live.gnome.org/Hackfests/DevDocTools < ebassi> have you seen the Clutter cookbook? it comes with videos and xincluded examples: http://docs.clutter-project.org/docs/clutter-cookbook/1.0/ < jhs> Company: would be good! Anyway, that doesn't mean we write tutorial, I guess cookbook style is the general preference < ebassi> (and it's also a devhelp book, so it can be viewed offline) < Company> jhs: yeah < Company> next topic? < jhs> so, everybody, would be nice if there was some agreement on how the docs should look like from gtk-devs, maybe you can sort that out on your hackfest. Doesn't make sense if we write docs that wouldn't be accepted upstream < ebassi> jhs: I think we're kind of settled on docbook < jhs> ebassi: so basically you would like to include most of your docs in docbook/code? * mclasen doesn't see revisiting that anytime soon < ebassi> jhs: yup * jhs is noting that for now < ebassi> jhs: for clutter, we include the docbook for the cookbook in the main repository, and build the examples included with it to avoid bitrotting < ebassi> jhs: this is also true for examples embedded into the API reference < ebassi> jhs: another thing that the devdoc hackfest should consider is updating gtk-doc's css :-) < ebassi> jhs: maybe add javascript for expanding/collapsing sections < jhs> ebassi: I think that is a good idea in general. About gtk-doc css, I guess fredp has an idea there. * tristan remembers seeing some examples of expanding/collapsing sections half a year ago... someone already did alot of work on that < tristan> cant remember who it was :-/ < ebassi> anyway, I guess we should go to the next topic < ebassi> since we have federico today, let's skip to the multi-root filechooser < ebassi> bug number: 609886 < ebassi> https://bugzilla.gnome.org/show_bug.cgi?id=609886 < mclasen> it didn't strike me as super-compelling, use-case-wise < mclasen> but it has only a small api cost < mclasen> so, I am not opposed to it, if the kinks are worked out * Company was never a fan of hiding stuff (like other files) < Company> but i always attributed that to me being a software developer < ebassi> it's a question that pops up incredibly frequently < mclasen> really ? < Company> the file chooser used to root ~ back in the days < Company> and it annoyed me a lot < Company> so much that i fixed it ;) < ebassi> and usually the answer to "you can't" is an incredible amount of hacks < mclasen> federico: did you get the completion issues fixed that I saw ? < ebassi> mclasen: yeah. irc, mostly; people that set up restricted environments < ebassi> (kiosks, corporate terminals) < mclasen> but for them, the multiroot thing might not be 'secure' enough ? < tristan> s < federico> mclasen: not yet < federico> this is not real security, BTW, it's just to keep unwanted files out most of the time < federico> while I'm looking at lockdown in the end, people right now could use it for a "pick file within the USB stick" button, for instance * mclasen has to go in ~6 minutes, will be gone for ~30 < Company> federico: but it will not cause apps that i care about on my home computer in some weird apps to not show me half my system? < federico> Company: well, no one uses the API yet (except vmware) < federico> Company: by default everything is visible < mclasen> need for more discussion on this ? anybody strongly object ? * Company not a ui person < ebassi> I'm pretty sure some designer will like the idea to restrict the root when loading files from a removable volume :-) < Company> of course * mclasen has to go, sorry, back in a bit < Company> unless they need to open a file that's not in their dropbox < Company> ;) < ebassi> true < Company> so the idea is "work out kinks, then merge it" and we can go to the next topic? < ebassi> but in that case the UI should not use a separate root :-) < Company> yeah < Company> that's my only worry - that programmers misuse it < tristan> it does sound interesting for kiosk like environment, specific hardware setups etc < ebassi> but we all do what UI designers tell us! :-D < Company> ebassi: exactly! < ebassi> anyway, I agree with Company: smooth the edges and then merge < tristan> except I think normally if you have a file-chooser in a kiosk, you have a blown up customized file chooser anyway < ebassi> tristan: which requires butchering gtk < tristan> right < ebassi> (see re: hacks above) < ebassi> personally, I'd rather developers used a sanctioned API; because then it means they don't come complaining when gtk blows up in their faces after tampering with it < ebassi> or come up with random patches in bugzilla that look like an explosion in an ASCII factory < ebassi> and have zero chances of being merged < ebassi> right, next topic while mclasen is away :-) < tristan> cant filechoosers be implemented with a custom UI anyway ? < federico> bbiab, lunchtime < tristan> hmm < ebassi> deprecate/remove gtk_init_add()/remove() < ebassi> tristan: no. they were designed as such, but it never worked < Company> ebassi: yes, please < ebassi> tristan: you have to patch gtk *a lot* -- see what maemo did in back the days < ebassi> s/in back/back in/ < Company> ebassi: the api for those functions looks pre-1.0, so nobody uses it < tristan> ebassi, right, I suppose its just an "interface" but shares about 0 code < ebassi> Company: yup; I also cannot see any valid use case < ebassi> tristan: yeah; all the logic is in gtkfilechooserdefault.c < Company> fix it! we must make file choosers look different on every installation < ebassi> tristan: so you have to reimplement a lot of code < Company> ubuntu file chooser™ < ebassi> Company: haha < tristan> eh, so in another light, multi-root becomes something every implementor *must* implement < ebassi> tristan: there are no implementors left, AFAIK < Company> tristan: i'll do a custom file chooser that doesn't implement it, and then i'll make that a advanced users desktop < Company> tristan: and name it GDE < tristan> ok not an issue, anyway I'm not arguing against it, I'm all for the swiss-army-knife approach < tristan> let programmers do everything < ebassi> right, so gtk_init_(add|remove) should go away < ebassi> also, I see no valid use cases for them - especially if we're moving towards a GtkApplication world < tristan> gtk_init_add/remove() ? < tristan> jaysus that exists < Company> that code emulates X events or something, for goodness' sake < tristan> I always used g_idle_add() for an initial startup hack < Company> stuff that was current when everyone used gtk_signal_connect() < ebassi> Company: I doubt it was ever "current" :-) < Company> so, remove, next topic :) < ebassi> deprecation of glib-gettext and move towards upstream < ebassi> that's jjardon, but he's not here < ebassi> gdk-pixbuf (and clutter) migrated < ebassi> not much to see, here < chpe_> the one thing that's problematic in the switchover from glib-gettext's Makefile.in.in to upstream's is that glib's has some glib functions as --keyword and --flag arguments. using upstream's Makefile.in.in, these need to put into po/Makevars for each project separately.... need to find a shareable solution here < ebassi> chpe_: m4 macro that creates the po/Makevars? < ebassi> glib could ship it < chpe_> yeah, something like that < ebassi> chpe_: should probably be mentioned on the bug: https://bugzilla.gnome.org/show_bug.cgi?id=624186 < chpe_> yes < tristan> this is only deprecation of glib-gettext and potential migration of GTK+ sources right ? < tristan> i.e. glib doesnt remove it and apps dont need to change that anyway < ebassi> tristan: and all projects using glib-gettext < Company> tristan: glib is api stable < tristan> so glib still offers the glib-i18n.h stuff < tristan> right, not a serious issue for external developers < ebassi> tristan: sure; it's just a build issue, not an API one < jhs> hmm, jjardon migrated all my modules - doesn't seem to do any harm < tristan> it shall cause no pain, except to jjardon ;-) < chpe_> jhs: with the right keywords/flags msgfmt can do more checks for translator's bugs < jhs> chpe_: I see. This means we need to update the docs or move some stuff to gnome-common (it this is still alive in 3.0) < chpe_> jhs: putting something into glib makes more sense; I want to kill gnome-common as much as possible < jhs> chpe_: so something different to glib? Good to see gnome-common die :) < Company> next topic? < Company> what was the conclusion here? < Company> needs-work-but-right-approach ? < chpe_> yes * mclasen comes back < mclasen> did I miss something ? all bugs now assigned to me ? < ebassi> okay, next topic - ::destroy signal: up or down? < chpe_> down ! < mclasen> ok, this is basically just double-checking that we've done the right thing here < ebassi> it depends - which way is up? < tristan> chpe_, which way is down ;-) < mclasen> and there are no huge unforeseen problems < tristan> lol < mclasen> down is to gtkwidget < mclasen> up is to gobject < chpe_> oh < chpe_> I thought 'up' == keep, 'down' == kill kill kill < tristan> your library stack is upsidedown < tristan> heh < tristan> ah < Company> basically there are 2 problems: < Company> 1) my code is built around crazy semantics and i'd like to keep that code < Company> 2) i don't understand refcounting but everyone is scared to tell me so i don't know < Company> *refcounting in glib < mclasen> I guess the more radical 'down' would be down to gtkwindow < Company> i vote gtkwindow < Company> the signal encourages the wrong behavior we want to get rid of < Company> and since people need to adapt code anyway... < kalikiana> destroy is so damn useful I'm surprised you want to get rid of it < Company> kalikiana: where is it better than weak refs? < kalikiana> I can destroy widgets and I can connect to the signal < mclasen> well, what we really wanted to get rid of is GtkObject < Company> kalikiana: a destroyed widget is useless though < jhs> hmm, did anyone connect to "destroy" except for GtkWindows? < tristan> I still feel like my vote is push to GObject, the "destroy" semantic is much nicer (and safer) than weak refs < tristan> if we want to be that dramatic, hell get rid of GInitiallyUnowned < Company> i'd love to get rid of GInitiallyUnowned, but that'd cause leaks in _every_ app < walters> glib isn't up for change < walters> at least, not incompatible change < tristan> Company, or make ref counting understandable < tristan> walters, I know it cant be done :( < Company> tristan: it's a one-liner < Company> tristan: in G_DEFINE_TYPE (GTK_WIDGET, ..) < kalikiana> Company, how would you get rid of a widget without destroying it? < ebassi> kalikiana: g_object_run_dispose() < Company> kalikiana: unref it? < ebassi> which is what destroy does anyway < mclasen> if it is a window, you destroy it, otherwise just unparent it < Company> kalikiana: it's like any other object? < kalikiana> ebassi, which is explicitly documented as a function for type systems or some such < tristan> g_object_run_dispose() safer when being the true owner of the object < ebassi> I think there's a general issue here - we're talking about ::destroy-the-signal, not destroy-the-method < kalikiana> Company, unref != destroy < Company> kalikiana: either your objects are refcounted or they are not < Company> kalikiana: strings aren't refcounted, you can destroy them < Company> kalikiana: widgets are refcounted, you can't destroy them < kalikiana> Company, those are perfectly orthogonal concepts < tristan> kalikiana, if you are the owner of an object that risks having circular ref cycles, you must run_dispose() < Company> kalikiana: if you do, code will start breaking < tristan> removing "destroy" only means that watcher objects cant have a reference anymore. < tristan> they must weak_ref()... it feels so racy < Company> kalikiana: so if i run gtk_object_destroy() on the GtkAlignment of a tree view, nothing will break? < jhs> back to ::destroy! Is it of any pratical use now that we have GApplication? I feel it was only used to end the mainloop... < ebassi> jhs: on top-levels, yes < Company> ebassi: that's because for toplevels, it's the only way to make sure gtk releases its internal ref to the window < Company> ebassi: not because toplevels are somehow special otherwise < ebassi> jhs: if we use "the last window closes the app" semantics, then there's no need for a destroy signal any more < ebassi> Company: right, that's what I'm saying :-) < jhs> ebassi: good, any other (valid) use-case? < kalikiana> Company, not sure which alignment. if the treeview exposes and requires it, it should watch if it's destroyed < tristan> gtk+ could use a weak_ref to its toplevel list alternatively then < ebassi> tristan: or have an object like thre ClutterStageManager which holds the list gives you a signal when a top-level is added/removed < tristan> if gtk+ likes to have a reference to toplevels, why should any other watcher not be interested in having a reference to any other object ? < Company> kalikiana: we do that _nowhere_ - but yes, for destroy to work, we must watch every object we create < Company> kalikiana: that's a _lot_ of work :) < tristan> s/should/shouldn't < Company> kalikiana: also, it'd spectacularly break all the bindings that assume objects stay valid while they have a ref < tristan> err double negatives there... anyway, if gtk+ likes having a reference to the GtkWindow, hypothetically owed by user code... why should that not be the case anywhere else an object is involved ? < kalikiana> Company, I'd consider a binding oblivious to "destroy" broken < mclasen> tristan: gtk has had those references since before weak refs existed in gobject... < jhs> just a note: moving it to GtkWindow would probably break much fewer apps than removing it completely, if that counts < Company> kalikiana: so all bindings need to take special care to evaluate destroyed objects to the null object? < tristan> mclasen, in which case the argument could be to remove ::destroy completely, not push it up to GtkWindow < mclasen> down < mclasen> :-) < tristan> heh < Company> tristan: yes, i've always said that gtk_window_destroy() should just g_object_unref () the window :) < tristan> Company, g_object_run_dispose() could be < tristan> you have to assume that some widget has an accelerator that is in an accel group that is attached to the window < walters> Company: run dispose, then unref maybe < tristan> or any such madness < Company> walters: we'd need this with the current refcounting mess, yeah < tristan> its not a mess < ebassi> it really is < tristan> circular refcounts are perfectly valid situations < ebassi> we have refcounting and then a huge hammer to break everything < tristan> not only in language bindings < Company> tristan: run_dispose() should never be called from C code < Company> tristan: unless that C code implements a GC < Company> for fun: < tristan> Company, we had this argument before, we dont need to waste meeting minutes for this. < Company> import gtk < Company> window = gtk.Window() < Company> window.show_all() < Company> window.destroy() < Company> window.show_all() < Company> what now? < mclasen> so, summary: it seems there's no urgent need to do further changes to destroy ? < tristan> Lets say I have an object that represents a type, then the type can be an object type, lets say the object owns an object that is a method... and the method refs a list of objects that are also types, and one of the types is itself < ebassi> alternatively: we need a wider bandwidth channel for discussions < tristan> there we have a GObject database in C, with circular ref cycle, perfectly valid < ebassi> and weaponry < tristan> yet needs run_dispose() to destroy properly < ebassi> I propose we punt this discussion until the hackfest < ebassi> were we can have popcorns and stuff < ebassi> where, even < mclasen> anything seft on the agenda ? < ebassi> GtkComboBoxText < ebassi> last item < ebassi> I think GtkComboBoxEntryText is pushing it a bit too far < jhs> I like that idea because I never found out how to create a GtkComboBoxText in Glade < Company> tristan: let's say i also have a ref to the type that i want to stay valid < tristan> that sounds totally weird, I dont want to be a sore thumb but whats the point of a combo-box text ? < Company> tristan: what now? < tristan> Company, in your opinion it must be a weak_ref, remember ? < jhs> tristan: It's the 99% use-case of a combobox < ebassi> tristan: it moves the awkward gtk_combo_box_text_* API to a proper sub-class < tristan> thats the difference between ownership and watching an object with "destroy" < Company> tristan: only if that'd introduce a cycle, right < tristan> Company, later, please. < Company> tristan: :) < tristan> so the combo_box_text is just a wrapper around the real combo-box, it does real simple stuff, it needs a class ? < ebassi> tristan: the namespacing is awkward, and it basically prevents you from using the whole API < tristan> and jhs, a comboboxtext in Glade doesnt exist because it just doesnt exist < ebassi> tristan: GtkComboBox is already overly complicated as it is < mclasen> ebassi: the current text convenience api is also exclusive, basically < tristan> jhs, makeing Glade better is besides the point < ebassi> tristan: the _text_* API is basically already doing the work of a sub-class < ebassi> mclasen: yup < mclasen> the awkward thing about subclassing-for-simple-case is that it breaks the real subclassing < mclasen> ie you can no longer use the text convenience api with comboboxenytry < jhs> tristan: yeah, but I would often need it and instead of creating a GtkComboBoxText I create a GtkComboBox and reimplement the gtk_combo_box_text_* API. glade is just a side-effect here < mclasen> and need a separate convenience subclass for that < ebassi> mclasen: can the entry be made a property, instead of requiring a sub-class? < kalikiana> it is, but the API would be missing < mclasen> that might be possible, but would be a more extensive refactoring < mclasen> sounds nicer, conceptuall < mclasen> y < ebassi> everyone is scared of GtkComboBox - kris wrote it and we almost lost him :-) < jhs> mclasen: well, now that jjardon is around more refactoring sounds possible :) < tristan> nod, ok subclassing-for-simpler-case sounds decent to me < tristan> does anyone use list-mode ? < ebassi> but ideally, yes: whether a combo box should have an entry should not be matter of sub-classing < ebassi> tristan: the windows theme, afair < tristan> a theme uses it ? < tristan> iish < ebassi> unless I'm still stuck in 2001 < tristan> combo would be much simplified without list vs menu mode for sure < mclasen> the list mode at least does no violence to GtkMenu... < tristan> and the entry not such a big deal to pull back down into combobox I think < tristan> I still have to see what a list-mode combo-box actually looks like < mclasen> it looks great < tristan> :) < tristan> ok sorry then < tristan> remove menu mode < tristan> eh, could those be split into separate classes ? < ebassi> GtkListCombo :-) < mclasen> thats what they started out as, optionmenu vs combobox < ebassi> GtkListMenu < ebassi> yep < ebassi> and everyone used OptionMenu < mclasen> there's a subtext here of optionmenu being the unixy api, and combobox being windowsy... < Company> just make all combo box entries an entry completion with a dropdown button! < jjardon> hello all, about this topic: gtkmm has a subclass for both GtkComboBox and GtkComoboBoxEntry < ebassi> OptionMenu had the added bonus of making the eyes of everyone with some taste bleed < Company> ebassi: but it made you scroll, which is awesome! < ebassi> Company: true, except when it's not. < ebassi> which is basically always :-) < jjardon> docs: http://library.gnome.org/devel/gtkmm/stable/classGtk_1_1ComboBoxEntryText.html and http://library.gnome.org/devel/gtkmm/stable/classGtk_1_1ComboBoxText.html < ebassi> jjardon: c++ has the advantage of not having long function names - I don't look forward to use gtk_combo_box_entry_text_set_frobnicator (GTK_COMBO_BOX_ENTRY_TEXT (combo), TRUE); < tristan> I like the idea of collapsing GtkComboBoxEntry as a property of combo-box < tristan> I wonder how much code that is < jjardon> ebassi: Don't look to GtkColorSelectionDialog api then ;) < ebassi> jjardon: I don't :-) < jhs> the good thing about GtkComboBox can handle GtkTreeModels, the bad thing is that everything that isn't a list looks ugly... < ebassi> I actually have to be reminding continuously that we have that dialog... < ebassi> jhs: tristan actually is solving that problem :-) < tristan> maybe we should start with doing the everybody wants a GtkComboBoxText, and consider the entry thing < mclasen> tristan: I think thats a good plan < tristan> it looks like mostly just adding the api set/get_text_column() < mclasen> so we accept comboboxtext, we reject comboboxentrytext, and we ask for a merger of combobox and comboboxentry < tristan> I think so, I might be able to fit that merge quickly and discreetly into my schedule < ebassi> cool < jhs> ebassi: you mean removing the menu code? Sorry, I am a bit out of context now and don't remember what we want to do and where we are just joking about our APIs... < tristan> I'll try, the tough part is the combo allocation portion that has so many branches (thats what scares everyone I guess) < ebassi> jhs: no, the "make multiple renderers/trees look better" < jjardon> and waht about the _text api in comboboxentry? < jhs> ebassi: ah cool - that will even make glade look better where I last tried. Rock on, tristan < tristan> jjardon, comboboxentry dies < mclasen> jjardon: the idea is to instead get rid of comboboxentry as a subclass, and fold it into combobox < jjardon> ah, ok < ebassi> right, that was the last topic < ebassi> next meeting: hackfest < ebassi> are there notes for that? < mclasen> cool, see you guys next weeks < ebassi> desrt: ? < mclasen> don't miss your planes < ebassi> hehe < mclasen> all we have so far is on the wiki < mclasen> would be good to brush that up a bit during the week... < Company> igalia tends to fetch one from the airport, right? < mclasen> if there's ideas, plans, topics, etc < ebassi> thanks everyone for attending; log on the wiki, minutes on the list as soon as I can