tde-devels February 2014

devels@trinitydesktop.org

20 participants
243 discussions

Alternative release version numbering scheme proposal

by Michele Calgaro

Dear all, in etherpad 63 (http://trinity.etherpad.trinitydesktop.org/63) we had some discussions about switching to a fixed-time release cycle after R14.0.0 is out of the door. The end result of those discussions and the preliminary agreement of some developers is to use a 90-day release cycle (pending Tim's agreement too :) ). The idea is to issue a maintenance release R14.0.x every 3 months, containing bug fixes and minor improvements, and issue a minor release R14.y.0 every year containing bigger improvements. This will require bugs to be backported from the trunk to the R14.0.x branch for up to 9 months (which could become not that easy after several changes are done in the trunk) and would provide major improvements to the users only once a year. On the other hand, it may prove a more stable solution. An alternative scenario I have been tinkering for a while lately is one where every 3 months we ship whatever is in the trunk as the next release. In this case we do not need to backport any bug and users would be able to get major improvements up to 4 times each year. On the other hand we may introduce some degree of instability if a feature is not well tested before shipping it (but in any case that risk would exist also with the minor R14.y.0 releases of the first scenario), with the "fixing time" being the same (3 months in both scenarios). Given the limited amount of development resources that we have, I have come to like the second scenario the most, and I would like to hear the opinion of other developers as well. If we end up adopting the second scenario, I would also like to propose an alternative release version numbering schema: Ryy.x, where yy is the year number and x is a progressive release number within the yy year. So for example this year we would have R14.0, R14.1, R14.2 (and R14.3 is R14.0 is released before March 31). Then next year we would have R15.0, R15.1, R15.2 and R15.3 and so on.... Coincidentally, this year is 2014, so the year number matches the R14 release number too :) Also, a side-effect benefit would be that TDE would look more active to the general public with Ryy.x release numbers than R14.0.x release numbers, since the last would probably be thought of as "nothing major, just minor fixes". Looking forward for your opinions. Cheers Michele

11 years

tde-Tork builds and works -- amazingly

by David C. Rankin

All, I had never built tork before and had no idea what it was, much less what it did -- well -- it works! Basically it is an internet anonymity extension and functions both as a proxy client and proxy server (configurable). It is basically a tool that allows you to browse/email/ssh anonymously. I still have no idea how to fully use it, but it was refreshing to see that some random app near the end of the applications build tree -- works -- without a lot of CPR. I haven't checked the code, but did see KDE4 patched tork for ipv6. We may need to do that as well. http://www.3111skyline.com/dl/dt/trinity/ss/tork-01.jpg -- David C. Rankin, J.D.,P.E.

11 years

Re: [trinity-devel] OnlyShowIn=TDE or NotShowIn=KDE?

by Darrell Anderson

>That brings us to the point of -- "What is a proper XDG_* >environment for >trinity?" Right now in tqtinterface, we have complete control over >the XDG >environment with trinity.sh. I currently have: > >What additional can we do/(do better) with the environment setup? As I wrote previously, Debian based distros do not use /etc/profile.d. We need to explore how to modify the XDG_*variables without using /etc/profile.d. >+1 When I was shopping desktops, it was not uncommon to have kde3, >kde4, wm2 >fvmwm2, e-16, e-17, gnome, fluxbox, twm, blackbox, openbox, etc. >all installed >simultaneously. The only real havoc was caused by kde3/kde4/gnome. >That's why >the X11 project put out an entire menuing standard to handle what >is isn't >visible in each desktop. I've picked through the standard, but >never compared >between what we have and what is says. Further, in doing so, I >don't ever recall >seeing a clean way of preventing the kde3/kde4/gnome menu mess. It >is almost as >if there is a need for a global 'menuedit' to manage /etc/xdg/menu >on a global >and per/user basis to include/exclude apps in menus when multiple >desktop environments are installed. The menus we now install work well enough within Trinity. We have the option to compile with a "[KDE]" suffix. To reduce menu clutter from duplicate naming, the default Trinity menu places all KDE menu items in a separate "KDE" submenu. We also have an alternate menu that must be installed manually that excludes all KDE menu items. We probably should have a GUI option somewhere to swap those two menu options. The menu mess begins outside of Trinity. Darrell

11 years

Re: [trinity-devel] OnlyShowIn=TDE or NotShowIn=KDE?

by Darrell Anderson

> Do you want a bug open on this one, or just push it? I think it >is small >enough just to push it. Get our fearless leader to comment, but >unless someone >wants a bug opened, I'd just push it if all give the nod. I will push changes for the few *.desktop files discussed. As I mentioned, the core problem is not OnlyShowIn=TDE but the XDG_* environment variables. In the broader scheme, we have no remedy for getting other environments to source /opt/trinity in the XDG_* environment variables. In distros that use /etc/profile.d, the solution is to ensure a script is installed (could be nothing more than the normal trinity.sh script). For the distros that don't use /etc/profile.d, such as Debian, I don't know how to ensure XDG_* variables are modified to recognize /opt/trinity. As I mentioned, when KDE4 is concurrently installed with Trinity, the result will be a menu mess one way or another, unless we provide distro maintainers a more organized menu structure to handle the KDE4/Trinity overload. Some might ask, why would users install Trinity and use a different environment? Many users prefer window managers rather than full desktops, but prefer a selection of apps from the full desktop environments. Many systems are multi-user, and the various users select what to run. In those instances, all options must be installed. There is a growing restlessness in the KDE4 community for PIM apps that do not rely on the akonadi/nepomuk foundation. Trinity PIM apps could fill that role, but without modifying the XDG_* environment variables, the apps won't be found in non-Trinity desktops. Darrell

11 years

Re: [trinity-devel] Alternative release version numbering scheme proposal

by Darrell Anderson

>One thing to point out against Darrells points: David's points. Darrell

11 years

Re: [trinity-devel] OnlyShowIn=TDE or NotShowIn=KDE?

by Darrell Anderson

>This topic deserves further investigation. Some quick testing reveals the problem experienced by the blog author is the XDG environment variables. That said, here is a list of Trinity *.desktop files using OnlyShowIn=TDE ========================================================== applications/adept/adept/notifier/adept_notifier_auto.desktop applications/desktop-effects-tde/desktop-effects-tde.desktop applications/gtk-qt-engine/kcm_gtk/kcmgtk.desktop applications/knutclient/src/knutclient.desktop applications/krusader/krusader/krusader_root-mode.desktop applications/tde-guidance/powermanager/guidance-power- manager.desktop libraries/pytdeextensions/pytdeextensions.desktop tdebase/kappfinder/kappfinder.desktop tdebase/kcontrol/kcontrol/KControl.desktop tdebase/kcontrol/randr/tderandrtray.desktop tdebase/kdesktop/init/Home.desktop tdebase/kdesktop/init/System.desktop tdebase/kfind/Kfind.desktop tdebase/khelpcenter/Help.desktop tdebase/kicker/kicker/kcmkicker.desktop tdebase/kicker/kicker/panel.desktop tdebase/klipper/klipper.desktop tdebase/kmenuedit/kmenuedit.desktop tdebase/konqueror/Home.desktop tdebase/konqueror/preloader/konqy_preload.desktop tdebase/kpersonalizer/kpersonalizer.desktop tdebase/ktip/ktip.desktop tdebase/tdescreensaver/KBlankscreen.desktop tdebase/tdescreensaver/KRandom.desktop tdelibs/tdeabc/tdeab2tdeabc.desktop tdelibs/tderesources/tderesources.desktop tdemultimedia/arts/builder/artsbuilder.desktop tdemultimedia/arts/builder/x-artsbuilder.desktop tdemultimedia/arts/tools/artscontrol.desktop tdemultimedia/arts/tools/artscontrolapplet.desktop tdemultimedia/kmix/kmix.desktop tdemultimedia/kmix/restore_kmix_volumes.desktop tdenetwork/filesharing/advanced/kcm_sambaconf/kcmsambaconf.desktop tdepim/kalarm/kalarm.desktop tdepim/korganizer/korgac/korgac.desktop tdepim/tdeabc/tdeabcdistlistupdater/tdeabcdistlistupdater.desktop tdeutils/kdf/kwikdisk.desktop tdeutils/superkaramba/src/superkaramba.desktop ========================================================== From this list, I think only the following are candidates for change: tdepim/kalarm/kalarm.desktop -> NotShowIn=KDE tdepim/korganizer/korgac/korgac.desktop -> NotShowIn=KDE tdeutils/kdf/kwikdisk.desktop -> NotShowIn=KDE Of the remaining Trinity *.desktop files, the question remains whether any TDE app that has the same name as in KDE4 should use NotShowIn=KDE. Such a change would be noticeable only when a user or admin modifies the XDG_* environment variables to search /opt/trinity. When KDE4 and Trinity are installed concurrently, any such change would remove the Trinity version from the menu and leave only the KDE4 version. I think a better strategy is find a way to improve the menus of other environments. There are two anomalies: NotShowIn=GNOME: tdebase/konqueror/konquerorsu.desktop tdebase/ksysguard/gui/x-ksysguard.desktop Darrell

11 years

Re: [trinity-devel] khelpcenter - howto identify icons opened? (brokenpng.c)

by Darrell Anderson

> There are a number of png files in TDE that generate errors on >opening due to >outdated png header information. I would like to identify which >icons these are. >For example when opening khelpcenter I receive the following >messages: > >03:03 valhalla:~> khelpcenter help:/khelpcenter/releasenotes >khelpcenter: WARNING: Main template file name is empty. >libpng warning: iCCP: known incorrect sRGB profile >libpng error: IDAT: invalid distance too far back >libpng error: IDAT: invalid distance too far back >libpng error: IDAT: invalid distance too far back >libpng warning: Interlace handling should be turned on when using >png_read_image >libpng error: IDAT: invalid distance too far back >libpng error: IDAT: invalid distance too far back >libpng error: IDAT: invalid distance too far back >libpng warning: Interlace handling should be turned on when using >png_read_image > > Apparently, the problem is out-of-date png header information. >Searching I >stumbled across a minimal bit of source that is supposed to fix >the issue, but >only if compiled on older versions of libpng. Looking at the code, >the crux of >it is to rewrite the first 8 bytes of the png header. I've >attached it for >experimentation. It builds well on all of the boxes I have, but I >suspect you >have to force it to build against libpng 1.2 in order for it to do >what it is >supposed to. I'll continue to experiment. If you have few spare >minutes give it >a try and let me know if you can see any discernible difference in >the new/old >png files. I haven't yet. This is a bug report against newer versions of libpng. I don't seen any such errors with libpng 1.4.12. I suspect a rite of initiation to become a libpng developer is to introduce new code that breaks something for everybody downstream. Cousins to the BOFH. Darrell

11 years

Re: [trinity-devel] cmake conversion audit

by Darrell Anderson

>Well, I did a cursory test ages ago just to get a handle on what >had >CMakeLists.txt and what didn't. If we could identify solid >criteria like you >suggested "directories with both CMakeLists and Makefile.am" >files, then it >would be a simple process of walking the git tree with 'find' and >identifying >apps which met the checks and those that partially met and those >that were just >autofoo. > >One issue I see is the use of .in.in and .in instead of .am, so we >may need a >fairly broad search of the variants of Makefile.am, configure.blah >to get a >valid picture of the state of the build setup. > >I'll look for some tests, if you can think of others, let us know. > >Everybody else as well. Here is a preliminary list of modules converted to cmake that contain directories with a Makefile.am but no corresponding CMakeLists.txt. The list offers no conclusions. Just a list. Which items are legitimate remains to be investigated. amarok/amarok/src/engine/helix amarok/amarok/src/engine/helix/config amarok/amarok/src/engine/helix/helix-sp amarok/amarok/src/engine/kdemm amarok/amarok/src/engine/mas amarok/amarok/src/engine/nmm amarok/amarok/src/engine/nmm/icons amarok/amarok/src/metadata/speex amarok/amarok/src/metadata/trueaudio amarok/amarok/src/metadata/wavpack amarok/amarok/src/scripts/graphequalizer amarok/amarok/src/sqlite dolphin/doc dolphin/doc/en dolphin/po knetworkmanager8/knetworkmanager-0.8/introspection knetworkmanager8/knetworkmanager-0.8/po knetworkmanager8/knetworkmanager-0.8/vpn-plugins knetworkmanager8/knetworkmanager-0.8/vpn-plugins/openvpn knetworkmanager8/knetworkmanager-0.8/vpn-plugins/openvpn/src knetworkmanager8/knetworkmanager-0.8/vpn-plugins/pptp knetworkmanager8/knetworkmanager-0.8/vpn-plugins/pptp/src knetworkmanager8/knetworkmanager-0.8/vpn-plugins/strongswan knetworkmanager8/knetworkmanager-0.8/vpn-plugins/strongswan/src knetworkmanager8/knetworkmanager-0.8/vpn-plugins/vpnc knetworkmanager8/knetworkmanager-0.8/vpn-plugins/vpnc/src tdebase/doc/kappfinder tdebase/kcontrol/accessibility tdebase/kcontrol/smartcard tdebase/khelpcenter/htmlsearch tdebase/kicker/applets/swallow tdebase/kicker/kicker/plugins tdebase/kicker/menuext/tom tdebase/konqueror/sidebar/test tdebase/konsole/doc tdebase/konsole/doc/VT100 tdebase/ksysguard/ksysguardd/FreeBSD tdebase/ksysguard/ksysguardd/Irix tdebase/ksysguard/ksysguardd/NetBSD tdebase/ksysguard/ksysguardd/OpenBSD tdebase/ksysguard/ksysguardd/Solaris tdebase/ksysguard/ksysguardd/Tru64 tdebase/libkonq/tests tdebase/nsplugins/test tdebase/nsplugins/wrapper tdebase/tdeprint/descriptions tdebase/twin/clients/kwmtheme tdebase/twin/clients/kwmtheme/cli_installer tdebase/twin/clients/test tdebase/twin/tools tdebase/twin/tools/decobenchmark tdegraphics/ksvg/plugin/backends/agg tdegraphics/kview/kviewcanvas/test tdegraphics/kview/kviewviewer/test tdegraphics/kview/modules/scale tdegraphics/kview/modules/template tdelibs/arts/kde/mcop-dcop tdelibs/dcop/tests tdelibs/doc/tdelibs tdelibs/interfaces/terminal/test tdelibs/kate/plugins/autobookmarker tdelibs/kded/test tdelibs/libtdemid/tests tdelibs/tdeabc/plugins/evolution tdelibs/tdeabc/plugins/sql tdelibs/tdeabc/scripts tdelibs/tdeabc/tests tdelibs/tdecore/tdeconfig_compiler/example tdelibs/tdecore/tdeconfig_compiler/tests tdelibs/tdecore/tests tdelibs/tdehtml/java/tests tdelibs/tdeinit/tests tdelibs/tdeio/tdefile/tests tdelibs/tdeioslave/http/kcookiejar/tests tdelibs/tdemdi/test tdelibs/tdeparts/tests tdelibs/tdeprint/foomatic tdelibs/tdeprint/lpd tdelibs/tdeprint/tests tdelibs/tdespell2/tests tdelibs/tdestyles/klegacy tdelibs/tdestyles/web tdelibs/tdeui/colors tdelibs/tdeutils/tests tdelibs/tdewallet/backend/tests tdelibs/tdewallet/tests tdelibs/tdewidgets/tests tdenetwork/kopete/kopete/chatwindow/tests tdenetwork/kopete/libkopete/compat tdenetwork/kopete/libkopete/tests tdenetwork/kopete/libkopete/tests/mock tdenetwork/kopete/plugins/smpppdcs/unittest tdenetwork/kopete/protocols/groupwise/libgroupwise/tasks/tests tdenetwork/kopete/protocols/groupwise/libgroupwise/tests tdenetwork/kopete/protocols/jabber/jingle/libjingle/talk/examples tdenetwork/kopete/protocols/jabber/jingle/libjingle/talk/examples/ca ll tdenetwork/kopete/protocols/jabber/jingle/libjingle/talk/examples/lo gin tdenetwork/kopete/protocols/oscar/liboscar/tests tdenetwork/kopete/protocols/yahoo/libkyahoo/tests tdenetwork/ksirc/puke tdepim/certmanager/lib/backends/kpgp tdepim/certmanager/lib/tests tdepim/indexlib/tests tdepim/karm/test tdepim/kitchensync/opensyncdbus tdepim/kmail/tests tdepim/kmobile/tdeioslave tdepim/kmobile/tdeioslave/mimetypes tdepim/kode/kwsdl tdepim/kode/kwsdl/kung tdepim/kode/kwsdl/schema tdepim/kode/kwsdl/tests tdepim/kode/kwsdl/tests/google tdepim/kode/kwsdl/wscl tdepim/kontact/plugins/kitchensync tdepim/kontact/plugins/kpilot tdepim/kontact/plugins/test tdepim/korganizer/plugins/printing/list tdepim/korganizer/plugins/printing/whatsnext tdepim/korganizer/plugins/projectview tdepim/korganizer/plugins/timespanview tdepim/ktnef/tests tdepim/libemailfunctions/tests tdepim/libkcal/tests tdepim/libkmime/tests tdepim/libksieve/tests tdepim/libtdenetwork/libgpg-error-copy tdepim/libtdenetwork/libgpgme-copy tdepim/libtdenetwork/libgpgme-copy/assuan tdepim/libtdenetwork/libgpgme-copy/gpgme tdepim/libtdenetwork/qgpgme/tests tdepim/libtdepim/cfgc tdepim/libtdepim/interfaces tdepim/libtdepim/komposer tdepim/libtdepim/komposer/core tdepim/libtdepim/komposer/core/tests tdepim/libtdepim/komposer/plugins tdepim/libtdepim/komposer/plugins/default tdepim/libtdepim/komposer/test tdepim/libtdepim/tests tdepim/tdeabc/frontend tdepim/tdefile-plugins/palm-databases tdepim/tdefile-plugins/rfc822 tdepim/tdeioslave/opengroupware tdepim/tderesources/blogging tdepim/tderesources/groupware tdepim/tderesources/tvanytime tdesdk/doc/kapptemplate tdesdk/kbabel/kbabeldict/modules/dbsearchengine2 tdesdk/poxml/antlr/antlr tdesdk/tdeunittest/example tdesdk/tdeunittest/example/module tdesdk/tdeunittest/example/simple tdesdk/umbrello/umbrello/autolayout tdevelop/buildtools/lib/parsers/autotools/tests tdevelop/buildtools/lib/parsers/qmake/tests tdevelop/doc/kdearch tdevelop/doc/tools tdevelop/kdevdesigner/plugins tdevelop/languages/cpp/app_templates/generichello tdevelop/languages/cpp/app_templates/gnome2mmapp tdevelop/languages/cpp/app_templates/kmake tdevelop/languages/cpp/app_templates/prc-tool tdevelop/languages/java/newclass_templates tdevelop/languages/kjssupport tdevelop/languages/kjssupport/subclassing_template tdevelop/languages/kjssupport/template tdevelop/parts/documentation/plugins/djvu tdevelop/parts/documentation/plugins/pdb tdevelop/parts/documentation/plugins/pdf Darrell

11 years

Re: [trinity-devel] cmake conversion audit

by Darrell Anderson

>Perhaps it is worth do a complete check of what is completed and >what not. That means check every single package. I agree. How? For example, dolphin was listed in the etherpad as completed. Yet I compiled dolphin with cmake and no doc or po files were compiled. Therefore I deleted the 'completed' tag in the etherpad and wrote a note. I know that not all components of amarok were converted and I filed a bug report against that a very long time ago. As I mentioned, the cmake packages do not build man pages. Another bug report filed. This is part of why I am suspicious of whether all packages have been converted completely. To my knowledge we no longer can build the core packages with automake. Only cmake. Therefore the only file-by-file comparison we can attempt is with a fully compiled 3.5.13.2 package. We have to account for the renaming changes. Yet everybody builds packages differently. Using a 3.5.13.2 package as a baseline does not mean all components were compiled. Darrell

11 years

build script for debian?

by Dr. Nikolaus Klepp

Hi all! Could sombody please send me a build script for debian? Nik -- Please do not email me anything that you are not comfortable also sharing with the NSA.

11 years

← Newer
1
...
7
8
9
10
11
12
13
...
25
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels February 2014