[Bug] README.md images and GIFs are broken

Uh yeah I understand why, screenshots and gif are on private repository, so I'm the only one to see it. I'll update this! Thanks for the report :)

Uh yeah I understand why, screenshots and gif are on private repository, so I'm the only one to see it. I'll update this! Thanks for the report :)

No problem. Thank you for the great app!

Thanks again 😄 Don't hesitate if you have any idea to make Colorpicker better! I've fixed the readme with new screenshots! I hope you like them!

Don't hesitate if you have any idea to make Colorpicker better!

Well, I'm a Designer, not sure if I can be of any help as you already got a good branding for your app. If you need some icon tweaking or UI/UX changes, feel free to let me know!

I've fixed the readme with new screenshots! I hope you like them!

They're beautiful and working as intended : )

Well, I'm a Designer, not sure if I can be of any help as you already got a good branding for your app. If you need some icon tweaking or UI/UX changes, feel free to let me know!

Precisely, as a designer, are there any features missing? Or are some features frustrating to use? And thank a lot for proposing to help! 😄

They're beautiful and working as intended : )

Okay cool! 👍

Precisely, as a designer, are there any features missing? Or are some features frustrating to use? And thank a lot for proposing to help!

Maybe I should open new issues for those, let me know if you want me too, gonna describe them here for now.

I have some suggestions and a few problems I've found:

I use a borderless window anager (i3-gaps) on Linux (Arch Linux), that means no close, minimize or maximize buttons nor window borders, and Colorpicker doesn't adhere to my system theme (GTK), it forces the icons in.
I wish that we had an extra option here, to disable these icons (bottom right on the mockup)
Also on the mockup is a suggestion for UX on the settings UI, instead of a miriad of colorful icons for each section, maybe highlight only the pane that the user is currently on, and grey out the rest. A accented bar that matches the icon color also helps visualize this. And no need for text if we have the icons to express the metaphor. Also this way it becomes more color blind friendly, not sure if a color blind person would use a color picker too much, but usually it's good practice to consider this. The overall idea here is declutter. But please don't take this as criticism, there is nothing really wrong with your current design, it's just a suggestion really, a possibility.
And here, maybe an outline around the selected pane? To match the lines used elsewhere on the UI, rather than just a blank pane.
Problems I'm facing includes:
- The app takes a really long time to open and have poor performance. I use Arch Linux with i3-gaps and have all the GTK back-end installed. I use the AppImage provided on the repo.
- The Show icon in realtime is really laggy.
- Dragging the shade bar breakes the interface, see screenshot below.

Maybe I should open new issues for those, let me know if you want me too, gonna describe them here for now.

Yeah It would be cool! 👍

* I use a borderless window anager (i3-gaps) on Linux (Arch Linux), that means no close, minimize or maximize buttons nor window borders, and **Colorpicker** doesn't adhere to my system theme (GTK), it forces the icons in.

Ohh, I didn't know we could do all that indeed! It's a quick and easy change for me. It's not a problem!

* Also on the mockup is a suggestion for UX on the settings UI, instead of a miriad of colorful icons for each section, maybe highlight only the pane that the user is currently on, and grey out the rest. A accented bar that matches the icon color also helps visualize this. And no need for text if we have the icons to express the metaphor. Also this way it becomes more color blind friendly, not sure if a color blind person would use a color picker too much, but usually it's good practice to consider this. The overall idea here is declutter. But please don't take this as criticism, there is nothing really wrong with your current design, it's just a suggestion really, a possibility.

Ahah no worries, I take all constructive suggestions! In fact, I was planning to change this interface and make it as close as possible to each OS. I've already started in another repository about this. The idea is to base myself on the native settings of each OS. I confess that I don't really know what to pick for the Linux interface. Since you seem to know the platform much better than me, if you have any ideas about the interface, I would be more than interested!

For macos, I'll use the native settings interface like this:

For windows, I'll use the native settings interface too: or

* And here, maybe an outline around the selected pane? To match the lines used elsewhere on the UI, rather than just a blank pane.

I don't really understand for this point.. This is the empty effect before putting an icon when dragging and dropping?

  * The app takes a really long time to open and have poor performance. I use Arch Linux with i3-gaps and have all the GTK back-end installed. I use the AppImage provided on the repo.

Yeah I know.. Electron is not the best choice for making desktop app, but it's the easier way for me to make this app for now. I have a lot of improvment to make, I hope it will be enough not to be slow anymore!

  * The `Show icon in realtime` is really laggy.

The picker feature? This feature is based on a C++ module that doesn't come from me, unfortunately I don't know enough how to create my own module to handle this, but it will be a pleasure to try to find a way to make it faster on Linux! It was already a challenge to make it functional ahah

  * Dragging the shade bar breakes the interface, see screenshot below.

Oh yeah, It's a bug from the newest release of Electron, I suppose I have somes improvments to make, but I'm afraid that this feature won't be viable with future releases.. 🤔

Thank you very much for all your feedback, it gives me a lot of happiness and I hope to be able to quickly fix all the little bugs to make Colorpicker even more robust! Normally, you should have seen the other issues, there are other features in development like the HSL sliders which are already operational for the next big update! 😄

Yeah It would be cool! +1

I think I'm satisfied with this discussion already. If opening some specific issue will help you, let me know what would help you best.

Ohh, I didn't know we could do all that indeed! It's a quick and easy change for me. It's not a problem!

Oh that's awesome to hear! Yeah, Tiling Window Managers are really useful and fun to use, highly customizable : )

They exist on macOS too, if you curious, Yabay is the most popular.

Ahah no worries, I take all constructive suggestions! In fact, I was planning to change this interface and make it as close as possible to each OS. I've already started in another repository about this. The idea is to base myself on the native settings of each OS. I confess that I don't really know what to pick for the Linux interface. Since you seem to know the platform much better than me, if you have any ideas about the interface, I would be more than interested!

In my opinion, you should follow the GNOME Human Interface Guidelines and the GTK2 UI Toolkit (Please keep in mind that they're moving to GTK3 in the future, keep updated on that). GNOME and GTK is the most widely used HIG and UI Toolkit in the Open Source world and adopted as the default Desktop Environment/Interface Toolkit, from the most popular and used Linux distributions like Ubuntu and Fedora on the Desktop to the bigger corporations like Redhat from IBM, with their very respected, popular and known Red Hat Enterprise Linux on servers, IBM/Redhat being the largest and main sponsor of GNOME and Fedora. Canonical, creators of Ubuntu, and also a big player on the IoT and server business, also adopted GNOME as default in recent years. The interface is beautiful, they aim for inovation and easy of use, and they've been catching up to macOS level of polish and even surpasing it in some areas. It's a exciting environment and UI to use, pleasing, calm, neutral, functional, practical, simple. Comes in two flavors: Standard and Dark.

The second most popular is QT from the KDE/QT team. Their community is very passionate about their Desktop Environment and UI Toolkit, but it's not used by default by most distros, desktop or server.

In my opinion, if you want to support the most used Linux distros and UI Toolkit, GNOME and GTK is the way to go.

For macos, I'll use the native settings interface like this:

For windows, I'll use the native settings interface too:

On GNOME it looks something like this: Screenshot from 2020-03-25 16-38-12

There is a close button. The inimize and maximize buttons are optional, following the GNOME HIG, you don't see it here because I use i3-gaps, not GNOME, so I disable these buttons, I manipulate windows with keyboard shortcuts and mouse drag.

I don't really understand for this point.. This is the empty effect before putting an icon when dragging and dropping?

No, I was suggesting adding an outline around this pane, like this. Currently it's blank, no border. quarta-25-março-2020_17-09-36

Yeah I know.. Electron is not the best choice for making desktop app, but it's the easier way for me to make this app for now. I have a lot of improvment to make, I hope it will be enough not to be slow anymore!

I love Electron, I make desktop apps with nativefier from web apps all the time : ) And I use a lot of Electron apps as well. It was super heavy in the past, but as devs got the hang of it and it became better, these apps are now very performant. I'm sure you're gonna improve that with time.

The picker feature? This feature is based on a C++ module that doesn't come from me, unfortunately I don't know enough how to create my own module to handle this, but it will be a pleasure to try to find a way to make it faster on Linux! It was already a challenge to make it functional ahah

This feature, it's absolutely lagging if I activate it, I have to leave it deactivated. colorpicker

Oh yeah, It's a bug from the newest release of Electron, I suppose I have somes improvments to make, but I'm afraid that this feature won't be viable with future releases..

I see.

Thank you very much for all your feedback, it gives me a lot of happiness and I hope to be able to quickly fix all the little bugs to make Colorpicker even more robust! Normally, you should have seen the other issues, there are other features in development like the HSL sliders which are already operational for the next big update!

No problem man, I'm glad to help. Your tool is incredibly helpful for a designer, it really is, I'm loving it and want to see it improve and grow.

Oh I almost talked about the HSL sliders hahaha, those are a must! Glat it's in the works!

