*	mclasen apologizes
*	mclasen wonders if the meeting takes place somewhere else
*	mclasen would like to discuss "2.16 for gnome 2.26"
<tristan>	erm, are we missing people ?
<tristan>	mclasen, if you release this early 2.16, will it include buildable menus ?
<mclasen>	we are a little short on people who have something to say, it seems...
<mclasen>	It depends on what people want and what is good to be shipped before the end of the year, I think
<mclasen>	will buildable menus allow you to have gtkbuilder support in glade ?
<mclasen>	that would be a pretty convincing argument for me
<tristan>	well *I* want to release a fully featured glade stable for gnome 2.26
<tristan>	yes
<tristan>	it will allow conversions of any glade files, that work
<mclasen>	sounds like a nobrainer to me
<tristan>	and if I get the action property in too, that will just be awesome
<mclasen>	not so sure about that one
<tristan>	:)
<mclasen>	well, the action property is certainly easier than a fullblown Activatable interface
<tristan>	hmmm, last meeting we discussed the patch, I got the impression it was all around agreed that the iface was a better approach
<tristan>	so I hacked all night and cleaned out gtkaction.c
<mitch>	+1
<tristan>	mitch, did you see the patch finally ?
<mclasen>	mitch ?
<mitch>	i'm all for the interface approach too, but i was too busy and sick today to finally look at the patch
<tristan>	I could try to sum up what it does in a few sentences
<tristan>	It makes a property "related-action" on the iface
<tristan>	(and a "use-action-appearance" too)
<tristan>	when gtk_activatable_set_related_action () is called
<mitch>	why "related"?
<tristan>	the property changes and the iface implementor must hook onto the action
<tristan>	mitch, filechooseractions
<tristan>	thats why
<mclasen>	mitch: we already have an "action" property
<mitch>	oh ok
<mclasen>	and gobject doesn't handle name clashes very gracefully
<mclasen>	or at all...
<tristan>	filechooser *uses* the GtkAction property :)
<tristan>	anyway, the activatable hooks onto notify
<tristan>	and calls gtk_activatable_update() from there
<tristan>	I added a vfunc so that child implementations could be graceful
<tristan>	one notify, one override in the implementing class
<mitch>	so the activatable approach makes the widgets true models instead of being configured from the outside?
<mclasen>	I'm still worried about the scalability of this many notfy handers...have you done a before-after comparison with the gimp ?
<tristan>	umm, one last thing... also the iface implementors call gtk_action_activate()
<mitch>	perhaps that method should be "update_action"?
<tristan>	where gtkaction would have registered a signal
<tristan>	activatable->update seems pretty implied its an action if you ask me :-/
<tristan>	but
<tristan>	if you wish
<mitch>	i don't see how "activatable" implies "action" at all actually ;)
<mitch>	a button is activatable
<tristan>	its the activatable that updates
<tristan>	not the action
<mitch>	oh
<mitch>	err yes sure
<tristan>	the activatable gets notified and calls itself
<tristan>	for subclasses to implement it cleanly
<tristan>	for instance, togglebutton is interested in the toggle actions active state
<mitch>	i wonder if it wouldn't make more sense to have some "set_action" methos and have the proxies connect themselves?
<tristan>	but not button
<mitch>	or am i on crak?
<mitch>	+c
<tristan>	the proxies do connect themselves with my patch
<tristan>	and connect_proxy() is deprecated in favor of gtk_activatable_set_related_action()
<tristan>	but as mclasen said, I didnt test this with gimp
<mitch>	hmm
<tristan>	and see if I could find performance differences
<tristan>	but it seems to me to be the right thing to do
<mitch>	so again, a GtkButton  would not be an activatable?
<tristan>	remember that action property changes are not a regular occurance, they happen sometimes
<tristan>	yes it would be activatable
<mitch>	maybe i should just sleep as planned and ask that stuff on daytime ;)
<mclasen>	mitch: you can connect buttons to actions currently
<tristan>	and by virtue of it being activatable, so would togglebutton
<mitch>	yes you can, that's why i got confused
<mclasen>	so if the new approach allows only to connect activatables, they better be
<tristan>	I was interested to find out that expanders can be seen as a toggle state
<mitch>	so how would e.g. a GtkToggleable interface fit in there?
<tristan>	and they have an activate signal that toggles it
<tristan>	mitch, my patch doesnt do that, but ... I have some ideas
<mitch>	would it have GtkActivatable as prerequisite and somehow hook into set_related_action() ?
<tristan>	one is type safety
<tristan>	it could override the type of the action property
<mitch>	yes for example
<tristan>	and serve as an all purpose toggle
<tristan>	and be resposable for the toggled signal
<tristan>	etc etc
<tristan>	but
<tristan>	I would rather see that as out of scope for this patch
<tristan>	and keep it simple
<mitch>	but this patch should not block that other thing
<tristan>	I think the toggles should be activatable by prerequisite though
<mitch>	also not a GtkRadio interface
<tristan>	exactly it should not
<mitch>	yes i agree
<tristan>	it was intended to be simple and scalable
<tristan>	one thing is a little weird
<tristan>	with recent chooser actions
<tristan>	they call functions on their proxies
<mitch>	so what i suggest it *trying* how a Gtktoggleable interface works on top of that, but leave it out of the current patch
<tristan>	and set sort func etc
<mclasen>	so, how do we proceed on this ? mitch reviews the patch and tristan does scalability tests with the Gimp ?
<tristan>	thats the *only* reason gtkaction still maintains a proxy list
<mitch>	i think that's best
<tristan>	and needs a connect_proxy
<mitch>	mclasen: i can't promise anything before christmas though, super busy mode
*	mclasen too
<mclasen>	tristan: oh, that proxy list was one of my scalability concerns, too
<tristan>	mclasen, its still maintained, and was kept for compatability reasons
<tristan>	people want to list the proxies etc
<mclasen>	so, can I get some general feedback on the "2.16 in 2.26" idea ?
<tristan>	I dont see how it can be removed, and its useful for weird ones, like recentchoosers
<mclasen>	yeah, probably
<mclasen>	is any of the stuff thats currently in trunk not baked enough to go out in a 2.15 release in January ?
<tristan>	ummm, you cant release those margined labels ;-)
<tristan>	heh
<mclasen>	what labels ?
<tristan>	sorry I mean menus
<tristan>	left margin in menus, notably from combos
<mclasen>	are you just talking about comboboxes, or do you disagree with margins in general ?
<tristan>	no you need margins for you menu items that have icons dont you ?
<tristan>	and check items and stuff
<tristan>	but not when none of the menu items have anything
<tristan>	right ?
<mclasen>	the idea of the margins change was to always have a consistent margin, regardless if icons are presnt or not
<tristan>	sorry, was that an intended feature ?
<tristan>	hrm
<mclasen>	the margin you showed in your combobox screenshot looked excessive though
<tristan>	well, in combos surely excessive
<tristan>	yeah
<tristan>	I dont know if in menus it should be default behaviour
<tristan>	well, if you expose a property there, I can easily let glade configure it... as usual...
<tristan>	but yeah actually, the combos are chopping out some text with that margin
<tristan>	my combo resizes to fit the menu width, and then the marin pushes my text off the menuitem
<mclasen>	yeah
<mclasen>	thats just a bug
<mclasen>	mitch: did you do the progress entry work ?
<mitch>	yes there is also stuff left to do :(
<mclasen>	right
<tristan>	oh yeah, that one thing about actions... is that people like actions with menus... and well... uimanager... *cough* 
<tristan>	anyway
<mclasen>	the selection vs progress color clash may be hard to fix without introducing an extra color for the progress
<mitch>	tristan: you will find a complex example in gimp for uimanager and menus ;)
<tristan>	mitch, man, maybe we should talk about uimanagers in another meeting
<mclasen>	yeah, any major action rework needs to survive the gimp test
<mclasen>	mitch: what about the unfinished flipping work
<mclasen>	can that go out in a 2.15 release as is ?
<tristan>	hahaha, I want to see the gimp work with actions and menus and without uimanagers !
<tristan>	grrrr
<mitch>	mclasen: i can commit the outstanding patch
<tristan>	ok I'll run gimp
<mclasen>	mitch: but keeping everything abstract ?
<mclasen>	I guess thats fine
<mitch>	mclasen: eek, indeed
<mclasen>	it just makes it less useful than it could be
<mitch>	needs more work indeed
<mitch>	will tackel that after xmas
<mitch>	tackle
<mclasen>	ok
<mclasen>	so, I assume from this discussion that there is no major disagreement over doing an early 2.16
<mitch>	need sleep now
*	mitch <- sick
<mitch>	nite all
<mclasen>	gute besserung
*	mitch is now known as miZzz
<miZzz>	danke :)
<mclasen>	lets close the meeting then, I guess
<mclasen>	last meeting of 2008, probably
<mclasen>	see you all in 2009
<miZzz>	happy new year ;)
<miZzz>	Zzzz...
<mclasen>	I'll send some mail about 2.16 plan changes to gtk-devel
<Lethalman>	thanks to everyone for considering the bug :)