when editing text in gimp the text tool is displayed on the screen.
Sometimes the text tool is blocking my view when adjusting or if I zoom in a lot, is not displayed in the visible portion of the screen.
How can I move the text tool itself, so that it is in a place where it does not obstruct any important part of the image.
Btw: This is the text tool:
You can't (this is a rather common complaint).
Related
I'm trying to use TUI Image Editor (https://github.com/nhn/tui.image-editor) in my Cordova app on Android.
It is based on Fabric.js and overall working reasonably, however I have major problems with the text annotation: If the edited text is in the lower part of the screen, the Android softkeyboard is covering the text input and doesn't scroll it into view. This also happens when I run the page in the normal Android Chrome browser.
Are there any recipes or examples how to get that working with Fabric.js?
I had the same problem, and I just avoided using the IText and Textbox objects. I just used the html input field and object with type Text in fabric.js without editing inside canvas, and editing inside input and changing text object to input value. Because if you will use the IText and Textbox objects, you will face problems with editing text on small texts, or text objects with a small scale, where editing inside canvas will be difficult and annoying.
If you still want to scroll to text object I can't give you a full solution. But I think you can use canvas events for text
canvas.on('text:editing:entered', (textObject) => {
// calculate canvas offset and textObject offset and scroll to this position
})
Sublime displays one panel at a time. Is there a way to cascade the panels on top of each other. For example when displaying the console, if I do super+f, the find panel should also display along with the console panel.
This is not possible; Sublime only wants to display a single panel at time and so the command that opens a panel implicitly closes any panel that might already be open first (at least logically).
This is part of the original design philosophy. As seen in the excerpt below, a desire to maximize space as much as possible is also one of the reasons why the find panel (for example) is a panel and not a Dialog or something else that would take up unnecessary space.
Unobtrusive, minimal chrome. The focus should be on the text, not fourteen different toolbars.
Don't obscure the text with dialogs.
Use the pixels you've got. Full screen, multi monitor and editing files side by side should all be possible.
I have read the documentation for the Color Schemes. I realized all settings except invisibles and shadow (+shadowWidth). I can translate from English, but I do not see anywhere where the elements, the color of which changes settings. Does anyone could show me the screenshots, where there are elements which change color? Thanks.
From the unofficial documentation on color schemes, linked to in your question, we can see that invisibles is ignored, so changing it has no effect on the appearance of any elements in ST3. The tmTheme format is borrowed from a different text editor, to make it easier to use the same color scheme in different editors. So maybe it does something in other text editors, but not in ST. EDIT: support for invisibles has been added to ST in build 3149 - https://github.com/SublimeTextIssues/Core/issues/1992.
The effect of the shadow setting can be seen below, it is the pink parts on the far sides:
It is only visible when the text in the document is wider than the window - it will appear on the left when the view can be scrolled to the left and it will appear on the right when the view can be scrolled to the right.
From my testing, including shadowWidth in the tmTheme file will cause the shadow to not appear. I have logged an issue in the unofficial documentation here, maybe someone will update it with details of how to get this working.
Note:
When making changes to atmTheme file, it is often necessary to close all open documents, and restart Sublime Text, before the change will become visible.
I have a CodenameOne application which has a TextArea that should display a multi-line text.
When I run the app in the simulator and click on the text-area, the spacing between the lines and possibly also between the characters change so that the area that the text occupies shrinks a bit.
Why is this?
What should I do to prevent it?
That is due to the switch from our drawing to the native editing which will always render things slightly differently. E.g. things like line spacing are really hard to get accurately for every native device.
TextArea has a setRowsGap method that allows you to specify the spacing between rows in pixels but since this differs between OS's its probably not ideal.
I've developed a shell (imitating the ubuntu terminal --> can only edit text after current prompt) by a PyQt QTextEdit.
The thing is when I select some text, the cursor moves as I'm selecting this text (so it disappers from the current command line) and I would like the cursor to stay where it is (only when I select text because I want it to move when I move it programmatically by textEdit.moveCursor(...)) at the same time I'm selecting the text.
Does anybody have any idea of how could I do that?
My solution for now, is to save the position at any change of it (except when it changes by a click), and when I copy some text en paste it, it'll be automatically pasted in the last position the cursor was before the click. That works perfectly but it's "ugly" for the user because, as I said, when he selects the text the cursor disappears of the current line and is where the user is selecting the text. Not like in ubuntu terminal.
Thanks in advance! And sorry for my english.
Adri
I don't see an easy solution to implement this with a text editor API. A terminal is a hack, basically. It mixes a read-only element (anything above the current prompt) with a text editor.
My approach would be to create two text editors, make one read only and display the results of all operations there. If you hide the borders of the two editors, then it will look like a single one. You may have to forward a bunch of events (like scrolling with the keyboard) to the read-only display.