0.38 Release Candidate 2
28 January 2017 at 21:31 #124134
Dear friends of cherrytree, after issuing the release candidate 0.37.99 I didn’t just polish but implemented one more major feature since after this release I would like to try and port the application from GTK2 to GTK3 thus I will freeze the new features for a while.
It would be very helpful if some of you could test the new features and/or verify that there are no regressions in your normal use of the app.
Remember to BACKUP YOUR DATA before installing this version.
Please do not ask for new features here but just polishing for the release.
The changelog is the following:
1) added the timestamp of creation and latest modification per node and the possibility to filter the searches using these values
2) implemented the possibility to execute the code of code nodes and codeboxes (File–Execute Code); the terminal and the command per node type is configurable in the preferences dialog, tab “Plain Text and Code”
3) the background color of the text formatted monospace is now configurable in the preferences dialog, tab Rich Text
4) implemented the VACUUM command for SQLite database to repack into minimal amount of disk space (File–Save and Vacuum)
5) it is now possible to edit the underlying text with the dialog listing the results of the search opened
6) better support for drag and drop of nodes in large trees with the scrollbars uncovering the hidden parts of the tree when dragging close to the edges
7) implemented the word count in the statusbar, to be enabled in the preferences dialog (tab Miscellaneous, work of cyingfan)
8) implemented the option to hide the tree right side auxiliary icon (currently a padlock for read only nodes and a pin for bookmarked nodes)
9) implemented the option to hide the embedded file name on top of the embedded file icon (tab Rich Text, work of jhermans76)
10) assigned static keyboard shortcut Ctrl+Shift+Right for ‘Node Change Parent’
11) updated bundled pygtkspellcheck from 4.0.1 to 4.0.5
And here are the links:29 January 2017 at 12:03 #124135
Thank you for this amazing software.
I’ve just installed 0.37.99 and probably found minor issue:
if i paste multi-line text and then try to undo editor doesn’t clear text block but it clears it line by line. Ctrl-Z removes last line of pasted block.
I assume it’s not expected behavior.30 January 2017 at 23:54 #124136
Environment: Windows 7
Binary: cheerytree portable
usage: I tried to set option Misc->Enable word count in status bar
Got popup indicating errors in cherrytree.ext.log. Its contents are shown below.
Traceback (most recent call last):
File “config.pyc”, line 2276, in on_checkbutton_word_count_toggled
File “core.pyc”, line 4912, in update_selected_node_statusbar_info
File “core.pyc”, line 4928, in get_word_count
File “wordbreak.pyc”, line 206, in break_units
File “wordbreak.pyc”, line 133, in word_breakables
File “wordbreak.pyc”, line 235, in _preprocess_boundaries
File “wordbreak.pyc”, line 288, in word_break
File “wordbreak.pyc”, line 292, in _word_break
TypeError: ord() expected a character, but string of length 2 found
Hope it helps.
Ravi1 February 2017 at 16:46 #124137
Testing on windows and Ubuntu, great so far. Incidentally, I go back and forth between work (windows) and home (linux), is there a way to define the location of the file that keeps track of the user preferences and last state?4 February 2017 at 01:02 #124139
Thanks for the feedback, I addressed the problem of the word count on windows and will try to fix the paste from clipboard before the upcoming 0.38.0.
the config.cfg is located for linux in
and in windows in
You can find the location with the top menu help–open preferences directory
You cannot currently define a custom location, the only option is to write it in the same directory of the binary cherrytree.exe for windows (or cherrytree in linux)
I’m also considering the possibility in future to let the user export/import the config.cfg8 February 2017 at 00:06 #124155
sorry, I am a little late here. But the last 2 weeks have been very busy for me, filled with several time-critical jobs to do.
I tested (as usual) on my Mint 17.3 box. 2 issues to consider:
#2 (the shorter one): Why not a pre-configuration for x-terminal-emulator instead of wanting the user at first to install xterm or reconfigure CT?
Point A: At now the search dialog leads the user to the wrong believe, that he can search in nodes, which have been created or modified before or after a given date / time, even without a search term. Obviously this does not work. Without a search term the dialog closes silently and that’s it. As long as doing a search by date / time *only* is not supported, the check boxes in front of the date / time settings and the respective buttons to change the date / time should be grayed out.
Point B: It would really be nice, if a search for date / time only would be possible. It would allow e.g. to investigate, which nodes did I create or alter since a given date / time. The search in node names and tags would most likely be useful for such a search.
At now it is possible to do something like that by filling the search term with a dot (.) and check regular expressions. But this is a rather circumstantial workaround; perhaps it helps, if you change the behavior in a way, that without any content for the search expression the search behaves like the regex . (dot)?
In principle the workaround works also for the regular search for content, but if the user does not limit the search to a rather limited tree (selected node and subnotes) the search takes ages and uses for the whole time the complete cpu power (at least on my test system with only one CPU in a virtual environment). So strictly not recommended for searching in content.
Point C: Obviously all nodes, which have not been created or modified after the new version, have no meta data about the date / time. It would be nice to have a way to search for nodes, which do not have a create or modify time. Alternative: Allow the user to set / modify the create / modify date. In a CT database, which has grown over years, all the existing nodes will obviously never get a creation time. With manually set creation dates the user would be able to distinguish between old, very old or not so old nodes.
Example for usage: There are many topics in the database, distributed in their respective nodes. If you find now, that a node has not been altered in – let’s say – the last 2 years, it might mean, that either the content of this node is outdated and needs some work to update the content or the content is not more current at all and the node could possibly get exported to an archive database. At now all the several hundred of nodes all have the same date = not defined; distinguishing between them with the search is impossible.
With some delayed greetings
Cosmo.8 February 2017 at 23:48 #124156
Thanks for testing the version and providing feedback.
About #2, the terminal emulator is just a wrapper with poor command line arguments while I need the capability of xterm arguments to open and run a command. Still it is possible to not use xterm but configure a different one desktop specific where the user must know the correct command line arguments.
About #1, I already applied a change to allow the search for a node with an empty search entry, so it is possible with Ctrl+T to search for nodes filtering only by dates, on the find in nodes contents instead I’m unsure and didn’t change the behaviour for now. About letting the user modify the date of creation I’m unsure, maybe I could do that only for empty field (old document), but what if the user sets up a date and then regrets and would like to change… it’s puzzling
Giuseppe.9 February 2017 at 12:54 #124160
you should disable in the search for content dialogs the check boxes and the buttons for setting time and date at least as long, as no content is filled in the respective field. Or – alternatively and probably better – disable the OK button as long as the content field is empty. At now it can easily lead to user’s confusion, if he activates one of the date options but leaves the content field empty: As soon as he clicks OK the dialog closes silently and the user might not understand, why he does not get a result, although he knows, that at least one node would match with the set date.
Another suggestion in this context: In the sub-dialog for setting date and time there are those 2 little fields for entering the hour and minute values. They appear somehow not self-explaining at the first look. I recommend to put the words “hour” and “minute” below those 2 fields, than the meaning of those fields get evident at the first look.
Regarding the manually editing of the create / modified meta data of the nodes: This is indeed a not so easy topic. I will invest today some time to think about that issue and will report back, which ideas I have found. Please give me some hours for that.
And now something quite different: I am very lucky about the feature to expand nodes at mouse clicks, which you added some versions ago following my request. Another thank you for that; it is a great productivity enhancer for me. But there are 2 cases I found, where this option does not work: First in case you jump to a node with subnodes via bookmark and second, if I reopen CT and the last used node has subnodes; you must know in this context, that I have set to collapse all nodes at startup. In those both cases the subnodes do not get expanded and I have to do this manually. This is a pity. Can you please change this, that also in the 2 described cases the subnodes get automatically expanded? It would be my biggest wish at now.
Regards, I will try to be back in a few hours
Cosmo9 February 2017 at 15:45 #124161
I made a long walk in the fresh air (with my dog) and came back with the following thoughts. Excuse me beforehand, if this is a wall of text. I have tried to find the pros and cons and some (hopefully) useful suggestions.
Allowing the user to fake the meta data is usually a bad thing. The idea of meta data is not to fake their content. They shall allow the user to keep some information, which can easily get captured by a computer on its own.
In case of CT there is a special situation. All CT-users, who have created and maintained their database over several years, do have hundreds of nodes. All those nodes do not have any meta data dates, which makes the new search feature more or less pointless. If I take my database and think about my work with it in the last years, I come to the prediction, that even after several years 90 % of all nodes will be those, which I already have. That means, that especially the search for creation date will be pointless most likely for the rest of my life. And also the modification date will likely only change in about 50 % of all nodes after several years. This means, that in case of CT the general hesitation against faked data will make the new search feature somehow pointless.
Next point: If we coincide, that faked creation date is needed, to give old databases the full power, which new databases will get by the new feature, than it is necessary, that the users decides on his own, which date might be a proper value. It is near to impossible, that an user will remember the exact date, but is likely, that he can tell a halfway matching date, when he created the node. In case of modification date this appears as near to impossible; faking the modification date would be like playing Roulette. So I suggest, that only the creation date can be faked and that the modification date will be set automatically to the same date. This leaves the case open, where an old node (without creation date) has been modified with the new CT version (and now has a modification date). In this case the modification date should get preserved; but also this needs an exception, if the faked creation date is later than the modification date (what would be a user mistake). This would obviously be an impossible situation and the modification date has to be set to the faked creation date.
I suggest further, that in case of faked dates only the date can be set by the user, not the time; nobody will be able to remember the time afterwards. The time should be set in this case to 00:00 (am). Alternatively the time could stay empty, but I can imagine, that with an empty time field there might arise bugs when a search gets performed. Not allowing to set a time has 2 advantages: At first it makes the setting for the faked date simpler. At second the user can even after some years make a qualified guess, if this is a faked or a real date. Although it is not impossible, that the user creates a node exactly at noon, the likelihood is rather low, as every day has 1440 minutes.
Next to the above thoughts I wondered, how this can get implemented. Take the following as a possible idea. The idea is, to use the node properties dialog (F2). The dialog could display both creation and modification date / time, if they exist (similar as LibreOffice document properties show this). If no creation date exists, there could be an empty box to enter the faked creation date. This empty box should not appear (or not be editable), if the creation date does exist; this limits the chance to misuse it. Next to the existing date should be a checkbox, which allows the user to delete the date (in this case both: creation and modification), if he finds, that the faked date was an error. After closing the properties dialog with the OK button the dates get deleted. When the user opens the dialog again, he can enter the new creation date in the said field.
I hope, that this helps you to decide about a proper solution. If you find something wrong or doubtful in my thoughts, please let me know and I will try to improve my ideas.
Cosmo.14 February 2017 at 01:31 #124163
Thanks for your feedback.
I improved the search dialog disabling the OK button when appropriate.
About the Hour/Minutes missing labels I cannot fix that right now because I already freezed the translatable text time ago and I already have most of the translations ready, I’ll improve that in future.
I enforced the option of node auto expansion at mouse click in case of click on bookmark and at the startup for the last visited node.
I agree with the need to have a way to be able to manually set a creation date for old nodes, forcing hours and minutes to 0. I’m still unsure about the interface though, and don’t want to further delay the issue of 0.38.0 that already has several improvements over the latest 0.37.6, so I will get back to that after 0.38.0.
You must be logged in to reply to this topic.