Re: releaseme new requirement: non-conflicting files on case-insensitive FS/OS
Sven Brauch composed on 2017-11-21 12:25 (UTC+0100): > Felix Miata wrote: >> Case sensitive filesystems are one of the most annoying things about FOSS. > I'd count that as a win. InsaniTY INSaniTy InSAnItY inSANity INsANItY INSANiTY iNSaNiTy InsAnItY Boss: Worker, please get me the insanity file. Worker: which one Boss? Boss: The one spelled I N S A N I T Y! Worker: There's at least 8 spelled that way! Boss: How is that possible? Worker: A & a sound the same, B & b sound the same, C & c sound the same, ad nauseum. There's no rhyme or reason for the case differences. It's anarchistic. -- "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/
Re: releaseme new requirement: non-conflicting files on case-insensitive FS/OS
Reindl Harald composed on 2017-11-20 18:50 (UTC+0100): > what do you gain from uppercase chars in filenames? 1-unpredictable location in a sorted filename list 2-need for case-insensitivity switches to various shell and script commands 3-many additional opportunities to mistype long unpronounceable, immemorable strings Case sensitive filesystems are one of the most annoying things about FOSS. :-( -- "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/
Re: GOAL: seriously accommodate >96 DPI users (was: Let's set some goals)
Lydia Pintscher composed on 2017-08-20 15:17 (UTC+0200):
> * Appeal to All our Senses: a visually impaired user should be able to
> use all the software produced by KDE;
Put an end to the creation of "situational impairment" described on:
http://www.telegraph.co.uk/science/2016/10/23/internet-is-becoming-unreadable-because-of-a-trend-towards-light/
(second paragraph prior to last of article)
Example 1:
KDE (ostensibly justifiably) blames problem on upstream:
[a11y][u7y] kcmshell5 fonts - > Choose (Select Font) initial window size much
too small (DPI>96)
https://bugs.kde.org/show_bug.cgi?id=346122
Then upstream it lies fallow:
https://bugreports.qt.io/browse/QTBUG-45522
The font selection dialogs are hardly the only KDE dialogs that open too small
when DPI is >96. It's pretty standard that first action on dialog open in those
environments is (try to) make it bigger so that its content reasonably fits its
window size:
picker window always opens with the left pane so narrow that most entries are
indistinguishable from others <https://bugs.kde.org/show_bug.cgi?id=297217>
http://fm.no-ip.com/SS/KDE/narrowWindow143-201708201148.jpg (cuts off selects)
Example 2:
That screenshot also exhibits too small titlebar icons, resulting from the
multitude of similar systemsettings contexts obfuscating whatever location may
exist for control of those sizes. What is needed is for them to be
/*automatically*/ adjusted larger when display density is >96 DPI. OTOH, whether
due to theming or otherwise, /all/ configurability regarding icon sizing needs
to be consolidated under one umbrella category (e.g. Icons) rather than being
incorporated among components of "Workspace Theme", "Icons", "Application
Style", "Accessibility" and wherever any others may be ensconced.
Example 3:
https://phabricator.kde.org/
143 DPI screenshot including it:
http://fm.no-ip.com/SS/KDE/phabricator-20170820-2600-143.jpg
This is an example of how web sites generally, and kde.org in particular, usurps
needs and preferences of web users through sites' manner of styling. In the
screenshot you can see the mouse pointer pointing to the following CSS rule:
body {
font: 13px 'Segoe UI','Segoe UI Emoji','Segoe UI Symbol','Lato',
'Helvetica Neue',Helvetica,Arial,sans-serif;...
What that rule does is ensure:
1-the user is unlikely to enjoy seeing his personally optimal font family in use
anywhere on kde.org (as can be seen from fc-match in screenshot: Droid Sans).
2-the user is unlikely to be unable to read anything on the kde.org page until
applying defensive measure(s) against the offensive behavior that is the CSS
declaration of font sizes in px units. The 13px size employed on kde.org can be
seen to be 29.3% of the browser's preferred size (as can be seen in screenshot)
of 24px, 16^2 / 24^2 being the calculation of (physical) size (as opposed to
nominal size, which is the singular length of glyph height) to reach 29.3%.
If you'll open the URL displayed in the screenshot's right side Firefox window,
<http://fm.no-ip.com/Inet/grayurls.html>, you'll be able to see an example of
styling that accommodates users settings. Its CSS body text inherits the browser
defaults of both size and family, here, 24px and Droid Sans. FWIW, 24px happens
to equate to 12pt at the 143 DPI display density environment of the Plasma 5
screenshot host. 12pt is the size all virtually all web browsers have
historically shipped with as default, literally 12pt in some (e.g. Internet
Explorer), more often as 16px (e.g. Firefox and Safari), which in *real* world
sizing equates to 12pt @ 96 DPI.
<http://fm.no-ip.com/Auth/dpi-screen-window.html> as open there in the SeaMonkey
window, can be used, within constraints indicated thereon, to confirm your
browser's font size setting, and the /accuracy/ (which is not necessarily
indicative of suitability) of the DE host's display density configuration.
Simply use a ruler on one of its black blocks to check.
Similar technique can be employed with phabricator-20170820-2600-143.jpg. By
opening it in a viewer that permits it to be arbitrarily resized, you can adjust
its black blocks to measure their indicated width, thus closely emulating the
environment in which it was originated and see it as it was seen, at least WRT
proportions if not details.
There's much to be done to have KDE appeal to users:
1-whose eyesight is poorer than, or preferences different from, those of
software developers
2-who employ larger displays intending to enjoy larger screen objects rather
than fitting more screen objects
--
"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/
QupZilla vs. Konqueror vs. ???
I expected KHTML's lagging behind web specifications to lead to some kind of massive change before now. Nevertheless, I'm not appreciative of what seems to be the current plan. 1-I am in favor of any names that begin with either K or Q, as these naturally and beautifully identify any application as a good fit to the QT-toolkit-based KDE environment providing it. 2-"Zilla" IMO has no legitimate place in the name of any web browser that is not built using a Mozilla browser engine. Mozilla-engined browsers are the only browsers whose engine development and goals are not driven by pecuniary mega-corporate interests Google, Microsoft and Apple. Thus QupZilla is a bad name as long as neither of Mozilla's rendering engines form its heart. 3-Mozilla users have long deserved a reliable, full-featured, QT-toolkit-based web browser, one not dependent upon being built using GTK. KDE would be a natural environment for fulfilling that need. 4-Konqueror's KHTML remains the sole current web engine capable of by default permitting a computer to do with web content what it was designed to do, automatically compute, and render, object sizes with accuracy. Some years ago, web standards were inexplicably changed to dispense with this ability with the stated goal of diverting blame away from browsers for poorly rendering incompetently constructed web designs. Blink, Edge, Trident and Webkit engines all complied unconditionally. Mozilla's Gecko engine reserved a proprietary facility to retain the ability, but otherwise complied. Konqueror, configured to use KHTML, failed to comply. By so doing, it remains the only web browser able to automatically, or at all (other than by happenstance), render objects at accurate physical sizes. To do so KHTML depends only on Xorg, or its equivalent, such as Wayland, to provide a logical display density that equals physical display density. Thus, Konqueror using KHTML remains the only current web browser which unconditionally permits automatic rendering where a displayed inch measures an inch, a centimeter a centimeter, and a point a point. -- "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/
Re: Can't access kde-devel mailing list archives
Franklin Weng composed on 2017-07-14 15:25 (UTC+0800): > I'd like to find some old posts (around March~June 2016) but I couldn't > access the mailing list archive at > https://mail.kde.org/mailman/listinfo/kde-devel . When clicking the > Archives it always told me no posts yet. > Could anyone please tell me where to find all the old posts in kde-devel > mailing list? http://marc.info/?l=kde-devel=1=2 -- "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/
Re: [Kde-hardware-devel] kscreen overrides xorg.con*
On 2013-08-05 12:01 (GMT+0200) Àlex Fiestas composed: Felix Miata wrote: On 2013-07-04 16:43 (GMT+0200) Àlex Fiestas composed: Felix Miata wrote: What bug #? Does a new bug need to be filed for it to happen? https://bugs.kde.org/show_bug.cgi?id=317929 No need to add a new bug. Trying to use Fedora 19's 4.10.5 with kscreen 1.0.1, /etc/kde/share/config/kdedrc contains: [Module-kscreen] autoload=false What do you think šumski telling me or expecting this to accomplish in http://lists.opensuse.org/opensuse-kde/2013-07/msg00086.html ? Not being a programmer http://api.kde.org/4.0-api/kdelibs-apidocs/kded/html/ doesn't really tell me what kded is about. and not only is xorg.conf nevertheless overridden, but there seems to be no UI to get access to any display settings: http://fm.no-ip.com/SS/Fedora/kscreen10-kdm4105-f19-01.png .xsession-errors is empty. Xorg.0.log: http://fm.no-ip.com/Tmp/Linux/xorg0log-f19-big41.txt How is one supposed to manually configure a display currently? In that screenshot you can see 3 little buttons within the square that represents your screen. Little for sure. Sitting tiny at the bottom of a square overwhelmed by gray whitespace, sitting in a vast larger sea of white whitespace, it's anything but intuitive what might be possible from that screen. It sure could use some A11Y/U7Y love, and some descriptive text that doesn't require hovering and squinting to see. On a related note, ... configure monitors and displays? Do people call LCDs monitors? Is there a more than an immaterial semantic difference between a monitor and a display? Wouldn't just display(s), or screens, or display screens be better? The Do not overwrite Xorg configuration when using only 1 screen will be done in 1.1, either that or a blacklist of drivers. I remember that. I also remember https://bugs.kde.org/show_bug.cgi?id=317929#c13 (and today is the 5th ;-) ). Should I just sit on this a week and find 1.1 in an upcoming round of F19 updates or the next Factory kscreen build? Do you have an amended ETA on 1.1? -- 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/ ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
Re: [Kde-hardware-devel] kscreen overrides xorg.con*
On 2013-07-04 16:43 (GMT+0200) Àlex Fiestas composed: Felix Miata wrote: What bug #? Does a new bug need to be filed for it to happen? https://bugs.kde.org/show_bug.cgi?id=317929 No need to add a new bug. Trying to use Fedora 19's 4.10.5 with kscreen 1.0.1, /etc/kde/share/config/kdedrc contains: [Module-kscreen] autoload=false and not only is xorg.conf nevertheless overridden, but there seems to be no UI to get access to any display settings: http://fm.no-ip.com/SS/Fedora/kscreen10-kdm4105-f19-01.png .xsession-errors is empty. Xorg.0.log: http://fm.no-ip.com/Tmp/Linux/xorg0log-f19-big41.txt How is one supposed to manually configure a display currently? -- 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/ ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
Re: [Kde-hardware-devel] kscreen overrides xorg.con*
On 2013-07-01 12:17 (GMT+0200) Àlex Fiestas composed: On Friday 21 June 2013 14:32:22 Felix Miata wrote: One solution would be disable kscreen manually in those systems, after all it is a manual configuration what is causing your problems. Will that work for you? Sounds like it. A new option in kdmrc? Something special in ~/.config/ or ~/.kde/? For KSCreen 1.1, we are considering doing the following to improve the situation in virtual machines that could apply in your case as well: -On first boot if there is only one screen, do nothing since Xorg/Drivers generally get this right. This too sounds good, for appropriate definition of first boot. Oks, will try to figure this out for 1.1, we have another related bug so it seems that this is something we really need to get fixed. :-) What bug #? Does a new bug need to be filed for it to happen? -- 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/ ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
Re: [Kde-hardware-devel] kscreen overrides xorg.con*
On 2013-06-21 19:30 (GMT+0200) Àlex Fiestas composed: Felix Miata wrote: ...testing various software. None use more than one display at once... Underscore. The question is, on systems that for whatever reason do have any of /etc/X11/xorg.con*, is $SUBJECT necessary? Yes On single display systems and initial start, really? Most non-ancient systems do not have any /etc/X11/xorg.con*. Those that do are usually doing so for a reason. If yes generally: A-should it do so even on initial KDE (Plasma?) startup (aka empty ~/.kde/) by any given user? Yes, Xorg gets it wrong most of the times when having more than one screen. This thread was intended to focus on single display configurations. B-what should it do on any startup directly subsequent to a global X configuration change? We have to assume that all configuration in Xorg are wrong (when it comes to things that reaches the user like Fonts, dpi and the like). WRT Xorg automagic, I agree with the strategy. WRT global overrides that /etc/X11/xorg.con* contain, I don't agree. It seems to me it should only be applied via a KScreen non-default user config option to disregard /etc/X11/xorg.con* either entirely, or maybe though a submenu of specific categories. Certainly your case is one of those that have not been taken into consideration while developing KScreen, reason being that KScreen is focused on those users that are not able to write their own Xorg.conf files. What about users relying on proprietary NVidia drivers, which seem dependent on /etc/X11/xorg.con*? (I'm not among them. Maybe KScreen is a replacement for that dependence?) Said that, we do want to cover all cases so let's see what we can do to improve your situation. :-) One solution would be disable kscreen manually in those systems, after all it is a manual configuration what is causing your problems. Will that work for you? Sounds like it. A new option in kdmrc? Something special in ~/.config/ or ~/.kde/? For KSCreen 1.1, we are considering doing the following to improve the situation in virtual machines that could apply in your case as well: -On first boot if there is only one screen, do nothing since Xorg/Drivers generally get this right. This too sounds good, for appropriate definition of first boot. -- 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/ ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel
