tde-devels

devels@trinitydesktop.org

2 participants
3849 discussions

Re: [trinity-devel] TDE on dense small screens
by Vincent Reher 12 Dec '17

12 Dec '17

On Monday 11 December 2017, E. Liddell wrote: > On Sat, 9 Dec 2017 19:21:19 -0800 > Vincent Reher <tde(a)4reher.org> wrote: > > > The remaining issue concerns TDE window/menu controls that are too small. These include window resizing double-arrows, window scrollbar and associated up and down arrows, the menu-submenu right arrow, list expand-collapse (+/-) controls, checkboxes, and radio buttons. > > > > I suspect that these resources are part of QT3 but don't really know for sure. I suspect QT3 because applications that do not use that toolkit (e.g. LibreOffice and Firefox) do not manifest the problem. > > > > I am hoping that somebody more knowledgeable about GUI configuration and programming can point me in the right direction. Is this something that can be corrected via a configuration file (e.g. qtrc)? If not, can somebody point me to where in in the source code tree I should be looking and what I would need to do to correct this? > > Widget appearances are dictated by the style code, which is applied by QT3. You would > have to either fix QT3 or create a new widget style to make everything correctly HiDPI-sensitive. > However, you *may* be able to improve your experience somewhat by selecting the "High > Contrast" style and turning on "Use wider lines" in its configuration. This will make most widgets > somewhat larger. It isn't the most elegant style, though. > > If you are interested in authoring your own widget style (requires C++ knowledge, > unfortunately), you can find existing styles in tdelibs/tdestyles and tdeartwork/styles. > > If you want to patch QT3 directly, my guess is that you would have to look at > qt3/src/styles/qcommonstyle.cpp , which has a lot of size-related magic constants > you could play with. > > E. Liddell > > --------------------------------------------------------------------- > To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net > For additional commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net > Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ > Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting > > Thanks, your message was very helpful in clarifying a path forward. I tried the High Contrast style and while I agree that its appearance leaves a lot to be desired, it did seem to remedy matters by presenting larger more visible window/menu controls. That says to me that modifying an existing style might provide a solution to the problem at hand. Perhaps that won't be as modern a solution as a true "it just works" dynamic scaling of these graphical controls, but it will be good enough for me if it allows me to run TDE on laptops such as these at native resolution. Interestingly, one of the things that was not corrected by that style was the really tiny window resizing cursor. I investigated further and noticed that my favorite cursor theme "Xfree theme redglass" now has an annotation "incomplete for TDE" -- I had never noticed that before. I guess the theme is incomplete because it lacks the "redglass" window resizing cursor. Without it, this particular cursor becomes "Adwaita", a theme that apparently doesn't scale at all. I guess I will also have to learn how to "complete" the redglass theme. -------------------------------------------------------

1 0

TDE on dense small screens
by Vincent Reher 12 Dec '17

12 Dec '17

Hello TDE Developers, I recently purchased a Dell XPS15 laptop for my daughter and before I turn it over to her, I am experimenting to see what must be done to make it usable under Linux/TDE for those with no better than normal eyesight. Per EDID, the laptop's native screen resolution is 3840 x 2160 and its physical screen dimensions are 346 x 194mm (~15.6" diagonal). My objective is to run the laptop at native resolution both inside and outside of X (no re-scaling). Using the EDID metrics, it is pretty easy to determine during boot an optimum terminal font (ter-i32b.psf) and X font scaling (Xft.dpi=240). After that, using the TDE control panel to increase panel and icon sizes produces a nice looking desktop environment … almost. The remaining issue concerns TDE window/menu controls that are too small. These include window resizing double-arrows, window scrollbar and associated up and down arrows, the menu-submenu right arrow, list expand-collapse (+/-) controls, checkboxes, and radio buttons. I suspect that these resources are part of QT3 but don't really know for sure. I suspect QT3 because applications that do not use that toolkit (e.g. LibreOffice and Firefox) do not manifest the problem. I am hoping that somebody more knowledgeable about GUI configuration and programming can point me in the right direction. Is this something that can be corrected via a configuration file (e.g. qtrc)? If not, can somebody point me to where in in the source code tree I should be looking and what I would need to do to correct this? Of course, if HiDPI issues have already been addressed by others in the post R14.0.4 source code, that would be great. Thanks in advance for your insights and help. Vince Reher

4 3

TDE for Debian & Devuan
by Michael Howard 12 Dec '17

12 Dec '17

Being a bit busy at the mo (and maybe a little lazy) can anybody tell me if there are significant differences between TDE for Debian & Devuan? If I were using Debian Stretch _without_ systemd, which would be the better choice of TDE install? Cheers, Mike. -- Mike Howard

3 4

Re: [trinity-devel] TDE on dense small screens
by Vincent Reher 12 Dec '17

12 Dec '17

On Saturday 09 December 2017, Felix Miata wrote: > [I am not a developer.] > > Vincent Reher composed on 2017-12-09 19:21 (UTC-0800): > > > I recently purchased a Dell XPS15 laptop for my daughter and before I turn it > > over to her, I am experimenting to see what must be done to make it usable > > under Linux/TDE for those with no better than normal eyesight. Per EDID, the > > laptop's native screen resolution is 3840 x 2160 and its physical screen > > dimensions are 346 x 194mm (~15.6" diagonal). My objective is to run the > > laptop at native resolution both inside and outside of X (no re-scaling). > > > Using the EDID metrics, it is pretty easy to determine during boot an optimum > > terminal font (ter-i32b.psf) and X font scaling (Xft.dpi=240). After that, > > using the TDE control panel to increase panel and icon sizes produces a nice > > looking desktop environment … almost. > > 15.6" nominal is physically 282.42 DPI @3840x2160 resolution: > http://fm.no-ip.com/PC/displays.html > > 3840x2160 is considered "quad density", aka 4K resolution. > > For a little perspective, consider what increased density means drawing icons or > text characters compared to lower resolutions. > > 15.6" nominal is 141.21 DPI @1920x1080 resolution (the HDTV standard). > The reference DPI, on which web standards are based, and from which most > software developers worked until production display densities started to > considerably exceed the standard reference, is 96. A screen that actually is 96 > DPI @1920x1080 would be almost 23". > > At the reference, a 16px by 16px icon is comprised at most of 16^2 or 256 > pixels, and measures 4.417mm square. Going down to a 15.6" screen at that same > resolution shrinks those same pixels into a 141 DPI 3.003mm square space. > Raising the resolution to *nominal* quad (3840x2160) squeezes those 256px into > 242 DPI 1.502mm square space. > > The converse is that in order to get an icon that was 4.417mm square on a true > 96 DPI screen to stay that size on a 15.6" screen @1920x1080 would require > utilizing approximately 554 pixels. On a quad screen, 3840x2160, that jumps to 2216. > > Computers can be programmed to scale up objects so as to improve their physical > size, but with images that comprise the standard 96 DPI icons, their appearance > cannot be improved to take advantage of higher available pixel density. Higher > density screens need to have different, and much larger, icons. > > > The remaining issue concerns TDE window/menu controls that are too small. > > These include window resizing double-arrows, window scrollbar and associated > > up and down arrows, the menu-submenu right arrow, list expand-collapse (+/-) > > controls, checkboxes, and radio buttons. > > > I suspect that these resources are part of QT3 but don't really know for > > sure. I suspect QT3 because applications that do not use that toolkit (e.g. > > LibreOffice and Firefox) do not manifest the problem. > > TDE and its own applications are QT3-based. QT3's initial release was 16 years > ago and for all practical purposes its development ended 3.5 years later, mid-2005. > > QT3's design foundation is close to two decades old, well before developers had > to consider escalation of display densities. Some elements could be scaled with > density, by using units that scaled (e.g. pt, mm or in), but images weren't > among them. Some design elements used a mixture of pixel units and scalable > units, while others used one or the other. Compromises were inevitable where > densities varied more than a little from the standard. > > Image scaling simply can't work as well as today's "HiDPI" screens require. > Either images in additional sizes need to be provided, or a different kind of > image designed to be scaled need to be provided, or both. QT3 wasn't designed > for scalable images, and no one ever provided much in the way of additional > images, or just as, or more, importantly, an effective framework for utilizing > them without compromises. > > Getting TDE off QT3 onto a foundation that fully supports "HiDPI", assuming any > such open source foundation actually exists at this point, in my estimation > would require resources several orders of magnitude larger than those available > to the TDE project. > > > I am hoping that somebody more knowledgeable about GUI configuration and > > programming can point me in the right direction. Is this something that can > > be corrected via a configuration file (e.g. qtrc)? If not, can somebody > > point me to where in in the source code tree I should be looking and what I > > would need to do to correct this? > > IMO you're probably facing a choice between using TDE and not using native > resolution. At a normal viewing distance, 141 DPI ought to be as high a display > density as anyone with no better than average visual acuity can fully > appreciate, absent side-by-side comparisons, where differences may or may not be > detectable without getting closer or using a magnifying glass. > > I suggest giving 1920x1080 (physically 141 DPI) a try. The kernel cmdline can be > configured through the bootloader menu to have it override EDID and use > 1920x1080. Xorg and thus TDE should use that mode automatically, but if it does > not, Xorg can readily be configured to use it directly. TDE settings can do same > if need be. > > Fonts in apps generally work best if DPI is a multiple of 24 (96 * 1.25, > 96*1.50, 96*1.75, etc.), less well at 12X, even less well at 4X or 8X, so at > 1920x1080 you might wish to try forcing DPI to 143 or 144. 144 is a breakpoint > in some software design, so you might notice some big differences between 143 > and 144. Depending on how good your daughter's vision is, leaving logical DPI > set to its 96 default may well prove acceptable with 1920x1080. > > > Of course, if HiDPI issues have already been addressed by others in the post > > R14.0.4 source code, that would be great. > Leaving QT3 has been suggested, but I've seen nothing on this mailing list or on > IRC to suggest anyone thinks it could ever happen. > > HTH Felix, thank you for your lengthy if somewhat pessimistic reply. To be clear, I have no issue whatsoever with the fonts -- they look great on this display with Xft.dpi=240, perhaps in part due to my past efforts at making fonts look reasonable on Linux desktops. And the desktop/panel icons are fine after stepping up to larger sizes (no scaling). It's just those apparently fixed-size bitmap images used for window/menu controls that are way too tiny. If indeed the problem lies in QT3 and it cannot be "configured away" either during build time or run time, then I simply ask for somebody more knowledgeable to point me in the right direction so I can start looking and experimenting with the source code. I am also not suggesting TDE be ported to QT>3. I know that is a non-trivial effort and would not be feasible. Also, I am not even sure that QT fixed this problem until the 5.x versions (http://doc.qt.io/qt-5/highdpi.html). To downsize from native resolution on this laptop would be to admit defeat and loose a touted feature. It's not going to be a problem for my daughter since most of the software she needs to run is "windows only" and the laptop's pre-installed Windows 10 does not seem to have any problem at all. It may be a problem eventually for me should I choose to get a similar laptop and stick with TDE.

1 0

kgpg related bugs
by deloptes 10 Dec '17

10 Dec '17

Hi Slavek, all, I was looking today in some related bugs and I think you can close http://bugs.pearsoncomputing.net/show_bug.cgi?id=630 won't fix and http://bugs.pearsoncomputing.net/show_bug.cgi?id=1090 should be fixed in the new kgpg you committed regards

1 0

[trinity-devel] openSUSE 42.3 packages require older libIlmImf
by Felix Miata 28 Nov '17

28 Nov '17

Does the following requirement of unavailable older package make sense? Shouldn't the requirement be >= rather than =? # zypse libIlm | libIlmImf-2_2-22-32bit | package | 2.2.0-2.1 | x86_64 | OSS | libIlmImfUtil-2_2-22 | package | 2.2.0-2.1 | x86_64 | OSS | libIlmImfUtil-2_2-22-32bit | package | 2.2.0-2.1 | x86_64 | OSS | libIlmThread-2_2-12-32bit | package | 2.2.0-2.2 | x86_64 | OSS i | libIlmImf-2_2-22 | package | 2.2.0-2.1 | x86_64 | OSS i | libIlmThread-2_2-12 | package | 2.2.0-4.1 | x86_64 | Packman v | libIlmThread-2_2-12 | package | 2.2.0-2.2 | x86_64 | OSS # zypper -v dup Verbosity: 1 Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Initializing Target Loading repository data... Reading installed packages... Computing distribution upgrade... Force resolution: No Computing upgrade... 9 Problems: Problem: nothing provides libIlmImf-Imf_2_1.so.21()(64bit) needed by trinity-tdelibs-14.0.4-1.oss423.x86_64 Problem: nothing provides libIlmImf-Imf_2_1.so.21()(64bit) needed by trinity-tdebase-tdeio-plugins-14.0.4-1.oss423.x86_64 Problem: nothing provides libmng.so.1()(64bit) needed by libtqt3-mt-3.5.0-14.0.4_1.oss423.x86_64 Problem: nothing provides libIlmImf-Imf_2_1.so.21()(64bit) needed by trinity-tdebase-tdeio-plugins-14.0.4-1.oss423.x86_64 Problem: nothing provides libIlmImf-Imf_2_1.so.21()(64bit) needed by trinity-tdebase-tdeio-plugins-14.0.4-1.oss423.x86_64 Problem: trinity-tdebase-tdeio-pim-plugins-14.0.4-1.oss423.x86_64 requires libldap-2.4.so.2()(64bit), but this requirement cannot be provided Problem: nothing provides libIlmImf-Imf_2_1.so.21()(64bit) needed by trinity-tdebase-tdeio-plugins-14.0.4-1.oss423.x86_64 Problem: firefox-esr-17.0.11-1.49.x86_64 requires libgstapp-0.10.so.0()(64bit), but this requirement cannot be provided Problem: nothing provides libIlmImf-Imf_2_1.so.21()(64bit) needed by trinity-tdebase-tdeio-plugins-14.0.4-1.oss423.x86_64 Problem: nothing provides libIlmImf-Imf_2_1.so.21()(64bit) needed by trinity-tdelibs-14.0.4-1.oss423.x86_64 Solution 1: Following actions will be done: deinstallation of trinity-tdelibs-14.0.4-1.oss422.x86_64 deinstallation of trinity-gtk-qt-engine-2:0.8-14.0.4_1.oss423.x86_64 deinstallation of trinity-gtk3-tqt-engine-2:0.5-14.0.4_1.oss423.x86_64 deinstallation of trinity-kmix-14.0.4-1.oss423.x86_64 Solution 2: keep obsolete trinity-tdelibs-14.0.4-1.oss422.x86_64 Solution 3: break trinity-tdelibs-14.0.4-1.oss423.x86_64 by ignoring some of its dependencies Choose from above solutions by number or skip, retry or cancel [1/2/3/s/r/c] (c): c -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/

1 0

New version of TDE PCLinuxOS remaster, version November 16, 2017
by Alexandre Couture 18 Nov '17

18 Nov '17

Hi, After a little pause of about 2 years, I decided to put together a brand new version on my PCLinuxOS TDE remaster. This new new version is a 64 bit system, with TDE 14.0.4, a 4.12.x kernel and no systemd. It has an appearance similar to Plasma 5, but with TDE workflow and apps. Login info: Guest user: guest guest password: guest Root user: root Root password: root Here is the link to download it: https://drive.google.com/file/d/1jcnG-arMt8B-odzVaVXMLbfJMfHKF6CC/view?usp=… Md5 checksum: 7d0ff8ad8f68cd4db8679a45d9aa4daa Have a great day! -Alexandre

4 3

devuan ascii, a note
by Dr. Nikolaus Klepp 27 Oct '17

27 Oct '17

Hi all! I just upgraded my testsystem from devuan jessie to devuan ascii. Everything went quite smooth, I just got this note for the tde repository: W: Konflikt bei Distribution: http://mirror.xcer.cz/trinity-sb ascii InRelease (ascii erwartet, aber stretch bekommen) Looking at the Release-file, it realy says "stretch" for the "ascii" repository :-) Nik -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ...

2 2

[trinity-devel] is hard dependency valid for CJK fonts for trinity-tdm/lib64xt6 on Mageia
by Felix Miata 20 Oct '17

20 Oct '17

Trinity-tdm refuses to install because via skip.list I block useless fonts (daewoo, jis, isas) from polluting my system and wasting bandwidth during installation and updates, which in turn blocks installation of lib64xt6. :-( Googling for lib64xt6 seems interested only in providing hits for packaging and source, nothing about what it is or does. rpm -qi lib64xt6 does little better: Description: X Toolkit Intrinsics library used to build older generation toolkits such as Motif & Xaw. What could this have to do with otherwise optional fonts? -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/

2 1

mirror.xcer.cz download site....heads up...
by Keith Daniels 17 Oct '17

17 Oct '17

This is just a heads up, you probably already know... "When I ran apt-get update" at 6 pm today, apt found the site, read through the package list, then gave a GPG error of no Public Key: NO_PUBKEY 608F529A304BE668 It said there was no public key available for mirror.xcer.cz and would not download Trinity. I had already uploaded your key, using apt-key and verified that it was installed and working. I was downloading the Trinity 14.4 version for use with Debian stretch version 9.1 Yesterday, on my first attempt to install Trinity on stretch, the Trinity package from that mirror, downloaded with no problems. Debian was a problem though and had to be reinstalled, which is why I am doing the complete install again today. I will keep trying until it comes back up, I have no computer currently, so I can only check my emails when I go to a friends house and use his. Keith

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels