On 03/21/2014 08:03 AM, Ed Greshko wrote:
> But, yeah, who looks at these indicators anyway.
If you want to belabor the point... UI progress indicators do one
primary task: indicate progress. that's it. And, as I at least
implied, it does not have to be accurate, but the act of the UI giving
progress feedback is important.
This is why I reacted in this thread to the suggestion of removing it.
Secondarily, giving an estimate for completion is an added bonus. We
can agree that the estimates given can be wildly inaccurate for a
variety of use-cases, but I still argue it can be useful for many.
In conclusion, my take is that improving accuracy (and removing
inaccuracy) should be the constructive focus and way forward. Anyone
willing to look at the code to improve it?
On 03/21/2014 07:05 AM, Patrick O'Callaghan wrote:
> Either that or just eliminate the indicator entirely if it's not giving
> useful information (or rather reduce it to a simple flag that the
> transfer hasn't completed yet).
Disagree, based on my own preference and experience, bad progress is
still better than no progress. really.
I'm using Dolphin to copy large files (several GB) to an NFS-mounted
NAS. This works fine except that the informational system tray pop-up is
showing absurd values for the copy bandwidth. e.g. a 2GB file is
declared to be finished when it's only just started. It looks like
what's being measured is the rate of handoff to network buffers. This
machine has a quad-core i7 CPU with 16GB of RAM and isn't doing much
else, so the entire file could be copied to system buffers very quickly.
However the actual LAN is 100Mbps so the real copy takes several
minutes, and it's only then that I get the pop-up saying it's finished.
Is this what's going on? Note that the copy does work correctly.
KDE 4.11.7 on F20.
On 03/20/2014 11:48 AM, Patrick O'Callaghan wrote:
> if KDE is going to
> show progress it should actually show progress and not lie about it.
Its not exactly a lie, consider it closer to a reasonable-effort
this is to briefly announce our intent to create a new "Fedora Plasma
Product", as part of the fedora.next initiative. This product should
eventually replace the current KDE spin.
Today, during the regular KDE SIG meeting, we formally ratified its
Mission Statement and Governance documents.
Prior to officially submitting the proposal to FESCo, we're going to
work hard in the following days and weeks on refining and polishing the
Product Requirements and TechSpecs documents.
Feedback and comments from the community are welcome and appreciated.
On behalf of the membership,
Lukáš Tinkl <ltinkl(a)redhat.com>
Software Engineer - KDE desktop team, Brno
KDE developer <lukas(a)kde.org>
Red Hat Inc. http://cz.redhat.com
FYI, I likely won't get to it myself this weekend... The wife encountered laptopocolypse ... My free time has been monopolized recovering data from a failing disk. :(
-------- Original message --------
From: Kevin Kofler <kevin.kofler(a)chello.at>
Date:03/15/2014 11:33 PM (GMT-06:00)
Subject: Re: 4.13 in unstable?
Markus Slopianka wrote:
> I'm relatively new to Fedora and I couldn't find the info online:
> When do unstable releases by KDE end up in Unstable/Testing/Stable?
No earlier than the first upstream beta tarballs. How long it takes between
the release of those tarballs and us packaging them depends on several
factors: whether Rawhide is close to branching for a release (then we wait
until after the branching before the import, and as kde-unstable is normally
a backport of Rawhide, it usually has to wait as well), how much time we
have, whether there are any split or renamed modules and/or new (not yet
packaged in Fedora) dependencies and how many those are (because each of
those needs to go through package review before it can be imported), etc.
For 4.13, Rex Dieter said on IRC that he'll start importing the beta into
Rawhide on Monday. (There's no release branch coming any time soon due to
Fedora.Next.) Any kde-unstable builds will come when the Rawhide import is
kde mailing list
New to KDE4? - get help from http://userbase.kde.org
Qt3D is not yet integrated in Qt5. However, I will soon monitor a Google
Summer of Code student (for porting Qt4 demos of cgal.org to Qt5), and I may
need Qt3D (a student candidate already proposed to use that new library).
Do we already have packages for Qt3D somewhere? There was an old review
request , but it was closed NOTABUG. There is new review request , yet
unanswered so far, and about an old version. There is also a package mingw32-
qt5-qt3d in Fedora, but I do not see any non-Mingw package. I also have a spec
file for it (see the attachment) for a very recent release (but it requires a
snapshot of Qt-5.3).
I tried to test current sddm status, so i used these instructions:
In section "How To Test" it says:
"Anybody able to run KDE Plasma Workspaces as his desktop can test."
So, is it safe to assume that one can test with a F20 host?
I tested with a F20 host, after enabling sddm i performed a reboot.
On the next boot, sddm appeared, but i am unable log in with any user.
It is like enter does nothing. I can login with those users on another
VT or via ssh, so the user/passwords are ok.
I tried setting SELinux to Permissive, but it did not help.
# systemctl status sddm.service -l
sddm.service - Simple Desktop Display Manager
Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled)
Active: active (running) since Thu 2014-03-13 12:49:28 ART; 7min ago
Main PID: 832 (sddm)
├─856 /usr/bin/X :0 -auth /var/run/sddm//A:0-RfaIBo
-nolisten tcp vt01
├─860 /usr/bin/sddm-greeter --socket sddm-:0-hwOZXu --theme
├─954 dbus-launch --autolaunch
e837339228d144d7978eae4231db458b --binary-syntax --close-stderr
└─958 /bin/dbus-daemon --fork --print-pid 5 --print-address
Mar 13 12:49:28 stark.espada sddm: DAEMON: Adding new display : 0
on vt 1 ...
Mar 13 12:49:28 stark.espada sddm: DAEMON: Adding cookie to
Mar 13 12:49:28 stark.espada sddm: /usr/bin/xauth: file
/var/run/sddm//A:0-RfaIBo does not exist
Mar 13 12:49:28 stark.espada sddm: DAEMON: Display server starting...
Mar 13 12:49:28 stark.espada sddm: DAEMON: Display server started.
Mar 13 12:49:28 stark.espada sddm: DAEMON: Socket server starting...
Mar 13 12:49:28 stark.espada sddm: DAEMON: Socket server started.
Mar 13 12:49:28 stark.espada sddm: DAEMON: Greeter starting...
Mar 13 12:49:28 stark.espada sddm: DAEMON: Greeter started.
Mar 13 12:49:29 stark.espada python: SELinux is preventing
/usr/bin/sddm-greeter from write access on the sock_file .
***** Plugin catchall (100.
confidence) suggests **************************
If you believe that
sddm-greeter should be allowed write access on the sock_file by
Then you should report this as a bug.
You can generate a local
policy module to allow this access.
allow this access for now by
# grep sddm-greeter
/var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Mar 13 12:56:35 stark.espada dbus: avc: received setenforce
Mar 13 12:56:47 stark.espada dbus: avc: received setenforce
Is there a dedicated logfile? (like kdm.log)