In D19216#421689, @rjvbb wrote:That is actual a valid point, although in say Krita with transparent pixels a checkerboard is shown.Heh, I've had the opportunity to work closely with professional infographists so I picked up a thing or two about using applications like Illustrator and InDesign :)
How to indicate a transparent area of an object is yet another subject, with a related but not identical purpose.
That said it might make more sense for this "testing background" to be part of the document and not a general setting - if the use case is as you say then the testing background would also be different for different projectsTrue. I was reacting to *re*moving a setting completely, not to moving it to a more appropriate context.
- Queries
- All Stories
- Search
- Advanced Search
Feed Advanced Search
Advanced Search
Advanced Search
Mar 14 2019
Mar 14 2019
Mar 7 2019
Mar 7 2019
Feb 28 2019
Feb 28 2019
That is actual a valid point, although in say Krita with transparent pixels a checkerboard is shown.
In D19216#421654, @rjvbb wrote:No, the canvas is part of the document and must never be themed. The canvas background is as much part of your drawing as any line you put on it.This hasn't been sitting right with me and I finally realised why.
That statement is true when you work with a real canvas and draw/paint/whatever directly onto that. If you take a grid paper the grid will become part of your art, but does Karbon print the grid which you can have it show (except possibly via an option)?
In drawing applications, the canvas is NOT part of your art, but simulates the canvas you'll be printing on. It's a backdrop layer that sits behind/below the lowest layer you can draw on. If you plan to print on a coloured piece of paper, or one with a canvassy texture, you'll probably want to adapt your virtual canvas so you can incorporate the physical canvas properties into your design. But you don't want that virtual canvas to print as that would be a waste of toner at best...
That is actual a valid point, although in say Krita with transparent pixels a checkerboard is shown.
That said it might make more sense for this "testing background" to be part of the document and not a general setting - if the use case is as you say then the testing background would also be different for different projects
That's not to say that the virtual canvas should not be exportable at all: you'd want to be able to include it when generating a PDF (SVG, JPG, etc) format version for use in on-screen only presentations. Of course you could just add a backdrop layer in that case.
I'm not aware that Karbon has the equivalent of a slide/page design feature where you can define how each page will look. That could look be used to be achieve what I describe here but in Karbon that layer should probably not be printed by default (just like it isn't in presentation apps, IIRC).
No, the canvas is part of the document and must never be themed. The canvas background is as much part of your drawing as any line you put on it.
Feb 26 2019
Feb 26 2019
no
Feb 25 2019
Feb 25 2019
Can we get a conclussion to this?
@Camilla Have you come up with any more unit tests?
totally agree about not theme'ing canvas
In D19216#417502, @rjvbb wrote:Canvas color:
I don't quite see what it is for. You can set a background color for the canvas but it is only for the views, it is not printed.A custom canvas colour feature doesn't strike me as odd, nor that it isn't printed (printing it WITHOUT setting a dedicated option would seem wrong to me).
What about when you use an inversed theme, isn't a custom canvas colour required then if you want to see your black line art on a light (white) canvas?
No, the canvas is part of the document and must never be themed. The canvas background is as much part of your drawing as any line you put on it.
Feb 22 2019
Feb 22 2019
Canvas color:
I don't quite see what it is for. You can set a background color for the canvas but it is only for the views, it is not printed.
In D19216#417288, @rjvbb wrote:This would indeed be great to have; even a page selector when importing a multi-page document would be an improvement (the Adobe Illustrator version I've use had that; IIRC it would just leave all other pages of the document alone).
You should also test with PDF documents; in my experience Karbon 3.1 works well enough with them.
Yes, pdf docs work, it is almost 100% handled by poppler.
...
A lot of code was duplicated between pageapp and karbon
and has been removed from karbon:Shouldn't that be a separate change - or does multi-page support come automatically with this change?
Well, my initial thought, but there was going to be quite a few intermidiate solutions mainly because
the KoPACanvas cannot be subclassed, so I decided to do everything in one go.
This would indeed be great to have; even a page selector when importing a multi-page document would be an improvement (the Adobe Illustrator version I've use had that; IIRC it would just leave all other pages of the document alone).
Feb 21 2019
Feb 21 2019
Thanks for the review, I will work next on libs/{pigment,version,widgetutils}.
Hmm, maybe wait with pigment, according to rempt, only krita actually used it.
I haven't looked into it, but if that is the case probably we should dump it.
In D19132#416519, @danders wrote:Ok, I can't say I have scrutinized every change, but...
Could you give a heads up when you continue with other parts or else there may be merge problems.
I'm working on karbon and pageapp atm, so please keep off :)
Ok, I can't say I have scrutinized every change, but...
Could you give a heads up when you continue with other parts or else there may be merge problems.
I'm working on karbon and pageapp atm, so please keep off :)
Feb 19 2019
Feb 19 2019
Fix build
- Revert foreach modifications
- Fix some forgotten 0 as nullptr instances
There is an issue with Qt's foreach, however if the author would be so nice as to check that this version using C++11 iteration does not break building on Windows, then it can go in... Though, yes, it most certainly wants testing, and i don't currently have a functioning windows build system. 2890f2a929034d613c4b4a8f3e6ad77c23162d41 is one of the commits which did the q_foreach/for loop change previously, to see what actually got changed.
Hmmm. wasn't it somethng with ms windows and for loops, leinir?
Also, I think there may be detachment issues with them, clazy can tell.
There is a qAsConst() solution but that is not supported in the qt version we need to support.
If there are issues, maybe drop the for loops for now.
Feb 18 2019
Feb 18 2019
Feb 15 2019
Feb 15 2019
This was accepted, but was it also committed yet?
Feb 14 2019
Feb 14 2019
In D18994#412049, @leinir wrote:A quick note that you kind of got the name of the suite wrong in a few places, it's called Calligra, not Callibra :)
Thanks.
A quick note that you kind of got the name of the suite wrong in a few places, it's called Calligra, not Callibra :)
Thanks, I'm checking it out now...
Just a couple of things:
Keywords needs to be on a separate line to have effect, see https://community.kde.org/Infrastructure/Git/Hooks
Also FIXED-IN is nice to add.
Now compile with checkXML5
ognarb added reviewers for D18994: Update screenshots for Calligra sheets 3.1: Calligra: 3.0, Documentation.
Feb 13 2019
Feb 13 2019
It seems like it landed. Please tell me if I screwed up anything.
BUG:358581
remove more trailing whitespace
remove trailing whitespace
Please remove trailing whitespace.
I definitely don't want this docker default on, but if as you say it's default off then i guess your change is okay - i'll take your word for it
In D18466#411248, @boemann wrote:Dan can you please reply - I'm fine with the account but I can't reply to Ben as I am not able to send email
Dan can you please reply - I'm fine with the account but I can't reply to Ben as I am not able to send email
Feb 12 2019
Feb 12 2019
Ok thanks for the review, I will retry to compile calligra master and see if it's still work and then land this diff. 😄
I do not have a developer account. I requested one some days ago with no answer yet.
I like it
It's good to +1
In D18963#410791, @ngraham wrote:The first image is the new version, not the old version. :)
The first image is the new version, not the old version. :)
It is pretty rough. It works, but needs better looks. The toolbar section now takes up almost half of the screen.
Certainly a visual improvement! +1!
Remove debug output
ognarb added reviewers for D18963: Improve KoModeBox display in horizontal Mode: Calligra: 3.0, VDG.
Feb 11 2019
Feb 11 2019
Feb 10 2019
Feb 10 2019
Added missing "h". Thanks for noticing that.
In D18866#408435, @danders wrote:What about the other check_function_exists, should they also be changed?
Replaced other check_function_exists invocations
Feb 9 2019
Feb 9 2019
What about the other check_function_exists, should they also be changed?
Also, do you know when check_symbol_exists was introduced?
We still use cmake 2.8.12.
Feb 8 2019
Feb 8 2019
mistake
Feb 5 2019
Feb 5 2019
Ok, it's accepted so please commit/push/land
Feb 4 2019
Feb 4 2019
- fixed whitespace, sorry
- Made windows show even without export-pdf flag
Jan 31 2019
Jan 31 2019
- Made window show on pdf print and removed trailing spaces
Yes, close.
When export to pdf, the mainwindow is not shown and since we don't exit, the app will hang.
You need to invert the check in KoApplication line 460 so the window is shown.
Jan 30 2019
Jan 30 2019
- Removed connection between job and exiting; added todo
Yeah, well there are some half done designs in here :(
I have some doubts:
- Moved QString pdfFileName to KoApplicationPrivate
Regarding the completed slot, the doc says:
--print Only print and exit
--export-pdf Only export to PDF and exit
In D18466#402362, @niccolove wrote:This solution is Qt <5.12 friendly
This solution is Qt <5.12 friendly
- Adding pdf filename as propriety of KoApplication
regarding the lambda connection - nice to see that you use the version with a "still alive" argument - but I fear this requires a qt version higher than what we currently support - could you please check