BinarySerializer shouldn't be used, due to security risk. Therefore it should be replaced with a custom serializer.

Useful to get back to work on drawing started previously.

Implement the extension parsers into PixiEditor's export/import window

At the moment PixiEditor crashes when trying to open a invalid/corrupted file

It would be good if it would display a error message instead

Currently Circle tool is making ellipses, but not correct for all sizes, they are jumping in X or Y axis from time to time. To reproduce this behavior.

We will need to replace the ToolType enum with something that can be edited at runtime since we want to give extensions the ability to add new custom tools

Currently, a selected area can only be moved. Most image editors let you move, resize, and rotate the selected area.

A selection should have four anchors on its corners that can be dragged to resize an area. Each side should also have an anchor used to stretch/squish the area in one direction. Holding shift while dragging should enable forced proportions. When hovering close to selection borders cursor should change showing that the area can be rotated. In addition to that, it would be nice to have a movable "origin" anchor that serves as an axis for rotation.

Describe as detailed as possible when it happens
I cloned the repository and have built it for the first time. And I got a bunch of warnings. In my opinion, those warnings:

1. Give the contributor the possibility to write code with even more warnings
2. Make harder for the contributor to become ensure that the change will not break anything
3. Indicate to possible bugs, just like failed tests

Describe what you tried to do in order to fix it
Firstly, I tried not to make even more warnings. I can try to fix all of them by myself, but I think it is better to create the issue first in order to:

1. Ask for information about env-related issues, which are raised only on my machine
2. Not to clog the pull-request related to the other issue, which is under code review now.
3. Clearly define the scope of the changes

Include screenshots of error

Additional context
Maybe, some of the warnings are related to my local environment and may be fixed without changing the code. If so, please write to me about it.

Implement a new popup that can import and manage extensions.

Extensions should be located in a folder in Local App Data or the Program Files

ExtensionManager.LoadExtension() can be used to load an extension

LineTool already contains Caps settings, but it doesn't work very well. The goal is to make round caps work regardless of line size;

The current logo is nice, however, we would gladly use something fresh.

• Dimensions should be at least 512x512 pixels.
• If we choose your logo, you should send us a PNG and a work file (.PSD, .AI, etc.)

By submitting you agree to give us a full right to all files you send.

Tool keys should work similarly to other drawing software:

• When a key is pressed shortly the corresponding tool should be selected (this is the current behavior)
• When a key is held down the corresponding tool should be selected only while it is held. Upon releasing the key the tool should automatically be switched to a previously used one. (to be implemented)

Is your feature request related to a problem? Please describe.
The main problem that the project is open-source, so a lot of people can contribute to the project. Each of them may have a unique style of writing code, so the repository may become the mixin of those styles. I think, it is better to have only one strictly defined style, which is close to the style of repo-owner.

Describe the solution you'd like
Add the static code analyzer such as StyleCop.Analyzers for every project in the repo. Add the Custom.ruleset file which defines the style of code in the repo. In all places where the style is not corresponding - the compile-time warning should be added (IDE will highlight it too). Since the reference to the analyzer and ruleset file should be placed in every project - it is better to create Directory.build.props file and move the reference there.

Describe alternatives you've considered
The other analyzers may be used. The main idea to have compile-time warnings about the style during the build in order to check them during Github Actions checks and manual code review

Additional context
Maybe, the usage of the analyzer is placed somewhere already and I simply havent found it. But as far as I found - all checks are done on the IDE-highlighting level only. The problem here is the IDEs may have different settings for each contributor.

Is your feature request related to a problem? Please describe.
Using tool Settings requires to manually cast object to the requested type, this is not comfortable to use and might make it more fragile to errors.

Describe the solution you'd like
Change Setting class to Setting<T> where T is a value type of setting. Currently to get ToolSize setting we need to do (int) Toolbar.GetSetting("ToolSize").Value but something like Toolbar.GetSetting<int>("ToolSize").Value would be better.

bleach is tasty

Here is a comment part about Flood Fill from Reddit post

FloodFill

You make a deep copy of the layer you flood fill on. That's an expensive operation right of the bat.

You use GetPixel and SetPixel on the clone to keep track of what pixels you have changed. That's a really expensive way of doing it. Consider replacing it with a bool[,] array with the same size as the layer. Then you can remove the clone and just sample from the original layer.

Consider checking if you've already seen a pixel before you put it into the stack. You could use the bool[,] array to keep track of pixels you've already placed into the stack and then check it before you place neighboring pixel Coordinates into the stack. It keeps the stack smaller and you have to do those checks later anyway.

Change the order of the neighbors you put into the stack. Adding x + 1 and x - 1 last, makes your data access a little more linear which increases the chances of the data being in the cache.

Extensions should be able to add their own Menu Items to the bar at the top but restricted to existing menus so
File, Edit, Select, Document, Help and two new ones Filters, Extensions

The requested menu items are stored in extension.MenuItems[0].Key and look like this File/Test1, the value of the KeyValuePair is which file and method is gonna be called when the item is clicked

Menu Item can be executed by using extension.ExecuteMenuItem(extension.MenuItems[0].Value)

The config file for this would look something like this

<Menu Name="File">
	<MenuItem Click="./Main.lua:Test1">Test1</MenuItem>
	<MenuItem Click="./Main.lua:Test2">Test2</MenuItem>
</Menu>

Add a class for interacting with the currently open bitmap. Use ExtensionManager.RegisterGlobal() to register a class.
Classes that are gonna be used in lua need to have the [MoonSharpUserData] attribute

The class could look something like this

[MoonSharpUserData]
class LuaBitmapEditor
{
	public void SetPixel(int x, int y, byte r, byte g, byte b, byte a)
	{
		BitmapManager.activeBitmap.SetPixel(x, y, Color.FromArgb(a, r, g, b));
	}
}

On application start, ExtensionManager.RegisterGlobal<LuaBitmapEditor>("Bitmap") has to be called

A lua script would then be able to set a pixel like this

function Test()
	Bitmap.SetPixel(2, 2, 3, 255, 80, 90, 255);
end

Classes for interacting with lua should be put in Models/ExtensionsModule/

When typing layer name, shortcuts get executed.

UI on smaller screens is not scaling well. Some features are even inaccessible.

Currently ViewModelMain is a big blob of code. It should be chopped into smaller sub-ViewModels.

Is your feature request related to a problem? Please describe.
There is already a Zoom tool that provides an alternative to the scroll wheel, allowing stylus/digital pen to zoom. Currently moving viewport is done by Shift + Mouse left button, there should be a tool that allows doing that just using the mouse.

Describe the solution you'd like
Move Viewport Tool that controls viewport position.

Additional context
Pressing the scroll wheel should automatically activate the move viewport tool

Is your feature request related to a problem? Please describe.
There is no way to zoom when using a graphic tablet.

Describe the solution you'd like
A zoom tool that would work similar to the one in photoshop or clip studio paint:
Left-click - zoom in
Alt + Left-click - zoom out
Drag right with left mouse button pressed - zoom in
Drag left with left mouse button pressed - zoom out

Describe alternatives you've considered
Keyboard shortcuts to zoom in/out would be good too

This is a major thing to implement in PixiEditor.

Animation pane is a system, that will allow the user to create animations from sprites. It should consist of:

• Frames panel
• Frames settings (speed)
• Onion skinning
• etc.

Is your feature request related to a problem? Please describe.
At the moment implementation of whether image changed, since the last edit is very naive, it works on Bitmap and Layer events, it does not know about the real state of the image. The perfect solution would be a hash comparison, this way we would know if the bitmap really changed.

Describe the solution you'd like
A class or extension that would calculate the hash of the final bitmap and use it to check if the program needs to show "Document was modified. Do you want to save changes?" dialog.

Since it will be only calculated on save and application close event, it doesn't need to blazingly fast, but it should be fast enough not to cause a visible delay between clicking the exit button and showing the unsaved changes dialog.

Describe as detailed as possible when it happens
Program running under user privileges crashes while downloading an update to a folder, which requires admin.

Describe what you tried to do in order to fix it
Prompt for admin privileges

Currently, users can change the size of the tool using UI, but we should add a shortcut to improve the workflow. In many popular graphics editing software square brackets are used ('[' and ']').

Tool size is held in Toolbar (BasicToolbar). You should create a new command that will access it and change the size.
Shortcuts are initialized in ViewModelMain.

Describe as detailed as possible when it happens
Shortcuts don't work randomly.

Describe what you tried to do in order to fix it
Always working shortcuts.

Currently only Pen Tool is affected by Tool Size. It is essential to add this to shapes too.

Describe as detailed as possible when it happens
While having unsaved changes, click the "Save" or "Save As..." option (or using shortcuts) and closing the dialogs (without actually saving the file) program marks changes as saved, so closing the program does not trigger "Are you sure?" dialog.

Potential fix*
The fastest solution would be to just check if the file was saved successfully, and set the value of _unsavedDocumentModified in ViewModelMain corresponding to the result.

Trying to resize the canvas causes a stackoverflow exception. To replicate: make a new 256x219 canvas, open resize canvas menu, type 246 in the width field. This only happens when preserve aspect ratio is checked.

Undo should support deleting and creating layers.

Memory leak

on bigger canvas sizes. Caused by storing bitmaps in UndoManager. Possible fix: Storing undo list on disk. I have already reduced size of individual layer by removing Images from them, and generating them on a fly.

CTRL + D is widely used as "Duplicate" not "Deselect", so instead CTRL + J, we should use CTRL + D, and deselect should be CTRL + SHIFT + A

Overview

There should be an option to enable grid lines, which will show over the canvas, to improve the visibility of individual pixels.

Implementation idea

User control, which will sit inside the canvas.

Additional things

• Menu item to enable/disable grid lines
• Shortcut (Maybe Ctrl + ')

It's a fairly minor issue but it annoyed me more times than it should've, so I'll document it here. To replicate: have at least two layers present, write a new value in the opacity field, click on the second layer (without clicking anywhere else/removing focus from textbox). The new opacity does not get applied.

Currently you can only edit one document at a time, there should be a tab user control where the user can select on what Document he wants to work on

Describe as detailed as possible when it happens
On smaller screens, UI overflows, same as canvas. (Swatches and covers the taskbar).

Is your feature request related to a problem? Please describe.
Pixel perfect is an option that is extremely helpful to pixel-art artists.

Describe the solution you'd like
Pixel perfect algorithm that is toggled in Pen Tool Toolbar.

1. Using the pen tool draw a line and release the mouse button below the bottom of the screen onto the windows task bar.
2. Hold the mouse button down to the right of and off the canvas and drag the mouse onto the canvas.

A diagonal line appears between where you exited the canvas at the bottom and where you entered the canvas on the right. In the image below the green pixel is where I exited the canvas and released the mouse button and the red pixel is where I entered the canvas.

When the canvas is zoomed out (fits into the window completely) it can't be moved past window borders. While it does make some sense, in practice it is annoying because sometimes it doesn't let you put the canvas in a comfortable position. This issue affects me specifically because my tablet area doesn't cover the whole screen, meaning I have to move canvas sometimes to reach areas even though they are visible.

Describe the solution you'd like
Let us move canvas wherever we want

At the moment, fast mouse movements might cause gaps between pixels, so PenTool is a LineTool, and it fills gaps with a line, this is okay for small gaps, but for bigger ones, done one bigger dimension it doesn't look natural. Improving overall app performance might help with that, but still, gaps will remain. We need to write some kind of supporter, that will fill gaps more naturally.

A potential solution might be to make round line caps, gaps will fill more naturally

well, the updater doesn't really work on the production and I screwed up zip building in CD.
But hey, as long as it will work in next release nobody will notice

Description

Draw a beautiful pixel art in PixiEditor so we can display it on the main page (README.md). Everyone visiting the repository (and website in the future) will see your work in the first place!

Requirements

• A full screenshot with software open, not an exported image. Check current README for reference.
• .pixi file
• Image must be drawn in PixiEditor

By submitting you agree to give us a full right to all files you send.

Code still need unit tests. Tests project is already included in solution. All Models and ViewModels needs to be covered.

Currently, clipboard doesn't have undo support, adding it is quite important.

Trying to undo 'Cut' results in crash

The issue
When moving and clicking at the same time mouseDown event sometimes doesn't fire fast enough, meaning mouseMove event might fire before it. Since the mouse is already pressed down when mouseMove fires this check passes and zoom tool gets executed updating viewport zoom (ZoomPercentageChanged). Since mouseDown event has yet to fire at this point SetClickValues function has yet to be called as well, meaning that (ZoomPercentageChanged) function used the old value of ClickScale. This causes a jump, similar to one cause by releasing mouse button outside viewport.

A hacky fix
ZoomPercentageChanged function already executes SetClickValues function when percentage == 100. We could add a flag, something like "mouseWasUp", and add another check to execute SetClickValues if mouseWasUp is true.

A more proper fix
I feel like it would make more sense to track mouse state manually based on the events instead of relying on System.Windows.Input.Mouse.LeftButton. This will ensure mouse state is always in sync with events