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 :)
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.