Single Qt codebase for kdeconnect

[Pavel Zinin]

By rewriting I mean only necessary changes. After all I do not want break everything and change architecture. So I would prefer  sticking to sshfs 
And I must admit that I am rare windows user: KDE is second to none since 2008 =)

I will eventually take a look at sshfs version for windows and figure out how to leverage it.. as I know it is not direct port from fuse but rather based on Dokan.net. I will try to cover more details in the actual proposal. 



On 20 January 2015 06:57:26 EET, Aleix Pol <aleixpol at kde.org> wrote:
>On Tue, Jan 20, 2015 at 4:47 AM, Albert Vaca <albertvaka at gmail.com>
>wrote:
>> Sometimes I use Windows and Mac, and I really miss KDE Connect on
>these
>> platforms. I would love to have KDE Connect in every platform, but
>having 1
>> client per platform is unsustainable.
>>
>> Using KDE for Windows I once managed to compile and run KDE Connect
>on
>> Windows 7, even though lots of plugins and features were missing.
>It's
>> normal to find this problems when porting code to a different
>platform, but
>> I think that our approach here should be to fix this issues instead
>of
>> rewriting everything from scratch. This is definitely more difficult
>and
>> challenging, specially for different platforms like Windows Phone,
>but I
>> truly believe that it is the correct choice.
>>
>>
>> On Mon, Jan 19, 2015 at 4:23 PM, Aleix Pol <aleixpol at kde.org> wrote:
>>>
>>> On Tue, Jan 20, 2015 at 1:05 AM, Pavel Borisov <pzinin at gmail.com>
>wrote:
>>> > On 20.01.2015 02:27, Aleix Pol wrote:
>>> >>
>>> >> This needs investigation. I have reports that dbus works properly
>on
>>> >> OS X, Windows, Android and BBX.
>>> >>
>>> > Yes it does. But as far as I am concerned Qt on Windows does not
>support
>>> > dbus by default so it requires rebuilding. Anyway if it will work
>as it
>>> > is -
>>> > fine.
>>> >
>>> > Also, by universal client for everything I mean, really, if I will
>do
>>> > that I
>>> > will make it like that (I won't touch existing KDE gui as it is
>good
>>> > already).
>>> >
>>> > BTW it is actually what I want to propose as GSoC project. And it
>>> > implies
>>> > sort of real changes because most plugins are highly dependent on
>KDE.
>>> > For
>>> > example, SFTP plugin uses KIO (however very slightly) . More
>important,
>>> > it
>>> > uses sshfs which is unacceptable on windows (it has its own port
>of
>>> > sshfs
>>> > and I will try to figure out how to deal with it probably), etc,
>etc.
>>> >
>>> > In conclusion, pretty much everything there needs to be rewritten
>>> > (slightly,
>>> > but still) in order to make it cross-platform.
>>> >
>>>
>>> I understand more the e-mails then. I'll be looking forward to your
>>> application. I must admit though that I don't love the fact that
>>> you're talking so much about rewritting, I want to read about
>>> improvements, so if there's anything to be rewritten (and in fact I
>>> agree the sftp plugin is a good candidate) please explain well what
>>> you want to do. Sentences like "everything needs to be rewritten"
>are
>>> bad.
>>>
>>> For example, KIO is really available and working on Windows, maybe
>>> there's something better you can do? What would you use instead? Is
>>> ssh the problem? Or sshfs itself? How do you plan to integrate it on
>>> Windows?
>>> Maybe what we want in the end is not SFTP-kind-of-thing but actual
>>> file synchronization...
>>>
>>> Aleix
>>> _______________________________________________
>>> KDEConnect mailing list
>>> KDEConnect at kde.org
>>> https://mail.kde.org/mailman/listinfo/kdeconnect
>>
>>
>
>Maybe a good first approach would be to have a GSoC that makes sure
>KDE Connect works great on Windows/OS X/Gnome rather than going to
>different mobile platforms that are admittedly harder.
>
>Aleix

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20150120/09950e2b/attachment.html>