1 < ebassi> so: agenda for tonight 2 < jjardon> mclasen, no progress I think. The most important is fix this bug abot deprecating widget flags: https://bugzilla.gnome.org/show_bug.cgi?id=69872 3 < ebassi> 1. bug 600141 (desrt) 4 < ebassi> 2. libmodel 5 < ebassi> 3. gvariant merge 6 < ebassi> 4. text-buffer 3.0 request (jessevdk) 7 < ebassi> 5. misc 8 < desrt> shall i start? 9 < ebassi> desrt: knock yourself out :-) 10 < desrt> ok. 11 < desrt> dbus links against libpthread. there's very little way for us to stop that 12 < desrt> glib doesn't do that. nor does gio. 13 < desrt> doing a dlopen() of a pthread-linked library into a non-pthread linked application is a no-no 14 < desrt> it happens to work fairly OK on linux, but it's not officially supported and it breaks (for example) gdb 15 < desrt> the easy fix here is to link gio against libpthread 16 < tml> ah, is that what causes that mysterious gdb message (I can't recall exacty what it says now) on linux 17 < desrt> which is slightly evil because, officially, our knowledge that gio opens libgvfs which depends on libdbus which depends on libpthread is an implementation detail 18 < desrt> but at the same time, it's unlikely to do any harm 19 < desrt> tml: yes. probably. 20 < tml> could we at the same time then make g_thread_init(NULL) be implicitly called always? would that make any sense? instead of this "you have to call this before anything else if at all, but actually it works even if you don't, at least most of the times" 21 < desrt> see also: Company mentioned for that 3.0 we should get rid of libgthread and remove the ability to run in threads-disabled mode 22 < desrt> tml: that call is in the gthread library which *is* linked against libpthread 23 < desrt> the problem here happens if you put gio-2.0 in your pkg-config libs but not gthread-2.0 24 < desrt> putting gthread into your pkgconfig is good enough to solve the problem, even if you *don't* g_thread_init 25 < ebassi> desrt: should gtk-devel-list be poked about this issue? 26 < desrt> ok. i can do that. 27 < ebassi> just to avoid bugzilla discussions 28 < desrt> i like those. it's the ML discussions i like to avoid :) 29 < ebassi> desrt: heh, I know 30 < desrt> anyway. if nobody has anything to say about that then i'll poke the ML 31 * mclasen just wants to avoid any discussions, on a day like this... 32 < Company> desrt: please make it say "we are going to make it depend on gthread-2.0 unless someone complains" instead of asking 33 < desrt> Company: i think that's the wrong solution 34 < desrt> Company: i prefer just adding -pthread to the link flags 35 < desrt> smaller hammer is better :) 36 < desrt> ok. #2. 37 < Company> you do the configure fixes on $STUPID_OS then 38 < desrt> i did a 0.2 release of the data model API that looks something like what i want to see in glib 39 < desrt> http://live.gnome.org/Model 40 < desrt> unless anyone has really tried it out, i doubt we will have too much to talk about 41 * mclasen drops out 42 < desrt> and in mclasen's interests i'm OK to limit the discussion to "look at this. we can talk later" 43 < desrt> ebassi: did you want to mention anything? 44 < Company> i looked at it, and it looked like bloating everything into an object so you can emit signals 45 < desrt> actually, the string/bool/float/int objects don't even have signals on them at all 46 < behdad> humm 47 < behdad> what's the deal about gthread? 48 < kris> I am wondering if there is any relation between this and the iterator and data structure stuff that never made it into glib 49 < desrt> they're immutable 50 < desrt> kris: i suppose i could make this stuff implement the iterator interface... 51 < desrt> it doesn't presently do that ,though 52 < Company> desrt: i fail to see why we need this whole api 53 < kris> Point being, are there any reasons why the iterator API never made it into GLib 54 < desrt> because people really hate writing GtkTreeModels 55 < kris> is that for example what Company said: why do we need this API? 56 < kris> do these reasons also apply to model? 57 < desrt> this isn't really a new interface for existing data structures 58 < kris> the iterator/collections stuff was also brought up for simplying doing tree models 59 < desrt> it's designed to model data from [whatever] and changes to that data 60 < desrt> tbh, i didn't really follow the discussion on that one 61 < danw> behdad: https://bugzilla.gnome.org/show_bug.cgi?id=600141 62 < desrt> anyway. this is something that was used in a project that codethink was working on 63 < behdad> danw: thanks 64 < kris> To me it feels like that there should be a solid discussion whether or not Glib should be a home to all these new and hip data structures; 65 < kris> but correct me if I am wrong 66 < kris> I take a neutral position here 67 < desrt> kris: i think that's a good discussion to have 68 < desrt> kris: my attitude is along the lines of "anything that's not directly related to putting stuff on the screen should be in glib" 69 < desrt> i'd prefer if things like GtkTreeModel in the first place were in glib 70 < kris> because to me it makes sense that if people want to see model go in, we also want to have iterator and collectionst stuff 71 < desrt> even GtkBuilder should have been GBuilder, i think 72 * mclasen has a less than neutral position here 73 < desrt> so my attitude there is 'yes' 74 < Company> and we all rejoice that it's not GtkStreamer! 75 < kris> GtkTreeModel should not have been in Glib because it was designed as a data model for GtkTreeView; nothing more nothing less 76 < Company> but it needs to be merged into glib soon 77 < mclasen> we don't want to balloon glib into 'everything that didn't fit into gtk' 78 < mclasen> and 'generic models' are at least somewhat of an oxymoron 79 < mclasen> because, as kris says, you usually want them to model something specific or be modeled for a specific purpose 80 < kris> not necessarily 81 < kris> but GtkTreeModel was specific for GtkTreeView 82 < desrt> it's amazing how much you can fit into lists and dictionaries 83 < desrt> so then there's another question: 84 < desrt> if all this stuff doesn't go into glib, then where does it go? 85 < kris> maybe a gdatastuff? 86 < kris> with a model, iterator, collections api 87 * desrt was under the impression that we were currently in the middle of some 'riddley' project ot get rid of extra libs and merge functionality into gtk/glib 88 < mclasen> the thing is, 'all this stuff' that people want to shoehorn into glib and/or gtk 89 < mclasen> usually doesn't come with maintainers attached 90 < mclasen> or at least, they don't stick... 91 < desrt> right. very fair argument there. 92 < desrt> and of course i can say "i'll maintain it, of course" 93 < desrt> but that's what they all say :p 94 < Company> i'd like if instead of stuffing everyting into glib, we could have proven libs first 95 < Company> kinda like libegg - something that people actually use 96 < ebassi> gstagingarea 97 < kris> we already have all this dbus stuff going into glib this cycle don't we? 98 < desrt> yes 99 < jjardon> Company, as desrt said, IMHO the actual objective is kill libegg 100 < desrt> i'm willing to let libmodel simmer as a separate library for the time being 101 < Company> jjardon: currently we do that by repeating all the errors of libgnome 102 < desrt> there's no super-compelling reason to merge it 103 < Company> jjardon: and that doesn't help 104 < desrt> and nothing to prevent people from writing code that uses it in its current state 105 < jjardon> There are feature branches nowadays ... 106 < desrt> i'm not proposing for merge now, else there would be a feature branch 107 < desrt> it's more like "i think this is cool. feedback appreciated. maybe we should have something like this some time." 108 < Company> jjardon: but noone bases her code on a feature branch of glib 109 < jjardon> Company, good point 110 < Company> we should move on a bit :) 111 < desrt> ya 112 < desrt> this is turning into a metadiscussion 113 < Company> <ebassi> 3. gvariant merge 114 < desrt> we had a ML discussion started by mclasen on this one 115 < desrt> but so far he's the only one who has made review comments 116 < desrt> i replied to the message proposing some changes that could make things better, but nobody bit 117 < mclasen> I promised you code review too, and failed to provide it... 118 < ebassi> desrt: I'll try to comment and review as well :-) 119 < desrt> it would really be better if this wasn't all on one person to review/comment 120 < desrt> davidz: i'd appreciate stuff from you as well :) 121 < davidz> desrt: roger that 122 < desrt> ok. that's all for now from me :) 123 < desrt> jessevdk? 124 < jessevdk> we are currently experimenting with implementing split view mode for gedit 125 < jjardon> FYI: There are links to GVariant branch and bug in http://live.gnome.org/GTK%2B/Roadmap 126 < jessevdk> and as everyone probably knows, doing this is not very easy with the current gtktextbuffer/gtktextview implementation 127 < kris> why not? 128 < jessevdk> so, we are wondering if with the upcoming gtk 3 API/ABI breakage, it would be possible to make multiple views per buffer possible 129 < kris> You can't have two text view instances editing a single buffer? 130 < jessevdk> the main problem is that the insert and selection points are stored in the buffer 131 < mclasen> well, thats part of the design... 132 < jessevdk> whereas for having two views working on a single buffer, it would be nice to have insert/selection per view instead of per buffer 133 < kris> not sure 134 < kris> if I have vim here with split view 135 < kris> there is only a single cursor active at the time 136 < kris> if you switch view, the "cursors switches as well" 137 < jessevdk> kris: but isn't that just making the cursor visible or not? 138 < mclasen> it is certainly possible to come up with a design where each view keeps its own, private set of marks 139 < jessevdk> I mean, if you move the cursor in one view, it should not move in the other. Otherwise it does not seem to useful to split at all 140 < mclasen> and then switch depending on focus 141 < Company> doesn't that invalidate the selection? 142 < kris> jessevdk: well, you save the cursor position before you switch view 143 < Company> webkit does that and it annoys me to no end 144 < mclasen> but you probably still need some api changes to prevent the selection of the current view to be rendered in all others 145 < mclasen> Company: are you talking about clipboards there ? 146 < Company> mclasen: yeah 147 < jessevdk> we figured we could have 'virtual' insertion marks and maybe show/hide cursors in views based on focus, but indeed rendering the selection is somewhat problematic without changes in gtk+ itself 148 < jessevdk> I'm also wondering how much the view would start scrolling according to certain changes in the buffer (like middle mouse paste) 149 < mclasen> jessevdk: so you want selection to behave like it does with the new entry buffers 150 < jessevdk> I don't know the new entry buffers 151 < mclasen> where the selection is in fact associated with the view 152 < jessevdk> yes 153 < mclasen> there's an example in gtk-demo of two entries sharing a buffer 154 < jessevdk> I think that makes sense 155 < mclasen> and if you select something in one, the selection is not rendered in the other 156 < jessevdk> it would also be nice to have the insertion point be saved/restored automatically on focus-out/focus-in 157 < jessevdk> although that can also be done externally if needed 158 < jessevdk> right now we're implementing splitting the view by creating a new buffer, which replicates all actions on the original buffer, but it's not very clean (not mentioning twice the memory usage) 159 < harobed> in qt, cursor and selection are managed by view 160 < jessevdk> so, is this something worth investigating/working out? 161 < mclasen> jessevdk: I think it is worth supporting it 162 < mclasen> if we can implement it without totally turning gtktextbuffer inside-out... 163 < pbor_> I think the question is what to do with api like get_inesert or has_selection 164 < pbor_> get_bounds, delete_selection 165 < mclasen> yeah, certainly 166 < pbor_> they all build on that assumption 167 < mclasen> one answer could be: in 'virtual mark mode' they don't work, you have to go through the view 168 < mclasen> or, they could implicitly operate on the view that last had focus 169 < pbor_> yeah, I guess they could say "if there is more than one view, result is not defined" 170 < pbor_> and either use the last used view or the first view 171 < jessevdk> operating on the last focused view seems quite good, it's not very nice model/view split wise maybe 172 < Company> you can deprecate all the functions in 2.30 and remove them in 3.0 ;) 173 < pbor_> basically our question is a general: would this kind of change be cosidered or is too much of a break and we should spend our time finding a solution out gtk? 174 < pbor_> (e.g. proxyiing two buffers) 175 < mclasen> pbor_: I tried to answer that...I think it is worth trying inside gtk, and see if it can be made to work without too much collateral damage 176 < pbor_> okay, great 177 < kris> i agree 178 < kris> for what it's worth ;) 179 < harobed> jessevdk's solution can be good 180 < jessevdk> cool 181 < jjardon> target? 2.20 or 3? 182 < pbor_> 3 I guess 183 < ebassi> I guess it depends on jessevdk - 2.20 is for the end of the year 184 < ebassi> jessevdk/pbor 185 < pbor_> but maybe we can ask for some api additions or deprecation along the way 186 < jessevdk> we will probably introduce this functionality when we break API too (in 3), so... 187 < jjardon> Do you mind If I add the info in http://live.gnome.org/GTK%2B/Roadmap ? Is there a bug report? 188 < mitch> argh 189 < tml> btw, when dbus is becoming even more important in the near future, what is the status of dbus maintenance? 190 < mitch> can't we adjust the meeting time to something not depending on summer/winter time? :) 191 < Company> mitch: s/not// 192 < Company> :p 193 < ebassi> mitch: we're already on UTC :-) 194 < mitch> Company: heh right 195 < jessevdk> mitch: GMT doesn't depend on winter/summer :) 196 < harobed> pbor_, you create a bug in bugzilla about this subject ? 197 < mitch> yea yea yea you got me :) 198 < tml> I would like to get the fragmentation of dbus on windows to an end at some point, but I get no reply on the dbus list when suggesting merging the dbus4win fork 199 < jjardon> mitch, I was late the last meeting for the same reason ;) 200 < pbor_> harobed: I can, but I am not sure if a bug makes much sense until we have evalued the impact of gtktextbuffer and came up with at least vague implementation plans 201 < tml> are linux distro -connected people in general satisfied with the stable dbus-1.2 branch and can't be bothered with dbus master? is dbus master a dead end? 202 < jessevdk> who is the main guy working on/responsible for gtktextview/gtktextbuffer? 203 < pbor_> you? 204 < pbor_> :) 205 < jessevdk> can't be worse than gsv :P 206 < mclasen> tml: we're waiting for 1.4, but no particular urgency 207 < harobed> pbor_, may be a issue to explain the problem 208 < harobed> pbor_, to assemble the idea ... 209 < jjardon> pbor_, and to track the progress ;) 210 < ebassi> anybody else has suggestions for the "misc" agenda point? 211 * desrt nothing 212 < Company> yes 213 < Company> i do 214 < Company> jjardon: what was the bug report for the imcontext? 215 < jjardon> I'd like to hear your opinnion about https://bugzilla.gnome.org/show_bug.cgi?id=601234 216 < Company> right, that one 217 < ebassi> mmh, what is the problem in changing the table to uint32? 218 < ebassi> I doubt it's the size of the compose sequences table :-) 219 < mclasen> we worked hard to shrink the table 220 < mclasen> would be a shame to blow it up to twice its size to quell a compiler warning now... 221 < jjardon> mclasen, but downcasting the unicode value 0x10001af to 0x01af is a bug? 222 < mclasen> the table doesn't contain non-bmp unicode values, afaik 223 < mclasen> and there is a comment somewhere that explains that we'll have to add a separate table with guint32 entries for non-bmp sequences 224 < mclasen> right now, compose-parse.py throws away non-BMP keysyms 225 < tml> jjardon: where do you see the 0x10001af value? 226 < tml> hmm, that would be GDK_Uhorn 227 < tml> which *does* occur in gtkimcontextsimpleseqs.h 228 < tml> how did it get there then? 229 < jjardon> tml, exactly 230 < mclasen> ah, thats a bug then 231 < mclasen> and we need the non-bmp table 232 < Company> ya, the compiler warning showed us the bug ;) 233 < Company> so the real fix is to create two tables 234 < jjardon> Another question: is Importance field really used in gtk+ bugs? 235 < tml> (does some keyboard really have a key for Uhorn? if not, what's the point in having it as input in the compose table? or am I missing something?) 236 < tml> jjardon: no 237 < Company> tml: there might be mappings with xkb, no? 238 < mclasen> tml: using the right xkb layout, you might 239 < tml> theoretically, sure 240 < mclasen> but yeah, it is probably not a huge loss 241 < mclasen> considering we haven't received bugs about the sequences not working... 242 < jjardon> try to compile gtk and you get a lot of warnings about this, not only that line 243 < tml> anyway, this Uhorn is not a non-BMP code point. it is just one of those for which there is no predefined X keysym 244 < tml> it's actually just U+01AF 245 < tml> but gdkkeysyms.h encodes non-X keysyms as that high bit + the codepoint 246 < mclasen> i believe that is the way unicode codepoints are folded into the X keysym space nowadays 247 < tml> would it be simpler to add some magic to the 16-bit table, split 32-bit keysyms for bmp codepoints into a magic prefix and the unicode codepoint? (and split keysyms for non-bmp codepoints to three guint16s... with different magic prefix) 248 < tml> nah, sounds ugly 249 < tml> luckily I don't know Python so I don't have to feel ashamed to not volunteer to do the 32-bit table 250 < ebassi> other items? 251 < ebassi> or should the meeting be closed? :-) 252 < tml> how does one close an IRC meeting? kick all participants? ;) 253 < ebassi> I take silence as a yes. next meeting is on the 24th. thanks for attending everyone :-) 254 < tml> bye
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.