Open Viza74 opened 5 years ago
The mode should definitely switch back to har and color i the user selects something in the character palette with the mouse as with all the other tools.
+1
There is a (to me) strange, in-between mode(?) when I press Esc while using the text tool, when the text cursor jumps back to the mouse cursor and behaves almost like when drawing (wasd works again for example), but we are still in text mode. I don't know that is probably for relocating the cursor with the mouse? To me it's just confusing :-/ Relocating could be done any time with themouse, without the need for a separate "mode". I suggest Esc should just switch back to char and color mode
Good observation. I would recommend to generally use ESC to switch back to drawing mode. That's the default to cancel all other modes.
Usually in painting apps when you click with the text tool, the mouse won’t move the cursor anymore (unless you left click). So I’d be -1 on changing this part.
But the two other suggestions (esc and click char select switches to draw) are without question improvements.
I would recommend to generally use ESC to switch back to drawing mode. That's the default to cancel all other modes.
Hmm, no, Esc does not cancel other modes right now, it only has special function in the brsuh mode, to reset the mode - I guess thats actually what happens in the text mode too. But while in brush mode that made sense (somewhat), in text mode not really.
Usually in painting apps when you click with the text tool, the mouse won’t move the cursor anymore (unless you left click). So I’d be -1 on changing this part.
I don't understand this reasoning... Let's see the workings from the users viewpoint. If the user assumes what you say (that in text mode you cannot relocate the cursor with a click), the she will never try clicking, so there are no confusion. If the user do click on the canvas in text mode, she expect something to happen, and be confused if not. To me it seems perfectly natural to use the canvas click as cursor relocation - much more than just ignoring user input, or using esc to switch to "relocate mode", or worse forcing the user to switch to another tool and back...
Yeah so now the mouse click relocates but you need to leave ”keyboard capture” with esc first. To me this works beautifully and clearly, but of course it’s obvious to me since I implemented it.
Maybe the confusing thing is that the cursor looks the same in both keyboard capture and mouse cursor relocate modes. I wonder if just using s different looking cursor in mouse mode would clear the confusion?
Changing the cursor would probably help, but I feel that would be only a bandaid... Just relocating the cursor with a click is way more straigthforward/streamlined solution. Also in other programs text mode you can relocate the cursor with a single click - granted only in the already written text, but you can think of the whole screen as already written, and than it is the same. :) Also there are text editors with support for clicking anywhere on the page, and just typing there - I think even Word supports that with a mode, if I remember well. Granted thats an somewhat obscure function for a text editor, but a pretty usefull one for a texmode graphics editor. :)
Oh right.. I may have brainfarted a little bit in my previous comments. :)
I misunderstood what you meant earlier and got off on a tangent. I think I now understand what you mean.
So when the app is in the text mode and typing characters with the keyboard, the "c64 like" cursor stays whereever it is. But if you move the mouse and the normal mouse pointer moves to a new location and you click, the "C64 text cursor" is moved there?
Maybe when in text input mode, there’d be a char select hover like cursor that moves with the mouse cursor? Currently the mouse cursor is always a c64 char block like pointer so using the normal pointer feels a little off.
Or did I still misunderstand you?
Just relocating the cursor with a click is way more straigthforward/streamlined solution.
I just played with Petmate a little and realized that this is actually the way it already works.
What's left to be done here? I just added "select draw tool" when picking a char or using alt-left click to select a char.
Maybe the alt-commodore key translation for the text mode to access the other set of graphical characters and colors with keyboard? Not that important really, just for consistency shake if the shift+key part working.
@Viza74 So here's how the text tool works now: https://youtu.be/lWaP132k9_I
It's basically exactly the same that it was in the release candidate build except that I show a box hover around the cursor location.
So when you start writing text with the text tool, you get a "text cursor" which you can move around by typing text and using arrow keys. If in this mode you also left-click another location on the canvas, the text cursor moves there. This is the way it worked earlier and this is the way it works now.
IMO the hover cursor helps a bit to make it feel like you can still click another position on the canvas to move the text cursor around.
Text mode seems nice, but has some strange things - not necessarily bugs, but somewhat confusing for the user (at least for me :) )
The mode should definitely switch back to har and color i the user selects something in the character palette with the mouse as with all the other tools.
There is a (to me) strange, in-between mode(?) when I press Esc while using the text tool, when the text cursor jumps back to the mouse cursor and behaves almost like when drawing (wasd works again for example), but we are still in text mode. I don't know that is probably for relocating the cursor with the mouse? To me it's just confusing :-/ Relocating could be done any time with themouse, without the need for a separate "mode". I suggest Esc should just switch back to char and color mode
Is there a modifier key to access the right side petscii chars on the keys (the commodore key on the original hardware)? Shift works fine to access the left side ones, but I can't find the key for the other. I think petmate should support a... hmm... "full(ish) commodore keyboard simulation" :) for the text mode - maybe alt for the commodore key, and switching colors with commodore(alt) and ctrl+numbers