Modern alternatives to keynote-nf

[Dialga]

Since this project is dead, here are two modern alternatives:

Trilium Notes Trilium Notes is a hierarchical note taking application with focus on building large personal knowledge bases. https://github.com/zadam/trilium

Cherrytree A hierarchical note taking application, featuring rich text and syntax highlighting, storing data in a single xml or sqlite file. http://www.giuspen.com/cherrytree/

[dpradov]

Hello @DrownedStarfish Could you attach a copy of that file, in which you only leave at least the node that you show on the screen (you can remove all the other nodes)? I would need you to make the changes using your previous version of KeyNote. Of course, using native format, not encrypted one

If it happens to you with all the files created/modified with the older version, you can create a new .knt file using 1.7.9.8 version with some test nodes, but do check first that it suffer of the same problem in 1.8.0 Beta 1 version.

[DrownedStarfish]

@dpradov ,

I'm not sure I understand. You want me to send you a native .knt file consisting of at least one node made with 1.7.9.8, and which displays incorrectly (as shown) in the new beta.

Is that correct?

Thanks, DrownedStarfish

[dpradov]

Is that correct?

Yes, that is :)

[DrownedStarfish]

Is that correct?

Yes, that is :)

BetaTestNode.zip

Your system wouldn't let me upload a .knt, so I zipped it first.

Thanks. DrownedStarfish

[dpradov]

Hi @DrownedStarfish I can open and see your file with the new KNT version perfectly. I have opened it in Windows 10 and also in Windows 11 (W11 Pro 22H2). It is a perfectly normal .knt file, and as such it opens correctly.

Please, rename your keynote.ini file (general option's file) and open the file again with 1.8.0, to use default options. Tell me if there is any difference.

[Stefanoko]

For the record: Meanwhile, I have run 1.8.0 on seven machines, all of them Win 10 and Win 11, no problems at all. Everything shows up properly formatted, including internal cross-links and search results.

Even when I edit my files on the "broken" notebook with an outdated Win7 RichEdit, my additions still display nicely on new Windows versions. No matter where I edit my files, the text remains intact, same for the formatting — I just don't get to see it with an outdated RichEdit.

Keynote interface colors and font sizes of tree and tabs are preserved on all systems, including Win7.

Bottom line: I am very happy with the latest Beta. Two thumbs up.

[DrownedStarfish]

I am mystified!

DS.

[DrownedStarfish]

No change.

My old notes open fine in 1.7.9 b8, still have the same display problem in the new beta (1.8.0 b1)

Thanks. DS

[thdoan]

I just tried KeyNote_1.8.0 Beta1.zip and noticed one thing different: every time I load KeyNote NF I get this warning even though the extension is already registered to the application:

Is this because I'm using a beta exe file, or is it a bug?

To suppress the error I had to disable this option, though in previous version I didn't have to do this:

(If I remember correctly, I did get the warning the first time running v1.7.9 Beta 8, but after starting as admin to set the file association once, I never got the warning again.)

[dpradov]

Is this because I'm using a beta exe file, or is it a bug?

To suppress the error I had to disable this option, though in previous version I didn't have to do this:

It's true, it's a bug. I always had that option disabled and didn't test it. I'll correct it. Thanks

[thdoan]

I noticed a bug today: I have a multi-monitor setup -- monitor A has 100% text scaling and monitor B (laptop) has 125% scaling. When you drag KeyNote NF from monitor A to monitor B, the font gets changed. Not sure if this makes a difference, but all of the tabs in my notes file are set to plain text format. Notes font = Consolas 12pt; Tree font = Tahoma 8pt.

[dpradov]

Hello. I've made a few other changes, including getting the app to scale correctly based on OS settings. Soon I will upload a new binary.

[mpradovelasco]

Thanks!

[dpradov]

Good evening everyone (from Spain) Attached the binaries of a new version (1.8.0 Beta 2). Try it and tell me.

A summary of the changes in history.txt. A more detailed information, in "Changes in 1.8.0 Beta2.txt"

All the best Daniel

BetaReleases_README.txt history.txt Changes in 1.8.0 Beta1.txt Changes in 1.8.0 Beta2.txt Comments on KNT file formats.txt

KeyNote_1.8.0 Beta2.zip

[Stefanoko]

Wow, I mean wow — thanks a million for Beta 2.

I love the improved handling of Zoom, all of it. You cannot imagine how often I have wished for zoom to apply to all notes by default. Which is what I want most of the time. Restricting it to the active node only via Ctrl-click is a great idea, should someone really want that. And the new default Zoom option is priceless, too.

Same for the BG-color, which can now be applied to all nodes by Shift-confirming the new choice. And to all note trees via the property dialog. It makes things sooo much easier for someone like me, who tends to go crazy on the colors.

The properties' dialog with only 2 instead of 3 tabs makes much more sense now. The checkbox "inherit BG-color from active node" is always greyed out, but that's probably because of my settings, I have not really used it much so far.

I highly appreciate your work and that you continue development. Many thanks!

[dpradov]

Hello I'm glad you find the improvements useful.

You said 3 weeks ago:

The small font size is still hard to read. It applies to the whole sidebar, including Templates, Macros, Favorites etc. All other font sizes can be cranked up and customized, but the sidebar remains tiny. It makes Keynote hard to use on today's HD monitors.

Search results are not easy do decipher. Don't know what to make of it:

I have incorporated the zoom adjustments for what you have been indicating, although for me it was also becoming a necessity to constantly zoom in... ;)

Note that Zoom now applies to Scratch panel as well, and also there is a new option to increase the size of search results.

I wonder if the TB-buttons could be sized up, too, along with the fonts in the resource panel, for HD-monitors?

I have two monitors at home, with a resolution of 1920 x 1080. Since they are not small (22 inches) I do not need to modify the default Windows settings. But the laptop at work has the same resolution with only 15 inches, so there I do need to modify the OS scaling, changing it to 125% or 150%.

I suppose that you know that option, but just in case, it is the following. With it you should be able to work comfortably in KeyNote or any other application with your HD-monitors. This new version of KNT correctly adapts to scaling settings on Windows:

The checkbox "inherit BG-color from active node" is always greyed out, but that's probably because of my settings

It is not a problem of your settings. I have decided to show that checkbox on that form so that we are aware of the implications of that option on the application's behavior regarding BG-color. But it is a property that is modified from the general options. You can change it from:

Best regards, Daniel

[Stefanoko]

Thank you Daniel

for clarifying the function of the "inherit BG color" checkbox. Upon re-reading the Beta-changes, I see what you mean. It just serves as a reminder that this setting exists. It does not reflect the actual state — checked or unchecked — of this setting in Options > Rich Text Editor. I am perfectly fine with that.

Good idea that zooming also applies to the Scratch Panel. I had missed this additional feature.

Here is the thing, though: There is still a huge difference in relative font size between the scratch panel and my custom tab, tree and editor font size. When I zoom large enough to get a readable Scratch panel, I will at the same time blow up my other fonts way out of proportion.

Ideally, all side panels (except Search) would share an additional custom setting for font size and BG-color. Or simply follow the setting of, say, the tree. This would make for a "framed" look, with darker colors left and right (in my case).

Reasons I hesitate to use the native OS-scaling of Windows: 1) It will render many dialogs and windows unreadable, which often cannot contain the increased font size within their layout. Important settings move out of sight, with no scrollbars available to get to them.

2) I work portable on different machines. Sometimes I lack the rights to make changes to the Windows environment. In general, I try to avoid changing anything on their systems to avoid complaints, should I forget to reset it back to whatever it was before.

It is not just Keynote, all apps suffer from today's hi-res monitor/ Windows scaling issue. With the problem becoming ever more pertinent, many apps have added custom font options. Keynote too, except for the resource panel and toolbar, which — admittedly — is not that terribly important. But it were nice to have a more consistent look with side panel colors and better readability.

Thanks a ton for your efforts! Will read up on your recommendations for the file format later this day.

[DrownedStarfish]

No change in my problem!

[dpradov]

No change in my problem!

I'm sorry, but it's normal, since none of the changes I've incorporated adds anything aimed at solving it. I'm still not clear what may be happening in your case. If it were affecting to other people, it could give me other clues. But, surely, it will end up solved

[dpradov]

... function of the "inherit BG color" checkbox. Upon re-reading the Beta-changes, I see what you mean. It just serves as a reminder that this setting exists. It does not reflect the actual state — checked or unchecked — of this setting in Options > Rich Text Editor. I am perfectly fine with that.

No, it did have to reflect current value (although read-only), and it was doing before. Making a last minute clean up on the code before the commit that incorporated that change I deleted one needed sentence, sureley, and now it always comes out unchecked. I will correct it, of course. But since it is not something serious, I will include it in the next beta, with more changes, unless you detect more things and then I will replace this beta as soon as possible.

[Stefanoko]

It probably won't help, but a while ago, I tried a multitude of different RichEdit DLLs, in my attempt to address my own formatting issues under an old Win7.

My issues were related to cross-links and search results only, the regular RTF text in the editor displayed correctly. Except for one time, when it looked very similar to the screenshot provided by DrownedStarfish.

Unfortunately, I do not remember the exact circumstances, under which it happened. I had downloaded different RichEdits from the web, some of them incorporated via keynote.ini, others via replacing them in Windows itself, then restarting my machine.

The only thing I learned, RichEdit seems to interact with other DLLs and/or other Windows components. Simply replacing RichEdit did not solve my formatting issues.

[dpradov]

Hello @DrownedStarfish

Could you do some tests? Even though the initial RTF content of each node is being interpreted as plain text, the editor should still work, and I'd be interested to know to what extent the application can interact with it.

Could you tell me if it is possible for you to edit the file you gave me (BetaTestNode.knt)?

• Add some line of text
• Put a word in bold
• Insert an internal hyperlink between two points of the same no (CTR+F6, Shift+F6)
• Drag a plain text (.txt) file into the tree and import it as a new note
• Drag a rich text file (.rtf) and import it as a new note as well. You can create the file with WordPad or if you want, exporting a node from the other version of KNT.

And finally try to save it (Save As). Tell me if any of these points works for you, and what failures it gives you (if any). Once saved, try to open it to see if there is any difference. If you manage to save it, then send me that modified file.

It would also help me if you repeated the previous test but starting from the 'BetaTestNode.knt' file marked from the previous version as 'Plain Text only'

Thanks

[dpradov]

Hello, I have prepared another version (1.8.0 Beta 3) , because I founded an error in previous versions that could be problematic. In the file "Changes in 1.8.0 Beta3.txt" I explain the reason. => It is important that we use this version instead of Beta1 or Beta2.

• Fixed: (Important) Text files imported as a new note note could be saved plain, not RTF

I have taken advantage of the need to generate this new version, to include a few other modifications. One of them will be very useful, at least for me:

• New: pressing [Ctrl] + [Hide Tree Panel] will temporarily preserve editor width, reducing the application window width

More info in the .txt files

Best regards Daniel

Changes in 1.8.0 Beta3.txt history.txt KeyNote_1.8.0 Beta3.zip

[Stefanoko]

will temporarily preserve editor width

It were amazing if we could have something similar without the distracting background of whatever lies behind the app window. A kind of ZEN-mode or distraction-free mode. Writing and reading large chunks of text is so much easier, when the lines do not stick to the borders, but "float" in the middle of the page, like in a Word processor or PDF file or a real book made of paper.

Personally, I were fine with hiding the tree and resource panels myself, and switching to "alternative text margins", customizable in keynote.ini for left and right: textmargin=360,220

The unit could be in pixels or % of total screen width. It would make long text better readable.

[DrownedStarfish]

Hello @DrownedStarfish

Could you do some tests? Even though the initial RTF content of each node is being interpreted as plain text, the editor should still work, and I'd be interested to know to what extent the application can interact with it.

Could you tell me if it is possible for you to edit the file you gave me (BetaTestNode.knt)?

• Add some line of text
• Put a word in bold
• Insert an internal hyperlink between two points of the same no (CTR+F6, Shift+F6)
• Drag a plain text (.txt) file into the tree and import it as a new note
• Drag a rich text file (.rtf) and import it as a new note as well. You can create the file with WordPad or if you want, exporting a node from the other version of KNT.

And finally try to save it (Save As). Tell me if any of these points works for you, and what failures it gives you (if any). Once saved, try to open it to see if there is any difference. If you manage to save it, then send me that modified file.

It would also help me if you repeated the previous test but starting from the 'BetaTestNode.knt' file marked from the previous version as 'Plain Text only'

Thanks

@dpradov ,

You want me to do all of this using the beta?

[dpradov]

Hello @DrownedStarfish https://github.com/DrownedStarfish Don't do it yet, wait a bit. In a few hours I will be able to generate a new build in debug mode, with logging enabled

El lun., 21 ago. 2023 3:34, DrownedStarfish @.***> escribió:

Hello @DrownedStarfish https://github.com/DrownedStarfish

Could you do some tests? Even though the initial RTF content of each node is being interpreted as plain text, the editor should still work, and I'd be interested to know to what extent the application can interact with it.

Could you tell me if it is possible for you to edit the file you gave me (BetaTestNode.knt)?

• Add some line of text
• Put a word in bold
• Insert an internal hyperlink between two points of the same no (CTR+F6, Shift+F6)
• Drag a plain text (.txt) file into the tree and import it as a new note
• Drag a rich text file (.rtf) and import it as a new note as well. You can create the file with WordPad or if you want, exporting a node from the other version of KNT.

And finally try to save it (Save As). Tell me if any of these points works for you, and what failures it gives you (if any). Once saved, try to open it to see if there is any difference. If you manage to save it, then send me that modified file.

It would also help me if you repeated the previous test but starting from the 'BetaTestNode.knt' file marked from the previous version as 'Plain Text only'

Thanks

@dpradov https://github.com/dpradov ,

You want me to do all of this using the beta?

— Reply to this email directly, view it on GitHub https://github.com/dpradov/keynote-nf/issues/602#issuecomment-1685488841, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADKJPUMGKAGBYR4IVMH5YQ3XWK3ITANCNFSM4M3DA5BA . You are receiving this because you were mentioned.Message ID: @.***>

[DrownedStarfish]

Hello @DrownedStarfish https://github.com/DrownedStarfish Don't do it yet, wait a bit. In a few hours I will be able to generate a new build in debug mode, with logging enabled23 3:34, DrownedStarfish @.***>

OK.

[dpradov]

Hello @Stefanoko What I wanted to solve with that functionality is different, I think. You see, the following has been happening to me on many occasions:

