[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: Webdav + Zope
From:       Paul Everitt <paul () zope ! com>
Date:       2002-03-25 15:37:37
[Download RAW message or body]


Sorry for the delay in replying.  I am on a two week swing through 
Europe and connectivity has been challenging.  BTW, if anybody in Paris 
wants to have a beer...:^)

Comments below...

Hamish Rodda wrote:
> On Wednesday, 20th March 2002, Paul Everitt <paul@zope.com> wrote:
> 
>>Hamish Rodda wrote:
>>
>>>As a preface to my answers, integration is somewhat hampered by the user
>>>interface capabilities of kio.  I hope to get around this with a konqueror
>>>plugin (a kpart). At the moment I don't have a time frame for this
>>>however.
>>
>>Yes, this UI issue is the part where I also don't understand the options.
> 
> 
> Kparts can be used to provide a different user interface in Konqueror, 
> including such things as showing which files are locked, edit source options 
> etc.

To what extent do you have to do Kpart development in C++?  Can Python 
be used in the future?

>>>Yes... the slave is aware of this and sends detected script locations to
>>>the kde app. A kpart is needed for konqueror to be aware in the UI.
>>
>>Ideally, in KWord I could do "Edit Source" if the server tells the
>>client there is a src available in the properties.
> 
> 
> Hmmm - now I think about it, this could be added universally with a small 
> dialog... I'll think about it a bit more...

Whew!

>>>>2) Mime type.  Zope is a rich object system, where you can have
>>>
>>Right-click, New->[sequence of builtin types, sequence of extended types]
>>
>>This is the behavior under Windows.
> 
> 
> Ok, needs investigation.
> 
> 
>>>>4) Lock/unlock.  It should be simple to set/remove the lock on a Zope
>>>>resource.  As we start do implement more versioning in Zope, there will
>>>>need to be more operations (checkout/checkin/revert/etc.), as well as
>>>>displaying the versioning status.
>>>
>>>Again, done but requires a kpart or custom app support.
>>
>>I don't think that it should, since there are HTTP verbs that specify
>>this.  It is simply a question of how (or whether) to display it).
> 
> 
> The support described is only on the user interface; the logic is built into 
> the slave already.

That is very good news.

>>Any idea if Kate can handle XML namespaces on attributes, such as:
>>
>>  <p tal:content="here/title">Some text</p>
> 
> 
> They are highlighted properly, yes. I don't think Kate provides much more 
> support than highlighting.

As long as Kate doesn't eat attributes from foreign namespaces.  Amaya 
used to do this, as did Mozilla.  That is, the attributes you added 
would disappear when you saved the file.

>>>>1) Sync.  I've wanted this for a while -- the ability to do a visual,
>>>>rsync-style application between the local filesystem and Zope (or two
>>>
>>Not really like versioning.  Rather, a two-paned view that compares
>>local to remote, then shows the add/change/delete differences in
>>resources.  Similar to cadaver, which has a Gnome frontend.
> 
> 
> That is a possibility but I would think a rather distant one.

Completely agree.  This is an application of the facility that should
be developed completely separately.

>>>>3) Rich presentation.  There is probably a way to make the non-file
>>>>information in Zope, such as security settings and properties, viewable
>>>>and settable in KDE.  Any ideas, without writing a dedicated app?
>>>
>>>Again, a job for the kpart.
>>
>>Right.  Can a kpart be written in Python?
> 
> 
> With the new bindings, I believe so...

Great, I'm off to take a look at them...

--Paul



[prev in list] [next in list] [prev in thread] [next in thread]