Gingko Desktop Beta


#1

Hi all,

Gingko is now available (in beta), as a downloadable local-file version, for Windows, Linux, and Mac.
You can get a download link and instructions by signing up here:
http://beta.gingko.io

Let’s keep the feedback on this thread, so that you can see if a bug has already been reported or not.

Thanks!
Adriano


#2

Know bugs, as of 0.0.8:

File Load Error (on launch, Mac)

Kevin and Justin report “Here’s another error I encountered immediately after starting the app:”

Missing Menu (Mac)

Kevin and Justin also report that there are missing menu items on the Mac:

I did not have any options in the menu bar other than command-q under Gingko menu.
- Justin

I can’t seem to import data to the desktop app. There are no obvious commands (via the toolbar or right-click) to do so
- Kevin

There are supposed to be the following menu items (this as seen on Windows/Linux):

Differences from Web Version

Here are a couple intentional differences from the web version, that I’m playing with.

Automatic Titles

The reasoning here is: many cards require titles, and often we want the titles to reflect the depth of the card (h1 for column 1, h2 for column 2, etc). Now the first line of the textarea is reserved for titles.

If your card doesn’t need a title, just skip it by pressing Enter.

To manually set the level, just use hashes as normal (#, ##, ### etc)

I know that if you have a large number of title-less cards, this means an extra keystroke. But if you use titles often, it saves you from: learning the syntax for titles, setting (and later, updating) the depth of the title.

It’s a tradeoff, we’ll see how it goes.

Single Root

This is not obvious visually, but the root card behaves differently from others. The reason for this is future-proofing.

With the web version, I had wanted to add several features that are far easier if your trees are actually trees (with a single root), and not a collection of trees. For example, for embedding trees within other trees.

I know it “wastes” a column, but I believe it will be worth it in the long run. For one, I don’t expect the first column to be wasted later (it can hold file preferences, plugin options, or any other tree-specific settings, for instance).

Again, we’ll see how it goes.


PS: I am trying to get a macOS virtual machine going, because it’s clearly the platform with the most bugs so far. Current attempt: VirtualBox + macOS Sierra on my Ubuntu. If you have any other suggestions for mac testing, let me know!


#3

I like that I can set the heading level by defining it with a hash, as with the web app and Markdown in general. I don’t think I’d be one of those who’d like to have an automatic level-to-heading selection, so it’s nice to see that I can ignore it or reconfigure it to the way I prefer.

As for the root card issue: This is a hard one for me, probably because I don’t have your future visions in mind. I think I can see value in having other root cards like preferences, help, styles, etc, but how would I handle this single root card in my tree? It would end up being just a placeholder of nothing of any real value, with a title like Kevin’s tree containing content like “This is Kevin’s Gingko tree containing notes about work, personal issues, and un-categorized Inbox issues.” Doesn’t seem that that adheres to the idea of every card containing relevant information in and of itself.


#4

I don’t disagree on root card @Kevin. Thanks for the input.
It’s true, that it’s an inconvenience now, for some future possible convenience… will give it more thought.

Another idea: instead of opening multiple Gingko windows, first column could hold all root cards currently open. In this way, this column would be equivalent to “tabs” in other software. Would be useful, for instance, with global search (search all open trees), moving data between trees, etc.


#5

Ah, now that’s an interesting idea: The root card would be the de facto container for all the user’s trees and would be identified as such. So it might be labeled My Trees (not that I’m necessarily recommending that as a label) with other cards like Help, Settings, Styles, etc. at the same level as My Trees. The root card would then spawn all my other trees, like Personal, Work, Inbox, etc.

My only remaining objection would be the following: Users might feel that the main app area should be devoted entirely to their own content rather than to administrative content used to maintain the application. So, while devoting the first level to administrative content might provide quick access to that sort of information, it does rob the user of space that might otherwise be devoted to their own content… All of which you noted in your initial comment, I believe.


#6

Yes, that’s a good point.
I was thinking either “admin” or “meta” cards in column one, or collection of open/chosen trees.

Will come back to this once I get the core experience for one tree stabilized and usable.


#7

0.0.9 Released

Apart from a few other details, the biggest fix is the menu issue on macOS. That means that Gingko is now actually usable on macOS. You can create new files, load files, import, export, etc.

Here’s the list of changes:

  • Menu fixed on macOS (wasn’t showing “File|Gingko”, “Edit”, “View”, or “Debug” menus).
  • Fixed: Onload “File not found” error for macOS.
  • InsertAbove/Below commands when on Root card no longer creates children.
  • Cards now have max-height on edit mode, then switch to scroll.
    Prevents scrolling bugs with long cards.
  • Ctrl/Cmd arrows in edit mode no longer create cards
    (shortcut conflicted with text navigation).
  • Pressing Tab in edit mode inserts two spaces (previously: lost focus).
  • Code blocks (triple backtick) now preserve whitespace.

Pacing - Slower next week

I am going to take next week off from extensive development & bug fixes.
I’ve been doing nothing-but-coding during my work time for the last 3 months, so I need a break to address everything I decided to let slide.

However, the more feedback I can come back to, the faster I can continue to iterate when I can get back to it.

New Version Notifications

As I mentioned (to some) by email, I won’t be sending out a newsletter on every new minor version.
If you are interested in knowing, you can follow @Azenha’s lead and subscribe to notifications on the CHANGELOG.md file as shown here:


Thanks for the help so far!


#8

More bug reports, from 0.0.9 (and before).
Thanks to Daniel M for both of these!

Copy/Paste doesn’t work on Mac

Copy and Paste does not work at all on Mac Os X 10.11.6 El Capitan.

Example 1:

  1. I copy your Text from your E-Mail and hit CMD+C or RIGHT-CLICK and COPY.
  2. I switch to Gingko Desktop and hit CMD+V. (RIGHT-CLICK does not produce a contextual menu in Gingko).
  3. Nothing happens.

Example 2:

  1. I select some text in Gingko and the text is highlighted while I am selecting
  2. The highlight vanishes, when I stop selecting.

Post-crash error

My Computer just crashed. I had to force a reboot.
When I now open my Gingko Document, all data is gone, which is no problem at this point.
Mac Os X tried to resume Gingko after the reboot. Here’s the screen I got:


Priority: Reliability

A note about the lost data reported here. My number one priority with Gingko Desktop is to make it, as far is technically possible, very very hard to accidentally lose data. So I will soon be focusing on regular autosaves, temp files, recovery files, etc…

The goal is for even a hard crash to not cause you to lose more than a few characters.

To that end, any time you lose even a single word with this software, let me know in as much detail as possible.


#9

I can’t manage to run 0.9 on Mac Sierra. I gunzip it, then untar it, and the un-tarring process produces errors like the following:

x Gingko-darwin-x64/Gingko.app/Contents/Frameworks/ReactiveCocoa.framework/Modules/module.modulemap: Cannot extract through symlink Gingko-darwin-x64/Gingko.app/Contents/Frameworks/
ReactiveCocoa.framework/Modules

and

x Gingko-darwin-x64/Gingko.app/Contents/Frameworks/ReactiveCocoa.framework/Headers: Can’t remove already-existing dir

I had a similar problem with an earlier build, but managed to get 0.8 installed. Am I doing something wrong, or is the Mac build messed up somehow?


#10

Most likely I messed up with archiving for Mac, an issue I had a couple builds ago.
I believe I know what I’m doing wrong… I uploaded a new archive.

Let me know if it works this time around.

Thanks @shanusmagnus!


#11

Thanks @Adriano, works now, thank you.

One pseudo-bug:

When you initially create a new card, and type some stuff into it, if the new card needs to scroll to accommodate the new text then some of initial text will disappear (will scroll off-screen in the card) and you won’t be able to see it. If, however, you re-open the card, and type more text, the card will lengthen downward, so that all of the text remains on-screen. (This latter is the way the web app works.) So it appears that scrolling behavior works differently for new cards vs. re-opened cards.


#12

Got it, Shane, thanks.
Yes, the latter behavior is what I intended (as it works in web app), so the fact that it doesn’t at first is a bug. Thanks for pointing it out.


#13

0.0.10 - Autobackup

In line with my priority (“as reliable as possible”), I’ve now added an automatic backup on every card change (save, insert, delete, move), and on every ~10 characters while editing.

Every 10 might be a little excessive, but it’s tunable. Let me know if you experience any performance changes with the latest release.


#14

@Adriano, where do these backups live in the filesystem?


#15

Hi @shanusmagnus.
The backup files are present as {original-file.gko.swp} in the same directory as the original.
However, they’re cleared on a clean exit.

If you try to load a file, and it seems that a .swp file already exists, it warns you that there was likely a crash, and “would you like to recover”.

FYI, I removed the backup “every ~10 characters while editing” because of performance issues. Not fundamental ones, so this will be back… just issues with implementation.


#16

While actually putting content into the system, it would be really convenient if the first line that the cursor landed on was not the “make new title” line every time. At first, I didn’t think the extra keystroke from just entering past it would be much of an issue – but that gets bloody annoying really quickly.

Given that creating cards with titles is actually not the primary use form for a new card, data entry should probably begin on the second line by default.


#17

Thanks for the input. Since this is something I’m experimenting with, I’m definitely open to changing it.
Will give it more thought, and wait for more input.


#18

I’m using the Desktop Beta on a Mac, and it works well for what it does so far. Missing features such as cut and paste, search, etc., make it difficult to test it on a real-world project. Do you anticipate including all the features of the online version as development progresses? If so, the offline app would be well worth the asking price. Thank you for your work on this.


#19

Yes, I intend to make it have all the features of the online version. Will do my best.

Cut and paste for Mac is on my list of know bugs. Working right now on rewriting the saving and autosaving logic, for better stability.


#20

This is really helpful when the network is down (especially with the recent ddos attacks!)
I did encounter a snag tho… now I want to import my cards online. I’m not sure how I’m going to do that.
The functionality isn’t there yet?

Note that import is actually missing in the online version. Or I haven’t figured out how to import

Alternatively, I could paste markdown of each individual card

Or better… Just import as a single blob and then split into cards :smile:

Thanks for you time!:relaxed: