Coder Social home page Coder Social logo

apricot's Introduction

apricot

Cross platform pixel art editor

apricot's People

Contributors

hessonit avatar mkatch avatar

Stargazers

 avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

apricot's Issues

Add frame and layer support

The Project contains only single Canvas element. It should be composed of multiple animation frames, each having it's separate layer set.

Create ellipse tool

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.

Create menu bar

We need menu bar with items such as: new project, save project etc.

Fix event handling in ToolActionArea

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.

Adjust bounding rectangle constructed by Painter

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.

Enhance CanvasView

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.

Enhance ToolActionArea

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.

Make Layer signal changes

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.

Checkered background in CanvasView

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.

Create recangle tool

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.

Add serialization

we need to store somehow, somewhere project (drawings, palette etc.)

Add a widget for managing animation frames

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.

Investigate possible ways of implementing Canvas

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:

  • the canvas sould have palletized format (at least 256 colors),
  • should be displayable via Qt Quick,
  • should provide means to partially refresh it on screen.

It would be best if any person contributing would meet with me personally to talk about some subtleties and what I've already considered.

Rename the files back to lower case

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 acts weird

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.

Add double buffering to Layer

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.

Investigate ways to implement undo/redo

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.

Prevent QDoc from treating specific methods as property access methods

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?

Inline documentation

The project is not documented at all. Learn QDoc and add inline documentation everywhere necessary.

Color picker expands vertically more than it should

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.

Move all documentation related files to a separate folder

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.

Create palette model and widget

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.

Create color picker widget

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:

color-picker-1

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.

Implement basic Canvas and Painter

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.

Create line tool

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.

Create toolbox widget

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.

toolbox

Add a widget for managing layers

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.