...

A hypothetical poll for users here....

If TDE were to close down, which desktop would you use instead? You would be allowed to abandon Linux entirely in this scenario. ;-)

Please state why you have not already switched; i.e. what item are missing or suboptimal in the other environment.

I am curious as to why TDE still exists and need some concrete examples to fall back on to counter detractors.

Thanks!

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

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.

Thank you all for your responses; I think the original blog post that started this whole discussion is now relatively well handled.

Tim

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.

Funny you mention that option. When I wrote my original response I considered writing something similar. I'm at an age when I see and accept my own mortality. As much as I enjoy tinkering with computers I realize my days are numbered and much of what we discuss and argue about here is insignificant in certain ways. That is, simply abandoning computers altogether is an option I won't ignore. :)

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.

Community indeed! In hindsight, the KDE developers could have accomplished a whopping public relations coup had they spent a very serious three months collecting all known patches, significantly resolving open bug reports, and releasing 3.5.11. They then could have informed users that they polished the 3.5 series in a serious way to last several years until they could release a usable 4.x.

They could have (and still can) accomplished another coup by redesigning the three backend technologies to be truly optional.

Darrell

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.

I understand the goal. Possibly even an admirable one. My resistance is people who receive a couple of emails a day (people who manually start and terminate KMail once or twice a day rather than run the app all day), configure only a few RSS feeds that are fetched only every few hours, configure a dozen or so events in KAlarm, and power down every night rather than let the computer run 24/7, don't need or want that kind of backend management. I appreciate how a backend caching service could help share and manipulate data when the user is an information junkie, but not when the user has no such need. For those users Akonadi is a burden rather than an aide.

Of course, geeks and trolls believe that everybody should buy bleeding edge hardware with gobs of RAM and CPU cycles to waste and just STFU.

With that said, possibly some of the PIM apps, such as Akregator, can be built without Akonadi support. Possibly not.

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.

:)

I once tested not installing the Strigi package. KDE4 would not start. Therefore even when disabled as a service, other apps are now dependent upon the Strigi libraries. When I see that kind of design I have a difficult time arguing against those who claim the environment is bloated.

Once again, for the trolls, this type of discussion is not about whether such technologies are useful. They are useful to certain people --- but not all people. These discussions are about the lack of choice --- unless choice is defined as "Use a different desktop environment and STFU." :)

Darrell

On Monday 13 February 2012 12:07:18 am /dev/ammo42 wrote:

On Sun, 12 Feb 2012 20:06:59 -0800 (PST) Darrell Anderson humanreadable@yahoo.com wrote:

...

Of course, geeks and trolls believe that everybody should buy bleeding edge hardware with gobs of RAM and CPU cycles to waste and just STFU.

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.

If the window manager overloads a 2.4ghz dual core CPU with 4GB RAM, I'd say one needs "bleeding edge" to run it ;-) (I can't say anything about post-4.6 releases of KDE, but even with just the panel and two Konqueror windows open, KWin from 4.6 would overload my CPU when I would push Alt+Tab, and it would take several minutes to actually switch the windows; of course, I don't know how well it would perform now on 4.7 or 4.8, I keep hearing it's been improving)

On Monday 13 February 2012 07:23:37 am /dev/ammo42 wrote:

On Mon, 13 Feb 2012 01:10:14 -0500 Kristopher John Gamrat chaotickjg@gmail.com wrote:

...

On Monday 13 February 2012 12:07:18 am /dev/ammo42 wrote:

...

On Sun, 12 Feb 2012 20:06:59 -0800 (PST) Darrell Anderson humanreadable@yahoo.com wrote:

...

Of course, geeks and trolls believe that everybody should buy bleeding edge hardware with gobs of RAM and CPU cycles to waste and just STFU.

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.

If the window manager overloads a 2.4ghz dual core CPU with 4GB RAM, I'd say one needs "bleeding edge" to run it ;-) (I can't say anything about post-4.6 releases of KDE, but even with just the panel and two Konqueror windows open, KWin from 4.6 would overload my CPU when I would push Alt+Tab, and it would take several minutes to actually switch the windows; of course, I don't know how well it would perform now on 4.7 or 4.8, I keep hearing it's been improving)

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.

Mine didn't have the KWin effects on either, I don't care much for any eye-candyish stuff.

<snip>

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

I know that this is sarcasm, but it seemed a good place to jump in to the thread... :-)

One of the major complaints I have against mobile technology is the widgets in use on mobile platforms. As a whole, they tend to be larger and have more limited interactivity due to the assumption that they need to (and in fact can only) be tapped with a finger.

I have attached a screenprint of both Konqueror and Dolphin running at the same time. I want to point out several things that I consider showstoppers, though others may of course consider them nits.

1.) Note the number of toolbars buttons shown on Konqueror and Dolphin both. Now measure the horizontal screen pixels taken by each toolbar and divide by the number of toolbar buttons. Result? Dolphin wastes screen space.

2.) Note the treeview on Konqueror, and how much information about the filesystem is displayed. Note the "equivalent" feature on Dolphin, and how little information is displayed.

3.) Note that Konqueror gives additional graphical information on directory entry rights (via the lock icon) that Dolphin does not.

4.) Note the horribly ugly colors Dolphin uses by default. I know, "it's a default", but the icon set is fairly ugly as well.

I could go on with both functional and asthetic problems shown in KDE4 applications, but I won't. :-) I know that some of the problems were inherited from Qt4 (I am not as stupid as some think; I have in fact used both Qt3 and Qt4, but for vastly different purposes), but KDE chose to use that toolkit and is ultimately responsible for fixing them.

When Dolphin can look and act exactly like Konqueror in that screenshot I will look at KDE4 once again. Until then, sorry, your product is not good enough in the areas that I use.

Tim

On Monday 13 February 2012 11:35:59 Timothy Pearson wrote:

...

<snip>

...

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

I know that this is sarcasm, but it seemed a good place to jump in to the thread... :-)

One of the major complaints I have against mobile technology is the widgets in use on mobile platforms. As a whole, they tend to be larger and have more limited interactivity due to the assumption that they need to (and in fact can only) be tapped with a finger.

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

Actually I do know the differences. :-) And I do see a gradual trend towards using QML-like technology in desktop applications.

I ask you this: If QWidget is so stable (i.e. did not change much between Qt3 and Qt4), why do Qt4/KDE4 applications always use more screen space to display less information? Why do KDE4 applications tend to require more mouse clicks for each operation?

Can you state 100% that the Qt4 developers did not modify widget parameters to be touch friendly? You would have needed to be on the Qt4 development team to be able to state this. :-)

Note that I am not claiming to know for certain the causes of the Qt4 widget bloat. All I do know is that it is present, it can be quantified, and it is very hard to remove.

Tim

On Monday, February 13, 2012 12:04:42 Timothy Pearson wrote:

...

I ask you this: If QWidget is so stable (i.e. did not change much between Qt3 and Qt4), why do Qt4/KDE4 applications always use more screen space to display less information?

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.

...

Why do KDE4 applications tend to require more mouse clicks for each operation?

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

...

Can you state 100% that the Qt4 developers did not modify widget parameters to be touch friendly?

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.

...

You would have needed to be on the Qt4 development team to be able to state this. :-)

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.

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

On Monday 13 February 2012 12:23:22 Timothy Pearson wrote:

...

...

On Monday, February 13, 2012 12:04:42 Timothy Pearson wrote:

...

I ask you this: If QWidget is so stable (i.e. did not change much between Qt3 and Qt4), why do Qt4/KDE4 applications always use more screen

space

...

...

to display less information?

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.

...

Why do KDE4 applications tend to require more mouse clicks for each operation?

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

...

...

Can you state 100% that the Qt4 developers did not modify widget parameters to be touch friendly?

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.

...

You would have needed to be on the Qt4 development team to be able to state this. :-)

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.

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.

in Dolphin it takes one click because media devices are listed in the side bar :-)

OK, I guess it serves me right for picking a directory off the top of my head. How about something without a trivial solution, such as /usr/bin?

I would file bug reports except for this: "few people like that, however, so there are few styles as cramped.". This indicates that KDE would not have much interest in supporting some of the TDE users' requests, making my bug reports a waste of time. Incidentally when I have asked for bug reports against TDE I have not received any either, so I guess this particular thought is present on both sides?

Here is something to consider. You have a skewed sample set, as those who used to use KDE3.5.10 and thought it was nearly perfect probably kept on using it, or jumped to Windows, or started using XFCE, etc. instead of trying each new KDE4 release. Therefore an entire set of users would not be represented in your sample when you make statements such as "few people like that". A much more accurate statement would be "few KDE4 users like that", with which I would agree.

Tim

On 13 February 2012 13:47, /dev/ammo42 mickeytintincolle@yahoo.fr wrote:

On Mon, 13 Feb 2012 12:43:07 -0600 "Timothy Pearson" kb9vqf@pearsoncomputing.net wrote:

...

OK, I guess it serves me right for picking a directory off the top of my head.  How about something without a trivial solution, such as /usr/bin?

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@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@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

This thread has become a shit slinging contest. I don't understand why either groups will waste time arguing. TDE is going to continue regardless who "wins" this discussion.

Calvin

On Monday 13 February 2012 12:52:07 Timothy Pearson wrote:

...

On Mon, 13 Feb 2012 12:43:07 -0600

"Timothy Pearson" kb9vqf@pearsoncomputing.net wrote:

...

OK, I guess it serves me right for picking a directory off the top of my head. How about something without a trivial solution, such as /usr/bin?

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" :)

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.

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.

Cheers Martin

On Monday 13 February 2012 12:52:07 Timothy Pearson wrote:

...

...

On Mon, 13 Feb 2012 12:43:07 -0600

"Timothy Pearson" kb9vqf@pearsoncomputing.net wrote:

...

OK, I guess it serves me right for picking a directory off the top of my head. How about something without a trivial solution, such as /usr/bin?

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" :)

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.

Timothy, please, your sarcasm and rants doesn't help you anything.

No, they probably don't. Frankly, it's not you, it's trying to use KDE4 that makes me frustrated, and then after a little while just plain angry. It's like trying to take away someone's high end tools and replace them with little plastic toys which yes, can be made to work (mostly), but rather than being a delight to use are a constant source of frustration. Rather than working on the computer I feel as if I am fighting with the computer every step of the way. Curiously, that's how I felt when I tried to switch to Linux from Windows before KDE 3.5 was available each and every time. Every time I went out and bought another copy of Windows instead of fighting with that impossible OS (which was usually running Gnome out of the box, so don't take this as a dig against versions of KDE older than v4.0).

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.

Interesting to know. Unlike you I was never able to adapt, and I strongly suspect that you have (subconsciously?) limited yourself in what you can actually do on the computer in a given timeframe, possibly even dumped entire workflows as a result. If you do that in electrical engineering you die; a competitor comes up and trounces all over your company. Period.

How many times do you have to resort to the terminal I wonder? I don't understand how one could give up a panoramic, easy-access view into their filesystem and still remain productive.

Oh well, to each his own. I'm going to take some time and just let the dust settle here.

Tim

On Mon, 13 Feb 2012 12:52:07 -0600 "Timothy Pearson" kb9vqf@pearsoncomputing.net wrote:

...

On Mon, 13 Feb 2012 12:43:07 -0600 "Timothy Pearson" kb9vqf@pearsoncomputing.net wrote:

...

OK, I guess it serves me right for picking a directory off the top of my head. How about something without a trivial solution, such as /usr/bin?

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" :)

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>

You could still type the directory name by typing Ctrl-L Ctrl-U /wherever/you/want Enter. No click needed.

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.

So do I. Actually I find a 80-column terminal easier than any graphical file manager without exception.

Tim

---

To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@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

On Mon, 13 Feb 2012 13:08:21 -0600 "Timothy Pearson" kb9vqf@pearsoncomputing.net wrote:

...

You could still type the directory name by typing Ctrl-L Ctrl-U /wherever/you/want Enter. No click needed.

Hardly intutive, and definitely not discoverable.

And still I did discover it myself without assistance between your message and mine ;) But for me it is "intuitive", or at least already-known shortcuts, as Ctrl-L triggers the location bar on Konqueror and Firefox, and Ctrl-U is the standard UNIX line-erasing sequence.

On Mon, 13 Feb 2012 12:23:22 -0600 "Timothy Pearson" kb9vqf@pearsoncomputing.net wrote:

...

On Monday, February 13, 2012 12:04:42 Timothy Pearson wrote:

...

I ask you this: If QWidget is so stable (i.e. did not change much between Qt3 and Qt4), why do Qt4/KDE4 applications always use more screen space to display less information?

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.

...

Why do KDE4 applications tend to require more mouse clicks for each operation?

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

...

Can you state 100% that the Qt4 developers did not modify widget parameters to be touch friendly?

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.

...

You would have needed to be on the Qt4 development team to be able to state this. :-)

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.

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.

Since it's an USB key it will be in the Places panel ;) Otherwise, there is no need to configure, just click right of the hierarchy which is where the location bar should be. It converts this hierarchy to a real location bar.

KDE4 has serious discoverability issues which are separate from the ease of use issues.

Tim

---

To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@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

On Mon, 13 Feb 2012 12:47:32 -0600 "Timothy Pearson" kb9vqf@pearsoncomputing.net wrote:

...

Since it's an USB key it will be in the Places panel ;) Otherwise, there is no need to configure, just click right of the hierarchy which is where the location bar should be. It converts this hierarchy to a real location bar.

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.

If you put the mouse over this area you will see a blinking bar which looks like the ones from editable text fields; I think it is supposed to suggest the trick. Still not obvious, but I didn't have to use a search engine to discover it. BTW, I don't use Dolphin regularly since I do most of my file management with bash/coreutils/etc.

Tim

---

To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@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

On Mon, 13 Feb 2012 12:57:16 -0600 "Timothy Pearson" kb9vqf@pearsoncomputing.net wrote:

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

When I wasn't already used to bash for file management I did use GNOME 1.4 and IceWM so I think the response is no ;)

Am Montag, 13. Februar 2012 schrieb /dev/ammo42:

On Sun, 12 Feb 2012 11:24:11 -0800 (PST)

Darrell Anderson humanreadable@yahoo.com wrote:

...

They could have (and still can) accomplished another coup by redesigning the three backend technologies to be truly optional.

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.

Akonadi is a patch for a major design flaw of KDE4, that by itself breaks KISS. E.g. how can I access a "akonadi DB" from commandline?

Nik

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

I'm glad to hear that! I have learned so much by participating in this project. One such skill is learning a thing or two about compiling packages. Another is spotting bugs. I am learning C++ and can submit minor patches. If R14 was the last of Trinity I would be able to obtain a few years life out of that environment. By then I'm sure the horizon will have changed with respect to other options. Yet my first choice is to see Trinity grow. :)

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).

Thank you. I want to emphasize again, for the trolls and those who have not read my previous response, I have no hatred for KDE4 or other desktop environments. The simple fact is those other environments do not satisfy my style of desktop computer usage. I wish advocates of those other desktops would accept that simple reality.

Yes, I'm not shy about expressing my opinion that those environments do not satisfy my style of desktop computer usage. But a difference of opinion and preferences should never be construed as hatred.

Second, there is nothing wrong with the concept of forking. Humans have been forking ideas and communities since the beginning of civilization. Forking is a natural way for humans to grow, mature, and evolve. Forking is very much an essential ingredient to improving how we exist.

Third, I would be far more open to using KDE4 if the KDE4 developers would address the three triplets of Akonadi, Nepomuk, and Strigi. Mere disabling the latter two is insufficient. End-users should be able not to install those packages without KDE4 failing to start or run. The problem with Akonadi is deeper but unless the developers provide end users the option to use or not use that backend, then I don't see KDE4 in my near future. The developers need to accept the reality that regardless of their skilled opinions about those three technologies --- and yes, the KDE4 developers are indeed a skilled bunch --- that a significant number of people do not want and do not need those technologies.

For a simple analogy, I admire the technology and luxury behind a Mercedes Benz, but I neither need nor want such a car. My pickup truck is far more suitable for my lifestyle and my needs and wants.

This observation about those three technologies is what these conversations are about. When developers do not provide users the options to use or not use certain backend technologies then they are acting no different from the proprietary commercial developers so many of us despise. Often I have said that if the Microsoft people had polished NT4 that NT4 would have been a killer desktop environment for running other apps. NT4 was the last of the Microsoft desktops that was benign and non intrusive. Instead those people pushed and rammed W2K/XP down the users' throats and decided they wanted to own the user rather than focus on delivering the best operating system possible. The end result was a lot of hatred and contempt for the Microsoft way of doing things.

The KDE4 (and GNOME and Ubuntu) developers seem to be thinking in a similar pattern --- "our way or the highway." Or, "you're stupid, we're not, so just STFU." In the end I respect their decisions but I'm saddened by such attitudes. The developers have every standing to scratch their own itch. They have standing to ignore what other people want outside their own social circle. If they go down that path then they have to realize they need to be honest with users that they have chosen that policy. If end users really are part of their goals and philosophy then do something about those three backend technologies.

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.

Thank you for that explanation. I never was sure. I did not understand the significant style differences between KDE4 and KDE3. Your explanation about "cell phone" influence makes sense and identifies why certain things in Qt4 seem difficult to accomplish. I hope we maintain (T)Qt3 for as long as possible because the (T)Qt3 widget set much better satisfies the desktop style of computing than Qt4.

I want to clarify another point. Both here and in previous threads I have emphasized the phrase desktop usage. I have not closed the doors to how KDE4, GNOME, Unity, etc., perform or look with other environments, such as hand-held devices.

Darrell

@Aaron, I used KDE 4 from beta up to 4.6. I can't say anything about 4.7 or 4.8, but from what I've seen, KDE 4 was very unstable, and it was such a sudden and huge change that even now, when people tell me, "Oh, it's improving now," I can't get myself to go back. It would be one thing if all the changes were more gradual, but such a sudden change is a good way to drive away existing users and will give way to projects like TDE. If KDE 4's stability is actually improving, you might attract new users, or existing users who liked the changes (from what I personally have seen, not many existing users do like the changes, regardless of stability).

From our perspective (or at least from my own), the sudden changes and instability make it seem as though the KDE 4 devs don't care about the users anymore. However, since I'm not a KDE 4 dev, I can't say whether or not my "KDE devs don't care" view is true. It could very well be that they do care. But it certainly would have made sense to delay the 4.0 release, regardless of what changes took place. In fact, when making such immense changes, a release date isn't a good idea until the devs know for sure that they can make a stable release.

I personally have not been as satisfied with TDE as I was with KDE 3.5.10, new glitches have popped up that I don't remember being there. I haven't noticed any issues with Kicker, though. The issues I have noticed are already in the bug tracker, and there seems to be a concensus that a more stringent QA cycle is needed, hence why I am still with TDE: I am willing to sit it out, and see if things improve, and I am certainly not the impatient type when it comes to projects run by a small dev team.

So now that you know the perspective of one lone user, perhaps you can try to understand that perspective and the perspectives of the others posting to this thread?

On Monday 13 February 2012 01:13:11 pm Aaron J. Seigo wrote:

On Monday, February 13, 2012 12:12:10 Kristopher John Gamrat wrote:

...

So now that you know the perspective of one lone user, perhaps you can try to understand that perspective and the perspectives of the others posting to this thread?

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.

I'm sorry if my brain isn't functioning today, apparently it hasn't functioned in awhile, because I have had the viewpoint that I stated for awhile (and I also make a point of trying not to attack KDE 4 despite my strong disliking for it, and I always make a point of stating my opinions for it as mine instead of that of the TDE team or anybody else); I have yet to see, after all this time, how I am coupling ignorance with negativity, nor how my viewpoint is destructive. Perhaps from a developer's standpoint, I am ignorant, but not from a user's standpoint. Perhaps my statements (both now and in the past) might have come off as negative, but they are just my own opinions, and if stating my opinions and telling people that they are my own opinions is being destructive, then perhaps I should be banned from the mailing lists. However, I doubt that will happen since I am not actually being destructive, and I am not purposely interpreting other people's statements is hurtful or destructive. I interpret messages on this mailing list as they are written. I interpret the software I use as they operate on a system I know is running smoothly. I choose to interpret the older versions of KDE 4 that I have used as being poorly designed and poorly designed. I happen to agree with some of the other statements in regards to it being the job of the developers to fix bugs, regardless of which toolkit they use. Yes, I understand Qt4 might have flaws, but in my mind, that is not an excuse to allow bugs to run rampant, nor is it an excuse to make things harder on users. I have shown both a vanilla KDE 3.5.10 install and vanilla KDE 4.5.x install to some friends who have never used Linux (or any other UNIX-based OS), they did have some good things to say about KDE 4, but the number of complaints were far greater. KDE 3 was chosen every time but one, who didn't have any complaints about KDE 3, but he said he just likes KDE 4 better (though I think he used a newer version on KUbuntu). Good for him. Though those of us who have had to watch KDE 4 develop (and choose not to use it) and who have witnessed the newbies using it see KDE 4 as not being user-oriented based solely on the reasons being stated on this thread.

I'm sorry, but I must say: you are the one being destructive by starting an argument and continuing to argue. Perhaps we are being equally destructive by continuing to argue with you, but we are not being destructive simply by stating our opinions and viewpoints.

On Monday 13 February 2012 12:20:36 Calvin Morrison wrote:

On 13 February 2012 05:56, Aaron J. Seigo aseigo@kde.org wrote:

...

On Saturday, February 11, 2012 23:42:31 Timothy Pearson wrote:

...

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).

<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.

* Release date 4.0: 11.01.2008 * Relase date 4.1: 29.07.2008 * Release date 3.5.10: 26.08.2008

Nobody was forced to update. This was in most cases the result of distributions. E.g Kubuntu shipped alongside KDE 3.5.9 and 4.0 in their 8.04 release. Debian continued to support 3.5 till just a month ago. The only distribution I am aware of switching instantly to 4.0 was Fedora. Yes I agree with everyone that they should have known better :-) It is unfortunate that the things happened the way they happened, but we are now four years into the 4.x series and it just doesn't matter any more how bumby the 4.0 ride was. It's btw a very good way to annoy KDE developers (especially those who joined after 4.0).

Cheers Martin

On Mon February 13 2012 02:56:26 Aaron J. Seigo wrote:

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

Aaron,

You did good work with KDE 3.5. We used your good work and we liked it. We found it efficient and friendly and intuitive and powerful and productive.

We could do our own good works using KDE 3.5.

And then you threw it all away. You cared not one jot for your existing users. I have tried KDE 4 many times and I don't like it and I cannot be as productive with it. I hear you picked up new users who like such things. I hope you'll be happy together.

Tim and his team picked up your discard and renovated it and we are extremely grateful to them.

We can continue doing own our good works using TDE.

--Mike Bird

On Mon February 13 2012 10:30:30 Aaron J. Seigo wrote:

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

The evidence, Aaron, is the early KDE 4.n releases. They were horrible in EVERY way and they were pushed down users throats.

Recent KDE 4.n are incremental improvements but KDE 4 is a different product than KDE 3.5. It is aimed at different users who work in different ways. I actually don't know anyone who claims to be productive in KDE 4 but I believe reports that such users exist.

You've lost the KDE 3.5 users. Go enjoy your new users. Go enjoy your life. We are very much enjoying TDE.

--Mike Bird

Hi Darrell,

I'm not going to address the technical content of your email, much of which I disagree with from a purely factual perspective, because I do not believe it is possible to make progress on technical topics when there is a wall of denial and negativity in the way. So I will instead focus on one specific thing you wrote which really tells the whole tale as to why it is currently infeasible to make progress on these matters:

On Saturday, February 11, 2012 19:57:44 Darrell Anderson wrote:

The KDE4 developers do what they want.

We do what we understand to be best given our resources, the requirements of today's applications and users and based on feedback from those who use KDE software. We come to these conclusions after a lot of research and testing. Ultimately, yes, we choose what to do and we don't always get the best answer on the first try, but the processes we engage in is a very different thing from simply doing "what we want".

So let me now quote slightly out of order:

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

What you are asking for is for me, and the rest of the team, to *lie* so as to fit *your* desired worldview. What nonesense. The reality doesn't fit your expectations (you think we're selfishly "doing it for ourselves", we maintain and demonstrate that we aren't) and so instead of modifying your worldview you want the world to stand on its head and match your flawed perspective. Perhaps you should simlpy adjust your conclusion and accept that we are writing software for others, but that the results of that process (for whatever set of reasons) are not what you wanted. Would that be so hard?

We don't bother anybody.

You need to go back and read the last set of release announcements for TDE or any of the numerous comments written on public blogs and web forums by TDE users, who quite obviously draw conviction and encouragement to do such things by the leadership and core group around TDE who express the exact combination of negativity and ignorance we see expressed time and again. Examining the reality shows that your statement is utterly untrue.

Perhaps you don't percieve TDE as "bothering anybody", and I accept that as a real possibility: it seems more likely than you being delusional or intentionally lieing. Maybe it will be an eye-opener to step back and consider just how you and the other TDE people come across in public. To say TDE, both its development team as well as its user base, has "bothered" people is akin to saying that Mount Everest is slightly high.

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

Ignoring the hypocracy in your question, I'll give you a straight answer:

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, and then have the balls to suggest that "TDE is improving things". Normally, this point on its own would be, while unfortunate, ignorable, however:

b) When a developer does come here and asks to unfork one component (kwin, e.g.) for everyone's benefit, the response is pathetic and juvenile, not the sort of thing I expect from mature software developers.

c) TDE and the people around it have repeatedly made public statements about the state of KDE software. Some of it has appeared in headlines on Slashdot as part of a TDE release announcement, to name one example. To expect no response to be made to such public assertions is to live in a fantasy world.

The way to get along with each other starts by those who brought the negativity in the first place to find peace within themselves and start behaving accordingly. The problems TDE reaps are the problems TDE sows.

Stop pretending to be a victim and start behaving like people who are trying to take control of your own positive destiny by developing technology you love.

On Monday 13 February 2012 11:23:29 Calvin Morrison wrote:

...

b) When a developer does come here and asks to unfork one component (kwin, e.g.) for everyone's benefit, the response is pathetic and juvenile, not the sort of thing I expect from mature software developers.

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

Please remember that I am not a native speaker. It is not my intend to be arrogant, though I know that what I write is often considered as being arrogant. This is an unfortunate situation as I am an expert in the area I'm working in (window management) while the people I address are no experts. In such situations it can happen that something sounds arrogant if language barriers are involved. I am sorry that you considered some of my comments as arrogant, this has not been my intention.

Concerning the demeaning of your group: well, I have nothing to say to it. If you consider it this way, it might be an idea to think about what Trinity could do to no longer come into situations that pointing out problems is demeaning your efforts.

I have never made things up. I pointed out real issues, like the one that twin does not start any more under certain circumstances. It's in my opinion a very severe issue which has to be pointed out.

Personally I'm always interested in extending my knowledge. I always seek for the advice of people more knowledged than I am and I accept their criticism of e.g. my code no matter how tough that may be.

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.

yes, I consider it as quite bad that such a thread has been started due to my blog post. I think it is not the best way to react to the problems I pointed out in my blog post. I would have expected that you start to reflect what I wrote, to think about whether there might be some truth, to think about whether the way Trinity took is the right one.

