Hi.
I'd like to undergo an effort to cleanup and reorganize all of our kcm modules. Over time there have been features added which are placed in the wrong section, other times things have been done inefficiently or made to be overly complicated.
I think an "audit" of our modules would be good, from a user perspective. This weekend I tried KDE4.0 and like Trinity it is plagued with this same confusion. I hadn't noticed it in trinity because I am so used to it, growing used to it over time. Trying to configure kde4.0 left me with confusion most users will feel with KDE3/Trinity. Our control system isn't laid out very effectively.
I am going to open an etherpad for this. I would also like any users/developers to respond to this email with anything they find to be weird/out of place.
I'll start: the Kicker configure screen, underneath appearance has an "advanced options" button. There is nothing advanced about these options and it should be more clearly organized.
Lets try and sort this out! Calvin Morrison
Hi.
I'd like to undergo an effort to cleanup and reorganize all of our kcm modules. Over time there have been features added which are placed in the wrong section, other times things have been done inefficiently or made to be overly complicated.
I think an "audit" of our modules would be good, from a user perspective. This weekend I tried KDE4.0 and like Trinity it is plagued with this same confusion. I hadn't noticed it in trinity because I am so used to it, growing used to it over time. Trying to configure kde4.0 left me with confusion most users will feel with KDE3/Trinity. Our control system isn't laid out very effectively.
I am going to open an etherpad for this. I would also like any users/developers to respond to this email with anything they find to be weird/out of place.
I'll start: the Kicker configure screen, underneath appearance has an "advanced options" button. There is nothing advanced about these options and it should be more clearly organized.
Lets try and sort this out! Calvin Morrison
Sounds like a good project. This is another area that we should be able to do better than KDE4 in theory; Windows$ has always (in versions up to XP) outdone Linux in this area as well.
Tim
On Sunday 05 February 2012 03:08:36 Timothy Pearson wrote:
Hi.
I'd like to undergo an effort to cleanup and reorganize all of our kcm modules. Over time there have been features added which are placed in the wrong section, other times things have been done inefficiently or made to be overly complicated.
I think an "audit" of our modules would be good, from a user perspective. This weekend I tried KDE4.0 and like Trinity it is plagued with this same confusion. I hadn't noticed it in trinity because I am so used to it, growing used to it over time. Trying to configure kde4.0 left me with confusion most users will feel with KDE3/Trinity. Our control system isn't laid out very effectively.
May I ask why you tried KDE 4.0? Why don't you go with 4.8? Somewhen in the past the systemsettings maintainers spent a lot of time in improving the layout. I am sure you could benefit from this work and not try to audit it again. It's just an idea to save you some time.
I am going to open an etherpad for this. I would also like any users/developers to respond to this email with anything they find to be weird/out of place.
I'll start: the Kicker configure screen, underneath appearance has an "advanced options" button. There is nothing advanced about these options and it should be more clearly organized.
Lets try and sort this out! Calvin Morrison
Sounds like a good project. This is another area that we should be able to do better than KDE4 in theory; Windows$ has always (in versions up to XP) outdone Linux in this area as well.
*sigh* You don't have to "do better than KDE4". If you do better, please upstream your changes. Please realize that you are not in competition with KDE.
Kind Regards
Martin Gräßlin Upstream developer
On 5 February 2012 04:57, Martin Gräßlin mgraesslin@kde.org wrote:
On Sunday 05 February 2012 03:08:36 Timothy Pearson wrote:
Hi.
I'd like to undergo an effort to cleanup and reorganize all of our kcm modules. Over time there have been features added which are placed in
the
wrong section, other times things have been done inefficiently or made
to
be overly complicated.
I think an "audit" of our modules would be good, from a user
perspective.
This weekend I tried KDE4.0 and like Trinity it is plagued with this
same
confusion. I hadn't noticed it in trinity because I am so used to it, growing used to it over time. Trying to configure kde4.0 left me with confusion most users will feel with KDE3/Trinity. Our control system
isn't
laid out very effectively.
May I ask why you tried KDE 4.0? Why don't you go with 4.8? Somewhen in the past the systemsettings maintainers spent a lot of time in improving the layout. I am sure you could benefit from this work and not try to audit it again. It's just an idea to save you some time.
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.
I am going to open an etherpad for this. I would also like any users/developers to respond to this email with anything they find to be weird/out of place.
I'll start: the Kicker configure screen, underneath appearance has an "advanced options" button. There is nothing advanced about these
options
and it should be more clearly organized.
Lets try and sort this out! Calvin Morrison
Sounds like a good project. This is another area that we should be able to do better than KDE4 in theory; Windows$ has always (in versions up to XP) outdone Linux in this area as well.
*sigh* You don't have to "do better than KDE4". If you do better, please upstream your changes. Please realize that you are not in competition with KDE.
Well said.
Calvin Morrison
On Sunday 05 February 2012 14:21:13 Calvin Morrison wrote:
May I ask why you tried KDE 4.0? Why don't you go with 4.8? Somewhen in the past the systemsettings maintainers spent a lot of time in improving the layout. I am sure you could benefit from this work and not try to audit it again. It's just an idea to save you some time.
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.
ok that makes more sense :-)
My recommendation would still be to stick as much as possible to 4.8 given that most users will go either from KDE to Trinity or the other way around. Also lots of work went into it and you can just save the time :-)
Of course not all settings will match given that Trinity ships obsoleted KCMs and KDE added new KCMs. But the general structure should work nevertheless.
As I read in another mail: don't try to reorganize the settings inside the KCMs. It is much work and some KCMs are really old (befor .ui files existed). I saw such a case listed for a KWin module where I know that it does not have ui files. That's the reason why the KCM is identical in KDE 4.x :-)
In case you want to work on the non ui files KCM, please upload the patches on http://reviewboard.kde.org :-)
Cheers Martin
Sounds like a good project. This is another area that we should be able to do better than KDE4 in theory; Windows$ has always (in versions up to XP) outdone Linux in this area as well.
*sigh* You don't have to "do better than KDE4". If you do better, please upstream your changes. Please realize that you are not in competition with KDE.
Kind Regards
Martin GräÃlin Upstream developer
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
On Sun, 5 Feb 2012 16:17:31 -0600 "Timothy Pearson" kb9vqf@pearsoncomputing.net wrote:
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 use KDE 4.8 on one of my laptops and use it nearly the same way as I use Trinity. Could you just name such a "latest desktop fashion" which is: -newer than KDE 3.5 -visible from the user (e.g. not the fact that KMail2 uses Akonadi), and -which use is *required* in the KDE4 desktop interface ?
I hope this clarifies some things.
Timothy Pearson Trinity Desktop Project
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Sun, 5 Feb 2012 16:17:31 -0600 "Timothy Pearson" kb9vqf@pearsoncomputing.net wrote:
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 use KDE 4.8 on one of my laptops and use it nearly the same way as I use Trinity. Could you just name such a "latest desktop fashion" which is: -newer than KDE 3.5 -visible from the user (e.g. not the fact that KMail2 uses Akonadi), and -which use is *required* in the KDE4 desktop interface
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
On Sunday 05 February 2012 17:45:10 Timothy Pearson wrote:
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.
My personal suggestion: try it again. Give 4.8 a week or two and really try to use it. If you run into issues just use forum.kde.org to get help. I would be surprised if you would not love it, if you try it without any prejudices.
given your statements in your last mail I guess you haven't used a current version of 4.x for a looong time.
It's not that I want you to start using KDE Plasma, but you should at least know what the desktop is able to do, if you do statements what it cannot do.
Cheers Martin
I use KDE 4.8 on one of my laptops and use it nearly the same way as I use Trinity. Could you just name such a "latest desktop fashion" which is: -newer than KDE 3.5 -visible from the user (e.g. not the fact that KMail2 uses Akonadi), and -which use is *required* in the KDE4 desktop interface
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
Calvin, I responded to your request for suggestions toward improving KControl. Let me know when you need help with testing.
Thanks! It's rather lengthy I need to review each of those ideas. Overall they look like valid choices. I like the idea of separating peripherals and other customizations. If not it's an 100% agreement, maybe a few small details.
I am going to create a Etherpad with your ideas copied into it. After doing my own review I will be asking Trinity users and developers for further ideas and modifications.
Spot on,
Calvin
Calvin, I responded to your
request for suggestions toward improving KControl. Let me know when you need help with testing.
Thanks! It's rather lengthy I need to review each of those ideas. Overall they look like valid choices. I like the idea of separating peripherals and other customizations. If not it's an 100% agreement, maybe a few small details.
I am going to create a Etherpad with your ideas copied into it. After doing my own review I will be asking Trinity users and developers for further ideas and modifications.
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 6 February 2012 13:54, Darrell Anderson humanreadable@yahoo.com wrote:
Calvin, I responded to your
request for suggestions toward improving KControl. Let me know when you need help with testing.
Thanks! It's rather lengthy I need to review each of those ideas. Overall they look like valid choices. I like the idea of separating peripherals and other customizations. If not it's an 100% agreement, maybe a few small details.
I am going to create a Etherpad with your ideas copied into it. After doing my own review I will be asking Trinity users and developers for further ideas and modifications.
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
That seems like a good approach.
As for Translations - what is the state of translations on Trinity in general? I only use English so I am not really aware of it. How many languages do we provide? do we have any translators willing to do this?
Calvin
On Mon, 6 Feb 2012 13:59:50 -0500 Calvin Morrison mutantturkey@gmail.com wrote:
On 6 February 2012 13:54, Darrell Anderson humanreadable@yahoo.com wrote:
Calvin, I responded to your
request for suggestions toward improving KControl. Let me know when you need help with testing.
Thanks! It's rather lengthy I need to review each of those ideas. Overall they look like valid choices. I like the idea of separating peripherals and other customizations. If not it's an 100% agreement, maybe a few small details.
I am going to create a Etherpad with your ideas copied into it. After doing my own review I will be asking Trinity users and developers for further ideas and modifications.
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
That seems like a good approach.
As for Translations - what is the state of translations on Trinity in general? I only use English so I am not really aware of it. How many languages do we provide? do we have any translators willing to do this?
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.
Calvin
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On 6 February 2012 14:30, /dev/ammo42 mickeytintincolle@yahoo.fr wrote:
On Mon, 6 Feb 2012 13:59:50 -0500 Calvin Morrison mutantturkey@gmail.com wrote:
On 6 February 2012 13:54, Darrell Anderson humanreadable@yahoo.com wrote:
Calvin, I responded to your
request for suggestions toward improving KControl. Let me know when you need help with testing.
Thanks! It's rather lengthy I need to review each of those ideas. Overall they look like valid choices. I like the idea of separating peripherals and other customizations. If not it's an 100% agreement, maybe a few small details.
I am going to create a Etherpad with your ideas copied into it. After doing my own review I will be asking Trinity users and developers for further ideas and modifications.
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
That seems like a good approach.
As for Translations - what is the state of translations on Trinity in general? I only use English so I am not really aware of it. How many languages do we provide? do we have any translators willing to do this?
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.
Calvin
I know many of our developers are international users. I wonder if we could get some sort of collective effort going to help translate strings.
Calvin
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.
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.
As for Translations - what is the state of translations on Trinity in general? I only use English so I am not really aware of it. How many languages do we provide? do we have any translators willing to do this?
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
On 02/06/2012 10:34 AM, Calvin Morrison wrote:
Calvin, I responded to your request for suggestions toward improving KControl. Let me know when you need help with testing.
Thanks! It's rather lengthy I need to review each of those ideas. Overall they look like valid choices. I like the idea of separating peripherals and other customizations. If not it's an 100% agreement, maybe a few small details.
I am going to create a Etherpad with your ideas copied into it. After doing my own review I will be asking Trinity users and developers for further ideas and modifications.
Spot on,
Calvin
Calvin,
Drop a link to the etherpad. I just googled and found nothing. I agree a small clean up is in order, but not too much. The kcontrol for 3.5.13 wasn't bad as of 10 months ago or so. I haven't had time to think lately, but I did install, test and dump 4.8 when released on Arch and system settings was garbage. 3.5.12->3.5.13 was not in too bad of shape, so I want to help with the review to make sure we don't throw the baby out with the bathwater :)
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@suddenlinkmail.com wrote:
On 02/06/2012 10:34 AM, Calvin Morrison wrote:
Calvin, I responded to your request for suggestions toward improving
KControl. Let me know when you need help with testing.
Thanks! It's rather lengthy I need to review each of those ideas. Overall they look like valid choices. I like the idea of separating peripherals and other customizations. If not it's an 100% agreement, maybe a few small details.
I am going to create a Etherpad with your ideas copied into it. After doing my own review I will be asking Trinity users and developers for further ideas and modifications.
Spot on,
Calvin
Calvin,
Drop a link to the etherpad. I just googled and found nothing. I agree a small clean up is in order, but not too much. The kcontrol for 3.5.13 wasn't bad as of 10 months ago or so. I haven't had time to think lately, but I did install, test and dump 4.8 when released on Arch and system settings was garbage. 3.5.12->3.5.13 was not in too bad of shape, so I want to help with the review to make sure we don't throw the baby out with the bathwater :)
-- David C. Rankin, J.D.,P.E.
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On 02/08/2012 06:34 PM, Calvin Morrison wrote:
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
Calvin,
I have created a tool that lets me generate a mock-up of kcontrol layout that will help in prototyping. I can generate the menu from a simple text file so we can move things around and get a consensus. It is a dtree replica of the menu that behaves (expanding/contracting) like the current kcontrol layout. The tool is here:
http://www.3111skyline.com/dl/dt/trinity/kcontrol/
The menu is generated by parsing a simple text file with the menu hierarchy determined by the indent level (spaces NOT tabs). Here is the one I used based on 3.5.12. Since it is web based, we can put the original and the proposal side-by-side on the same page that will help in comparing the changes visually.
http://www.3111skyline.com/dl/dt/trinity/kcontrol/mlabels.txt
The BASH script is still in work, but if you want a quick peek, you can grab it here:
http://www.3111skyline.com/dl/dt/trinity/kcontrol/genmen.sh
a text file to view in a browser is here:
http://www.3111skyline.com/dl/dt/trinity/kcontrol/genmen.sh.txt
My daughter has a gymnastics meet tomorrow, so it will be Monday before I can work on it again (maybe tomorrow evening if I get home in time)
Just grab the contents of the directory if you want to run it on your box.
On 02/11/2012 10:09 PM, David C. Rankin wrote:
On 02/08/2012 06:34 PM, Calvin Morrison wrote:
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
Calvin,
I have created a tool that lets me generate a mock-up of kcontrol layout that will help in prototyping. I can generate the menu from a simple text file so we can move things around and get a consensus. It is a dtree replica of the menu that behaves (expanding/contracting) like the current kcontrol layout. The tool is here:
http://www.3111skyline.com/dl/dt/trinity/kcontrol/
The menu is generated by parsing a simple text file with the menu hierarchy determined by the indent level (spaces NOT tabs). Here is the one I used based on 3.5.12. Since it is web based, we can put the original and the proposal side-by-side on the same page that will help in comparing the changes visually.
http://www.3111skyline.com/dl/dt/trinity/kcontrol/mlabels.txt
The BASH script is still in work, but if you want a quick peek, you can grab it here:
http://www.3111skyline.com/dl/dt/trinity/kcontrol/genmen.sh
a text file to view in a browser is here:
http://www.3111skyline.com/dl/dt/trinity/kcontrol/genmen.sh.txt
My daughter has a gymnastics meet tomorrow, so it will be Monday before I can work on it again (maybe tomorrow evening if I get home in time)
Just grab the contents of the directory if you want to run it on your box.
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
Darrell Anderson wrote:
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.
This isn't necessarily true. I've been running a somewhat stripped down (no compositing or Nepomuk/Strigi) KDE4.4/Debian Squeeze installation on a ~6 year old Thinkpad T42 (PM@1.7GhZ) for the past year or so. The system has 'only' 512MB of RAM, and rarely uses it all! (idles at about 200 in fact.) I have another modest system running KDE4.7 on SUSE that idles at 220MB used. I haven't done any real optimization on these systems, just disabled desktop effects and Nepomuk/Strigi. Now, I still wouldn't use it on anything *really* old, but KDE4's certainly more capable on older hardware than it gets credit for.
This isn't necessarily true. I've been running a somewhat stripped down (no compositing or Nepomuk/Strigi) KDE4.4/Debian Squeeze installation on a ~6 year old Thinkpad T42 (PM@1.7GhZ) for the past year or so. The system has 'only' 512MB of RAM, and rarely uses it all! (idles at about 200 in fact.) I have another modest system running KDE4.7 on SUSE that idles at 220MB used. I haven't done any real optimization on these systems, just disabled desktop effects and Nepomuk/Strigi. Now, I still wouldn't use it on anything *really* old, but KDE4's certainly more capable on older hardware than it gets credit for.
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
Darrell Anderson wrote:
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
As I type this (web browser, mail client, IRC, and a PDF open) 300MB of RAM is used in total, and the system is snappy and responsive. Firing up an Akonadi-using application increases RAM usage to about 380MB. All the typical services/daemons (NetworkManager, HAL, udev, etc.) are running, just no Nepomuk/Strigi, and no KWin compositor.
On Sun, 5 Feb 2012 21:57:49 -0800 (PST) Darrell Anderson humanreadable@yahoo.com wrote:
I use KDE 4.8 on one of my laptops and use it nearly the same way as I use Trinity. Could you just name such a "latest desktop fashion" which is: -newer than KDE 3.5 -visible from the user (e.g. not the fact that KMail2 uses Akonadi), and -which use is *required* in the KDE4 desktop interface
Sure, I can do that. :)
Odd that you should exclude KMail and Akonadi, which pretty much pins the tail on the donkey.
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.
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.
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'd like to undergo an effort to cleanup and reorganize all of our kcm modules. Over time there have been features added which are placed in the wrong section, other times things have been done inefficiently or made to be overly complicated.
I am going to open an etherpad for this. I would also like any users/developers to respond to this email with anything they find to be weird/out of place. I'll start: the Kicker configure screen, underneath appearance has an "advanced options" button. There is nothing advanced about these options and it should be more clearly organized.
Okay, here are some conversation starters:
* Refer to bug report 841 for branding issues. (KDE -> TDE)
* All of the "Advanced" button dialogs should be moved to the parent dialog. Another Advanced button example is in the Screen Savers section.
* Merge the Appearance & Themes and Desktop categories into one category named Appearance.
* Rename Desktop/Behavior to Menu & Icon Behavior (to identify what is being configured and distinguish from Window Behavior).
* Move Desktop/Multiple Desktops to TDE Components.
* Move Window-Specific Settings as a new tab option in Window Behavior. Name the tab Specific Settings.
* In Window Behavior, Advanced tab, move all items to the Window Actions tab. Delete the Advanced tab.
* Rename Panels to Panel/Kicker. (Both terms are used often and interchangeably.)
* Rename Splash Screen to Startup Splash Image.
* Rename Style to Theme Style. (Coincides more nicely with Theme Manager.)
* Split Regional & Accessibility into two separate categories: 1) Regional Settings and 2) Accessibility.
* Under Regional & Accessibility, move Keyboard Layout and Keyboard Shortcuts to Peripherals/Keyboard.
* Move Regional & Accessibility/Input Actions to TDE Components.
* Move the TDE Components/KDE Performance/Konqueror tab to TDE Components/File Manager.
* Move the TDE Components/KDE Performance/System tab to TDE Components/Session Manager and eliminate the tab by moving the "System Configuration" group box to the Session Manager parent dialog.
* Eliminate the TDE Components/KDE Performance option.
* Move Peripherals/Monitor and Display to System Administration. Actions require Admin access.
* Move Peripherals/ICC Color Profile to System Administration. Actions require Admin access.
* Rename Peripherals/Display/Power Control tab to Power Management (provides naming consistency with the same tab in Peripherals/Monitor and Display).
* Move Power Control/Laptop Battery to Peripherals/Laptop Battery. Delete the Power Control category.
* Many of the Peripherals items came from the not-yet-fully-purged KInfoCenter (bug report 289). The items in Peripherals should be those that are configurable. Move the non-configurable informational items to a new category called System Information:
CD-ROM Information (rename to CDs/DVDs) DMA Channels Devices (Rename to Kernel Device Assignments. Many users think of "devices" as the things they grab with their hands --- "Devices" is not distinguishable from IEEE 1394 Devices, Storage Devices, or USB Devices.) IEEE 1394 Devices IO-Ports Interrupts Memory PCI PCMCIA Partitions (Rename to Hard Drive Partitions) Processor SCSI Sound Storage Devices USB Devices X-Server
* Rename Peripherals category to Hardware. "Peripherals" is a throw-back term used primarily by geeks. :)
* 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.
* Why in System Administration is there is a configuration option for LILO but not for GRUB? Both should be supported.
* Some items should appear ghosted when the underlying system does not support the option. That is, the list item itself in the tree should be ghosted. For example, in System Administration, the IBM Thinkpad Laptop (useless anywhere other than a Thinkpad), Image Index (useless unless GNU Image Finding Tool is installed), and Sony Vaio Laptop (useless anywhere other than a Sony Vaio). Likewise for Power Control/Laptop Battery and Peripherals/Remote Control.
As you noted, experienced users acclimate to the existing layout. You'll find good feedback if you recruit some not-computer-savvy people to sit at a default Trinity desktop and ask them to reconfigure as much as possible. Let them ask questions to find options. Encourage them to say "WTF!" ;) Take notes where they struggle to find anything or ask. Pizza and beverages should be a sufficient exchange for their time and evaluations. :)
Many of these changes should be straightforward reorganization and could (should?) be part of R14.
Darrell
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 Tue, Feb 7, 2012 at 2:09 AM, Darrell Anderson humanreadable@yahoo.com wrote:
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.
IMHO this should not be split. Creating new category just for 2-3 items is a bit overkill for me. It causes too much segmentation.
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
Another thing that should be done is to remove redundant configuration methods. Take the monitor settings. Actually there are 3 ways to configure your screen (2 in kcontrol + kranrdr in tray), yet I wasn't able to configure my screens like I wanted to. I used xrandr form my terminal to do that. The 'Display' and 'Monitor and Display' options should be merged (both are in 'Peripherals' category. Next thing is that 'Monitor and Display' on my system requires root password/access to allow me to configure anything. Yet if I use xrandr directly I don't need it. This is a flaw for me. As last thing would be to add possibility to display icon in the systray if user wants it, that allow quick access/change of resolution (just like we have atm) but is not an external application.
On 7 February 2012 05:20, Pawel Soltsy sh4dou@gmail.com wrote:
On Tue, Feb 7, 2012 at 2:09 AM, Darrell Anderson humanreadable@yahoo.com wrote:
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.
IMHO this should not be split. Creating new category just for 2-3 items is a bit overkill for me. It causes too much segmentation.
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
Another thing that should be done is to remove redundant configuration methods. Take the monitor settings. Actually there are 3 ways to configure your screen (2 in kcontrol + kranrdr in tray), yet I wasn't able to configure my screens like I wanted to. I used xrandr form my terminal to do that. The 'Display' and 'Monitor and Display' options should be merged (both are in 'Peripherals' category. Next thing is that 'Monitor and Display' on my system requires root password/access to allow me to configure anything. Yet if I use xrandr directly I don't need it. This is a flaw for me. As last thing would be to add possibility to display icon in the systray if user wants it, that allow quick access/change of resolution (just like we have atm) but is not an external application.
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
On 02/07/2012 09:46 AM, Calvin Morrison 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
disregard, I found it :)
Le dimanche 05 février 2012, Darrell Anderson a écrit :
I'd like to undergo an effort to cleanup and reorganize all of our kcm modules. Over time there have been features added which are placed in the wrong section, other times things have been done inefficiently or made to be overly complicated.
I am going to open an etherpad for this. I would also like any users/developers to respond to this email with anything they find to be weird/out of place. I'll start: the Kicker configure screen, underneath appearance has an "advanced options" button. There is nothing advanced about these options and it should be more clearly organized.
Okay, here are some conversation starters: ...
- Why in System Administration is there is a configuration option for LILO
but not for GRUB? Both should be supported. ...
Darrell
--------------------------------------------------------------------- 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...
- Why in System Administration is there is a
configuration option for LILO
but not for GRUB? Both should be supported. ...
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!
Check the etherpad for my comments. I don't want to see this option disappear but I recognize that people using distros that do not use LILO do not want to be bothered with the item. I recommended making this item a build option within the kcontrol cmake options. Those who want to see this item in kcontrol set a build option and those who don't tweak the opposite. Everybody wins.
I agree about GRUB. I still use 0.97 and have no desire to move to GRUB2 and the convoluted mess that app has become. A challenge with adding a kpart to kcontrol for GRUB is supporting both versions. Like LILO, GRUB 0.97 has not disappeared and is unlikely to disappear soon. So for now the best approach is to create a build option for the LILO option.
Darrell
-
/dev/ammo42 -
Calvin Morrison -
Darrell Anderson -
David C. Rankin -
Martin Gräßlin -
Old Laptop -
Patrick Serru -
Pawel Soltsy -
Timothy Pearson