Thanks.
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Feb 14 2019
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
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
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
Feb 11 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
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
mistake
Feb 5 2019
Ok, it's accepted so please commit/push/land
Feb 4 2019
- fixed whitespace, sorry
- Made windows show even without export-pdf flag
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
- 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
What have I Done:
- Added slots in KoApplication to handle pdf and print.
Jan 29 2019
- Removed unnecessary newlines
- Made slotFilePrint depend on signal loadCompleted to avoid it running before remote file being complete
Jan 28 2019
Well, unit tests has been added that fails without this patch and passes with this patch.
If there are more test cases needed, please add them so that we can get this patch committed soon...
Jan 27 2019
In D18466#400507, @niccolove wrote:I'm not sure on how to do that, do you have any tip?
openDocumentInternal is called by openDocument, which is called in KoApplication just before checking the arguments. When it sees the print argument, it calls slotFilePrint. openDocumentInternal downloads the document in async. Should it be made not async, or is there another way to make it wait until the other process ends? Also, "slotLoadCanceled" is already implemented, or were you talking about something else?
Jan 26 2019
So just don't call slotFilePrint connect loadCompleted to slotFilePrint. When openDocumentInternal downloads the document it fires signal of finish, just connect to slot of opened it.
I'm not sure on how to do that, do you have any tip?
openDocumentInternal is called by openDocument, which is called in KoApplication just before checking the arguments. When it sees the print argument, it calls slotFilePrint. openDocumentInternal downloads the document in async. Should it be made not async, or is there another way to make it wait until the other process ends? Also, "slotLoadCanceled" is already implemented, or were you talking about something else?
Jan 25 2019
In D18466#399471, @danders wrote:Probably we need to start printing in a slot connected to KoMainWindow::loadCompleted() instead.
And to be safe, we also need to handle loadCanceled().
I think the problem is that slotFilePrint() is called (in KoApplication::start()) before the document is actually loaded.
Probably we need to start printing in a slot connected to KoMainWindow::loadCompleted() instead.
And to be safe, we also need to handle loadCanceled().
And the same for exportToPdf, I think.
Jan 23 2019
I tried differents files (locale and remote, opening and printing), and everything works okay. Other applications work normally, but calligrasheets still crashes when trying to print a remote (odt) file - but I can see the file is downloaded correctly, so it looks like a different problem (calligrasheets manages printing?).
About removing features from slotLoadCompleted, it is important to notice that it is only called by openDocumentInternal itself, so that should not be a problem.
Please check with loading a normal document,. The same concerns now applies to slotLoadCompleted - especially since you have now removed functionality from it.
I've seen that openDoumentInternal is called every time a remote document is used as input. I'm not sure if it's also used in different scenarios.
- Moving the if from slotLoadCompleted to openDocumentInternal.
Yes that description helped a lot, and you are doing great. Keep up the good work :)
At this point my only worry is that the setRootDocument in openDocumentInternal makes the check for opening a new window in slotLoadCompleted useless. Moving the whole if statement from slotLoadCompleted to openDocumentInternal also works, and could avoid to replace the root document instead of opening a new window. It makes more sense, now that I think of it.
Sure.
Calligra was crashing because the method "slotFilePrint" called "rootView()" that tried to return the first elements of "d->rootViews". The problem is that such list was empitya, as SetRootDocument was never called: that method is called in openDocument but not in openDocumentInternal. I therefore added that function and it now works. But, when slotLoadCompleted is called (that is, after slotFilePrint), there's a check to open a new window if there's already a non-blank document. Since the root document was already set, it opened a new window with the same document. I therefore added the conditions of the two documents being different.
I hope I've been clear, this is one of my first commits here :-/
Could you please describe what you have done and why
- Fixed typos
Jan 22 2019
Jan 17 2019
Ran this patch against new unit tests and it fixes all the expected ones, namely those where all cells in first row is merged with cells in second row.
Test results without patch: https://build.kde.org/job/Calligra/job/calligra/job/kf5-qt5%20SUSEQt5.10/lastCompletedBuild/testReport/projectroot.libs.textlayout/tests/libs_kotextlayout_TestTableLayout
See uploaded file for result with patch.
Jan 15 2019
absolutely
Even if they do not all pass, I think they should be commited if the tests/methods are ok and the reason for not passing are genuin bugs, no?
Jan 10 2019
Add a test that trigger a loop in the table layout
Jan 8 2019
No, all do not pass, generally when the first row is merged, layout fails.
(I am trying to provoke problems similar to bug 381341 that we have tried to fix in D15428.)
Looks like a good first start to me - do they pass currently? - if so then i think they should be pushed
Not trivial (for me) to get data out of layout so it is hard to create robust tests.
I don't think I have been able to create a test to simulate the loop excactly.
Also, uncertain wether the MockRootAreaProvider is sufficient.
Any ideas/comments wellcome.