Re: Munich Sprint

[John Layt]

On 18 April 2016 at 22:50, dennis knorr  wrote:

> as far as i am aware, kprinter from credativ was only a part which was
> needed. The old kde printing system had more features. but as i explain
> in my other mail, i first wanted to tidy up our issues before
> "ambushing" you. :)

There's still a lot of features missing from QtPrintSupport and it
needs a fundamental re-write to support modern print systems (e.g,
pull printing, IPP, cloud services, etc). The underlying architecture
is designed and parts implemented, but to bring it to completion is
not a weekend activity (my last change-set took 6 months and almost
broke me). Funding needs to be found in the Qt community to support at
least a years full-time work to implement everything needed on all the
platforms. Sadly, seems no-one is interested in paying for such
un-sexy work, because supposedly we live in a paperless society...

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Munich Sprint

[John Layt]

On 18 April 2016 at 20:58, John Layt <jl...@kde.org> wrote:
> That would be kprinter. Credative / Limux had a replacement for KDE4
> called kprinter4 (part of which is a poorly-attributed fork of some
> code I wrote for Okular):
>
> http://kde-apps.org/content/show.php/KPrinter4?content=163537
> https://quickgit.kde.org/?p=kprinter4.git
>
> It's in playground, been meaning to have a poke at it to see if it's
> still of any use. AFAIK though it only works on postscript files and
> relies on very old tools like poster, but it shouldn't take much to
> generalise it for all file types supported by CUPS, and to update to
> more modern PDF-based tools. Add in a Dolphin service for a context
> menu print option and it's done. Perhaps a small porting project for
> someone to bring it into Plasma5?

So I spent a couple of hours writing a new one with correct copyrights
on it, basically my Okular code ported to Qt5 and wrapped in a command
line call. Pretty basic so far but takes a filename or shows the file
dialog, then shows the print dialog, then sends it to the printer.
Lots of polishing required, Linux/CUPS only, yadda yadda, but if
there's interest I'll try finish it this weekend and put it up for
review. Any suggestions where this should live?

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Munich Sprint

[John Layt]

On 18 April 2016 at 16:14, Kai Uwe Broulik  wrote:

> * something about a printing tool kde 3 had we lost

That would be kprinter. Credative / Limux had a replacement for KDE4
called kprinter4 (part of which is a poorly-attributed fork of some
code I wrote for Okular):

http://kde-apps.org/content/show.php/KPrinter4?content=163537
https://quickgit.kde.org/?p=kprinter4.git

It's in playground, been meaning to have a poke at it to see if it's
still of any use. AFAIK though it only works on postscript files and
relies on very old tools like poster, but it shouldn't take much to
generalise it for all file types supported by CUPS, and to update to
more modern PDF-based tools. Add in a Dolphin service for a context
menu print option and it's done. Perhaps a small porting project for
someone to bring it into Plasma5?

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [KDE/Mac] systemsettings, kde-cli-tools and other plasma components on non-Plasma/non-X11 platforms

[John Layt]

Hi,

Drive-by comment, no time to read the full thread so not sure if it's been
said, but I thought I'd just refresh memories on what we discussed at an
Akademy a few years back. The general consensus was that forcing
Mac/Windows/Gnome users to install Systemsettings just to configure their
standalone app was A Bad Thing (TM) and shouldn't be done. It required
specialised knowledge of what to do and where to look that we couldn't
expect from new users or users of other platforms. Installing a 'KDE
Settings' module in the host settings program (Mac System Preferences or
Windows Control Panel) was also ruled out for the same reason: what new
user knows to go there, or even knows the app comes from KDE? The user's
mental model is they are not configuring a desktop or group of apps from
the same 'manufacturer', but rather they are configuring a single app they
have downloaded and installed.

The agreed correct behaviour when we could not use the host settings or
services for something was that the config for the KDE replacement must be
directly accessible where the user expects it to be, that is in the
application's settings, either in the main config dialog or where
appropriate as a separate menu item in the help menu. Note this does not
mean launching Systemsettings, but rather embedding the individual KCM
modules that the app requires. So, for example, if an app requires access
to KWallet, then the KWallet KCM should be embedded in the app's config
dialog (even if this config is perhaps shared with other KDE apps they have
installed).

Obviously our KCM tech makes this relatively straight-forward to do if the
KCM modules are split out correctly. What needs doing is to determine what
KCM's are needed by apps on other platforms and to ensure these are
installable separately from Systemsettings so the devs and packagers can
pull them in as required.

Note too that this model was intended to apply to running under Gnome as
well. If you install Krita under Gnome, you shouldn't have to install and
run KDE Systemsettings just to get the right fonts or use your desktop
wallet. This implies that the decision on whether to display the required
KCM's in the App dialog or Systemsettings is not a build-time one but
rather a run-time one, i.e. if running under a non-KDE desktop where we
can't use the host config then embed the KCM, otherwise don't. This
obviously requires work on the individual apps themselves to define what
they depend on, but also perhaps some common library code in KCM to make
this easy, and libraries like KWallet need to define on what platforms
their KCM is required. It was this work that we never got around to doing
and that needs better defining if we're ever to get serious about
cross-platform support.

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 124885: Fix issues in translation control module

[John Layt]

 On Aug. 23, 2015, 2:47 a.m., Jeremy Whiting wrote:
  Ship It!
 
 Jeremy Whiting wrote:
 Incidentally, the pt issue sounds like a QLocale bug, do we need to find 
 one or file a new one for that probably?

Yeah, looks a Qt bug, it has a table from CLDR of default countries to use so 
there's something wrong with the lookup. I'm not aware of a bug report for that 
so go ahead.

That, or Thiago has rigged it so he always gets pt_BR :-)


- John


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124885/#review84202
---


On Aug. 23, 2015, 1:34 a.m., Albert Astals Cid wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/124885/
 ---
 
 (Updated Aug. 23, 2015, 1:34 a.m.)
 
 
 Review request for Plasma.
 
 
 Bugs: 345761 and 347956
 https://bugs.kde.org/show_bug.cgi?id=345761
 https://bugs.kde.org/show_bug.cgi?id=347956
 
 
 Repository: plasma-desktop
 
 
 Description
 ---
 
 Fixes two problems:
  * Variants not being shown up, i.e. ca ca@valencia showing up both as 
 català
  * pt showing up as português do Brasil
 
 For the first one i've went the easy route of adding the languageCode if 
 there's an @ in it
 For pt i hard to hard code it since i found no other way to make Qt 
 understand that for pt we mean portuguese from portugal
 
 
 Diffs
 -
 
   kcms/translations/kcmtranslations.cpp e5024e2 
 
 Diff: https://git.reviewboard.kde.org/r/124885/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Albert Astals Cid
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 122488: Improved calendar navigation

[John Layt]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122488/#review83024
---


Fantastic to see this :-) Pretty much as I documented it at 
https://community.kde.org/Plasma/Clock#Zooming_Calendar (which was a serious 
crib from Windows anyway :-) ). The thing to add for the future will be 
clicking on the day takes you to an Agenda view with your calendar and holidays 
and even weather forecast for that day :-)

- John Layt


On July 27, 2015, 10:43 a.m., Kai Uwe Broulik wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/122488/
 ---
 
 (Updated July 27, 2015, 10:43 a.m.)
 
 
 Review request for Plasma and KDE Usability.
 
 
 Repository: plasma-framework
 
 
 Description
 ---
 
 This improves the calendar navigation by providing a Year overview showing 
 all 12 months in a grid, and a Decade overview showing the current decade 
 in a grid.
 
 A lot of code has just been moved around. The overviews use a QML ListModel 
 owing to laziness.
 
 See https://www.youtube.com/watch?v=7SaBhRa32ds for a screencast (I love that 
 mouse click effect!)
 
 
 Diffs
 -
 
   src/declarativeimports/calendar/qml/MonthView.qml 601755f 
   src/declarativeimports/calendar/qml/DaysCalendar.qml ab3e750 
   src/declarativeimports/calendar/qml/DayDelegate.qml 6a3747e 
   src/declarativeimports/calendar/daysmodel.cpp 1a6f454 
   src/declarativeimports/calendar/daysmodel.h e1285f6 
   src/declarativeimports/calendar/daydata.h 39ac086 
   src/declarativeimports/calendar/calendar.h 5dc3081 
   src/declarativeimports/calendar/calendar.cpp c462dbd 
 
 Diff: https://git.reviewboard.kde.org/r/122488/diff/
 
 
 Testing
 ---
 
 I changed the selection to be persistent during navigation; other than that, 
 should work as before, with the new overviews.
 
 
 Thanks,
 
 Kai Uwe Broulik
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

KHolidays 5 branch

[John Layt]

Hi,

I've just pushed a new branch called kf5-port to the kholidays
repository for people to look at. This contains the set of api changes
I wanted to make and attempts to remove the kdelibs4support
dependency.

Could someone who understands CMake better than me have a look at the
last commit, as it refuses to link to QWidget once I remove the
kdelibs4support linkage.

Once that's fixed, what's the next step, do people want to see each
individual change go on review board? Or do I just push and get it
tagged for the next frameworks release?

The api changes are pretty self-explanatory, but there's a couple of
interim measures needed to plug gaps in Qt to allow removing
kdelibs4support usage:

1) I've replaced KCalendarSystem with a private copy of
QCalendarSystem until it is merged into Qt

2) I've had to import some private Qt code for converting ISO codes to
QLocale language and country enums until Qt adds the required public
api or I finish OpenCodes.

I've kept the astronomical and astrological classes, but haven't
looked at them in detail. I was wondering if we want to add private
d-pointers to them just to be safe?

Some other possible changes remain, but are not really necessary for
the first release:

1) Change from ki18n to tr

2) Make the widget and designer plugin build fully optional (any CMake
wizard care to do it?)

3) Add the Holiday Category public api

Cheers!

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Request: better override functionality in locale settings

[John Layt]

On 28 August 2014 09:31, Harald Sitter sit...@kde.org wrote:
 On Thu, Aug 28, 2014 at 3:49 AM, Matthew Ruffalo mm...@case.edu wrote:

 Perhaps I am leaning myself way out the window but I think there is
 one very portable solution to this problem: writing an own locale
 defintion [1] and installingconfiguring that. And I do not mean by
 hand, but through a GUI.
 This not only allows customization of stuff but also makes every
 application on the system respect whatever was configured in our KCM.
 Also it doesn't actually tie into the existing KCM, it would be a
 standalone 'locale editor' basically.

That is indeed The Plan, at least for non-Qt POSIX / glibc using apps :-)

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Request: better override functionality in locale settings

[John Layt]

On 28 August 2014 09:28, Martin Klapetek martin.klape...@gmail.com wrote:
 On Wed, Aug 27, 2014 at 11:34 AM, Sebastian Kügler se...@kde.org wrote:


 There's more than just metric and imperial. This page gives you a slight
 impression of the complexity:
 http://en.wikipedia.org/wiki/Imperial_units#Current_use_of_imperial_units

 A binary combobox is just not enough to portray this correctly.


 I'm actually quite curious what does QLocale do with this complexity. Do
 they really do

 if (en_GB) {
 beer_unit = pint;
 milk_unit = liter;
 etc...
 }

 That would be quite strange. I'll investigate and post back.

Yes, the locale code for each each category does determine what
translations will get used for that category.  While Qt doesn't (yet)
have that level of complexity, other toolkits may, such as glibc or
gtk or Java or ICU.  We're setting a desktop-wide setting here, not
just something for KDE/Qt apps only to use.

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Request: better override functionality in locale settings

[John Layt]

Hi,

Just to add to the background (and seeing as I'm the primary culprit
in the death of KLocale and the slow pace of improvements to QLocale),
there's 2 very big reasons for removing it (and the consequent loss of
the customization feature):
1) It was very big and a maintenance burden, especially when Qt
provides good-enough facilities for most purposes. The size stopped
people using KDE libraries and reduced the number of potential KDE
apps, and adding new features like proper collation and spell-out
formatting would have taken a lot of duplicated work.
2) It was a walled garden, only KDE apps used the settings, all other
apps ignored them, and KDE apps running on other desktops/platforms
ignored their host settings, leaving an inconsistent user experience.

Just setting the standard POSIX codes has one very big advantage in
being universal: all apps running under Plasma will respect them,
rather than just KDE apps. If we implement a Qt-only solution then any
POSIX/glibc/Java/Firefox/Chrome/etc apps will look out-of-place again,
as they did under KDE4.  Any solution needs to apply to everything
(even if not everything is implemented at once).

We do want the configurability back, I use it myself, but there's a
series of technical steps we need to achieve first. The first is
removing Qt's own locale system which has the same size/maintenance
problems and has hard-coded locale data that cannot be changed, as
well as being short on some features. I've written 3 different
solutions so far over the last 2 years and none have been accepted. We
do now have a fourth design that has come out of these efforts, and I
have some code towards it, but I estimate it as a 6 month full-time
effort to get it implemented, tested and integrated, as it is nothing
less than a complete rewrite of all of QLocale for every platform Qt
supports without breaking any previous behaviour or api. That is time
I don't have to give right now, and no-one in the Qt world seems
interested in paying for it in spite of many people wanting it (just
like printing really).

The design is basically to wrap the host services on each platform in
a common api, with ICU as the chosen backend on Linux due to
POSIX/glibc localization being totally useless. Unfortunately that
means we end up catering for some lowest common denominator feature
set, in this case Windows XP.  If we ignore XP (and we will) then it's
better but still not what we really want, and the current debate is
whether we have an advanced api in QtCore that degrades gracefully on
Windows, or if the advanced features go in a new QtLocale add-on
module.

Even once this full rewrite of QLocale is completed, that still
doesn't give us the ability to edit individual settings on Linux (only
Win and Mac), but it does set the precedent that QLocale should
respect the users override settings and so make it acceptable to add
some 'hacks' into Qt on Linux to make it work.  For Qt the mechanism
will probably be a small json file that stores the custom overrides
that QLocale loads and then applies as overrides when calling in to
ICU.

But even once Qt reads and uses our custom settings, that still
doesn't apply those settings to POSIX / glibc / gtk apps, we need an
extra step there as well. There is a hack we could use, which is that
the System Settings module could save a POSIX format locale file with
the custom settings and set the LC_* envvar to point directly to the
file, but that would require all toolkits to correctly implement the
POSIX standard and I'm not convinced they do.  Alternatively we could
ask the user for the root password and install the locale file
globally, but I'm not keen on that.  It also doesn't solve things for
apps that use ICU directly, like Chrome, where we have no possible
solution.

All that is besides the point with the System Settings module.  We did
say at the time that a drop-down with 200+ entries was probably not
the best solution, but it was an interim implementation for 5.0.  I'm
sure with a little thought we can come up with a better way of
managing such long lists, for example with a pop-up selector which
includes filters by language or region, or something like that.
Perhaps for metric/imperial we could be a little smarter and use the
users chosen language or default locale to guess at a suitable
locale match to use.  For date/time format overrides, well that I'm
afraid belongs in individual apps and plasmoids for now.

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Request: better override functionality in locale settings

[John Layt]

Hi,

Just to add to the background (and seeing as I'm the primary culprit
in the death of KLocale and the slow pace of improvements to QLocale),
there's 2 very big reasons for removing it (and the consequent loss of
the customization feature):
1) It was very big and a maintenance burden, especially when Qt
provides good-enough facilities for most purposes. The size stopped
people using KDE libraries and reduced the number of potential KDE
apps, and adding new features like proper collation and spell-out
formatting would have taken a lot of duplicated work.
2) It was a walled garden, only KDE apps used the settings, all other
apps ignored them, and KDE apps running on other desktops/platforms
ignored their host settings, leaving an inconsistent user experience.

Just setting the standard POSIX codes has one very big advantage in
being universal: all apps running under Plasma will respect them,
rather than just KDE apps. If we implement a Qt-only solution then any
POSIX/glibc/Java/Firefox/
Chrome/etc apps will look out-of-place again,
as they did under KDE4.  Any solution needs to apply to everything
(even if not everything is implemented at once).

We do want the configurability back, I use it myself, but there's a
series of technical steps we need to achieve first. The first is
removing Qt's own locale system which has the same size/maintenance
problems and has hard-coded locale data that cannot be changed, as
well as being short on some features. I've written 3 different
solutions so far over the last 2 years and none have been accepted. We
do now have a fourth design that has come out of these efforts, and I
have some code towards it, but I estimate it as a 6 month full-time
effort to get it implemented, tested and integrated, as it is nothing
less than a complete rewrite of all of QLocale for every platform Qt
supports without breaking any previous behaviour or api. That is time
I don't have to give right now, and no-one in the Qt world seems
interested in paying for it in spite of many people wanting it (just
like printing really).

The design is basically to wrap the host services on each platform in
a common api, with ICU as the chosen backend on Linux due to
POSIX/glibc localization being totally useless. Unfortunately that
means we end up catering for some lowest common denominator feature
set, in this case Windows XP.  If we ignore XP (and we will) then it's
better but still not what we really want, and the current debate is
whether we have an advanced api in QtCore that degrades gracefully on
Windows, or if the advanced features go in a new QtLocale add-on
module.

Even once this full rewrite of QLocale is completed, that still
doesn't give us the ability to edit individual settings on Linux (only
Win and Mac), but it does set the precedent that QLocale should
respect the users override settings and so make it acceptable to add
some 'hacks' into Qt on Linux to make it work.  For Qt the mechanism
will probably be a small json file that stores the custom overrides
that QLocale loads and then applies as overrides when calling in to
ICU.

But even once Qt reads and uses our custom settings, that still
doesn't apply those settings to POSIX / glibc / gtk apps, we need an
extra step there as well. There is a hack we could use, which is that
the System Settings module could save a POSIX format locale file with
the custom settings and set the LC_* envvar to point directly to the
file, but that would require all toolkits to correctly implement the
POSIX standard and I'm not convinced they do.  Alternatively we could
ask the user for the root password and install the locale file
globally, but I'm not keen on that.  It also doesn't solve things for
apps that use ICU directly, like Chrome, where we have no possible
solution.

All that is besides the point with the System Settings module.  We did
say at the time that a drop-down with 200+ entries was probably not
the best solution, but it was an interim implementation for 5.0.  I'm
sure with a little thought we can come up with a better way of
managing such long lists, for example with a pop-up selector which
includes filters by language or region, or something like that.
Perhaps for metric/imperial we could be a little smarter and use the
users chosen language or default locale to guess at a suitable
locale match to use.  For date/time format overrides, well that I'm
afraid belongs in individual apps and plasmoids for now.

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma 5 RC

[John Layt]

On 7 July 2014 10:16, Jonathan Riddell j...@jriddell.org wrote:
 On Fri, Jul 04, 2014 at 10:36:00AM +0100, John Layt wrote:
 Co-installabilty of Plasma 4 and Plasma 5 with minimal work required
 by the distros is a must if we want to avoid the mess of KDE4.
 Already openSUSE has announced that you can't have both installed at
 once, which will force people to choose one or other, when what we
 really want is for them to be able to try Plasma 5 out while still
 being able to switch back to 4 if there are things that break their
 workflow.

 They won't be co-installable just as konsole won't be co-installable
 with its kdelibs4 version, it's a new version of the same programme.
 But the parts that are used by applications, libraries and runtime
 parts need to be co-installable so kdelibs4 and kf5 applications can
 be installed on the same system.

Hmmm, well that's not quite what I was expecting, I was hoping to be
able to install them in parallel and test it out while keeping my old
desktop safe, like I can install and try Gnome or Unity or XFCE.  I
don't expect to have parallel installs of apps though, the latest
version should just run under any desktop.  No Plasma 5 for me then
until a couple more releases and it's stabilised :-\

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [kde-packager] Re: [kde-packager] Plasma 5 RC

[John Layt]

On 4 July 2014 10:13, Vishesh Handa m...@vhanda.in wrote:
 On Fri, Jul 4, 2014 at 10:59 AM, Jonathan Riddell j...@jriddell.org wrote:

 I renamed baloo's tar to baloo5 because it contains some libraries
 which most distros will want to co-install so I'd expect baloo
 (kdelibs4) and baloo (kf5) to exist in distro archives together, for
 which they need different names.  kfilemetadata is similar.  milou is
 probably a mistake, that won't co-exist.

 A similar case exists for kactivites. It existed in kde4 as well and the
 current framework has the same name.

 I would really like the tarballs to have the same name. Also, baloo4 and 5
 are not really co-installable. They both ship executables with the same
 name.

Co-installabilty of Plasma 4 and Plasma 5 with minimal work required
by the distros is a must if we want to avoid the mess of KDE4.
Already openSUSE has announced that you can't have both installed at
once, which will force people to choose one or other, when what we
really want is for them to be able to try Plasma 5 out while still
being able to switch back to 4 if there are things that break their
workflow.

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [kde-packager] Re: [kde-packager] Plasma 5 RC

[John Layt]

On 4 July 2014 10:13, Vishesh Handa m...@vhanda.in wrote:
 On Fri, Jul 4, 2014 at 10:59 AM, Jonathan Riddell j...@jriddell.org wrote:

 I renamed baloo's tar to baloo5 because it contains some libraries
 which most distros will want to co-install so I'd expect baloo
 (kdelibs4) and baloo (kf5) to exist in distro archives together, for
 which they need different names.  kfilemetadata is similar.  milou is
 probably a mistake, that won't co-exist.


 A similar case exists for kactivites. It existed in kde4 as well and the
 current framework has the same name.

 I would really like the tarballs to have the same name. Also, baloo4 and 5
 are not really co-installable. They both ship executables with the same
 name.

Co-installabilty of Plasma 4 and Plasma 5 with minimal work required
by the distros is a must if we want to avoid the mess of KDE4.
Already openSUSE has announced that you can't have both installed at
once, which will force people to choose one or other, when what we
really want is for them to be able to try Plasma 5 out while still
being able to switch back to 4 if there are things that break their
workflow.

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 119103: Startkde: Remove KLOCALE_LANGUAGES

[John Layt]

 On July 3, 2014, 12:41 p.m., Aleix Pol Gonzalez wrote:
  Don't we still need to pass the language somehow? or now it will be enough 
  with $LANG?
 
 Vishesh Handa wrote:
 KLocale languages had a list of languages. The first one being the main 
 one, and others being fallbacks. We no longer seem to support this multiple 
 languages option in QLocale.
 
 I'm not familiar with KSplash internals and why we ever needed to pass 
 the languages variable at all.
 
 Sebastian Kügler wrote:
 We still support it, but it's now the $LANGUAGES variable (which in 
 contrast to $LANG is a list of languages, preferred and fallback). In 
 principle, this patch is fine, I'd go with let's kill KLOCALE_LANG and see 
 what breaks, but on RC-tagging-day, this might not be the most prudent thing 
 to do.
 
 I'm also not familiar with KSplash, but with the current design we ship, 
 there's nothing translated there, anyway, so it's not like we're breaking the 
 default setup.
 
 Vishesh Handa wrote:
 So, I ship this tomorrow after the tagging?

A quick grep shows this is the *only* place that $KLOCALE_LANGUAGES gets used, 
and it gets unset immediately afterwards, so the entire process is redundant if 
KSPlash doesn't use it.  I don't know why KSplash needed it before, but now it 
could use $LANGUAGES instead, or QLocale().uiLanguages() after $LANGUAGES is 
set.


- John


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119103/#review61543
---


On July 3, 2014, 12:25 p.m., Vishesh Handa wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119103/
 ---
 
 (Updated July 3, 2014, 12:25 p.m.)
 
 
 Review request for Plasma.
 
 
 Repository: plasma-workspace
 
 
 Description
 ---
 
 Startkde: Remove KLOCALE_LANGUAGES
 
 KLOCALE_LANGUAGES was used by the kde4 ksplash in order to to know which
 language to show. This environment variable is no longer used by the qml
 based ksplash. It makes no sense to have it.
 
 Additionally, this means we can stop linking against kdelibs4support.
 This is important cause kdostartupconfig blocks the rest of the boot
 sequence. On my system it causes a good 0.3 - 0.4 seconds delay. By no
 longer linking to kdelibs4support it takes less than 0.1 seconds and no
 longer shows up in the bootchat logs.
 
 
 Diffs
 -
 
   startkde/kstartupconfig/CMakeLists.txt 6920fe5 
   startkde/kstartupconfig/kdostartupconfig.cpp d545f4f 
   startkde/startkde.cmake 40e3377 
 
 Diff: https://git.reviewboard.kde.org/r/119103/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Vishesh Handa
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Locale Name Primer

