Tags:
editing1Add my vote for this tag user_interface1Add my vote for this tag wysiwyg1Add my vote for this tag create new tag
, view all tags

SmartEditAddOnDev Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on SmartEditAddOn contributed by the TWikiCommunity.
• Please let us know what you think of this extension.
• For support, check the existing questions, or ask a new support question in the Support web!
• Please report bugs below

Feedback on SmartEditAddOn

-- GaelCrova - 07 Aug 2006

Note: See related NatEditContrib.

-- PeterThoeny - 27 Apr 2007

Enhancement suggestions

Suggestion Proposer Status
Insertion of dates by adding the JSCalendarContrib to the toolbar ThomasWeigert  
Add a help topic which just shows help, rather than refers to the plugin topic (no need to have installation instructions, when the editor is already running). Show this topic with template=viewprint. ThomasWeigert Implemented
Remove the shrink/grow text area buttons from below the text are, as they are already provided by the SmartEditAddOn ThomasWeigert  
Insertion of signature line from tool bar (and remove from below the text area) ThomasWeigert  
Add button to jump to end of edited text (nice when text is long, as scrolling is more tedious) ThomasWeigert  
Provide skin-based invocation. ThomasWeigert Implemented, see attachment
Don't indent on Alt-tab (not really an enhancement but there you go...) MartinRothbaum Implemented, see attachment

Bugs ( SmartEditAddOn + SmartEditPlugin )

Bug Required action Proposer Date Status
Unacceptably slow response when using IE with large pages (over 10000 characters) Disable addon IF ( large topic AND Internet Explorer ) Various    
SmartEditPlugin not working with SmartEditAddOn: plugin fails to insert the required div-tag with id "smartEditorTopToolbarID" and the javascript at the end of the page (when added manually to template, plugin works ok)   MikkoLaakso    
If you try to edit a form with a textarea, and press Carriage Return in one of the fields, it jumps to the main edit textarea Only catch actions in main edit textarea AndrewRJones 11 Apr 2007  
If you edit a page in Firefox (1.5.x or 2.x), preview it, then go back using the back button, the changes are lost (on TWiki 4.1)   AndrewRJones 12 Apr 2007

Discussion

As an initial version I must say that it looks great.

I have installed the AddOn as a trial. Or at least I think I have.

You really need to provide a better installation description of how to modify the templates.

I am not at all sure I did it the right way.

If you have made your own skin you may know. But for basic admins using just plain PatternSkin which I am sure is 95% of all TWiki users, understanding the template files is not basic knowledge. After they have been split in many small files they are a true horror to understand.

You should provide better explanation of exactly where the view and edit templates should be edited showing the context around the added text. And you should provide example files of both edit and view.

I have something running now but I am not at all sure I did it right.

The impression I get is WOW.

Some functions have some cosmetic problems. Adding links and searching seems to happen in a bar that does not look quite right. I am looking in IE. If you look yourself in IE you will known what I mean. E.g. in search I cannot read the text on the two buttons until I click them. Same in add link. When you add a link you have to go back to the topic and place the cursor again - otherwise the text gets pasted in typically at the very beginning of the topic. The pulldown list of topics have the text centered. I think it would look better and be more easy to find the right topic if it was normally left justified.

Small cosmetics - but I am sure that can be fixed. It really looks good. The way bullets work is really cool and user friendly. What I really like is the intuition in the use.

It is just the installation description for the templates and a few cosmetics I have found as problems until now.

I have not yet measured the performance impact.

-- KennethLavrsen - 07 Aug 2006

Thank you very much Gael for sharing this improved JavascriptBasedEditor add-on with the TWikiCommunity!

I fixed some formatting issues on the add-on topic, please feel free to take this into the next release:

  • Use à instead of à
  • Fixed bullet nesting issue
  • Escaped <nop> etc in the docs
  • Removed hard-coded TWiki web prefix
  • Added SHORTDESCRIPTION text

I have tried out the add-on. Make sure to generate proper XHTML, e.g. <hr /> instead of <hr>, and <br /> instead of <br>.

-- PeterThoeny - 08 Aug 2006

Hi ! I will change text colors for IE buttons today, it's just a CSS color value that I forgot to change. Thanks a lot for your comments, I will work on this today! wink

-- GaelCrova - 08 Aug 2006

