1 *	mclasen apologizes
   2 *	mclasen wonders if the meeting takes place somewhere else
   3 *	mclasen would like to discuss "2.16 for gnome 2.26"
   4 <tristan>	erm, are we missing people ?
   5 <tristan>	mclasen, if you release this early 2.16, will it include buildable menus ?
   6 <mclasen>	we are a little short on people who have something to say, it seems...
   7 <mclasen>	It depends on what people want and what is good to be shipped before the end of the year, I think
   8 <mclasen>	will buildable menus allow you to have gtkbuilder support in glade ?
   9 <mclasen>	that would be a pretty convincing argument for me
  10 <tristan>	well *I* want to release a fully featured glade stable for gnome 2.26
  11 <tristan>	yes
  12 <tristan>	it will allow conversions of any glade files, that work
  13 <mclasen>	sounds like a nobrainer to me
  14 <tristan>	and if I get the action property in too, that will just be awesome
  15 <mclasen>	not so sure about that one
  16 <tristan>	:)
  17 <mclasen>	well, the action property is certainly easier than a fullblown Activatable interface
  18 <tristan>	hmmm, last meeting we discussed the patch, I got the impression it was all around agreed that the iface was a better approach
  19 <tristan>	so I hacked all night and cleaned out gtkaction.c
  20 <mitch>	+1
  21 <tristan>	mitch, did you see the patch finally ?
  22 <mclasen>	mitch ?
  23 <mitch>	i'm all for the interface approach too, but i was too busy and sick today to finally look at the patch
  24 <tristan>	I could try to sum up what it does in a few sentences
  25 <tristan>	It makes a property "related-action" on the iface
  26 <tristan>	(and a "use-action-appearance" too)
  27 <tristan>	when gtk_activatable_set_related_action () is called
  28 <mitch>	why "related"?
  29 <tristan>	the property changes and the iface implementor must hook onto the action
  30 <tristan>	mitch, filechooseractions
  31 <tristan>	thats why
  32 <mclasen>	mitch: we already have an "action" property
  33 <mitch>	oh ok
  34 <mclasen>	and gobject doesn't handle name clashes very gracefully
  35 <mclasen>	or at all...
  36 <tristan>	filechooser *uses* the GtkAction property :)
  37 <tristan>	anyway, the activatable hooks onto notify
  38 <tristan>	and calls gtk_activatable_update() from there
  39 <tristan>	I added a vfunc so that child implementations could be graceful
  40 <tristan>	one notify, one override in the implementing class
  41 <mitch>	so the activatable approach makes the widgets true models instead of being configured from the outside?
  42 <mclasen>	I'm still worried about the scalability of this many notfy handers...have you done a before-after comparison with the gimp ?
  43 <tristan>	umm, one last thing... also the iface implementors call gtk_action_activate()
  44 <mitch>	perhaps that method should be "update_action"?
  45 <tristan>	where gtkaction would have registered a signal
  46 <tristan>	activatable->update seems pretty implied its an action if you ask me :-/
  47 <tristan>	but
  48 <tristan>	if you wish
  49 <mitch>	i don't see how "activatable" implies "action" at all actually ;)
  50 <mitch>	a button is activatable
  51 <tristan>	its the activatable that updates
  52 <tristan>	not the action
  53 <mitch>	oh
  54 <mitch>	err yes sure
  55 <tristan>	the activatable gets notified and calls itself
  56 <tristan>	for subclasses to implement it cleanly
  57 <tristan>	for instance, togglebutton is interested in the toggle actions active state
  58 <mitch>	i wonder if it wouldn't make more sense to have some "set_action" methos and have the proxies connect themselves?
  59 <tristan>	but not button
  60 <mitch>	or am i on crak?
  61 <mitch>	+c
  62 <tristan>	the proxies do connect themselves with my patch
  63 <tristan>	and connect_proxy() is deprecated in favor of gtk_activatable_set_related_action()
  64 <tristan>	but as mclasen said, I didnt test this with gimp
  65 <mitch>	hmm
  66 <tristan>	and see if I could find performance differences
  67 <tristan>	but it seems to me to be the right thing to do
  68 <mitch>	so again, a GtkButton  would not be an activatable?
  69 <tristan>	remember that action property changes are not a regular occurance, they happen sometimes
  70 <tristan>	yes it would be activatable
  71 <mitch>	maybe i should just sleep as planned and ask that stuff on daytime ;)
  72 <mclasen>	mitch: you can connect buttons to actions currently
  73 <tristan>	and by virtue of it being activatable, so would togglebutton
  74 <mitch>	yes you can, that's why i got confused
  75 <mclasen>	so if the new approach allows only to connect activatables, they better be
  76 <tristan>	I was interested to find out that expanders can be seen as a toggle state
  77 <mitch>	so how would e.g. a GtkToggleable interface fit in there?
  78 <tristan>	and they have an activate signal that toggles it
  79 <tristan>	mitch, my patch doesnt do that, but ... I have some ideas
  80 <mitch>	would it have GtkActivatable as prerequisite and somehow hook into set_related_action() ?
  81 <tristan>	one is type safety
  82 <tristan>	it could override the type of the action property
  83 <mitch>	yes for example
  84 <tristan>	and serve as an all purpose toggle
  85 <tristan>	and be resposable for the toggled signal
  86 <tristan>	etc etc
  87 <tristan>	but
  88 <tristan>	I would rather see that as out of scope for this patch
  89 <tristan>	and keep it simple
  90 <mitch>	but this patch should not block that other thing
  91 <tristan>	I think the toggles should be activatable by prerequisite though
  92 <mitch>	also not a GtkRadio interface
  93 <tristan>	exactly it should not
  94 <mitch>	yes i agree
  95 <tristan>	it was intended to be simple and scalable
  96 <tristan>	one thing is a little weird
  97 <tristan>	with recent chooser actions
  98 <tristan>	they call functions on their proxies
  99 <mitch>	so what i suggest it *trying* how a Gtktoggleable interface works on top of that, but leave it out of the current patch
 100 <tristan>	and set sort func etc
 101 <mclasen>	so, how do we proceed on this ? mitch reviews the patch and tristan does scalability tests with the Gimp ?
 102 <tristan>	thats the *only* reason gtkaction still maintains a proxy list
 103 <mitch>	i think that's best
 104 <tristan>	and needs a connect_proxy
 105 <mitch>	mclasen: i can't promise anything before christmas though, super busy mode
 106 *	mclasen too
 107 <mclasen>	tristan: oh, that proxy list was one of my scalability concerns, too
 108 <tristan>	mclasen, its still maintained, and was kept for compatability reasons
 109 <tristan>	people want to list the proxies etc
 110 <mclasen>	so, can I get some general feedback on the "2.16 in 2.26" idea ?
 111 <tristan>	I dont see how it can be removed, and its useful for weird ones, like recentchoosers
 112 <mclasen>	yeah, probably
 113 <mclasen>	is any of the stuff thats currently in trunk not baked enough to go out in a 2.15 release in January ?
 114 <tristan>	ummm, you cant release those margined labels ;-)
 115 <tristan>	heh
 116 <mclasen>	what labels ?
 117 <tristan>	sorry I mean menus
 118 <tristan>	left margin in menus, notably from combos
 119 <mclasen>	are you just talking about comboboxes, or do you disagree with margins in general ?
 120 <tristan>	no you need margins for you menu items that have icons dont you ?
 121 <tristan>	and check items and stuff
 122 <tristan>	but not when none of the menu items have anything
 123 <tristan>	right ?
 124 <mclasen>	the idea of the margins change was to always have a consistent margin, regardless if icons are presnt or not
 125 <tristan>	sorry, was that an intended feature ?
 126 <tristan>	hrm
 127 <mclasen>	the margin you showed in your combobox screenshot looked excessive though
 128 <tristan>	well, in combos surely excessive
 129 <tristan>	yeah
 130 <tristan>	I dont know if in menus it should be default behaviour
 131 <tristan>	well, if you expose a property there, I can easily let glade configure it... as usual...
 132 <tristan>	but yeah actually, the combos are chopping out some text with that margin
 133 <tristan>	my combo resizes to fit the menu width, and then the marin pushes my text off the menuitem
 134 <mclasen>	yeah
 135 <mclasen>	thats just a bug
 136 <mclasen>	mitch: did you do the progress entry work ?
 137 <mitch>	yes there is also stuff left to do :(
 138 <mclasen>	right
 139 <tristan>	oh yeah, that one thing about actions... is that people like actions with menus... and well... uimanager... *cough* 
 140 <tristan>	anyway
 141 <mclasen>	the selection vs progress color clash may be hard to fix without introducing an extra color for the progress
 142 <mitch>	tristan: you will find a complex example in gimp for uimanager and menus ;)
 143 <tristan>	mitch, man, maybe we should talk about uimanagers in another meeting
 144 <mclasen>	yeah, any major action rework needs to survive the gimp test
 145 <mclasen>	mitch: what about the unfinished flipping work
 146 <mclasen>	can that go out in a 2.15 release as is ?
 147 <tristan>	hahaha, I want to see the gimp work with actions and menus and without uimanagers !
 148 <tristan>	grrrr
 149 <mitch>	mclasen: i can commit the outstanding patch
 150 <tristan>	ok I'll run gimp
 151 <mclasen>	mitch: but keeping everything abstract ?
 152 <mclasen>	I guess thats fine
 153 <mitch>	mclasen: eek, indeed
 154 <mclasen>	it just makes it less useful than it could be
 155 <mitch>	needs more work indeed
 156 <mitch>	will tackel that after xmas
 157 <mitch>	tackle
 158 <mclasen>	ok
 159 <mclasen>	so, I assume from this discussion that there is no major disagreement over doing an early 2.16
 160 <mitch>	need sleep now
 161 *	mitch <- sick
 162 <mitch>	nite all
 163 <mclasen>	gute besserung
 164 *	mitch is now known as miZzz
 165 <miZzz>	danke :)
 166 <mclasen>	lets close the meeting then, I guess
 167 <mclasen>	last meeting of 2008, probably
 168 <mclasen>	see you all in 2009
 169 <miZzz>	happy new year ;)
 170 <miZzz>	Zzzz...
 171 <mclasen>	I'll send some mail about 2.16 plan changes to gtk-devel
 172 <Lethalman>	thanks to everyone for considering the bug :)