DumbPad v03

@javier,joerg
Quote:

I build simple test case where just open a window and texteditor in. So, GA_TEXTEDITOR_FixedFont DEFINATELY works. When i set it to TRUE, i do have fixed font for sure. When to FALSE, do not. But when i tried to do so in dumbpad, then it didn't work.. strange! I.e. in dumbpad it's :



In test case where it works:




Need to play with flags a bit ..

Anyway, i need to understand how this flag is choose what font to use depending on TRUE and FALSE for GA_TEXTEDITOR_FixedFont ? Because my system one for now is DejaVu Sans MONO , which in any size are "fixed size" one, but then when GA_TEXTEDITOR_FixedFont to False, which font it then use ?

Just want to got how it all handles to not recreate a wheel.

@kas1e
Quote:The "Screen Font" from Fonts prefs, which can be changed for individual screens in Screens prefs as well.
The always fixed width "System Default" font, topaz/8 in old versions of AmigaOS without such prefs, from Fonts prefs is used for GA_TEXTEDITOR_FixedFont, TRUE, and anything else requiring a fixed width font.

I noticed that in the "Screen Font" settings, I have DejaVu Sans 18, which is not a fixed-width font. However, when using GA_TEXTEDITOR_FixedFont, TRUE, the TextEditor gadget does not select topaz.font but instead seems to choose DejaVu Sans Mono 18. This suggests that the texteditor.gadget code likely includes some font-scanning functionality. Does it first search for a fixed-width font with a name similar to the current screen font (e.g., appending "Mono" to "DejaVu Sans")? If none is found, does it then proceed to other fonts in the system font list?

Regarding the issue where GA_TEXTEDITOR_FixedFont, TRUE does not work, I found that it fails when the TextEditor object is added directly to a Layout gadget. However, it works correctly if I place the TextEditor inside a Page gadget, which is then added to the Layout. Since page.gadget is primarily designed for use with ClickTab to manage tabbed content, using it to fix the TextEditor font issue feels like an odd side effect rather than an intended feature.

To me, GA_TEXTEDITOR_FixedFont should work consistently, whether the TextEditor is placed directly in a Layout or inside another container (like a Page) before being added to a Layout. This seems like either a bug in the Layout class or the TextEditor class, or perhaps both. It appears that the Page gadget provides a more suitable initialization context, enabling GA_TEXTEDITOR_FixedFont to function correctly, whereas adding TextEditor directly to Layout does not.

@kas1e
Quote:Your "System Default" font is obviously DejaVu Sans MONO 18.
I'm not sure if there still is a Prefs/Fonts, several of the older and small prefs programs were merged into Prefs/GUI.

No idea about the root vs. page layout difference.

@joerg
Quote:

17 one, and i got it now, "System Default" can only be of fixed fonts, right ? So not surprise it take this one.

But when GA_TEXTEDITOR_FixedFont, FALSE, i assume it takes not the "System Default" one, but some other ?

(prefs/font still there, not in prefs/gui)

@kas1e
Quote:Yes.

Quote:"Screen Font".

@joerg

As it seems that GA_TEXTEditor_FixedFont still acts stragely, i go TextAttr way, and just make it a bit more heavy : checked firstly for "System Default" by GraphicsBase->DefaultFont, if there is issues with, then i get "Screen Font" one, by pubscreen->Font->ta_Name. And if there also issues, then fallback to topaz (Through that probably will never happen, but who know):

@All
V0.3:

(click open in new tab for fullsize):



Changes:



Link: https://kas1e.mikendezign.com/aos4/dumbpad/v03/dumbpad_v03.lha

Plz test it as much as you can, and report bugs, thanks!

What i want to add as the last bit of features (at least, until realize that miss something badly) : is marking of the text not by lines, but by lines and columns : like in notepadd++, you hit "alt" key (will be "amiga" one for us), and then my mouse can mark in any direction : horizontally and vertically. Pretty help to delete blocks. Through, as texteditor.gadget for sure didn't support this, this need to be think how to do properly ..

@kas1e

Thanks for adding the search for text content, that's great. Since I am interested in searching for texts and I often use such a function, I noticed that when searching further in the text file itself, the find button has to be clicked each time to continue searching.

Here I would like you to add a "Next" button in the "Find Text" window or something else so that the search can continue until the entire text file has been searched.

And yes, I know that the search is continued via the title bar of the WB via "Next find", but this is also somewhat cumbersome and time-consuming.

Another possibility would be to leave the "Find Text" window open when searching for texts and when clicking "Find" again, the search will simply continue until the end of the text file.

It is not ideal to have to click the Find button every time to continue the search for texts. This is not a criticism, but simply a suggestion for improvement.

Otherwise really great.

@Maijestro
Wait, but you only need one time to hit "F3" (on keyboard) then type in this window what you want to search, and then, hitting F3 (without any new window opening) will continue to search what you type: just like in all modern editors.

I.e. when you have text, hit F3, type what you want to search, hit "enter" 2 times , and then, you can simple hit F3 for next search without any additional clicking/hitting/window opening and it will search in a loop until you hit f3 for a whole text one by one.

Or you mean something different ?

Quote:

You don't need that, just hit F3 key and it will search for the next without any window. Again f3 - next, again - next, if text ends, then it will start from beginning.

Quote:

Of course ! That why you have keyboard shortcut : F3 : no window, no worries, just f3/f3/f3 and you it will be next/next/next. Just like in same notepad++ , or vscode, or any other modern editor anywhere.

@kas1e

Quote:

ahhhh ok I didn't know and yes it works perfectly via f3 Will you also add drag and drop via AmiDock?

@Maijestro
Quote:

That was reasson to add input handler interrupt , so we take over over the texteditor gadget input code, and add our own : i just love this "f3 for next search" on every editor i use, it's really make work fast.

Quote:

If it have it's use, why not ..

@kas1e

Quote:

You also have to see it a bit from a user's point of view and not like developers do. And of course I want to put DumbPad in my dock as soon as it's ready so that I can access it quickly, the ability to quickly drop or display text files via the AmiDock/DumbPad icon is something I'm already used to from NotePad and would be a great feature