-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Color palette cant and wont be loaded (File could not be opened) #189
Comments
Hi, which version did you compile? There were palette file loading issues in the following commit range: c909184..ed0c7ab. If your version is inside this range, then you will have to update to a newer version. In which directory did you install Gpick? If installation directory is not listed in View->Layout menu seems to be broken. I am currently investigating and I will fix as soon as possible. |
The folder just states GPick 2.6. It was the latest stable version available. It was my first own compiled program, although i'm on Linux for more than a decade. It's Debian, i'm used to "old but stable". ;) I compiled it for two paths:
Both had the problems. 'XDG_DATA_DIRS' is usually being set automatically and always sets '/home/user/.local/share'. The error message suggests those files being expected in 'XDG_DATA_HOME'. I'm currently using it with linked files and importing/exporting my table. Looking forward for a working version. Best regards. |
Do not use temporary string in g_object_set_data_full() call. Issue #189.
View->Layout menu should be fixed now. Does the directory $XDG_DATA_HOME/gpick/ exist? And if it does, are Gpick files installed there? I can reproduce *.lua file load errors by creating empty /home/user/.local/share/gpick/ directory. This causes problems, because Gpick simply selects first data path containing gpick/ subdirectory by checking XDG_DATA_HOME and all directories in XDG_DATA_DIRS. If XDG_DATA_HOME environment variable is not set, then it defaults to /home/user/.local/share/ and this path is selected because subdirectory gpick/ exists, causing following error on startup:
I can not reproduce your palette file loading problem. Please update to master and try again. Also, please create a random palette, save and send the file to me so that I could inspect it and make sure that files are saved correctly. |
The releases still states 0.2.6 from the 23 Dec 2020. So i guess i have to 'git clone' to get the current version? Gotta mention, it's really simple. I'll give it a try. |
I can not test it. 'checkinstall' gives the following error:
The file is there, the permissions are right. I don't know why it throws the error. I have to use 'checkinstall' because i don't want to mess up my system. |
This is my error:
This is the release 2.6. |
You can, but do not have to use I tried using checkinstall, and the following commands successfully produced a *.deb file:
So I have no idea why it fails for you. Does directory /path/to/user/.data/gpick/ exist? Is it empty? Or does it contain *.lua, *.txt and *.png files? |
Now that you mention it... Thats correct. Hm. Tested it again. Deleted the .data gpick directory and the errors went away. Maybe it was the older Debian version, which created it again. Ah! I just remembered and got it. I did create the .data gpick, because i wanted to place my color palette in there and did so! |
That's what i get: https://asciinema.org/a/rYlwi0FFTuFDNrqHnZb9MYgJl I did work with the 2.6 release package. Fakeroot didn't change anything. |
Validate data directory by checking for known file. Issue #189.
Hello.
I occasionally use Gpick and already "collected" some colors. Since the current Debian version had some problems, i downloaded the source and compiled it myself. The problems persist. Namely:
This made the error messages go away and the UI, except "view->layout", seems to work. Including html color values and names. It would be usable now, if it wouldn't deny to load its own created color palette. (File could not be opened) It won't load the older one either. It does import the exported colors from the "*.gpl" file.
Is there any hope, that this problem will be addressed in the near future?
The text was updated successfully, but these errors were encountered: