primarycat / chromora Goto Github PK

The ability to lock certain colors on the palette during generation, so that the next generated palette keeps the locked color, could be useful especially while generating random palettes.

Y-Scroll Bug

Bug Description: On mobile layouts, if the page is scrolled enough that the color wheel is still visible, the color picker will move under the inputted position.

How To Replicate: Switch to the mobile layout, scroll the page down and click/tap on anywhere on the color wheel to move the picker.

Expected output: Picker moves to the clicked/tapped position.

Actual output: Picker moves below the clicked/tapped position.

Fix: Add the y-scroll of the page to the offset calculations.

Palette Import Bug

Bug Description: When importing a palette from a code, the color picker will not move to the correct position.

How To Replicate: Export a palette via code, move the picker and import the previous palette using the code.

Expected output: Picker moves to the position of the main color.

Actual output: Picker stays where it was previously.

Fix: Call the correct method during the import process.

Although PWAs are useful, standalone apps could even be better for various reasons especially for mobile platforms.

There are two paths to achieve this:

1. Use a framework like Electron/Tauri/Capacitor. The upside is that the current codebase can be used with slight modifications, the downside is that this, in my opinion, creates an inferior version of the PWA since it's literally the same thing with more overhead and most likely worse performance.
2. Completely rewrite the project in native platforms. The upside is that the performance would likely increase, and there'd be an actual reason to choose this version over a PWA, downside is that the project would split into (n) different projects each with their own maintenance work.

A positive for both paths, a native app could be distributed through app stores to reach more users. A negative for both paths, they create a lot of development overhead for unknown (possibly negligible) amounts of exposure.

At this point, this issue is more of a suggestion than anything else. It's in 2.0.0 milestone but it's not a promised feature.

Right now the notifications are only used for code exports, and as such they're hard coded. Notifications should have a system in place for 1.4.0, as a number of other improvements could also benefit from their use such as #3.

Moreover, the notifications don't fit the app aesthetically. They should be revamped so that they fit more with the general look and feel of the app.

Currently, the sorting is bugged on chrome with monochrome palettes, where the darkest color is displayed as the second swatch instead of the first. Investigation is needed.

Currently the code generation algorithm is very barebones, and it doesn't allow for more complex palette types to be exported such as random palettes or palettes containing locked swatches.

A more robust algorithm that can export any palette would be useful.

I would normally do this by saving exported palettes in a central DB where they can be referenced, but it's important that the app works with full capacity offline so this solution is out.

Another solution is to just make the "code" a listing of all colors, or the generator parameters (as it is now) + locked swatches, but with larger palettes the resulting code would be way too long. Zipping the resulting text could make it smaller, but that also completely depends on the palette and would present very inconsistent results.

Another solution would be to list all colors, but instead somehow encode them into a binary file (1 color can be stored in 3 bytes as RGB values, so the resulting file size would be really small with 108 kb for 36000 colors) and replace "code" export with a "file" export. Honestly right now this looks like the best bet, but I feel like this is unnecessarily complex and with a little thinking a more elegant solution could be found.

All suggestions welcome.

Nice simple application. I like it.

You could consider defaulting the colour to the value in the html input id="hex" instead of setting a default in the javascript.

let initColor;
// if(theme === "dark"){
// initColor = new Color().fromHEX("#E7B03A");
// }else{
//initColor = new Color().fromHEX("#2265A4");
_colorInput("hex");
// ;
// }
//updateColors(initColor);
//ColorWheel.positionFromHSV(initColor);
_generate();

Also, it would be nice to be able to copy each colour from the generated palette in text.

Last I checked, the entire thing behaves weirdly and doesn't look right on desktop and mobile Safari. My only way of working on WebKit is with Epiphany, however I cannot replicate the issues there.

Moving this to 2.x so that I can come back to it if I ever get a device that I can use to add full support for Safari.

Also marking this as a "good first issue" since the problems shouldn't be that hard to fix, just that I have no way of debugging on these devices. If anyone wants to tackle this, feel free.

The main script for the app main.js is longer than 1000 lines, and continues to get longer.

I believe using ES6 modules to break the script up into smaller parts will be better for modularity, maintainability and even readability.

Color-Thing's main focus is being fast and lightweight, so I'll need to test this to see if it affects the footprint of the app and it's speed (both page load and execution) and if it does, to what degree. After this, if the effects are acceptable, I think it'll be better to go forward with a more modular approach.

Currently there are some issues regarding the service worker with the updates. It's supposed to erase old caches and replace them with new files on an update but nothing short of manually deleting old caches seem to work and users might be stuck on earlier versions.

This needs to be investigated and solved.

When I started this project I didn't think I'd spend so much time on it and grow this attached to it, so I just gave it a throwaway name. Now with 2.0.0, I want to stop the development of this project further besides maintenance (and full webkit support if anyone wants to tackle that.) and to celebrate, I want to give it a makeover.

• First issue is the name. Color-Thing: Color Palette Generator is a mouthful. Color-Thing on its own isn't a really great name either. So any name suggestions are welcome. I'm currently thinking "Chromora".

• The logo can stay.

• The logo can be incorporated somewhere on the main screen instead of being relegated to the about page.

• The default accent color / palette should be updated to reflect the logo colors.

• The project should move to its own domain if possible (need to check the costs and see if this is worth it).

• Depending on the previous point, SEO improvements could be made.

However the rebranding will NOT affect the current vision of the project, that is:

• The app must still be completely free to use.

• There won't be any ads, premium features of any kind, data collection or anything.

• No watermarks anywhere.

The rebranding is the smaller issue, first come #17 and #13 , and this is just my sendoff gift for the project more or less.

Print Export

The current print export layout is not very pleasing to the eye, or ink efficient. Improvements should be made to the layout in order to improve efficiency and aesthetics. (Implemented in #14 )

Image export

The current image export is very barebones. If the exported image was a "copy" of the palette display, the user could get more information and a more consistent output. (Implemented in #15)

Additional export options

Currently, there are only options to export the entire palette. A feature to only export individual colors could be useful.

The immediate idea is to make it so that each value present on the swatch (RGB, HSV, HEX and color name) is clickable, and on click copies its values to the clipboard. For mobile, the idea is to make this available once a swatch is expanded to prevent accidentally copying values and overriding a user's clipboard. (Implemented in #9)

Suggestions welcome.

This issue is for compiling a list of bugs related to mobile browsers.

1. Tapping on the code export notification dismisses the notification immediately without copying the code to the clipboard.
2. Can't tap on the swatch labels to copy information.

In 1.4.0-Beta1, manually entering color values in the text fields don't update the accent color.