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

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: Request: better override functionality in locale settings

[John Layt]

On 28 August 2014 09:31, Harald Sitter  wrote:
> On Thu, Aug 28, 2014 at 3:49 AM, Matthew Ruffalo  wrote:
>> I still strongly, *strongly* disagree that it's acceptable for a user to
>> choose an appropriate locale for override settings.
>
> 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 installing&configuring 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  wrote:
> On Wed, Aug 27, 2014 at 11:34 AM, Sebastian Kügler  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]

On 28 August 2014 09:28, Martin Klapetek  wrote:
> On Wed, Aug 27, 2014 at 11:34 AM, Sebastian Kügler  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]

On 28 August 2014 09:31, Harald Sitter  wrote:
> On Thu, Aug 28, 2014 at 3:49 AM, Matthew Ruffalo  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 installing&configuring 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: Plasma 5 RC

[John Layt]

On 7 July 2014 10:16, Jonathan Riddell  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  wrote:
> On Fri, Jul 4, 2014 at 10:59 AM, Jonathan Riddell  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  wrote:
> On Fri, Jul 4, 2014 at 10:59 AM, Jonathan Riddell  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. ;)
> 
> 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 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 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 gette

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

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

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

Re: Locale settings in Plasma Next

[John Layt]

On 6 May 2014 22:35, Sebastian Kügler  wrote:

> Where can I find that KCM? I've looked into the old kde-runtime repo, and the
> new location in plasma-desktop, but no branches that look like the code is in
> there.

The new one is only in my private clone of kde-runtime at the moment,
I could push it to a branch there or plasma-desktop if you like.

> You can find it in plasma-desktop[sebas/locale], it's quite work-in-progressy.

I'll have a play with it.

> I've started on the Formats KCM, it's very rough (but conceptionally working,
> writing out export LC_ALL and sourcing that from startkde has the desired
> effect, now on to splitting the variables out and adding more UI for them.

Cool, except LC_ALL should never be set by the shell, it's a special
override for libraries to use when they need to ignore the users
locale.

Cheers!

John.
___
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  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: Compatibility problems with latest GTK+ applications

[John Layt]

On 8 May 2014 13:56, Sebastian Kügler  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  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: Locale settings in Plasma Next

[John Layt]

On 5 May 2014 15:44, Sebastian Kügler  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

Re: Plasma 5?

[John Layt]

On 5 May 2014 14:55, Sebastian Kügler  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

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) 
Date: 2 April 2014 17:00
Subject: Proposal: Location hackfest
To: John Layt , Aaron McCarthy <
aaron.mccar...@jollamobile.com>, Hanno Schlichting 
Cc: Bastien Nocera , 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  wrote:
> On Sun, Feb 23, 2014 at 8:10 PM, John Layt  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 

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=60543&picture=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  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  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]

> 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: 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: Keep the Things You Forgot

[John Layt]

On 24 October 2013 14:54, Mario Fux KDE ML  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  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.
&g

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  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: PIM Events via Plasma Clock/Calendar

[John Layt]

On 3 July 2012 09:26, Davide Bettio  wrote:
> Hello,
>
>
> Quoting Daniel Kreuter :
>>
>> 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 17:07, "Davide Bettio"  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: 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: How to access calendar using javascript?

[John Layt]

On 2 Jul 2012 08:08, "Aaron J. Seigo"  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: 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
> 
>  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

Re: the utter failure of bugzilla (and us?)

[John Layt]

On Monday 30 May 2011 09:41:21 Aaron J. Seigo wrote:
> also
> more of this kind of page would be very useful:
> 
> http://techbase.kde.org/Development/Tutorials/Debugging/How_to_create_usefu
> l_crash_reports
> 
> and they should be on community.kde.org where reporters are more likely to
> find them.

Good point.  I've created a new section 
http://techbase.kde.org/Contribute#Reporting_Bugs where I've linked to this, 
but eventually most of techbase.k.o/Contribute needs to go to community.k.o.

It should also be linked to from the userbase page at 
http://userbase.kde.org/Asking_Questions#Reporting_KDE_Bugs, although a more 
prominent link and a visual guide to Dr Konqi might also be an idea in 
userbase.

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

Re: Plasma clock bug/wish triage

[John Layt]

On Friday 27 May 2011 16:46:15 Aaron J. Seigo wrote:
> On Friday, May 27, 2011 16:28:02 John Layt wrote:
> > 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:

> > There are bugs for fuzzy clock and world clock that strictly are not part
> > of Plasma Clock, do we want to move them elsewhere?
> 
> world clock belongs with marble. fuzzy clock should have its own component
> in plasma.

Right all done, down to 33 bugs, with 4 of those going to fuzzyclock once the 
new component is created, and 10 more closed from General too.  I think I 
started with 60, so not a big dent but a start...
___
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 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: 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: 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


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



libs/plasmaclock/clockapplet.h


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


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



libs/plasmaclock/clockapplet.h


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


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



libs/plasmaclock/clockapplet.cpp


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



libs/plasmaclock/clockapplet.cpp


Coding style: put back the space before the opening brace



libs/plasmaclock/clockapplet.cpp


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



libs/plasmaclock/clockapplet.cpp


Coding style: braces belong with keywod



libs/plasmaclock/clockapplet.cpp


Style: put back the space before brace



libs/plasmaclock/clockapplet.cpp


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


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



libs/plasmaclock/clockapplet.cpp


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



libs/plasmaclock/clockapplet.cpp


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



plasma/generic/applets/analog-clock/clock.cpp


Why remove the line?



