I created an etherpad containing TDE application descriptions. I extracted much of the information from Helpbook abstracts and then massaged the information accordingly. The extraction process was not fluid or easy to read, even after cleanup. I suspect a few apps are missing from the list.
The descriptions are more or less grouped the same as the T-Menu.
Everybody please feel free to edit the list as needed.
Tim, Calvin:
In my web site improvement suggestions I recommended an applications description page. Ideally, we should have full web pages for certain apps, but this list will provide a nice start.
Darrell
2011/12/27 Darrell Anderson humanreadable@yahoo.com:
I created an etherpad containing TDE application descriptions. I extracted much of the information from Helpbook abstracts and then massaged the information accordingly. The extraction process was not fluid or easy to read, even after cleanup. I suspect a few apps are missing from the list.
The descriptions are more or less grouped the same as the T-Menu.
Everybody please feel free to edit the list as needed.
Tim, Calvin:
In my web site improvement suggestions I recommended an applications description page. Ideally, we should have full web pages for certain apps, but this list will provide a nice start.
I was thinking about page for each app, containing description, screenshot, dependencies and build instructions. It will be much work, but I think it will ease for people who search for apps with certain functionalities and for those who are building them manually.
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
I created an etherpad containing TDE application
descriptions. I extracted much of the information from Helpbook abstracts and then massaged the information accordingly. The extraction process was not fluid or easy to read, even after cleanup. I suspect a few apps are missing from the list.
The descriptions are more or less grouped the same as
the T-Menu.
Everybody please feel free to edit the list as
needed.
Tim, Calvin:
In my web site improvement suggestions I recommended
an applications description page. Ideally, we should have full web pages for certain apps, but this list will provide a nice start.
I was thinking about page for each app, containing description, screenshot, dependencies and build instructions. It will be much work, but I think it will ease for people who search for apps with certain functionalities and for those who are building them manually.
Yes, that is where we go eventually. :)
The etherpad is an outline. Something that can be used in the revamped web site to provide a basic list. The descriptions will grow with screen grabs. If everybody picked a few apps, snapped a couple of screen shots, added more detail to the descriptions, then we could have a nice application description section in short order.
Dependencies and build instructions should go in the wiki rather than main web site. Here is a suggested outline for those wiki pages:
Feel free to edit as necessary everybody. :)
Trinity Package Build Requirements
===================================== Common Expected System Dependencies ===================================== cups pcre libxml2 libxslt dbus-python libpng poppler rebuilt with Qt3 support ruby wv2
===================================== Optional Third Party Dependencies ===================================== openexr ilmbase GraphicsMagick jre (Java Runtime Engine) jdk (Java Development Kit) xmms ortp boost facile ocaml graphviz speex gnokii opensync libsndfile libdvdcss libdvdnav lame libdv libdvdread a52dec faac faad2 xvidcore liboil schroedinger openjpeg yasm x264 speex ffmpeg libquicktime mjpegtools libmpeg2 transcode vcdimager emovix
===================================== Trinity Foundation Packages ===================================== tqt3 tqtinterface arts libart-lgpl avahi-tqt dbus-1-tqt dbus-tqt python-tqt sip4-tqt tqca tqca-tls tqscintilla
===================================== Trinity Core Packages ===================================== tdelibs tdebase
===================================== Trinity Main Packages ===================================== tdebindings tdeaccessibility tdeutils tdemultimedia tdenetwork tdeadmin tdeartwork tdegames tdetoys tdeedu tdegraphics tdevelop tdeaddons tdewebdev tdepim tdesdk tdei
===================================== Trinity Libraries ===================================== kipi-plugins libkdcraw libkexiv2 libkipi libksquirrel libtqt-perl mlt mlt++ pytdeextensions python-trinity libical libcaldav libcarddav
===================================== Additional Trinity Applications =====================================
abakus adept amarok basket bibletime compizconfig-backend-kconfig desktop-effects-tde digikam dolphin filelight filelight-l10n fusion-icon gtk-qt-engine gwenview k3b k9copy kaffeine kaffeine-mozilla katapult kbarcode kbfx kbookreader kchmviewer kcpuload kdbusnotification kdiff3 kdirstat kdmtheme kdpkg keep kerry kgtk-qt3 kile kima kio-apt kio-locate kio-umountwrapper kiosktool kmplayer kmyfirewall kmymoney knemo knetload knetstats knetworkmanager8 knetworkmanager9 knights knowit knutclient koffice konversation kopete-otr kpicosim kpilot kpowersave kradio krename krusader ksplash-engine-moodin ksquirrel kstreamripper ksystemlog ktechlab ktorrent kuickshow kvirc kvkbd kvpnc piklab potracegui rosegarden smartcardauth smb4k soundkonverter tde-guidance tde-style-lipstik tde-style-qtcurve tde-systemsettings tdesudo tdesvn tellico twin-style-crystal wlassistant yakuake
Darrell
Darrell Anderson wrote:
Trinity Package Build Requirements
===================================== Common Expected System Dependencies ===================================== cups pcre libxml2 libxslt dbus-python libpng poppler rebuilt with Qt3 support ruby wv2
This is really tricky if you want to be complete. What about xorg, gcc, binutils, and make? What assumptions are you making?
Also gtk+1, ghostview, doxygen...
It's really quite non-trivial.
-- Bruce
Trinity Package Build Requirements
===================================== Common Expected System Dependencies ===================================== cups pcre libxml2 libxslt dbus-python libpng poppler rebuilt with Qt3 support ruby wv2
This is really tricky if you want to be complete. What about xorg, gcc, binutils, and make? What assumptions are you making?
Also gtk+1, ghostview, doxygen...
It's really quite non-trivial.
With reference to Trinity. :) For example, building kprinter is useless unless cups is installed. Many distro maintainers no longer build poppler with Qt3 support. Amarok breaks unless ruby is installed while building. Etc. No need to get carried away with this list. :)
Darrell
Darrell Anderson wrote:
Trinity Package Build Requirements
===================================== Common Expected System Dependencies ===================================== cups pcre libxml2 libxslt dbus-python libpng poppler rebuilt with Qt3 support ruby wv2
This is really tricky if you want to be complete. What about xorg, gcc, binutils, and make? What assumptions are you making?
Also gtk+1, ghostview, doxygen...
It's really quite non-trivial.
With reference to Trinity. :) For example, building kprinter is useless unless cups is installed. Many distro maintainers no longer build poppler with Qt3 support. Amarok breaks unless ruby is installed while building. Etc. No need to get carried away with this list. :)
That's true, but if you are going to publish build instructions for every package, you need to specify your base system. I don't follow what other distros are doing, but ubuntu, for instance, doesn't distribute gtk1 apps like ghostview and xmms by default any more.
It's almost a Catch-22. You need a lot of prerequisites to build Trinity, so you use a distro like Debian or Ubuntu to get them. If you do that, why build from source and not just get the binaries for Trinity the same way?
It also gets really complicated. Why is ghostview needed? The answer of course is kghostview, but you don't need to build that. You either need to say that app X needs prerequisite Y or say that Trinity needs prerequisites Y1, Y2, ... Yn. The second way will not help a lot of users.
-- Bruce
That's true, but if you are going to publish build instructions for every package, you need to specify your base system. I don't follow what other distros are doing, but ubuntu, for instance, doesn't distribute gtk1 apps like ghostview and xmms by default any more.
It's almost a Catch-22. You need a lot of prerequisites to build Trinity, so you use a distro like Debian or Ubuntu to get them. If you do that, why build from source and not just get the binaries for Trinity the same way?
It also gets really complicated. Why is ghostview needed? The answer of course is kghostview, but you don't need to build that. You either need to say that app X needs prerequisite Y or say that Trinity needs prerequisites Y1, Y2, ... Yn. The second way will not help a lot of users.
Sure, when people build from scratch things get complicated. :)
I have good notes about what external packages are required to provide TDE full functionality. The original KDE3 packages provided many hooks to other packages. The KDE3 packages still built when those external packages were not installed, but when those packages were installed and the respective configure options were set, then the KDE3 packages took advantage of those hooks. Those hooks still exist in TDE.
That is the point of my original statement. Using the word dependency was inaccurate. Expanded functionality is a better expression.
Your point about kghostview is interesting. Will kdegraphics build when ghostview is not installed? I presume yes and that the configure messages will say as much. The Kghostview package would not get built but I presume Kpdf would.
That pretty much is how I accumulated my notes about external packages. Those packages are not dependencies, but external icing on the cake. I don't pretend to know what additional functionality each of those hooks provide, I only know that when those external packages are not installed I see related messages during the configure process (now cmake with several packages).
I mentioned in a previous response I could provide those notes if requested. I suppose I should just post them. :)
Darrell
On Tuesday 27 December 2011 11:49:44 am Darrell Anderson wrote:
[putolin]
That pretty much is how I accumulated my notes about external packages. Those packages are not dependencies, but external icing on the cake. I don't pretend to know what additional functionality each of those hooks provide, I only know that when those external packages are not installed I see related messages during the configure process (now cmake with several packages).
I mentioned in a previous response I could provide those notes if requested. I suppose I should just post them. :)
I would sure help me for one!
I mentioned in a previous response I could provide
those notes if requested. I suppose I should just post them. :)
I would sure help me for one!
When installed these packages provide additional functionality in TDE:
==================================== I don't know which TDE packages look for the following. I know that they were expected to be installed back in the KDE3 days. ==================================== pcre (Perl-compatible regular expression library) libxml2 (many TDE packages?) libxslt (twebdev? others?) dbus-python (kdebindings? others?) libpng (many TDE packages?) poppler (tdegraphics, others?)
==================================== tdelibs, tdebase ==================================== cups (kprint) avahi (dns-sd, dns service discovery/zeroconf) required by avahi libdaemon lua hspell (Hebrew spell checking)
==================================== Several Trinity packages ==================================== krb5 (kerberos authentication) (Any package that uses a login likely takes advantage of this) openexr (EXR image format support) required by openexr ilmbase
==================================== tdebase, koffice-chalk ==================================== GraphicsMagick (various image filters)
==================================== tdebindings ==================================== sip, PyQt3, pyKDE3 (Python support) jre (Java Runtime Engine) jdk (Java Development Kit) Ruby
==================================== tdeutils, tdeaddons, tnetwork ==================================== xmms (I have no idea what the connection might be :))
==================================== tdenetwork, kdepim (kopete jabber jingle) ==================================== ortp
==================================== tdeedu ==================================== boost kalzium (tdeedu) facile required by facile ocaml
==================================== tdevelop ==================================== graphviz
==================================== tdenetwork ==================================== ffmpeg required by ffmpeg speex
==================================== tdepim ==================================== gnokii opensync libical libcarddav libcaldav
==================================== amarok ==================================== ruby libmp4v2 libmusicbrainz daap libnjb libmtp libgpod libkarma amazon xmms gstreamer
==================================== k3b ==================================== libsndfile libdvdcss libdvdnav required by k3b and ffmpeg lame libdv libdvdread a52dec required by ffmpeg faac faad2 xvidcore liboil schroedinger (requires liboil) openjpeg yasm x264 (requires yasm) speex required by transcode ffmpeg libquicktime mjpegtools libmpeg2 transcode vcdimager emovix musepack-tools libmusicbrainz
==================================== koffice ==================================== wv2 GraphicsMagick (chalk)
==================================== kaffeine ==================================== gst-plugins-base gstreamer xine-lib
==================================== k9copy ==================================== ffmpeg dvdauthor vamps MPlayer k3b
==================================== digikam ==================================== lcms dcraw libgphoto2 jasper exiv2 libkdcraw libkexiv2 libkipi kipi-plugins sqlite
==================================== gwenview ==================================== exiv2 libkexiv2 libkipi kipi-plugins
Reminder: most of these packages are not dependencies or build requirements. These packages provide additional functionality. This list is by no means complete or exhaustive.
Yes, this type of information should be in the wiki. When we get around to that as a team, we should list dependencies for each package, but we should add these other packages as providing additional functionality. I think the easiest way to create a complete lists for both is to parse the configure options. :)
Darrell
When installed these packages provide additional functionality in TDE:
Looking at those packages that provide additional functionality raises an interesting question: before building TDE, could those related packages be removed to build a TDE Light? That is, create a special build environment to build TDE Light?
I tinker with old hardware. TDE is --- well --- sluggish on a PI and PII machine. Without those many hooks would TDE be snappier?
Those older machines lack the hardware muscle to support modern expectations of video and graphics support. Therefore when building for older hardware, why build TDE with that support and those hooks? If TDE is built without that support is there anything to gain on older hardware? Just curious --- I don't know the answer.
Those older machines were expected to be office machines, not home theater PCs. Why can't they still fulfill that role?
I would like to see a discussion about what a TDE Light might entail or provide. Is a TDE Light feasible? Doable? What are the technical challenges?
If I had appropriate information I would create a special build environment and give TDE Light a test.
Should anybody say that building TDE for such hardware is unreasonable, I counter with a simple question. Why is NT4, a 32-bit operating system, so snappy on such hardware? To follow: Why can't a Linux based OS with TDE be just as snappy? Or, to put a *mischievous* twist to the question: what did the Microsoft devs do right that the free/libre software devs did wrong? :)
I have NT4 installed on both my PI and PII machines (dual boot). NT4 just hums. Apps open quickly. There is no lag. Granted, I don't surf the web with those machines or play videos, but everything else is a pleasure to use.
Oh, I have WFWG 3.11 with the Norton Desktop still installed on the first 512 MB partition of the PI hard drive. A 16-bit OS on 32-bit hardware. Oh. My. Gosh. Fast. :) ;)
Is there any hope to the idea of a TDE Light?
Darrell
Darrell Anderson wrote:
When installed these packages provide additional functionality in TDE:
Looking at those packages that provide additional functionality raises an interesting question: before building TDE, could those related packages be removed to build a TDE Light? That is, create a special build environment to build TDE Light?
I tinker with old hardware. TDE is --- well --- sluggish on a PI and PII machine. Without those many hooks would TDE be snappier?
How about kdelibs+kdebase without arts. That gives konsole and konqueror. What else is needed? koffice? kpdf? kmail? A couple of apps from kdepim?
Not everything needs to be Trinity. Other apps such as FF and OO are useful in an office environment.
-- Bruce
How about kdelibs+kdebase without arts. That gives konsole and konqueror. What else is needed? koffice? kpdf? kmail? A couple of apps from kdepim?
Not everything needs to be Trinity. Other apps such as FF and OO are useful in an office environment.
Let me define TDE Light: An almost fully featured TDE that runs *snappily* on older hardware. Key word is snappily. :)
The office machine of the 1990s used PDFs, email, and basic sound support. Only nominal web surfing. Konqueror would suffice for limited web surfing and is far more responsive in a native TDE than Firefox. Although, as we have discussed here in this list, Konqy needs serious attention to again become an enjoyable web browser.
Firefox is impossible on a PI/PII class machine. Been there done that. Firefox takes about 30 seconds just to start. On these old machines, hard drives are bottlenecked by the motherboards, which means nothing faster than ATA-2. Yet even after loading Firefox, the video cards of those days can't handle web 2.0 of today. I have experimented with Firefox on these machines. Not installing the flash plugin helps, as does disabling Java, JavaScript, iframes, etc. Disabling images helps, but many web pages are not well designed and won't format properly without the images. Basically, Firefox performance is embarrassing compared to IE5/6 on NT4 or W2K on those same machines.
OpenOffice/LibreOffice are not good options for old hardware. Been there done that. KOffice will suffice much better, especially in a native TDE. (If I can ever get all the bugs out of KOffice to build properly.) Recently in this list we discussed keeping KOffice as a part of TDE but marketing KOffice as a light weight office suite. People using such hardware are not expecting splendid melodrama. They just want to use old hardware for basics.
Many of these machines have only 128 MB of RAM. Yes, we would recommend updating to 256 MB but that is the limit of what we can recommend because many of the PI motherboards only support 256 MB.
The key here is to run snappily, not what packages get stripped from TDE. I envision almost all TDE packages being available in TDE Light. My focus is reasonable performance speed.
As far as performance speed, on a PI/PII, NT4 runs circles around any Linux based desktop environment, even Xfce and LXDE. I'll side here with Calvin that LXDE is not a true integrated desktop environment but is more a semi-glued hodge-podge of apps. Nonetheless, TDE, Xfce, and LXDE don't compare to NT4 with respect to response speed.
I noticed through the years with KDE3 on these old machines is startup times are slow but once the libraries are in memory, response of KDE3 apps improves noticeably. For example, even the first use of the K-Menu is slow --- there is a noticeable momentary delay. After that first use the menu response is fast. Perhaps a key with TDE Light is to somehow preload or cache certain libraries and files into RAM right away.
My vision is that most of the apps that are packaged with TDE would be packaged with TDE Light. Just all non-essential hooks and dependencies are stripped before building TDE Light so the packages do not build those hooks. My focus for TDE Light is speed.
Darrell
Darrell Anderson wrote:
How about kdelibs+kdebase without arts. That gives konsole and konqueror. What else is needed? koffice? kpdf? kmail? A couple of apps from kdepim?
Not everything needs to be Trinity. Other apps such as FF and OO are useful in an office environment.
Let me define TDE Light: An almost fully featured TDE that runs *snappily* on older hardware. Key word is snappily. :)
The office machine of the 1990s used PDFs, email, and basic sound support. Only nominal web surfing. Konqueror would suffice for limited web surfing and is far more responsive in a native TDE than Firefox. Although, as we have discussed here in this list, Konqy needs serious attention to again become an enjoyable web browser.
I understand where you are coming from, but wonder how many need such a system. I just checked and Wal-Mart has brand new systems with 1 TB disk and 3GB ram for $300. For a used system, I see a 1.7GHz P4 w/512 RAM for $25.
One problem with the PIIs is that they are being scrapped as junk. You can't find a lot of them any more.
The other side is how many users will be satisfied with systems without Java, JavaScript, iframes, Flash, etc?
Personally, I don't have Flash on my regular browser because it is used 90% of the time for ads that I don't want to see. I have another browser with it for those few occasions that it's needed.
I like the command line (konsole), but many don't. I've been thinking of going back to Lynx/Links because of all the junk put out by a lot of web sites.
OTOH, Trinity is quite snappy on a Core2 system or even a 3GHz P4 (2005 vintage).
-- Bruce
I understand where you are coming from, but wonder how many need such a system. I just checked and Wal-Mart has brand new systems with 1 TB disk and 3GB ram for $300. For a used system, I see a 1.7GHz P4 w/512 RAM for $25.
One problem with the PIIs is that they are being scrapped as junk. You can't find a lot of them any more.
The other side is how many users will be satisfied with systems without Java, JavaScript, iframes, Flash, etc?
Personally, I don't have Flash on my regular browser because it is used 90% of the time for ads that I don't want to see. I have another browser with it for those few occasions that it's needed.
I like the command line (konsole), but many don't. I've been thinking of going back to Lynx/Links because of all the junk put out by a lot of web sites.
OTOH, Trinity is quite snappy on a Core2 system or even a 3GHz P4 (2005 vintage).
Perhaps are seeing things from a BLFS "geek" perspective. :)
I live in a rural area. Folks in such areas don't have Wal-Marts close by. Closest one to me is an hour away. As a caveat, none of my three immediate rural neighbors own a computer. Which means the average computers owned in this area is still greater than one per household because I have five. :)
There are many people in less developed regions of the world who have no easy access to computers and $300 is a year's salary.
For the sake of discussion let's raise the bar to a PIII. Yet doing so evades the point that NT4, a 32-bit OS from the 1990s, run circles around anything Linux based on the same hardware. Is there a way to tweak better performance out of TDE? I don't know.
How many users would be satisfied without Java, JavaScript, iframes, Flash, etc? Probably many. :) I use NoScript in Firefox to disable all of that. Konqueror has a way to create white lists for some of that, but I never found the interface easy to use.
A better question is how many people using older computers would be satisfied without that crap? Probably all because they aren't using that machine as a web surfing or video appliance. They would be using the machine as a basic office (or possibly school) system with nominal web browsing.
Darrell
Darrell Anderson wrote:
I have good notes about what external packages are required to provide TDE full functionality. The original KDE3 packages provided many hooks to other packages. The KDE3 packages still built when those external packages were not installed, but when those packages were installed and the respective configure options were set, then the KDE3 packages took advantage of those hooks. Those hooks still exist in TDE.
That is the point of my original statement. Using the word dependency was inaccurate. Expanded functionality is a better expression.
Your point about kghostview is interesting. Will kdegraphics build when ghostview is not installed? I presume yes and that the configure messages will say as much. The Kghostview package would not get built but I presume Kpdf would.
I had to pass -DBUILD_KGHOSTVIEW=OFF to cmake to get kdegraphics to build. In fact, here are my notes:
cmake -DCMAKE_INSTALL_PREFIX=$TRINITY_PREFIX \ -DCMAKE_VERBOSE_MAKEFILE=ON \ -DQT_VERSION=3 \ -DCMAKE_CXX_FLAGS="-fpermissive" \ -DWITH_TIFF=ON \ -DWITH_PAM=ON \ -DBUILD_ALL=ON \ -DBUILD_KAMERA=OFF \ -DBUILD_KSVG=OFF \ -DBUILD_KUICKSHOW=OFF \ -DBUILD_LIBKSCAN=OFF \ -DBUILD_KOOKA=OFF \ -DBUILD_KGHOSTVIEW=OFF \ -DBUILD_KFILE_PLUGINS=OFF \ $KDEGRAPHICS &&
#-DWITH_LIBPAPER=ON #-DWITH_T1LIB=ON #-DWITH_OPENEXR=ON
#-DBUILD_KAMERA requires gphoto2 #-DBUILD_KSVG=OFF requires fribidi #-DBUILD_KUICKSHOW=OFF requires imlib #-DBUILD_LIBKSCAN=OFF requires sane #-DBUILD_KFILE_PLUGINS=OFF needs poppler
kpdf is built. In fact, these are all the programs built:
kcolorchooser kdvi kfaxview kolourpaint kpovmodeler ksnapshot kviewshell kcoloredit kfax kiconedit kpdf kruler kview mrmlsearch xf86gammacfg
-- Bruce
Darrell Anderson wrote:
I had to pass -DBUILD_KGHOSTVIEW=OFF to cmake to get kdegraphics to build. In fact, here are my notes:
Interesting. That should be automated. If not found, don't build. :)
I don't remember if cmake failed or not. In a couple of places, cmake completed but the make failed.
In a complex package like kdegraphics, it's hard to get every combination right.
-- Bruce
<snip>
With reference to Trinity. :) For example, building kprinter is useless unless cups is installed. Many distro maintainers no longer build poppler with Qt3 support. Amarok breaks unless ruby is installed while building. Etc. No need to get carried away with this list. :)
Poppler should not need to be rebuilt--see this code in the GIT tree: http://git.trinitydesktop.org/cgit/tdegraphics/tree/kfile-plugins/dependenci...
If something else depends on Poppler being rebuilt then there is a problem that needs to be fixed. Upstream will not support Qt3 and we cannot ask users to install modified versions of base system packages.
Tim
Poppler should not need to be rebuilt--see this code in the GIT tree: http://git.trinitydesktop.org/cgit/tdegraphics/tree/kfile-plugins/dependenci...
If something else depends on Poppler being rebuilt then there is a problem that needs to be fixed. Upstream will not support Qt3 and we cannot ask users to install modified versions of base system packages.
I think that is good news. Please provide further details.
For example, in Slackware poppler no longer is built with Qt3 support.
Does adding the new poppler-tqt package overcome that problem? Does poppler-tqt install header files to /usr/include/poppler/Qt3? Or does poppler-tqt install headers that provide the same support as building poppler with Qt3 support but only TDE packages know where to find those headers? In other words, the Qt3 support is unique only to TDE and no other system packages can find that support?
Looks to me like building tdegraphics automatically builds poppler-tqt and I don't have to build that separately?
If a distro maintainer builds poppler with Qt3 support, will this new poppler-tqt conflict?
Do distro maintainers who want to package TDE need to know they don't have to rebuild poppler with Qt3 support?
I'm happy to learn I no longer have to rebuild poppler! I'm just asking questions to understand this new support. :)
Darrell
On 12/26/2011 09:32 PM, Darrell Anderson wrote:
I created an etherpad containing TDE application
descriptions. I extracted much of the information from Helpbook abstracts and then massaged the information accordingly. The extraction process was not fluid or easy to read, even after cleanup. I suspect a few apps are missing from the list.
The descriptions are more or less grouped the same as
the T-Menu.
Everybody please feel free to edit the list as
needed.
Tim, Calvin:
In my web site improvement suggestions I recommended
an applications description page. Ideally, we should have full web pages for certain apps, but this list will provide a nice start. I was thinking about page for each app, containing description, screenshot, dependencies and build instructions. It will be much work, but I think it will ease for people who search for apps with certain functionalities and for those who are building them manually.
Yes, that is where we go eventually. :)
The etherpad is an outline. Something that can be used in the revamped web site to provide a basic list. The descriptions will grow with screen grabs. If everybody picked a few apps, snapped a couple of screen shots, added more detail to the descriptions, then we could have a nice application description section in short order.
Dependencies and build instructions should go in the wiki rather than main web site. Here is a suggested outline for those wiki pages:
Feel free to edit as necessary everybody. :)
Trinity Package Build Requirements
Can I suggess the following changes?
I can then use your "topic names" as the directory for my build scripts and your docs would match the packaging repo. Also the packaging directories under each distro can be named as your topics so that the tde packaging git repo has some order to it. That way under each distro we would have for example:
tde-packaging/arch/ dependencies desktop libraries applications
===================================== Trinity Foundation Packages ---> This to Trinity Dependencies ===================================== tqt3 tqtinterface arts libart-lgpl avahi-tqt dbus-1-tqt dbus-tqt python-tqt sip4-tqt tqca tqca-tls tqscintilla
===================================== Trinity Core Packages ---> This to Trinity Desktop ===================================== tdelibs tdebase
===================================== Trinity Main Packages ---> This is Trinity Desktop ===================================== tdebindings tdeaccessibility tdeutils tdemultimedia tdenetwork tdeadmin tdeartwork tdegames tdetoys tdeedu tdegraphics tdevelop tdeaddons tdewebdev tdepim tdesdk tdeui
Can I suggess the following changes?
I can then use your "topic names" as the directory for my build scripts and your docs would match the packaging repo. Also the packaging directories under each distro can be named as your topics so that the tde packaging git repo has some order to it. That way under each distro we would have for example:
tde-packaging/arch/
dependencies desktop libraries applications
Please change what you want. I threw that list into the conversation only as a starter. Something off the top off my head.
One only caveat is there is a pecking order for building some packages. Obvious is the foundation dependency packages: tqt3, tqtinterface, etc., need to be built before anything else.
PyQt3 and PyKDE3 need to be built before building kdebindings. Not required but there will be no Python integration if those packages are not built first. I think those two packages are renamed in TDE.
libical, libcaldav, and libcarddav need to be built before kdepim. The latter two are not required but must be built if kdepim is to take advantage.
Build tdesdk after installing tdepim. tdepim provides libkcal (bugzilla) hooks for tdesdk.
I can post an exhaustive list if anybody is interested.
Darrell
L0ner sh4dou wrote:
I was thinking about page for each app, containing description, screenshot, dependencies and build instructions. It will be much work, but I think it will ease for people who search for apps with certain functionalities and for those who are building them manually.
Well you are duplicating what I'm doing for LFS, at least as far as dependencies and build instructions. What I have now is not finished and I'm sure there are mistakes, but what I have fundamentally works.
-- Bruce
I was thinking about page for each app, containing
description,
screenshot, dependencies and build instructions. It
will be much work,
but I think it will ease for people who search for
apps with certain
functionalities and for those who are building them
manually.
Well you are duplicating what I'm doing for LFS, at least as far as dependencies and build instructions. What I have now is not finished and I'm sure there are mistakes, but what I have fundamentally works.
You are new to the list (I think). In the last monthly meeting, I committed to creating a list of app descriptions. Something to get us started for the new web site revisions.
I completed the list, which now is available to the team for further editing. This is only a starter list so please help!
The wiki has only the basics for building packages. Participants agreed in the last monthly meeting that the wiki needs significant improvement to help build all packages. Please feel free to hack at the wiki. :)
Darrell
Darrell Anderson wrote:
Well you are duplicating what I'm doing for LFS, at least as far as dependencies and build instructions. What I have now is not finished and I'm sure there are mistakes, but what I have fundamentally works.
You are new to the list (I think). In the last monthly meeting, I committed to creating a list of app descriptions. Something to get us started for the new web site revisions.
Yes, I am new to the list. I joined because I am a senior LFS/BLFS Editor and am in the process of changing KDE3 to Trinity there.
I completed the list, which now is available to the team for further editing. This is only a starter list so please help!
The wiki has only the basics for building packages. Participants agreed in the last monthly meeting that the wiki needs significant improvement to help build all packages. Please feel free to hack at the wiki. :)
I would if I wasn't so busy with BLFS. We have about 600 packages there (count Trinity as three chapters out of 48) and we just released LFS 7.0 in September. Updating BLFS is quite a chore. I will note that I wrote the original BLFS KDE instructions somewhere around 2003.
BTW, I can't find several packages for Trinity. I can't find any i18n packages or kdewebdev for 3.5.13, although I see the PKGBUILD files for them. Do you know where I can find them?
-- Bruce
-
Baho Utot -
Bruce Dubbs -
Darrell Anderson -
L0ner sh4dou -
Timothy Pearson