I would like to have access to the Windows Store, to be able to see crashes from KDE Connect (I've been told there are lots of them) and submit releases there.

Emailed maintainer to check if they'd like their app to be ported today - will update when I get a response. (I'm new to please let me know if I do something wrong).

We already do this systematically whenever

According to https://invent.kde.org/packaging/craft-blueprints-kde/-/blob/master/libs/dbus/dbus.py#L67 it uses now 1.13.18.

Another possibility of integrating KIO directly into Windows would be through cfapi: https://docs.microsoft.com/en-us/windows/win32/cfapi/build-a-cloud-file-sync-engine

In T9579#250279, @andriusr wrote:

Another possibility I've still not checked would be integrating kio-fuse into Dokany's FUSE wrapper, I don't know how complex it'd be or even if it's stable, but in this way the KIOs could be shipped independently.

I see, thank you very much for your hard work!

The issue was introduced recently I currently rebuild the cache to fix the issue, it should be gone in the next couple of days.

I hope this is the proper place to ask about this:
I downloaded the latest artifact and installed it.
Problem is, it always complains about expat.dll, see screenshot:

I'm afraid we can't assist with SQLCipher - you'll need to follow that up with the folks that work on KDE on Windows, or alternatively (and preferrably), the SQLCipher developers directly.

Hi Ben,

That is an issue that occurs from time to time depending on how well Windows is initialized when the Task Scheduler decides to start the Jenkins agent processes.

Thank you Ben for enabling it.

Why would we need fuse on Windows?

In T9579#250279, @andriusr wrote:

Hi, I was an avid user of Dolphin on KDE4 times, I'd like to share some thoughts ...

My main use case was browsing remote (sftp) files and opening them in Kate. Since at that time all the KDE environment was shared (plug-ins, kio etc.) it was fantastic to work that way! So, first of all, for Dolphin and for other apps I think we should always ship them with a common set of KIOs. I understand that individual app installers are the new way since KF5, but maybe we could think about packaging some sets of apps as a bundle.

Hi, I was an avid user of Dolphin on KDE4 times, I'd like to share some thoughts ...

This has now been done.
https://binary-factory.kde.org/job/Skrooge_Nightly_mingw64/

Skrooge is now able to build without QWebengine. So, is it possible to enable again the build of Skrooge on Windows ?

Still "in certification" but already available @ https://www.microsoft.com/en-us/p/labplot/9ngxfc68925l

LabPlot is in the MS Store now but still marked as "In certification" in the Partner Center. I don't think we can do anything right now but wait.

I can work on this. Let me first have a look if Cantor contains everything needed to publish it on MS Store.
LabPlot already contains everything to use the functionality provided by Cantor. So it is independent of Cantor, but Cantor would be useful as standalone app too.

@sgerlach, are you available to also publish Cantor there? How Cantor is a dependence of Labplot, maybe you could do it during the process of publish Labplot.

Please file a separate ticket with Sysadmin to be given access to the KDE e.V. Partner Centre account.

We also need to add detection for virtual windows files to kio, tries to doewnload all files in onedrive/owncloud when the home dir is entered, to index them.

Draggin and dropping files from 7z to dolphin fails as the prompt move/copy here doesn't lock the files and the tmp files are gone when the user decides.

The 'Show menu' button (on screenshot 2) doesn't work - clicking on it forces Dolphin to crash.

And maybe we should continue a dolphin specific discussion in https://phabricator.kde.org/T9579 instead :)

I guess we should see KDE as a brand here and offer the native KDE icons and a breeze theme :)

If wanted I can offer the collibre icon theme which was designed for LibreOffice on Windows 10. Collibre icon theme use the icon guidelines from MS so it would fit perfect into windows 10.

I use Dolphin since a while and the biggest problem was that move to trash didn't work.

I guess its kio used for that and we should just use https://doc.qt.io/qt-5/qfile.html#moveToTrash.

In T9575#244277, @mgallien wrote:

Is somebody already working on packaging Dolphin for the Windows Store ?

I have tested the current builds on my work laptop and they seem to work fine and do the job (I had crashes with a previous version).

I would like to help pushing this forward. Not sure I can really help with development tasks but at least we should work to get a package ready to be published (properly packaged, with installers generated by binary-factory at the format expected by Windows Store).

Is somebody already working on packaging Dolphin for the Windows Store ?

In T9579#240811, @emvaized wrote:

Just tried current 'exe' build and decided to share a little feedback here.

Looks very-very cool and promising!
The issues I found:

Just tried current 'exe' build and decided to share a little feedback here.

Sounds good from the maintainer's side.

just contacted you over mail. :D

@brute4s99 At the moment I am the only major contributor so no list has been setup specifically for kdiff3. However I do monitor kde-core-devel. As of this moment the appx file is building and installs. However it is missing screen shots and icons spcefic to kdiff3. Also I do not have access to Windows 10 S. So I can't actually test it on that platform although it should work. My e-mail should be readily visable from the history on invent.kde.org. I will not post it here to minimize exposure to spam bots.

I'm willing to help out with packaging and testing kdiff3 for windows. I have a fair amount of experience firefighting with Craft.
I couldn't find the appropriate group/ channel where the kdiff3 developers hang out. Help in that regards would be appreciated.

Ben activated the APPX stuff

Could someone turn on appx in binary factory. I would like to begin testing for a push.

Thanks to @brute4s99 who found https://www.microsoft.com/en-us/search/shop/Apps?q=KDE+e.V. and ms-windows-store://publisher/?name=KDE+e.V. in the Microsoft Store app

On the KDE windows wiki page, we have a (probably outdated) list of apps for Win: https://community.kde.org/Windows

I think having 44x44 and 150x150 icons is just a matter of scaling the ones we have, they are a SVG anyways.
I think the hard part is that somebody needs to check if all things work ok for the binary factory builds and later care about the reported issues.

in the LibreOffice theme we have done icon themes depend on the desktop environment. So there is breeze for kde desktop, elementary for gtk, Colibre for windows and Sukapura for macOS

I use Dolphin from the binary factory. I can test dolphin builds if needed.

Given we have now a bunch of applications in the store, it might sense to start the promotion a bit.

Nice!

Hi there,

I suppose I can set it resolved.

Thanks a lot for all the support I have received !
A first submission is now published on the Windows store.

Nice that this went now into the store, cool!

After more tests on physical machine instead of virtual machine, I have decided to submit the latest stable build of Elisa.
Let's wait for the result.

I have pushed two commits backporting a few patches.
I believe that this version should be publised (there are still minor bugs). A new tagged version will come soon and provides more fixes.
I will test the new package tomorrow and check if it can be published for the Windows store review process.

Sounds releaseable. Crashes just make a good impression, do you want to release it. We might add a beta disclaimer to the description?

The current package of the 19.12.1 release built with KDE Frameworks 5.66.0 has still one bug:

In T9641#214088, @vonreth wrote:

Opening the settings dialog the first time takes quite long, clicking it the second time crashes elisa.
Maybe you should investigate before we release ^^

Opening the settings dialog the first time takes quite long, clicking it the second time crashes elisa.
Maybe you should investigate before we release ^^

MS is not necessarily well liked by KDE users

A simple music player that should be easy to use. It does not require any configuration before one can use it. It will read all your music.

The screenshot of Elisa running on Windows is here https://community.kde.org/File:Elisa-windows.png

In D25599#573581, @sars wrote:

Yes it works :)

(I added QLocale::setDefault(QLocale(QString::fromLatin1(languageCode))); to the end of the if statement in initializeLanguages())

Hmm... For an application like Kate it is totally fine to set the language through kxmlgui, but kxmlgui is tier 3 while kcoreaddons and ki18n are tier1. Sure any application can use setDefault() to change the language of the plugin metadata, but that does not change the translation language in ki18n.

I think the proper solution would be to use the same mechanism in ki18n and KCoreAddons. If we use the env variable we need to change KCoreAddons and if we want to use QLocale we need to change KI18n to use QLocale.

Yes it works :)

In D25599#572013, @sars wrote:

I would agree that a UNIX/POSIX env var is not the most logical thing to use on Windows, but how do we ensure that we are in sync with ki18n? The usage of QLocale in ki18n looks like it is just adding extra languages to a list of languages, not actually using QLocale to determine what catalog to load. At least LANGUAGE overrides any QLocale settings. Should ki18n not be moved to using QLocale and setDefault()?

Do you BTW have a hint at what the "correct" place is to use QLocale::setDefault()?

I would agree that a UNIX/POSIX env var is not the most logical thing to use on Windows, but how do we ensure that we are in sync with ki18n? The usage of QLocale in ki18n looks like it is just adding extra languages to a list of languages, not actually using QLocale to determine what catalog to load. At least LANGUAGE overrides any QLocale settings. Should ki18n not be moved to using QLocale and setDefault()?

In D25599#571880, @sars wrote:

So the conclusion is that we are not using setDefault() yet and ki18n & gettext uses the LANGUAGE env so the logical thing, for now, is to also use LANGUAGE env here in KCoreAddons for the plugin metadata translations?

So the conclusion is that we are not using setDefault() yet and ki18n & gettext uses the LANGUAGE env so the logical thing, for now, is to also use LANGUAGE env here in KCoreAddons for the plugin metadata translations?

In D25599#571398, @vonreth wrote:

In D25599#571158, @aacid wrote:

In D25599#570678, @vonreth wrote:

Are you sure? https://github.com/KDE/ki18n/blob/a5477f812c563ffd7fb08b6ec4bd573bc49bb76a/src/klocalizedstring.cpp#L146

Sure about what?

I don't know what that link is supposed to mean :)

I don't see a call to QLocale::setDefault so I don't see how QLocale() should yield a different result.

In D25599#571158, @aacid wrote:

In D25599#570678, @vonreth wrote:

Are you sure? https://github.com/KDE/ki18n/blob/a5477f812c563ffd7fb08b6ec4bd573bc49bb76a/src/klocalizedstring.cpp#L146

Sure about what?

I don't know what that link is supposed to mean :)

In D25599#570678, @vonreth wrote:

Are you sure? https://github.com/KDE/ki18n/blob/a5477f812c563ffd7fb08b6ec4bd573bc49bb76a/src/klocalizedstring.cpp#L146

Are you sure? https://github.com/KDE/ki18n/blob/a5477f812c563ffd7fb08b6ec4bd573bc49bb76a/src/klocalizedstring.cpp#L146

In D25599#570372, @sars wrote:

ki18n does not seem to use QLocale to get the language for translation

Well it sounds to me like we might need both.
But the issue this pr tries to tackle would probably be gone with setDefault

ki18n does not seem to use QLocale to get the language for translation, but uses LANGUAGE env. Also gettext uses the env variable.

To be honest i don't remember why we don't use setDefault.