2025-06-03 [v0.2] + Added - Drag-and-drop support for opening files. - Undo/Redo support. - Complex logic to handle application exit with unsaved data (for single and multiple tabs). - Command-line argument support for opening files. - Iconification support for Workbench. - Display of filename and path in the window title. - ARGB bitmap support for internal clicktab images. - AmigaOS versioning support. - Custom icon in the "About..." dialog. - Support for opening empty files. - Warning requester when a file is in use by another application during saving. + Enhanced - Debug messages split into `info` (internal) and `fatal` (user-facing) for clearer error reporting. - Version string and "About..." dialog dates now use the `__DATE__` macro. - Skipped NULL bytes to enable opening binary files.
Plz , give it a go, and report all bugs you find or what you think can be added/changed. Maybe worth to add this button on the right top of window border , near of iconify, to be able to do "snapshot", so to save size of window on start ?
But, IMHO, if we have nothing in buffer, then Paste should be ghosted, right ? At least that sounds logical and user will see right from beginning - paste ghosted, then nothing in the buffer.
I strongly agree with this - I believe in guiding the user as much as possible in the GUI by disabling anything and everything which wouldn't make sense to use, given the current circumstances.
It makes a user feel safe with a program to see that you are guided to not do anything wrong/confusing.
If at all possible, I think it should be done by disabling the button, i.e. make the effort to check whether there is anything in the clipboard already when setting up the GUI, and set up a DOS file notification (if possible?) to tell the program if anything is put into the clipboard (enable the button) or deleted again (disable the button). This should probably be standard behaviour/"best practice" for software using the clipboard.
(Note: I haven't yet had time to try 0.2, so I don't know if you've already implemented this.)
If at all possible, I think it should be done by disabling the button, i.e. make the effort to check whether there is anything in the clipboard already when setting up the GUI, and set up a DOS file notification (if possible?) to tell the program if anything is put into the clipboard (enable the button) or deleted again (disable the button). This should probably be standard behaviour/"best practice" for software using the clipboard.
Yeah, checking on running are easy, but setting up some event to be catched (so any other program change the clipboard, and our button should react): for now need to think how to implement better. Probably it should be in the same hook which listen for gadget notifications , in something like IDCMP_IDCMP, just what even to check what to set it up for clipboard.. Need to think about more cleaner way.. Maybe worth to ask Colin (dos.library author) how to do it better..
Currently i only think about some hardcore way, like add to WMHI_INTUITICK (which happens 10 times in a second) , a counter, which will be check let's say 1 time in 5 seconds, or in 10, a clipboard (via any method, there few) and act accordingly. That of course not an even, but should be ok too.. Or going heavy like create some simple commodity for clipboard.device at start, just hide it, which will send events, but it's imho too much, INTUITICKs are easy.. Of course, if nothing else possible.
@javier Quote:
Any chances to have/use fixed font size in edit?
Why not, just i dunno how to test if it make any differences: i tried yesterday to set GA_TEXTEDITOR_FixedFont to TRUE, but have no differences.. That probably will not take effect with any font used in system ? (i use DejaVu Sans ones).
Quote:
about _DATE_ macro wortks fine, but isn't "amigalike", you can use this on makefile:
Yes, i just hope to avoid makefile for now, and thinking about just a bit overload __DATE__ macros inside of code, but thinking that this is too much for just date, but maybe you are right, and need to go more amigaish way
Yeah, checking on running are easy, but setting up some event to be catched (so any other program change the clipboard, and our button should react): for now need to think how to implement better.
- CBD_CHANGEHOOK should only be used by a special application, such as a clipboard viewing program. Most applications can check the contents of the clipboard when, and if, the user requests a paste. - Do not add system overhead by blindly reading and parsing the clipboard every time a user copies data to it. If all applications did this, the system could become intolerably slow whenever an application wrote to the clipboard. Only read and parse when it is necessary.
So while I agree with you and Nils it would be nice to have the Paste button ghosted when the clipboard is empty, I don't think AmigaOS provides good tools for all applications to do this. In Rave, multiple clipboard units can be used for copy/pasting. In SoundFX, any of the 256 units can be used for that. Now imagine that an application installs a change hook on all units it supports, only to be able to ghost a button!
@Trixie What if create separate monitoring process via createnewproc() with a timer, by which run something like own CheckClipboard() (and doing it let's say 1 time in a 0.5 second) which will send notifications with a flag to our appPort of winObj (and send notifications only if clipboard changes, but crc32 content of it or so). Then in our WM_HANDLEINPUT handle this event, and call UpdatePaste() which will do ghost/unghost of button/menu.
by this way we catch any changes in clipboard, calling it every half of second is nothing even for a1200 with 68020, and it will take only few KB of the memory for process.
And for clipboard's changes just textclip.library can be used, so code is tiny. But yes, just for CLIPUNIT_0.. But then, "paste" only do paste from unit 0 if i understand texteditor.gadget well..
First of all, thank you very much for your tireless work in promoting OS4 :) I already find Dumpad very useful because it is small and fast, really great. Just as an idea, could you maybe add tooltypes so that you can adjust the window size and position of DumbPad? e.g. WinPos top/bottom/center ... Win_height ... Win_width ... and also a localization would be great But even now DumbPad is a really great tool, thanks again :)
by this way we catch any changes in clipboard, calling it every half of second is nothing even for a1200 with 68020, and it will take only few KB of the memory for process. And for clipboard's changes just textclip.library can be used, so code is tiny.
But you'll still need to read and interpret data from the clipboard to determine what has changed. (If you don't, Rave copying audio data to the clipboard will unghost your Paste button, which is something you don't want.) Doing this every half-second will certainly add overhead.
For use Fixed font "juts" need to parse font.prefs and the use the fixed font size ... and use "GA_TEXTEDITOR_TextAttr (struct TextAttr *) (V50)" (hope it works)
Should work, but looks like a complicated version of
and set up a DOS file notification (if possible?) to tell the program if anything is put into the clipboard (enable the button) or deleted again (disable the button).
Even if it's possible (the clipboard contents used to be stored in files, one per unit, at least in some cases and with some versions of AmigaOS, but I don't know if that's still the case) don't use dos.library file change notifications for it. The correct way is using the clibboard.device CBD_CHANGEHOOK.
Just like reading/writing ENV variables with dos.library file I/O functions from/to the files in ENV: and/or ENVARC: and installing file change notifications for them is possible, with the current implementation of ENV variables (which could be changed to something else, unless too much software uses the wrong functions), it never should be done. For accessing ENV variables only the IDOS->(Get|Set|Notify|Delete)Var() functions should be used.
The same happens with Notepad too : just in case with notepad, when you click on Paste and it haven't anything, it says "clipboard contain no data to paste" ... Same happens with Andy's Multiedit : Paste button enabled at start, even if clipboad have no content in. User then hit hit button, it hits, but have no visual return of any kind , and may think it just broken.
IMHO both is wrong. A requester too much, nothing at all too few. Checking clipboard changes, to enable/disable the menu, may be too much overhead. How about always having the paste menu enabled, but if it's used with an empty clipboard, or unusable data like audio, image or video content, call IIntuition->DisplayBeep()?
I read with interest what - among others - Trixie and Joerg wrote above. I wasn't aware of CBD_CHANGEHOOK. It would of course be better to use a feature specifically made for the purpose than a general DOS file notification (even if that one could work; I don't know, but regardless of how the clipboard may be implemented inside, we still have it presented as a directory with an assign CLIPS:, so maybe it would).
Then I'm wondering if the warning in the RKRM isn't from another age, where such an overhead would be a real problem? Provided a hook-like or notification-like mechanism could work, it would certainly be less of an overhead than having a loop check (even with delays) regularly for changes.
Of course, then comes the added task (which I didn't think of) of determining whether the data are relevant (i.e. text).
It would probably be ideal if the CBD_CHANGEHOOK mechanism could be set up for specific data types or something, so the system took care of determining whether to bother the subscribuing program.
@McFly Instead of using ToolTypes, I followed Javier's and Dan's suggestion and implemented WINDOW_UniqueID, which, combined with WINDOW_PopupGadget, TRUE, adds a pop-up gadget next to the iconify gadget. This menu includes "Snapshot," allowing you to position and size the window as desired, save it with a snapshot, and have those settings persist across runs until you select "Unsnapshot" or "Restore" (to defaults) from the same menu. Additionally, I added a "Jump to Screen" (thanks to Trixie), enhancing the apps look and feel. This keeps DumbPad sleek, avoiding ToolTypes and minimizing settings to ensure simplicity without unnecessary complexity.
@joerg Quote:
How about always having the paste menu enabled, but if it's used with an empty clipboard, or unusable data like audio, image or video content, call IIntuition->DisplayBeep()?
Probably this one better of all, but still, for user it will be unclear why paste is enabled at all, if nothing to paste. And this Beep, may looks like something wrong happens :) But yeah, better than nothing probably, at least for now.
Thanks for the development of DumbPad it is already great, fast and I love the tab function. I usually use NotePad a lot to edit .cfg files and here I also have the possibility to search text content.
Will you also teach DumbPad to search for text content?
And yes yes it is great to be able to use native apps that have been developed from scratch
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
News feed
OS4 Feedback forum
OS4Depot Feedback forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
