On 5 February 2012 04:57, Martin Gräßlin <mgraesslin(a)kde.org> wrote: Sorry it was indeed 4.8. Which is quite nice by the way :) looking through KDE4 was just as much of a pain as Trinity. In comparison XFCE and GNOME offer less configuration so I had less of an issue there. Well said. Calvin Morrison

This Email was not supposed to go to the public list; I misclicked and off it went. Please realise that no disrespect was intended; as I have stated before KDE4 is good for a certain group of users, as are Gnome, TDE, XFCE, and all the other desktop environments. In context between the TDE devs, what the previous comment means is that we do need to make TDE better than those other desktop options ***for our specific userbase***. In that sense we ***are*** in competition with all other desktop environments (including non-Linux systems like Windows) for the userbase desiring the feature set that TDE (partially) provides. Even compared to KDE4.8, Windows would still be a more attractive option for me if TDE did not exist. Others feel the same way as noted in our last meeting. There is a small Linux userbase out there that does not buy into the latest desktop "fashions", and unless a stable and full=featured desktop is provided for them we will lose them permanently to Windows. I hope this clarifies some things. Timothy Pearson Trinity Desktop Project

It isn't so much what you are forced to use. I don't have time or the desire to pick through KDE4 at the moment but KDE4 is still less efficient for my workflows then TDE, period. It takes more space on the screen to display less information in a harder-to-digest format for starters. Then there is the whole assumption that people have low-resolution or small screens and one-button mice (in TDE all three mouse buttons can be used to interact with on screen elements--much of that power is just gone in KDE4). As I said I don't have time to play with KDE4, and all of my prior attempts to use KDE4 as anything other than a shiny toy failed miserably. Please remember that there is a bit of a frog-in-the-pot syndrome when users are forced to use an inefficient interface for long periods of time; the best way to break this is to go back and use Windows XP or KDE 3.5 for a day or two, then go back to KDE4. If KDE4 is truly better then that will be obvious; if it is not then this fact will also be obvious. (I have done this and KDE4 still looks like a shiny toy). I don't want to start a war so I won't say anything else. :-) These are just my opinions, and may not be the TDE project's opinions. Tim

Sure, I can do that. :) Odd that you should exclude KMail and Akonadi, which pretty much pins the tail on the donkey. I have tried KDE4. I have KDE4 installed in virtual machines. I am not naive about KDE4. I have a lengthy writeup at my web site, written a while ago with 4.5.5, based on my experience as a non KDE4 user learning to use KDE4. Before people rush to nit pick everything "wrong" and "short-sighted" with my journal entries, I can say with hindsight that I have learned a few things since that writeup and KDE4 has continued to mature --- but the writeup is legitimate for that moment in time based upon my experience at that time. Yes, I dislike the way various configuration options function, such as customizing the panel, folder versus desktop views, etc. Yes, there is a method that, once learned, more or less works. More or less. That does not mean because I learned the KDE4 way of doing things that I like what I see. Yet learning the KDE4 way of doing things does not excuse the way Nepomuk, Strigi, and Akonadi are now being embedded into the system, which are examples of the "latest desktop fashion" that is required to use KDE4. These three services reminds me much of the way Internet Explorer is embedded into Windows starting with Service Pack 2 or 3 of Windows 2000. Previous to that Internet Explorer could be removed with impunity and I did so regularly. Not so thereafter. The basic Nepomuk and Strigi services can be disabled from running, but they can't be removed completely because developers use libraries from those packages. That is, developers are building their apps with those dependencies. I tried removing them. Things start breaking when those packages are not installed. To me that is poor design. I see places where semantic desktop services like Nepomuk could provide benefits, such as enterprise environments or virtual offices. I am curious to read how others might be using that backend to coordinate work flows --- although I have yet to read detailed examples how people are sharing in that manner. To me the semantic desktop remains a concept that has yet to prove its viability. Possibly in five years developers and users might have this figured out. Yet I recognize that such services provide no benefit to many home or single workstation users --- so why should they be forced to install such packages? Akonadi is a "latest desktop fashion" example that cannot be disabled. Starting any PIM app starts the Akonadi service. Although I see some users benefiting from this caching service, I also see that many never will and they are stuck. For example, I am not an email glutton. A few emails a day, even when I'm contracting off site. I don't run KOrganizer and KAlarm is sufficient for some basic reminders. I use Akregator but subscribe only to a few feeds. I'm not an information junkie. I also do not have or need a huge address book. I'm not that kind of user. I don't need (or want) that kind of information overload. I don't need to waste RAM running a cache like that because there is nothing to cache. At release 4.8, I am still reading complaints from people using KMail. That is disheartening. Eight point releases and how many minor releases in between and a key PIM app is broken? Because I use KMail, I am not migrating to KDE4 when I know I am likely to experience breakage. I could choose not to use KDE4 PIM apps, but I'm not interested in migrating to GTK PIM apps. Why bother with an integrated desktop environment when I am going to start mixing apps and widget libraries? I might as well use a basic window manager and have a full menagerie of apps. If the developers had let the user decide whether or not to install those three backend services, I likely would be using KDE4 right now. I have been around computers a long time, longer than many people participating in this list have been alive. I recognized that the early push --- not by the KDE4 developers but by distro maintainers --- to include the early KDE4 releases as standard fare rather than in a testing branch, would be short-lived and eventually KDE4 would mature. I blame the distro maintainers with their unrealistic and insane bleeding edge mentality for those early perceptions about KDE4. Because of my anticipations toward that eventual maturity, some time after the 4.2.x series was introduced I considered moving to KDE4 --- eventually --- until I read that removing Akonadi was not an option. My own testing showed that to be true. I could not start simple apps like KAlarm or Akregator without starting the Akonadi backend service. When I discovered that removing the Strigi package started to break things, I frowned some more. Recently I read an online forum discussion about a user trying to build a non mainstream KDE4 app that, with the latest release, required Nepomuk to be installed. A deeper frown. KDE4 will not run on older hardware. An idle, stripped-to-the-bones KDE4 desktop (along with the underlying operating system) requires more than 512 MB of RAM. That more or less excludes people on fixed incomes with older computers and people in developing regions of the world from using KDE4. From my perspective KDE4 has become a geek's playground and geeks almost always have bleeding edge hardware. Understandably so because time is money. The faster development proceeds the faster the results. Better hardware improves that kind of environment. But that kind of environment is not what non developers use, which is where software should always be tested. Fellow geeks using bleeding edge hardware and sharing similar opinions seldom provide good feedback for usability testing. And so the story goes. Redesign Akonadi, Nepomuk, and Strigi as true optional packages for users and I will reconsider my perceptions about KDE4. Until then I will devote my energy toward building Trinity. Please notice I have shared my experiences and opinions. I have not written that KDE4 is crapware. I have written that I disagree with some fundamental KDE4 design decisions. Decisions that, for now at least, seem irrevocable. Nor have I called anybody names. I disagree with certain design decisions but have not called anybody stupid or insulted anybody's mother. This list is for Trinity developers. That means opinions and enthusiasm here will lean heavily toward that desktop environment and not others. Why Trinity exists is no secret and we here should not back off from those reasons. Trinity exists because those involved do not like the design decisions made by the KDE4 developers, such as those I just shared. Yes, during discussions we should pause to check our facts before making statements, but often in human interaction the line between fact and opinion is forgotten --- especially when those involved in a tight community share similar opinions for being involved. Human nature 101. Nothing new about this behavior trend any more than a person during a game rooting for a visiting team can expect some razing from the home team crowd. Humans are social creatures and seek those who share similar perspectives and views. In those discussions we should remind ourselves that this is the Trinity developers list and we should expect that kind of human interaction. We should not apologize for why we are here or even feel compelled to do so. Every time somebody here in this list uses the symbols K, D, E, and 4 concurrently and in that order in a comparative manner to Trinity does not mean the person is a bad person or is misinformed. Such statements should be received and viewed from the simple premise that this is the Trinity developers list, not the KDE4 developers list. People are allowed their opinions. Such statements are not always derogatory although in my opinion, KDE4 developers deserve some criticism. Criticism yes, but not hatred. And no, I'm not going to join the KDE4 discussion lists to help change KDE4. End users have been trying to persuade the KDE4 developers to reconsider their design decisions and they have refused. I'm interested in improving Trinity, not KDE4. As long as Nepomuk, Strigi, and Akonadi are required I am not interested in trying KDE4, 4.8, 4.9 or 4.whatever. I'm not interested in trying GNOME (version 2 or 3), Unity, LXDE, or Xfce, on desktop computers (other devices such as tablets is a different conversation). For desktops I am interested in Trinity. I don't join KDE4 discussions with the intent of pimping Trinity any more than I would join an Ubuntu discussion list to pimp Slackware. Joining the Trinity discussion list means being expectant that participants are going to be favorable toward Trinity more than other desktops. To join and act otherwise is acting naively. The world is big enough for different desktop environments and different operating systems. Users and proponents of each should focus on their preferences and leave others to do likewise. I am not going to hold my breath or pretend to walk on glass every time somebody here shares an opinion favoring Trinity over KDE4. That is exactly why we're all here. Calvin, I responded to your request for suggestions toward improving KControl. Let me know when you need help with testing. Darrell

Okeydokey. How about a multi-phase approach? First address those items involving basic tree list reorganization. Those items require editing and creating some XML files but no code hacking. Second phase would be those items that require code hacking, such as moving group boxes from one location to another. Third phase involves renaming various categories. Although this sounds easy, I offer this phase last because of translations. Some of these should be straightforward, such as splitting Regional & Accessibility and Sound & Multimedia. Others will be a challenge, such as renaming Peripherals to Hardware and creating a new category named System Information. Maybe we do the best we can with various translation tools and hope for the best. The KControl tree list structure is defined in tdebase/applnk/kde-settings.menu. The individual tree list categories are named in various main/tdebase/applnk/kde-settings*.directory files. I haven't looked further to see how the sub items in each category are created. Darrell

On Mon, 6 Feb 2012 13:59:50 -0500 Calvin Morrison <mutantturkey(a)gmail.com> wrote: As of now Trinity translations are mostly the KDE 3.5.10 ones with very few updates, so most new Trinity strings aren't translated at all, and display in English instead. If and when I find the time I could update some French translations.

I now see how they work. The sub items all are *.desktop files in $PREFIX/share/applications and have a related X-KDE-settings* option in the Categories key. With that information we should be able to start tinkering once you get the etherpad established. I suspect even Tim has not tried to address translations and has side-stepped those challenges simply by leaving the original *.desktop files as-is. There are various translation tools but as mentioned in a recent thread, translations seldom are copy-and-paste. That is why I wrote we use such tools and then hope for the best. I am sure people using the other locales will let us know when we butcher their language. We don't have a user base to solve this challenge easily. At least not for every language. But we can post messages to the Trinity lists and ask for help. One option would be for team members and users who attend college to solicit help on campus. Professors likely know of ways and other people who might help. Another option is to encourage somebody in Trinity-land who speaks multiple languages to help as a translation team leader. That is, such a person who speaks multiple languages will be more familiar with distinct aspects. For example, to English speaking people, many foreign languages look "backwards" because words are placed in different locations. For example, in English somebody might say The Blue Book but in a different language the text would read The Book Blue. A person more familiar with other languages would know to watch for those kind of syntax challenges even when a translation tool correctly selects the words. Another option will be to search the web for similar *.desktop files from all free/libre software. Here is a list of the two-letter abbreviations used to identify each language: http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes What happens when a language is not translated in a desktop file? Does the underlying parsing code then default to Name and GenericName, which almost always are American English? If we can't translate everything is that a Bad Thing? Would such default text be better than butchering a language through a translation tool? I have seen that most developers don't worry about translations until people using other languages contribute that specific translation. The challenge we face is many of these Trinity desktop files are already translated. When we rename some of the KControl items --- and that is a good long-term goal --- we start over from scratch and that might seem unfair to those already using Trinity. Darrell

While I think that it's mostly okay, with maybe a few big problems , now is the chance to revamp it. Sorry for top posting. Calvin On Feb 8, 2012 7:03 PM, "David C. Rankin" <drankinatty(a)suddenlinkmail.com> wrote:

On 02/11/2012 10:09 PM, David C. Rankin wrote: My first cut at moving items in kcontrol are shown in this side-by-side: http://www.3111skyline.com/dl/dt/trinity/kcontrol/index-comp.html -- David C. Rankin, J.D.,P.E.

I don't consider any system with a CPU of 1 GHz or faster to be old. :) You say only 512 MB of RAM. I'm curious what system services are running or what the system is like when running several apps. Darrell

On Sun, 5 Feb 2012 21:57:49 -0800 (PST) Darrell Anderson <humanreadable(a)yahoo.com> wrote: Because it is a technical one, and I was talking about user-interface change. If it works (and it seems to finally work in 4.8) it won't change anything for the user. Moreover a SQL DB is not necessarily heavy, such technology was already used in LAMP stacks a decade ago, when the first PIV's were the latest radiators from Intel. I think it will somehow run on 256 MB of RAM. But not anything less. By the way 512 MB of old-technology RAM is significantly cheaper than a new computer, if the motherboard supports it. In France it is something like €15 including taxes.

I did some preliminary experimenting. Some of the changes require only modifying the Categories key in the respective desktop files. Some changes require carefully replacing "KDE" with "TDE" in the respective *.desktop file. With such nominal changes I was able to perform the following: * Rename KDE Components to TDE Components. * Move Desktop/Multiple Desktops to TDE Components. * Rename KDE Performance to TDE Performance. * Rename KDE Resources to TDE Resources. * Move the remaining Desktop category items to Appearance & Themes. * Move Peripherals/Monitor and Display to System Administration. * Move Peripherals/ICC Color Profile to System Administration. * Move Power Control/Laptop Battery to Peripherals/Laptop Battery. * Move the old KInfoCenter items to a new catagory named System Information. As proof of concept, I split Sound & Multimedia into two categories: 1) Sound and 2) Multimedia. Sound contains Sound System, System Bell, and System Notifications. Multimedia contains Audio CDs and CDDB Retrieval. I did not tinker with translations. I also renamed Appearance & Themes to Appearance and Peripherals to Hardware. Yet again I did not tinker with translations. These nominal changes improved the KControl layout. I did not change source files and rebuild packages. I fiddled directly with the related filed in a virtual machine. A note if you tinker directly with the desktop files in an installed Trinity desktop: delete the $TDEHOME/cache-$HOSTNAME/ksycoca files and restart each session anew. Otherwise the cache will not show any changes. Darrell

On 7 February 2012 05:20, Pawel Soltsy <sh4dou(a)gmail.com> wrote: I have started an etherpad. Please organize new ideas into those categories provided, or create a new category. Anything that doesn't fit please put below. Also please respond with AGREE/DISAGREE/MODIFY and why in a sub bullet http://trinity.etherpad.trinitydesktop.org/40 Thanks! Calvin Morrison

Le dimanche 05 février 2012, Darrell Anderson a écrit : --------------------------------------------------------------------- Hi everybody I had a look here: etherpad.trinitydesktop.org/40. I agree with Darrell: "Both should be supported". <troll> In my mind, Lilo is for bootstrap loaders what Trinity is for Windows managers: the latest versions Grub2 and KDE4/gnome3 do not keep their promises. The universal usability targeted by Grub may be reached today, but 99.999% of the standard PC + Linux/Windows users dont care about that. I fill like having paid something for that, like lost of time with re-intallation, for instance, especially for problems of incompatibility between GRUB 1 and GRUB2. These systems "of the future" are finaly good but for TESTs purpose only...</troll> So, I am happy to see on http://lilo.alioth.debian.org/ that the project restarted in June 2010. I will use LILO if its support is available at the moment I will "definitively" install Trinity! Cheers Patrick NB: Not directly related to Trinity, but thinking about this "final" installation, another concern is the support for ReiserFS. This file system seems being abandoned for EXT4 and is sometimes simply ignored by distributions at the time of installation. This will likely cause me problems...