Re: Integration of ultracopier

[alpha_one_x86 <alpha_one_x86 first-world info>]

Hello,

Thanks for your advised reply. I have do the windows and KDE
implementation, then the implementation can be resumed by:
if(file.isLocal() && catchcopy.isConnected())
{
   catchcopy.copy(sources,destination);
   return; //to ignore the copy because it will be done as external
}
Splitting the file operation is few hard and slow. Just implement this
kind of code is easy, transparent, and allow external application to
be used. Not always have advanced copier running, then the copy should
be with the default copy dialog when have not application to overwrite
it. It's why externalization is not a solution, because the default
code should be acceded.

Can you add a entry into the wish list and give me the url?

Thanks, cheer,

On Wed, Jul 4, 2012 at 2:02 AM, Cosimo Cecchi <cosimoc gnome org> wrote:
> On Sun, 2012-07-01 at 19:01 +0200, alpha_one_x86 wrote:
>> Hello,
>>
>> I have do unix socket listener + api or dbus listener. And KDE patch
>> for example of integration of ultracopier into KDE. The catchcopy is
>> the standard of communication: file manager <-> software to do a copy.
>> Some user (included me) wish integration with nautilus for local file.
>> That's mean, copy/paste not use the default dialog but send the
>> source/destination to ultracopier to do it.
>
> Hi, it's not possible at the moment for an external application to
> replace the built-in file operations dialog, not even by using
> extensions, and implementing such kind of support unfortunately wouldn't
> be an easy task, as it would mean splitting the file operations code
> from Nautilus into a separate component.
>
> Cosimo
>



-- 
alpha_one_x86 <alpha_one_x86 first-world info>
Main developer of Ultracopier, Esourcing and server management
IT, OS, technologies, security and business department