Re: Conduit as common back end

["John Stowers" <john stowers gmail com>]

On Wed, Jul 30, 2008 at 11:14 PM, Pascal Bach <pascal bach nextrem ch> wrote:
> Hi sorry it took me so long but I had lots of work to do with my exams and a
> project we had to finish for university.

No problem. I understand.

>
> Now I have some spare time and I started digging around in the source code
> of conduit. Concerning your mail I have some questions.
>
>
> John Stowers wrote:
>>
>> On Wed, Jun 11, 2008 at 10:06 AM, Pascal Bach <pascal bach nextrem ch>
>> wrote:
>>
>>>
>>> Hi,
>>>
>>
>> Hi Pascal,
>>
>> I have copied this email to John Carr, another conduit developer who
>> has had some talks with KDE folks in the past.
>>
>
> Was there already something done in this direction or was there just a
> discussion, if yes do you now where I can find something about it?

Im not sure. I will ask Jc2k.

>>
>> This will not be very hard at all, for the most part. There is an
>> example of how this can be done in the source tree, with both hildon
>> (maemo) and gtk UIs. In addition, Conduit can be run 'headless', with
>> only a DBus interface showing. The conduit Core does not depend on
>> Gtk, only glib/gobject.
>>
>
> Whats the reason it depends on glib/gobject on not just on plain python?

Many reasons. gobject mainloop, signals, timers, etc. The gobject/glib
dependency will stay.

>>
>> But... because no one has yet started to implement a KDE gui for
>> Conduit this abstraction falls down in few places.
>> 1) We still depend on gnomevfs. I am slowly porting all of the
>> filesystem access to our own abstraction layer - conduit.Vfs. My goal
>> for this is to use gio/gvfs for all file operations, to allow conduit
>> to be run on windows. However, there is no reason, that once
>> conduit.Vfs is complete, a kio backend could not implement the same
>> interface.
>>
>
> It would be nice to have it running on Windows and Mac OS X to because most
> parts of KDE will be available on these platforms too.

Since your last mail I have merged a great many improvements to the
platform abstraction. I should have vfs implementations using the
native python file io, and using gio, done in a week.

http://bzr-playground.gnome.org/~jstowers/conduit/conduit-gio/

>>
>> 2) The configuration windows for all dataproviders currently use
>> gtk/glade. The dataproviders can also be configured from xml, so there
>> are a few options for implementing kde native configuration windows,
>> or at least removing the hard dependence on gtk for configuring them.
>>
>
> What I would like the most is if the base of the program is really only
> python with a minimum of dependencies so no GTK+ or QT stuff there. This
> would make it easier to write a web based frontend or what other frontends
> somebody might imagine
>>
>> The third way is to implement a KDE gui for Conduit using the dbus
>> interface alone.
>>
>>
>
> bbus would be a nice way, but I don't know the support on platforms other
> than Linux. I think we should be as platform independent as possible.

I agree. Please check out the gio branch and let me know what you think.

John

>>
>> I like it, and I look forward to working with you.
>>
>
> Me too :-)
>
> Regards,
>
> Pascal
>
>
>