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 [~firstname.lastname@example.org] 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
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.