I have spent considerable time thinking about that question ever since the official announcement that KDE3 no longer would be actively supported by the KDE developers. I would use the last available release of Trinity or KDE 3.5.10 --- for as long as I could. If Trinity disappeared today I could squeeze a couple of more years out of either before running into insurmountable compiling issues. I never have been a GTK fan. The standard file picker dialog is clunky. Much of the GTK design seems to revolve around the NIH (Not Invented Here) syndrome. Every year I try Xfce, LXDE, Fluxbox, IceWM, etc. and immediately yearn for KDE3. I do not like any of the file managers offered in the GTK world, which is where my yearning begins. Konqueror 3.5 is one of the all-time great file managers. Initially I decided I'd bide my time until KDE4 became fully usable. As I mentioned some days ago, I did not blame the initial KDE 4.0 reaction as the fault of the developers but the distro maintainers. Until the day when I determined KDE4 had matured for my usage --- and I would determine that day, not self-appointed nannies --- I decided to learn to rebuild 3.5.10 to fill the void. Somewhere along the way Trinity appeared and I saw hope. As a free/libre software advocate I want KDE4 to succeed. I want GNOME and 'buntu to succeed. That does not mean those environments satisfy my needs for desktop computer usage. I gave 4.2.4 a serious shot when I built my home theater PC. A horrible experience. I installed 3.5.10 and used the various kiosk features to build a great little appliance. A year ago I gave KDE 4.5.5 a serious opportunity. The more I used KDE4 the more exhausted I became. A desktop should never get in a user's way. As a desktop I could acclimate to KDE4 without fanfare. My challenge is ever since the KDE4 developers announced that Akonadi would be deeply entrenched into the PIM apps, I am faced with running the KDE4 PIM apps with that overhead or face finding GTK apps to replace what I use. Not to mention that KMail has been broken through 7 point releases. I'm waiting for glowing reviews about KMail from 4.8 users. I use KMail, Akregator, and KAlarm. I don't need a database caching that data all day. I'm not an information or data junkie. I don't care what spin doctors say about managing personal information. A significant number of users who do not need enterprise support get along fine with each PIM app handling its own data. I understand why the KDE4 developers chose their path. The PIM data management ties into their idea of semantic desktops and sharing data among users and apps. I do not have that kind of information flow in my life that requires the backend overhead KDE4 now requires, but I can't disable the overhead. I don't like Dolphin. I don't like the look and feel of KDE4. Perhaps Qt4 is the actual culprit, I don't know. Amarok 2 is awful compared to the simplicity of Amarok 1.4. Yeah, I know, there is Clementine, but I like 1.4. Although there is a method to the new way of doing things in KDE4, configuring a KDE4 desktop takes more effort. Using apps requires more mouse clicks or keyboard strokes. The more that KDE4 evolves the more that various external apps will be built with dependencies on Akonadi, Nepomuk, and Strigi. There is no Plan B with KDE4. I'm sure those who use KDE4 love what they have. I want them to be happy with their choice. That is how free/libre software should be. Likewise, for me, I like the way KDE3/Trinity works and not the way KDE4 works. I should be able to enjoy my choice and be left alone and not be hen-pecked by self-appointed nannies. I have the hardware to run the overhead of KDE4 PIM apps. If today my only choice was a GTK desktop or KDE4 I would choose KDE4. To me KDE4 is more palatable than anything in GTK. I don't like certain design decisions made with KDE4 but I would learn to live with the bloated design. I would rebuild packages if that avenue allowed me to reduce some cruft. Today those two environments are not the sole options. Therefore I would keep my eye on Razor-Qt, maybe even join their effort. I don't think think they offer PIM apps, but perhaps someday somebody will strip the Akonadi crap from KDE4 PIM apps and port to Razor-Qt. To my perspective, that Razor-Qt exists is an indicator that users are unhappy with the direction of KDE4. Fortunately I need not decide today. For now I continue rebuilding KDE 3.5.10 and Trinity. I'll squeeze as many years as possible from those sources. As I am teaching myself C++, possibly one day I might even learn enough to keep Trinity as my desktop for a long time. I'd be dismayed if the day came soon that Trinity disappeared. GNOME and KDE4 do not help me feel warm and fuzzy. I'm too deep in the 'nix way of using computers. Therefore Windows is not a palatable option. Outside of work contracts I don't use Windows. I detest the philosophy of the Apple people and their walled gardens. The philosophy of free/libre software fits me wonderfully. That does not mean the current trend in free/libre desktops fits me wonderfully. Trinity is my hope for the future. The KDE4 developers do what they want. The GNOME developers do what they want. The 'buntu people do what they want. And to a certain degree, rightfully so. And rightfully so I wish others would leave us alone to do what we want. We don't bother anybody. Why do they believe they have standing to bother and attack us? Mostly I don't like the attitude of KDE4 and GNOME developers. At one time the BSD developers were blatant about who they wrote the software for --- themselves. There was no pretense. I could endure the GNOME and KDE4 developers (but not their software) if they would be as honest and admit they develop the software for themselves and not others. I prefer the attitude and philosophy of those participating in Trinity. In the discussions held here in this list there is a genuine concern for users. Even I have solicited ideas and then retracted because of the needs of the wider user base. I invest a lot of my time to make Trinity succeed. I need to because the alternatives leave me sour. I wish we had one or two additional crack C++ coders on board to expedite development and bug fixing. I wish I could crank C++ code a tenth as good as you. I don't own any crystal balls and can't predict the future of Trinity. For my style of usage, I hope Trinity hangs around for several more years. If not then I'll hang on as long as possible and hope Razor-Qt becomes popular with traditional apps and no KDE4 overhead. Yet as long as Trinity is active I'll do my part to help. With that all said, I ask and hope that everybody involved here ignores the KDE4 people every time they interrupt our discussions. Just ignore them. No response at all no matter how tempting. Let them say and think what they want while we mind our own business and devote our energies to Trinity. :) Darrell

I would move to an Indian ashram and forsake computing all together, although they probably also have a few boxes but certainly not with enough processing power to run KDE4.

Community based projects keep the end user in mind, and that is what we need. This is why my preference lies with projects such as Trinity. KDE3 was an abandoned child, adopted by Trinity and slowly growing to be a respectable, viable alternative to the bloated, overweight and overly complicated (read non intuitive) standards adopted by KDE4 and other DM's hell bent on moving forward while throwing caution (and compatability throughout linux) to the wind.

I could be wrong but Akonadi's goal seems to be to simplify kdepim data storage by using a standard DB engine that "just works" instead of custom application-specific and mutually-incompatible DB-like code. If it works, everything's fine and we will benefit from advanced optimisations of SQL engines. And from my own experience it finally works in KDE 4.8.

NEPOMUK and Strigi don't have the same place, their role is to eat CPU cycles and disk bandwith until the user either deactivates them or does something useful with them. But kdepim won't depend on them.

On Sun, 12 Feb 2012 20:06:59 -0800 (PST) Darrell Anderson <humanreadable(a)yahoo.com> wrote: One not really needs to have a "bleeding edge hardware" to run KDE4. Unless you consider an €250 (without taxes) ultra-low-end box from 2004 being bleeding edge.

On Mon, 13 Feb 2012 01:10:14 -0500 Kristopher John Gamrat <chaotickjg(a)gmail.com> wrote: My €250 box didn't run KWin effects (you can disable them instantly with Alt-Shift-F12, or go in the System Settings to disable them permanently), anyway it couldn't given the old "Graphics My A**" it has. The KWin performance improvements on 4.7/4.8 are real, at least on my all-AMD laptop with FOSS drivers.

Anyway the code path in question has been reworked in 4.8 and uses now evil technology coming from mobile devices ;-)

On Monday 13 February 2012 11:35:59 Timothy Pearson wrote: I'm sorry but you are very badly informed. The technology provided by Qt for mobile development is called QML. It is not a widget toolkit in the classic way but more like HTML 5 + JavaScript. I recommend to just read a little bit about it :-) This technology allows you as the developer to decide how large e.g. a button is. In Plasma we use the same widget API just with different backend for desktop and touch allowing us to have large buttons for touch and normal buttons for mouse/keyboard driven environments like a desktop. Now your screenshot shows two applications not using QML, two applications not designed for touch. Aaron already pointed out that QWidget is a very stable area and has not changed at all. I am sorry to say, but you really have to read a little bit about the technology behind before doing bold statements. It's one of the things I criticised in my blog post as you might have noticed - at least I hope so :-) Cheers Martin

