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