You can clone with
HTTPS or Subversion.
Will this be fixed?
Would you accept a port of the respective cocotron obj-c classes (MIT-license)?
I'm not a licensing expert, but I think we have other cocoatron inspired code in the framework so it should be fine. Be aware that this, even with example code, is a very complex task.
That said, I do encourage you to work on it if you have the time. I believe that if someone started work on it, the community will quickly help out to fill in the gap.
The relevant portion of the Cocotron license:
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights to use,
copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the
Software, and to permit persons to whom the Software is furnished to do so,
subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
So licensing is not an issue. Actually implementing NSTextView in a browser is no joke. To fully implement it would mean doing your own text drawing and not rely on the underlying or elements.
Post something on the mailing list, a few people have already done some work on this. Better to benefit from their work or join forces than to start from scratch.
The goal was to build it on top of CoreText (which no longer seems like a priority for @nciagra). It would be nice if you could start by finishing the CoreText branch of Cappuccino, and building on top of that. :)
Contact Nicolas Goy firstname.lastname@example.org, he has been working on CoreText/CPTextView.
the core text project is currently idle on the side of nicolas goy
Just to share some notes I made:
I cannot work on the project right now, but I'd be delighted to discuss about it.
It's a hard problem but not as hard as all that. A TextView based on the CoreText branch was demonstrated at last year's CappCon. It included selection, keyboard navigation and all the other things you might expect.
Cappuccino is pretty good with measuring font metrics even within the limitations of the browser. See CPPlatformString metricsOfFont: and CPString sizeWithFont:.
I don't expect we'll ever do anything using one div per character. That's been tried before in Cappuccino apps and the performance is awful. Probably we will use canvas when available, and when not and we need to degrade I'd imagine one span per CTRun, not one per character.
I doubt we will see the TextView from CappCon materialise. Still, its existence shows that with the current CoreText branch, it's very doable as soon as someone volunteers time or money.
i indeed found some stuff at github (emaillard/cappuccino) that follows the canvas approach.
i ported it to the current version of cappuccino. basic functionality is actually there after a bit of tweaking and debugging. i put a demo on http://aug-fancy.ukl.uni-freiburg.de/NewApplication/.
However, the code still needs tons of debugging/profiling and i have currently no idea how to get native copy/paste working without native text elements.
Without looking at your code, I'd like to make sure you're using Cappuccino's built in copy/paste method calls... I believe they're part of CPResponder.
In order to use the native clipboard we need to add an invisible textfield to the page, set the value of the field to the string being copied, then select the text when onCopy or onBeforeCopy is called... Whatever it is. But, I thought Cappuccino already did that...
thank you for the hint. however, from the online documentation, only CPTextField implement copy/paste. Furthermore, these methods do nothing when called in browser environment.
please see https://github.com/daboe01/CPTextView for the stuff that i have so far
The text drawing in canvas looks terrible, and the performance is currently unusable based on the examples I have seen.
This is definitely something that needs addressing. If only we had access to the google docs engine or something like that.
Milestone: Someday. Labels: #accepted, #needs-patch, AppKit. What's next? This issue needs a volunteer to write and submit code to address it.
i just updated my CPTextView repo to use spans instead of canvas drawing. this seems the way to go.
new demo: http://aug-fancy.ukl.uni-freiburg.de/CPTextView
old demo: http://aug-fancy.ukl.uni-freiburg.de/NewApplication2
Definitely better than canvas. Still has some issues as I’m sure you know. Seems you are defining a TCL-like language using Cappuccino, no?
Looks nice. Why do the spans have <br> in them?
the br' s obviously come from including the actual newline-character into the span. i will fix this, thanks.
hi aparajita, i am aware of the issues. a lot are already fixed in the repo. i cannot update the demo from home. the demo is actually a demo for https://github.com/daboe01/cappusance :-)
i just put a new demo online that has a bunch of issues fixed and also demonstrates some basic rich-editing capabilities.
I cut out some text and pasted it back in and it appeared in a different place than where I cut it.
thanks for the feedback! i just fixed your issues in my repo on https://github.com/daboe01/CPTextView. however, the fontpanel looks awful and needs to be redone.
i also fixed keyboard navigation issues and added color support (including drag-accepting from color-panel).
all in all, i do not see serious issues anymore.
the performance seems quite ok (at least for one-page documents) without looking into optimisation at all.
what do you think?
i can update the demo-app only early in next week. you can download the demo from my github if you do not want to wait.
i updated the demo app. remember to clear the browser-cache.
daboe01, this is some seriously amazing work!
Can't wait for this to make it to master.
I'm curious - how does the font panel know which fonts to show? I ask as I have installed 9 800 fonts recently and loading font menus takes... a while, so I wonder if there would be any performance issues there.
Huge progress, selection works better, font panel works for me now, cut and paste on the same spot does what's expected. Here's another small bug: I selected the final e of the red title and the first character of the next line and did a "cut" - this caused the formatting of the title to be lost.
i have seen this also. it is actually a bug in CPAttributedString. the fix is non-trivial :-(
the fontpanel uses [[CPFontManager sharedFontManager] availableFonts] for the list.
yet another update! critical patches to CPAttributedString, copy/paste, undo, more bugs fixed.
NEW: CPParagraphStyle + Font panel now observes the selection + several bug fixes.
clear browser cache before loading the demo.
i did not get any feedback on bugs or missing features so far.
do you guys think, my stuff is mature enough to warrant a pull request?
I have a very small one and that is when alt selecting words with the keyboard arrow keys ( <- and -> ) the word gets correctly selected but also an extra space. This differs from Cocoa.
When you make a selection and then press the right arrow key (without holding shift or anything) this should happen:
Currently the cursor seems to be moved to the left side of the previous selection (probably the range .location).
You can copy and paste working code from CPTokenView - it already handles a lot of these selection situations. You'll find code for moveRightAndModifySelection: etc too. If you use all of these standard methods you get key bindings support.
// Right arrow
if ((_selectedRange.location < [[self _tokens] count] || _selectedRange.length) && [self _editorValue] == "")
// Place the cursor at the end of the selection and collapse.
_selectedRange.location = CPMaxRange(_selectedRange);
_selectedRange.length = 0;
// Move the cursor forward one token if the input is empty and the right arrow key is pressed.
_selectedRange.location = MIN([[self _tokens] count], _selectedRange.location + _selectedRange.length + 1);
_shouldScrollTo = CPScrollDestinationRight;
// Allow cursor movement within the text field.
[[[self window] platformWindow] _propagateCurrentDOMEvent:YES];
Great work so far. If you're ready for some feedback, here are some details about keyboard control that aren't quite right yet.
N.B. For shift-based text selection, to get correct behavior, keep in mind that we are just moving the caret from its current position to a new position, and adding anything unselected in its wake to the selection, while removing anything already selected in its wake from the selection. Also, the caret is always in the position where the selection was finished. So if I select the word 'finished' from back to front, the caret is before the letter f.
Anyways, I have quite a list here. I'll be happy to test on Win and Mac when you have new upgrades.
thank you very much for your valuable feedback. @kerusan : should be fixed now. @aljungberg : should be fixed now. @Timovzl : proper shift+arrow support required hefty refacturing, but it was worth it. thanks for pointing this out.
IMHO we should not mimic the platform (as we do not mimic the native controls). maybe this should be voted on the usenet. Anyway, this cannot be done in CPTextView because the actual modifier keys are abstracted away in CPKeyBinding.j.
any more issues?
Yes it seems like
when alt key and arrow key is pressed you save a (alt) start position. This position does not get cleared right.
1. Place the cursor in the middle of a word.
2. Press alt & arrow keys to go to the next word
3. Release the alt key. Now we are standing at the end of the word.
4. Press Shift-alt arrow. Now the selection starts in the middle of the word where we started, not from the position at the end of the word where it should.
This error complies to all the arrow keys up, down, right and left.
Keep up the good work, this is fantastic.
good news: i reached my personal milestone! all critical issues fixed that i was aware of.
would you prefer a PR with all classes in the main AppKit directory? Or do you guys fancy a CPTextView subdirectory inside?
How many classes are there? If you already have a branch it'd be fine to just make a pull request out of it - it's good to have the full commit history, which can be very helpful when tracking down issues (as opposed to 1 enormous rebased commit).
IMHO no way to keep the full commit history.
At the moment, it is a standalone framework with 13 files (10 are new).
Three of the 13 are CPText.j, CPAttributedString.j and CPFontManagerAdditions.j. These comprise of monkey-patches for Cappuccino issues.
there already is PR #2045 for CPAttributedString.j
would you recommend separate PRs for CPFontManager and CPText?
or should i put it all in one PR?
I'd recommend separate PRs.
thank you for the recommendation.
however, it turns out more complicated.
i have to move a lot of constants around to get rid of all circular inclusions.
the only option to get it all right, is to pull it all at once (save the stuff from PR #2045).
you can see my current layout at
i made a final update to the online demo. you can see the latest speed optimisations for chrome.
i just updated the online demo from http://ansb.uniklinik-freiburg.de/CPTextView/ to reflect my recent fixes and optimisations to the typesetter and the layoutmanager. please let me know if you see issues.
i updated selection drawing to use DOM spans instead of canvas. This should be faster, look nicer and last but not least work with large text. We previously were hit by a size limitation of a canvas element. I updated the online demo so you guys can test this. please let me know if you see issues (remember to clear the browser cache).
i updated the online demo once more so you guys can verify that native pasting is now supported in safari. make sure to clear the browser cache.
updated the online demo so you guys can see the new regex based granularity engine. make sure to clear the browser cache
Absolutely awesome! Two issues I see:
When the Font panel is opened, the color is not set to the color of the text if all of the selected text is the same color.
When clicking on a letter, it always places the caret to the left of the letter. The caret should be placed to the right of the letter if the click point is >50% width of the letter.
thank you @aparajita.
i fixed both issues and updated the demo.
How are you calculating the character width? It seems the calculation is biased towards the left by a certain percentage, because at smaller font sizes I have to click farther to the right to get the caret to appear to the right.
i do not see it (testing in chrome)
the code is
partialFraction = (point.x - frames[j].origin.x) / frames[j].size.width;
it has to be a rounding issue.
I checked again zooming in on the screen, and it is working correctly. Great job!