On Monday, February 13, 2012 12:04:42 Timothy Pearson wrote: they don't; but where there is more whitespace usage it's due to the QStyle. a QStyle that using the same pixelmetrics as you are familiar with from Qt3 would have the same layout and proportions. few people like that, however, so there are few styles as cramped. they don't. see how easy it is to make assertions when no supporting facts are required? well, here: http://aseigo.blogspot.com/2010/01/gwenview-user-friendly.html yes, i can. you may recall i worked at the same company as these guys for 6 years, the years that happen to be in question. unfortunately for you, i worked with them extensively during this time period. i saw new things before others did, i worked with APIs before others did, i had long discussions with the developers as they were working on things.

On Monday 13 February 2012 12:23:22 Timothy Pearson wrote: in Dolphin it takes one click because media devices are listed in the side bar :-)

On Mon, 13 Feb 2012 12:43:07 -0600 "Timothy Pearson" <kb9vqf(a)pearsoncomputing.net> wrote: Right-click -> Add Entry, in Places panel. You can add whichever location you want, and by right-clicking the new location you can change the label to something more suggestive than "bin" :) --------------------------------------------------------------------- To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pejarsoncomputing.net/mailing_lists/#top-posting

And when I have to access more than a handful of different (*gasp* NEW!) directories in rapid succession? Let me guess, there's some king of plasmoid that makes this easier, though I'd have to go to the desktop (minimize all windows or similar) to even see it. </sarcasm> KDE4's focus is radically different that TDE's, and these "new ways of doing things" are proof of that. I'm sure they work fine for some, but I find an 80-column terminal easier and more intuitive to use than Dolphin.

On Monday 13 February 2012 12:52:07 Timothy Pearson wrote: Timothy, please, your sarcasm and rants doesn't help you anything.

You can still use Konqueror as the default file manager in recent releases of the KDE Plasma Workspaces. You can configure Dolphin to behave different. Dolphin is focusing on a different user group than Konqueror did. That is just fine. Konqueror's target user group is still very well suited by Konqueror. Personally I was a very strong Konqueror power user in the days of KDE 3.5. I had twenty open tabs, with splitted views, konsoles embedded. I could never believe to use anything different. Nowadays I use Dolphin and I love it. I am much faster using Dolphin than I have ever been with Konqueror. The examples you bring might sound valid to you by counting clicks. But the truth is: you never need these things. I have perhaps five folders I often need - those are in my places bar. If I really need to enter an address I use Ctrl+L to jump into the location bar and enter it manually, but that hardly happens.

And when I have to access more than a handful of different (*gasp* NEW!) directories in rapid succession? Let me guess, there's some king of plasmoid that makes this easier, though I'd have to go to the desktop (minimize all windows or similar) to even see it. </sarcasm>

KDE4's focus is radically different that TDE's, and these "new ways of doing things" are proof of that. I'm sure they work fine for some, but I find an 80-column terminal easier and more intuitive to use than Dolphin.

Tim --------------------------------------------------------------------- To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting

Hardly intutive, and definitely not discoverable.

How is that unfortunate for me? It is good to know the truth! I already know the whitespace is embedded in the widget metrics. If I needed to I could fix that one problem programatically, but it still leaves all the others open. Remember I said *almost* all applications? There are a handful that have finally grown up and become better than the KDE3 originals, but right now the only one I can think of is krdc. It took many years, and their presence frankly does not justify using the rest of KDE4. Also, you are trying to tell me that e.g. changing to the /media/flash directory requires fewer clicks in Dolphin than in Konqueror? In Konqueror it would take exactly two mouse clicks, and if media/ was already expanded it would take one click. In Dolphin I don't even know where to begin, other than poking around trying to get my location bar back. Heck, I don't even know where to begin looking for that configuration option.

KDE4 has serious discoverability issues which are separate from the ease of use issues. Tim --------------------------------------------------------------------- To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting

Ooh, black magic. I love that in my desktop environment. Who cares about discoverability? I'll just randomly click on everything until I see what I want. </rant> </sarcasm> Honestly when I tried KDE4 I was willing to put up with the hideous ugliness of the whole thing, and the fact that it wasted my screen space, if the UI was just discoverable. I was even willing to redo the themes, widgets, etc. until I discovered just how much of a discoverability nightmare the entire UI had become. Users having to resort to using Google to find out the new way of doing simple tasks is a Very Bad Sign.

Tim --------------------------------------------------------------------- To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help(a)lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting

Did you always use Bash, or did you ever use the old Konqueror regularly? I am just curious here.

On Sun, 12 Feb 2012 11:24:11 -0800 (PST) Darrell Anderson &lt;humanreadable(a)yahoo.com&gt; wrote: I could be wrong but Akonadi's goal seems to be to simplify kdepim data storage by using a standard DB engine that "just works" instead of custom application-specific and mutually-incompatible DB-like code. If it works, everything's fine and we will benefit from advanced optimisations of SQL engines. And from my own experience it finally works in KDE 4.8.

Very well said Darrell. And TDE is not going anywhere soon if I have anything to say about it. :-)

Responses like yours are good material for the KDE4 devs to digest as well. If they care about the users then they can use your insight to actually do something about KDE's flaws. If not, their desired direction will be clearer and we can safely ignore a good chunk of the criticism (as you said above).

And yes, Qt4 is the culprit to a large extent when you said "I don't like the look and feel of KDE4". What you are seeing is the end result of a widget pool and default styles that were designed for cell phones (after all, they are what Nokia makes!). KDE4 could theoretically override these defaults, but there is some resistance to creating a new widget set that is more appropriate for a desktop environment as far as I can tell from reading various mailing lists. Part of that is that creating widget sets is a lot of work, and I guess another part is that smaller widgets will only serve to accentuate the loss of point-and-click functionality from items such as toolbars, treeviews, and toolboxes.

On Monday, February 13, 2012 12:12:10 Kristopher John Gamrat wrote: what you shared is not new to me, or to anyone else i imagine. to expect something that is already known to change a conclusion based on what is known is unrealistic. i have no issue with people deciding what is best for them. what i do take issue with, and which your viewpoint as shared does nothing to diminish, is the choice some make to couple ignorance with negativity and turn that into unconstructive, indeed destructive, interaction. good luck with that.

On 13 February 2012 05:56, Aaron J. Seigo &lt;aseigo(a)kde.org&gt; wrote: <snip> In regard to caring about users, I think it is important to note why many users felt like they were left in the dust. KDE 4.0 had a rocky start, and was not ready for usual consumption for some time by many users running into bugs. It was a beta release that wasn't beta. I think many users were forced to upgrade to 4.0 had a very difficult time understand what was going on, especially since the very loved 3.5 was totally out the window (when there could have been continued support for a short time, until a stable KDE4 was released). If KDE 4.8 was released exactly when 4.0 was, users would be more likely to have switched. KDE 4.8 is very stable and works great for almost all users. The problem is the past 8 releases that have driven everyone insane, and they are now biased against the KDE4 experience.

We do care for users, evidence abounds for that, but not all of our users agree with each other.

so let's set the record straight, once again: we do care for our existing users, then and now.

The KDE4 developers do what they want.

if they would be as honest and admit they develop the software for themselves and not others.

We don't bother anybody.

Why do they believe they have standing to bother and attack us?

If anything, Martin Graesslin is "pathetic and juvenile". Every message he has sent here has been arrogant and demeaning of our group.

It really blows my mind that he keeps pretending that he has has no part in the negativity. This entire thread is a response to his attacks (valid or not) on the TDE project.

He has made several high profile blog posts regarding Trinity and cast it in his own light.

That is fine by me, but after saying all of that crap, and then coming here and pretending he wants us to use KWin? It's a double standard.

It is clear that the only people using TDE are people who are very consciously doing so.

They are all aware of KDE4, Gnome and other projects. I keep trying to say "live and let live" but it doesn't get much headway.

I have repeatedly gone out of my way to state that KDE4 is a perfectly valid desktop along with all the rest (Gnome, XFCE, etc). available for Linux. I have NEVER started a KDE4 bashing thread, and have always tried to differentiate based on feature sets and workflows instead of claiming that "TDE does everything".

Almost every major argument comes up as a result of the KDE project bashing TDE or trying to replace core components willy-nilly, as happened most recently.

That said, TDE users have a different opinion of how "today's applications" should look, feel, smell, act, and quack. :-)

I don't see any reason that this differing opinion should be treated any differently than the continual ideological disagreement between the Gnome devs and the KDE devs (e.g. how a file dialog should look and act)--politely, without attempts to change user visible elements of the other desktop environment.

What seems to be lost here is that I actually went out of my way to add the ability to use kwin4 in TDE. Because I didn't replace twin outright (even though I have outlined the steps many times before that would be required to even consider replacement) Martin went off on a TDE bashing spree.

If anything, this is immature. I have repeatedly asked him for the technical reasons that he considers twin changes to have "broken" it, and I still do not have an answer.

I would hate to see you go;

With the exception of a few who want to squash the TDE traitors at all cost, I have no issues whatsoever with the KDE developers, and wish them the best of luck with their modern desktop environment.

On Monday 13 February 2012 10:59:10 Timothy Pearson wrote: I pointed out to two incorrect commits in my very first mail to this mailing list. I have offered several times the help, I have told you that you can ask me any question about KWin. And now you complain that I never explained to you why the commits have broken KWin? Seriously you had enough time to ask, and I had expected that you would ask why it is wrong. Cheers Martin

yes I know they are made on purpose, nevertheless they are wrong. It is quite common that developers not knowing a codebase do things incorrectly. I will now only elaborate on the two commits I outlined. In fact all commits I have seen so far would not pass a review request for KWin and as I mentioned there is at least one commit with the potential to prevent KWin from starting at all. Let's start with 1f40ada: you modify the inline getter for keepAbove. This is not how KWin internally works to have window being as keep above. The proper method to go through is Client::setKeepAbove() which would also tell other interested parties that the window is in fact kept above. This method is quite important to use as it also takes care of putting the window into the correct layer of the stacking order. I think you solved that by hacking the stacking order. The simplest way to achieve what you actually wanted would have been to make your "modal system notification" an override redirect window.

The second commit I pointed out was 9cc1e2c1: I think others already commented in my blog comments why this one is rather bad from a users point of view (introducing new config options without removing the obsoleted ones). But well the main issue from my point of view is that it modified an enum in a public header by not appending to the end, but in the middle. I think you can imagine what happens to 3rd party offerings compiled against the previous version.

On Monday 13 February 2012 23:25:13 Timothy Pearson wrote: This is completely useless and broken patch because all the same functionality already existed in KDE3 (i.e. the shadows). And the newly introduced shadows have less functionality than those existed originally (i.e. they are not displayed when moving a window). I suspect this patch was introduced before the final KDE 3.5.10 was released, when KDE still had no shadow function in kwin.

On Tuesday 14 February 2012 00:07:57 Timothy Pearson wrote: Those shadows in KDE3.5.10 I think, in fact, composited. They work satisfactory for me. The original shadows have an extensive settings dialog in kcontrol and more features than those from Chakra project. For example the shadows can be set to appear or not when resizing and moving windows. Those shadows from Chakra are not displayed when moving windows. The original shadows also can be enabled separately for menus, active and non-active windows, and their size also can be set separately. There is also an option for different shadow color. http://storage3.static.itmages.ru/i/12/0214/h_1329165438_7516085_4b941fd1da… And this is how the shadows look like: http://storage9.static.itmages.ru/i/12/0214/h_1329165743_2170554_d5f80f5a0b…

On Tuesday 14 February 2012 00:52:19 Timothy Pearson wrote: No. These shadows are not those present in TDE. TDE currently uses the shadows introduced by the cited above Chakra patch. The shadows on this screenshot are the original kwin shadows.

While they are original, they are in fact handled by kompmgr. :-) There are also non-composited shadows that originally came with KDE 3.5.10 as well, and those are glitchy.

The checkbox in your screenshot is not very accurate. In TDE it has been changed to read ""Enable the Trinity window composition manager" instead of "Use Translucency/Shadows", and if you dig around in the KDE 3.5.10 code a bit you will see what I mean. kompmgr's shadows (which incidentally are configured using the exact same kcontrol module with the same general options) work almost 100% on the TDE system that I am writing this from...

Attached is a screenshot from TDE 3.5.13, showing the exact same control module that you showed in your screenshot of KDE 3.5.10. There are checkboxes on that page that control shadows being shown on move and resize. It is quite possible that there is a problem with the control module, probably due to the extensive changes to kompmgr in order to stabilize it, but the general code and control modules remain intact from KDE 3.5.10.

OK, I'll buy that. Do you mind filing a bug report so that I can repair this for R14.0?

On Tuesday 14 February 2012 01:40:32 Timothy Pearson wrote: And also it seems there are multiple minor differences in your dialog and mine. Mine shows vertical and horizontal offset sliders, yours - only vertical, mine shows size sliders adjusters, yours only adjuster for the base size and two sliders for multiliers. Even the form of the sliders in the same theme (Plastik) differs. This all suggests that Trinity is based on an older branch of KDE3 than that in openSUSE repository. This may explain why you experience problems with standard KDE3 shadows which work well for me.

Simple fact is, the official KDE 3.5.10 sources have broken shadows when the compositor is turned off. That was the main reason for the commit, which I did in fact test and it did make the shadows work better on my test systems compared to the stock KDE 3.5.10 sources.

> On Tuesday 14 February 2012 02:11:10 Timothy Pearson wrote: > >> Simple fact is, the official KDE 3.5.10 sources have broken shadows >> when >> the compositor is turned off. That was the main reason for the commit, >> which I did in fact test and it did make the shadows work better on my >> test systems compared to the stock KDE 3.5.10 sources. > > Also note the differences in the nodes in the tree. In my case they are > pluses, and in your case they are arrows. > > Since the last version of KDE3 in Debian was KDE 3.5.9, and Trinity is > based on the Debian version with Ubuntu patches, > I suspect that Trinity is based on KDE 3.5.9 release.

Sure, as I mentioned all commits would not pass review, hardly anyone is only close to correct. You are not a window manager developer - that's nothing bad. Hardly anyone is actually developing window managers. It took me more than a year to understand KWin. It is no surprise that you - given the amount of code you have to handle, are not able to properly develop it. Think about that we develop the window manager in a peer reviewed style and hardly any commit just enters the tree. Also we have hundreds of developers testing our code right from the day it enters master, have thousands of beta testers and much much more infrastructure to handle the development of critical code pathes. That's why it would be important to switch to KWin. It would seriously improve the quality for your users and as it has been stated here more than once, that's what you care about :-)

In the case you want them to have window decorations, yes override redirect

On Monday 13 February 2012 15:01:18 Robert Xu wrote: that's quite simple: rm -rf twin, git pull kde-workspace You cannot get twin even close to KWin due to lack of manpower. I have written it before, I say it again: the KWin developer community is larger than the Trinity developer community. In 2011 we had more than 800 commits by 49 individual contributors and fixed ~200 bugs, some of them present since KDE 3. If you want to get a superb window manager get in touch with us to help tailor KWin for your needs. I offered you several times a separate branch were Trinity specific patches could go. Making KWin compile standalone is something I personally would consider as useful. This is way more efficient and useful than trying to develop twin. Our community is small and I find it very sad to see commits done to an outdated fork. Seeing duplicated work by fixing bugs again. Seeing users still getting bugs we have fixed years ago. This makes me really, really sad. Cheers Martin