[John Layt]

Locale Names.

A quick primer on Locale Names, seeing as we've had a few issues in
the last couple of days. I can't claim perfect knowledge, so feel free
to point out where I am wrong :-)

TL;DR:
* Don't use QLocale::bcp47Name().
* Use QLocale::name(), but may need to modify the results.
* You usually want QLocale().name() and not QLocale::system().name()
* Don't assume language code is alpha-2, it may be alpha-3
* Always use case insensitive comparisons.
* I'll improve support in Qt 5.4.

POSIX Locale:
* What we use on Linux systems and in glibc.
* Format is lang_REGION.encoding@variant.
* How many of those componants are included can depend on the system
or implementation.  In most cases the language and region are always
included, with the encoding and variant optional.
* lang is ISO 639 alpha-2 or alpha-3 (so QLocale().name().left(2) is
not valid!) , usually in lower case
* REGION is ISO 3166 alpha-2, usually in upper case
* Many distros explicitly add .utf8 or .UTF-8 for Unicode, e.g. on
openSUSE en_GB.utf8 uses UTF-8 but en_GB uses ISO-8859-1.
* The variant is usually used to change the script, but doesn't use an
ISO code for this e.g. sr_RS uses Cyrillic script but sr_RS@latin
uses Latin script
* The variant can change other options like the currency, e.g. de_DE@euro
* Always use case-insensitive comparison as case of codes is meaningless
* Run locale -a to see what your distro has installed

BCP47 Locale:
* IETF RFC, used in Unicode, W3C standards, etc.
* Used in Windows Vista and later, where it replaces the old LCID.
* Basic format is lang-Script-REGION-variants-extensions
* Always uses hyphen as a subtag separator
* Always uses minimum subtags required to uniquly identify locale,
e.g. de-Latn-DE will be reduced to de as Latn and DE are the
assumed defaults.
* lang is ISO 639 alpha-2 or alpha-3 code, usually in lower case
* Script is ISO 15924 alpha4 code usually in title case
* REGION is ISO 3166 alpha 2 code, usually in upper case
* variant are registered variant codes
* extensions are registered extension codes
* Always use case-insensitive comparison as case of codes is meaningless

Qt 5.3 support:
* name() always returns lang_REGION, except where AnyCountry is set
or C, never returns encoding or variant
* bcp57Name() returns the minimal BCP47 name
* No direct may to get lang or country code, need to use
QLocale().name().split('_').at(x)

Needed in Qt 5.4:
* languageCode()
* countryCode()
* scriptCode()
* posixName()
* encoding?

Cheers!

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118584: Formats KCM: Use QLocale::name() instead of bcp47Name() when writing to the configuration file

[John Layt]

 On June 6, 2014, 11:53 a.m., Sebastian Kügler wrote:
  I'd like to hear John's take on this. IIRC, bcp47Name() is the correct one 
  to use here. (Which leaves questions indeed.)
 
 Luca Beltrame wrote:
 Indeed. But for some reason, at least on my system, bcp47Name() returns 
 it only, and that breaks everything. Hence the reason for this patch.
 Also I wanted indeed to wait till the pros gave their answers. ;)

Please don't make me read the BCP47 standard again: it's long and complicated 
and ambiguous and I read it three times and still didn't understand it :-) What 
I do remember with BCP47 is that the standard states it should always return 
the minimal code required to identify a locale.  For example, if your locale 
fully expressed is it_IT@Latn then bcp47name() returns just it as Italy and 
Latin are the default country and script values for Italian and so are 
unneeded.  This compares to name() which will always return the form 
language_COUNTRY regardless of the locale (unless country is explicitly set to 
AnyCountry) but will always leave off the script for backwards compatibility 
reasons.  I need to go back to the POSIX standard to check, but I think it 
expects to have the country explicitly included, but the script only if not the 
default (or not Latn?).  If so Qt needs a posixName() which we'd need to 
simulate for now.  I also need to look into the .UTF-8 stuff as well.


- John


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118584/#review59407
---


On June 6, 2014, 7:45 a.m., Luca Beltrame wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/118584/
 ---
 
 (Updated June 6, 2014, 7:45 a.m.)
 
 
 Review request for Plasma, John Layt and Sebastian Kügler.
 
 
 Repository: plasma-desktop
 
 
 Description
 ---
 
 Currently the Formats KCM writes its configuration file using the selected 
 locale's bcp47Name(). This, at least on my distro, breaks locale loading as 
 locales are in the form foo_FOO (e.g., it_IT for my own locale) and 
 instead the Formats KCM exports LANG as foo (e.g. it).
 
 This causes a bunch of runtime warnings and locales don't get actually 
 loaded. This patch's approach is naive and likely needs more pairs of eyes on 
 it, as I can't test with other distros.
 
 Also we might need UTF-8 suffix for distros that use UTF-8 locales: or so I 
 think, but I'm not knowledgeable enough to tell if this is needed or not.
 
 
 Diffs
 -
 
   kcms/formats/kcmformats.cpp 4169244 
 
 Diff: https://git.reviewboard.kde.org/r/118584/diff/
 
 
 Testing
 ---
 
 Compiled, ran the Formats KCM, selected my country, inspected the generated 
 files.
 
 
 Thanks,
 
 Luca Beltrame
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118584: Formats KCM: Use QLocale::name() instead of bcp47Name() when writing to the configuration file

[John Layt]

 On June 6, 2014, 11:53 a.m., Sebastian Kügler wrote:
  I'd like to hear John's take on this. IIRC, bcp47Name() is the correct one 
  to use here. (Which leaves questions indeed.)
 
 Luca Beltrame wrote:
 Indeed. But for some reason, at least on my system, bcp47Name() returns 
 it only, and that breaks everything. Hence the reason for this patch.
 Also I wanted indeed to wait till the pros gave their answers. ;)
 
 John Layt wrote:
 Please don't make me read the BCP47 standard again: it's long and 
 complicated and ambiguous and I read it three times and still didn't 
 understand it :-) What I do remember with BCP47 is that the standard states 
 it should always return the minimal code required to identify a locale.  For 
 example, if your locale fully expressed is it_IT@Latn then bcp47name() 
 returns just it as Italy and Latin are the default country and script 
 values for Italian and so are unneeded.  This compares to name() which will 
 always return the form language_COUNTRY regardless of the locale (unless 
 country is explicitly set to AnyCountry) but will always leave off the script 
 for backwards compatibility reasons.  I need to go back to the POSIX standard 
 to check, but I think it expects to have the country explicitly included, but 
 the script only if not the default (or not Latn?).  If so Qt needs a 
 posixName() which we'd need to simulate for now.  I also need to look into 
 the .UTF-8 stuff as well
 .

OK, checked POSIX and it always expects the country to be included, so name() 
is closer to what we want than bcp47Name(). We also need to add the .encoding 
and @script when not the default, but I'm still working on the rules for that.  
My opinion is ship it, as it improves the situation and fixes many issues, but 
isn't the full solution so add a TODO note in the code.


- John


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118584/#review59407
---


On June 6, 2014, 7:45 a.m., Luca Beltrame wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/118584/
 ---
 
 (Updated June 6, 2014, 7:45 a.m.)
 
 
 Review request for Plasma, John Layt and Sebastian Kügler.
 
 
 Repository: plasma-desktop
 
 
 Description
 ---
 
 Currently the Formats KCM writes its configuration file using the selected 
 locale's bcp47Name(). This, at least on my distro, breaks locale loading as 
 locales are in the form foo_FOO (e.g., it_IT for my own locale) and 
 instead the Formats KCM exports LANG as foo (e.g. it).
 
 This causes a bunch of runtime warnings and locales don't get actually 
 loaded. This patch's approach is naive and likely needs more pairs of eyes on 
 it, as I can't test with other distros.
 
 Also we might need UTF-8 suffix for distros that use UTF-8 locales: or so I 
 think, but I'm not knowledgeable enough to tell if this is needed or not.
 
 
 Diffs
 -
 
   kcms/formats/kcmformats.cpp 4169244 
 
 Diff: https://git.reviewboard.kde.org/r/118584/diff/
 
 
 Testing
 ---
 
 Compiled, ran the Formats KCM, selected my country, inspected the generated 
 files.
 
 
 Thanks,
 
 Luca Beltrame
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118063: New Formats KCM

[John Layt]

 On May 11, 2014, 6:59 p.m., John Layt wrote:
  kcms/formats/kcmformats.cpp, line 204
  https://git.reviewboard.kde.org/r/118063/diff/1/?file=272244#file272244line204
 
  Why are you writing all these entries here?  If all they have set is 
  the global then all we need to export is LANG, so only writing out lcGlobal 
  should be enough. If there's no overrides we should always be deleting them.
 
 Sebastian Kügler wrote:
 Hm, LANG will be set from the Translations KCM, and affects that, no? (I 
 might be off here, that's how I understand it.)
 
 This brings me back a bit to the way this KCM works, it's used to 
 override settings specified elsewhere, if necessary. I think in combination 
 with the Translations KCM, a clean separation makes sense, but I'm not 100% 
 sure that's achievable. Effectively, with the current version of code, we 
 have a few scenarios:
 
 - Language set from distro installer, however. User's happy, doesn't 
 touch the KCM
 - User sets Language in the Translations KCModule, which sets LANG (in 
 the same fashion as we do here), LC_* is not set, so everything falls back to 
 LANG - we're peachy
 - User sets Language, but wants something else changed, configures that 
 in the Formats KCM, and it's applied by exporting LC_*, - we're fine again
 
 The Translations KCM probably the first one we should show when the 
 category in systemsettings is opened, as it allows a very Global setting: 
 LANG is changed, affects translations, and additionally all the formatting 
 because LC_* not set means fall back to LANG.

Ah, here we get to the difference between LANG and LANGUAGE and LC_* and the 
override hierarchy (see 
http://www.gnu.org/savannah-checkouts/gnu/libc/manual/html_node/Locale-Categories.html).
  LANG is the global default locale to use, with LC_* and LANGUAGE used to 
override that default for certain functions.  The LANGUAGE override is a GNU 
gettext extension that allows you to define a priority list of languages to be 
used in the translation system, whereas LANG and LC_* only allow a single 
locale code at a time.  For example, QLocale::uiLanguages() returns the list of 
whatever is held in LANGUAGE, otherwise whatever is in LC_MESSAGES, otherwise 
whatever is in LANG, otherwise defaulting to the C locale (en_US).

Defining how that relationship between LANG and LANGUAGE will work in the 
config GUI is the tricky part.  My original plan was to treat them completely 
separately:

* The LANGUAGE envvar configures the gui translation systems, i.e. gettext and 
KLocalizedString, and QTranslator.  The Translations kcm would configure it 
from a list of available translation catalogs installed, usually only 1 or 2, 
with en_US as the fallback.  startkde would always export a LANGUAGE value, 
defaulting to the system LANG if no LANGUAGE value set in the kcm.  It would 
also export the first value in the LANGUAGE list as LC_MESSAGES

* The LANG and LC_* envvars configure the localization system, i.e. date 
formatting, number formatting, etc in glibc and ICU and QLocale.  The kcm 
configures them from a list of available locale files installed, usually 
several hundred.  These locale files contain month and day name translations 
separate to the gui translation system.  startkde would export a value for LANG 
or LC_* only if set in the kcm.

This would give users maximum flexibility while perhaps making it clearer why 
just selecting say an Arabic locale doesn't give you an Arabic gui translation. 
 However I'm rethinking that a bit now, as while by default most users would 
never need to change anything after their initial distro install, I could see 
those users who do need to change being confused/annoyed at having to do it in 
two separate places.  Having the two kcms messing with each others settings 
also seems a no-no to me, so the only alternative is to merge them.

One other reason for the original approach was the rather problematic Languages 
tab in the old Locale kcm which I was copying for Translations.  It uses a 
KActionSelector widget which shows side-by-side lists of Available Languages 
and Preferred Languages: you move the languages you want from Available to 
Preferred and then adjust the order.  Problem is this takes up a lot of space 
so needs a separate pane or tab, but most of this space and functionality is 
wasted on most users who only have 1 or 2 KDE language packs installed: its a 
gui optimised for the 0.1% corner case of someone with dozens of languages 
installed who's regularly modifying them.  There's also a debate about what the 
Available Languages list should show given we are setting LANGUAGES now for all 
apps under the workspace including gettext ones: do we list just the KDE 
language packs, or also all languages installed into /usr/share/locale, or all 
possible languages?

One possibility is to throw away all the old code and have a single list of 
Preferred Languages, with a small + button to pop

Re: Review Request 118063: New Formats KCM

[John Layt]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118063/#review57726
---



kcms/formats/formats.desktop
https://git.reviewboard.kde.org/r/118063/#comment40181

s/language/formats



kcms/formats/formats.desktop
https://git.reviewboard.kde.org/r/118063/#comment40182

Language shouldn't be there, perhaps Number, time, currency and other 
formats for your particular region



kcms/formats/formats.desktop
https://git.reviewboard.kde.org/r/118063/#comment40183

accessibility?



kcms/formats/kcmformats.cpp
https://git.reviewboard.kde.org/r/118063/#comment40184

I think we should add a combo for Collation to the GUI.



kcms/formats/kcmformats.cpp
https://git.reviewboard.kde.org/r/118063/#comment40185

While this approach is easier and makes more sense to the user, I don't 
think it will work in the world of POSIX locales. I believe the LC_MEASUREMENT 
locale set may also affect the formatting of the numbers i.e. the decimal and 
grouping separators used, not just the units.  We probably need to check that 
and if so just use the same list of locales as the others.  If it doesn't, then 
there's actually 3 different possible values, Metric, US Imperial, and UK 
Imperial.



kcms/formats/kcmformats.cpp
https://git.reviewboard.kde.org/r/118063/#comment40186

Perhaps Use Default Locale?



kcms/formats/kcmformats.cpp
https://git.reviewboard.kde.org/r/118063/#comment40190

countryToString() doesn't do what you'd think, it just converts something 
an enum like QLocale::UnitedStates to the string UnitedStates.  What you 
really want is nativeCountryName().



kcms/formats/kcmformats.cpp
https://git.reviewboard.kde.org/r/118063/#comment40188

I'm not sure defaulting to the German flag will be popular everywhere :-)  
Perhaps if there's no country then we just don't try load the name, or perhaps 
have a default blank flag?



kcms/formats/kcmformats.cpp
https://git.reviewboard.kde.org/r/118063/#comment40189

Damn, I thought we'd made countryCode() and splitLocale() public api in 
QLocale already :-\ *adds to TODO list*



kcms/formats/kcmformats.cpp
https://git.reviewboard.kde.org/r/118063/#comment40187

The flag resource is actually from kdelibs4support so won't be around for 
long, and have recently moved to a different location (kf5/locale/countries/).  
They will make a comeback in a new Framework in a few months time though, so 
are probably OK to stay this way for now.



kcms/formats/kcmformats.cpp
https://git.reviewboard.kde.org/r/118063/#comment40191

H.  I do prefer listing by Country rather than Language (it's more 
natural to users I think), and I sort-of like showing the locale code so 
experts knwo what they are getting, but I think we do need to include the name 
of the language somehow (just ask your Catalans how they feel :-)



kcms/formats/kcmformats.cpp
https://git.reviewboard.kde.org/r/118063/#comment40192

Why are you writing all these entries here?  If all they have set is the 
global then all we need to export is LANG, so only writing out lcGlobal should 
be enough. If there's no overrides we should always be deleting them.



kcms/formats/kcmformats.cpp
https://git.reviewboard.kde.org/r/118063/#comment40193

Shouldn't lcGlobal just be exported as LANG?  The lcCollate and lcCtype 
should be read form the config and exported in their own right?



kcms/formats/kcmformats.cpp
https://git.reviewboard.kde.org/r/118063/#comment40194

Actually, Yen does have subunits called Sen, its just thanks to inflation 
they're not used anymore :-)  It's a valid concern though, but I think the 
format code takes care of it by using a setting of 0 decimal places, so the .99 
is thrown away.  It's worth a test though.  Also, the toCurrencyString() call 
does the right thing in figuring out whether to use , or ., that's all part 
of the settings defined by choosing the locale to use rather than the currency 
code.



kcms/formats/kcmformats.cpp
https://git.reviewboard.kde.org/r/118063/#comment40195

We need to check what it actually affects and use that as an example.  
Problem is QLocale doesn't have any methods that use this other than 
measurementSystem() returning Metric/ImperialUK/ImperialUS. If my comment above 
about needing to show the locale names in teh combo is correct, then just 
showing the resultign system name shoudl be enough.  Otherwise we need to find 
something that will format using LC_MEASUREMENT.  Or maybe we just leave it out 
for now.  It needs research.


- John Layt


On May 9, 2014, 5:05 p.m., Sebastian Kügler wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/118063/
 ---
 
 (Updated May 9, 2014, 5

Re: Review Request 118063: New Formats KCM

[John Layt]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118063/#review57729
---


Mostly looks good, a few obviously issues, but once it's in I can tweak it as 
needed.

- John Layt


On May 9, 2014, 5:05 p.m., Sebastian Kügler wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/118063/
 ---
 
 (Updated May 9, 2014, 5:05 p.m.)
 
 
 Review request for Plasma and John Layt.
 
 
 Bugs: 331930
 https://bugs.kde.org/show_bug.cgi?id=331930
 
 
 Repository: plasma-desktop
 
 
 Description
 ---
 
 The current Locale KCM is almost entirely broken. The way forward is to 
 split it into localization options (this, Formats), and translaticons. This 
 patch implements a new Formats KCM which writes out an environment suitable 
 for QLocale to pick it up.
 
 It's a rewrite of the current KCM, since:
 - everything under the hood is different (KLocale is gone, QLocale takes over)
 - everything above the hood is different, in QLocale, everything is deduced 
 from the country / region
 
 Now this includes feature regressions compared to the old KCM, but not all of 
 these features can be done at all on top of QLocale right now, so we have to 
 set up what we can.
 
 This KCM caches the settings in a config file, but most importantly, it 
 writes out a script with export instructions, which can be picked up by 
 startkde. This is all done according to John's suggestions, and I have a 
 patch for startkde to pick up the settings here. It all works fine (on my 
 machine).
 
 Many more details about the implementation can be found in the plasma-devel 
 thead Locale settings in Plasma Next, started by John on February, 23rd 
 2014.
 
 
 Diffs
 -
 
   kcms/formats/kcmformatswidget.ui PRE-CREATION 
   kcms/formats/kcmformats.cpp PRE-CREATION 
   kcms/formats/kcmformats.h PRE-CREATION 
   kcms/formats/Messages.sh PRE-CREATION 
   kcms/formats/formats.desktop PRE-CREATION 
   kcms/formats/CMakeLists.txt PRE-CREATION 
   kcms/CMakeLists.txt ed86efa 
 
 Diff: https://git.reviewboard.kde.org/r/118063/diff/
 
 
 Testing
 ---
 
 Tried all kinds of different combinations, applied them, made sure they're 
 exported correctly in the script.
 
 
 File Attachments
 
 
 new Formats KCM in kcmshell5
   
 https://git.reviewboard.kde.org/media/uploaded/files/2014/05/09/873980fe-04f2-4d75-9074-2aa676723061__formatskcm.png
 Formats KCM in systemsettings
   
 https://git.reviewboard.kde.org/media/uploaded/files/2014/05/09/86a830ed-2d5d-4bdd-ba82-71ec73e6ce2c__formatskcmss.png
 
 
 Thanks,
 
 Sebastian Kügler
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118063: New Formats KCM

[John Layt]

 On May 10, 2014, 9:52 p.m., Martin Klapetek wrote:
  File Attachment: new Formats KCM in kcmshell5 - formatskcm.png
  https://git.reviewboard.kde.org/r/118063/#fcomment219
 
  Shouldn't this be Country rather than Region?

I'd stick with Region, the locale is a combination of country and language 
which usually applies in a region. Just ask our Catalan friends how they would 
feel about only having a single option for Spain :-)  The alternative (as 
used in POSIX, Gnome, and Windows) is to list by language name first, e.g. 
English (Great Britain) but personally I prefer the country first in this 
case (as does Mac OSX).


- John


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118063/#review57693
---


On May 9, 2014, 5:05 p.m., Sebastian Kügler wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/118063/
 ---
 
 (Updated May 9, 2014, 5:05 p.m.)
 
 
 Review request for Plasma and John Layt.
 
 
 Bugs: 331930
 https://bugs.kde.org/show_bug.cgi?id=331930
 
 
 Repository: plasma-desktop
 
 
 Description
 ---
 
 The current Locale KCM is almost entirely broken. The way forward is to 
 split it into localization options (this, Formats), and translaticons. This 
 patch implements a new Formats KCM which writes out an environment suitable 
 for QLocale to pick it up.
 
 It's a rewrite of the current KCM, since:
 - everything under the hood is different (KLocale is gone, QLocale takes over)
 - everything above the hood is different, in QLocale, everything is deduced 
 from the country / region
 
 Now this includes feature regressions compared to the old KCM, but not all of 
 these features can be done at all on top of QLocale right now, so we have to 
 set up what we can.
 
 This KCM caches the settings in a config file, but most importantly, it 
 writes out a script with export instructions, which can be picked up by 
 startkde. This is all done according to John's suggestions, and I have a 
 patch for startkde to pick up the settings here. It all works fine (on my 
 machine).
 
 Many more details about the implementation can be found in the plasma-devel 
 thead Locale settings in Plasma Next, started by John on February, 23rd 
 2014.
 
 
 Diffs
 -
 
   kcms/formats/kcmformatswidget.ui PRE-CREATION 
   kcms/formats/kcmformats.cpp PRE-CREATION 
   kcms/formats/kcmformats.h PRE-CREATION 
   kcms/formats/Messages.sh PRE-CREATION 
   kcms/formats/formats.desktop PRE-CREATION 
   kcms/formats/CMakeLists.txt PRE-CREATION 
   kcms/CMakeLists.txt ed86efa 
 
 Diff: https://git.reviewboard.kde.org/r/118063/diff/
 
 
 Testing
 ---
 
 Tried all kinds of different combinations, applied them, made sure they're 
 exported correctly in the script.
 
 
 File Attachments
 
 
 new Formats KCM in kcmshell5
   
 https://git.reviewboard.kde.org/media/uploaded/files/2014/05/09/873980fe-04f2-4d75-9074-2aa676723061__formatskcm.png
 Formats KCM in systemsettings
   
 https://git.reviewboard.kde.org/media/uploaded/files/2014/05/09/86a830ed-2d5d-4bdd-ba82-71ec73e6ce2c__formatskcmss.png
 
 
 Thanks,
 
 Sebastian Kügler
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 118063: New Formats KCM

[John Layt]

 On May 10, 2014, 9:52 p.m., Martin Klapetek wrote:
  File Attachment: new Formats KCM in kcmshell5 - formatskcm.png
  https://git.reviewboard.kde.org/r/118063/#fcomment220
 
  Shouldn't this be Country rather than Region?
 
 John Layt wrote:
 I'd stick with Region, the locale is a combination of country and 
 language which usually applies in a region. Just ask our Catalan friends how 
 they would feel about only having a single option for Spain :-)  The 
 alternative (as used in POSIX, Gnome, and Windows) is to list by language 
 name first, e.g. English (Great Britain) but personally I prefer the 
 country first in this case (as does Mac OSX).

The one problem I do have with using Region is that it feels slightly 
inconsistent with the other combo labels which are Numbers Time etc


- John


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118063/#review57693
---


On May 9, 2014, 5:05 p.m., Sebastian Kügler wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/118063/
 ---
 
 (Updated May 9, 2014, 5:05 p.m.)
 
 
 Review request for Plasma and John Layt.
 
 
 Bugs: 331930
 https://bugs.kde.org/show_bug.cgi?id=331930
 
 
 Repository: plasma-desktop
 
 
 Description
 ---
 
 The current Locale KCM is almost entirely broken. The way forward is to 
 split it into localization options (this, Formats), and translaticons. This 
 patch implements a new Formats KCM which writes out an environment suitable 
 for QLocale to pick it up.
 
 It's a rewrite of the current KCM, since:
 - everything under the hood is different (KLocale is gone, QLocale takes over)
 - everything above the hood is different, in QLocale, everything is deduced 
 from the country / region
 
 Now this includes feature regressions compared to the old KCM, but not all of 
 these features can be done at all on top of QLocale right now, so we have to 
 set up what we can.
 
 This KCM caches the settings in a config file, but most importantly, it 
 writes out a script with export instructions, which can be picked up by 
 startkde. This is all done according to John's suggestions, and I have a 
 patch for startkde to pick up the settings here. It all works fine (on my 
 machine).
 
 Many more details about the implementation can be found in the plasma-devel 
 thead Locale settings in Plasma Next, started by John on February, 23rd 
 2014.
 
 
 Diffs
 -
 
   kcms/formats/kcmformatswidget.ui PRE-CREATION 
   kcms/formats/kcmformats.cpp PRE-CREATION 
   kcms/formats/kcmformats.h PRE-CREATION 
   kcms/formats/Messages.sh PRE-CREATION 
   kcms/formats/formats.desktop PRE-CREATION 
   kcms/formats/CMakeLists.txt PRE-CREATION 
   kcms/CMakeLists.txt ed86efa 
 
 Diff: https://git.reviewboard.kde.org/r/118063/diff/
 
 
 Testing
 ---
 
 Tried all kinds of different combinations, applied them, made sure they're 
 exported correctly in the script.
 
 
 File Attachments
 
 
 new Formats KCM in kcmshell5
   
 https://git.reviewboard.kde.org/media/uploaded/files/2014/05/09/873980fe-04f2-4d75-9074-2aa676723061__formatskcm.png
 Formats KCM in systemsettings
   
 https://git.reviewboard.kde.org/media/uploaded/files/2014/05/09/86a830ed-2d5d-4bdd-ba82-71ec73e6ce2c__formatskcmss.png
 
 
 Thanks,
 
 Sebastian Kügler
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Compatibility problems with latest GTK+ applications

[John Layt]

On 8 May 2014 13:56, Sebastian Kügler se...@kde.org wrote:
 On Thursday, May 08, 2014 14:39:49 Matthias Klumpp wrote:
 However, to support the cross-desktop efforts, the GNOME people should
 maybe make a few compromises (e.g. make GTK+ behave differently on
 other DEs), especially since GTK+ is not just for GNOME but also used
 by other projects.

 This is actually at the root of all these problems. The GTK developers have at
 some point decided to couple the toolkit with the GNOME desktop, so GTK is --
 in their view -- the toolkit for GNOME. It seems, the developers lost interest
 in keeping their cross-platform and cross-desktop promise. This is visible in
 other areas as well, such as theming: Theming APIs have been unstable and
 changed will-nilly for some time now, and the revolt of theme creators has
 calmed down by now (I suppose they all just walked away). I suppose this CSD
 episode will just speed up this exodus.

 We might be looking at a completely different GTK here than we did a few years
 ago, and that's pretty bad news for interoperability on the freedesktop.

Exactly, they seem to have forgotten what the G actually stands for
:-)  Which makes me wonder how apps like Gimp who use Gtk but are not
part of Gnome and want to be cross-desktop and cross-platform are
going to be affected?  And how are the other Gtk desktops like XFCE
affected?

Pardon my ignorance, but does Gtk impose CSD on all apps, or just
those apps that opt-in to using it?  I'm assuming it's opt-in, in
which case perhaps the app authors don't realise the implication for
other desktops/platforms?  If they do realise what it means then
that's their decision to only support Gnome and I don't see why we
should even bother to try work around it: if it looks ugly elsewhere
and that costs them users, that's their problem not ours.

Either way, it seems to me that the Gtk app and desktop authors may be
the people in the best position to influence Gtk to work on these
issues, the Gtk maintainers may not care about what KDE thinks, but
you'd hope that they would listen to their own users.  Perhaps if/when
the direct approach fails, we need to raise bugs reports against the
apps themselves to get their authors interested?

John.

P.S. If Gtk keep this up, we could see another surge in apps switching
to Qt, and that presents a great opportunity for KDE as a community
interested in being cross-platform/desktop
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Compatibility problems with latest GTK+ applications

[John Layt]

On 8 May 2014 13:56, Sebastian Kügler se...@kde.org wrote:
 On Thursday, May 08, 2014 14:39:49 Matthias Klumpp wrote:
 However, to support the cross-desktop efforts, the GNOME people should
 maybe make a few compromises (e.g. make GTK+ behave differently on
 other DEs), especially since GTK+ is not just for GNOME but also used
 by other projects.

 This is actually at the root of all these problems. The GTK developers have at
 some point decided to couple the toolkit with the GNOME desktop, so GTK is --
 in their view -- the toolkit for GNOME. It seems, the developers lost interest
 in keeping their cross-platform and cross-desktop promise. This is visible in
 other areas as well, such as theming: Theming APIs have been unstable and
 changed will-nilly for some time now, and the revolt of theme creators has
 calmed down by now (I suppose they all just walked away). I suppose this CSD
 episode will just speed up this exodus.

 We might be looking at a completely different GTK here than we did a few years
 ago, and that's pretty bad news for interoperability on the freedesktop.

Exactly, they seem to have forgotten what the G actually stands for
:-)  Which makes me wonder how apps like Gimp who use Gtk but are not
part of Gnome and want to be cross-desktop and cross-platform are
going to be affected?  And how are the other Gtk desktops like XFCE
affected?

Pardon my ignorance, but does Gtk impose CSD on all apps, or just
those apps that opt-in to using it?  I'm assuming it's opt-in, in
which case perhaps the app authors don't realise the implication for
other desktops/platforms?  If they do realise what it means then
that's their decision to only support Gnome and I don't see why we
should even bother to try work around it: if it looks ugly elsewhere
and that costs them users, that's their problem not ours.

Either way, it seems to me that the Gtk app and desktop authors may be
the people in the best position to influence Gtk to work on these
issues, the Gtk maintainers may not care about what KDE thinks, but
you'd hope that they would listen to their own users.  Perhaps if/when
the direct approach fails, we need to raise bugs reports against the
apps themselves to get their authors interested?

John.

P.S. If Gtk keep this up, we could see another surge in apps switching
to Qt, and that presents a great opportunity for KDE as a community
interested in being cross-platform/desktop
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Compatibility problems with latest GTK+ applications

[John Layt]

On 9 May 2014 10:04, Martin Gräßlin mgraess...@kde.org wrote:

 XFCE is affected in that way that GTK developers opened bug reports against
 XFCE that their window manager is broken (stating it's the only one not
 supporting that, well KWin neither).

That's not exactly the way to win friends and influence people :-)

 I'm not sure whether it's opt-in. Using the gtk3-demo and the gallery one can
 find many examples which enforce client-side-decorations. E.g. the standard
 message box dialog example.

If the standard dialogs have it forced, then that does become a big
issue.  If an app chooses to not work cross-desktop that's their
problem, but if an app that wants to be cross-desktop suddenly finds
the standard dialogs don't work then that's a bad thing.

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma 5?

[John Layt]

On 5 May 2014 14:55, Sebastian Kügler se...@kde.org wrote:

 I am not happy with the 2014.6 name and naming scheme. There I said it.

Here's a few random thoughts to add to the mix.

I'll admit I always thought the .MM number scheme somewhat awkward
to use, but that the reasons behind it had a lot of validity.  However
a simple sequential version number is far better for packaging and
support/bug triage issues, and having a matching major version number
across frameworks, plasma and apps might help that too.  Everything
Sebas says here is very valid, it is a better *technical* solution,
but Jos is equally right that a mixture of same major number but
different minor version numbers could be confusing to end-users.  And
we keep running into that PR problem of what to call it without
painting all KDE products as a monolithic whole.  I firmly believe our
viability as a community in the next 2-3 years is going to depend on
how strongly we can rebrand in potential developers and users minds as
a community that develops useful apps for any platform (especially
Android), as well as providing a great Linux desktop if they want one.
The Qt5 transition gives us a chance to emphasise that as a clear
break, we've put a lot of effort into the technical side of it, we
just need to get that PR side to work for us.  We need a working
numbering scheme that is co-ordinated between the 3 products to ensure
we put that message across, we can't really decide them in isolation
(hence me, a fringe Plasma person, adding my tuppence worth), but one
that is not too similar so it appears a monlithic KDE unit.

My preference would be for Plasma to use a v2 numbering scheme under
the bonnet (with perhaps some sonames using v5 if needed), but to
never mention that number in the PR effort, instead to use the release
date when really needed.  For example the first release announcement
could say something like The KDE Community is proud to annouce the
December 2014 release of their Plasma workspace.  This is the first
release of Plasma using Qt5 and the KDE Frameworks.  With careful
wording, you might be able to get away with never mentioning version
numbers.  If anyone does use the version numbers when naming them it
would then be Plasma 2 and Frameworks 5, neatly avoiding the ability
to call it all KDE 5.

A major concern for Martin is people not realising how old their
version is, and a date based scheme would communicate this, albeit in
a vacuum of the average user not knowing what our release cycle is, so
not really knowing if it is too old or not.  Perhaps there are other
ways to address this concern?  Where do people see version numbers and
how much do they pay attention to them, especially the Plasma version
number?  For apps we have various About KDE and bug report dialogs
which give the App version number and the Platform version number, but
I can't think of anywhere we see the Plasma version string in the UI?
So people only see the Plasma version in their software installer?
Unfortunately we can't do a lot about the number there (blame distros
imposing a bad UX that depends on package version numbers, although we
might be able to influence Apper, or use the AppStream data to include
the date in the description).  In the About KDE dialogs we could
choose to emphasise the release date instead of the version number,
perhaps with a new tab that includes the full app, frameworks and
Plasma version details?

Cheers!

John.

P.S.  Sorry Jens, it's a neat solution, but Plasma by KDE is just
way too pretentious sounding and begging to be trolled... ;-)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Locale settings in Plasma Next

[John Layt]

On 5 May 2014 15:44, Sebastian Kügler se...@kde.org wrote:
 On Sunday, February 23, 2014 20:10:31 John Layt wrote:
 One question is when these changes to the envvars will get applied, and the
 action required to apply them to the apps.  I believe Gnome forces you to
 log out and in again before the new envvars are applied.  In KDE4 you could
 simply restart individual apps, but to update Plasma itself you had to log
 out and in.  Do we update the envars as soon as the KCM changes are saved,
 which would allow apps to simply be restarted, or would that be considered
 dangerous for running apps that assume the envvars won't change, e.g. would
 something like glibc immediately pick up the change and return inconsistent
 results?

 I'd say let's try writing out the envvars immediately, we'll see soon enough
 if things break. (Which to me would be application-level bugs, but if they're
 too bad, we might want to indirected the setting.)

 John, you said that you started splitting the locale KCM already, is that work
 already available somewhere? I could put some time into trying to get it up to
 scratch for an initial release. (To me, right now, even disabling the locale
 KCM altogether is better than keeping it as-is.)

I started, basically I copied the existing kcm to a new one in
kcontrol/translations and deleted all the KLocale format code, leaving
just the languages tab, I've mostly been experimenting with layout
options.  I hadn't started the new Formats kcm yet.  Basically feel
free to do what you like, I'd say disable or delete the existing one,
and we can add new ones as clean code whenever we get to them.

If you want to do something, I'd suggest looking at startkde, or
whatever it is that starts Plasma up, and modify it to export the
locale envvars if set by the kcm (LC_NUMERIC, LC_TIME, LC_MONETARY,
LC_MESSAGES, LC_MEASUREMENT, LC_COLLATE, LC_CTYPE, LANGUAGE and LANG,
but *not* LC_ALL).  You'll need first to decide in what config file
these get saved, just remember that it's a Plasma specific setting,
not a general KDE Frameworks or Apps setting.

