REXPaint > Everything REXPaint

Option for making palette (like CTRL+SHIFT+E) but for a clipboard contents

(1/3) > >>

gumix:
Hi Kyzrati,
Like in the title, this is just suggestion, low-priority, currently I simply copy-paste into new image then do the regular CTRL+SHIFT+E, usually using in combination with the killer 'D'-depth.

Fun fact, I run RP on ubuntu (with wine), there is a key-stroke collision with gnome's text input. By default pressing CTRL+SHIFT+E starts to produce emoticons. Remapping it to use <Super> modifier additionally fixes the problem.
gsettings set org.freedesktop.ibus.panel.emoji hotkey $'[\'<Control><Super><Shift>e\']'

Kyzrati:

--- Quote from: gumix on December 06, 2022, 02:35:52 AM ---Hi Kyzrati,
Like in the title, this is just suggestion, low-priority, currently I simply copy-paste into new image then do the regular CTRL+SHIFT+E, usually using in combination with the killer 'D'-depth.

--- End quote ---
Hey gumix, so you're talking about making a palette from clipboard contents? I'd say that might be just a bit too specific for something I'd want to add as a feature, even in 2.0. Unless it turns out it's easy enough to add via a new menu system and doesn't add too much clutter, but in general I think it might have too few use cases and the alternative to achieve this effect isn't very onerous compared to how often anyone might use it (as you say, using an empty image as an intermediary).

I guess I could ask more about how this sort of need fits into your workflow, like how frequently and why you need to do this.


--- Quote from: gumix on December 06, 2022, 02:35:52 AM ---Fun fact, I run RP on ubuntu (with wine), there is a key-stroke collision with gnome's text input. By default pressing CTRL+SHIFT+E starts to produce emoticons. Remapping it to use <Super> modifier additionally fixes the problem.
gsettings set org.freedesktop.ibus.panel.emoji hotkey $'[\'<Control><Super><Shift>e\']'

--- End quote ---
Aw, too bad REXPaint doesn't have the same remapping support that I added for Cogmind, something I should do eventually... (pretty time-consuming and error-prone though, not a great solution)

At least 2.0 would likely have a more in-depth menu system that also allows people to have alternatives to so many hotkeys.

gumix:
Hi, yes your're probably right it is quite specific to my work flow. It turned to be very useful during retouching (refreshing) sprites though.
Eg, sprite makes use of many similar colors, 'violets' over its shoes and 'magentas' for the shirt. They are not easily distinguishable by eye especially over contrasting background but I would like not to mess them together. So while retouching one part, I select it, make palette for it retouch it using generated palette of a very few colors, then I can proceed to another part.

Forget it Kyzrati, it's so specific, but it took some time to realize that :)

Kyzrati:
Okay gotcha, was interesting in learning just what you were doing here. Reuse of the same colors is one reason I implemented (and love love love) the standard right-click dropper function to grab any glyph and/or foreground/background color, for when adjusting a piece but want to make sure it's using the same small set of colors.

So what I do in your case here would be to use my left hand to hit 'g' (and 'b' if necessary) to toggle off the bits I don't need, then can right-click on stuff and reuse it elsewhere. Very fast retouching that way, without having to move the cursor all the way over to the palette etc. The main drawback in comparison would be that you don't simultaneously see an organized representation of the limited range of palette options in a given sprite/area, but in my case they're pretty obvious anyway. I do a lot of grabbing and dropping colors (and glyphs) to make adjustments.

gumix:
I do agree, this is also the primary weapon in my case.
The problem was with multi layered assets, where fg/bk colors are not so easy to pick without seeing it / knowing which layer that cells is located at.

Navigation

[0] Message Index

[#] Next page