Forum Posts Feed
RFC - New Software Project: Infosqueezer
< Next Topic | Back to topic list | Previous Topic >
Posted by Lothar Scholz
Sep 11, 2019 at 10:36 PM
>To follow up on my “database”/file storage question: So the data will be
>stored in a proprietary format on disk? No way to get the data out when
>I decide to stop using your app or when you (one fine day) stop updating
>the software?
Using the Export feature?
I don’t think that the database itself needs to be non proprietary.
I’m not designing the program to stop starting one day and prevent you from using the export menu option.
I have no intention to create a vendor lock in.
But if you use it there will be one automatically because of the unique feature set.
This happens with every program.
There will be exports to plain text markdown, xml, json and OPML natively.
The json and xml file format will be simple and documented and the base for anyone who want to write transformation tools.
I will write at least one transformation tool for html myself.
If you have good ideas i’m listening.
I’m a CRIMPer myself, i know that this is important.
Posted by Luhmann
Sep 12, 2019 at 04:56 AM
My main concern is workflow. It is hard to get a sense of this without mockups of the actual UX, but it sounds like things will be divided into “cards.”? One of the things I like about both Ulysses and Dynalist is the ability to easily merge and/or divide other blocks of text into either larger or smaller units. In some apps, however, this can be quite cumbersome, requiring a lot of pre-processing of the text in something like BBEdit before it can be imported properly. Let’s say I have a PDF which exports with improper line breaks. If I import those and it assigns each line of text to a different card, will I be able to easily merge them and clean up the line breaks within the app? Or the reverse, if I have a text that is long can I easily break it into smaller cards? This kind of thing actually takes up a considerable amount of my time as I move text from one app to another and the less I have to do of this the better. (For the same reason I probably won’t actually use the app until iOS support is implemented, but I do like the idea!)
Posted by Simon
Sep 12, 2019 at 07:13 PM
Luhmann wrote:
>In some apps, however, this can be quite
>cumbersome, requiring a lot of pre-processing of the text in something
>like BBEdit before it can be imported properly.
Slightly off topic, but Textsoap is good for this: https://www.unmarked.com/textsoap/
I use it all the time and it’s pretty quick.
Posted by MadaboutDana
Sep 13, 2019 at 08:27 AM
Well, good for you, Lothar - I think this sounds like an exciting and desirable concept.
You might want to take a look at Ilaro on macOS/iOS, a rather neat research/reference management app (with some irritating flaws) that does some of what you’re describing.
Cheers,
Bill
Posted by Paul Korm
Sep 13, 2019 at 02:18 PM
Good to see there will be documentation. I think only a vanishingly small number of people know or care to know what an XML transform is, let alone how to write one. So if you let others have the html transform tool as part of the package, that would be appreciated.
Lothar Scholz wrote:
>The json and xml file format will be simple and documented and the base
>for anyone who want to write transformation tools.
>I will write at least one transformation tool for html myself.