tde-devels

devels@trinitydesktop.org

9 participants
3819 discussions

Resolving the TWin/KWin Fork Issue
by Martin Gräßlin 30 Apr '12

30 Apr '12

Hi all, I had to see that there is still development going on in your fork of KWin and I am very unhappy about that. This is something I really want to see resolved, any development to KWin should happen in KWin, it's such a waste to work on the same project without coordination. Let's first recapture the state of TWin: = Why does TWin exist? = Because KWin got forked together with everything else from KDE 3.5 to form the Trinity Desktop Environment (TDE). = Why has the TDE fork happened? = The TDE fork existist because of a combination of the following reasons: * Parts of KDE had to be rewritten in order to be ported to Qt 4 * Early versions of KDE 4.x were lacking functionality compared to KDE 3.5 * Early versions of KDE 4.x had quality and stability issues compared to KDE 3.5 * A general disagreement with some project decisions * KDE 4.x introduced new technologies unliked by some (e.g. Nepomuk or Akonadi) = Do these reasons hold for KWin? = No! None of the reasons stated above has ever been true for KWin. KWin is a direct continuation of the KDE 3 version. The codebase did not get rewritten, the quality of the window manager did not suffer, new functionality got added as optional addons. = Is there any other reason justifying the TWin fork? = Maybe the fact that KWin depends on Qt4/kdelibs4 which is not liked by TDE. = Is that a reason for a hostile fork as it is at the moment? = No, the fact that TWin requires Qt 3 is no reason to have the current state with the hostile fork. Best would be a solution of no fork, but a collaborative friendly fork should be possible, given that KWin and TWin share a large code base. = What can KDE do about the fork? = Actually pretty much nothing. The license allows TDE to fork KWin - whether we like it or not. All we can do is force you to change the name and urge you to work together with us. = Why do I actually care? = The KWin development team is rather small. I would like to see more involvment inside KWin than to see duplicated work in a fork. Furthermore KWin 3.5 has a very good reputation and is known as rock solid. I see this reputation questioned if the TWin fork is continued without the quality checks performed in the KWin development. Lets have a look at the recent patch for TWin called "Mac Like Switching Panel". This introduces a new feature to switch through applications and references an implementation in window maker. To be clear: this functionality has been present in KWin since version 4.4 (I added it). A little bit of coordination here would have prevented the duplication of development. But is there a problem when Trinity adds code, should I care? Well the code is wrong (review based on patch2.patch on mailing list). In an attempt to copy everything from window maker code got added to KWin (particular readClass) which already existed. Lack of knowledge about the KWin source code are probably the reason that it is unknown that KWin::Client::resourceName()/resourceClass() provide the window class attribute. Another problem is that the code is crashy. For me as an experienced KWin developer I only need to look at the code and see immediately were it is likely that the code will crash. Consider that start is NULL and the following line of code: start->readClass(). How likely is it that a non KWin developer would have spotted this crashy code? How likely is it that you know how to create such a situation? (I know it exactly). It is not surprising that you are not able to add code to KWin which is correct - hardly anybody not knowing the code base is able to do so. That's why we perform code review and help new developers to get the code into a state that it works correctly. We are happy to accept patches from the Trinity team to KWin as well (of course we only accept patches for current master). The important difference is that in KWin there is a quality assurance through the code review by *experienced* KWin developers. This is impossible in TDE as there are no experienced developers for KWin. Now I'm not writing this mail to blame you for writing wrong code. If I would be "evil" I would sit back, relax and wait to see TDE hit the wall which is approaching faster and faster when crashy code gets added. Remember: one of the reasons for Trinity is the (no longer) bad quality of KDE 4 code. And you even use that in your external communication - such crashy changes might backfire and then you cannot blame KDE. I'm here now to resolve this issue about TWin together with you. I want to see the hostile fork go away. From all we see TDE is unable to maintain or even develop TWin. Please accept this fact as it is. It is nothing bad, I needed three years of strong involvment in KWin developer before becoming maintainer and there are still large areas of code blocks where I have no clue about. Based on that fact we have to look for a solution. In my opinion the best would be to just use our KWin. And we have some quite useful things about that in our current development version: * no longer depends on anything else from kde-workspace * build options to disable "KDE 4" features (see http://techbase.kde.org/Projects/KWin/Build_Options) * mostly runtime dependencies to libplasma * desktop integration possible through custom QML additions like e.g. Alt+Tab * currently integrates with three desktop shells * (under review) build option to change the name of the binary, which would allow you to generate a kwin_tde or twin binary (automatic adjustment of all configuration files, etc.) (see https://git.reviewboard.kde.org/r/104299/) * after feature freeze: branch to build kwin standalone without the need to run cmake in kde-workspace. As you can see this is a rather impress list of features which would allow TDE to use KWin instead of their fork. Of course KWin depends on Qt 4 and kdelibs 4. We have no interest to support anything below Qt 4.7 and are currently preparing the transition to Qt 5 and KDE Frameworks 5. I think that this is only a minor issue to Trinity as to my understanding TDE can also use Qt 4. We are open to discuss any concerns regarding integration a Qt4/kdelibs4 based application into TDE. I am very sure that most of your possible concerns are rather non-issues and that they can all be easily resolved. I hope that you consider dropping your hostile fork of KWin and start to collaborate with your upstream pears at KDE more closely. Thanks for your time Martin Gräßlin KWin maintainer

17 74

STRACE - kwrite crash i686
by David C. Rankin 30 Apr '12

30 Apr '12

Tim, Darrell, As /dev/ammo42 suggested, I captured a strace on the i686 crash. It is attached to bug 979. (current tdebase and tqt3, tdelibs from 4/16 -- same crash) http://bugs.trinitydesktop.org/attachment.cgi?id=568 Also, this bug occurs 100% of the time when pasting 'small' amounts of text (1-2 words at a time) until the line wraps. I can paste 10 lines of text into kwrite and keep editing - so it looks like something that effects the single line length computation. I'll keep incrementally downgrading and report when I narrow the time the bug was introduced. If anyone can read straces, then take a look. -- David C. Rankin, J.D.,P.E.

2 2

kwrite/kate - why is 3.5.12 not affected (help analyzing)
by David C. Rankin 30 Apr '12

30 Apr '12

Tim, All, As I work to downgrade my R14 test boxes to troubleshoot what caused the kate/kwrite crash, I ran into a question I would like to get your thoughts on. All my day-to-day boxes run fully updated Archlinux (with one openSuSE box), and TDE 3.5.12 as the desktop (3.5.10 on SuSE). QUESTION: If the crash is due to an Arch update -- "They why do kate/kwrite continue to function normally in 3.5.12?" It just strikes me that 3.5.12 would be much more susceptible to break due to Arch updates that R14. Would we not expect to see this same crash in 3.5.12 if this was due to an Arch update? What say the experts? If this was Arch, wouldn't 3.5.12 have broken too? -- David C. Rankin, J.D.,P.E.

4 19

kcmshell keys
by Jay 29 Apr '12

29 Apr '12

Tmenu/settings/regional & accessibility/keyboard shortcuts gives a segfault SIGSEGV. Running *kcmshell keys* opens the panel successfully. Can someone else confirm this? Jay

5 18

New kwrite crashes with yesterdays builds of tdelibs/tdebase
by David C. Rankin 28 Apr '12

28 Apr '12

All, After rebuilds of tdelibs/tdebase yesterday evening (with fresh GIT update), I have experienced repeated crashes with kwrite becoming unresponsive. The kwrite window stays open, but no response from the menu, toolbar or context menu and the screen within the kwrite window does not repaint itself. (leading to a million copies of anything you move across it). Here are a couple of screenshots of the behavior after the crash (we've all seen it before...) http://nirvana.3111skyline.com/dl/dt/trinity/ss/kwrite-crash-select-buffer.… http://nirvana.3111skyline.com/dl/dt/trinity/ss/kwrite-crash-backspacing.jpg I repeated the crash twice. It seemed to occur when either inserting text with the select buffer (select, then middle-mouse paste) or when simply backspacing to join two lines of text in kwrite. It was bad enough that after the second crash, I had to give up and just use vim. For the second attempt working with kwrite, I started it from konsole so I could look at the kdDebug output. There was nothing out of the ordinary. These crashes have always been difficult for me to isolate. Can anyone suggest a test that would help identify the problem. Also, any reports confirming this behavior would be helpful. -- David C. Rankin, J.D.,P.E.

5 35

How to support ruby 1.9.x?
by Darrell Anderson 28 Apr '12

28 Apr '12

I have some patches that I apply for my builds when using ruby 1.9.x rather than 1.8.x. Amarok, tdebindings, and koffice, although the latter has additional problems with ruby 1.9.x. I want to push these patches to GIT but I can't change code one-way because the ruby 1.9 patches will cause build failures for those folks still building against ruby 1.8.x. I need to add preprocessor checks in the patches to test the ruby version, similar to what we have been doing for building against libpng 1.4/1.5. Normally there is an APP_MAJOR_VERSION and APP_MINOR_VERSION variable defined in an app header. The ruby people feel the need to be different and don't do this. At least not with the latest versions. There are two basic methods to extract the version: RUBY_MAJOR_VERSION="`ruby --version | awk '{print $2}' | awk -F '.' '{print $1}'`" RUBY_MINOR_VERSION="`ruby --version | awk '{print $2}' | awk -F '.' '{print $2}'`" Or: RUBY_MAJOR_VERSION=ruby -rrbconfig -e "puts Config.expand( Config::MAKEFILE_CONFIG['MAJOR'] )" RUBY_MINOR_VERSION=ruby -rrbconfig -e "puts Config.expand( Config::MAKEFILE_CONFIG['MINOR'] )" How do I get the cpp code to recognize those variables? Can I do this through the configure process? Thanks. Darrell

2 1

Tim: tdegraphics POPPLER_016
by Darrell Anderson 28 Apr '12

28 Apr '12

Tim, What is the significance of checking for version 0.16 of poppler and not earlier versions? Darrell

5 11

kmplayer patch
by Darrell Anderson 28 Apr '12

28 Apr '12

A while ago David posted a build failure with kmplayer: gstplayer.cpp:1009:5: error: C99 designator 'b' outside aggregate initializer I don't know what the error means. David proposed a patch but nobody responded as to whether his patch was legitimate. Yesterday I tried to build kmplayer with gcc 4.7. I saw the same failure. I forgot about David's query. I looked around the web for clues to resolve the problem. I ran into this: http://websvn.kde.org/?view=revision&revision=686006 The patch description is exactly what David and I saw with the build failure. The patch was to the xineplayer.cpp module. Other than the difference between "XINE" and "XVIDEO" I figured the patch is just what the doctor ordered. I massaged the patch for the gstplayer.cpp module and compiled. No failures and the package size is the same as non gcc 4.7 builds. I tested the patch with a non gcc 4.7 build too. I pushed the patch in GIT hash 5106117b. Odd that the "C99 designator" problem was addressed in the xineplayer.cpp module yet the same exact code in gstplayer.cpp was not. The patch does not include fixes for xine-libs. Because there remains a wide mix of xine-libs versions being used, at least for now, the original patch David proposed should have some preprocessor tests like we did with several other patches. That way the patch can be pushed to GIT and work for all versions of xine-libs. I will try to do that. I searched the list archives but could not determine the exact version when the problems start. Which version of xine-libs causes the problems? Darrell

1 2

tdegraphics FTBFS
by Darrell Anderson 27 Apr '12

27 Apr '12

What is the status of the patch in bug report 902? I tried the patch with the latest GIT and gcc 4.7. The build still fails with the same error: collect2: error: ld returned 1 exit status /usr/lib/gcc/i486-slackware-linux/4.7.0/../../../../i486-slackware-linux/bin/ld: CMakeFiles/ksnapshot.dir/windowgrabber.cpp.o: undefined reference to symbol 'XShapeQueryExtension' Darrell

2 6

gcc 4.7 support
by Darrell Anderson 27 Apr '12

27 Apr '12

I am now (finally) building Trinity in a gcc 4.7 environment. So far pretty good news. I can't build tdebindings with xparts and tdegraphics. Otherwise I seem to be moving forward. As I build each package I notice what fails and then head to the bug tracker looking for patches. Bug report 958 is a first start but there are a few other bug reports too. If you have not submitted any related gcc 4.7 patches, please do so. As an attachment here in the list is fine or a bug report. I have tested some of the patches and they work for me as well. Therefore I am going to start pushing those that I test successfully. (Working for two or more people using different distros is a reasonable litmus test.) I mention this here as a friendly warning. :-) That is, if you are building from GIT, please check all resources before posting to the list. That includes doing a git pull to discover whether I pushed a patch. I'm even learning. :-) I just created a tdepim patch that needed a this-> pointer. Thanks to all of you who have created similar patches, from which I learned what to do. I don't grasp the whole "this" pointer concept, but I can patch. :-) Darrell

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels