**** BEGIN LOGGING AT Wed Feb 22 16:01:15 2006 Feb 14 15:45:24 hmmm, no federico Feb 14 15:47:46 isn't it too early still? Feb 14 15:47:56 13 minutes to go by my clock Feb 14 15:55:02 yes, I was just looking around for federico on irc... Feb 14 16:03:15 ok, looks like federico is not around Feb 14 16:04:58 so it looks like we should postpone async filechooser discussions until federico shows up Feb 14 16:05:30 guess so yes Feb 14 16:05:40 mitch: did you see dom's response re rich text ? Feb 14 16:06:15 mclasen: yea i did Feb 14 16:08:11 after reading it, i beleive there is the need for both approaches, internal format of copying just anything (which needs something like tagsets to be somehow configurable), and other methods which probably should not have that tagset stuff Feb 14 16:08:47 perhaps leaving out tagsets from application registered (de)seriaization methods would already be sufficient Feb 14 16:09:25 i'm ok with there being an internal format that matches the GtkTextBuffer's model. it's perhaps the best way to guarantee lossless copy+paste Feb 14 16:09:52 yea, for whatever voodoo stuff people want to do Feb 14 16:10:22 the internal format must somehow be parametrized by the used set of tags Feb 14 16:10:35 yea Feb 14 16:11:29 i think application installed functions do not need this, since they will know what to do Feb 14 16:12:27 why treat this one differently? Feb 14 16:13:22 because app b may not know what to do with tags from app a ? Feb 14 16:13:28 they do not need tagsets i mean, if your app has an xhtml deserializer, it will know what tags the textbuffer can handle and just do what's right Feb 14 16:13:36 oh Feb 14 16:13:42 ok, i did misread Feb 14 16:14:47 mitch: won't letting app b subclass the tagset deserializer solve that issue? Feb 14 16:14:58 dom: that's actually the special case of copying within one app or multiple apps of the same "framework" or whatever Feb 14 16:15:31 dom: their text buffers may have whistles and bells which do not appear in any serialized form, but which one wants to copy between them Feb 14 16:15:31 one could just do a get_data(), try to deserialize it, and have the drop/paste fail if one meets unknown tags... Feb 14 16:16:38 dom: subclassing involves abstracting that stuff generally, right now we just register function pointers Feb 14 16:17:29 i don't mean to present "subclassing" as the only way to solve the problem Feb 14 16:17:45 yea Feb 14 16:18:00 i guess i don't understand why we're pushing the deserialization logic down to the TextView, instead of up 1 level to the app Feb 14 16:18:30 um, it's the app that registers the stuff Feb 14 16:18:34 we are not. the app registers the deserialization functions Feb 14 16:18:40 i might suggest documenting the tagset markup, and the apps write parsers for it. they can ignore whatever they don't grok Feb 14 16:18:43 the text buffer just uses the rich text registry Feb 14 16:20:42 the deserialization functions are completely separate and registered in gtkrichtext.c as any app-supplied one Feb 14 16:20:57 the app can even unregister it Feb 14 16:22:45 anyone of you interested in helping me with gtk bindings for prolog? :) Feb 14 16:23:18 cehteh: wrong channel, this is a meeting. go to #gtk+ Feb 14 16:23:58 ah well :) Feb 14 16:23:59 um, unless i misunderstood you, did i :) Feb 14 16:24:10 if he's writing bindings, it's not totally off topic Feb 14 16:24:25 yea that's what i just thought too Feb 14 16:24:44 * cehteh uses Peter van Eertens gtk-server for now Feb 14 16:25:24 used to expose the plain gtk api ... and now working on some higher level gui definition Feb 14 16:25:31 mind you; ew, prolog. (-; Feb 14 16:25:35 http://www.pipapo.org/prologwiki/PasteBin/GUI Feb 14 16:26:44 mitch: can we get rid of the separate tagset in the api, and just require apps to use a suitable mime-type when registering the internal-format serialization function ? Feb 14 16:26:52 mitch: ok, i re-read your tagset description. let's say for instance that i'm app A, and support features XYZ under "tagset-a". let's say that there exists an app B, that supports the same features XYZ under "tagset-b". how does one negotiate richtext pasting between the two? Feb 14 16:27:23 mclasen: would probably simplify stuff quite a bit Feb 14 16:27:35 dom: this problem is the same as nonstandard mimetypes, really. what if one uses application/xml, and the other text/xml ? Feb 14 16:27:39 mclasen: actually, that's ust what happens internally :) Feb 14 16:28:56 mclasen: why add more to the mess, though? :) Feb 14 16:29:25 dom: I just proposed to reduce the mess to the usual mimetype mess... Feb 14 16:29:36 yea :) Feb 14 16:30:36 the real problem is to get internal copying of arbitrary crap into the same api as standard rich text formats Feb 14 16:33:36 mitch: do you think your patch can be reworked to avoid tagsets in the api ? Feb 14 16:33:40 but i don't think that there's a need for even that. gtk+ should advertise the data as "application/x-gtk-textbuffer-internal" or whatever. the app should provide its own desrialization functions that ignore the tags it doesn't support Feb 14 16:34:12 i'm a broken record now. i'll just be quiet. Feb 14 16:35:04 thanks for the feedback anyway, the next iteration will be better because of it Feb 14 16:35:17 so, switching topics to glib Feb 14 16:35:20 dom: but that's exactly what happens now, apart from that taget stuff that only makes sense for "application/x-gtk-textbuffer-internal" Feb 14 16:35:39 mclasen: it will even simplify stuf Feb 14 16:35:40 f Feb 14 16:35:48 cool Feb 14 16:36:17 does anybody have the gnome 2.14 schedule at hand ? how long till 2.14 final ? Feb 14 16:36:26 --- mitch is now known as mitchAway Feb 14 16:36:28 need to run... Feb 14 16:36:38 bye mitch Feb 14 16:36:45 6 March - Hard Code Freeze Feb 14 16:36:48 bye Feb 14 16:36:50 thanks Feb 14 16:37:05 so, we should probably target end of february for glib 2.10 Feb 14 16:37:05 bye :) Feb 14 16:37:23 27th Feb is 2.14 RC tarballs due Feb 14 16:37:33 ah, thanks. thats the target date then Feb 14 16:37:54 * leio hugs the clock applet with evolution ics calendar Feb 14 16:38:07 mclasen: if you have anything pending for/blocking on me, please just ping me again on it. Feb 14 16:38:43 rambokid: i'll look over the bug list, but I don't think there is anything blocker like Feb 14 16:39:05 rambokid: did you see davyd's gslice "graph" ? Feb 14 16:39:14 no, where's that? Feb 14 16:39:25 he posted on performance-list@gnome.org Feb 14 16:39:41 http://davyd.livejournal.com/166736.html Feb 14 16:39:47 http://davyd.ucc.asn.au/images/gmemchunk.png Feb 14 16:40:31 while being shiny etc, I wonder if it is a good idea to put a graph like that in the release notes without further explanation Feb 14 16:40:46 it might set unrealistic expectations... Feb 14 16:41:23 vapml? Feb 14 16:42:07 especially if people don't realise fully, that this is about malloc/free, and that being x times quicker means maybe only lower than 1-5% quicker in most cases Feb 14 16:42:08 mclasen: agree Feb 14 16:42:49 but if that's clear, then it would be useful under developers section, so people would get rid of their mem chunks and free lists :) Feb 14 16:42:52 mclasen: there's plenty of docuemntation i prodiced for GSlice that you can link to though. (blog entries, reference documentaiton, emails on the mailing list and incode docu) Feb 14 16:43:09 rambokid: yes Feb 14 16:43:20 mclasen: do you have the performance-list subject? Feb 14 16:43:36 request for numbers and graphs for Release Notes Feb 14 16:44:48 ok, gotta go. we really need to get federico here for the async filechooser discussion sometime soon... Feb 14 16:45:01 see you next week **** ENDING LOGGING AT Tue Feb 14 16:45:06 2006