Re: Future of Alkimia
Am 05.05.2018 um 17:54 schrieb Christian David: > Hello Ralf, > > Am Donnerstag, 12. April 2018, 17:09:16 CEST schrieb Ralf Habacker: >> Another option would be make it more interesting for other projects by >> adding more stuff into. > > Do not get me wrong, I still think the original ideas are very good [1]. > However, there were no development on features for eight years, why should it > happen now or in future? I cannot answer this question for the past, but there seem to be corresponding requirements now. Let me give you an example: In the last six months, online pricing services have changed a lot. The current implementation requires a new version of KMyMoney to be made available when services are changed or users must manually change the regular expressions for service definitions in their installation, which is error-prone. Skrooge continues at this point: configurations for quotation services are stored in the KDE store (see https://store.kde.org/browse/cat/339/). Users can access a list of available services within the application and install or update them. This makes it easier to keep the services up to date. You can now implement the import of your own and/or Skrooge online services in KMymoney, but then you already have two implementations, which would have to be adjusted when extending the format (e.g. for better recognition of service types such as stocks, price conversions). It would be better to store the necessary code to access these services in the alkimia repo and use the corresponding classes in Skrooge, KMyMoney and maybe other applications. Ralf
Re: Future of Alkimia
Hello Lukasz, Thomas, Jack and Thomas, I am afraid that this discussion could just end without any decision. So let me sum up what we have until now: 1) Alkimia is only used by KMyMoney. So using it as a separate library is not useful. 2) For eight years no feature was added that makes alkimia of interested for other software developers. 3) Instead of dropping Alkimia we could make it useful (for the first time). Is that a good representation? So I recommend: we wait until 23rd of October 2018 (this is in 6 months). If there is no new feature¹ then we drop it. Knowingly that the git repository, the wiki etc. will still be kept and can be reactivated if needed. I want to highlight that this does not mean that the ideas behind alkimia are bad nor that the work which went into it were senseless! I spent a lot of time with alkimia, too! Btw: the first svn commit to Alkimia was on Sun May 23 13:15:55 2010 (8 years - 1 week ago). Best Chris ¹ A feature that makes alkimia of real interest to other programs Am Mittwoch, 4. April 2018, 18:34:28 CEST schrieb Christian David: > For this reason I recommend to drop alkimia and move AlkValue into KMyMoney > directly.
Re: Future of Alkimia
Hello Ralf, Am Donnerstag, 12. April 2018, 17:09:16 CEST schrieb Ralf Habacker: > Another option would be make it more interesting for other projects by > adding more stuff into. Do not get me wrong, I still think the original ideas are very good [1]. However, there were no development on features for eight years, why should it happen now or in future? Also I think we should think like: there is a problem, this should be solved with a library. Not the other way round: we want a library, how can we get people to use it? Best Chris [1] https://community.kde.org/Alkimia/Usecases
Re: Future of Alkimia
On 2018.04.29 11:02, Thomas Capricelli wrote: On 28/04/2018 20:31, Christian David wrote: > Hello Ralf, > > Am Donnerstag, 12. April 2018, 17:09:16 CEST schrieb Ralf Habacker: >> Another option would be make it more interesting for other projects by >> adding more stuff into. > > Do not get me wrong, I still think the original ideas are very good [1]. > However, there were no development on features for eight years, why should it > happen now or in future? Also I think we should think like: there is a > problem, this should be solved with a library. Not the other way round: we > want a library, how can we get people to use it? (note : I'm not a kmm dev) I agree with that. Sure a lib is great and all, but better wait for a real need to extract useful stuff from kmm into a library. Currently this really seems unneeded. Extracting some code into a lib is not very difficult, even less so if you know precisely what is required to be shared by several projects. Until then... your gain is that you don't need to maintain a separate code base, separate release, porting, ... And you remove some pain for packagers. Unless I misunderstand something, Alkimia is already a separate library. I think the question is whether to keep it separate, and hopefully increase the number of apps using it. Jack
Re: Future of Alkimia
On 28/04/2018 20:31, Christian David wrote: > Hello Ralf, > > Am Donnerstag, 12. April 2018, 17:09:16 CEST schrieb Ralf Habacker: >> Another option would be make it more interesting for other projects by >> adding more stuff into. > > Do not get me wrong, I still think the original ideas are very good [1]. > However, there were no development on features for eight years, why should it > happen now or in future? Also I think we should think like: there is a > problem, this should be solved with a library. Not the other way round: we > want a library, how can we get people to use it? (note : I'm not a kmm dev) I agree with that. Sure a lib is great and all, but better wait for a real need to extract useful stuff from kmm into a library. Currently this really seems unneeded. Extracting some code into a lib is not very difficult, even less so if you know precisely what is required to be shared by several projects. Until then... your gain is that you don't need to maintain a separate code base, separate release, porting, ... And you remove some pain for packagers. regards, -- Thomas Capricelli
Re: Future of Alkimia
Hello Ralf, Am Donnerstag, 12. April 2018, 17:09:16 CEST schrieb Ralf Habacker: > Another option would be make it more interesting for other projects by > adding more stuff into. Do not get me wrong, I still think the original ideas are very good [1]. However, there were no development on features for eight years, why should it happen now or in future? Also I think we should think like: there is a problem, this should be solved with a library. Not the other way round: we want a library, how can we get people to use it? Best Chris [1] https://community.kde.org/Alkimia/Usecases
Re: Future of Alkimia
Hi, On Donnerstag, 12. April 2018 17:09:16 CEST Ralf Habacker wrote: > Am 04.04.2018 um 18:34 schrieb Christian David: > > Hello, > > > > Alkimia was started about eight years ago by the developers of Skrooge, > > Kraft and KMyMoney. Unfortunately it never supported more than AlkValue. > > As far as I know, KMyMoney is the only project left to use alkimia. > > Skrooge and Kraft are not using it anymore and I do not know any other > > software to use alkimia. > > > > For this reason I recommend to drop alkimia and move AlkValue into > > KMyMoney > > directly. This reduces the maintenance for developers, packages and users > > who just want to compile KMyMoney on their own. Additionally it reduces > > possible sources of trouble (just remember how much work it was for Ralf > > to get it working with Qt 4 & 5) > > which was an interesting challenge to see how to create a multi platform > library. > > and we remove a dependency. > According to a recent build log > https://build.opensuse.org/package/live_build_log/windows:mingw:win32/mingw3 > 2-kmymoney-installer/openSUSE_Leap_42.2/x86_64 kmymoney depends on about 85 > packages. Removing one dependency is about 1,11 %. > > > What are you thinking about this? > > Another option would be make it more interesting for other projects by > adding more stuff into. I was thinking about moving the exchange rate stuff incl. the online updates into alkimia. I think, there was some approach towards it already. -- Regards Thomas Baumgart https://www.telegram.org/ Telegram, the better WhatsApp - Designed to make a difference -- Minus Sign - signature.asc Description: This is a digitally signed message part.
Re: Future of Alkimia
Am 04.04.2018 um 18:34 schrieb Christian David: > Hello, > > Alkimia was started about eight years ago by the developers of Skrooge, Kraft > and KMyMoney. Unfortunately it never supported more than AlkValue. As far as > I > know, KMyMoney is the only project left to use alkimia. Skrooge and Kraft are > > not using it anymore and I do not know any other software to use alkimia. > > For this reason I recommend to drop alkimia and move AlkValue into KMyMoney > directly. This reduces the maintenance for developers, packages and users who > just want to compile KMyMoney on their own. Additionally it reduces possible > sources of trouble (just remember how much work it was for Ralf to get it > working with Qt 4 & 5) which was an interesting challenge to see how to create a multi platform library. and we remove a dependency. According to a recent build log https://build.opensuse.org/package/live_build_log/windows:mingw:win32/mingw32-kmymoney-installer/openSUSE_Leap_42.2/x86_64 kmymoney depends on about 85 packages. Removing one dependency is about 1,11 %. > What are you thinking about this? Another option would be make it more interesting for other projects by adding more stuff into. Ralf
Re: Future of Alkimia
Hi, I was about to suggest this myself. I think it's a good idea. Cheers Łukasz Dnia środa, 4 kwietnia 2018 18:34:28 CEST Christian David pisze: > Hello, > > Alkimia was started about eight years ago by the developers of Skrooge, > Kraft and KMyMoney. Unfortunately it never supported more than AlkValue. As > far as I know, KMyMoney is the only project left to use alkimia. Skrooge > and Kraft are not using it anymore and I do not know any other software to > use alkimia. > > For this reason I recommend to drop alkimia and move AlkValue into KMyMoney > directly. This reduces the maintenance for developers, packages and users > who just want to compile KMyMoney on their own. Additionally it reduces > possible sources of trouble (just remember how much work it was for Ralf to > get it working with Qt 4 & 5) and we remove a dependency. > > What are you thinking about this? > > Best > Chris
