CintaNotes Forum

Oct 1, 2014 - Version 2.8 Beta 2

In this version:

(in green - changes since 2.8 Beta 1)

Features:

• Forward and backward filter navigation on the search bar
  
• Filter history on right click on back and forward buttons, and "Clear History" command
  
• Option Tags/Autodeleted by default

Enhancements:

• Tag sidebar: tags font is now configurable with "app.mainframe.tagsidebar.font" settings file option
  
• Improved notebook loading and switching performance
  
• Improved section switching performance
  
• Improved notes list scrolling performance
  
• Improved tag renaming, splitting and merging performance
  
• Improved import performance
  
• Don't reset filter to keep just edited note visible by default (will affect new installations only)

Fixes:

• Editor: fixed outstanding stateful text formatting issues
  
• Tag sidebar: scrolling should stop when mouse button is released
  
• Editor: "Insert Link" command is disabled when selected text is wrapped
  
• Editor: vertical tabs are treated as paragraph separators
  
• Editor: inconsistent behavior of some text formatting shortcuts
  
• Fix possible crash on import
  
• Notebook file name in app title turns to lower case
  
• Tab scrolling sometimes can freeze
  
• Simplenote sync: catch potentially unhandled exception

Download:
Installable: CintaNotes_2_8_Beta2_Setup.exe
Portable: CintaNotes_2_8_Beta2.zip

WARNING! BETA SOFTWARE! USE AT YOUR OWN RISK AND ALWAYS BACKUP YOUR DATA!

Hi Alex,

thank you for this new update!

CintaNotes Developer wrote:* Editor: vertical tabs are treated as paragraph separators

I confirm it is fixed.

CintaNotes Developer wrote:* Editor: inconsistent behavior of some text formatting shortcuts

I confirm it is fixed.

Btw. i noticed a little inconsistency while testing. When some text is selected and Ctrl+Shift+<format char> gets pressed it will behave same as Ctrl+<format char>. It applies to the selected text only. Probably no real problem in practice. Not sure what to do best. One solution could be to ignore the paragraph shortcut when text is selected. Another solution would be to ignore the selected text and apply the setting on the paragraph. I think the later might be best.

I will report more on the latest improvements later.

Thomas

Hi Alex,

i did some testing regarding the implementation of the "history" feature. My understanding of the implementation is a lot better now - i think . Though i was not able to find some bugs the user experience is not so good to me. This is mainly due the presentation of the history. The popup window has separate items for backward and forward. Each represents a point in history and the change which is involved by moving backward or forward respectively. I had expected the same items for both buttons, displaying the full state which the item represents. To me this is clearer than showing the difference of the prev-/next-item. Especially when i look for an item that is not related to my current search. History is such a powerful and handy feature, yet it confuses me a lot. Because of that, when i search for a history item, i now press Alt+Arrow until i find what i was looking for.

Other remarks:

• shortcuts work great and improve user experience a lot
• displaying the search text and tag names is very handy
• The presentation of the hint should only show "Right-click to see history". The hint should not include shortcuts. It's not its job. It also makes the hint less clear.
• Ctrl+F appears to reset the search history under some circumstances. That makes history meaningless to me, since i use Ctrl+F all the time.
• When i type something that matches a tag selection, the tag combo gets shown. When i press Alt+Arrow the history changes, but the combo is still shown. Is this by intention? To me it is rather confusing.

Thomas

Hi Thomas,
thanks for checking out the beta!

Thomas Lohrum wrote:Btw. i noticed a little inconsistency while testing. When some text is selected and Ctrl+Shift+<format char> gets pressed it will behave same as Ctrl+<format char>. It applies to the selected text only. Probably no real problem in practice. Not sure what to do best. One solution could be to ignore the paragraph shortcut when text is selected. Another solution would be to ignore the selected text and apply the setting on the paragraph. I think the later might be best.

I agree that the shortcuts should be consistent and that Ctrl+Shift+<letter> should always operate on the paragraph. However, RichEdit doesn't make it easy and most probably your current text selection will be lost after that. Would that be acceptable do you think?

