1 < ebassi> agenda points, as usual, are available here: http://live.gnome.org/GTK+/Meetings
   2 < ebassi> 1. Orientation and default packing options 2. Schedule for next releases 3. miscellaneous
   3 < kris> (i am around but hacking on uni work)
   4 < mclasen> time to start ?
   5 < mclasen> mitch: can you explain the orientation vs defaults issue ?
   6 < mclasen> timj: can you ?
   7 < mitch> when you change a class from abstract to instantiable you effectively create a new widget
   8 < mitch> this new thing can have new defaults
   9 < mclasen> right
  10 < mclasen> the existing subclasses retain their defaults, of course
  11 < mitch> like a GtkBox created with gtk_box_new() has packing defaults of FALSE, FALSE now, not the insane TRUE, TRUE
  12 < mitch> exactly
  13 < mitch> timj things we should also do more like making these new widgets visible by default and stuff
  14 < mitch> timj: your turn
  15 < mitch> i fixed the TRUE,TRUE -> FALSE,FALSE issue in box, but left everything else as-is
  16 < mitch> and kept the bugs open for that purpose
  17 < mclasen> what other defaults are in question ? do we have a list of properties ?
  18 < mitch> no, that remains to be done
  19 < timj> right, basically we should evaluate all properties of the types that GtkBox (and others) derive from and figure what new defaults for those properties are best for the common case. once figured, implement it and only then make the new types instantiatable. i.e. wait until we've figured new defaults, so we don't keep changing property defaults/API for those "new" widget types
  20 < mitch> and i also made the new things committed recently instantiable by default
  21 < mitch> now we are as far a before :)
  22 < mclasen> ok, so who takes the action to assemble a list of properties and child properties on newly-instantiatable classes
  23 < mclasen> and to come up with proposals for sensible defaults 
  24 < mitch> the master of rapicorn i would say, he thought a lot about that ;)
  25 -!- mathias [~mathias@86.56.69.25] has quit [Ex-Chat]
  26  * mclasen can look at creating a list of widgets/properties
  27 < mclasen> anything else on this topic ?
  28 < mitch> not really, except i plan to grep for orientation apis again and deprecate them
  29 < ebassi> ACTION: assemble a list of object+child properties on newly-instantiatable classes for defaults (timj, mitch)
  30 < mclasen> deprecated by GtkOrientable ?
  31 < mitch> yes
  32 < mclasen> ok
  33 < ebassi> ACTION: deprecate widget-specific orientation API (mitch)
  34 < mitch> any opinion about gtkiconview?
  35 < mitch> it's orientation api switched the items' orientation not the widgets
  36 < mitch> switches'
  37 < mitch> -' :)
  38 < mclasen> mitch: thats a bit of a misnomer, I guess
  39 < mitch> mclasen: yes :(
  40 < mitch> should be item_orientation
  41 < mclasen> it is much closer to text-beside-icon than to orientation
  42 < mitch> agreed
  43 < mclasen> not much we can do there, I guess
  44 < mitch> and it would make sense to have it switchable, it would scroll horizontally then
  45 < mitch> indeed
  46 < mitch> i could rename it to item_orientation and deprecate the old api, for clarity
  47 < mitch> opinions?
  48 < kalikiana> mitch: is there a bug?
  49 < mitch> no it's just grossly misnamed
  50 < mitch> or do you mean a filed bug?
  51 < kalikiana> Yes, in bugzilla
  52 < mclasen> well, it uses GtkOrientation, so there is some justification to calling the property "orientation"
  53 < kalikiana> ^^ I would think, as long as the value is a GtkOrientationType, it's hard to rename it?
  54 < leio> I think in the context of GtkOrientation it might make most sense if in case of GtkIconView it determined if icons flow from left to right or top to bottom (having only the left side filled with icons with a few icon entries)
  55 < mclasen> we can't just change what the existing property does, though
  56 < mitch> leio: exactly my thought
  57 < mitch> that's what the api suggests intuitively imho
  58 < mitch> therefore it should be renamed to item_orientation
  59 < mitch> mclasen: no we can't :/
  60 < leio> and GtkOrientation stuff made to control that flow of icons? (fwiw, there's a missing checkbox in port completeness in wxGTK for not supporting left aligned icons)
  61 < leio> ok, I guess not, at least not under the same property binding then..
  62 < mclasen> well, there is no code for making icon views flow left-right, so this discussion is a bit void...
  63 < mclasen> maybe we should move on
  64 < mclasen> wrt. to schedules for releases
  65 < mclasen> I'll do a stable release around the time of the next stable gnome release, and maybe one before
  66 < mclasen> but 
  67 < mclasen> I don't see any urgent reason for one
  68 < mclasen> for an unstable release, it would perhaps make sense to get the orientation business settled before doing one
  69 < leio> if targeting 2.24.2, I can find some time to look into if there's any bug fixes that can be backported in the two weekends between now and then
  70 < mclasen> that would be great
  71 < mitch> ebassi: remind me after the meeting to show you a bug in the recent files stuff please (i try to remember myself)
  72 < ebassi> mitch: sure
  73 < ebassi> ACTION: next stable release in time for GNOME 2.24.2
  74  * mclasen doesn't have the schedule at hand
  75 < ebassi> one gtk-2.90 issue for the "misc" point
  76 < mclasen> do we know when that is ?
  77 < ebassi> raised on #gnome-hackers
  78 < leio> 24th Nov is 2.24.2 tarballs
  79 < ebassi> gnome 2.24.2 should be at the end of the month
  80 < ebassi> leio: thanks
  81 < leio> two weeks, basically
  82 < mclasen> ok, lets target that then
  83 < ebassi> re: gtk-2.90 - what do we do with GtkObject?
  84 < kalikiana> leave it
  85 < ebassi> do we finally bury it?
  86 < kalikiana> nothing to do :)
  87 < mitch> ebassi: having a common base class in your object system does make sense, dunno
  88 < ebassi> kalikiana: what's the reason to leave it, since we are removing all the cruft?
  89 < kalikiana> It is very much in use, and even if you ported "destroy", why would you remove it?
  90 < ebassi> kalikiana: why would you port ::destroy?
  91 < ebassi> to have a signal?
  92 < mitch> exactly
  93 < ebassi> can't we add ::dispose as a GObject signal?
  94 < kalikiana> ebassi: Because it's a fundamental feature ;)
  95 < mitch> dispose has no signal
  96 < kalikiana> It's like saying we don't need g_object_unref :P
  97 < ebassi> wtf
  98 < ebassi> GtkObject is a thin wrapper around GInitiallyUnowned
  99 < mitch> ebassi: if we want to be kindof source-compatible, we need to keep the destry signal
 100 < ebassi> mitch: okay, that's more of a reason :-)
 101 < ebassi> and yet, I still think it should go and we should move ::destroy to Widget
 102 < ebassi> I don't think somebody uses ::destroy on Adjustments
 103 < ebassi> and I don't think anyone subclasses GtkObject
 104 < ebassi> just food for thought - removing cruft and all that
 105 < mclasen> ebassi: we still ship several gtkobject subclasses in gtk
 106 < mclasen> GtkTreeViewColumn, GtkFileFilter, GtkCellRenderer
 107 < mclasen> which are not widgets
 108 < mitch> ebassi: what's the problem with having a common base class?
 109 < mitch> i think all objects in gtk should be gtkobjects
 110 < ebassi> mitch: what's the problem in having InitiallyUnowned as that base class? :-)
 111 < mitch> ebassi: it doesn't have a destroy signal
 112 < mclasen> mitch: we ship several direct gobject subclasses in gtk too
 113 < mitch> ebassi: you can't add gtk specific hacks to it
 114 < mitch> mclasen: a bad thing imho :(
 115 < mclasen> I have another misc point
 116 < ebassi> anyway, I wanted a reason and the one I got is fair enough :-)
 117 < mclasen> I spent some time recently on finishing up the icon-in-entry patch
 118 < mclasen> and would appreciate some review/feedback
 119 < mitch> lovely :)
 120 < mclasen> http://bugzilla.gnome.org/show_bug.cgi?id=85292
 121 < bratsche> mclasen: Thanks for working on that
 122 < mclasen> some issues left, but it mostly works as I expect it to now
 123 < mitch> mclasen: are you still opposed to the text for e.g. seach entries?
 124 < mclasen> you mean the "shadow" thing ?
 125 < mitch> yes, it seems to be a pretty widely used thing, and makes sense imho
 126 < bratsche> Can that be theme-controlled at all yet?
 127 < mitch> bratsche: if we make it so
 128 < mclasen> I still think it is bad in terms of consistency and usability
 129 < mitch> mclasen: tigert and many others seem to disagree
 130 < mclasen> I basically think it is just a case of horror vacui
 131 < mitch> haha
 132 < bratsche> Another thing that needs to be made themeable in this widget is some kind of "invalid" state I think.
 133 < mitch> oh and we need consistent input validation etc :)
 134 < bratsche> Actually, in GtkEntry I think.
 135 < mclasen> we have a 'input validation' bug with a long a varied history...
 136 < mitch> bratsche: um, we are talking about the entry
 137 < bratsche> At work we do a Firefox-like search entry, and if you type something that isn't in the document then it changes colors.. but Firefox changes red, but we didn't want to do that because it may not fit in the theme.  So we just query the tooltip color and it looks kind of sucky, but it fits into the theme.
 138 < mitch> aah
 139 < mclasen> the icon-in-entry support might actually be an important piece in input validation
 140 < mitch> mclasen: yes
 141 < bratsche> So just throwing that out there while this topic is open.
 142 < mitch> mclasen: do you have icons on both sides and are they clickable?
 143 < mclasen> yes
 144 < mitch> rock
 145 < mclasen> also tooltips and drag source
 146 < mitch> hmmm :)
 147 < kris> oh drag source
 148 < kris> that reminds me, i totally need to mail out my proposal for new tree view drag and drop api
 149 < mclasen> a bit of a fringe case, but it was fun to implement
 150 < bratsche> mclasen: Do you want me to merge it into GtkEntry or leave as a separate widget?
 151 < mitch> kris: i lost track of the tap-and-hold front, what's new there?
 152 < mclasen> bratsche: I started investigating that, and there's some work left to do to make GtkSpinButton work 
 153 < bratsche> So just leave it for now?
 154 < mclasen> currently it draws the spin arrows over the secondary icon
 155 < mitch> mclasen: but there is a virtual function now to get the text window size
 156 < mclasen> I think merging it up is the right thing
 157 < bratsche> Oh okay.  Well, I started working on extended attributes for Pango now so I'll just try to finish that up.
 158 < mclasen> mitch: yeah, it probably needs some simple spinbutton fix
 159 < kris> mitch: not much, it depends on tim and my figuring out proper signal handling for it
 160 < kris> mitch: plus animation theme foo
 161 < mitch> ok
 162 < timj> mitch: if you don't like gobject derived types in gtk, maybe you should file a bug (+patch?) to derive those objects from gtkobject instead? that's at least something that could compatibly go into 2.90
 163 < timj> and filing a bug is needed to discuss the matter
 164 < mitch> timj: yes i should
 165 < mclasen> bratsche: so, if you want to look at how to merge the iconentry work up to gtkentry.c, that would be ok with me
 166 < mitch> mclasen: oh you did a separate class? didn't sound so
 167 < bratsche> mclasen: Okay.. until the end of this month my time is very limited, so maybe I'll save that for now.
 168 < timj> kris: ah, making a note to look into your email wrg signal handling again...
 169 < bratsche> Our new app is scheduled to be finished Nov.27 and then I should have more time to hack on gtk stuff again I hope.
 170 < mclasen> mitch: it started out like that in the patch I inherited from bratsche, a port of SexyIconEntry
 171 < mitch> ah
 172 < mitch> i agree it should be in GtkEntry
 173 < bratsche> Yeah, I deliberately left it as a separate widget while I was hacking on it with the intention of merging it all into GtkEntry later.
 174 < kalikiana> Would be pretty neat to just say gtk_entry_set_icon_from_stock and be done :)
 175 < kalikiana> App wise that is
 176 < mclasen> ok, anything else for misc ?
 177 < bratsche> kalikiana: Yeah, that's kind of what I was thinking to do.
 178 < ebassi> looks like we can adjourn the meeting, if nobody has anything else to add
 179  * mclasen adjourns
 180 < mitch> fine
 181 < ebassi> see you again in two weeks; minutes and log will be on the wiki after I have dinner :-)
 182 < mclasen> thanks