Roadmap discussion for 2.9 and 3.0

Sat Feb 22 01:59:33 UTC 2014

On Sat, Feb 22, 2014 at 12:21 AM, Erik Johansson <erik.johansson at fido.se>wrote:

> Just wanted to chip in on:
>
> """
>
>> * MDI interface (more than one document loaded in one window)
>>
>
> I would give this the top priority, because it's the single feature that
> has be merged before we go to 3.0 and will likely also need a lot of work.
> """
>
> Will this result in less memory/cpu usage when having multiple documents
> open?
>

I think so, resources would only be loaded once per process so you save
that.

>  Will the old way of one process per document still work?
>

You would still have a process per window. So as long as you have one
document open it should work like the old application.

> Is it possible to have a chrome like approach where each tab is a process?
>

If there was a single component that was crashing it might possible to
isolate it, but it's not feasible I think. Allthough I'm wondering if it
would be possible to check if it's possible to create a opengl canvas in
another process before crashing the main application.

> As Krita still ain't rock solid. LOADS better than some months ago and I
> guess it will be even more stable when 3.0 hits but it would still s**k for
> all open documents to crash because one of them bugs out. Just wanted this
> to be taken into consideration when implementing this.
>

Use Krita on Linux ;) At least there we have zero reported crashes for the
master branch.

> Cheers,
> Erik
>
>
> On Fri, Feb 21, 2014 at 11:10 PM, silvio grosso <grossosilvio at yahoo.it>wrote:
>
>> Hi everyone,
>>
>> Regarding the plans for Krita (2.9 and 3.0) I am wondering how difficult
>> would be to have a portable version (for Windows)?
>>
>> In essence, you should only need to download a zip file (7zip or
>> whatever) and you might unzip it on your location (folder): that's it :-)
>> By doing so, you might even start Krita from your usb pendrive :-)
>> No more folders scattered on your system (e.g. %AppData%)
>>
>> More precisely, I am thinking about a 64 bit portable version (not a 32
>> bit one).
>> Nowdays, IMHO, whenever it is possible, it does not make much sense to
>> use a 32 bit version...
>>
>> Gimp has already this option. At present, you can download portables
>> versions both from the stable [1] and unstable versions [2].
>> BTW, another interesting open source software (QT 5.2) is Shotcut [3]
>> which sports the portable option as default (both on Windows and Linux).
>>
>> Needless to say, IMHO, this option has a lower priority compared to the
>> other ones...
>> Improving the shortcuts backend would be extremely cool for instance.
>> As you know, with Gimp, you can download a text file (ps-menurc) with all
>> Photoshop shortcuts and adopt it as your default option.
>>
>> Best regards,
>>
>> Silvio
>>
>> [1] http://portableapps.com/apps/graphics_pictures/gimp_portable
>> [2] http://nightly.darkrefraction.com/gimp/
>> [3] http://www.shotcut.org/
>>
>>
>>
>>   Il Venerdì 21 Febbraio 2014 21:21, Paul Geraskin <
>> paulgeraskin at gmail.com> ha scritto:
>>
>>  For 2.9 i would like to add:
>> - LayerGroups for PSD files (save/load). This is the most important
>> thing. This will be better integration between PS/Painter/SAI and Krita.
>> - Possibility to draw on FileLayer and save it. This will be integration
>> between Blender and Krita. In this way we can exchange layers between the
>> apps.
>>
>> These are the most important features.
>> And ofcourse "Line quality" as already Boud mentioned. We need the same
>> lines quality as PS/Gimp have. To get our brushes scalable.
>>
>> Thanks.
>>
>>
>>
>> 21.02.2014 21:02, Sven Langkamp пишет:
>>
>>  On Wed, Feb 19, 2014 at 11:04 AM, Boudewijn Rempt <boud at valdyas.org>wrote:
>>
>> Krita Roadmap
>> -------------
>>
>> 2.8 will be awesome, but after 2.8 comes 2.9...
>>
>> During the 2.8 beta phase, we've been lucky to have had a lot of input on
>> areas where Krita should be better. The main areas are:
>>
>> * MDI interface (more than one document loaded in one window)
>>
>>
>>  I would give this the top priority, because it's the single feature
>> that has be merged before we go to 3.0 and will likely also need a lot of
>> work.
>>
>>
>> * Mask handling: creating and converting masks is not as easy as it
>> should be.
>>
>> * Selection handling: modifying selections is really inconvenient at the
>> moment
>>
>> * Line quality: we should try and figure out how better anti-alias
>> especially thin lines. This wasn't a problem before because our display
>> quality wasn't very good, but since that's excellent now, it is a problem
>>
>> * Performance of the color correction system: the final conversion step
>> for display is now holding us back. We might be able to move that to the
>> GPU as well, for the OpenGL canvas
>>
>>
>>  Have you measured the impact of that? I have seen many comments about
>> bad performance recently. Users expect fast painting with the biggest brush
>> on a 10k x 10k image.
>>
>>
>> * Text and vector tools. We share these with Calligra. The current system
>> is a hybrid of ODT, ODG and SVG. Creating and manipulating text is
>> difficult, the difference between the two text tools is hard to explain,
>> and finally, the results aren't good and we cannot save all features the
>> gui offers.
>>
>>
>>  That's a very tricky problem. I know that the current system has a lot
>> of shortcoming, but there is currently no good alternative for it. We have
>> to keep backwards compatibility, so we can't throw it out. The problem with
>> the text are more related to bugs in the text tools rather than the
>> fileformat (the shadow problem is too). Even if we throw it out, it would
>> take months to replace the text tools alone and years if you want to reach
>> the capabilities of other applications.
>>
>>  In any case the text shapes and text tools would have to be replace, if
>> you want to store as SVG we would likely need massive changes in Flake too.
>> We have seriously question is that is really a justified change,
>> considering how much effort would have to be dumped into it.
>>
>>  * The dirty brush proposal and related preset handling issues
>>
>> This is obviously already more than we can handle in one release period,
>> so we need to prioritize. Also, I might have forgotten a topic that is more
>> important than any of these!
>>
>> Then there is the roadmap towards 3.0. 3.0 should be our Qt5 release,
>> which means no refactoring, just porting. For that to be as smooth as
>> possible, at least the MDI refactoring should have landed, and any other
>> big refactorings that influence which dependencies we have.
>>
>>
>>  I would add:
>>
>>  *Unified shortcut confguration: Currently many users are confused that
>> the shortcuts for the actions and the input manager shortcuts are split
>> over two locations. These should be combined into a single UI. The same
>> unification should be done for the done for saving shortcuts so everything
>> is saved to shortcut profiles (which should be a resource).
>>
>>
>>
>> _______________________________________________
>> Krita mailing listkimageshop at kde.orghttps://mail.kde.org/mailman/listinfo/kimageshop
>>
>>
>>
>> _______________________________________________
>> Krita mailing list
>> kimageshop at kde.org
>> https://mail.kde.org/mailman/listinfo/kimageshop
>>
>>
>>
>> _______________________________________________
>> Krita mailing list
>> kimageshop at kde.org
>> https://mail.kde.org/mailman/listinfo/kimageshop
>>
>>
>
>
> --
>
>
> *Erik Johansson*
> *Pipeline TD*
> *Fido*Rosenlundsgatan 36
> 118 53 Stockholm, Sweden
> www.fido.se
>
> _______________________________________________
> Krita mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20140222/0b69bf4d/attachment-0001.html>