1 < mclasen> time to start ? 2 * mclasen somewhat distracted by waiting for a school bus 3 < dom> no time like the present 4 < ebassi> good for me 5 < mitch> yea 6 < mclasen> ok 7 < mclasen> first topic is "what do we do about the public outcry over the adjustment changes" ? 8 < bratsche> Hi 9 < mclasen> the way I see it, there are 3 options here 10 < mclasen> 1) revert it to the previous behaviour 11 < mclasen> 2) stick to it and maybe explain it better, broken apps be damned 12 < mclasen> 3) try to make it more palatable by changing spin buttons (what else? ) to ignore page_size 13 < mclasen> anything else ? 14 < mitch> is 3) feasible at all? 15 < kalikiana> 4) restore the old behaviour and instead emit a critical warning 16 < mitch> it's a model/view ting after all 17 < ebassi> assuming that 3 did not break applications, 2+3 would be the perfect solution 18 < mclasen> mitch: I haven't explored it really 19 < Sonderblade> 3 is feasible, atleast for spin buttons 20 < mitch> kalikiana: in spinbutton? 21 < leio-dl> 1) with the fix reintroduced in a later bug fix release after better public notification 22 < leio-dl> or something like 3) with a similar approach 23 < mitch> i don't see how that can be done within GtkSpinButton? 24 < kalikiana> mitch: it's not only spin buttons 25 < mitch> kalikiana: i know 26 < mitch> gimp was affected on all levels 27 < kalikiana> and my volume is stuck at 80% 28 < kalikiana> so behaviour should not change, still a warning would make sense to me 29 < kalikiana> or am I overlooking something? 30 < mitch> kalikiana: what should not change? 31 < kalikiana> mitch: the behaviour that now breaks all of my desktop and previously worked 32 < mitch> i still think that all these apps are broken and were broken before 33 < mclasen> mitch: we can try again in 2.90... 34 < mitch> mclasen: indeed 35 < Sonderblade> what was the bug# and the commit that caused the new behaviour? 36 < mitch> if we revert i would add a big fat warning to spinbutton and scale 37 < mclasen> so, if we revert to accepting the full range, where would we warn ? 38 < mclasen> when setting a problematic adjustment on the affected widgets ? 39 < mitch> in all adjustment users apart from scrollbar 40 < mitch> i would say there and in their "changed" callbacks 41 < mclasen> that could be a lot of warning, though 42 < mitch> not "value-changed" 43 < mitch> "changed" 44 < mclasen> ah, ok 45 < kalikiana> mitch: That's what I just said as 4) :P 46 < mclasen> do we have a volunteer to come up with a patch for that ? 47 < mitch> until when? tomorrow? 48 < mclasen> ideally 49 < mitch> i can do that tomorrow, and revert my own original commit 50 < mclasen> I may have a look myself tonight 51 < mitch> mclasen: if you do, don't forget to also revert all the removed manual (upper - page_size) i removed 52 < mitch> scratch one "removed" ;) 53 < mclasen> we only revert on the gtk-2-14, and leave the strict code in trunk ? 54 < ebassi> trunk should stay 55 < ebassi> we have a year worth of warning 56 < bratsche> That would go into 2.16 right? Is that intended? 57 < mclasen> bratsche: maybe not 58 < mclasen> but we can sort that out when 2.16 and 2.90 split ways 59 < bratsche> Maybe save it for when 2.90 is branched separately from 2.16 60 < bratsche> Yeah. 61 < mitch> i agree 62 < ebassi> so 63 < ebassi> ACTION: revert and add a warning in gtk-2-14 64 < ebassi> ACTION: add the strict code when we branch in 2.90 65 < mclasen> ok, thanks 66 < mitch> it's three things to revert IIRC, starting 2008-08-05 67 < mitch> what? add strict code when we branch? 68 < mitch> i thought we keep the strict code in trunk? 69 < mclasen> mitch: for 2.90, yeah 70 < mclasen> maybe not for 2.16 71 < bratsche> But trunk will become 2.16, right? 72 < mclasen> but we can sort that out later 73 < mitch> yea indeed, no hurry 74 < mclasen> I just need the stable branch to be fixed right now 75 < mclasen> was there another topic for today ? 76 < mitch> i added one, it's all my fault today 77 < mitch> i basically have patches ready to get rid of all H and V subclasses and have "orientation" properties in their parents 78 < mclasen> we surely can't drop the subclasses ? 79 < mitch> that gets rid of so much code duplication 80 < mitch> mclasen: why not? 81 < kalikiana> but we can deprecate the subclasses :) 82 < mclasen> because apps are using them ? 83 < mitch> sure, deprecate them, not drop :) 84 < kris> I wonder if apps will ever move away from using them though ... 85 < mitch> that would give us nice opportinities to fix default values, since e.g. GtkBox is abstract 86 < mitch> so having GtkBox instances is essentially a new widget 87 < mitch> where the packing defaults could be fixed 88 < mitch> kris: sure, many people fix their code to not use deprecated, don't you? ;) 89 < kalikiana> that would be a pretty neat side effect 90 < bratsche> Is it possible to make like #define gtk_hbox_new helpers that alias to gtk_box_new and add the correct property, plus the remaining arguments to the #define? 91 < ebassi> +1 for 92 < mitch> bratsche: no, the function would have to stay 93 < kris> mitch: okay okay 94 < ebassi> #define gtk_vbox_new(t,s) 95 < kris> mitch: no further input from me here as I don't maintain apps 96 < ebassi> gtk_box_new (orientation, t, s) 97 < mitch> we can't get rid of the symbol 98 < mitch> ebassi: exactly 99 < mitch> gtk_srparator_new() 100 < mitch> gtk_ruler_new() 101 < mitch> etc. 102 * mclasen is all for making things flippable 103 < bratsche> I know the symbol needs to stay during 2.16, but I meant during 2.90.. but anyway, that's for later. :) 104 < mitch> ok, expect a ton of patches to be files in the coming days 105 < kalikiana> mitch: Make a note to expressly document the properties, please, if you change them 106 < mitch> filed 107 < mitch> kalikiana: what change? 108 < kalikiana> mitch: You said the defaults can be fixed 109 < kalikiana> Or did I misunderstand? 110 < Sonderblade> if vbox, hbox and friends become deprecated won't they still someday have to be removed? otherwise what is the point of deprecation? 111 < mitch> kalikiana: that is unimplemented and needs to be discussed, i don't even have code for changed defaults 112 < kalikiana> Sonderblade: Of course, but not within 2.16 113 < mitch> Sonderblade: exactly, but the actual point is a) reducing code duplication and b) making subclassing easier 114 < mitch> right now you have to derive from GtkHRuler *and* GtkVRuler if you need to subclass 115 < kalikiana> mitch: Sure, good enough if you add it to the bug orwhatever, just that it's considered right away :) 116 < mitch> or look at GtkScaleButton, it has two subclasses for HScale and VScale 117 < kalikiana> There are even 3rd party hvbox style widgets out there 118 < mitch> i know, they can all die once 2.16 is out then 119 < mitch> i will file separate bugs for each bunch of parent,v,h i hacked 120 < mitch> ebassi: ACTION please ;) 121 < Sonderblade> it would be very cool if they are runtime flippable :) 122 < bratsche> heh 123 < mclasen> one interesting thing is that we get runtime flippability 124 < mitch> Sonderblade: they all are in my tree 125 < ebassi> ACTION: mitch files bugs with the various patches 126 < ebassi> :-) 127 < mclasen> but if you have nested boxes, you probably want to flip them all at the same time 128 < mitch> one small problem i have is e.g. GtkRange which has class members to control drawing details 129 < mitch> that needs to be sorted somehow 130 < Sonderblade> mitch: yay! :) 131 < mitch> mclasen: yea i have code in testgtk for that too ;) 132 < mitch> works nicely actually 133 < bratsche> Oh, that's cool that it's runtime-flippable. 134 < ebassi> neat 135 < ebassi> this is definitely going in the minutes :-) 136 < mclasen> are we ready to go to 'misc' ? 137 < mitch> do we want set/get_orientation() API in addition to the properties? 138 < mclasen> that would be the standard for widget properties, no ? 139 < mitch> yea useless question 140 < mitch> let's move along to misc 141 < mclasen> the one thing I have is a follow up to the advisory board call on GTK3 142 < mclasen> thus mostly for kris, timj, mitch, I guess 143 < mclasen> has anybody done any work on the action items we had coming out of that call ? 144 < mclasen> in particular the www.gtk.org section on gtk3 145 < mitch> mclasen: everybody apart from me has been at the maemo summit, we will have to do lots of stuff this week 146 < mclasen> ah, thats fine 147 < mclasen> but we need to get going on those things soon 148 < mitch> omg i promised work done by my coworkers ;) 149 < mclasen> I'll keep the www.gtk.org update on my todo list 150 < kris> we've been thinking about some more concrete features and such 151 < ebassi> I could not make it for the conf call :-( 152 < kris> but I dunno how that is going to proceed 153 < kris> oh and there is timj 154 < kris> timj: 22:31 < mclasen> has anybody done any work on the action items we had coming out of that call ? 155 < ebassi> by the way: anybody has the actual list of action items 156 < mclasen> wow, so late already in europe 157 < ebassi> ? 158 < mclasen> I think timj took notes 159 < ebassi> (and possibly the log/minutes of the meeting of two weeks ago) 160 < mitch> mclasen: we work our asses off at night here! 161 < mclasen> at least he made it sound like he did... 162 < timj> ebassi: did you get the slides? 163 < ebassi> mitch: I had three pints down at the pub before the meeting, so I guess this qualifies as "working my ass off" as well ;-) 164 < ebassi> timj: nope 165 < timj> there was little point in minutes during a slide presentation 166 < mitch> ebassi: exactly :) 167 < ebassi> heh 168 < mclasen> ebassi: I sent some impressions immediately after the call, I can forward that to you 169 < mclasen> its a far cry from minutes, though 170 < ebassi> mclasen: thanks, that would be cool 171 < mclasen> ok, thats all I had on my list for today 172 < mclasen> if nobody else has 'misc' items, I think we're done 173 < bratsche> Out of curiosity, is anyone else here planning to be at Boston? 174 < mclasen> I'm doing a stable release tomorrow, for the gnome guys 175 < bratsche> I know ebassi and federico are going. Didn't know if anyone else is planning. 176 < mclasen> I'll probably be there 177 < bratsche> Cool 178 < mclasen> Owen is going to be there, too 179 < mitch> mclasen: i'll do the patches or review yours, whoever is faster (i'll not do anything tonight though) 180 < kris> mclasen: we'll get back with roadmap stuff at some point, we did some concretizing and all 181 < kris> bratsche: not me 182 < kris> matlab fried my brain this evening 183 < mclasen> mitch: the ass is already off... 184 < bratsche> kris: heh 185 < mitch> haha yes! 186 < mclasen> good night then, everybody 187 < bratsche> Bye. 188 < ebassi> 'night everyone 189 < bratsche> kris: Where is your uni anyway? 190 < mitch> nite 191 < kris> bratsche: Leiden 192 < mitch> die Leiden des jungen Kris 193 < timj> kris: could you fwd the advisory board meeting slides to ebassi? 194 < bratsche> :) 195 < kris> oh no I get lessons in German again 196 < kris> timj: sure 197 < bratsche> Okay, back to work. Bye everyone! 198 < kris> later bratsche 199 < ebassi> thanks kris 200 < timj> mclasen: about AB meeting action items, it's mostly us creating a gtk-3 web presence (blog) and posting a roadmap. 201 < mclasen> yeah 202 < timj> i'll do my best to send out an initial draft of that in a few days (or have kris do it, since i'm on vacation next week) 203 < mclasen> cool, thanks
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.