And thanks for supporting AppImage, it's the best way to use software on Linux in my opinion. The more support it gets and standard it becomes, the better.

BTW, do you support AppImageUpdate?

I think I'm satisfied with this discussion already. If opening some specific issue will help you, let me know what would help you best. I've created somes issues just to track the progress

Oh that's awesome to hear! Yeah, Tiling Window Managers are really useful and fun to use, highly customizable : )

Yeah, you can track issue here #66 !

They exist on macOS too, if you curious, Yabay is the most popular.

Okay, I'll let a try 😄

In my opinion, you should follow the GNOME Human Interface Guidelines and the GTK2 UI Toolkit (Please keep in mind that they're moving to GTK3 in the future, keep updated on that). GNOME and GTK is the most widely used HIG and UI Toolkit in the Open Source world and adopted as the default Desktop Environment/Interface Toolkit, from the most popular and used Linux distributions like Ubuntu and Fedora on the Desktop to the bigger corporations like Redhat from IBM, with their very respected, popular and known Red Hat Enterprise Linux on servers, IBM/Redhat being the largest and main sponsor of GNOME and Fedora. Canonical, creators of Ubuntu, and also a big player on the IoT and server business, also adopted GNOME as default in recent years. The interface is beautiful, they aim for inovation and easy of use, and they've been catching up to macOS level of polish and even surpasing it in some areas. It's a exciting environment and UI to use, pleasing, calm, neutral, functional, practical, simple. Comes in two flavors: Standard and Dark.

The second most popular is QT from the KDE/QT team. Their community is very passionate about their Desktop Environment and UI Toolkit, but it's not used by default by most distros, desktop or server.

In my opinion, if you want to support the most used Linux distros and UI Toolkit, GNOME and GTK is the way to go.

Thanks for the informations! I'm going to look at all this to make an interface as close as possible to this model.

On GNOME it looks something like this:

There is a close button. The inimize and maximize buttons are optional, following the GNOME HIG, you don't see it here because I use i3-gaps, not GNOME, so I disable these buttons, I manipulate windows with keyboard shortcuts and mouse drag.

Hmm, I don't know if I will be able to detect if these different buttons have to be disabled or not independently from the others by the OS. In the worst case, I would put an option to enable or disable these different buttons.

No, I was suggesting adding an outline around this pane, like this. Currently it's blank, no border.

Oh okay! Since I'll change this interface, it's not really a problem. But for the moment I'll add this for the next update, see #67

I love Electron, I make desktop apps with nativefier from web apps all the time : ) And I use a lot of Electron apps as well. It was super heavy in the past, but as devs got the hang of it and it became better, these apps are now very performant. I'm sure you're gonna improve that with time.

Ahah yeah, this is my favorite framework for javascript! I'm really happy with the evolution and the active follow-up it benefits from. 😁

This feature, it's absolutely lagging if I activate it, I have to leave it deactivated.

Hmm interesting.. I know the picker can sometimes be very slow depending on the OS, but this is the first time that having the colors in real time makes the picker lagging. During my tests on Linux, I use Elementary OS, so I'm based on Ubuntu and I don't have any problem of slowdown. I'll have to make myself an Arch Linux environment as well to see that.

Oh yeah, It's a bug from the newest release of Electron, I suppose I have somes improvments to make, but I'm afraid that this feature won't be viable with future releases..

I see.

Just in case, is it a rather important feature, or is it something rather unimportant? So that I know if I should invest myself seriously in it...

No problem man, I'm glad to help. Your tool is incredibly helpful for a designer, it really is, I'm loving it and want to see it improve and grow.

Oh I almost talked about the HSL sliders hahaha, those are a must! Glat it's in the works!

Thank you! I didn't think that my tool could be so useful, I developed it for my little designer habits, I'm glad it's useful to others as well!

And thanks for supporting AppImage, it's the best way to use software on Linux in my opinion. The more support it gets and standard it becomes, the better.

BTW, do you support AppImageUpdate?

Yeah I know that Linux has a lot of ways to install, recently I made Colorpicker available on snapcraft but I still have some small problems with the integration of the picker on it. For AppImage, I don't have an update system yet. I plan to add a modal that informs about a new update. Unfortunately for Macos, I have to have a paid developer account and on Windows, I have to pay a provider or a very expensive license to be able to add an automatic update system... I need to inquire for Linux to see what can be done!

I've created somes issues just to track the progress

I saw, nice!

Okay, I'll let a try

Please be careful as it has the chance to break your macOS haha, give it a try in a VM first, play around with it.

