1 < ebassi> as usual: meeting agenda is available on the wiki at http://live.gnome.org/GTK%2B/Meetings
   2 < ebassi> • magic expand (bug: 628902)
   3 < ebassi> • fate of the tutorial and examples
   4 < ebassi> • Deprecate / remove gtk_init_add / remove* API (bug: 629955)
   5 < ebassi> • ::destroy - up or down ? (bug: 630690)
   6 < ebassi> • Deprecation of glib gettext macros (bug: 624186)
   7 < ebassi> • GtkComboBoxText subclass to supersede "text" convenience API (bug: 612396) ‣ GtkComboBoxEntryText needed? 
   8 < ebassi> • Miscellaneous
   9 < federico> Company: ah, got it 
  10 < federico> Company: let me build my copy with that patch
  11 < federico> Company: thanks :)
  12 < mitch> ebassi: i lost track, what happened to getting rid of GdkColor and adding an alpha-enables color type?
  13 < mitch> enabled*
  14 < ebassi> mitch: mmh, no idea
  15 < mitch> garnacho was on that iirc
  16 < Company> it was pending on the themeing api changes
  17 < Company> no clue what happened with that
  18 < mitch> yeah
  19 < mitch> let's bug the right people next week?
  20 < Company> => hackfest
  21 < Company> yeah
  22  * mclasen fiddles with 2 parallel meetings
  23 < mclasen> should we start ?
  24 < mclasen> so, magic expand
  25 < mclasen> I spent some time on the widget-expand-3 branch yesterday
  26 < mclasen> and added compute_expand implementations to all the containers where it made sense
  27 < mclasen> unless there's serious doubt about the general idea, I'd like to merge whats on that branch
  28 < mclasen> and work on the window resizability later
  29 < mclasen> I tried to do that too, but thats a little trickier
  30 < federico> can we add to the agenda something about multiroot-filechooser?
  31 < ebassi> federico: sure
  32 < federico> ebassi: thanks
  33 < ebassi> mclasen: I have no objections on that
  34 < mclasen> oh, another agenda addition from me: gtkwrapbox removal 
  35 < Company> remove it
  36 < Company> nobody uses the wrapbox and it's gtk3 only
  37 < Company> less bloat!
  38 < mclasen> the big remover speaks :-)
  39 < ebassi> heh
  40 < Company> do more with less!
  41 < ebassi> dunno, having it in master without any user was a bit premature, probably
  42  * desrt wouldn't mind sneaking in a quick hide vs. show chat
  43 < mclasen> but yeah, it is probably best to keep it out if we don't have any user
  44 < ebassi> so I don't see any problem in getting it out
  45 < ebassi> we can still move it to libegg
  46 < Company> :)
  47 < Company> i agree with merging the expand stuff btw
  48 < mclasen> anybody against removing gtkwrapbox ?
  49 < 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
  50 < ebassi> at the hackfest or here
  51 < 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...
  52 < tristan> awww, it has so many bugs ? (it did need to handle expand better, for rows/cols)
  53 < mclasen> ebassi: sounds like a good hackfest topic
  54 < ebassi> mclasen: okay
  55 < mclasen> tristan: just assuming a fixed bug/loc ratio...
  56  * ebassi scribbles it down
  57 < tristan> anyway, lets throw it out if nobody uses it is my take
  58 < federico> Company: the patch works perfectly, thanks!  it was making me panic
  59 < ebassi> ACTION: remove WrapBox from master, eventually move it to libegg
  60 < ebassi> tristan: do you mind doing the removal or you need somebody else to do it?
  61 < Company> federico: we should probably have added it to 2.20 in retrospect
  62 < tristan> ebassi, no I dont mind at all, I was just leaving at least a week to see what people say.
  63 < tristan> I'll do that tomorrow then.
  64 < federico> Company: definitely
  65  * federico mails distributor-list
  66  * mclasen lost track. next topic is what ?
  67 < ebassi> simple one: fate of tutorial + examples
  68 < ebassi> tutorial: die, die, die
  69 < ebassi> examples: which ones?
  70 < ebassi> if they are the ones in the tutorial, then: die, die, die
  71 < ebassi> I'd actually move some of the content of the tutorial into the API reference
  72 < ebassi> e.g. packing theory should go in GtkContainer + GtkBox
  73 < mclasen> I was talking abou thte examples from the tutorial, yes
  74 < ebassi> signal connection should probably go in GtkWidget
  75 < Company> a new tutorial would be nice, but i suppose i'm the wrong one to complain about that
  76 < ebassi> Company: tutorials in general suck; I much prefer the cookbook style approach, nowadays
  77 < ebassi> far more useful
  78 < Company> but the old one makes people do stuff wrong
  79 < mclasen> and yes, I would also liketo see us move new examples into the api docs
  80 < ebassi> mclasen: I'll do the tutorial surgery if you want
  81 < mclasen> cool, thanks
  82 < 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)
  83 < ebassi> mclasen: yes
  84 < mclasen> guarantees they don't get outdated
  85 < Company> i liked that
  86 < Company> the examples were so outdated, i'd have had to spend lots of time to fix them ;)
  87 < jhs> about tutorial -> devdoctools hackfest *might* be a place to get into this
  88 < Company> jhs: that's in berlin, right?
  89 < tristan> tutorials are a pain to maintain, I still wish bitrotting Glade tutorials got merged to the virtually nonexistent user docs
  90 < Company> it is
  91 < jhs> Company: yes, 2-5th of december iirc
  92 < Company> jhs: i can definitely take a train to get there for 1 or 2 days
  93 < jhs> Company: http://live.gnome.org/Hackfests/DevDocTools
  94 < ebassi> have you seen the Clutter cookbook? it comes with videos and xincluded examples: http://docs.clutter-project.org/docs/clutter-cookbook/1.0/
  95 < jhs> Company: would be good! Anyway, that doesn't mean we write tutorial, I guess cookbook style is the general preference
  96 < ebassi> (and it's also a devhelp book, so it can be viewed offline)
  97 < Company> jhs: yeah
  98 < Company> next topic?
  99 < 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
 100 < ebassi> jhs: I think we're kind of settled on docbook
 101 < jhs> ebassi: so basically you would like to include most of your docs in docbook/code?
 102  * mclasen doesn't see revisiting that anytime soon
 103 < ebassi> jhs: yup
 104  * jhs is noting that for now
 105 < 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
 106 < ebassi> jhs: this is also true for examples embedded into the API reference
 107 < ebassi> jhs: another thing that the devdoc hackfest should consider is updating gtk-doc's css :-)
 108 < ebassi> jhs: maybe add javascript for expanding/collapsing sections
 109 < jhs> ebassi: I think that is a good idea in general. About gtk-doc css, I guess fredp has an idea there.
 110  * tristan remembers seeing some examples of expanding/collapsing sections half a year ago... someone already did alot of work on that
 111 < tristan> cant remember who it was :-/
 112 < ebassi> anyway, I guess we should go to the next topic
 113 < ebassi> since we have federico today, let's skip to the multi-root filechooser
 114 < ebassi> bug number: 609886
 115 < ebassi> https://bugzilla.gnome.org/show_bug.cgi?id=609886
 116 < mclasen> it didn't strike me as super-compelling, use-case-wise
 117 < mclasen> but it has only a small api cost
 118 < mclasen> so, I am not opposed to it, if the kinks are worked out
 119  * Company was never a fan of hiding stuff (like other files)
 120 < Company> but i always attributed that to me being a software developer
 121 < ebassi> it's a question that pops up incredibly frequently
 122 < mclasen> really ?
 123 < Company> the file chooser used to root ~ back in the days
 124 < Company> and it annoyed me a lot
 125 < Company> so much that i fixed it ;)
 126 < ebassi> and usually the answer to "you can't" is an incredible amount of hacks
 127 < mclasen> federico: did you get the completion issues fixed that I saw ?
 128 < ebassi> mclasen: yeah. irc, mostly; people that set up restricted environments
 129 < ebassi> (kiosks, corporate terminals)
 130 < mclasen> but for them, the multiroot thing might not be 'secure' enough ?
 131 < tristan> s
 132 < federico> mclasen: not yet
 133 < federico> this is not real security, BTW, it's just to keep unwanted files out most of the time
 134 < 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
 135  * mclasen has to go in ~6 minutes, will be gone for ~30
 136 < 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?
 137 < federico> Company: well, no one uses the API yet  (except vmware)
 138 < federico> Company: by default everything is visible
 139 < mclasen> need for more discussion on this ? anybody strongly object ?
 140  * Company not a ui person
 141 < ebassi> I'm pretty sure some designer will like the idea to restrict the root when loading files from a removable volume :-)
 142 < Company> of course
 143  * mclasen has to go, sorry, back in a bit
 144 < Company> unless they need to open a file that's not in their dropbox
 145 < Company> ;)
 146 < ebassi> true
 147 < Company> so the idea is "work out kinks, then merge it" and we can go to the next topic?
 148 < ebassi> but in that case the UI should not use a separate root :-)
 149 < Company> yeah
 150 < Company> that's my only worry - that programmers misuse it
 151 < tristan> it does sound interesting for kiosk like environment, specific hardware setups etc
 152 < ebassi> but we all do what UI designers tell us! :-D
 153 < Company> ebassi: exactly!
 154 < ebassi> anyway, I agree with Company: smooth the edges and then merge
 155 < tristan> except I think normally if you have a file-chooser in a kiosk, you have a blown up customized file chooser anyway
 156 < ebassi> tristan: which requires butchering gtk
 157 < tristan> right
 158 < ebassi> (see re: hacks above)
 159 < 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
 160 < ebassi> or come up with random patches in bugzilla that look like an explosion in an ASCII factory
 161 < ebassi> and have zero chances of being merged
 162 < ebassi> right, next topic while mclasen is away :-)
 163 < tristan> cant filechoosers be implemented with a custom UI anyway ?
 164 < federico> bbiab, lunchtime
 165 < tristan> hmm
 166 < ebassi> deprecate/remove gtk_init_add()/remove()
 167 < ebassi> tristan: no. they were designed as such, but it never worked
 168 < Company> ebassi: yes, please
 169 < ebassi> tristan: you have to patch gtk *a lot* -- see what maemo did in back the days
 170 < ebassi> s/in back/back in/
 171 < Company> ebassi: the api for those functions looks pre-1.0, so nobody uses it
 172 < tristan> ebassi, right, I suppose its just an "interface" but shares about 0 code
 173 < ebassi> Company: yup; I also cannot see any valid use case
 174 < ebassi> tristan: yeah; all the logic is in gtkfilechooserdefault.c
 175 < Company> fix it! we must make file choosers look different on every installation
 176 < ebassi> tristan: so you have to reimplement a lot of code
 177 < Company> ubuntu file chooser™
 178 < ebassi> Company: haha
 179 < tristan> eh, so in another light, multi-root becomes something every implementor *must* implement
 180 < ebassi> tristan: there are no implementors left, AFAIK
 181 < Company> tristan: i'll do a custom file chooser that doesn't implement it, and then i'll make that a advanced users desktop
 182 < Company> tristan: and name it GDE
 183 < tristan> ok not an issue, anyway I'm not arguing against it, I'm all for the swiss-army-knife approach
 184 < tristan> let programmers do everything
 185 < ebassi> right, so gtk_init_(add|remove) should go away
 186 < ebassi> also, I see no valid use cases for them - especially if we're moving towards a GtkApplication world
 187 < tristan> gtk_init_add/remove() ?
 188 < tristan> jaysus that exists
 189 < Company> that code emulates X events or something, for goodness' sake
 190 < tristan> I always used g_idle_add() for an initial startup hack
 191 < Company> stuff that was current when everyone used gtk_signal_connect()
 192 < ebassi> Company: I doubt it was ever "current" :-)
 193 < Company> so, remove, next topic :)
 194 < ebassi> deprecation of glib-gettext and move towards upstream
 195 < ebassi> that's jjardon, but he's not here
 196 < ebassi> gdk-pixbuf (and clutter) migrated
 197 < ebassi> not much to see, here
 198 < 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
 199 < ebassi> chpe_: m4 macro that creates the po/Makevars?
 200 < ebassi> glib could ship it
 201 < chpe_> yeah, something like that
 202 < ebassi> chpe_: should probably be mentioned on the bug: https://bugzilla.gnome.org/show_bug.cgi?id=624186
 203 < chpe_> yes
 204 < tristan> this is only deprecation of glib-gettext and potential migration of GTK+ sources right ?
 205 < tristan> i.e. glib doesnt remove it and apps dont need to change that anyway
 206 < ebassi> tristan: and all projects using glib-gettext
 207 < Company> tristan: glib is api stable
 208 < tristan> so glib still offers the glib-i18n.h stuff
 209 < tristan> right, not a serious issue for external developers
 210 < ebassi> tristan: sure; it's just a build issue, not an API one
 211 < jhs> hmm, jjardon migrated all my modules - doesn't seem to do any harm
 212 < tristan> it shall cause no pain, except to jjardon ;-)
 213 < chpe_> jhs: with the right keywords/flags msgfmt can do more checks for translator's bugs
 214 < 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)
 215 < chpe_> jhs: putting something into glib makes more sense; I want to kill gnome-common as much as possible
 216 < jhs> chpe_: so something different to glib? Good to see gnome-common die :)
 217 < Company> next topic?
 218 < Company> what was the conclusion here?
 219 < Company> needs-work-but-right-approach ?
 220 < chpe_> yes
 221  * mclasen comes back
 222 < mclasen> did I miss something ? all bugs now assigned to me ?
 223 < ebassi> okay, next topic - ::destroy signal: up or down?
 224 < chpe_> down !
 225 < mclasen> ok, this is basically just double-checking that we've done the right thing here
 226 < ebassi> it depends - which way is up?
 227 < tristan> chpe_, which way is down ;-)
 228 < mclasen> and there are no huge unforeseen problems 
 229 < tristan> lol
 230 < mclasen> down is to gtkwidget
 231 < mclasen> up is to gobject
 232 < chpe_> oh
 233 < chpe_> I thought 'up' == keep, 'down' == kill kill kill
 234 < tristan> your library stack is upsidedown
 235 < tristan> heh
 236 < tristan> ah
 237 < Company> basically there are 2 problems:
 238 < Company> 1) my code is built around crazy semantics and i'd like to keep that code
 239 < Company> 2) i don't understand refcounting but everyone is scared to tell me so i don't know
 240 < Company> *refcounting in glib
 241 < mclasen> I guess the more radical 'down' would be down to gtkwindow
 242 < Company> i vote gtkwindow
 243 < Company> the signal encourages the wrong behavior we want to get rid of
 244 < Company> and since people need to adapt code anyway...
 245 < kalikiana> destroy is so damn useful I'm surprised you want to get rid of it
 246 < Company> kalikiana: where is it better than weak refs?
 247 < kalikiana> I can destroy widgets and I can connect to the signal
 248 < mclasen> well, what we really wanted to get rid of is GtkObject
 249 < Company> kalikiana: a destroyed widget is useless though
 250 < jhs> hmm, did anyone connect to "destroy" except for GtkWindows?
 251 < tristan> I still feel like my vote is push to GObject, the "destroy" semantic is much nicer (and safer) than weak refs
 252 < tristan> if we want to be that dramatic, hell get rid of GInitiallyUnowned
 253 < Company> i'd love to get rid of GInitiallyUnowned, but that'd cause leaks in _every_ app
 254 < walters> glib isn't up for change
 255 < walters> at least, not incompatible change
 256 < tristan> Company, or make ref counting understandable
 257 < tristan> walters, I know it cant be done :(
 258 < Company> tristan: it's a one-liner
 259 < Company> tristan: in G_DEFINE_TYPE (GTK_WIDGET, ..)
 260 < kalikiana> Company, how would you get rid of a widget without destroying it?
 261 < ebassi> kalikiana: g_object_run_dispose()
 262 < Company> kalikiana: unref it?
 263 < ebassi> which is what destroy does anyway
 264 < mclasen> if it is a window,  you destroy it, otherwise just unparent it
 265 < Company> kalikiana: it's like any other object?
 266 < kalikiana> ebassi, which is explicitly documented as a function for type systems or some such
 267 < tristan> g_object_run_dispose() safer when being the true owner of the object
 268 < ebassi> I think there's a general issue here - we're talking about ::destroy-the-signal, not destroy-the-method
 269 < kalikiana> Company, unref != destroy
 270 < Company> kalikiana: either your objects are refcounted or they are not
 271 < Company> kalikiana: strings aren't refcounted, you can destroy them
 272 < Company> kalikiana: widgets are refcounted, you can't destroy them
 273 < kalikiana> Company, those are perfectly orthogonal concepts
 274 < tristan> kalikiana, if you are the owner of an object that risks having circular ref cycles, you must run_dispose()
 275 < Company> kalikiana: if you do, code will start breaking
 276 < tristan> removing "destroy" only means that watcher objects cant have a reference anymore.
 277 < tristan> they must weak_ref()... it feels so racy
 278 < Company> kalikiana: so if i run gtk_object_destroy() on the GtkAlignment of a tree view, nothing will break?
 279 < 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...
 280 < ebassi> jhs: on top-levels, yes
 281 < Company> ebassi: that's because for toplevels, it's the only way to make sure gtk releases its internal ref to the window
 282 < Company> ebassi: not because toplevels are somehow special otherwise
 283 < ebassi> jhs: if we use "the last window closes the app" semantics, then there's no need for a destroy signal any more
 284 < ebassi> Company: right, that's what I'm saying :-)
 285 < jhs> ebassi: good, any other (valid) use-case?
 286 < kalikiana> Company, not sure which alignment. if the treeview exposes and requires it, it should watch if it's destroyed
 287 < tristan> gtk+ could use a weak_ref to its toplevel list alternatively then
 288 < ebassi> tristan: or have an object like thre ClutterStageManager which holds the list gives you a signal when a top-level is added/removed
 289 < 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 ?
 290 < Company> kalikiana: we do that _nowhere_ - but yes, for destroy to work, we must watch every object we create
 291 < Company> kalikiana: that's a _lot_ of work :)
 292 < tristan> s/should/shouldn't
 293 < Company> kalikiana: also, it'd spectacularly break all the bindings that assume objects stay valid while they have a ref
 294 < 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 ?
 295 < kalikiana> Company, I'd consider a binding oblivious to "destroy" broken
 296 < mclasen> tristan: gtk has had those references since before weak refs existed in gobject...
 297 < jhs> just a note: moving it to GtkWindow would probably break much fewer apps than removing it completely, if that counts
 298 < Company> kalikiana: so all bindings need to take special care to evaluate destroyed objects to the null object?
 299 < tristan> mclasen, in which case the argument could be to remove ::destroy completely, not push it up to GtkWindow
 300 < mclasen> down 
 301 < mclasen> :-)
 302 < tristan> heh
 303 < Company> tristan: yes, i've always said that gtk_window_destroy() should just g_object_unref () the window :)
 304 < tristan> Company, g_object_run_dispose() could be
 305 < tristan> you have to assume that some widget has an accelerator that is in an accel group that is attached to the window
 306 < walters> Company: run dispose, then unref maybe
 307 < tristan> or any such madness
 308 < Company> walters: we'd need this with the current refcounting mess, yeah
 309 < tristan> its not a mess
 310 < ebassi> it really is
 311 < tristan> circular refcounts are perfectly valid situations
 312 < ebassi> we have refcounting and then a huge hammer to break everything
 313 < tristan> not only in language bindings
 314 < Company> tristan: run_dispose() should never be called from C code
 315 < Company> tristan: unless that C code implements a GC
 316 < Company> for fun:
 317 < tristan> Company, we had this argument before, we dont need to waste meeting minutes for this.
 318 < Company> import gtk
 319 < Company> window = gtk.Window()
 320 < Company> window.show_all()
 321 < Company> window.destroy()
 322 < Company> window.show_all()
 323 < Company> what now?
 324 < mclasen> so, summary: it seems there's no urgent need to do further changes to destroy ?
 325 < 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
 326 < ebassi> alternatively: we need a wider bandwidth channel for discussions
 327 < tristan> there we have a GObject database in C, with circular ref cycle, perfectly valid
 328 < ebassi> and weaponry
 329 < tristan> yet needs run_dispose() to destroy properly
 330 < ebassi> I propose we punt this discussion until the hackfest
 331 < ebassi> were we can have popcorns and stuff
 332 < ebassi> where, even
 333 < mclasen> anything seft on the agenda ?
 334 < ebassi> GtkComboBoxText
 335 < ebassi> last item
 336 < ebassi> I think GtkComboBoxEntryText is pushing it a bit too far
 337 < jhs> I like that idea because I never found out how to create a GtkComboBoxText in Glade
 338 < Company> tristan: let's say i also have a ref to the type that i want to stay valid
 339 < tristan> that sounds totally weird, I dont want to be a sore thumb but whats the point of a combo-box text ?
 340 < Company> tristan: what now?
 341 < tristan> Company, in your opinion it must be a weak_ref, remember ?
 342 < jhs> tristan: It's the 99% use-case of a combobox
 343 < ebassi> tristan: it moves the awkward gtk_combo_box_text_* API to a proper sub-class
 344 < tristan> thats the difference between ownership and watching an object with "destroy"
 345 < Company> tristan: only if that'd introduce a cycle, right
 346 < tristan> Company, later, please.
 347 < Company> tristan: :)
 348 < tristan> so the combo_box_text is just a wrapper around the real combo-box, it does real simple stuff, it needs a class ?
 349 < ebassi> tristan: the namespacing is awkward, and it basically prevents you from using the whole API
 350 < tristan> and jhs, a comboboxtext in Glade doesnt exist because it just doesnt exist
 351 < ebassi> tristan: GtkComboBox is already overly complicated as it is
 352 < mclasen> ebassi: the current text convenience api is also exclusive, basically
 353 < tristan> jhs, makeing Glade better is besides the point
 354 < ebassi> tristan: the _text_* API is basically already doing the work of a sub-class
 355 < ebassi> mclasen: yup
 356 < mclasen> the awkward thing about subclassing-for-simple-case is that it breaks the real subclassing
 357 < mclasen> ie you can no longer use the text convenience api with comboboxenytry
 358 < 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
 359 < mclasen> and need a separate convenience subclass for that
 360 < ebassi> mclasen: can the entry be made a property, instead of requiring a sub-class?
 361 < kalikiana> it is, but the API would be missing
 362 < mclasen> that might be possible, but would be a more extensive refactoring
 363 < mclasen> sounds nicer, conceptuall
 364 < mclasen> y
 365 < ebassi> everyone is scared of GtkComboBox - kris wrote it and we almost lost him :-)
 366 < jhs> mclasen: well, now that jjardon is around more refactoring sounds possible :)
 367 < tristan> nod, ok subclassing-for-simpler-case sounds decent to me
 368 < tristan> does anyone use list-mode ?
 369 < ebassi> but ideally, yes: whether a combo box should have an entry should not be matter of sub-classing
 370 < ebassi> tristan: the windows theme, afair
 371 < tristan> a theme uses it ?
 372 < tristan> iish
 373 < ebassi> unless I'm still stuck in 2001
 374 < tristan> combo would be much simplified without list vs menu mode for sure
 375 < mclasen> the list mode at least does no violence to GtkMenu...
 376 < tristan> and the entry not such a big deal to pull back down into combobox I think
 377 < tristan> I still have to see what a list-mode combo-box actually looks like
 378 < mclasen> it looks great
 379 < tristan> :)
 380 < tristan> ok sorry then
 381 < tristan> remove menu mode
 382 < tristan> eh, could those be split into separate classes ?
 383 < ebassi> GtkListCombo :-)
 384 < mclasen> thats what they started out as, optionmenu vs combobox
 385 < ebassi> GtkListMenu
 386 < ebassi> yep
 387 < ebassi> and everyone used OptionMenu
 388 < mclasen>  there's a subtext here of optionmenu being the unixy api, and combobox being windowsy...
 389 < Company> just make all combo box entries an entry completion with a dropdown button!
 390 < jjardon> hello all, about this topic: gtkmm has a subclass for both GtkComboBox and GtkComoboBoxEntry
 391 < ebassi> OptionMenu had the added bonus of making the eyes of everyone with some taste bleed
 392 < Company> ebassi: but it made you scroll, which is awesome!
 393 < ebassi> Company: true, except when it's not.
 394 < ebassi> which is basically always :-)
 395 < 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
 396 < 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);
 397 < tristan> I like the idea of collapsing GtkComboBoxEntry as a property of combo-box
 398 < tristan> I wonder how much code that is
 399 < jjardon> ebassi: Don't look to GtkColorSelectionDialog api then ;)
 400 < ebassi> jjardon: I don't :-)
 401 < jhs> the good thing about GtkComboBox can handle GtkTreeModels, the bad thing is that everything that isn't a list looks ugly...
 402 < ebassi> I actually have to be reminding continuously that we have that dialog...
 403 < ebassi> jhs: tristan actually is solving that problem :-)
 404 < tristan> maybe we should start with doing the everybody wants a GtkComboBoxText, and consider the entry thing
 405 < mclasen> tristan: I think thats a good plan
 406 < tristan> it looks like mostly just adding the api set/get_text_column()
 407 < mclasen> so we accept comboboxtext, we reject comboboxentrytext, and we ask for a merger of combobox and comboboxentry
 408 < tristan> I think so, I might be able to fit that merge quickly and discreetly into my schedule
 409 < ebassi> cool
 410 < 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...
 411 < tristan> I'll try, the tough part is the combo allocation portion that has so many branches (thats what scares everyone I guess)
 412 < ebassi> jhs: no, the "make multiple renderers/trees look better"
 413 < jjardon> and waht about the _text api in comboboxentry? 
 414 < jhs> ebassi: ah cool - that will even make glade look better where I last tried. Rock on, tristan
 415 < tristan> jjardon, comboboxentry dies
 416 < mclasen> jjardon: the idea is to instead get rid of comboboxentry as a subclass, and fold it into combobox
 417 < jjardon> ah, ok
 418 < ebassi> right, that was the last topic
 419 < ebassi> next meeting: hackfest
 420 < ebassi> are there notes for that?
 421 < mclasen> cool, see you guys next weeks
 422 < ebassi> desrt: ?
 423 < mclasen> don't miss your planes
 424 < ebassi> hehe
 425 < mclasen> all we have so far is on the wiki
 426 < mclasen> would be good to brush that up a bit during the week...
 427 < Company> igalia tends to fetch one from the airport, right?
 428 < mclasen> if there's ideas, plans, topics, etc 
 429 < ebassi> thanks everyone for attending; log on the wiki, minutes on the list as soon as I can