Testing F22 RC3 I noticed a difference that has me wondering if this is just temporary....
On the current KDE in F21 one can go to "System Settings --> Common Appearance --> Locale --> Country/Region" and separately set the format of "Numbers", "Money", "Calendar", "Date&Time" and other things such as page size.
Now, with Plasma 5 there is a "Personalization --> Formats" section but I can't seem to find a way to set the Time Format to HH:MM:SS such that AM/PM isn't displayed and I get the time in the clock in 24hr format. I could set it to UK, but being originally from the US I'm used to MM/DD/YY not DD/MM/YY as the UK has it. So, my work around is to create .bashrc settings for LC_TIME.
So, either I am missing something or the graphic tools are offer less functionality than before.
On 03/09/2015 09:28 PM, Ed Greshko wrote:
Now, with Plasma 5 there is a "Personalization --> Formats" section but I can't seem to find a way to set the Time Format to HH:MM:SS such that AM/PM isn't displayed and I get the time in the clock in 24hr format. I could set it to UK, but being originally from the US I'm used to MM/DD/YY not DD/MM/YY as the UK has it. So, my work around is to create .bashrc settings for LC_TIME.
So, either I am missing something or the graphic tools are offer less functionality than before.
https://bugs.kde.org/show_bug.cgi?id=340982
Please comment and vote.
On 03/10/15 20:42, Glenn Holmer wrote:
https://bugs.kde.org/show_bug.cgi?id=340982
Please comment and vote.
Thanks.... Done....
Done. Thanks for taking the time to report this to the list. I'm not using Plasma5 but display my date as Day Month Year. Hopefully they'll fix this in short order. Configurability is one of KDE's strengths. It shouldn't be GNOMEified.
On Tuesday 10 of March 2015 06:55:04 Gerald B. Cox wrote:
Done. Thanks for taking the time to report this to the list. I'm not using Plasma5 but display my date as Day Month Year. Hopefully they'll fix this in short order. Configurability is one of KDE's strengths. It shouldn't be GNOMEified.
Please note that his has nothing to do with GNOME or lack of configurability. Instead of using the custom KLocale, the needed functionalities are now in Qt and its QLocale class. So the system locale is used, instead of duplicating the pieces for locale change. See for example: http://vizzzion.org/blog/2014/05/locale-changes-in-plasma-next/
Ciao
On Tuesday 10 of March 2015 15:03:04 Luigi Toscano wrote:
On Tuesday 10 of March 2015 06:55:04 Gerald B. Cox wrote:
Done. Thanks for taking the time to report this to the list. I'm not using Plasma5 but display my date as Day Month Year. Hopefully they'll fix this in short order. Configurability is one of KDE's strengths. It shouldn't be GNOMEified.
Please note that his has nothing to do with GNOME or lack of configurability. Instead of using the custom KLocale, the needed functionalities are now in Qt and its QLocale class. So the system locale is used, instead of duplicating the pieces for locale change. See for example: http://vizzzion.org/blog/2014/05/locale-changes-in-plasma-next/
... and especially the comment here: http://vizzzion.org/blog/2014/05/locale-changes-in-plasma-next/comment-page-...
Just to say that the extra-configurability should be fixed in Qt first. Unfortunately the shortage of manpower there (John has many things on his plate) does not help.
Ciao
If I read that explanation correctly it basically says that you no longer can override Locale settings. You get what is defined by the locale. If that is correct it is indeed a loss of configurability and it is the GNOME approach of restricting the options for the user. On Mar 10, 2015 11:03 AM, "Luigi Toscano" luigi.toscano@tiscali.it wrote:
On Tuesday 10 of March 2015 06:55:04 Gerald B. Cox wrote:
Done. Thanks for taking the time to report this to the list. I'm not using Plasma5 but display my date as Day Month Year. Hopefully they'll
fix
this in short order. Configurability is one of KDE's strengths. It shouldn't be GNOMEified.
Please note that his has nothing to do with GNOME or lack of configurability. Instead of using the custom KLocale, the needed functionalities are now in Qt and its QLocale class. So the system locale is used, instead of duplicating the pieces for locale change. See for example: http://vizzzion.org/blog/2014/05/locale-changes-in-plasma-next/
Ciao
Luigi
On Tuesday 10 of March 2015 07:10:23 Gerald B. Cox wrote:
If I read that explanation correctly it basically says that you no longer can override Locale settings. You get what is defined by the locale. If that is correct it is indeed a loss of configurability and it is the GNOME approach of restricting the options for the user.
No, because you can change potentially the locale (see the other email and the relevant comment in that blog post). The code and the UI to do it in an easy way is just missing because it was not written, no one is trying to remove features because they shouldn't be there. The point is that it should be fixed in some lower levels of the stack than the removed KLocale.
Ciao
The end user doesn't care about where the code is written. They care about the end result. This is something that was possible in past KDE releases and now it is gone. Changing the locale is not acceptable because that changes all settings. That isn't an acceptable or workable solution. On Mar 10, 2015 11:14 AM, "Luigi Toscano" luigi.toscano@tiscali.it wrote:
On Tuesday 10 of March 2015 07:10:23 Gerald B. Cox wrote:
If I read that explanation correctly it basically says that you no
longer
can override Locale settings. You get what is defined by the locale.
If
that is correct it is indeed a loss of configurability and it is the
GNOME
approach of restricting the options for the user.
No, because you can change potentially the locale (see the other email and the relevant comment in that blog post). The code and the UI to do it in an easy way is just missing because it was not written, no one is trying to remove features because they shouldn't be there. The point is that it should be fixed in some lower levels of the stack than the removed KLocale.
Ciao
Luigi
On 03/10/2015 09:24 AM, Gerald B. Cox wrote:
The end user doesn't care about where the code is written. They care about the end result. This is something that was possible in past KDE releases and now it is gone. Changing the locale is not acceptable because that changes all settings. That isn't an acceptable or workable solution.
In addition, it's quite clumsy to navigate a list of dozens of countries (same for each option under "Detailed Settings") without knowing what you'll get until you try one.
From the article cited by Luigi:
"KLocale is also still there, in the kde4support library, but it’s deprecated, and included as a porting aid and compatibility layer."
Then why not use it until this functionality is provided in Qt?
"QLocale, as opposed to the deprecated KLocale doesn’t allow to set specific properties for outside users. This is, in my opinion, a valid choice"
Respectfully disagree.
If you read the comments in the first article posted by Luigi you'll see that they already realize this was a non-starter. People were already complaining with the same things we have pointed out. There was a comment from May 2014 that the functionality would be returned in the next year or so, which is rapidly approaching. If not, they they can expect a deluge of complaints when people start actively using Plasma5 - better to get it fixed before widespread adoption to avoid all that.
On Tue, Mar 10, 2015 at 10:36 AM, Glenn Holmer shadowm@lyonlabs.org wrote:
On 03/10/2015 09:24 AM, Gerald B. Cox wrote:
The end user doesn't care about where the code is written. They care about the end result. This is something that was possible in past KDE releases and now it is gone. Changing the locale is not acceptable because that changes all settings. That isn't an acceptable or workable solution.
In addition, it's quite clumsy to navigate a list of dozens of countries (same for each option under "Detailed Settings") without knowing what you'll get until you try one.
From the article cited by Luigi:
"KLocale is also still there, in the kde4support library, but it’s deprecated, and included as a porting aid and compatibility layer."
Then why not use it until this functionality is provided in Qt?
"QLocale, as opposed to the deprecated KLocale doesn’t allow to set specific properties for outside users. This is, in my opinion, a valid choice"
Respectfully disagree.
-- Glenn Holmer (Linux registered user #16682) "After the vintage season came the aftermath -- and Cenbe." _______________________________________________ kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
Glenn Holmer wrote:
As I wrote in https://bugs.kde.org/show_bug.cgi?id=340982#c6 : This is a regression resulting from the switch from KDE's powerful locale and formatting classes to the inferior Qt-only ones, as part of the Frameworks initiative (that aimed at reducing interdependencies between KDE classes so that KDE can now ship a bazillion small "Frameworks" instead of a single coherent kdelibs framework). Sadly, loss of functionality was not considered a blocker for any of those K*→Q* ports.
Kevin Kofler
On 03/11/2015 10:26 PM, Kevin Kofler wrote:
Glenn Holmer wrote:
As I wrote in https://bugs.kde.org/show_bug.cgi?id=340982#c6 : This is a regression resulting from the switch from KDE's powerful locale and formatting classes to the inferior Qt-only ones, as part of the Frameworks initiative (that aimed at reducing interdependencies between KDE classes so that KDE can now ship a bazillion small "Frameworks" instead of a single coherent kdelibs framework). Sadly, loss of functionality was not considered a blocker for any of those K*→Q* ports.
This is a biased and incomplete explanation. While I personally lament the loss of KLocale's functionality as well, the motivation in switching to Qt's locale system was mainly that the behavior and scope it im- plements aligns closely with the rest of desktop Linux, which KLocale always had trouble mapping to - application of settings and behavior is now more con- sistent between KDE's apps and other Qt apps, as well as Linux desktop apps not using Qt at all.
Further, KDE contributed extensively to QLocale in Qt 5 to expand and improve it, to make the port feasible at all.
Finally, loss of functionality was generally con- sidered something to avoid in moving to the Qt/KF5 architecture, and KDE contributed tens of thousands of lines of kdelibs code and new code to Qt to help avoid it. In specific cases - like this one - functionality was lost, but not without thought or reason.
Kevin Kofler
Cheers, Eike
On Wed, Mar 11, 2015 at 5:16 PM, Eike Hein hein@kde.org wrote:
the motivation in switching to Qt's locale system was mainly that the behavior and scope it im- plements aligns closely with the rest of desktop Linux
There is an old saying: "The path to hell is paved with good intentions..."
People can wax poetic about the reasons but that doesn't change the fact that the functionality is gone; people have noticed and aren't at all pleased. Telling an end user that they have lost functionality but hey "the behavior and scope..." isn't going to fly. Their eyes will glaze over and they'll say WTF?
If Plasma5 gets into a major distribution (such as Fedora) without this being fixed you ain't heard nothing yet. Queue the GNOME comparisons, etc. etc.
Luckily it appears the KDE team recognizes this is a bit of a foobar and is working to correct.
Gerald B. Cox composed on 2015-03-11 18:14 (UTC-0700):
...it appears the KDE team ... is working to correct.
What evidence did you find to so indicate?
On Wed, Mar 11, 2015 at 6:36 PM, Felix Miata mrmazda@earthlink.net wrote:
Gerald B. Cox composed on 2015-03-11 18:14 (UTC-0700):
...it appears the KDE team ... is working to correct.
http://vizzzion.org/blog/2014/05/locale-changes-in-plasma-next/comment-page-...
Gerald B. Cox composed on 2015-03-11 18:41 (UTC-0700):
Felix Miata wrote:
Gerald B. Cox composed on 2015-03-11 18:14 (UTC-0700):
...it appears the KDE team ... is working to correct.
http://vizzzion.org/blog/2014/05/locale-changes-in-plasma-next/comment-page-...
I saw that. I was hoping you found something better than a 10 month old statement of intent. Good intentions do not pavement create. :-(
On Wed, Mar 11, 2015 at 6:58 PM, Felix Miata mrmazda@earthlink.net wrote:
I saw that. I was hoping you found something better than a 10 month old statement of intent. Good intentions do not pavement create. :-(
Touche! ROFL... he did say it "was planned"... that appeared to be definite, but the time line was a bit squishy - hopefully they'll meet the May target.
Gerald B. Cox wrote:
Touche! ROFL... he did say it "was planned"... that appeared to be definite, but the time line was a bit squishy - hopefully they'll meet the May target.
I doubt it. Maybe it will be back in 3 years, maybe never. (We are STILL missing some of the features that the KDE 3 kdeprint had before it was replaced by Qt's printing classes in KDE 4.)
Kevin Kofler
Well this issue is a real attention grabber... For example: you can't be a US citizen and display 24 hour time unless you change to the UK and the British pound. I still can't believe they thought that would pass muster. On Mar 12, 2015 9:09 PM, "Kevin Kofler" kevin.kofler@chello.at wrote:
Gerald B. Cox wrote:
Touche! ROFL... he did say it "was planned"... that appeared to be definite, but the time line was a bit squishy - hopefully they'll meet the May target.
I doubt it. Maybe it will be back in 3 years, maybe never. (We are STILL missing some of the features that the KDE 3 kdeprint had before it was replaced by Qt's printing classes in KDE 4.)
Kevin Kofler
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
On Mar 13, 2015 11:19 AM, "Gerald B. Cox" gbcox@bzb.us wrote:
Well this issue is a real attention grabber... For example: you can't be
a US citizen and display 24 hour time unless you change to the UK and the British pound. I still can't believe they thought that would pass muster.
Not entirely true. As I mentioned in my original post I just added export LC_TIME=C to my .bashrc to get that working.
Ed, what you did was hack around the issue. The vast majority of users aren't going to know to do that nor will that help with the other items such as date. You can also use IOS, Windows, GNOME, KDE 4 etc. to display 24 hour time and the sky is blue. We're discussing Plasma5 functionality and within that context what I said was true. On Mar 13, 2015 6:02 AM, "Ed Greshko" ed.greshko@greshko.com wrote:
On Mar 13, 2015 11:19 AM, "Gerald B. Cox" gbcox@bzb.us wrote:
Well this issue is a real attention grabber... For example: you can't
be a US citizen and display 24 hour time unless you change to the UK and the British pound. I still can't believe they thought that would pass muster.
Not entirely true. As I mentioned in my original post I just added export LC_TIME=C to my .bashrc to get that working.
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
On Mar 13, 2015 6:33 PM, "Gerald B. Cox" gbcox@bzb.us wrote:
Ed, what you did was hack around the issue. The vast majority of users
aren't going to know to do that nor will that help with the other items such as date. You can also use IOS, Windows, GNOME, KDE 4 etc. to display 24 hour time and the sky is blue. We're discussing Plasma5 functionality and within that context what I said was true.
Yes, it can't be done with the graphic tool. Just pointing out the, hopefully, temporary workaround.
On Mar 13, 2015 6:02 AM, "Ed Greshko" ed.greshko@greshko.com wrote:
On Mar 13, 2015 11:19 AM, "Gerald B. Cox" gbcox@bzb.us wrote:
Well this issue is a real attention grabber... For example: you can't
be a US citizen and display 24 hour time unless you change to the UK and the British pound. I still can't believe they thought that would pass muster.
Not entirely true. As I mentioned in my original post I just added export LC_TIME=C to my .bashrc to get that working.
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
On 03/13/2015 11:52 AM, Ed Greshko wrote:
Yes, it can't be done with the graphic tool. Just pointing out the, hopefully, temporary workaround.
It can be done with the graphic tool. "Time" is its own combo box in the config page, independent from "Currency".
What's gone relative to the old KLocale system is that KLocale allowed you to essentially create a custom locale with custom values for time format, while the new system requires you to set Time to, say, "Germany" if you want a 24 clock, which means you need to know which locale has the format you want. Which is fairly clumsy.
I agree the old system was better in this regard, and I take no offense if you as a user wish for it back. Unfor- tunately on the development side these are difficult decisions sometimes where pros and cons need to be weighed and a long-term view maintained. I'd ask that you try to understand that, while wishing for richer con- figurability.
Cheers, Eike
On Sat, Mar 14, 2015 at 7:36 AM, Eike Hein hein@kde.org wrote:
What's gone relative to the old KLocale system is that KLocale allowed you to essentially create a custom locale with custom values for time format, while the new system requires you to set Time to, say, "Germany" if you want a 24 clock, which means you need to know which locale has the format you want. Which is fairly clumsy.
Were you involved in this decision? Was the comment that I referred to earlier in the thread about this being fixed in the May, 2015 timeframe incorrect?
Regarding setting your locale to "Germany" for 24 time? Correct me if I am mistaken but that also changes currency to the Euro. If that is the case, as a solution it's not "fairly clumsy" it's just ridiculous. How anyone could consider this is solution is beyond me. It solves one issue and creates many more. Now the currency, date, etc. is in the wrong format. It's just clueless.
On 03/14/2015 03:48 PM, Gerald B. Cox wrote:
Were you involved in this decision? Was the comment that I referred to earlier in the thread about this being fixed in the May, 2015 timeframe incorrect?
No, I wasn't involved in that decision personally. I'm willing to speak for KDE in that regard, however (I am a core developer).
Regarding setting your locale to "Germany" for 24 time? Correct me if I am mistaken but that also changes currency to the Euro. If that is the case, as a solution it's not "fairly clumsy" it's just ridiculous. How anyone could consider this is solution is beyond me. It solves one issue and creates many more. Now the currency, date, etc. is in the wrong format. It's just clueless.
I specifically wrote that "Time" and "Currency" are independent settings.
Cheers, Eike
On Sat, Mar 14, 2015 at 9:20 AM, Eike Hein hein@kde.org wrote:
No, I wasn't involved in that decision personally. I'm willing to speak for KDE in that regard, however (I am a core developer).
Seems you're a bit out of the loop then. You're trying to spin a decision that they have accepted was a mistake and are working to correct.
On 03/14/2015 05:30 PM, Gerald B. Cox wrote:
Seems you're a bit out of the loop then. You're trying to spin a decision that they have accepted was a mistake and are working to correct.
I'm not trying to "spin" anything, and I'd prefer if you could stop the constant antagonizing. I understand you're frustrated and why you're frustrated, but that doesn't justify bad behavior.
The decision you're referring to was to drop KLocale in favor of improving QLocale, for the reasons I outlined. The "working to correct" part refers to improving QLocale even further, i.e. continuing the process of adding KLocale features to Qt. Describing this as "correcting a mistake" is _actual_ spin, since you're painting eggs on faces where none exists -- notice nothing in John's comments you linked actually supports that narrative.
You're certainly free to disagree with the original decision and refer to it as a mistake if you feel qualified to make that call, however.
As for timeframe, Qt 5.5 is currently in feature freeze and will likely be released in April. It contains no rele- vant new features in QLocale. The next opportunity to introduce new feature in QLocale is therefore the Qt 5.6 release cycle, which will deliver about half a year later. A Plasma Desktop release depending on Qt 5.6 will likely be released in early 2016. However, there is currently no confirmation of expanded QLocale functionality in Qt 5.6.
Cheers, Eike
On Sat, Mar 14, 2015 at 9:45 AM, Eike Hein hein@kde.org wrote:
I'm not trying to "spin" anything, and I'd prefer if you could stop the constant antagonizing. I understand you're frustrated and why you're frustrated, but that doesn't justify bad behavior.
I'm just pointing out the facts to ensure people don't get lost in your misdirection. That isn't being antagonistic, that's providing clarity.
On 03/14/2015 06:01 PM, Gerald B. Cox wrote:
I'm just pointing out the facts to ensure people don't get lost in your misdirection. That isn't being antagonistic, that's providing clarity.
Let's say I'm not particularly worried about who's looking like they're misdirecting and who's providing actual infor- mation in this exchange of ours. It's a shame your're doing it on the back of the venue, however.
Cheers, Eike
OK Eike... fair enough.
On Sat, Mar 14, 2015 at 10:21 AM, Eike Hein hein@kde.org wrote:
On 03/14/2015 06:01 PM, Gerald B. Cox wrote:
I'm just pointing out the facts to ensure people don't get lost in your misdirection. That isn't being antagonistic, that's providing clarity.
Let's say I'm not particularly worried about who's looking like they're misdirecting and who's providing actual infor- mation in this exchange of ours. It's a shame your're doing it on the back of the venue, however.
Cheers, Eike _______________________________________________ kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
Am 14.03.2015 um 15:48 schrieb Gerald B. Cox:
Regarding setting your locale to "Germany" for 24 time? Correct me if I am mistaken but that also changes currency to the Euro. If that is the case, as a solution it's not "fairly clumsy" it's just ridiculous. How anyone could consider this is solution is beyond me. It solves one issue and creates many more. Now the currency, date, etc. is in the wrong format. It's just clueless
interesting that *you* after abusing others in the bugtracker as well as on the mailing-list not accepting feature loss in case of DNFnow don't suck the same in other compontents *you care* and even abuse people in this thread
https://bugzilla.redhat.com/show_bug.cgi?id=1049310#c32 http://www.spinics.net/lists/fedora-devel/msg199907.html
Reindl, you actually changed my mind on that one.
On Sat, Mar 14, 2015 at 10:08 AM, Reindl Harald h.reindl@thelounge.net wrote:
Am 14.03.2015 um 15:48 schrieb Gerald B. Cox:
Regarding setting your locale to "Germany" for 24 time? Correct me if I am mistaken but that also changes currency to the Euro. If that is the case, as a solution it's not "fairly clumsy" it's just ridiculous. How anyone could consider this is solution is beyond me. It solves one issue and creates many more. Now the currency, date, etc. is in the wrong format. It's just clueless
interesting that *you* after abusing others in the bugtracker as well as on the mailing-list not accepting feature loss in case of DNFnow don't suck the same in other compontents *you care* and even abuse people in this thread
https://bugzilla.redhat.com/show_bug.cgi?id=1049310#c32 http://www.spinics.net/lists/fedora-devel/msg199907.html
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
On 03/14/15 22:36, Eike Hein wrote:
On 03/13/2015 11:52 AM, Ed Greshko wrote:
Yes, it can't be done with the graphic tool. Just pointing out the, hopefully, temporary workaround.
It can be done with the graphic tool. "Time" is its own combo box in the config page, independent from "Currency".
No, you can't. And the problem is related to being "American".
Yes, you can set the "time" setting to UK, or Germany, or whatever to get you 24hr time. *BUT* you end up getting the date in your clock in the format of dd/mm/yyyy or dd/mm/yy when we (silly) Americans want mm/dd/yy.
On 03/14/2015 04:21 PM, Ed Greshko wrote:
No, you can't. And the problem is related to being "American".
Yes, you can set the "time" setting to UK, or Germany, or whatever to get you 24hr time. *BUT* you end up getting the date in your clock in the format of dd/mm/yyyy or dd/mm/yy when we (silly) Americans want mm/dd/yy.
Date != currency. Yes, setting the time and date formats independently is currently not possible.
Cheers, Eike
On 03/15/15 00:21, Eike Hein wrote:
On 03/14/2015 04:21 PM, Ed Greshko wrote:
No, you can't. And the problem is related to being "American".
Yes, you can set the "time" setting to UK, or Germany, or whatever to get you 24hr time. *BUT* you end up getting the date in your clock in the format of dd/mm/yyyy or dd/mm/yy when we (silly) Americans want mm/dd/yy.
Date != currency. Yes, setting the time and date formats independently is currently not possible.
If you would have read the entire thread you would have seen that *I* never mentioned anything about currency!
So......
On 03/14/2015 05:50 PM, Ed Greshko wrote:
On 03/15/15 00:21, Eike Hein wrote:
Date != currency. Yes, setting the time and date formats independently is currently not possible.
If you would have read the entire thread you would have seen that *I* never mentioned anything about currency!
So......
So this thread is going downhill fast.
I just had a thought maybe Eike or Kevin would know if this is possible: How are the locale files stored? Is it possible to manually create or edit one to get around this issue?
That would certainly be a good workaround if possible...
On Sat, Mar 14, 2015 at 4:35 PM, Glenn Holmer shadowm@lyonlabs.org wrote:
On 03/14/2015 05:50 PM, Ed Greshko wrote:
On 03/15/15 00:21, Eike Hein wrote:
Date != currency. Yes, setting the time and date formats independently is currently not possible.
If you would have read the entire thread you would have seen that *I* never mentioned anything about currency!
So......
So this thread is going downhill fast.
-- Glenn Holmer (Linux registered user #16682) "After the vintage season came the aftermath -- and Cenbe." _______________________________________________ kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
On 03/15/15 09:00, Gerald B. Cox wrote:
I just had a thought maybe Eike or Kevin would know if this is possible: How are the locale files stored? Is it possible to manually create or edit one to get around this issue?
That would certainly be a good workaround if possible...
They are kept in /usr/share/i18n/locales. You probably want to create your own since your modifications may not survive an update.
On Sat, Mar 14, 2015 at 6:54 PM, Ed Greshko ed.greshko@greshko.com wrote:
They are kept in /usr/share/i18n/locales. You probably want to create your own since your modifications may not survive an update.
Thanks Ed... I looked at en_US and en_GB... looks like there is a copy function to take sections from other files. I want both the 24hour time and dd/mm/yy so I did this:
LC_TIME copy "en_GB" END LC_TIME
I'm not running Plasma5 now so not sure if that is all that is required. Also, if I renamed the file as you suggested to say "en_US2" would that show up in whatever selection mechanism Plasma5 has?
On 03/15/15 23:22, Gerald B. Cox wrote:
Thanks Ed... I looked at en_US and en_GB... looks like there is a copy function to take sections from other files. I want both the 24hour time and dd/mm/yy so I did this:
LC_TIME copy "en_GB" END LC_TIME
I'm not running Plasma5 now so not sure if that is all that is required. Also, if I renamed the file as you suggested to say "en_US2" would that show up in whatever selection mechanism Plasma5 has?
I will try this on my test system later today, time permitting....
I would also be curious to know what effect if any changing the settings in GNOME would have... On Mar 15, 2015 11:41 PM, "Ed Greshko" ed.greshko@greshko.com wrote:
On 03/15/15 23:22, Gerald B. Cox wrote:
Thanks Ed... I looked at en_US and en_GB... looks like there is a copy
function to take sections from other files. I want both the 24hour time and dd/mm/yy so I did this:
LC_TIME copy "en_GB" END LC_TIME
I'm not running Plasma5 now so not sure if that is all that is
required. Also, if I renamed the file as you suggested to say "en_US2" would that show up in whatever selection mechanism Plasma5 has?
I will try this on my test system later today, time permitting....
-- If you can't laugh at yourself, others will gladly oblige. _______________________________________________ kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
On 03/16/15 19:15, Gerald B. Cox wrote:
I would also be curious to know what effect if any changing the settings in GNOME would have...
Well, I sort of tried it today.... 2 problems....
1. Using copy en_GB gets you 24 time, but gets you dd/mm/yy in displays. 2. The new locale doesn't show up in the "Systems Settings" menu. Don't know how to get that to work. I just used "export LC_TIME=" in my .bashrc to use the new locale.
I rarely use GNOME and don't have it installed on my F22 test systems.
On Mar 15, 2015 11:41 PM, "Ed Greshko" <ed.greshko@greshko.com mailto:ed.greshko@greshko.com> wrote:
On 03/15/15 23:22, Gerald B. Cox wrote: > Thanks Ed... I looked at en_US and en_GB... looks like there is a copy function to take sections from other files. I want both the 24hour time and dd/mm/yy so I did this: > > LC_TIME > copy "en_GB" > END LC_TIME > > I'm not running Plasma5 now so not sure if that is all that is required. Also, if I renamed the file as you suggested to say "en_US2" would that show up in whatever selection mechanism Plasma5 has? I will try this on my test system later today, time permitting.... -- If you can't laugh at yourself, others will gladly oblige. _______________________________________________ kde mailing list kde@lists.fedoraproject.org <mailto:kde@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
On Mon, Mar 16, 2015 at 5:44 AM, Ed Greshko ed.greshko@greshko.com wrote:
Well, I sort of tried it today.... 2 problems....
- Using copy en_GB gets you 24 time, but gets you dd/mm/yy in displays.
- The new locale doesn't show up in the "Systems Settings" menu. Don't
know how to get that to work. I just used "export LC_TIME=" in my .bashrc to use the new locale.
I rarely use GNOME and don't have it installed on my F22 test systems.
OK, I expected to get dd/mm/yy since it was using en_GB, so it's working as I thought. I looked here: http://en.wikipedia.org/wiki/Date_format_by_country and it appears that at first glance no country exists which uses 24 hour time and mm/dd/yy so the actual code will need to be edited rather than making a copy... I'll take a shot at that and post.
I am on travel with just my laptop (that I need) so can't install Plasma5 here with me. You might consider installing GNOME and giving it a shot. There was another instance I ran into where KDE couldn't do something but if you did it in GNOME the settings were picked up and displayed correctly in KDE. If it were to work a temporary workaround could be for people to install GNOME to do the configuration.
Gerald B. Cox composed on 2015-03-16 07:28 (UTC-0700):
On Mon, Mar 16, 2015 at 5:44 AM, Ed Greshko ed.greshko@greshko.com wrote:
Well, I sort of tried it today.... 2 problems....
- Using copy en_GB gets you 24 time, but gets you dd/mm/yy in displays.
- The new locale doesn't show up in the "Systems Settings" menu. Don't
know how to get that to work. I just used "export LC_TIME=" in my .bashrc to use the new locale.
I rarely use GNOME and don't have it installed on my F22 test systems.
OK, I expected to get dd/mm/yy since it was using en_GB, so it's working as I thought. I looked here: http://en.wikipedia.org/wiki/Date_format_by_country and it appears that at first glance no country exists which uses 24 hour time and mm/dd/yy so the actual code will need to be edited rather than making a copy... I'll take a shot at that and post.
Maybe it's a good time to think about switching to unabiguous iso formats. I much prefer the unambiguous, sortable, big-endian date format, and 24 hour days that each have 24 hours in them 100% numerically, two formats which can be combined into one accurate and sortable string of digits with a single decimal to segregate calendar from clock.
Maybe try en_DK for a while?
On 14 March 2015 at 12:21, Eike Hein wrote:
setting the time and date formats independently is currently not possible.
Having the source code, anything should be possible. My question is what is the easiest way to hack around this issue and set time and date formats independently? Environment variables? Hardcoding the time and date formats in KDE (Qt?) source code?
Thanks, Orcan
On Sat, 2015-03-14 at 23:21 +0800, Ed Greshko wrote:
On 03/14/15 22:36, Eike Hein wrote:
On 03/13/2015 11:52 AM, Ed Greshko wrote:
Yes, it can't be done with the graphic tool. Just pointing out the, hopefully, temporary workaround.
It can be done with the graphic tool. "Time" is its own combo box in the config page, independent from "Currency".
No, you can't. And the problem is related to being "American".
Yes, you can set the "time" setting to UK, or Germany, or whatever to get you 24hr time. *BUT* you end up getting the date in your clock in the format of dd/mm/yyyy or dd/mm/yy when we (silly) Americans want mm/dd/yy.
Actually, most of the people who call themselves American use the dd/mm/yy format. I refer to every other country in the Americas apart from the US.
US nationals are perfectly entitled to call themselves Americans of course, just be aware that other nationalities also do so. That's why the locale settings don't say American, they say US (or VE, BR, CA, etc. as the case may be).
poc
On 03/15/15 02:19, Patrick O'Callaghan wrote:
On Sat, 2015-03-14 at 23:21 +0800, Ed Greshko wrote:
On 03/14/15 22:36, Eike Hein wrote:
On 03/13/2015 11:52 AM, Ed Greshko wrote:
Yes, it can't be done with the graphic tool. Just pointing out the, hopefully, temporary workaround.
It can be done with the graphic tool. "Time" is its own combo box in the config page, independent from "Currency".
No, you can't. And the problem is related to being "American".
Yes, you can set the "time" setting to UK, or Germany, or whatever to get you 24hr time. *BUT* you end up getting the date in your clock in the format of dd/mm/yyyy or dd/mm/yy when we (silly) Americans want mm/dd/yy.
Actually, most of the people who call themselves American use the dd/mm/yy format. I refer to every other country in the Americas apart from the US.
Pedantic much? :-) :-)
In the spirit of being "pedantic" I will point out that I first used quotes around "American" to indicate it wasn't related to the entire continent of North American or South American. And, incidentally, most folks know that Canadians, Mexicans, and people living in countries other than the USA don't commonly refer to themselves as Americans.
On Sun, 2015-03-15 at 06:57 +0800, Ed Greshko wrote:
Actually, most of the people who call themselves American use the dd/mm/yy format. I refer to every other country in the Americas
apart
from the US.
Pedantic much? :-) :-)
Well if we can't be pedantic, what's the point :-)
In the spirit of being "pedantic" I will point out that I first used quotes around "American" to indicate it wasn't related to the entire continent of North American or South American. And, incidentally, most folks know that Canadians, Mexicans, and people living in countries other than the USA don't commonly refer to themselves as Americans.
It depends on context. I lived in South America for over 30 years and I can assure you that whenever people saw a movie, TV show, political speech or whatever from the US in which "American" was used in the sense of nationality (which is close to 100% of the time), many people would react negatively, essentially saying "we're American too". And I don't mean hot-headed radicals but ordinary people without strong political leanings.
However this is now getting OT.
poc
On 03/11/2015 08:14 PM, Gerald B. Cox wrote:
People can wax poetic about the reasons but that doesn't change the fact that the functionality is gone; people have noticed and aren't at all pleased. Telling an end user that they have lost functionality but hey "the behavior and scope..." isn't going to fly. Their eyes will glaze over and they'll say WTF?
If Plasma5 gets into a major distribution (such as Fedora) without this being fixed you ain't heard nothing yet.
+1
Eike Hein wrote:
This is a biased and incomplete explanation. While I personally lament the loss of KLocale's functionality as well, the motivation in switching to Qt's locale system was mainly that the behavior and scope it im- plements aligns closely with the rest of desktop Linux, which KLocale always had trouble mapping to - application of settings and behavior is now more con- sistent between KDE's apps and other Qt apps, as well as Linux desktop apps not using Qt at all.
The problem is that QLocale doesn't support the POSIX LC_TIME, LC_NUMERIC etc. either, it also does its own thing, and supports only LANG from the POSIX locale system.
So we traded a system that was incompatible with POSIX because it was MORE flexible than the POSIX LC_* variables with one that is also incompatible with POSIX LC_*, but because it is LESS flexible. :-(
Kevin Kofler
-
Ed Greshko -
Eike Hein -
Felix Miata -
Gerald B. Cox -
Glenn Holmer -
Kevin Kofler -
Luigi Toscano -
Orcan Ogetbil -
Patrick O'Callaghan -
Reindl Harald