Re: VCS interfaces draft

>>> One question is that I don't know to which
directory this file should
>>> go. Other than that, everything seems to be
straightforward.
>> I'd say lib/interfaces

>Uhm, you sure? Until now it doesn't contain any
extension interfaces, so
>I guess its rather plugins/vcs/interfaces (and later
have vcs/cvs and
>vcs/svn with the 2 default implementations).

But that's strange. To my understanding so far, extention
interface
header files(*.h) should be included at some other
components.
For example, ioutputview.h is included in qmakebuilder.cpp
Then the build system should keep track of every dispersed
directories where extention interfaces reside.
Why don't we consolidate every extentions into one
directory?
lib/interfaces or lib/extentions seem to be good

Also for Alexander's comment

>From more major modifications, I'd say that the
interface is not enough.
>What if we have more methods in IVersionControl?
Something
>along these lines:

>bool commit(KUrl::List &);
>bool add(KUrl::List &);
>bool remove(KUrl::List &);
>....
>etc.

I don't feel the need of these user-invoked action
interfaces.
The only case these commit/add actions start is via menubar
or context
menu. I personaly think that these context menu should be
filled out
by each plugin. So other component can forget about other
actions.
Rather, IVersionControl::fillContextMenu(KUrl&,
QMenu&) seems
to be appropriate.

for example, in my working copy

void ProjectTreeView::popupContextMenu( const QPoint
&pos )

{
    QModelIndex index = indexAt( pos );

    if ( ProjectBaseItem *item = projectModel()->item(
index ) )
    {
        KMenu menu( this );

        IPlugin* vcsIface =
d->m_part->core()->pluginController()->
           
pluginForExtension("IVersionControl");
        KDevelop::IVersionControl* vctrl;
        if( vcsIface )
            vctrl=
vcsIface->extension<KDevelop::IVersionControl>();

        if ( ProjectFolderItem *folder = item->folder()
)
        {
            menu.addTitle( i18n( "Folder: %1",
folder->url().directory() ) );
            if( vctrl )
                vctrl->fillContextMenu( folder->url(),
menu );
        }
        else if ( ProjectFileItem *file = item->file() )
        {
            menu.addTitle( i18n( "File: %1",
file->url().fileName() ) );
            if( vctrl )
                vctrl->fillContextMenu( file->url(),
menu );
        }
        else if ( ProjectTargetItem *target =
item->target() )
        {
            menu.addTitle( i18n( "Target: %1",
target->text() ) );
        }
        menu.exec( mapToGlobal( pos ) );
    }
}

so let's clearify it!
Other than these, I applied all the member's comments.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

2007/3/23, dukju ahn <dukjuahngmail.com>:
> I personaly think that these context menu should be
filled out
> by each plugin.

Sorry, typo and unclear meaning.
Not each plugin, but VCS plugin.

"I personaly think that these VCS context menu should
be filled
out by VCS plugins itself."

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 23.03.07 05:52:56, dukju ahn wrote:
> >>> One question is that I don't know to which
directory this file should
> >>> go. Other than that, everything seems to
be straightforward.
> >> I'd say lib/interfaces
> 
> >Uhm, you sure? Until now it doesn't contain any
extension interfaces, so
> >I guess its rather plugins/vcs/interfaces (and
later have vcs/cvs and
> >vcs/svn with the 2 default implementations).
> 
> But that's strange. To my understanding so far,
extention interface
> header files(*.h) should be included at some other
components.
> For example, ioutputview.h is included in
qmakebuilder.cpp
> Then the build system should keep track of every
dispersed
> directories where extention interfaces reside.
> Why don't we consolidate every extentions into one
directory?
> lib/interfaces or lib/extentions seem to be good

Because then you've got a "huge" pile of extension
interfaces for
various types of things. At the moment we keep the
interfaces together
with the plugins, thats why we have outputview/interfaces,
project/interfaces and so on. Thats just easier to manage,
IMHO.

> >>From more major modifications, I'd say that the
interface is not enough.
> >What if we have more methods in IVersionControl?
Something
> >along these lines:
> 
> >bool commit(KUrl::List &);
> >bool add(KUrl::List &);
> >bool remove(KUrl::List &);
> >....
> >etc.
> 
> I don't feel the need of these user-invoked action
interfaces.

Are they always user-invoked? We're thinking about allowing
people to
write scripts using Kross and there they might want to use
these
methods, at least add/remove do make sense to me. (not with
that
parameter list though).

Andreas

-- 
You have the body of a 19 year old.  Please return it before
it gets wrinkled.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Friday 23 March 2007 14:52, dukju ahn wrote:
> But that's strange. To my understanding so far,
extention interface
> header files(*.h) should be included at some other
components.
> For example, ioutputview.h is included in
qmakebuilder.cpp
> Then the build system should keep track of every
dispersed
> directories where extention interfaces reside.
> Why don't we consolidate every extentions into one
directory?
> lib/interfaces or lib/extentions seem to be good
The point is that each plugin can define an extension
interface
and we certainly don't have to have them all in one place.
Therefore we keep extension interfaces as close to their
plugins as
possible.

> Also for Alexander's comment
>
> >From more major modifications, I'd say that the
interface is not enough.
> >What if we have more methods in IVersionControl?
Something
> >along these lines:
> >
> >bool commit(KUrl::List &);
>
> I don't feel the need of these user-invoked action
interfaces.
> The only case these commit/add actions start is via
menubar or context
> menu. I personaly think that these context menu should
be filled out
> by each plugin. So other component can forget about
other actions.
> Rather, IVersionControl::fillContextMenu(KUrl&,
QMenu&) seems
> to be appropriate.

I understand that, but I'd like to have some scripting via
QtScript so
that not only plugins with popup menus but also scripts
could use
the vcs functionality. For example, one might write a script
alike
svnmerge.py but with user interaction in kdevelop.

Also there're appwizard needs. Basically, to create a
project in repository,
appwizard needs to add files there and fetch them back.
Maybe there will be need for committing.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

2007/3/23, dukju ahn <dukjuahngmail.com>:
> I personaly think that these context menu should be
filled out
> by each plugin.

Sorry, typo and unclear meaning.
Not each plugin, but VCS plugin.

"I personaly think that these VCS context menu should
be filled
out by VCS plugins itself."

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel