(09:19:15) Conversation with #gtk+ at 2008-06-06 091915 on pbor (09:19:15) You joined #gtk+ (09:21:04) so is this jaafar EL GONNOUNI just a clueless idiot, a troll, or a honest guy who has misunderstood something? (09:21:39) jpetersen (~petersen@xdsl-81-173-189-210.netcologne.de) joined #gtk+ (09:22:16) or maybe I understand his question wrong, his grammar isn't that good (09:22:30) harlan (~harlan@g230225100.adsl.alicedsl.de) joined #gtk+ (09:25:42) looks like a clueless newbie to me (09:25:49) if he's a troll he's really bad at it (09:27:09) AfC (andrew@office.syd.operationaldynamics.com) joined #gtk+ (09:30:26) tml: you can always call him on GSM and ask :) (09:32:11) rodo_ (~rodo@195.70.144.67.adsl.nextra.cz) joined #gtk+ (09:41:09) kalikiana (~kalikiana@xdsl-84-44-178-83.netcologne.de) joined #gtk+ (09:42:39) neil_d (~neil@40.7.240.220.dynamic.dsl.rns01-kent-syd.comindico.com.au) joined #gtk+ (09:43:07) bersace (~bersace@did75-13-82-243-217-90.fbx.proxad.net) joined #gtk+ (09:44:07) Sup3rkiddo (~sudharsh@59.96.5.20) joined #gtk+ (09:44:27) harlan quit (Ping timeout: 600 seconds) (09:45:13) jpeterse1 (~petersen@xdsl-81-173-150-178.netcologne.de) joined #gtk+ (09:50:53) jpetersen quit (Ping timeout: 600 seconds) (09:56:51) juergbi (~juergbi@boogiebox.inf.ethz.ch) joined #gtk+ (09:56:54) juergbi quit (Read error: 104 (Connection reset by peer)) (09:56:59) juergbi (~juergbi@boogiebox.inf.ethz.ch) joined #gtk+ (09:57:03) juergbi quit (Read error: 104 (Connection reset by peer)) (09:58:46) Sup3rkiddo quit (Remote closed the connection) (09:59:17) satis (~c-a@77.240.67.219) joined #gtk+ (10:00:49) juergbi (~juerg@80-219-17-53.dclient.hispeed.ch) joined #gtk+ (10:00:49) kmaraas quit (Ex-Chat) (10:02:19) Sup3rkiddo (~sudharsh@59.96.5.20) joined #gtk+ (10:02:48) yongsun quit (Read error: 145 (Connection timed out)) (10:05:22) Can anyone op me for a minute? (10:08:54) yosh sets mode: +o bratsche (10:09:14) Thanks. (10:09:56) bratsche set topic on #gtk+: Please do not feed the trolls in gtk-devel-list | http://www.flickr.com/photos/arclnx/2335638271/ (10:11:24) bratsche: thanks. /me presses the discard button (10:12:03) Yeah, this is getting out of hand. (10:13:27) garnacho (~carlos@benny.imendio.com) joined #gtk+ (10:13:57) The whole thing makes me feel good about having chosen to always use existing getter/setter functions where they exist, and only use the property system as a fallback when necessary, though (10:20:39) fredmorcos (~fred@ip-141-31-187-86.nat.selfnet.de) joined #gtk+ (10:22:46) Ademan_ quit (Ex-Chat) (10:22:55) Ademan (~dan@h-68-167-207-98.snfccasy.dynamic.covad.net) joined #gtk+ (10:27:26) harobed (~stephane@pda57-1-82-231-115-1.fbx.proxad.net) joined #gtk+ (10:29:46) yongsun (~yongsun@123.116.98.154) joined #gtk+ (10:32:14) tim (~tpm@dsl-217-155-195-89.zen.co.uk) joined #gtk+ (10:32:25) harlan (~harlan@g230225100.adsl.alicedsl.de) joined #gtk+ (10:36:16) gianmt quit (Ping timeout: 600 seconds) (10:36:31) andre quit (Remote closed the connection) (10:39:17) andre (~andre@f053155131.adsl.alicedsl.de) joined #gtk+ (10:43:15) yongsun_ (~yongsun@202.108.88.133) joined #gtk+ (10:43:15) yongsun quit (Ping timeout: 600 seconds) (10:43:47) njpatel (~njp@5ac61482.bb.sky.com) joined #gtk+ (10:44:40) gianmt (~gianmt@adsl-ull-92-176.47-151.net24.it) joined #gtk+ (10:51:16) MacSlow (~mirco@dslb-088-076-040-110.pools.arcor-ip.net) joined #gtk+ (10:56:40) Hallski (~micke@83.251.94.123) joined #gtk+ (10:59:15) Hi Hallski (11:00:27) fredmorcos quit (Leaving) (11:01:40) what is so special about libatk-1.0.la when libtool only warns (numerous times when linking some executable high up in the stack) "warning: `c:/devel/target/HEAD/lib/libatk-1.0.la' seems to be moved" but not for any of the other .la files? (11:01:55) s/only / (11:02:57) That sounds familiar, I think I was having that with libcairo at some point. (11:03:18) Err.. with something, but I don't remember now. (11:03:29) hmm, the only difference to, say, libglib-2.0.la seems to be that the libdir= line in libatk-1.0.la doesn't have the drive letter... (11:03:50) *tml adds that to see if the annoying (but harmless) warnings go away (11:03:56) ebassi (~ebassi@host86-163-240-190.range86-163.btcentralplus.com) joined #gtk+ (11:04:28) I know I've seen that, but now I think I might be getting it confused with something else. (11:04:37) Hi ebassi (11:08:07) Sonderblade (~mah@h-79-136-53-26.NA.cust.bahnhof.se) joined #gtk+ (11:08:53) bratsche: hey (11:10:42) bleh, past 4am. I guess I'll try again to get to sleep. (11:11:01) For some reason I've been having a lot of trouble sleeping this week. (11:11:05) hi everyone (11:11:16) Hey (11:12:31) tml: I don't remember seeing it on libatk.. I think it was libcairo for me, but I don't remember how I fixed it. (11:13:22) I'll try to think about it again when I wake up, if I can get to sleep. (11:13:29) bratsche: just some randomness... libtool, bite my shiny metal ass (11:13:36) heh (11:14:25) ebassi: Don't let the trolls get to you dude, stay on the list. :) (11:14:28) Good night everyone. (11:14:42) sleep well (11:15:18) indeed, stay on the list and put on the mighty ignore filter :) (11:16:44) aike (user1@e180040129.adsl.alicedsl.de) joined #gtk+ (11:20:40) giskard (~giskard@85-18-81-138.ip.fastwebnet.it) joined #gtk+ (11:29:39) well, no. I wanted to unsubscribe for a while, now; the trolls just got me to do it sooner (11:30:07) gtk-devel-list is mostly useless; we have far more productive outlets (11:31:54) gianmt quit (Leaving) (11:33:04) AfC quit (Leaving.) (11:33:11) I'm more worried about the code of conduct and its enforcement - well, the lack thereof (11:34:06) ebassi: though those productive outlets mostly cut out application developer which are not in gtk inner loop (11:34:15) ebassi: as unpleasing and paranoid as muntyan mail may be, if you leave out the "freedom of speach" crap, there is still a strong point in his mail that I fear it will be dismissed just because of the way it has been expressed (11:35:10) and that is that the current plan for gtk+3.0 is perceived as a loose-loose thing for an application developer (11:35:27) and I fear I am inclined to agree with that (11:35:45) (though I also see the points why such thing is beeing done) (11:39:13) lose-lose you mean (11:39:21) yeah, I guess (11:39:44) bkor_ (~bkor@a51049.upc-a.chello.nl) joined #gtk+ (11:39:47) Burrito sets mode: +o bkor_ (11:41:46) alfauros quit (Ex-Chat) (11:42:30) harlan quit (Ping timeout: 600 seconds) (11:44:23) neil_d quit (Remote closed the connection) (11:45:00) fargiolas|afk is now known as fargiolas (11:45:17) AfC (andrew@office.syd.operationaldynamics.com) joined #gtk+ (11:45:45) pbor: how can a clean migration path towards an API break possibly be detrimental to application developers? (11:45:52) pbor, the thing is that application developers does not need to move to 3.0 (11:46:00) pbor, and can wait with that switch to 3.2 (11:46:12) pbor: or do application developers expect the API to be fixed forever and ever? (11:46:23) because that's a bit unrealistic (11:46:38) ebassi, I guess that application developers want features and fixes of long standing issues. (11:46:54) ebassi, but have little or no idea about the efforts involved in getting those into the toolkit at the current state (11:46:58) "we wantz fitiurz!" "we wantz API stability forevah" (11:47:04) ebassi, and were hoping 3.0 would be the holy grail (11:47:14) which fixed everything and got tons of new features (11:47:27) Hallski: I perfectly understand that (11:48:33) ebassi, Hallski: as I said I *do* see your point, but what I mean is that it's also true that it will be 2010 and I will not have a better api that fixes long standing problems with the current gtk, I will not have new features and I will not even have a gtk2 properly supported (11:49:03) pbor, why do you say that there won't be any new features by 2010? (11:49:05) Well, in so far as a top level version number change signals an API break, I figure that 3.0 is appropriate. The fact that in the marketing world "3.0" means "massive new features" is, I think, where most people run awry. (11:49:26) AfC, I agree (11:49:31) nacho (~nacho@125.120.218.87.dynamic.jazztel.es) joined #gtk+ (11:49:32) Hallski: I don't, but that's how things are perceived now IMHO (11:49:46) Ah, that's unfortunate then :) (11:50:23) Hallski: I am all for gseal etc, but I'd also love to see some other api breakage to fix long standing problems (11:50:26) Is it really or is it just what the trolls chose to use as argument for trolling? (11:50:51) pachi (~pachi@84.76.213.34) joined #gtk+ (11:51:16) pbor: API breakage and fixes do not mix very well; that's what happened with 2.0 and that release was always pushed back (11:51:25) Hallski: and say for instance a new Notebook or GtkEntry that replaces the current one (those can be introduced in 2.X and then switched to proper in 3.0) (11:51:35) pbor: well, API breakage+fixes+features (11:51:38) I must admit that the perception that many issues are going unresolved, and have been so for a long time, is vaguely disturbing. I can't say as how I'm burned by that myself, but I appreciate the frustration level. Certainly work done to get a 3.0 out the door won't help such people. The open question is whether such work will make fixing such problems easier. (11:52:09) [Based on what I heard in Berlin, it doesn't sound like 3.0 class work is holding up fixing such things] (11:52:28) ... easier in the long run. (11:52:56) roosmaa (~roosmaa@195-50-211-19-dsl.krw.estpak.ee) joined #gtk+ (11:53:33) pbor, it's the same old "We have a huge technical debt here that we ignore for long and focus on adding more and more features" (11:54:09) pbor, and while we can continue doing that for quite a long while it adds up to the point where the effort of getting a simple single feature in is measured in weeks (11:54:33) And I'd say that the large number of unresolved long standing issues is a result of that (11:54:44) (and lack of resources) (11:55:01) with 2.x you also have the problem that if you add a feature, it must be right at once because you will be stuck for it forever (11:55:19) 3.0 and the new development policy will guarantee us there will be deprecation cycles/breaks at pre-defined times (11:55:46) so it's easier to fix it and you know the wrong stuff will be removed at some point (11:58:38) kris: Hey, Kris, one thing that occurred to me since our discussions about what Python has done for their migration was that they have very loud warnings when you use something deprecated. Perhaps in a post 3.0 era (and maybe even earlier) we should start doing that [aggressively] (11:59:37) AfC: yes, there are basically two plans for that (11:59:52) AfC: this "diagnostic mode" that you could turn on would be very appropriate for given such warnings (12:00:24) AfC: ie. it is a mode that will help you to identify things in our app that will break once you upgrade to a newer gtk+ (12:00:39) AfC: the other one is that we plan to enable the DISABLE_DEPRECATED compile flags by default (12:00:56) All makes sense (12:02:43) mathrick quit (Read error: 145 (Connection timed out)) (12:05:54) quikee__ (~quikee@BSN-61-84-66.dial-up.dsl.siol.net) joined #gtk+ (12:08:21) Hallski: ebassi, sorry got a phone call for work... /me reads the backlog (12:10:29) Hallski: one of the problem I see, is the guarantee that "3.0 is perfectly compatible with 2.X modulo the deprecated stuff" (12:10:56) Hallski: I definately agree that heavily changing the api is not workable (12:11:43) Hallski: but I also think that we should take the chance to fix *some* api problems that actually bite application writers in the ass (12:14:09) Hallski: put in other words, my main problem (and that's the bit of truth I see in muntyan mail), I fear I see some trend where gtk developement is getting disconnected from application writers needs (12:14:26) quikee_ quit (Ping timeout: 600 seconds) (12:14:31) pbor, we want to avoid breaking the API more than necessary for *3.0* and also get a new policy in place that let's us fix up API during the 3.x series (12:15:03) Hallski: I know, and I agree with that (12:15:08) pbor, I don't think that's true (12:15:28) pbor, the main issue has (and to is) a lack of resources (12:15:35) Hallski: but not all of them can be adressed by deprecating and removing a method and adding a new one (12:15:56) kalikian1 (~kalikiana@xdsl-87-78-33-139.netcologne.de) joined #gtk+ (12:16:17) pbor, that's true, some of them will need new classes or new backends etc (12:17:04) Hallski: to make a practical example if an interface has a "changed" signal and a widget has a "changed" signal and I want to subclass the widget and implement the interface I am royally screwed (12:17:25) Hallski: and to deal with that you'd have to change a *lot* of stuff (12:17:37) (that's something that actually happened to me) (12:18:40) pbor, are you worried that valuable resources are spent on doing sealing and what not that could be spent on fixing other things? (12:18:59) pbor, as none of the things that you can fix in 2.x is going to be harder to fix in 3.x (12:19:04) quite the contrary (12:19:36) Hallski: I am worried that sealing is thought to be as a technical solution to all of our problems... which I do not think is true :( (12:19:50) hehe, of course it isn't (12:20:06) it's a necessary step in order to be able to implement some of the solutions in a feasible way (12:20:31) I agree on that (as I said I agree on sealing itself) (12:20:34) onur (~onur@88.232.226.64) joined #gtk+ (12:21:08) Hi. I have a noob question. I want to add a scrollbar to my textview. But how can i do that? I dont find anywhere. (12:21:13) or do you mean that you are worried that others think that sealing is thought to be the solution? (12:21:28) I must admit I don't quite get your concern :) (12:21:45) onur: place the TextView into a ScrolledWindow and then pack the ScrolledWindow into whatever was going to include the TextView originally (12:22:41) onur: (that's not obvious at all, so don't feel bad about having to ask about it) (12:23:01) ok thanks AfC (12:23:10) kalikiana quit (Ping timeout: 600 seconds) (12:24:00) Hallski: my main worried are: 1) "sealing will allow to fix all of our api problems" which is not true 2) let's do sealing for 3.0 and the rest after -> 2010 (at best) to have a new toolkit version with all the compat problems it brings for someone maintaining an app and still no "real" improvements for "me" (fixed api, new features) (12:24:26) onur: you'll also probably want to call gtk_scrolled_window_set_policy() (12:25:20) pbor: I think someone threw out 2010 and it stuck in this discussion. No one I know of that is working on core GTK has any thought that forward progress will be deliberately delayed until then! (12:26:07) 2010 has more attraction as "The Year We Make Contact". I'm looking forward to meeting HAL, myself. (12:26:08) AfC: Do you know much about using TextView inside ScrolledWindow..? I've been looking at how to make it bottom-heavy; keeping the bottom scrolled... I wonder if a "gravity" setting needs to be made somehow (12:26:21) Hallski: and then the biggest of my concerns (which however is not related to sealing), is that almost all new features that made into gtk lately, were good but actually not quite good enough to be used straight away in a real app because they were prototyped implemented and added with no (or just one) real app ported to it (12:26:30) LeoNerd: let's just say I'm learning as I go. (12:26:45) pbor: examples? (12:26:47) Hallski: printing, notebook improvements, builder (12:27:03) Hallski: gio itself (12:27:26) LeoNerd: gravity would need to be implemented in TextView (12:27:59) jpeterse1: Yes, I know... I was just trying to make a typical scroller window... It's possible manually, but takes a lot of effort; lots of signals to hook up, resize behaviours, etc... (12:28:11) Hallski: gedit is not the center of the world nor it is such a sophisticated app, that said all the features that on paper are a great step forward for gedit, were actually not quite there to be really used (12:28:21) LeoNerd: but I'll try. Bottom heavy in the sense of? The insert mark has right gravity and as I recall will scroll the thing. Failing that, use something like gtk_text_view_scroll_mark_onscreen()? (12:28:22) gtk_textview_set_gravity(view, GTK_GRAVITY_BOTTOMLEFT); would be lovely :) (12:28:33) Hallski: some got fixed with time some not (12:28:53) AfC: After every update, scroll the mark. But that's not enough.. think about resize... Have to scroll so the bottom's visible if it gets shrunk on resize... and lots of other messups like that (12:29:01) If it managed its own gravity, all of those issues would go away (12:29:03) nacho quit (Ping timeout: 600 seconds) (12:29:13) pbor, right, I agree with you on most of those (12:29:26) pbor, though I don't understand what 2010 comes from (just some random number taken from the blue?) (12:29:31) pbor: I don';t see how you get at 2010 (12:29:56) pbor: I don't see the numerous compat problems of this new toolkit version either, the whole point of 3.0 is having a very, very easy migration path (12:30:00) Hallski: to be fair with kris I admit that the new tooltip rock :-) (12:30:17) pbor: your best opiotn is to stay on 2.x, which up the field accesses when you have time (12:30:27) psankar (~evo@ecoprobe-dmz.gns.novell.com) joined #gtk+ (12:30:27) pbor, but I don't necessarely see how you can improve the development model (ie. develop something, have a few apps port to it, improve it, etc..) (12:30:28) pbor: once you see new features in 3.2, 3.4 that can be of use, you can migrate (12:30:40) kris, Hallski: [someone used 2010 stupidly in that gawd awful fork of the 3.0 thread] (12:30:45) kris: ok 2010 was a long shot, but surely 3.0 is not before 2009, no? (12:30:59) AfC: yea I have replied to that guy iirc (12:31:00) AfC, ah (12:31:09) pbor: we want to get 3.0 out withint 12 months from now (12:31:12) pbor: which is before mid-2009 (12:31:15) I'll implement gravity when we'll use a new Scrollable interface in 3.x ... (12:31:22) pbor, our hope is that it can be released within the year (12:31:25) pbor: if work on new features is already underway by then (12:31:32) pbor: we could have a 3.2 with new stuff before end-2009 (12:32:13) (also note that people are not going to drop touching 2.x during this period) (12:33:06) kidfoo quit (Ping timeout: 600 seconds) (12:33:53) Hallski: well, let's make that very clear then, because at the moment the feeling I get is: either I switch to 3.0 without getting any advantage and pissing off all the users which are not on the very latest distro or sticking with 2.X that will get no fixes (12:34:43) kris, Hallski: maybe you should explain on the list what you have written here? exactly what will happen after 3.0 and so on (12:34:53) pbor: and as for the tooltips, exactly what has been biting us there were the structure fields ;) (12:35:08) e.g. when will all the horrible api design mistakes made in 2.x be fixed? (12:35:09) Sonderblade: it's already been written on the list (12:36:02) sven_ (~sven@p57A6E471.dip.t-dialin.net) joined #gtk+ (12:36:38) I've got a question to Glib signal handling (12:36:52) kris: yep, I know, struct fields bit my ass too, that's why I am all for sealing, as I was explaining before I just do not think that sealing will allow us to fix a large part of the api issues (12:37:45) I'd like to connect some signal from an instance from class A to a method from the instance from class B _AND_ i want to transport auxillary data via the GCallback. But I see no way to realize that. (12:38:41) ebassi: i can't find it (12:38:52) Hallski, kris: anyway, thanks for the clarifications... time to get back to real work :-) (12:39:16) which unfortunately is not gtk3.0 here ;) (12:39:39) vampirefrog quit (Leaving) (12:39:40) neil_d (~neil@40.7.240.220.dynamic.dsl.rns01-kent-syd.comindico.com.au) joined #gtk+ (12:39:48) nacho (~nacho@47.120.218.87.dynamic.jazztel.es) joined #gtk+ (12:39:51) pbor, hehe (12:40:17) Here's the real life example: http://rafb.net/p/08PVep34.html -- see line 185-192: I want the GtkMenuItem "activate" signal connect to the current instance of my own GtkPaperTape object _AND_ I want to send the callback function/method the auxiallary data ("+", "-", "_", ...) (12:40:29) Sonderblade: http://mail.gnome.org/archives/gtk-devel-list/2008-March/msg00046.html (12:40:48) Sonderblade: the pdf, not the slides (12:41:01) Sonderblade, might be good to reiterate the points (nothing new here) (12:42:25) nobody who could help me? :-( (12:42:59) GClosures, Marshaller, ... they don't seem to help (12:44:30) sven_: g_signal_connect (instance_a, "signal", G_CALLBACK (instance_b_method), data); (12:44:43) sven_: unless it's c++, then you should probably ask on #c++ (12:45:05) Ademan quit (Ping timeout: 600 seconds) (12:45:16) rob (~rob@141.201.109.66) joined #gtk+ (12:45:39) ebassi, it's C, but where's the improvement in your code? I need something like g_signal_connect(instance_a, "signal", G_CALLBACK(instance_b_method), instance_b, data); (12:46:01) hi (12:46:03) because in your solution instance_b_method will be called with the parameters and , but is missing (12:46:04) sven_: oh, you want to pass the instance as well (12:46:13) yes, that's _exactly_ my problem. (12:46:27) sven_: define a structure holding the instance_b and the data (12:46:47) struct { TypeB *instance_b; gpointer data } closure; (12:46:54) then pass it as the data (12:47:23) yes... but that's really ugly and much lines of overhead code. I thought there would be some nice glib methods... :/ (12:51:44) sven_: it's not "ugly" - that's C (12:52:03) psankar quit (psankar) (12:52:34) sven_: you could create your own GClosure and marshal/demarshal it (12:52:52) Ademan (~dan@h-68-167-207-98.snfccasy.dynamic.covad.net) joined #gtk+ (12:53:04) sven_: but you would still need to create a structure for holding that stuff (12:55:15) belou (~benoit@LAubervilliers-151-12-74-51.w193-252.abo.wanadoo.fr) joined #gtk+ (12:55:19) so an own GClosure could not replace this structure. (12:56:03) sven_: one extends a basic GClosure by *creating* a new struct with a GClosure at the top. (12:56:22) sven_: you would replace this structure with a GClosure structure ()... (12:56:49) deitarion quit (brb (If the power went out, you wouldn't be seeing this)) (12:57:59) hm (12:58:08) and how would this GClosure look like? (12:58:20) mcrha is now known as mcrha|eat (12:58:56) herzi (~herzi@p578EBE42.dip.t-dialin.net) joined #gtk+ (12:59:22) sven_: as AfC said like your structure with a GClosure at the top (12:59:58) erhm... truct { GClosure *closure, TypeB *instance_b; gpointer data } ....!? (13:00:03) s/truct/struct/ (13:00:51) ... { GClosure closure, ... (13:01:02) I think gobject should implement such a g_signal_connect_* function which would make this much more comfortable. (13:01:27) Hello! What could've caused a segfault with the following backtrace? http://rafb.net/p/f0Yewv29.html (13:01:56) (it's after an gtk_list_store_insert_with_values) (13:05:08) hmkey (13:05:21) I assume I can insert NULL in a column that would take an object, right? (13:06:07) I'll make it with this dummy structure which holds the instance and data... but thank you for your help, jpeterse1, AFC, ebassi =) (13:07:16) jones: no (13:07:45) sven_: don't take it so hard. As Emmanuele pointed out, it's just the way C is. (13:08:11) jones: did you terminate the column/value pairs with -1? (13:08:30) garnacho: yes I did. (13:08:40) jpeterse1: no? I can't insert NULL? (13:08:43) Are you sure? (13:09:38) I have a column that takes GdkPixbufs. What if I don't have a pixbuf available for that row and I wanna show nothing in the view? Wouldn't I insert NULL in the model? (13:10:27) jones: eh yes (13:10:42) Ok, so the problem is somewhere else. Any clue? (13:12:40) belou quit (Read error: 145 (Connection timed out)) (13:13:38) jones: can you generate a backtrace with line numbers? (13:13:53) gianmt (~gianmt@adsl-ull-218-189.47-151.net24.it) joined #gtk+ (13:14:02) jpeterse1: I'll see (13:15:05) AfC: just the way C is... yeah I think GObject is an huge typing overhead, compared to cpp... but... it's just the way C is ;) Anyway, why do you implement such an object system in C if there's something like C++ or objective C? (13:16:07) Because 1) some people want to work in C, and 2) most other languages can call native code ... so writing language bindings is doable so long as the library you're trying to make common is in C. (13:16:56) armin (~ck@i3ED6EC07.versanet.de) joined #gtk+ (13:17:24) sven_: {shrug} I work in Java, so don't look for much more defence of C from me :) I started in C 22 years ago, though, and it has been a good grounding. (13:19:55) jpeterse1: http://rafb.net/p/QMs6XT89.html (13:20:44) jpeterse1: I think I get it. Perhaps I'm trying to insert a row at position 0 when the model is empty. Would this break it? (13:21:32) mbarnes (~mbarnes@66.187.234.200) joined #gtk+ (13:23:53) belou (~benoit@LAubervilliers-151-12-74-51.w193-252.abo.wanadoo.fr) joined #gtk+ (13:24:23) jones: looks like a problem in the gtk_list_store_insert_with_values call (13:24:38) jpeterse1: what could go wrong, there? (13:25:07) wrong argument, like missing iter? (13:25:27) nope, not the case (13:25:47) This works the first time, then I clear the model and repopulate it again, and the problems happens. (13:26:44) Cimi (~cimi@host77-147-dynamic.116-80-r.retail.telecomitalia.it) joined #gtk+ (13:27:20) mathrick (~mathrick@users177.kollegienet.dk) joined #gtk+ (13:28:28) yongsun_ (~yongsun@202.108.88.133) left #gtk+ (13:28:51) mikkel (~mikkel@84-238-113-66.u.parknet.dk) joined #gtk+ (13:29:17) hmkey Afc (13:29:20) thankfs (13:29:22) -f (13:29:28) sven_ is now known as sven|away (13:30:38) fargiolas is now known as fargiolas|lunch (13:30:39) fargiolas|lunch quit (Remote closed the connection) (13:30:47) fargiolas (~Filippo@host16-152-dynamic.104-80-r.retail.telecomitalia.it) joined #gtk+ (13:30:48) fargiolas is now known as fargiolas|lunch (13:32:08) jpeterse1: it might be that I'm inserting in the list an object that I unreffed. (13:32:21) jones: hm, yes (13:32:28) probably something like that (13:39:17) jpeterse1: and bingo, that was it. (13:41:36) harobed quit (Read error: 104 (Connection reset by peer)) (13:42:09) manphiz (~dxy@218.244.247.198) joined #gtk+ (13:43:33) mcrha|eat is now known as mcrha (13:45:01) Hallski quit (Ping timeout: 600 seconds) (13:45:11) ebassi is now known as ebassi|lunch (13:47:43) fargiolas|lunch quit (bye) (13:48:13) manphiz quit (Remote closed the connection) (13:48:29) manphiz (~dxy@218.244.247.198) joined #gtk+ (13:48:54) tjafk1 is now known as timj (13:48:59) ebassi|lunch: around? (13:49:01) fargiolas|afk (pippo@host16-152-dynamic.104-80-r.retail.telecomitalia.it) joined #gtk+ (13:49:35) fargiolas (~Filippo@host16-152-dynamic.104-80-r.retail.telecomitalia.it) joined #gtk+ (13:49:47) fargiolas quit (Connection reset by peer) (13:49:55) matrixise (~stephane@112.40-247-81.adsl-static.isp.belgacom.be) joined #gtk+ (13:50:19) baku (~b@host160-170-dynamic.26-79-r.retail.telecomitalia.it) joined #gtk+ (13:53:21) fargiolas|afk quit (Coyote finally caught me) (13:55:39) belou quit (Ping timeout: 600 seconds) (14:00:45) jwendell (~wendell@wks227.usinasantoantonio.com.br) joined #gtk+ (14:05:46) belou (~benoit@LAubervilliers-151-12-74-51.w193-252.abo.wanadoo.fr) joined #gtk+ (14:09:15) timj: yes (14:13:38) fargiolas (~Filippo@host16-152-dynamic.104-80-r.retail.telecomitalia.it) joined #gtk+ (14:14:09) kalikiana (~kalikiana@xdsl-87-78-23-196.netcologne.de) joined #gtk+ (14:17:09) belou quit (Ping timeout: 600 seconds) (14:21:30) Enselic is now known as Enselic-AFK (14:21:56) kalikian1 quit (Ping timeout: 600 seconds) (14:23:26) Hallski (~micke@83.251.94.123) joined #gtk+ (14:25:02) mclasen (~mclasen@66.187.234.200) joined #gtk+ (14:27:21) belou (~benoit@LAubervilliers-151-12-74-51.w193-252.abo.wanadoo.fr) joined #gtk+ (14:28:51) whoppix (~whoppix@c8113BF51.dhcp.bluecom.no) joined #gtk+ (14:29:41) fargiolas|afk (pippo@host16-152-dynamic.104-80-r.retail.telecomitalia.it) joined #gtk+ (14:29:46) setanta (~setanta@200.184.118.132) joined #gtk+ (14:30:45) fargiolas quit (bye) (14:31:15) fargiolas|afk is now known as fargiolas (14:31:29) argh, why osx is so painful to develop on? (14:31:32) ebassi|lunch is now known as ebassi (14:31:54) I had a working environment, upgrade to 10.5 and now everything's gone (14:32:12) fargiolas quit (Coyote finally caught me) (14:36:40) tbf (~mathias@ip-80-226-14-175.vodafone-net.de) joined #gtk+ (14:37:49) roosmaa_ (~roosmaa@195-50-201-214-dsl.krw.estpak.ee) joined #gtk+ (14:38:02) metalgod quit (Ping timeout: 600 seconds) (14:40:08) Sup3rkiddo quit (Remote closed the connection) (14:40:42) ebassi: what is gone then? (14:40:42) ie. define everything ;) (14:41:10) fargiolas (pippo@host16-152-dynamic.104-80-r.retail.telecomitalia.it) joined #gtk+ (14:41:11) kris: xcode, x11 headers (14:41:23) roosmaa quit (Read error: 145 (Connection timed out)) (14:41:27) kris: it basically broke every single macport as well (14:42:24) kalikiana quit (Read error: 104 (Connection reset by peer)) (14:42:35) ah yeah (14:42:41) xcode and x11 are easily reinstalled (14:42:49) but breaking all macports is unfortunate ... (14:43:04) kalikiana (~kalikiana@xdsl-87-78-23-196.netcologne.de) joined #gtk+ (14:44:26) and I needed to test the installation of clutter via macports :-/ (14:46:01) kidfoo (~kidfoo@59.162.168.11) joined #gtk+ (14:47:31) metalgod (~metalgod@87-196-190-90.net.novis.pt) joined #gtk+ (14:48:49) fargiolas is now known as fargiolas|afk (14:49:28) fargiolas|afk quit (Remote closed the connection) (14:50:37) Unavowed (~silent@static-87-105-185-61.ssp.dialog.net.pl) joined #gtk+ (14:51:10) what is the rationale for gio functions each accepting a cancellable? why isn't the cancellable object per-stream instead? (14:51:22) gianmt quit (Leaving) (14:51:29) or can multiple IO operations be active on one stream at the same time, so that each can be cancelled separately? (14:51:45) belou quit (Ping timeout: 600 seconds) (14:52:40) fargiolas|afk (pippo@host16-152-dynamic.104-80-r.retail.telecomitalia.it) joined #gtk+ (14:52:50) fargiolas|afk is now known as fargiolas (14:57:16) gianmt (~gianmt@adsl-ull-218-189.47-151.net24.it) joined #gtk+ (14:59:54) baku quit (http://www.autistici.org/bakunin/foaf.rdf) (15:02:05) belou (~benoit@LAubervilliers-151-12-74-51.w193-252.abo.wanadoo.fr) joined #gtk+ (15:02:56) AfC (andrew@office.syd.operationaldynamics.com) left #gtk+ (15:06:38) gianmt quit (Read error: 131 (Connection reset by peer)) (15:07:39) gianmt (~gianmt@adsl-ull-218-189.47-151.net24.it) joined #gtk+ (15:08:52) belou quit (Read error: 104 (Connection reset by peer)) (15:09:53) ebassi, i could test it for you (15:12:42) borschty_ (~sebastian@p54BB50C3.dip.t-dialin.net) joined #gtk+ (15:13:57) garnacho quit (Ex-Chat) (15:14:27) giskard: I'm checking that out now (15:14:48) giskard: just do: sudo port install clutter - and it will check out the current stable release (15:15:05) martyn quit (Ex-Chat) (15:16:23) jkroon (~jkroon@c83-254-41-184.bredband.comhem.se) joined #gtk+ (15:20:28) pachi (~pachi@84.76.213.34) left #gtk+ (15:21:18) borschty quit (Read error: 145 (Connection timed out)) (15:25:39) armin quit (home) (15:28:26) manphiz quit (leaving) (15:28:27) fer|out is now known as fer (15:32:44) * Disconnected