I need to be working on a single monitor, with an application (a video conferencing program, for example) occupying as much of the screen as possible. I have Keynote open to be able to take my notes, located on the right of the screen, with the tree panel hidden, only the editor visible, with a reduced width. At any time I need to consult some data from another node or from another note, and with the Tree Panel visible the editor is barely visible, so I have to widen the window a bit (I don't maximize it because I would completely stop seeing the other window, which I need to follow). Once I have returned to the node from where I am making the annotations, I need to reduce the width of the window again, since it is not enough to hide the tree again.

With this new functionality everything is much easier.

[dpradov]

Hi again @DrownedStarfish

I have generated a new compilation of KeyNote 1.8.0 Beta 3, as Debug, with the log enabled. I have added new log entries in several points of the code, trying to obtain some information that coud help me to resolve the problem you have.

In the zip attached there are several files:

keynote.exe sampleTXT.txt sampleRTF.rtf BetaTestNode.knt BetaTestNode_MODIF.knt keynote_ok.log

The .log is the one created by this excutable while I followed the steps I indicated before. BetaTestNode.knt is the file you gave me several days ago. I have used it as start point. BetaTestNode_MODIF.knt is the file after the changes I made.

In detail:

• Copy the keynote.exe to your KNT folder

• Rename keynote.ini to _keynote.ini ( to use default settings )

• Create a direct access in Windows to that .exe

• Edit the properties of the direct access. In target field you need to add the "-debug4" argument: ".....\keynote.exe" -debug4

  "-debug" open KeyNote with log enabled. By default it will register up to what I have defined as to level 1 of detail. It is possible to use -debug1 ... -debug3, etc. But for this test you must use -debug4

• Open KeyNote using the direct access. By default it will open a blank new file. Close it, without saving.

• Open the file "BetaTestNode.knt"

• Add one line of text, with something in bold format.

• Mark a position (Ctr+F6) and create an internal link to it in other point of the node: Shift+F6

• Drag and drop the file "sampleTXT.txt" into the tree and import it as a new note

• Select the first note (tree note)

• Drag and drop the file "sampleRTF.rtf" into the tree and import it as a new note

• Save the file as "BetaTestNode_MODIF.knt"

• Close KeyNote

• Open KeyNote again. It will open "BetaTestNode_MODIF.knt". Then close it again.

Please, send me the "keynote.log" file that will appear in the folder where you put the .exe file.

Hopefully, comparing my log with yours I will find something that give me clues of what it is happening

Thanks

KeyNote_1.8.0 Beta 3_Debug -Test.zip

[dpradov]

@Stefanoko, would you do the same test with your old Win7 laptop? Thanks

[Stefanoko]

@Stefanoko, would you do the same test with your old Win7 laptop?

Here you go: Debug.zip

On a sidenote: The original file BetaTestNode.knt uploaded by DrownedStarfish (containing 3 lines of text) displays nicely on my Win7.

However, here is something I find worth pointing out: Like I said, I had a similar occurence to what DrownedStarfish reported, while I was experiencing with various RichEdit versions that I injected into my Windows system.

Upon taking a closer look, I noticed the mention of the exact same version that also pops up on the screenshot that DrownedStarfish provided. The text on my screenshot was pasted from this website: https://forum.ultimatehackingkeyboard.com/t/runtime-macros-so-so-handy/19/21 When I now copy and paste it — I am back at my original RichEdit version 4.1 — the text displays nicely and I cannot reproduce the error:

[DrownedStarfish]

• Copy the keynote.exe to your KNT folder
• Rename keynote.ini to _keynote.ini ( to use default settings )
• Create a direct access in Windows to that .exe
• Edit the properties of the direct access. In target field you need to add the "-debug4" argument: ".....\keynote.exe" -debug4 "-debug" open KeyNote with log enabled. By default it will register up to what I have defined as to level 1 of detail. It is possible to use -debug1 ... -debug3, etc. But for this test you must use -debug4
• Open KeyNote using the direct access. By default it will open a blank new file. Close it, without saving.
• Open the file "BetaTestNode.knt"
• Add one line of text, with something in bold format.
• Mark a position (Ctr+F6) and create an internal link to it in other point of the node: Shift+F6
• Drag and drop the file "sampleTXT.txt" into the tree and import it as a new note
• Select the first note (tree note)
• Drag and drop the file "sampleRTF.rtf" into the tree and import it as a new note
• Save the file as "BetaTestNode_MODIF.knt"
• Close KeyNote
• Open KeyNote again. It will open "BetaTestNode_MODIF.knt". Then close it again.

It did not open a blank file. It opened something starting with "This is a sample note file". I closed the open file, then opened BetaTestNode.knt.

I did not have SampleTXT.txt, but SimpleTXT.txt. Same with Simple RTF.rtf.

I seem to have made a mistake in saving the new BetaTestNode_MODIF.knt, so I had to do it again. I hope it's all right. If not, guess I'll just do it again.

But, even so:

keynote.log

[dpradov]

Hello @DrownedStarfish The log file has been very useful. Clearly the difference that it must be giving you problems with this version of KeyNote NF is that your system codepage is 65001 (UTF-8), not ANSI, as I would expect.

I did tests loading and saving files with ANSI and UTF8, but never tested in a system with a codepage defaulted to UTF8.

I must investigate the implications, but now I can test with that codepage and see what is happening. From version 1.8.0 I'm using a version of Delphi that has a very different management of strings (compared with the one I used, Delphi 2006). Since Delphi 2009, the compiler has complete support for the Unicode character set. So, probably, it must be something wrong in the code changes I needed to do when migrated to this new version, that no cover your configuration (a lot of changes were necessary, because the type 'string', that had been always AnsiString now were UnicodeString, based on UTF16, so 2 bytes for each character, instead of 1, among other differences)

... KNT needs to 'tell' the control RichEdit if the data to load is RTF or plain text, and when it compares the first 6 characters of the node stream with "{\rtf1", in your case it is returning False, probably because the string loaded in your case has an initial header (BOM, Byte Order Mark, 3 bytes in UTF8), not present when default codepage is ANSI. I must study it.

[dpradov]

Hello @Stefanoko Regarding your problem in W7, and according to the log, the commands required to insert the hyperlink have been executed correctly and even then they have been interpreted as plain text. Assuming that it is not an error that is being produced, I have focused on the methods that do the insertion and I think I have found the explanation:

In version 1.7.7 of KeyNote NF, I made several changes to 'Make KeyNote NF Unicode compliant' (Issue #139) (20/09/2009), and included a function to insert/append RTF fragments that could include unicode characters, in the RichEdit control. I didn't understand then why, but I needed to convert the string from WideString (UTF16) to UTF8, because it was not working with the 1200 codepage. According to the documentation for the EM_SETTEXTEX message, which hasn't changed, it should have worked: <<lParam - Pointer to the null-terminated text to insert. This text is an ANSI string, unless the code page is 1200 (Unicode). If lParam starts with a valid RTF ASCII sequence for example, "{\rtf" or "{urtf" the text is read in using the RTF reader.>>

I have looked through my notes and I can confirm that at that time I had Windows 7... I installed W8 on December of 2012. That explains everything. I guess there would be some sort of bug with that control on W7.

When I made the changes for this new version I tested again and tried what seems the most reasonable, not to do any conversion to UTF8 when the string to pass is already in Unicode (in codepage 1200). In older Delphi compiler the string was saved in WideString type and now in UnicodeString type (a new string type, default for string). Both stores as unicode string of WideChar (16-bit) characters, althought UnicodeString is much better in terms of performance and flexibility.

If I were to keep doing the conversion to UTF8, my understanding is that it would work on both W7 and later versions of Windows. Although it must be taken into account that W7 is an old version of Windows, not updated, without security patches (it seemst that even Extended Security Update (ESU) is ended for that version)

I wouldn't want to do unnecessary conversions that could penalize performance. In any case, I'll do a little research, because I think I've read somewhere about how it can be useful (precisely for performance purposes) to pass contents in UTF8 to the RichEdit control. If the RichEdit control actually ends up converting to UTF8, then there would be no problem passing it in that format. And on the other hand, I think that due to the current use of that function (and the EM_SETTEXTEX message) in the application, that conversion should probably hardly have any impact. I can do some measurements and check it.

Actually:

...

Older versions:

...

[dpradov]

I see now that about the same date (2009) there was identified that problem:

https://stackoverflow.com/questions/1782409/unicode-rtf-text-in-richedit

"It seems that, despite what MSDN almost suggests, the "RTF" parser will only work with 8-bit encodings. So what I ended up doing was using UTF-8, which is an 8 bit encoding but still can represent the full range of Unicode characters."

Newer versions of RichEdit, however, do understand correctly UTF-16 encoding

[dpradov]

Of course, I can always convert to UTF8 only if the version of the RichEdit control is old, eg <= 4 It is simple and will allow those of you who still have an old version of the control, for example on W7, to continue working with new versions of KeyNote NF.

[Stefanoko]

Thanks a million, Daniel, for checking into this with your expertise.

I see now that about the same date (2009) there was identified that problem: https://stackoverflow.com/questions/1782409/unicode-rtf-text-in-richedit

Most of it is way over my head. I completely trust your judgment in this matter, how much extra work it would entail for you, and whether or not it makes sense to address the problem, given that W7 ist bound to disappear.

Of course, I can always convert to UTF8 only if the version of the RichEdit control is old, eg <= 4 It is simple and will allow those of you who still have an old version of the control, for example on W7, to continue working with new versions of KeyNote NF.

Sounds good to me. If I read you correctly, this would NOT penalize the performance for the majority of users with newer Windows and RichEdit versions.

Apart from internal knt-links, would it also solve the formatting issue of my search results?

[Stefanoko]

I have Keynote open to be able to take my notes, located on the right of the screen, with the tree panel hidden, only the editor visible, with a reduced width.

Thanks for explaining your usage scenario. Makes sense to me now. And the new Ctrl-click fits the purpose perfectly. I see your point.

Maybe I can convince you nevertheless, to keep customizable text margins in the back of your mind. It makes large chunks of text easier to read, when padding them with white space left and right. Especially in proofreading or creative writing, wider text margins help to focus.

An ini-option would work fine for me, no need to spend time building this option into the interface.

[dpradov]

Apart from internal knt-links, would it also solve the formatting issue of my search results?

Yes, and also other things like inserting templates, for example Don't worry, it won't affect other installations.

Maybe I can convince you nevertheless, to keep customizable text margins in the back of your mind. It makes large chunks of text easier to read, when padding them with white space left and right. Especially in proofreading or creative writing, wider text margins help to focus.

I will consider it

[Stefanoko]

Thank you. Looking forward to future updates. You put the excitement back into using Keynote NF.

Not that I ever wavered, Keynote has always been an essential ingredient in my daily workflow. But it is so much more fun to use now, with your improvements in place.

[cfgardez]

@dpradov Thank you for your contribution to the further development of keynote-nf! I got acquainted with the program 15 years ago. In the years that followed, I tried dozens (very many) of other outlining programs. At the end of this circle, based on the news of your return, I'm back to using keynote-nf again. The main thing I want to ask you is to implement .png support (instead of .bmp). Sorry if this question has already been discussed.

[mpradovelasco]

Hello, I have prepared another version (1.8.0 Beta 3) , because I founded an error in previous versions that could be problematic. In the file "Changes in 1.8.0 Beta3.txt" I explain the reason. => It is important that we use this version instead of Beta1 or Beta2.

* Fixed: (Important) Text files imported as a new note note could be saved plain, not RTF

I have taken advantage of the need to generate this new version, to include a few other modifications. One of them will be very useful, at least for me:

* New: pressing [Ctrl] + [Hide Tree Panel]  will temporarily preserve editor width, reducing the application window width

More info in the .txt files

Best regards Daniel

Changes in 1.8.0 Beta3.txt history.txt KeyNote_1.8.0 Beta3.zip

Thanks to the new beta!. Indeed very useful the new function [Ctrl] + [Hide Tree Panel] to hide the tree without change the width of text!

[dpradov]

Hello, I have another version (1.8.0 Beta 4) , with several fixes. Among them is the correction of the problems reported by @Stefanoko (with older version of RichEdit, in W7) and by @DrownedStarfish (on systems with local codepage set to UTF8). Please, could you confirm that the problems are efectively gone?

It also includes some improvements.

As always, in history.txt you have a list of the changes, and in "Changes in 1.8.0 Beta4.txt" more detail about them.

If you don't find any major bugs, I would like to offer this version as Release, instead of the one currently listed as the latest (1.7.9 Beta 8). I think this version is much better than that one. At least, it would be more correct to use the "keynote_1.7.9.Beta9_Test.2.zip" version than 1.7.9.Beta 8 (as I indicated in a note to that release)

Therefore, I would appreciate it if you would inform me of any problems you may encounter.

Best regards Daniel

history.txt Changes in 1.8.0 Beta4.txt KeyNote_1.8.0 Beta4.zip

[mpradovelasco]

Thank you a lot for the new version!!

[Stefanoko]

Thanks. Many issues resolved. Calling up the default web browser works flawless again. Same for multi-line tabbing and most importantly, RTF inserts get correctly formatted on my Win7 / RichEdit 4.

Search results remain somewhat sketchy. Visually, the results list formats nicely now, it looks as good as on newer Windows versions. When it comes to content, however, it finds/ highlights lots of text that does not contain my search term at all.

Before going into lengthy details, I figure it's easier to just provide an example file, so you can check up on it yourself. I exported this knt-file from a larger file with many notes. The lower nodes were written years ago with old keynote versions. The upper nodes (titled beta and versions) were edited with the latest Betas.

I also included my keynote.ini, because I also experience weird things going on in the tree, that don't allow me to select tree branches after running a search. Even though filtering is OFF. Maybe it has to do with my ini-settings?

Beta4_test.zip

[dpradov]

Hello @Stefanako:

When it comes to content, however, it finds/ highlights lots of text that does not contain my search term at all.

Is it exclusive to operation in Win7 / RichEdit 4, or does it also happen to you in more recent versions? Could you tell me an example of a search term for the file you gave me? How many results did you expect to obtain?

it's easier to just provide an example file, so you can check up on it yourself.

Of course. Totally agree. Thank you very much for taking it into account. It will help me locate the problems you point out.

I also included my keynote.ini, because I also experience weird things going on in the tree, that don't allow me to select tree branches after running a search. Even though filtering is OFF. Maybe it has to do with my ini-settings?

Again, please, it would help me to know if that problems are specific to your old configuration (Win7 with RichEd 4) or general in knt 1.8.0 And yes, it would not be strange for you to use a configuration option that I never used and so what you point out does not happen to me. You do very well in passing me your configuration file, so my tests will be much closer to yours.

Thanks again, I'll tell you what I see.

[dpradov]

I just opened the .zip and I see that you have put screenshots with examples ;) Thanks

[Stefanoko]

does it also happen to you in more recent versions?

That was my first thought as well. Especially the visual distortions that seemed like a problem with screen-updating on my machine. But I won't be able to test it before Wednesday when I am back home and have access to newer Win versions, other than my current Win7.

I did try it with various knt-files, different content, but that made no difference. It also happened on pure text.

Luckily, it never happens when searching step by step via the regular Find and FindNext commands. This still works correctly and only highlights the search term in all files. So no rush, take your time.

[dpradov]

I have been testing the file that you have given me, with your .ini file, and I have not had the slightest problem (W10 + RichEdit 7.5). All behavior is normal.

Highlighted results do not match the search term

Please note that the search does not automatically highlight the terms in the text. It only highlights the first word found in each match (in which case several could have been highlighted, for example with 'All the words' or ' Any of the words'), and it does so only as we select results from the list obtained. The text you highlight should have been selected previously, at the time of executing the search, or later, if you have been trying to move through the nodes, but without selecting any result from the list, is it possible?

Is coherent with the results offered by old version 1.7.9 Beta 9:

Strange visual cover up tree and make it un-clickable

Doesn't seem like it has anything to do with the search. Didn't this happen to you with previous versions, for example 1.7.9 Beta ..

On second start-up, after having run a search, I get to see jumbled text like this. It disappears again after click around in the tree.

It seems like a refresh problem in the editor. ¿?

Currently, once needed text is recollected from the beginning, to facilitate searches, when you look for a search term the app is not asking each of the nodes (with the help of RichEdit control) anymore. Only if one node is modified it will get it searchable text again (much compact information than RTF, and still valid to position correctly the cursor once a found is matched). So, "Find All" (and "Find Next", also) is now much lighter (and fast), because it looks inside strings in memory and not relies in continous calls (messages) to several RichEdit controls, that needed to be loaded previously with the RTF text of eache node. So, it doesn't have much sense that behaviour.

In new version only at the final of Find All operation, all the match results are written to an specific RTF editor (one unique instance), used now for this, instead of old list results. But it should not affect to other edit controls ¿?

The process of recolletion data to optimize the searches can last several seconds, but only it is done when it detects user inactivity (ver little is needed). As soon as it detects activity again, it stop and resume later. Try to open your file and wait just a few seconds before making any "Find All" operation. If it is instantaneous this indicates that the process finished before, if not, then it will be conclude it at this point before giving the results.

Is there any difference if the searches are done this way (just knowing the text recollection is done yet)?

And a last test, please, search for an inexistent word. The application will do the same, but as no match is find, no results will be created, and no RTF table will be created as a list of results. I say this thinking that the problem came after the creation of the RTF table the results, that it coult it be expensive (...) for that version of RichEdit, and it is going a bit groggy...

[dpradov]

Just one thing I have seem in your .ini configuration that I would not recommend: You have marked the option Automatically save changes "when you switch to another application". This implies that whenever KeyNote loses the focus, ALL save process is done, including the creating of all backup files, as configured. That can be very CPU / hard disk "expensive", specially for big files. And it could penalize your experience with KNT.

I recommend to use the option "Every X minutes", together with the option "Backup at regular intervals" (you know you will have copies you are assured that it will not be overwritten: last 4 for weeks, once for each month, ..). You will have a copy with the situation just before the first modfication at the day, too. It is also useful the option "Backup original file when saving changes" (although with the option "when you switch to another application" it will imply that the older of that ciclying backups will be too much recent..., because it will be overriding continuosly)

And of course you can press Save button anytime you feel that "if the power goes out and I lose all the changes not saved, I die..."

Not recommended (normally):

Perfect: