[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-vcm-dev] Mutlithreading in the Team UI
|
I would be very interested in the result. I believe using progess
monitors *and* content providers is a common case without a common
solution supported by the current UI API. I was wondering if you would
trigger a change in the ui APIs?
Mariano
On Mon, 2002-08-12 at 17:51, Michael Valenta wrote:
>
> OK. Now I see what you mean. I believe you are referring to the cases where
> we don't even pop up a progress monitor (i.e. expanding an entry in the
> repo view, etc). We are investigating solutions to this.
>
>
>
>
> Mariano Kamp
> <mkamp@xxxxxx> To: eclipse team dev <platform-vcm-dev@xxxxxxxxxxx>
> Sent by: cc:
> platform-vcm-dev-admin@ Subject: Re: [platform-vcm-dev] Mutlithreading in the Team UI
> eclipse.org
>
>
> 08/12/2002 01:34 PM
> Please respond to
> platform-vcm-dev
>
>
>
>
>
> Hi Michael,
>
> > What do you mean by content provider? Do you mean TargetProvider?
> Well, I am talking about a content provider for some view. This is a
> problem which is not unique to the team plugin, but I did believe it had
> the most impact here.
>
> > As for non-blocking communications, the problem from a CVS, FTP and DAV
> > standpoint is that, if an upload or download is non-blocking, a user
> could
> > modify resources that are involved in the transfer at the wrong time and
> > cause corruption either locally or remotely. Some sort of mechanism to
> lock
> > the resource during the operation would be required.
> I do understand that, but I don't believe that it is ok to lock the
> whole ui. Not even a repaint is possible.
>
> > So to answer you question: yes, it bothers me when I have to wait for a
> > long running operation to finish but I can't think of a safe way to make
> > the CVS, FTP or DAV operations non-blocking. I should also say that there
> > may be some operations that can be non-blocking and we will investigate
> > these.
> I believe the platform ui is missing something here. I explained that
> below. Could you have another look?
>
> Mariano
>
>
> >
>
> > Mariano Kamp
>
> > <mkamp@xxxxxx> To: eclipse
> team dev <platform-vcm-dev@xxxxxxxxxxx>
> > Sent by: cc:
>
> > platform-vcm-dev-admin@ Subject:
> [platform-vcm-dev] Mutlithreading in the Team UI
> > eclipse.org
>
> >
>
> >
>
> > 08/12/2002 12:23 PM
>
> > Please respond to
>
> > platform-vcm-dev
>
> >
>
> >
>
> >
> >
> >
> > This is a repost. I posted it the first as the 2.0 version was beeing
> > finalized, probably this was a bad time.
> >
> > If this is off no interest or whatsoever I would at least appreciate if
> > somebody says so.
> >
> > Mariano
> > ----
> > Hi,
> >
> > I am working on a plugin, where the gui submits long lasting calls (to
> > a database). Unfortunately the gui locks up then.
> >
> > I did see that you guys are facing the same thing when accessing the
> > repositories. Especially when you connect to a slow cvs server, e.g.
> > sourcforge, the gui is not responsive anymore.
> >
> > There is another similarity. I would divide the issue into two type of
> > calls. a) Operations on cvs, like check-out or update (in my case
> > executing queries to a database) and b) calls from a content provider.
> >
> > I think a) is relatively easy to accomplish in my case (no resource
> > modifications needed) -> just spawn a new thread and implement a call
> > back, but b) seems to be more complex. The content provider calls don't
> > provide a progress monitor and now call backs. I do understand the
> > intention, that these calls should be fast, but as even the resources
> > can meanwhile live on a ftp or web-dav server this assumptions will not
> > even last for the simplest case of resources.
> >
> >
> > I know that platform-ui-dev would be the addressee for most of these
> > things, but I wanted to talk to you first, to see how you want to cope
> > with it, or doesn't the current behaviour bother you?
> >
> > I am sure everything could be accomplished with the current API. I've
> > also read the article from Chris Grindstaff
> > (http://eclipse.org/articles/treeviewer-cg/TreeViewerArticle.htm) where
> > he proposes to show some "loading" image and using a callback to deliver
> > the real information, but he wasn't going into any detail, how to do
> > that in a non-ugly fashion. I am just wondering if in 3.0 there will
> > evolve something elegant to solve this common problem?
> >
> > On a side bar (just to be on-topic ;-). I really like the 2.0 Team
> > API. I like the full exposure of the cvs functionality and still the
> > tight integration into the platform. Great job.
> >
> > Cheers,
> > Mariano
> >
> >
> > _______________________________________________
> > platform-vcm-dev mailing list
> > platform-vcm-dev@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/platform-vcm-dev
> >
> >
> >
> >
> > _______________________________________________
> > platform-vcm-dev mailing list
> > platform-vcm-dev@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/platform-vcm-dev
> >
>
>
> _______________________________________________
> platform-vcm-dev mailing list
> platform-vcm-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-vcm-dev
>
>
>
>
> _______________________________________________
> platform-vcm-dev mailing list
> platform-vcm-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-vcm-dev
>
