lwouis / f9 Goto Github PK

It's always useful to have an idea of the memory/cpu footprint of an app at runtime.

Also, it would be interesting to write automated perf tests (unit tests, integration tests, memory leak detection tests, stress tests).

Use JNI? Manually invoke another language to do the job ? (e.g. python or C).

I already tried a lot of these solutions, and they are all hard to implement/maintain, fragile across versions of Windows.

Also this can be unit tested during #2 by checking that the resulting base64 code is the same as some mock data.

Falcon 9 / F9. Maybe even rename the app F9 to be more memorable

Use the gradle getdown plugin to integrate GetDown in the app.

This means auto-updates, and delta updates. It also encompasses distribution on Windows (portable folder or installer.exe)

Provide localization so the app is accessible to users from different countries

Add a popup on startup if the user has nothing yet in the app. Propose to add their apps for them.

This means parsing C:/Program Files/ and C:/Program Files(x86) once, then to main sync, check if something new showed up on a timer, or during startup (this can be a pref).

Note that if the user delete an app which was added automatically, we should not add it back on next update. It kind of signify a blacklisting from the user's perspective.

It would be useful to export your app list so people could check what app you use. Another use-case is people with multiple machines.

Highlight search matches in the list

Today if you trigger fast saves, they will conflict with each other, and anyway it make no sense to execute a previous save if you have newer/fresher state to save instead.

Improve the algorithm on the search bar to account for typos, utf8 characters (e.g. typing "ete" to find "été.jpg"). This means both the filtering, and the sort order of the results.

Integrate the "it was recently used by the user" factor. Check how Z does its frecency.

Current plan is to use Apache Lucene.

Current code in TrayIconManager.java is:

closeItem.setFont(new Font("Segoe UI", Font.PLAIN, 14));

This MenuItem.setFont(Font) API has a bug which makes it not apply.

Maybe some hack is possible (e.g. passing a child to this element then changing the child font, or maybe overriding the drawn pixels directly by subclassing or calling a method on TrayIcon.

DiskPersistanceManager.oneLevelDeepCopy is called within the background thread thus concurrency issues should still be possible.

Need to put that code into the UI thread. And test in-depth -> write unit tests.

Find a gradle plugin to automate versioning, and link to github tickets and commits automatically.

Use TestFX to make some UI tests:

• the many keyboard manipulations
• show/hide behaviour
• drag&drop

Color the path red with an icon or something (for color-blind people) to tell the user that the path of an item doesn't/no-longer lead to something.

on smaller/larger displays, the default window size should be different

Check how PrtScr does the 3D effect.

The effects need to be decorative, but not slow down operation of the app.

Use Travis for CI.

Compiles
All the tests from #2 and #5
Code coverage
Checkstyle
Sonar-like?

While in production-mode, the app shouldn't be logging to file but show a dialog with "send issue through email" or something.

Also for performance/size reasons, dev libs/code shouldn't be included with the production build. Maybe check the state of treeshaking in the Java world also.

Try to reduce file size by using something like Proguard.

Through right-click, and the menubar, the user should be able to update the item name, path, and launch arguments.

This also overlaps with #1 since editing an automatically-added app means that the app shouldn't be updated as the user "froze" it.

To save application state to disk, the current implem serialize state to JSON then write to disk. A better implementation would only write deltas to the current file.

Another benefit would be that updates done in background threads wouldn't need a copy of the observable list to avoid concurrency issues.

With every keystroke, the item list is filtered, but while refreshing the visual of each item, there is a flickr during which we can see another item for a brief moment. This only apply to the name section, not the path/icon

I got surprised to see different icon behaviors at home/work. Also some .lnk files I had at work were crazy and unexpected.

Maybe #2 allow to simulate different environments? It allows headless so maybe it's possible to run it in VMs.

Also try multi-display, small display, and low-spec setups. See #5

When the app is closed through the top-right cross button, and the "Quit" context menu on the system tray icon, everything is fine.

When the app is closed through Task Manager (by a SIGTERM/SIGKILL signal in general), the threads are closed, the JVM is deallocated, but Windows fails to clean the icon until the mouse hovers it.

I tried Runtime.getRuntime().addShutdownHook() which removes the icon when clicking on "Exit" on the bottom left in IntelliJ, but it doesn't fix kill the app after that.

DiskPersistenceManager listens to changes on the observable list right at init, thus the first load into the list triggers a useless save.

Some points to improve:

• selected item in the list is grey. It should be obvious that pressing enter will launch it
• first result item line should be more prominent. Maybe the name could be in bold, or a different height for the row
• combine the titlebar to be more vertical-space efficient, and have a denser interface for the in-the-spotlight front-and-center app.
• the app in general could be skinned for more visual delight

Add app icon (different from windows installer/distribution)

Save on the disk should be atomic in order to avoid stopping in the middle of it, and corrupting the files.

Check if move+copy is the best pattern to do this.

If the user typed a new key, we should focus their view uptop on the most probable candidate

Text highlighting generates a lot of Text() instances. These creates garbage and thus GC spikes. Pooling them at listview level solves this issue.