I am believing that the colouration of "http://phabricator.kde.org/file/data/to7e46zbo7jhwg6mbwv4/PHID-FILE-7qs7usxqzpuvfwbsrgis/sheets_alt.png" is superior, because ascertainment of which tabs are active and inactive is significantly more easy than within "http://phabricator.kde.org/file/data/4mp4omhmpt3j7mxtin42/PHID-FILE-md7fdorexja3vakdh5to/sheets.png".

The first proposal that is similar to the interface of Microsoft's Word, and the interface that is present for Gemini are utterly unsuitable for Calligra, because they are not adherent to any of the appearances of current Qt software that has been created by KDE, and are consequently more inconsistent.

I come a bit late in the discussion, sorry about that :/
@manueljlin I kindly disagree with the proposed UI for words because it reproduces the same mistake as every other word processor (MS Word, LibreOffice Writer, probably Corel WordPerfect).
There is a very deep flaw in the WISIWYG world. When you set a piece of text in bold, this is 99% of the time not what you want to do. What you wanted to do is an emphasis of this text. The difference is subtle but major in user interface. I think there is a place in the word processor landscape for a style first word processor. No bold button, but emphasis style. Numbered list being harder to reach than a title style…
I'm not good at UX and UI design, but do you think there is a way to do that? Getting out of the Word box most UIs are in?

Since it is a graphics related program unlike rest of the suite, i was thinking karbon could be split into its own repo. Similar to krita.

In T12815#238382, @marcboocha wrote:

Just wondering, is there any use of karbon inside the suite?

Just wondering, is there any use of karbon inside the suite?
Also the stuff used by okular could be split out?

All painting of documents is done in points

In D15111#672155, @boemann wrote:

Even for line thickness it doesn't make sense to enable it in general. the image will change if you zoom in and out.

Even for line thickness it doesn't make sense to enable it in general. the image will change if you zoom in and out.

I miss something here, the idea behind the patch is to have pixel metrics in thickness, geometry etc. @boemann i got your opinion as to have configurable pixel units, is that right?

In D15111#671510, @boemann wrote:

Nothing prevents Karbon from having a m_pixelUnit with ppi collected from a widget for user control

and the use that unit like inkscape does.

But what this patch does is enable it in general with an arbitrary chosen ppi value

Why not measure in apples too - it will make as much sense ..

Nothing prevents Karbon from having a m_pixelUnit with ppi collected from a widget for user control

In D15111#671492, @boemann wrote:

And that is why this proposal should be rejected as is

pixels is not a unit unless assigned a ppi on a case by case basis

and thus it needs to be something requested and not EVER something that is always available !

And that is why this proposal should be rejected as is

This does need DPI configuration for pixel units to be useful. Or maybe you could just set the DPI to 96 for pixel units since that's probably what most people want.

Rebase on master

Thank you, i should wait ship it, but just got Dag comment as it is.

Incidentally, while this was committed before i could test it, i can confirm that it works fine with Calligra Gemini

Seems fine, i'll push pageapp/flake changes as part of this review in 3.2 branch and master, refactoring main window in separate commit master only.

This seems to work fine, I also tested with only pageapp/flake changes.
Imho I would prefer to separate the pageapp/flake and KoMainWindow changes into separate commits,
The pageapp/flake changes should go into 3.2 branch followed by a swift release.
I don't think the KoMainWindow changes should go into the branch as it only removes unused functionallity.
I'm a bit in two minds if it should go in at all actually, so I'll leave it you or maybe somebody else has an opinion.

@danders i saw your patch on my email. d->viewportWidget->canvas()->removeEventFilter(this); fixes the issue but i still prefer all of refactoring code. Please test on all components does not have regressions.

We should call removeEventFilter or found exactly why signal is emitted in destructor.

In D29542#668076, @anthonyfieroni wrote:

`d->rootPart->createView(doc, this);` Creates the view which parent is main window.

Ahh, yes, but then...
Why will it not crash if a new document is set so that d->rootView != 0 ?

d->rootPart->createView(doc, this); Creates the view which parent is main window.

Hmmm, it seems to me you are creating a leak in your lines 544, 545? (Have not tested, I might be wrong)

Add more context

Looking at these, D29264 tab style (as long as it has a different background color for inactive tabs is probably the way to go, or else there might be too many blue rectangles on the screen at once.

Should I also do Plan, Karbon or KEXI? And the new document dialog?

Calligra Sheets

Just my two cents, this might be much better for a simple reaon: the categories can be too many (think Office and the tabs that show up when you edit images/tables/charts/etc.)

Damn I would love to use an office suite that looked like that again. Reminds me of Apple's Pages which I loved, and sorely miss.

Some more mockups:

In D29242#658883, @boemann wrote:

Well you are definitely in the right class to make such changes.

The thing is the current code was made to adopt to many different user wishes - so the user could choose

What you are doing is to throw all that away - would it be impossible to have this new way as a mode so we don't throw away the old but enhance it with something new.

I don't mind if the new mode becomes default

I forgot about this diff. Now that I looked again I found a flaw in the migrations: QDomDocument only supports valid XML files but there are valid HTML files that aren't valid XML files. So probably QDomDocument is not a solution :(

The announcement was created and shared on the social media:

• More work in progress change