Note: should we add complex plugins like this to krita, or should we start setting up a plugin registry or something like that on share.krita.org?

A plugin registry would be cool. But I also suggest that some curated and famous scripts from the registry should be added to default set from time to time. So there won't be a blog-post saying 10 things you should do after you install krita :D

A plugin registry would be cool. But I also suggest that some curated and famous scripts from the registry should be added to default set from time to time. So there won't be a blog-post saying 10 things you should do after you install krita :D

But first people need to test it!

Okay, so this has been merged to master. Therefore, please us the version in master to test! The README.md can be found in the source.

First, as I said on IRC, good work!
I also could get an idea about how long and complex it was to write this by opening the Python files.
It's light year of my new-born Python skill, but it motivates me to learn a lot to see all the action you can do.
(right now I'm learning via your other simplier but great quick_settings_docker ; a single python file, good entry door to fork&tweak)

My feedback

The pros:

• I had no problem to use it. I understood the logic behind it.
• New project, adding pages; perfect! Template works nicely.
• I like the default settings: the default name for project directory tree.
• I like the codename generator ( NyxSaffron! IynxCashew! super).
• It's cool to get an overview of the document within a project, and being able to open them quickly.
• It reminds me the old "flipbook" docker made by @rempt in 2013, I'm happy to see something like that back in Krita. (screenshot at the end)
• I can really see how your docker could boost my production: to storyboard directly on split document instead as a single document. (screenshot at the end)

What I would like if I had skill to code it:

• I would like bigger thumbnail in the overview: to be able to re-read the story from the docker ( Ideal would be to be able to resize the docker horizontally and have thumbnail expanding/shrinking ; adapting to the docker width)
• You wrote about it on your article: a possibility to sort the pages (move up/move down), so it's possible to , for eg. "insert a new page and move it in the middle"
• Make the layout of the docker thinner and adapted for vertical layout; to use it aside of the canvas as the old flipbook docker (screenshot at the end)
• The page viewer popup is cool but was a bit little for a preview (256x256?), and its dialog windows didn't had a "close button" on my system , I had to ALT+F4 to close it. (Cinnamon D.E. similar as GNOME3 undecorated dialog)

Optional

• This is good usability for webcomic (vertical scrolling of page) but for printing, comic/manga artist often needs to use template for right-page/left-page ( ref: https://youtu.be/N1xQpYza2KA , to manage panels expanding in the margin of right, or left). On Pepper&Carrot, I do not expanded panel outside margin, so I'm fine with your design. Maybe it's a webcomic plugin? Vertical scrolling solve so many issue with cross-reading platform (smartphone/tablet/desktop/print/e-reader)...

That's all, thanks again for sharing your tool and the sources!

Attachements:

Flipbook docker screenshot, 2013:

The way I storyboard on a single document right now:

• The viewer docker starts out at 256x256, but can be resized to full size(it shows the mergedimage.png). Originally I had all the pages loaded into this(and you could flip between them), but the problem was that on average sized projects the loading of the mergedimage.png would be noticably heavy, and it is maybe not a good idea to load 20ish A4 300DPI sized pngs into memory without explaining to the user why Krita is suddenly eating their ram. But yes, I forgot about a close button on it.
• As for the thumbnails, the maximum I can get them to is 256x256(the preview.png size). They are now 100x100... I hadn't figured out how to let someone adjust the size yet.
• You can rearrange pages by drag and dropping the numbers on the right. So for the coding thing, were you thinking of Insert above, or insert right after selected?
• Hiding the button group might be possible with a QSplit, like we use for the filter list in filter config. That would make it possible to make everything a bit thinner.
  • Python also allows us to add actions to the shortcuts list, might this be helpful when then buttons are hidden? If so, which actions?

The print stuff, I figured that people, for spreads and double pages would use specific templates for images covering two pages and images covering single pages. This type of thing is also why the export settings allow you to crop to the guides before margins, because I saw that double-page comic page template, single page templates and cover page templates had wildly different margins. Right now there's no manner for the docker to think about pagecount, and it will take a lot of thinking to figure out how it ought to be done.

Thanks for testing it :)

• The print stuff/double pages : Good idea! It also solve when artists needs to draw on the two pages at same time. Maybe this type of design idea needs to be written somewhere on the docker to avoid hundreds of artist asking the same question as I did.

• Thumbnail/256x256px/Add slider : It's ok. I understand the constrain for weight ( 100 pages with mergedimage.png is overkill on memory, yes). Slider to zoom would be a perfect solution. Thanks!

• Viewer docker/larger/Add close button: Thanks! Good to know mergedimage.png is used for this one.

• Rearrange pages/drag and dropping the numbers : Oh! :O I had no idea you implemented this feature. Super cool! It's perfect as it is then. In my opinion; no need "insert above" / or "insert right" ; I can insert a page at the end and then sort it correctly in a second time with the drag&drop. Inserting a page is a rare situation, I don't think it deserve a special button to load the GUI.

• Hiding the button /QSplit /bit thinner : Super!

• Custom shortcuts /If so, which actions? : No need; if I need to edit/sort/remove/add a page ; I'll extend the docker.

Thank you for taking the time to study my feedback, for giving information about usage and your detailed reply!

There's actually a massive readme in the sources (src/plugins/extensions/pykrita/plugin/plugins/comics_project_management_tools/) that contains the majority of the howto and logic. Though I guess it could do with some extra bits on the spreads type of stuff. I figured we might have it somewhere more visible somehow, so that readme makes a good first step :)

This is merged, but I am still not sure how we should handle documentation for this.

I did some massive updates, mostly for ACBF support:

1. Fixed bugs with scaling.
2. We can now export panels and text to acbf. Krita will check layers containing "panels" and "text" in the name for the appropriate vector objects and use those.
3. The text has the minimal markup that acbf allows for(but no type yet)
4. We can now export standalone acbf files.
5. We can define bookmarks and page transitions with keywords.
6. Progress window ought to show up a little better.

Since I've begun hacking a bit away at the Comic Project reader, I figured it might be a good idea to add some of my thoughts here. I'm pretty close to finishing T8139, just a bit stumped on some layout alignment stuff and a couple of improvements I want to make to it. :)

Layout Suggestion

Firstly, I was thinking the layout of the docker could be more like the Layer docker, as I feel it's currently too wide. So instead of having two columns, you would have from the top down:

• Title of comic
• Drop down menu with rarely used functions:
  • New Project
  • Open Project
  • Project Settings (including Meta Data)
  • Edit Template (see below)
  • Batch Process (resize and more)
  • Export Comic (opens export settings dialog and let's you export the comic)
• Zoom Slider
• Thumbnails (pretty much the same way they're currently displayed)

Below that you would then have a line of icons, like in the Layer docker. These would be

• Add Page (from default template) with a + next to the icon for drop down with Import Page and Add From Other Template
• Duplicate Page
• View Page/Read Comic (opens the reader at the currently selected page)
• Delete Page (trash can icon aligned on the right side.

Missing from that list are Copy Location and Scrape Author Info...I'm honestly not sure if these are that useful, but we could keep them in there.

I could have a shot at implementing this, and make a patch, but would be curious to hear what your thoughts are on this.

Adding Pages

I have to disagree with Deevad a bit here, and I think it comes down to a different way of working. I like to actually use a page manager when doing thumbnails, be it Gimp Book or the one in Clip Studio Paint....or this one in future releases of Krita, instead of doing all thumbnails in a single document

This means adding, duplicating, moving and removing a lot of pages in a very non-linear fashion. I may be doing changes on pages 10 through 15, even though I already have 100 pages in the comic. When you've got a lot of pages, it would be most convenient to have new pages added before or after the page you have selected. Having to drag each page back 90+ pages after adding it, is not going to be very effective. The Layer docker adds new layers above the currently selected one, while my gut feeling thinks it would make more sense to add it after the selected page....but either would be fine.

The one in Clip Studio Paint is actually not that good at this, as adding or moving pages becomes super slow the more pages you have. At a hundred pages it takes 30 seconds or more to just add a page. We should definitely test creating 200 to 300 page comics in Krita, just to make sure it can handle it (I've only been testing with 5-10 page comics so far).

Edit Templates

It would be nice if there was a way to open and edit the templates from the interface. I know you can find them on disk, but it may not be obvious to all users. I tend to create templates with pre-made layers, such as thumbnails, rough, pencil, ink, guides for panels and more.

Move Deleted Pages to a Trash Folder

It would be nice if deleted pages could be moved to a Trash folder (not the actual OS trash). You would still have them there as a backup, and could re-import them if you wanted them back, but it would not clutter up the 'pages' folder with pages that are no longer part of your comic.

Other Stuff

On project creation it would be nice to include the creation for the initial template and to open the project once it's been created.

The page name next to the Thumbnail can be a bit confusing, as it's actually the Document Information>Title from Krita, and not the file name. If you duplicate a page, the Title doesn't change, so you would wind up with two pages with the exact same name in the docker, but different names on disk. Maybe this should be the filename instead.

We should probably add more export formats, such as .jpg and .png sequences.

The Name and Concept confused me a bit at first. Do we really need Concept?

Finally, I still think there is something funny going on when you add, move around, duplicate and delete pages, but I haven't been able to quite put my finger on it, so it may just be my imagination. I'll test this out once I finish the page viewer, to make sure everything is as it should.

This turned out a bit longer than planned. :)

It's awesome that you've written this plug-in for Krita. Combined with the upcoming vector and text improvements, Krita will become and even more awesome tool for creating comics.

Ah, let's see.

Concept and Name are specifically for the following problem:

1. You have an idea.
2. You do't have a title or whatever, but the computer wants you to give the file a title. Most artists will just type in "nnn" or "asdfghj" or "blabla" to get around this. Hence the generation thingy.
3. Now you have all these incomprehensibly named project files, but you forgot what a project was about. This is where concept comes in: It is a footnote for the artist themselves to know what they were thinking when starting to project without the danger of this ending up in the meta-data(so they can write down "a story in which B dies horribly" without being afraid it'll spoil people straight away). I got the idea from several writing books and software I've examined over the year. Writing down the concept can also help a lot with crystallizing what is important to you, the story teller, in the story. The description of the page is visible for a similar reason. I really wanted to create a workflow where there is a ton of room to leave little notes for yourself to keep organized(and also to get yourself back on track when you haven't worked on a project for a while)

Copy location is something for which the usefulness becomes more obvious when you start using the docker in earnest. For example, it could be that you have a folder with background information in the same project folder, or you want to check what resulted from the export. Copy location then copies the location and allows you to access the folder quickly from a different program, like a text editor, a file browser or even your favourite image viewer/referencing program.

Scrape Author Info was designed with teams in mind, part of the tools is to help reduce busy work like writing down each author that touched a file.

For project creation, I had briefly though about generating an initial template, but then I realised I actually wanted to get people to go past the setup phase as quickly as possible, so I am not sure how to enable template creation while still nt forcing people to stay in the setup any longer than they have to.

I am not sure in what situation you would want to duplicate a page? It is new to me as part of a comic workflow. Either way, when duplicating a page we can adjust the name, it might be slower, sure, but I have to admit I have not considered copying at all, and showing the proper title made more sense to me... Insert page and trash folder are an interesting idea, as is editing the template, but I am not sure about how the gui for that would look.

As for adding pages, deevad was saying that this was his original method because he was trying to solve the same issue as we did: Needing to be able to overview the pages and access them during the initial process. His solution, in lieu of the time and knowledge to write a python plugin, was to do everything on one page.

I am a bit hesitant to redesign the whole docker as I spent a long time thinking about how often and when each action would be triggered, which is what led to its current layout (For example, copy project location is it's own button not because it is that important, but if you're using a stylus you'll need to have an easy time clicking it, the rest of the minor actions have gui associated with them, so it's not that prudent there). You can already hide the buttons by dragging the section to the left.

For what it's worth, clip studio proly is slowing down a ton because it loads the comic into memory as a database, while all we do is open the kra thumbnail.

We should probably add more export formats, such as .jpg and .png sequences.

I am wondering how useful this is, as they already generate jpeg and/or png sequences in a seperate folder before bundling them(this is because I anticipate some people would want to dot their i's and cross their t's after export and thus adjust the files and then rebundle the cbz/epub). Right now each export format creates separate folder with images, because each can have seperate resolution sizes, and I am wondering whether it is better to encourage people to just make a cbz with the sequence size instead of making separate cbz and image sequence exports.

Part of the reason I might seem hesitant here and there is that I have quite a bit of experience as Krita dev and manual writer, so I am also making decisions using that experience, though I am also someone who needs to sit on a thought for a few days before I can make a decision on it. I hope it's not discouraging and I can convey what kind of philosophy is behind some of the decisions.

I have been working on letting the exporter handle basic po file translation in the past few days, so I am a bit preoccupied and scatterbrained too.

Also the damn thing needs more testing. And code cleanup. And testing.

Okay, pushed all of my code regarding the translations.

Right now, if you have a project, you can define the search keys for text layers in the export settings. Then, when going to the dropdown next to page, there's "scrape text for translations". Pressing that will trigger a script that goes allong the layers in each file until it finds the vector layer with the appropriate name. It will then parse through that file and get out the data of all text objects. Those get put into a POT file into the translation folder.

When running export and CBZ is active, the ACBF exporter will try to get the text data as well, as well as parse through the PO files it can find in the translation folder, and then put each of those into the ACBF file translations. There's also functionality to have the translator's comments inside PO files be included into the ACBF as translator's notes.

Other things also implemented:

1. Frames for acbf
2. Genre matching
3. ACBF author is now a proper author with full name
4. ACBF style sheets.
5. Designer and artbook are now properly part of the autocompletion keys.

This is about as far as I can get to supporting ACBF without changing the python shape API, so it will be on cooldown for now. (and maybe I'll clean up some more)

Yep, when explained, having Conecept makes sense.

Copy Location seems good to keep around, we could even add a Go To Folder (though I'm not sure how easy this would be to implement cross platform).

I hadn't thought of the use case for Scrape Author Info, but it makes sense if multiple artists are collaborating on a book.

As for duplicating pages, I often use this in early stages of creating a comic, when doing thumbnails and roughs. I use it when I want to try different solutions for a page or a scene. I'll duplicate some pages, and erase and redraw parts parts of them, then choose one of the solutions to keep, and delete the other.

The interface for editing the template could simply be Krita. Just have a button/menu to load a template in Krita, then you can do any changes to it that you want, and re-save it.

I can understand that you're reluctant to change the layout of the interface, and it's really not a priority, so we can just leave it for now.

That said, I'm wondering if a bug has snuck into the comic project docker. I just compiled the latest source with my patch applied D11076, and when I create a new comic, I can't add an initial template. After closing the template creation window, it errors out with.

Traceback (most recent call last):
  File "/home/ragnarb/krita/inst/share/krita/pykrita/comics_project_management_tools/comics_template_dialog.py", line 125, in slot_create_template
    if (create.prepare_krita_file()):
  File "/home/ragnarb/krita/inst/share/krita/pykrita/comics_project_management_tools/comics_template_dialog.py", line 298, in prepare_krita_file
    backgroundNode.setName(i18n("Background"))
AttributeError: 'NoneType' object has no attribute 'setName'

Loading existing comics works fine.

If I find the time, I'll try to beta test it a bit more, and help iron out any bugs I find.

Hm, I suspect that might be because the python API got updated to handle some memory leaks, meaning that a node doesn't necessarily pre-exist like it did back then. In that case, I'll have to work around that and push the fix to 4.0 too.

Edit: should be fixed now :)

For epub, I have to admit that my foray into epub was very simple.

One of the things that we for example can do is to try and instead of generating html files, generate svg files with the png inside, a page number overlaid, and maybe the sections with text overlaid with an invisible rectangle that has the text appended to the 'Desc' tag, though, I can only think of screenreaders that would pick up that last bit of information.

And indeed, a double check which metadata the epubs can use too.

EPub is mostly used by e-readers, which tend to have small screens, so I would be skeptical doing any thing that adds more margins around the comics page. I've actually bought EPub comic books, that I've wound up running through ImageMagick to get rid of unnecessarily wide margins, to make the pages larger and more readable on my Kobo Aura One.

I've gotten an index out of range error on line 569 of comic_project_manager_docker.py a couple of times when deleting the first page of a comic, but I've been unable to reproduce it. I'll let you know if I figure out what's going on there.

I also tested the plug-in with 200 pages, and adding, removing and moving pages works perfectly, with no noticeable performance difference from when working with 5 pages. There is however a problem with export, as it doesn't free up RAM after exporting a page. After exporting 70 pages, I had managed to use up all the 8G of RAM on my laptop, and my machine froze. I also tested exporting a 10 page project, and it seems like the RAM is not freed up after a successful export either.

Yes, that is sorta related to the memory pool, I think, because what happens is that it tells Krita "closeLater()" and that in turn has to do with how the objects are destroyed in cpp. I am afraid all we can do is annoy @dkazakov and @rempt about that.

For the problem at line 569, the function for logical index can give -1 when out of range, which is then super out of range for any sensible python list. I pushed a fix for that.

Wrote up what I did for EPUB exporter here: http://wolthera.info/?p=840