Re: [Kde-pim] Contact Aggregation [was: KDE Telepathy on its way to Extragear]

[Georg C. F. Greve]

On Thursday 05 January 2012 13.25:53 Daniele E. Domenichelli wrote:
> In this way we can still query nepomuk database like if we write data there
> directly, but we will handle aggregation using a library whose only aim is
> to aggregate contacts.

FWIW, a dedicated library -- if feasible -- would be my preferred option, as 
well, since that would be usable in places where Nepomuk might not be easily 
deployed, e.g. advanced Akonadi scenarios on servers & other devices.

I also agree the results of this should then be fully usable by Nepomuk to 
gain all the advantages that has.

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: gr...@kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve

Re: Contact Aggregation [was: KDE Telepathy on its way to Extragear]

[Martin Klapetek]

2012/1/5 Venky 

> Wasn't using folks for contact aggregation suggested few months by Paolo 
> Capriotti? If I remember the idea was
>
>
> dismissed (I am not able to find the discussion between him and G Goldberg), 
> but there were few who were receptive. I think the guy also made a scratch 
> repo.
>
>
Yes, it was Paolo who created it with using QtContacts as frontend. We
discussed QtContacts on Desktop Summit in Berlin and concluded it
was...well, not good. Nevertheless we later attended the libfolks talk and
it is pretty much the same as Nepomuk's PIMO:Person, except that Nepomuk is
a broader and general platform while folks concentrate solely on contacts.
And given the effort to integrate Nepomuk more deeply into KDE Workspace,
we simply chose to go with Nepomuk.


> It will be great to use a framework which works for both KDE and GNOME and it 
> seems folks is deeply integrated into GNOME
>
>
And KDE has deeply integrated Nepomuk, which already has contact
aggregation features. I'm not really keen on the idea of having two such
services at once, pretty much duplicating their work.

--
Martin Klapetek | KDE Developer

Re: Review Request: Fix FindXine.cmake to use pkg-config instead of xine-config

[Johannes Huber]

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

(Updated Jan. 6, 2012, 1:06 p.m.)


Review request for kdelibs.


Changes
---

Parse version number from defines out of xine.h.


Description
---

This is a gentoo downstream patch, see bug 
https://bugs.gentoo.org/show_bug.cgi?id=397595 for cause.


Diffs (updated)
-

  cmake/modules/FindXine.cmake 37c58c6 

Diff: http://git.reviewboard.kde.org/r/103631/diff/diff


Testing
---


Thanks,

Johannes Huber

Re: Review Request: Port shutdown dialog to QML

[Alexander Neundorf]

On Friday 06 January 2012, Lamarque V. Souza wrote:
> Em Thursday 05 January 2012, Alexander Neundorf escreveu:
> > On Thursday 05 January 2012, Lamarque V. Souza wrote:
> > > Em Wednesday 04 January 2012, Alexander Neundorf escreveu:
> > > > On Wednesday 04 January 2012, Lamarque Vieira Souza wrote:
> > > > > > On Jan. 3, 2012, 9:38 p.m., Albert Astals Cid wrote:
> > > > > > > ksmserver/CMakeLists.txt, line 57
> > > > > > >  > > > > > > e4 53 63 li ne57>
> > > > > > > 
> > > > > > > no variable for kdeclarative?
> > > > > > 
> > > > > > Lamarque Vieira Souza wrote:
> > > > > > There is one in shutdowndlg.cpp, in KSMShutdownDlg's
> > > > > > constructor.
> > > > > > 
> > > > > > Albert Astals Cid wrote:
> > > > > > I mean cmake variable like ${SOMETHING_SOMETHING}
> > > > > 
> > > > > I do not think so. All CMakeLists.txt throughout kde-workspace,
> > > > > kde-runtime and plasma-mobile add the library name directly.
> > > > 
> > > > libkdeclarative is from kdelibs/experimental/, right ?
> > >   
> > >   Yes.
> > >   
> > > > So, it is not from within the same project.
> > > > And I didn't find a place where libkdeclarative would install a
> > > > KDeclarativeConfig.cmake file. Did I miss this somewhere ?
> > > > 
> > > > If not, is there a FindKDeclarative.cmake somewhere ?
> > > > 
> > > > If not, this is seriously messed up.
> > > > 
> > > > It would mean that simply using "kdeclarative" means that cmake
> > > > interprets this as name of a library and simply adds -lkdeclarative
> > > > to the command line, without checking whether it actually exists nor
> > > > in which directory.
> > >   
> > >   I guest that is indeed what happens now.
> > >   
> > > > So, is there a FindKDeclarative.cmake or a KDeclarativeConfig.cmake
> > > > file somewhere ?
> > >   
> > >   locate /*Declarative*.cmake returned nothing here, so there is none 
in
> > > 
> > > my notebook.
> > 
> > So, quick solution: write a simply FindKDeclarative.cmake file (mostly
> > find_library(), find_path() and a find_package_handle_standard_args()
> > call) and use this (but don't install it).
> > 
> > Good solution: kdeclarative should install a KDeclarativeConfig.cmake
> > file, so it will be found automatically. But this has to be done
> > carefully.
> 
>   I think the person to talk about this is Marco Martin. 

Still, if you are a user of kdeclarative, you have an interest in having a 
FindKDeclarative.cmake file.
Have a look at some of the simpler find-files, e.g. FindJPEG.cmake coming with 
cmake, and write a FindKDeclarative.cmake file similar to it.
This won't take you long.

> As far as I know
> he is the one doing most of the work in kdeclarative. Kdeclarative is going
> to be very important in Plasma 4.8, I think we should fix this properly
> before the 4.8 final release.

Yes.

Alex

Re: ktouchpadenabler moved to kdereview

[Albert Astals Cid]

El Divendres, 6 de gener de 2012, a les 01:09:40, Albert Astals Cid va 
escriure:
> El Dijous, 5 de gener de 2012, a les 21:59:10, Lamarque V. Souza va 
escriure:
> > Em Thursday 05 January 2012, Albert Astals Cid escreveu:
> > > El Dijous, 5 de gener de 2012, a les 21:35:18, Lamarque V. Souza va
> > 
> > escriure:
> > > > Em Thursday 05 January 2012, Albert Astals Cid escreveu:
> > > > > El Dimecres, 4 de gener de 2012, a les 21:55:36, Lamarque V.
> > > > > Souza va
> > > > > 
> > > > > escriure:
> > > > > > Em Wednesday 04 January 2012, Albert Astals Cid escreveu:
> > > > > > > El Dimecres, 4 de gener de 2012, a les 23:40:26,
> > > > > > > David
> > > > > > > Faure va
> > > > 
> > > > escriure:
> > > > > > > > On Wednesday 04 January 2012 18:51:44 Albert Astals Cid wrote:
> > > > > > > > > El Dimecres, 4 de gener de 2012, a les
> > > > > > > > > 01:53:13,
> > > > > > > > > Christoph Feck
> > > > > > > > > va
> > > > > > > 
> > > > > > > escriure:
> > > > > > > > > > On Wednesday 04 January 2012 00:28:11
> > > > > > > > > > Albert Astals Cid
> 
> wrote:
> > > > > > > > > > > My little kded daemon that listens
> > > > > > > > > > > to
> > > > > > > > > > > XF86XK_TouchpadToggle and
> > > > > > > > > > > enables disables the touchpad
> > > > > > > > > > > accordingly has
> > > > > > > > > > > been moved
> > > > > > > > > > > to
> > > > > > > > > > > kdereview.
> > > > > > > > > > > 
> > > > > > > > > > > My plan is moving it to extragear,
> > > > > > > > > > > not
> > > > > > > > > > > really
> > > > > > > > > > > sure if
> > > > > > > > > > > -base or
> > > > > > > > > > > -utils.
> > > > > > > > > > > 
> > > > > > > > > > > The code doesn't have a kcm or any
> > > > > > > > > > > kind
> > > > > > > > > > > of
> > > > > > > > > > > configuration
> > > > > > > > > > > since
> > > > > > > > > > > it
> > > > > > > > > > > is designed to "just work".
> > > > > > > > > > > 
> > > > > > > > > > > I'd appreciate any review or
> > > > > > > > > > > suggestion
> > > > > > > > > > > over it.
> > > > > > > > > > 
> > > > > > > > > > I cannot test it because I have no
> > > > > > > > > > touchpad,
> > > > > > > > > > but if
> > > > > > > > > > it is
> > > > > > > > > > supposed
> > > > > > > > > > to
> > > > > > > > > > "just work" without any UI, I suggest to
> > > > > > > > > > just add it
> > > > > > > > > > to
> > > > > > > > > > "khotkeys"
> > > > > > > > > > or
> > > > > > > > > > "kaccel" daemon (whichever of them is
> > > > > > > > > > used
> > > > > > > > > > for
> > > > > > > > > > global
> > > > > > > > > > shortcuts), so that we do not filter
> > > > > > > > > > global
> > > > > > > > > > X11
> > > > > > > > > > keyboard
> > > > > > > > > > events twice.
> > > > > > > > > 
> > > > > > > > > I don't really see any point in doing that,
> > > > > > > > > nothing can
> > > > > > > > > be
> > > > > > > > > shared
> > > > > > > > > between
> > > > > > > > > them and the existing ktouchpadenabler so
> > > > > > > > > instead of one
> > > > > > > > > simple
> > > > > > > > > codebase (166 lines with 20 of headers) you
> > > > > > > > > end
> > > > > > > > > up
> > > > > > > > > adding more
> > > > > > > > > complexity to existing programs (probably
> > > > > > > > > integrating
> > > > > > > > > the code
> > > > > > > > > in the
> > > > > > > > > existing programs
> > > > > > > > > would be more than 166 lines).
> > > > > > > > 
> > > > > > > > IMHO this isn't about the number of lines of
> > > > > > > > code,
> > > > > > > > but about
> > > > > > > > the
> > > > > > > > runtime performance (how many process to wake up
> > > > > > > > when
> > > > > > > > pressing a
> > > > > > > > key).>
> > > > > > > 
> > > > > > > khotkeys is already a kded module, so there won't be
> > > > > > > no
> > > > > > > more
> > > > > > > processes waking up now than before by adding a new
> > > > > > > kded
> > > > > > > module.
> > > > > > > 
> > > > > > > > kglobalaccel seems quite suitable indeed, no?
> > > > > > > 
> > > > > > > It would, if Qt had a key for XF86XK_TouchpadToggle,
> > > > > > > as
> > > > > > > it
> > > > > > > doesn't i'd need to introduce a big "ignore all the
> > > > > > > workflow of
> > > > > > > kglobalaccel for this special key" since
> > > > > > > kglobalaccel
> > > > > > > only
> > > > > > > understands Qt keys (see KGlobalAccelImpl::grabKey).
> > > > > > 
> > > > > > In your blog
> > > > > > (http://tsdgeos.blogspot.com/2011/12/sad-story-of-day-
> > > > > > qt-
> > > > > > 
> > > > > > and.html) you said your patch against Qt was accepted. I
> > > > > > thought
> > > > > > your
> > > > > > patch would add XF86XK_TouchpadToggle support to Qt and
> > > > > > then
> > > > > > there
> > > > > > would be no need for this kded module. If we patch Qt we
> > > > > > could add
> > > > > > the support for a key as one #define and one enumerate
> > > > > > per
> > > > > > key in
> > > > > > kdelibs/kdeui/util/kkeyserver_x11.cpp with no runtime
> > > > > > overhead. I
> > > > > > also
> > > > > > cr

Re: [Kde-pim] Contact Aggregation [was: KDE Telepathy on its way to Extragear]

[Daniele E. Domenichelli]

On 06/01/12 12:40, Martin Klapetek wrote:

Nevertheless we later attended the libfolks talk and
it is pretty much the same as Nepomuk's PIMO:Person, except that Nepomuk is
a broader and general platform while folks concentrate solely on contacts.
And given the effort to integrate Nepomuk more deeply into KDE Workspace,
we simply chose to go with Nepomuk.



It is not exactly the same as PIMO:Person, you are confusing a 
representation of something with a class + algorithms to handle 
something. You might compare want to compare Folks to the library that 
George Goldberg was writing, but we have being waiting for this library 
for a lot of time now, and afaik the library is in a bad shape at the 
moment, George was planning to make a lot of changes to the library but 
he is currently inactive. Moreover you told me that we miss some major 
feature in nepomuk (watching for property changes) so that will delay 
even more the availability of the library.


I am not suggesting not to use Nepomuk, I am suggesting not to use it 
for _creating_ new information but just to _extract_ information created 
somewhere else (i.e. by folks)



Daniele

Re: Review Request: Fix FindXine.cmake to use pkg-config instead of xine-config

[Alexander Neundorf]

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


We're getting there :-)
...but not yet completely.

You actually don't have to compare the version number yourself, 
find_package_handle_standard_args() does that for you. It is enough to get a 
variable which contains the complete version string.
So at least the lines where XINE_VERSION_OK is set to TRUE can be removed.

While at it, please also do the following things:
- setting Xine_FIND_QUIETLY to TRUE is not necessary, please remove this if() 
completely (find_package_handle_standard_args() is quiet by itself if the 
output has not changed from the previous run)
- remove the if(WIN32) around the pkgconfig-stuff. People say it should work 
also on Windows. So let's see.
- is the check_c_source_compiles() stuff actually necessary ? Can it simply be 
removed ? I'd say so.

- Alexander Neundorf


On Jan. 6, 2012, 1:06 p.m., Johannes Huber wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103631/
> ---
> 
> (Updated Jan. 6, 2012, 1:06 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Description
> ---
> 
> This is a gentoo downstream patch, see bug 
> https://bugs.gentoo.org/show_bug.cgi?id=397595 for cause.
> 
> 
> Diffs
> -
> 
>   cmake/modules/FindXine.cmake 37c58c6 
> 
> Diff: http://git.reviewboard.kde.org/r/103631/diff/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Johannes Huber
> 
>

Re: Review Request: Fix FindXine.cmake to use pkg-config instead of xine-config

[Rolf Eike Beer]

> - remove the if(WIN32)
> around the pkgconfig-stuff. People say it should work also on Windows. So
> let's see.

But add an if() to check if pkg-config is actually found?

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

Re: Review Request: Fix FindXine.cmake to use pkg-config instead of xine-config

[Alexander Neundorf]

On Friday 06 January 2012, Rolf Eike Beer wrote:
> > - remove the if(WIN32)
> > around the pkgconfig-stuff. People say it should work also on Windows. So
> > let's see.
> 
> But add an if() to check if pkg-config is actually found?

If it's not found, the call to the macro simply does not set any variables, so 
no problem.

Alex

Review Request: Make KFileWidget provide default filename even when the protocol doesn't support listing

[Dawit Alemayehu]

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

Review request for kdelibs and David Faure.


Description
---

This patch changes the logic KFileWidget::getStartUrl so that a default file 
name is provided for protocols that do not support listing, e.g. http. This 
should address the problem reported in bug# 169348 at a central location 
instead of leaving it up to each application to do the right thing. 


This addresses bug 169348.
http://bugs.kde.org/show_bug.cgi?id=169348


Diffs
-

  kfile/kfilewidget.cpp 960d6c4 

Diff: http://git.reviewboard.kde.org/r/103642/diff/diff


Testing
---


Thanks,

Dawit Alemayehu