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