Re: Ultracopier integration into dolphin and konqueror

2014-02-18 Thread KDEnhancer
Wow,

This seems like fun. I always wondered if there was a way to do this, but
for some reason never bothered asking this on the mailing list / forums
probably as I thought, it is not going to be of much interest to anyone or
people might feel insulted if I tell them that the native copy / paste on
KDE is too slow as compared to third party solutions out there.

I am a newbie to programming but really willing to contribute to open source
era. Eagerly waiting for someone's directions on how can this be
implemented.



--
View this message in context: 
http://kde.6490.n7.nabble.com/Ultracopier-integration-into-dolphin-and-konqueror-tp1268033p1560437.html
Sent from the kde-devel mailing list archive at Nabble.com.

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


Re: Geolocation module

2014-02-18 Thread John Layt
On 18 February 2014 23:28, Kevin Krammer  wrote:
> On Tuesday, 2014-02-18, 14:40:17, Mirko Boehm wrote:
>> at FOSDEM I met Zeeshan Ali who told me about his work on geolocation and
> that it would be cool if it were re-used across desktops. I don't know much
> about the topic, but his work looks cool to me. Here is what he wrote:

>> Is anybody involved in any kind of geolocation work and can get in touch
>> with Zeeshan about it?
>
> I am not involved in any geolocation work but if this is mainly about making
> geoclue2 available as a position provider for Qt applications then contacting
> the people working on QtLocation might be the way to go.
> It already seems to have a geoclue provider plugin, but that could be geoclue1
>
> https://qt.gitorious.org/qt/qtlocation/source/4c0599e2537a439f59ee91e1561c1c3ecf0b34e0:src/plugins/position/geoclue
>
> That is for Qt5, so it would take a while until it is used by KDE applications
> developers.

Yes for Qt5.2 onwards the new QtLocation module is the option I
recommend for general use in KDE Generation 5, as it is just the
location services api without the mapping api and so is now very
lightweight, i.e. doesn't pull in Qt3D when all you want to know is
what country you are in.  It currently only uses Geoclue 1, but the
maintainer is aware of Geoclue 2 and it is on his feature list to
implement support.  (I did ask for the data containers to be in QtCore
so we could pass data around without even needing QtLocation, but that
was opposed by the maintainer).

In Qt4 the QtMobility module was using Geoclue 1, but we didn't
recommend it's use in KDE due to the heavy dependency requirements and
possible data licensing issues.

Marble already uses Geoclue in KDE4, and I think there are other apps
using it directly.

Note that it is not recommended to use Geoclue directly in KDE apps as
it is platform dependent, we prefer to use an abstraction layer like
QtLocation that will work on all platforms, including OSX and Windows.

Cheers!

John.

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


Re: Review Request 115878: File: Add a thin wrapper around different xattr implementations.

2014-02-18 Thread Thomas Lübking

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



src/file/lib/baloo_xattr_p.h


I've to admit that i'm not sure how various compilers or the xattr headers 
will react to this, but you might want to try:

namespace BalooXattrInternal {
#if defined(Q_OS_LINUX)
#include 
...
#endif
}

namespace Baloo {

inline ssize_t getxattr(const char* path, const char* name, void* value, 
size_t size)
{
#if defined(Q_OS_LINUX)
return BalooXattrInternal::getxattr(path, name, value, size);

}

using namespace BalooXattrInternal;
using Baloo::getxattr;
using Baloo::setxattr;

---

getxattr & setxattr should then always be in scope and refer to the Baloo 
variants (ie. the wrappers)


- Thomas Lübking


On Feb. 18, 2014, 10:51 p.m., Raphael Kubo da Costa wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115878/
> ---
> 
> (Updated Feb. 18, 2014, 10:51 p.m.)
> 
> 
> Review request for Baloo and Vishesh Handa.
> 
> 
> Repository: baloo
> 
> 
> Description
> ---
> 
> File: Add a thin wrapper around different xattr implementations.
> 
> OS X, Linux and some BSDs all support extended file attributes in a way or
> another, but the API differs among the operating systems.
> 
> Introduce baloo_getxattr() and baloo_setxattr(), named after the OS X and
> Linux APIs for getting and setting extended attributes, to perform the right
> calls depending on the operating system.
> 
> These functions accept as parameters the arguments that are common across
> all xattr implementations -- this means one cannot pass custom |flags| on
> Linux or |options| on OS X, but that should be fine for now as the code was
> not doing that anyway.
> 
> 
> Diffs
> -
> 
>   src/file/lib/autotests/filefetchjobtest.cpp 
> a738c62a58d29ca092e53702d4852a48634d4315 
>   src/file/lib/autotests/filemodifyjobtest.cpp 
> 4ad1a6d2138d9754356a573eaf5f2487fcbe220f 
>   src/file/lib/baloo_xattr_p.h PRE-CREATION 
>   src/file/lib/filecustommetadata.cpp 
> 3a01520947a324dc1674f304e44eca1ae4a19ed7 
>   src/file/lib/xattrdetector.cpp e05984e611e8582d0e18d08f93b325381222d280 
> 
> Diff: https://git.reviewboard.kde.org/r/115878/diff/
> 
> 
> Testing
> ---
> 
> baloo finally builds on FreeBSD. filefetchjobtest and filemodifyjobtest fail 
> just like they do on Linux :-)
> 
> 
> Thanks,
> 
> Raphael Kubo da Costa
> 
>


