Re: PSA: KAccounts now requires two env vars set

[Weng Xuetian]

I just wonder whether it is some work for startkde or something to be
installed under /etc/xdg/plasma-workspace/env/ . If so maybe add a
file to kaccounts and install it under /etc/xdg/plasma-workspace/env/
then you won't need to bother packagers to figure out how to make it
work.

On Mon, Jan 18, 2016 at 12:06 PM, Martin Klapetek
 wrote:
> Because of a co-installability issue with other DEs [1]
> that use the accounts-sso tech, I had to change the location
> of the provider and service files we ship. This was decided
> after discussing with upstream.
>
> To make KAccounts/libaccounts actually read those from
> the new locations, two new env variables will be needed:
>
> AG_PROVIDERS=/path/to/providers
> AG_SERVICES=/path/to/services
>
> So please make sure you add them to your systems.
> Distro people - please make sure this is set in Plasma
> sessions (and ideally in Plasma sessions only).
>
> Your existing accounts should not be affected by this change.
>
> However you won't be able to add new or change accounts
> if you don't have these two env vars set. It's recommended
> to clean rebuild all things installing providers or services
> (currently known to me are ktp-accounts-kcm, kaccounts-providers
> and purpose iirc).
>
> This change will affect the Applications 16.04 release.
>
> [1] - https://bugs.kde.org/show_bug.cgi?id=347219
>
> Cheers
> --
> Martin Klapetek | KDE Developer

Re: 10000 lines change in kdeplasma-addons 4.14 branch

[Weng Xuetian]

Hi,
Sorry for all the trouble.

Sho on irc asked me that he want to test the ibus 1.5 support easier so I
get it merged for kde4. Unfortunately there's no further kdeplamsa-addons
for kde4 and I didn't finish this before 4.14, so it's also either leave it
broken in kde4 or add a usable version.

This change doesn't break old things but fix a never supported version for
ibus, and the old support is also kept in a different directory. So there
is no actual code deletion, and doesn't change the behavior for old version
of ibus 1.4.

The line number looks huge for following reason:
1. The ibus upstream changed quite a lot and made that ibus support must
parse a gtk key string. It's not possible to use gtk for just a keystring
parse so I was forced to copy some gdk key string parsing code here. In
this part of code there is a hardcoded key symbol to string table which is
unfortunately huge.
2. The old supporting code is also kept but moved, and new code is also
based on those code.

For i18n, there is no new string should be introduced.

In summary, this change doesn't break on old version, and introduce a fix
of supoort for new version which is never supported before.


On Thu, Oct 2, 2014 at 3:52 PM, Albert Astals Cid aa...@kde.org wrote:

 Hi Weng, I have been just told you just merged your
   origin/xuetianweng/kimpanel-ibus-1.5
 into
   KDE/4.14
 in the kdeplasma-addons repo

 That brings
   27 files changed, 10677 insertions(+), 1424 deletions(-)

 Has this been discussed anywhere? Because honestly this seems quite a big
 change for a stable branch.

 Cheers,
   Albert

Re: Adopting AppData in KDE?

[Weng Xuetian]

On Monday, November 04, 2013 08:58:22 PM Richard Hughes wrote:
 On 4 November 2013 20:56, Weng Xuetian wen...@gmail.com wrote:
  Some questions:
  1. What about non-application case?
 
 In GNOME we only consider an application to have a desktop file
 without NoDisplay=true. That's probably a desktop-level choice tho.
It's not about NoDisplay, plasmoids is a kind of widgets on KDE desktop, it 
also use desktop file to store metadata, though it's not sit in 
share/applications but some kde private folder. But each small widget is like 
an small application.

What I care is a app center doesn't only have application, it somehow should 
contains plugin to other application, for example, a browser plugin, a widget 
on desktop. And it makes sense if they don't have desktop file.

Can AppData handle such case?

 
  2. What if an application doesn't actually have an window, or a big enough
  window can be put in screenshot? Like a minimal media player stay in tray.
 
 I guess do the best you can and use the stock KDE fonts, wallpapers
 and that kind of thing wherever possible.
 
appdata-validate is preferable minimum size  is about 600px, I guess an 22px 
tray icon isn't visible enough on that.

Is it possible for an application not providing any screenshot?

Regards,
Xuetian

Re: Adopting AppData in KDE?

[Weng Xuetian]

Some questions:
1. What about non-application case?
KDE plasmoid, and some kcm worked as a plugin in system setttings, some of 
them also present a desktop, which doesn't theoratically an application, but I 
think should be able to install from app center.

2. What if an application doesn't actually have an window, or a big enough 
window can be put in screenshot? Like a minimal media player stay in tray.

On Saturday, November 02, 2013 09:27:18 AM John Layt wrote:
 Hi,
 
 I've been asked by Richard Hughes from Gnome and Fedora to raise the
 profile of using AppData metadata within KDE.  I know very little
 about this area myself, but thought it was worthwhile raising on the
 list for discussion.  If you have any questions about AppData then
 Richard would be happy to answer them, so please cc him on replies.
 
 The AppData justification, file format and tools are documented at
 [1].  AppData and AppStream are slowly being adopted by various
 distros for use in their software installers and app stores.  The
 AppData metadata file supplements the .desktop file by having a long
 description of an app, links to some screenshots, and the app home
 page, which get dispalyed in the app installer.  The description can
 also be localized.  While distro's could generate and maintain this
 data for themselves, to do so would be very time consuming for them,
 may not present the app in the best way possible, and would quickly
 get outdated.  It makes a lot of sense for apps to create and maintain
 this metadata for themselves, presenting themselves in the best way
 possible, which all the distros can then reuse in their installer
 applications.
 
 As far as I'm aware, AppData and/or AppStream is either used or
 scheduled to be used by default in Gnome Software Centre, Apper,
 Fedora, and OpenSuse, and optionally in several other distros, so is
 not a distro specific intiative.  I think there's even OBS integration
 happening.  If anyone knows more or thinks differently please let us
 know.
 
 Some recent developments make this a fairly high priority for apps
 that wish to target a cross-desktop audience.  The new Gnome Software
 Centre in Gnome 3.12 which uses AppData will become the default
 installer in Fedora 20 for Gnome (Fedora KDE will use Apper).
 Currently apps that don't provide AppData are ranked lower in search
 results in Gnome Software, but from Gnome 3.14 such apps will not be
 listed at all [2].  This means that without an AppData file KDE apps
 will eventually not be visible to Gnome users in their default app
 installer.  Currently Gnome has 50% of apps covered and is
 coordinating an effort for full coverage [3], but KDE has only 1%.
 
 Obviously individual apps are free to add these files [4], but from a
 KDE-wide perspective we need to discuss if we want to officially adopt
 this as a requirement, and if we want to provide a more coordinated
 and standardized solution.  What do people think?
 
 If we do adopt it, the two obvious issues to me are localization and
 screenshots.  Ideally scripty would be hooked up to generate the
 translation files, but as they are an XML format it may need a bit of
 work.  Scripty would also need the AppData file to be in a standard
 location in each repo.  The screenshots need to be hosted by the app
 (at least initially, Fedora copy the screenshots to their own server
 later to save load), so we may want to have somewhere common on the
 KDE infrastructure for that.  I'd also suggest defining a file naming
 standard including the app name and version number in the screenshot
 name.
 
 Taking a slight step-back, I wonder if there is a need for a more
 generic KDE metadata file in each KDE repo that describes even more
 useful info, like module, maintainer, reviewboard, bugzilla, last
 stable release number, frameworks tier, forums, irc channel, userbase,
 mailing list, etc, that AppData and projects.xml and inqlude and any
 other required metadata files could all be automatically generated
 from?
 
 One obvious question is how this might relate to Bodega if KDE chooses
 to switch to that?  What does Gnome shipping their own official App
 Store mean for cross-distro/cross-desktop app store efforts and do we
 need to start working on our own now, or will Bodega fill that need
 for us?
 
 Cheers!
 
 John.
 
 [1] http://people.freedesktop.org/~hughsient/appdata/
 [2] http://blogs.gnome.org/hughsie/
 [3] https://wiki.gnome.org/GnomeGoals/AppDataGnomeSoftware
 [4] https://git.reviewboard.kde.org/r/113531/

Re: Fwd: looking for phonon gstreamer maintainer

[Weng Xuetian]

Another question, gstreamer is not parallel linkable, and ktp-call-ui is
currently using QtGstreamer (which also seems unmaintained for quite some
time) and it's using gstreamer 0.10.

So if phonon-gstreamer is ported to gstreamer then QtGstreamer also must be
ported to 1.0 (Though phonon-gstreamer and QtGstreamer doesn't use each
other but they could end up in same application which will cause some
problem..).

Would it be easier to make phonon-gstreamer to use QtGstreamer and hence
also make someone to maintain QtGstreamer?


