1 **** BEGIN LOGGING AT Fri Aug 18 04:33:51 2006
   2 
   3 Aug 18 04:33:51 *	Now talking on #gsv
   4 Aug 18 04:33:52 <paolo>	ok
   5 Aug 18 04:33:54 <muntyan>	hi there
   6 Aug 18 04:33:55 <pbor>	soero non ci sia troppa coda
   7 Aug 18 04:34:01 <pbor>	hey muntyan
   8 Aug 18 04:34:03 <paolo>	ji guys
   9 Aug 18 04:34:04 <paolo>	hi
  10 Aug 18 04:34:12 <paolo>	muntyan: how are you?
  11 Aug 18 04:34:38 <muntyan>	well, going to sleep actually
  12 Aug 18 04:34:43 <muntyan>	was going to :)
  13 Aug 18 04:35:02 <paolo>	ops, we can meet later if you prefer
  14 Aug 18 04:35:37 <muntyan>	no no
  15 Aug 18 04:35:43 <muntyan>	better now
  16 Aug 18 04:35:47 <paolo>	ok
  17 Aug 18 04:35:57 <muntyan>	(just not for four hours like last time :)
  18 Aug 18 04:36:13 <paolo>	hehe, ok
  19 Aug 18 04:36:35 <paolo>	I have just read you mail
  20 Aug 18 04:36:52 <paolo>	lemme see if I have a clear vision of the current state
  21 Aug 18 04:37:37 <paolo>	1. Syntax highlighting is working quite well but needs some tuning
  22 Aug 18 04:38:07 <paolo>	2. Before doing this it is better to try to test the code in some real condition
  23 Aug 18 04:39:24 <paolo>	3. For some reason you think we still have to wait for the printing stuff (can you explain me why?)
  24 Aug 18 04:39:39 <paolo>	4. You want to discuss about the style stuff and the undo manager
  25 Aug 18 04:40:10 <paolo>	5. You are worried about the interaction with the file chooser
  26 Aug 18 04:40:28 <paolo>	6. You have some question for me
  27 Aug 18 04:40:33 <paolo>	it should be all
  28 Aug 18 04:40:34 <paolo>	right?
  29 Aug 18 04:40:43 <muntyan>	okay, let me go through these
  30 Aug 18 04:40:49 <paolo>	perfect
  31 Aug 18 04:41:35 <muntyan>	1. Yes. it needs lot of tunings but hopefully really small tunings, i.e. normal bugs and small changes, i.e. not much in total
  32 Aug 18 04:42:23 <muntyan>	2. absolutely. i'm just afraid to even say that something is fine (i do hope it's fine)
  33 Aug 18 04:44:54 <muntyan>	sorry, slow typing
  34 Aug 18 04:45:28 <paolo>	no problem
  35 Aug 18 04:45:41 <muntyan>	3. not sure we really need to wait, but i am frustrated enough with printing at the moment (that list of bugs), and it doesn't look like gtksourceview needs gtk printing right now
  36 Aug 18 04:46:12 <muntyan>	i would really love to move printing to gtksourceview though
  37 Aug 18 04:46:34 <muntyan>	if you say it makes sense or needed, i'll do it
  38 Aug 18 04:46:40 <paolo>	hmmm... are you frustrated by gtk+ printing stuff or what?
  39 Aug 18 04:46:51 <muntyan>	yes, with gtk priniting stuff
  40 Aug 18 04:47:04 <muntyan>	i am really frustrated with those bugs which don't get fixed
  41 Aug 18 04:47:09 <muntyan>	a simple example:
  42 Aug 18 04:47:16 <muntyan>	you can't cancel preview
  43 Aug 18 04:47:31 <muntyan>	okay, i go to the code and going to write a cool patch
  44 Aug 18 04:48:09 <muntyan>	but i can't, because it's made in some strange way, preview is some interface, and i can't understand what's going on in there, and i have other things to do, and so on
  45 Aug 18 04:48:13 <muntyan>	another thing
  46 Aug 18 04:48:40 <muntyan>	i thought gtk printing is about multi-platformness, but there's no win32 release yet
  47 Aug 18 04:48:42 <paolo>	I see
  48 Aug 18 04:48:47 <muntyan>	i.e. i hate gtk-2.10 :)
  49 Aug 18 04:48:52 <paolo>	gtk+ printing stuff have serious problem
  50 Aug 18 04:49:04 <paolo>	hehe... ok
  51 Aug 18 04:49:32 <muntyan>	and, e.g. gedit has *better* printing with gnomeprint
  52 Aug 18 04:49:44 <muntyan>	so it really doesn't make sense to rush with gtk printing
  53 Aug 18 04:49:45 <paolo>	I think we can wait for printing (even if we will have to work on it sooner or later)
  54 Aug 18 04:49:59 <muntyan>	of course i don't mind to share my work on it :)
  55 Aug 18 04:49:59 <paolo>	I agree
  56 Aug 18 04:50:10 <muntyan>	okay, let me go farther
  57 Aug 18 04:52:29 <muntyan>	4. one needs to say exactly what he wants from these two guys. not the api, but what's needed.
  58 Aug 18 04:52:46 <muntyan>	4a. the styles thing - do you want live styles scheme editing, or it's fine to create a scheme file once, and then load it.
  59 Aug 18 04:53:34 <muntyan>	4b. this one is harder: for example: you do replace-all, you don't want cursor to jump to last replaced word, it needs some interactive-non-interactive thing
  60 Aug 18 04:54:00 <muntyan>	i.e. these two need special discussion dedicated to them
  61 Aug 18 04:54:26 <muntyan>	normal work, but needs attention and can't be "just done"
  62 Aug 18 04:54:37 <muntyan>	5.
  63 Aug 18 04:54:41 <muntyan>	Yes, it's a bad bugf
  64 Aug 18 04:54:43 <muntyan>	bug
  65 Aug 18 04:54:59 <muntyan>	while it's a rare bug, but i do not think it's acceptable
  66 Aug 18 04:55:25 <muntyan>	user can't cancel highlighting and can't open a file, it's really really lame
  67 Aug 18 04:55:34 <paolo>	About 5, please note that the async file chooser is going to be retired
  68 Aug 18 04:55:41 <muntyan>	paolo: no it's not
  69 Aug 18 04:55:46 <muntyan>	paolo: check gtk-devel :)
  70 Aug 18 04:55:58 <paolo>	oh
  71 Aug 18 04:56:03 *	paolo reads the last mails
  72 Aug 18 04:56:07 <muntyan>	and finally, 6:
  73 Aug 18 04:56:19 <muntyan>	please please look at that highlighting thing
  74 Aug 18 04:56:35 <muntyan>	i stuffed lot of lines of code with noone looked at it
  75 Aug 18 04:56:42 <muntyan>	it needs eyes!
  76 Aug 18 04:57:44 <paolo>	ok
  77 Aug 18 04:58:14 <muntyan>	um, 7.
  78 Aug 18 04:58:25 <muntyan>	the important thing
  79 Aug 18 05:00:21 <muntyan>	soc is going to be over, but not my gtksourceview thing. while i am not going to be a greatest gedit contributor, i do want to work on gtksourceview *at least* for things we are talking about
  80 Aug 18 05:00:37 <muntyan>	e.g. i am not going to stop syntax highlighting after august, 21 :)
  81 Aug 18 05:01:03 <paolo>	this is great ;)
  82 Aug 18 05:01:11 <muntyan>	um, not sure i should have said it, but i have. now time to smoke a bit :)
  83 Aug 18 05:01:20 <paolo>	Then, let us sketch some action plan
  84 Aug 18 05:02:11 <paolo>	- I will spend next days looking at the current code and thinking about the printing stuff
  85 Aug 18 05:02:38 <paolo>	- You will prepare a proposal about the undo manager stuff
  86 Aug 18 05:03:03 <paolo>	- We will meet to discuss about the requisites of the styles stuff
  87 Aug 18 05:05:23 <muntyan>	1) ok
  88 Aug 18 05:06:31 <muntyan>	2) okay, it will be different a bit from what i have now ("groups" needs to be better specified, to allow "Undo This Thing" in menus and such)
  89 Aug 18 05:06:39 *	pbor returns... mission failed :( 10 people before me and the doctor didn't even show up yet!
  90 Aug 18 05:06:40 <muntyan>	3) ok
  91 Aug 18 05:06:57 <muntyan>	pbor: sounds like soviet union :)
  92 Aug 18 05:07:18 <pbor>	sounds like typical italy, even more so in august :)
  93 Aug 18 05:07:26 <muntyan>	a note about printing stuff:
  94 Aug 18 05:08:15 <muntyan>	i feel it must subclass GktPrintOperation, to allow connecting to its signals, the progress and cancel is the main thing
  95 Aug 18 05:09:39 <muntyan>	</note>
  96 Aug 18 05:10:14 <muntyan>	pbor: i knew it was true that italians are good people :)
  97 Aug 18 05:12:51 <paolo>	muntyan: about 2) I'd like to have the possibility to add custom actions
  98 Aug 18 05:13:14 <paolo>	see also the undo manager related bugs in bugzilla
  99 Aug 18 05:14:20 <muntyan>	well, the undo manager itself should not care (it does not) about actions at all
 100 Aug 18 05:14:37 <paolo>	for example I'd like to be able to add a custom action for "replace all" (so that I can store the related info in some more compact way, i.e. not as a sequence of insert-delete)
 101 Aug 18 05:14:53 <muntyan>	it
 102 Aug 18 05:15:03 <muntyan>	's perfectly fine
 103 Aug 18 05:15:10 <paolo>	ATM. it does not expose such details
 104 Aug 18 05:15:20 <muntyan>	question is how to deal with this stuff in the buffer
 105 Aug 18 05:15:38 <paolo>	but it is probably worth exposing the undo manager as a public object
 106 Aug 18 05:15:48 <muntyan>	paolo: well, i mean the new and great undo manager thing :)
 107 Aug 18 05:16:00 <muntyan>	where users tell it to store actions
 108 Aug 18 05:16:07 <muntyan>	okay, i'
 109 Aug 18 05:16:12 <muntyan>	crappy enter key
 110 Aug 18 05:16:21 <paolo>	I have not seen the new undo manager
 111 Aug 18 05:16:29 <paolo>	so I don't know how it works
 112 Aug 18 05:16:30 <muntyan>	i'll try to present better undo manager proposal, i guess
 113 Aug 18 05:16:41 <paolo>	ok, cool
 114 Aug 18 05:16:49 <paolo>	my only requirements are:
 115 Aug 18 05:17:01 <paolo>	- should have all the features of the current one
 116 Aug 18 05:17:08 <paolo>	- should support custom actions
 117 Aug 18 05:17:41 <paolo>	- should undo/redo markers (see bugzilla)
 118 Aug 18 05:18:00 <pbor>	well, that's part of custom actions :)
 119 Aug 18 05:18:30 <pbor>	along the same lines it should allow undo of tag-applying
 120 Aug 18 05:18:30 <paolo>	I'm not sure it is a custom action
 121 Aug 18 05:18:55 <paolo>	- should implements the features written on wiki
 122 Aug 18 05:19:40 <muntyan>	"Store the list of actions on disk???" - crap
 123 Aug 18 05:19:59 <paolo>	it can wait, and may be we don't need it
 124 Aug 18 05:20:02 <muntyan>	the rest looks fine
 125 Aug 18 05:20:25 <muntyan>	(didn't look at gnumeric)
 126 Aug 18 05:20:42 <paolo>	but it would be very nice to have a way to serialize/de-serialize undo lists (for advance session management)
 127 Aug 18 05:21:04 <paolo>	but it is not a requirement now
 128 Aug 18 05:21:07 <pbor>	uhm... doesn't sound like a good idea to me
 129 Aug 18 05:21:08 <muntyan>	well, i don't think it would be difficult, but does it make sense?
 130 Aug 18 05:21:24 <muntyan>	you change a file, or better delete it, and what then?
 131 Aug 18 05:21:38 <pbor>	what if the file and the undo file go out of sync
 132 Aug 18 05:21:45 <pbor>	exactly
 133 Aug 18 05:21:52 <paolo>	the list will be invalidated
 134 Aug 18 05:22:13 <muntyan>	but how can you know when to invalidate? md5 checksums?
 135 Aug 18 05:22:13 <paolo>	but what I mean is that we should expose an API to get the list
 136 Aug 18 05:22:24 <muntyan>	well, that's better :)
 137 Aug 18 05:22:40 <pbor>	but you need sha1 or md5 or... we'll end up reinventing bzr/git etc :)
 138 Aug 18 05:22:54 <paolo>	then super-cool-text-editor-that-wants-to-be-like-emacs will use it as preferred
 139 Aug 18 05:23:05 <muntyan>	i just object to making it make sense between different processes
 140 Aug 18 05:23:28 <muntyan>	err, even different buffers
 141 Aug 18 05:23:33 <paolo>	BTW, as I said it is not a requirement for this first step
 142 Aug 18 05:23:56 <muntyan>	well, as i said, the rest looks fine :)
 143 Aug 18 05:24:16 <paolo>	good
 144 Aug 18 05:24:25 <paolo>	I'd say you can go to sleep :)
 145 Aug 18 05:24:31 <pbor>	hehe
 146 Aug 18 05:24:47 *	muntyan goes to sleep
 147 Aug 18 05:24:53 <muntyan>	so, see you guys
 148 Aug 18 05:24:58 <paolo>	see you
 149 Aug 18 05:25:03 <pbor>	later
 150 Aug 18 05:25:13 <muntyan>	i'm often here in the late night - early morning for you, so we can talk
 151 Aug 18 05:25:14 <muntyan>	:)
 152 Aug 18 05:25:23 <pbor>	paolo: what do you think to add support for gsv2 in gedit cvs? (#ifdeffed and disabled, obviously)
 153 Aug 18 05:25:24 <muntyan>	good night or whatever
 154 Aug 18 05:25:48 <paolo>	dunno
 155 Aug 18 05:26:25 <paolo>	I think we can
 156 Aug 18 05:26:29 <paolo>	- wait for RC1
 157 Aug 18 05:26:35 <paolo>	- branch gedit and gtksourceview
 158 Aug 18 05:26:43 <paolo>	- working on HEAD for both
 159 Aug 18 05:27:50 <pbor>	yeah, I don't care in which branch it goes: my point was about having support for both gsv1 and 2
 160 Aug 18 05:28:30 <pbor>	to allow normal use to casual jhbuilders but also allow easy testing for those interested
 161 Aug 18 05:28:50 <pbor>	without the hassle to keep two branches in sync
 162 Aug 18 05:31:07 <muntyan>	um, while i'm here
 163 Aug 18 05:31:16 <muntyan>	i have a cool plan for merge
 164 Aug 18 05:31:35 <muntyan>	create a new branch, and commit bunch of patches to it
 165 Aug 18 05:31:56 <muntyan>	one patch is to the contextengine, the rest as they are
 166 Aug 18 05:32:10 <muntyan>	since the engine change is one big change anyway
 167 Aug 18 05:32:20 <pbor>	why not just join your branch?
 168 Aug 18 05:32:26 <muntyan>	it will simplify merge
 169 Aug 18 05:32:32 <pbor>	changes on HEAD were minimal
 170 Aug 18 05:32:49 <muntyan>	pbor: for example, because i removed printing :(
 171 Aug 18 05:33:07 <muntyan>	now i think CVS is not as flexible for that
 172 Aug 18 05:33:24 <pbor>	ok, then if you go for 'collection of patches' I'd say to just commit them on HEAD after we branch
 173 Aug 18 05:33:32 <muntyan>	maybe it's crap though, i never did such things with CVS
 174 Aug 18 05:33:48 <muntyan>	pbor: right
 175 Aug 18 05:34:03 <muntyan>	err, not right
 176 Aug 18 05:34:21 <muntyan>	if it gets approved as "do it", then right
 177 Aug 18 05:34:32 <muntyan>	but i'm not sure about it
 178 Aug 18 05:34:33 <pbor>	of course :)
 179 Aug 18 05:34:57 <muntyan>	well, it all goes down to CVS details
 180 Aug 18 05:35:12 <pbor>	we'll see when it's time, I am not that concerned
 181 Aug 18 05:35:35 <pbor>	maybe we'll even have svn at some point
 182 Aug 18 05:35:39 *	pbor dreams on
 183 Aug 18 05:35:44 <muntyan>	i just wanted to say that the history in soc-2006 branch should not necessarily be preserved in HEAD
 184 Aug 18 05:35:53 <pbor>	yep, agreed
 185 Aug 18 05:36:25 <muntyan>	okay, now i'm off. good night, etc.
 186 Aug 18 05:36:40 <pbor>	'night
 187 Aug 18 05:37:37 <muntyan>	okay, so CVS can wait, i guess :)
 188 Aug 18 05:37:47 <muntyan>	you have release soon, and everything
 189 Aug 18 05:37:58 <muntyan>	then we can attempt hard surgery
 190 Aug 18 05:38:11 <pbor>	ok
 191 Aug 18 05:38:16 <muntyan>	okay, i'm really off now :)
 192 Aug 18 05:38:20 <pbor>	:)