I fully support this - but I was tol long ago that it actually isn't so easy to do as it will depend on where things are installed or so - but perhabs now that we use json it has become easier.

One thing tohugh - it shouldn't be an empty document - I wan to get away from this as we need all sorts ofinitial setup, and i want to remove the custom dialog for the same reason - but anyway the default startup document should be the blank template

but as i said i fear it's not such a low hanging fruit at all

Would it be a good idea to have UI/UX experts look at this as well?
Because I personally prefer the current UI if I just start the application binary itself, without any parameters. So if we agree on changing the default start UI, I would like to keep the current one as option at least, so I can stay happy.

Now, the "frequent" in "frequent scenario" is measured how? :)

Please rethink the 1 step in the scenario you gave, "Run a word processor, without delay": How do users start the word processor? By selecting some item in the UI of their workspace? If so, what do they actually mean and expect when the chose that item? What about having that item having a more specific meaning than "start app into whatever state"?

Looking at myself, I found I have certain set of different subtypes of richtext documents I create (when talking about page-centric text documents), and most are not started from just plain empty sheets, but have a dedicated predefined structure and predefined content: generic formal letters, reports of several kinds, documentations.
So most of the time I use a richtextdocument editor for a new document it seems I do not need a blank sheet or another single type of template to start from. But instead first need to decide on the subtype of richtext document I am creating.
So the proposed new UX here would be a regression for me and people who also work like me (e.g. in most offices, the real world work places I mean here, template-based document creation surely is widespread for improved processes). Thus the proposal should be an optional start variant IMHO, at most.

While talking about it, I personally dream of a workspace which is not just an app starter, but integrated in my workflows. So for Plasma I have some draft plasmoid and runner which allows me to start creating & editing new documents by typing "new letter" or "new $other-doc-template" in krunner or selecting a template from a plasmoid drop-down, which then results in the matching app being shown with a new document created from the selected template, so I can type away. Hello document-centric UI :)
It is currently stuck in making this a general-purpose thing, so it can be used to create all kind of new documents with all kind of apps. Making things generic is not easy, especially in a wild world :)
It also needs a patch to Calligra, I should brush that over and hand it in for review finally in any case, so expect a review request soon.

In T665#15282, @kossebau wrote:

Would it be a good idea to have UI/UX experts look at this as well?

Yes, though it would be unfortunate to repeat this -- "they" apparently did: ​
​for StarOffice, OO.org, LO , and MS Office at least :)

Because I personally prefer the current UI if I just start the application binary itself, without any parameters. So if we agree on changing the default start UI, I would like to keep the current one as option at least, so I can stay happy.

Sure, as always ​I am ​OK with options that change the "worldwide" default.

Now, the "frequent" in "frequent scenario" is measured how? :)

Please rethink the 1 step in the scenario you gave, "Run a word processor, without delay": How do users start the word processor? By selecting some item in the UI of their workspace? If so, what do they actually mean and expect when the chose that item? What about having that item having a more specific meaning than "start app into whatever state"?

Looking at myself,

Look, without a persona it's to easy to express just own preferences​.
What I explained is a "Jane User" persona who start typing on a plain white paper. No templates, no customization. This concept is 30+ years old.​ if we want to break into the mainstream...

I found I have certain set of different subtypes of richtext documents I create (when talking about page-centric text documents), and most are not started from just plain empty sheets, but have a dedicated predefined structure and predefined content: generic formal letters, reports of several kinds, documentations.
So most of the time I use a richtextdocument editor for a new document it seems I do not need a blank sheet or another single type of template to start from. But instead first need to decide on the subtype of richtext document I am creating.
So the proposed new UX here would be a regression for me and people who also work like me (e.g. in most offices, the real world work places I mean here, template-based document creation surely is widespread for improved processes). Thus the proposal should be an optional start variant IMHO, at most.

While talking about it, I personally dream of a workspace which is not just an app starter, but integrated in my workflows. So for Plasma I have some draft plasmoid and runner which allows me to start creating & editing new documents by typing "new letter" or "new $other-doc-template" in krunner or selecting a template from a plasmoid drop-down, which then results in the matching app being shown with a new document created from the selected template, so I can type away. Hello document-centric UI :)

I am afraid this drags Calligra again to the Plasma universe, too closely.
I believe integration into workflows shall be a separate code installed optionally (maybe by default for Plasma users). This alone makes the integration not worth developing - it's just hell to maintain and do well.

It is currently stuck in making this a general-purpose thing, so it can be used to create all kind of new documents with all kind of apps. Making things generic is not easy, especially in a wild world :)
It also needs a patch to Calligra, I should brush that over and hand it in for review finally in any case, so expect a review request soon.

As a secondary feature I believe this is not worth the effort but your opinion can be different.

Unless I have seen and read the reports of the UI designers of MS, LO & Co. and their reasoning for why it is like this, it seem just blind copying of their UI, which does not make sense to me and my needs.
And otherwise I also would not need to work on Calligra, if LO UI would already be what I want.

Surely helping people to transition from learned & trainred usage patterns (first start app, then go to app menu to find template, select template) is something that can be useful, when trying to gain new users for the only sake of gaining new users. For them having this variant makes sense, they would possibly think something is broken if there is no empty white sheet seen after app start.

The plasmoid and krunner I talk about is completely decoupled from Calligra code, so no need to fear dependencies.
The integration hook needed in Calligra for which I will send the patch is generic as well and useful for other cases. Don't judge too quickly without having seen the details :)

I imagine this motto:

Make simple, familiar things easy, awesome complicated things -- possible.

In my opinion for now we're more heading towards the latter what is a major mistake.
We have the code, design and all toys. The latter part is possible to have to meet the needs that bring you/us in Calligra. But this big project needs users and common sense.