Xinha Discussion Forum

I wonder if we even need to set the src in the first place.  If we droped that then the iframe would perhaps be ready to go as soon as we create it and we could then go straight into initIframe from the tail of generate, no need for timeouts or events.

I guess mish must have put it there for some reason though, so perhaps it just doesn't work without some src.

Did you try reordering the fonts in the config?

No, not really.  Ticket submitters could use the keywords field for that if it's specific to a certain platform.

Sounds good to me.

Interesting (and a much better way of doing it BTW).  I wonder if the delay is due to the src we are setting on the iframe.  I have found that recently (last few months) my F/fox installs have been having trouble with local connections, they just get slower, and slower, and slower.  Restart the fox and it's quick again for a while.  It's not anythign to do with Xinha, this is totally without Xinha even in the picture. 

I havn't been able to find any relevant bug reports about it though so I thought it was probably just me.

Hmmmm.

There is something else to consider - debugging, and error messages in general.  If we use XMLHTTPRequest and then eval then the browser can't tie the code to a filename, which makes debugging much harder.

I think we need to stick with inserting script tags in this case.  I'll rewrite loadplugin and loadplugins to solve the problem in 226 .

Exactly.  That was why I didn't go with XMLHTTPRequest to load plugins.  I couldn't come up with any way of getting the code to be evaluated in the global scope (technically the scope of window).

I'm pretty sure I mentioned that somewhere in the past?

Did you have a look at the code that the dude who was working on the Safari stuff did?  How did he do it?

Will & Kim: patches welcome.

Be more specific, what doesn't work?

Taken from dom_checkInsertP this should help

  var sel = this._getSelection();
  sel.removeAllRanges();
  sel.collapse(newblock,0);

that would put the cursor at offset 0 inside newblock (which is just a dom element).

If you don't at least do a cursory test first, yes

Chuck:
for one way see this section of the subversion docs, http://svnbook.red-bean.com/en/1.0/ch07 … 7-sect-4.1
but you might be able to get away with using svn merge, heres how (don't know if this works, worth a try)...

For this example I'll denote revisions in the Xinha svn as X.<rev> and in your own svn as Y.<rev>

To get setup

1. svn export http://svn.xinha.python-hosting.com/trunk wc; cd wc
...this exports a copy of Xinha at revision X.a

2. svn import <Y repos>
...import this into your repository at revsion Y.b

3. Make local changes in your version, after some time you are at rev Y.d

... in the meantime Xinha has progressed to X.e and you want to bring in those changes from us ...

4.  svn co -rY.b <Y repos> wc; cd wc
... this checks out a clean copy of the version of Xinha you imported, ready to be "upgraded"

5. svn merge -rX.a:X.e http://svn.xinha.python-hosting.com/trunk .
... this should merge the changes from X.a (the one you originally imported) to X.e (the latest one) in the Xinha svn into your Y.b revision working copy

6. svn update
... this will update the working copy (which is now X.e) with all the local changes you have made locally up to Y.d

7. resolve any conflicts that might have occurred

8. svn ci -m "Merging changes from Xinha, now at Xinha Rev:X.e"
... this checks in everything, you are now at Y.e

From this point on you just follow this procedure...

9. make more changes, say now you're at Y.g and Xinha is at X.h
10. svn co -rY.e <Y repos> wc; cd wc #get the revision where you synced at X.e previously
11. svn merge -rX.e:X.h http://svn.xinha.python-hosting.com/trunk . #bring in the X.h changes
12. svn update # bring in your local changes (in this case Y.f and Y.g)
13. resolve conflicts
14. svn ci -m "Merging changes from Xinha, now at Xinha Rev:X.h" # commit it

Of course I've shown all this using the command line client, you can do the same thing with Tortoise or whatever, just substitute mouse clicks for commands as appropriate

I wouldn't worry about that too much, I expect that we'll have to make a "Core" package which includes only the core and a couple of important plugins (enterparagraphs, fullscreen) and a "Plugins" package anyway, and perhaps even a package for each plugin.  All automatically of course.

It would be nice though to know where the smileys came from, and what the status of copyright/licencing is on them.

will: almost certainly won't right now, Xinha is full of things to work around problems in both IE and Mozilla as while similar in implementation of contentEditable/designMode they are different - I expect Safari will be different again and require some specialised code.

It's a bit difficult for me to develop for safari, seeing as I don't actually have a mac.