Attachment '20080923.txt'
Download 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 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.