Quick status update on el6 kde builds hosted @ kde-redhat repos...
* I moved the kde-4.10.x stuff from kde-unstable to kde-testing, finally.
* Over the past couple of says, started working on kde-4.11.x builds,
should be showing up in kde-unstable real soon, as soon as I work my way
through the last batch of stuff that doesn't build cleanly:
I am going to summarize what I wrote yesterday on IRC so everyone can read
The discussion of what should be the default browser on the Plasma Product
has come up yesterday, and I strongly believe that Firefox is NOT the answer
(but either Konqueror+KWebKitPart or Rekonq is), for the following reasons:
* We do not control the packaging of Firefox. It is not even open to
provenpackager! We'd be completely at the mercy of the Firefox
* In particular, the Fedora Firefox package will most likely NOT include the
KDE integration developed by openSUSE, ever. That means the package will
integrate extremely poorly into our Plasma setup (e.g., no KDE file
* Firefox also has unwanted GNOME dependencies such as
* Shipping Firefox means we have to ship a third HTML engine just for
Firefox! We already have to ship KHTML and QtWebKit because KDE software
requires them. Shipping either Rekonq or Konqueror+KWebKitPart reuses
QtWebKit. Shipping Firefox means adding Gecko and thus pointless code
duplication and more security updates for users to worry about.
* Users who absolutely want Firefox can simply install it from the
repository. Or they could use one of the other spins, which (last I
checked) all included Firefox (either as the one default or next to
Midori). Users who do NOT want Firefox forced on them will have no option
to choose from anymore if we join the monopoly.
* I don't buy the argument that there is "no alternative" to Firefox. There
are 2 perfectly fine KDE alternatives, both based on QtWebKit. Both Rekonq
and Konqueror+KWebKitPart just work on almost all websites out there. (And
even Firefox doesn't work on 100% of the web.) Our plan is to prefer KDE
applications wherever possible. Here, it is clearly possible. Shipping
non-KDE applications is acceptable if those are specialized applications
with no KDE alternative (think, e.g., Blender). A browser is not
specialized, it's a core part of the desktop. And the KDE alternatives
exist and work.
* I also don't share the worries about Rekonq's future. The port to Qt 5 +
QtWebKitWidget is proceeding well. A switch to QWebEngine will be done
only when QWebEngine will be ready, a sound decision. And if this really
should become a problem in the future (i.e. AFTER F21), we can always
reevaluate the default browser decision at that point.
* Firefox does not use kioslaves. As such its URL support is inconsistent
with the other applications we will ship. In particular, Firefox does NOT
support man:foo and info:foo URLs. IMHO, those are by far the most
comfortable way to read man and info pages. It also cannot reuse things
like kio_gopher, requiring a separate extension (for Gopher, that would be
OverbiteFF) instead. In both Rekonq and Konqueror, man:, info: and all the
other kioslave-handled protocols just work.
* Firefox also has some "features" that are worrisome for Fedora as a whole:
- The anti-malware and anti-phishing protection (enabled by default!)
sends a hash of every URL you visit to Google (yes, Google!).
- Firefox Health Report sends some additional data to Mozilla. It is also
enabled by default!
- Mozilla also intends to show client-side advertisements (i.e. ones that
are NOT part of a web page you are visiting) by default. This is both an
added annoyance (as if the ads on the web weren't bad enough!) and a
privacy risk. (Speaking of ads on the web, both Konqueror and Rekonq
support ad blocking out of the box, Firefox doesn't.)
And the Firefox trademark and packaging situation are such that we have no
control over these "features", nor any future ones that get added.
So please consider these points before voting here:
(votes please ONLY from Plasma working group members, 4 voting members have
not voted yet). If you voted for Firefox and these arguments convinced you
otherwise, it's also not too late to change your mind!
Let's PLEASE let the Plasma Product be a Plasma product, not yet another
So this afternoon, I downloaded F20 Gnome 3 live cd, burned it to a USB stick
and tried it for 20 min.
hahaha is all I can say.... I felt like I was using UNITY in ( Ubuntu default)
Gnome3. lots of clicking and I found the programs menu confusing compaired to
Unity's where it shows you EVERYTHING where the gnome 3 menu is like sub
divided off ( for the admin options)
I am just looking for an alternative to KDE, been using it for so long just
kinda bored with it unfortantly here in Kubuntu. =[
So I have 2 gigs of ram.... I have been running Kubuntu 12.04
and I am wanting to try Fedora.
Should I try XFCE or stick with KDE?
Really havent had too many issues with KDE memory wise besides AKONDI eating
memory when KMAIL isnt open. but other than that thanks to KSPLICE ive had 21,
22 consecutive uptime without a reboot.
hi folks new here!
I am currently running Kubuntu 12.04 since nov, I am kind of looking for a
change from the Buntus. Been running something buntu ( meaning xubuntu,
kubuntu,) for a couple years now. I just feel like I am ready to try to learn
something a bit harder.
But I have one friend telling me SUSE and I am wanting to try Fedora. is one
easier than the other to learn coming from the buntus?
I think this is a konqueror bug but would appreciate a second opinion.
When multiple l10n packages are installed and configured in system settings and konqueror requests a page I believe the "accept_language" is used to tell the server what languages are accepted and the order of priority for the language.
In konqueror when I go to start.fedoraproject.org accept_language is sent as "en-US,zh-TW;q=0.9,en;q=0.8" and the page with Content-Language of zh-TW is returned.
Chrome, on the other hand, sends accept_language "en-US,en;q=0.8,zh-TW;q=0.6,zh;q=0.4" and the English page is returned.
I believe that konqueror should also use the least common denominator for English (and other languages) in its request to cover the cases where a server doesn't fully define the page languages it can supply.
Getting tired of non-Fedora discussions and self-serving posts
On 03/26/2014 09:37 AM, Timothy Murphy wrote:
> I'm not a member of this group, which I have never heard of.
We started the process of formalizing the kde-sig to form a working
group while back (Mar 11), starting here:
In particular, see
> This poll seems a bizarre way of choosing the best way forward.
> Surely if you are going to ask anyone, you should ask KDE users.
Of course user feedback is absolutely encouraged and welcome, but
*someone* has to ultimately make that decision, and I feel strongly that
this working group is the best ones to entrust with that job.
Did any KDE or Fedora or other Linux development team ever solve the
Blu-ray mystery for the K Desktop?
I recently acquired a Samsung external Blu-ray disk player/burner
(SE-506AB). It has a USB 2.0 connector through which it gets all its
power and signal. I just plugged it into a USB port on my Linux box,
popped in a commercial Blu-ray disk, and waited to see what would happen.
Well, all that happened was, it gave me three options: open it with File
Manager, look at the photographs with Gwenview, and open it with K3b.
The option to play the video content with Kaffeine did not show.
So I guess Kaffeine doesn't know how to play a Blu-ray movie.
Come on, guys. The world's going to Blu-ray fast, now that HDTV is
becoming standard. Have I missed something? Is there a way to play a
Blu-ray title in KDE (or elsewhere in Linux), other than ripping it (in
Windows, probably) and playing the rip on my hard drive?
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?