Conversative stance and traditions not withstanding, TDE might profit from some
visual improvements, IMHO. Nothing fundamental, just some low-hanging fruits.
Perhaps worth considering: The icon sets from "http://www.ravefinity.com/".
They claim to do only Open-Source work, so this should be feasible -- either
for direct inclusion, or as a theme source.
The "vibrantly simple" icon set works very well vor me, for example.
Over the years I've collected a lot of Xcursor icon sets for various purposes
and reasons:
* color variants of classic sets, better harmonizing with my colorscheme(s)
** Oxygen -- wide spectrum of colors, some slightly textured
** DMZ -- small spectrum of colors
** Komix -- wide color spectrum, somewhat flippant, but excellent in
combination with e.g. the "Kids" icon set, and quite usable
** Popsicle -- wide color spectrum, quite flippant, but excellent in
combination with e.g. the "Kids" icon set
* dynamic/pulsating cursors, easier to locate (helpful accessibility feature
for some people)
** e.g. "flame" rotating pseudo-3D object, but not to fidgety
** "GreenLight"-series, slowly pulsating glow, in the actual color of the
cursor (not necessarily green ;-)
** "Pulse-Glass"-series, slowly pulsating glow
** "bCircle" and "Tanga" -- very unusual, but interesting design, with very
strong visual cues maybe helpful in terms of accessibility
I attach a few (static) screenshots of the cursors -- if there is interest for
some of them, I can dig into the license issues ...
Some of the icon sets have problems, e.g.
* TDE-LoColor -- does this actually has still an use-case? your are not aiming
at car dashboard display, aren't you? it is very low-res, too.
* iKons -- IMHO nice, but quite incomplete?
* Tango -- only apps icons!?
You might ask "so what?".
Well, they might scare off some users, before they find the more pleasing
themes.
For discussion: What about having a kind of "tag mechanism" for artwork?
We could then tag artwork as "colorful", "dark theme", "light theme",
"monochromatic", "accesibility optimzed", "nostalgia", "kids", "modern",
"conversative", "flippant", etc. (multiple tags can be applied to an artwork!).
The user might set preferences in the control-center, which limit the artwork
actually presented for selection -- this would be innovative, improve the
harmony of the resulting setup, reduce the clutter in the selection lists and
would enable a harmonic co-existence of old and new visual styles, without
need to drop legacy artwork.
Finally, about the TDE/Trinity logos, which are still very KDE-ish:
If that is wanted -- OK.
If more visual distance would be welcomed, have a view at:
https://en.wikipedia.org/wiki/Triquetrahttps://en.wikipedia.org/wiki/Triskelion
Would some simple, color-ramped (to stay clear of well-established meanings)
Triquetra or Triskelion be of interest? I can draft those on positive
feedback.
Best regards,
ThoMaus
Hi
I filed a bug 2613 (https://bugs.trinitydesktop.org/show_bug.cgi?id=2613)
This is really blocking me ATM, hence the high prio I set. How does the fix
cycle looks like from time line perspective?
I'm considering downloading the source and patching myself.
thanks in advance
Hi all,
try the following: Open Konqueror and in Konqueror then open /opt/trinity/bin
or /bin and watch ~/.xsession-errors. You'll see a lot of warnings about the
missing embedded icons.
Because many binaries do not have an embedded icon, and the user can not
change it in any way, seem to me these reports unnecessary. I propose to
change these messages from kdWarning to kdDebug.
What do you think about it?
--
Slávek
The short version: some auxiliary build commands are trying to touch
directories the package manager doesn't want them to touch, resulting
in sandbox violation failures of the following format:
===
VERSION 1.0
FORMAT: F - Function called
FORMAT: S - Access Status
FORMAT: P - Path as passed to function
FORMAT: A - Absolute Path (not canonical)
FORMAT: R - Canonical Path
FORMAT: C - Command Line
F: mkdir
S: deny
P: /root/.trinity
A: /root/.trinity
R: /root/.trinity
C: /usr/trinity/14/bin/tdeconfig_compiler /var/tmp/portage/trinity-base/libkcal-14.0.0/work/tdepim/libkcal/htmlexportsettings.kcfg /var/tmp/portage/trinity-base/libkcal-14.0.0/work/tdepim/libkcal/htmlexportsettings.kcfgc
===
I've attacked a full build log for libtdepim which ends in a couple of failures of
the same type.
The long(er) version: Gentoo is a source distribution, so Gentoo packages are
more or less glorified build scripts. The package manager creates a per-package
sandbox in /var/tmp/portage/ which is used during build and install to keep failures
from spewing files all over the system.
For some reason, both tdeconfig_compiler and maketdewidgets are trying to do
a mkdir in (probably) ~/.trinity . They don't, as far as I can tell, put anything in
the resulting directories. Regardless, this breaks the sandbox and the build can't
complete.
This is in 14.0.0, but if there's been a commit that has changed any of this since
then, I can't find it.
It's possible that there's an additional CMake variable I need to set, in which
case feel free to hit me over the head with it. Otherwise, I need some way of
either redirecting those mkdir commands so that they land inside the sandbox,
or keeping them from being issued in the first place.
E. Liddell
I'm wondering, if something changed over years.
Which mirror I supposed to use for scripts which meant to be used to
build trinity on end-user machines from source (gentoo ebuilds)?
Now I use http://scm.trinitydesktop.org/scm/git/<package name>. Is it
correct, or there is something better?
I don't think it will make a high load any day, unless TDE will become
anyway popular, but you never know and it's better to ask...
Hi Fat-Zer, all,
I saw that in CMake processing of UIC files is a called command with redirect
of output. I think that's not the ideal way. Therefore, I propose to modify
it so that it will be used CMake method of processing outputs.
See proposed patch.
Cheers
--
Slávek
Unlike autotools this one doesn't installs headers.
Why may we need k3b headers in system? Is there something linking against it?
If so, I'll add install statements for them...
Also it doesn't installs k3bsetup2 by default because mostly every
modern linux have sane permissions to allow user to burn cd's whithout
such hacky crap.
+musepack is disabled due to k3b doesn't builds against recent
versions (tested with 465)
Hi
The context to my questions is the project I started about integrating
syncevolution in TDE.
I finished the basic plugin part and would like to write the platform part,
which seems to use dbus from within the plugin to provide password
read/write in the tdewallet.
1. Question
what would be the best place to start reading about using dbus from within
trinity? What is the preferred library to use for the future - it says
dbus-1-tqt is qt4 bindings backport?
I guess the dbus-tqt should serve my needs as I'm targeting the TDE wallet,
but still I would appreciate some advise.
http://git.trinitydesktop.org/cgit/dbus-tqt/http://git.trinitydesktop.org/cgit/dbus-1-tqt/http://git.trinitydesktop.org/cgit/kdbusnotification/
2. Question
For Calendar/Todo/Memo and Addressbook we hit some issue in syncevolution
that child sends via dbus the final sync report message to the parent but
the return message does not result in the defined callback and both parent
and child are stuck. Patrick Ohly from Syncevolution is looking into it but
I think asking here is worth in this case.
Are you aware of some side effects in DBus context when used in Trinity?
Are there some recommendations - examples, application code?
thanks in advance
