Call for contributors for Fixture [ Qt5 based raster graphics editor ]

Fri Sep 21 18:17:17 BST 2018

On Fri, 21 Sep 2018 at 16:40, Jaroslaw Staniek <staniek at kde.org> wrote:

>
> On Fri, 21 Sep 2018 at 16:23, Scott Petrovic <scottpetrovic at gmail.com>
> wrote:
>
>> One thing that helps Krita is it has focus on who they are helping
>> (people that can draw and paint). Photoshop caters to a lot of different
>> industries - which is why it has 1,000 features built into it (which is
>> both good and bad). When you get feedback from people, they oftentimes
>> don't tell you important information about who they are. Are they graphic
>> designers, web designers, photographers, 3d texture artists, animators, or
>> maybe beginners just trying to get into basic image editing like cropping.
>> You need to find out who you are trying to help. Graphic designers don't
>> normally do painting and illustrations, and web designers don't usually do
>> animation. This is why pretty much everyone only uses 2-3% of all the
>> features in Photoshop. The rest of the features are just useless to them
>> and are UI clutter.
>>
>> Trying to do a 1:1 copy of Photoshop isn't a good direction. That program
>> has had 30 years to add a giant amount of features that have turned it into
>> the powerful/bloated software that it has become. As a UI/UX person, I
>> would focus on finding the people you want to help, learn about them, and
>> give them a product that they are excited about.
>>
>
> Practical thing is, I'd like to gently hear from the Krita community if
> they accept properly done "Photoshop" mode for Krita, perhaps at the build
> time and if possible go there. Krita has dozens of structures and GUI items
> you need but you do not want to re-implement them in coming years... This
> can be done right but has costs too for Krita so cost-benefit math needs to
> be done first.
>

Similar: Phase 5 and 6 from
https://github.com/eyeon/Fixture/blob/master/ROADMAP.md looks like a
business of Calligra from years 201x and it took many years to reach beta.
Whatever we implement, per rule of thumb it's 20%, then you have 80% of
work in tests.

Like Boud said, many features such as the lasso tool, you plan in earlier
phases would have to be reimplemented if you do not use variable color
spaces from day one, and then reimplemented again if you do not use tiles
instead of linear memory model from day one. And this is top of the
iceberg... Simple editing and viewing tools you list are a property of
advanced image viewers these days, very often even online and mobile ones.
So there's a lot to do to match good image viewer, not raster editor.

>
>>
>>
>> On Fri, Sep 21, 2018 at 7:10 AM Kuntal Majumder <zee at hellozee.me> wrote:
>>
>>> Hey,
>>>
>>>  ---- On Fri, 21 Sep 2018 16:28:41 +0530 Boudewijn Rempt <
>>> boud at valdyas.org> wrote ----
>>>  > Using QGraphicsItems for layers is not an approach that's going to
>>> work out.
>>>  > It will not perform, it will not allow you to go beyond 8 bits sRGB
>>> and it
>>>  > will take too much memory.
>>>  >
>>>  > If you insist on starting from scratch, and I understand the
>>> temptation, you
>>>  > should:
>>>  >
>>>  > * consider color management: you cannot do anything useful unless
>>> you
>>>  > understand color management. Check out littlecms and
>>> https://poynton.ca/
>>>  > ColorFAQ.html.
>>>  >
>>>  > * develop a structure for storing (including swapping), modifying
>>> and
>>>  > retrieving raster data. QGraphicsView actually is a tile engine, but
>>> you're
>>>  > not using it that way. Its level of maintenance in Qt is also low.
>>>  >
>>>  > * develop a system for undo/redo -- Krita uses Qt's system for that,
>>> but if
>>>  > you want to clone photoshop, you should consider using their system.
>>> There's a
>>>  > presentation from an Adobe engineer at a C++ conference in Moscow
>>> that should
>>>  > help you form an idea. But basically, every modification results in a
>>> shallow
>>>  > clone of the document. You will need this to clone photoshop's
>>> history brush.
>>>  > Google for it, I cannot find the presentation right now.
>>>  >
>>>  > Then you can start on implementing a real canvas and a tool system.
>>>
>>> Thanks for the pointers, at least I won't be clueless like before.
>>>
>>>  > I only remember you from https://phabricator.kde.org/T8198#132594 --
>>> did you
>>>  > post a patch for review and did I miss that?
>>>
>>> This is the one you reviewed https://phabricator.kde.org/D10202
>>>
>>> Thanks
>>> Kuntal M
>>>
>>>
>>>
>
> --
> regards, Jaroslaw Staniek
>
> KDE:
> : A world-wide network of software engineers, artists, writers, translators
> : and facilitators committed to Free Software development - http://kde.org
> KEXI:
> : A visual database apps builder - http://calligra.org/kexi
>   http://twitter.com/kexi_project https://facebook.com/kexi.project
> Qt Certified Specialist:
> : http://www.linkedin.com/in/jstaniek
>

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
KEXI:
: A visual database apps builder - http://calligra.org/kexi
  http://twitter.com/kexi_project https://facebook.com/kexi.project
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20180921/2ee4c78d/attachment.htm>