Re: Behaviour of system tray bandwidth indicator
by Rex Dieter
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?
-- rex
10 years, 1 month
Re: Behaviour of system tray bandwidth indicator
by Rex Dieter
On 03/21/2014 07:54 AM, Ed Greshko wrote:
> Progress, yes. But supplying information which is not certain to be accurate, no.
I guess we will have to agree to disagree then.
-- Rex
10 years, 1 month
Re: Behaviour of system tray bandwidth indicator
by Rex Dieter
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.
-- Rex
10 years, 1 month
Behaviour of system tray bandwidth indicator
by Patrick O'Callaghan
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.
poc
10 years, 1 month
Re: Behaviour of system tray bandwidth indicator
by Rex Dieter
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
approximation.
-- Rex
10 years, 1 month
Fedora Plasma Product announcement
by Lukáš Tinkl
Hi list,
this is to briefly announce our intent to create a new "Fedora Plasma
Product"[1], 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[2] 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.
[1] https://fedoraproject.org/wiki/Fedora_Plasma_Product
[2] https://fedoraproject.org/wiki/Fedora_Plasma_Product/Governance
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
10 years, 1 month
RE: 4.13 in unstable?
by Rex Dieter
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)
To: kde(a)lists.fedoraproject.org
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
complete.
Kevin Kofler
_______________________________________________
kde mailing list
kde(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/kde
New to KDE4? - get help from http://userbase.kde.org
10 years, 1 month
4.13 in unstable?
by Markus Slopianka
Hi.
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?
10 years, 1 month
Testing sddm (F21 Feature: SDDM as the default KDE display manager instead of KDM)
by Reartes Guillermo
Hi,
I tried to test current sddm status, so i used these instructions:
fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM#How_To_Test
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)
CGroup: /system.slice/sddm.service
├─832 /usr/bin/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
/usr/share/apps/sddm/themes//fedora
├─954 dbus-launch --autolaunch
e837339228d144d7978eae4231db458b --binary-syntax --close-stderr
└─958 /bin/dbus-daemon --fork --print-pid 5 --print-address
7 --session
Mar 13 12:49:28 stark.espada sddm[832]: DAEMON: Adding new display : 0
on vt 1 ...
Mar 13 12:49:28 stark.espada sddm[832]: DAEMON: Adding cookie to
"/var/run/sddm//A:0-RfaIBo"
Mar 13 12:49:28 stark.espada sddm[832]: /usr/bin/xauth: file
/var/run/sddm//A:0-RfaIBo does not exist
Mar 13 12:49:28 stark.espada sddm[832]: DAEMON: Display server starting...
Mar 13 12:49:28 stark.espada sddm[832]: DAEMON: Display server started.
Mar 13 12:49:28 stark.espada sddm[832]: DAEMON: Socket server starting...
Mar 13 12:49:28 stark.espada sddm[832]: DAEMON: Socket server started.
Mar 13 12:49:28 stark.espada sddm[832]: DAEMON: Greeter starting...
Mar 13 12:49:28 stark.espada sddm[832]: DAEMON: Greeter started.
Mar 13 12:49:29 stark.espada python[992]: 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
default.
Then you should report this as a bug.
You can generate a local
policy module to allow this access.
Do
allow this access for now by
executing:
# grep sddm-greeter
/var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Mar 13 12:56:35 stark.espada dbus[958]: avc: received setenforce
notice (enforcing=0)
Mar 13 12:56:47 stark.espada dbus[958]: avc: received setenforce
notice (enforcing=1)
Is there a dedicated logfile? (like kdm.log)
Cheers.
10 years, 1 month