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

Is this still WIP, it looks good, can we proceed?

The idea is to remove some of the configuration possibility: for example only allowing the KoModeBoxDocker to be a left or right sidebar. (putting at the top and bottom was completely broken anyway so I don't think many people did it).

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 don't know why everyone wants tools to be above edit window. That's pretty old style when resolution ratio was 4:3 that's why they was arranged one above another. But i agree that it should be flexible to be horizontal or vertical as needed.

With the promo group we were talking about doing an announcement tomorrow. I already started a draft for the announcement: https://share.kde.org/s/gd2zkasmPZqZqsE (feel free to add any important features to it) and the full list you created will be added as a link for the people who are interested in seeing all the changes.

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

There is a mockup here: T12837 this is really WIP I just created the diff because I asked someone to help me with a part of the code and I needed to show them the code.

i believe Carl's been doing some stuff already, and as we had a bit of a chat about it on the promo chat last week, i'll tag promo in as well :)

Time for an announcement?
@Carl: If you want to handle it, I have a list of changes.
If not I put sometning on kde-announce-apps@kde.org.

My immidiate reaction is no.

I personally prefer the first one, and it's consistent with okular !156 from Invent and with T11579.
People from VDG seem to agree too

Hey @abstractdevelop do you have a matrix or telegram account to talk about the design on the VDG room or via private messages? I'd rather not spam unfinished mockups here like I did on the system tray task.

In T12787#227927, @danders wrote:

It's out, so frezzes lifted.
I have posted a changelog draft on calligra-devel, please reviw!

It's out, so frezzes lifted.
I have posted a changelog draft on calligra-devel, please reviw!

Thanks @manueljlin , that would be really nice. Your designs are always breathtaking. :D
I'm not very good in the design department, better at actually doing the code, but I'm trying to improve. :/

I can try to design something if you want. Also, if a task is related to design it should probably have VDG as a tag too
(btw sorry for not seeing the email earlier, you can always ping me on telegram if I take too long to see a task/diff)

Won't have time for a relase today, posibly tomorrow or Saturday.

Release in progress!
Feature freeze in effect, bugfixes only, please.

No objections from this side :)

Nothing much has happened lately, so...
I propose to create a beta release tomorrow,
with a final release Thursday 23th unless something serious pops up.
This means feature freeze from tomorrow, and
string freeze from Thursday 16th.

Ok, unit tests fixed,
There are a few on BSD that fails but these are just sanity checks for i18n, in case somebody does something 'stupid' with some Message.sh file, so I think we can live with it pt.
Seems BSD tail command is missing the tail -n +NUM variant so...

Thank you for clarifying @leinir. Actually, I did see the "Switch to Desktop" button, and that is the interface which I am suggesting be redesigned. That's really cool how it automatically transforms like that!

In T12837#223853, @abstractdevelop wrote:

I didn't know about Gemini! Yes, it looks nice, but the touch based QtQuick Interface seems to just be for viewing documents, and it seems like none of the editing features are implemented yet. But if that gets working, it will be really cool. :)

In the case of a tabbed interface, maybe something like this:

I also think that both interfaces need a bit of work. The QtQuick one is strongly inconsistent with other KDE applications. The QtWidgets one is not great, in my opinion, as the sidebar takes a lot of space and you can't hide it. You can move it on top, but it's hardly usable as a tabbed interface as contents are to tall and takes to much vertical space. I think a general redesign might be very useful to promote the application more :-)

Thank you @ognarb !
I have spent some time making a mockup for Calligra in Qt Quick (it's great for making mockups ;)). Here is how it looks:

@leinir has more knowledge than me regarding the QtQuick interface. At least I saw that a long time ago you could edit the text and the shaped while using it in some youtube videoi, but it seens this features was lost/disabled.

The former, I'd say. The key thing is that KoAbstractGradient isn't a gradient; it's a resource that provides gradients.

I didn't know about Gemini! Yes, it looks nice, but the touch based QtQuick Interface seems to just be for viewing documents, and it seems like none of the editing features are implemented yet. But if that gets working, it will be really cool. :)
For the Words/Sheets/Stage, I can't seem to figure out how to give it the tabbed interface. So maybe adding an option in the settings or making it default would be nice for beginners. It seems like it will just be a matter of tweaking some things, for example some of the buttons look a little funny in the tabbed and docked interface.
I don't mind helping with this, but I can't seem to find any documentation for the Calligra source and API.

Did you take a look at the Gemini interface? It is also Qt Quick based and more modern. The Qt Quick components are also used by the office suite in SailfishOS.

I think where leinir has landed is more doable than a frameworks.
Also if compiletime is a big hurdle, I see a couple of things that can be done:

• Remove pigment, see T5738.

furiously attempts to put the worms back in the can - Oh dear! ;)

As a newcomer, and only occasional contributor, my experience of getting the build up and running is that it's already a daunting process, made tractable only because the instructions are very good. Anything that simplifies these instructions is good, anything that complicates them is bad.

I sometimes find myself feeling this way about Frameworks too. A recent experience at a hackathon where I helped 8 students set up complete development environments from scratch reinforced this viewpoint. Not that I'm seriously recommending re-merging the frameworks, but I would like to challenge the notion that splitting a monolithic codebase across multiple repos is a boon to onboarding; I don't think it is. It may have other benefits, but I don't think onboarding is one of them.

As I have some free time due to the virus and I'm trying to get up to date.

In T12815#223428, @rempt wrote:

As an aside, I think splitting up kdepim into so many repositories was a huge mistake. Listening to David Faure at the onboarding sprint only confirmed that opinion. Having to work on half a dozen repos to add a single feature to kmail sounds like hell to me. I think it would be a mistake for Calligra, too, but don't pay attention to me :-)

As an aside, I think splitting up kdepim into so many repositories was a huge mistake.