On my notebook (OpenSuSE install) the following happens, if I place the
"kicker" panel upright on the right side:
* "kicker" completely hogs 1 core (with ~4000 BogoMIPS) for around 150 seconds
(yes 2:30!), just to layout and display the panel and react to interaction
again
* the resulting layout is very far from optimal (to be polite)
* whenever I try to change any configuration option, either via 'kcontrol' or
panel functions, a new "kicker" is spawned, incurring the 2:30 minutes
paralysis penalty
* when trying to change the panel-clock configuration (hoping) to improve
layout, the system after some minutes was driven into a trashing frenzy so
bad, I had to physically switch of the machine (STRG+ALT+DEL or STRG+ALT+BS or
switching to a VT were not possible anymore, terminal windows not reactive,
even "top" was essentially frozen!)
To better understand your vision of Trinity -- what is your perception:
On one hand the code base is from KDE3 in the era of 4:3 displays -- placing
the panel sideways was at least unusual -- I never tried, and don't know if
this ever worked or was expected to work ...
On the other hand, in the era of 16:9 displays IMHO side panels are a
desirable option ...
So, is the reported behavior
* a bug report?
* a request for improvement?
* a change request?
* to be expected and tolerated for such an uncouth non-traditional
configuration (;-) ?
Best regards,
ThoMaus
Is there a way to tell if the mirrors are in an unusable state? I just
did a minimal X openSUSE 42.1 installation expecting to install TDE on
it, and everything I try to install depends on some package or other that
cannot be provided. e.g.:
Selecting 'trinity-tdeutils-14.0.2-1.oss421.x86_64' from repository 'TDE' for installation.
Problem: nothing provides libaudio.so.2()(64bit) needed by libtqt3-mt-3.5.0-14.0.2_1.oss421.x86_64
Selecting 'trinity-konsole-14.0.2-1.oss421.x86_64' from repository 'TDE' for installation.
Problem: nothing provides libaudio.so.2()(64bit) needed by libtqt3-mt-3.5.0-14.0.2_1.oss421.x86_64
Selecting 'trinity-tdebase-14.0.2-1.oss421.x86_64' from repository 'TDE' for installation.
Problem: nothing provides libmad.so.0()(64bit) needed by trinity-arts-2:1.5.10-14.0.2_1.oss421.x86_64
Selecting 'trinity-tdemultimedia-14.0.2-1.oss421.x86_64' from repository 'TDE' for installation.
Problem: nothing provides libmad.so.0()(64bit) needed by trinity-libarts-mpeglib-14.0.2-1.oss421.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/
Hi all!
Would this be interesting to do with TDE sources?
http://www.viva64.com/en/b/0377/
Nik
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
I appreciate your work much Trinity TDE seems to be the only X11 desktop left
providing enough functionality and configurability to support an ergonomic and
powerful X11 GUI for me(FOOTNOTE{Usage}). And it is significantly improved
over KDE 3.5!
That said, nevertheless there are some kinks, one being the new Xrandr config
interfaces in "control center -> system administration -> monitor & display"
and the system tray "TDErandrtray" applet.(FOOTNOTE{Expertise offered})
These look very promising and I was quite excited -- until I discovered that
they will not support my typical use cases(FOOTNOTE{Xrandr use cases}).
=== observations + problem description ===
1. The screens are always snapped to each other in the control center module.
If no edges overlap, the nearest corners snap together with no overlap,
leading to both screens being handled independently (dual head / Zaphod mode).
The panel remains unchanged and windows are maximized within their respective
screen.
==> OK.
But if edges overlap, these edges snap together with a few pixels overlap. The
consequence is, that both screens are treated as one united screen:
* the panel expands as its size is relative to full (virtual) screen width --
both ends of the panel might become invisible and the user is stuck (if not
having a 'xterm' and knowledge of 'xrandr' ...), if the screen not bearing the
panel is wider than the screen with panel ...
* maximizing windows will maximize them over the joint screen area of both
screens (while maybe a nice *option* for identical screens side-by-side or
stacked, typically quite detrimental on 2 screens with different resolutions!)
* it seems neither possible to separate screens nor to construct a cloning
configuration with mouse-dragging (documentation is not available, so I might
miss some hidden controls, but tried the usual suspects ...)
==> serious usability BUG (IMHO), as many useful screen configurations are
precluded and the normal user might end up with a messed up GUI without any
obvious way back ...
Even if I hand-craft the display profiles according my needs, upon loading
(both from the tray-applet and the control-center) they will be "corrected"
and rendered useless -- with the exception of hand-crafted clone configurations
(full and sub-set).
Workaround are manual 'xrandr' cmds or 'arandr', but this is doing TDE
disgrace, IMHO.
2. if the primary screen is below/right of the secondary screen, the secondary
screen gets negative coordinates in the stored profile (to my knowledge not
possible within X11). Upon loading this profile (both via control-center or
TDErandrtray) the screen upper/left-most screen becomes the primary screen.
--> serious BUG (as silently changing an accepted manual config IMHO is never
OK)
3. automatic loading of display profiles is a very clever + useful addition,
but at least in my typical use cases it would be advantageous if the profile
loaded reacts to the specific monitors to detect a location via monitor and
restore the optimal profile for this location.
=== proposals for bug fixes ===
* XRANDR control-center module
(control center -> system administration -> monitor & display)
** must never change the primary screen attribute on its own
** must calculate X11 coords correctly for secondary screens left or above the
primary screen and store them in profiles
** allows unconstrained placement of screens to enable clone and other useful
configurations (either as default behavior or a modified, see next point)
** different snapping behavior is provided via modifiers or keys, e.g.
SHFT+mouse-movement snaps with overlapping offsets, CTRL+mouse is either
unconstrained or snaps abut (non-overlapping)
=== proposals for improvements ===
* XRANDR control-center module
(control center -> system administration -> monitor & display)
** give some feedback on the actual coords and snapping (major usability
improvement)
** indicate primary screen (e.g. by color as in "arandr") (medium usability
improvement)
** option to add some "AutoStart" functionality to a profile, either by
providing an input field for entering a command or shell script or by giving an
AutoStart directory.
Assuming that specific profiles constitute either specific operation modes or
locations -- like "presentation" or "movie viewing" or "home" or "office" --
additional settings like switching power-scheme, configure proxies, etc. could
be done (major functional improvement (for power users))
** "arandr" uses "xrandr" command lines to store configuration and thus is able
to load hand-crafted display profiles which instantiate xrandr-configs beyond
'arand' config capabilities (e.g. complex panning constructions as described in
'xrandr(1)') -- IMHO very powerful and useful = major functional improvement)!
I see some possible approaches, the following might be the easiest:
*** displaying the constructed "xrandr" command can serve as feedback of
actual coords and snapping
*** the user might copy this command to an input field and modify it or add
further shell syntax (this would implement implicitely the profile
"AutoStart"). This manual initiation command overrides the automatic setting.
* automatic display profile loading of TDE XRANDR logic
** option to tie hotplug rules to specific monitors (either via the whole
EDID blob or by extracting manufacturer+serial#) -- this would allow to detect
a specific monitor and automagically restore e.g. home + office configs. (major
functional improvement)
* control-center -> desktop -> panel
** allow panel size to be given in pixels or percent (minor functional
improvement)
** configuration option to tie the panel to the primary screen (it switches if
the primary screen setting in the control center is changed) instead to a
specific screen number, which is only available if 2 non-overlapping screens
are configured ... (medium functional improvement)
Best regards,
ThoMaus
FOOTNOTE{Expertise offered}:
I can contribute in the following areas:
* programming skills (hundred thousands LOCs in production quality in various
programming languages, several thousand lines C (but not recently), -- but NO
KDE-related programming so far)
* bug hunting + killing
* documentation (especially if the points raised above stem from me not finding
functionality because of missing or misunderstood documentation ;-)
* performance analysis + optimizing
* security analysis + hardening
* testing on some desktop + notebook systems, single+dual-headed
So probably I can debug, sometimes modify code else hint where modification
might be needed, and final test existing functionality -- if guided
where to start. I probably can't introduce new GUI elements or functionality
for lack of KDE/TDE framework skills.
FOOTNOTE{Xrandr use cases}:
1. presentations via projector
1.1 the projection representing a completely logically separated screen
1.2 the projection screen being a subset-clone of the notebook screen, so I
can use it as a view-port, concentrating e.g. on the inner part of a specific
window
1.3 full cloning (typically on a monitor)
2. extended workspace
2.1 my home config with a large monitor (both in resolution and dimensions)
sitting above the notebook LCD
2.2 spontaneous extensions elsewhere with monitors of whatever resolution and
positioning
FOOTNOTE{Environment}:
OpenSuSE Tumbleweed on notebook single-headed + with varying dual-head configs
repositories:
* the recommended ones below
http://mirror.ppa.trinitydesktop.org/trinity/trinity/rpm/opensuse42.1/trini…
* the official OpenSuSE LEAP 42.1 repositories as second-tier, enabling trinity
to install older library versions -- so far without any collisions or failed
dependencies
FOOTNOTE{Usage}:
Despite working with computers for near on 40 years, and using X11 30+ years,
I managed to avoid RSI and other computer work induced problems so far very
well. I attribute this to using all ergonomic advantages my X11 desktops
provided since the early days of "olvwm", especially:
* focus follows mouse + auto-raise (delays fine-tuned to my personal reaction)
* B2 window style (automatically and dynamically reducing the width of window
title bars, such creating a tabbed appearance, very useful with auto-focus)
* consistent color scheme indicating active elements clearly (excellent
visibility and discernability -> easier for eyes and perceptive workload)
* panning (bound to a mouse key -- IMHO more ergonomic than scrolling,
essentially with the key pressed, mouse movements scroll ...)
* ...
You mileage might vary, but a few days with KDE5 or even Cinnamon produced the
first RSI inklings (and an impeded work-flow ...) and thus proved the
effectiveness of my personal ergonomic approach
