Before I start, I would like to thank all core developers and volunteers for their continued time and devotion to this program and its users.
@boudewijn: Please pass/refer this post/thread onto core dev's and volunteers.

I am a GUI programmer and mostly use wxPython(sorta dev). I have used PySide/PyQt before also in porting Embroidermodder 2 C++(Qt) to python(experimental Qt port).
So you can probably figure, I am really excited that the python scripting/plugins is almost/here!!!
Also I'll probably be the first to try implementing a wxPython(Frame/Dialog) with your API options into Krita. Qt if I have too. On Windows OS atm, still waiting for a 4.0 with python plugin manager.

I've tested just about every "paint" application at least once, and have made art/textures with many of them, but always end up back with Photoshop for these reasons:
1. GUI is user-friendly(EASY to use). Im just talking about the basic tools(toolbar). COPY this philosophy. (You guys are close!)
2. Layer features, and Layer styles(you guys seem to have this one done-ish already.)
3. Actions(Photoshop's implementation kinda sucks). A good Python API is better(and EASY). Screw javascript unless it is an alternative/addon.
4ish. I have a Logitech G11/G15 keyboard with 18*3 dedicated macro keys and I don't use it for gaming(yep you guessed it. PS and other apps). (Sucks their software doesn't work on linux/mac)


Krita Enhancements:
===================

Major TODO List: (These may take some time to implement.)
----------------

1. and only.(til ya get this done. lol. This one's worth a bounty by many photoshop users)
Selection Tools.
In Photoshop, when dragging inside of a selection(mouse must be within selection area), it translates/moves the selection marquee(only the selection, not the image underneath)
This functionality with Krita's selection tools is sorely missed. This functionality is very good for increasing productivity and is a must-have selection feature.
Make your selection tools work like Photoshop's does, and they will come. ...Then add extra cool stuff.
THIS is THE #1 reason prettymuch I haven't converted to Krita completely yet. It is a SuperiorWorkTime vs. SlightInferiority Issue.
You must make doing the repetitive simple things manualy extremely easy, before moving onto such things as scripted languages (python), in my opinion. EDIT See: Version 4.2.0preview https://krita.org/en/item/the-krita-201 ... -the-bugs/

This is also referenced here as #5: viewtopic.php?f=288&t=138391
Also other users notice THIS when trying Krita(I'm a volunteer at http://www.computerbanc.org/ . We refurbish computers as a non-for-profit org and load computers with OS's and software)

Some folks have even called my program(a code editor/SDK), 'SourceCoder', a 'Notepad++' - ish clone that is cross-platform, but I like to tend to think the other way around. lol.
I(Adobe does this also) spend a LOT of time on implementing the smallish usability features.
MAKE people say that 'Photoshop' is a 'Krita' clone. Haha, I love Open Source!


Minor TODO List: (These may take just a night or so to implement.)
----------------

1a. In Photoshop, the Rectangular Marquee Tool modifys the cursor when Shift(Adds a little plus to the cursor) when adding to selection
and also Alt(Adds a little minus to the cursor) when subtracting from selection. EDIT See: Version 4.2.0preview https://krita.org/en/item/the-krita-201 ... -the-bugs/

2. In Photoshop, when using the mousewheel over a document it zooms toward the pointer.(Krita does this also)
Krita is missing the following functionality: When Alt is held, it scrolls the vertical scrollbar, and when Ctrl+Alt is held, it scrolls the horizontal scrollbar.
The document window's keyboard funtionality is a MAIN focus(make this a priority). Don't forget that people with disabilities use computers also.

3. In Photoshop the Transparency Settings has a simple dc rendered checkerboard preview square. Krita is missing one. Sorta minor feature. EDIT: See: pixel grid @ zoom option. This indeed is a innovative solution. Not quite the same as the presented idea, but solves the problem.

4. Photoshop has a window/docker named 'Info'. Pretty simple, RGB and X,Y document stuff. Missing in Krita.

5. Offline docs, bundled with the app(for the RELz version). Online docs links suck when your Offline. EDIT: Wiki has been converted over to sphinx so offline docs are easily possible with portable builds. And folks can upload tutorials with images and a simple blerb links easily now, whether official or unofficial docs.


WISH List: Stick it on your TODO and hope someone implements it.
----------

1. Photoshop CS2 cool menus dialog. Color changes and other workflows in the MenuItems. And MenuItem visibility also. (Im working to port to a wxPython widget)
2. A Blender plugin that updates the/a document texture to the/a mesh in blender(some guy did this one with photoshop and blender processes somehow)
3. See https://developer.nvidia.com/nvidia-tex ... -photoshop DDS Tools.
4. I wish for more WISHES. lol

Hi
I'm 6 weeks in with both Krita and Linux. I have been able to organise workspace, brushes and learn basic controls in a way that means I can just get on and paint, which is wonderful, and the learning support is very good. I know it will take time to learn what is already there, but am looking forward to steadily learning how Krita does things. I believe I read in another thread that Krita's main focus is direct painting, and, for example, new GSoC engines are coming in for watercolour, all of which is exciting. Krita has such a big following due to being true to itself; that it includes features that people who like many different programs and ways of working can use, from children to amateur to advanced to professional, is a real credit to them.
I'm not a Photoshop/Gimp kind of person, but, from what I've seen, many paint in Krita then do some editing in Photoshop, or Gimp/similar (paid/free), if on Linux.

Ah... could you try to... make your english writing a little more regular? This is so variable it's like trying to read a 6yo's handwriting


We have a few rules regarding feature requests. Yours in particular is missig the 'how are you using this/which problem is this solving for you'. We are not intending to be a photoshop clone, we intend to be a tool for artists.

Let's see...

List 1:
1. We don't really care whatever photoshop does with their toolbar.
2. Yeah, this gets tweaked from time to time.
3. Stringing together actions(everything keyboard schortcuttable) is possible in our current python implementation, yes. However, there's no recording method.
4. We can do little with this, because we're tied to what QT can pick up.

List 2:
Selections are a big problem, but we're not focusing on them because text and vectors were a bigger problem, and before that speed was a bigger problem. Selection workflow is significantly complicated that it would probably be worth a kickstarter fundraiser on its own.

List 3:
1. Attempted before(we have the icons and everything), failed, needs a larger refactor because we don't have dynamic cursors anywhere yet.
2. You can configure this yourself.
3. I don't know what this is? This is why you need to say why you need this.
4. Attempted before, but actually slowed the whole program down.
5. Not easily possible. The docs are currently in a mediawiki, which make this difficult.

List 4:
1. I have no idea whatever this is.
2. Not trivial.
3. People have asked us about this, but it is not trivial.
4. here's all the wishes people have made

TheraHedwig wrote:List 1:
4. We can do little with this, because we're tied to what QT can pick up.

I have asked many folks before, and usually it ends up with someone wanting to do the GUI work(which is already DONE)
and a very few people claiming they could write a DRIVER for the keyboard on linux. Most of which, never happens.

TheraHedwig wrote:List 2:
Selections are a big problem, but we're not focusing on them because text and vectors were a bigger problem, and before that speed was a bigger problem. Selection workflow is significantly complicated that it would probably be worth a kickstarter fundraiser on its own.

I'm all in for a kickstarter item on this one. My bro and I have helped out a little bit in the past. I'd figure maybe a few thousand or possibly more if a complete selection system rewrite is in store. It seems the biggest problem is a lack of developers overall with a familiar background with the codebase, and the time to do it of course at the moment. I'd make it a priority item for your next fundraiser.

TheraHedwig wrote:List 3:
2. You can configure this yourself.
3. I don't know what this is? This is why you need to say why you need this.

regarding #2:
How would you configure it? Please Explain. I believe you might be misunderstanding. I do not see a way to do this/configure it. It should be a built-in usability functionality, in my opinion.

Regarding #3:
Draw the transparency options, like they would show up upon(OK), when they are in the settings dialog. This is useful when setting up the document/grid/snap.
https://github.com/Metallicow/Program-Screenshots/blob/master/Photoshop%20CS2/PhotoshopCS2_Edit_Preferences_TransparencyGamut.png

TheraHedwig wrote:List 4:
1. I have no idea whatever this is.
2. Not trivial.

Regarding Wish#1: PS Menus Dialog.
https://github.com/Metallicow/Program-Screenshots/blob/master/Photoshop%20CS2/PhotoshopCS2_Edit_Menus.png
The Menus dialog is basically the same thing as the Keyboard Shortcuts dialog, except it deals with MenuItems visibility and color.

Regarding Wish#2: A blender/krita plugin will probably come a lot sooner now that python is included in krita.
It's just a matter of time before someone codes it to work with krita...
see https://blenderartists.org/forum/showth ... etely-Free

Regarding #3:
Draw the transparency options, like they would show up upon(OK), when they are in the settings dialog. This is useful when setting up the document/grid/snap.
https://github.com/Metallicow/Program-S ... yGamut.png

When you say transparency options, If you mean tweaking checker board pattern, then it can be done by going to settings > configure krita > display section , there is a separate section for transparency checker board pattern there.

TheraHedwig wrote:List 3:
2. You can configure this yourself.

@ TheraHedwig
I have toyed with the 'Photoshop Compatible' canvas input settings(which are not quite right) and I believe I have come across a bug.
These changes fix the Pan settings, but when Alt + Mouse Wheel is used NOTHING happens with the zooming. Space + Mouse Wheel works tho and is similar enough with the pan tool to work right. The problem seems to be with Alt. Normally that is a Menu access button on windows.

Canvas Input Settings Changes:
Pan Canvas>
Mouse Wheel -> Mouse Wheel Up -> Pan Down
Mouse Wheel -> Mouse Wheel Down -> Pan Up
Mouse Wheel -> Ctrl + Mouse Wheel Up -> Pan Right
Mouse Wheel -> Ctrl + Mouse Wheel Down - > Pan Left

Zoom Canvas>
Mouse Wheel -> Alt + Mouse Wheel Down -> Zoom Out
Mouse Wheel -> Alt + Mouse Wheel Up -> Zoom In

Pic:
https://github.com/Metallicow/Program-Screenshots/blob/master/Krita%204.0.0-pre-alpha/KritaPSCompatSettings.png

Edit:
Tool Invocation>
Also the Shift + Left Mouse Button that activates the line tool conflicts with shift selection adding. This should probably be changed to V + Left Mouse Button like the `Krita Default`to avoid conflicts.

kamathraghavendra wrote:

Regarding #3:
Draw the transparency options, like they would show up upon(OK), when they are in the settings dialog. This is useful when setting up the document/grid/snap.
https://github.com/Metallicow/Program-S ... yGamut.png

When you say transparency options, If you mean tweaking checker board pattern, then it can be done by going to settings > configure krita > display section , there is a separate section for transparency checker board pattern there.

Yes, I see that. The issue is there is no preview square(checkering) of what the settings should look like there. One must click OK then check a open doc with a alpha layer, which is a slight pain to setup, you see. Photoshop has one of these in their transparency settings which visualizes it in the dialog so the user can see it before hitting OK.

Ok so you need a preview of the checker-board pattern before applying.

kamathraghavendra wrote:Ok so you need a preview of the checker-board pattern before applying.

Right!

I often do icon/textures of varying sizes and this helps out. As you can see in the image I recreated "Snakey", my python icon/app mascot as 16x16 .kra icon in krita. Notice that the zoom is set at 1600% so the checkerboard(which is set at 16px) matches up nicely to 1 pixel. The same type of setup applies for a variety of sizes, and it is easier to visualize the checkerboard before applying in the dialog. On a side note, regarding the selections not being able to be moved/translated after they are made, makes griding/organizing out icon sheets a lot harder.

TheraHedwig wrote:List 3:
5. Not easily possible. The docs are currently in a mediawiki, which make this difficult.

Well, what does everyone think about trying a few different ways this might be done.

1. https://www.httrack.com/ might be able to make quick work of the mediawiki.
2. Write a python script to iterate through all the pages and get the "Printable version" or the "print as pdf" and do something to bind them into a doc(pyPDF or similar lib maybe).
3. Login and paste each page contents into files, then manually convert everything to rst Sphinx.(Blender did this). Then either drop the wiki altogether(Blender) or monitor each for changes before releases.
4. http://pandoc.org/index.html GitHub Page Never used this one...

I personally think Sphinx would be the easiest route for maintaining and compiling offline docs, but would take a bit of leg work to convert the wiki first.
HTTrack, on the other hand, if setup right, might be an option, but it takes some getting used to the software and then bundling only what you need for docs.
Lastly, writing a python script to iterate through all the pages and get the "Printable/PDF" version would likely result in being one big Hack of a headache.

Thoughts...?

Hi Metallicow,

Well, what does everyone think about trying a few different ways this might be done.

1. https://www.httrack.com/ might be able to make quick work of the mediawiki.
2. Write a python script to iterate through all the pages and get the "Printable version" or the "print as pdf" and do something to bind them into a doc(pyPDF or similar lib maybe).
3. Login and paste each page contents into files, then manually convert everything to rst Sphinx.(Blender did this). Then either drop the wiki altogether(Blender) or monitor each for changes before releases.
4. http://pandoc.org/index.html GitHub Page Never used this one...

I personally think Sphinx would be the easiest route for maintaining and compiling offline docs, but would take a bit of leg work to convert the wiki first.
HTTrack, on the other hand, if setup right, might be an option, but it takes some getting used to the software and then bundling only what you need for docs.
Lastly, writing a python script to iterate through all the pages and get the "Printable/PDF" version would likely result in being one big Hack of a headache.

Thoughts...?

There was a discussion about adopting sphinx, mediawiki and other solutions, the docs.krita.org is not that old, not more than 1-1/12 years old, we just migrated there, earlier it was userbase wiki. The discussion is public and is on phabricator (can't find the link right now) . Having said that, I strongly disagree with you here.

Do you know how much work it takes to create a wiki, the manual that you see now at docs.krita.org is result of countless hours of work by volunteers who are very rare to turn up for help. So your suggestion of copy pasting each page in sphinx rst format (which is a mountain of work considering media wiki format and rst format are quiet diffferent) is not worth it one bit in my opinion. What you are suggesting is similar to porting an already existing application to different language. Say from c++ to java. So it would take another 1 year or so to port all the documents properly. Until we have the new wiki done and ready to be made live, we would also have to maintain the current wiki too, and at the rapid pace of krita's development we are already finding it a bit hectic to add new features and documentation there. so unless we have an army of documentation writers and proof readers I would not suggest a rewrite.

Would you help us in porting it to sphinx, I am sure if you have it ready, then the devs will surely look into adopting it. You can have a github repo and start working on it, interested people who want offline pdf can contribute to it. But I would suggest, If possible we should finding a solution for mediawiki, if it exists, to export to pdf and avoid re-inventing the wheel and doing double donkey work of copy pasting stuff twice here and there and scattering google seo ranks.

P.S. Sorry if this sounds a bit aggressive reply.

kamathraghavendra wrote:Would you help us in porting it to sphinx, I am sure if you have it ready, then the devs will surely look into adopting it. You can have a github repo and start working on it, interested people who want offline pdf can contribute to it. But I would suggest, If possible we should finding a solution for mediawiki, if it exists, to export to pdf and avoid re-inventing the wheel and doing double donkey work of copy pasting stuff twice here and there and scattering google seo ranks.

P.S. Sorry if this sounds a bit aggressive reply.

Sure, porting docs to a Sphinx setup is something I've helped done before for other projects. It's not my favorite thing to do, but I'll start looking into "something" for offline docs. The difference here looks like there may be many non-dev users that contribute to the wiki and normally a sphinx setup is intended to be downloaded and worked on locally then push commits. Most devs of the other projects agreed Sphinx was the way to go, but this also makes non-dev wiki users have to learn git/python/rst which is a headache for their contributing workflow, a different way than they are used to. There are pro's and con's for both types of users. Sphinx can compile the docs as loose html(then maybe into a .chm also like the python docs) and do pdf or other options, which is nice, but the con is that it isn't a online tool like a wiki(or atleast I haven't seen one yet). Maybe in the future someone will write a SphinxWiki like application for web that works with a git repo setup(github wikis can be downloaded so maybe something similar)

I've thought a little more about how offline docs might be done, and have this idea. Create a basic page layout like the mediawiki in sphinx, which every page will load it's content from a different .rst. Compile a list of page url's to snake the mediawiki infos/syntax from and download each page to a separate pagename.mediawiki file. This way only top level wiki page changes would have to be monitored. Then use pandoc cmd to convert every pagename.mediawiki file to a equivalent .rst which would be loaded in the sphinx basic layout setup.
All this should easily be able to be done with python scripting and pandoc commandline. The only thing I see might be a problem with this approach might be the pandoc conversion to rst. Hopefully the default output won't need tweaking, but it might... And if all works well, then the mediawiki and sphinx could co-exist, but main doc changes would still need to be done in mediawiki until a RELz is ready to be made when compiling/packaging with Sphinx/pandoc would come into play.

I'll also look into "export to pdf" from mediawiki when I review the raw html of the pages and compile a page link list.

In the end, whichever way is figured out to generate the offline docs, then maybe a Krita python doc viewer plugin should be written so they can be viewed in app or from a menuitem link in the core code.

Can you add tablets with "UGEE" in the xinput identifier name to list of supported tablets for pressure sensitivity to work? Because my tablet screen Artist XP Pen 10 S worked well in 2.9.x series, but stops working (pressure sensitivity) in 3.1.x.

xinput
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Logitech USB Optical Mouse id=10 [slave pointer (2)]
⎜ ↳ UGEE 10.1 Tablet Monitor id=16 [slave pointer (2)]
⎜ ↳ UGEE 10.1 Tablet Monitor id=17 [slave pointer (2)]
⎜ ↳ UGEE 10.1 Tablet Monitor id=18 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=13 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ Video Bus id=8 [slave keyboard (3)]
↳ Power Button id=9 [slave keyboard (3)]
↳ HP Truevision HD id=11 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=12 [slave keyboard (3)]
↳ HP WMI hotkeys id=14 [slave keyboard (3)]
↳ HP Wireless hotkeys id=15 [slave keyboard (3)]

harishankar wrote:Can you add tablets with "UGEE" in the xinput identifier name to list of supported tablets for pressure sensitivity to work? Because my tablet screen Artist XP Pen 10 S worked well in 2.9.x series, but stops working (pressure sensitivity) in 3.1.x.

xinput
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Logitech USB Optical Mouse id=10 [slave pointer (2)]
⎜ ↳ UGEE 10.1 Tablet Monitor id=16 [slave pointer (2)]
⎜ ↳ UGEE 10.1 Tablet Monitor id=17 [slave pointer (2)]
⎜ ↳ UGEE 10.1 Tablet Monitor id=18 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=13 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ Video Bus id=8 [slave keyboard (3)]
↳ Power Button id=9 [slave keyboard (3)]
↳ HP Truevision HD id=11 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=12 [slave keyboard (3)]
↳ HP WMI hotkeys id=14 [slave keyboard (3)]
↳ HP Wireless hotkeys id=15 [slave keyboard (3)]

I have no idea what you are asking for here. Whatever this is, it is in the wrong thread. Please open a new thread, and be more descriptive as to what you are asking for exactly and some of the devs might be able to help you.

kamathraghavendra wrote:Would you help us in porting it to sphinx, I am sure if you have it ready, then the devs will surely look into adopting it. You can have a github repo and start working on it, interested people who want offline pdf can contribute to it. But I would suggest, If possible we should finding a solution for mediawiki, if it exists, to export to pdf and avoid re-inventing the wheel and doing double donkey work of copy pasting stuff twice here and there and scattering google seo ranks.

Well, I've managed to compile a indented(like the wikitree) list of page links with a few options in a python script.
Good News:
* It can export pages mediawiki syntax to filename.mediawiki files.
* It can export pages to pdf.

Bad News:
* pandoc conversion of the .mediawiki files was "half-assed" to say the least and only converted some. So it looks like Sphinx will have to be a manual conversion.
* The mediawiki exported pdfs have some images with artifacts/ugly. This may be because of wikisize/color profile/etc...?? I dunno. NEEDS Investigated.
* Links in the pdfs don't work, but are readable. Apparently the mediawiki pdf exporter isn't the greatest.

Here is the GitHub repo I setup for this stuff: https://github.com/Metallicow/Krita-Docs-Utilities