Description: Cherrytree is a hierarchical note taking application, featuring rich text and syntax highlighting, storing data in a single xml or sqlite file.
Download CherrytreePortable_0.33.1_Development_Test_5 [19.8MB download / 97.2MB installed]
Officially released with Cherrytree 0.33.4 on 2014-05-16
Development Test 5 (2014-05-16):
- Update to Cherrytree 0.33.1
Development Test 5 (2014-01-08):
- Update to Cherrytree 0.32.0
Development Test 5 (2013-12-07):
- Update to Cherrytree 0.31.4
Development Test 5 (2013-09-27):
- Update to Cherrytree 0.30.5
Development Test 5 (2013-03-23):
- Update to Cherrytree 0.29.4
Development Test 5 (2013-03-16):
- Update to Cherrytree 0.29.3
Development Test 5 (2013-01-30):
- Added language switching support
Development Test 4 (2013-01-27):
- Update to Cherrytree 0.29.2
Development Test 4 (2013-01-24):
- Bug fixing
- Configuration backup
- Started Language switching support
Development Test 2/3 (2013-01-23):
- Bug fixing
Development Test 1 (2013-01-22):
- Initial release (Cherrytree 0.29.1)
DirectoryMoveOKline commented out
Thanks a lot for your quick answer.
I use portableapps for a long time now and this is the first app I tried to submit for approval.
Data\settings\CherrytreePortable.ini should not be touched by you, as this is a file used behind the scenes by the Launcher - you never have to do anything to it. But your [FilesMove] and [FilesWriteX] commands reference a file called cherrytree_win32_portable.ini, but this file doesn't exist and I'm wondering where you got it from.
Give me a couple of hours or so and I will get back to you with some necessary changes, if time permits I'll get to language switching for it, too.
I think I solved all points you mentioned. The [FilesMove] and [FilesWriteX] commands I copied from another app but didn't understood its purpose. Now after reading a bit more realized that they are not needed... I will upload this version so that you can have a look.
Where can I get/build the final splash image or this app?
How long will the app take to be published?
You stick with the default development test splash until (if) such a time comes when it is released officially.
First time developers can sometimes take a while to get their first app released (over a year for me, longer for some, less for others). It largely depends on how popular the app is, whether it fills a specific function not yet present in the PortableApps catalog and how quickly it gets through testing, but there is also a factor involving how proficient you are with the PortableApps process, and how well you handle updating your apps, too. John doesn't want to rush-release an app from a first time developer, just to have them drop off the site soon after and leave him with more work.
But don't be put off. Your best bet is to keep going, find more apps to post, and get your head around the full process of making an app portable (including language switching, probably the hardest part of the process to get your brain around).
Regarding language switching, I've had a good look at Cherrytree, and I'm 99.9% sure it is going to require custom code, so we'll leave it alone for now. When I have more time I will look at it (custom code isn't a strength of mine, but I need to learn).
By "language switching" you mean configure the app language directly from the language he selected during the installation?
Yes, I didn't see any configuration file written on the cherrytree_win32_portable folder... Also checked registry, but nothing relevant was stored. So, I'm not really sure how preferences are kept. I will try to have a look on its code and try to figure it out.
Yes, I will continue. I have a couple more apps I'm used to use under portableapps framework as they have the .exe in the first folder, it works just fine. I'll try to convert them too
Getting there, but still a few issues.
file_dir = DEFAULTSAVEDIR
This will make Cherrytree point to \Data the first time someone tries to open or save a file, instead of somewhere on the host machine, and won't affect anything after the first run. But as I said, it is optional if you want to do it or not.
I uploaded a new version with most of the points you mension corrected. I'm not sure what I need to do regarding point 3 (please have a look in installer.ini and check if it's correct.). Also updated the laucher.ini and found how language is set. Cherrytree creates a file %APPDIR%/cherrytree/lang with codes like (en,...). I don't know yet how to handle the languages and how the process works but already started to do something in laucher.ini (I had a look on other app...).
Please review version 3.
Good job on the path handling and DEFAULTSAVEDIR stuff, they both work fine.
You missed point 2 - remove everything from the installer.ini except the [Languages] section, including the new line you put in as a result of point 3, which wasn't very clear on my part.
I meant that before you run the PortableApps Installer to create the paf.exe package, you need to delete the Data directory from your folder structure (if it is there, my new beta test of LAN Messenger seems to create Data when installing which is odd).
Regarding language switching, you've got a good start and there are some issues, but because of the way Cherrytree stores its language nothing you do in the launcher.ini will work, because as far as I know and have tested none of the [LanguageFile] or [FileWrite] Types handle strings with nothing to define them, and none of them handle wildcards either.
To achieve language switching here we would need to write some custom NSIS code, which I will look into as time permits.
There is no need for removing Data before running the installer. In fact, you can have other files and directories next to the portable app; the install will only pack App, Data, Other, help.html and .exe files in the root.
Previously known as kAlug.
I know there is no technical requirement to remove Data but I think of it more like a preventative measure.
I recommend it so people get it into their workflow and minimize the possibility of existing data files being packaged, in case the user has run the app prior to packaging it.
I tried several things too, but yes, it seems to be hard to parse a file containing only a word...
Ok, will fix these last things and maybe I can explore NSIS. Is there any way to call/use/introduce/execute NSIS custom code by defining something in these .ini files? Is there any info on that?
You can access data from launcher.ini in custom code, but you may not need to as it all should be in the Launcher's environment variables. Don't quote me on it though as custom launcher code isn't something I've really touched.
The documentation is here and you will also need to know about segments, and the debug stuff may be handy, too. Honestly though, the documentation on custom code is quite minimal, your best bet is to find an app that utilizes custom code for the same purpose and just use the documentation for reference.
I was having a closer look into this Custom.nsh things and at a first check it is not so complicated, but lets see.
My problem is more related to the expected behavior of the [LanguageFile] and its relation with the normal associated [FileWriteX]. I was assuming that this is only used during installation time to configure the application with the language selected in the AppInstaller. Am I right?
Meaning that if what is defined below is true (file exists) nothing else is executed.
But if the file doesn't exist the default language will be written to a file using a [FileWriteX].
So what are the [LanguageFile] for?
For my case this doesn't help so I have to build the Custom.nsh to read whatever is on the lang file, right?
I thought that the idea was to use the configuration on the launcher to update the lang file with whatever was selected on the installer using the [LanguageStrings] to map the correct characters to write into the file.
So, I'm a bit lost here.
Can you give some guidance?
The language switching code does not preset the language to what was chosen during installation.
Everything in the language switching except [LanguageFile] is about trying to set the language of the base app to the same as the Platform if the option is set to run all apps in the same language as the Platform.
The [LanguageFile] bit is only there for if the app isn't running from the Platform to determine the last language the app was run as, otherwise every app not run from the Platform would just end up in English.
I think I got it now.
I managed to build the Custom.nsh to change the lang file. I tested it by changing the language options on PortableApp. Each time we run the app the file is updated, then the app reads it...
Can you give feedback on this last update?
I was wondering if you're still interested in supporting this on an ongoing basis. I think this would be a good app for us to make official.
Sometimes, the impossible can become possible, if you're awesome!
I have tried to have it always up to date. So, yes.
I think this might be next weeks new app release then. I'll give it a full work over before then.
Sometimes, the impossible can become possible, if you're awesome!