You are not logged in.
gogo wrote:Hi Yermo, feel free to include any (preferably working
) plugins you want in the plugins directory, just make sure there is a README or something to show what's required to run them, and then add to the example (mostly you should be able to just add a new checkbox to the example menu and it will work).
It took me a while but it's done. A modified version of Wei's ImageManager has been checked in and the full_example.html has been modified with a checkbox for the ImageManager.
There is a README.txt. I've set it up so that hopefully for the majority of people "it will just work'.
Users may have to tweak the "images_url" config setting in config.inc.php if they did not unpack Xinha in the DOCUMENT_ROOT.
Unfortunatly, that probably means it's not going to work from the examples page here. Is there any way of making it use _editor_url?
The other way forward, is to make enter do a <br />, and detect two enters in a row in which case it becomes a <p>. But I have the distinct impression that would be a really difficult code.
You also need to be aware of <li> (maybe others?) because in that case you want to create a new parapraph (which happens to be an <li>) on the first enter.
<p>this is a</p><p>test line</p>which would appear as
this is a test lineOne would like this to behave as a single paragraph so we can set properties on it.
Well, you'd think that, but if we are modelling things on the way that Word et al work, that's exactly what they do (I think, at least in the OOWriter instance I'm looking at now). You can see this simply by entering
fooo<hit enter>
barplace the cursor in fooo somewhere and hit right align, you'll see that only that line aligns, because they are distinct paragraphs. If on the other hand you do
fooo<hit shift-enter>
barand cursor into fooo and right align, you'll see both lines align because effectively they are the same paragraph. It's plain crazy if you ask me.
<p><span class="softline">this is a </span><span class="softline">test line</span></p>What do you think?
Mmm, I really don't like that at all. But as long as it's a plugin that does it I don't give a crap ![]()
Actually, can somebody who has MS Word handy confirm that it behaves in the same way?
If you have a look at the "generate" function in htmlarea.js you'll see how the editor is "built up", specifically everythign is put into a div which is referenced as editor._htmlArea, I'd put it in there...
var fr = document.createElement('iframe');
fr.style.backgroundColor='window';
fr.src = _editor_url + "plugins/Helene/editor.html";
editor._htmlArea.appendChild(fr);Cool... let me see if I can figure it out...
If you get it working (or even partially working) I think this would be a [bold]very[/bold] popular addition to Xinha, particularly when we get some sort of "shielded" code happening. I'd love to see the resulting plugin in the Xinha package. If you want to do it in the Xinha subversion repository I'm happy to accommodate, just let me know.
The "natural" way to put a blank line between paragraphs is to hit enter twice, you don't want to force people to have to do shift-enter to make a blank line (which would only do a linebreak, not a new paragraph, anyway).
So if they do that (hit enter twice) then currently (with enterparagraphs, and probably in IE but I havn't checked) we get something like
<p>Foo</p>
<p></p>
<p>Bar</p>What you (adamp) are suggesting I think is
<p class="x_normalParagraph">Foo</p>
<p class="x_linebreakParagraph">Bar</p>and what I am suggesting is
<p>Foo</p>
<br />
<p>Bar</p>the developer can then use CSS selectors like
p+br { display:none; }if they want to hide the "extra" break and use margined paragraphs; or
p { margin-top:0px; margin-bottom:0px; }if they want to use non margined paragraphs and use the explicit "blank line".
however I think we would need to add a class to the <br /> because I don't think that IE supports the adjacent sibling selector.
I think my way is cleaner (I like to see the HTML out of Xinha be as clean of "Xinha specific oddities" as possible).
All that said however, the use of paragraphs in this way I personally feel is wrong, and unintuitive. Even in OOWriter or Word I often mistake adjoining no-blank-line paragraphs as a single paragraph and am surprised when I change a paragraph property only to have it change only part of what I thought was a paragraph. And also, if we did this (via config value of course) and the user did enter thier data in this way, then it probably doesn't make sense for the data to be displayed with normal paragraphs any more, in which case perhaps it is better to add specific styles.
All you need to do is override HTMLArea.prototype.getHTML() with your own function which
a) if your "helene" editor is currently displayed, returns the content from that
b) otherwise returns the content of the original getHTML..
I think something like this would work..
function HeleneEditor(editor)
{
this.editor = editor;
var helene = this;
editor.getHTML_pre_helena = editor.getHTML;
editor.getHTML = function() { return helene.getHTML(); }
}
HeleneEditor.prototype.getHTML = function()
{
if(this.isActive) return this.someContent; // whateever, pseudo code of course ;)
return this.editor.getHTML_pre_helena();
}There should be an attach file button on the ticket.
Code+bugfixes are worth more than money ![]()
Could somebody try out the method I posted http://xinha.gogo.co.nz/punbb/viewtopic … d=460#p460
and let us know how well it works. Particularly with respect to doing a double-enter to get a blank line.
If that is done, then how would you get actual spacing when we do want space between paragraphs? From what I understand and have seen, if you set the margins to the <p> to 0, then you will not get the any spacing between text when you want it. I think Yermos solution of the 2 classes is a good idea, unless there is something I am missing regarding the <p> set to 0.
Hmmm. Yes that's a good point. It may work already, but if it doesn what we would need to do is insert a non-breaking-space ( ) into blank paragraphs (<p></p> or <p/>). That would do the job (the would create the "blank line" you are seeking).
Actually, thinking about it more, it might be better if <p></p> and <p/> were converted to a <br/> in thier entirity, so as to avoid meaningless paragraphs like <p> </p>
ie..
<p>Blah</p>
<br/>
<p>Foo</p>
this would also give the desired effect I think. We could also add a class to the <br/> so we can distinguish it from "explicit" breaks created by SHIFT-enter
<p>Blah</p>
<br class="xinha_implicit_break"/>
<p>Foo</p>
so if the developer wanted to remove those breaks they could using CSS (.xinha_implicit_break { display:none} would probably do it).
I think a simple check of the DOM when hitting enter (at the very last step, after enterparagraphs etc) would do that (getElementsByTagName('p') and check for childless ones that are not currently "focused", convert to breaks and add a class).
Have you had a chance to put up that donations page?
Not yet, no.
One of these days.
That said, setting textarea.value should work fine too.
Check it out against a fresh copy of the nightly, I can't think of anything that would do that.
I've always just put it in the textarea body using (more or less) htmlspecialchars.
Yermo, perhaps you would like to look at including EFM as well (if the licence permits, I havn't looked at it), I think it's a quite popular plugin so would be good to have it there (particularly in the examples).
I think it would probably be possible without modifying htmlarea.js.
I don't think I'd define a new mode, perhaps set the editor to text mode, and then hide the textarea again and "overlay" your source-editor iframe in it's place. This will turn off the buttons that are active in wysiwyg mode.
If you do need to modify htmlarea.js thats ok, as long as it doesn't break anything existing.
Using Internet Explorer 6.0 . Firefox does not seem to exhibit this problem.
I'm trying it out with the full-example.html, insert by clicking on the "Insert special character" icon.
Hope that helps. Do you still need me to submit a separate ticket for this bug?
BTW, I've using the nightly download version about 2 - 3 days back.
Yes if you havn't submitted a ticket please do. Also if you could attach a screenshot illustrating the problem to the ticket.
Sorry, my bad, was trying to get it running under mod_python, only to discover it doesn't work using mod_python on apache 1.x, only 2.x. I didn't put things back quite right
Fixed now.
I've added a patch to Trac to fix the problem with browsing source code, and have denied most robots from spidering the site, as Slurp was doing some serious hitting I've left it open for Google to spider everythign except source, tickets, roadmap etc (everything except wiki and forum basically).
It may be that the somewhat load inducing nature of spiders was killing things, so lets see if the situation improves.
Fingers crossed everybody.
Yes I found that thread, see my post there.
There are a few things I'll point out here.
1. There was a bug in EnterParagraphs (that I think I introduced) that made enter effectivly do a double paragraph break. This is the same bug that stopped lists from working properly. It was fixed a while back.
2. P is the preferred markup because that's the way that word processors work, hitting enter produces a new paragraph rather than a line break. The difference is that in html P creates a top/bottom margin. In word etc it doesn't (at least, in OOWriter which I'm looking at right now), you can see this in say OOWriter or Word (havn't actually looked, but I guess) by typing some text, hit enter, type some more, then right align - only one of the texts will align, because they are separate paragraphs. If you use shift-enter then both will align because they are the same paragraph.
Because of that, I think the best solution is for the developer implementing Xinha to just use CSS to style-out the margins of paragraphs defined within content that has been edited by Xinha.
I don't see how it would be a problem for the developer to do
<div class="fromxinha"><?php echo $stuffFromXinha ?></div>and have CSS with
.fromxinha p { margin-top:0px; margin-bottom:0px }and similarly
config.pageStyle ='p { margin-top:0px; margin-bottom:0px; }'I don't see a reason for there to be code included into xinha to accomplish this, as long as what Xinha produces is wellformed HTML markup, the developer can use CSS to do whatever he/she wants with it.
Since this is not meant to be a spam post, I will not post the url. Contact me if you want more details.
We're not competing with anybody, feel free to post the URL to the editor if it does something better (or worse
) than Xinha so we can learn from it ![]()
I'm looking for suggestions on how to deal with this problem right now. I seem to remember that in HTMLArea 3 there were some way to work with forms inline, but right now there doesn't seem to be a good way.
Forms may or may not work for you
Please submit a ticket for this so we can look at it at some stage.
Indeed, if you start the editor in a display:none area, things will be, err, fishy to say the least (actually it used to be that moz would crash if you tried to do that).
I'm working (on and off) on fixing up the sizing (and resizing) of the editor, at the same time as I put in some small support for skins and fix up the toolbar problems.
You may find it's better to use
config.pageStyleSheets.push('/htmlarea/screen.css');
but please submit a ticket for this anyway.