In D9148#176859, @wojnilowicz wrote:

Isn't KMyMoneyUtils relatively big dependency? If yes, then I would refrain to use it in plugins at all, as it would add significantly to the size of simple plugin.

I can't because kmymoneyutils is in a separate library and not exposed/exported.

Fix Christian's observation in kmymoney/plugins/qif/import/kimportdlg.cpp that I forgot

Answer to Thomas requests

In D9148#175499, @christiand wrote:

Hi Olivier,

why do you download and save the data into a file and then read it again? In my opinion it is easier to simply use the QByteArray returned by StoredTransferJob::data() directly.

Best
Chris

Fix upload issue

Fix upload permissions and bug

Remove debugs

Fix a QTemporaryFile problem in my porting

Other thought for food (in jekyll) :

Don't put long texts as it was on the previous KDE.org

In T6854#109433, @prh wrote:

I use KMail but not any other PIM applications. My layout has the folder list down the left, then the message list above the current message. I already resist developers' attempts to waste my valuable screen space, and I'd resent losing any more of it to bells and whistles I'll never use, or to daft ideas of modernity.

Please, KISS - no, I'm not calling anyone stupid, just reinforcing that timeless principle, which applies to UI design just as to all others.

In T6854#109348, @rjvbb wrote:

I don't think it's too much space lost.

It's still an unnecessary space loss. The Kontact statusbar is empty and unused except for the "Ready" word and the summary progressbar during syncs, adding a new toolbar (or similar) is, well, someone did make that comparison with a M$ product already...

In T6854#109017, @rjvbb wrote:

I also agree that Kontact application buttons should be moved to the bottom left as Outlook does.

The ones where you choose which actual application you want to use? IF moving those to the bottom it should be into the status bar, they should NOT take up additional vertical space.

Vertical space is at a premium on most all monitors, much more so than horizontal space.

In T6854#109010, @andreaska wrote:

I would have this 3 buttons instead of bottom left (additional toolbar) to the top toolbar (as there is already an toolbar for the apps). as less different UI elements as possible. In addition you don't have that much actions in the main top toolbar in a PIM suite.

To solve this particular problem (Where to put the Kontact toolbar to switch between views), I would take inspiration from MS Outlook, that solve it quite nicely I think:

The code to generate qch files is present. It is not activated currently as I could not fully test it.

Use the PIM_VERSION variable

update eventviews lib version

Update lib version and add CMakeLists.txt to the patch

Increase lib version

In D7500#139749, @mlaurent wrote:

You exported/install Helper so you need to increase lib version => increase it in CMakeLists.txt top level.

Update to follow @dkurz comments

Follow @dkurz corrections

Misuse of arc... sorry for the noise

I saw that on the Vdg Telegram group.

At the time I thought about merging it but we would have to re-document everything in doxygen , which would be completely different from what upstream cmake does.

In D6604#123635, @sitter wrote:

related to D6603

@ochurlaud I hope this will not break api.kde, given ECM hasn't had a metainfo.yaml previously it seems to have some sort of special arrangement?

Yes, there might be a second iteration to do.

In D6368#119511, @mlaurent wrote:

Hi,
now it's just a rectangle ?
It's more modern ?
For me it's better with actual code because you can see when event start/end when you see round corner.
With your code we don't know it if we don't select one day before one day after.

Really I don't see the improvement here.
I am not a designer but just a rectangle I don't know if it's an improvement.

I am against this changes...

In D6368#119467, @ochurlaud wrote:

Remove unused parameters from the function signature

Remove unused parameters from the function signature

In D6368#119246, @winterz wrote:

I applied the patch locally and tested it. I think I like the new look better but I'm not sure.
Please post screenshots so we can make it easier for other folks to compare the before and after.

... also you have some unused argument warnings in drawEventRect(). please fix those warnings.

In D5275#99677, @antonanikin wrote:

Hi, Olivier.

Your QCH files displayed normally but with one bug - broken links for some JavaScript code. For example open KTipDialog class doc from your Frameworks file. Then try to click (open) Public Member Functions inherited from QDialog - nothing happens :( See QCH file from D3261 - for KAutoSaveFile class for example such actions works well.

Corrected antonanikin issue

Update: Order alphabetically the libs in a product

Here 3 examples. Frameworks only contains KApiDox, KConfigWidgets and KItemModels. I could have generated all of them of course...

I add some people who may be able to tell me if the output can be used in the kdevelop generation (because I heard you use it).

In T5578#84272, @lydia wrote:

This looks like something someone else can help with. I believe the following questions are open for someone to help out:

• Where is the testing site and how do they get access?

Type in your browser: https://www-devel.kde.org/ and try to login, then ask me for admin rights, which I'll do. Then, like a virus, new people can ask new admins to get rights

• Which kinds of pages do you need populated? From where? Entirely new content? Just copying over? Copying but with tweaking?

If I recall correctly we said no direct copy, so maybe just relevant pages with some hints of what content is needed? (hints like bulletpoints)

In D3048#56488, @mart wrote:

i am in favor of this chane, but i think the real reson of the breakage should be investigated as well, uf there may be problems in kconfigwidget itself

One draw back of this way is that if Default.colors is erased or not found, there is no "Default", and in case no *.colors are found, the kcm will be empty...