nntp (aka, usenet) client in kde?
by Gene Smith
I currently use t-bird with an nntp account pointing to gmane to read
this list and sereral others. Does kde have an nntp client program of
any sort? I don't see it as a possible new account type in kmail. Also,
search with kpackagekit yields nothing with "usenet" or "nntp" that is
kde specific.
-gene
3 years, 9 months
kde4 in F22
by Piotr Gbyliczek
Hi all,
Some people on this list and in general did not take the switch from KDE4 to
Plasma 5 desktop easy way.
For those who prefer older workspace, or just see plasma 5 as unstable, which
potentially includes me, I've created copr repository to maintain KDE4 for
F22.
If you can, please test it in real life and report issues. I have tested in
on default KDE-live install, resulting in one bug report already.
I can't promise continuity, but I will try my best.
Regards,
Piotr
8 years
Re: KDE 5: VMware Workstation unuseable
by Reindl Harald
Am 16.09.2015 um 18:12 schrieb Wes Hardaker:
> Reindl Harald <h.reindl(a)thelounge.net> writes:
>
>> * start a VM
>> * move the mouse pointer into the window
>>
>> "Do you really want to activate 'slow keys' and 'mouse keys'..... if
>> you do not need them, you can select 'Deativate all AccessX features
>> and gestures' - independent what you chose, move the mouse and the
>> same dialog appears again and again - seriously?
>
> Yikes. Please to post if you find a fix for that
a workaround is just disable 3D graphics for the VM's and start them
headless with the VNC option and avoid the normal GUI but after so many
years using VMware under KDE (as well as ESXi for production servers) it
leaves a bad taste in my mouth to say it polite
and the fact that copy files over sftp freezes half of the GUI and i
recently smoked two cigarettes until something starts to working again
on a i7 SandyBrdige machine with 16 GB ram while switch with CTRL+ALT+F2
to a console and verify that all the files are already there while
plasma is running in circles with high CPU load confirms that until now
KDE5 is just unusable
8 years
Stepping down from KDE SIG
by Kevin Kofler
Hi,
in recent times, I have been increasingly unable and unwilling to adequately
(co)maintain the huge set of packages known as the KDE Software Compilation
(i.e., the union of the KDE Plasma Workspaces, KDE Frameworks and KDE
Applications release sets), which I will refer to as "KDE SC" in this mail.
* unable because:
- the set of packages keeps growing and growing (mainly due to splitting of
existing packages). The KDE SC used to be about a dozen packages. When a new
release came out, it could be updated to manually (without any scripts) by
one person in about a day. These days, we are talking about hundreds of
packages. (I am supposedly comaintaining over 300 packages at the moment.)
Those packages are impossible to deal with without scripts, and even those
scripts take hours to run (and require some amount of babysitting because
things such as rebasing patches cannot always be automated). The same
phenomenon also affects Qt, at a slightly smaller scale. Back in the day, I
felt confident about having a global view on the KDE SC packages. This is no
longer the case.
- I am having an increasingly hard time keeping up with the latest evolutions
that the KDE Project releases. Right now, I am still running Plasma 4 and am
highly unfamiliar with Plasma 5. This means I am out of touch with the
issues our users are reporting and also have only limited ability to test
any fixes.
- big parts of the KDE Plasma Workspaces are now written in QML, a language I
am also not very familiar with.
- for varying reasons (job, etc.), I have found myself having nowhere near
enough time to dedicate to KDE SC packaging lately. I am drowning under
bugmail, and have found myself unable to even READ all of it at times, let
alone act on it. The poor quality of KMail 2 (see below) is not helping, and
neither will the F23 release that accidentally defaults to ABRT instead of
DrKonqi (see below). I am basically the only true volunteer left in the SIG,
and the time I can invest in Fedora packaging is finite.
* unwilling because:
- the way the Fedora Project has been treating KDE since Fedora 21 (when
"Fedora.Next" was introduced) makes me feel like a second-class citizen
in the Fedora community. After years of fighting for equal treatment of KDE
in Fedora, Fedora.Next with its "Fedora is now more focused" (on GNOME)
message was a major setback and a huge disappointment. (Another symptom of
this evolution is how the PackageKit backend was rewritten with only the
exact feature set GNOME Software happens to need, leaving Apper utterly
broken.)
- the evergrowing package set (see above) is making it increasingly painful
and boring to maintain KDE SC packages.
- the Akonadi/KMail stack has been a huge pain to use, due to major serious
issues, both performance and reliability issues. Upstream has been either
unwilling or unable to do anything about the problem, none of the fixes so
far really helped in any way. I am unwilling to have anything further to do
with this abomination of software.
- while I have not experienced it personally yet, the quality of KDE Plasma 5
is also reported to be very disappointing; the promise from KDE 4.0 times
that "KDE 5" (as it was referred to at the time) would be an evolutionary
rather than a revolutionary release was not followed through.
- the Fedora 23 KDE Spin (which is now final or almost final) is easily the
worst KDE Spin we have ever released:
. Firefox, a non-KDE and even non-Qt application, is the default browser. It
does not integrate into the Plasma desktop in any way.
. Due to an oversight, DrKonqi is missing, and thus ABRT (another non-KDE
application) is the default crash handler. ABRT reports all the crashes to
us downstream packagers instead of upstream where the crash reports
belong. And experience has shown that the ABRT fire&forget reporters are
unwilling to upstream the bug reports manually, if they even read our
replies at all (and that's if we even manage to reply to all the bugs to
begin with).
Both of these are complete no-gos where I have said from day one that those
are not acceptable. The Firefox fiasco was a deliberate decision, the ABRT
fiasco could have been avoided if DrKonqi had not been made optional against
my recommendation, and/or if people had actually tested that the KDE Spin
uses the KDE crash handler. I do not want to be held responsible for these
decisions I did not approve of.
As a result, I AM HEREBY STEPPING DOWN FROM THE KDE SIG AND FROM
(CO)MAINTAINERSHIP OF KDE SC PACKAGES.
In particular, effective NOW:
* I hereby request to be removed from the group::kde-sig group.
* I will withdraw my comaintainership (including watchbugzilla and
watchcommits!) of Qt and of all packages in the KDE SC, EXCEPT:
- the packages for which I am upstream: kompare, libkomparediff2
- compatibility packages: qt3, kdelibs3, qt(4), kdelibs(4), kdewebdev (3),
kdegames3
* I may also withdraw comaintainership of, or orphan where I am the point of
contact, any packages that I am maintaining because the KDE SC depends on it,
and possibly selected other KDE-related packages.
* I am stepping down from being a voting member in the KDE SIG. I leave it to
the remaining members to nominate a replacement or reduce the member count.
* I am stepping down as a moderator of the fedora-kde mailing list. I already
cleared the moderation flag of the one person I have put on moderation. This
list moderation is an additional duty that I just do not have time for.
* I am stepping down as an operator of the #fedora-kde IRC chan. (You should
also remove the operator privileges from tigcc_bot. It does not need them, it
was only symbolic.)
* I will no longer consider it my duty to attend KDE SIG meetings, though I may
attend some meetings as an interested user. In particular, I will no longer
lead any meetings and I will not try to herd people into attending (the
necessity of which has always been annoying me).
I will KEEP (until further notice):
* my Fedora packager status,
* my provenpackager privileges in Fedora,
* my packager sponsor privileges in Fedora,
* (co)maintainership of a reasonable number of packages that I can actually
scale to (i.e., NOT the current 300-400), including:
- as mentioned above, the Kompare stack and the compatibility packages,
- KDE-related packages outside of the KDE SC (though possibly fewer than now),
- the Calamares installer,
- some non-KDE packages,
* taking care of the compatibility libraries that make existing applications
work (the Qt3/kdelibs3 stack right now, the Qt4/kdelibs4 stack if and when
needed) and of legacy applications themselves,
* developing Kannolo (what the Fedora KDE Spin SHOULD be), to which I hope being
able to devote more time than now,
* maintainership of Kompare upstream (for now), unless another maintainer with
more time can finally be found,
* using and promoting (to the current extent) Fedora with KDE (be it the KDE
Spin or Kannolo).
I am sorry, but after 8 years of volunteering and ending up with almost 400
packages to take care of, I just have to scale down. It was fun while it lasted.
I wish the remaining KDE SIG members good luck for the future.
Kind regards,
Kevin Kofler
8 years
Plasma 5 - Where have all the screensavers gone
by Eli Wapniarski
In Plasma 5... Where haveall the screensavers gone????
Eli
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
8 years
Implement Fedora KDE documentation in order to create a stronger contributors base
by Germano Massullo
A few personal considerations: Fedora KDE spin is well maintained by the
KDE SIG. Since it is made of a not-so-big amount of people, every time a
person leaves the group, we obviously have a not trivial problem.
I would like to help the KDE SIG, therefore a short thought: we would
need a step-by-step guide/documentation concerning how the KDE SIG
maintains the entire spin, so that:
- potential volunteers can study on their own how to contribute without
having to contact contributors;
- we can increase the volunteers base, in order to rely the project on a
bigger and stronger contributors base, avoiding potential problems when
a person leaves the group.
What do you think about?
8 years, 1 month
KDE Plasma Workspace failure
by Peter Grainger
For the third time my KDE Plasma Workspace has failed during the
post-installation software update. On the third occasion (but not the
other 2) it managed to display an error dialogue box, though I could not
send a bug report directly since the system hang had disabled the mouse
and keyboard. However, the dialogue box contained some information which
may be of use to you:
"Plasma closed Unexpectedly"
"Executable: plasmashell (deleted) PID: 2204 Signal: Segmentation fault
(11)" [followed by the date and time]
[The software update (comprising 696 items) was about 75% complete
according to the progress bar, and was well into the installation phase.
My system is based on an Intel Core I7-3770K CPU and a UEFI 'BIOS',
running the 64-bit version of F22. It is not dual-booted (I run Windows
most of the time - such as now - but had hoped to run LINUX on separate
disks).]
I would be delighted to run KDE Plasma Workspace, but I can't afford to
waste any more time repeatedly installing it: if you can't produce
software stable enough actually to install successfully, I'm surprised
anyone is able to use it.
I am a LINUX beginner, and have no idea how to chase this error myself.
However, F22 is still installed, and if you point me in the right
direction I might be able to get some more useful data from a system
log, if there is one covering the software update.
Any other suggestions would be welcome.
Peter Grainger
8 years, 1 month
frozen control bar
by Reindl Harald
is there any way to not need CTRL+ALT+BACKSPACE when the stupid
controlbar is frozen as well the desktop don't react on right-click and
so no way for a clean logout at all?
in 2 hours 4 times restart my KDE session is simply too much, once
because every focus change to a different application had 5 seconds
delay after accept input
8 years, 1 month
