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
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;
^
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
I tried reinstall tdelibs14-trinity-dev and libtiff4-dev
just to find out that neither libtiff4 nor libtiff4-dev is installable.
How did I get it on my system?
is libtiff5 compatible?
thanks and regards
apt-get --reinstall install libtiff4-dev tdelibs14-trinity-dev
libtiff4:amd64
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reinstallation of libtiff4 is not possible, it cannot be downloaded.
Reinstallation of libtiff4-dev is not possible, it cannot be downloaded.
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 8 not
upgraded.
Need to get 0 B/6,151 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
(Reading database ... 373052 files and directories currently installed.)
Preparing to
unpack .../tdelibs14-trinity-dev_4%3a14.0.2-0debian8.0.0+0_amd64.deb ...
Unpacking tdelibs14-trinity-dev (4:14.0.2-0debian8.0.0+0) over
(4:14.0.2-0debian8.0.0+0) ...
Processing triggers for man-db (2.7.0.2-5) ...
Setting up tdelibs14-trinity-dev (4:14.0.2-0debian8.0.0+0) ...
Processing triggers for libc-bin (2.19-18+deb8u1) ...
Hi
In a KNotesIface_stub.h file I find following in the header
/****************************************************************************
**
** DCOP Stub Implementation created by dcopidl2cpp from KNotesIface.kidl
**
** WARNING! All changes made in this file will be lost!
**
*****************************************************************************/
Inside the file (this is from old KDE opensync code) there is a lot of
QTString and similar which needs to be prepended with T.
So I am wondering where do we find the TQT style of the file, or how one is
suppose to create it... and in general what is that all about.
Someone has experience with it? Light in the dark?
I do not have too much time to dig in all that stuff and I have the feeling
that I need some guidance in TDE or at least the part that I am interested
in.
Can someone provide a summary on this specific case?
AFAIK DCOP is the successor of the CORBA from KDE1/2 responsible for
IPC/RPC ... and I don't know what they use today in >KDE4.
https://en.wikipedia.org/wiki/DCOPhttps://techbase.kde.org/Development/Architecture/DCOP
I'm familiar with serialization from the axis corner. So in theory the
knowledge is there.
The context is my attempt to build a TDE backend for syncevolution. I have
some experience in completeing Akonadi plugin for opensync in KDE4.
Now I've successfully created 42lines of test code to read my addressbook,
so trying to achieve the same for knote, which as far as I know is one of
the challenges.
On Mon, Jan 11, 2016 at 23:20 (+0900), Michele Calgaro wrote:
>>>So why is no pkg-config for tdecore and tdeui ? or how can I use cmake from within automake project to get what I
>>>need?
>>I have installed 14.0.[23] from slavecs repository on devuan and "pkg-config tqt" works as expected. In detail your
>>"/opt/trinity/include" and "/opt/trinity/lib/pkgconfig" does not exist on my system, but "/usr/include/tqt3" does.
>To the original poster (since I did not receive the original email,
>not the second time request). If you are using debian or ubuntu,
>the best way to build is to use the info in the tde-packagin repo
>which contains all the required info. If not, a good way is to look
>at the build log files of the nightly builds, which contains all the
>build options used for such distros. If you are using a different
>distro, you could probably reuse most of the options, if not all of
>them ;-)
For web-challenged people like me, can you point us in the direction
of where we can see the build logs?
Thanks.
Jim
Hi,
I asked already once but there was no answer.
How can I get the cflags and libs for TDE applications?
I read and followed this manual:
https://wiki.trinitydesktop.org/KApplication_template
I updated the code sample to use the new (r14) headers.
I then found out I had to do following
export PKG_CONFIG_PATH=/opt/trinity/lib/pkgconfig
c++ `pkg-config tqt --cflags` `pkg-config tqt --libs` test.cc -o test
but it was unsufficient. I had to change to following to be able to compile
c++ `pkg-config tqt --cflags` -I/opt/trinity/include \
`pkg-config tqt --libs` -L/opt/trinity/lib -ltdecore -ltdeui \
test.cc -o test
So why is no pkg-config for tdecore and tdeui ?
or how can I use cmake from within automake project to get what I need?
thanks
Hi all,
I am currently running Plasma 5 (KDE 5) on my desktop computer, and I find that Plasma 5 is capable of booting, from login to desktop, faster than TDE on the same machine. This computer is an humble Core 2 duo with 2gb of ram, probably from 2008 or so.
While this is great for KDE, it is not that great for TDE, because KDE is built on much heavier toolkit and frameworks than TDE. And TDE (with its KDE 3 past) was built to run well on P2-P3 computers. The thing is that even with much faster computers, it should have near instant boot time.
So, I don't know if there could be ways to re-organize TDE startup sequence, or maybe to prefetch so things in TDM. Maybe starting TDE modules in parallel could help?
May 2016 be a great year for you all!
-Alexandre
