[gemini] Remove "template://" scheme from file name
ClosedPublic

Authored by anthonyfieroni on Aug 31 2019, 8:14 PM.

Details

Summary

I don't know why they are added but it cannot be opened.

Test Plan

You can now open the templates.
Create file still not work it tells "Cannot open "/newfile:///""
Did someone knows how should it look?

Diff Detail

Repository
R8 Calligra
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
anthonyfieroni created this revision.Aug 31 2019, 8:14 PM
Restricted Application added a project: Calligra: 3.0. · View Herald TranscriptAug 31 2019, 8:14 PM
Restricted Application added a subscriber: Calligra-Devel-list. · View Herald Transcript
anthonyfieroni requested review of this revision.Aug 31 2019, 8:14 PM
leinir added a comment.Sep 1 2019, 9:40 AM

The idea is that the template protocol gets caught by the components, which marks the file as new, resets the filename and so on (the way you would expect a template to work). Doing it this way just opens the template as a file, and requires the user to manually do the save-as thing... Unless you are trying to actually edit the template, this isn't the solution... Create file will be something similar.

That makes sense but none handle that schemes or should be responsible for that?

leinir added a comment.Sep 2 2019, 8:02 AM

That makes sense but none handle that schemes or should be responsible for that?

It's handled by the components: https://phabricator.kde.org/source/calligra/browse/master/components/impl/TextDocumentImpl.cpp$225 for text documents, and https://phabricator.kde.org/source/calligra/browse/master/components/impl/PresentationImpl.cpp$171 for presentations

Test plan:

  1. Open existing document -> works
  2. Open template document -> works
  3. Create new document -> works
leinir requested changes to this revision.Sep 2 2019, 5:27 PM

Something tells me there's going to be problems on windows if this gets done... since that is the precise reason that code exists in the first place: https://phabricator.kde.org/R8:c1866b590bd6103fdf118558834104be2737cca4

however, if it could be made windows-only, that would work for me. That would likely require exposing that from MainWindow::initTouchView() (where there's already some windows detection code and such) Something like adding an osIsWindows root context property and setting that to true, and then checking for that in the if statement there in addition to the filename check, ought to do the trick.

Also, thanks for taking an interest in the code, it's really great to see work happening on it :D

This revision now requires changes to proceed.Sep 2 2019, 5:27 PM

I can't test, but it should be fine.

leinir accepted this revision.Sep 7 2019, 8:10 AM

Long as that works on linux, that ought to do the trick, yes :) (probably ought to have been there to start with anyway)

This revision is now accepted and ready to land.Sep 7 2019, 8:10 AM
This revision was automatically updated to reflect the committed changes.