Cross platform pixel art editor
mkatch / apricot Goto Github PK
View Code? Open in Web Editor NEWCross platform pixel art editor
Cross platform pixel art editor
The Project contains only single Canvas element. It should be composed of multiple animation frames, each having it's separate layer set.
Provide 16x16 icons for each tool Toolbox
.
Extend Tool
to create a tool for drawing ellipses. It wil suffice for not for it to only draw hollow ellipses. It seems that ellipse tool will have very similar controls to rectangle tool so consider using inheritance.
You can assume that painter
in Tool::paint()
comes properly initialized with pen and color. Also we don't have any toolbox widget so just instatniate the tool in main
for testing purposes for the time being.
We need menu bar with items such as: new project
, save project
etc.
The image should zoom relative to the center of the view.
The drag tool is not receiving mouse move events. The QGraphicsView child of ToolActionArea seems to intercept it somehow. There are much likely issues with other events too.
While constructing the bounding rect of operations performed, Painter
does not take into account the pen size. I added a hot fix for drawRect
in 379a72a because I needed it, but it has to be checked for correctness. The bounding rect should fit the changed pixels as tight as possible.
Possibly helpful: Coordinate System of QPainter. Also please note that we will never use anti-aliasing in Painter
.
The stylesheet for QDoc generated documentation is making it unreadable. Please change if possible.
CanvasView
now only displays a given Canvas
. It should display a whole AnimationFrame
thus becoming AnimationFrameView
. This class should also be moved to the view
module.
The ToolActionArea
is in a draft form. The event handling and dispatching has to be carefully thought through and fixed. Also it should allow the tools to actually draw on the underlying frame's active layer.
Every site genereted by QDoc for our application has this bullet list with first enrty 'qdoc-index' and the title of current page as the second entry. Please remove it if posible as it serves no purpose.
This is another iteration of Painter
and Layer
interaction. The newPainter
method of Layer
should be replaced by beginPainting
and there should be also an endPainting
method that destroys the painter returned by beginPainting
. Similar to what was described in comments section of #7 but ditched eventually.
The layer should also emit a signal in endPainting
, notifying about the changed rectangle. There should also be argument-less version of the signal.
CanvasView
should display checker tiles in place of transparent canvas parts โ just like in many popular raster image editors. The size of tiles should be independent of the zoom factor. By default the tiles sould be gray and white but it should be configurable.
Extend Tool
to create a tool drawing rectangles. It will suffice for now if it only draws hollow rectangles.
Modifier keys should affect the way a rectangle is laid out. For example Ctrl
could fix the rectangle to square, Shift
could trigger "center to corner" mode instead of "corner to corner" (if you know what I mean). Use your imagination. Whe modifier keys chosen are not important, this can always be changed.
You can assume that painter
in Tool::paint()
comes properly initialized with pen and color. Also we don't have any toolbox widget so just instatniate the tool in main
for testing purposes for the time being.
we need to store somehow, somewhere project (drawings, palette etc.)
The items in AnimationView
seem to be laid out alright relative to each other, bt their position in the view seems to break on certain events.
At the bottom of application window there should be a horizontal list displaying frame thumbnails allowing for addition, removal, reordering, and (multi)selection of animation frames.
The Canvas
class represents the most basic editable image in Apricot. It should come along with basic primitive drawing routines. Most prefferable would be an accompanying painter class, much like QPainter
, that manipulates the canvas' pixel data. The Tool
class specifications would then be getting the bound painter to apply their results to the canvas.
Some requirements to consider:
It would be best if any person contributing would meet with me personally to talk about some subtleties and what I've already considered.
The .hpp and .cpp files implementing classes were renamed from plainlowercase to PascalCase. This has made a lot of people very angry and been widely regarded as a bad move. Please revert.
RubberTool
seems like it's not commiting and that it only draws over some parts of active canvas.
My guess is that this may be caused by the RubberTool
itself or by caching in AnimationFrameView
. I advise @mrhania and @hessonit both look at the issue and try to determine if the problem is not in their parts of code.
Right now Layer
holds a single Canvas
internally. It should hold another one for buffering tool actions. Therefore Layer
should have beginPaint
and endPaint
methods. The former gives a Painter
bound to the back buffer, and the latter applies the changes to front buffer. After calling endPaint
, the painter becomes invalid.
Right now various components of the app are stitched together in main
. Move it to Application and MainWindow โ as it ought to be.
Out application obviously needs some undo/redo mechanism. It is a component that interleaves with the major part of the app so it is important to establish it as soon as possible.
The history mechanism should have minimum impact on other components. Preferably is should store abstract actions that can perform virtually anything. When designing, think about such use-cases as: painting, layer and frame management, image resizing.
It would be perfect if this issue resulted in a wiki page roughly describing the undo/redeo system.
This arised when documenting CanvasView
. It has a property called scale
with a getter method scale()
, obviously. But the class also has a method scale(qreal)
which multiplies the existing scale by a given factor. QDoc sees scale(qreal)
as another access method.
The problem is that the noun and verb forms of the word scale are the same. I would like to preserve the names and the convenience of Q_PROPERTY
macro but prevent QDoc from treating scale(qreal)
as access method as this makes it impossible to document.
Feel free to pick on that one in spare time. Is it even possible?
The project is not documented at all. Learn QDoc and add inline documentation everywhere necessary.
In the left dock area of MainWindow
are ColorPicker
and LayerView
. For unknown reason, ColorPicker
expands beyond what it really needs and squishes LayerView
. What makes it more strange is that the sizes can be manually adjusted by the user when the app is running, so there seem to be no constraints forcing such initial layout.
The QDoc configuration files are located in the application's root folder. All documentation related files should reside in doc
folder.
Currently qdoc
is configured to output the documentation in HTML format to doc
catalog. Make sure that git ignores them if they are still saved in doc
or change the output directory.
Project
should contain palette and also there should be a palette widget that allows for addig, removing and changing colors in the palette. The palette colors do not have to be coupled with pixels in the image. That would be a nice feature, but only if we had more time.
We wanto to have a custom, embedded HSL color picker widget. This component is stand-alone, not dependent of the other parts of the app. Here are some initial proposed designs:
The hex display should be editable and be permissive about the initial '#' when pasted into. When '#' is not present or there is '&' instead, it should add '#' by itself... you get the idea.
Also the textboxes to the right of the sliders should be editable, but in a standard textbox there pressing up or down key takes you to another line (or to the beginning/end of the current line if there aren't eny). We want to replace that behaviour for the up/down keys to increment/decrement the value.
Hue has domain 0-360, saturation and lightness have domain 0-100.
Please comment and suggest improvements. My personal favourite is number 3.
PencilTool
and RubberTool
place a dot at every mouse move event. Event at moderate speeds the dots are too sparse so they should be connected with lines. A series of connected dots shall be committed on mouse button release.
AnimationFrameView
should rebuild it's onion skin frame structure, or whatever it holds for displaying onion skin, when either onionSkinForward
or onionSkinBackward
property changes.
Canvas
is a surface one can paint on. It should use palettized storage. Palettes should be sharable between canvases. We do not support alpha channel, just a special palette entry for completely transparent. It should be convertible to QPixmap
or QImage
for display (determine which will give better performance or choose randomly and we will optimize later).
Canvas
, by design, sould not have any reference to the application model structure. This may sound a little unclear so, as a rule of thumb, avoid referencing any QObject
derived classes when implementing Canvas
. Particulary it should not be aware of the existance of Project
, AnimationFrame
and Layer
.
The canvas itself should not provide any functionality beyond creation and resizing (not even pixel read acces is necessary atm.) any pixel manipulation should be done via Painter
.
Painter
is a lightweight class that provides routines to draw on a canvas. It should be allowed to be passed by value. It must not be copyable but it has to be movable. It will suffice to make it able to put single pixels. It should not be possible to change dimensions of Canvas
via Painter
.
Temporarily, at the time of writing, Painter
has a method load
. It exists for testing purposes in early stages of development. Please preserve it's functionality.
AnimationFrameView
should be able to display a configurable amount of frames back and ahead of the currently set frame. Onion skinning on Wikipedia.
Extend Tool
to create a line drawing tool. The tool should draw polygon edges with vertices at user's consecutive clicks.
The modifier keys should affect the way a line is laid out. For example Ctrl
could fix the line to snap to certain angles. Use your imagination. The modifier keys chosen are not important as this can always be changed.
You can assume that painter
in Tool::paint()
comes properly initialized with pen and color. Also we don't have any toolbox widget so just instatniate the tool in main
for testing purposes for the time being.
We should have a toolbox on the left side of the application window. A toolbox is a 2-column vertical bar with tool icons that allow the user to switch between tools. Also the toolbox should also hold the colors currently painted with and the size of the pen.sketch
This enhancement needs adding some appearance information to Tool
. This could be done by expanding the Tool
class with additional properties and methods. But I would personally prefer it stayed separated from it. This can be achieved by creating a wrapper like ToolBoxItem
or something, which internally held a Tool
and appearance information.
Appearance information includes, obviously, an icon that appears in toolbox. But also a tooltip, that appears when the user holdt the cursor over the icon. We could possibly also have some tool grouping which also counts as appearance information (or layout information). Like for example there would be a hollow rect tool and filled rect tool and the user would choose either of them by clicking an aggregating tool icon which then expand context-menu style and shows the two tools. (I don't think there would be separate tool for filled and hollow rect but you get the idea). It will suffice to just implement the icons atm.
At the right side of the application there should be vertical list displaying layer thumbnails of selected animation frame, allowing the user to add, remove and reorder the layers.
Please wait for #11 to close (or to be in an intermediate stage) see how it's implemented, so we have coherent arhitecture. I'm posting this issue right now for the asignee to prepare for it. I'll try to finish #11 as soon as possible.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.