Extending the IProjectFileManager interface

Hi,

 we are discussing here with Jens the need of storing
certain 
information for each file inside the project. One case in
Quanta would 
be storing information about uploads (to the web server):
when the file 
was last uploaded, should it be uploaded or not at all,
should it be 
uploaded without asking the user for confirmation. 
I can imagine that other plugins would also like to store
information 
about a file belonging to the project.
 Our idea was to store such information in the project
configuration 
file (the "local" one if such exists now, not the
one that is shared 
between users).
 I'm writing this mail to ask feedback about how do you
think we should 
go on. The solution are:
1) Extend IProjectFileManager with the needed methods
(probably 
something like writeProperty(ProjectItem*, key, value) and 
readProperty(ProjectItem*, key) ). The IProjectFileManager
would 
contain a default implementation for these methods, so there
is no need 
to reimplement them in every project file manager, unless
there is a 
need for a different behavior. Our way of implementing this
would be 
storing every file as a group (in the KConfig object) and
add the 
key/value pairs to it.

2) Write our own little plugin which does the above and put
it in either 
Quanta (so only Quanta plugins would benefit of this), or in

kdevplatform.

Andras

-- 
Quanta Plus developer - http://quanta.kdewebdev.o
rg
K Desktop Environment - http://www.kde.org

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

On 03.07.07 21:10:05, Andras Mantia wrote:
>  we are discussing here with Jens the need of storing
certain 
> information for each file inside the project. One case
in Quanta would 
> be storing information about uploads (to the web
server): when the file 
> was last uploaded, should it be uploaded or not at all,
should it be 
> uploaded without asking the user for confirmation. 

Such information should be included in the ProjectItem's.

>  Our idea was to store such information in the project
configuration 
> file (the "local" one if such exists now, not
the one that is shared 
> between users).

Yes, thats what the projectmanager does when importing the
file.

> 1) Extend IProjectFileManager with the needed methods
(probably 
> something like writeProperty(ProjectItem*, key, value)
and 
> readProperty(ProjectItem*, key) ).

Why would this be needed? Those extra informations can be
stored by the
projectmanager via obtaining the project configuration and
write to it
the information you need to store. I don't see why this
would be needed.

Of course this means duplicating such things among the
various project
managers. So the question I'm really asking: Can you give me
some
use-cases which wouldn't be easily possible without such (or
similar,
like Alex said) API?

Andreas

-- 
You'll be sorry...

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

On Tuesday 03 July 2007, Andreas Pakulat wrote:
> On 03.07.07 21:10:05, Andras Mantia wrote:
> >  we are discussing here with Jens the need of
storing certain
> > information for each file inside the project. One
case in Quanta
> > would be storing information about uploads (to the
web server):
> > when the file was last uploaded, should it be
uploaded or not at
> > all, should it be uploaded without asking the user
for
> > confirmation.
>
> Such information should be included in the
ProjectItem's.

Exactly what Alexander wrote on IRC. Good point!

> >  Our idea was to store such information in the
project
> > configuration file (the "local" one if
such exists now, not the one
> > that is shared between users).
>
> Yes, thats what the projectmanager does when importing
the file.

BTW, I couldn't find how to access the local file. It seems
to be 
commented out now.

> > 1) Extend IProjectFileManager with the needed
methods (probably
> > something like writeProperty(ProjectItem*, key,
value) and
> > readProperty(ProjectItem*, key) ).
>
> Why would this be needed? Those extra informations can
be stored by
> the projectmanager via obtaining the project
configuration and write
> to it the information you need to store. I don't see
why this would
> be needed.

We want to avoid having all plugins accessing directly the
config file 
and doing the same thing. Also Quanta might want to store
information 
how I told, but maybe QMake or CMake project wants to store
some 
information in other form. Still this would be transparent
to the 
plugin that writes or read the properites.

> Of course this means duplicating such things among the
various
> project managers. So the question I'm really asking:
Can you give me
> some use-cases which wouldn't be easily possible
without such (or
> similar, like Alex said) API?

I gave the use case for which we need right now: the upload
plugin. And 
I want to avoid config file manipulation directly from the
plugin.

Andras
-- 
Quanta Plus developer - http://quanta.kdewebdev.o
rg
K Desktop Environment - http://www.kde.org

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

On Tuesday 03 July 2007, Andreas Pakulat wrote:
> So the question I'm really asking: Can you give me
some
> use-cases which wouldn't be easily possible without
such (or similar,
> like Alex said) API?

Jens gave me a good reason why not to do in the plugins: if
you remove a 
file from the project, you want to have the properties
removed from the 
config file. So you need a central place which handles
adding/removing 
the properties.

Andras

-- 
Quanta Plus developer - http://quanta.kdewebdev.o
rg
K Desktop Environment - http://www.kde.org

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

