xcb windowing system
by Nathan England
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sorry for the ignorant question, but I just noticed this and I'm
curious...
When I open Dolphin and click on Control->Help->About Dolphin and then
select Version it says
The xcb windowing system
Can someone explain what this is? I'm not familiar with xcb. And why
doesn't this say the KDE windowing system?
- -- Nathan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJXsC4VAAoJEOuk7+DwYjzgMMwH/AoZZabImL7bqVmQe5ZIb6iW
BuzmTwFKI/AVFRuBMfb7W3Ig7eOxF5zAhDSherMsZaP44vuFwIit6d+HpM/S6CmC
WJIHdqlSQxGNMzb9VDTPM7dUPtkI6NEO+cu7HxWy5HKx3pTIX+iGmwudtctowzN3
D+gRcjRPQOtEAcDkojcputPbG39DksSs0uwDe6ANnSDSMsq6e4C27pvP+hsf7bMZ
PgTNkwLLXdVQXHb789MNWgILAB49vjxoH1uEx7XwJIH8PIvJiXa4sCHj89TxtxS7
kY+GGYW3nUmhhNWLz1dcE+O2NUNyrob7stG7a7FUyDir1WQIvIa0r7bSDQZXMJw=
=nc3O
-----END PGP SIGNATURE-----
7 years, 7 months
Default Browser Voting - and apparent inconsistency with mission statement
by Gerald B. Cox
Rex requested that I start a separate thread on this if I believed it
warranted further discussion. I believe it does. I believe that the
current voting proposal currently underway for the selection of default
browser does not align with the mission statement of the Fedora KDE SIG.
Below is the text of my previous message which was attached to the initial
voting results. I understand that some voting has yet to be completed -
but unless I am mistaken this isn't suppose to be a vote about browser
personal preference. It is suppose to be a vote about which browser aligns
with the published mission of the KDE SIG.
=========================================
Thanks very much Rex for posting this so quickly. I would be interested in
understanding
the reason people voted the way they did. The issue IMO is that normally,
when selecting
a default you have well defined criteria for making the decision. This
assists in making sure
that everyone is on the same page and is making an objective decision. For
example, as I
mentioned before I'm a big proponent of all things Chrome - but even if the
Chromium that
exists in the Fedora repository was in a state that what I would consider
stable (it's not, IMO)
I would still choose qupzilla in this instance. It fits into what I
believe would be the mission
of the KDE spin. Obviously, there is an extreme disconnect between what I
believe the mission
to be, and the opinion of others. I believe the lack of clarity is causing
friction. There can be
a big difference between personal preference and adherence to a defined
mission. From the
wiki:
"The KDE SIG (Special Interest Group) is a group of Fedora contributors
that maintain KDE <https://fedoraproject.org/wiki/KDE>
packages in Fedora.
Their mission is to provide high-quality, usable KDE software packages to
Fedora users and developers and to
support one another in maintaining those packages."
Granted, qupzilla is not an official KDE project, but it is definitely
using KDE based technologies.
That tells me that all things considered, if there is a browser that uses
these technologies, and is
functional - that it should be favored over other contenders - unless there
is a complelling reason.
Unless I'm missing something, I don't see that "compelling reason".
Personal preference
does NOT outweigh a mission statement.
What am I missing here? From an outsider looking in, it appears that
everyone is voting based
upon different criteria and not adhering to the mission statement. Voting
members have a
responsibility to be consistent and objective.
Mission statements exist to provide clarity, direction and to hold decision
makers accountable.
7 years, 7 months
opengl-3.1 with intel graphics
by Neal Becker
I have
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev
09)
glxinfo | grep OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2)
OpenGL core profile version string: 4.3 (Core Profile) Mesa 12.0.1
OpenGL core profile shading language version string: 4.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 12.0.1
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 12.0.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:
But if I select opengl 3.1 in settings/display/compositor, it doesn't work
reliably. It seems sections of screens are often not updated. This doesn't
happen if I select opengl 2.
I read that intel opengl depends on mesa, and whatever mesa claims to
support should work. Doesn't seem to, any ideas?
7 years, 7 months
Ctrl N not working on kmail
by José Abílio Matos
Ever since I installed Fedora on this laptop in May (Fedora 24 beta at the
time I think) that kmail always display an annoying warning when I press Ctrl
N (for a new message):
The key sequence 'Ctrl+N' is ambiguous. Use 'Configure Shortcuts'
from the 'Settings' menu to solve the ambiguity.
No action will be triggered.
The option was to go to Settings->Configure Shortcuts and remove the default
shortcut from "New Message". Then it works.
If I try to set the default shortcut to "New Message" action I get a warning:
The 'Ctrl+N' key combination is already used by the New Message... action.
Please select a different one.
????
I am puzzled, but at least now it works. :-)
--
José Abílio
7 years, 7 months
DPI >96 = Bad UI fonts in Geckos built with GTK3
by Felix Miata
UI fonts in Firefox, as noted in another thread, (and UI fonts in SeaMonkey),
no longer match those configured in Plasma settings if Xorg's DPI is 120 or
more (I've not tested at less):
http://fm.no-ip.com/SS/Fedora/ff45ff48qz201-f25-168.jpg
This began with building Geckos with GTK3 (rv46 and up in mozilla.org builds)
instead of GTK2.
In Mageia 5 and openSUSE 13.1, which are using GTK3 3.16 versions, FF fonts
are as they should be. Supported Fedora releases all use GTK3 versions >3.16
for the latest FF and SM versions, which produce the too small Gecko fonts.
https://bugzilla.mozilla.org/show_bug.cgi?id=1269274
seems to explain why this is happening, but not whose job it should be to
fix. Apparently Mozilla's not going to accept the responsibility. I asked on
the gtk-devel list and got no response:
https://mail.gnome.org/archives/gtk-devel-list/2016-July/msg00028.html
Any ideas whose responsibility it should be?
Anyone know of a KDE, Gnome/GTK or RedHat BZ bug already addressing this
problem? Is there a fix in the form of an rpm I simply haven't discovered and
installed?
Installed GTK packages on F24 on host big41:
gtk+-1.2.10-82.fc24.x86_64
gtk2-2.24.30-1.fc24.x86_64
gtk3-3.20.6-1.fc24.x86_64
gtk-update-icon-cache-3.20.6-1.fc24.x86_64
kde-gtk-config-5.7.3-1.fc24.x86_64
libcanberra-gtk2-0.30-11.fc24.x86_64
libcanberra-gtk3-0.30-11.fc24.x86_64
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
7 years, 7 months
digikam5 problems
by Chris Rouch
I recently upgraded to fedora 24 and so now get digikam 5.0.0.
Unfortunately, like most of the rest of plasma5, it has thrown away my
settings and started again.
With digikam4, I had it set up so that photos were imported into a folder
based on the date the image was taken. I can't find the option to do this.
Is it possible or does everything have to be imported to the same folder?
Once imported, I can find an option to rename based on date, but not one to
move to a folder based on date (the rename dialog does not accept "/"). Is
that possible or should i use bash and hope the digikam database catches up
later?
The included handbook (from the help menu), is version 1.2 (2010-02-20). It
doesn't say which version of digikam it is for, but the contents seem to
match what I recall of the previous version (e.g. the automatic renaming
section).
Should I raise bug reports for the lack of rename option and the old manual
version or am I missing something obvious?
Regards,
Chris
7 years, 7 months
Panel Move
by Ed Greshko
I'm running a dual-monitor setup. One connected to HDMI the other to a DP. The HDMI is
tagged as "primary".
Today, during a chase, my cats managed to yank out the monitor cables. After putting them
back in place the panel had shifted from the HDMI display to the DP display. I could find
no setting or menu item to move the panel. So, I resorted to creating a new panel on the
HDMI display and then deleting the one on the DP. A bit of a pain since I had to redo all
the favorites and widgets.
Is there a way to move a panel? I seem to recall back in the KDE4 days you could drag the
panel to where you wanted it. That doesn't seem possible now.
--
You're Welcome Zachary Quinto
7 years, 7 months
KDE logspam on F24
by Reindl Harald
it's one thing that KDE spams the syslog all day long, but complaining
on enduser machines about unclean stuff which should be fixed by
upstream suggests that *they* should read their outputs instead annoy
users all day long with it
Aug 4 19:10:13 srv-rhsoft kbuildsycoca5: kf5.kservice.sycoca: The menu
spec file contains a Layout or DefaultLayout tag without the mandatory
Merge tag inside. Please fix your file.
Aug 4 19:10:13 srv-rhsoft kbuildsycoca5: kf5.kservice.sycoca: The menu
spec file contains a Layout or DefaultLayout tag without the mandatory
Merge tag inside. Please fix your file.
Aug 4 19:10:13 srv-rhsoft kbuildsycoca5: kf5.kservice.sycoca: The menu
spec file contains a Layout or DefaultLayout tag without the mandatory
Merge tag inside. Please fix your file.
Aug 4 19:10:13 srv-rhsoft kbuildsycoca5: kf5.kservice.sycoca: The menu
spec file contains a Layout or DefaultLayout tag without the mandatory
Merge tag inside. Please fix your file.
Aug 4 19:10:59 srv-rhsoft gwenview: Found no root index for
QUrl("/home/harry/Desktop")
Aug 4 19:11:46 srv-rhsoft kbuildsycoca5: kf5.kservice.sycoca: The menu
spec file contains a Layout or DefaultLayout tag without the mandatory
Merge tag inside. Please fix your file.
Aug 4 19:11:46 srv-rhsoft kbuildsycoca5: kf5.kservice.sycoca: The menu
spec file contains a Layout or DefaultLayout tag without the mandatory
Merge tag inside. Please fix your file.
Aug 4 19:11:46 srv-rhsoft kbuildsycoca5: kf5.kservice.sycoca: The menu
spec file contains a Layout or DefaultLayout tag without the mandatory
Merge tag inside. Please fix your file.
Aug 4 19:11:46 srv-rhsoft kbuildsycoca5: kf5.kservice.sycoca: The menu
spec file contains a Layout or DefaultLayout tag without the mandatory
Merge tag inside. Please fix your file.
7 years, 7 months