I asked about a possible solution to this elsewhere, generating no response
as yet:
https://mail.gnome.org/archives/gtk-devel-list/2016-July/msg00028.htmlhttps://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org/t…
Apparently, a fix from mozilla.org is unlikely forthcoming, while a
particular Gnome commit is highly likely responsible for the regression in
Firefox and SeaMonkey built by mozilla.org with GTK3 toolkit:
"UI text sizes no longer inherited from Linux system"
https://bugzilla.mozilla.org/show_bug.cgi?id=1269274
Screenshot of mozilla.org's FF48 in TDE on openSUSE 1920x1080 @132DPI display
showing the problem:
http://fm.no-ip.com/SS/Moz/uifontsRV48-s422tde-132.jpg
Screenshot of mozilla.org's FF48 in TDE on openSUSE 1680x1050 @108DPI display
showing the problem:
http://fm.no-ip.com/SS/Moz/uifontsRV48-s422tde-108.jpg
Screenshot of mozilla.org's FF48 in TDE on openSUSE 1680x1050 @108DPI display
showing no such problem before the update of GTK3 from 3.16 to 3.20:
http://fm.no-ip.com/SS/Moz/uifontsRV48-s421tde-108.jpg
Screenshot of mozilla.org's FF48 and FF45 on Fedora 24 with Plasma5 @168DPI
display showing problem is not unique to TDE, and doesn't exist in FF45:
http://fm.no-ip.com/SS/Moz/uifontsRV48-f24K5-168.jpgMozilla.org's FF ESR 45 is still built with GTK2, so doesn't have the
problem. SeaMonkey 2.40 is also built with GTK2, so also has no problem. All
the mozilla.org alphas and betas are being built with GTK3, so all manifest
the problem unless used with system GTK3 libs 3.16 or older.
Whether this problem shows up in Firefox or SeaMonkey provided by individual
distros depends on which toolkit is used to build them. In Fedora, the switch
to GTK3 has been made, as have been the GTK3 libs past 3.16, the last before
the upstream patch. Thus, all current rpms from Fedora produce the problem.
In openSUSE Tumbleweed, Firefox 48 is still built with GTK2, so even though
it has switched to 3.20 GTK3 libs, the problem there hasn't yet appeared.
Stretch has 3.20 GTK3 libs, builds FF 45ESR with GTK2, so has the problem in
FF with mozilla.org builds but not with its available FF .deb package. Jessie
is OK, with only GTK3 lib 3.14. Buntu 16.04's GTKs3 lib is 3.18. Its FF 48
buildconfig screen doesn't include the string gtk anywhere, but apparently
it's using the GTK3 default, and thus also not obeying TDE's UI font
specification.
So, to eventually restore parity to all distro and version installations,
always having the Geckos use the UI fonts specified in Trinity desktop
settings, something needs to be done. The question is where. Is getting
upstream patch reversion the right answer? Would some new or altered
gtk-*qt*-trinity package be good, only, or better answer? Would some new or
altered theme package be a right answer? Is there already some solution that
just hasn't been installed yet?
--
"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/
Hi,
in the past few days I found some time to revive my work on the libkcal
testing, but I noticed that no debug information is printed out by the test
programs.
I suspect it is because it gets compiled without debugging, but I am not
sure, as (if you recall I asked you how to compile the project and you
instructed to use the debian/rules file) I don't know where and how to tell
the rules file to add/activate debugging.
I use something like
DEB_MAKE_CHECK_TARGET=testing fakeroot debian/rules build
at the moment.
I'll appreciate some ideas. Thank you in advance
regards
hi folks - all working, just thought you might like to know.
installation was very straightforward, and unlike a couple of months
ago on a devuan amd64 system worked perfectly without package
conflicts.
can i recommend that you put devuan on the list of OSes as it's
clearly much much faster, and hugely less hassle.
l.
---
crowd-funded eco-conscious hardware: campaign running LIVE:
https://www.crowdsupply.com/eoma68/micro-desktop
Has anyone here figured out if there's some other package that can be
installed or some other fix or workaround to avoid this upstream tiny UI
fonts bug with trying to use GTK3 builds of Firefox (47+) & SeaMonkey (2.43+)
without having to have Gnome3 installed?:
https://bugzilla.mozilla.org/show_bug.cgi?id=1269274
--
"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/
I am trying to reinstall Jessie from the Debian Trinity Repo
I added:
deb http://mirror.ppa.trinitydesktop.org/trinity/trinity-r14.0.0/debian
jessie main
deb http://mirror.ppa.trinitydesktop.org/trinity/trinity-builddeps-r14.0.0/
debian jessie main
to : /etc/apt/sources.list file
I ran:
# apt-key adv --keyserver keyserver.quickbuild.pearsoncomputing.net
--recv-keys
F5CFC95C
in a root console.
I then ran:
# apt-get update
from the same root console, and after it finished reading everything in the
package list, I got this error message TWICE in a row:
W: GPG error: http://mirror.ppa.trinitydesktop.org jessie Release: The
following signatures couldn't be verified because the public key is not
available: NO_PUBKEY 96C95152F5CFC95C
The above was exactly what I did 3 days ago and it worked at that time.
Is there a problem with the public keys or am I somehow doing something
wrong?
Keith
$SUBJECT appears identical on same machine booted to Jessie/14.0.3, including
correct (external) speakers used in IceWM session. :-(
Felix Miata composed on 2016-07-16 21:21 (UTC-0400):
> On other PCs with openSUSE (42.1, 13.2 & 13.1) and TDE 14.0.x that have no
> speaker built into the motherboard, I've not experienced $SUBJECT, sound
> simply works as expected. On this PC, a SFF Dell Optiplex 780, aplay and
> speaker-test work as expected whether run in multi-user.target or
> graphical.target, as does Youtube sound running an IceWM session, producing
> sound from accessory speakers plugged into the green jack, only if a TDE
> session is not running or has not been running since the last instance of
> 'alsactl restore'. Speakers always work as expected in openSUSE Tumbleweed
> running Plasma5 or openSUSE 13.2 or 13.1 running KDE4 (none of which have
> their respective pulseaudio packages installed).
> IOW, TDE redirects sound to the internal speaker that should be going to
> external speakers, only on this one PC. Might there be a fix for this that
> does not involve polluting the installation with the otherwise unnecessary
> Pulseaudio rpm and its deps?
> output of alsa-info.sh:
> http://fm.no-ip.com/Tmp/SUSE/421/alsa-info-gx780-s421.txt
> Various installed rpms:
> alsa-1.0.29-10.1.x86_64
> alsa-firmware-1.0.29-3.2.noarch
> alsa-plugins-1.0.29-10.1.x86_64
> alsa-utils-1.0.29-9.1.x86_64
> arts-1.5.10-66.2.x86_64
> libasound2-1.0.29-10.1.x86_64
> libpulse-mainloop-glib0-7.0-5.1.x86_64
> libpulse0-7.0-5.1.x86_64
> trinity-arts-1.5.10-14.0.3_1.oss421.x86_64
> trinity-kmix-14.0.3-1.oss421.x86_64
> trinity-libarts-akode-14.0.3-1.oss421.x86_64
> trinity-libarts-audiofile-14.0.3-1.oss421.x86_64
> trinity-libarts-mpeglib-14.0.3-1.oss421.x86_64
> trinity-libarts-xine-14.0.3-1.oss421.x86_64
> (as yet ignored) opensuse mailing list thread (from before I found alsactl
> restore helped outside of a TDE session):
> https://lists.opensuse.org/opensuse/2016-07/msg00283.html
--
"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/
Hi,
in the course of vcard and the encoding issue I ask herewith for help to
solve another annoying utf8 encoding issue.
Problem:
Attached images show that My_Documents when language set to bg gets mangled.
Unfortunately looking into this I found out it is mangled in
/opt/trinity/share/apps/kdesktop/Desktop/My_Documents
I tested in fresh install of TDE, but after first logout/login it changed
I workaround it by fixing the file and removing the write permissions.
I don't know where to look for the system:/ entry.
regards
Hi,
after few months of testing, I do not see any issues in the TDE
backends/plugins.
I want to finalize this work and upload the code in some way. I asked
SyncEvolution about it [1,2] while trying to build 1.5.1 against synthesis.
This required version which is provided in debian sid. Unfortunately I hit
a bug [3] and I think I'll try against syncevolution from git as the patch
for [3] is still to be uploaded for 1.5.1.
What I want to discuss with you based on [1] is if you think it is wise to
provide syncevolution-whatever-trinity package(s), which for the moment I
think is the best and fast (but not optimal) solution. I will call this
short term solution - STS.
I think it would be more complex to push each distro to include support for
tdepim in syncevolution, but in long term it is the best solution. I will
call this long term solution - LTS. However I think there are still few
places to improve in the code (the calendar part mostly) and there are some
issues in the underlaying libkcal or whatever handles the todo's
subject/description when utf-8 and/or quoted content. In fact I dropped
support for cal v1 in the plugins as it looks broken and I did not have
time to deal with it. SyncEvolution does convert internally a v1 cal into
v2 just excellent.
So the plan for the STS would be to modify the vendors build scripts (I know
only debian ... so debian/*) to produce the syncevolution packages with
trinity extention, which will be build with the tdepim/wallet support on
top of the vendors configure options. Those packages should replace the
vendors own packages and thus provide the tdepim support.
The LTS would easy the way that we'll have tdepim/wallet in the mainline,
but perhaps we should still provide packages to overwrite the distros
shipped package.
Based on this what are you thinking?
Thanks in advance
[1] http://comments.gmane.org/gmane.comp.mobile.syncevolution/5396
[2] http://comments.gmane.org/gmane.comp.mobile.syncevolution/5393
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824426