>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


Review Request 115878: File: Add a thin wrapper around different xattr implementations.

2014-02-18 Thread Raphael Kubo da Costa

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

Review request for Baloo and Vishesh Handa.


Repository: baloo


Description
---

File: Add a thin wrapper around different xattr implementations.

OS X, Linux and some BSDs all support extended file attributes in a way or
another, but the API differs among the operating systems.

Introduce baloo_getxattr() and baloo_setxattr(), named after the OS X and
Linux APIs for getting and setting extended attributes, to perform the right
calls depending on the operating system.

These functions accept as parameters the arguments that are common across
all xattr implementations -- this means one cannot pass custom |flags| on
Linux or |options| on OS X, but that should be fine for now as the code was
not doing that anyway.


Diffs
-

  src/file/lib/autotests/filefetchjobtest.cpp 
a738c62a58d29ca092e53702d4852a48634d4315 
  src/file/lib/autotests/filemodifyjobtest.cpp 
4ad1a6d2138d9754356a573eaf5f2487fcbe220f 
  src/file/lib/baloo_xattr_p.h PRE-CREATION 
  src/file/lib/filecustommetadata.cpp 3a01520947a324dc1674f304e44eca1ae4a19ed7 
  src/file/lib/xattrdetector.cpp e05984e611e8582d0e18d08f93b325381222d280 

Diff: https://git.reviewboard.kde.org/r/115878/diff/


Testing
---

baloo finally builds on FreeBSD. filefetchjobtest and filemodifyjobtest fail 
just like they do on Linux :-)


Thanks,

Raphael Kubo da Costa


>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


Review Request 115877: cmake: Use more portable checks for xattr support.

2014-02-18 Thread Raphael Kubo da Costa

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

Review request for Baloo and Vishesh Handa.


Repository: baloo


Description
---

This is patch 1/2 of making the extended attributes support work on
non-Linux operating systems, and covers the build-system changes.

Replace the Linux-specific FindXAttr.cmake with a more standard
ConfigureChecks.cmake that looks for extended attributes-related headers in
multiple locations to account for multiple operating system implementations.


Diffs
-

  cmake/modules/FindXattr.cmake 530eb6ddba45149fe86e04ca6c5154471a2e0272 
  CMakeLists.txt d9be10f5b5f89205ab09a81ed0afc016238d5b7d 
  ConfigureChecks.cmake PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/115877/diff/


Testing
---

I stop getting fatal errors on FreeBSD due to the Linux xattr headers not being 
found.


Thanks,

Raphael Kubo da Costa


>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


Re: Geolocation module

2014-02-18 Thread Kevin Krammer
Hi,

On Tuesday, 2014-02-18, 14:40:17, Mirko Boehm wrote:
> Hello,
> 
> at FOSDEM I met Zeeshan Ali who told me about his work on geolocation and 
that it would be cool if it were re-used across desktops. I don’t know much 
about the topic, but his work looks cool to me. Here is what he wrote:
> > If you recall, I told you about geoclue and my
> > wish for other desktops (especially KDE) to use and perhaps also
> > contribute to and I promised to send you this email. Here are some
> > blog posts you might find interesting on the topic:
> > 
> > http://zee-nix.blogspot.com/2014/01/geoclue-211.html
> > http://zee-nix.blogspot.co.uk/2013/10/gnome-310-312-and-me.html
> > 
> > Could you please ask around in your community about this? Thanks in
> > advance for all the help!
> 
> Is anybody involved in any kind of geolocation work and can get in touch
> with Zeeshan about it?

I am not involved in any geolocation work but if this is mainly about making 
geoclue2 available as a position provider for Qt applications then contacting 
the people working on QtLocation might be the way to go.
It already seems to have a geoclue provider plugin, but that could be geoclue1

https://qt.gitorious.org/qt/qtlocation/source/4c0599e2537a439f59ee91e1561c1c3ecf0b34e0:src/plugins/position/geoclue

That is for Qt5, so it would take a while until it is used by KDE applications 
developers.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


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

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


Last chance ;-). And some more information.

2014-02-18 Thread Mario Fux KDE ML
As my questionnaire [1] is now open for two weeks I plan to give it another 24 
hours and then close it. So you’ve still time till tomorrow, Wednesday, 
February 19, 23.59 UTC to fill in the survey and participate in the draw.

If you should need more time or planned to fill in the questionnaire [1] after 
tomorrow night please ping me (unormal) on freenode.net or write me an email. 
And thank a lot to all the people who already filled it in: thank you!

And now a promise: this is the last time I write here to ask you to fill in 
this questionnaire [1]. Next time I write about this topic I’ll write about 
results. Although my diploma thesis will be in German I’ll write some 
summaries or blog posts about the results in English and probably will do even 
a presentation or two about it.

And here yet another teaser: tomorrow I’ll blog on planet kde about the dates 
and topics of the Randa Meetings in August 2014 ;-).

[1] http://survey.kde.org/index.php/249736/lang-en



>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


Geolocation module

2014-02-18 Thread Mirko Boehm
Hello, 

at FOSDEM I met Zeeshan Ali who told me about his work on geolocation and that 
it would be cool if it were re-used across desktops. I don’t know much about 
the topic, but his work looks cool to me. Here is what he wrote: 

> If you recall, I told you about geoclue and my
> wish for other desktops (especially KDE) to use and perhaps also
> contribute to and I promised to send you this email. Here are some
> blog posts you might find interesting on the topic:
> 
> http://zee-nix.blogspot.com/2014/01/geoclue-211.html
> http://zee-nix.blogspot.co.uk/2013/10/gnome-310-312-and-me.html
> 
> Could you please ask around in your community about this? Thanks in
> advance for all the help!
> 

Is anybody involved in any kind of geolocation work and can get in touch with 
Zeeshan about it?

Cheers, 

Mirko.
-- 
Mirko Boehm | mi...@kde.org | KDE e.V.
FSFE Fellow, FSFE Team Germany
Qt Certified Specialist and Trainer


>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


Re: Ultracopier integration into dolphin and konqueror

2014-02-18 Thread Sebastian Kügler
On Monday, February 17, 2014 20:36:09 therealbene wrote:
> Sorry I am a newbie and I might be resurrecting a dead thread.
> I'm a new Linux Mint (16) KDE user, and AFAIK there is no program that can
> match Ultracopier (in Windows) copying speed. 
> KDE's KIO is slower (copy-paste via dolphin).
> 
> I really hope that there is an option to intercept copy-paste file (like,
> "Make Ultracopier default file copy app", much like installing
> "Oxygen-transparent" just give an option to apply that theme instead of
> directly applying it upon make-install.
> 
> 
> David Faure-6 wrote
> 
> > Right, it's not meant to be intercepted.
> > I don't think people expect another app to pop up when they use copy/move
> > in dolphin or konqueror? Why not work on adding your features to KIO
> > itself?
> 
> I guess Windows are okay with their file-copy/move operations being
> intercepted by ultracopier/Teracopy. Users install it for that purpose: to
> get way faster copying.

Why would one not want way faster copying?

The question here is that nothing in KIO's is orthogonal to being fast, so if 
"fast" is the feature you want, the solution is not to make the current 
solution replaceable, but to fix its performance.

"Windows are OK with this" seems like a strawman though -- you can't fix it 
yourself in Windows, so the only way to achieve it is a drop-in replacement. 
This way of going about it is more often than not wrong in the Free software 
world, though.
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<