Thanks for the informations! I'm going to look at all this to make an interface as close as possible to this model.

I need to make a important correction! The GNOME/GTK teams will be moving to GTK4 not 3!

Hmm, I don't know if I will be able to detect if these different buttons have to be disabled or not independently from the others by the OS. In the worst case, I would put an option to enable or disable these different buttons.

I simple option to disable them would suffice really.

Oh okay! Since I'll change this interface, it's not really a problem. But for the moment I'll add this for the next update, see #67

Ahah yeah, this is my favorite framework for javascript! I'm really happy with the evolution and the active follow-up it benefits from.

:+1:

Hmm interesting.. I know the picker can sometimes be very slow depending on the OS, but this is the first time that having the colors in real time makes the picker lagging. During my tests on Linux, I use Elementary OS, so I'm based on Ubuntu and I don't have any problem of slowdown. I'll have to make myself an Arch Linux environment as well to see that.

ElementaryOS is one of the least standardized Linux distros, not great for development testing. They have their own unique way of implementing things, their own apps, etc.

Installing vanilla Arch Linux may be very troublesome if you never installed it before, if you struggle and or want to save time, you can install EndeavourOS instead, great distro, easy to install and is based on Arch Linux and respects it's vanilla aspects, theoretically, everything you can do on vanilla Arch Linux you can also do on EndeavourOS.

I also recommend Ubuntu LTS as a test bed. Stable, popular, ample support, easy to use.

Just in case, is it a rather important feature, or is it something rather unimportant? So that I know if I should invest myself seriously in it...

Well, it's up to you. For me it's a bit broken, I can use it but when I drag, there are "ghosts" of the dragging handles..

I think you should focus on improving the launch time first, it takes like 20 seconds for the app to open for me.

Thank you! I didn't think that my tool could be so useful, I developed it for my little designer habits, I'm glad it's useful to others as well!

:+1:

Yeah I know that Linux has a lot of ways to install, recently I made Colorpicker available on snapcraft but I still have some small problems with the integration of the picker on it. For AppImage, I don't have an update system yet. I plan to add a modal that informs about a new update. Unfortunately for Macos, I have to have a paid developer account and on Windows, I have to pay a provider or a very expensive license to be able to add an automatic update system... I need to inquire for Linux to see what can be done!

Oh I'm not talking about CI and or a full update system.

That's why I asked if you can support AppImageUpdate, a user can just drag your app inside AppImageUpdate and it updates the app automatically. I'm just asking if you plan to support it. No need to worry about other install methods that much, I recommend that you focus on AppImage, and if possible, support the update feature through AppImageUpdate. Later on if people demmand DEBs, RPMs, Flatpaks, etc, you can slowly roll them out. But I love AppImage and anyone on any distro can use that, and if developers supports AppImageUpdate, anyone can update their apps.

Please be careful as it has the chance to break your macOS haha, give it a try in a VM first, play around with it.

Ahah okay!

I need to make a important correction! The GNOME/GTK teams will be moving to GTK4 not 3!

👍

ElementaryOS is one of the least standardized Linux distros, not great for development testing. They have their own unique way of implementing things, their own apps, etc.

Installing vanilla Arch Linux may be very troublesome if you never installed it before, if you struggle and or want to save time, you can install EndeavourOS instead, great distro, easy to install and is based on Arch Linux and respects it's vanilla aspects, theoretically, everything you can do on vanilla Arch Linux you can also do on EndeavourOS.

I also recommend Ubuntu LTS as a test bed. Stable, popular, ample support, easy to use.

yeah I know, I had installed it to test the interface and since then I haven't changed, but I'll probably change soon for the development indeed!

Well, it's up to you. For me it's a bit broken, I can use it but when I drag, there are "ghosts" of the dragging handles..

I think you should focus on improving the launch time first, it takes like 20 seconds for the app to open for me.

Yeah I see, I'll do what I can for these!

Oh I'm not talking about CI and or a full update system.

That's why I asked if you can support AppImageUpdate, a user can just drag your app inside AppImageUpdate and it updates the app automatically. I'm just asking if you plan to support it. No need to worry about other install methods that much, I recommend that you focus on AppImage, and if possible, support the update feature through AppImageUpdate. Later on if people demmand DEBs, RPMs, Flatpaks, etc, you can slowly roll them out. But I love AppImage and anyone on any distro can use that, and if developers supports AppImageUpdate, anyone can update their apps.

Okay! I'll look at it while changing the distribution, so it would be a good thing indeed to be able to update the appimage.

Toinane / colorpicker

[Bug] README.md images and GIFs are broken #65