IRC 2007/02/28

16:46 <@jfhv> OK. Volker and Scott: did you checked out the svn today?
16:46 < lewiscot> No, I haven't. Which version in the branch?
16:46 <@jfhv> The trunk.
16:46 <@vmx> no, i'll take a look (i really like tracs timeline)
16:47 <@jfhv> Many things to say...
16:48 <@jfhv> I've added a basic l10n system.
16:48 <@jfhv> + constants
16:48 <@jfhv> + many options
16:49 <@jfhv> + buttons work in general
16:49 <@jfhv> + switching containers works
16:50 <@jfhv> + a 'hack' with setTimeout for a callback fn
16:50 <@jfhv> OK in IE/OP/FF
16:51 <@jfhv> Volker: we use a specific file for each browser
16:51 <@jfhv> This is done by init()
16:52 <@vmx> jfhv, yes i've seen that
16:52 <@vmx> and there's alsa a "master" file for all of them, right?
16:52 < lewiscot> JF: the more I think about it the more I think this is the correct way to go. We only have to do one browser detect. This should lower the cpu overhead.
16:52 <@jfhv> Yes, jquery.wymeditor.js
16:52 <@jfhv> Yes, I like this method.
16:53 < lewiscot> I like how little code is required. Very nice.
16:53 <@jfhv> Yes. I try to keep the specific files the lighter possible, too.
16:53 <@jfhv> To avoid duplicates.
16:53 <@vmx> can you overwrite functions?
16:54 <@vmx> i mean, can the ff specific file overwrite a function from the general one?
16:54 < lewiscot> JF, so the setTimeout worked?
16:54 <@jfhv> Volker: I didn't test overwriting.
16:55 <@jfhv> Scott: yes!
16:55 < lewiscot> The overwriting should work
16:55 < lewiscot> Excellent. I'm glad that worked out. I think there are some ways to make the technique more reliable. You might try looking at how jQuery handles the document.ready function.
16:56 <@vmx> if overwriting works it sounds nice. i thought about cases where all browsers need the same code, except of one
16:56 < lewiscot> Another option is to hard-code the function you want to be called (setting the html) in the body.onload of the iframe document.
16:56 < dreszka> if you could take a look at my problem... it's visible here:
16:56 < dreszka>  http://trac.wymeditor.org/trac/browser/branches/d.reszka/002/wymeditor/jquery.wymeditor.js?rev=127
16:56 < dreszka> at line 49 where I try to use the value of sToolsHtml in sSectionTopHtml
16:56 < dreszka> if you can give me an advice to make it finally work I would be very very happy ! :)
16:57 < dreszka> ... sorry to interrupt
16:58 <@jfhv> Scott: I tried many solutions. IIRC, one worked well in any browser, except MSIE...
16:58 <@jfhv> You can see an example using setTimeout in index.html
16:58 <@jfhv>  http://trac.wymeditor.org/trac/browser/trunk/src/index.html
16:59 <@jfhv> I find it pretty simple
17:00 <@jfhv> You just have to pass the WYMeditor index (i)
17:00 <@jfhv> $j.wymeditors(i) returns the WYMeditor instance i
17:00 < lewiscot> Yes, it is simple. I ran into a problem with it however in my implementation of Wymeditor for my CMS. If the internet connection is slow you have to set the timeout interval to a higher number.
17:01 < lewiscot> It works but it is not pretty.
17:01 <@jfhv> I agree.
17:01 < lewiscot> Daniel, I will experiment with jquery to see how to work it out. It should not be difficult.
17:01 < dreszka> thank you
17:02 <@jfhv> sorry, phone call
17:02 < lewiscot> It really depends on how JavaScript parses and resolves the object's properties.
17:02 < lewiscot> np
17:02 < lewiscot> I think i have figured out (in theory) how to handle the Safari implementation.
17:02 <@vmx> scott: can you tell me what you are talking about, i can really follow your discussion. i don't know the inital problem
17:03 < dreszka> I know it can be done becouse I foud a way several months ago, but can't remember how I did it :(
17:03 < lewiscot> vmx, do you mean about Safari?
17:03 <@vmx> no the prevoius onw with settimeout
17:03 < lewiscot> LOL. I do that all the time, Daniel.
17:04 <@jfhv> Volker: I'd like to add a callback function to $j(".wymeditor").wymeditor()
17:04 <@jfhv> So you can manipulate the WYMeditor instance
17:04 <@jfhv> When it's ready
17:04 < lewiscot> Oh. JF was having a problem with setting the content of the iframe. The issue was that the setHTML function was being called before the iframe was completely loaded so when he tried to set iframe.content to the HTML, there was not 'body' element present. We used setTimeout to cause the setHTML function to delay by 1 second.
17:05 <@vmx> ok ic
17:05 <@jfhv> (Setting the html value is an example)
17:05 < lewiscot> It is a hack and I think there should be a cleaner, more reliable way to do it but we have not found it yet.
17:05 <@vmx> k
17:05 < lewiscot> JF, I think I figured out how to handle the safari implementation.
17:06 < lewiscot> Safari does not fully implement execCommand but some of the commands are supported.
17:06 < lewiscot> Whenever possible, we will use execCommand
17:06 < lewiscot> where necessary, I will write custom code to handle the commands not supported.
17:07 < lewiscot> As support in safari improves we can change the individual functions.
17:07 <@jfhv> OK, that's what I was thinking.
17:07 < lewiscot> We will need a wrapper for execCommand calls however.
17:07 < lewiscot> This will be necessary in all browser files though.
17:07 < lewiscot> So we would need:
17:07 < lewiscot> wym.execCommand(cmd);
17:08 < lewiscot> wym.prototype.execCommand = function(){
17:08 < lewiscot> ... etc.
17:08 < lewiscot> Then in the safari code, we will need a separate function for each command.
17:09 < lewiscot> For the commands supported natively, we will simply call the native function.
17:09 < lewiscot> For those not supported, we will have custom code to execute the command.
17:09 <@jfhv> OK. See for example jquery.wymeditor.mozilla.js : _exec
17:09 < lewiscot> This will make it easier to strip the custom code out as support improves.
17:09 < lewiscot> Ah, excellent. So you already did this?
17:09 <@jfhv> I guess :)
17:09 < lewiscot> Great.
17:09 < lewiscot> :-)
17:10 <@jfhv> Wymeditor.prototype.exec
17:10 <@jfhv> in jquery.wymeditor.js
17:10 < lewiscot> I'm going to spend a lot of time this weekend researching safari's JS engine.
17:10 <@jfhv> It's a little bit different, but the approach is the same.
17:10 < lewiscot> Cool. I will work with what you have already done.
17:11 < lewiscot> The way I will handle it is this:
17:11 < lewiscot> If the command is supported natively, I will do nothing except call the native code.
17:11 <@jfhv> Yes.
17:11 < lewiscot> If not supported natively, I will create a duplicate of the selection and set a variable to the parentNode.
17:12 < lewiscot> I will manipulate the duplicate then replace the original once the duplicate is changed.
17:12 < lewiscot> it will require some key capturing but luckily most commands are supported.
17:13 < lewiscot> The tough part will be keeping track of the caret pos and the selection range.
17:13 < lewiscot> None of it is too difficult, though.
17:13 < lewiscot> I looked at the Writely.js file and saw some good ideas there.
17:14 < lewiscot> Whatever works for Google should work for us, right?
17:14 <@jfhv> LOL
17:14 < lewiscot> Do we have a target date for release of v0.3?
17:15 <@jfhv> Volker: this is Google Docs
17:15 <@jfhv> I'd like to make a release in March
17:15 < lewiscot> Ok. I will get to work this weekend.
17:15 <@vmx> was that all you had to talk about, is it now my part to talk about my ideas?
17:16 < lewiscot> Yes, I'm done.
17:16 <@jfhv> OK!
17:16 < lewiscot> Which part are you working on volker?
17:17 <@vmx> no specific yet, and i don't know how my time i'll have. but i'm on the gecko side, as i'm a linux user
17:17 < lewiscot> Excellent. I love linux. It's the best.
17:18 <@vmx> and (hopefully) the software design (as i've some ideas) and the "m" in "wym"
17:18 <@vmx> have you all seen my hacked eymeditor?
17:18 < dreszka> scott: let him talk !
17:18 <@vmx> *wymeditor
17:18 < lewiscot> sorry :(
17:18 <@jfhv> Scott:  http://vmx.cx/tmp/wymeditor/
17:18 < dreszka> sorry but I have to go
17:18 < dreszka> bye
17:18 <@vmx> by dreszka
17:19 <@vmx> (i can't type today)
17:19 < dreszka> I'll ask JFH to send me a copy of this session
17:19 < dreszka> bye
17:19 <@jfhv> (the session is logged)
17:20 <@jfhv> (it will be available on the wiki)
17:20 <@vmx> ok, so the basic i have is based on the ideas lyx have. do you know lyx?
17:20 -!- dreszka [n=admin@…] has left #wymeditor []
17:20 <@jfhv> A little...
17:21 <@vmx> you can't to things, that you dn't mean. e.g. an empty paragraph isn't allowed, it won't make any sense
17:21 <@vmx> if you'd like more space you should change your stylesheet, not the markup
17:22 <@vmx> it's the smae with indenting with spaces
17:22 <@vmx> do you like the way it currently works?
17:23 < lewiscot> I like what I have read so far.
17:23 <@jfhv> Actually, this is WYSIWYM.
17:23 <@vmx> ok i'll come to the software design
17:24 <@vmx> we should have some documentation on what should happen when
17:24 <@vmx> like: what happens if you press enter at the end of a headline
17:25 <@vmx> or: if you have selected bold formatting and press enter, should the next line also be bold
17:25 <@vmx> so that everyone who implements for a specific browser know what should be done
17:26 < lewiscot> vmx: I agree. We need to think out the scenarios and make decisions before writing any code.
17:27 <@jfhv> Not so easy in a web-based editor, but I agree.
17:27 <@vmx> why not?
17:27 <@vmx> do you think of written scenarios or a diagram. i think a diagram would fit best. it could like a state machine
17:27 <@jfhv> Because we use designMode, and we don't control it.
17:28 <@vmx> we can control it. that is anpther point
17:28 <@vmx> one i'm not sure about
17:28 <@jfhv> MSIE is really crazy...
17:28 <@vmx> how much should we stop the designmode what he does by default
17:28 <@jfhv> I've had many, many problems in MSIE
17:29 <@jfhv> FF is better
17:29 <@vmx> if you take a look at my code, you'll see that i often stop the events completly and do what i want then
17:29 <@jfhv> Yes, I saw that. I'm impressed!
17:30 < lewiscot> vmx: I agree with what you are saying. I think the most maintainable and forward-compatible solution is to not break designMode unless it is absolutely necessary.
17:30 <@vmx> that isn't that nice but sometmes the only solution, e.g. if you press enter at the end of a headline, it inserts two "<br>" (msie also does that)
17:30 <@vmx> but we like to have a "<p>"
17:31 < lewiscot> agreed
17:31 <@jfhv> FF uses lots of <br> in designMode
17:32 <@vmx> tightly connected to that problem: how should the code wymeditor creates while editing look like
17:32 < lewiscot> question:
17:32 < lewiscot> should we remove the <br> tags as the user types or during idle time?
17:33 <@vmx> that would have been my next point
17:33 < lewiscot> :-)
17:33 <@vmx> there a two ways: cleanup at the end of the session, or while editing
17:33 < lewiscot> yes, that is what I was thinking too
17:33 <@vmx> i think cleanup while editing would be nicer
17:33 <@jfhv> At some time, I used to remove the <br> while editing, but that causes problems
17:33 < lewiscot> I can see a benefit in both approaches
17:34 <@vmx> in my prototpye you can see that it would work while typing
17:34 < lewiscot> cleaning while typing is visually nicer
17:34 < lewiscot> on the other hand, the code will probably be simpler to clean up during idle time
17:35 <@jfhv> This was a bu I had to fix in 0.2
17:35 < lewiscot> Do either of you know much about regular expressions?
17:35 <@jfhv> bug
17:36 <@jfhv> Medium knowledge
17:36 <@vmx> the disgnmode in ff acts strange, but almost everytime the same way, so you could "repair" it immediately
17:36 <@vmx> medium
17:36 < lewiscot> I was just wondering which is less cpu intensive: dom manipulation or string manipulation with regex.
17:37 < lewiscot> My guess would be dom manipulation but I don't know for sure.
17:37 <@vmx> the approach in my prototype was, zthat i sometimes double check if there aren't any unwanted tags
17:38 <@vmx> if you try keep the markup always clean i think you'll have smaller problems
17:38 < lewiscot> good thinking
17:38 < lewiscot> perhaps I have an idea:
17:38 <@vmx> think of very long editing session, how would the markup look afterward. how many "<b></b>" will there be?
17:39 <@jfhv> BTW: MSIE always rewrites what you've cleaned up
17:39 < lewiscot> we could have a "cleaner" function that each time a keyboard event occurs, the current node is run through the cleaner.
17:39 <@vmx> scott i think this is to much unneeded overhead
17:39 < lewiscot> ok
17:40 <@vmx> but the diea is good
17:40 <@vmx> a general cleanu function
17:40 < lewiscot> so should the cleaner be conditional on certain events?
17:40 <@vmx> yes
17:40 < lewiscot> Oh, I just realized that is what your code is already doing.
17:40 <@vmx> e.g. if you press backspace at the beginning of a paragraph, when two paragraph get joined
17:40 <@vmx> yes
17:41 <@vmx> as you know what can and should happen if you perform an action
17:41 < lewiscot> someone mentioned a state machine a bit earlier. I think that is the correct thinking. Who mentioned that?
17:42 <@vmx> it was me
17:42 <@jfhv> Volker: I guess you've modified something in  http://vmx.cx/tmp/wymeditor/ - it doesn't work anymore in my FF.
17:42 <@vmx> no i haven't, i'll take a look
17:42 < lewiscot> JF, I have a suggestion:
17:43 < lewiscot> While you and I are working on the core functionality in each browser, perhaps volker could be in charge of code cleaning.
17:43 <@vmx> jfhv: there#s a bug sometimes if you press backspace just after it was loaded
17:43 <@vmx> jfhv: type soemthing first and then you can do what you want
17:44 <@jfhv> Well, I get an error when I click to get the cursor
17:44 <@vmx> i don't get an error, which version of ff are you using?
17:44 <@jfhv> 2.0.0.2
17:45 <@jfhv> I get an exception: nsISelection.getRangeAt
17:45 <@jfhv> line 505
17:45 <@vmx> hm i use 2.0.0.1 but that should make a difference (as 2.0.0.2 was a secutiry update)
17:45 <@jfhv> NS_ERROR_ILLEGAL_VALUE
17:45 <@vmx> scott, does it work for you?
17:46 < lewiscot> Yes. I'm using FF1.5 on Mac.
17:46 <@jfhv> I can delete, but I can't write.
17:46 <@vmx> jfhv: what are you doing? can you reproduce the bug?
17:46 < lewiscot> volker, can you add a button show the textarea content?
17:46 <@jfhv> Yes. I do CTRL+F5, and the I click in the editor.
17:47 <@jfhv> I get: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsISelection.getRangeAt]" nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)" location: "JS frame ::  http://vmx.cx/tmp/wymeditor/wymeditor/wymeditor.js :: selection :: line 505" data: no]
17:47 < lewiscot> JF, it sounds like an empty selection exception.
17:47 <@vmx> scott: i use firebug for debugging, so i haven't needed it. in addition i had no time to look how you add such a button
17:48 < lewiscot> np
17:48 <@vmx> i'll have a look at it, just booting another pc
17:48 <@vmx> ok another thing i'd like to talk about
17:49 <@jfhv> I've restarted FF. It works now.
17:49 <@vmx> ok :)
17:49 <@vmx> what do you think about wiritng code that could be easily used as jquery plugin for others
17:50 <@vmx> e.g. my allChildren() function. it returns also textnode, what jquery doesn't do
17:51 <@vmx> this could easily go to a "general purpose utility file"
17:51 <@jfhv> Yes, so you mean using extend?
17:52 <@jfhv> $.fn...
17:52 <@vmx> yes
17:52 <@vmx> as you can see at the end of my file
17:52 <@jfhv> yes, I saw that
17:52 <@jfhv> It's OK, of course
17:52 <@vmx> anotr problem are "phantom nodes"
17:53 <@vmx> these only occur in gecko afaik
17:53 <@vmx> should the code to handle them go to thegecko specific file, oder to the genera one
17:54 <@jfhv> In the Gecko one, I guess
17:54 <@vmx> i'm not really sure
17:54 <@jfhv> In MSIE, you've also 'phantom nodes'
17:55 < lewiscot> I think a wrapper should go in the general code with a browser-specific function in each browser.
17:55 <@vmx> oh, i din't know that
17:55 <@jfhv> &nbsp;
17:55 < lewiscot> How and when do the phantom nodes appear?
17:56 <@vmx> jfhv, i think you mean empty nodes, not phantom nodes
17:56 <@vmx> phantom nodes are between tags (elements)
17:56 <@vmx> if you have "<tr>\<td>..."
17:57 <@vmx> gecko will return on <tr>.firstChild the "\n"
17:57 <@vmx> sorry, it should read "<tr>\n<td>"
17:58 <@jfhv> Well, IIRC, MSIE uses lots of &nbsp; (but in the numeric format)
17:58 <@vmx> jfhv, ic
17:58 < lewiscot> It seems to me that in both cases we are talking about unwanted white space.
17:58 <@vmx> again the allChildren() example. the removal of phantom nodes could be easily implemented there. if you put it into the gecko file, you would need t implement it again, just for one if statement
17:59 < lewiscot> Isn't what you both are talking about part of the code cleaning?
17:59 <@vmx> it's just an example, i think we should use more such wrappers
18:00 <@vmx> celaning phantom nodes it too much work imho
18:00 <@vmx> not to much work to implement but for the cpu
18:01 < lewiscot> Perhaps we should use both an "as you type" cleaner, and a "tyding" cleaner that is run at end of session.
18:01 <@jfhv> That's what is done in 0.2
18:01 < lewiscot> the "as you type" cleaner would be event-triggered and the tyding function would only look for specific things like phantoms.
18:01 <@vmx> yes, of course. phantom nodes occur to often to celan them on typing, and an idented source can also be nice
18:01 < lewiscot> ack, JF.
18:02 <@vmx> without phantom nodes there code will be in one long line
18:02 <@jfhv> I try to handle bad events while editing, and I clean up the code at the submit
18:02 <@vmx> i've one last big thing
18:02 < lewiscot> I think you are both on the same page and essentially saying the same thing.
18:03 <@vmx> we need a selection api
18:03 < lewiscot> I agree.
18:03 <@vmx> the idea is from kupu editor
18:03 <@vmx> it wrapps the selection, and therefore supports some highlevel functions
18:03 < lewiscot> vmx, do you have a link to kupu editor so I can check it out?
18:04 <@vmx> the main code os for all browsers, and some of the code needs to be browser specific
18:04 <@vmx> scott: this is the dev page  http://kupu.oscom.org/
18:05 <@jfhv> jquery.wymeditor.js: Wymeditor.prototype.container
18:05 <@vmx> and this the current one  http://plone.org/products/kupu
18:05 < lewiscot> I just found it. Thanks.
18:05 < lewiscot> I have a suggestion that I think will make future development eaiser.
18:05 <@vmx> the essitial code is in "common" (hard to find imho)
18:05 < lewiscot> ok, thnxs
18:06 <@jfhv> And WymClassX.prototype.selected
18:06 <@vmx>  http://codespeak.net/svn/kupu/branch/plone-2.1/common/kupuhelpers.js (search for BaseSelection)
18:07 <@jfhv> WymClassX.prototype.selected returns the selected container
18:08 <@vmx> jfhv: we need far more fucntionality, in addition the selection api of the browser is very different
18:09 <@vmx> take a look at my code again. i've tried to do it as general as posible. functions like "isAtStart" can nice in many situations
18:10 < lewiscot> vmx, I understand what you are doing. I think you are on the right path.
18:10 <@vmx> we should wrap the whole selection into our slection object. at the moment i sometimes use the original selection
18:10 <@vmx> so that we have one selection object that is crossplatform
18:11 <@vmx> this is also a part where i think tests would make sense
18:11 < lewiscot> Similar to the way jQuery returns a selected object?
18:11 <@vmx> so that "isAtAtart" really retuns true on the same cases on all browsers
18:11 <@vmx> how does jquery return a selected object?
18:12 < lewiscot> if you do $("#foo"), a DOM object is not returned but a JS object with the DOM object embedded.
18:12 <@vmx> yes
18:12 < lewiscot> JF, what do you think?
18:12 <@vmx> but almost all dom functionality should be wrapped
18:12 < lewiscot> so essentially, we are always performing operations on a clone?
18:13 <@vmx> yes, but sme operations will be cheap as the only clone the value of the dom object
18:13 <@vmx> but most of the time we don't need those dom functions/attributes
18:14 <@vmx> as they aren't that sane. we'll create our own sane ones
18:14 <@vmx> have you had a look at the dom selection api?
18:14 < lewiscot> JF, I think this is the way Writely does it using documentFragment
18:14 < lewiscot> Not sure, though.
18:15 <@vmx> e.g. the "anchorNode" returns the node you started the selection, if you select from back to front, it returns the node at the back
18:16 <@vmx> but most of the time you aren't interested in the way the user selected
18:17 <@vmx> so a documentation about what (sane) funvtions are needed (and what they'll do) should be written
18:18 <@jfhv> OK. I didn't have the need for such API in 0.2, so I'll think it over. I'm sorry, I have to go now. I keep my IRC client open, so the session keeps logged.
18:18 <@vmx> ok, cu jfhv
18:18 <@jfhv> ... and you can continue the discussion
18:18 <@jfhv> ciao!
18:18 < lewiscot> a bientot, JF.
18:19 <@jfhv> oui, à bientôt! Very interesting discussion, BTW!
18:19 < lewiscot> j'suis d'accord.
18:19 <@vmx> if course with selection don't only mean selected text, but also the current cursor position
18:20 < lewiscot> JF, I want to talk to you about some non-wymeditor stuff when you have time.
18:20 <@vmx> e.g. the cursor can be in a text node, but also between element nodes, which makes a big difference
18:20 < lewiscot> vmx, I agree. I think you are on the right track with your thinking. I have been thinking very similarly about wymeditor:
18:21 < lewiscot> a state engine, working on a clone, etc.
18:21 <@vmx> that's nice. so were are probably on the right track
18:21 < lewiscot> I think so.
18:21 < lewiscot> I think before we start coding we should do 3 things:
18:22 < lewiscot> - create a list of the functionality to be supported e.g., bold, italic, insert image, etc.
18:22 <@vmx> and i think we should right test for the selection api, as this one of the most important things with a great spot of problems
18:22 < lewiscot> - create a diagram for each browser of the support for each function and compare each browser
18:23 < lewiscot> - write out detailed scenarios of how to handle each situation
18:23 < lewiscot> I agree with your idea on testing the selection api
18:23 <@vmx> your points are good, i agree
18:24 < lewiscot> Before we write code to perform operations we should know that we can monitor the current state of the document, selection and events
18:24 < lewiscot> and correctly in each browser
18:25 < lewiscot> If we can create a representation of the selection in a wymeditor-native object, then we do not have to worry so much about browser-specific code.
18:25 < lewiscot> very good idea, btw
18:25 <@vmx> yes
18:25 <@vmx> a thing that comes to my mind. if jquery is used, we should code upwards compatible
18:26 <@vmx> e.g. use ".attr('name')" instead of "name()"
18:26 < lewiscot> I agree.
18:26 < lewiscot> ok, I have to go now. Welcome aboard and it was a good discussion.
18:26 <@vmx> ok
18:26 < lewiscot> ciao.
18:26 <@vmx> cu
18:27 <@vmx> that's it, thanks for the great discussion