Ticket #9387 (closed New Feature: fixed)

Opened 22 months ago

Last modified 18 months ago

V4: Inline editing - No ability to display toolbar in other location than content area

Reported by: j.swiderski Owned by: fredck
Priority: Normal Milestone: CKEditor 4.1 RC
Component: UI : Toolbar Version: 4.0
Keywords: Drupal Cc: wim.leers@…

Description (last modified by j.swiderski) (diff)

CKEditor v3 had shared spaces sample that allowed to display toolbar in location specified by user.

For example: editor had extra configuration options

sharedSpaces :
				{
					top : 'topSpace',
					bottom : 'bottomSpace'
				},

in which id of DOM elements were specified

<div id="topSpace"></div>
other code...
<div id="bottomSpace"></div>

This makes its V4 equivalent - inline editing not complete.
I think it would be good idea to allow defining toolbar location in inline editing.

Attachments

ff_shared_spaces.png (37.5 KB) - added by Reinmar 19 months ago.

Change History

comment:1 Changed 22 months ago by j.swiderski

  • Status changed from new to confirmed

comment:2 Changed 22 months ago by j.swiderski

  • Type changed from Bug to New Feature

comment:3 Changed 22 months ago by sarmiena

I read that sharedSpaces feature has been removed in favor of the floating toolbar (ticket #9377). However, I don't think the floating toolbar solves the same problem as sharedSpaces.

There are a lot of UIs out there that have an omnipresent toolbar fixed at the top with editable fields clearly marked (e.g. http://jejacks0n.github.com/mercury/). In my opinion, sharedSpaces is a good feature because users can clearly see that they are in an "edit mode" without having to interact with contentEditable fields to get feedback.

comment:4 Changed 21 months ago by Reinmar

  • Milestone set to CKEditor 4.0.1

comment:5 Changed 21 months ago by j.swiderski

  • Description modified (diff)
  • Summary changed from V4: No ability to display toolbar in other location than content area to V4: Inline editing - No ability to display toolbar in other location than content area

comment:6 Changed 21 months ago by dmachis

We took a serious look at V4 - Inline editing, and would like to use it as soon as soon as toolbar display can be directed to a div we position, e.g., sharedSpaces implemented. Floating toolbar does not work for our requirement.

comment:7 Changed 20 months ago by dinu

Me too, waiting on this.

comment:8 Changed 20 months ago by fredck

  • Milestone changed from CKEditor 4.0.1 to CKEditor 4.1

comment:9 Changed 20 months ago by jonesjunior3

inline editing is great but has its limitations, it would be great if you could specify where the toolbar is positioned, seperating the toolbar into its own element which could be postioned relative to a container instead of the body would solve the issue we are having.

comment:10 Changed 20 months ago by blainegarrett

I would also very much like this feature.

comment:11 Changed 20 months ago by j.swiderski

#9778 was marked as duplicate.

comment:12 Changed 20 months ago by j.swiderski

#9793 was marked as duplicate.

comment:13 Changed 20 months ago by RosemaryONeill

I would also prefer to have something similar to SharedSpaces implemented.

comment:14 Changed 20 months ago by Wim Leers

  • Cc wim.leers@… added

comment:15 Changed 20 months ago by fredck

  • Status changed from confirmed to assigned
  • Owner set to fredck

comment:16 Changed 20 months ago by fredck

  • Status changed from assigned to review

Pushed t/9387@cksource. Sample included.

I have glued part of the floatingspace and the original code for sharedspaces from v3 into a new plugin called sharedspace. The v4 code was well designed so it was really a piece of cake.

The nice thing is that it was possible to make it a standalone plugin, so it'll not disturb those who are not interested on it.

comment:17 Changed 20 months ago by Wim Leers

From d.o:

Will this also allow us to force the UI to remain visible even if the cursor is not currently inside the editable area? In the case of the Edit module, we want to control when the UI is visible.
(I should have made this more clear — sorry for not explicitly stating this earlier.)

comment:18 Changed 20 months ago by fredck

From d.o :)

Yes... btw, I've just pushed this feature at #9387. It does more than what you expect, because I've ported a CKEditor 3 feature... but it does exactly what you want.

comment:19 Changed 19 months ago by oyejorge

Just tested the sharedspaces plugin with gpEasy CMS and it's working great!

comment:20 Changed 19 months ago by Wim Leers

Glad to hear it works well for gpEasy CMS :)

I forgot to report it here, but over a week ago I reported to @fredck and team that it's also working perfectly for Drupal, and specifically for integration with the Edit module (see the screenshots at the top of http://drupal.org/node/1824500 if you want to learn more).

So it would seem this is ready to go.

comment:21 Changed 19 months ago by Wim Leers

Quite a few people have played with CKEditor + shared spaces in Drupal now, no problems have been reported. It'd be great if this would be (one of) the first patch(es) to be merged into the 4.1 branch, so that we could start testing against the 4.1 branch. This is the most elementary thing we need, without it, we (at Drupal) cannot use CKEditor's "inline editing" mode.

comment:22 follow-ups: ↓ 23 ↓ 24 ↓ 25 Changed 19 months ago by Reinmar

  • Status changed from review to review_failed

Hi Wim. Sorry for the long waiting - I was completely absorbed by the #9829 for last two weeks :).

I force-pushed branch rebased on master + added commit fixing coding style issues.