Thanks for the comments Kenneth. This is definitely a first version with rough edges, to beta test it. The long-term goal would be for it have it as the standard editor for all the skins (including pattern). Be kind with Gael (a student in my team), as he is new to TWiki and perl, and he will gladly recieve advice, especially on how to package it.

-- ColasNahaboo - 08 Aug 2006

Thanks Colas for your explanation! I forgot to say it before... please excuse me. I have fixed some problems with IE display, changed the color for IE buttons and fixed some other "hidden" bugs. Tell me if you see another bug !!

Thanks

-- GaelCrova - 08 Aug 2006

I have tried the new version from 08 Aug and now it really looks good. I cannot find more to complain about. You have made a great job!

I would like to help you improve the installation instruction for the modification of the template files. It is still not clear enough. I know the templates are very hysterical about new lines and it is not clear exactly how the edit.xxx.tmpl and view.xxx.tmpl files should look like.

It seems if I copy view.pattern.tmpl to view.smarteditor.tmpl and edit.pattern.tmpl to edit.smarteditor.tmpl and modify the files the best I can following your description, then I can activate the smarteditor by setting * Set SKIN = smarteditor,pattern in Main.TWikiPreferences

So it is probably a good idea if you include the files view.smarteditor.tmpl and edit.smarteditor.tmpl with the addon and instruct people to change the skin setting instead. That is much easier this way.

Thanks to Colas for this great initiative.

-- KennethLavrsen - 08 Aug 2006

Indeed, it does look good. How does this relate to / is different from MarkupEditorContrib?

-- JosMaccabiani - 09 Aug 2006

Hi Kenneth,

I am working on a new release with a specific skin. I have just to make different templates for each TWiki version.

-- GaelCrova - 09 Aug 2006

Actually, it is not related to the JavascriptBasedEditor, MarkupEditorContrib, and PowerEditPlugin (and others). We toyed with the idea of reproducing the WysiwygPlugin functionalities, but emphazising 100% predictability and reliability over WYSIWYG. It seemed that we could either make the WysiwygPlugin totally reliable (but it seemed doomed to fail due to the bugs in the browsers) or going the "wikipedia" way, as many users seemed to be happy with this kind of editors (one - a computer science phd - even said: "why don't you provide a WYSIWYG editor like the wikipedia one" - sigh). To avoid browser bugs, it seemed we had to stay within the TEXTAREA limits, and we tried to cram as much WysiwygPlugin functionality there (we lack image insertion though)

But... when Gael added (some) context-sensitive editing, and the TAB handling of bullet lists, we were so impressed with the results that we thought that we definitely had something great in our hands there.

As for "why not enhancing previous efforts?", well, I believe that to really advance on things, one goes farther faster by working alone, thus following a coherent vision. Then, the beauty of open source is that the parallel efforts can steal each other ideas and strive on the competition (and even merge if the developers see that they share the same vision).

-- ColasNahaboo - 09 Aug 2006

Colas: Good points.

Gael: I just did a test drive on your demo site. This looks very professional. Nice design and layout, and nice functionality. I think we can take this into the standard TWiki distribution after some time.

