tedit development and design discussion
-
@Br1 True, not having to swipe a note to open it is something I would prefer too.
I will think if having several start page options is possible: new (empty) note, notes list, last used note. But not sure yet if that is easy to do.
I will certainly not only support dark theme. Many users like Ambiance too. So an app needs to support that. But I may reduce coloring options to make this work. Although maybe I add a setting for a fixed theme in tedit like other apps do (system theme, Ambiance, SuruDark).
-
@danfro said in tedit development and design discussion:
@Br1 True, not having to swipe a note to open it is something I would prefer too.
Nevertheless, swiping the app away will remain possible. What happens to the note being edited then? Are the unsaved changes lost?
-
@arubislander said in tedit development and design discussion:
@danfro said in tedit development and design discussion:
@Br1 True, not having to swipe a note to open it is something I would prefer too.
Nevertheless, swiping the app away will remain possible. What happens to the note being edited then? Are the unsaved changes lost?
Yes, unsaved changes are lost on swipe&close of the app.
-
@danfro Sorry, but I'm not on gitlab. So I can't open a feature request.
Therefore I appreciate your survey here.
-
To open a note I would also prefer a tap instead of a swipe.
Having all notes on the initial screen would be a good option.
That unsaved changes are lost on swipe&close of the app is okay for me, because you get a red warning.
I like your idea of a toolbar. If there would be a save-button you may use two different colors for it. E.g. grey button (inactive) = note is already saved or black botton (active) = note is unsaved.
-
Hi, I got enough done to release a new version of tedit. Could you please test before I do release? The build can be grabbed from the latest pipeline here (https://gitlab.com/Danfro/tedit/-/pipelines).
Changelog is:
v.3.2.0- fixed: #1 notes page background color is now persistent
- added: #5 clear clipboard option
- added: infomessage, when trying to paste from clibpoard and clipboard is empty
- improved: edit area now resizes height when OSK is visible
- improved: all pages follow system theme now, except custom main pages background
- improved: settings page design, font size setting moved up
- updated: translations, many thanks to all translators!
(I know, not all features discussed above are included yet :smirking_face: .)
-
@danfro Everything seems ok for this version. Thanks again.
Curious to test a read-only mode to see how the UI reacts: because what has always bothered me a little in Tedit is, when scrolling through long texts with the swipe, the non-voluntary selection of text randomly which randomly too causes the message 'cut copy paste' to appear, which interferes with reading. Involuntary modifications of texts, without consequences if there is no recording, can be made. I always thought that scrolling text and having a clean visualization needed improvement in tedit if possible.
-
@danfro
I think I have installed from the right place, now tedit is perfect, when you change the wallpaper to black in the menu and in the options the chosen wallpaper colours stay
I like it better now, with these modifications
Maybe the share note option is missing, I think that putting the share icon inside the slide to open note is a viable solution,
Thank you... -
@Josele13 Thanks for the feedback. Share note is on my todo list for the next release.
-
Actually I consider to remove the word suggestion option in a future version.
If nothing is set, it is using whatever is set in system settings. I don't see much point in overriding the system wide setting within the app. Who does not want word suggestion will have it turned off in system settings.
It just fills the settings page. Also only word suggestion is turned off, not spellchecking. So it might confuse users that still something is suggested even with the option turned off.
Or do I miss any benefit to make it worth to keep that setting?
-
@danfro Personally, I've never used word suggestion in tedit. Just activating through the system settings seems enough to me.
-
@danfro I never use the spellchecker and neither do the word suggestions, you can remove it perfectly well, whoever wants to use word suggestions should use the system one.
Regards...
-
-
@danfro For scrolling long texts, I would see two scrolling buttons (text down or up) if it's possible which would allow a minimum use of the swipe Just an idea like that. If you think yes, i will make a feature request.
-
@domubpkm Do you mean a "jump to top" and "jump to bottom" button? That I can understand for long texts. From my usage I don't quite understand, how would pressing a button be quicker/better than swiping on a mobile device? Or are you talking about a tablet?
This is going to be tricky anyway, since the current swipe functionality is "built in" in TextArea. So likely going to be tricky.
-
@danfro said in tedit development and design discussion:
Do you mean a "jump to top" and "jump to bottom" button?
No, I apologize for any vagueness. The purpose of the buttons would be to gradually scroll the text either towards the beginning or towards the end.
-
@domubpkm You can already do that with the keyboard. Swipe to top and press the scroll keys which replace the keyboard keys, there is also something like a trackpad.
-
@domubpkm My answer wasn't clear enough too. But you confirmed my thoughts. My question tried to address this usecase with two buttons for gradually scrolling. How would that be better than swiping?
A button would either scroll line by line for fine placment. That I would think to be tedious to scroll large areas. But if scrolling several lines at once (how many?) fine placement would not be possible.
I would think a swipe does allow much quicker and more precise handling here. But since you ask for those buttons, maybe I am missing something. Would you want them for large files and jumping several (many) lines at once? Or for fine jumping line by line?
And I tried the workaround suggested by @ikoz , that works for jumping to top and bottom. The swipe is less nice than the swipe implemented in TextArea in my opinion.
-
@danfro Forget
. My goal is to find a mechanism so that the text is not polluted when scrolling. I have nothing against swiping.
-
@domubpkm Ah, thanks, now I understand what your goal is.
I will need to think up a mechanism to control the edit area. Another idea is to have a swipe area besides the edit area. But not sure yet what will be technically possible and what will work in terms of UI. Please file an feature request or issue for that, so I don't forget. But this might take a while to get sorted...
