1 < ebassi> okay, as usual: the meeting agenda is available at http://live.gnome.org/GTK%2B/Meetings 2 * mclasen goes for coffee 3 < mclasen> ok, shall we go ? 4 < ebassi> fine by me :-) 5 < mclasen> do we have anything else for the agenda ? 6 < ebassi> I didn't receive any further point 7 < mclasen> ok 8 < mclasen> first one is the assistant redesign 9 < ebassi> okay, first point: • GtkAssistant design refresh: 648136 (committed, comments still welcome) 10 < mclasen> I landed that by now (and just found some issues with it today...) 11 < mclasen> the one thing why this is worth discussing at all 12 < garnacho_> I think it needs some love for the default theme, I may take care of that 13 < mclasen> is that I had to slightly weaken our guarantees for child properties 14 < ebassi> I saw a bug from hadess about adding titles for pages; do we need to check every Assistant use and see if the title is not set? or do should we add a fallback to avoid unnamed pages? 15 < mclasen> so that containers can have internal structure 16 < mclasen> the problem in hadess' bug was that the control center code was poking at the internals of hte assistant 17 < mclasen> to make the page titles take markup 18 < ebassi> ah, okay 19 < mclasen> and since we've moved the internals around, that broke... 20 < Company> "poke at the internals"? 21 < Company> in what way? 22 < mclasen> list all direct children, and assume that the page labels are among those 23 < Company> ah 24 < Company> yeah, that is supposed to break 25 < Company> if you do things in a way that is obviously not the right way to do things but works around a missing feature, you should expect it to break in the future 26 < mclasen> I'm slightly worried that glades assistant handling seems pretty busted 27 < mclasen> but maybe it was so before, too ? not sure... 28 < Company> like calling APIs reserved for containers from random code 29 < Company> (glade is pretty broken in lots of ways anyway) 30 < ebassi> mclasen: relaxing the child properties worries me a bit; it might happen that you start poking from a button to its grandparent :-/ 31 < mclasen> ebassi: the alternative would have been to introduce a much heavier 'composite' interface, and duplicate all the child property machinery 32 < ebassi> mclasen: or add a GParamSpec *(* find_property) to GtkContainer? 33 < ebassi> mclasen: then the assistant would overrid it 34 < ebassi> override, even 35 < mclasen> one alternative I proposed was a 'is_this_your_child?' vfunc for containers 36 < mclasen> I think this somehow relates to tristan's ideas about composites, but I'm not sure yet how, in detail 37 < Company> i think it boils down to protected vs public API 38 < mclasen> anyway, I don't plan to go on a wild chase to introduce indirect-child properties all over the place 39 < mclasen> although it would be handy in some places, e.g. response ids in dialogs 40 < mclasen> if there is nothing else on assistants, I think we can move on; I'll keep an eye out for regressions, and hope to get cosimo/garnacho to apply some theme love to them 41 < garnacho_> for sure :) 42 < mclasen> next topic on the list was GtkLockButton 43 < cosimoc> mclasen, will get to it 44 < mclasen> I've committed that as well before 3.1.4 45 < mclasen> the slight concern here is that this is fairly specialized 46 < mclasen> but otherwise, it should be a straightforward widget 47 < ebassi> not any more specialized than the GtkSwitch, or the Assistant :-) 48 < mclasen> the only things it is missing atm is a tailored a11y implementation and a nice example in gtk-demo 49 < mclasen> I was struggling a bit with how to add a nice example without adding a polkit dep, I may try again at some point... 50 < mclasen> should probably move on further to the interesting topics 51 < mclasen> the next one is certainly more interesting: GeditOverlay 52 < ebassi> I still need to see that in action 53 < mclasen> its what you get if you search in gedit, no ? 54 < Company> GeditOverlay is the popup in nautilus and epiphany, no? 55 < mclasen> yeah, it is used there too 56 < cosimoc> nautilus uses it for the floating statusbar yeah 57 < Company> (i'm not gonna comment on it because i think it's really crappy UI) 58 < Company> other than that it's interesting because it stacks widgets 59 < Company> which no other "serious" widget does 60 < ebassi> does it use compositing or is it just stacking? 61 < aruiz> my only concerns with it is the navigating behaviour 62 < aruiz> it is inconsistent with firefox for example 63 < ebassi> as soon as you tab out, it goes away 64 < aruiz> and not very nice to navigate the results with the keyboard 65 < mclasen> ebassi: I think it has compositing support, but turned off by default, since it was causing performance problems with scrolling 66 < ebassi> which is also inconsistent with chrome 67 < mclasen> I don't think the hide-on-focus-out is builtin, or is it ? 68 < ebassi> dunno, I haven't seen the code :-/ 69 < cosimoc> I don't think it is, no 70 < Company> why is it 2 widgets? 71 < aruiz> ebassi, my concern is more about the usability of it than the consistency with other apps, how to navigate is not very discoverable 72 < mclasen> Company: it isn't really; and I've commented that the child thing should probably just go away and be turned into regular child properties 73 < Company> ah 74 < Company> a workaround for child properties :) 75 < mclasen> no, I think it is because they needed a window in between 76 < mclasen> but you have just demonstrated how to do that without extra widgets in gtkpaned, as I understand... 77 < Company> the handlebox can do without, too 78 < Company> yeah, it should be quite simple to do with gtk_widget_set_parent_window() 79 < ebassi> aruiz: to fully copy from chrome, you'd need to add a close button 80 < mclasen> so, my general feeling is that we should probably take a container like this, since it seems to be a pattern that is actually used in apps 81 < xan> mclasen: it is because of the need for a window, yes 82 < ebassi> aruiz: that at least would allow closing it without a) tabbing out or b) pressing Esc 83 < aruiz> ebassi, nod 84 < mclasen> and we should probably get some more eyes on the code to get it closer what we want 85 < mclasen> I already did one round of review... 86 < ebassi> mclasen: and probably, to avoid another Switch, some input from the design team 87 < cosimoc> my feeling is that the interaction can be improved, but it belongs to the embedded widget really 88 < ebassi> mclasen: about usage guidelines 89 < mclasen> ebassi: good point 90 < Company> cosimoc: it should pretty much be done manually and not be part of the overlay 91 < Company> cosimoc: the overlay should just be about displaying the overlay widget at some given position 92 < cosimoc> Company, yeah that's what I'm saying - the overlay could indeed offer some high-level helpers like "move on the other side on mouse hover" 93 < Company> cosimoc: or not if its visibility == FALSE 94 < cosimoc> but that's just about it 95 < mclasen> the overlay also needs to handle focus, somehow 96 < Company> yeah 97 < Company> it needs to do the magic for this stuff 98 < Company> probably provide some signals to hook up to 99 < mclasen> ok, I'll try to condense this discussion into a comment on the bug - anything else on the overlay ? 100 < mclasen> do people agree that this would deprecate gtkfixed ? 101 < Company> no 102 < Company> wait 103 < Company> gtklayout is scrollable, gtkfixed isn't, right? 104 < cosimoc> mclasen, I don't think the overlay can be assigned an arbitrary x/y 105 < Company> but nonetheless, fixed should be deprecated (just like handlebox) 106 < mclasen> there is a 'static' mode; just not implemented, from what I saw 107 < mclasen> could be easily added, I think 108 < cosimoc> mclasen, at least the copy I copied in nautilus only worked on corners...yeah not too hard to add 109 < Company> i would use align flags for that btw 110 < Company> use gtk_widget_get_halign (child) to layout the child 111 < ebassi> Company: +1 112 < cosimoc> that's a good idea 113 < ebassi> fixed coordinates is not a great solution 114 < ebassi> especially with resizable windows 115 < cosimoc> that would make it more similar to clutter constraints too 116 < ebassi> cosimoc: yeah, though I'd like to add Constraints to gtk ;-) 117 < mclasen> yeah, not sure that fixed coords is going to be very useful 118 < Company> and it'd make it possible for totem to use it 119 < Company> if they'd want to 120 < mclasen> although you already have it, kinda, with the offsets 121 < Company> totem could use valign end and halign center or fill 122 < mclasen> ok, further comments in the bug ? this clearly needs a few more rounds of refinement... 123 < ebassi> agree 124 < mclasen> ok, the next one should be a fun topic too 125 < mclasen> font selection dialog 126 < aruiz> \o/ 127 < Company> i'd suspect it goes through some more blog posts 128 < aruiz> so, I've been working on a branch to implement a design I've been discussing mostly with aday, but with input from jimmac and most recently hbons 129 < Company> until no more UI guys comment ;) 130 < mclasen> has anybody other than me tried th ebranch ? 131 * Company hasn't, he only argues on irc or blogs 132 < aruiz> I'm taking that as a no 133 < cosimoc> I did not...some screenshots would probably be useful? :) 134 < aruiz> Company, I implemented your idea of hiding the preview entry 135 < aruiz> Company, with a property 136 < aruiz> cosimoc, sure, one sec 137 < aruiz> cosimoc, http://dl.dropbox.com/u/4524326/Screenshot-Font%20Selection.png 138 < aruiz> so with this design, the major controversial point is what to do with the preview entry when it grows 139 < aruiz> mclasen, suggests that it should eat the treviews space up to a maximum 140 < ebassi> aruiz: resize the entry at the expense of the treeview 141 < aruiz> okay 142 < aruiz> that's a +2 143 < Lethalman> isn't it possible to compute the maximum size of the preview? 144 < aruiz> Lethalman, for the standard sizes, yes 145 < mclasen> you don't want to show tiny text in a huge entry, really 146 < aruiz> mclasen, I guess that makes sense 147 < aruiz> most times you have sensible sizes there 148 < ebassi> plus, you want to make sure that a) the dialog does not need resizing and b) it doesn't occupy the whole screen on netbooks 149 < mclasen> one alternative you could try is to avoid the vertical scrollbar and go for a paned instead 150 < mclasen> which lets you manually shrink the list to make the preview fit 151 < aruiz> ebassi, yeah, I've designed the dialog with small screens in mind 152 < aruiz> mclasen, I had something like that in 2.x, but the size_request behavior changed 153 < cosimoc> aruiz, why the marks on the range? 154 < aruiz> cosimoc, those are the standard sizes 155 < aruiz> cosimoc, it's more convinient than a treeview 156 < mclasen> some of the designers favor a different arrangement: http://bugzilla-attachments.gnome.org/attachment.cgi?id=187582 157 < aruiz> and they are not critical enough to use the space of a whole treeview 158 < ebassi> I like the slider; it's more informative than a spin button 159 < aruiz> mclasen, I have several problems with that design 160 < Company> mclasen: the fontselectionwidget is orientable! 161 < Company> mclasen: :) 162 < mclasen> more like a netbook mode 163 < cosimoc> I like the slider too, but I think marks other than the default size don't really add anything 164 < ebassi> it could detect the aspect ratio of the screen 165 < aruiz> mclasen, the first one is that it scarifies horizontal space for both the treeview and the preview 166 < ebassi> and change orientation based on that 167 < aruiz> mclasen, the other one is that the slider will be next to the treeview's scrollbar 168 < aruiz> very confusing 169 < mclasen> yeah, I noticed that too 170 < mclasen> so, lets not get hung up on this one thing 171 < aruiz> and the relationship between the spin button and the slider is lost in that layout 172 < aruiz> yeah 173 < aruiz> I mean, I'm open to suggestions 174 < mclasen> there's some other questions that are maybe more relevant for this meeting 175 < aruiz> but I did run through a lot of iterations with jimman and aday 176 < aruiz> and I moved over stuff to C when there was some consensus in gnome-design 177 < mclasen> such as the deprecated old apis, and code to support them 178 < aruiz> yes 179 < aruiz> So I deprecated the accessors to the old treeviews, but still implemented them to work alongside the new UI 180 < mclasen> I guess there's two questions here: 181 < mclasen> if they give you a treeview thats not actually shown, is that cheating ? 182 < aruiz> mclasen, yes :P 183 < mclasen> and is that going to be useful for whatever use people might have for those accessors ? 184 < ebassi> I do wonder if somebody is actively using those 185 < cosimoc> aruiz, so you create a treeview on the fly that mimics the old behavior? 186 < aruiz> cosimoc, yeah, there's some signal spaghetti involved, but yes 187 < mclasen> would it not be more straightforward to just return NULL ? 188 < ebassi> because I honestly can't see the point in accessing the treeview of a composite widget 189 < aruiz> ebassi, AFAIK, none 190 < ebassi> we don't allow that for GtkFileChooserWidget 191 < Company> mclasen: depends on your goal - NULL would break apps 192 < aruiz> I searched through codesearch 193 < aruiz> and found nothing but bindings 194 < ebassi> (even though people begged us to do that) 195 < mclasen> Company: assuming any apps use these apis 196 < Company> mclasen: yes 197 < ebassi> I'd return NULL, and if apps break then we can fake it 198 < Company> mclasen: but if we break it anyway, we could just remove the API 199 < mclasen> the obvious alternative would be to leave the old fontsel in place, and put a new api next ot it 200 < aruiz> honestly, I though you guys would yell at me if I returned NULL 201 < mclasen> but then people have to port 202 < aruiz> :-) 203 < Company> mclasen: and claim it was a bug we left it in for 3.0 204 < ebassi> Company: bindings are more resilient against NULL than against a missing symbol 205 < Company> ebassi: true 206 * aruiz is happy to maintain that code 207 < Company> ebassi: we could also just return the font list tree view -.- 208 < ebassi> mclasen: GtkFontChooser? 209 < cosimoc> I think I would like better having a new widget altogether 210 < cosimoc> that leaves no room for misunderstandings 211 < Company> yeah 212 < Company> doing subtle things leads to subtle bugs 213 < aruiz> that would be two new widgets or just one? 214 < aruiz> I mean 215 < Company> i know from GtkLabel::width-chars 216 < aruiz> GtkFontChooser + Dialog 217 < ebassi> aruiz: GtkFontChooserWidget and GtkFontChooserDialog 218 < mclasen> aruiz: it would be 2, I think 219 < aruiz> or would GtkFontSelectionDialog use FontChooser underneath? 220 < ebassi> aruiz: like GtkAppChooser, GtkRecentChooser and GtkFileChooser 221 < Company> gtk_font_selection_dialog_get_apply_button() 222 < ebassi> aruiz: no, I'd deprecate GtkFontSelection* 223 < Company> we do have awesome apis... 224 < aruiz> okay 225 < ebassi> aruiz: like we deprecated GtkFileSelection* 226 < aruiz> Company, yeah, I thought the same thing :P 227 < Company> ebassi: +1 228 < aruiz> okay 229 < mclasen> ok, so we all think that that is better ? 230 < mclasen> cool 231 < aruiz> you guys tell me what to do, I have no strong opinions in this regard 232 < mclasen> it does mean that apps need to be ported, but that should not be hard, I assume 233 < Company> we can then reuse the "selection" term when we deprecate the cooser widgets 234 < mclasen> aruiz: I hope you don't mind the extra work 235 < aruiz> mclasen, I'll cry a little bit for the few afternoons I spent on the deprecated stuff, but that's about it :-) 236 < aruiz> I'm fine with it 237 < Company> aruiz: you now have full freedom in redesigning the API 238 < Company> aruiz: so i'd throw out everything that people don't need :) 239 < mclasen> that is an added benefit, indeed 240 < ebassi> just make it small :-) 241 < mclasen> and we probably do want some extra apis 242 < aruiz> ebassi, yeah 243 < mclasen> like app-provided filtering (monospace !) 244 < aruiz> mclasen, the monospaced filter 245 < ebassi> and, for god's sake: no poking at internals! 246 < aruiz> mclasen, app-provided? 247 < aruiz> with some sort of filtering function? 248 < mclasen> as opposed to by-the-user 249 < aruiz> ebassi, absolutely 250 < mclasen> like a little brother of GtkFileFilter 251 < Company> i suppose that's easy - gboolean (* FontFilter) (PangoFontSomething *font, gpointer data); 252 < aruiz> mclasen, is that a requirement for an eventual merge? 253 < mclasen> no 254 < mclasen> just something to keep in mind 255 < aruiz> I will, definitively 256 < Company> mclasen: GtkFileFilter sucks, don't use that... 257 < ebassi> a simple function would do 258 < mclasen> now that we gave aruiz enough to do for the next week, we should probably move on... 259 < ebassi> we don't need mime type or regexp 260 < mclasen> quite a few more things on the agenda 261 < aruiz> yup 262 < ebassi> right, next up: GProperty 263 < mclasen> gproperty ? I lost track of the developments there 264 < mclasen> whats the latest ? 265 < ebassi> I have a v0.2 which bypasses GValue and adds some API that makes Company happy :-) 266 < ebassi> missing docs+examples, a bunch of cosmetic fixes, a GVariant variant, and locking 267 < mclasen> ok 268 < Company> i mainly added it to the list 269 < Company> so that everybody is aware of it 270 < ebassi> it's on a branch on git.gnome.org now 271 < Company> i expect that ebassi, me and whoever is interested will review it 272 < ebassi> so people can check it out (though I rebase it quite often) 273 < mclasen> anything to discuss there today ? or just ongoing in bz ? 274 < Company> and then merge it when we're happy 275 < mclasen> sounds good to me 276 < Company> and then port gtk 277 < mclasen> although we probably need to hire janitors at some point 278 < Company> and other stuff 279 < mclasen> we are already behind on the latest property technology in gtk 280 < Company> to make sure it really works how we imagined it 281 < Company> what are we missing in gtk? 282 < mclasen> the pspec array stuff 283 < ebassi> mclasen: the nice part is that changing this + array of paramspecs is a single job 284 < ebassi> since it integrates nicely, and both touch the same code 285 < mclasen> that is nice, indeed 286 < ebassi> but yeah, it'll need some of the old jjardon magic :-) 287 < mclasen> I'll look at v2 when this gnome release is behind me 288 < mclasen> does it still do the atomic stuff, or did you drop that ? 289 < Company> while we are at announcing stuff 290 * aruiz is in the same room that the so called janitor 291 < Company> i should probably announce the pending css parser merge 292 < Company> especially now that garnacho_ listens 293 < mclasen> good point 294 < Company> so for anybody not aware of it: 295 < ebassi> mclasen: I didn't drop the API, just the implementation; I actually added API for overriding the lock/unlock primitives 296 < Company> i've a rewrite of the css parser that does not use GScanner and conforms closer to css 297 < Company> *css parsing rules 298 < ebassi> mclasen: I'll work on the default implementation along with the rest of the fixes 299 < mclasen> makes sense, I guess 300 < Company> the main reason is that i want proper error handling with line numbers 301 < Company> and long term i want to get to making css work properly with inherit etc 302 < jjardon> ebassi: give me the first patch ;) 303 < Company> i'm doing that with cosimoc 304 < Company> so if anyone wants to provide input there, it's in gnome git, the parser branch 305 < mclasen> I will, after 3.1.1 306 < mclasen> I don't have a ton of time today, so let rush the deprecation topics, if you don't mind... 307 < ebassi> sure 308 < mclasen> there's various: h/v variants, table/box, misc/alignment and color 309 < ebassi> my take: yes, yes, yes and yes :-) 310 < mclasen> not sure there is too much to discuss here, even 311 < cosimoc> box is going to be huge 312 < Company> question is how quickly we want to deprecate it 313 < mclasen> I did merge tristan's rgba textview patch, so we are much closer on gdkcolor 314 < mclasen> box is not really realistic for 3.2, I think 315 < jjardon> links to the bugs in http://live.gnome.org/GTK+/Meetings 316 < Company> yeah, color should go asap 317 < jjardon> cosimoc: yeah, thats the most difficult task 318 < mclasen> the others are much easier 319 < Company> color just requires someone doing the work 320 < Company> misc should go asap, too 321 < mclasen> what exactly is left in gdkcolor ? just style properties ? 322 < ebassi> misc and alignment should just go 323 < jjardon> Company: I'm sending patches to the bug to review. Thanks mclasen btw 324 < Company> mclasen: i think it's just the API 325 < Company> mclasen: style properties should all be rgba by now 326 < ebassi> one thing for Box would be a nice migration chapter, with examples for each setting 327 < ebassi> and screenshots 328 < mclasen> there's some leftovers like link colors 329 < Company> damn 330 < jjardon> mclasen: the link colors 331 < ebassi> those are pretty trivial 332 < mclasen> ebassi: yep, that would be of utmost importance 333 < Company> and we can't change that i guess because of API stability? 334 < ebassi> it's just two: link and link-visited, AFAIR 335 < mclasen> the thing is that nobody really uses style properties as api 336 < Company> there might be subclasses? 337 < mclasen> they are just set in css (where we parse whatever) and used inside gtk 338 < jjardon> bug here: https://bugzilla.gnome.org/show_bug.cgi?id=648989 339 < Company> i'd like to move a bunch of properties around fwiw 340 < ebassi> you cannot set style properties directly anyway 341 < Company> and i'm not yet sure how to do that without breaking API 342 < mclasen> what kind of properties ? 343 < Company> ebassi: but style_get (widget, "link-color", &gdk_color, NULL) will break... 344 < ebassi> you can mark properties as deprecated 345 < Company> mclasen: big thing is merging style properties and style context properties or whatever they are named 346 < mclasen> Company: we can add a rgba property next to it, deprecate the original, and keep them in sync 347 < mclasen> but yeah, just phasing out style properties altogether might be better 348 < Company> mclasen: that's kinda ugly in the css though, we'd need special cases there... 349 < Company> should link-color be using :visited or some generic state flag? 350 < Company> or is :visited too css specific? 351 < Company> also: it's probably something not for this meeting 352 < mclasen> sounds like a nice idea, actually 353 < ebassi> :active, :hover, :visited 354 < ebassi> would be nicer using pseudoclasses like that 355 < mclasen> yeah, so: anything else on deprecations ? it seems jjardon is working on it, and I will try to do some work on the migration docs too 356 < mclasen> if not, I'd like to close the meeting and run off, unless there's misc items to bring up 357 < ebassi> not here 358 * mclasen has one himself 359 < jjardon> yeah 360 < jjardon> what about the new website? 361 < mclasen> I haven't followed that, tbh 362 < ebassi> jjardon: I think the person that was working on that disappeared or something 363 < ebassi> we'll have to poke martyn again 364 < mclasen> there was a mail from martyn today 365 < mclasen> where he said 'I'll migrate it shortly' 366 < ebassi> oh, cool 367 < jjardon> oh, ok, I didnt see that 368 < mclasen> sent 3 hours ago 369 < mclasen> I wrote an initial patch for hiding focus rectangles 370 < mclasen> when not doing keynav 371 < mclasen> the designers wanted something like that to reduce clutter 372 < cosimoc> mclasen, how do you detect if we're doing keynav or not? 373 < mclasen> it is somewhat limited, but maybe people want to give it a try anyway 374 < mclasen> I just show the rectangles when any key event comes in 375 < ebassi> mclasen: do you have a bugref? 376 < mclasen> no good way to discriminate between e.g editing in an entry and 'keynav' per se 377 < cosimoc> mclasen, ah so it's hidden by default and activated after the first keypress 378 < mclasen> https://bugzilla.gnome.org/show_bug.cgi?id=649567 379 < ebassi> thanks 380 < mclasen> yeah, I tried to be smart and inherit the initial value from a transient parent 381 < mclasen> but what you would really need is to pass not just a timestamp along, but the entire event, when activating a window/application 382 < mclasen> so you could see if it was activated 'by keynav' 383 < jjardon> about GtkBox -> GtkGRid transition, what do you think about set a GnomeGoal / GtkGoal as seems a huge work but that can be done for new contributors? 384 < mclasen> I think we need the docs first, before such a goal can make any sense 385 < mclasen> also, I just found what looked like some issues with nested grids today 386 < Company> yeah 387 < Company> i'm not sure how expand flags should really work yet 388 < mclasen> so maybe not quite ready for widespread conversion yret... 389 < Company> and i don't think hp is either... 390 < jjardon> mclasen: sure 391 < mclasen> sorry, I have to go now. Thanks everybody ! 392 < mclasen> see you sometime soon 393 < jjardon> see you! 394 < ebassi> thanks everyone for attending 395 < ebassi> as usual, minutes will be sent to the list ASAP, and log will be on the wiki 396 < ebassi> next meeting in two weeks, if everyone is alright with that
Attached FilesTo refer to attachments on a page, use attachment:filename, as shown below in the list of files. Do NOT use the URL of the [get] link, since this is subject to change and can break easily.
You are not allowed to attach a file to this page.