After that it should be easy enough to do a temporary Formats kcm with
some combo boxes populated with locales using
QLocale::matchingLocales().  There would be one combo for Default
Format which defaults to System Locale (i.e. don't override
anything) and populates LANG if a different locale is chosen.  The
other combos would be for example Number Format which defaults to
Default Format (i.e. don't override anything).  Don't offer
LC_MESSAGES here, I think that should be set by the Translations KCM.

Cheers!

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Fwd: Proposal: Location hackfest

[John Layt]

Hi,

Please see the below email from Zeeshan Ali of Gnome and GeoClue who is
organising a Location hackfest in London in May/June time-frame to get
Gnome, KDE, Qt, Mozilla, Jolla and others working together on improving
location services on the Linux desktop.  If anyone is interested in
attending, in particular to work on porting Qt from GeoClue1 to GeoClue2,
addressing any missing features in GeoClue2, or to work on cool new desktop
features using location, then please contact him directly or add your
details to the wiki.

Cheers!

John.

-- Forwarded message --
From: Zeeshan Ali (Khattak) zeesha...@gnome.org
Date: 2 April 2014 17:00
Subject: Proposal: Location hackfest
To: John Layt jl...@kde.org, Aaron McCarthy 
aaron.mccar...@jollamobile.com, Hanno Schlichting hschlicht...@mozilla.com

Cc: Bastien Nocera had...@hadess.net, Ekaterina Gerasimova 
kittykat3...@gmail.com


Hi everyone,

I'm planning a combined hackfest in the spirit of cooperation between
our projects to ensure we all have a stable, well-documented and free
location infrastructure for both desktops and mobile devices:

https://wiki.gnome.org/Hackfests/Location2014

If you folks (or others from your projects) can participate, please
add your names on the list and propose date and duration for the
event. I'm hoping to organise it mid/late May or sometime in June.

Once I know who can join, I can contact our board for making it
official and organising the event.

Aaaron, From the changelog on geoclue rpm on my Jolla phone, I
gathered you are the person to contact about this in your company but
if that is not the case, kindly forward this mail to the right person.

--
Regards,

Zeeshan Ali (Khattak)
FSF member#5124
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Plasma Next - Translations KCM - What Languages?

[John Layt]

Hi,

I'm doing some more work on the new KCM for Translations, i.e. the KCM in 
Plasma Next to configure the LANGUAGE env var that startkde will export for 
all apps running under Plasma Next to use, including Gtk as well as Qt apps.  
Because this is now the workspace/desktop wide setting, and not the setting 
for just KDE apps under all workspaces, the way the current KCM works may no 
longer be valid.

The current Languages KCM has two columns, Available Languages and 
Preferred Languages.  The Available Languages is populated with the list of 
all KDE translations installed by calling KLocale::installedLanguages(), i.e. 
all the QStandardPaths::GenericDataLocation/locale/*/entry.desktop files 
installed.

Now, that seems a fine idea, until you think about non-KDE apps that may have 
other translation languages installed which won't get listed.  Are we 
concerned about those?  Is there a common cross-distro way to find out all 
languages that are installed?  Do we just scan all the locale/*/LC_MESSAGES/* 
or locale-bundle/*/LC_MESSAGES/* entries installed to get all the possible 
languages (and what is the difference between locale and locale-bundle)?  Or 
do we list all languages regardless of whether they are installed or not 
(probably way too many)?

If we stick with just KDE translations installed, do we copy the 
KLocale::installedLanguages() code (will we still be installing the 
entry.desktop files?), or use the new 
KLocalizedString::availableApplicationTranslations() method which requires 
setting an Application Domain to define which LC_MESSAGES file to look for (if 
so, which one)?

Cheers!

John.

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Locale settings in Plasma Next

[John Layt]

On 10 March 2014 10:11, Martin Klapetek martin.klape...@gmail.com wrote:
 On Sun, Feb 23, 2014 at 8:10 PM, John Layt jl...@kde.org wrote:

 Any ETA on the QLocale changes? Any particular plans with which we can help?
 I'd be happy to help out there.

I'm hoping for Qt 5.4, but this is something that needs to be 100%
correct on all platforms before it goes in so getting it done is
proving to be a pain.  We've been through Plans A thru D so far...  I
plan to get focussed back on it once Frameworks goes Beta 1 and my
stuff in Qt 5.3 is stabilised, so I'll ping you then with my plans.

 Some sort of temporary/transient KCM comes to mind...we could simply list
 the locale items (Numeric system, Time, Money formatting...) and
 combobox next to it with available locales, presented as countries (Czech
 Republic, Germany, USA...). It would be a bit ugly tho, but it would
 serve its purpose. Or have no KCM at all...I imagine the percentage of
 people setting different locales for each thing will be quite minimal...plus
 we can advertise that this will come back later (whenever QLocale is ready).

Funny enough, I spent Sunday working on that.  I'm splitting
kde-runtime/kcontrol/locale into the two kcm's as I described below,
one for Translations which for now is just the old ui, and one for
Formats which for now is a list of combo's for the 6 envvars Qt uses.
It is indeed ugly, and I can think of prettier/friendlier ways to do
it, but it's functionality that counts for now.

One point that came out of it was the realisation that the code will
move from kde-runtime/kcontrol into kde-workspace/kcontrol, as it
really is configuring the locale for all apps running under Plasma
Next, not configuring KDE apps running everywhere.

I actually spent most of the day looking at Gnome3 code to see what
they are doing (my eyes!), a few other desktops too, some distros, and
systemd / localed to see how that fits in.  I'll write up a more
detailed design/spec for what it needs to do over the next couple of
days.

 For KDE4 apps running under Plasma Next, I wonder if it will be too confusing
 having them using different locale settings than the KF5 apps?

 I'd be all for that, except that if people will have two sessions on their
 PCs, one for KDE4 and the other for Next, try out Next one time and this
 will nuke their KDE4 session settings, I imagine this will make them
 unhappy. And I think this will be quite common use case from the beginning
 as people will want to try things out. We could put a warning there, but
 that might scare some people off = less testing. Can we just override the
 KDE4 kdeglobals from Next? We could simply change the path or something and
 then the KDE4 apps won't be reading the KDE4 session kdeglobals file.

Yes, good point, wiping settings is a no-no in that scenario.

We actually have two scenarios we need to work with here
1) KF5 apps still using KLocale from kde4support
2) KDE4 apps using KLocale from kdelibs

For 1, I think I we should patch kde4support/KLocale to check what
platform it is running under, by default it should use the user locale
but ignore the individual user overrides, but if running under KDE4 (I
assume that's a valid scenario?) then it should use the overrides.
What's a good way to detect that?

For 2, I think the same rule should probably apply, but that would
require patching kdelibs (can we still?).  Alternatively we'd have to
mess with the paths.  I'll need to look into that more.

 One question is when these changes to the envvars will get applied, and
 the action required to apply them to the apps.

 I think restarting Plasma while running would be easy. As to if it should be
 considered dangerous, I'm not educated enough to answer that.

I think to start with we'll just force users to log out, less code,
but we can work toward dynamic reloading (Qt has an event signal for
that, I plan to make it actually work at some stage).

 I guess another obvious question is where to save the envvar settings, I
 guess kdeglobals still?  Or somewhere new?

 Not sure about this either...

I'll put it there for now, we'll be reusing the existing Languages
setting and just adding new ones for the LC_* overrides.

 Longer term we will need to restore the ability to edit the individual
 settings and I have a roadmap for that.

 Will there be QLocale/QML Locale support for that too? That'd be great ;)

Yes, the plan is actually for all apps, Qt and Gtk and whatever, to
use our settings, otherwise it 's a bad user experience to have
different apps using different settings.  It just requires some magic
and for other toolkits to be following the POSIX standard properly.
The simplest way is just to have QLocale load our settings, probably
from a CLDR format json file, perhaps via the platform plugin, but
that would only work for all Qt apps.  The POSIX spec actually says if
a locale envvar like LANG starts with a / then it's an absolute path
to the locale file to be loaded, so assuming all

Locale settings in Plasma Next

[John Layt]

Hi,

With the countdown to Plasma Next underway, I thought I'd better outline what 
needs to be done for locale settings, in particular the KCM, in case I don't 
find the time to do it.

In KDE4 we had KLocale in which we wrote the formatting code and provided the 
locale data ourselves which gave our users the ability to override every 
single locale setting in the Locale KCM, but completely failed to apply those 
settings to apps written with Qt or Gtk or anything else that also ran under 
Plasma.  It also meant KDE apps running under other workspaces, such as Gnome 
or Unity, sometimes failed to respect the host locale settings and used the 
KDE settings instead.  We also had separate settings for country and language 
rather than the more standard locale code of country and language combined, 
which while being more user-friendly didn't integrate well when talking to the 
outside world that was using only standard locale codes.

In KF5 we have switched to QLocale to remove the heavy dependency for KF5 
users and to better integrate with Qt apps and the host workspace.  I've been 
working on bringing QLocale up to scratch, but it doesn't yet have the ability 
to load and use the custom KDE settings when running under Plasma Next, it 
will only use the standard POSIX envvars.  This means that any changes made in 
the existing Locale KCM will be applied to KDE4 apps only, not KF5 apps that 
have removed the kde4support version of KLocale.  We need to decide the best 
way to deal with this.

What we can do in Plasma Next is allow users to separately choose which locale 
code to apply for each of the standard unix envars (LC_ALL, LC_NUMERIC, 
LC_TIME, LC_MONETARY, LC_MESSAGES, LC_MEASUREMENT, LANG), and have these apply 
to *all* apps running under Plasma Next by having kdeinit set them at start-
up.  But how do we present that in a usable way in a KCM, and what do we do 
with the KDE4 settings and KCM?

For KDE4 apps running under Plasma Next, I wonder if it will be too confusing 
having them using different locale settings than the KF5 apps?  Perhaps on 
migrating from KDE4 to Plasma Next we delete any old user locale settings in 
kdeglobals and as a consequence the apps will use the same settings as all 
other apps under Plasma Next?  If we do keep the old settings, then we will 
probably also need to keep the old KCM available.

For the new Locale KCM we will need to remove the separate Numbers, Money, 
Calendar, Date  Time and Other tabs for now.  I'd suggest we no longer refer 
to the Languages tab but call it Translations instead, as that is what 
they really are, it configures how KLocalizedString works.  Referring to them 
as Languages has created a lot of confusion, as has the current gui, but I'm 
not sure how to make it better.  I'd also suggest changing the Country tab 
to Formats, with a series of combo boxes to select the Number Format, 
Money Format, etc.  We may be able to merge the Formats and Translations 
tabs into one layout but I suspect that will be too crowded, so instead 
perhaps we should have them as separate KCMs so they appear listed separately 
in the System Settings Locale group and sidebar as Formats, Translations, and 
Spell-Checker.

One question is when these changes to the envvars will get applied, and the 
action required to apply them to the apps.  I believe Gnome forces you to log 
out and in again before the new envvars are applied.  In KDE4 you could simply 
restart individual apps, but to update Plasma itself you had to log out and 
in.  Do we update the envars as soon as the KCM changes are saved, which would 
allow apps to simply be restarted, or would that be considered dangerous for 
running apps that assume the envvars won't change, e.g. would something like 
glibc immediately pick up the change and return inconsistent results?

I guess another obvious question is where to save the envvar settings, I guess 
kdeglobals still?  Or somewhere new?

Longer term we will need to restore the ability to edit the individual 
settings and I have a roadmap for that, but I'm expecting some negative user 
feedback in the meantime :-)

Cheers!

John.

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Date in digital-clock?

[John Layt]

On Thursday 06 Feb 2014 01:39:33 Martin Klapetek wrote:
 Hey,
 
 what's the plan of getting the date back to the digital clock applet? Do we
 want that? Do we not? Should it go again under the clock (making it really
 tiny I guess)? Ideas?
 
 Cheers

As a survivor of the Clock Wars back in the naughties, I've seen things that 
you people wouldn't believe...  :-)

Seriously though, this issue raised more heat and light than almost any other 
I've seen, it's up there with the battery % in terms of controversy.  People 
got *very* irate over the very limited config options we gave them in 4.0 
(have a look in this list archives and in bugzilla for the long flamewars), 
but it proved incredibly difficult to come up with a solution that balanced 
usability, configurability, and elegance.  I lost count of the number of 
patches I and others proposed, but nothing ever really worked too well  Partly 
that was due to the limits of localizing date formats, partly due to the 
restrictions of the layout code.  QML will probably make getting the layout 
right easier, but localizing is still an issue and will be until we can hook 
into ICUs advanced formatters (Qt 5.4?).

There's a fairly vocal group of uses who want to be able to customise the 
clock date format separate to their local date format in System Settings, i.e. 
having a shorter or longer version of the date in the clock than the standard 
short date format they use everywhere else.  These people usually wanted an 
edit box to type in a date format like we have in System Settings, but this 
was rejected as being ugly and having poor usability.  I have at times 
proposed a nicer way of doing this [1] and the Nepomuk Query Builder someone 
built last year for Dolphin is close to what I was after.

Basically, I guess I'm saying you have too separate challenges ahead of you, 
getting the layout right, and coping with users demands to customise their 
date format any way they like.  Good luck!

FWIW, I usually don't have the date showing, but if I did I'd only have Mon 1 
Jan (like Mac does), or for other timezones just the name like we used to.  
If the panel height is high enough then we can fit the date underneath, 
otherwise for a narrow panel it will need to go by the side.  The problem we 
found with that in the past is the average panel height fell between the 
optimal size for either of those options to look good.  One alternative to 
spelling out the date is to have a small calendar page icon like [2] that 
could show the short month name, day, and short day name stacked in a way that 
you only have to localize each component separately, rather than having to 
worry about getting the sequence and separators localized correctly. 

[1] http://www.layt.net/john/blog/odysseus/a_challenge
[2] 
http://www.publicdomainpictures.net/view-image.php?image=60543picture=desk-calendar-icon-december-25th

Cheers!

John.

P.S. Apologies to the Fandom for conflating my sci-fi universes :-)

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 114886: Port Time dataengine to QTimeZone

[John Layt]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/114886/#review46915
---

Ship it!


Looks good to me (haven't tested it though).

- John Layt


On Jan. 6, 2014, 3:07 p.m., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/114886/
 ---
 
 (Updated Jan. 6, 2014, 3:07 p.m.)
 
 
 Review request for Plasma and John Layt.
 
 
 Repository: kde-workspace
 
 
 Description
 ---
 
 as $summary
 
 
 Diffs
 -
 
   plasma/generic/dataengines/time/timeengine.cpp 0321b0e 
   plasma/generic/dataengines/time/timesource.cpp 6651d56 
 
 Diff: https://git.reviewboard.kde.org/r/114886/diff/
 
 
 Testing
 ---
 
 Engine explorer shows correct values
 
 
 Thanks,
 
 Martin Klapetek
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: PIM Sprint (The bits relevant to Plasma)

[John Layt]

On 19 November 2013 10:51, Marco Martin notm...@gmail.com wrote:
 On Monday 18 November 2013, John Layt wrote:

  dataengine in Plasma 1)
 
  - various runners

 There are 3 data engines and 2 runners which link to kdepimlibs.  The
 Akonadi and RSS data engines are not used anywhere in the kde repos,

 rss is used in kdeplasma-addons


Ah, grep-fail, updated thanks!

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: PIM Sprint (The bits relevant to Plasma)

[John Layt]

On 18 November 2013 20:53, David Edmundson da...@davidedmundson.co.uk wrote:
 To plasma-devel, CC'ing KDE PIM.

A few small clarifications, for more details see some initial
documentation at http://community.kde.org/Frameworks/Epics/kdepimlibs

 Preparing for Plasma 2:

  - KDE PIM is currently used in kde-workspace for:
 - an Akonadi dataengine
 - showing events in the calendar (which was C++ without the
 dataengine in Plasma 1)
 - various runners

There are 3 data engines and 2 runners which link to kdepimlibs.  The
Akonadi and RSS data engines are not used anywhere in the kde repos,
only the Calendar Engine is used in the calendar plasmoid.  The 2
runners are for contacts and events and link directly to kdepimlibs
and not via the data engines.  Full details are on the wiki.

There was some discussion that KPeople would remove the need for the
contacts runner to link to kdepimlibs?

  - Tentative timeline for PIM:
- Plan is to start porting to Qt5/Frameworks  /after/ frameworks is
 done (so we may have a kdepimlibs-transitional in ~ 6months)

We're tentatively aiming to fork a frameworks branch in about 3 months
once the KF5 split is done, then perhaps 3 months of basic Qt5/KF5
porting and re-arranging before we split, then each library will be
released as it is ready over the following 6 months.  We're reluctant
to throw too many resources at it too soon that are needed to bug fix
KDEPIM 4.

- Annoyingly (from a Plasma perspective) kcalcore is going to be
 one of the hardest (and therefore slowest) to port as it uses
 KDateTime a lot. (probably nearer to 12 months)

We'll be trying to prioritise the libraries used by Plasma, and it
could be ready sooner, but we're very reluctant to give a time frame
before anyone's had a look at it.  The other main library used is
KHolidays which will be available very quickly.

  - One discussion was to have a first run wizard which shows web
 accounts to raise awareness of PIM/super cool IM clients, over web
 applications (gmail + FB etc)
   [having a first run wizard] is Plasma's call, but if there is one,
 this is what we want to add - John Layt.

The idea being that if the user didn't configure any calendars on
first run, then we would know to disable events and so never wake
Akonadi up.  The alternative is that we ship with events turned off by
default, which is what most distros do now.

Cheers!

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 113260: Port KTimeZoned to Qt5/KF5

[John Layt]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113260/#review43331
---

Ship it!


Ship It!

- John Layt


On Oct. 22, 2013, 4:49 p.m., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/113260/
 ---
 
 (Updated Oct. 22, 2013, 4:49 p.m.)
 
 
 Review request for KDE Runtime, KDE Frameworks, Plasma, and John Layt.
 
 
 Repository: kde-runtime
 
 
 Description
 ---
 
 Originally I wanted to port KTimeZoned 1:1 to Qt5/KF5, but then I found out 
 that all the stuff KTZD was doing was added in QTimeZone, that includes 
 reading correct system files/env variables to obtain the timezone and 
 returning the proper system zone (KTZD did all this by itself). It also 
 doesn't need to parse the timezone files itself or watch for their changes as 
 QTimeZone objects are not stored.
 
 So now it's just a thin module watching /etc/timezone (used by Debian-based 
 distros) and /etc/localtime (used by eg. Fedora or Suse, but also by Debian 
 in conjunction with /etc/timezone) for changes and if it detects a change, it 
 checks if the new timezone is really different and if it is, it sends out a 
 DBus signal timeZoneChange. I changed it from configChanged as I think 
 timeZoneChanged makes way more sense.
 
 I didn't touch the Windows part as I have no way to test, would be nice if 
 someone could help with that.
 
 EDIT: I removed the other two DBus signals which were not used and I'm unsure 
 KTZD is the correct place for that now anyway. The only usage in 
 KSystemTimeZone can be replaced by own KDirWatch instance.
 
 
 Diffs
 -
 
   CMakeLists.txt a5ec93d 
   ktimezoned/CMakeLists.txt bafc85e 
   ktimezoned/ktimezoned.h ff21807 
   ktimezoned/ktimezoned.cpp f380c09 
   ktimezoned/ktimezoned_win.h 26e21cc 
   ktimezoned/ktimezoned_win.cpp cadfe3a 
   ktimezoned/ktimezonedbase.h ca00aca 
   ktimezoned/org.kde.KTimeZoned.xml daaa0b7 
 
 Diff: http://git.reviewboard.kde.org/r/113260/diff/
 
 
 Testing
 ---
 
 Tested by changing the timezone in different ways, change was detected and 
 signalled out.
 
 
 Thanks,
 
 Martin Klapetek
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 113260: Port KTimeZoned to Qt5/KF5

[John Layt]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113260/#review42961
---


I've asked on the Qt Development list about Qt 5 Solaris support.  I'm told it 
builds and works to some extent, and patches are welcome, but not without 
having been tested on a real Solaris build first, which I have no desire to do. 
 I don't think much is required, Solaris uses the Olsen tz files, just with 
different patches and possibly a different zonetab layout, but I don't want to 
code blind.  So we have two options, one is not worry about Solaris support for 
now, and if anyone (Ade?) complains then ask them to contribute upstream (with 
my help).  The alternative is to keep the Solaris code in ktimezoned, including 
calls to return the current system time zone and the list of available time 
zones, and on other platforms just wrap the Qt calls.  Opinions?

- John Layt


On Oct. 22, 2013, 4:49 p.m., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/113260/
 ---
 
 (Updated Oct. 22, 2013, 4:49 p.m.)
 
 
 Review request for KDE Runtime, KDE Frameworks, Plasma, and John Layt.
 
 
 Repository: kde-runtime
 
 
 Description
 ---
 
 Originally I wanted to port KTimeZoned 1:1 to Qt5/KF5, but then I found out 
 that all the stuff KTZD was doing was added in QTimeZone, that includes 
 reading correct system files/env variables to obtain the timezone and 
 returning the proper system zone (KTZD did all this by itself). It also 
 doesn't need to parse the timezone files itself or watch for their changes as 
 QTimeZone objects are not stored.
 
 So now it's just a thin module watching /etc/timezone (used by Debian-based 
 distros) and /etc/localtime (used by eg. Fedora or Suse, but also by Debian 
 in conjunction with /etc/timezone) for changes and if it detects a change, it 
 checks if the new timezone is really different and if it is, it sends out a 
 DBus signal timeZoneChange. I changed it from configChanged as I think 
 timeZoneChanged makes way more sense.
 
 I didn't touch the Windows part as I have no way to test, would be nice if 
 someone could help with that.
 
 EDIT: I removed the other two DBus signals which were not used and I'm unsure 
 KTZD is the correct place for that now anyway. The only usage in 
 KSystemTimeZone can be replaced by own KDirWatch instance.
 
 
 Diffs
 -
 
   CMakeLists.txt a5ec93d 
   ktimezoned/CMakeLists.txt bafc85e 
   ktimezoned/ktimezoned.h ff21807 
   ktimezoned/ktimezoned.cpp f380c09 
   ktimezoned/ktimezoned_win.h 26e21cc 
   ktimezoned/ktimezoned_win.cpp cadfe3a 
   ktimezoned/ktimezonedbase.h ca00aca 
   ktimezoned/org.kde.KTimeZoned.xml daaa0b7 
 
 Diff: http://git.reviewboard.kde.org/r/113260/diff/
 
 
 Testing
 ---
 
 Tested by changing the timezone in different ways, change was detected and 
 signalled out.
 
 
 Thanks,
 
 Martin Klapetek
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 113260: Port KTimeZoned to Qt5/KF5

[John Layt]

 On Nov. 4, 2013, 4:12 p.m., John Layt wrote:
  I've asked on the Qt Development list about Qt 5 Solaris support.  I'm told 
  it builds and works to some extent, and patches are welcome, but not 
  without having been tested on a real Solaris build first, which I have no 
  desire to do.  I don't think much is required, Solaris uses the Olsen tz 
  files, just with different patches and possibly a different zonetab layout, 
  but I don't want to code blind.  So we have two options, one is not worry 
  about Solaris support for now, and if anyone (Ade?) complains then ask them 
  to contribute upstream (with my help).  The alternative is to keep the 
  Solaris code in ktimezoned, including calls to return the current system 
  time zone and the list of available time zones, and on other platforms just 
  wrap the Qt calls.  Opinions?

s/patches/paths


- John


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113260/#review42961
---


On Oct. 22, 2013, 4:49 p.m., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/113260/
 ---
 
 (Updated Oct. 22, 2013, 4:49 p.m.)
 
 
 Review request for KDE Runtime, KDE Frameworks, Plasma, and John Layt.
 
 
 Repository: kde-runtime
 
 
 Description
 ---
 
 Originally I wanted to port KTimeZoned 1:1 to Qt5/KF5, but then I found out 
 that all the stuff KTZD was doing was added in QTimeZone, that includes 
 reading correct system files/env variables to obtain the timezone and 
 returning the proper system zone (KTZD did all this by itself). It also 
 doesn't need to parse the timezone files itself or watch for their changes as 
 QTimeZone objects are not stored.
 
 So now it's just a thin module watching /etc/timezone (used by Debian-based 
 distros) and /etc/localtime (used by eg. Fedora or Suse, but also by Debian 
 in conjunction with /etc/timezone) for changes and if it detects a change, it 
 checks if the new timezone is really different and if it is, it sends out a 
 DBus signal timeZoneChange. I changed it from configChanged as I think 
 timeZoneChanged makes way more sense.
 
 I didn't touch the Windows part as I have no way to test, would be nice if 
 someone could help with that.
 
 EDIT: I removed the other two DBus signals which were not used and I'm unsure 
 KTZD is the correct place for that now anyway. The only usage in 
 KSystemTimeZone can be replaced by own KDirWatch instance.
 
 
 Diffs
 -
 
   CMakeLists.txt a5ec93d 
   ktimezoned/CMakeLists.txt bafc85e 
   ktimezoned/ktimezoned.h ff21807 
   ktimezoned/ktimezoned.cpp f380c09 
   ktimezoned/ktimezoned_win.h 26e21cc 
   ktimezoned/ktimezoned_win.cpp cadfe3a 
   ktimezoned/ktimezonedbase.h ca00aca 
   ktimezoned/org.kde.KTimeZoned.xml daaa0b7 
 
 Diff: http://git.reviewboard.kde.org/r/113260/diff/
 
 
 Testing
 ---
 
 Tested by changing the timezone in different ways, change was detected and 
 signalled out.
 
 
 Thanks,
 
 Martin Klapetek
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Keep the Things You Forgot

[John Layt]

On 24 October 2013 14:54, Mario Fux KDE ML kde...@unormal.org wrote:

 You probably mean dot.kde.org/2013/09/25/frameworks-5

 And this:
 http://dot.kde.org/2013/09/04/kde-release-structure-evolves

Yes, that explains Frameworks and Workspaces, albeit a little fuzzy on
Workspaces vs Plasma, but it kinda leaves Applications hanging, and
with good reason as we really don't know what's happening there yet.
Talking to a few people there does seem to be an interest in having a
clean-up of the modules and apps, reducing the number of apps in the
official release, having fewer essential applications of higher
quality, and killing off the SC name once and for all.  I'm also
keen on breaking down the whole Modules vs Extragear distinction,
they're all KDE Applications built by the same KDE Community, just
with different release schedules.  How that all might work is
something the community as a whole needs to discuss.

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Keep the Things You Forgot

[John Layt]

On 23 October 2013 21:49, Mark mark...@gmail.com wrote:

 A blog post that i'd very much like from you (Aaron) is about the next
 big KDE version, the naming and how the complete collection is going
 to be called or if there even will be a collection release (what KDE
 SC is now). Press is still getting that wrong, i tend to get it wrong
 and other people talking about KDE seem to get it wrong. Usually it's
 just being referred to as KDE 5 which is wrong. (Frameworks 5,
 Plasma 2, ...). So if you have the time, a blog about that would be
 wonderful and very educational ^_^

H, actually I had an email I was writing about that, must finish
it off...  Basically just a discussion starter on the community list
to discuss the future of Modules and Apps and the SC and how we need
to do a big clean-up and re-brand for Gen5.  I think most people here
have a loose idea of where we are heading, but it would probably be a
good idea to make it more explicit at some stage.

Kick me at the PIM Sprint if I haven't sent it by then :-)

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 113260: Port KTimeZoned to Qt5/KF5

[John Layt]

 On Oct. 16, 2013, 12:15 p.m., John Layt wrote:
  Wow, there sure is a lot of code in there catering for all the possible 
  corner cases :-)  QTimeZone has a lot less places it checks, so I'll need 
  to do an in-depth comparison, but given Qt5 will only support modern 
  distros I think most of it is redundant.  
  
  One thought is if we still want to have a signal that the system database 
  has been updated?  While Qt doesn't cache the time zone data, the apps 
  probably will cache the QTimeZone instances themselves and may need to be 
  told that the database has changed so they can take action.  Then again, 
  it's not something that will happen very often, and what will the apps do 
  in response?  If they refresh their cache the shared copies in QDateTime 
  won't update.  I guess QTimeZone will need a reloadData() method added 
  instead.
  
  I've looked at the Windows code and it mostly looks OK, all it does is 
  monitor the registry for changes.  What you do need to change is the DBus 
  signal from configChanged to your new timeZoneChanged signal.
  
  With regards the signal name change, does it need to go in the porting 
  guide or somewhere so people know it has changed?
  
  In Qt 5.3 I will try adding a QEvent for TimeZoneChanged and 
  TimeZoneDatabaseChanged, but I can't guarantee it will get in so we still 
  need the daemon for now.
 
 Martin Klapetek wrote:
  Wow, there sure is a lot of code in there catering for all the possible 
 corner cases :-)  QTimeZone has a lot less places it checks, so I'll need to 
 do an in-depth comparison, but given Qt5 will only support modern distros I 
 think most of it is redundant. 
 
 Part of that is support for Solaris, but I see Solaris is not supported 
 by Qt anymore [1][2], so I just removed it altogether.
 
  One thought is if we still want to have a signal that the system 
 database has been updated?  While Qt doesn't cache the time zone data, the 
 apps probably will cache the QTimeZone instances themselves and may need to 
 be told that the database has changed so they can take action.
 
 I think it might be worth having it...I'll add it back, can't hurt :)
 
  I've looked at the Windows code and it mostly looks OK, all it does is 
 monitor the registry for changes.  What you do need to change is the DBus 
 signal from configChanged to your new timeZoneChanged signal.
 
 Ah yes, I forgot to add that to the patch, sorry.
 
  With regards the signal name change, does it need to go in the porting 
 guide or somewhere so people know it has changed?
 
 I wanted to add it, but that's in kdelibs. Question is, should there be a 
 guide for runtime/workspace too?
 
  In Qt 5.3 I will try adding a QEvent for TimeZoneChanged and 
 TimeZoneDatabaseChanged, but I can't guarantee it will get in so we still 
 need the daemon for now.
 
 Ok, keep us posted. (It would be cool to have cross-desktop solution for 
 this too...or system-wide spec at least, so we could use non-qt/-kde apps 
 still supporting timezone changes, but oh well).
 
 
 [1] - http://qt-project.org/doc/qt-5.1/qtdoc/supported-platforms.html
 [2] - http://qt.digia.com/Product/Supported-Platforms/
 
 David Faure wrote:
 There are still people around with a Solaris system. Not supported 
 doesn't mean we should actively remove existing support, IMHO.
 
 About the porting guide: the distinction between kdelibs and kde-runtime 
 will disappear, given the framework-ification. So treat it as a porting guide 
 from kde 4 to kde-frameworks, i.e. it's fine to include runtime stuff in 
 there.
 
 About a solution in Qt --- that means each and every Qt app will have to 
 monitor the same timezone file(s), isn't that a bit too expensive? (not sure, 
 just wondering)
 
 Martin Klapetek wrote:
  There are still people around with a Solaris system. Not supported 
 doesn't mean we should actively remove existing support, IMHO.
 
 Is there any attempt to make sure KF5/PW2 is working with Solaris? 
 Because if the underlying components won't work on Solaris, there's no point 
 in keeping Solaris code in one tiny module sitting on top of the bigger 
 blocks.
 
  it's fine to include runtime stuff in there.
 
 Cool, will add it then :)

I'm not sure Qt5 even compiles on Solaris, and it might be hard to convince 
Thiago to accept code for it, but I can ask what the status there is.  The 
alternative is to have timeZone() and listTimeZones() calls in ktimezoned that 
wrap the Qt or Solaris calls.

As for Qt monitoring the time zones: yes that would probably be the end result 
which is not ideal, but AFAIK we can't use a daemon inside Qt, or call dbus 
inside QtCore which rules out using ktimezoned if it's running, or systemd if 
it ever adds this feature.  I have to post to the development list the design 
proposal for it and see if it gets shot down or not.


- John

Re: Review Request 113260: Port KTimeZoned to Qt5/KF5

[John Layt]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113260/#review42017
---



ktimezoned/ktimezonedbase.h
http://git.reviewboard.kde.org/r/113260/#comment30665

Not generic enough, is Unix specific.  Perhaps timeZoneDatabaseUpdated() 
without the file path?



ktimezoned/org.kde.KTimeZoned.xml
http://git.reviewboard.kde.org/r/113260/#comment30664

You need to keep this, or a variant of it.


I don't think this is generic enough, it only applies to the zonetab file on 
Unix, and the data files could be updated without the zonetab being changed, 
and it doesn't apply to Windows at all.  I'd suggest a generic 
timeZoneDatabaseUpdated() signal instead that triggers on Unix if any file in 
the zone path tree (/usr/share/zoneinfo or wherever) is updated, or for Windows 
if any of the registry database is updated (I can do that later).

- John Layt


On Oct. 18, 2013, 1 p.m., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/113260/
 ---
 
 (Updated Oct. 18, 2013, 1 p.m.)
 
 
 Review request for KDE Runtime, KDE Frameworks, Plasma, and John Layt.
 
 
 Repository: kde-runtime
 
 
 Description
 ---
 
 Originally I wanted to port KTimeZoned 1:1 to Qt5/KF5, but then I found out 
 that all the stuff KTZD was doing was added in QTimeZone, that includes 
 reading correct system files/env variables to obtain the timezone and 
 returning the proper system zone (KTZD did all this by itself). It also 
 doesn't need to parse the timezone files itself or watch for their changes as 
 QTimeZone objects are not stored.
 
 So now it's just a thin module watching /etc/timezone (used by Debian-based 
 distros) and /etc/localtime (used by eg. Fedora or Suse, but also by Debian 
 in conjunction with /etc/timezone) for changes and if it detects a change, it 
 checks if the new timezone is really different and if it is, it sends out a 
 DBus signal timeZoneChange. I changed it from configChanged as I think 
 timeZoneChanged makes way more sense.
 
 I didn't touch the Windows part as I have no way to test, would be nice if 
 someone could help with that.
 
 EDIT: I removed the other two DBus signals which were not used and I'm unsure 
 KTZD is the correct place for that now anyway. The only usage in 
 KSystemTimeZone can be replaced by own KDirWatch instance.
 
 
 Diffs
 -
 
   ktimezoned/ktimezoned.cpp f380c09 
   ktimezoned/ktimezoned.h ff21807 
   ktimezoned/CMakeLists.txt bafc85e 
   ktimezoned/ktimezoned_win.h 26e21cc 
   ktimezoned/ktimezoned_win.cpp cadfe3a 
   ktimezoned/ktimezonedbase.h ca00aca 
   ktimezoned/org.kde.KTimeZoned.xml daaa0b7 
 
 Diff: http://git.reviewboard.kde.org/r/113260/diff/
 
 
 Testing
 ---
 
 Tested by changing the timezone in different ways, change was detected and 
 signalled out.
 
 
 Thanks,
 
 Martin Klapetek
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request 113260: Port KTimeZoned to Qt5/KF5

[John Layt]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113260/#review41816
---


Wow, there sure is a lot of code in there catering for all the possible corner 
cases :-)  QTimeZone has a lot less places it checks, so I'll need to do an 
in-depth comparison, but given Qt5 will only support modern distros I think 
most of it is redundant.  

One thought is if we still want to have a signal that the system database has 
been updated?  While Qt doesn't cache the time zone data, the apps probably 
will cache the QTimeZone instances themselves and may need to be told that the 
database has changed so they can take action.  Then again, it's not something 
that will happen very often, and what will the apps do in response?  If they 
refresh their cache the shared copies in QDateTime won't update.  I guess 
QTimeZone will need a reloadData() method added instead.

I've looked at the Windows code and it mostly looks OK, all it does is monitor 
the registry for changes.  What you do need to change is the DBus signal from 
configChanged to your new timeZoneChanged signal.

With regards the signal name change, does it need to go in the porting guide or 
somewhere so people know it has changed?

In Qt 5.3 I will try adding a QEvent for TimeZoneChanged and 
TimeZoneDatabaseChanged, but I can't guarantee it will get in so we still need 
the daemon for now.

- John Layt


On Oct. 15, 2013, 8:09 p.m., Martin Klapetek wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/113260/
 ---
 
 (Updated Oct. 15, 2013, 8:09 p.m.)
 
 
 Review request for KDE Runtime, KDE Frameworks, Plasma, and John Layt.
 
 
 Repository: kde-runtime
 
 
 Description
 ---
 
 Originally I wanted to port KTimeZoned 1:1 to Qt5/KF5, but then I found out 
 that all the stuff KTZD was doing was added in QTimeZone, that includes 
 reading correct system files/env variables to obtain the timezone and 
 returning the proper system zone (KTZD did all this by itself). It also 
 doesn't need to parse the timezone files itself or watch for their changes as 
 QTimeZone objects are not stored.
 
 So now it's just a thin module watching /etc/timezone (used by Debian-based 
 distros) and /etc/localtime (used by eg. Fedora or Suse, but also by Debian 
 in conjunction with /etc/timezone) for changes and if it detects a change, it 
 checks if the new timezone is really different and if it is, it sends out a 
 DBus signal timeZoneChange. I changed it from configChanged as I think 
 timeZoneChanged makes way more sense.
 
 I didn't touch the Windows part as I have no way to test, would be nice if 
 someone could help with that.
 
 EDIT: I removed the other two DBus signals which were not used and I'm unsure 
 KTZD is the correct place for that now anyway. The only usage in 
 KSystemTimeZone can be replaced by own KDirWatch instance.
 
 
 Diffs
 -
 
   ktimezoned/CMakeLists.txt bafc85e 
   ktimezoned/ktimezoned.h ff21807 
   ktimezoned/ktimezoned.cpp f380c09 
   ktimezoned/ktimezoned_win.h 26e21cc 
   ktimezoned/ktimezoned_win.cpp cadfe3a 
   ktimezoned/ktimezonedbase.h ca00aca 
   ktimezoned/org.kde.KTimeZoned.xml daaa0b7 
 
 Diff: http://git.reviewboard.kde.org/r/113260/diff/
 
 
 Testing
 ---
 
 Tested by changing the timezone in different ways, change was detected and 
 signalled out.
 
 
 Thanks,
 
 Martin Klapetek
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Building plasma mediacenter - qt-mobility

[John Layt]

On 24 March 2013 11:00, todd rme toddrme2...@gmail.com wrote:

 That is good to know.  So are there any plans for a qt-mobility
 release any time soon?  It looks like there has been a lot of
 development in the last 2 years or so.

Qt Mobility as a monolithic package won't see another release, but the
modules have been integrated in the Qt 5 release, either as essential
modules or as add-on modules, so in future PMC can only rely on the
required modules.  See
http://qt-project.org/wiki/Qt_5.0#66036ddf6d03c9ce1fc742741417f128.

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: plasma calendar - event system config option

[John Layt]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105924/#review17095
---


Sorry, but I disagree.  The separate config settings are for specific technical 
reasons, due to previous user feedback, and for backwards compatibility 
purposes.  We have two config settings for Events and Holidays due to Events 
turning on Akonadi which many people don't want to use but still want to have 
Holidays displayed.  Until we have a proper solution to the Akonadi problem we 
have to retain the separate config options.  In any case, the solution would be 
in modifying the behaviour of the GUI, not in changing the backend config.

We used to have separate tick-boxes in the GUI directly mapped to the config 
options, but I changed the Holidays tick-box to the multiple holidays selection 
widget and had to retain the backwards compatible behaviour of respecting any 
existing config setting.  You also have the usability issue of people ticking 
the Holiday options but not the Event box and wondering why the Holidays don't 
show, you would need to change the GUI to make this obvious.

Also, you seem to have other unrelated code fixes included in the review?

- John Layt


On Aug. 8, 2012, 7:35 a.m., Greg T wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/105924/
 ---
 
 (Updated Aug. 8, 2012, 7:35 a.m.)
 
 
 Review request for Plasma and Anne-Marie Mahfouf.
 
 
 Description
 ---
 
 This patch addresses an usuability issue. The config option 'display events' 
 enables/disables now all events/holidays. The user doesn't distinguish 
 between them and it must be possible to turn off that feature with just one 
 click. 
 
 
 This addresses bug 281464.
 http://bugs.kde.org/show_bug.cgi?id=281464
 
 
 Diffs
 -
 
   libs/plasmaclock/calendar.cpp 75bfc31 
   libs/plasmaclock/calendartable.h 8678593 
   libs/plasmaclock/calendartable.cpp d2b436e 
   libs/taskmanager/groupmanager.cpp 45c15a9 
 
 Diff: http://git.reviewboard.kde.org/r/105924/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Greg T
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: How to access calendar using javascript?

[John Layt]

On 2 Jul 2012 17:07, Davide Bettio bet...@kde.org wrote:

 Hello,

 I've created the current calendar widget, my initial intention was to
review it and to move it to kdelibs but I didn't so the API isn't meant to
be used by anyone.
 If you don't mind to wait few days I will commit the QML implementation
that I'm writing.

 Bye,
 Davide Bettio.

Please note that kdelibs is closed for new features, bugfixes only are
allowed. Any new widgets will need to be Plasma only until Frameworks 5.

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: PIM Events via Plasma Clock/Calendar

[John Layt]

On 3 July 2012 09:26, Davide Bettio bet...@kde.org wrote:
 Hello,


 Quoting Daniel Kreuter daniel.kreute...@googlemail.com:

 John Layt mentioned on planet.kde.org in his blog post about Fake
 Academy, that the users would like to see the PIM events in the plasma
 calendar / clock. I would like to work on that feature. I will read
 more about it in wiki this evening when I come from work.


 Be aware that calendar will be subject to several changes, please contact me
 if you want to discuss about it.

 Bye,
 Davide Bettio.

The DataEngine/Service work needs to come first, once that is ready
then whatever plasmoids are available can be modified to use it.

Cheers!

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: How to access calendar using javascript?

[John Layt]

On 2 Jul 2012 08:08, Aaron J. Seigo ase...@kde.org wrote:

 On Thursday, June 28, 2012 15:46:09 qasdfgtyuiop wrote:
  I want to let my widget add some events to the calendar.  But I can
  not find the api doc, where can I find them?

 you probably want to be adding events into Akonadi.

 the calendar DataEngine has a Service defined that lets you add an event
.. but
 it has not been fully implemented.

 so we either need to complete that implementation or you will need to
write
 directly to Akonadi. finishing the DataEngine would be preferred because
then
 it immediately becomes available to QML/Javascript.

Funnily enough, I've been documenting what's needed and had written a blog
about it. It's now posted at www.layt.net/john/fame_akademy with more
details at community.kde.org/Plasma/Clock .

Cheers!

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: How to access calendar using javascript?

[John Layt]

 Funnily enough, I've been documenting what's needed and had written a
blog about it. It's now posted at www.layt.net/john/fame_akademy with more
details at community.kde.org/Plasma/Clock .

Bah, thats www.layt.net/john/blog/odysseus/fame_akademy or just wait for it
on the Planet :-)

John
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Adjust KDateTimes to Current TimeSpec of the Calendar

[John Layt]

 On Nov. 9, 2011, 10:33 a.m., David Narváez wrote:
  If there are no more comments against or in favor of this patch, I'm 
  assuming everyone is OK with it so I'll commit this patch.
 
 Sergio Luis Martins wrote:
 Ok.
 
 Please add a note in the TODO that we'll need to look at this again when 
 using the kdepimlibs library.

TBH, I'd rather not change anything in the Akonadi code that causes it to be 
out of sync with the kdepim code, as that will just make keeping them in sync 
and applying patches from kdepim harder to do.  It also adds more work later 
when switching over to the kdepimlibs version.  I think this belongs instead in 
the Data Engine.  The Data Engine should be the one making any required 
adjustments to translate between the data source and the applet request.  We 
can't expect the average applet to know to deal with the issue correctly, 
that's exactly what the data engine is for.


- John


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102997/#review8038
---


On Nov. 8, 2011, 9:14 a.m., David Narváez wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/102997/
 ---
 
 (Updated Nov. 8, 2011, 9:14 a.m.)
 
 
 Review request for Plasma and Sergio Luis Martins.
 
 
 Description
 ---
 
 Adjust KDateTimes after finding out the type of incidence added. Also adjust 
 KDateTimes after a change in the Calendar TimeSpec.
 
 
 This addresses bug 279427.
 http://bugs.kde.org/show_bug.cgi?id=279427
 
 
 Diffs
 -
 
   plasma/generic/dataengines/calendar/akonadi/calendar.cpp 67c12e9 
 
 Diff: http://git.reviewboard.kde.org/r/102997/diff/diff
 
 
 Testing
 ---
 
 1. Add an event in any timezone distinct from the local timezone (you can do 
 that in KOrganizer)
 2. Check the start and end times of the event in the calendar
 
 Not sure how to test changing timezones from Plasma, so proposed patch is 
 based on what I think we should do in such a case.
 
 
 Thanks,
 
 David Narváez
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: [Kde-pim] Akonadi Calendar

[John Layt]

On Thursday 27 Oct 2011 21:26:03 Sérgio Martins wrote:

  The intention has always been to move the Akonadi calendar interface
  into
  kdepimlibs so everyone could use it, but I don't know if this has been
  done yet.  Once done we can delete the copy and switch the data engine
  to the kdepimlibs version.
  
  Sergio, do you know the status of this?
 
 I'm in the middle of cleaning kdepim/calendarsupport/ so we can move
 it to kdepimlibs.
 Sorry for not seeing your e-mail, lots of bugs and e-mails piled up
 while on vacation :).

Cool :-)  So the plan looks something like:

1) Sergio finishes the clean-up in kdepim, then moves the code to kdepimlibs
2) Someone (probably me) then removes the copy from kde-workspace and points 
the data engine at the kdepimlibs version.
3) Someone (David?) overhauls the Data Engines and adds a Service

Cheers!

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Akonadi Calendar

[John Layt]

On Thursday 27 Oct 2011 05:50:46 David Narvaez wrote:
 On Sat, Oct 15, 2011 at 6:09 AM, David Narvaez
 
 david.narv...@computer.org wrote:
  Hi all, sorry for the cross posting,
  
  I was about to work on fixes in the calendar events dataengine dealing
  with the Akonadi calendar support, and found this README[0] explaining
  a migration plan for the dataengine into Akonadi, etc. I wonder what's
  the status of that migration: if it's already in progress (and needs
  any help) or if it's still pending. Also, what would be the status of
  fixes to that feature? First fix in kdepimlibs and then port to the
  copied code in calendar dataengine? Or should fixes be frozen while the
  migration happens?
 So after 12 days without an answer I'm assuming:
 
 1) No one is taking care of that migration
 2) There's no freeze to fix bugs on that code
 
 I assume we are now too close to the freezes to try any drastic move,
 but can we plan for November to pick this topic up? I could take care
 of the migration if someone tells me how files should end up
 structured in Akonadi.
 
 David E. Narváez

Hi,

Sorry for not picking up your first email, I've been offline a lot lately.  
Seeing as I'm the one who wrote that README I should fill things in a bit 
more.

The original author of the data engine had to copy the Akonadi interface from 
kdepim as it was not available in kdepimlibs at the time.  I moved it to the 
subfolder and updated it with some bug-fixes [1] as well as overhauling the 
data engine itself.  I'm supposed to be keeping the code in sync but forgot 
before the last release, so we need to look at refreshing the copy before the 
next release.

The intention has always been to move the Akonadi calendar interface into 
kdepimlibs so everyone could use it, but I don't know if this has been done 
yet.  Once done we can delete the copy and switch the data engine to the 
kdepimlibs version.  

Sergio, do you know the status of this?

It was at this point that I was suggesting we might move the code from the 
Calendar engine to the Akonadi data engine so the implementations and 
interfaces are consistent, but thinking about it again Akonadi is an 
implementation detail and a bad name for a high level api so perhaps separate 
data engines for Calendar, Mail, and Contacts are better even if they use the 
same underlying code and consistent api.

Currently the Calendar data engine is a one-way affair, it just fetches the 
existing events from Akonadi, you can't use it to add new events.  What I 
would like to see happen is a two-way integration using a Plasma service [2] 
for which I wrote the initial operations definition file [3] but stalled at 
that point.  The idea here is not to provide a full api or feature set, as 
creating events is rather complex and Akonadi/kdepimlibs provides advanced 
widgets for doing that which you don't want to be trying to replicate in 
Plasma as well.  I think an advanced PIM Plasma widget should link directly to 
and use the PIM widgets.  What the service would provide is api for adding 
simple events such as one-off reminders for plasmoids that want to integrate 
but are not really PIM specific.

The other big thing that needs investigation is the abiltiy to configure what 
Akonadi resource to use, at the moment it just uses the default resource but I 
can imagine users might want to show different calendars in different widgets.  
Whether this is something to be provided through the data engine api or if 
it's something an applet should use akonadi directly for is a matter for 
debate.

Basically, as far as I know, no futher work has been done on the Plasma end or 
the Akonadi end.  If you have any more questions, poke me with a stick and 
I'll get back to you when I can.

Cheers!

John.

[1] https://projects.kde.org/projects/kde/kde-
workspace/repository/revisions/master/show/plasma/generic/dataengines/calendar/akonadi
[2] http://techbase.kde.org/Development/Tutorials/Plasma/Services
[3] https://projects.kde.org/projects/kde/kde-
workspace/repository/revisions/master/entry/plasma/generic/dataengines/calendar/calendar.operations

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Plasma clock bug/wish triage

[John Layt]

Hi,

Following on from the bugs discussion I've gone through the bugs for the 
widget-clock componant closing what I can.

I've previously posted a number of to-do points at 
http://community.kde.org/Plasma/Tasks#Calendar.2FClock_Plasmoids based on the 
open bugs.  If anyone was to fix/rewrite the digital clock resizing code we 
could kill half the bugs, my eternal gratitude awaits someone :-)

What's then left is a lot of wishes for new visual features that I think we 
can be ruthless with closing if there is no intent to ever implement them, so 
opinions please on:

162828 - Blinking dots on clock
165416 - Zoom/Crop Analog Clock in Panel
169130 - Manually Set Font Size
184179 - Display timezone at top of clock not bottom
185588 - Manually Set Font Size
185665 - Ability to always have calendar widget on top
186692 - Option to remove border
186913 - Show temperature
193747 - Show more than 1 month in calendar
193925 - Show seconds in on-hover pop-up
19 - Show date in analog clock
204198 - Let user choose side-by-side or stacked mode
210613 - Ability to independently set 12/24 hour time display
224344 - Ability to turn off week numbers
255344 - Add close button to calendar pop-up

There are bugs for fuzzy clock and world clock that strictly are not part of 
Plasma Clock, do we want to move them elsewhere?

Cheers!

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Idea for Season of KDE

[John Layt]

On Wednesday 04 May 2011 12:35:27 Samikshan Bairagya wrote:
 Hi, I am interested in participating in the season of KDE with a project
 idea which is related to the Digital-Clock Plasma Applet.
 While the Digital-Clock applet does show events (mainly holidays) it can be
 put to better use if we add more features to it.
 This is the idea:
 On clicking on any date from the calendar that pops up from the clock, we
 should be able to view more
 information related to that date(past or future). Various date specific
 informations like chat-logs, browsing history, emails
 received/sent, birthdays, to-dos/appointments also notes if we do wish to
 write them down.
 
 I suppose this would be great. Regarding implementation I think integration
 with Kontact, Nepomuk. Well I about the
 chat logs I am not sure if integration should be done with telepathy or
 not. So, it would be great if anyone interested could
 mentor me throughout this. :)
 
 Cheers,

Hi Samikshan,

A nice idea, but unfortunately one that is already being worked on.  At the 
moment we have both Holidays and Akonadi support in the Plasma Calendar 
widget, which will give us full PIM data integration once the kdepim migration 
is complete.  We also already have a GSoC project this year for Zeitgeist 
integration into Plasma which will give us the other data, albeit not yet in 
the calendar.  If you do want to try adding it to the calendar then pop back 
after GSoC and use the new dataengine to do so.

Have a look at the 

Cheers!

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Idea for Season of KDE

[John Layt]

On Wednesday 04 May 2011 20:03:27 John Layt wrote:
 On Wednesday 04 May 2011 12:35:27 Samikshan Bairagya wrote:
  Hi, I am interested in participating in the season of KDE with a project
  idea which is related to the Digital-Clock Plasma Applet.
  While the Digital-Clock applet does show events (mainly holidays) it can
  be put to better use if we add more features to it.
  This is the idea:
  On clicking on any date from the calendar that pops up from the clock, we
  should be able to view more
  information related to that date(past or future). Various date specific
  informations like chat-logs, browsing history, emails
  received/sent, birthdays, to-dos/appointments also notes if we do wish to
  write them down.
  
  I suppose this would be great. Regarding implementation I think
  integration with Kontact, Nepomuk. Well I about the
  chat logs I am not sure if integration should be done with telepathy or
  not. So, it would be great if anyone interested could
  mentor me throughout this. :)
  
  Cheers,
 
 Hi Samikshan,
 
 A nice idea, but unfortunately one that is already being worked on.  At the
 moment we have both Holidays and Akonadi support in the Plasma Calendar
 widget, which will give us full PIM data integration once the kdepim
 migration is complete.  We also already have a GSoC project this year for
 Zeitgeist integration into Plasma which will give us the other data,
 albeit not yet in the calendar.  If you do want to try adding it to the
 calendar then pop back after GSoC and use the new dataengine to do so.
 
 Have a look at the
 
 Cheers!
 
 John.

Sorry, missed the bit on the end :-)  I was going to suggest if you want to 
work on a SoK project for the Plasma Calendar that you could look into two-way 
Akonadi integration, e.g. being able to add new appointments via the calendar.  
I'm not sure if that is enough work of a SoK project or not, but if you do 
some research and come up with a draft proposal we can make a decision then.

Cheers!

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Chime Time Implementation

[John Layt]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101074/#review2646
---


Given there is no real functionality added, it's a bit hard to review, but you 
do seem to be in the right place now.  You don't seem to have paid attention to 
the last email I did describing how to do the ui with a combo for choosing the 
feedback option as it takes less space.

The reason for the bug of the config choice changing is because you haven't 
written the choice to the config file.

I have made comments on the coding style, you need to stick with the coding 
style used by the existing code in the file, which is usually 
http://techbase.kde.org/Policies/Kdelibs_Coding_Style or very similar.  You 
also seem to have added a lot of extra whitespace?


libs/plasmaclock/CMakeLists.txt
http://git.reviewboard.kde.org/r/101074/#comment2339

Is this stuff needed, surely it worked before so I can't see why you need 
to add this now?



libs/plasmaclock/clockapplet.h
http://git.reviewboard.kde.org/r/101074/#comment2340

Don't put the include in the header if you are not using the class in the 
header, it slows things down.  Put it in the .cpp only.



libs/plasmaclock/clockapplet.h
http://git.reviewboard.kde.org/r/101074/#comment2341

What does this do?  Give it a more meaningful name that explains at a 
glance.



libs/plasmaclock/clockapplet.h
http://git.reviewboard.kde.org/r/101074/#comment2342

You shouldn't put variables in the class if a Private d-ptr is being used, 
put these in the Private class instead, and use the KDE naming conventions, 
i.e. not s_*.



libs/plasmaclock/clockapplet.cpp
http://git.reviewboard.kde.org/r/101074/#comment2343

Should be QtGui/QRadioButton if not already included by .ui file via moc



libs/plasmaclock/clockapplet.cpp
http://git.reviewboard.kde.org/r/101074/#comment2344

coding style, opening brace of method should be on separate line.



libs/plasmaclock/clockapplet.cpp
http://git.reviewboard.kde.org/r/101074/#comment2345

Coding style: put back the space before the opening brace



libs/plasmaclock/clockapplet.cpp
http://git.reviewboard.kde.org/r/101074/#comment2349

Code style: Also have braces around if/else even if just one line.



libs/plasmaclock/clockapplet.cpp
http://git.reviewboard.kde.org/r/101074/#comment2346

Coding style: braces belong with keywod



libs/plasmaclock/clockapplet.cpp
http://git.reviewboard.kde.org/r/101074/#comment2350

Style: put back the space before brace



libs/plasmaclock/clockapplet.cpp
http://git.reviewboard.kde.org/r/101074/#comment2356

Why have a bool for s_none when you can derive it from s_chime and s_speak? 
 Better yet, seeing as these are exclusive options, this should only be one 
variable with either a string like chime or speak or a private enum.



libs/plasmaclock/clockapplet.cpp
http://git.reviewboard.kde.org/r/101074/#comment2353

Code style: Should be space between close bracket and open brace



libs/plasmaclock/clockapplet.cpp
http://git.reviewboard.kde.org/r/101074/#comment2354

Code style: brace and else if should be on same line



libs/plasmaclock/clockapplet.cpp
http://git.reviewboard.kde.org/r/101074/#comment2355

Code style: brace and else if should be on same line



plasma/generic/applets/analog-clock/clock.cpp
http://git.reviewboard.kde.org/r/101074/#comment2351

Why remove the line?



plasma/generic/applets/analog-clock/clock.cpp
http://git.reviewboard.kde.org/r/101074/#comment2352

Put back the space before brace


- John


On April 10, 2011, 1:22 p.m., Sunny Sharma wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/101074/
 ---
 
 (Updated April 10, 2011, 1:22 p.m.)
 
 
 Review request for Plasma.
 
 
 Summary
 ---
 
 Presently I have developed a UI for the setting s in the General part. 
 There are at present 3 radio buttons and according to the user wish, the 
 radiobutton which is clicked would work. There is a bug since the settings 
 gets changed when you again go and see the general settings.
 
 
 Diffs
 -
 
   libs/plasmaclock/CMakeLists.txt 667df3c 
   libs/plasmaclock/clockapplet.h b75f286 
   libs/plasmaclock/clockapplet.cpp b806792 
   libs/plasmaclock/generalConfig.ui aae25c0 
   plasma/generic/applets/analog-clock/clock.cpp 68d0725 
 
 Diff: http://git.reviewboard.kde.org/r/101074/diff
 
 
 Testing
 ---
 
 
 Screenshots
 ---
 
 snapshot
   http://git.reviewboard.kde.org/r/101074/s/122/
 
 
 Thanks,
 
 Sunny
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Keyboard navigation for calendar applet

[John Layt]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100718/#review1601
---


Just wondering if we want to have navigation for day selection in the date 
table as well?  Do we want to make it consistent with the KDatePicker class in 
kdeui?

KDatePicker has the following key mappings:
Up Arrow = - 1 week (i.e. up one row)
Down Arrow = + 1 week (i.e. down one row)
Left Arrow = - 1 day (i.e. left one column)
Right Arrow = + 1 day (i.e. right one column)
Page Up = - 1 Month
Page Down = + 1 Month

It has no key for +/- year.  KDEPIM doesn't have any key-mappings for its date 
table widget.

I think if you have both, then moving the day selected in the day table should 
be the primary navigation, i.e. the arrow keys, with month and year being 
secondary navigation, i.e. Page Up/Down or perhaps Alt-Arrows or Shift-Arrows?  
I like the Home key for Today.

Do we also need key mappings for moving the focus from the date table to the 
other input widgets (Months = Alt-M, Year = Alt-Y, Date = Alt-D, Week = Alt-W) 
or is tabbing enough?

I also think Ctrl-C could copy the currently selected date into the clipboard.

- John


On Feb. 22, 2011, 5:42 p.m., Farhad Hedayati Fard wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/100718/
 ---
 
 (Updated Feb. 22, 2011, 5:42 p.m.)
 
 
 Review request for Plasma.
 
 
 Summary
 ---
 
 Added some keyboard shortcuts through keyPressEvents 
 Key_Right - next month
 Key_Left - previous month
 Key_Return and Key_Enter - today
 Key_PageUp - next year
 Key_PageDown - previous year
 
 
 This addresses bug https://bugs.kde.org/show_bug.cgi?id=249866.
 
 http://bugs.kde.org/show_bug.cgi?id=https://bugs.kde.org/show_bug.cgi?id=249866
 
 
 Diffs
 -
 
   libs/plasmaclock/calendar.h f0f1c09 
   libs/plasmaclock/calendar.cpp 57eecd6 
 
 Diff: http://git.reviewboard.kde.org/r/100718/diff
 
 
 Testing
 ---
 
 works fine here!
 
 
 Thanks,
 
 Farhad
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Featurlets for 4.7

[John Layt]

On Tuesday 15 February 2011 17:59:54 Aaron J. Seigo wrote:
 the timezone tooltip already does use a table to align content. as for the
 calendar popups: don't bother. i've started a branch in kde-workspace
 called plasmaclock/eventsinline where i plan to gratuitously steal some
 design ideas from gnome-shell's calendar popup: calendar on the left,
 events on the right.

Interesting, I'll have a look.  Kind of like the NetworkManger plasmoid pop-up 
I guess?  But surely we'll still need the old pop-up on hover over the clock 
itself, or will people always need to pop up the calendar first?  Will that 
change days on hover or on click?  Will that work on space constrained devices 
(mobile, netbook)?  How's that going to look popping up from the panel clock 
in the bottom right corner (The gnome screenshot I just found looks a little 
unbalanced)?  Could the events list code be shared with a standalone plasmoid 
as well?

There's a wish (https://bugs.kde.org/show_bug.cgi?id=186913) to show the 
temperature in the clock which I didn't include as it's the wrong place, but 
having a side panel like that would have the room for a weather icon and 
summary at the top, like all those weather/calendar home screen widgets you 
see on Android.  A thought anyway.

Hmmm, I must find time to prototype my zoomable calendar idea for mobile 
devices, shamelessly stolen from Win7 and put on steroids :-)

 KAlarm is in kdepim and is an application; not sure it makes sense to
 integrate with KAlarm itself. if the data is kept in akonadi, then it could
 be put there? my concern, however, would be that if there is no GUI
 provided for the alarms (e.g. due to not having kdepim installed), then we
 end up with a feature that is useless. some thought should be put into
 making alarm notifications a desktop service perhaps that we can rely on
 being there.

Yes, KAlarm is being Akonadified in kdepim 4.6, so at least displaying them 
will be easy that way, not sure about adding but I assume so.  I'll make it 
clear it should be added to the calendar or akonadi data engine.

KAlarm also has a dbus interface for adding alarms which pops up KAlarm's add 
dialog, so that might be another option.  I wonder how standalone kalarmd is 
from the rest of kdepim?  I'll be at the kdepim sprint next weekend, so I can 
always ask djarvie then.

https://bugs.kde.org/show_bug.cgi?id=181065
https://bugs.kde.org/show_bug.cgi?id=195017
https://bugs.kde.org/show_bug.cgi?id=11

 -1; what is the use case for this? unlike with the date, where it is a
 matter of how much information is shown versus how much space it takes up,
 there is no such issue with the time. all this would mean is bloating the
 config UI, add more (if trivial in this case) code paths and provide one
 more place that the user needs to go fiddle with things. please, no.

There's wish for it at https://bugs.kde.org/show_bug.cgi?id=210613.  If it's 
not something we want we can close that.

  * Apply font to date  timezone text as well?
 
 if it isn't, it should be.

It doesn't.  Hmmm, I wonder though with some fonts if that's a good thing or 
not, if you use a classic segmented lcd font it looks great with the clock 
numbers, but not sure for date/tz text.  Well, someone can try anyway.

https://bugs.kde.org/show_bug.cgi?id=193472

  * Improve text auto-layout code, there's many bugs reported.
 
 listing BR#s on the page would nice ..

Done, I've listed 17 layout related bugs which would need further triaging to 
see if still valid.  The maximum possible size especially seems to be wrongly 
calculated, and possibly vertical panels as well.

Some other wishes that we could respond to or close with No:

 * Blinking dots on clock 
   https://bugs.kde.org/show_bug.cgi?id=162828

 * Display timezone above time and date below
   https://bugs.kde.org/show_bug.cgi?id=184179

 * Remove clock border 
   https://bugs.kde.org/show_bug.cgi?id=186692

 * Resize calendar to show multiple months
   https://bugs.kde.org/show_bug.cgi?id=193747

 * Add optional date to analogue clock
   https://bugs.kde.org/show_bug.cgi?id=19

 * Ability to turn off calendar week numbers
   https://bugs.kde.org/show_bug.cgi?id=224344

 * Close button on calendar pop-up
   https://bugs.kde.org/show_bug.cgi?id=255344

Cheers!

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: multiscreen fix

[John Layt]

On Thursday 17 February 2011 20:03:28 Jeffery MacEachern wrote:
 On Thu, Feb 17, 2011 at 09:02, Yuen Hoe Lim yuenho...@gmail.com wrote:
  I have multiscreen now :) Will give this a go over the weekend if no
  one's free.
 
 If you need further testing, I'll be game, providing I have my dev
 environment (re)set up by then. This affects me a lot.
 Thanks!
  - Jeffery MacEachern

Ditto, I should be able to test as well (git branches makes this stuff easy!).  
There's a whole bunch of other problems I find with dual screens and panels 
and plugging/unplugging that I should really find/open bug reports for.

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Featurlets for 4.7

[John Layt]

On Friday 11 February 2011 21:58:29 Marco Martin wrote:
 Let ideas begin :)

I've added a few for calendar / clock widget improvements, some my ideas, some 
from bug reports, feel free to critique:

Calendar / Clock
* Improve appearance of pop-ups by arranging timezone / holiday / event data 
using HTML tables
* KAlarm integration: RMB menu to have New Alarm sub-menu, pop-ups to show 
KAlarms currently set
* Keyboard navigation
* In config choose time format via combo for System / 12 hour / 24 hour (like 
date format now is)
* In config make setting clock font optional, default to system font
* Apply font to date  timezone text as well?
* Improve text auto-layout code, there's many bugs reported.

World Clock:
* Ability to set custom time in a selected timezone to see result in other 
timezones (as discussed elsewhere)
* Search box / combo to quickly select a timezone, with time edit next to it, 
and a Current Time button, able to turn on/off in config
* In config use same timezone selector as normal clocks, make separate page 
not tab, set default timezone for clock to show
* List view of time zones instead of map (or new widget?)

Cheers!

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: remove Assert on collection id change

[John Layt]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100523/#review1441
---


This is in a file copied in from Akonadi and I would strongly prefer us not to 
patch them up in plasma.  I intend to occasionally update the code from Akonadi 
until such time as the required classes become public and we can delete the 
copy, so would prefer not to have keep track of additional patches to be 
applied.  Please try fix this in Akonadi itself and we can then copy it over 
intact.

- John


On Feb. 2, 2011, 8:19 a.m., Mario Bensi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/100523/
 ---
 
 (Updated Feb. 2, 2011, 8:19 a.m.)
 
 
 Review request for KDEPIM and Plasma.
 
 
 Summary
 ---
 
 Actually, there is an assert when the collection id are not the same you
 are store in your cache. I work on Zanshin and I can move an Item from a
 Collection to another and i can reproduce the same behaviour with 
 akonadiconsole.
 
 This path remove the assert on this case and avoid a crash when we move
 the item to a different collection.
 
 I add kdepim in groups because a part of the code comes from 
 kdepim/akonadi/kcal
 
 
 Diffs
 -
 
   plasma/generic/dataengines/calendar/akonadi/calendar.cpp 71e4fe6 
 
 Diff: http://git.reviewboard.kde.org/r/100523/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Mario
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: KHoliday::HolidayRegionSelector: emit signal when modified

[John Layt]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100619/#review1403
---

Ship it!


Lookd good!

- John


On Feb. 12, 2011, 4:40 a.m., Romário Rios wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/100619/
 ---
 
 (Updated Feb. 12, 2011, 4:40 a.m.)
 
 
 Review request for KDEPIM-Libraries and Plasma.
 
 
 Summary
 ---
 
 Makes HolidayRegionSelector emit a signal when something is modified in the 
 widget. Needed for enabling Apply button on plasmaclock config 
 [http://git.reviewboard.kde.org/r/100620/].
 
 
 Diffs
 -
 
   kholidays/holidayregionselector.h a48823e 
   kholidays/holidayregionselector.cpp 6115b2f 
 
 Diff: http://git.reviewboard.kde.org/r/100619/diff
 
 
 Testing
 ---
 
 Works fine so far, although I'm not sure if the naming is OK.
 
 
 Thanks,
 
 Romário
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Enable Apply button for plasma clock

[John Layt]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100620/#review1404
---

Ship it!


Looks good.

- John


On Feb. 12, 2011, 4:42 a.m., Romário Rios wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/100620/
 ---
 
 (Updated Feb. 12, 2011, 4:42 a.m.)
 
 
 Review request for Plasma.
 
 
 Summary
 ---
 
 Enables apply button for plasma clock. Dependens on patch 
 http://git.reviewboard.kde.org/r/100619/. Needed for 
 http://git.reviewboard.kde.org/r/100614/.
 
 
 Diffs
 -
 
   libs/plasmaclock/calendartable.cpp f15f1ff 
   libs/plasmaclock/clockapplet.cpp b806792 
 
 Diff: http://git.reviewboard.kde.org/r/100620/diff
 
 
 Testing
 ---
 
 Seems to be fine.
 
 
 Thanks,
 
 Romário
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Tips for commit messages

[John Layt]

On Wednesday 09 February 2011 14:00:23 Artur de Souza wrote:
 Hello! :)
 
 Somebody just sent this two websites with short and useful tips for
 commit messages and I felt I should share with my new git friends on
 the block :P
 
 https://github.com/erlang/otp/wiki/Writing-good-commit-messages
 http://lbrandy.com/blog/2009/03/writing-better-commit-messages/

And in the same vein:

http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: roadmap of the chime feature in the analog clock

[John Layt]

On Saturday 15 January 2011 19:29:29 sunny sharma wrote:

 To make things clear for me i would reguest you guys to tell me the further
 steps that i should take.
 So that i can clear up my mind and come up with a clear algorithm of what
 should be done.

[Catching up on my email now that I'm back from holiday]

The problem here is the old one of balancing features for the power users 
against ease of use for the majority of users, it just means we have to make 
the code do more of the work instead of the user, or rather just be smarter 
about it.

The most common features of chiming clocks are:
 * Quarters, i.e. different chimes at 00, 15, 30 and 45
 * Striking the hour, i.e. 12 strikes at midnight
 * The hour chime plays before the hour, with the first hour strike playing 
exactly on the hour

Combined with the Speak Time feature, we would obviously want to allow 
slightly more options, such as only chiming/speaking on the hour, turning off 
striking the hours (which can get very annoying and is meaningless for speak 
time), or chiming/speaking every x minutes.  I'm sure people can think of 
plenty more nice-to-have-but-rarely-used options that we don't want to 
expose most users to.

Expecting a user to configure a ui for all that is just not on.

The key to keeping it simple is to NOT allow the user to configure the sounds 
and when they play in the ui as most users will never need to do this, and 
catering for all the options is just too complex.  Instead we would define a 
Chime Theme file format that we and power users can use to configure how a 
Chime Theme works and what sound files to use, and provide the user with a 
simple list of available themes to choose from.  We could even allow 
downloading new themes from GHNS, in which case we would ship KDE with just a 
very simple theme.

Here's how a single ui section for Audible Feedback in the General tab 
would look like:

A combo for Feedback Type with options for:
 * None
 * Speak Time
 * Play Chimes

A combo for Frequency that is activated only if Feedback Type is not 
None, with options for:
 * Chime Theme Defaults (only show if Play Chimes chosen)
 * Hourly
 * Quarters
 * Every x Minutes (better wording needed)

(Note that Hourly and Quarters are just synonyms for every 60 or 15 minutes.)

Next to this combo is a minutes input spin box activated when Every x 
Minutes is chosen.  Alternatively we do Frequency as a radio button with 
the spinbox inline in the Every x minutes text.

A combo for Chime Theme which is only activated if Play Chimes is 
selected, with a list of the currently available themes:
 * Beep
 * Time Pips
 * Westminster
 * Cuckoo
 * ...

Next to this could be a GHNS button to download more themes.

Optionally under this could be a tick-box for Strike Hours which is only 
activated if Play Chimes is activated, to turn off striking hours which 
could get annoying.  Alternatively it could be integrated into the Feedback 
Type combo as separate options for Play Chimes and Strikes Play Chimes 
Only and Play Strikes Only.

I think 3 or 4 lines of simple config options is not too bad.  The Feedback 
Type and Chime Theme could even be merged for an even simpler interface.

The Chime Theme would actually be a self-contained folder holding a config 
file and all required sound files, and would look something like this:

  sounds/chimes/themename/
themename.desktop - Holds name of theme and default config options
default.ogg   - Default sound to play if no specific sound
strike.ogg
hour.ogg
quarterpast.ogg
half.ogg
quarterto.ogg

In the .desktop file itself, the config options would allow you to point to 
other sound files in other locations and set default frequency, e.g.:

[Sounds]
hour=/media/data/audio/sounds/doh.wav

There's lots of options that could be set here, but I won't detail them now.

Some possible Chime Themes:

Beep: A simple beep with slightly different ones for hours, quarters,
  and minutes. Ship with KDE, download the rest.
Time Pips:http://en.wikipedia.org/wiki/Greenwich_Time_Signal
Westminster:  http://en.wikipedia.org/wiki/Westminster_Quarters
Whittington:  http://en.wikipedia.org/wiki/Whittington_chimes
Ships Bells:  http://en.wikipedia.org/wiki/Ship%27s_bells

At first glance it may seem a fairly complex solution, but I think the 
implementation will actually be fairly simple and not add much overhead, the 
hardest part is designing the config file to be flexible enough.

John.

P.S. This is what you get from staring at the ceiling at 4am in the morning 
thanks to jet-lag :-)
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Automatic activity switching and other stuff -- thoughts for 4.7

[John Layt]

On Sunday 19 December 2010 08:49:34 Ryan Rix wrote:
 I've been thinking a lot about how to give the Activity Manager a way to
 predict what a user would like to be doing at a certain time, based on
 external input, whether that's things like current GPS coordinates, what is
 scheduled in KOrganizer right now, etc. What follows is a braindump of crap
 I've been contemplating since before akademy, and it may well not make any
 sense.

[Finally catching up on my mail after holidays]

Nice to see some thinking going on around this.  I blogged about this sort of 
thing a while back as a generic concept of Events triggering Actions which you 
might be interested in reading (see 
http://www.layt.net/john/blog/odysseus/the_reactive_desktop and be sure to 
follow the link to Marco Polo) and with the new Activities stuff this is 
looking more achievable. I'm still looking into the geolocation side of things 
(hopefully have a state-of-the-onion email on that soon) but would be happy to 
kick ideas around sometime.

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: First try on Git repo for kdebase-workspace

[John Layt]

On Monday 13 December 2010 23:56:56 Alex Fiestas wrote:
 On 12/14/2010 12:30 AM, Ian Monroe wrote:
  Dunno if dropping 'kde' makes sense. Dropping the 'base' makes sense,
  since its mostly a historical artifact. But workspace is KDE's
  workspace under past and present marketing schemes, so it makes sense.
  
  Plasma-workspace might be ok as well, even with Aaron's point. Just
  workspace seems way too generic. Remember this is the name the
  tarball would get, probably the name (new) distros would give the
  package as well...
 
 Well, it is already under the KDE git repository so in theory it is
 already KDE branded.
 
 For me just workspace works.

But if I clone to a random folder or repo somewhere it's a bit too generic.  I 
think kderuntime and kdeworkspace keeps it consistent with the rest of the kde 
repo.

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Compile Failure

[John Layt]

On Sunday 12 December 2010 01:53:48 Steven Sroka wrote:
 I'm trying to compile kdebase and I keep getting this compile error:
 /kdebase/workspace/libs/plasmaclock/calendartable.cpp:853:54: error: ‘class
 KHolidays::HolidayRegionSelector’ has no member named ‘setRegionUseFlags’
 My copy of trunk is up to date.

You need to svn up kdepimlibs, this was a BIC change I did last Monday.

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: The clock applet chiming per hour, half-hour and quarter hour

[John Layt]

---
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/6108/#review9215
---


This is wish https://bugs.kde.org/show_bug.cgi?id=232004

I think it should be in the base clock widget, I'm sure there will be people 
wanting chimes from the standard panel clock as well, so long as they are off 
by default and don't consume any resources.  See 
http://websvn.kde.org/trunk/KDE/kdebase/workspace/libs/plasmaclock/, probably 
done something like ClockApplet::speakTime(const QTime time).

You will need to allow users to configure multiple chimes, at least the 4 
quarters but possibly as many as they like at any time they like, and allow 
them to select a different sound for each chime.  Depending on the size it 
takes, put the config ui either into a new tab called Chimes, or into General 
which is the only current tab with any space left.

I wonder where we can get Free wav's for Westminster Chimes? :-)

- John


On 2010-12-12 19:20:12, Sunny Sharma wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://svn.reviewboard.kde.org/r/6108/
 ---
 
 (Updated 2010-12-12 19:20:12)
 
 
 Review request for Plasma, Aaron Seigo and Anne-Marie Mahfouf.
 
 
 Summary
 ---
 
 Hello Everybody,
 
 i have implemented the chiming of the analog clock every hour.though i have 
 hard coded it and it would only chime every hour. and not for 45 mins. 
 Presently I am working on the development of a ui which would allow the user 
 to set the clock to chime according to the choice of the user. 
 
 thanks,
 sunny_slls
 
 
 This addresses bug https://bugs.kde.org/show_bug.cgi?id=232004.
 
 https://bugs.kde.org/show_bug.cgi?id=https://bugs.kde.org/show_bug.cgi?id=232004
 
 
 Diffs
 -
 
   
 /trunk/KDE/kdebase/workspace/plasma/generic/applets/analog-clock/CMakeLists.txt
  1203585 
   /trunk/KDE/kdebase/workspace/plasma/generic/applets/analog-clock/clock.h 
 1203585 
   /trunk/KDE/kdebase/workspace/plasma/generic/applets/analog-clock/clock.cpp 
 1203585 
 
 Diff: http://svn.reviewboard.kde.org/r/6108/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Sunny
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: The clock applet chiming per hour, half-hour and quarter hour

[John Layt]

 On 2010-12-12 20:27:41, John Layt wrote:
  This is wish https://bugs.kde.org/show_bug.cgi?id=232004
  
  I think it should be in the base clock widget, I'm sure there will be 
  people wanting chimes from the standard panel clock as well, so long as 
  they are off by default and don't consume any resources.  See 
  http://websvn.kde.org/trunk/KDE/kdebase/workspace/libs/plasmaclock/, 
  probably done something like ClockApplet::speakTime(const QTime time).
  
  You will need to allow users to configure multiple chimes, at least the 4 
  quarters but possibly as many as they like at any time they like, and allow 
  them to select a different sound for each chime.  Depending on the size it 
  takes, put the config ui either into a new tab called Chimes, or into 
  General which is the only current tab with any space left.
  
  I wonder where we can get Free wav's for Westminster Chimes? :-)

Oh, and you'll need striking the hours as well, i.e. at 8pm you play a Bong 
sound 8 times, again able to be turned on/off and choose the sound.


- John


---
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/6108/#review9215
---


On 2010-12-12 19:20:12, Sunny Sharma wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://svn.reviewboard.kde.org/r/6108/
 ---
 
 (Updated 2010-12-12 19:20:12)
 
 
 Review request for Plasma, Aaron Seigo and Anne-Marie Mahfouf.
 
 
 Summary
 ---
 
 Hello Everybody,
 
 i have implemented the chiming of the analog clock every hour.though i have 
 hard coded it and it would only chime every hour. and not for 45 mins. 
 Presently I am working on the development of a ui which would allow the user 
 to set the clock to chime according to the choice of the user. 
 
 thanks,
 sunny_slls
 
 
 This addresses bug https://bugs.kde.org/show_bug.cgi?id=232004.
 
 https://bugs.kde.org/show_bug.cgi?id=https://bugs.kde.org/show_bug.cgi?id=232004
 
 
 Diffs
 -
 
   
 /trunk/KDE/kdebase/workspace/plasma/generic/applets/analog-clock/CMakeLists.txt
  1203585 
   /trunk/KDE/kdebase/workspace/plasma/generic/applets/analog-clock/clock.h 
 1203585 
   /trunk/KDE/kdebase/workspace/plasma/generic/applets/analog-clock/clock.cpp 
 1203585 
 
 Diff: http://svn.reviewboard.kde.org/r/6108/diff
 
 
 Testing
 ---
 
 
 Thanks,
 
 Sunny
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Disabled python scriptengine

[John Layt]

On Sunday 21 November 2010 17:48:22 Aaron J. Seigo wrote:
 On Sunday, November 21, 2010, Will Stephenson wrote:
  kdebase/workspace/plasma/generic/scriptengines/python has been disabled
  since August, any idea why?
 
 no i don't. this is the commit:
 
 http://websvn.kde.org/?view=revisionrevision=1159462
 
 i'll re-enable it and see who screams :)

Not screaming, but it does break build in my dev environment:

-- Installing: 
/media/laptop/Programming/KDE/inst/kde4trunk/share/apps/plasma_scriptengine_python/pydataengine.py
CMake Error at 
workspace/plasma/generic/scriptengines/python/cmake_install.cmake:56 (FILE):
  file INSTALL cannot find
  
/media/laptop/Programming/KDE/build/trunk/KDE/kdebase/workspace/plasma/generic/scriptengines/python//pydataengine.pyc.

Could just be something local, or why it was disabled.

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: plasmate status?

[John Layt]

On Monday 18 October 2010 17:57:59 Marco Martin wrote:
 On Monday 18 October 2010, Chani wrote:
  wouldn't it upset kdepim 4.4?
  given the changes in kdepim 4.5 I'd rather play it safe :) I'm probably
  lucky that kdepim and kdelibs still get along all right (ish).
 
 i'm using kdepim 4.4 with pimlibs trunk since a while, probably isn't a
 wise thing to do, but seems to work decently so far

Nope, should work fine, backwards compatible and all that, kdepim 4.4 
continues to use the older parts of kdepimlibs, only kdepim 4.5 uses the new 
stuff and it's the kdepim side that is problamatic, not kdepimlibs.

Cheers!

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Add city and country resolution to GPS geolocation data using geonames.

[John Layt]

On Monday 04 October 2010 20:31:36 John Layt wrote:
 On Saturday 25 September 2010 19:44:09 you wrote:
  On Saturday, September 25, 2010, you wrote:
   However, we really need to sort
   out geolocation services for KDE as a whole, re-inventing everything
   that Geoclue and Marble have already figured out is not the best use
   of resources.

  until someone does the research and finds a good solutions, however, we
  ought to continue to try to keep the geolocation engine at least
  moderately useful.

 Damn, wish I'd been organised enough to call a geolocation bof at Akademy,
 we had everyone we needed there.

I've found out the Marble guys are having a sprint in November, so I've scored 
an invite to discuss a number of things including geolocation services and 
other map related stuff for kdelibs/kdepimlibs/kdebase.  If anyone has 
thoughts on the matter drop me a line.  I'll do some more research over the 
next couple of weeks and post to k-c-d for discuassion before the sprint.

Cheers!

John.

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Plasma on N810

[John Layt]

On Monday 04 October 2010 12:33:16 Marco Martin wrote:
 On Monday 04 October 2010, Jeffery MacEachern wrote:
  On Mon, Oct 4, 2010 at 04:15, Artur de Souza aso...@kde.org wrote:
   Hi,
   
   Quoting Jeffery MacEachern j.maceach...@gmail.com:
   Has anyone tried running a recent version of Plasma on the N810 (under
   Maemo or MeeGo)?  Is it even feasible?  I've been wanting to use my
   N810 (affixed via car-mount to my equipment rack) as a sort of
   quick-glance dashboard, and Plasma's remote widgets would be an
   excellent fit, if I could get the requisite code running on it.
   
   Take a look at plasma-mobile as it should be lighter and more mobile
   oriented than plasma-desktop.
  
  Thanks, I intended to.  I just hadn't seen any talk of Plasma of any
  sort running on a device that old as of late, and wanted to see if
  anyone had been poking at it before undertaking the poking myself. :)
 
 it's been quite a long time i built kde on the n810 (i think it was with Qt
 4.5) so it should have gotten a bit better (both in terms of Qt speed and
 our fixes/optimizations in plasma) at the time  it did ran but was really
 too slow to be usable
 
 Cheers,
 Marco Martin

The problem I ran into when looking at it recently for an N800 is the Qt 
version required.  The final OS2008/Maemo Diablo version of Qt in the repos is 
Qt 4.5, which is not enough to build KDE SC 4.4 or later, so you would need to 
build your own version of Qt as well as many other libraries that KDE depends 
on.  You might have better luck investigating if the MeeGo skunkworks project 
for N810 is ready yet.

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Add city and country resolution to GPS geolocation data using geonames.

[John Layt]

On Saturday 25 September 2010 19:44:09 you wrote:
 On Saturday, September 25, 2010, you wrote:
  I do have a GPS, I could try get it working to test the patch if there is
  still interest in getting this in.  However, we really need to sort out
  geolocation services for KDE as a whole, re-inventing everything that
  Geoclue and Marble have already figured out is not the best use of
  resources.
 
 agreed; last i looked, geoclue was not broadly available on desktop linux /
 bsd (could be fixed by making it a dependency, of course ;) and carried
 some deps that weren't great for use in KDE (e.g. gconf). that was
 probably a little over a year ago now so that should be re-cehcked. as for
 marble, do you know if anything they've done is reusable?
 
 until someone does the research and finds a good solutions, however, we
 ought to continue to try to keep the geolocation engine at least
 moderately useful.

Unfortunately my gps unit doesn't give location over its usb port, only track 
downloads, so I can't test it.  I'll ask around my mates for one that does.

GeoClue is officially part of the MeeGo platform, and most distros seem to 
have it now, so availability shouldn't be an issue anymore.  Marble does have 
code for PositionProvider for GeoClue, gpsd and Maemo sources, but I'm not 
sure if its fully functional (see 
kdeedu/marble/src/plugins/positionprovider/).  We'd need to ask Torsten about 
that, but unless Marble moves some of its core libraries to kdesupport we 
wouldn't be able to use them anyway.

There's also the new Qt Mobility stuff which seems to cover everything needed, 
but pulls in a lot of other stuff we don't really need like their pim stuff.  
And it seems like another QWebKit/QtScript situation, shunning our own 
existing solution for upstream's solution.  On the other hand it will be 
guaranteed available on the mobile platform, even if no distros are shipping 
it yet.

Damn, wish I'd been organised enough to call a geolocation bof at Akademy, we 
had everyone we needed there.

Either way, there will always be a DataEngine for plasma, just with a GeoClue 
plugin or calling a kdelibs or Qt api, so any work to advance the engines api 
is worth it.

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: kdereview: events runner

[John Layt]

On Friday 27 August 2010 22:22:29 John Layt wrote:
 On 24 August 2010 22:06, Aaron J. Seigo ase...@kde.org wrote:
  other than that, it would be a very nice feature to do something like:
  events today or events tomorrow and get a list of them back ...

Forgot to mention this is easily done using the Calendar DataEngine.

 1) The runner directly interfaces with Akonadi, shouldn't the update parts
 be moved into a Plasma Service? (Yes, I'm supposed to be looking at moving
 the Calendar DataEngine into a Service but I'm doing fieldwork right now
 and won't have time for a few more weeks).

I found a little time and I've committed a first pass at the .operations file 
for the Service to 
workspace/plasma/generic/dataengines/calendar/calendar.operations.  It defines 
a minimal simple set of ops for adding Events/Todos/Journals, I'm still not 
convinced advanced ops like recurrences should be done through the Service 
method but rather done directly using Akonadi widgets.  

I'm assuming the source for the service will be the Akonadi::Collection for 
the Event/Todo/Journal to be added to, and a lot of the logic to talk to 
Akonadi and return the result will go into a CalendarServiceJob class.

Just wondering if it's possible in the .operations kcfg file to nest complex 
structures, have multiple occurrences for the same entry, or use Akonadi 
enums?  For example an Attendee has a name and e-mail and role etc and there 
can be several attendees, or their are allowed values for Status or Secrecy.  
What's the best way to handle these?

 2) It uses Boost shared pointers, shouldn't it be using a Qt equivalent?

I think the boost pointers are used by Akonadi as I can't see any code 
actually defining them directly?  If so you shouldn't need to include them 
directly, just use the Akonadi includes/typedefs instead.

A couple more comments:

The CompleteTodo and CommentIncidence actions take the Event/Todo Summary as 
the key for the incidence to update, but not only is this potentially a very 
long string and prone to mis-typing, it is also optional and not guaranteed to 
be unique so is not a good choice for the key.  The only unique and guaranteed 
key is the collection id and incidence id, but I'm not sure that's a user-
friendly choice so updating these via a runner might not be a good idea?

You also assume Incidences should be added to the default Collection, which is 
a reasonable assumption in most cases, but prevents people adding to other 
Collections (e.g. a remote or group calendar), you should try to find an 
optional syntax to allow users to include the Collection they want.

Cheers!

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: kdereview: events runner

[John Layt]

On 24 August 2010 22:06, Aaron J. Seigo ase...@kde.org wrote:

 hi ..

 the events runner has been in kdereview for a while now and it is time to
 decide what to do with it :)

 Alexey: if there are no known issues with it, please move it into
 kdeplasma-
 addons/runners/

 kdeplasma-addons has no hard restrictions on coding style, but we do
 encourage
 the use of kdelibs style so that there is an ease of switching between
 plugins
 for all plasma developers. it is up to you, however.

 other than that, it would be a very nice feature to do something like:
 events
 today or events tomorrow and get a list of them back ...

 cheers :)


Interesting, haven't seen that before.  A few comments after a quick look, I
can get more specific later.

1) The runner directly interfaces with Akonadi, shouldn't the update parts
be moved into a Plasma Service? (Yes, I'm supposed to be looking at moving
the Calendar DataEngine into a Service but I'm doing fieldwork right now and
won't have time for a few more weeks).

2) It uses Boost shared pointers, shouldn't it be using a Qt equivalent?

3) The code is a bit messy, it needs some polishing to kdelibs standard.

4) I don't think variantToDateTime() and dateTimeToVariant() are needed
anymore, KDateTime is now a proper QMetaType so will work seamlessly with
QVariant.

5) The DateTimeRange and DateTimeParser classes have far more methods in
them than actually get used in Event, either trim back to only what is
needed, or look to move to kdelibs where it can be used in a general case,
but it would need a lot of work, e.g. data members are currently public and
accessed directly rather than via get methods.

6) The date/time input formats are not localised, i.e. are not what the user
expects to be able to enter.  You should try use the standard KLocale read
date/time functions, don't try reinvent the wheel.  If only a fixed format
is possible then ISO format would be preferred using KDateTime methods.

7) Have you tested timezones work properly?

In short, I don't think it's ready yet.  I'd be happy to work with Alexey in
a few weeks to use his code to develop a Service for this based around the
existing calendar DataEngine.

Cheers!

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: changing the changelog

[John Layt]

On Thursday 12 August 2010 19:06:21 Artur Souza (MoRpHeUz) wrote:
 On Thu, Aug 12, 2010 at 2:48 PM, Aaron J. Seigo ase...@kde.org wrote:
  i'd like to therefore request that all commits to plasma code in kdelibs,
  kdebase and kdeplasma-addons that represent a new feature or a bug fix
  include the appropriate keywords in the commit msg. kmail will filter
  them for me :)
 
 This will also help when we migrate to git: using git shortlog or
 git log --pretty=oneline it will be much easier to generate the
 Changelogs :).
 
 So, it's *really* important that we write nice first line message
 and then a nice commit message for each commit :) It will help the
 maintainer's life a lot :D
 
 Cheers,

One of the things I really like about git is how easy it is to set up a commit 
message template that could include all the keywords as a memory aid (1).  
I've tried a quick google but there doesn't seem to be an easy way to do this 
using subversion?

John.

(1) For the Nokia/Qt template see 
http://qt.gitorious.org/qt/qt/blobs/4.7/.commit-template
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: battery: change brightness on mouse wheel

[John Layt]

 On 2010-08-01 01:53:17, Aaron Seigo wrote:
  you don't need to propagate wheel events (or most other events, for that 
  matter, unless there is an underlying implementation that also needs to be 
  called). i don't know why it would be crashing with looking at the 
  backtrace.
  
  that said, however, i don't see the connection between the battery icon and 
  the brightness of the screen. screen brightness affects power usage, sure, 
  but it's a little like scrolling on the app menu and having it switch 
  between windows :)
  
  as such, i don't think this is something that should go into svn.

Drive-by bike-shedding :-)

Scrolling over an indicator icon suggests changing the primary function of that 
indicator, so scrolling over the battery suggests to me changing the Power 
Profile.  Progressively switching from one profile to the next as the user 
scrolls would not be a good thing, so scrolling would just show a pop-up with a 
list of all the profiles with a highlight around the selection that the 
scrolling would move, then once the scrolling stops after a slight delay the 
profile would switch.

For easily changing the brightness I would suggest a new Screen Brightness 
plasmoid in kdebase that works like the Volume plasmoid.  It would display the 
fairly standard sunshine icon that you can scroll over, with the sun's ray 
changing in size accordingly and clicking on it would pop-up a slider.  Bonus 
points for integrating the NVDimmer screen brightness functionality, although 
that probably needs to be done further down the stack in Solid :-)

It always seemed a little strange to me to have the screen brightness slider 
and sleep and hibernate buttons in the battery/power management plasmoid 
pop-up, it's not really obvious to users and trying to use any of them was 
always 2-3 clicks away when 1-2 would be better.  The battery should be purely 
about power profile management.  With a separate brightness plasmoid, and the 
lock plasmoid now also providing the sleep/hibernate buttons, the battery 
pop-up on click could be simplified to just choosing the Power Profile using 
the same pop-up as the scrolling action suggested above.  I think this would 
give the indicators a more consistent look-and-feel, and work better for the 
mobile/netbook containments.  Tying it all together would be an 'Add Panel' 
profile for 'Laptop' that includes the battery and brightness plasmoids and the 
lock plasmoid with the sleep/hibernate buttons enabled, then on plasma first 
run try make an intelligent choice between using the normal default Desktop 
panel profile or the Laptop profile.  Sound elegant? :-)


- John


---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/4810/#review6758
---


On 2010-08-01 01:01:33, Rafa? Mi?ecki wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviewboard.kde.org/r/4810/
 ---
 
 (Updated 2010-08-01 01:01:33)
 
 
 Review request for Plasma.
 
 
 Summary
 ---
 
 This implements feature requested in bug 230888 . Scrolling over battery 
 plasmoid changes brightness.
 
 In (uncommon) case of multiple brightness devices it affects the first 
 registered device. We may want to make it configurable in the future.
 
 
 This addresses bug 230888.
 https://bugs.kde.org/show_bug.cgi?id=230888
 
 
 Diffs
 -
 
   /trunk/KDE/kdebase/workspace/plasma/generic/applets/battery/battery.h 
 1157714 
   /trunk/KDE/kdebase/workspace/plasma/generic/applets/battery/battery.cpp 
 1157714 
 
 Diff: http://reviewboard.kde.org/r/4810/diff
 
 
 Testing
 ---
 
 It works fine for my notebook, doesn't crash on machine without brightness 
 device.
 
 The part I am not sure about is:
 Applet::wheelEvent(e);
 I though we need to propagate events so tried to use this call. However using 
 it causes crash. Help?
 
 
 Thanks,
 
 Rafa?
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: battery: change brightness on mouse wheel

[John Layt]

On Sunday 01 August 2010 16:52:07 Alex Fiestas wrote:
 Most laptops have
specific keys (Fn+X) to change the brightness, so I'm
 not sure about add a
second plasmoid just to do that by default.
 
 Anyway, I don't really see
an issue with the current Battery plasmoid,
 it does what it has to
imho.

Most laptops also have keys for volume and we have an OSD for
displaying while pressing them, but that doesn't mean we don't need the
Volume plasmoid and should hide the volume slider away in the Now Playing
plasmoid instead.  

Same goes for suspend, wireless,  multimedia, expose,
dashboard, battery, eject and menu which are all on my keyboards, or even
standard key mappings like for copy and paste.

Not every form factor is
guaranteed to have convenient buttons for everything or anything (e.g.
mobiles), and it's a useful visual confirmation for users of the current
status separate from their battery status.  I see no harm in providing users
that option.  It's also the only logical way to implement mouse-wheel for
brightness, which you seem to think would be useful too :-)

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Akonadi PIM in the Plasma Calendar

[John Layt]

Hi pimsters and plasma-wranglers(?),

Just a follow-up on where this is now.  

After Akademy I managed to finish off my changes to the calendar data engine 
to enable recurring and multi-day incidences to be treated correctly.  
Basically I deleted much of what was already there and started again.

This still required copying files from kdepim/akonadi/kcal which now live in 
their own directory 
kdebase/workspace/plasma/generic/dataengines/calendar/akonadi along with a 
README explaining the what and why:

  calendar_p.h
  calendar.h
  calendar.cpp
  calendarmodel.h
  calendarmodel.cpp
  calfilterproxymodel.h
  calfilterproxymodel.cpp
  utils.h
  utils.cpp

If anyone makes bug-fixes to those classes in kdepim could you also apply them 
to kdebase, or at least ccmail: me so I can keep them in sync?  Thanks.

The CalendarEngine now returns almost all the Event/ToDo/Journal attributes 
for all Incidences that occur within the requested date range, as well as a 
list of all the Recurrences for each Incidence within the requested date 
range.  Only Attendees, Attachments, Relations, Alarms, Custom Properties, 
Lat/Lon and Collection/Source are not (yet) returned.  The returned data 
structure can be found in 
kdebase/workspace/plasma/generic/dataengines/calendar/calendarengine.h.

The problems with the original code resulted from it not being obvious to us 
non-experts that requesting from Akonadi a list of Incidences in a date range 
does not return all the Recurrences in that date range, only the base 
Incidence which gives Start/End Dates for the first Recurrence only which may 
not even fall in the requested date range.  Explicit calls must be made on 
each base Incidence to obtain the Recurrences and their End Dates.  I don't 
think the KCal::CalendarModel::entityData() call even exposes the recurrence 
details at all, hence having to switch to KCal::Calendar class instead.

Any new Akonadi/KCal API intended for use outside kdepim should try to make 
this easier and more obvious to non-experts, i.e. that a one-to-many model is 
needed between Incidences and Recurrences.

Where to next?

Obviously we'll start using the new Akonadi/KCal code once it's in kdepimlibs, 
remove the duplicated code, and add the last few missing fields to the 
returned data.

I think the code needs to move from the Calendar DataEngine into the Akonadi 
DataEngine so they can share a common infrastructure and consistent API 
design.

We'll need to allow the user to configure what Collections/Sources get 
displayed in each plasmoid instance, and to filter within those Collections 
e.g. have work and personal calendars on separate widgets, hide private 
events, disable events if calendar displayed on screen-saver, etc.  Or even to 
turn it off entirely, something missing in 4.5 ;-)

There's probably a lot that can be done to make the display prettier, but I'll 
mostly leave that to the Plasma guys, they're better at that kind of stuff :-)  
Perhaps use html table formatting in the pop-up text to allow proper layout 
and indenting?

The big one will be allowing creating/editing of Incidences.  I managed to 
grab Marco for a couple of minutes just before he left Akademy.  He pointed me 
at Plasma Services which are designed for Plasmoids needing to perform 
updates.  He would prefer that we try implement as much functionality as 
possible using a Service so it is usable by scripted Plasmoids, but did agree 
that advanced/complicated functionality like the recurrence editor might be 
better off used directly rather than being duplicated.  This needs more 
investigation as I don't understand any of it yet :-)  Perhaps I can copy how 
sebas does it in LionMail if it works that way?

Cheers!

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Plasma Calendar showing Akonadi Events in SC 4.5

[John Layt]

I've been chatting to the kdepim guys about the bugs in the plasma calendar 
when showing pim events.  While I'm on track to fix those today, a more basic 
issue has appeared.

The plasma calendar uses Akonadi to obtain the calendar data.  Calendar data 
is being akonadi-fied for the first time in kdepim 4.5.  kdepim 4.5 has been 
delayed and will not ship with the rest of SC 4.5.  Hence most users will not 
even see the calendar events displayed as their data will not have been 
migrated and they do not have the compatibility layer enabled.

This becomes a comms issue.  If we announce the feature in the release plan 
then we will get bug reports for it not working and disappointed users.  We 
need to either not announce the feature at all, or make it very clear that 
this will only work when kdepim 4.5 is released which may be several months.

Cheers!

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request: Fix some Event/Todo problems in Plasma Calendar

[John Layt]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/4387/
---

Review request for Plasma.


Summary
---

Fix some problems and make some improvements:
1) Todo items were not being cached or displayed as they don't have a 
StartDate. Instead return the TodoDueDate and other Todo details in the 
DataContainer for clients to use.  Use the TodoDueDate to index and display 
Todo's, other details cannot be added due to string freeze (do in 4.6).
2) Only show Event times in Calendar pop-up, not dates as pop-up is for a 
single date anyway
3) Tweak the whitespace in the pop-up
4) Cache Events/Todos as Data rather than display strings, only format display 
strings at point of display
5) Generally make Event/Todo code more consistent with Holiday code

What still doesn't work correctly:
1) Recurring events only show first occurrence
2) Date range filter does not work, all Akonadi Events/Todos are returned and 
cached
3) New or modified Events/Todo's (e.g. in KOrganizer) do not auto-update in 
plasma as they should
4) There might be an issue with multi-day events not displaying on correct days
5) There might be issues with timezones

Still looking into these, may need help from the pimsters to work out why.


Diffs
-

  trunk/KDE/kdebase/workspace/libs/plasmaclock/calendartable.cpp 1139216 
  
trunk/KDE/kdebase/workspace/plasma/generic/dataengines/calendar/eventdatacontainer.cpp
 1137927 

Diff: http://reviewboard.kde.org/r/4387/diff


Testing
---

Usual rounds of testing with plasmoidviewer and akonadi resources with plenty 
of events and todos.


Thanks,

John

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request: Modify Calendar Data Engine to not use multiple keys

[John Layt]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/4273/
---

Review request for Plasma.


Summary
---

Remove use of insertMulti() by changing holidays data request to return a 
list instead of a hash.  Holidays don't really have a unique key, neither date 
nor name are unique, so a list of objects with attributes better matches the 
data than a hash.  The date is simply another attribute of the holiday rather 
than being the key (with more attributes to come in 4.6).

Alternatives:
* Keep the hash with date as key, with a nested list of holidays for that date 
as the value, which just seems over-complex to set-up and read.
* Keep the hash but with a random meaningless key and the date as an attribute, 
which is really just another name for a list.


Diffs
-

  trunk/KDE/kdebase/workspace/libs/plasmaclock/calendartable.cpp 1136478 
  
trunk/KDE/kdebase/workspace/plasma/generic/dataengines/calendar/calendarengine.h
 1136478 
  
trunk/KDE/kdebase/workspace/plasma/generic/dataengines/calendar/calendarengine.cpp
 1136478 

Diff: http://reviewboard.kde.org/r/4273/diff


Testing
---

Calendar plasmoid displays multiple holidays on same day with distinction 
between days-off and days-on.


Thanks,

John

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: fix data leak in dataengines

[John Layt]

 On 2010-06-09 01:06:51, Aaron Seigo wrote:
  John's commit should just be reverted and the calendar dataengine changed 
  properly. this penalizes the common case and adds more complexity that is 
  uneeded, and the calendar dataengine really ought to list all holidays for 
  the same day in one key/value pair. using QVariant for the values in 
  DataEngines allows us to use lists and other such fancy things, and they 
  work very well even in the automatic scripting bridges.
 
 Beat Wolf wrote:
 I'm no expert for the dataengines. so i let the experts sort that out ;) 
 at least i found the problem :) or i can just revert the other commit.
 
 Beat Wolf wrote:
 never mind, didn't see the comment in the other patch.

OK, I'll revert my commit and change the data engine to wrap the data in 
another level of container.


- John


---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/4261/#review6047
---


On 2010-06-08 20:30:26, Beat Wolf wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviewboard.kde.org/r/4261/
 ---
 
 (Updated 2010-06-08 20:30:26)
 
 
 Review request for Plasma.
 
 
 Summary
 ---
 
 fix the data leak introduced by http://reviewboard.kde.org/r/4235/
 The fix is to use insertMulti if multiple values with the same key are added 
 at once.
 
 
 Diffs
 -
 
   trunk/KDE/kdelibs/plasma/datacontainer.h 1136034 
   trunk/KDE/kdelibs/plasma/datacontainer.cpp 1135137 
   trunk/KDE/kdelibs/plasma/dataengine.cpp 1135137 
 
 Diff: http://reviewboard.kde.org/r/4261/diff
 
 
 Testing
 ---
 
 Different plasmoids using dataengines
 
 
 Thanks,
 
 Beat
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Re-enable showing all holiday types in plasma calendar

[John Layt]

 On 2010-06-05 09:25:36, Marco Martin wrote:
  I like it. unfortunately introduces strings, so i think it's too late for 
  4.5?

No new strings, just an old one moved down few lines.  I would have liked to 
have a label for the 'other' holidays so it's clearer they are not a day off, 
but didn't for this very reason.


- John


---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/4236/#review5991
---


On 2010-06-05 00:10:56, John Layt wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviewboard.kde.org/r/4236/
 ---
 
 (Updated 2010-06-05 00:10:56)
 
 
 Review request for Plasma.
 
 
 Summary
 ---
 
 The calendar data engine will now return all holidays along with their 
 holiday type, i.e. if a day off or not.  The calendar plasmoid only shows 
 days off highlighted in red.  In the pop-up only days off are prefixed with 
 'Holiday', but all other holidays are now listed.
 
 I have also changed how Events are displayed.  They were shown as a green 
 highlight with higher priority than a holiday.  This caused two issues.  
 First, information is blocked, it can only show a day is a Holiday or an 
 Event, it can't show when you have both on the one day.  Second, many users 
 will have Events on almost every day, so almost every day would be green 
 highlighted, which besides looking ugly and busy also effectively wastes a 
 high visibility signal on a more common piece of information.  Instead I've 
 gone for the more standard bold day number as done in KOrganizer and most 
 other calendar programs, and re-used the green highlight for Holidays that 
 are not days off.
 
 In the future we could use other options such as cell shading and font 
 colour, and make it user configurable.
 
 Screenies attached.
 
 
 This addresses bug 218549.
 https://bugs.kde.org/show_bug.cgi?id=218549
 
 
 Diffs
 -
 
   trunk/KDE/kdebase/workspace/libs/plasmaclock/calendartable.h 1134154 
   trunk/KDE/kdebase/workspace/libs/plasmaclock/calendartable.cpp 1134154 
   
 trunk/KDE/kdebase/workspace/plasma/generic/dataengines/calendar/calendarengine.h
  1133276 
   
 trunk/KDE/kdebase/workspace/plasma/generic/dataengines/calendar/calendarengine.cpp
  1133276 
 
 Diff: http://reviewboard.kde.org/r/4236/diff
 
 
 Testing
 ---
 
 Always :-)  Note in the second screenie we have Feb 12 with a public holiday 
 (day off), a commemorative holiday (not a day off), and an event.
 
 
 Screenshots
 ---
 
 Calendar Table
   http://reviewboard.kde.org/r/4236/s/418/
 Calendar Popup
   http://reviewboard.kde.org/r/4236/s/420/
 
 
 Thanks,
 
 John
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Re-enable showing all holiday types in plasma calendar

[John Layt]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/4236/#review5993
---



trunk/KDE/kdebase/workspace/libs/plasmaclock/calendartable.cpp
http://reviewboard.kde.org/r/4236/#comment5613

Nope, already existing string, see old line 531 :-)


- John


On 2010-06-05 00:10:56, John Layt wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviewboard.kde.org/r/4236/
 ---
 
 (Updated 2010-06-05 00:10:56)
 
 
 Review request for Plasma.
 
 
 Summary
 ---
 
 The calendar data engine will now return all holidays along with their 
 holiday type, i.e. if a day off or not.  The calendar plasmoid only shows 
 days off highlighted in red.  In the pop-up only days off are prefixed with 
 'Holiday', but all other holidays are now listed.
 
 I have also changed how Events are displayed.  They were shown as a green 
 highlight with higher priority than a holiday.  This caused two issues.  
 First, information is blocked, it can only show a day is a Holiday or an 
 Event, it can't show when you have both on the one day.  Second, many users 
 will have Events on almost every day, so almost every day would be green 
 highlighted, which besides looking ugly and busy also effectively wastes a 
 high visibility signal on a more common piece of information.  Instead I've 
 gone for the more standard bold day number as done in KOrganizer and most 
 other calendar programs, and re-used the green highlight for Holidays that 
 are not days off.
 
 In the future we could use other options such as cell shading and font 
 colour, and make it user configurable.
 
 Screenies attached.
 
 
 This addresses bug 218549.
 https://bugs.kde.org/show_bug.cgi?id=218549
 
 
 Diffs
 -
 
   trunk/KDE/kdebase/workspace/libs/plasmaclock/calendartable.h 1134154 
   trunk/KDE/kdebase/workspace/libs/plasmaclock/calendartable.cpp 1134154 
   
 trunk/KDE/kdebase/workspace/plasma/generic/dataengines/calendar/calendarengine.h
  1133276 
   
 trunk/KDE/kdebase/workspace/plasma/generic/dataengines/calendar/calendarengine.cpp
  1133276 
 
 Diff: http://reviewboard.kde.org/r/4236/diff
 
 
 Testing
 ---
 
 Always :-)  Note in the second screenie we have Feb 12 with a public holiday 
 (day off), a commemorative holiday (not a day off), and an event.
 
 
 Screenshots
 ---
 
 Calendar Table
   http://reviewboard.kde.org/r/4236/s/418/
 Calendar Popup
   http://reviewboard.kde.org/r/4236/s/420/
 
 
 Thanks,
 
 John
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Stop DataContainer from discarding multiple values for a single key.

[John Layt]

 On 2010-06-05 09:29:07, Marco Martin wrote:
  good catch.
  could also have something to do wwith 
  https://bugs.kde.org/show_bug.cgi?id=240462  ?

Just tested that scenario, but I'm afraid it doesn't fix it.  I'll try look at 
that, and there's another report duplicated entries and failures to update.  I 
also think the Event details displayed need a bit of polish.


- John


---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/4235/#review5992
---


On 2010-06-05 00:08:34, John Layt wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://reviewboard.kde.org/r/4235/
 ---
 
 (Updated 2010-06-05 00:08:34)
 
 
 Review request for Plasma.
 
 
 Summary
 ---
 
 If a DataEngine implementation uses QHash::insertMulti() to try return 
 multiple values for a key, the DataContainer discards the multiple values and 
 only returns a single value to the client.
 
 A simplified example showing where 2 holidays occurring on the same date need 
 to be treated as separate data entities:
 
 Plasma::DataEngine::Data holidays;
 holidays.insertMulti(2010-06-01, A national public holiday);
 holidays.insertMulti(2010-06-01, A minor religious holiday);
 setData(request, holidays);
 
 What gets returned to the client is only the second value for the minor 
 religious holiday, so the public holiday doesn't appear on the calendar.
 
 This is because the call to setData() loops through each value in the passed 
 in DataEngine::Data and calls DataContainer::setData(), which inserts each 
 value into a new DataEngine::Data, in the process discarding any previous 
 multiple values.
 
 This patch uses insertMulti() in the DataContainer::setData() to fix this.  I 
 can't think of anything this would break by changing the behaviour to retain 
 any multiples, they can only get there in the first place by the DataEngine 
 explicitly calling insertMulti() so I think it's safe to assume the coder 
 wants them kept.
 
 The alternative would be to create new DataEngine::setMultiData() and 
 DataContainer::setMultiData() methods.
 
 
 Diffs
 -
 
   /trunk/KDE/kdelibs/plasma/datacontainer.cpp 1134380 
 
 Diff: http://reviewboard.kde.org/r/4235/diff
 
 
 Testing
 ---
 
 Without the patch, holidays disappear between the calendar data engine and 
 the calendar plasmoid.  With the patch all the holidays make it and can be 
 treated differently according to type.
 
 
 Thanks,
 
 John
 


___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request: Stop DataContainer from discarding multiple values for a single key.

[John Layt]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/4235/
---

Review request for Plasma.


Summary
---

If a DataEngine implementation uses QHash::insertMulti() to try return multiple 
values for a key, the DataContainer discards the multiple values and only 
returns a single value to the client.

A simplified example showing where 2 holidays occurring on the same date need 
to be treated as separate data entities:

Plasma::DataEngine::Data holidays;
holidays.insertMulti(2010-06-01, A national public holiday);
holidays.insertMulti(2010-06-01, A minor religious holiday);
setData(request, holidays);

What gets returned to the client is only the second value for the minor 
religious holiday, so the public holiday doesn't appear on the calendar.

This is because the call to setData() loops through each value in the passed in 
DataEngine::Data and calls DataContainer::setData(), which inserts each value 
into a new DataEngine::Data, in the process discarding any previous multiple 
values.

This patch uses insertMulti() in the DataContainer::setData() to fix this.  I 
can't think of anything this would break by changing the behaviour to retain 
any multiples, they can only get there in the first place by the DataEngine 
explicitly calling insertMulti() so I think it's safe to assume the coder wants 
them kept.

The alternative would be to create new DataEngine::setMultiData() and 
DataContainer::setMultiData() methods.


Diffs
-

  /trunk/KDE/kdelibs/plasma/datacontainer.cpp 1134380 

Diff: http://reviewboard.kde.org/r/4235/diff


Testing
---

Without the patch, holidays disappear between the calendar data engine and the 
calendar plasmoid.  With the patch all the holidays make it and can be treated 
differently according to type.


Thanks,

John

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request: Convert Plasma Calendar to use new KHolidays API

[John Layt]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/4079/
---

Review request for Plasma.


Summary
---

In SC 4.5 KHolidays has a number of new API calls to provide more metadata on 
each Holiday Region, such as Name, Country (including subdivisions such as 
States and Provinces) and Language, to test validity of a given Holiday Region 
code, and to return all holidays in a date range.

This patch adapts the plasma calendar data engine and calendar plasmoid to use 
this new API to improve efficiency and usability.  However, because of the data 
engine abstraction layer what is a small and simple change in other KHolidays 
clients required major changes in the data engine to basically recreate and 
wrap the new KHolidays API calls.  As such it could be argued that this is a 
new feature rather than just an efficiency and usability fix, and so has missed 
the feature freeze boat.  I'll leave that call to others, but if deemed too big 
I'll try a smaller efficiency fix within the bounds of the existing data engine 
API.

* Efficiency is improved by fetching all the holidays to display in a single 
call, rather than 3 calls by the plasmoid and 90 calls by the data engine (and 
thus saving reading the holiday file 90 times), and by using the 
isValid(regionCode) API instead of fetching all the regions and scanning for a 
match.

* Usability is improved by displaying the real name of the Holiday Region (e.g. 
if it's actually a state or province) and the language each Holiday Region is 
available in, and by including the language as a criteria in the default 
Holiday Region selection so the user is more likely to get a useful Holiday 
Region (e.g. in bilingual countries).

I've also included a few bug fixes and validity checking of the contents of the 
data queries.


Diffs
-

  trunk/KDE/kdebase/workspace/libs/plasmaclock/calendartable.cpp 1128950 
  
trunk/KDE/kdebase/workspace/plasma/generic/dataengines/calendar/calendarengine.h
 1128950 
  
trunk/KDE/kdebase/workspace/plasma/generic/dataengines/calendar/calendarengine.cpp
 1128950 

Diff: http://reviewboard.kde.org/r/4079/diff


Testing
---

Extensive testing using plasmoidviewer, especially of the new default region 
algorithm with various combinations of country and language.


Thanks,

John

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Concerning the KDE 4 Digital Clock widget

[John Layt]

 On Saturday 13 February 2010 05:16:50 Maki Jaderborg wrote:
  I was wondering if the digital clock widget present in KDE 4, which lists
  you as the author, could be configured like the PHP date() option.
  http://php.net/manual/en/function.date.php

I have been slowly looking at the config options in the digital clock for a 
while, but have yet to come up with a fully satisfactory solution.  We have a 
couple of outstanding wishes in bugs.kde.org against this already with very 
vocal users :-)

We basically need to balance keeping the clock config simple for the majority 
of users versus supporting our power-users desire to tweak everything.

KDE already supports the full POSIX date format standard in our date 
formatting API, which is very similar to that used in PHP.  However forcing 
the average user to learn and enter format strings like %d %M %Yis not a 
nice way to do things, and is prone to error.  In our Regional System Settings 
when setting the system date format we wrap this in an easier syntax like DD 
MONTH  but that fails for the same reasons.

I did try an interim step where I replaced the current configuration tickboxes 
with a combo box which allowed you to choose between the system short date 
format and several standard variations show as examples rather than formats, 
but I was never happy with it as there were too many options listed.  I also 
tried a combination of a combo and tickboxes but that just felt clunky, and 
adding lots of tickboxes for each option gets messy and also has localisation 
issues.

I have blogged in the past about how OSX does it using a drag-and-drop gui 
widget (http://www.layt.net/john/blog/odysseus/a_challenge) and how we could 
do even better, but I've had little chance to take it further.

I'm open to suggestions :-)

Cheers!

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Concerning the KDE 4 Digital Clock widget

[John Layt]

On Thursday 25 Feb 2010 15:03:04 Riccardo Iaconelli wrote:
 On Thursday 25 February 2010 10:27:12 Maki Jaderborg wrote:
  But the KDE 3.5 clock at least allowed the following configuration
  options:
  
  Time format:
  HH:MM:SS
  pH:MM:SS AMPM
  
  Date format:
  WEEKDAY DD MONTH 
  SHORTWEEKDAY MONTH dD 
  
  Short date format:
   -MM-DD
  
  dD.mM.
  DD.MM.
  
  Why didn't those move over into the KDE 4 clock?
 
 Well, this is reasonable, and we can probably implement a similar feature
 in the default clock. See below for details.

Let the bike-shedding commence :-)

The 'replace tickboxes with combo box' option I've been trying has the 
following options (where the example date/time shown is as at that moment):

Show Time:
  System default format - 16:11
  24 hour clock, no seconds - 16:11
  24 hour clock, with seconds - 16:11:23
  12 hour clock, no seconds - 16:11 pm
  12 hour clock, with seconds - 16:11:23 pm

I think this might be simpler with 3 radio buttons for choosing System Format, 
24 Hour, or 12 Hour (or just those options in the combo), with a tickbox for 
Show Seconds as currently done.  If Date Format uses a combo, then using radio 
buttons might look inconsistent.

Show Date:
  Do not show date
  System default short date - 25/02/2010
  ISO standard short date - 2010-02-25
  Short weekday - Thu
  Long weekday - Thursday
  Day and Month - 25/02
  Day, Month and Year - 25/02/2010
  Weekday, Day and Month - Thu 25/02
  Weekday, Day, Month and Year - Thu 25/02/2010
  Day and Month Name - 25 Feb
  Day, Month Name and Year - 25 Feb 2010
  Weekday, Day and Month Name - Thu 25 Feb
  Weekday, Day, Month Name and Year - Thu 25 Feb 2010
  ... and many many more...

Each of those date formats is translated so are sort-of localised for regional 
customs with regards to ordering (mm/dd or dd/mm?) and separators (spaces, 
commas, dashes, slashes, dots or combinations there-of?).  However language 
based localisation is not the same as region based localisation, e.g. a 
Spanish speaker in the USA would get the wrong format.

It then just becomes a question of which combinations to include in the list, 
trying to cater for them all would get overwhelming.  One solution to both 
this and the localisation issue might be to add a list of preferred date 
formats to the locale file for each country and just show those with a few 
standard options.

It's been suggested in bko that in addition to setting the Long Date and Short 
Date formats in System Settings we have a new option for Short Display Date 
that the clock could use, but that's just moving the problem elsewhere.

Using a bunch of tickboxes and/or radio buttons for Show Weekday, Show Year, 
Use Month Name, Use Short Numbers, Use Short Names, Show Month First, etc, 
would I think look messy and overwhelming and localising all the possible 
combinations would make for a long translation list.  Using both a combo and a 
few tickboxes might work but I haven't tried it yet as it seems an awkward 
process to me.

Allowing the user to edit their own format strings avoids all these issues but 
is bad usability, which is where a simple drag-and-drop config wizard would be 
a good thing.

Cheers!

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Plasma Calendar data engine widget future plans

[John Layt]

Hi guys,

I'm currently revising the KHolidays library to be more useful, in particular:
* Return a date range, not just a single date
* Support non-Gregorian calendars (Islamic  Jewish holidays, etc)
* Add holiday type (Public, School, Financial, Religious, Cultural, etc)
* Split holiday region files by type / sub-region / etc, i.e. allow separate 
selection of national, provincial and religious holiday files, etc
* Add file metadata for region, language, name, etc.
* Proper translation of holiday region name (but not holiday names 
themselves)

I'm planning to use the Plasma Calendar as a test client for these changes and 
so want to add the following:

* Support multiple holidays on each day
* Support multiple holiday regions at once
* Choose which holiday region(s) to highlight as days off
* Tool-tip on hover over day showing any holidays

Of course, this is it is also a start on how to display PIM data from Akonadi 
(if not yet the two-way integration).  I'm not sure if anyone is planning to 
work on that yet, but decisions on how to display holidays will affect pim and 
so need to be thought about together.

Some points that will need input from you and the usability guys:

* How do we highlight holidays, just stick to the current halo, or support 
multiple methods such as halo colour, day number colour, day number 
bold/italic, and cell background colour/shade.

* Do we provide users the option of choosing the highlight method for each 
holiday type, or not to highlight some types?  Or do we impose 'sensible' 
options?

* How do we highlight multiple holidays and types on the same day cell?  Do we 
rank holiday types so we show only a single highlight for each day, apply 
ranking at the highlight method level, or try show all types at once?  (See 
bug 46262 for some user suggestions on PIM display in general).  Has anyone 
used other calendar applets that do this well that we can learn from?

* How to show Weekends (shading of cell or day header?) and Day of Religious 
Observance (red day number? possibly do same for all religious holidays?).

* In configuration, for selecting multiple holiday regions I was thinking to 
have all the available regions listed like the timezones are, but with two 
tick-boxes, one for show on calendar and another for show as days-off.

As always we need to balance features with ease-of-use and not end up with a 
visual mess.

Just on pim/akonadi integration, I think the obvious interaction would be 
double-click on a day opens KOrganizer on that day, right-click on a day puts 
options in the menu for add/edit pim 'stuff' for that day.  That's not my 
immediate priority, but we should think about it in general terms to see if it 
would clash with the holidays handling.

Thoughts?

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Tokamak4 Attendance, LAST CALL

[John Layt]

On Tuesday 05 January 2010 11:26:27 Sebastian Kügler wrote:
 Please everybody who's planning to attend Tokamak4, to be held from 19th -
  26th February at the openSuse premises in Nuremberg, Germany, do the
  following:
 
 Put your name into the wiki page, including as much information as you can:
 
   http://techbase.kde.org/Projects/Plasma/Tokamak4
 
 There's too many TBD in there at this point to be able to request a
  budget, so we need this nailed down. The further process looks as follows:
 
 - Tomorrow night (Europe!), I'll take the list of attendees and add up the
  travel costs
 - I'll get a quote from a suitable ho(s)tel (Will gave some good pointers)
 - I'll request budget from the e.V., hopefully get it approved relatively
  quickly - as soon as we got approval, I'll notify you and you book your
  tickets, we'll book the ho(s)tel
 
 The numbers you put in are the amounts you'd need reimbursement from the
  KDE e.V. for, not necessarily (but possibly) the total travel expenses.
  Note that if you don't put anything specific in, we might not be able to
  reimburse you for these costs. We can't have the budget changing
  constantly, that's why I'm putting a rather hard deadline.
 
 As to the dates: Do plan to arrive on the 19th. Will checks if we can
  conquer the opensuse hacking space that day already. Plan to leave on the
  26th (if needs be, earlier). After the 26th, we'll not take care of
  accommodation (but you can obviously organize something for yourself).
  Make sure your travel dates are correct on the wikipage, as that's what
  we're basing room reservations on.
 

I had hoped to make it to discuss/code improvements to the calendar widget, 
especially holidays and pim integration via akonadi, but the weekend is out 
for me.  I may be able to make it from Monday onwards, but I won't know that 
for a couple more weeks, so I'll make my own arrangements.  Will anyone else 
interested in the calendar/holidays/pim still be around during the week?

Cheers!

John.

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: bugfixing

[John Layt]

And a little reminder to have a look at your krazy checks too, most may seem 
minor nitpicking but every little bit helps :-)  And if you clean out the 
minor stuff, then the major stuff becomes easier to track.

kdelibs/plasma has 148 code and 716 apidox issues
kdebase/apps/plasma has 12 code issues
kdebase/runtime/plasma has 9 code issues
kdebase/workspace/plasma has 212 code and 245 apidox issues
kdeplasma-addons has 194 code and 93 apidox issues

Could I ask that you especially check the copyright and license issues 
highlighted?

Remember, if you are unable to fix something krazy highlights, you can flag it 
to be ignored, just document why you can't fix it, see 
http://techbase.kde.org/Development/Tutorials/Code_Checking

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Fix Plasma CalendarTable widget for RTL

[John Layt]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2088/
---

(Updated 2009-11-29 00:56:27.688430)


Review request for Plasma.


Changes
---

While trying to fix a bug in the behaviour of the original patch, I thought 
about this some more, and decided that rather than patch over the top I should 
really fix the problem at it's root, so here's a revised version that separates 
the date offset calculations from the screen drawing position.

1) There's far fewer places that need to check for RTL
2) The code is simpler and cleaner
3) This also solves the bug where the hover highlight usually doesn't disappear 
when moving the mouse off the calendar, and where borders got confused (well 
almost, moving off the right edge doesn't remove the hover at first, but if you 
resize the widget it does start working, very mysterious).
4) It gets rid of the localeDateNum() stuff by using the KCalendarSystem string 
methods (changes made in kdelibs for this).
5) More clean-ups and some krazy fixes.


Summary
---

The CalendarTable widget does not correctly display in RTL mode, the cells in 
the table go LTR instead.  The numbers in the cells are controlled by code and 
not the widget layout, so we need to handle this the code.  

This patch fixes the day numbers, weekday names, and week numbers to go RTL, 
see screenshots for example.  It doesn't move the Week Numbers column from the 
left to the right as this is part of the SVG, we would need to flip the SVG 
along it's vertical axis to do so and shuffle everything about.  Is this 
possible or too much effort?  

Also rename a couple of variables for clarity seeing as I now understand what 
they do.

Patch against trunk, I'll backport to 4.3 if all OK.  Note we may want to 
rewrite some of the CalendarTable in 4.5 for a cleaner implementation.

cc to Dotan to confirm this looks OK and to confirm it's not a problem if we 
can't move the Week Number column.


This addresses bug 182976.
https://bugs.kde.org/show_bug.cgi?id=182976


Diffs (updated)
-

  trunk/KDE/kdebase/workspace/libs/plasmaclock/calendartable.cpp 1055882 

Diff: http://reviewboard.kde.org/r/2088/diff


Testing
---

Tested using 'plasmoidviewer --reverse calendar'


Screenshots
---

Left to Right mode
  http://reviewboard.kde.org/r/2088/s/253/
Right to Left mode
  http://reviewboard.kde.org/r/2088/s/254/


Thanks,

John

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Review Request: Digital Clock applet date formatting

[John Layt]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1877/
---

(Updated 2009-11-04 01:05:16.263057)


Review request for Plasma.


Changes
---

Fewer date format options, more time format options, fix some i18n mistakes, 
updated screenshots.

I wasn't entirely happy with the number of entries in the combo in the original 
change caused by having duplicates for both US and international formats 
listed.  To avoid this, I have now used just the en_US date formats, but made 
the format strings themselves translatable so each i18n team can decide what 
format is right for their language.  The down side is it now ties date 
formatting to language which is not always a good heuristic for locale, for 
example where someone is using es for language but US for locale so will get 
the wrong format.  Is this an acceptable compromise?

Having explanatory text before the example looks rather crowded and hard to 
pick out, should it just be the example date?

As an experiment and in response to bug 210613 I've tried the same config 
method on the Time Format as well, I'm happy to rip it out if it's not a useful 
addition.


Summary
---

As discussed on the plasma mailing list.  The Digital Clock applet has problems 
with l10n and i18n when formatting the date to be displayed, this change fixes 
these problems and simplifies the config while allowing more options.

The config GUI has changed from 3 tick-boxes to a single combobox of valid 
formats, which now includes the system locale formats.  Existing config files 
are automatically converted to the new config format.

Comment welcomed on available formats and wording in combobox


Diffs (updated)
-

  trunk/KDE/kdebase/workspace/plasma/generic/applets/digital-clock/clock.h 
1035179 
  trunk/KDE/kdebase/workspace/plasma/generic/applets/digital-clock/clock.cpp 
1035364 
  
trunk/KDE/kdebase/workspace/plasma/generic/applets/digital-clock/clockConfig.ui 
1035179 

Diff: http://reviewboard.kde.org/r/1877/diff


Testing
---

Tested conversion process for existing configs and new configs.  Tested 
selecting all available formats in gui.


Screenshots (updated)
---

Settings GUI
  http://reviewboard.kde.org/r/1877/s/249/
Time formats
  http://reviewboard.kde.org/r/1877/s/250/
Date formats
  http://reviewboard.kde.org/r/1877/s/251/


Thanks,

John

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: OT: Thanks!

[John Layt]

On Saturday 17 October 2009 01:42:33 Thomas Olsen wrote:
 And BTW:
 http://www.kde-look.org/content/show.php/Currency+Converter?content=113866
 
 Next one tomorrow :-)

Nice.  That reminds me I have a draft proposal to add full ISO Currency Code 
support into KLocale, that could save you (and several others) a lot of work 
around codes, localisation, translations, formats and rounding rules.  Must 
get that done before feature freeze :-)  If you have any input on what 
features you'd find useful, please let me know.

John.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Review Request: Digital Clock applet date formatting

[John Layt]

---
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1877/
---

Review request for Plasma.


Summary
---

As discussed on the plasma mailing list.  The Digital Clock applet has problems 
with l10n and i18n when formatting the date to be displayed, this change fixes 
these problems and simplifies the config while allowing more options.

The config GUI has changed from 3 tick-boxes to a single combobox of valid 
formats, which now includes the system locale formats.  Existing config files 
are automatically converted to the new config format.

Comment welcomed on available formats and wording in combobox


Diffs
-

  trunk/KDE/kdebase/workspace/plasma/generic/applets/digital-clock/clock.h 
1035179 
  trunk/KDE/kdebase/workspace/plasma/generic/applets/digital-clock/clock.cpp 
1035364 
  
trunk/KDE/kdebase/workspace/plasma/generic/applets/digital-clock/clockConfig.ui 
1035179 

Diff: http://reviewboard.kde.org/r/1877/diff


Testing
---

Tested conversion process for existing configs and new configs.  Tested 
selecting all available formats in gui.


Screenshots
---

Modified config gui
  http://reviewboard.kde.org/r/1877/s/230/
Date format combo
  http://reviewboard.kde.org/r/1877/s/231/


Thanks,

John

___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel