Hi all,
I noticed one problem regarding the cmake build of libraries with versioning
and tdelfeditor. Tdelfeditor is used not only on file with the appropriate
version, but also on base 'so' file without a version number. However, this
is a symlink to the file with the appropriate version. Use tdelfeditor causes
that instead of this symlink is created a regular file. Results are then two
full 'so' files, which is incorrect. For example, in tdebase (current stable
R14.0.3 Wheezy@amd64):
libkonq.so - size 809232 (package libkonq4-trinity-dev)
libkonq.so.4.2.0 - size 809240 (package libkonq4-trinity)
Solutions should be simple: in the common cmake module run tdelfeditor only on
libraries with the appropriate version and on base files only if the library
is not versioned. In some cases tdelfeditor is used, although library is not
shared == tdelfeditor is started without valid arguments. See proposed patch.
I believe that there is no reason against to push the patch. There will be
only one consequence - the patch causes rebuild almost all packages.
--
Slávek
Hi all,
I need some help again.
Which is the preferred function to use when creating TQString from
std::string and how can I make sure that I end up with Utf-8.
The thing is that input in std::string can be either UTF-8 or not UTF-8.
What is the standard way of doing this in TDE (TQt)?
I am really confused, because I was looking in some KDE3/TDE code and I see
both used.
My problem is that some older phones would most likely lack UTF and newer
would do only UTF. So how can I make sure to "speak the right language"
with them?
A hint would be appreciated.
regards
Hi
I'm trying to migrate our systems to a 'pure' TDE 14 environment on
Debian Jessie (previously used Wheezy with a TDE and KDE3 mix) and
having real problems porting an old KDE3.5 application (it's a modified
version of kconsole that's needed to run some of our legacy stuff).
I freely admit I don't understand the build process/kde-tde changes and
flailing around with configure/make isn't getting me anywhere apart from
deeper into a hole :-(
Is there anyone on this list that would be willing to port it for me?
If someone can do this, as a form of thank-you, I'll donate $500 to TDE.
PS - I do hope this request/offer won't be regarded as inappropriate and
I will be making my annual-ish donation to TDE regardless of the above.
--
Regards,
Russell
--------------------------------------------------------------------
| Russell Brown | MAIL: russell(a)lls.com PHONE: 01780 471800 |
| Lady Lodge Systems | WWW Work: http://www.lls.com |
| Peterborough, England | WWW Play: http://www.ruffle.me.uk |
--------------------------------------------------------------------
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...
