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.

They are, this patch just provides the ability to save this data into the existing database using existing variables. This variables are the ones that are used in the print checks plugin.

In T11403#218245, @ostroffjh wrote:

Much better. Would it be worth the effort to add mention to the home page of the latest released version? If not on the Home page, at least on the Download page? I know I sometimes do go to an application's page just to confirm I'm actually on the latest released version. Right now, other than the News page, I don't see it anywhere within two or three clicks of the Home page.

Much better. Would it be worth the effort to add mention to the home page of the latest released version? If not on the Home page, at least on the Download page? I know I sometimes do go to an application's page just to confirm I'm actually on the latest released version. Right now, other than the News page, I don't see it anywhere within two or three clicks of the Home page.

I just moved the news to /news and increased the list of news per page to 10

Unfortunately, the number of items per page is fix for all pages in jekyll. Since the announcements on the first page are somewhat indistinguishable from the rest, how about having a News section between KMyMoney and Support in the top header. Creating a news subdir allows us to have another index.html (the pagination only works on index.html) but I have not tested that at all, just ideas

Yes, especially after the first page. Even the first page is larger than most screens, so putting 5 or even 10 items per page after the first seems OK. (It seems the announcements are clipped to at most a few lines, so they will never be very long.)

I just pushed a fix :) Maybe we could also increase the number of announcements displayed per page?

Thanks for all the work on this, but there are 12 pages, and the only thing that changes is Announcements, and even that took me a while to notice, since that section is not set off from the rest in any way. Also, the "Major Platform" icons are missing on all except the first page. The second is likely to be a bug somewhere. The first is more a style issue - so where is the best place to discuss how it "should" work, and what options there are.
Thanks.

kmymoney.org now use the new design and is deployed 🎉 Many thanks to all the peoples who helped with the update.

A nice blog-post about this task contains some guidance to setup the development environment in case that helps.

Hi @ognarb . I want to work on this website redesign during the season of KDE this time. Please guide me regarding this.

@adrianchavesfernandez Please request push access :) In the meantime Phabricator diff are also ok

Should I request push access until we finish the migration, or should I use Phabricator differentials?