On Monday 13 February 2012 14:21:19 Timothy Pearson wrote: given your changes to the twin source base I consider this as joke - to be honest. To come here with quality control, while you don't have any for you own. That's a very bad joke and reads to me like "I don't want it and make up an argument that it won't happen". If that is the case: say it than I walk away and let you work for your own. Any Trinity specific changes have of course to be done by Trinity developers. That should be as simple as putting your commits into the branch - the commit won't apply cleanly, but manually that's possible. I cannot do them as I don't know what Trinity needs and I will never ever install Trinity. This is ridiculous. Do you seriously think that we don't take care of ensuring that it does not break on some hardware? Do you think that Trinity will spot severe bugs the KWin team has not found for their millions of users? Are you aware of all the steps we have to ensure that never again a driver will fail KWin? About the fact that we have five different compositing modes? * OpenGL 2 * OpenGL ES 2 * OpenGL 1 * XRender * no compositing That KWin is able to choose the right backend based on the hardware and driver the user is using? That KWin can disable compositing if it notices that things go wrong? yes I have as outlined above. If you want to use KWin use it, but stop the fork and no demands to our development team. We have enough to work without taking care of Trinity development. If I offer you help accept it in the way I offer it, but not by demanding futher things. Cheers Martin

Timothy Pearson wrote: This doesn't really make sense to me. KDE 4 development never broke the existing KDE 3.5 in any way. (It's also silly to say that the KDE developers prevented people from enjoying KDE 3.5 after KDE 4 was released.) If there would be a stable version of kwin4 working well with Trinity in the future, it will always be possible to stick with that version if newer versions would turn out to be problematic. I see no problems in using an upstream project here at all.

Timothy Pearson wrote: Combining efforts with kwin4 would mean that (large parts of) the code will even be tested by more users (both Trinity & KDE 4 users). I fully agree that extra testing is necessary (although this can sometimes even be delegated downstream IMO). Not being afraid to revert changes if they significantly break things or going back to (keeping) a previous revision is important as well. This is basically how Trinity was formed :) KDE 4 took a certain path which was the reason to go back to KDE 3.5 and develop Trinity from there. Any effort to take things from KDE 4 as they evolved and adapt them so they can fit nicely again into Trinity along with obviously many fixes that are also relevant for Trinity seems very admirable. (Especially when initiated or proposed by KDE developers IMO.) Julius

You cannot get twin even close to KWin due to lack of manpower. I have written it before, I say it again: the KWin developer community is larger than the Trinity developer community. In 2011 we had more than 800 commits by 49 individual contributors and fixed ~200 bugs, some of them present since KDE 3.

what exactly do you dislike about KWin 4? What would for you be a reason to not use it? Are you aware that it is exactly the same window manager as twin with just less bugs if you turn off one option? I am not asking you to switch to KDE 4 (which btw does not exist, but that's just a minor detail).

On Monday 13 February 2012 12:54:08 Timothy Pearson wrote: yes I know they are made on purpose, nevertheless they are wrong. It is quite common that developers not knowing a codebase do things incorrectly. I will now only elaborate on the two commits I outlined. In fact all commits I have seen so far would not pass a review request for KWin and as I mentioned there is at least one commit with the potential to prevent KWin from starting at all. Let's start with 1f40ada: you modify the inline getter for keepAbove. This is not how KWin internally works to have window being as keep above. The proper method to go through is Client::setKeepAbove() which would also tell other interested parties that the window is in fact kept above. This method is quite important to use as it also takes care of putting the window into the correct layer of the stacking order. I think you solved that by hacking the stacking order. The simplest way to achieve what you actually wanted would have been to make your "modal system notification" an override redirect window. The second commit I pointed out was 9cc1e2c1: I think others already commented in my blog comments why this one is rather bad from a users point of view (introducing new config options without removing the obsoleted ones). But well the main issue from my point of view is that it modified an enum in a public header by not appending to the end, but in the middle. I think you can imagine what happens to 3rd party offerings compiled against the previous version. Cheers Martin

a) TDE has taken code many of us worked on for years and is taking it in the direction TDE sees fit. Not normally a problem, but in this case TDE often does a less than spectacular job of it. Diminishing someone else's work and doing the long-term users of it a disservice is not great, is it? Yeah, it annoys me when people use my software, which they still refer to as "kicker", with someone else's changes to it which actually make it less stable rather than more, something I worked years on to achieve