tde-devels

devels@trinitydesktop.org

11 participants
3800 discussions

kicker trips over its own feet!
by Thomas Maus 22 Feb '16

22 Feb '16

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

2 1

Git
by Lisi Reisz 20 Feb '16

20 Feb '16

Do you all use a git community? Lisi

1 0

[trinity-devel] r14 in rebuilding state?
by Felix Miata 20 Feb '16

20 Feb '16

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/

3 5

PulseAudio support for KNotify
by Serghei Amelian 19 Feb '16

19 Feb '16

Hello, I implemented minimal PulseAudio support for KNotify (at this moment only for ogg files, wav decoder is not implemented yet). So, we can have event sounds even with aRts disabled :) https://github.com/serghei/kde3-kdelibs/commit/66b483400567d72968e09a1b1f8e… -- Serghei

1 0

Static code analysis of TDE ...
by Dr. Nikolaus Klepp 18 Feb '16

18 Feb '16

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.

2 1

Multi-Head configuration (Xrandr) -- potential bugs and improvements
by Thomas Maus 16 Feb '16

16 Feb '16

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

2 1

New machine for TDE!
by Alexandre 08 Feb '16

08 Feb '16

Look at this: http://www.phoronix.com/scan.php?page=article&item=talos-workstation&num=1 For $3100 USD You Can Have A Fast, Fully-Free-Software Workstation - Phoronix<http://www.phoronix.com/scan.php?page=article&item=talos-workstation&num=1> www.phoronix.com Phoronix is the leading technology website for Linux hardware reviews, open-source news, Linux benchmarks, open-source benchmarks, and computer hardware tests.

1 0

iteration over ABC ressources
by deloptes 31 Jan '16

31 Jan '16

Hi all, could you please help a bit. I try to iterate over resources in address book, but fail so far. using namespace TDEABC; AddressBook* kab = TDEABC::StdAddressBook::self(false); TDEABC::StdAddressBook::setAutomaticSave(false); TQPtrList<Resource> lit = kab->resources(); TQPtrListIterator<Resource> it( lit ); Resource *res; while ( (res = it.current()) != 0 ) { ++it; debug() << "SUB RES ID :" << res->identifier() << "\n"; } but I get std-test.cc: In function ‘int main(int, char**)’: std-test.cc:72:38: error: invalid use of incomplete type ‘class TDEABC::Resource’ debug() << "SUB RES ID :" << res->identifier() << "\n"; ^ In file included from /opt/trinity/include/tdeabc/addressbook.h:29:0, from /opt/trinity/include/tdeabc/stdaddressbook.h:24, from std-test.cc:7: /opt/trinity/include/tdeabc/addressee.h:45:7: error: forward declaration of ‘class TDEABC::Resource’ class Resource; ^ In file included from /usr/include/tqt3/ntqstrlist.h:46:0, from /usr/include/tqt3/ntqstringlist.h:47, from /usr/include/tqt3/ntqcolor.h:46, from /usr/include/tqt3/ntqpalette.h:46, from /usr/include/tqt3/ntqwidget.h:48, from /usr/include/tqt3/ntqdesktopwidget.h:43, from /usr/include/tqt3/ntqapplication.h:45, from /usr/include/tqt/tqapplication.h:33, from /opt/trinity/include/tdeapplication.h:40, from std-test.cc:3: /usr/include/tqt3/ntqptrlist.h: In instantiation of ‘void TQPtrList<type>::deleteItem(TQPtrCollection::Item) [with type = TDEABC::Resource; TQPtrCollection::Item = void*]’: std-test.cc:92:1: required from here /usr/include/tqt3/ntqptrlist.h:153:21: warning: possible problem detected in invocation of delete operator: [-Wdelete-incomplete] if ( del_item ) delete (type *)d; ^

1 1

pytdeextensions FTBFS on debian stretch due to lack of 'python-support' package
by Michael Howard 30 Jan '16

30 Jan '16

As per the subject, is there an official patch? -- Mike Howard

3 9

TDE/KDE3 API docs
by deloptes 20 Jan '16

20 Jan '16

Hi, I'm trying to find a compiled version of the docs but when I try this here http://api.kde.org/3.5-api/ I find out that it is incomplete. Example: I try kdepim-apidocs/kaddressbook Not Found The requested URL /3.5-api/kdepim-apidocs/kaddressbook/html/classes.html was not found on this server. Apache Server at api.kde.org Port 80 Otherwise I should compile the docs from the source - correct? Is there a procedure as I already pulled the pim sources from git? Thanks in advance

2 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels