kplato compile problem on windows

[Pierre Stirnweiss]

do we have a consensus on one solution over the other?

PierreSt

On Mon, Jan 24, 2011 at 10:51 AM, Dag Andersen <danders at get2net.dk> wrote:

> Mandag 24 januar 2011 10:37:00 skrev Cyrille Berger Skott:
> > On Monday 24 January 2011, Pierre Stirnweiss wrote:
> > > I can try the nepomuk solution (using KPLATO_EXPORT on each methods of
> > > the class instead of on the class itself) this evening. This would
> > > probably be the minimal impact solution.
> > > Just so I am clear, it seems that in nepomuk they have only specified
> > > NEPOMUK_EXPORT on some of the methods. My assumption is that they
> > > exported only the methods which were really used outside? Otherwise I
> > > don't really understand why isFileDataObject would get the EXPORT and
> > > not isFolder for example.
> >
> > Generally speaking, you only need to export what is really used outside
> :)
> > We usually export the whole class, because if a function is public, we
> > assume that it wants to be used. I don't know what is the intent of
> > "libs/kernel", if it is strictly private to kplato/plan, then exporting
> > only the needed function make sense.
> I put the basics into separate lib because I thought maybe in the
> (distant?)
> future one could use it independently of the current plan/kplato gui.
> >
> > (Personnally, I would go for Jan's solution and hide the QMap, because I
> > don't like to inherits from the containers, but I guess it is a matter of
> > taste :) )
>
> --
> Mvh.
> Dag Andersen
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20110124/7183f23e/attachment.htm>