@atem Sorry, what dropdown? I see buttons for "Install KMyMoney >" and "Download" which both go to the Download page, but no dropdown. Is there a draft home page? (Minor issue - all the items on the menu line keep the same menu line, except for "Donate" which is the main KDE Donate page, not KMM specific. I don't remember if we ever had a KMM Donate page.)

@wrobelda Ok if you have more details on how you would do it, I am interested. Also @ostroffjh what do you think about the dropdown on the homepage ?

Checked the 5.x branch code and can no longer find any usage of "${DATA_INSTALL_DIR}/appdata/"

@atem I don't see why this would be a problem at all for automation, we can maintain multiple stable release placeholders in _config.yml for both KMyMoney5 and KMyMoney4 stable branches and it is absolutely not a problem to make Gitlab Pipelines aware of that.

This is outdated by now.

All theming related issues were migrated to Invent: https://invent.kde.org/office/kmymoney/-/issues

Discussion moved to Invent: https://invent.kde.org/office/kmymoney/-/issues/16

The discussion has moved to GitLab: https://invent.kde.org/office/kmymoney/-/issues/2

Discussion moved to Invent: https://invent.kde.org/office/kmymoney/-/issues/14

@wrobelda Since there is multiples versions, you cannot use something like a Git tag to replace a placeholder in the _config.yml file.

The discussion has moved to GitLab: https://invent.kde.org/office/kmymoney/-/issues/2

The discussion has moved to GitLab: https://invent.kde.org/office/kmymoney/-/issues/4

When it comes to automation, it is a perfect job for GitLab pipelines which can handle additional steps post-release. What I suggest is that the pipeline auto-updates the version.yml file with most recent version, and the version.yml to be incorporated into the html.

Ok then in that case may I suggest to do like Vscode guys did : https://code.visualstudio.com/

I wish it were that simeple :-) Although we have both current (5.0.x) and vintage (4.8.x) releases, we have several "versions" of each, especially depending on platform. For Linux, it's source, appimage, or get it from your distribution. For Windows, there are multiple paths, depending on build system (craft or cross compiling) and build system (autotools or msys, and I may have these wrong). There's also MacOS. That multiplicity is unfortunate, but due to not all combinations being able to deliver all functionality and components successfully. However, I think it would be really cool if we could do something like LibreOffice - a drop down for each version with an entry for each available download. That would complement and not replace the current different page for each build type with an entry for each version - especially the CI services with daily entries. Bottom line, however, is the simplest thing we need is just to have the most recent 5.0.x and 4.8.x releases listed, perhaps with release dates, on the main page.

@tbaumgart ok then no problem, we can do something like Libreoffice : https://www.libreoffice.org/download/download/

@atem Don't worry to much about the enclosing HTML. As I mentioned, that was the q&d way to get the jekyll supported version going. It's the content that should be kept. We don't care if it comes out of a config file (preferred) or not. I agree, it is easier to maintain. Regarding the versions: we have a latest based on KF5 (stable) and one on KDE4 (vintage is a cool name). The versions available for download maybe different, depending on the OS environment. Here is how we displayed different versions in the old days of the project (Example).

@ostroffjh, Still I don't get what you mean. For Plasma Desktop, it's written "Latest Release: Plasma 5.18 LTS" even if they do fixes older releases. So just a variable in _config.yml like kmymoney_latest_version: 5.0.8 and display it in the homepage is easy. If you need something more advanced, I need more details how you want it displayed.

@atem in case you need to adjust the HTML and want to convert it to markdown, please feel free to make suggestions. This seems to be a leftover from the conversion to jekyll.

@atem Development is done in master branch, so no version numbers there. However, we do make releases from both 5.0 and 4.8 branches.

@ognarb I can do it, I am just confused about "Multiple branches should be supported (stable, unstable, vintage, ...)".

I'll take care of landing it but this may only happen after the repository has been moved to its new location over the weekend.

Added the fix for incorrect Next button tooltip messages on the Schedule page.

Simply add it here.

OK, I found it.
The 2nd last line of the isComplete() method should be d->m_wizard->d_func()->m_nextButton->setToolTip(msg); instead of d->m_wizard->d_func()->m_finishButton->setToolTip(msg);
Now the tooltip message informs the user why the Next button is disabled.

I suppose that the minimal fix to prevent the crash is the best approach here, and the issue of notifying the user of why an action is disabled can be deferred for later discussion of a consistent approach.

@tbaumgart, That's right. I also investigated those #if 0/#endif lines to find out why they had been added before I decided to bring those two payment methods back and found no good reason. It might well have been only temporary and the author forgot to revert the change.

@ostroffjh, I agree that your concerns are important. I have just skimmed through the code and came acrosss something that may render useful.
There is a virtual method isComplete() in KMyMoneyWizardPage class.

/**
  * This returns, if all necessary data for this page has been
  * filled. It is used to enabled the 'Next' or 'Finish' button.
  * The button is only enabled, if this method returns @p true,
  * which is the default implementation.
  *
  * @retval false more data required from the user before we can proceed
  * @retval true all data available, we allow to switch to the next page
  */
virtual bool isComplete() const;

The method is overridden in subclass CreditCardSchedulePage which is changed by this patch.
It seems this approach works as expected on the previous page:

I wondered who added the #if 0 / #endif and traced them back into 2009 but could not go back any further. They existed every since.
It certainly does not make sense to skip adding a method and then later on make it the current one (2nd last line of this method). That is simply wrong. So the fix to add those methods seems valid to me.

I defer a decision to Thomas, and consistency across the app is good. The issue of how to notify the user what is blocking the desired action is a more widespread problem, and might be better deferred until it can be addressed in general, and not just in specific cases. (That has mostly arisen when trying to delete something, and it is not clear what is preventing that.)

The patch also disallows the user to intentionally set empty payment method. Empty method is not listed. Therefore I consider the fix quite solid.

In D29776#671741, @ostroffjh wrote:

What about just refusing to allow to complete the creation (instead of crashing) unless a payment method is selected, but not set a default type?

What about just refusing to allow to complete the creation (instead of crashing) unless a payment method is selected, but not set a default type? That does raise the same issue we have elsewhere of how to inform the user of why the action is disabled - but I suggested in another bug using some sort of notification or status area, especially if there was only one remaining reason the action could not be completed.

Yes, will do. Just did not find the time to do it.

@tbaumgart, thank you for your acceptance. Could you please land the patch for me? I do not have git push permission.

Removed unnecessary function declaration.

Added the requested changes.

Thanks :) I really like to see that charts work as expected.

I see, you get a kick out of this charting stuff. Cool.

Before fix:

Simplified c'tor arguments. Removed unnecessary if statements. Added indentation.

With the priceless help from @tbaumgart I managed to find a solution. Please find attached the final version of the patch.

I have done some more testing and I realized that precision (number of digits after the decimal point) is subject to change. In fact, account balance history chart is pretty straightforward but the code that I worked with is also used with configurable charts in reports. Precision can be changed in the Range tab of the Report Configuration window.
My previous patch created yAxis by calling new KReportCartesianAxis(loc, m_precision) whereas it should be new KReportCartesianAxis(loc, config.yLabelsPrecision()).

0.0 is quite a special argument for the logarithm. I made one last change adding support for this case.

Also there was a todo comment in the code I have removed, so thought it to be appropriate to take care of it lest it be missed out.

/ @todo this might also need some vertical adjustment in case of a horizontal line
/ see below how this has been solved for linear graphs

Indeed, support for logarithmic axis type was required.
Now I think the code is robust and complete. Now I'll just wait for the final review from you :)

Still looks OK to me. Push it.

There is one thing I overlooked in my previous revision. I have just tested my changes against a new account with clear history (empty ledger). It leads to a horizontal-line chart that is drawn incorrectly if no custom grid extension is made. The conclusion is the original grid extension code is here to stay. I have just moved it from void KReportChartView::slotNeedUpdate() to the bottom of void KReportChartView::drawPivotChart( ... ) and I refactored a little bit. Sorry for messing around in this already accepted patch. The good thing is labels are now printed correctly even when one zooms a horizontal-line chart :)

Thank you, @tbaumgart for your time spent reviewing my changes. I have amended my commit message with tag "BUG: 420767"

Do we have a bug entry for this one? If not, please create one and add

Looks good to me.

Uploaded a new diff patch after changes according to @tbaumgart's comments.

This in general is a high quality patch. Thanks much. The changes I suggest are minor details.

Extract from the jenkins log:

19:33:14  -- Downloading...
19:33:14     dst='/home/appimage//appimage-workspace//downloads/qt-everywhere-src-5.11.3.tar.xz'
19:33:14     timeout='none'
19:33:14  -- Using src='https://download.qt.io/archive/qt/5.11/5.11.3/single/qt-everywhere-src-5.11.3.tar.xz'
19:33:14  -- Retrying...
19:33:14  -- Using src='https://download.qt.io/archive/qt/5.11/5.11.3/single/qt-everywhere-src-5.11.3.tar.xz'
19:33:14  -- Retry after 5 seconds (attempt #2) ...
19:33:19  -- Using src='https://download.qt.io/archive/qt/5.11/5.11.3/single/qt-everywhere-src-5.11.3.tar.xz'
19:33:19  -- Retry after 5 seconds (attempt #3) ...
19:33:25  -- Using src='https://download.qt.io/archive/qt/5.11/5.11.3/single/qt-everywhere-src-5.11.3.tar.xz'
19:33:25  -- Retry after 15 seconds (attempt #4) ...
19:33:39  -- Using src='https://download.qt.io/archive/qt/5.11/5.11.3/single/qt-everywhere-src-5.11.3.tar.xz'
19:33:40  -- Retry after 60 seconds (attempt #5) ...
19:34:47  -- Using src='https://download.qt.io/archive/qt/5.11/5.11.3/single/qt-everywhere-src-5.11.3.tar.xz'
19:34:47  CMake Error at ext_qt-stamp/download-ext_qt.cmake:159 (message):
19:34:47    Each download failed!

Apparently caused by a TLS cipher negotiation problem.

Any idea why the build failed https://binary-factory.kde.org/job/KMyMoney_Nightly_Appimage_Dependency_Build/51/ ?

I don't have write access. Would appreciate if you could do it!

Please let me know, if you have write access to the repo. If not, I can take care of committing this change.

In D27582#616283, @Abella wrote:

I can commit into master (whit 'arc land') but I don't know how to do it in 5.0

I can commit into master (whit 'arc land') but I don't know how to do it in 5.0

In D27582#616121, @tbaumgart wrote:

The kmymoney-devel@kde.org mailing list is an even better option for that purpose.

In D27582#616092, @Abella wrote:

Next time I use kmymoney@kde.org mailing list. Chapter updates by KMyMoney team will be very welcome by Catalan team.

Thanks for your help - these are things I have obviously missed, and will help me in future updates.
This should be able to go into both master and 5.0 branch.

In D27582#615999, @ostroffjh wrote:

Please note that the KMyMoney team (mainly myself) generally handles the doc editing for this application.

Please note that the KMyMoney team (mainly myself) generally handles the doc editing for this application. However, all these changes look OK to me. Also note that about half the chapters have not yet been updated to reflect Version 5 of the program - there are two of slowly working our way through that backlog. In general, we do not post doc updates through Phabricator, although I'll be happy to do so in order to get a review for these types of changes.