Trying to find reasons why everything is perfect the way it is, does not improve anything. Asking on the Trinity developer list who will continue to use Trinity does not help you. Of course everybody here loves Trinity and would never use something different. Such a thread is flawed, the conclusions you can derive from it are flawed.

One very good way to react to such criticism is not to react instantly. Take your time. Reacting instantly makes things mostly just worst. Of course everybody was angry when they read my post - I would have felt the same. But reacting in anger does not help you. Give it a few days and then start to think what of the things I wrote is right, were things can be improved. Think about why I reply to these threads on Monday and did not do on Saturday :-)

Just to let you know: I did not write the post and publish it. It took me about two weeks from the day when I decided to write the post till I sat down and typed. I did not publish instantly, but kept it one more day to think over it again, to make sure that nothing gets into the post, what I don't want to write.

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

Google tells me I have only written two posts. One I have written in the light of very bad publicity thrown on KWin due to the Trinity release. Unreasonable and incorrect crap. The second post is the one from Saturday.

Additionally I have written a German article for freiesMagazin to illustrate the history of Trinity (how the fork happened) and what users can and cannot expect from Trinity. This was a very objective article as I have written it for a magazine and they would not have accepted a non objective one.

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.

In my first blog post I only criticise that you are forking everything - for example KWin. Getting here to undo the fork does not sound like double standard to me but is completely in line with what I would like to see for Trinity. May I quote my own post:

"I appreciate the idea of the Trinity developers to bring back the KDE 3.5 desktop experience to those users who really want it. This is a great offer."

Obviously I don't expect that you would start to use KWin any more. I was quite aware about that when I wrote the post although I had been contacted by one of the Trinity people last weeks to get the KWin thing started. Before anyone thinks this is "revenge" because you were not in favor of switching to Trinity: that is of course not the case.

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

I rather doubt that.

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.

This is one of the things I seriously see as a problem. Why should a user who wants to use kdesktop/kicker be forced to use twin? Why should a user be forced to use tate (assuming you did a s/k/t/g for all KDE applications) even if there are much better applications around? Why should a user be forced to use the legacy HAL and Qt 3? The technology choices by Trinity are seriously flawed as I illustrated in my blog post.

Please see my post as an opportunity to improve Trinity. Once again: if you have any questions, I am willing to help you. I am interested in having a "classic" desktop provided alongside our primary offerings. I would have never contacted you if I would not have been interested in Trinity.

Kind Regards Martin

On Monday, February 13, 2012 10:59:10 Timothy Pearson wrote:

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".

please read your email in response to Darrell Anderson. read his email too. note the ignorance (as in: both of you lack knowledge of what you speak) in both emails coupled with the overt negativity ..

remember, Timothy, your response was: "Very well said Darrell." after which you made a number of false statements about Qt4, widgets and style defaults in KDE 4.

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.

you are in denial.

go back and look at TDE's last release announcement communication.

try to find a similar posting to slashdot or any other public news site about TDE from KDE as we have seen already from TDE.

look through the threads on this list and all the rubbish thrown around about KDE. your email about styles and "point and click interaction in widgets" is a fun romp rife with ignorance; though when compared to emails asserting people might be being paid off by Microsoft to destroy KDE, it's a relatively harmless example.

then go and try to find a similar thread on a KDE list.

the icing on this case is that when you get the all-to-easy-to-predict negative response you then play the victim? please.

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

that's fine. but somehow TDE users also don't know how to hold an opinion that's different from others without obnoxious about it, nor do they seem to be held back by ignorance when deciding to make a statement.

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.

if you want to talk about politeness, TDE needs to learn how to manage this. i waved an olive branch quite a while ago in response to utterly *vile* communication around a TDE release. there was no reason to do this, only reasonability and the hope that we could reach a polite and adult level of interaction. TDE's community seems incapable of it.

btw, who is trying to change the visible elements in TDE?

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.

adding the ability to _use_ kwin4 misses the entire point of what Martin was outlining.

and his "TDE bashing spree" was one blog in which he spent most of his time pointing to emails written by the TDE community and noting _evidence_ showing how the current approach to maintain the 3.5 code base was running into problems.

had the TDE community treated people, including Martin, with respect and politely declined in this case for whatever reason, i'm sure none of this would be happening. but no, you have this need as a group to fling poo at people.

you (the TDE community) have an attitude problem coupled with a penchance for speaking without having done the research. fix that, and you'll find your desired politeness following.

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.

having read his blog entry, i got the answers to that. why didn't you?

I would hate to see you go;

and yet you've managed to make it happen. something to consider.

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.

yet that is not reflected in the actions and words of people involved with TDE. it's not even reflected in the tone of your own writing in other emails. so you can write this as many times over as you want, it isn't going to improve anything.

On Monday 13 February 2012 10:59:10 Timothy Pearson wrote:

...

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 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

Care to elaborate? I am willing to listen. Your original message was disregarded to some extent as you linked to changes that were made on purpose, and I usually expect people who claim something is wrong to make an attempt at stating *why( they think said something is wrong.

Tim

...

Care to elaborate? I am willing to listen. Your original message was disregarded to some extent as you linked to changes that were made on purpose, and I usually expect people who claim something is wrong to make an attempt at stating *why( they think said something is wrong.

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.

This would have caused the modal system notifications to lose their window handles/decorations and drag/resize abilities, unless I have been reading the FreeDesktop WM specifications incorrectly. Example: http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2528706

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.

We are not too concerned about ABI compatibility here, but since the requested change is so trivial I suppose I can push it through.

Anything else?

Tim

On Monday 13 February 2012 23:25:13 Timothy Pearson wrote:

...

...

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.

We are not too concerned about ABI compatibility here, but since the requested change is so trivial I suppose I can push it through.

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.

I do agree that if shadow code has been duplicated, the broken code should be removed. I seem to remember KDE 3.5.10 having badly broken shadows, though at this distance I could be mistaken.

Actually, with all the repairs I made to kompmgr, and given the inherent bugginess of the non-composited kwin shadow code, I'd like to see the non-composited shadows removed altogether. Non-composited fading has a similar problem IIRC, although I have not tested it as I run kompmgr exclusively on my systems.

Tim

On Tuesday 14 February 2012 00:07:57 Timothy Pearson wrote:

...

...

I suspect this patch was introduced before the final KDE 3.5.10 was released, when KDE still had no shadow function in kwin.

I do agree that if shadow code has been duplicated, the broken code should be removed. I seem to remember KDE 3.5.10 having badly broken shadows, though at this distance I could be mistaken.

Actually, with all the repairs I made to kompmgr, and given the inherent bugginess of the non-composited kwin shadow code, I'd like to see the non-composited shadows removed altogether. Non-composited fading has a similar problem IIRC, although I have not tested it as I run kompmgr exclusively on my systems.

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....

Yep, those are the kompmgr composited shadows, which are present in TDE and are the ones I want to keep. The other shadows in question are not composited and are very glitchy as a result.

Tim

On Tuesday 14 February 2012 00:52:19 Timothy Pearson wrote:

...

...

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....

Yep, those are the kompmgr composited shadows, which are present in TDE and are the ones I want to keep. The other shadows in question are not composited and are very glitchy as a result.

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...

Does this make things a bit clearer?

Tim

On Tuesday 14 February 2012 01:00:59 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.

This is screenshot from KDE3, not from Trinity, and it shows the only shadows that present in the original KDE3.

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...

Your shadows in Trinity are not shown when resizing and moving windows.

On Tuesday 14 February 2012 01:40:32 Timothy Pearson wrote:

...

This is screenshot from KDE3, not from Trinity, and it shows the only shadows that present in the original KDE3.

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. This control module in Trinity is non-functional and does not affect anything. It has been broken by the criticized patch from Chakra.

On Tuesday 14 February 2012 01:54:51 Timothy Pearson wrote:

...

...

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. This control module in Trinity is non-functional and does not affect anything. It has been broken by the criticized patch from Chakra.

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

I usually test the patches before applying them. I tested this patch and found that it breaks the system and does not introduce anything valuable instead.

I suggest you to employ a similar practice, i.e. not applying the patches without testing.

In this case the easiest way is to revert this patch http://paste.kde.org/408152/ .

On Tuesday 14 February 2012 01:40:32 Timothy Pearson wrote:

...

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.

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.

Not sure how you could have gotten a "later branch" than 3.5.10, unless you included distro-specific patches that have not yet made their way into TDE. If so, I'd like to merge them into TDE.

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.

At this point reverting the patch would reintroduce those problems, unless I can then turn around and apply whatever changes were made to the version that works properly for you....

As I said, a bug report is needed! :-)

Tim

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.

...

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.

Nope. It's based on a 3.5.10 release, and was never created from a Debian release. :-) Please check facts (e.g. via the GIT commit logs) before stating things like this.

Tim

On Mon, Feb 13, 2012 at 14:53, Martin Gräßlin mgraesslin@kde.org wrote:

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 :-)

Martin, please hear my request:

Instead of telling us how great KDE's infrastructure and community is compared to ours, please give us information that can further our development, such as bugs and code snippets. For instance, you have not told us how our code can move in the direction that could possibly bring us into compat with KWin.

For example:

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

does not work.

is a good one because it clearly points out a flaw that can be fixed.

On Monday 13 February 2012 15:01:18 Robert Xu wrote:

...

On Mon, Feb 13, 2012 at 14:53, Martin Gräßlin mgraesslin@kde.org wrote:

...

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 :-)

Martin, please hear my request:

Instead of telling us how great KDE's infrastructure and community is compared to ours, please give us information that can further our development, such as bugs and code snippets. For instance, you have not told us how our code can move in the direction that could possibly bring us into compat with KWin.

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

I outlined the steps to replace twin many, many times. I need to be sure that nothing will break, and that means that for now twin has to stick around. I will need to see support for some of the twin-specific features (i.e. decorated modal system dialogs), and will leave it up to you to handle the specific implementation under kwin4 if you wish.

I am already doing what I can to make TDE coexist with Qt4, which will in turn open up the possibility of embedding KDE4 kcontrol modules in TDE's Control Center.

Basically, if people could just stay civil and learn to work together (that means being *patient* as well) TDE and KDE4 could actually start to integrate chunks of each other's code to, as stated, reduce the duplication of effort.

However, twin will NEVER be completely deleted. Why? I don't like relying on an upstream project (KDE) that has a history of seriously breaking things in new releases (history is history and cannot be changed). We need something to fall back on if kwin turns out to have serious problems (e.g. on certain graphics hardware), even if twin's codebase is never touched again.

Does this make sense? Do you fundamentally disagree with some part of it?

Tim

On Monday 13 February 2012 14:21:19 Timothy Pearson wrote:

...

...

On Monday 13 February 2012 15:01:18 Robert Xu wrote:

...

On Mon, Feb 13, 2012 at 14:53, Martin Gräßlin

mgraesslin@kde.org

...

...

wrote:

...

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 :-)

Martin, please hear my request:

Instead of telling us how great KDE's infrastructure and community is compared to ours, please give us information that can further our development, such as bugs and code snippets. For instance, you have not told us how our code can move in the direction that could

possibly

...

...

bring us into compat with KWin.

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

I outlined the steps to replace twin many, many times. I need to be sure that nothing will break, and that means that for now twin has to stick around. I will need to see support for some of the twin-specific features (i.e. decorated modal system dialogs), and will leave it up to you to handle the specific implementation under kwin4 if you wish.

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.

...

However, twin will NEVER be completely deleted. Why? I don't like relying on an upstream project (KDE) that has a history of seriously breaking things in new releases (history is history and cannot be changed). We need something to fall back on if kwin turns out to have serious problems (e.g. on certain graphics hardware), even if twin's codebase is never touched again.

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?

...

Does this make sense? Do you fundamentally disagree with some part of it?

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

OK, then stop demanding that we replace twin this instant. It goes both ways! :-)

I don't want to hear any further discussion on this topic. You clearly do not have a desire to support TDE in the long run, so we will explore kwin as we have time to do so. In the meantime, I will state emphatically that twin is nowhere near as broken as you would like to claim, and any serious breakage will be reported to the TDE bugtracker and fixed like it always has been for the duration of this project.

FOSS is about choice; I have done my part to give users choice as to which WM to use, and right now given your attitude I would rather replace twin with Compiz if I had to rather than to use or rely on kwin.

Tim

Timothy Pearson wrote:

...

However, twin will NEVER be completely deleted. Why? I don't like relying on an upstream project (KDE) that has a history of seriously breaking things in new releases (history is history and cannot be changed). We need something to fall back on if kwin turns out to have serious problems (e.g. on certain graphics hardware), even if twin's codebase is never touched again.

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.

I guess if we kept a known working copy of kwin and only imported from upstream after stability testing then it would be viable to delete twin.

I am not the be all and end all of TDE knowledge. If I am not making sense please correct me! :-)

Tim

Timothy Pearson wrote:

...

...

Timothy Pearson wrote:

...

However, twin will NEVER be completely deleted. Why? I don't like relying on an upstream project (KDE) that has a history of seriously breaking things in new releases (history is history and cannot be changed). We need something to fall back on if kwin turns out to have serious problems (e.g. on certain graphics hardware), even if twin's codebase is never touched again.

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.

I guess if we kept a known working copy of kwin and only imported from upstream after stability testing then it would be viable to delete twin.

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

Yes, and in principle I have always agreed with this. However Martin does not agree with the testing first and reverting if needed parts. :-)

Tim

On Mon February 13 2012 12:13:47 Martin Gräßlin wrote:

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.

Rapid movement in the wrong direction is not progress.

TDE is where we want to be. For us TDE works better than KDE 4.

You're free to enjoy KDE 4 if that's your cup of tea.

--Mike Bird

On Mon February 13 2012 12:37:32 Martin Gräßlin wrote:

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).

If you make your KWIN4 available as a Debian Squeeze-compatible package in a working repository, as Tim has done with TWIN, and make sure that cross-grades from KWIN4 to TWIN work in both directions and without requiring a vast horde of KDE4 libraries, I'll try it. OK?

--Mike Bird

On Mon, Feb 13, 2012 at 2:16 PM, Martin Gräßlin mgraesslin@kde.org wrote:

On Monday 13 February 2012 12:54:08 Timothy Pearson wrote:

...

...

On Monday 13 February 2012 10:59:10 Timothy Pearson wrote:

...

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 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

Care to elaborate?  I am willing to listen.  Your original message was disregarded to some extent as you linked to changes that were made on purpose, and I usually expect people who claim something is wrong to make an attempt at stating *why( they think said something is wrong.

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

Let me see if I have this right....

Martin said publicly on his blog that we are "Haters", that we are outdated, and that we are wasting our time.

Now why someone who obviously detest us and what we are doing, come to our site and try to help us with coding problems?

Maybe it is because his article did not cause us to rant and rave enough to give him ammunition for more hate mongering on his blog? So maybe he came here and implied that we are incompetent and don't know what we are doing--hoping that will anger us enough to where we will say or do something stupid--so he can use it against us?

Was he one of the original programmers for KDE 3 and one of the ones who never bothered to fix any of its bugs? If so, maybe why he is so upset with us is because we are trying to fix something he didn't, for whatever reason?

Personally I think the worst thing we could do to someone with an ego the size of his, is to totally ignore him.

Keith

On Monday 13 February 2012 14:51:40 Aaron J. Seigo wrote:

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

Are you sure?

This is http://websvn.kde.org/?view=revision&revision=406411 your commit after which the buttons on the taskbar in KDE 3.4 ceased to be visually pushed, when using the Classic mode.

The key line in file kicker/taskbar/taskcontainer.cpp before:

Code: Select all style().drawPrimitive(QStyle::PE_HeaderSection, p, QRect(0, 0, width(), height()), colors, sunken ? QStyle::Style_Down : QStyle::Style_Raised);

after:

Code: Select all style().drawPrimitive(QStyle::PE_HeaderSection, p, QRect(0, 0, width(), height()), colors)

After reverting this change and restoring the removed parameter to the function the taskbar works well again.

I also have KDE2's installed on my system and I find it both more stable and visually appealing than that of KDE3. For instance one of the changes in KDE3 was using table caption widgets for the taskbar instead of the provided with Qt special widgets for the taskbar. The KDE3's kicker is more simply looking, has no visual zooming when hovering over quick launch items, and the buttons (including K-button) do not respect the Qt style. It also has a serious bug with K-menu positioning with some icon and Qt themes.

Is that all improvement over KDE2? As I know you did not work on the KDE2's kicker.