bayleeadamoss / zazu Goto Github PK

I'd like an option to disable/enable the mouse support.

Often, when typing I hit my trackpad and it shifts my results, which is undesireable. Mouse support is so common, I'd say this should be opt-in behavior.

Right now, a theme determines which icon shows up. Zazu needs to be able to give the theme the icon instead.

1. Install the clipboard plugin
2. Open zazu
3. Use the clipboard keyboard shortcut to launch zazu
4. ASSERT the zazu logo still appears instead of the clipboard logo

1. Have file finder installed
2. Have system installed
3. Type in "lo"
4. Scroll to "lock" and click it
5. Repeat a few times
6. Assert lock is not the first result.

We should provide a debounce for plugins. We want it to first at the end, but we also want the first one to fire immediately, and we want all subsequent responses to return the previous promise. So it works a little different than other debouncers.

1. Install clipboard plugin
2. Open Zazu
3. Use hotkey to launch the scoped clipboard plugin
4. Use the menubar icon to toggle zazu closed
5. Use the menubar icon to toggle zazu open
6. ASSERT clipboard plugin is still scoped.

One of the issues we ran into was getting a plugin working. A lot of the issues were syntax errors and general api issues. If we had a boilerplate with basic tests and example blocks this could be a lot easier path to go down.

We could litter the code with doc links.

We are currently using git-clone we should switch to nodegit

http://www.nodegit.org/guides/install/electron/

Originally, I went without nodegit since it couldn't compile on windows and linux, but I think it's a better solution then relying on users having git installed.

In the readme we should list we are anonymously tracking by default.

The first time they launch we should give them a notification that we are anonymously tracking.

There can be a setting in ~/.zazurc.js to disable tracking.

1. Launch Zazu
2. Type something to get results
3. Hide zazu
4. Show zazu
5. ASSERT old results appear for a second before going away

My work computer won't allow me to overwrite this setting, I had to compile locally.

Electron-builder (#56) has these docs.

As a user who often clicks the wrong thing
It would be nice to have search history I can traverse
So I can return to previous results

Way to reproduce:

1. Open the About page.
2. Close the About page.
3. Try to quit Zazu.
4. Exception.
5. Profit??

Uncaught Exception:
Error: Object has been destroyed
    at Error (native)
    at MainEmitter.globalEmitter.on (/Applications/Zazu.app/Contents/Resources/app.asar/background.js:65:17)
    at emitNone (events.js:85:20)
    at MainEmitter.emit (events.js:179:7)
    at MainEmitter.emit (/Applications/Zazu.app/Contents/Resources/app.asar/lib/globalEmitter.js:20:11)
    at menuTemplate.click (/Applications/Zazu.app/Contents/Resources/app.asar/helpers/menu_template.js:64:21)
    at MenuItem.click (/Applications/Zazu.app/Contents/Resources/electron.asar/browser/api/menu-item.js:81:16)
    at Function.delegate.executeCommand (/Applications/Zazu.app/Contents/Resources/electron.asar/browser/api/menu.js:119:40)

I've noticed every now and then zazu runs slow. My theory is that this is based on the file finder locking the thread.

If this is the case we could test it by changing the interval to 0 and seeing it be laggy all the time.

This could be fixed by using child_process.fork

Another theory is that the setInterval stop working when a laptop is asleep, and upon waking catch up by calling the method x number of times, which slows it down. This could be tested by sleeping the computer and, upon waking it, try and use zazu.

We could fix this by adding debouncing on top of the setinterval.

Or I my hunch if totally off and we should look into other issues.

Storing an api key in your zazurc.js file means it can't be backed up to github or other public type places. There should be a way to easily add encrypted data to this file. Possibly related to the package manager #32

https://github.com/electron/electron/blob/master/docs/api/app.md#appmakesingleinstancecallback

I would have assumed that "Terminal.app" would be higher in the list.

To reproduce:

1. Focus on Chrome
2. Open Zazu
3. Close Zazu
4. Assert chrome is no longer focused

If your file is not correct then zazu will run however you won't be able to quit unless you kill the processes.

These should be the same, after having more strict validation (#33) this should be easy to do.

cc @amjith

• Output blocks
• Install Plugin
• Update Plugin
• Toggle window
• Navigate Results
• Compile process

Maybe something like:
https://github.com/winstonjs/winston

Used universally.

When no window is focused you can't toggle devtools it throws an exception. We should handle this more gracefully.

Uncaught Exception:
TypeError: Cannot read property 'toggleDevTools' of null
    at click (/Applications/Zazu.app/Contents/Resources/app.asar/helpers/menu_template.js:61:43)
    at MenuItem.click (/Applications/Zazu.app/Contents/Resources/electron.asar/browser/api/menu-item.js:59:9)
    at Function.executeCommand (/Applications/Zazu.app/Contents/Resources/electron.asar/browser/api/menu.js:121:15)

https://github.com/electron/electron/blob/master/docs/api/app.md#appsetloginitemsettingssettings-macos-windows

If a plugin fails to update, we don't tell the user anything.

If a single plugin fails to load, we should tell the user it failed to load, and still give them a notification when the process of updating is complete.

We could also think about having a more reliable "update" then a git pull and reloading it.

https://gist.github.com/domenic/ec8b0fc8ab45f39403dd
https://developer.github.com/guides/managing-deploy-keys/

just needs to be modified to run npm run docs:deploy

It would be great if the plugins could have a shared context between them all, great for counters, connection or other shared things.

This could be great for testing plugins, or adding/removing plugins.

External blocks aren't logging correctly.

https://github.com/tinytacoteam/zazu/blob/master/app/blocks/externalBlock.js#L11

should be data.pluginId

Problem

We can release a new versin of Zazu with backwards incompatiable changes to themes OR/and plugins. A user has no built-in interface for updating dependencies.

Proposed Solution

Zazu can maintain a list of breaking changes by type:

themes: ['0.1.0 - 0.1.5', '1.0.0 - 0.2.0'],
plugins: ['0.1.0 - 0.1.5', '0.3.0 - 0.2.0', '1.0.0 - 1.3.0'],

Then, plugin developers can mark in their plugin what versions this code was tested on:

module.exports = {
  name: 'Clipboard',
  zazuVersions: ['0.2.0', '0.3.0', '1.0.0'],
}

Now, it can warn the user based on these things. We will NOT disable plugins based on these settings, just warn the user. These plugins could still be working just fine and we should lean on the side of the power user.

Philosophy

This enforces a fail forward type of design, where as a user the only interface I have is to update zazu or my plugins.

Given I download a version of zazu
When I install a plugin that works on my version
Then everything works as expected

Given I download a version of zazu
When I install a plugin that doesn't works on my version
Then it prompts me that the plugin is not compatiable
And gives me the option to check zazu for updates
And gives me the option to check plugins for updates

Given I have an old version of zazu
And I have plugins installed and working
When I update zazu
And I now have plugins that are not compatiable
Then it will prompt me that some plugins are not compatiable
And gives me the option to check my plugins for updates

The issue is that their require is cached in our node require.cache, we could possibly clear this per plugin before requiring.

1. Install an old plugin without outdated package.json dependencies
2. Open zazu
3. Assert plugin works
4. Update plugins
5. Assert plugin is broken
6. Restart zazu
7. Assert plugin works

This gives themes the ability to decorate based on holidays.

Here's a module I found that gives us the correct functionality:
https://gist.github.com/blainesch/b710aece2d679207340b6c8793817f6b

Zazu is aggressive in adding itself to the startup. If you remove it and restart zazu it'll re-add itself. There should be some way for a user to remove it from the startup and keep using it as needed. There are a few ways to accomplish this.

Select all/copy/cut/paste inside of zazu.

Validate:

• plugin icon
• Block types
• Block data
• Script formats
• Return values

If you compile zazu, it stops sending notifications.

The problem is when we compile with asar we need it to unpack the notifications executables.

Problem Description

https://github.com/mikaelbr/node-notifier#within-electron-packaging

Places to Change

https://github.com/tinytacoteam/zazu/blob/master/tasks/release/linux.js#L37
https://github.com/tinytacoteam/zazu/blob/master/tasks/release/osx.js#L39
https://github.com/tinytacoteam/zazu/blob/master/tasks/release/windows.js#L37

Select a text and type a shortcut to show the text in Large Type.

Often results can have multiple actions based on a modifier key like shift/alt/cmd/etc.

Possibly a Decision type of block to dynamically pick the connections.

I think it's an unnecessary dependency.

If we switch to electron builder we can remove these dependencies from the non-app repo:

• yargs
• q
• gulp-util
• fs-jetpack
• gulp (if we convert gh pages task)
• asar
• appdmg
• rcedit
• Ensure correct naming (zazu-v0.1.3-darwin-x64.dmg)
• Widows needs a nupkg file?
• Maintain a auto_updater.json file. Possibly on zazuapp.org ?
• Signed app
• Test installs manually
• Make final tag release to test CI uploads

https://github.com/jenslind/electron-gh-releases/blob/master/docs/2.x/how-to.md
https://github.com/electron-userland/electron-builder
https://github.com/electron-userland/electron-builder/wiki/Code-Signing
https://travis-ci.org/tinytacoteam/zazu/builds/167393493