< ebassi> agenda points, as usual, are available here: http://live.gnome.org/GTK+/Meetings < ebassi> 1. Orientation and default packing options 2. Schedule for next releases 3. miscellaneous < kris> (i am around but hacking on uni work) < mclasen> time to start ? < mclasen> mitch: can you explain the orientation vs defaults issue ? < mclasen> timj: can you ? < mitch> when you change a class from abstract to instantiable you effectively create a new widget < mitch> this new thing can have new defaults < mclasen> right < mclasen> the existing subclasses retain their defaults, of course < mitch> like a GtkBox created with gtk_box_new() has packing defaults of FALSE, FALSE now, not the insane TRUE, TRUE < mitch> exactly < mitch> timj things we should also do more like making these new widgets visible by default and stuff < mitch> timj: your turn < mitch> i fixed the TRUE,TRUE -> FALSE,FALSE issue in box, but left everything else as-is < mitch> and kept the bugs open for that purpose < mclasen> what other defaults are in question ? do we have a list of properties ? < mitch> no, that remains to be done < 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 < mitch> and i also made the new things committed recently instantiable by default < mitch> now we are as far a before :) < mclasen> ok, so who takes the action to assemble a list of properties and child properties on newly-instantiatable classes < mclasen> and to come up with proposals for sensible defaults < mitch> the master of rapicorn i would say, he thought a lot about that ;) -!- mathias [~mathias@86.56.69.25] has quit [Ex-Chat] * mclasen can look at creating a list of widgets/properties < mclasen> anything else on this topic ? < mitch> not really, except i plan to grep for orientation apis again and deprecate them < ebassi> ACTION: assemble a list of object+child properties on newly-instantiatable classes for defaults (timj, mitch) < mclasen> deprecated by GtkOrientable ? < mitch> yes < mclasen> ok < ebassi> ACTION: deprecate widget-specific orientation API (mitch) < mitch> any opinion about gtkiconview? < mitch> it's orientation api switched the items' orientation not the widgets < mitch> switches' < mitch> -' :) < mclasen> mitch: thats a bit of a misnomer, I guess < mitch> mclasen: yes :( < mitch> should be item_orientation < mclasen> it is much closer to text-beside-icon than to orientation < mitch> agreed < mclasen> not much we can do there, I guess < mitch> and it would make sense to have it switchable, it would scroll horizontally then < mitch> indeed < mitch> i could rename it to item_orientation and deprecate the old api, for clarity < mitch> opinions? < kalikiana> mitch: is there a bug? < mitch> no it's just grossly misnamed < mitch> or do you mean a filed bug? < kalikiana> Yes, in bugzilla < mclasen> well, it uses GtkOrientation, so there is some justification to calling the property "orientation" < kalikiana> ^^ I would think, as long as the value is a GtkOrientationType, it's hard to rename it? < 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) < mclasen> we can't just change what the existing property does, though < mitch> leio: exactly my thought < mitch> that's what the api suggests intuitively imho < mitch> therefore it should be renamed to item_orientation < mitch> mclasen: no we can't :/ < 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) < leio> ok, I guess not, at least not under the same property binding then.. < mclasen> well, there is no code for making icon views flow left-right, so this discussion is a bit void... < mclasen> maybe we should move on < mclasen> wrt. to schedules for releases < mclasen> I'll do a stable release around the time of the next stable gnome release, and maybe one before < mclasen> but < mclasen> I don't see any urgent reason for one < mclasen> for an unstable release, it would perhaps make sense to get the orientation business settled before doing one < 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 < mclasen> that would be great < mitch> ebassi: remind me after the meeting to show you a bug in the recent files stuff please (i try to remember myself) < ebassi> mitch: sure < ebassi> ACTION: next stable release in time for GNOME 2.24.2 * mclasen doesn't have the schedule at hand < ebassi> one gtk-2.90 issue for the "misc" point < mclasen> do we know when that is ? < ebassi> raised on #gnome-hackers < leio> 24th Nov is 2.24.2 tarballs < ebassi> gnome 2.24.2 should be at the end of the month < ebassi> leio: thanks < leio> two weeks, basically < mclasen> ok, lets target that then < ebassi> re: gtk-2.90 - what do we do with GtkObject? < kalikiana> leave it < ebassi> do we finally bury it? < kalikiana> nothing to do :) < mitch> ebassi: having a common base class in your object system does make sense, dunno < ebassi> kalikiana: what's the reason to leave it, since we are removing all the cruft? < kalikiana> It is very much in use, and even if you ported "destroy", why would you remove it? < ebassi> kalikiana: why would you port ::destroy? < ebassi> to have a signal? < mitch> exactly < ebassi> can't we add ::dispose as a GObject signal? < kalikiana> ebassi: Because it's a fundamental feature ;) < mitch> dispose has no signal < kalikiana> It's like saying we don't need g_object_unref :P < ebassi> wtf < ebassi> GtkObject is a thin wrapper around GInitiallyUnowned < mitch> ebassi: if we want to be kindof source-compatible, we need to keep the destry signal < ebassi> mitch: okay, that's more of a reason :-) < ebassi> and yet, I still think it should go and we should move ::destroy to Widget < ebassi> I don't think somebody uses ::destroy on Adjustments < ebassi> and I don't think anyone subclasses GtkObject < ebassi> just food for thought - removing cruft and all that < mclasen> ebassi: we still ship several gtkobject subclasses in gtk < mclasen> GtkTreeViewColumn, GtkFileFilter, GtkCellRenderer < mclasen> which are not widgets < mitch> ebassi: what's the problem with having a common base class? < mitch> i think all objects in gtk should be gtkobjects < ebassi> mitch: what's the problem in having InitiallyUnowned as that base class? :-) < mitch> ebassi: it doesn't have a destroy signal < mclasen> mitch: we ship several direct gobject subclasses in gtk too < mitch> ebassi: you can't add gtk specific hacks to it < mitch> mclasen: a bad thing imho :( < mclasen> I have another misc point < ebassi> anyway, I wanted a reason and the one I got is fair enough :-) < mclasen> I spent some time recently on finishing up the icon-in-entry patch < mclasen> and would appreciate some review/feedback < mitch> lovely :) < mclasen> http://bugzilla.gnome.org/show_bug.cgi?id=85292 < bratsche> mclasen: Thanks for working on that < mclasen> some issues left, but it mostly works as I expect it to now < mitch> mclasen: are you still opposed to the text for e.g. seach entries? < mclasen> you mean the "shadow" thing ? < mitch> yes, it seems to be a pretty widely used thing, and makes sense imho < bratsche> Can that be theme-controlled at all yet? < mitch> bratsche: if we make it so < mclasen> I still think it is bad in terms of consistency and usability < mitch> mclasen: tigert and many others seem to disagree < mclasen> I basically think it is just a case of horror vacui < mitch> haha < bratsche> Another thing that needs to be made themeable in this widget is some kind of "invalid" state I think. < mitch> oh and we need consistent input validation etc :) < bratsche> Actually, in GtkEntry I think. < mclasen> we have a 'input validation' bug with a long a varied history... < mitch> bratsche: um, we are talking about the entry < 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. < mitch> aah < mclasen> the icon-in-entry support might actually be an important piece in input validation < mitch> mclasen: yes < bratsche> So just throwing that out there while this topic is open. < mitch> mclasen: do you have icons on both sides and are they clickable? < mclasen> yes < mitch> rock < mclasen> also tooltips and drag source < mitch> hmmm :) < kris> oh drag source < kris> that reminds me, i totally need to mail out my proposal for new tree view drag and drop api < mclasen> a bit of a fringe case, but it was fun to implement < bratsche> mclasen: Do you want me to merge it into GtkEntry or leave as a separate widget? < mitch> kris: i lost track of the tap-and-hold front, what's new there? < mclasen> bratsche: I started investigating that, and there's some work left to do to make GtkSpinButton work < bratsche> So just leave it for now? < mclasen> currently it draws the spin arrows over the secondary icon < mitch> mclasen: but there is a virtual function now to get the text window size < mclasen> I think merging it up is the right thing < bratsche> Oh okay. Well, I started working on extended attributes for Pango now so I'll just try to finish that up. < mclasen> mitch: yeah, it probably needs some simple spinbutton fix < kris> mitch: not much, it depends on tim and my figuring out proper signal handling for it < kris> mitch: plus animation theme foo < mitch> ok < 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 < timj> and filing a bug is needed to discuss the matter < mitch> timj: yes i should < 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 < mitch> mclasen: oh you did a separate class? didn't sound so < bratsche> mclasen: Okay.. until the end of this month my time is very limited, so maybe I'll save that for now. < timj> kris: ah, making a note to look into your email wrg signal handling again... < 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. < mclasen> mitch: it started out like that in the patch I inherited from bratsche, a port of SexyIconEntry < mitch> ah < mitch> i agree it should be in GtkEntry < 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. < kalikiana> Would be pretty neat to just say gtk_entry_set_icon_from_stock and be done :) < kalikiana> App wise that is < mclasen> ok, anything else for misc ? < bratsche> kalikiana: Yeah, that's kind of what I was thinking to do. < ebassi> looks like we can adjourn the meeting, if nobody has anything else to add * mclasen adjourns < mitch> fine < ebassi> see you again in two weeks; minutes and log will be on the wiki after I have dinner :-) < mclasen> thanks