looks good, msvc issues can be fixed later.
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Oct 10 2019
I think it would make more sense to first try this with the native msvc compiler, aka win64 as platform.
We can later still revert back to using mingw64 if that fails.
You can do that via merge request to
In D24440#544532, @cullmann wrote:Overall: As you seem to be interested in getting KDE games running on Windows, shall we add some jobs to binary-factory.kde.org for Windows compiles?
Then you can take a look there if all works nicely.
Hannah can give perhaps some short feedback.
Oct 9 2019
In D24444#543333, @aacid wrote:Nice patch.
I see you've been working on getting things compiling on Windows, nice work :)
Do you know of the initiative we have for getting some applications to the Windows Store? Want to join?
Oct 7 2019
I've not much idea about craft, but this seems like a no brainer, so landing it :)
Oct 6 2019
Compiles fine in Linux without that include. Thanks.
Oct 5 2019
Works fine in Linux.
Jun 13 2019
Yes, I re-read the KF5 porting notes and I guess the KFoo -> QFoo thingy was a misconception based on the deprecation of quite some the KDE 4 KFoo classes.
Thanks for your comments. :)
Jun 12 2019
Depends, KUrl? Yes Kurl is deprecated and you should use QUrl
Hmm, that was exactly my thought when I saw these Krazy issues. I think to remember exactly the opposite suggestion from a few years ago where Krazy said, we should use the equivalent Qt classes. Am I remembering correctly?
Jun 11 2019
at this point i'd say that krazy warning is a bit old fashioned, but sure, won't hurt either
May 4 2019
If checked closely, the values are essentially handled well, because the values which will get converted to symbols are limited and therefore the values to be converted back would be limited as well. Hence, it will not produce unexpected results.
May 1 2019
In D20831#458883, @mlaurent wrote:Do you have commit access or you want that we commit for you ?
Do you have commit access or you want that we commit for you ?
Apr 30 2019
for me it's ok.
Forget to commit last changes
Apr 29 2019
Apr 28 2019
Apr 26 2019
Change to KStandardAction & Revision increase in rc file
Apr 25 2019
Apr 2 2019
In D20187#441919, @aacid wrote:@patrickelectric @andreagenor will one of you commti this?
Apr 1 2019
@patrickelectric @andreagenor will one of you commti this?
In D20187#441890, @cfeck wrote:
Jan 17 2019
https://phabricator.kde.org/D17860 has been committed.
Jan 1 2019
In T10205#171471, @smaudet wrote:https://phabricator.kde.org/D17860
Updated. I'm not using arcanist... I suppose I should bug the mailing list every so often?
Updated. I'm not using arcanist... I suppose I should bug the mailing list every so often?
Dec 29 2018
Also, it is extremely unpractical to get a review through a task - they are not meant for this. Please close this and send a review.
I'd really suggest to use arcanist and send a patch. Commit to the local repository, arc diff, and that's it, the kdegames mailing list will be notified.
Dec 20 2018
diff --git a/cellitem.cpp b/cellitem.cpp index b4e3060..443b743 100644 --- a/cellitem.cpp +++ b/cellitem.cpp @@ -33,6 +33,17 @@ CellItem::CellItem(KGameRenderer* renderer, QGraphicsItem* parent) reset(); }
Not really sure how to use all your tooling (way, way too complicated, doesn't work/breaks).
Oct 21 2018
Sep 24 2018
Removed the uncessary localization update since that has been fixed elsewhere and renamed the revision to make it clear it's just about OARS now
Sep 21 2018
(this specific change is going to be only about adding the oars tag)
But then the commit message should be fixed, and also the german change removed.
The german translation part should go to @kde-i18n-de. Will reach out.
Sep 4 2018
No need for being sorry :) it's just that the unified issue tracker is there.
Tasks can be created later from bugs, depending on the team.
Thanks for reporting the issue.
Apologies.
On it - but this should have been a bugs on bugs.kde.org, not a task here.
May 22 2018
Sigh, could have thought of this. Yeah, I'll open a ticket.
Problem is that now continuous integration fails because the lib is not available.
Thanks, Fabian, and - you are welcome!
Oh well, time to get this merged. I didn't get *too* strong objection from the mailing list, so I intend to merge this as is. Thank you very much @shlomif for your patience and your code contribution.
May 16 2018
Yeah, sure, I'll send the mail.
May 14 2018
In D12415#262090, @fabiank wrote:@aacid : Do you know anyone from the distro side who could chime in if adding the library would pose an issue?
@fabiank : from what I seem to recall, that new file was derived from an existing one that carried that copyright. I on my part disclaim any ownership for my modifications to this file.
Sorry, I technically reviewed it already, but forgot to hit submit :-(. I'm happy with the current state of the code (sans that one copyright line), and the solver does a better job than the current one.
May 13 2018
hi! Can you please review the second (and the latest) patch?
Apr 24 2018
Update to the master branch and apply commentary from the reviewers - no iostream, no kDebug, precanned solving themes, etc.
Hi all!
Apr 23 2018
Considering that currently no one (including me, the de-facto maintainer) really knows what the solver is doing exactly and how the numbers for the search in it were derived, I appreciate outsourcing the logic to a library. However, like @aacid said, it would be nice to have either some numbers how the solver compares.
Do you have a game number we can use to compare how this is better than the existing code?