1 < ebassi> meeting time :-) 2 < ebassi> as usual, the agenda is on the wiki: http://live.gnome.org/GTK%2B/Meetings 3 < ebassi> • GApplication and GtkApplication 4 < ebassi> • Revise 'deprecatable' list 5 < ebassi> • Change default values for properties 6 < walters> ok so, GtkApplication status quickly - we reworked GAppliaction's API significantly based on comments, and various fixes landed. I've been working a bit today on documentation and more minor fixes 7 < walters> there are still big picture items outstanding like win32/osx backends, but I think the general feedback there is that it wouldn't hurt at least, and can potentially help 8 < ebassi> I've been looking at re-implementing UniqueApp in terms of GtkApplication - or at least porting it inside GtkApplication itself (basically, the message passing) 9 < ebassi> it's not ready, yet, but this week I've allocated time to finish it off and propose it 10 < mclasen> ok, I have a few additions to the agenda 11 < mclasen> - xi2 merge 12 < mclasen> - minor api cleanup possibilities 13 < mclasen> so, what do we start with ? 14 < ebassi> mclasen: do you have other things to say, re: gapplication? 15 < ebassi> otherwise we can start with xi2 merge 16 < mclasen> my main concern re gapplication is to get some prototype implementation for win32/osx 17 < mclasen> but lets start with xi2 merge then 18 < jjardon> Do somebody know the nick of the guy that makes the ige stuff? 19 < mclasen> paul davis is las, I don't know if john ralls is on irc 20 < mclasen> status of xi2: carlos created the xi2-for-master branch last week 21 < mclasen> and I spent some time fixing up distcheck and docs on it 22 < mclasen> and it works fine, as far as I can see 23 < mclasen> today I committed the gdk sealing patch to master 24 < mclasen> and merged it to xi2-for-master 25 < mclasen> so from my perspective, the branch is good to be merged 26 < mclasen> I would have loved to have garnacho look over things one more time, but he seems not around this week 27 < ebassi> I'd say go for it :-) 28 < mclasen> yeah, my feeling as well 29 < mclasen> oh 30 < mclasen> ok, if there is no further discussion on it, I'll merge it later, and do a snapshot with it 31 < mclasen> garnacho said he'd work on some more docs, but that clearly doesn't have to block the merge 32 < mclasen> next topic ? 33 < ebassi> "minor API cleanup possibilities" 34 < mclasen> thats mine, I guess ? 35 < mclasen> some things I noticed while looking through api docs yesterday... 36 < mclasen> We still have GtkArg in the headers, with gtk_main_add_quit_func_full (or similar) being the only user 37 < mclasen> we could consider replacing that with GParameter, which has the same purpose 38 < jjardon> indeed, GtkArg is already deprecated 39 < mclasen> it would be an api break, for an almost never-used api 40 < mclasen> another small thing I noticed in passing is an unused GtkForeachData in gtkcontainer.c 41 < mclasen> but thats not in any headers, I think 42 < mclasen> and the last one I had on my list was GtkWidgetHelpType - is that something that is used/useful ? 43 < ebassi> doesn't seem used at all 44 < mclasen> iirc the gimp used it at some point 45 < mclasen> not sure if they still do 46 < ebassi> wasn't that some sort of windows95 kind of "help topic"? 47 < ebassi> to get quick help about controls 48 < mclasen> yeah 49 < mclasen> the original idea was to click on a help button in the window frame, and then on a control 50 < mclasen> or something like htat 51 < mclasen> never implemented 52 < jjardon> mclasen, gimp doesnt have GtkWidgetHelpType in its code 53 < mclasen> anyway, I just wanted to throw these out here to maybe inspire some thought or patches 54 < mclasen> no need to decide anything on the spot 55 < kalikianatoli> ^^ Hopefully somebody takes notes on these deprecation items 56 < mclasen> the last topic I'd like to get a quick vote on is the flipping of orientables 57 < mclasen> last week we said that we'd try to do the default value changes that were holding this up for all this time 58 < jjardon> kalikianatoli, I'll, Should I file a bug for each item 59 < jjardon> ? 60 < mclasen> but when jjardon and I looked at it, it turned out that changing visible to default to true does not work 61 < kalikianatoli> jjardon, yeah, if you don't mind, that would be nice 62 < mclasen> it breaks all kinds of assumptions inside gtkwidget.c 63 < mclasen> so I think it is essentially undoable 64 < mclasen> the only other default changes that were on the wiki are already in place 65 < mclasen> (that was box expand and fill child properties) 66 < kalikianatoli> so can we have non-abstract orientables then? 67 < leio> jjardon: GtkWidgetHelpType seems to be a parameter of GtkWidgetClass::show_help btw, so some GtkWidget derivatives outside gtk+ that implement show_help use the symbol as its in the prototype of the vfunc per google codesearch 68 < jjardon> This was the patch: http://pastebin.com/Sx5pn87b 69 < mclasen> kalikianatoli: that is my proposal: make orientables instantiable anyway 70 < mclasen> I have a patch to do so ready to go 71 < mclasen> just want to see how others feel about that 72 < ebassi> I don't mind 73 < kalikianatoli> You have my thumbs up 74 < ebassi> would allow me to stop using VBoxes and HBoxes 75 < mclasen> yeah, only boxes from now on 76 < mclasen> so, I'm done with my topics. whats next ? deprecation list ? 77 < ebassi> yep 78 < ebassi> 'revise deprecatable list' 79 < ebassi> the TearoffMenuItem bug is getting ridiculous 80 < mclasen> so, where's the list, and what revisions are proposed ? 81 < ebassi> people asking for a discussion on the list, but not sending email 82 < jjardon> the bugzilla query: 83 https://bugzilla.gnome.org/buglist.cgi?status_whiteboard_type=casesubstring;status_whiteboard=deprecations;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO 84 < jjardon> Decission about GtkHSV, GtkRuler, GtkVruler and GtkHRuler should be taken 85 < jjardon> Also GtkAdjustment signal tadeboro reported 86 < kalikianatoli> I vote for Gtk[HV]Ruler, it's hardly used, and Gimp for example has its own fork and doesn't use it iirc 87 < mclasen> my position on this is that I think it is much more important that we get all the currently deprecated stuff cleaned up 88 < mclasen> we don't have to go overboard deprecating yet more stuff at the last minute 89 < kalikianatoli> I agree in terms of it being not important at all. If somebody does it, fine, if not, doesn't hurt, I think 90 < tadeboro> And about GtkAdjustment::(value-)?changed signals, GtkAdjustment with all of it's (now GSEALed) public files will make one hell of a mess all across the gtk's code. 91 < tadeboro> So I think mclasen's proposal to clean already deprecated stuff first is completelly in place. 92 < jjardon> mclasen, I think onyl gtkprogress deprecated api remains 93 < jjardon> because It's used by GtkProgressBar 94 < jjardon> check with git grep "ifndef GTK_DISABLE_DEPRECATED" in gtk/ 95 < mclasen> jjardon: there's a bunch of deprecated stuff in gdk, I believe 96 < jjardon> mclasen, yeah, I try to work on that, but some stuff is pretty low level. Anyway I submitted a patch to remove GdkColors today 97 < mclasen> ok, cool 98 < jjardon> Tracker bug here fot GDK: https://bugzilla.gnome.org/show_bug.cgi?id=597742 99 < mclasen> looking at the bug list, I would sort rulers, hsv and non-multihead-safe api at the bottom of the priority list 100 < mclasen> tearoff menu items are a somewhat borderline case... pretty much fallen out of use and fashion, but there's a small group of lovers of that feature 101 < mclasen> they do complicated the menu code quite a bit 102 < jjardon> mclasen, ok, but should these be deprecated if someone makes the patches or is not a good idea? 103 < jjardon> rules, I mean 104 < ebassi> mclasen: I'd even settle for an early 3.x deprecation 105 < jjardon> and hsv 106 < mclasen> jjardon: hsv, I just don't care. I don't even remember why we made it public at some point. was there an external user ? 107 < mclasen> seems to be bug 547270 108 < mclasen> so mitch made it public in 2.14 109 < mclasen> is the gimp using it ? 110 < jjardon> mclasen, in modules/color-selector-wheel.c 111 < jjardon> (only) 112 < jjardon> jjardon@rhun:~/git/gimp(master)$ git grep gtk_hsv 113 < jjardon> ChangeLog.pre-2-6: * modules/color-selector-wheel.c: declare gtk_hsv_get_type() if 114 < jjardon> modules/color-selector-wheel.c: wheel->hsv = gtk_hsv_new (); 115 < jjardon> modules/color-selector-wheel.c: gtk_hsv_set_color (GTK_HSV (wheel->hsv), hsv->h, hsv->s, hsv->v); 116 < jjardon> modules/color-selector-wheel.c: gtk_hsv_set_metrics (GTK_HSV (wheel->hsv), size, size / 10); 117 < jjardon> modules/color-selector-wheel.c: gtk_hsv_get_color (hsv, 118 < mclasen> for rulers, do we have any known users ? 119 < mclasen> the gimp has its own right ? since they have all kinds of corner thingies 120 < jjardon> mclasen, not many results in google code search ... 121 < mclasen> gimp has its own, indeed 122 < leio> dia 123 < leio> xsane maybe 124 < tadeboro> claws-main also I think (checking now ...) 125 < tadeboro> claws does use GtkHRuler 126 < mclasen> things like bug 610346 (allow-shrink vs resizable) seem more worthwhile to me 127 < mclasen> cleaning up real sore spots in our api, as opposed to killing innocent widgets 128 < mclasen> maybe we should talk about the adjustment stuff, quickly ? 129 < jjardon> I think tadeboro has something to say here 130 < tristan> 9 131 * tristan excuses 132 < jjardon> This is the GtkAdjustment bug: https://bugzilla.gnome.org/show_bug.cgi?id=619493 133 < tadeboro> I did some experiments with GtkAdjustment lately and making it behave like any other GObject will couse some real pain. 134 < tadeboro> Most obvious thing is, a lot of code uses GSEALed public fileds. 135 < tadeboro> More troubling thing is "delayed emission of signals". A lot of code currently modifies some value and only emits signal later. 136 < tadeboro> One such example is GtkRange with it's various update policies. 137 < mclasen> is that purely for batching of changes ? 138 < tadeboro> One thing is batching, but other (more troublesome) use is making sure that GtkAdjustment is in consistent state when signal is emitted. 139 < tadeboro> For example, if direct accessors are to be used, it will become impossible to prevent emitting two ::changed signals when changing :upper and :lower. 140 < tadeboro> First emission in this case will likely cause some trouble for widgets, because there is a real chance that GtkAdjustment is unusable at the moment of first emission (for example, upper might be less than lower). 141 < ebassi> freeze/thaw pair? 142 < tadeboro> Currently this is possible, but when I proposed a solution based on this couple of days ago, owen was not impressed. 143 < kalikianatoli> there's gtk_adjustment_configure for that 144 < ebassi> true 145 < tadeboro> kalikianatoli, but you need to provide all of the values there and that function is in the end a simple wrapper around g_object_set(). 146 < mclasen> also you can just object_freeze/thaw 147 < ebassi> it's more the signal emission that's messing up 148 < kalikianatoli> tadeboro, yes of course. because it makes a lot of sense if the values depend on each other 149 < mclasen> but the signal emission is tied to property notification 150 < tristan> I was wondering if anyone is ever going to want to subclass the adjustment, and if triggering the notification/setting the values should be tied together so strong at all 151 < mclasen> in fact, adjustment_configure was added when we sealed GtkAdjustment in 2.14 152 < tristan> I was also wondering if keeping the manual notification apis around was justified, if only for the purpose of less integral code... that needs to force an update for some obscure reason 153 < tristan> just some thoughts 154 < jjardon> Bugs to remove GtkArg, GtkWidgetHelpType and GtkForeachData filed 155 < tadeboro> The way I see it after couple of days looking and thinking about it is: 156 < tadeboro> - make accessors replacement for direct field setting and leave signal emission to the owner 157 < tadeboro> - make accessors wrappers for g_object_set() and emit signals together with ::notify signal 158 < tadeboro> I do have some prototype code for second scenario and it works quite nice actually. 159 < tadeboro> As an additional benefit, second method also offers a way to make sure GtkAdjustment is in sane state when property setting is done. 160 < mclasen> that leaves delayed-apply use cases uncovered ? 161 < tadeboro> For example, one can ensure that upper >= lower, lower <= value <= upper - page_size, 0 < page_size < upper - lower ... 162 < mclasen> ie the gtkrange update policy you cited 163 < mclasen> I don't think the last constraint is valid, btw 164 < mclasen> page_size could well be larger than upper - lo wer 165 < tadeboro> Both methods proposed would cover all cases; direct accessors as proposed yesterday would fail to do so. 166 < tadeboro> But does it make sense to have page_size larger than the whole range? 167 < tadeboro> Scrollbars cannot do anything with this scenario, spin button will be fixed to lower value, ... 168 < mclasen> tadeboro: I could see some ui using upper, lower and pagesize to somehow visualize what fraction of a page is currently shwon 169 < mclasen> you are right though, it'll pin the value to lower in any case 170 < mclasen> maybe we should call it good for this week ? 171 < mclasen> my takeaway from the discussion is: a) make orientables flippable b) merge xi2 c) do a release 172 < mclasen> and the application stuff needs another week to simmer 173 < ebassi> sounds good to me 174 < tadeboro> I'll finish my GtkAdjustment patch and offer it for revision and let people decide when they see some code. 175 < ebassi> tadeboro: thanks 176 < mclasen> thanks 177 < jjardon> I'll try to work on remove more deprecated code 178 < mclasen> I'll further sit on Company to get 2.22 building again 179 < mclasen> and to get the region stuff into master as well
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.