Several bug reports focus on TDE not displaying device icons on the desktop or the standard popup dialog when a new device is detected. Refer to bug reports 372, 385, 634 for starters.
These are serious usability bugs.
Today I started investigating. I discovered that HAL support is not enabled in the default cmake options. I don't know why that is the default.
I enabled HAL support with -DWITH-HAL=ON. The build failed for failing to find some header files. I submitted a small patch in bug report 755.
I don't think my patch is the best approach. Instead I think the following environment variables need to be defined:
$DBUS_TQT_LIBRARY_DIRS
$HAL_INCLUDE_DIRS
$HAL_LIBRARIES
Although referenced, I don't think these variables are defined anywhere in the cmake files. How do I patch the cmake files to know those locations?
I could hard-code those locations in my kdebase build script or build environment, but what is the proper approach?
Darrell
I just created bug report 750 (http://bugs.pearsoncomputing.net/post_bug.cgi):
Akregator default feeds all point to KDE sites
This is a somewhat serious public relations bug.
Does the Trinity web site currently offer any kind of RSS feed? Even if the feeds are stale old news, anything would be better than the default feeds to all KDE sites. :)
Darrell
I have a testing account I use often. That account gets used in my real machines and virtual machines. For many years I have used a left-handed mouse (mouse buttons reversed). Because the virtual machine passes the mouse buttons transparently, I wrote a snippet for that user's .bashrc file to test the mouse button configuration and swap the mouse buttons in kcminputrc as necessary. That way I can use a left-handed mouse regardless of which environment the account gets used.
To test my mouse buttons I run the following in that user's .bashrc:
kreadconfig --file $PROFILE_HOME/share/config/kcminputrc --group Mouse --key MouseButtonMapping
Simple enough.
Today I booted my PII machine that has a partition for Trinity 3.5.13. I login from the command line, which means X is not yet running. When I logged in with that testing account I received the following message:
NVIDIA OpenGL Driver requires CPUs with SSE to run.
The current CPU does not support SSE.
Superficially, I saw this message because originally I had cloned a testing partition from another hard drive and that partition had the proprietary Nvidia drivers installed. The PII machine does not support those drivers. Hence the messages.
The real mystery is what is kreadconfig and kwriteconfig doing that indirectly causes those messages? I suspect a linking problem, which ldconfig resolved after I removed the Nvidia packages. Nonetheless, why are those two commands querying X libraries when X is not running? Is this a feature or a bug? :)
Darrell
I rebuilt kdebase with HAL support and now I am again seeing device icons on the desktop.
However, the patch I submitted that reenables the Keep password check box in the kdesu dialog box no longer works despite running that patch during the build. That is, the checkbox no longer appears.
I don't see why enabling HAL would have such an effect. Any ideas?
Darrell
Over the past few months I have read several articles like this:
http://www.h-online.com/open/features/LXDE-and-Xfce-the-other-desktops-1392…
I'm not sure Xfce is a cholesterol free desktop or that LXDE is ready for prime time with non geek users. Yet I am sure that Trinity is receiving little comparative press coverage.
I'm not calling for a marketing campaign, but I would like to request all team members focus on making R14 the best release yet. To me that means three goals:
* Eliminating many, many paper cut bugs.
* All packages build with minimal fuss.
* Provide an improved web site.
The paper cut project never got off the ground. Paper cut bugs discourage non geek users. They don't care or want to understand the nuances of programming or why something fails to function as intended. Paper cut bugs are a public relations nightmare. People vote with their feet. :(
Struggling to build packages is a good way to ensure little exposure because the desktop then is not available to users. A significant portion of the discussion in this list is build issues. Simple things like autotools looking for Qt4 rather than Qt3 are frustrating to non geeks. Remember that until Trinity is provided as a regular prebuilt package option in most distros, end-users are left to build the packages on their own. That means the wiki needs attention too and should be revised for non geeks.
We have been discussing web site changes and a possible RSS feed. Those plans likely will fall into place shortly. :)
Despite what reviewers declare, I don't see Trinity "competing" with KDE4 --- or GNOME. I see the "competition" as Xfce and LXDE. I use the word "competition" in a friendly, comparative way. Long-term we should be asking ourselves questions such as whether there is anything those desktops do better than Trinity? Is there anything those desktops do that Trinity does not? Trinity does not have to be at the top of all comparison lists, but should look favorable all around.
There is one thing those two desktop environments do better than Trinity: start and exit faster. I don't know whether that observation merits an enhancement request. While I agree too much discussion is wasted on the topics, I'd like to think both can be improved in Trinity.
In the article I linked the writer mentions that "One developer in China has ported LXDE to a device with 128 RAM, 400 MHZ CPU." How does Trinity perform with such hardware? I have PI and PII machines sitting here with 256 MB of RAM. I have run 3.5.10 on those machines for several years and 3.5.10 is, well, sluggish. I suspect my problem is the video cards in my machines and I haven't fully tested yet. Yet I am guessing Trinity will fare only a tad better than 3.5.10.
The author also quoted somebody as saying "if Windows 98 and XP work quite well on old machines, why does my Linux desktop need a 1.0 GHz CPU + 1GB RAM?" I agree. I think Trinity can be a significant player in keeping old hardware running. If LXDE is going to be touted as ideal for that kind of hardware, then is that a topic for discussion for Trinity too?
One thing Trinity does well is conform to the traditional desktop model that most users are accustomed. That means users familiar with Windows. I never have had a problem with Linux desktops continuing that model and to me, the original 1969 desktop model derived in the PARC labs and copied by Microsoft and Apple developers still works wonderfully well today.
Not to mention that Trinity is far more configurable than Xfce and LXDE.
There are several distros focusing on being lightweight or fast. The simple message of that focus is many users do not like bloat but they also do not want to deal with the "crippled" world of window managers only. In the end, will distro maintainers offer Trinity as an option because Trinity satisfies such goals? If Trinity is easy to build, will Trinity be offered as an alternate desktop in major distros too?
Opportunity is waiting. Let's strive to make R14 a desktop reviewers want to review and praise. :)
Darrell
Out of curiosity? Isn't Qt registered trademark of nokia? I found this
on qt4/nokia page: "Nokia, Qt and their respective logos are
trademarks of Nokia Corporation in Finland and/or other countries
worldwide.".
Hello,
I've seen many calls for a stand alone Konqueror. I have seen people who do
not want to use KDE3 anymore, but desperately miss their beloved Konqueror
asking for it. What do you all think about creating just a Konqueror
tarball for the releases, and push it out to package maintainers?
Frankly Konqueror is the best manager around, I think we might as well get
people hooked on it :)
Calvin Morrison
I am starting to do the development/testing needed to add Trinity to
Linux From Scratch, replacing KDE3. Right now I have a couple of issues
I'd like to get clarified.
First, I notice in the dependencies directory, there are several packages:
dependencies/arts
dependencies/avahi-tqt
dependencies/dbus-1-tqt
dependencies/dbus-tqt
dependencies/tqtinterface
I have no problems with arts or tqtinterface but I don't see the other
three mentioned anywhere. Are these packages required for Trinity? If
so, at what point are they required? We do have instructions already in
LFS for D-Bus and avahi libraries.
Second, I have had some problems building kdelibs. There were no
problems following the instructions for qt3, tqtinterface, or arts, but
there were many places in building kdelibs where I had to edit a
link.txt file and add -lX11. I am fairly new at using cmake so I'd like
to know if there is a way to add this automatically.
My installation of xorg is a little non-standard because the files are
in /opt/xorg, but there are appropriate symlinks at /usr/X11R6 and
/usr/include/X11. I didn't seem to have a problem with include files.
It would also be useful to know how to set -L/opt/xorg/lib, but that is
not critical because I can do essentially the same thing by export(ing)
LIBRARY_PATH.
I'll note that LFS has a policy of not using development versions of
packages, so for now we need to be able to work with trinity-3.5.13.
Thanks for your help.
-- Bruce Dubbs