On Wed, Sep 25, 2013 at 5:08 PM, Harald Sitter sit...@kde.org wrote:

 On Wed, Sep 25, 2013 at 9:53 PM, Aaron J. Seigo ase...@kde.org wrote:
  thanks for the swift and excellent response! muchly appreciated ...
 
  On Wednesday, September 25, 2013 15:00:43 Harald Sitter wrote:
  d) at some point port to phonon5
 
  would it at all make sense to see if we can resuscitate this backend by
 just
  going straight to (d)? does it make sense to port the existing code, or
 would
  a start from scratch make sense?

 Starting from scratch is certainly a viable option. Going straight to
 d would not solve the problem for Phonon4, or Qt4 for that matter as
 Phonon5 is supposed to be exclusively Qt5. However from a backend POV
 there is not going to be a whole lot difference between the two
 versions as Phonon5's key element is getting rid of pointless API
 dynamics and through that simplifying the frontend API (like not
 having a mediagraph where in theory one could order nodes in any order
 and something reasonable should come out at the end). The heavy
 lifting code of setting a source, building a pipeline and making it
 create output should be largely the same.

 I personally would go for a rewrite but at the same time I am also
 very confident that starting from the existing code base would yield
 success. Torrie Fischer already rewrote a lot of the pipeline building
 and control logic a while ago, so it is most certainly not as bad as
 it used to be. At the very least there is stuff that can be salvaged
 for a possible rewrite.

  given all the downsides to not having a *good* gstreamer 1.0 backend in
 your
  report, this seems like a pretty important item. particularly for those
 of us
  looking to bring software to mobile devices where having multiple media
  middleware is not an awesome solution.

 There definitely are solid reasons for having a GStreamer backend,
 otherwise it would have gotten the boot like all the other broken
 backends years ago. While I had not originally thought of mobile
 devices, it certainly has even greater importance there. Regardless of
 the device though it would be a shame to loose the backend, so I
 really hope someone who enjoys HD videos steps up and volunteers to
 make software to play them (better) :)

 HS

Re: Input method integration for KDE 4.11

[Weng Xuetian]

On Saturday 26 January 2013 13:03:29，Todd :
 On Sat, Jan 26, 2013 at 3:41 AM, Andriy Rysin ary...@gmail.com wrote:
  On 01/15/2013 03:11 PM, Weng Xuetian wrote:
  Hi,
  Under linux, input method is always being a mess:
  1. Start it correctly
  ubuntu, debian: im-switch, im-config
  fedora: imsettings
  opensuse: their own script and I don't really know package name about it.
 
  im-switch and im-config have bug so long time, and all of them are distro
  specific.
 
  2. Relation betwen keyboard layout and input method
  Agree it or not, keyboard layout is only a kinds of special input method,
  and
  it should live with input method,
 
  Now, more and more input method are taking care of keyboard layout (which
  means it would just conflict with kde's own keyboard layout settings),
  but
  it's the correct way to go:
  Here comes my beloved usecase :D
  User is using a Chinese input method, which expect it to be something
  similar
  with qwerty, but if you're using a de layout, it will type some non-sense
  character.
 
  And idea is, input method have layout on its own, and should be take care
  by
  input method itself (if they can).
 
  So, leaving user with keyboard layout settings provided by kde if input
  method
  can already handle it doesn't make any sense.
 
  Under upper idea, I wrote some code, now it's only complete the idea 1.
  https://github.com/csslayer/**kde-input-methodhttps://github.com/csslaye
  r/kde-input-method
 
  Currently it only have fcitx's profile for test (since I'm selffish fcitx
  dev), but it's trivial to add others (gcin, hime, ibus, maliit).
 
  It provides distro independent start up and environment handling (by
  global
  kde env script), input method process starting and monitoring (by kded).
 
  BTW kded part can be also adopted by plasma-active.
 
  Configure button in kcm is not implemented yet.
 
  Currently it has its own kcm, which I want to have it sit in
  kcm-component-
  chooser. And for backward compatibilty, it can be switch to none and in
  that
  way nothing will be affected.
 
  And I need input from kcm-keyboard maintainer (already in CC) and non-CJK
  people. I'm not sure about which list should be CC to, so I only send to
  kde-
  devel for now.
 
  Regards,
  Xuetian
 
  Hi
 
  I am a current (even if somewhat recently passive :)) KDE keyboard module
  maintainer and I promised Weng to reply so here it goes.
 
  1. I've never used IM and have pretty vague understanding how it works so
  I am open for discussion
  2. I don't plan to use IM (current keyboard layout implementation in KDE
  is good enough for me), but I don't mind to take a look at it if it's
  implemented as an additional feature and I can play with it temporarily to
  see if it bring something cool for users like me
  3. There's probably tons of users that like me are ok (more or less -
  there's still open bugs) with current keyboard layout support in KDE and
  we
  *cannot* break things for them, especially not in 4.x branch (although I
  suspect people would prefer things they use not being broken in 5.x as
  well
 
  :))
 
  4. There's tons of features requests implemented and bugs fixed in KDE
  keyboard module for last 10 years, this is the baggage I would not just
  trash
  5. I have story of GNOME keyboard module maintainer leaving after dozen of
  years of development because keyboard layouts management code in GNOME was
  superseded by IM module
  6. I have also stories that GNOME keyboard layouts got pretty much
  unusable for many users after this switch (unless you do the trick to
  activate old code)
  7. Now having said that I also agree that many people need IM and also
  that keyboard layout module and IM are trying to do pretty much the same
  thing (at high level that is), so making them work together (or at least
  show up together for the user in UI) would be the right way to go;
  actually
  there's pretty old feature request (
  https://bugs.kde.org/show_bug.cgi?id9845) to do exactly that
  8. With 1-7 in mind I would say I am in favor of adding IM module to KDE,
 
  as long as:
  a) it does not override, remove, or hide existing keyboard layout
 
  module
 
  b) it is off by default (like keyboard layout module itself)
  c) it makes sense that if IM is turned on, keyboard layout
 
  configuration (or to be exact some part of it) will be disabled (as it's
  functionality is taken over by IM)
 
  d) as user needs to see which module (IM or keyboard layout) is
 
  active, the IM control UI should reside in the same UI as keyboard layout
  (I would suggest another tab), thus when user enables IM he can easily see
  which parts of keyboard module is taken over by IM and which he still can
  (or should) change
 
  e) there's still some functionality from the old module that will be
 
  useful even if IM is active (i.e. xkb options to define keys behavior) -
  we
  need to analyze which parts are taken over by IM activation and which ones

Re: plasma and new shadow mess

[Weng Xuetian]

On Sun, Jan 6, 2013 at 10:37 AM, Aaron J. Seigo ase...@kde.org wrote:

 On Sunday, January 6, 2013 13:35:16 Martin Graesslin wrote:

 btw, these changes were made in mid-November of 2012. i'm a little
 surprised
 people are only noticing now.


I'm sure this change is not included the first beta, people might see
things goes alright and then we have Christmas which worse the case.

I'm working on some of fix.. those changes go into 4.10 or 4.11 I don't
really care.. but I don't want have visual regression for 4.10.
[1] https://git.reviewboard.kde.org/r/108222/
[2] https://git.reviewboard.kde.org/r/108223/

If code is not reverted, we may discuss the solution?

As for kwin tabbox shadow, though I'm not expert for kwin, there is two
problem
1. how to do the shadow for tabbox? use X property or some kwin custom way
because it's in kwin.
Well.. I guess later way it not easy and will duplicate the shadow drawing
code path, so I still propose to use X property for passing shadow.

2. who provide the shadow, qml or the current declarativeview?
I think qml is much more easy, since the Svg object in qml is the
Plasma::Svg. If qml tabbox want to use shadow, it can pass the property to
rootObject and let declarativeview easily get and render it.

Re: Kded and DBus

[Weng Xuetian]

On Thursday 03 January 2013 19:32:27，Cédric Bellegarde :
 Le jeudi 3 janvier 2013 18:09:25 David Edmundson a écrit :
  Always use async calls for everything

 On kded-appmenu part, the blocking code isn't in kded-module but in
 appmenu-qt plugin used to export the menu over dbus:

 http://bazaar.launchpad.net/~indicator-applet-developers/appmenu-
 qt/trunk/view/head:/src/appmenuplatformmenubar.cpp#L406

 QDBusInterface host(REGISTRAR_SERVICE, REGISTRAR_PATH, REGISTRAR_IFACE) call
 dbus_connection_send_with_reply_and_block () to do the dbus introspection.

 If someone know how to bypass this issue...

 regards,

Why appmenu-qt doesn't use static dbus interface (generate from XML)? From Qt
code that can avoid synchronous introspection.

signature.asc
Description: This is a digitally signed message part.

plasma and new shadow mess

[Weng Xuetian]

Hi Plasma world,
As new shadow lands in KDE 4.10 RC1, some unintentional mess is introduced.

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

And it affects some more components, at least including kmix osd,
brightness osd, icontasks.

The problem is, custom widget using plasma svg doesn't get new shadow
support automatically, some code must be written.

I observe that some components get necessary modifications, for example
krunner, while also quite a few of them still not.

What make this problem worse is, the necessary class for shadow is not
public. And AFAIK there are already 3 copies of same code across different
kde projects (kdelibs/plasma/private/dialogshadows ,
kde-workspace/libs/plasmagenericshell/panelshadows, and one of my own in
kdeplasma-addons), plasmagenericshell is a shared library but it doesn't
install header..

I think some action need to be taken before the release, some possible
solutions.
1. Revert the changes of new plasma air theme, so old shadow can be used.
and try to fix all the things in KDE 4.11
or 2. get some header exposed to avoid duplication of the code, and fixed
every custom widget, at least including: kwin, kmix, powerdevil, icontasks.

I can give out my help for fix those, but some decision still need to be
made (add new header to kdelibs or kde-workspace).

Regards

Re: merging development branch into master

[Weng Xuetian]

On Sun, Nov 4, 2012 at 5:27 PM, Andriy Rysin ary...@gmail.com wrote:

 On 11/04/2012 01:18 AM, Shaun Reich wrote:

 well, you've got until november 8th (4 days according to my clock) until
 hard feature freeze which blocks even those on the planned feature list.

 so, as my procrastinating self would say you've got plenty of time ;)

 done: 
 https://git.reviewboard.kde.**org/r/107202/https://git.reviewboard.kde.org/r/107202/
 I could not find kde-workspace or systemsettings groups so I've added it
 to kde-runtime

 I would appreciate any feedback,
 Thanks,
 Andriy

 P.S. I rebased the feature branch locally so we'll be able to FF (or just
 apply the patch)


Hi all,

sorry for interrupt the thread, but I have some code that ported from
libgnomekbd (port to Qt), used in my own project, idea is similar, but
provides more feature though.

https://github.com/fcitx/kcm-fcitx/blob/master/layout/keyboardlayoutwidget.cpp

It's layout is based on parsing xkb model file, not hard code, and key
press can be displayed on the preview.
It's quite standalone, I'm not sure if you guys want to take a look at it.

Fwd: import kde-thumbnail-po into kdesdk

[Weng Xuetian]

Hi,
My friend ask me to forward this mail since maillist seems to think
his mail is spam.


-- Forwarded message --
From: nihui shuizhuyuan...@126.com
Date: 2012/4/20
Subject: import kde-thumbnail-po into kdesdk
To: kde-core-devel kde-core-devel@kde.org


 hi all

I think it is the time to import kde-thumbnailer-po[1] into kdesdk.
There was a same plugin in the old kde3 days, but got removed with
kbabel altogether.
this plugin depends on gettext-po library

Though I have already implemented lots of kde thumbnailer plugins and
made some releases on kde-apps.org, this po plugin is the most popular
and got high voting. I think it should be quite useful for many users,
especially the translators using KDE.

[1]http://kde-apps.org/content/show.php/KDE+PO+Thumbnailer?content=142036

regards,
nihui

Re: Review Request: include KolorManager in kdegraphics

[Weng Xuetian]

On Thu, Mar 15, 2012 at 12:46 AM, Thomas Zander zan...@kde.org wrote:
 On Wednesday 14 March 2012 16.39.00 Boudewijn Rempt wrote:
  Hi!
  Colord - just to mention that - is also not a GNOME project, it's a
  FreeDesktop project. (Doesn't mean it's standard, but does mean that
  it's not GNOME)

 Well, no, having something on freedesktop.org doesn't mean it's not a
 gnome project;

 Little semantic confusion here :)
 He said it *IS*  a freedesktop project.  Which means it is not a gnome
 project, which seems to me to be true.

 it is a gnome project, and it's widening its scope. The
 reason it's used at all is that is is used inside gnome.

 Projects should be judged on merit, irregardless of who pushes it.
 If gnome is using it and that makes it grow acceptance, thats a good thing in
 my book.  Why; *because* acceptance is growing. I don't care if its gnome or
 any other player pushing it.

 That said; Cups also depends on colord. And IMO that has a bigger impact than
 the gnome components that pull it in.

No, colord guys push CUPS to add API that they need, I thought that's
why CUPS depends on colord.

http://libregraphicsworld.org/blog/entry/richard-hughes-on-color-management-in-linux-and-gnome

Which oyranos don't like to, to be more concrete, use existing
protocol / interface.

No offense on both side. Just for more information.