On 03.07.07 22:10:57, Andras Mantia wrote:
> On Tuesday 03 July 2007, Andreas Pakulat wrote:
> > On 03.07.07 21:10:05, Andras Mantia wrote:
> > >  Our idea was to store such information in
the project
> > > configuration file (the "local" one
if such exists now, not the one
> > > that is shared between users).
> >
> > Yes, thats what the projectmanager does when
importing the file.
> 
> BTW, I couldn't find how to access the local file. It
seems to be 
> commented out now.

Uhm, you don't access that file. You access the projects
configuration.
And all changes done will be written to the local file. This
way using
remote projects is completely transparent for the plugins.

> > > 1) Extend IProjectFileManager with the needed
methods (probably
> > > something like writeProperty(ProjectItem*,
key, value) and
> > > readProperty(ProjectItem*, key) ).
> >
> > Why would this be needed? Those extra informations
can be stored by
> > the projectmanager via obtaining the project
configuration and write
> > to it the information you need to store. I don't
see why this would
> > be needed.
> 
> We want to avoid having all plugins accessing directly
the config file 
> and doing the same thing. Also Quanta might want to
store information 
> how I told, but maybe QMake or CMake project wants to
store some 
> information in other form. Still this would be
transparent to the 
> plugin that writes or read the properites.

I'm pretty sure QMake won't do this, its a manager on top of
a
buildsystem, so all I provide is what the buildsystem
provides. Anyway,
I do agree this might be useful, no objections from my side
adding it to
ProjectBaseItem.

Andreas

-- 
You will have a long and boring life.

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

On Jul 3, 2007, at 1:10 PM, Andras Mantia wrote:

> Hi,
>
>  we are discussing here with Jens the need of storing
certain
> information for each file inside the project. One case
in Quanta would
> be storing information about uploads (to the web
server): when the  
> file
> was last uploaded, should it be uploaded or not at all,
should it be
> uploaded without asking the user for confirmation.
> I can imagine that other plugins would also like to
store information
> about a file belonging to the project.
>  Our idea was to store such information in the project
configuration
> file (the "local" one if such exists now, not
the one that is shared
> between users).
>  I'm writing this mail to ask feedback about how do you
think we  
> should
> go on. The solution are:
> 1) Extend IProjectFileManager with the needed methods
(probably
> something like writeProperty(ProjectItem*, key, value)
and
> readProperty(ProjectItem*, key) ). The
IProjectFileManager would
> contain a default implementation for these methods, so
there is no  
> need
> to reimplement them in every project file manager,
unless there is a
> need for a different behavior. Our way of implementing
this would be
> storing every file as a group (in the KConfig object)
and add the
> key/value pairs to it.
>
> 2) Write our own little plugin which does the above and
put it in  
> either
> Quanta (so only Quanta plugins would benefit of this),
or in
> kdevplatform.
>
> Andras
>
> --

3. Create ProjectItem subclasses to store the data for the
item with  
that item. They should be able to save their data to the
file of  
their choice as requested by taking a QDataStream. Something
like:

QuantaFileItem::save( const QDataStream& );

for a declaration.

#3 is the idea I like the best. It seems the cleanest from
my point  
of view and doesn't require changing our API.
--
Matt



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

On Tuesday 03 July 2007, Andreas Pakulat wrote:
> On 03.07.07 22:10:57, Andras Mantia wrote:
> > On Tuesday 03 July 2007, Andreas Pakulat wrote:
> > > On 03.07.07 21:10:05, Andras Mantia wrote:
> > > >  Our idea was to store such information
in the project
> > > > configuration file (the
"local" one if such exists now, not the
> > > > one that is shared between users).
> > >
> > > Yes, thats what the projectmanager does when
importing the file.
> >
> > BTW, I couldn't find how to access the local file.
It seems to be
> > commented out now.
>
> Uhm, you don't access that file. You access the
projects
> configuration. And all changes done will be written to
the local
> file. This way using remote projects is completely
transparent for
> the plugins.

Maybe I wasn't clear about the local file. Of course, I
shouldn't care 
if the project was remote or not, and if the file I'm
writing on is 
*exactly* the project file or a local copy of it.

What I meant all above with the local file is the file that
is not 
shared by developers. Do we still have this concept? I mean,
in 
KDevelop3 and Quanta3 there is the project file and a
project session 
file (yeah, this is a better name). Theoretically the
project file 
contains only information that are relevant for all
developers, while 
the session file is specific for the current developer.
Propertis IMO 
can go in both files, as they might be shearable or not. 
So is such a session file now in KDevelop4? If not, I'd say
we need to 
introduce one.

Andras

-- 
Quanta Plus developer - http://quanta.kdewebdev.o
rg
K Desktop Environment - http://www.kde.org

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

On 05.07.07 14:02:56, Andras Mantia wrote:
> On Tuesday 03 July 2007, Andreas Pakulat wrote:
> > On 03.07.07 22:10:57, Andras Mantia wrote:
> > > On Tuesday 03 July 2007, Andreas Pakulat
wrote:
> > > > On 03.07.07 21:10:05, Andras Mantia
wrote:
> > > > >  Our idea was to store such
information in the project
> > > > > configuration file (the
"local" one if such exists now, not the
> > > > > one that is shared between users).
> > > >
> > > > Yes, thats what the projectmanager does
when importing the file.
> > >
> > > BTW, I couldn't find how to access the local
file. It seems to be
> > > commented out now.
> >
> > Uhm, you don't access that file. You access the
projects
> > configuration. And all changes done will be
written to the local
> > file. This way using remote projects is completely
transparent for
> > the plugins.
> 
> Maybe I wasn't clear about the local file. Of course, I
shouldn't care 
> if the project was remote or not, and if the file I'm
writing on is 
> *exactly* the project file or a local copy of it.
> 
> What I meant all above with the local file is the file
that is not 
> shared by developers. Do we still have this concept?

Yes, its stored in
<project>/.kdev4/<projectname>.kdev4 and access
to it
is given through the projectConfiguration() API.

> I mean, in 
> KDevelop3 and Quanta3 there is the project file and a
project session 
> file (yeah, this is a better name). Theoretically the
project file 
> contains only information that are relevant for all
developers, while 
> the session file is specific for the current developer.
Propertis IMO 
> can go in both files, as they might be shearable or
not. 

No they can't, the project file is read-only because a
read-write-approach didn't work out. So now
project-default-config is
read from the project-file, but storing is always done into
the
local-file (or session file, whatever you call it).

Andreas

-- 
You are taking yourself far too seriously.

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

On Thursday 05 July 2007, Andreas Pakulat wrote:
> On 05.07.07 14:02:56, Andras Mantia wrote:
> > On Tuesday 03 July 2007, Andreas Pakulat wrote:
> > > On 03.07.07 22:10:57, Andras Mantia wrote:
> > > > On Tuesday 03 July 2007, Andreas Pakulat
wrote:
> > > > > On 03.07.07 21:10:05, Andras Mantia
wrote:
> > > > > >  Our idea was to store such
information in the project
> > > > > > configuration file (the
"local" one if such exists now, not the
> > > > > > one that is shared between
users).
> > > > >
> > > > > Yes, thats what the projectmanager
does when importing the file.
> > > >
> > > > BTW, I couldn't find how to access the
local file. It seems to be
> > > > commented out now.
> > >
> > > Uhm, you don't access that file. You access
the projects
> > > configuration. And all changes done will be
written to the local
> > > file. This way using remote projects is
completely transparent for
> > > the plugins.
> >
> > Maybe I wasn't clear about the local file. Of
course, I shouldn't care
> > if the project was remote or not, and if the file
I'm writing on is
> > *exactly* the project file or a local copy of it.
> >
> > What I meant all above with the local file is the
file that is not
> > shared by developers. Do we still have this
concept?
>
> Yes, its stored in
<project>/.kdev4/<projectname>.kdev4 and access
to it
> is given through the projectConfiguration() API.
>
> > I mean, in
> > KDevelop3 and Quanta3 there is the project file
and a project session
> > file (yeah, this is a better name). Theoretically
the project file
> > contains only information that are relevant for
all developers, while
> > the session file is specific for the current
developer. Propertis IMO
> > can go in both files, as they might be shearable
or not.
>
> No they can't, the project file is read-only because a
> read-write-approach didn't work out. So now
project-default-config is
> read from the project-file, but storing is always done
into the
> local-file (or session file, whatever you call it).

Now I am confused very much. Do you mean we have one *.kdev4
file which is 
read-only (which is supposed to be in a VCS) and one 
<project>/.kdev4/<projectname>.kdev4 which is
read-write (which is supposed 
to be _not_ in a VCS)? 

Jens


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

On 05.07.07 22:20:40, Jens Herden wrote:
> On Thursday 05 July 2007, Andreas Pakulat wrote:
> > On 05.07.07 14:02:56, Andras Mantia wrote:
> > > I mean, in
> > > KDevelop3 and Quanta3 there is the project
file and a project session
> > > file (yeah, this is a better name).
Theoretically the project file
> > > contains only information that are relevant
for all developers, while
> > > the session file is specific for the current
developer. Propertis IMO
> > > can go in both files, as they might be
shearable or not.
> >
> > No they can't, the project file is read-only
because a
> > read-write-approach didn't work out. So now
project-default-config is
> > read from the project-file, but storing is always
done into the
> > local-file (or session file, whatever you call
it).
> 
> Now I am confused very much. Do you mean we have one
*.kdev4 file which is 
> read-only (which is supposed to be in a VCS) and one 
> <project>/.kdev4/<projectname>.kdev4 which
is read-write (which is supposed 
> to be _not_ in a VCS)? 

Yes, thats what I meant. This has been this way ever since
Adam (IIRC)
created the code. The only difference between then and now
is that the
user can't choose which file to store the settings to.
Reason for that
is a discussion held on this list some time in March (IIRC),
where the
outcome was that allowing the user to choose is not
working.

Andreas

-- 
It is so very hard to be an
on-your-own-take-care-of-yourself-because-there-is-no-one-el
se-to-do-it-for-you
grown-up.

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