Cursor position?

[Mat]

Dear all, for EditorMagic I am really hoping to show the popup at cursor position. Fellow Snowgoon uses this code in his comptext plugin in TW:

https://github.com/snowgoon88/TW5-extendedit/blob/master/plugin/files/cursor-position.js

I don't understand js. How would I use this to position a div? Is it possible? Is there some kind of command?

What I want to do is to control the position of a popup (a div) to be just below the cursor. I assume the most critical bit for this is to identify the x,y values for the cursor.

Thank you.

<:-)

[Mat]

I realize these are silly beginner js questions but... well, I hope to get EditorMagic to be useful (for us all) so:

I note the cursor-position.js has

function getCaretCoordinates(element, position, options)
...
var coordinates = {
   top: span.offsetTop + parseInt(computed['borderTopWidth']),
   left: span.offsetLeft + parseInt(computed['borderLeftWidth'])
};
...
return coordinates;

and I interpret this to be called via this:

window.getCaretCoordinates = getCaretCoordinates;

How do I "get access" to this in the tiddler editor? 

Any answer is better than none so I really appreciate any thoughts on this.

Thank you.

<:-)

[Jed Carty]

Getting the cursor position shouldn't be too bad to implement, and we should be able to do it without adding bloat from external libraries. I will see if I can get something together once I get home.

[Mat]

Oh! That would be super! As I noted elsewhere, my hope is to be able to position a popup like they do in the CKEditor feature "Balloon editor" (see below the video, in the editable text select/click on any word to get the balloon to pop up).

<:-)

[Mat]

@Jed, any success with the cursor position? It is much appreciated that you look into it.

<:-)

[Jed Carty]

Sorry mat, I made this and then completely forgot to share it.

I put it up on gitlab with a demo wiki, it should be available here https://ooktech-tw.gitlab.io/plugins/mousey

 

[PMario]

On Tuesday, March 24, 2020 at 1:59:53 AM UTC+1, Jed Carty wrote:

Sorry mat, I made this and then completely forgot to share it.

I put it up on gitlab with a demo wiki, it should be available here https://ooktech-tw.gitlab.io/plugins/mousey

Nice!

There is a problem if the "example" tiddler is opened in a new window. ... It seems the right-click "cursor" position in the new window is calculated relative to the "parent window" element.

IMO there needs to be a new event-handler, for every "cursor" element. ... Just a guess. Didn't have a close look to the code.

-mairo

[Jed Carty]

Mario,

I hadn't even thought to test that. I think you are correct about the position tracking but I am not sure how to do that, I need to do some more research. I don't think that the multi-touch api solves this problem, but I think that implementing tracking for it would be worth doing.

At the moment the mouse position is tracked by a global onmousemove handler that saves the mouse position as $tw.mouseX and $tw.mouseY.

I may have to add a mouse move handler to the $mouse widget itself, that would limit the places where the mouse position is tracked but it would allow any pop-ups to move with the tiddlers. As it is they stay in the same position relative to the document even when the tiddler river moves.

[PMario]

On Tuesday, March 24, 2020 at 12:07:17 PM UTC+1, Jed Carty wrote:

...

I may have to add a mouse move handler to the $mouse widget itself

Yea, I was thinking about that too.

 

, that would limit the places where the mouse position is tracked but it would allow any pop-ups to move with the tiddlers. As it is they stay in the same position relative to the document even when the tiddler river moves.

This may probably be a nice "side effect" :)

-m

[Jed Carty]

I made some updates. There are two different things, one tracks global mouse position and has the drawbacks that you saw, the other tracks mouse position inside the $mouse widget but works in separate windows and will move with the tiddler as expected.

The reason for the global one is that it lets you get the mouse position in places where wrapping everything in a mouse widget would be awkward. I am not sure if that is really necessary but I didn't see any reason to remove it so I didn't.

[Mat]

Jed - a big thank you! I am currently overloaded with work but hope to look properly at this in the weekend.

<:-)

[Mat]

@Jed,  the readme  https://ooktech-tw.gitlab.io/plugins/mousey/#%24%3A%2Fplugins%2FOokTech%2FMousey%2Freadme

points to a missing tiddler, i.e it says "If you are going to make popups using this read A note about popups"

As noted in my OP here, for EditorMagic I hope to somehow set the position for a popup (currently a div, see comment here below) so that it shows up below the cursor in the editor. If this is not described in that missing tiddler, how can this be done?

Another thing that has come up since I announced EditorMagic is the the enhancement of the ActionPopupWidget with the $coords attribute: https://tiddlywiki.com/prerelease/#ActionPopupWidget

I can't tell if it is possible to use the ActionPopupWidget in edit mode but, if it is, would it somehow be possible to capture the coords via your (@Jeds) creation and feed it into the ActionPopupWidget?

Thank you Jed!

P.S I now have vacations for a week so finally some time to get gritty with this.

<:-)

[Jed Carty]

You should be able to put it into the correct form for the popup widget, the demo on the prerelease site isn't doing anything for me so I am not certain. And if we need to I can make a pull request to add separate x, y, h and w inputs.

[Jed Carty]

The demo was just doing something other than what I expected. The two widgets shoal be able to work together, you would have to use a helper macro to put the coordinates into the (x,y,h,w) form. One potential problem is that the mouse widget gives the location relative to either the full wiki or to the mouse widget container, the popups need to be placed so that they can work with that.

I will look at the plugin and see why it is missing a tiddler.

[Saq Imtiaz]

I suspect what Mat needs is actually the co-ordinates of the caret in a textarea, and not the mouse cursor position.

Should be possible to wrap this in a widget or action to get the job done:

https://github.com/snowgoon88/TW5-extendedit/blob/master/plugin/files/cursor-position.js

[Jed Carty]

I updated the mousey wiki to include the missing tiddler.

[Mat]

Saq Imtiaz wrote:

I suspect what Mat needs is actually the co-ordinates of the caret in a textarea, and not the mouse cursor position.

Yes... I'm almost nervous to say it after all the work Jed has put into the mouse thing which, however, I can also see use for for other ideas. For one thing, one could imagine View mode editing of a tiddler by clicking at some point where one wants an editor to pup up. But, yeah, the idea with EditorMagic is to get the popup where the text cursor is because this is where the popup trigger is as one types it. I was not aware of the term "caret".

 

Should be possible to wrap this in a widget or action to get the job done:

https://github.com/snowgoon88/TW5-extendedit/blob/master/plugin/files/cursor-position.js

...yeah, unfortunately I have no idea how to do this. 

<:-)

[Mat]

Anyone, is this guess correct:

The ActionPopupWidget requires an action to execute so this means it cannot be used in EditorMagic because the idea there is that the user merely types some string combo, e.g [[,  as part of the normal typing, and this has to be enough to trigger the popup. - Correct?

The current solution is a persistent div but styled with display:block or display:none depending on if any of the triggers are detected (via a persistent regexp search on the text field). 

<:-)

[Mat]

@anyone who's interested

I've made http://titlepicker.tiddlyspot.com and I think it is a functional little macro that can bring value to people. What is really missing is for the picklist to not steal real estate like it does now, so I figure that having the picklist as a popup at curs.., eh, caret position is what makes most sense.

Because the popup is to appear without any action (other than from typing the triggering string in EditView) I figure it has to be a div, not an actionwidget (such as button-triggered popup). I am happy to discover that the solution snowgoon uses for this (as mentioned in the OP above) is he very one that some consider the best method, as originally found here https://github.com/component/textarea-caret-position and demoed here.

<:-)

[Jed Carty]

I made a plugin that uses the method you linked to.

Me and css are not friends, and this method feels very hacky, so there are some bugs to work out. But the idea is there and it is usable at least.

To test it out go to the examples tab, check the enable cursor display checkbox and start typing in the text box.

https://ooktech-tw.gitlab.io/plugins/caretposition/

[Mat]

This is very exciting! Thank you so much Jed! I did some quick testing and I got following scroll to work but then I flubbed it and lost what I did, but I'll find it. One problem is a div surrounding the tc-caret div which has position:fixed - I assume this div is from the widget, right?

(So no misunderstanding: My work starts again thursday and tomorrow I need to get a new computer and do all works things I've procrastinated over the holidays here, so I'll only be able to fiddle in small parts at a time for a while but it'll eventually be a key part in EdiorMagic so... well, again, thanks Jed!)

<:-)

[Jed Carty]

Yes, it is fixed for a reason, the plugin creates a div that coves the visible area on the screen and the marker is placed on that, otherwise I couldn't find a way to allow the cursor to be anywhere on the screen. I briefly tried making the widget like the mousey widget where you wrap the area in the widget but that was giving me trouble getting the location of the pointer, I am not sure what the problem was there. Like I said, I me and css aren't friends.

[Mat]

Maybe this is what you just said is not possible but:

Using the inspector, it seems to me that the popup is positioned outside of the river. But for it to move with the tiddler, it should probably use the tiddler as the frame of reference for position. I'm thinking the position on the screen is not what matters IF the frame of reference for position is the tiddler. -?

<:-)

[Jed Carty]

I tried that and couldn't get it to work. I only spent about 2 hours on it and am bad with CSS, so it may be possible

[Mat]

Did you by any chance look at how Snowgoon did it? If I understand right, his version requires an alternative editor - could this position issue be why? Trying to use the inspector tool on his popup indicates that his popup is generated inside the editor:

I'll do more css experimenting in the weekend.

<:-)

[Mat]

OK, to get the popup to scroll, it at least works in the inspector tool if I drag'n drop the div from under the river up into a tiddler frame to get this:

I use the following style for the div:

  pointer-events: none;
  position: absolute;
  height:0;

...and for the

 

.tc-caret {
  pointer-events:none;
  position:absolute;
}

Could you try this?

Thank you Jed!

<:-)

[Jed Carty]

Mat,

You are much better with css than I am. I had to add on the scroll position to the position value but it works. The only problem I have found is that when you are typing in the search box and then you scroll the story river with the popup active it will scroll with the river, but once you continue typing it goes back to the correct position.

There is still the refresh problem where the position is always one step behind where it should be, that should be able to be handled with the widget somehow, I need to look into it. I will push the changes in a moment.

[Alain Dutech]

Hello,

I had a *quick* look into your code (https://ooktech-tw.gitlab.io/plugins/caretposition) and I wanted to share some thoughts.

1 - the fact that the position is always one step late is *MAYBE* because your event handler for the "input" event of the active widget is called before the regular input event handler (for example, before a textarea has received this event and inserted a caracter after the user has typed something), so for your event handler, the caret position is the position BEFORE the input of the user is really processed. But I am not sure.

2 - if you want to detect/react to arrows and other keys, the "input" event is not the good one to track. I chose to do most of my processing on the "keyup" event (in part, also, to address problem 1) above).

3 - it is a very nice idea to store the result of the caret position computation into a Tiddler. In fact, it might be the only way to have a wikimacro or widget be able to use this information to display a popup without having to rely on some more javascript.

4 - currently, I have the impression that the carret position is stored globally in two attributes of $tw ? It is a work in progress I guess, end ultimately you would like to store theses values in a tiddler ?

You approach (the CaretPosition in tidddler and the EditorMagic you aim at) is indeed way more generic than my approach which targeted only special pattern in a textarea. My approach would not work on a title editor field, or on a tag editor field.

I am not sure that a global behavior is in fact needed. Have you a list of all text fields or areatext where popup information under the caret would be needed ?

In the meantime, I will try make a more compact module/widget/plugins with only one function : put the current carret position in a tiddler, while reusing what I did, but with no processing at all from the text under the carret. I let you know if I make any progress.

Snowgoon

[Mat]

I'm at this again hoping to get it to work.

@Jed, for some reason your plugin doesn't work for, specifically, the tiddler text field editor. It does work for the other fields, e.g in the title field. I set up http://testing-cpos.tiddlyspot.com/  to show the problem. The wiki is basically an otherwise empty wiki. The password is password if you want to test something. Do I misunderstand something?

@Alain, thank you for taking a look at this! If it's not clear, it's Jed that has kindly made the caret position code. Did you happen to progress anything in what you state last, i.e to put the current caret position in a tiddler based on your previous work?

If people have forgotten by now: The idea is to first create a title picker but the bigger idea - which should be extremely useful - is a generic popup that can show anything, including title picks, macrocall picks, filter operator picks, image picks or really any information. This immediate accessible toolbox should much speed up and simplify authoring.

<:-)

[Mat]

Mat wrote:

@Jed, for some reason your plugin doesn't work for, specifically, the tiddler text field editor. It does work for the other fields, e.g in the title field. I set up http://testing-cpos.tiddlyspot.com/  to show the problem. The wiki is basically an otherwise empty wiki. The password is password if you want to test something. Do I misunderstand something?

Hm, I should have waited to post for yet another 30 minutes because now I finally found it: Apparently, for the popup to show in the main editor, the tiddler $:/config/TextEditor/EnableToolbar has to have been actively set to "no", which is not the default value in TW. (By default, that tiddler doesn't exist. It is an option in the $:/core/ui/ControlPanel/Settings/EditorToolbar ). I don't see any mention of this tiddler in your plugin so I'm wondering if it is incidental or what's happening. Could it be "removed" or perhaps automatically set when one creates a popup tiddler?

Thanks!

<:-)

[Mat]

@Alain/Snowgoon, you ask

[...] Have you a list of all text fields or areatext where popup information under the caret would be needed ?

Well, the critical one is the main editor. If the popup can be made to work properly there, then 90% of all needs are probably covered. Basically, the popup is  needed where access to tools or information is needed.

 

<:-)

[Jed Carty]

Mat,

I am getting the same problem you are in the normal text field, but only when the editor toolbar is enabled. I vaguely remember something about the text editor using something special when the editor toolbar is used so you don't lose the cursor position.

What the something special is I don't know, but finding that may point us to a solution.

[Mat]

@Jed, thanks for confirming. You probably already know but, there's mention of $:/config/TextEditor/EnableToolbar in $:/core/modules/editor/factory.js so maybe one can figure out the purpose with it there... ?

Another Q: How can I access the current tiddlers title from within the popup? Doing <<currentTiddler>> shows the name of the tiddler containing the caret macrocall.

Thank you!

<:-)

[Eric Shulman]

On Friday, June 26, 2020 at 4:23:18 PM UTC-7, Jed Carty wrote:

I am getting the same problem you are in the normal text field, but only when the editor toolbar is enabled. I vaguely remember something about the text editor using something special when the editor toolbar is used so you don't lose the cursor position.

What the something special is I don't know, but finding that may point us to a solution.

When the editor toolbar is enabled, the text editor uses an IFRAME to encapsulate the edit field.  By isolating the edit field within the IFRAME, it maintains it's own focus and thus the cursor position is unchanged.  Otherwise, clicking on a toolbar item would "steal the focus" from the edit field, thereby losing the cursor position.  Perhaps something can be done by using "onBlur" event handing to capture the cursor position and use that when processing an editor toolbar button?

-e

[Mat]

@Jed

To clean up a little, I modified the stylesheet (see attached)

...and consequently, the inline styledef appearing in $:/plugins/OokTech/CaretPosition/PointerSurface needs to be removed.

The styles are now somewhat opinionated but it should make it easier to work with for now. 

As noted, I need to access the currentTiddler or I can't put anything meaningful in the popup.

<:-)

[Mat]

BTW, if anyone is curious about the current status, you can see and test it here:

http://titlepicker2.tiddlyspot.com/

<:-)

[Saq Imtiaz]

@Mat I am not familiar enough with your code to be able to offer an opinion.

Sometimes these issues are due to transcluding like {{template}} instead of {{||template}} or {{mytiddler||template}}

Another option would be to save the value of currentTiddler to a different name like current, higher up in your code.

In the meantime try using this instead of currentTiddler:

{{{[<storyTiddler>get[draft.of]]}}}

[Mat]

Saq Imtiaz wrote:

In the meantime try using this instead of currentTiddler:

{{{[<storyTiddler>get[draft.of]]}}}

Ingenious Saq!

Now it actually works well enough to clearly convey the concept:

http://titlepicker2.tiddlyspot.com/

<:-)

[Alain Dutech]

Some answer in text. And a question below...

Le ven. 26 juin 2020 à 22:25, Mat <matia...@gmail.com> a écrit :

I'm at this again hoping to get it to work.

@Alain, thank you for taking a look at this! If it's not clear, it's Jed that has kindly made the caret position code. Did you happen to progress anything in what you state last, i.e to put the current caret position in a tiddler based on your previous work?

No, sorry, had no time to advance on this. But it seems @Jed did a wonderful job about this.

Another concern of mine for you is the way you will handle keys to navigate within the popup windows ? Will you need this functionality ?

I'm asking because you said earlier that getting the coordinate of the carret was 90% of the job, and accordingly now you can position the popup. But this popup will stay informative (and not interactive) if you cannot intercept the keyboard to alter the popup, right ?

Is this possible using only wikitext and wikiwidget in TW5 actual version ?

(Sorry, I'm stuck in the past with version 5.13 of TW5).

Alain

 

If people have forgotten by now: The idea is to first create a title picker but the bigger idea - which should be extremely useful - is a generic popup that can show anything, including title picks, macrocall picks, filter operator picks, image picks or really any information. This immediate accessible toolbox should much speed up and simplify authoring.

<:-)

--
You received this message because you are subscribed to a topic in the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywikidev/scGK9fBKsZ8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tiddlywikide...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/0eb30113-5ac9-4f1a-bf52-3489ea09f405o%40googlegroups.com.

[Mat]

Alain

Key navigation would be great and I believe other fellow tiddleurs are doing work on that independently of EditorMagic. But it is already possible to select titles in the popup by clicking with the mouse, so I'm not sure what you mean.

With the popup-at-caret (partly) solved, I can now make a prototype to sufficiently demo the concept so people can "get it" and see why it will be extremely useful for editing in TW. If you missed it, here's the current status for TitlePicker:

http://titlepicker2.tiddlyspot.com/

Note that the popup issues you identified in your previous post here are still present.

<:-)

[Alain Dutech]

Hello,

regarding key navigation and selection (through ENTER for example), it is just that I often work on a laptop and I am used to do everything on the keyboard, without the mouse. But selecting with the mouse is a nice first step.

regarding the popup issues, if you mean that the popup is "late", I still think my remarks/advice still holds. But I do not have time to have a deeper look into the code. Sorry.

Nice and interesting work.

Alain

--

You received this message because you are subscribed to a topic in the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywikidev/scGK9fBKsZ8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tiddlywikide...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/634837de-3ea3-48c0-812c-1861e8c66a29o%40googlegroups.com.