Thomas Lohrum wrote:the user experience is not so good to me. This is mainly due the presentation of the history. The popup window has separate items for backward and forward. Each represents a point in history and the change which is involved by moving backward or forward respectively. I had expected the same items for both buttons, displaying the full state which the item represents.

I agree that it might have a better usability. But there are two problems to solve here:
1) How to represent all filters in each history item without it becoming too long and bulky. Imagine, for example, it being represented like this:
"Tags: Projects/Todo/Tomorrow Projects/Todo/NextWeek -Archive/Done; Search: blog javascript ; Sort by: Last modified first".
2) How to make things that change between two history states stand out. Compare with the history item above:
"Tags: Projects/Todo/Tomorrow Projects/Todo/NextWeek -Archive/Done; Search: blogs javascript ; Sort by: Last modified last".

When we come up with a way to solve these two issues, the history can be improved. However it can happen only after 2.8 is released, probably in 2.8.1.

The presentation of the hint should only show "Right-click to see history". The hint should not include shortcuts. It's not its job. It also makes the hint less clear.

I tend to agree about the bulky shortcut, but what about the action description ("Back: Select !/todo!')? The hint now allows to see what will happen when you press the button.

Ctrl+F appears to reset the search history under some circumstances. That makes history meaningless to me, since i use Ctrl+F all the time.

What do you mean exactly under "reset history". The back menu becomes empty? The forward menu becomes empty? Or both?
IIRC, you have the "Ctrl+F resets filter" setting on, I think it can be of importance here - you're resetting the text filter when you press Ctrl+F. Here we're coming back to the issue of storing empty filter states in the history. Mind that the tag filter can very well be not empty here.

[*]When i type something that matches a tag selection, the tag combo gets shown. When i press Alt+Arrow the history changes, but the combo is still shown. Is this by intention? To me it is rather confusing.[/list]

Why would you navigate history when the tag combo is shown? But this is clearly a bug, I'll fix it in the 2.8 Final. Thanks!

CintaNotes Developer wrote:I agree that the shortcuts should be consistent and that Ctrl+Shift+<letter> should always operate on the paragraph. However, RichEdit doesn't make it easy and most probably your current text selection will be lost after that. Would that be acceptable do you think?

I don't expect the issue to be a problem in the field. I stumbled over it when i was testing the Ctrl+Shift-fixes. A clean solution might be to store and restore the selection in case it actually gets dropped. If the effort is that high, it is probably the best though, to not bother and leave it as it is. One can still argue that the selection has higher priority than the paragraph shortcut. Change it (fix it), if it is of little effort only.

Thomas

CintaNotes Developer wrote:

Thomas Lohrum wrote:The presentation of the hint should only show "Right-click to see history". The hint should not include shortcuts. It's not its job. It also makes the hint less clear.

I tend to agree about the bulky shortcut, but what about the action description ("Back: Select !/todo!')? The hint now allows to see what will happen when you press the button.

I suggest to remove it. The hint "Right-click to see history" is all it takes. From there it just takes a right click to check what will happen next (in case of interest). I think this is cleaner.

Thomas

CintaNotes Developer wrote:

Thomas Lohrum wrote:Ctrl+F appears to reset the search history under some circumstances. That makes history meaningless to me, since i use Ctrl+F all the time.

What do you mean exactly under "reset history". The back menu becomes empty? The forward menu becomes empty? Or both?
IIRC, you have the "Ctrl+F resets filter" setting on, I think it can be of importance here - you're resetting the text filter when you press Ctrl+F. Here we're coming back to the issue of storing empty filter states in the history. Mind that the tag filter can very well be not empty here.

I don't remember exactly. It happened only once while i was testing. I will observe the issue though.

Btw. what actually fires the history to be stored? Ctrl+F does, also a backspace will do as well as Enter, right?

Thomas

CintaNotes Developer wrote:I agree that it might have a better usability. But there are two problems to solve here:

I understand your design decisions. Each user has different requirements also. To me the implementation is very technical. The design requires to store empty searches (reset search), to be able to show the delta. But this is extra information i don't care. I don't want to step back to "reset search". I can reset any time using Ctrl+F if i like to. I prefer a list of search results (absolute information) rather than a list of deltas (relative information).

CintaNotes Developer wrote:1) How to represent all filters in each history item without it becoming too long and bulky. Imagine, for example, it being represented like this:
"Tags: Projects/Todo/Tomorrow Projects/Todo/NextWeek -Archive/Done; Search: blog javascript ; Sort by: Last modified first".

I use a 30" screen, no problem to me My practice is though very different. Usually it just takes 1-3 words of searching to find the desired notes. In rare cases i actually use a tag filter. I never change sorting. Others might use search differently though.

A history of mine could be:

search for 'javascript blogs'
search for 'CintaNotes beta'
search for 'Ubuntu shortcuts'

This also brings up the request to have a shortcut to the history. Especially this makes sense if there would be only one history, rather than two for backward/forward.

CintaNotes Developer wrote:2) How to make things that change between two history states stand out. Compare with the history item above:
"Tags: Projects/Todo/Tomorrow Projects/Todo/NextWeek -Archive/Done; Search: blogs javascript ; Sort by: Last modified last".

Your example is fine as it is! I can see the difference if i look at it. Maybe the information can be shortened to gain a better oversight.

Your suggestion:
"Tags: Projects/Todo/Tomorrow Projects/Todo/NextWeek -Archive/Done; Search: blog javascript ; Sort by: Last modified first".

Alternatives:
"blog javascript" in (Projects/Todo/Tomorrow Projects/Todo/NextWeek -Archive/Done)
blog javascript (Projects/Todo/Tomorrow Projects/Todo/NextWeek -Archive/Done)

Maybe it is important for the sort order to take part in the history, but do we actually need to show it? In that case we would have the same entry twice, because it can not be distinguished (so what?).

Sort Alternatives:
"blog javascript" in (Projects/Todo/Tomorrow Projects/Todo/NextWeek -Archive/Done) [Last modified first]
blog javascript (Projects/Todo/Tomorrow Projects/Todo/NextWeek -Archive/Done) [Last modified last]

Thomas

[EDIT 03.10.2014 00:26]

Sort Alternatives:
"blog javascript" in (Projects/Todo/Tomorrow Projects/Todo/NextWeek -Archive/Done) [LAST MODIFIED]
blog javascript (Projects/Todo/Tomorrow Projects/Todo/NextWeek -Archive/Done) [last modified]

Hi Alex,

Ctrl+Alt+S is no longer working. It simply does not save the note. Instead it should save the note while keeping the last modified date.

Thomas

Thomas Lohrum wrote:I don't expect the issue to be a problem in the field. I stumbled over it when i was testing the Ctrl+Shift-fixes. A clean solution might be to store and restore the selection in case it actually gets dropped. If the effort is that high, it is probably the best though, to not bother and leave it as it is. One can still argue that the selection has higher priority than the paragraph shortcut. Change it (fix it), if it is of little effort only.

I doubt very much that the issue will be easy to fix, so let's leave it as it is for now - at least, till someone else complains.

Thomas Lohrum wrote:I suggest to remove it. The hint "Right-click to see history" is all it takes. From there it just takes a right click to check what will happen next (in case of interest). I think this is cleaner.

Probably you're right, it's too bulky now. The shortcut key can be seen in the View menu anyway. I'll limit it to "Go Back \n Right click to see history".

Thomas Lohrum wrote:I don't remember exactly. It happened only once while i was testing. I will observe the issue though.

Ok

Thomas Lohrum wrote:Btw. what actually fires the history to be stored? Ctrl+F does, also a backspace will do as well as Enter, right?

It's a bit more complicated. The decision to store or not to store is based only on the diff between two states, not on user actions. Basically, the new state is stored when it is different enough from the previous one. There's also some code in place that prevents intermediate typing to be stored (it checks that the search string is not growing any more).

Thomas Lohrum wrote:This also brings up the request to have a shortcut to the history. Especially this makes sense if there would be only one history, rather than two for backward/forward.

What do you mean under "shortcut into history" exactly?

Thomas Lohrum wrote:Your example is fine as it is! I can see the difference if i look at it. Maybe the information can be shortened to gain a better oversight.

The only solution I've come up with is to use icons instead of words "Tags", "Search", "Sorting". This should look great, for example the sorting can be shortened to just two icons. But it will require some serious effort, to implement an owner-drawn menu and such. Not something for 2.8 at any rate.

What I suggest is this plan:
1) In 2.8 I'll do only the following changes:
- Display bulky absolute state descriptions instead of deltas in the history menu
- Merge two menus into one, highlight the current state with bold, "back" items placed below the bold one, "forward" items placed above the bold one.

2) In 2.8.1: implement owner-drawn menu to replace bulky descriptions with nice icons. also it will become possible to highlight changed parts with reddish background or something like that.

Thomas Lohrum wrote:Alternatives:
"blog javascript" in (Projects/Todo/Tomorrow Projects/Todo/NextWeek -Archive/Done)
blog javascript (Projects/Todo/Tomorrow Projects/Todo/NextWeek -Archive/Done)

Nice, but mind also that if any extra sections are added to the selection, they should be included here as well. Also when ALL sections are included, this should be shortened to "All sections".

Thomas Lohrum wrote:Maybe it is important for the sort order to take part in the history, but do we actually need to show it? In that case we would have the same entry twice, because it can not be distinguished (so what?).

Maybe we should just consider sorting not part of the history? Would that make better sense?

Thomas Lohrum wrote:Sort Alternatives:

Thanks for the ideas. I like the variant with "Last modified first" more, because it is immediately understandable to anyone.

CintaNotes Developer wrote:

Thomas Lohrum wrote:This also brings up the request to have a shortcut to the history. Especially this makes sense if there would be only one history, rather than two for backward/forward.

What do you mean under "shortcut into history" exactly?

Right now to use the history one must use the mouse and right click. I suggest to add a keyboard shortcut as an alternative, since CN support for keyboard use is first class.

Thomas

Thomas Lohrum wrote:Right now to use the history one must use the mouse and right click. I suggest to add a keyboard shortcut as an alternative, since CN support for keyboard use is first class.

Do you mean a shortcut to display the history menu, or to activate the current-N history item?

CintaNotes Developer wrote:What I suggest is this plan:
1) In 2.8 I'll do only the following changes:
- Display bulky absolute state descriptions instead of deltas in the history menu
- Merge two menus into one, highlight the current state with bold, "back" items placed below the bold one, "forward" items placed above the bold one.

This sounds very promising!

Thomas

CintaNotes Developer wrote:

Thomas Lohrum wrote:Right now to use the history one must use the mouse and right click. I suggest to add a keyboard shortcut as an alternative, since CN support for keyboard use is first class.

Do you mean a shortcut to display the history menu, or to activate the current-N history item?

I mean a shortcut to display the history menu. This should be sufficient. Maybe we can decide later, whether it makes sense to focus on the current state (the bold entry) inside the menu?

Thomas

CintaNotes Developer wrote:

Thomas Lohrum wrote:Maybe it is important for the sort order to take part in the history, but do we actually need to show it? In that case we would have the same entry twice, because it can not be distinguished (so what?).

Maybe we should just consider sorting not part of the history? Would that make better sense?

Sorting affects presentation. It is not a filter mechanism. So yes, maybe the state should not be saved at all.

Thomas

Thomas Lohrum wrote:Ctrl+Alt+S is no longer working. It simply does not save the note. Instead it should save the note while keeping the last modified date.

Alex, did you catch this one here?

It is easy to reproduce: open a note, edit it, save it using Ctrl+Alt+S and click the Cancel-button. The changes should have been saved, but they are not.

Thomas Lohrum wrote:I mean a shortcut to display the history menu. This should be sufficient. Maybe we can decide later, whether it makes sense to focus on the current state (the bold entry) inside the menu?

Ok, I get it. By the way, I don't know of a way to programmatically make Windows focus a particular item inside of a popup menu (other than emulating keypresses, which is ugly as hell).