You are not logged in.
So to summarise my rambling, niko if you would like to add the config variable, the meta tag to the iframe and fix up any of those minor character set issues such as in superclean you can handle (you might try a search for utf that should find any), then submit a patch as a ticket that'd be just great ![]()
Ah, man, I'm going senile, I'm sure, I forgot you'd written all that in the first post ![]()
OK... utf-8-encoded pages are working great....
but i have a problem with non-utf-8-pages:
the SuperClean plugin doesn't work correctly when calling tidy.
this is because tidy is called with the parameter -utf8when i not have a page that uses latin1 all chars like üä get replaced by ? when i call tidy.
A solution is calling tidy with the right charset.
But we would have to pass the right charset then to the php-script as get-parameter i think(?)please comment on this - if this would be a solution - i could then write a patch...
Yes, I think we'll need to add a config variable to HTMLArea.Config to specify the character set that should be used, probably defaulting to utf8, I can't find any way to find the character encoding of the page from javascript or we could default it to the correct setting automagically.
Tricky bit is I'm not totally sure how the character set in the iframe is set currently. Well, I do know, it's simply not set, what I don't know is if that means the iframe inherits the page's character set or if it uses the browsers default (which is probably ISO-8859-1 for most). it may be that we will also need to add a meta tag into the iframe to try and persuade it into using the correct encoding.
Can you make a test case and submit it as a new ticket.
hello,
did anyone use Xinha or Htmlarea with a different charsets?
has anybody expirience with utf8?
Yes, I use it as utf8. The one problem with that though is that the translations are not (all) utf8 which kinda messes things up a bit.
When I finish the new translation system I would hope to see translations converted to utf8, possibly they could also made available also in other "common" character sets for the given language.
what is the if (/^@(.*)$/.test(txt)) { good for?
when do we get an @ bevore de dictionary?
why should this one be selected?
I don't know on that one, I dont' think we have the spellchecker plugin author here.
I'll look at your patch tonight with a bit of luck.
It's probably a timing issue. Although I thought I'd got that sorted out. Also the editor would have to be focused (clicked in, with blinking caret) before any of the buttons will work (not sure if it would throw an exception if you tried though.
I should probably make it so the buttons are disabled while the editor is not focused to sidestep that.
In a possibly related question, I just noticed the Cut, Copy, and Paste buttons are missing. Again, the ctrl-c, ctrl-x, and ctrl-v work beautifully, it's just that the buttons are missing.
Is this a ticket issue, or am I missing something obvious?
Yes ticket that too. I probably removed those because they won't work properly in Gecko, but they should really be there by default I guess.
How about allowing users to post comments? Sth. like with online documentation at www.php.net? That way there is clear distinction between 'official' and 'any-user-could-write-this' content.
If it's not too difficult to implement of course... Otherwise there's always forum.
Enjoy!
Anze
My Python isn't up to scratch to start modifying Trac ![]()
So, in conclusion, your only hope is a possible fix in Longhorn, since Microsoft is not planning to update IE until then.
Thats about the size of it, except that MS has indicated they will release a new IE sooner than longhorn now, how much improved it is over the current IE remains to be seen, my guess is some cosmetical stuff and not much more.
There's nothing else we can do, it's very easy to make circular references in javascript even when you don't intend to, and destroying those circular references before you lose a reference to some point in the circle outside of the circle, when the references can be anywhere and everywhere, well, you can imagine how that is unworkable.
P.S. - This problem doesn't happen in Firefox, correct? I guess that is pretty good workaround.
Correct, it's only Microsoft's JScript engine (thier version of Javascript/ECMAScript) which doesn't garbage collect the circular references correctly. It's a bug in there, not with the language.
P. P. S. - Is there anyway to open a new IE "process" (not just a window under the same process) from a link in a webpage in IE?
I shoulsn't imagine so (security hole), even if there were, IE is so tightly coupled to Windows that I expect it woudln't make a difference.
If that is possible (I don't believe it is), you could solve your problem by placing Xinha in the popup, and then the memory would be cleared after the user closed the popup window. Even if this was possible, you would probably have issues with sessions not carrying across multiple IE processes and etc..
Yes I would epect that even if it were possible to have two totally distinct IE processes running at once, that there could be no IPC (inter process communication) between them at the javascript level, for security reasons if nothing else.
I don't know if you read mishoo's article on closures, but he suggests a way around it, it leaves you with the same functionality, but it solves the IE memory leak....
His workaround isn't practical, I don't think we'd ever get all the references before they are lost to us (this is the problem, they become inaccessable to us, but IE still thinks they are alive) so that we could nullify them. It would be a mammoth undertaking.
BTW: I am using Xinha in our production environment now and it seems to work like a charm
Which version are you using Mirical, the nightly?
What is the best way to install the package as a whole? Can I simply put it in a /xinha/ directory, then call it from outside that directory, or will this cause problems?
Yep that's the idea.
You just need to set _editor_url to the base URL where you put xinha before you load the javascript files
<script language="Javascript">
_editor_url = '/xinha/';
</script>
<script language="Javascript" src="/xinha/htmlarea.js"></script>I'm playing with the nightly from 2/25/05. I noticed that there are no "undo" or "redo" buttons, however the ctrl-z and ctrl-y keyboard combinations work nicely. Is this something that was omitted on purpose (for a good reason that I shouldn't be second-guessing), or am I missing something? Is there an option to turn this on?
Hmm. I'm sure there used to be undo & redo buttons. Can you submit a ticket for that.
In summary, I believe the core of Xinha probably uses closures a lot, and it would not be an easy task to remove them. James could probably add more input here, since he probably knows much more about closures than I.
Yes that sounds plausable. Closures are, well, hard to describe, basically when you create a function in javascript it has access (when called) to all the variables that were defined in the same (or ancestor) scope that you defined the function in. Whoosh, that probably went over most peoples heads
They are a very useful feature of Javascript, and you're right, Xinha uses them extensivly, actually, lost of Javascript uses them extensivly because it's kind of a wether you need it or not thing (creating a function creates a closure).
I'd put money on it that it's a recursive reference problem with the IE garbage collector. Essentially a garbage collector runs periodically and frees up memory no longer in use (nothing references it), my thought is that IE's collector is not freeing (indirectly) recursivly referenced memory.
Short answer - can't be fixed.
Long answer - can't be fixed by me.
Hi,
Another point, is that we should be able to define the button image as an international ressource. For example, the bold button, which is a bold B, should be defined as a bold G (gras in french). This is not dificult :
Hmm, good point. I'll have to think how it can be done, considering that the old I18N system is going away.
Hmm. All I can say is that I've never seen this problem, that said I use FFox more than IE so perhaps I've been lucky. I can't really think why it wouldn't work.
Are any javascript errors thrown on the page when it doesn't load up? Perhaps one of those who are seeing it could install the MS Script debugger?
Is there a reason for Stylist to use a lower part of the text area and not a dropdown menu?
Yes, you can apply multiple styles to the selection, simply select something click a style, click another style. That would be cumbersome in a select list.
Is it possible to alter the way the enter key works? I think would be nice to have this feature.
Let's say you have four styles: h1 (Title), h2 (Subtitle), p (Text) and div.quotation (Quotation). The editor should start in 'Title' mode. Then when user presses Enter the editor should automatically switch to Subtitle (of course, the user could change the mode to some other).
When the user is inside Subtitle the enter key should go to Text. Inside Text mode the enter should keep it there, but it should close the current paragraph and start new one ('</p><p>').
Interesting idea. Submit a feature request ticket.
Hmm, yes I've been busy the last week (whats new), I didn't spot those defacements.
I guess I'll lock it down.
Anybody with a trac account will be able to edit it, anyone without won't.
I didn't want to do that but I guess there is no option.
Anybody who wants a trac account post here.
If I put together a list of documents, examples and similar, would you look at them and write comments? Then we could put it all in one (official?) place.
If it helps, I would be more than happy to do it.
Yes certainly! The best thing to do is to start writing it in the Wiki, say at
http://xinha.gogo.co.nz/XinhaDocumentation
then it can be edited by anybody ![]()
Sorry if I was a little unclear (I was pretty damn tired when I wrote that), I meant that I would like to see the flash plugin implemented, I could quite easily convert that into something usefull for myself...
Ahhh, I see. Can you submit a ticket as an enhancement request for that.
Thanx.
I would like to add users the option to add DIVs in text (for quotations and similar). I tried using formatblock for this but somehow can't make it work. Instead of adding '<div>' and '</div>' I get '<<div>>' and '</<div>>' - which is not really useful...
Formatblock can't be used for div AFAIK (this is a built in command of the browser, the browser just doesn't support div as a block).
What I'd suggest is using the stylist plugin for this purpose, http://xinha.gogo.co.nz/cgi-bin/trac.cgi/wiki/Stylist
with a config command something like
cfg.stylistLoadStyles('div.quotation { /* whatever styles in here */ }');
aside from that you might look at the CSS or DynamicCSS plugin but I don't have any experience with those - http://xinha.gogo.co.nz/cgi-bin/trac.cgi/wiki/Plugins
There is no documentation at the moment, infact I've removed all the old documentation because I think it would create more confusion than anything.
The best way at the moment is to grab the nightly (use that it's more or less OK, there are some slight problems) and have a look at examples/full_example-body.html you can use that file as a boilerplate (just read through the source it explains how to use it to set up your own editors).
Any questions, post here. When you've got it worked out perhaps you would like to create a page in the Wiki to help others in the same situation - perhaps http://xinha.gogo.co.nz/NewbieGuide
I found out, that it's a problem with my router / firewall settings. If I reduce safety, the Editor works in Firefox.
What firewall? What does "reducing safety" actually permit I wonder.
By the way, htmlarea forums seem to be closed down for the time being.
I hope that IT doesn't go and delete the forums totally, I should have archived them off for reference.