-
-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Desktop: Add new setting to show note counts for folders and tags #2006
Conversation
I would make it dependent on the collapsed status of folders. The current calculation is a bit confusing when a folder is collapsed. Calculate the sum of descendants + the folder itself, iff folder is collapsed:
But maybe this is just a dumb idea. In any case, I'm very happy that someone is looking into this again. As for the count position: it should be right aligned. But that's just interface stuff. Oh, and I would move the setting to Great job so far. Let's wait for Laurent's input. |
Thanks for the feedback @tessus
Yeah, you're right, but I also find it confusing that the number changes based on display options :/
I'm far from a css expert, but I gave it a try. Not sure how much value is the "notes" word adding, I would just leave the number.
I was just copying what "Show completed to-dos" toggle was doing, I didn't realize they show up in the Settings panel. Apparently if you don't specify a "section", it doesn't (for example, folders.sortOrder.field does that), so I went with that. Thanks. |
BTW, I just changed the folder note count calculation to always include descendants. |
I think we have to look at how other apps are calculating items. The system I described seemed the most logical, but I could be wrong.
No, the
Hmm, I don't see anything at all with the current code. No numbers that is.
|
I couldn't easily find a similar application that has nested folders with counts.
So, the options I see so far are (in no particular order): I find C more intuitive, but I don't have a strong preference. |
Ah, now I know where I have seen the tessus count (brilliant name ;-)) before: Thunderbird counts this way. e.g. for unread mails. But I believe I have seen this in other apps as well. The thing is I do believe it is the most accurate and intuitive way to count. If not, you'd have to go with option G, otherwise one type of info is just not available. e.g. With C you will never know how many notes are in a top folder (or any folder that has subfolders). With B you'll never know how many notes are under a folder. But Laurent still hasn't voiced his opinion. @laurent22 what's your take on this? |
@erdody, I haven't had the opportunity to check the code in details yet but will do so as soon as possible. |
I've just noticed the following issues:
For the count, I think the way it's done now is fine. Another good option would be the Thunderbird way I guess, but it will be trickier to implement. |
I don't understand this sentence. Actually it has exactly to do with how the app looks like. Without the setting the app shows a number next to a folder. Without it, it does not. It changes the appearance of the app. I advised the OP to move it to Appearance, because this setting has to do with the appearance of app. This setting has nothing to do with the note. The note tab has settings that are related to a singular note. e.g. something when you open or edit a note. The count has nothing to do with this. Here are some examples how note counts are used in other UIs (right aligned): There's also the matter how notes should be counted. I think that's the most important part of this PR. e.g. I would find it unusable if they were counted any other way as I described in my first reply. (As mentioned in another reply, any other way would be missing one part of the info.) |
Ok let's go for the Appearance section then. For the note counts, I'm fine with either the number with a background, as in your example, as long as it works with all the themes without having to modify all them (i.e. by using one of the existing colour for the background). Or the Evernote way, with just plain text with faded background ( |
The style of how the numbers are presented (or shown) can be easily chaged at any time. I'm more concerned about how notes are actually counted. The OP and I had a few back and forth arguments in this PR, so what do you think? What's you take on the counting algorithm? |
I've answered above, but let's wait for @erdody's take on all this. |
Ah, I missed the part:
Ok, maybe in the future we can add an option how to count. That would be my favorite choice. In that case people can choose the way how notes are counted. I'm not insisting on this, it's just an idea for the future. |
e.g. anything other than A and G are useless to me. But that's a personal thing. ok, time for bed. ttyl. |
@laurent22 @tessus Thanks for the feedback, I'm glad this is moving forward. Let me try to summarize the pending items:
I just pushed a fix to make it look like Evernote
Fix pushed.
This seems to be working when adding a note, but I could verify that counts are not updated when removing a note. I will take a deeper look sometime this week.
Yes, tags were already doing an outer join (to only show tags with notes), so it was safe (performance wise) to add a field for the counts. I just added a view to clean up multiple places where that query was needed. |
@laurent22 I just pushed a fix for the folder/tag count update on note delete/add. |
@erdody I'm not sure what you did, but I think you merged master into your branch. This is a no-no. |
@tessus I believe @laurent22 was the one that merged master into my branch. See here: I just merged my local branch with his commit because I didn't realize he committed something. By the way, why is syncing with master a "bad idea"? |
I've experienced unforseen things happen. e.g. imagine 2 branches: In branch A, somebody makes a change to file X (X'). In branch B, somebody changes some other files, and pulls changes from master including file X (the original from master). Now after merging branch A and B, I've seen it happen that master had file X and not file X'. Anyway, Laurent will merge this, so I guess I'm off the hook. ;-) |
@tessus I don't see why that should be the case, git should be able to identify the latest change in that scenario. In general, if the code has been pushed to the public (like in this case), I would avoid rewriting history (which is what rebase does). |
@erdody I agree, but I've seen strange things in certain cases. Maybe there was a bug in git or maybe somebody force pushed eiher master or a branch (I can't really recall), but I have seen it happen. Anyway, don't worry about it. All good. It's just me being too cautious. |
The merge commit happened after I fixed a conflict, but normally it should be fine. Thanks for the update @erdody, I'm going to take a look at it as soon as possible. |
@laurent22 I hope it will still be ok to add the Thunderbird count option in the future.... |
ElectronClient/app/gui/SideBar.jsx
Outdated
@@ -431,6 +435,11 @@ class SideBarComponent extends React.Component { | |||
return this.anchorItemRefs[type][id]; | |||
} | |||
|
|||
noteCountElement(baseStyle, count) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
baseStyle
is not used, so can be removed.
ElectronClient/app/gui/SideBar.jsx
Outdated
@@ -431,6 +435,11 @@ class SideBarComponent extends React.Component { | |||
return this.anchorItemRefs[type][id]; | |||
} | |||
|
|||
noteCountElement(baseStyle, count) { | |||
let style = Object.assign({}, this.style().noteCount); | |||
return <div style={style}>({count})</div>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no need for the intermediate style
variable.
@@ -20,7 +20,12 @@ const reduxSharedMiddleware = async function(store, next, action) { | |||
ResourceFetcher.instance().autoAddResources(); | |||
} | |||
|
|||
if (action.type == 'NOTE_DELETE') { | |||
console.info(`reduxSharedMiddleware ${action.type}`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remove the console statement.
Thanks @erdody, that's a solid PR and it's great that you've added tests for all the backend features. I've just left a few comments for minor issues, and once it's fixed we can merge. |
Thanks @laurent22, all comments addressed. |
Great job. Just wanted to ask, if it was on purpose to put the setting in the section Well @erdody, if you're ever bored, you could always implement the Thunderbird count as an option. ;-) Hahaha. |
I don't have a strong opinion about where the setting should so in "General" section it's fine for me. For the Thunderbird count, if I understand correctly the difference is that we don't show the count if a notebook is expanded, is that correct? |
It's easier with an example: Thunderbird count
current count
So the TB count shows the count aggregated when collapsed and the correct number of notes for the folder, if not collapsed. e.g. with the current count you do not know how many notes are in folder A, unles you count them manually.
Same here. It also works in General. I just didn't expect it there, that's all. |
Ok that makes, so yes I'd accept a PR for a Thunderbird count, but no need to make it optional, it would just replace the current one. |
thanks for this feature! |
I was totally thinking this is needed and then it arrived shortly after - thank you guys :) |
First stab at adding the ability to show note counts for Notebooks and Tags.
There's one menu item to toggle the feature.
Thanks.