Comments (9)
Awesome, great. I can start with a draft PR and we can continue iterating there.
from satty.
great idea! have you seen #30? We should add default colour and default size there!
would this already solve your use case?
Currently there is no such notion as "state". Satty is basically stateless as all config is passed to it at startup. The configuration file in #30 would be a way to not only describe the initial state but - when writable - also to persist state. Imho that might be the best approach.
We should avoid unpredictable options, i.e. specifying A but getting B...
from satty.
would this already solve your use case?
not entirely since what I'd really like is for the editor to remember the last setting used. This is something that other tools like flameshot do.
Having a config file to set the color and size would partially help, but it won't be a nice UX since it'd be very painful having to go to that file each time I want to change them.
from satty.
I think the way forward will be to implement the configuration file as a way of persisting state and then use one of the toml editor crates to edit that file when the remember last state option is set
from satty.
I think the way forward will be to implement the configuration file as a way of persisting state and then use one of the toml editor crates to edit that file when the remember last state option is set
yes sure, this makes sense. How do you prefer to move forward about this? Can I help #30 to move forward somehow?
from satty.
I thought about this again and had some specific doubts about us touching the users config file and also systems where the configuration file is immutable. So I asked the NixOS community over at Reddit [0] and the answers are very useful .. let me summarise
- we should never touch the users config file - that's sacred userland
- we should follow the xdg standards, there is a place for application state
- it would be easier for NixOS if the user config would be immutable to the program, but if it's not that wouldn't be deal breaker either
For us that boils down to:
-
config and state are two different things - contrary to what i said above
-
we can implement state without worrying about the config file and even before implementing #30
-
the state for should reside in it's appropriate folder and can be anything - probably json
from satty.
I would prefer the following behaviour/spec
- we introduce a flag that enables satty to remember it's last state. if the flag is not specified, it shall behave as it does until now
- If the flag is specified we do:
- try to open a json file from the xdg specified folder
- load the state from there
- use the last selected tool from there
- update the file on every change of state
- the state includes: selected tool, selected colour, custom colour and selected size
from satty.
Awesome, great. I can start with a draft PR and we can continue iterating there.
great, looking forward!
from satty.
I implemented config file handling in #38. It pushes the config into a global variable called APP_STATE
that is a relm4 SHARED_STATE
. I do think that this might also be a good approach for tracking the app state (selected tools, colors, sizes etc)
from satty.
Related Issues (20)
- [FEATURE] Resizing the output HOT 3
- Ellipse is missing? HOT 1
- Support the `ppm` image format HOT 6
- [Feature Request] Option to Disable Notification HOT 4
- [feature] add 1:1 scale shortcut in the toolbar to scale the image for uniform size reference HOT 2
- [feature] style: allow to load extra css file for customize HOT 2
- [Bug] The blur tool doesn't blur the right part of the image if the window's size is changed HOT 9
- [Feature Request] Start multiple instances of satty HOT 1
- [feature] link upload and/or additional buttons with custom functions HOT 1
- [feature] low res pixel blur HOT 1
- [bug] using the chrono formatting options for file name causes satty to hang and crash on save HOT 1
- [feature] Add option to choose location of where to save the file HOT 4
- [feature] Allow for pan and zoom with the mouse/trackpad to move the (infinite) canvas around HOT 3
- Input smoothing / post-processing HOT 3
- [Bug] clipboard cleared when satty closed HOT 9
- "No such file..." error on copy to clipboard HOT 1
- Add UI element to change font size HOT 6
- Release error: v0.14.0 is not released publicly HOT 1
- [Bug]: Gdk-Message Error 22 (Invalid argument) dispatching to Wayland display.
- Hyprland keybinding is not working!
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from satty.