plasma/generic/applets/analog-clock/clock.cpp


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

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 "keyPressEvent"s 
> 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: 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  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 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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=revision&revision=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: 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: 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  wrote:
> > > Hi,
> > > 
> > > Quoting Jeffery MacEachern :
> > >> 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 2009-04-14 18:59:59, Aaron Seigo wrote:
> > other than a couple of code style comments, and that i can't test it with a 
> > gps for you either :/, my only question/concern is that it's doing look ups 
> > on the internet without checking to see if we're connected. it could be in 
> > a local cache, but i'm going to guess that in a fairly typical "i'm using 
> > gps" scenario one won't have an internet connection as well. should we 
> > query solid for network status?
> > 
> > rambling off-topic here: i also wonder if we aren't going to want some "can 
> > use the internet for ..." settings somewhere for the case where we have a 
> > system with gps, cheap wifi and expensive g3 connectivity .. somethings, 
> > like looking up the place name on the internet, may not be acceptible even 
> > if there is g3 service? not a use case we actually have to deal with now, 
> > but it's something that pops into my head every once in a while .. .. like 
> > when i see a patch like this :)
> 
> Petri Damstén wrote:
> Dataengine already checks network state but since it thinks gps does not 
> need one it uses gps plugin. I think location -> place should be a separate 
> plugin. It's not possible with current code though and I would like to 
> evaluate all the other possibilities before doing rewrite (there were some 
> wlan etc ideas as well). For 4.3 should it go like this, I'm not sure?
> 
> For 4.4 is geoclue out of the question? It seems that we are implementing 
> pretty much all the same things.
>
> 
> Beat Wolf wrote:
> any progress on this patch?
> 
> Beat Wolf wrote:
> can this patch be asumed dead?

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.


- John


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


On 2009-04-14 16:46:26, Andrew Coles wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/592/
> ---
> 
> (Updated 2009-04-14 16:46:26)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> Yesterday, I proposed a patch for using an IP geolocation service that 
> returns longitude and latitude, as the GPS backend would give that data but 
> the IP one would not.  Today, it's the other way around: a patch to add place 
> name and country information to the GPS geolocation data, as the IP 
> geolocation gives this but GPS geolocation does not.
> 
> The only caveat is that I'm programming blind - I don't have a GPS receiver, 
> and 'it compiles' is far from good enough.  Hence, I need a volunteer to test 
> it - anyone?
> 
> Assuming it works, the geolocation data engine will then have reached the 
> point where the fields returned are identical, /irregardless of whether IP or 
> GPS data is used/.  Specifically, the user gets:
> 
> - Latitude
> - Longitude
> - Accuracy
> - Country Name
> - Country Code
> - City Name
> 
> 
> Diffs
> -
> 
>   /trunk/kdereview/plasma/dataengines/geolocation/location_gps.h 954031 
>   /trunk/kdereview/plasma/dataengines/geolocation/location_gps.cpp 954031 
> 
> Diff: http://svn.reviewboard.kde.org/r/592/diff
> 
> 
> Testing
> ---
> 
> It compiles, and it looks alright.  How pitiful is that?  Given it's based on 
> the IP geolocation XML code, but using a reverse geocoding rather than IP 
> geolocation service, it should in theory work, but it really does need 
> testing by someone with a GPS unit.
> 
> 
> Thanks,
> 
> Andrew
> 
>

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

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

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

Re: [kde-promo] Plasma Calendar showing Akonadi Events in SC 4.5

[John Layt]

On Sunday 11 July 2010 10:32:22 Kevin Krammer wrote:
> The part of the migration where Akonadi gets access to the same files used
> by KResource applications should be enabled already (since 4.2 or 4.3
> IIRC). The disabled part if the creation of application side compatibility
> plugins.
> 
> E.g. KOrganizer writing into the default calendar file through KResources
> should be detected by Akonadi's Personal Calendar Resource.
> Probably not instantanious though.

On my openSuse machine with SC 4.5 and kdepim 4.4, my calendar events are not 
showing up in the plasmoid.  When I upgraded to kdepim 4.5 they did show up, 
but now I'm back at a clean kdepim 4.4 again they do not.  So the situation is 
definitely inconsistent depending on each individuals config and relative 
success of migration and the compatibility layer.

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

Re: Review Request: Improve display of week number in calendar applet

[John Layt]

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


You can test RTL by running "plasmoidviewer calendar -reverse".  Alternative 
calendars are even easier, just right-click to configure.  Anyway, they look 
OK.  I might tweak the 'most days' formula.  Thanks!

- John


On 2010-06-21 06:07:40, Alain Boyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/4419/
> ---
> 
> (Updated 2010-06-21 06:07:40)
> 
> 
> Review request for Plasma.
> 
> 
> Summary
> ---
> 
> This patch is a temporary workaround for bugs 238116 and 224344. I am calling 
> it temporary since it is my understanding that the drawing of the calendar 
> applet will be worked on and improved for 4.6. Is this correct?
> 
> Basically, only one week number is shown when there is not enough room to 
> display two week numbers in the calendar applet (two week numbers are 
> displayed when the first day of the week is not Monday). Instead of simply 
> displaying the first week number, an attempt is made to display the week 
> number that has the most amount of days in the calendar row.
> 
> 
> Diffs
> -
> 
>   /trunk/KDE/kdebase/workspace/libs/plasmaclock/calendartable.cpp 1140389 
> 
> Diff: http://reviewboard.kde.org/r/4419/diff
> 
> 
> Testing
> ---
> 
> Tested with Georgian calendar and seems to give correct behavior no matter 
> which day of the week is set as the first day of the week.
> 
> Needs testing with other calendars and RTL layouts.
> 
> 
> Thanks,
> 
> Alain
> 
>

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

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

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

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

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