[Ann] CintaNotes 1.6 Beta 2

[CintaNotes Developer]

Hi,
well here's the new freshly baked beta version! Please check it out.

Mar 20, 2012 - Version 1.6 Beta 2

What's new compared to 1.5.7:
Features:

• Multiple notebooks support: CintaNotes now has the "File/Open" and "File/Save As..." commands, and also has the recently opened files list to easily switch between different DB files. The name of the currently opened DB file is displayed in the main window title (unless it is "cintanotes.db").
  
• Ctrl+Enter shortcut to paste note text into currently active application.
  
• Exporting notes to HTML format.
  
• Unified and consistent search behavior: Search behavior is now unified and consistent. "Exact search" mode has been removed. Instead there's an option to search inside words. Now you can always use the logical operators: space as AND and '|' as OR
  If you need to search for an exact quote, put it in doublequotes, like this: "to be or not to be".
  
• "Help/License" dialog to manage product licensing: The dialog includes ability to automatically fill licensing data from clipboard.
  
• "Cut" command for notes, and custom clipboard format to transfer notes from one notebook to another while keeping text formatting.

Enhancements:

• Tag sidebar can now be resized with the mouse.
  
• New option: "Options/Clipping/After Clipping/Assign currently active tags"
  When this option is on, newly clipped notes are automatically assigned tags which are currently selected on the Tag Sidebar.
  
• Note editor: Alt+C now works as shortcut for "Cancel".
  
• Ctrl+U shortcut for displaying untagged notes.
  
• Last used export format is now remembered in settings.

Fixes:

• Full-text search was not working for East-Asian languages.
  
• Searching for "-a" lead to a "Malformed MATCH expression" error.
  
• Note Editor: applying formatting cleared existing formatting.
  
• Copy/pasting note in the notes list doesn't lose text formatting anymore.
  
• Removed redundant formatting tags in exported XML file.
  
• Note editor lower pane height changed on Ctrl+S.

What's new compared to 1.6 Beta 1:

• No admin privileges required to register
  
• FTS search no longer treats {"word"} as {"word*"}
  
• Negation was treated incorrectly when searching by text and title
  
• Fixed wrong search highlights for queries in doublequotes
  
• Fixed crash (AV) with Ctrl+Enter pasting
  
• Added Russian translation

Download:
Installable: CintaNotes_1_6_Beta2_Setup.exe
Portable: CintaNotes_1_6_Beta2.zip

License Key:
Copy this whole quote to clipboard and open the Help/License dialog.
(Pressing Ctrl+Del in the License dialog deletes the key that is already present).

===CINTANOTES LICENSE===
[License removed - beta testing of this version is over - A.J.]

Translations:
Help with translating the new version will be much appreciated (the new strings are already on Transifex).

[Thomas Lohrum]

Hi Alex,

i confirm the following fixes work correctly:
• copy/paste underlined text is fixed
• reopen new note is fixed
• Ctrl+Enter clipping to CN window is fixed (remark #1: the user must focus the editor before clipping - clipping to the title is rather meaningless) (remark #2: when running into this AV Ctrl+S luckily prevented dataloss, because i had saved my note before the crash ) (remark #3: the doc's should read "into the last active application" rather than "into the active application", because when clipping, it's CN that's active).

Other
• Ctrl+Shift+Enter clipping including title not yet implemented
• resizing tag sidebar with mouse works like a charm; windows constraints are implemented; can't fool CN by making the window to small
• the "Note saved" flicker is still present
• Ctrl+U how could i ever live without
• Last Opened Windows re-open when CN starts, e.g. after reboot, that's an undocumented feature in v1.6, right?
• the "About" dialog should show the beta information, e.g. "Beta 2" to more easily verify the installed product
• After installing beta 2 i had to re-register from Beta 1. I understand the reason, but think you should clearly state so. At a first glance i was surprised that beta 2 was no longer a registered product. Since more betas are to come users should be aware of the need. Unless you decide, that registering one time only is enough
• FR: when you create a bullet list, each "ENTER" will create a new bullet. Fine. But when pressing "ENTER" twice without entering text this should be treated as an indication to end further bulleting. Instead of creating empty bullets, remove the last unwanted bullet. This comes more handy than double Ctrl+L to stop bulleting.

one more...
• I noticed a strange behaviour with the "undo". Testcase: select a block, cut and paste again. Now first alt+backspace will hightlight the block, second alt+backspace does nothing (which is strange), third alt+backspace deletes the block as expected.

Thomas

[SibRich]

Hi Alex,

I just upgraded to Beta 2 and as with Thomas below I was surprised that there wasn't some sort of warning during the installation that my license does not support the new version. Not so important right now, but needs to be implemented soon to be sure someone's doesn't lose their licensed version when they update ..

Actually I just tried to register with the first beta license and was surprised it worked. Is it supposed to? And if it works, why did my updated version not stay registered?

Otherwise, so far I have not seen any issues. The beta works smooth and fast, a pleasure to work with.

Richard

[CintaNotes Developer]

Thomas, thanks for such a thorough review!

the doc's should read "into the last active application" rather than "into the active application", because when clipping, it's CN that's active

You probably meant "pasting" instead of clipping here? Anyway you are right, "last active application" is less confusing.

Ctrl+Shift+Enter clipping including title not yet implemented

Yes, it wasn't.

the "Note saved" flicker is still present

Ok, will investigate this further.

Last Opened Windows re-open when CN starts, e.g. after reboot, that's an undocumented feature in v1.6, right?

What exactly do you mean here? Actually reopening editor windows which haven't been explicitly closed is supported since 1.3.

the "About" dialog should show the beta information, e.g. "Beta 2" to more easily verify the installed product

You can rely on the date displayed in the About dialog to determine which build it is. But you are right, specifying beta info explicitly would be more user-friendly. Will do.

After installing beta 2 i had to re-register from Beta 1.

Actually this is just a side effect of changing the place of storing the "license.key" file. In Beta 1 it was stored near the cintanotes.exe, which lead to impossibility to register if CN was in Program Files and runnin not as admin. In Beta 2, the license key is always stored in the %APPDATA% folder. Further updates won't require re-entering license info.

FR: when you create a bullet list, each "ENTER" will create a new bullet. Fine. But when pressing "ENTER" twice without entering text this should be treated as an indication to end further bulleting. Instead of creating empty bullets, remove the last unwanted bullet. This comes more handy than double Ctrl+L to stop bulleting.

Actually I consider this to be a bug and have posted it as such here:
http://roadmap.cintanotes.com/topic/102745-/
Thanks!

I noticed a strange behaviour with the "undo". Testcase: select a block, cut and paste again. Now first alt+backspace will hightlight the block, second alt+backspace does nothing (which is strange), third alt+backspace deletes the block as expected.

I confirm, added to the issue tracker. Will investigate the problem.

[CintaNotes Developer]

Hi Richard,

I just upgraded to Beta 2 and as with Thomas below I was surprised that there wasn't some sort of warning during the installation that my license does not support the new version. Not so important right now, but needs to be implemented soon to be sure someone's doesn't lose their licensed version when they update ..

As I said above, this is a one-time issue

Actually I just tried to register with the first beta license and was surprised it worked. Is it supposed to? And if it works, why did my updated version not stay registered?

Yes, why not? It shouldn't work only if the key was issued more than a year before the release of the CN version you're trying to register.
It didn't stay registered because the location of the license file changed. If you'd manually move the license.key file to the %APPDATA%/CintaNotes folder, it would have stayed registered

Otherwise, so far I have not seen any issues. The beta works smooth and fast, a pleasure to work with.

Great to hear that!

[Thomas Lohrum]

Thomas, thanks for such a thorough review!

Alex, you're welcome. It is a pleasure to me to help on CN's development. As said before, imo CN is a phantastic tool. It is perfect for managing notes easily. And it's fast and lightweight. It runs like a charm. Before CN i was using plain text files and PSPad (great editor with project-managemant). Since i use CN PSPad is needed in only rare cases. It also changed my kind of working. Ideas i want to memorize just get out of my way now, by simply creating a note in a second. Especially i use untagged notes for things that i need to work on. Now Ctrl+U made that even better for i can access them even more easily. Also your support on CN is outstanding!!! You really take care on requests and bugs. That is why CN is evolving fast and neat.

Last Opened Windows re-open when CN starts, e.g. after reboot, that's an undocumented feature in v1.6, right?

What exactly do you mean here? Actually reopening editor windows which haven't been explicitly closed is supported since 1.3.

Well, i guess i have never noticed before

the "About" dialog should show the beta information, e.g. "Beta 2" to more easily verify the installed product

You can rely on the date displayed in the About dialog to determine which build it is. But you are right, specifying beta info explicitly would be more user-friendly. Will do.

Please add the beta number to it, e.g. "Beta 2". Thank you.

In Beta 2, the license key is always stored in the %APPDATA% folder. Further updates won't require re-entering license info.

Fine Thank's for clarifying.

FR: when you create a bullet list(...)

Actually I consider this to be a bug and have posted it as such here:
http://roadmap.cintanotes.com/topic/102745-/

OK, just voted for it.

I noticed a strange behaviour with the "undo". (...)

I confirm, added to the issue tracker. Will investigate the problem.

OK

Thomas

[Thomas Lohrum]

Alex,

i have just noticed, that when i create new note, for the creation date "01.01.2000" is shown. This surely is not correct.

Thomas

[CintaNotes Developer]

Thomas, thanks again for the appreciation. I'm really glad that CN could become such a useful tool for you.

Please add the beta number to it, e.g. "Beta 2". Thank you.

It will already be Beta 3, but other than that, will be done

i have just noticed, that when i create new note, for the creation date "01.01.2000" is shown. This surely is not correct.

I confirm, will be fixed in Beta 3. Thanks.

[Thomas Lohrum]

Alex,

i did more tests on searching.

Explanation
Search in text and title
SIW = Search inside words

Results

• [cintanotes] 36 of 879 SIW ON/OFF - as expected
• [-cintanotes] 843 of 879 SIW ON/OFF - as expected
• [notes] 45 of 879 SIW ON/OFF - as expected
• [-notes] 834 of 879 SIW ON/OFF - as expected
• [public] 18 of 879 SIW OFF - as expected
• [-public] 861 of 879 SIW OFF - as expected
• [public] 19 of 879 SIW ON - as expected
• [-public] 860 of 879 SIW ON - as expected
• [1.6] 5 of 879 SIW ON - as expected
• [-1.6] 874 of 879 SIW ON - as expected
• ["-1.6"] 1 of 879 SIW ON - as expected
• ["delphi blog"] 0 of 879 SIW OFF - as expected
• ["delphi blog"] 2 of 879 SIW ON - as expected
• ["delphi blogs"] 2 of 879 SIW ON/OFF - as expected

Unexpected

• F3 highlights in the note text, when the note editor get's opened after a search. However this is valid for the note's text only. Highlighting is currently not supported for the title. When the only hit is in the note's title this can be irritating.
• Search for [1.6] with SIW OFF finds "1.6", "1" and "6". The extra hits for "1" and "6" is because the FTS is used. It's not really hurting, but unexpected. However F3 fails to highlight them in the notes editor. Probably it is only highlighting "1.6".
• Search for [public-roadmap] searches for notes containing "public", but not containing "roadmap". I think the exclusion-operator should have a space before it, e.g. [public -roadmap]. The term [public-roadmap] should be treated same as ["public-roadmap"]. Imo that makes the search more intuitive. It is also interesting to observe that right now [public-] will find more results as compared [public-r], which accentuates my statement.

Remarks

• There is no indication whether fts is used (viewtopic.php?f=6&t=1248#p4708). I still think this could help.
• While running my tests i needed to check the state of SIW, but that was not easy, because it is visible only, wenn opening the options window with the ALT+Arrow-Down-Key. Showing an indication might be interesting.
• Search-phrase needs a leading double quote only. CN returns the same results regardless of the presence of a closing quote. I guess because of the live-search-feature. Otherwise CN would have to wait for searching until the user inputs the closing double quote. Google works different. The first double quote is ignored and google does a regular search. As soon as the closing quote is entered, google changes the search as a "phrase-search".

Conclusion
The revised search-engine is a huge step forward compared to 1.5. CN brings google's search capabilities to the desktop. This is not about comparing the two, but googles search operators are smart. It's phantastic to have CN to be that strong.

Thomas

[Thomas Lohrum]

Alex,

i suggest to slightly change the syntax for excluding a word. Example: [public-roadmap] will find all notes containing "public", but not containing "roadmap". It came as a surprise to me. I suggest that the exclusion operator should have a space before it. A space between the operator and the exclusion word is an option, but not a must. Example: [public -roadmap] or [public - roadmap]. Imo this is more natural. It does not force me to use phrase search, when i am searching for all notes containing exactly "public-roadmap". Imagine the exclusion-operator would be a natural word "NOT", then spaces surrounding the operator would be mandatory, right?! [public NOT roadmap] you could not write [publicNOTroadmap]. Imo having a space before the "-" operator is more natural to use. The only exception is the beginning of a search term, in which case, the space is not required, e.g. [-roadmap].

With the OR operator "|" the problem is less critical, because the pipe symbol is usually not used inside notes, e.g. [public|roadmap]. Imo it doesn't hurt to also require a space before it, e.g. [public |roadmap] or [public | roadmap]. It's actually more readable. To stay consistent both operators should have a space before it.

Thomas

PS: Right now i have plans to do more testing on searching, but want to wait for beta 3 first.

[CintaNotes Developer]

Hi Thomas,
huge thanks for such a thorough testing. Hopefully thanks to you the changed search logic in CN 1.6 won't
present any nasty surprises to CN users;)

F3 highlights in the note text, when the note editor get's opened after a search. However this is valid for the note's text only. Highlighting is currently not supported for the title. When the only hit is in the note's title this can be irritating.

Yes, this hasn't been implemented yet. And actually I haven't thought about it at all, since title is usually short and it should present no
difficulty to locate something in it, especially when the highlight in the notes list has already shown where it is.
Also it is unclear what to do in case there are hits in both body and title.
So I've added it to the roadmap, let's see if it gets 10+ upvotes:
http://roadmap.cintanotes.com/topic/103 ... in-editor/

Search for [1.6] with SIW OFF finds "1.6", "1" and "6". The extra hits for "1" and "6" is because the FTS is used. It's not really hurting, but unexpected. However F3 fails to highlight them in the notes editor. Probably it is only highlighting "1.6".

In Beta3, FTS won't be used for such queries and thus the highlighting should be ok.

Search for [public-roadmap] searches for notes containing "public", but not containing "roadmap". I think the exclusion-operator should have a space before it, e.g. [public -roadmap].

Good catch. I completely agree that a space in front of the hyphen should be mandatory in order for it to be treated as NOT.
The problem we had is that using plain LIKE operator it is not possible to do a "word-boundary-only" search (at least not without doing something very ugly: "WHERE x LIKE ' word%' OR x LIKE '.word%' OR x LIKE '!word%' OR.. ). But we've already overcome this via implementing a custom regexp-function and registering it with SQLite. So now we'll actually have not two but three search engines:

• FTS (used when SIW=off and query doesn't contain delimiter characters)
• custom regex-based (used when SIW=off and query contains delimiter characters)
• LIKE (used in all other cases, i.e. when SIW=on)

There is no indication whether fts is used (viewtopic.php?f=6&t=1248#p4708). I still think this could help.

Now we have not two but three modes. I think burdening the users with all these implementation details isn't the right thing to do. We should strive to make it absolutely transparent. True, there can be some variability in search performance, but every time CN will pick the fastest possible approach and the results will be correct and consistent. If the users absolutely needs to search for "D$ | *82*11", knowing whether FTS was used won't help much Normal people just don't care about this stuff. They just want the search to be as fast and as correct as possible.

While running my tests i needed to check the state of SIW, but that was not easy, because it is visible only, wenn opening the options window with the ALT+Arrow-Down-Key. Showing an indication might be interesting.

Sometime ago I suggested something like this, but quite unexpectedly it was downvoted into minus: http://roadmap.cintanotes.com/topic/351 ... lass-icon/
But I agree this would be useful.

Search-phrase needs a leading double quote only. CN returns the same results regardless of the presence of a closing quote. I guess because of the live-search-feature. Otherwise CN would have to wait for searching until the user inputs the closing double quote. Google works different. The first double quote is ignored and google does a regular search. As soon as the closing quote is entered, google changes the search as a "phrase-search".

I would argue that CN's approach is better and more convenient. Usually if I type a doublequote, I do it for a reason.

i suggest to slightly change the syntax for excluding a word. Example: [public-roadmap] will find all notes containing "public", but not containing "roadmap". It came as a surprise to me. I suggest that the exclusion operator should have a space before it.

Is already in implementation and will be done in Beta 3.

With the OR operator "|" the problem is less critical, because the pipe symbol is usually not used inside notes, e.g. [public|roadmap]. Imo it doesn't hurt to also require a space before it, e.g. [public |roadmap] or [public | roadmap]. It's actually more readable. To stay consistent both operators should have a space before it.

Sorry but I don't agree. Not having to type an extra space in queries like "one|two" is a big deal for me. NOT is an unary operator and OR is a binary operator, so I don't think the symmetry here is obligatory. But of course you are welcome to persuade me otherwise

[Thomas Lohrum]

Hi Thomas,
huge thanks for such a thorough testing. Hopefully thanks to you the changed search logic in CN 1.6 won't
present any nasty surprises to CN users;)

So do i.

(...)Also it is unclear what to do in case there are hits in both body and title. So I've added it to the roadmap, let's see if it gets 10+ upvotes:
http://roadmap.cintanotes.com/topic/103 ... in-editor/

I voted for it. Also see my comments there.

In Beta3, FTS won't be used for such queries (EDIT: e.g. [1.6]) and thus the highlighting should be ok.

Ok, i'll retest with beta3.

Search for [public-roadmap] searches for notes containing "public", but not containing "roadmap". I think the exclusion-operator should have a space before it, e.g. [public -roadmap].

Good catch. I completely agree that a space in front of the hyphen should be mandatory in order for it to be treated as NOT.

The problem we had is that using plain LIKE operator it is not possible to do a "word-boundary-only" search (at least not without doing something very ugly: "WHERE x LIKE ' word%' OR x LIKE '.word%' OR x LIKE '!word%' OR.. ).

SQL has its limitations.

But we've already overcome this via implementing a custom regexp-function and registering it with SQLite. So now we'll actually have not two but three search engines:

• FTS (used when SIW=off and query doesn't contain delimiter characters)
• custom regex-based (used when SIW=off and query contains delimiter characters)
• LIKE (used in all other cases, i.e. when SIW=on)

Wow, that really should handle all requests

There is no indication whether fts is used (viewtopic.php?f=6&t=1248#p4708). I still think this could help.

Now we have not two but three modes. I think burdening the users with all these implementation details isn't the right thing to do. (...) Normal people just don't care about this stuff. They just want the search to be as fast and as correct as possible.

Agreed. The complexity and the power of 1.6's search capabilities is a huge step forward. As long as the user finds what he's looking for, all will be fine.

While running my tests i needed to check the state of SIW, but that was not easy, because it is visible only, wenn opening the options window with the ALT+Arrow-Down-Key. Showing an indication might be interesting.

Sometime ago I suggested something like this, but quite unexpectedly it was downvoted into minus: http://roadmap.cintanotes.com/topic/351 ... lass-icon/
But I agree this would be useful.

I guess people didn't understand the need for this. I think the idea is great! I voted for it now. At least i would love to be able to recognize the state of SIW on/off.

Search-phrase needs a leading double quote only. CN returns the same results regardless of the presence of a closing quote. I guess because of the live-search-feature. Otherwise CN would have to wait for searching until the user inputs the closing double quote. Google works different. The first double quote is ignored and google does a regular search. As soon as the closing quote is entered, google changes the search as a "phrase-search".

I would argue that CN's approach is better and more convenient. Usually if I type a doublequote, I do it for a reason.

I do it for reason too. What might be the better approach can be discussed. I don't want to. My focus is on the fact, that with the current implementation CN's phrases actually are not used as a phrase. Rather than surrounding the text, a phrase is treated as such by having a leading double quote. A trailing quote is just plain noise

i suggest to slightly change the syntax for excluding a word. Example: [public-roadmap] will find all notes containing "public", but not containing "roadmap". It came as a surprise to me. I suggest that the exclusion operator should have a space before it.

Is already in implementation and will be done in Beta 3.

fantastic.

Not having to type an extra space in queries like "one|two" is a big deal for me. NOT is an unary operator and OR is a binary operator, so I don't think the symmetry here is obligatory. But of course you are welcome to persuade me otherwise

No. You already convinced me

Looking forward to beta 3

Thomas

[sadun]

very timely the html export! thanks i couldnt find a way to print with with the tags..

[Thomas Lohrum]

Hi Sadun,

very timely the html export! thanks i couldnt find a way to print with with the tags..

What do you mean "a way to print with tags"? The exported HTML document does contain the tags, whereas CN itself does not have any means of printing yet.

Thomas

[Sadun]

Thats exactly what I meant I couldnt find a way until I found this beta version.. An option to print the notes directly as they appear in the cintanotes window might also come in handy for some.

[Thomas Lohrum]

Hi Sadun,

Thats exactly what I meant I couldnt find a way until I found this beta version.. An option to print the notes directly as they appear in the cintanotes window might also come in handy for some.

You can vote for it here http://roadmap.cintanotes.com/topic/8843-printing-note-from-the-editor-window/ and here http://roadmap.cintanotes.com/topic/3198-note-printing/

Thomas

[Thomas Lohrum]

Search-phrase needs a leading double quote only. CN returns the same results regardless of the presence of a closing quote. I guess because of the live-search-feature. Otherwise CN would have to wait for searching until the user inputs the closing double quote. Google works different. The first double quote is ignored and google does a regular search. As soon as the closing quote is entered, google changes the search as a "phrase-search".

I would argue that CN's approach is better and more convenient. Usually if I type a doublequote, I do it for a reason.

I do it for reason too. What might be the better approach can be discussed. I don't want to. My focus is on the fact, that with the current implementation CN's phrases actually are not used as a phrase. Rather than surrounding the text, a phrase is treated as such by having a leading double quote. A trailing quote is just plain noise

Maybe i can express myself better now. E.g. search term [word1_of_phrase word2_of_phrase word3]. This will find the needed note, but maybe too many notes. So i edit the term inserting a double quote to the beginning at pos 1. Zero notes will be found, because CN treats the term as a complete phrase already. Now rearrange the term to [word3 word1_of_phrase word2_of_phrase]. When you enter a double quote before "word1_of_phrase" everything is fine. Imo this is inconsistent. I still think googles approach is more consistent here. Ignore a single double quote and change to phrase search as soon as the closing double quote gets entered.

[CintaNotes Developer]

Maybe i can express myself better now. E.g. search term [word1_of_phrase word2_of_phrase word3]. This will find the needed note, but maybe too many notes. So i edit the term inserting a double quote to the beginning at pos 1. Zero notes will be found, because CN treats the term as a complete phrase already. Now rearrange the term to [word3 word1_of_phrase word2_of_phrase]. When you enter a double quote before "word1_of_phrase" everything is fine. Imo this is inconsistent. I still think googles approach is more consistent here. Ignore a single double quote and change to phrase search as soon as the closing double quote gets entered.

Google is really imprecise, e.g. it completely ignores doublequotes if there's an "OR" inside: try googling for ["life OR death"].
I agree that maybe ignoring the first doublequote is more consistent with regard to swapping search terms, however in case of general lazy typer such as I am, not having to type the second doublequote is an advantage. So I'd say it is a draw here )