Some feedback:

  • It would be nice if the "outdent text" works also to remove the bullet.
  • Colored text possibly with %RED% and %ENDCOLOR% instead of span sheet tags with style sheet.
  • Insert internal link: pulldown list with topic names is not visible in FF, is OK in IE. Possibly a foreground/background issue (I see a tiny bit below the input field, but nothing overlapping into the textarea.
  • Layout issue on IE: The close buttons on search and insert link are off screen to the right (also the help button when search and/or insert link bar open). I need to scroll horizontally to close. The textarea is OK, it uses the full width. This works properly on FF.
  • Spacing issue in insert external link: If you double click a word to highlight, a trailing space is highlighted. If you click on external link, trailing space gets included and produces an incorrect link like: [[http:/foo.com/][click ]]more text (expected: [[http:/foo.com/][click]] more text)
  • Insert internal link: When you highligh text and click on internal link, the highlighted text disappears. I would expect that a plain WikiWord is inserted if no text is highlighted, and a [[WikiWord][selected text]] if there is. (Watch out for trailing space.)
  • Insert TWiki icon: Better to insert %ICON{name}% instead of long img tag.
  • Insert TWiki icon: It would be nice if list is configurable
  • Select and insert standard string: It would be nice if list is configurable (label, inserted text pairs)
  • Insert bullet/numbered list: Click on line that is already a list removes the bullet/number, whcih is fine. It would be nice to remove the leading space as well (undo bullet)
  • It would be nice to support definition list as well.
  • It would be nice to support "insert table" as well. Something like in Word where you can drag open a grid, to insert an empty table of n x y cell size

Here is an idea I had while taking a shower (somehow I have creative moments when taking a shower smile ), but not sure if technically possible: How about a true WYSIWYG editing experience by enhancing this editor in this way:

  • The TML text gets updated in a hidden textarea when you type text, or use the toolbar
  • A visible WYSIWYG text area is updated whenever the text in the hidden textarea is updated (this requires a TML renderer written in JavaScript)

-- PeterThoeny - 09 Aug 2006

You are not the only one with the shower inspiration smile

The WYSIWYG method you describe will never be perfect, since there might be variables, TWiki or SpreadSheetPlugin, defined in the page (or worse, in included pages) that need to get resolved for correctness. You will need a save cycle for TWiki to be able to see these. If you can figure out a way around this, then the same technique could be applied to normal edits as well as SectionalEditPlugin edits.

-- PankajPant - 09 Aug 2006

The idea is to leave variables unexpanded. This is actually better since this is the only way to actually be able to edit the variables. Also HTML tags could be shown verbatim, so that you can edit an HTML form for example.

-- PeterThoeny - 09 Aug 2006

thats pretty much what the first iteration of InlineEditPlugin did, and we are looking towards re-implementing some kind of preview & validation functionality into its sectional editing. Presuming that SmartEditPlugin is now capable of dynamic (and multiple) instanciation, it will also be able to be used in InlineEditPlugin's textareas.

-- SvenDowideit - 10 Aug 2006

Hmmm ... InlineEditPlugin sounds really interesting but the only real bits of information I could Google up are http://www.home.org.au/cgi-bin/view/TWiki/InlineEditPlugin and http://www.home.org.au/cgi-bin/view/TWiki/ComponentEditPlugin.

Are you planning to upload them to twiki.org for people to try?

-- PankajPant - 10 Aug 2006

This looks to be a very valuable addon. I particularly like the web-link-preview option, and the menu configurability.

How easy/difficult would it be to create menu trees? If there is a way to convert something like:

  • My List
    • category A
      • list of icons (A)
    • category B
      • list of icons (B)
    • category C
      • list of icons (C)

into a pull down list of menus, that would be a huge benefit to my wiki users.

(My particular interest is for LaTeX symbols, of course)

-- ScottHoge - 10 Aug 2006

PTh says Colored text possibly with %RED% and %ENDCOLOR% instead of span sheet tags with style sheet.

mmm I must confess I was the one pushing Gael for the span approach because of

  1. I think TML should not reinvent HTML where it is not needed... why for instance using the 4-chars %BR% instead of the 4-char <br>? Moreover, using HTML educates people on HTML rather on a niche language...
  2. the uglyness of %ENDCOLOR% was troubling me.
But these are personal feelings. I guess I could be convinced, if we use something shorter than %ENDCOLOR%... maybe just %END% ? (as now with CSS, anything can be expressed as a SPAN with the appropriate styling, a generic /SPAN named %END% makes alot of sense

PS: I let Gael answer on the other points, but thanks you discovered many bugs... alas some of them depended on the version of the pattern skin frown (if only the pattern skin was more stable...)

-- ColasNahaboo - 10 Aug 2006

I see your point, %ENDCOLOR% is a bit longer to type. However, %RED%...%ENDCOLOR% is faster to type than <span class="red">...</span>. Also, users are used to TWikiVariables syntax, but might not be used to raw HTML. Same thing with %BR%, which avoids also XHTML errors, such as writing incorrect <br> instead of <br />.

-- PeterThoeny - 10 Aug 2006

Sorry, I forgot the 3rd point which was actually the one which made us go this way:

  • With %RED%, what is red is actually defined in a TWiki topic
  • With <span class=red what is red is defined by the skin (as a CSS class), as it should be (how to render colors, especially pale ones like yellow, grey) hould depend on the skin general hues. This is especially true with the popular white on black looks of some communities, see: http://www.wowwiki.com/Main_Page and http://www.wowwiki.com/Main_Page?useskin=monobook that some users may prefer.

But again I think we can fix this, just define in TWiki RED by

  • Set RED = <span class=red>
instead of defining it directly by a color as it is now.

On the subject of HTML/TML, my users will have much more opportunity to ecounter HTML than TML. And on XHTML, well a lot of users still use what they learnt by experience (HTML) or paste from HTML-producting tool. So since I cannot ensure 100% XHTML contents, thus I argue that we should stay to HTML. But I guess this could be a configuration setting of SmartEditAddOn (produce XHTML or HTML)... It could maybe even autodetect it from the current page DOCTYPE smile

-- ColasNahaboo - 11 Aug 2006

Does this work with Cairo?

-- PankajPant - 11 Aug 2006

I have tested it on Cairo. It seems that some TWiki variables have not he same definition so, for example, "Insert Wiki link" feature doesn't work on Cairo.

You can see my work and all your comments on my personnal working page on Wikix : http://wikix.ilog.fr/wiki/bin/view/Students/SmartEditAddOnNextRelease

-- GaelCrova - 11 Aug 2006

On skin depended colors: A site typically just has one skin for the whole site, so a %RED% can be adjusted in the Main.TWikiPreferences. Some sites possible have a few skins used acress webs, colors can be adjusted in the WebPreferences.

BTW, not all agents support JavaScript. Does this add-on degrade gracefully if JavaScript is not available or disabled?

Also, would it make sense to detect the browser and show the toolbar only for supported browsers & version?

See PreInstallSmartEditAddOn for reasons why we should ship this add-on with the standard TWiki distribution.

-- PeterThoeny - 11 Aug 2006

Sites using NatSkin can have per-user configurable skins that could be dark or light for the same page. As long as the complexity is hidden from the user behind a %RED% variable there's no reason not to allow skins to specify these colours.

-- SamHasler - 12 Aug 2006

Nice work. But... it would be great if all features would also work on Safari. Are you planning to work on that?

-- ArthurClemens - 12 Aug 2006

The installation instructions on SmartEditAddOn seem incorrect. For example:

  • The installation state that one needs to edit view.pattern.tmpl by inserting text right after %TMPL:P{"content"}. But there is no such text in view.pattern.tmpl; instead, this is found in body.pattern.tmpl.
  • Then the code pasted refers to a non-existing location pub/TWiki/TWikiSmartEdit. Probably should be pub/TWiki/SmartEditAddOn (where the css actually is)
  • It is unclear whey this code is even there, as the edit bar should not require a css to be loaded for the view template, but I may be missing something...

-- ThomasWeigert - 13 Aug 2006

To simplify the inclusion of the SmartEditAddOn, which seems a great and light-weight way of editing TWiki topics, I put together a little SmartEditPlugin, which basically just loads the SmartEditAddOn. However, as a plugin, it can be turned on or off depending on what the user wants and, of course, does not require that the TWiki templates be edited...

If this plugin resonates, one could combine these two so one does not have to install two things (plus get it to work out of the box by using the plugin settings for configuration).

Another way of integrating this SmartEditAddOn better would be to create a special skin (e.g., create a copy of pattern skin and push a skin setting) but I have not experimented with that one....

-- ThomasWeigert - 13 Aug 2006

I have several enhancement suggestions which I put into a table on top of this page...

-- ThomasWeigert - 13 Aug 2006

Did you test the AddOn with Opera? If I edit a topic with Opera (9.01/Win 2000) the behaviour of the "Shift" key is very strange. If I press only "Shift" the cursor goes 2 positions back.

-- PeterRill - 14 Aug 2006

If GaelCrova doesn't have access to a mac then perhaps Swift (a web browser for Windows based on the Apple WebKit rendering engine) can be used for testing.

-- SamHasler - 15 Aug 2006

Hi all!

Ok I know that there are some bugs on Opera and I'm trying to fix it. (I don't write Opera in "Supported browsers" wink ) For Safari, thanks to Sam, I will test Smart Edit with it this week.

-- GaelCrova - 16 Aug 2006

Thanks for a fantastic plugin! smile - Alone the search feature is worth it all, searching a text area is not possible with a default Firefox.

We are seeing some performance issues with Internet Explorer and large topics (100 lines up) - did anybody notice the same?

-- SteffenPoulsen - 18 Aug 2006

Yes Steffen, I've seen these problems. I've fixed some bugs with Internet Explorer in the last release(today, 18 August). But I think you may meet some performance problems with very large topics. I have to work on it for the next release.

You can see these points on http://wikix.ilog.fr/wiki/bin/view/Students/SmartEditAddOnNextRelease

-- GaelCrova - 18 Aug 2006

Added another suggestion on top (provide jump to end of text button).

I also have noticed the performance problem -- my work around is to use SectionalEditPlugin for such topics. Maybe I should look into putting this editor into a skin rather than invoking it via a SmartEditPlugin which does at least allow user and web control over whether this should be invoked)....

-- ThomasWeigert - 20 Aug 2006

One more word on the slow-down... the following actions are excrutiatingly slow on large topics:

  • carriage return
  • first character at new line
  • hitting asterisk character (even in middle of line)
  • autofit (but that is obvious)
Still slow, but not as bad
  • indent and outdent
  • select color palette
Everything else is slowed down not as much...

Just to give you a feel of the order of magnitude we are talking about: On TWikiFuncDotPm (1333 lines), on my laptop (used as both server and client, 2Ghz single core Intel) hitting carriage return takes 13 sec before the cursor comes back, hitting an asterisk at the beginning of a line takes a whopping 51 sec before you see the asterisk appear.

-- ThomasWeigert - 20 Aug 2006

Attached is a template file which allows you to invoke the SmartEditAddOn via adding cover=smart to the URL parameter. You can set the COVER preference to accomplish this throughout, if so desired, but watch out for big topics. It might be better to add another "edit" button that invokes the SmartEditAddOn, when desired (or maybe one even would count the number of lines in the topic and only boot up the SmartEditAddOn when the topic is small; this could be done easily in SmartEditPlugin).

-- ThomasWeigert - 23 Aug 2006

Simply disabling the addon on edit if IE is detected would work ok in our case, more topics than not are hit by this.

But it would definetely be great to have the possibility for en/dis-abling the addon selectively using standard preferences, form-based applications (like BugsContrib) which hides the textfield using CSS will have the addon toolbar appearing out of nowhere if it is not disabled in the web / the set of topics that doesn't have a main textarea.

-- SteffenPoulsen - 24 Aug 2006

I keep getting:
Error: twikismartTextarea has no properties Source File: http://simonraven.nuit.ca/pub/TWiki/SmartEditAddOn/twikismartEngine.js Line: 69

I've integrated it with NatSkin.

Oh, *NIX line endings would be nice too wink .

-- EricCote - 24 Aug 2006

The TAB handling of bullet lists, is a great idea but when I use ALT+TAB key to switch to a other application (task switch in MS-Windows) I get additional tabs into my twiki page. It would be nice if SmartEditAddOn would ignore the ALT+TAB key.

  • I have uploaded a patch which fixes this (seems to on my install anyway wink -- MartinRothbaum - 03 Dec 2006

-- RomanRuediger - 18 Sep 2006

When looking for a topic in the dynamic "Search for topic" dropdown, I think you could use a regex that looks for strings beginning with the entered characters. When I type "pa" it is unexpected that I get a hit UserHomePageHeader.

Inserting a link should be done preserving the selected text, and by putting [[][]] around the selected topic and the selected text.

The "auto fit" button does not belong to the topic control buttons in the top bar, but to the textarea and should be placed somewhere near the textarea. Same goes for the expand/shrink buttons.

I would not repeat the toolbar at the bottom - one is crowded enough - instead use the bottom space for textarea controls.

The Close button of the link toolbar looks frightening, as if I am going to close all my work.

-- ArthurClemens - 18 Sep 2006

Just to echo a lot of previous comments:

  • Wonderful work, especially the linking to other topics functionality.
  • The editor addon is too slow to use in practical situations UNLESS we can go to the 'every heading is a section' model of Wikipedia, and therefore all edits will be on small bits of pages.

My biggest desire for a TWiki editor is intelligent syntax highlighting: the ability to distinguish content from markup visually is my number one requirement for useability.

-- AnthonyDervish - 27 Sep 2006

Hi! Great plugin. I only have a few problems under Internet Explorer (both IE6 and IE7) that don't occur under FireFox. If I press shift+left arrow, only 1 character get selected. If I try to select whole lines, empty ones stop the selection from being expanded further down. I have this problem both with my TWiki installation and the demo at http://twbw-test.luddeni.net/bin/view/Sandbox. Help!

-- PavelDort - 02 Oct 2006

This might seem a bit obvious, but why not just put the edited content into a <pre> block, and let the browser WYSIWYG editor handle the cursor position? IIRC you get cursor move events from all the browsers in the DHTML editors.

-- CrawfordCurrie - 02 Oct 2006 (moved from PreInstallSmartEditAddOn)

I'm having problems trying to get a string that I want to inserted escaped correctly for adding to the SMARTEDITSTRINGSITE variable. Here's the string I want added:

---++!! Comments

%COMMENT{type="above"}%

It seems that the line breaks that I want are causing problems. TWikiVariables#Setting_Preferences_Variables says that I can create multi-line variable values, but I'm not sure how all that works out.

-- BryceSchober - 10 Oct 2006

What is the status of the performance improvements on IE?

-- PeterThoeny - 04 Nov 2006

Was getting some garbage in my apache error log with this plugin

File does not exist: /srv/www/vhosts/twiki.singleview.local/pub/TWiki/TWikiSmartEdit
Turns out the installation instructs for your "view" template should be "SmartEditAddOn/twikismartstyle.css" instead of "TWikiSmartEdit/css/twikismartstyle.css".

Ive updated SmartEditAddOn to reflect this.

-- GlennRoberts - 07 Nov 2006

Ok, I have installed the SmartEditAddOn and SmartEditPlugin. SmartEdit runs in my main web and my Twiki web where I have pattern skin running. It does not run in my Sandbox web where I have nat (natural) skin running. What do I need to fix, or should I even bother?

-- RonCostin - 12 Dec 2006

You need to apply the same changes to nat skin that are described for pattern skin on SmartEditAddOn.

-- ThomasWeigert - 12 Dec 2006

It looks like the edit.nat.tmpl file is fairly different, so I'm having problems figuring out what to insert, and where in that file. The lines referenced on SmartEditAddOn are different.

-- RonCostin - 12 Dec 2006

Would it be possible to extend the SmartEditPlugin to do the appropriate mods for natskin?

-- RonCostin - 12 Dec 2006

Is there a trick to the SMARTEDITSTRING... formatting?

In the documentation example, there is an entry to insert the %TOC% variable, but if I extend this to have the {depth="3"} argument, then the SmartEditAddOn toolbar no longer appears.

Same thing happens if I try to add an HTML string like the <img> tag.

A bit more information in the documentation would be good.

-- DuncanKinnear - 07 Jan 2007

Hi Ducan,

It's a known problem but you have a workaround using \" instead of ".

-- GaelCrova - 12 Jan 2007

Hi all, (and sorry to come back so late ...)

To summarize the status of this editor:

I'm working to give you these functionnalities:

  • Automatic configuration of the SmartEditAddOn by browser (IE and FF)
    • Disable the editor on other browsers
    • Disable some functionnalities when the page is too long (depending of the browser: 13000 characters for IE and 180000 for FF)
  • On the SmartEditAddOn Installation
    • The way to install the SmartEditAddOn easier is to copy your view and edit templates in smarteditor(or another name) named templates.
    • To install the SmartEditAddOn, you just have to copy and unzip the zip file in your TWiki distribution and to set the skin that you want to use.
    • I have some templates availables for the pattern skin so I will attach it soon to this page

-- GaelCrova - 12 Jan 2007

Gael, my suggestion is to exclusively focus on performance. We have the installation procedure fixed already through either loading the editor as plugin or invoking by cover=smart as shown in the attached.

But this wonderful feature cannot be used in topics that are longer, and many topics unfortunately are.

Maybe you can expand what you mean by disabling functionality, but my experiments showed the addon to be unusable in any respect once the topic got longer.

ALERT! This addon is a really great contribution if it could be made to work faster on long topics. Many users would love to have this.

-- ThomasWeigert - 12 Jan 2007

Just to echo Thomas' comment above - I would love to use this also, but the performance on long topics is a show stopper.

-- MartinRothbaum - 12 Feb 2007

Well....I loved to use this SmartEdit....but I'm completely confused. I've downloaded and unzip SmartEditAddOn and SmartEditPlugin . And now ? vi or not vi ? What is the correct thing to do ?

-- NicolasDorfsman - 14 Feb 2007

Just a quick note that if you're using short urls you may need to tweak twikismartEngine.js to avoid a JavaScript permission denied error on XMLHttpRequest.open (this is the Firefox error - no doubt IE will have a different error - but the result is the same - the topic list doesn't display). I ran into this and had to remove the +"/" from the following line (approx #673 in twikismartEngine.js):

var address =  twikismartWikiHomeURL+"/"+web+'?skin=smarteditorwebtopiclist';

-- MartinRothbaum - 16 Feb 2007

I have a problem with Insert internal link: pulldown list with Webs is not visible and there are only topics from Main Web visible. All other functions are working.

-- AnnaPapierz - 21 Feb 2007

I've spot a problem with the plug-in in 4.1.1 TWiki on FireFox (v2.0.0.2) only! (IE works fine in this case). When I put changes to the topic I hit preview to see if the changes are correct. If not, I go back in the browser to correct things. The plug-in seems to loose not saved changes ;-/. All you get is the content as if you had just hit the Edit button, all changes are lost. Anyone with similar experiences???

-- JacekZapotoczny - 07 Mar 2007

If I use the search on the bottom bar and hit return to find the first occurrence, the edit is saved and I return to the topic. The edit button must be catching the return.

-- AndrewRJones - 28 Mar 2007

The new version from 12 Jan 2007 is not in SVN.

-- ArthurClemens - 28 Mar 2007

From PreInstallSmartEditAddOn: I confirm that the performance issues described by ThomasWeigert and ColasNahaboo are related to IE, Firefox performs much better. Is there still any intent on fixing this? More importantly, is this addon/plugin still under development by anyone? For me this seems to be the only reasonable direction to develop TWiki editing (which is clearly not getting enough attention). Almost forgot: thanks so much to GaelCrova for taking TWiki editing to more pleasant direction, this helps increase contribution and therefore collaboration.

SmartEditAddOn and SmartEditPlugin should be developed together, as this avoids editing the templates (which is unacceptably difficult).

-- MikkoLaakso - 30 Mar 2007

Filed a new bug in the table at the top. We have had to disable this AddOn from pages that use extensive forms because of this frown

-- AndrewRJones - 11 Apr 2007

Have filed another new bug. Is anyone maintaining this AddOn?? Anybody seeing similar problems?

-- AndrewRJones - 12 Apr 2007

We had to remove the extension because of the following problems stated also by AndrewRJones:

  • Firefox lost content after getting back from "preview" mode. Seems to be unimportant but can be frustrating when e.g. over an hour work is lost.
  • IE performance problem with large documents. During typing we get letters with a great delay in editbox. Behaves like on a remote shell with a really slow link.

At this point the AddOn is unacceptable for us. But I hope smbd will take care of it as I see it as a very important extension which can convince many to contribute and ease work with documents e.g. by very useful search ability in editbox.

-- JacekZapotoczny - 24 Apr 2007

Perhaps the hack I worked into the BehaviourContrib js can be used for this AddOn as well. It has greatly sped up twisties on IE.

-- ArthurClemens - 24 Apr 2007

Hello, we realized that backward marking with the shift key (SHIFT + CURSOR LEFT) doesn't work properly. Forward marking is ok (SHIFT + CURSOR RIGHT). Is this issue knwon or is there even a patch available? Thanks, Tobias

-- TobiasLeisgang - 26 Apr 2007

I have uploaded the v2 version. Alas is is as slow as before, we did not have the time to recode it. But now it has proper templates inherited from pattern, and an icon menu allowing to inset the TML of the icon, not the HTML. Note that wiki power users use it exclusively on our intranet for 18 months now, and love every minute of it. But of course power users use only firefox. We have hints on how to rewrite it faster (not modifying the text buffer so much - and factorizing a lot of duplicated code) but alas no time yet to perform the work frown

-- ColasNahaboo - 23 Jan 2008

The demo site was outdated. I have set up a new demo site (free registration) at http://wiki.koalaz.net/bin/view/Sandbox/WebHome

-- ColasNahaboo - 24 Jan 2008

2.1 uploaded: just a fix to template to avoid smartedit menus appear in thw WYSIWYG edit mode

-- ColasNahaboo - 25 Jan 2008

Colas, should v2.1 work with Twiki 4.1.2? I had the older version of this add on aworking fine and found it incredibly useful, but found problems with TinyMCE. Having installed V2.1, I'm not getting the smartedit buttons anywhere.

I'm using pattern skin and have tried both the preference settings you suggest in your installation instructions but am not seeing the smartedit toolbar, even if I disable TinyMCE completely.

Any suggestions?

-- TamsinTweddell - 25 Feb 2008

Mmm, didnt test in on 4.1.2. I guess pattern skin differences may be the problem. I do not think I will be able to work on it this week, however frown

-- ColasNahaboo - 25 Feb 2008

I've just installed SmartEdit but I am still getting smartedit toolbars on WYSIWYG edit mode? It seems a bit intermittent when they show up. But always I get both on a newly created topic(the smartedit tool bar is inactive however). Is the version downloaded by configure extensions v2.1?

-- HansSchwing - 20 Apr 2008

Currently this bug happen only on creating new topics. Note that it is kind of cool that then the smartedit toolbar activates when you toggle the WYSIWYG mode on/off... now being able to hide them while inactive would be even cooler :-). havent found the time yet to squash this bug frown

-- ColasNahaboo - 20 Apr 2008

Actually the Smartedit toolbar shows up on existing topics as wells as new when the EDIT button(the WYSIWYG button) is clicked. Not sure why at first it seemed intermittent I like Smartetid but need WYSIWYG for the casual users. Sure hope you get some time to kill the bug! Thanks for all the good work.

-- HansSchwing - 22 Apr 2008

Found a small bug: twikismartWikiHomeURL is not valid when script suffix (e.g. ".pl") is set (it screws up the toolbar with 404 errors when clicking "insert a link to a wiki page").

To fix, I've set it to /cgi-bin/view in edit.smarteditor.tmpl.

-- SergeiKlink - 06 Jun 2008

Oops, that should have been %SCRIPTURLPATH{"view"} %...

-- SergeiKlink - 06 Jun 2008

Opps forgot to say that EnriqueCadalso fixed the double bar bug, see: TWikiRawEditDefault04x02

-- ColasNahaboo - 06 Jun 2008

I have a suggestion for improvement:

Change in twikismartActions.js (line 1968):

var sstagBeg = "";
var sstagEnd = "";

To:

var sstagBeg = "%"+smartColor.toUpperCase()+"%";
var sstagEnd = "";
Now SmartEditAddOn supports correct twiki syntax for colors, instead of unneeded html code.

-- SaschaVetter - 23 Jul 2008

Tzzz, bloody pre, sorry!

twikismartActions.js (line 1968):

var sstagBeg = "<span class=\""+smartColor+"\">";
var sstagEnd = "</span>";
To:
var sstagBeg = "%"+smartColor.toUpperCase()+"%";
var sstagEnd = "%ENDCOLOR%";

-- SaschaVetter - 23 Jul 2008

I'm still getting double bars in WYSIWYG mode when it's the default one...

The fix/workaround is to make it consistent with the smarteditordefault skin - find the line specifying TMPL:DEF{"edit_topic_link"} in viewtopicactionbuttons.smarteditor.tmpl and change

%IF{"context TinyMCEPluginEnabled" then="" else=";nowysiwyg=1;skin=pattern"}%
to
%IF{"context TinyMCEPluginEnabled" then=";skin=pattern" else=";nowysiwyg=1;skin=pattern"}%

-- SergeiKlink - 08 Aug 2008

I have a problem when accessing a SmartEdit-Enabled TWiki using Safari (the MacOS Web Browser): Pressing a upper case letter (shift + letter) makes the editor to change focus to the end of the textarea and insert the character there - which is not nice. Accessing the page using Firefox works fine ... Any ideas how this nasty problem could be solved?

-- MichaelKoch - 11 Aug 2008

Was just wondering if there is any way to get the Smartedit toolbar to only show up on the Raw_edit? I have tried to follow the instructions above but still get both the Tineymce and the Smartedit toolbars when selecting the EDIT(WYSIWYG) button.

-- HansSchwing - 02 Feb 2009

Has the "Don't indent on Alt-tab" patch been applied to the main v2 or v2.1 release? According to the change history, v2 was released two years after the patch was submitted, but our v2 installation still has this bug.

-- TristanMiller - 2011-08-29

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatpatch SmartEditAddon_alt-tab.patch r2 r1 manage 1.9 K 2006-12-03 - 17:55 MartinRothbaum Patch to disable indenting on Alt-Tab & Ctrl-Tab
Unknown file formattmpl edit.smart.tmpl r1 manage 4.5 K 2006-08-23 - 12:01 ThomasWeigert Template to invoke SmartEditAddOn
Edit | Attach | Watch | Print version | History: r85 < r84 < r83 < r82 < r81 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r85 - 2011-08-29 - TristanMiller
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.