Take Cursor out of text block and Select text frame

Previous topic - Next topic


Trying to figure out an issue, and not sure if its a bug in the scripter api or not.

If you have a text frame on screen and you are entering text, you have the cursor in the text frame as you type.

Is there an API call that will take the cursor out of the text frame and select the text frame?

see image : "cursor_in_text_block.png", I want to be able to select the text frame as in pic  "text_block_selection.png".

Im on a mac running 1.5.6.snv r.23014.

[attachment deleted by admin]




Here is a very basic example of the issue that im having.

I have 1 text frame on my Scribus doc and its called "Text1".

I also have the below sample script.

import scribus

textframe = scribus.getSelectedObject()



If you follow this order:

1.  When I enter some text into my textframe, click out of the text frame and select the text frame again so its selected, I run the script to simply copy/paste the object.

works great and it pastes the text frame onto the page. (as shown in screen shot textframe_selected.png).

2. If you do the same thing, enter some text into the text frame, and keep the cursor in the text block as if you are entering more text, and then run the same script.

If you look at the attached screen shot, this is the result I get (see cursor_in_textframe.png).

its putting in the textframe inside the existing text frame etc.

Is this a bug, or am I doing something incorrectly with the script?  I would like to copy/paste the entire text frame as if I had it selected in the first example. (We cant rely on the script to work depending on where the end user has something clicked).

running MacOS and scribus 1.5.6 r. 24102 now.

[attachment deleted by admin]


i could not replicate your use case.

but i've now created a patch for setNormalMode() and uploaded it to the bug tracker:


let's hope it gets into scribus soon...

and now a question from my side: does anybody see a reason for having also setEditMode().
it's in the patch, but i'm not sure there is any use for it...


Hi a.l.e,

This is awesome!, looking forward to seeing it in an upcoming svn release.

Re: setEditMode()

Im assuming setEditMode would be similar to my initial image "cursor_in_text_block.png" ?

it would definitely be useful to be able to select specific text frames and then place text into them.

(However, the way selectObject works right now with text frames, would it not be very similar to setEditMode ?)



as far as i can tell, there is nothing you can do with setEditMode() that is not already possible.

for sure, you don't need to go into edit mode to modify the content or its formatting.

jean is suggesting that we could have setMode() and allow any of the modes... but i really wonder if there is a need for it.

as far as i can tell, we really only need the setNormalMode()...

and even that is more of an error in the way the scripter works: when you try to apply a format to a full frame you might have some surprises, if the users was in edit mode before starting the script.

(probably, it would be better to rethink the whole concept of how to apply formats to a whole frame, but switching to normal mode is the easier path...)



the more I dive into it, the more I see a need for "setEditMode()" as well.

One example, we run a script on scribus launch and we want to have the cursor already in the correct field ready for typing. having setEditMode() would allow us to achieve this.

Im still trying other existing options, but I dont think its possible.


what is the script that would do that?
what is the use case?

and what about getting the user into node edit mode for a bezier?



In our case, we use the command line to open scribus each time, which passes the correct scribus doc to use (one out of hundreds of templates), we also run a .py script on startup that performs any maintenance needed ie. doc zoom levels etc.

Our scribus docs/templates contain many objects on the page. By having "setEditMode()", we would not have to deal with finding the correct text frame /location they need to enter the text (our script would deal with that), and the cursor would be in the text frame for the end user to simply copy/paste content or type.

overall it provides more capabilities to automate things and much less user clicks.