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