I've found some issues:

  • Maximize feature doesn't work (no UI spaces in maximize mode) for themed editors, but button is displayed. Initially it is hidden, but that's because toolbar for inline editor is displayed, so you need to focus themed editor first.
  • Resize handler is displayed and:
    • For themed ui it works, but this is strange and cool feature at once - I drag here, but it resizes somewhere else :). It even worked with resize_dir='both'.
    • Dragging handler for inline editor throws JS errors.
  • Once per N refreshes I've got this (on FF and Chrome):

  • When switching between themed and inline editors bottom space changes height.
  • I saw in samples that floatingspace plugin is removed, but for me everything worked fine with it loading.
  • Showblocks is switched off when blurring inline editor. This makes sense with floatingspace, but when toolbar is constantly visible it is inconsistent with themed editor.
  • Sharedspace sample's layout is broken on IE7. Or rather - IE's weird rendering bugs are ruining it.
Last edited 19 months ago by Reinmar (previous) (diff)

Changed 19 months ago by Reinmar

comment:23 in reply to: ↑ 22 Changed 19 months ago by Wim Leers

Replying to Reinmar:

What I failed to mention in comment:20 and comment:21, is that we're removing the elementspath plugin, i.e. we don't get the bottom space, thus also no resizing handle. This is the most current integration patch for CKEditor in Drupal to leverage this ticket btw: http://drupal.org/node/1873500#comment-6930746.

We also only use it for CKEditor's inline editing mode, so the maximize problem and the switching problem are non-issues for us. We are removing the floatingspace plugin as well, so I assume that you were also able to reproduce these problems with that plugin removed, because otherwise that might be the cause?

Sad to see that there are still significant blockers to get this in the 4.1 branch; I was under the impression that was at least one fixed gap!

comment:24 in reply to: ↑ 22 Changed 19 months ago by fredck

Replying to Reinmar:

  • Maximize feature doesn't work (no UI spaces in maximize mode) for themed editors, but button is displayed. Initially it is hidden, but that's because toolbar for inline editor is displayed, so you need to focus themed editor first.

That's by design... Maximize is not compatible with shared-spaces (in v3 as well). It was just a sample issue, fixed with git:ba414bc.

  • Resize handler is displayed and:
    • For themed ui it works, but this is strange and cool feature at once - I drag here, but it resizes somewhere else :). It even worked with resize_dir='both'.
    • Dragging handler for inline editor throws JS errors.

It was a sample issue as well. The resizer should not be available there. Fixed with git:ba414bc as well.

  • When switching between themed and inline editors bottom space changes height.

I'm not able to reproduce this now, because of #9960. In any case, this should not be a blocker.

  • I saw in samples that floatingspace plugin is removed, but for me everything worked fine with it loading.

That's just to show that the floatingspace plugin can be safely removed if shared-spaces is used.

  • Showblocks is switched off when blurring inline editor. This makes sense with floatingspace, but when toolbar is constantly visible it is inconsistent with themed editor.

Hum... I have mixed feelings about this. I'm imagining a page full of inline editor instances and I think it would be ok to make it behave in the very same way as it would do if floating spaces would be used instead. In fact, many times, this features will be used to not make the float toolbar float (like having it at the top of the viewport).

Note that we're mixing inline and framed editors in the sample just to showcase the power of shared spaces. Still this situation is very unlike to happen in the real world, so we don't need to make inline and framed behave in the very same way, just to satisfy our sample.


The following are under investigation right now, but still this feature is really close to be ready:

  • Once per N refreshes I've got this (on FF and Chrome):

  • Sharedspace sample's layout is broken on IE7. Or rather - IE's weird rendering bugs are ruining it.

comment:25 in reply to: ↑ 22 Changed 19 months ago by fredck

  • Status changed from review_failed to review

Replying to Reinmar:

  • Once per N refreshes I've got this (on FF and Chrome):

Fixed with git:6569029.

  • Sharedspace sample's layout is broken on IE7. Or rather - IE's weird rendering bugs are ruining it.

Gotta love that browser :)

I've checked the sample, which has not been made with IE7 in mind, and in fact things are messed up. Still it is possible to confirm that the feature works on it.

I would ask to not block this feature because of the sample file. The sample issue can be fixed on a separated ticket, if someone would ever care about it.


We should be done with the pointed out issues.

comment:26 Changed 19 months ago by Wim Leers

comment:24 and comment:25 are very helpful — thanks!

comment:27 Changed 19 months ago by Reinmar

  • Status changed from review to review_passed

Code looks OK, feature works, R+ :).

Last edited 19 months ago by Reinmar (previous) (diff)

comment:28 Changed 19 months ago by wwalc

  • Keywords Drupal added

comment:29 Changed 19 months ago by fredck

  • Status changed from review_passed to closed
  • Resolution set to fixed

Committed into major with git:091cb61.

comment:30 Changed 18 months ago by bernesto

It would also be nice, to enable this to work across frames (iframe) too similar to how you could a few versions back.

comment:31 Changed 18 months ago by j.swiderski

@bernesto this works with both iframed and inline editors. You can check it by getting 'major' on github as explained in comment:29.

comment:32 Changed 18 months ago by Reinmar

@j.swiderski: bernesto asked about something different. It'd be cool if toolbar could be in other frame than editors. We're thinking about this feature, but we're not planning to have it on 4.1.

comment:33 Changed 18 months ago by j.swiderski

Let's wait for @bernesto comment but by saying "to how you could a few versions back" I think that he means having it work just like in CKE 3.x (few iframed editors and one toolbar).

comment:34 Changed 18 months ago by dinu

He's definitely talking about location:out, I remember not supporting this anymore was a design decison in CK3 but can't remember the specifics. There definitely is a ticket in here somewhere but with 20 searches I can't find it.

Note: See TracTickets for help on using tickets.
© 2003 – 2012 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy