<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Feb 22, 2014 at 12:21 AM, Erik Johansson <span dir="ltr"><<a href="mailto:erik.johansson@fido.se" target="_blank">erik.johansson@fido.se</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Just wanted to chip in on:<div><br></div><div><div>"""<br><div><div style="font-family:arial,sans-serif;font-size:13px">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
* MDI interface (more than one document loaded in one window)<br></blockquote><div><br></div></div><div style="font-family:arial,sans-serif;font-size:13px">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. </div>
</div><div style="font-family:arial,sans-serif;font-size:13px">"""</div><div style="font-family:arial,sans-serif;font-size:13px"><br></div></div><div style="font-family:arial,sans-serif;font-size:13px">Will this result in less memory/cpu usage when having multiple documents open?</div>
</div></div></blockquote><div><br></div><div>I think so, resources would only be loaded once per process so you save that. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>
<div style="font-family:arial,sans-serif;font-size:13px">Will the old way of one process per document still work?</div></div></div></blockquote><div><br></div><div>You would still have a process per window. So as long as you have one document open it should work like the old application.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div style="font-family:arial,sans-serif;font-size:13px">Is it possible to have a chrome like approach where each tab is a process?</div></div></div></blockquote><div><br></div><div>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.</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div style="font-family:arial,sans-serif;font-size:13px">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.</div>
</div></div></blockquote><div><br></div><div>Use Krita on Linux ;) At least there we have zero reported crashes for the master branch.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div style="font-family:arial,sans-serif;font-size:13px">Cheers,</div><div style="font-family:arial,sans-serif;font-size:13px">Erik</div><div class="gmail_extra">
<div><div>
<br><br><div class="gmail_quote">On Fri, Feb 21, 2014 at 11:10 PM, silvio grosso <span dir="ltr"><<a href="mailto:grossosilvio@yahoo.it" target="_blank">grossosilvio@yahoo.it</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div style="font-size:12pt;font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif">Hi everyone,<br><br>Regarding the plans for Krita (2.9 and 3.0) I am wondering how difficult would be to have a portable version (for Windows)?<br>
<br>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 :-)<br>By doing so, you might even start Krita from your usb pendrive :-)<br>
No more folders scattered on your system (e.g. %AppData%)<br>
<br>More precisely, I am thinking about a 64 bit portable version (not a 32 bit one).<br>Nowdays, IMHO, whenever it is possible, it does not make much sense to use a 32 bit version...<br><br>Gimp has already this option. At present, you can download portables versions both from the stable [1] and unstable versions [2].<br>
BTW, another interesting open source software (QT 5.2) is
Shotcut [3] which sports the portable option as default (both on Windows and Linux).<br><br>Needless to say, IMHO, this option has a lower priority compared to the other ones...<br>Improving the shortcuts backend would be extremely cool for instance.<br>
As you know, with Gimp, you can download a text file (ps-menurc) with all Photoshop shortcuts and adopt it as your default option.<br><br>Best regards,<br><br>Silvio<br><br>[1] <a href="http://portableapps.com/apps/graphics_pictures/gimp_portable" target="_blank">http://portableapps.com/apps/graphics_pictures/gimp_portable</a><br>
[2] <a href="http://nightly.darkrefraction.com/gimp/" target="_blank">http://nightly.darkrefraction.com/gimp/</a><br>[3] <a href="http://www.shotcut.org/" target="_blank">http://www.shotcut.org/</a><br><br><div style="display:block">
<br> <br> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:12pt"> <div style="font-family:HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;font-size:12pt">
<div dir="ltr"> <font face="Arial"> Il Venerdì 21 Febbraio 2014 21:21, Paul
Geraskin <<a href="mailto:paulgeraskin@gmail.com" target="_blank">paulgeraskin@gmail.com</a>> ha scritto:<br> </font> </div><div><div> <blockquote style="border-left:2px solid rgb(16,16,255);margin-left:5px;margin-top:5px;padding-left:5px">
<div><div>
<div>
<div>For 2.9 i would like to add:<br>
- LayerGroups for PSD files (save/load). This is the most
important thing. This will be better integration between
PS/Painter/SAI and Krita.<br>
- 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. <br>
<br>
These are the most important features. <br>
And ofcourse "Line quality" as already Boud mentioned. We need the
same lines quality as PS/Gimp have. To get our brushes scalable.<br>
<br>
Thanks.<br>
<br>
<br>
<br>
<a href="tel:21.02.2014%2021" value="+12102201421" target="_blank">21.02.2014 21</a>:02, Sven Langkamp пишет:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>On Wed, Feb 19, 2014 at 11:04 AM,
Boudewijn Rempt <span dir="ltr"><<a rel="nofollow">boud@valdyas.org</a>></span> wrote:<br>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Krita
Roadmap<br>
-------------<br>
<br>
2.8 will be awesome, but after 2.8 comes 2.9...<br>
<br>
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:<br>
<br>
* MDI interface (more than one document loaded in one
window)<br>
</blockquote>
<div><br>
</div>
<div>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. </div>
<div> </div>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Mask handling: creating and converting masks is not as
easy as it should be.<br>
<br>
* Selection handling: modifying selections is really
inconvenient at the moment<br>
<br>
* 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<br>
<br>
* 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<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div> </div>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* 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.<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* The dirty brush proposal and related preset handling
issues<br>
<br>
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!<br>
<br>
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.<br>
<br>
</blockquote>
<div><br>
</div>
<div>I would add:</div>
<div><br>
</div>
<div>*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). </div>
</div>
<br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Krita mailing list
<a rel="nofollow">kimageshop@kde.org</a>
<a rel="nofollow">https://mail.kde.org/mailman/listinfo/kimageshop</a>
</pre>
</blockquote>
<br>
</div>
</div><br>_______________________________________________<br>Krita mailing list<br><a>kimageshop@kde.org</a><br><a>https://mail.kde.org/mailman/listinfo/kimageshop</a><br><br><br></div> </blockquote> </div></div></div> </div>
</div> </div></div><br>_______________________________________________<br>
Krita mailing list<br>
<a href="mailto:kimageshop@kde.org" target="_blank">kimageshop@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kimageshop" target="_blank">https://mail.kde.org/mailman/listinfo/kimageshop</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><div dir="ltr"><p><b>Erik Johansson<br></b><i>Pipeline TD<br></i><b>Fido<br></b>Rosenlundsgatan 36<br>
118 53 Stockholm, Sweden<br><a href="http://www.fido.se/" style="color:rgb(17,85,204)" target="_blank">www.fido.se</a></p>
</div>
</font></span></div></div>
<br>_______________________________________________<br>
Krita mailing list<br>
<a href="mailto:kimageshop@kde.org" target="_blank">kimageshop@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kimageshop" target="_blank">https://mail.kde.org/mailman/listinfo/kimageshop</a><br>
<br></blockquote></div><br></div></div>