Dropping one more comment, in case someone wants to give it a try: Apparmor profile transitions don't work if a seccomp filter has been installed before. This makes it probably rather difficult to integrate DrKonqi into an Apparmor policy.
So to recap recent discussions, here are the requested changes:
- (Required) Create a version of the go-previous icon with this same style, and name it go-previous-translucent
- (Required) Make the background circle more opaque and/or darker
- (Optional, your call) experiment with making the symbols a bit smaller inside the background circle, per @filipf's suggestion
It might be worth getting in touch with the Samba developers, as I believe they've worked with the people at Microsoft who look after the SMB parts of Windows - and they'd know best what is done in regards to discovery of shares these days.
Turning to Google though, it looks like this is simply broken in current versions of Windows 10 (by default at least) - https://answers.microsoft.com/en-us/windows/forum/windows_10-files/homegroup-removed-how-to-get-network-sharing-work/01277332-2916-4a68-853a-116696b20743
Fit page content horizontally *and* vertically
@bruns Apart from these, does the code seems sane to you?
@ngraham No, please recheck, the check is before the first m_totalSize > m_freeSpace check
1ul << 32) -1 needs a comment explaining what it means, for people like me with puny brains. :)
File size limit check for a given file system before (m_totalSize > m_freeSpace) check
It's available as an API, but it is not used to publish shares it seems. In fact, if I am reading Microsoft's arcticle on smb1 correctly then ws-discovery is also not enabled by default. Finding other shares in the network seems simply not supported out of the box. I've gotten a device which has an up to date windows 10, albeit installed before the 2017 Fall update, so it has smb1 still enabled. As expected the discovery service also mentioned in the article isn't started by default. Starting it gives me some ws-discovery chatter on the network.
Ping. Can someone please review ?
FWIW my +1 is to removing it. The Appstream assessment is all right but fixing something nobody uses sounds like a waste of time. :P
Done some research on ws-discovery. gsoap is the only free c implementation I could find. There are some python, js and java implementations but they'll probably not help us nearly as much (unless someone wants to write a daemon or helper binary to bridge the language divide without much hassle). Alternative approach would be writing our own implementation using KDAB's kdsoap library, but then that'd need a maintainer which I am confident we don't have :)
FWIW, in practice the workgroup is much less prominent to even unnecessary in a macOS or Linux shared file environment. I've only ever seen shares on multiple workgroups used in a Windows environment.
Tested this out and couldn't actually make it work the way I asked--with the FAT32 file size limit checked first. I think I see why: there are two total size > available space? checks that output ERR_DISK_FULL on error, and both of them execute first. The FAT32 file size limit check should be before the first one, probably near // Stat the next src url.
Thu, Oct 18
Qt decided against #pragma once. I wouldn't want to use it in KDE unless it is decided on kde-frameworks-devel.
Thank you for indulging me 😊
Thanks, this is looking better. I will test it out later.
Cache file system time instead of creating it every time
Maybe we could cache the value of KFileSystemType::fileSystemType() somewhere so we don't need to calculate it again for every file, since it's the same for every one.