Re: Unit test coverage

[Pierre Stirnweiss]

I have never really looked deep into how unit tests are set. Is there
somewhere something I can read to give me more insight into this. For
example, how is the coverage of a file calculated?

Pierre


On Sun, Dec 12, 2010 at 10:43 AM, Cyrille Berger Skott
wrote:

> On Sunday 12 December 2010, Cyrille Berger Skott wrote:
> > So kudo to Dag and Plan for the file with the highest coverage:
> > http://my.cdash.org/viewCoverageFile.php?buildid=127785&fileid=508339
> Bah, there is an other page with test with higher coverage :
> http://my.cdash.org/viewCoverage.php?buildid=127785&status=2
>
> --
> Cyrille Berger Skott
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Developer Sprint

[Pierre Stirnweiss]

I won't be able to fill in the doodle until the 10th of January. I am
already on holiday and will go back to work on the 10th. I don't have access
to my calendar. If organisation can't wait untill then, then i'll just pray
that the chosen date is not conflicting with anything.

Pierre

On Tue, Dec 21, 2010 at 10:17 PM, Jaroslaw Staniek  wrote:

> I am glad to see this thread and equally glad to see the long list of
> valuable topics.
> I'd like to add something popping on top of my head for quite some
> time (while not working on picking new names for office suites ;))
>
> I propose to go with Qt-only libs a bit more, to make our offerings
> more independent each-other and drive potential contributions of new
> kind (Qt only devs, non-KDE devs...).
> Filters are good candidates for this group, and especially the
> lower-level libraries like mso Smart Art, Diagrams...
>
> KoReports are nearly Qt-only already (as a fork of OpenRPT it has
> never used kdelibs in fact). The same for KoProperty lib.
>
> I am investing into Qt-only Predicate a lot too
> (http://community.kde.org/Predicate), as you know it'll be dependency
> of kexi, hopefully 2.4.
>
> Moreover I also believe that every app has some nontrivial bit of code
> that can be provided on the outside with a simple API, say, using the
> Facade pattern.
>
> At a conceptual level the idea may evolve into slightly different
> model of composing our building blocks: develop core functionality as
> Qt-only and then extend for KDE, to get the integration level and
> look&feel we all want.
>
> A bit like it is in WebKit/QtWebKit tandem.
>
> RFC.
>
> --
> regards / pozdrawiam, Jaroslaw Staniek
>  http://www.linkedin.com/in/jstaniek
>  Kexi & Calligra (kexi-project.org, identi.ca/kexi, calligra-suite.org)
>  KDE Software Development Platform on MS Windows (windows.kde.org)
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Merge request of text layout restructuring

[Pierre Stirnweiss]

Hi, I am back from holidays. I have for the moment problems with my
Virtualbox 4 installation which keeps crashing on me as soon as I push it a
bit. That means I'll have difficulties for reviewing the patch right now. I
am considering trying a development set-up on Windows until Virtualbox is
stabilised again, but i am not sure how feasible this is (any hint in this
direction is actually welcomed).

PierreSt


On Wed, Jan 5, 2011 at 4:44 PM, Sebastian Sauer  wrote:

> C. Boemann wrote:
> > Last week I worked on the text layout, and I'm now requesting a merge of
> > the branch I worked in:
> >
> > text-layoutrestructure-boemann
> >
> > What I've done is moving the text runaround properties from the KWFrame
> > class to KoShape
> >
> > Secondly I moved the runaround code from KWord to the TextShape.
> > However it is still the responsibility of the application to supply the
> > textshape with the relevant shapes.
> >
> > This was stepd 2-4 in my big 7 step master plan that I've talked to all
> > words developers about.
> >
> > Please take a look, and comment.
> >
> > I've made basic testing and I'm rather confident that there are no
> > regressions. Many unit test might be broken, and should be disabled for
> > now.
> >
> > Review mainly requested from hanzes,pierreSt ,pinaraf, sebsauer, but also
> > anyone else who think they have something to contribute.
>
> Review done. In words/part/tests/TestDocumentLayout.cpp before 21 tests
> failed
> and now 25 are failing. The probably most interesting one seems to be in
> placeAnchoredFrame3() which does;
>
> QTextLayout *lay = doc->begin().layout();
> QVERIFY(lay->lineCount() >= 2);
>
> Before the refactoring that lay->lineCount() call returns 17 here and after
> it
> returns 1. Also waiting for a few seconds after the layout doesn't change
> that
> result either. Can that be a problem?
>
> Beside this case it looks fine to me :-)
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Merge request of text layout restructuring

[Pierre Stirnweiss]

I have already seen that one. But I have also seen on the dot comments (in
the article about KDE on windows) that calligra is not compiling and that
Boud is looking into this. I am interested in more calligra specific
information. Also, is Qt Creator a good solution for developing on windows?

PierreSt

On Wed, Jan 12, 2011 at 2:59 PM, Cyrille Berger Skott
wrote:

> On Wednesday 12 January 2011, Pierre Stirnweiss wrote:
> > Hi, I am back from holidays. I have for the moment problems with my
> > Virtualbox 4 installation which keeps crashing on me as soon as I push it
> a
> > bit. That means I'll have difficulties for reviewing the patch right now.
> I
> > am considering trying a development set-up on Windows until Virtualbox is
> > stabilised again, but i am not sure how feasible this is (any hint in
> this
> > direction is actually welcomed).
> All information is there:
>
> http://techbase.kde.org/Getting_Started/Build/KDE4/Windows
>
> --
> Cyrille Berger Skott
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Merge request of text layout restructuring

[Pierre Stirnweiss]

On Wed, Jan 12, 2011 at 3:13 PM, Boudewijn Rempt  wrote:

> On Wednesday 12 January 2011, Pierre Stirnweiss wrote:
> > I have already seen that one. But I have also seen on the dot comments
> (in
> > the article about KDE on windows) that calligra is not compiling and that
> > Boud is looking into this. I am interested in more calligra specific
> > information.
>
> My problem is that I tried to compile against packages from the kdewin
> installer since I didn't have enough space to use the emerge script. And
> those packages have some errors that made my life hard.
>
> Damn, I was hoping to use these pre-compiled packages to avoid having to
compile the whole stack under calligra. oh well, it will remind me of my
time with gentoo.



> > Also, is Qt Creator a good solution for developing on windows?
>
> Yes.
>

Are you using (if so) ms compiler or mingw compiler? It seems they have both
pros and cons (disregarding any philosophical considerations).

Pierre
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: 2.4 Release Plan

[Pierre Stirnweiss]

On Thu, Jan 13, 2011 at 2:51 PM, Inge Wallin  wrote:

> On Thursday, January 13, 2011 14:15:01 Cyrille Berger Skott wrote:
> > On Thursday 13 January 2011, Tomas Mecir wrote:
> > > As a disclaimer, I'm not active in Calligra development currently, so
> > > my opinion may not be entirely relevant, but hopefully it will be
> > > useful anyway.
> > >
> > > Wouldn't it be better to (at least for the initial release) use a
> > > different development scheme with an alpha/beta version being released
> > > every month or so, with no feature freeze in place? It could be more
> > > work to manage it, but by maintaining a relatively constant stream of
> > > pre-releases that each contains actual improvements (not only bug
> > > fixes), you'd keep the general awareness of the project, while at the
> > > same time having enough time to polish the applications to be end-user
> > > ready for the first final version (2.4 or 3.0 or however you're going
> > > to call it).
> >
> > One of my main concern with that is that I do think that having hard date
> > gives us a focus. I think "a release when we feel we are ready" tends to
> > make us go in many directions, because anyway we have time to fix things.
> > While if you have a date, you have to focus on selecting what you feel is
> > important to finish and fix before that date.
>
> That is probably correct.  How could we make it so that we can keep focus
> while still make sure that we get the necessary features and bugfixes in?
>

Perhaps by doing a suggested: every maintainer set a list of required to
release features. Then we can set a fixed date for feature freeze and leave
the release date opened.

Pierre


> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Merge request of text layout restructuring

[Pierre Stirnweiss]

Well, I have only looked at the code through gitweb, which seems not to
allow an easy way of finding the relevant diff to master (maybe I am using
the tool incorrectly): the commits specific to this branch do not seem to be
highlighted. I have looked at the commits "Move text run around attributes
from Words frame class...", "Move Line out into a file of it's own" and
"Move Line and Outline  from Words to TextShape". I would have liked a way
to find a condensed diff to the master branch.

At first view, things seem ok. I have not yet tested the branch in real
life. I have a question though: what impact does it have (if any) on other
apps using the textshape (Stage comes to my mind)? These where not getting
this run-around behaviour from the textShape.

Another minor thing. Shouldn't the properties/methods "textRunAroundSide"
and "textRunAroundDistance" be called a more generic way? There might be
other shapes which would run their content around shapes (the musicShape
could an example of this). Perhaps remove the "text" from the name?
Also, to be more consistent, the Through enum should be named RunThrough, it
is after all set by setRunThrough().

In principle, I think we should merge this ASAP if we want it to be included
in the next release. There should be enough time to test it and iron out
things. The month before release would be a bad idea.


PierreSt



On Mon, Jan 3, 2011 at 11:25 AM, C. Boemann  wrote:

> Hi
>
> Last week I worked on the text layout, and I'm now requesting a merge of
> the
> branch I worked in:
>
> text-layoutrestructure-boemann
>
> What I've done is moving the text runaround properties from the KWFrame
> class
> to KoShape
>
> Secondly I moved the runaround code from KWord to the TextShape.
> However it is still the responsibility of the application to supply the
> textshape with the relevant shapes.
>
> This was stepd 2-4 in my big 7 step master plan that I've talked to all
> words
> developers about.
>
> Please take a look, and comment.
>
> I've made basic testing and I'm rather confident that there are no
> regressions.
> Many unit test might be broken, and should be disabled for now.
>
> Review mainly requested from hanzes,pierreSt ,pinaraf, sebsauer, but also
> anyone else who think they have something to contribute.
>
> best regards
> Casper
> Best regards
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Merge request of text layout restructuring

[Pierre Stirnweiss]

Ah, so why does it still appear as a head in gitweb?

It just proves that I really need to set up my development environment. Busy
week end in sight

Well, other comments still applies... ;)

Pierre



On Fri, Jan 14, 2011 at 2:23 PM, C. Boemann  wrote:

> On Friday 14 January 2011 14:20:45 Pierre Stirnweiss wrote:
> > Well, I have only looked at the code through gitweb, which seems not to
> > allow an easy way of finding the relevant diff to master (maybe I am
> using
> > the tool incorrectly): the commits specific to this branch do not seem to
> > be highlighted. I have looked at the commits "Move text run around
> > attributes from Words frame class...", "Move Line out into a file of it's
> > own" and "Move Line and Outline  from Words to TextShape". I would have
> > liked a way to find a condensed diff to the master branch.
> >
> > At first view, things seem ok. I have not yet tested the branch in real
> > life. I have a question though: what impact does it have (if any) on
> other
> > apps using the textshape (Stage comes to my mind)? These where not
> getting
> > this run-around behaviour from the textShape.
> >
> > Another minor thing. Shouldn't the properties/methods "textRunAroundSide"
> > and "textRunAroundDistance" be called a more generic way? There might be
> > other shapes which would run their content around shapes (the musicShape
> > could an example of this). Perhaps remove the "text" from the name?
> > Also, to be more consistent, the Through enum should be named RunThrough,
> > it is after all set by setRunThrough().
> >
> > In principle, I think we should merge this ASAP if we want it to be
> > included in the next release. There should be enough time to test it and
> > iron out things. The month before release would be a bad idea.
> >
> >
> > PierreSt
> >
> > On Mon, Jan 3, 2011 at 11:25 AM, C. Boemann  wrote:
> > > Hi
> > >
> > > Last week I worked on the text layout, and I'm now requesting a merge
> of
> > > the
> > > branch I worked in:
> > >
> > > text-layoutrestructure-boemann
> > >
> > > What I've done is moving the text runaround properties from the KWFrame
> > > class
> > > to KoShape
> > >
> > > Secondly I moved the runaround code from KWord to the TextShape.
> > > However it is still the responsibility of the application to supply the
> > > textshape with the relevant shapes.
> > >
> > > This was stepd 2-4 in my big 7 step master plan that I've talked to all
> > > words
> > > developers about.
> > >
> > > Please take a look, and comment.
> > >
> > > I've made basic testing and I'm rather confident that there are no
> > > regressions.
> > > Many unit test might be broken, and should be disabled for now.
> > >
> > > Review mainly requested from hanzes,pierreSt ,pinaraf, sebsauer, but
> also
> > > anyone else who think they have something to contribute.
> > >
> > > best regards
> > > Casper
> > > Best regards
> > > ___
> > > calligra-devel mailing list
> > > calligra-devel@kde.org
> > > https://mail.kde.org/mailman/listinfo/calligra-devel
> Good you think so becasue it was merged by sebastian more than a week ago
> ;)
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: words - call for help

[Pierre Stirnweiss]

If my memory is not betraying me (being past 30 you can never be sure of
this any more ;)), what you are looking for (to check current
implementation) is in plugins/textshape/dialogs. There should be something
called styleWidget, styleModel, (or similar names).

PierreSt


On Fri, Jan 14, 2011 at 2:29 PM, brian larochelle <
larochelle.br...@gmail.com> wrote:

> Hello,
> I want to start looking at this tonight after work.  Provided the girl will
> leave me alone for a few geek hours ;), and no one else has shown interest.
>  I've been working with Qt over the past several months porting my iphone
> application to Qt, which makes use of model/view.  And I've always wanted to
> contribute to kde.
>
> I'll start by rereading the wiki and irc logs, haven't had a chance to
> really read them yet.  Then work on navigating the source and find my way
> around.  At first glance, I'll likely start at the below locations.  Any
> pointers or additional info would be welcome :)
> cheers,
>
> calligra/plugins/dockers/styledocker/
> calligra/words/part/dockers
>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Calligra Sprint 1.4.-3.4.

[Pierre Stirnweiss]

I don't seem to be able to log in anymore. Could our beloved admin have a
look for me please?
In the mean time, here is my info: flight cost: about 120EUR, both
accomodation and sponsorship needed.

PierreSt


On Sat, Jan 15, 2011 at 5:28 AM, Thorsten Zachmann wrote:

> Hello all,
>
> looks like not everybody has filled out
>
> http://community.kde.org/Calligra/Meetings/Begin_2011_meeting#Attendance
>
> yet. This is a reminder to fill it out by the end of the week (16.1.). The
> information is needed so that we can get the approval of the costs by the
> e.V.
> board.
> So if you like to join the sprint please don't wait any longer and fill it
> out.
> It does not matter if you have answered the doodle or not. Fill out the the
> above now so that we can go on with the next steps. We need to hurry so
> that
> we can arrange visas for the people needing those.
>
> Thanks,
>
> Thorsten
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Re: koffice-essen branch interesting for a story in the Commit Digest?

[Pierre Stirnweiss]

I'd be delighted to see a calligra news dated for the 19th of December. I
like this date a lot, since it's my birthday ;)

But no pressure ;)

Pierre

On Sun, Jan 16, 2011 at 1:59 PM, Boudewijn Rempt  wrote:

> On Sun, 16 Jan 2011, Alexander van Loon wrote:
>
> > If possible I’d like to include it for the next Commit Digest of either
> 19 December or 26 December (remember we are still
> > catching up after delays) which will be prepared over the next week I
> assume. I didn’t think of a deadline, but if you could e-
> > mail it during the next week it would be good, let’s say before next
> Friday?
>
> Ok, will do!
>
> Boudewijn
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Combined startup view and file menu

[Pierre Stirnweiss]

I like this idea a lot.

PierreSt (who is still struggling to set a development environment in
Windows. God the Linux package managers are a bless)


On Thu, Jan 20, 2011 at 7:38 AM, Mani N C  wrote:

> I like the way Recent Documents are grouped and listed.
>
> For me the side pane looks cluttered in the top. How would it be, if it was
> evenly spaced out and fonts/icons little bigger ?
>
> On the whole +1 from me :)
>
>
> On Thu, Jan 20, 2011 at 1:10 AM, Jaroslaw Staniek  wrote:
>
>> Another mockup.
>> Variant of the 3.1 mockup: "Words" button's frame has been completely
>> removed, so the button looks and feels like other menu items.
>>
>>
>> http://community.kde.org/Calligra/Usability_and_UX/Common/Startup/Startup_view_integrated_with_the_File_menu#Startup_view_mockup_3.2:_with_view_hidden_and_no_button_frame
>>
>> --
>> regards / pozdrawiam, Jaroslaw Staniek
>>  http://www.linkedin.com/in/jstaniek
>>  Kexi & Calligra (kexi-project.org, identi.ca/kexi, calligra-suite.org)
>>  KDE Software Development Platform on MS Windows (windows.kde.org)
>> ___
>> calligra-devel mailing list
>> calligra-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/calligra-devel
>>
>
>
>
> --
> Mani Chandrasekar
>
>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

kplato compile problem on windows

[Pierre Stirnweiss]

As some of may know, I am trying to get Calligra to compile on Windows
MSVC2010. I have encountered a couple of problems, which were easy enough to
solve (with the help of SaroEngels).
The one I am facing now is apparently way more complicated:

in kplato/libs/kernel/kpappointment.h we have the following:

class KPLATO_EXPORT AppointmentInterval {}
class KPLATO_EXPORT AppointmentIntervalList: public QMultiMap {}

This construct yields the error C2487:
 'identifier' : member of dll interface class may not be declared with dll
interface
You can declare a whole class, or certain members of a non-DLL interface
class, with DLL interface. You cannot declare a class with DLL interface and
then declare a member of that class with DLL interface.


According to SaroEngels, both QDate and AppointmentInterval are problematic
here. A solution he proposed to this is to have the following:

class KPLATO_EXPORT AppointmentInterval;

class AppointmentIntervalBase : public QMultiMap

class KPLATO_EXPORT AppointmentIntervalList : public AppointmentIntervalBase


Any further thought on this?


PierreSt
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: kplato compile problem on windows

[Pierre Stirnweiss]

The functions it is complaining about are the ones from QMap/QMultiMap

PierreSt

On Mon, Jan 24, 2011 at 9:19 AM, Thorsten Zachmann wrote:

> On Monday, January 24, 2011 08:57:15 Pierre Stirnweiss wrote:
> > As some of may know, I am trying to get Calligra to compile on Windows
> > MSVC2010. I have encountered a couple of problems, which were easy enough
> > to solve (with the help of SaroEngels).
> > The one I am facing now is apparently way more complicated:
> >
> > in kplato/libs/kernel/kpappointment.h we have the following:
> >
> > class KPLATO_EXPORT AppointmentInterval {}
> > class KPLATO_EXPORT AppointmentIntervalList: public QMultiMap > AppointmentInterval> {}
> >
> > This construct yields the error C2487:
> >  'identifier' : member of dll interface class may not be declared with
> dll
> > interface
> > You can declare a whole class, or certain members of a non-DLL interface
> > class, with DLL interface. You cannot declare a class with DLL interface
> > and then declare a member of that class with DLL interface.
> >
> >
> > According to SaroEngels, both QDate and AppointmentInterval are
> problematic
> > here. A solution he proposed to this is to have the following:
> >
> > class KPLATO_EXPORT AppointmentInterval;
> >
> > class AppointmentIntervalBase : public QMultiMap > AppointmentInterval>
> >
> > class KPLATO_EXPORT AppointmentIntervalList : public
> > AppointmentIntervalBase
> >
> >
> > Any further thought on this?
> If I understood the comment from jahm correctly it might mean you need to
> implemnt the functions it is complaining about in your inherited class but
> I'm
> not 100% sure about that. Maybe try it with one of the functions to see if
> the
> error message goes away.
>
> Thorsten
>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: kplato compile problem on windows

[Pierre Stirnweiss]

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.

PierreSt

On Mon, Jan 24, 2011 at 10:23 AM, Dag Andersen  wrote:

> Mandag 24 januar 2011 09:52:23 skrev Jan Hambrecht:
> > On 24.01.2011 08:57, Pierre Stirnweiss wrote:
> > > As some of may know, I am trying to get Calligra to compile on Windows
> > > MSVC2010. I have encountered a couple of problems, which were easy
> > > enough to solve (with the help of SaroEngels).
> > > The one I am facing now is apparently way more complicated:
> > >
> > > in kplato/libs/kernel/kpappointment.h we have the following:
> > >
> > > class KPLATO_EXPORT AppointmentInterval {}
> > > class KPLATO_EXPORT AppointmentIntervalList: public QMultiMap > > AppointmentInterval> {}
> > >
> > > This construct yields the error C2487:
> > > 'identifier' : member of dll interface class may not be declared with
> > > dll interface
> > > You can declare a whole class, or certain members of a non-DLL
> interface
> > > class, with DLL interface. You cannot declare a class with DLL
> interface
> > > and then declare a member of that class with DLL interface.
> > >
> > >
> > > According to SaroEngels, both QDate and AppointmentInterval are
> > > problematic here. A solution he proposed to this is to have the
> > > following:
> > >
> > > class KPLATO_EXPORT AppointmentInterval;
> > >
> > > class AppointmentIntervalBase : public QMultiMap > > AppointmentInterval>
> > >
> > > class KPLATO_EXPORT AppointmentIntervalList : public
> > > AppointmentIntervalBase
> > >
> > >
> > > Any further thought on this?
> >
> > I would try to change the class from  to  > QMultimap>. If I remember correctly from a short look yesterday, nowhere
> > in the code are the QMultimap methods of AppointmentIntervalList used,
> > beside within the implementation of AppointmentIntervalList itself.
> Not quite true, but refactoring is not a *big* thing, it's mostly
> lowerBound(), upperbound().
> So if this is the cleanest way, I can do that.
> > So maybe using the follwing construct will work:
> >
> > class AppointmentIntervalBase
> > {
> > // all your existing methods go here
> > private:
> >  QMultiMap m_data;
> > };
> >
> > Ciao Jan
> > ___
> > calligra-devel mailing list
> > calligra-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/calligra-devel
>
> --
> Mvh.
> Dag Andersen
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: kplato compile problem on windows

[Pierre Stirnweiss]

But then, would it be possible to instantiate an AppointmentIntervalList
from outside?

Pierre

On Mon, Jan 24, 2011 at 10:28 AM, Pierre Stirnweiss <
pstirnwe...@googlemail.com> 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.
>
> PierreSt
>
>
> On Mon, Jan 24, 2011 at 10:23 AM, Dag Andersen  wrote:
>
>> Mandag 24 januar 2011 09:52:23 skrev Jan Hambrecht:
>> > On 24.01.2011 08:57, Pierre Stirnweiss wrote:
>> > > As some of may know, I am trying to get Calligra to compile on Windows
>> > > MSVC2010. I have encountered a couple of problems, which were easy
>> > > enough to solve (with the help of SaroEngels).
>> > > The one I am facing now is apparently way more complicated:
>> > >
>> > > in kplato/libs/kernel/kpappointment.h we have the following:
>> > >
>> > > class KPLATO_EXPORT AppointmentInterval {}
>> > > class KPLATO_EXPORT AppointmentIntervalList: public QMultiMap> > > AppointmentInterval> {}
>> > >
>> > > This construct yields the error C2487:
>> > > 'identifier' : member of dll interface class may not be declared with
>> > > dll interface
>> > > You can declare a whole class, or certain members of a non-DLL
>> interface
>> > > class, with DLL interface. You cannot declare a class with DLL
>> interface
>> > > and then declare a member of that class with DLL interface.
>> > >
>> > >
>> > > According to SaroEngels, both QDate and AppointmentInterval are
>> > > problematic here. A solution he proposed to this is to have the
>> > > following:
>> > >
>> > > class KPLATO_EXPORT AppointmentInterval;
>> > >
>> > > class AppointmentIntervalBase : public QMultiMap> > > AppointmentInterval>
>> > >
>> > > class KPLATO_EXPORT AppointmentIntervalList : public
>> > > AppointmentIntervalBase
>> > >
>> > >
>> > > Any further thought on this?
>> >
>> > I would try to change the class from  to > > QMultimap>. If I remember correctly from a short look yesterday, nowhere
>> > in the code are the QMultimap methods of AppointmentIntervalList used,
>> > beside within the implementation of AppointmentIntervalList itself.
>> Not quite true, but refactoring is not a *big* thing, it's mostly
>> lowerBound(), upperbound().
>> So if this is the cleanest way, I can do that.
>> > So maybe using the follwing construct will work:
>> >
>> > class AppointmentIntervalBase
>> > {
>> > // all your existing methods go here
>> > private:
>> >  QMultiMap m_data;
>> > };
>> >
>> > Ciao Jan
>> > ___
>> > calligra-devel mailing list
>> > calligra-devel@kde.org
>> > https://mail.kde.org/mailman/listinfo/calligra-devel
>>
>> --
>> Mvh.
>> Dag Andersen
>> ___
>> calligra-devel mailing list
>> calligra-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/calligra-devel
>>
>
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: kplato compile problem on windows

[Pierre Stirnweiss]

>
>
>
> (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
> :) )
>
> Which wouldn't *need* to add a AppointmentIntervalListBase, would it?

Pierre
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: 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  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@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: kplato compile problem on windows

[Pierre Stirnweiss]

On Mon, Jan 24, 2011 at 3:53 PM, Pierre Stirnweiss <
pstirnwe...@googlemail.com> wrote:

> On Mon, Jan 24, 2011 at 3:48 PM, Dag Andersen  wrote:
>
>> Mandag 24 januar 2011 14:40:10 skrev du:
>> > ok, no stress, i have still plenty of other things to do in setting up
>> my
>> > development environment on windows. i am still missing a lot of the
>> > optional dependencies, i still can't commit from windows,
>> > if worse comes to worse and i am left with nothing else to do, i can
>> still
>> > temporarily disable compilation of kplato.
>> Done, even with minutes to spear :)
>> God luck with windows.
>>
>
> Thanks, it is actually proving way more cumbersome than anticipated. By the
> time i am finished, virtualbox will probably be fixed, and i would be able
> to run linux again oh well, at least it brings some value to the
> project.
>

Modulo 3 changes in the kpappointment.cpp, that class is now compiling. I
have reached a further error in kplato but haven't looked into it yet. I'll
have more time tomorrow to finish up fixing the errors on kplato and i'll
commit then.

Pierre
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: tools docker etc in plan

[Pierre Stirnweiss]

To be honest, I think we should think a bit further. My impression (when I
was looking into tools/plugins loading mechanism for the (still unfinished)
change tracking tool) is that the system is very rigid and basically depends
on the developer knowing what plugins are there what plugins would be
usefull. There also is the case where some tools of one particular plugin
does not make sense (expl, the change tracking tool of the textshape plugin
doesn't make sense outside words, because odf does not foresee change
tracking outside a text document).
I think we should revisit how our plugins/tools are loaded and allow more
flexibility at runtime to set which are the plugins to be loaded (also by
users). After all, the whole point of the plugin system is to allow external
plugins to be designed. So there should be a way to set this up, other than
calligra core developpers explicitely allowing/disallowing plugins/tools.

On a side note, it seems that at application startup, all the plugins are
loaded serialised and only when this is finished will the application load
further. That's ok when we have only a handfull of plugin installed but the
system does not scale very much. Can't we have non critical plugins load in
parrallel to further application startup?, in a different thread?

PierreSt

On Tue, Jan 25, 2011 at 10:49 AM, Dag Andersen  wrote:

> Atm I don't have any use for the tools docker nor actually any other docker
> except the Scripting docker in plan.
> This *may* change in the future of course, so it would be nice to have a
> way
> of controlling which plugins should be loaded. AFAICS it's possible to
> *disable* plugins if you know their id. I'd rather have the possibility to
> *enable* those I use and have everything else disabled.
> Anybody knows how this could most easily be achived?
> --
> Mvh.
> Dag Andersen
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: tools docker etc in plan

[Pierre Stirnweiss]

On Tue, Jan 25, 2011 at 3:25 PM, Sven Langkamp wrote:

> On Tue, Jan 25, 2011 at 11:07 AM, Pierre Stirnweiss <
> pstirnwe...@googlemail.com> wrote:
>
>> To be honest, I think we should think a bit further. My impression (when I
>> was looking into tools/plugins loading mechanism for the (still unfinished)
>> change tracking tool) is that the system is very rigid and basically depends
>> on the developer knowing what plugins are there what plugins would be
>> usefull. There also is the case where some tools of one particular plugin
>> does not make sense (expl, the change tracking tool of the textshape plugin
>> doesn't make sense outside words, because odf does not foresee change
>> tracking outside a text document).
>> I think we should revisit how our plugins/tools are loaded and allow more
>> flexibility at runtime to set which are the plugins to be loaded (also by
>> users). After all, the whole point of the plugin system is to allow external
>> plugins to be designed. So there should be a way to set this up, other than
>> calligra core developpers explicitely allowing/disallowing plugins/tools.
>>
>
> Only plugins that flake loads by default should need to be blacklisted.
> Usually external developers shouldn't add plugins with that type. The change
> tracking tool could be loaded as Words plugin, just as the Krita tools that
> have the Krita/Tool plugin type.
>

The change tracking tool is (and up to now) need to be a tool of the
textshape, so as far as I understand the system, I can't load the textshape
without the change tracking tool. But maybe there is something I overlooked.

But in a more general way, is there a way for me (as a user) to let's say,
have the music shape enabled for words and not for stages? Can I change this
at run time?


Pierre
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: kplato compile problem on windows

[Pierre Stirnweiss]

Hi Dag,

sorry to nag you again. I have some questions related to the external (made
internal) dependency for the scheduler (librcps). Was there a reason to copy
the code inside our repository instead of linking to it as an external lib?
I have a couple of problems with it. The first problem, which is now solved
is that the files have a .c extension, although they are c++. I (locally)
renamed them. However, that fix might not be desirable, the code being from
external source. In that case I think there is the possibility to add a flag
to the CMakeList.txt. Tell me what you think is best.

The problem I am now stuck at is coming from this:

 537 int job_compare(const void *a, const void *b) {
 538 return a - b;
 539 }

MSVC tells me that the size of const void* is unknown. On looking on the
web, I see people explaining that since the object type, and therefore size
is unknown you cannot (at least in msvc) do pointer math on these. There are
actually some quite heated discussions on the merit of msvc/gcc spawning
from this, funny.
Basically it seems that the consensus is to cast the pointer to a char* if
you want to do pointer arithmetic.
Now, I am not actually completely sure I understand what is wanted here, but
I assume this code is basically a: if(job a == job b) return 0 else return
!0. I guess then that casting the pointers to char* wouldn't affect the
logic, would it?

Any other suggestion for this? Should I contact the original author of the
lib?

Thanks,

PierreSt
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Review Request: Moving anchor strategy into text shape

[Pierre Stirnweiss]

Sorry to arrive after the battle, but I still would like to give an opinion
on this one.
I don't think this change is going in the right direction. It mixes
responsibilities between kotext lib/textshape/application even more.

I think we should have a clear separation of responsibilities:
kotext lib: handles character/string level
textshapes: handles lines inside a shape, given constraints of that shape
application: handles shapes

I think it is bad idea to put things like page size, page number,... inside
kotext. This lib is supposed to be used by applications which are not
necessarily page driven.
Equally, I don't think it is the responsibility of every text shape to have
a track record of the other shapes. Children shapes eventually, but
definitely not shapes that are unrelated. This should be at application
level.

Now you have even more diffusion of stuff. If this is the direction you want
to give to the text stuff, why are we still having a textshape and kotext
lib?


Pierre



On Thu, Jan 27, 2011 at 6:13 AM, Thorsten Zachmann wrote:

>This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/100442/
>
> I just added some small comments mostly about the style. Would be nice if you 
> could fix those before committing.
>
>
>
> plugins/textshape/Layout.h
>  (Diff
> revision 1)
>
> class ToCGenerator;
>
>56
>
> ~Layout();
>
>   the destructor should be marked virtual
>
>
>
> plugins/textshape/TextAnchorStrategy.h
>  (Diff
> revision 1)
>
> class KoTextShapeData;
>
>28
>
> class TextAnchorStrategy  : public KoAnchorStrategy {
>
>   the opening { should be moved to the next line
>
>
>
> plugins/textshape/TextAnchorStrategy.cpp
>  (Diff
> revision 1)
>
> bool TextAnchorStrategy::countVerticalRel(QRectF &anchorBoundingRect, QRectF 
> containerBoundingRect,
>
>335
>
> switch (m_anchor->verticalRel()) {
>
>   the indention of the switch and case is wrong here
>
>
>
> words/part/frames/KWTextDocumentLayout.cpp
>  (Diff
> revision 1)
>
> private:
>
>   286
>
> // if part of page is already layouted than check if there 
> are some anchored shapes and register them
>
> 259
>
> //QRectF bounds = m_state->shape->boundingRect();
>
>   is it worth to keep the commented out code. If so please add a comment on 
> why it is commented out, if not please delete it. That will make it easier 
> later to figure out why the code is commented out
>
>
> - Thorsten
>
> On January 25th, 2011, 2:04 p.m., Matus Hanzes wrote:
>   Review request for Calligra and Casper Boemann.
> By Matus Hanzes.
>
> *Updated Jan. 25, 2011, 2:04 p.m.*
> Description
>
> This patch moves KWAnchorStrategy into text shape.
>
> The reason is that it is not possible to do advanced shape anchor logic 
> outside Layout.cpp.
>
> The main idea is to register the shapes into Layout.cpp and layout handles 
> all the necessary things.
>
> The registration is done in KWTextDocumentLayout::positionInlineObject where 
> all the words dependent data are set. 
> (pageRectangle,pageContentRectangle,pageNumber)
>
> If the document or anchored shape changes 
> KoTextDocumentLayout::resetInlineObject is called which resets all the shapes 
> that are not valid and layout finds the right place for them.
>
> Any comments are welcome
>
>
>   Diffs
>
>- libs/flake/KoShape.h (f7179d7)
>- libs/flake/KoShape.cpp (c5aee86)
>- libs/kotext/KoTextAnchor.h (2bbbf9a)
>- libs/kotext/KoTextAnchor.cpp (ece23d6)
>- libs/kotext/KoTextDocumentLayout.h (4284d37)
>- libs/kotext/KoTextDocumentLayout.cpp (6b66e0f)
>- libs/kotext/KoTextShapeContainerModel.h (ce3a6ae)
>- libs/kotext/KoTextShapeContainerModel.cpp (00ca9b5)
>- plugins/textshape/CMakeLists.txt (a23ecc3)
>- plugins/textshape/Layout.h (5e42b7a)
>- plugins/textshape/Layout.cpp (e1228e4)
>- plugins/textshape/TextAnchorStrategy.h (PRE-CREATION)
>- plugins/textshape/TextAnchorStrategy.cpp (PRE-CREATION)
>- words/part/CMakeLists.txt (2d5c667)
>- words/part/frames/KWAnchorStrategy.h (b39f377)
>- words/part/frames/KWAnchorStrategy.cpp (c168962)
>- words/part/frames/KWTextDocumentLayout.h (59add4f)
>- words/part/frames/KWTextDocumentLayout.cpp (15a8803)
>
> View Diff 
>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Review Request: Moving anchor strategy into text shape

[Pierre Stirnweiss]

On Thu, Jan 27, 2011 at 10:51 AM, C. Boemann  wrote:

> Well this is a step on the road and not the end result. So bear with me.
>
> But I've indeed changed my mind about who does the layout and drawing, and
> have come up with an abstraction that will allow the kotext library to do
> just
> that.


So you mean, drawing/layouting would be done at kotext level?


> Well totally controlled by the textshape. This abstraction will allow
> any application to gain layout and painting.


This is already the case. kotext provides an abstracted interface for
layouting. the user of the lib needs to implement his layouting logic. What
layouting logic/paradigm would you favor for kotext? this would also mean
that any other layouting paradigm/logic, would still need to carry the
weight (memory footprint,...) of a layouting logic he does not even care
about?
Sounds like a step in the opposite direction of the goal of deploying/using
on a multitude of devices, for a multitude of use cases.
A bit like MS having internet explorer right tied up with their kernel. It
becomes awefully difficult to have a very lean kernel based on windows.

First app that will benefit from
> this is our very own Tables.
>
> But shapes and pages will soon be abstracted away as i said. Oh and no one
> requires those pagesizes and numbers to be filled out by apps that don't
> use
> it. For those apps the anchoring mode that relate to these things will
> simply
> not be activated.
>

Yes, no one has to fill these, but you are bloating a general purpose
library with specific cases peculiarities. You'll end up with a melting pot
library of things which do not relate to each other. You mention Tables, so
why not also add the Spreadsheet/Cell coordinates to the mix? And since
kotext could also be used in a painting application, the layer to which the
anchored shape belongs. then, one could use kotext for a music notation
stuff, so we could add score/voice/bar information.

I am exaggerating this a lot, but once the box is opened, it is very
difficult to draw a line.


Pierre



>
> On Thursday 27 January 2011 10:25:08 Pierre Stirnweiss wrote:
> > Sorry to arrive after the battle, but I still would like to give an
> opinion
> > on this one.
> > I don't think this change is going in the right direction. It mixes
> > responsibilities between kotext lib/textshape/application even more.
> >
> > I think we should have a clear separation of responsibilities:
> > kotext lib: handles character/string level
> > textshapes: handles lines inside a shape, given constraints of that shape
> > application: handles shapes
> >
> > I think it is bad idea to put things like page size, page number,...
> inside
> > kotext. This lib is supposed to be used by applications which are not
> > necessarily page driven.
> > Equally, I don't think it is the responsibility of every text shape to
> have
> > a track record of the other shapes. Children shapes eventually, but
> > definitely not shapes that are unrelated. This should be at application
> > level.
> >
> > Now you have even more diffusion of stuff. If this is the direction you
> > want to give to the text stuff, why are we still having a textshape and
> > kotext lib?
> >
> >
> > Pierre
> >
> > On Thu, Jan 27, 2011 at 6:13 AM, Thorsten Zachmann
> wrote:
> > >This is an automatically generated e-mail. To reply, visit:
> > > http://git.reviewboard.kde.org/r/100442/
> > >
> > > I just added some small comments mostly about the style. Would be nice
> if
> > > you could fix those before committing.
> > >
> > >plugins/textshape/Layout.h<
> http://git.reviewboard.kde.org/r/100442/dif
> > >f/1/?file=7551#file7551line56> (Diff
> > >
> > > revision 1)
> > >
> > > class ToCGenerator;
> > >
> > >56
> > >
> > > ~Layout();
> > >
> > >   the destructor should be marked virtual
> > >
> > >plugins/textshape/TextAnchorStrategy.h<
> http://git.reviewboard.kde.org/
> > >r/100442/diff/1/?file=7553#file7553line28> (Diff
> > >
> > > revision 1)
> > >
> > > class KoTextShapeData;
> > >
> > >28
> > >
> > > class TextAnchorStrategy  : public KoAnchorStrategy {
> > >
> > >   the opening { should be moved to the next line
> > >
> > >plugins/textshape/TextAnchorStrategy.cpp<
> http://git.reviewboard.kde.or
> > >g/r/100442/diff/1/?file=7554#file7554line335> (Diff
> > >
> > > revision 1)
> > >
> > 

Re: Review Request: Moving anchor strategy into text shape

[Pierre Stirnweiss]

>
> Well as i said it's going to be abstracted away, and we are creating a
> layout
> engine for ODF after all. Meaning that a lot of the layout is quite
> specified
> how should look.

If all a user wants is layout of text, then kotext is handly
> a match anyway. And yes there might be a little overhead in terms of memory
> footprint, but it's actually not that much.
>
> And we gain so much by having a shared library in terms of easier, smaller
> and
> more maintainable code. And the cells and layer coordinates you talk of,
> are
> actually going to be supplied by the application with the exact same
> abstraction as the pages of a words document.
>
> Casper
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>

There must be something I am missing here.
We have already: kotext providing an abstracted interface for layouting
lines (koTextDocumentLayout IIRC). one implementation of that interface is
in the textShape (Layout). The text within a line is already drawn/layouted
by Qt text engine.
Now you are telling me that layouting gets drawn inside kotext and will be
reabstracted later?

If the purpose is to also have a shared layouting implementation without the
bloat of textshape/texttool,... then I think a better solution would be to
provide one in its own library which would depend on kotext. That way you
can keep kotext clean of higher level layouting, such as lines/shape. Which
would still allow for simpler use cases.

Pierre
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Review Request: Moving anchor strategy into text shape

[Pierre Stirnweiss]

>
>
>
> Anyway there will not be that much interaction between the layout and
> loading.
> So I guess we could make it into a separate text-layout library. But first
> I
> would like a usecase of someone not wanting the full blown layout after
> having
> loaded everything into a library that loads all sorts of formatting
> information.
>

Well, our main differentiating factor and selling point as always been: look
we have a set of very light weight and very modular libraries you can
use/combine to build your own application with. Now we are pulling into
kotext, layouting logic of shapes, probably header and footer and so on.
I don't think all the use cases of "rich text" really need this full blown
stuff. Laying out formatted text along a line could be done using kotext and
its own layouting "plug-in". Applications which would want to draft very
simple text files (for drafting very simple reports, a very basic word
processor for low age education...) probably wouldn't want all the handling
of other shapes logic. You say Tables will benefit, for text inside a cell?
But will the text-run-around logic be really the same as in the word
processor?

The point is that I think we should be keeping a set of very light weight,
purpose specific and modular libraries. If we would have thought monolitic
from the begining, stuff like calligra mobile wouldn't have been possible at
all. After all, at the time koffice2 started: "running a office suite on a
mobile phone? is it really a realistic use case?"

Pierre
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

"How to write a book in a single string"

[Pierre Stirnweiss]

Just a quick email to remind one of our fellow hacker I won't name here that
he has promised to shorten some strings for me. I hope our fellow hacker
still remember what I am talking about. After all, Bavarian nectar comes in
mighty containers

PierreSt
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Help, I need somebody's help (AKA Tables compilation problem on windows)

[Pierre Stirnweiss]

Here is the error: http://paste.kde.org/3643/
Here is the header: http://paste.kde.org/3641/
Here is the cpp: http://paste.kde.org/3642/

These files (header and cpp) are already a modified version of the original
tables/Style.h and Style.cpp, with one of the trials i have already done.

I just don't know what else to do.

Thanks,

PierreSt
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Help, I need somebody's help (AKA Tables compilation problem on windows)

[Pierre Stirnweiss]

i don't know if this code compiles on other platform. this is the result of
several iterative trials to solve the problem

i think i'll try the separate header file solution.

Pierre


On Sun, Jan 30, 2011 at 2:19 PM, Johannes Simon wrote:

> Looks to me like you can't use a forward-declaration of CustomStylePrivate
> to declare a QSharedDataPointer with. Try putting the
> class definition of CustomStylePrivate in its own header (something_p.h) and
> include it in Style.h instead of using this forward declaration. And why is
> it
>
> class CustomStylePrivate::CustomStylePrivate : public QSharedData
> {
> public:
> QString name;
> StyleType type;
> };
>
>
> and not simply
>
> class CustomStylePrivate : public QSharedData
> {
> public:
> QString name;
> StyleType type;
> };
>
>
> This seems odd to me, also since in the comment above the definition it
> says "CustomStyle::Private" (so which of the three is it really supposed to
> be now?). Does this code compile on other platforms?
>
> Johannes
>
>
> Am 30.01.2011 um 09:54 schrieb Pierre Stirnweiss:
>
> Here is the error: http://paste.kde.org/3643/
> Here is the header: http://paste.kde.org/3641/
> Here is the cpp: http://paste.kde.org/3642/
>
> These files (header and cpp) are already a modified version of the original
> tables/Style.h and Style.cpp, with one of the trials i have already done.
>
> I just don't know what else to do.
>
> Thanks,
>
> PierreSt
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
>
>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Help, I need somebody's help (AKA Tables compilation problem on windows)

[Pierre Stirnweiss]

it does not seem possible to move the private classes to a separate private
header, because some data members of those classes are actually define in
the Style class (which is defined in the Style.h)

Pierre


On Sun, Jan 30, 2011 at 2:24 PM, Pierre Stirnweiss <
pstirnwe...@googlemail.com> wrote:

> i don't know if this code compiles on other platform. this is the result of
> several iterative trials to solve the problem
>
> i think i'll try the separate header file solution.
>
> Pierre
>
>
>
> On Sun, Jan 30, 2011 at 2:19 PM, Johannes Simon 
> wrote:
>
>> Looks to me like you can't use a forward-declaration of CustomStylePrivate
>> to declare a QSharedDataPointer with. Try putting the
>> class definition of CustomStylePrivate in its own header (something_p.h) and
>> include it in Style.h instead of using this forward declaration. And why is
>> it
>>
>> class CustomStylePrivate::CustomStylePrivate : public QSharedData
>> {
>> public:
>> QString name;
>> StyleType type;
>> };
>>
>>
>> and not simply
>>
>> class CustomStylePrivate : public QSharedData
>> {
>> public:
>> QString name;
>> StyleType type;
>> };
>>
>>
>> This seems odd to me, also since in the comment above the definition it
>> says "CustomStyle::Private" (so which of the three is it really supposed to
>> be now?). Does this code compile on other platforms?
>>
>> Johannes
>>
>>
>> Am 30.01.2011 um 09:54 schrieb Pierre Stirnweiss:
>>
>> Here is the error: http://paste.kde.org/3643/
>> Here is the header: http://paste.kde.org/3641/
>> Here is the cpp: http://paste.kde.org/3642/
>>
>> These files (header and cpp) are already a modified version of the
>> original tables/Style.h and Style.cpp, with one of the trials i have already
>> done.
>>
>> I just don't know what else to do.
>>
>> Thanks,
>>
>> PierreSt
>> ___
>> calligra-devel mailing list
>> calligra-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/calligra-devel
>>
>>
>>
>> ___
>> calligra-devel mailing list
>> calligra-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/calligra-devel
>>
>>
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Review Request: Patch for using KoAbstractionController directly from FreOffice

[Pierre Stirnweiss]

I might be missing something, but I thought we decided that in-source
building would not get supported in Calligra. Why is it necessary for
Calligra mobile?, Why the exception?
I think that if it is not absolutely necessary to build in source, then we
should drop the possibility and have only out of source build set up.
Especially if having the two enabled means having to change the structure of
the software in an sub-optimal way.

PierreSt


2011/2/2 Mani N C 

> Hello All,
>
> I need your comments/Inputs for the possible solutions,
>
> 1. Write a Wrapper class for KoAbstractApplicationController which would
> have all the slots and signals in it and Child(MainWindow) can create a
> object of the wrapper and connect the signals to it.
>
> 2. Remove QMainWindow inheritance from MainWindow.h and have it as a
> private member of MainWindow class. In this approach we can make
> KoAbstractApplicationContoller to Inherit from QObject.
>
> 3. Have the same design but while building check if it is built
> out-of-source-tree and add/remove headers from KoAbstraction.
>
> Jaroslaw,  Thanks for your hint. But I guess it can't be used in this
> scenario. since we need to define slots in children(MainWindow.cpp) as well.
> Or Have I got it wrong ?
>
> Br,
> Mani
>
>
> On Tue, Feb 1, 2011 at 1:14 PM, Jaroslaw Staniek  wrote:
>
>> ok.. small hint; by coincidence I've encountered
>> KEXI_DATAAWAREOBJECTINTERFACE code in
>> kexi/widget/tableview/kexidataawareobjectiface.h. It'a a Q_OBJECT-like macro
>> that inserts connecting methods to a class. Maybe similar macro could be
>> useful in this case.
>>
>>
>> 2011/2/1 Mani N C 
>>
>> My bad, I agree we won't be able to connect signals. The problem I have is
>>> when f-office is compiled out-of-tree the gives errors. I am trying to fix
>>> this in such a way that it would compile in-source and out-of-tree. Thanks
>>> for your comments, I will try to emit pure virtual methods and see.
>>>
>>> Br,
>>> Mani
>>>
>>>
>>> On Mon, Jan 31, 2011 at 7:23 PM, Jarosław Staniek wrote:
>>>
This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/100462/

 One of the solutions is to have emit*() pure virtual methods in the 
 controller and implement them in f-office to emit real signals.

 Sebastian, you wrote in ba54ba08 3 days ago that something did not build. 
 But it did before...


 - Jarosław

 On January 31st, 2011, 12:07 p.m., Mani Chandrasekar wrote:
   Review request for Calligra.
 By Mani Chandrasekar.

 *Updated Jan. 31, 2011, 12:07 p.m.*
 Description

 This patch removes KoAbstraction class which implements 
 KoAbstractionContorller.

 Since we are reimplementing most of the functions in MainWindow.cpp I have 
 removed KoAbstraction class and moved all the signals to MainWindow
 I feel the implementation should be in freoffice code instead of 
 abstraction library.

 Is there any possible drawbacks in this approach?

   Diffs

- tools/CMakeLists.txt (d4e6ab5)
- tools/f-office/CMakeLists.txt (a212bc0)
- tools/f-office/MainWindow.h (f7b6149)
- tools/f-office/MainWindow.cpp (549b7d1)

 View Diff 

>>>
>>>
>>>
>>> --
>>> Mani Chandrasekar
>>>
>>>
>>
>>
>> --
>> regards / pozdrawiam, Jaroslaw Staniek
>>  http://www.linkedin.com/in/jstaniek
>>  Kexi & Calligra (kexi-project.org, identi.ca/kexi, calligra-suite.org)
>>  KDE Software Development Platform on MS Windows (windows.kde.org)
>>
>
>
>
> --
> Mani Chandrasekar
>
>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: release schedule proposal

[Pierre Stirnweiss]

On Wed, Feb 2, 2011 at 10:18 AM, Boudewijn Rempt  wrote:

> On Wednesday 02 February 2011, Inge Wallin wrote:
>
> > Do you plan to make real, i.e. not previews, of Krita in the mean time?
> The
> > reason I ask is that I wonder which Linux distros are going to package
> the
> > previews and how.
>
> I think that (after a bit of cleanup), Calligra master contains a stable
> version of Krita that is a big improvement over KOffice 2.3. So I would want
> to communicate that to users. I think the same holds for the other apps --
> with 37 feature branches, we've clearly shown that we've grasped the git way
> of working.
>
>
If I remember properly Oslo, we actually had planned to have a "always
stable" master and features developed in branches that would be merged when
"ready". Bug fixes should be done in master.
 I think this is actually working pretty good as of now.

So would it be possible to have on a regular basis (monthly why not), a
"stable snapshot". I am not sure there should be a link with a future
"numbered" release (like 3.0 technology preview). That way we could have
"numbered release" linked to evolution in the software rather than date
constraint.

We could have the following then:
- Calligra [last release number] Stable snapshot [YYMM]. These would provide
both "maintenance releases" and new "finished " merged features.
- Calligra [new release number]: when we decide we achieved technically a
new Milestone.

Pierre
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: [calligra] kplato/plugins/schedulers/rcps/libs/src: Fix Plan compile errors on windows msvc2010

[Pierre Stirnweiss]

On Sat, Feb 5, 2011 at 4:42 AM, Thorsten Zachmann wrote:

> Hello Pierre,
>
> On Saturday, February 05, 2011 00:26:26 Pierre Stirnweiss wrote:
> > -kde4_add_library(librcps_plan SHARED ${librcps_LIB_SRCS})
> > +kde4_add_library(librcps_plan STATIC ${librcps_LIB_SRCS})
>
> this change breaks compiling on linux
>

Bummer, here is a catch 22 situation. What does the error mean? Is it easily
fixable on linux?


>
> Linking CXX shared module ../../../../lib/kplatorcpsscheduler.so
> /usr/bin/ld: ../../../../lib/liblibrcps_plan.a(librcps.o): relocation
> R_X86_64_32 against `.rodata' can not be used when making a shared object;
> recompile with -fPIC
> ../../../../lib/liblibrcps_plan.a: could not read symbols: Bad value
> collect2: ld returned 1 exit status
> make[2]: *** [lib/kplatorcpsscheduler.so] Error 1
> make[1]: ***
> [kplato/plugins/schedulers/rcps/CMakeFiles/kplatorcpsscheduler.dir/all]
> Error
> 2
> make: *** [all] Error 2
>
> When reverting this change it compiles fine again.
>
> Also I get the following message
>
>
> /home/tz/develop/kde/git/calligra/kplato/plugins/schedulers/rcps/libs/src/librcps.c:
> At top level:
>
> /home/tz/develop/kde/git/calligra/kplato/plugins/schedulers/rcps/libs/src/librcps.c:514:
> warning: initialization discards qualifiers from pointer target type
>
> /home/tz/develop/kde/git/calligra/kplato/plugins/schedulers/rcps/libs/src/librcps.c:515:
> warning: initialization discards qualifiers from pointer target type
>
> /home/tz/develop/kde/git/calligra/kplato/plugins/schedulers/rcps/libs/src/librcps.c:516:
> warning: initialization discards qualifiers from pointer target type
>
> /home/tz/develop/kde/git/calligra/kplato/plugins/schedulers/rcps/libs/src/librcps.c:517:
> warning: initialization discards qualifiers from pointer target type
>
> /home/tz/develop/kde/git/calligra/kplato/plugins/schedulers/rcps/libs/src/librcps.c:518:
> warning: initialization discards qualifiers from pointer target type
>
> /home/tz/develop/kde/git/calligra/kplato/plugins/schedulers/rcps/libs/src/librcps.c:519:
> warning: initialization discards qualifiers from pointer target type
>

not culprit for those ones.


>
> /home/tz/develop/kde/git/calligra/kplato/plugins/schedulers/rcps/libs/src/lib.h:7:
> warning: ‘kpt_max’ defined but not used
>
> /home/tz/develop/kde/git/calligra/kplato/plugins/schedulers/rcps/libs/src/lib.h:12:
> warning: ‘kpt_min’ defined but not used
>
>
> maybe this kpt_max and kpt_min can be replaced by qMax and qMin?
>

actually it shouldn't even be fixed with kpt_ prefix. This is an external
library copied in source for convinience. This ought to be fixed upstream
actually.

Pierre
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Here comes success

[Pierre Stirnweiss]

I have not tested anything really yet.
Will do more thotough testing, once I have installed kde-workspace, because
for now the style is hurting my eyes. ;)

Pierre


On Sun, Feb 6, 2011 at 1:36 PM, Jaroslaw Staniek  wrote:

> Congratz!
> BTW, do the shortcuts work?
>
> --
> regards / pozdrawiam, Jaroslaw Staniek
>  http://www.linkedin.com/in/jstaniek
>  Kexi & Calligra (kexi-project.org, identi.ca/kexi, calligra-suite.org)
>  KDE Software Development Platform on MS Windows (windows.kde.org)
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: [calligra] /: Added more checks so cstester, koabstracton and f-office are not built if should not.

[Pierre Stirnweiss]

I was thinking about these when looking at the windows emerge scripts. The
problem I thought was about the libs. If you do a "build krita only" and a
"build words only", you'll still be building the underlying libs each
time. You might turn into problems if you do not update all your "build app
X only" together. I guess I am raising the "independent lib " question
again.

PierreSt


On Tue, Feb 8, 2011 at 10:13 AM, Boudewijn Rempt  wrote:

> On Tuesday 08 February 2011, Cyrille Berger Skott wrote:
> > 2) keep the way things are currently, do not try to resolve dependencies
> > between BUILD_ variables, it is going to be a nightmare anyway, and
> BUILD_ are
> > there for people who know what they are doing, and since the main problem
> we
> > want to solve is to allow people to build only Krita, like we have a TINY
> > option, we add a KRITAONLYOPTION that does:
> > IF (KRITAONLYOPTION)
> > set(SHOULD_BUILD_WORDS FALSE)
> > set(SHOULD_BUILD_KPRESENTER FALSE)
> > set(SHOULD_BUILD_TABLES FALSE)
> > set(SHOULD_BUILD_KARBON FALSE)
> > set(SHOULD_BUILD_KRITA TRUE)
> > set(SHOULD_BUILD_KEXI FALSE)
> > set(SHOULD_BUILD_FLOW FALSE)
> > set(SHOULD_BUILD_KPLATO FALSE)
> > set(SHOULD_BUILD_KFORMULA FALSE)
> > set(SHOULD_BUILD_KCHART FALSE)
> > set(SHOULD_BUILD_KDGANTT FALSE)
> > set(SHOULD_BUILD_KOUNAVAIL FALSE)
> > set(SHOULD_BUILD_SCRIPTING TRUE)
> > set(SHOULD_BUILD_F_OFFICE FALSE)
> > set(SHOULD_BUILD_KOREPORT FALSE)
> > set(SHOULD_BUILD_BRAINDUMP FALSE)
> > set(SHOULD_BUILD_CALLIGRA FALSE)
> > set(SHOULD_BUILD_CSTESTER FALSE)
> > ENDIF()
>
> I like this idea, it will make much easier for Krita users who follow git.
> I'm tempted though, to suggest that karbon should be on by default, since
> karbon still contains a couple of plugins that are useful in Krita as well.
>
> --
> Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Looking for a list of TODO items for a newcoming

[Pierre Stirnweiss]

>
>
>
> Also Pierre is working on getting calligra build on windows. He already
> succeeded but there is still a lot of work done as most optional
> dependencies
> are not there yet. So you might also want to contact him :
> Pierre Stirnweiss 
> Best is if you discuss it on the list with him so also others get to know
> the
> state.
>
> And that would be me ;) There actually are 2 Pierre in Calligra (I don't
know if the other realise the sheer luck of having 2 Pierre in the project).
I am indeed looking into developing on windows, since my virtualbox linux
guest isn't really stable. The first step for developing on windows was to
have it at least compile.
I have the project compiling. However only with a limited set of the
optional dependencies. A lot of these are actually not provided as
kde-on-windows emerge scripts. Krita and Kexi are the main applications hit
by the missing dependencies (these are also the ones requirering the most of
them).

Apart from that, welcome to the project.

PierreSt
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Linking error on windows

[Pierre Stirnweiss]

http://winkde.org/pub/kde/ports/win32/releases/nightly/20110222/logs/log-msvc2010-testing_calligra.txt

There is a linking error happening involving poppler and lcms, when linking
karbonPdfImport.
After talking on the kde-win channel, the conclusion is that we shouldn't
use poppler directly, but the c++ backend.

Is it possible for whoever wrote the plugin to fiy this? or is it too much
work and there is a better/quicker workaround?

PierreSt
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Linking error on windows

[Pierre Stirnweiss]

On Wed, Feb 23, 2011 at 8:45 PM, Cyrille Berger Skott
wrote:

> On Wednesday 23 February 2011, Pierre Stirnweiss wrote:
> >
> http://winkde.org/pub/kde/ports/win32/releases/nightly/20110222/logs/log-ms
> > vc2010-testing_calligra.txt
> >
> > There is a linking error happening involving poppler and lcms, when
> linking
> > karbonPdfImport.
> > After talking on the kde-win channel, the conclusion is that we shouldn't
> > use poppler directly, but the c++ backend.
> >
> > Is it possible for whoever wrote the plugin to fiy this? or is it too
> much
> > work and there is a better/quicker workaround?
> It is not posible. Except by contributing the SvgOutputDev to poppler...
> but
> that would only move the problem.
>
> What about linking to lcms in filters/karbon/pdf/CMakeLists.txt ?
>
> --
> Cyrille Berger Skott
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Linking error on windows

[Pierre Stirnweiss]

On Wed, Feb 23, 2011 at 10:08 PM, Pierre Stirnweiss <
pstirnwe...@googlemail.com> wrote:

>
>
> On Wed, Feb 23, 2011 at 8:45 PM, Cyrille Berger Skott  > wrote:
>
>> On Wednesday 23 February 2011, Pierre Stirnweiss wrote:
>> >
>> http://winkde.org/pub/kde/ports/win32/releases/nightly/20110222/logs/log-ms
>> > vc2010-testing_calligra.txt
>> >
>> > There is a linking error happening involving poppler and lcms, when
>> linking
>> > karbonPdfImport.
>> > After talking on the kde-win channel, the conclusion is that we
>> shouldn't
>> > use poppler directly, but the c++ backend.
>> >
>> > Is it possible for whoever wrote the plugin to fiy this? or is it too
>> much
>> > work and there is a better/quicker workaround?
>> It is not posible. Except by contributing the SvgOutputDev to poppler...
>> but
>> that would only move the problem.
>>
>> What about linking to lcms in filters/karbon/pdf/CMakeLists.txt ?
>>
>> I'll try. However, I'll have to commit before being sure it solves the
problem, because for some reason, poppler is not detected on my system, and
the filter is not built.
I'll do this this evening. However, if somebody can do it before, all the
better.

Pierre


> --
>> Cyrille Berger Skott
>> ___
>> calligra-devel mailing list
>> calligra-devel@kde.org
>> https://mail.kde.org/mailman/listinfo/calligra-devel
>>
>
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Linking error on windows

[Pierre Stirnweiss]

>
>
>
> That said, since it is a windows only problem, and it might be difficult on
> linux to know if poppler is build with lcms1 or lcms2 (and it works fine on
> linux anyway...), I suggest to do the explicit linking only for windows.
>

Is it easier on windows to know if poppler is built with lcms1 or lcms2? Or
doesn't it matter, if we link to an lcms different from the one poppler
would have been built with?
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

"Post-it" area + notes as a GSOC?

[Pierre Stirnweiss]

Do you think that the following would be a good GSOC subject?

- implement the "post-it" area. inspiration:
http://wiki.services.openoffice.org/wiki/Notes2
- implement the notes/change tracking info as "post-tis"

The post-it area might actually need to also refactor the KWCanvas somehow,
because the pages are actually "simulated".

Also, is there somewhere on KDE wiki a summary of what it takes/involves to
be a mentor?

PierreSt
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: "Post-it" area + notes as a GSOC?

[Pierre Stirnweiss]

>
> That was Zaebos. He put his code up in git repo, I've got a copy of that.
> He had some big problems actually synching the notes and the text correctly
> and I couldn't figure it out either.
> https://mail.kde.org/mailman/listinfo/calligra-devel
>

Yes, we discussed together at the time. This is the part which might require
some refactoring in the KWCanvas, if we want this functionnality to be Words
only. If the solution is to be available to other apps, it might touch more
central areas and mechanisms of our canvasControler/canvasBase classes.

Pierre
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: "Post-it" area + notes as a GSOC?

[Pierre Stirnweiss]

Sure, they are overlapping nearly one to one (I should have read better the
already proposed ideas). Co-mentoring would suit me fine, because I am not
sure I would have the time to actually handle a mentoring on my own
(especially in summer). Plus I have never mentored a GSOC student before.

Pierre

On Sat, Feb 26, 2011 at 9:52 PM, Sebastian Sauer  wrote:

> On Saturday 26 February 2011 12:38:40 Pierre Stirnweiss wrote:
> > Do you think that the following would be a good GSOC subject?
> >
> > - implement the "post-it" area. inspiration:
> > http://wiki.services.openoffice.org/wiki/Notes2
> > - implement the notes/change tracking info as "post-tis"
> >
> > The post-it area might actually need to also refactor the KWCanvas
> somehow,
> > because the pages are actually "simulated".
> >
> > Also, is there somewhere on KDE wiki a summary of what it takes/involves
> to
> > be a mentor?
>
> Probably similar to my proposal at
> http://community.kde.org/GSoC/2011/Ideas#Calligra_Words
>
> 
> Project: Implement notes-support
>
> Brief explanation: Implement and extend the notes-support in Calligra Words
> to
> view+add+edit+delete+load+save notes/comments/annotations in Calligra
> Words.
>
> See also bugs 260138 and 260184 and 260102 and 260127.
> 
>
> we could merge the ideas. I can co-mentor if you like :)
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: GSoC 2011

[Pierre Stirnweiss]

Just something to keep in mind:
on windows MSVC, libpoppler is a static library ("because poppler does not
have import/export thing for the core(private) api" dixit pinotree).
Libpoppler is not meant to be used directly. For the karbon pdf filter this
is however what we do. This means that:
-either we disable the filter on windows MSVC
-or we link the filter to every library libpoppler was linked to. these
should be exactly the same ones. that solution is not very practical to
implement.

So if during the course of refactoring, this could be avoided/fixed, all the
better.

Pierre


On Sun, Mar 20, 2011 at 8:10 AM, Jain Basil Aliyas wrote:

> Hello,
>
> I am Jain Basil Aliyas, a computer science engineering student from India.
> I am interested in working on the idea* Import/Export to/from PDF* in
> Calligra KWords. (
> http://community.kde.org/GSoC/2011/Ideas#Project:_PDF-Import_and.2For_PDF-Export
> )
>
> I'd like to share my contributions in free software development; I am one
> among the core development team of Scribus, the open source DTP software,
> and I participated in Google Summer of Code 2010 with Pardus Project. In
> GSoC 2011, I developed a* snapshot and monitoring tool for KDE4 settings*with 
> GitPython as backend.
>
> In scribus, I've developed import filters for quark xpress xtg file, and
> adobe indesign idml package (these are available in scribus 1.5 svn ).
>
> I've my calligra build system ready, and am trying to draft a proposal for
> this project. I'd like to get suggestions from Calligra Developers so that I
> can make this work more exciting.
>
> Greetings!
>
> --
> *Jain Basil Aliyas*
> **
> *
> *
> Scribus Developer, Google Summer of Code 2010 Participant.
> http://blog.jainbasil.net
>
>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: PDF-Import and/or PDF-Export

[Pierre Stirnweiss]

cf my remark on the GSOC2011 thread about libpoppler on windows MSVC.

Pierre


On Sun, Mar 20, 2011 at 9:06 AM, Boudewijn Rempt  wrote:

> On Saturday 19 March 2011 Mar, Diego Turcios wrote:
> > Hi I was looking at the  KDE Wiki, and I have interest in the PDF-Import
> > and/or PDF-Export project.
> > I have some experience in QT c++. The project sounds interesting, I will
> > like to know am little more about this project.
>
> I'm not totally sure which wiki page you were looking at :-).  I guess
> http://community.kde.org/GSoC/2011/Ideas#Project:_PDF-Import_and.2For_PDF-Export,
> right?
>
> Sebastian Sauer is on holiday right now, but the description has most of
> the basics. You need to investigate the poppler library to start with. The
> idea is to be able to load PDF documents as editable text. Years ago, KWord
> had this ability through using xpdf directly (
> http://websvn.kde.org/branches/koffice/1.6/koffice/filters/kword/pdf/).
> However, xpdf causes a steady stream of security issues, so it's necesary to
> use a real library for that, poppler. I'm not sure myself how I would go
> about it, but I would start browsing the old code and the poppler api
> documentation (http://people.freedesktop.org/~aacid/docs/qt4/). Focus on
> the import part first: right now our pdf export is not great, but it works.
>
> --
> Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: [calligra] kplato/libs/kernel/tests: Add unit tests for kptcommand, calendar commands.

[Pierre Stirnweiss]

Actually it does not seem so, and it compiles fine here (on windows).

I don't really understand what the problem is here.

Pierre

On Sun, Mar 27, 2011 at 6:36 PM, Cyrille Berger Skott
wrote:

> Hi,
>
> On Saturday 26 March 2011, Pierre Stirnweiss wrote:
> > Git commit 1e1c11fdd8ced4f2f4b3631c8a929452ccd2c096 by Pierre Stirnweiss.
> > Committed on 18/03/2011 at 22:23.
> > Pushed by pstirnweiss into branch 'master'.
> >
> > Add unit tests for kptcommand, calendar commands.
>
> This commit breaks compilation:
> http://my.cdash.org/viewBuildError.php?buildid=171626
>
> I guess you might have forgotten to commit somethings ?
>
> --
> Cyrille Berger Skott
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: #warning for msvc

[Pierre Stirnweiss]

This is what I have used to fix all the #warning I encountered. Didn't
realise it was actually kde defined. Apparently it is defined in
kdewin_export.h.

On Wed, Apr 6, 2011 at 9:20 PM, Jaroslaw Staniek  wrote:

> Just a note, for handy WARNING macro please look at
> kexi/kexidb/kexidb_global.h (#warning is a GNU extension).
>
> Yes, could be moved to a shared place for Calligra. Or is it already
> somewhere defined by kde-windows?
>
> The usage is not easy though:
> #ifdef __GNUC__
> #warning TODO  foo
> #else
> #pragma WARNING(foo)
> #endif
>
> (note: no need for " " anywhere)
>
> PS: If someone has time, I suppose we may have a git pre/post commit
> hook fixing the warnings and use that at global level in KDE.
>
> --
> regards / pozdrawiam, Jaroslaw Staniek
>  http://www.linkedin.com/in/jstaniek
>  Kexi & Calligra (kexi-project.org, identi.ca/kexi, calligra-suite.org)
>  KDE Software Development Platform on MS Windows (windows.kde.org)
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Google Summer of Code Projects

[Pierre Stirnweiss]

> > I've worked a lot with C/C++ and Java and have dabbled in Qt, but I've
> done
> > GUI design with Java Swing. The project that really interested me was
> > Implementing notes-support because I use notes/comments a lot in other
> > software that I use and think that it is a project within my experience
> > level to make a difference on.
>
> The notes project is indeed plenty interesting. And we would love to see
> you start hacking on it. But it is _really_ late to start writing a proposal
> and work together with us to refine it to something that stands a chance in
> the competition with other projects. It's not too late to do the same for
> the Season of KDE project, or to just get started. We help everyone, whether
> they are gsoc students or not, just join us on #calligra and we can get you
> started.
>
>
For having worked a bit on it last year, I can tell you that there currently
are some hindrances in the relationship between KoCanvasControler/KWCanvas.
It mainly concerns the pages. There would be ways to get around these, but
at the expense of making it a Words only feature. Furthermore, this area is
being/will very soon be redesigned by Sebastian/Casper.
This is indeed a very interesting project. A very important one too, because
I'd need this for the review tool / change tracking notes.

Pierre
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: The snapshot and the new text layout code.

[Pierre Stirnweiss]

I also agree. If it really is a matter of days rather than weeks. It really
would be a shame to miss one of the biggest and most noticeable change in
words. Not to mention missing the whole application, which would in my
opinion be a big problem PR wise.

Pierre

On Thu, Apr 28, 2011 at 11:38 AM, Elvis Stansvik  wrote:

> Hi,
>
> 2011/4/28 Inge Wallin :
> > Today is officially the tagging for 2.4 or 3.0 snapshot 1.  And I hear
> people
> > expressing the opinion that the new text layout code should not be merged
> > before the snapshot. This worries me.
> >
> > We do the snapshots for two reasons:
> >
> > 1. To get feedback on what we have now.
> >
> > 2. To show some activity and let people know that the project is very
> active.
> >
> > I would say that the most important development that we have going right
> now
> > is the new text layout engine. It is crucially important for both Words
> and
> > Stage.  Casper says it is ready, there has been a full-time tester
> (Swathi)
> > testing it for over a week and she says that it is better than the old
> code.
> >
> > Yet, if we continue on the set track, the new layout code will not be
> part of
> > the snapshot.  In fact, Casper says that if this happens he doesn't want
> Words
> > to be part of the snapshot at all. This means that reason 1 will be
> completely
> > failed.
> >
> > So I suggest that we delay the tagging of the snapshot a few days and let
> > Casper merge the branch. It only touches two parts of the engine: kotext
> and
> > the text shape.  In addition to that, there are changes in Words and
> Stage.
> > Things may be a little bit unstable, but since Swathi says it is already
> > better than before, I think we can live with that.
> >
> > Most importantly, if we *don't* merge it, we will not have words in the
> > snapshot, which to me is failure, *or* we will have lots of feedback on
> things
> > that will be thrown away, maybe even in the time between the tagging and
> the
> > actual release day.
> >
> > So please, let's agree to merge the text layout code, and if that means
> > delaying the snapshot a couple of days, then it's a very cheap price to
> pay.
>
> Although I'm not involved in any of this, I must say I wholeheartedly
> agree. And saying "but there will be a new snapshot in just a month
> from which we'll get feedback" does not address the issue you bring up
> Inge; you'll be getting feedback on essentially dumped code. Also, a
> month is actually quite a long time at the speed with which things
> have been moving lately (yes, my units of measurement are mixed up
> here, but you get what I mean, and please don't bring up relativity ;)
>
> I'd also say that since this is the very first snapshot, a small slip
> in the schedule is arguably more OK now than it would be for any of
> the subsequent snapshots.
>
> Anyway, it's up to you guys. Just my 2 öre.
>
> Elvis
>
> >
> >-Inge
> > ___
> > calligra-devel mailing list
> > calligra-devel@kde.org
> > https://mail.kde.org/mailman/listinfo/calligra-devel
> >
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Text layout has landed

[Pierre Stirnweiss]

>
> I'm sorry, but I actually see no other way than what I did, but I do
> apologize
> for not having waited longer.
>
>
Although I think that the new text layout should be included in the
snapshot, I do agree with Thorsten here that the branch should have got a
better review process.
Basically saying, sorry the branch was too big and a review was not
workable, so the best thing is just to push it to trunk and fix stuff
afterwards in trunk is a complete U-turn to the agreed work-flow of having
an always releasable trunk, with features developed in branches which are
merged once deemed releasable.
Making a branch and pushing it so _it can have a good test in trunk so we
fix the problem in trunk_ is no different than the previous svn work-flow:
_I develop something locally and push it to trunk when I think it is good
enough_. The difference of the branch being public vs local development is
private is actually very minimal. How many public branches have everyone
actually compiled and really tested (aside from one's own)?

That episode also undermines our dire need to finish our set up with
automatic testing, and our "staging trunk" thingy.

Pierre
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: The state of Calligra Words (a call for testing)

[Pierre Stirnweiss]

Well, the style selection widget is still work in progress. The reason why
it is not displaying the preview is still eluding me. It was before the
re-factoring of the layout, but I don't have nailed down where exactly the
problem lies. I'll work more on it this evening. However, I don't know if it
really is a show stopper.

Pierre

On Wed, May 11, 2011 at 2:20 PM, Cyrille Berger Skott
wrote:

> Hi,
>
> Is words in order for a snapshot tag tomorrow ?
>
> --
> Cyrille Berger Skott
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: test server is back, now with calligra

[Pierre Stirnweiss]

Also that the subject of test server is on again. Is a windows test setup
still planned? If there is need for help, please tell me what I can do. I am
still compiling the whole calligra and fixing compilation errors when I
encounter any. However it is consuming a large part of my coding time.

Pierre


On Wed, May 11, 2011 at 3:29 PM, Uzak Matus  wrote:

> Hi Jos,
>
> there is a number of crashes reported which I can't reproduce.  Those might
> be 64 bit OS specific.  Can you please send a few OS details.
>
> br,
>
> -matus
>
> --
> Matus Uzak
> Software Designer
> Ixonos Slovakia s.r.o.
> Sturova 27, 040 01 Kosice, Slovakia
> mobile 0421 918 718 958
> email: matus.u...@ixonos.com
> http://www.ixonos.com
>
> 
> From: Jos van den Oever [j...@vandenoever.info]
> Sent: Tuesday, May 10, 2011 10:18 AM
> To: calligra-devel@kde.org
> Subject: Re: test server is back, now with calligra
>
> On Monday, May 09, 2011 15:34:04 PM Jos van den Oever wrote:
> > The test server is up again at http://158.36.191.251:8080/
> > Press "Login as a Guest User" at the bottom of the login screen.
> >
> > As before you can follow the progress of Calligra in steps of a few
> > commits.
> >
> > In Calligra/default you can see:
> >   -- if Calligra compiles
> >   -- how many tests are failing
> >   -- how long each test took and if that's slower or faster then before
> >
> > In Calligra/kofficetests you can see:
> >   -- what files are causing crashes on a load/save cycle
> >   -- how long these cycles take in the current and previous snapshot
> >   -- see backtraces for crashes
>
> I forgot an important feature: ODF 1.2 validation. After roundtripping,
> saved
> documents are validated. A large group of reported errors is formed by
> this.
> For example, roundtripping
> kofficetests/interoperability/kword/oowriter/mumi0.odt with the command
>  words --roundtrip-filename out.odt mumi0.odt
> gives a file out.odt with a content.xml that has many of the same error (as
> repoted by
>  calligra/tools/scripts/validateODF.py
> /tmp/tmp9D5U4N_content.xml:2140:86: error: bad value for attribute "letter-
> spacing" from namespace "urn:oasis:names:tc:opendocument:xmlns:xsl-fo-
> compatible:1.0"
> The cause is simple. Here is one occurrance of the problem:
>   weight="bold" fo:letter-spacing="97"/>
> The attribute fo:letter-spacing has no unit! In the input file the spacing
> was
> specified in inches, e.g. fo:letter-spacing="-0.0041in". In Qt letter
> spacing
> can be done in percent or in pixels. In Calligra, using pixels makes no
> sense,
> percentages are being used. ODF only allows absolute length, so the
> relative
> value has to be converted. (It would be nice of Calligra kept track of the
> original absolute distance, but making it write valid ODF at all is already
> an
> improvement.)
> The fix for this problems was done in less than an hour. The problem count
> should go down shortly, when the committed patch has made it through the
> test
> server. You see that getting the problem count down, can be easy.
>
> > http://158.36.191.251:8080/
> > Press "Login as a Guest User" at the bottom of the login screen.
>
> Cheers,
> Jos
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Calligra on windows

[Pierre Stirnweiss]

On Wed, May 11, 2011 at 5:08 PM, Gopalakrishna Bhat
wrote:

> Hi,
>
> The previous post in the mailing list made me ask this question, is
> Calligra installable on Windows.
>
> On looking through the archive I found out that Pierre Stirnweiss was able
> to get it working.
>

That's me. I have indeed Calligra compiled and running on windows. I am
actually developping Calligra on windows.
As for the windows installer stuff, there are a couple of things which need
to be smoothed out.
The first is that the poppler emerge script needs to be modified not to
compile XPDF support. I haven't managed to commit to the kde windows svn
repository.
Another thing which is missing is an emerge script for the dependencies.

A good start is actually on the kde on windows wiki.

Pierre

If there is still some work on that I would like to help.
>
> --
> My blog http://gkbhat.blogspot.com
>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

styles docker

[Pierre Stirnweiss]

i am trying to debug the styles docker in words. when clicked it should
display a list of available styles, written with the corresponding character
style. This preview is actually a pixmap generated as follow: a text
document is used to apply the character style on the name of the style. This
document is laid out (using the calligra layout engine). then the text
document is painted on a pixmap. This pixmap is returned to the ListView (as
decoration role). Before the new layout engine, this was working fine. Now
it is not.
I am trying to pinpoint where exacltly the problem lies. My question is as
follow: is there a way to save or display this pixmap (in the sense of
kDebug() << variable; allows you to look at values,...) so i can look into
the generated pixmap?

Pierre
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Windows compilation error

[Pierre Stirnweiss]

While compiling on windows, i get the following error:


[  9%] Building CXX object
libs/main/CMakeFiles/komain.dir/KoRecentDocumentsPane.obj
KoRecentDocumentsPane.cpp
C:\Users\pierre\shared\Hacking\calligra\libs\main\KoRecentDocumentsPane.cpp(125)
: error C2665: 'KIO::filePreview' : none of the 2 overloads could convert
all the argument types
c:\kde\include\kio/previewjob.h(165): could be 'KIO::PreviewJob
*KIO::filePreview(const KFileItemList &,int,int,int,int,bool,bool,const
QStringList *)'
c:\kde\include\kio/previewjob.h(187): or   'KIO::PreviewJob
*KIO::filePreview(const KUrl::List &,int,int,int,int,bool,bool,const
QStringList *)'
while trying to match the argument list '(KFileItemList, QSize)'
NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~1.0\VC\bin\cl.exe' : return
code
'0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio
10.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio
10.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.


I won't have much time to fix this before mid next week. And i'd like to
nail down the styles widget stuff in the little time i'll have then. So if
the corresponding author could look into this one, i'd be much gratefull.

Pierre
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Windows compilation error

[Pierre Stirnweiss]

The Calligra update is pretty recent. The kdelibs version is on the other
hand pretty old. I'll try to check this evening if i don't come back too
late from saxophone rehearsal.

Pierre


On Mon, May 23, 2011 at 9:31 AM, Marijn Kruisselbrink <
mkruisselbr...@kde.org> wrote:

> When did you last update calligra? And what kdelibs version are you
> building
> against? There should be a #if in the code that only uses the
> (KFileItemList,
> QSize) arguments for kdelibs versions where that method exist, but somehow
> that check seems to be failing for you?
>
> Marijn
>
> On Sunday, May 22, 2011 01:00:28 pm Pierre Stirnweiss wrote:
> > While compiling on windows, i get the following error:
> >
> >
> > [  9%] Building CXX object
> > libs/main/CMakeFiles/komain.dir/KoRecentDocumentsPane.obj
> > KoRecentDocumentsPane.cpp
> >
> C:\Users\pierre\shared\Hacking\calligra\libs\main\KoRecentDocumentsPane.cpp
> > (125) : error C2665: 'KIO::filePreview' : none of the 2 overloads could
> > convert all the argument types c:\kde\include\kio/previewjob.h(165):
> could
> > be 'KIO::PreviewJob *KIO::filePreview(const KFileItemList
> > &,int,int,int,int,bool,bool,const QStringList *)'
> > c:\kde\include\kio/previewjob.h(187): or   'KIO::PreviewJob
> > *KIO::filePreview(const KUrl::List &,int,int,int,int,bool,bool,const
> > QStringList *)' while trying to match the argument list '(KFileItemList,
> > QSize)' NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~1.0\VC\bin\cl.exe'
> > : return code '0x2'
> > Stop.
> > NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio
> > 10.0\VC\BIN\nmake.exe"' : return code '0x2' Stop.
> > NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio
> > 10.0\VC\BIN\nmake.exe"' : return code '0x2' Stop.
> >
> >
> > I won't have much time to fix this before mid next week. And i'd like to
> > nail down the styles widget stuff in the little time i'll have then. So
> if
> > the corresponding author could look into this one, i'd be much gratefull.
> >
> > Pierre
>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

krita compile fail on windows

[Pierre Stirnweiss]

[ 47%] Building CXX object
krita/ui/CMakeFiles/kritaui.dir/dialogs/kis_dlg_preferences.obj
cd C:\Users\pierre\shared\Hacking\calligra_build\krita\ui
C:\PROGRA~1\MICROS~1.0\VC\bin\cl.exe
@C:\Users\pierre\AppData\Local\Temp\nmC757.tmp
kis_dlg_preferences.cc
c:\users\pierre\shared\hacking\calligra\libs\odf\KoXmlReader.h(48) : warning
C4099: 'QPair' : type name first seen using 'struct' now seen using 'class'
C:\kde\include\QtCore\qpair.h(55) : see declaration of 'QPair'
C:\Users\pierre\shared\Hacking\calligra\interfaces\KoGenericRegistry.h(75) :
error C2039: 'id' : is not a member of 'KisAbstractPreferenceSetFactory'

C:\Users\pierre\shared\Hacking\calligra\krita\ui\kis_preference_set_registry.h(52)
: see declaration of 'KisAbstractPreferenceSetFactory'

C:\Users\pierre\shared\Hacking\calligra\interfaces\KoGenericRegistry.h(73) :
while compiling class template member function 'void
KoGenericRegistry::add(T)'
with
[
T=KisAbstractPreferenceSetFactory *
]

C:\Users\pierre\shared\Hacking\calligra\krita\ui\kis_preference_set_registry.h(63)
: see reference to class template instantiation 'KoGenericRegistry' being
compiled
with
[
T=KisAbstractPreferenceSetFactory *
]
NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~1.0\VC\bin\cl.exe' : return
code
'0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio
10.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio
10.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: arbitration decision

[Pierre Stirnweiss]

i'd like to see it please.

Pierre

On Mon, May 30, 2011 at 10:01 AM, Boudewijn Rempt  wrote:

> Hi,
>
> The arbitrator has prepared a final draft of his decision. It is not yet
> public. I already mailed it to a number of people who I knew were
> interested. If you have not had this mail, please mail me privately and I
> will send you the text.
> --
> Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: KDE git workflow

[Pierre Stirnweiss]

Well, sounds really really familiar. They could have attended our sprint and
spared the discussion time, couldn't they? ;)
IIRC this very workflow was already discussed in Oslo.


PierreSt




On Wed, Jun 8, 2011 at 7:38 PM, Boudewijn Rempt  wrote:

> fyi
> --
> Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org
>
>
> -- Forwarded message --
> From: Cornelius Schumacher 
> To: kde-core-de...@kde.org
> Date: Wed, 8 Jun 2011 19:03:01 +0200
> Subject: KDE git workflow
> As you already know, we have discussed the git workflow for KDE at the
> Platform 11 sprint, and have come up with a recommendation. Please find the
> full text here: http://community.kde.org/KDE_Core/Platform_11/Git_Workflow
>
> The core ideas are that:
> * master is always kept in a stable state that is ready to be used for
> starting a release
> * development is happening in feature branches
> * for larger projects integration branches will be used for further
> stabilization and wider testing
> * changes going into master are going through a review process
> * releases are coming from release branches
>
> Please read the full text before commenting to get all details.
>
> This workflow will be adopted by some core modules, and is recommended for
> all
> KDE modules. It's flexible enough to be used by modules of different sizes
> and
> different requirements in terms of stability, so we hope it to be a
> reasonable
> fit for as many people as possible. Obviously we'll have to see how well it
> works and adapt it, if necessary, but it should be a good start.
>
> --
> Cornelius Schumacher 
>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: KDE git workflow

[Pierre Stirnweiss]

On Wed, Jun 8, 2011 at 9:30 PM, Aaron J. Seigo  wrote:

> On Wednesday, June 8, 2011 21:18:49 Pierre Stirnweiss wrote:
> > Well, sounds really really familiar. They could have attended our sprint
> and
> > spared the discussion time, couldn't they? ;)
>
> if someone had documented it and shared it on kde-core-devel and proposed
> it
> for wider adoption, then perhaps yes.
>
>
well, it was more meant as a jest than anything, especially given the fact
that we actually still not manage to apply this to ourselves really.
that is what happens when you allow french people in ;)



> is it safe to state, then, that this is the workflow that calligra is using
> today? (sorry, i just follow discussions here and build it every so often;
> i'm
> not involved in actual day-to-day devel :)
>
>
safety is all relative, isn't it? personnaly i wouldn't call it safe


Pierre
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: KDE git workflow

[Pierre Stirnweiss]

On Thu, Jun 9, 2011 at 1:13 PM, Cyrille Berger  wrote:

> On Wed, Jun 08, 2011 at 11:01:13PM +0200, Jos van den Oever wrote:
> > On Wednesday, June 08, 2011 21:18:49 PM Pierre Stirnweiss wrote:
> > > Well, sounds really really familiar. They could have attended our
> sprint
> > > and spared the discussion time, couldn't they? ;)
> > > IIRC this very workflow was already discussed in Oslo.
> >
> > I'll believe it when I see 0 failing tests and all document
> round-tripping
> > without errors. ;-)
> >
> > Seriously, I think we can get there if we set up a system where a patch
> can go
> We have discussed this at the last sprint in Berlin, the idea is that
> developers commit in master, and the buildbot validate the commits, and if
> the tests are passing they are migrated to a "master-validated" branch. And
> if master does not pass the test suite, the migration is blocked until the
> problem is solved, either by a fix, or by reverting the bad commit.
>
> And I am actually (slowly) working on the setup right now.
>

Any help needed in setting up a windows buildbot (if at all possible)?

Pierre
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Using ODF Relax NG schema to generate easier XML writing classes

[Pierre Stirnweiss]

I like the idea.
On the headerWriter example you give, the end-element is written when the
Writer gets out of scope. We'd need to verify that all our start/end element
couples are within the same scope however.

Pierre


On Fri, Jun 10, 2011 at 8:22 AM, Jos van den Oever <
jos.van.den.oe...@kogmbh.com> wrote:

> Here is an idea to improve code quality in Calligra.
>
> Currently, we use KoXmlWriter to write ODF XML. For this, functions like
> startElement, endElement, addAttribute are used.
>
> By using the Relax NG schema, we could generate a wrapper around this class
> which would give us functions like
>
>  TextPWriter TextContentWriter::startTextP();
>  void TextHWriter::writeTextOutlineLevel(quint32 level);
>
> that would wrap around KoXmlWriter or QXmlStreamWriter:
>
> class TextHWriter {
> friend class TextContentWriter;
> private:
>KoXmlWriter* const xml;
> protected:
>TextHWriter(KoXmlWriter* xml_) :xml(xml_) {
>xml->startElement("text:h");
>}
> public:
>~TextHWriter() { xml->endElement(); }
>TextSpan startTextSpan() { return TextSpanWriter(xml); }
>void writeTextOutlineLevel(quint32 level) {
>xml->setAttribute("text:outline-level", level);
>}
> };
>
> These writer classes would all go in header files only and should not
> affect the
> compiled form; the functions are so simple and that they should all be
> compiled away.
> The classes would provide compile time checking of the code that writes
> XML.
> It would be easier for people to write code to write XML and it would be
> harder to make mistakes. When writing serialization code, one would not
> need
> to look up the what attributes can go in which element and what type they
> have; your development enviroment would tell you with autocompletion.
>
> Can you think of a reason why this would not work?
>
> Cheers,
> Jos
>
> --
> Jos van den Oever, software architect
> +49 391 25 19 15 53
> 074 3491911
> http://kogmbh.com/legal/
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Creating a branch

[Pierre Stirnweiss]

Have you added the folder in the calligra/filters/words CMakeList.txt file?

Pierre

On Tue, Jun 21, 2011 at 5:06 PM, Diego Turcios wrote:

> Hi guys I am going to begin working on the pdf import/export filter.
> The first  think I should do its to create my branch. (I did it )
> Later I created my PDF folder, in the /calligra/filters/words path
> I copy the cmakelist.txt, ASCIIImport.h+cpp to the PDF folder (Sebastian
> told me to do this)
>
> Now the problem is the fallowing when I try to visualize the pdf folder in
> the qt creator, it doesn't appears. It also appears dissable the option of
> add existing folder, so what should I do for solving this small problem?
>
> Thanks
> --
> Diego Turcios
> DiegoTc
> Ubuntu User  # 27518
> ---
> Mis Blogs
> http://blog.diegoturcios.net16.net/
> https://wiki.ubuntu.com/DiegoTurcios
> --
> Recuerden Dios siempre esta presente:
> http://sagradocorazondejesus-diegotc.blogspot.com/
>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Proposal: Promote svg support

[Pierre Stirnweiss]

On a general note, I'm pretty much a supporter of the line "we need to keep
KoShape as slim as up to nearly impossible". So anything which on the one
hand is not of a complete universal use and on the other hand could be
implemented outside should in my opinion be left outside.

PierreSt


On Tue, Jun 28, 2011 at 6:00 AM, Thorsten Zachmann wrote:

> On Monday, June 27, 2011 22:07:28 ja...@gmx.net wrote:
> > On Monday 27 June 2011 17:25:37 Thorsten Zachmann wrote:
> > > On Sunday, June 26, 2011 18:25:56 ja...@gmx.net wrote:
> > > > I thought to have a separate lib similar to our odf lib containing
> the
> > > > classes  used for loading/saving svg. One of these classes would be
> an
> > > > interface which shapes can implement to save/load svg data, i.e.
> > > > calling it SvgSerializable.
> > > >
> > > > class SvgSerializable
> > > > {
> > > >
> > > > public:
> > > > virtual bool saveSvg(SvgSavingContext &context) = 0;
> > > > virtual bool loadSvg(SvgLoadingContext &context) = 0;
> > > > // some more required functions
> > > >
> > > > };
> > >
> > > Agreed that having a libs like the odf lib makes sense and that
> contains
> > > the stuff like SvgLoadingContext  However I'm not sure if we need a
> > > class SvgSerializable. Why not just put that into KoShape directly?
> >
> > There is no reason other than I was a little hesistant to force svg
> > loading/saving support on each shape. Instead I thought making it
> > optionally. But if there is consent about putting it directly into
> > KoShape, I have no problem with that.
>
> Looks like I did not understand how you want to use the above. For me it
> looked like KoShape would need to inherit SvgSerializable to be able to
> implement the functions. Seems I was wrong. Maybe you can explain how that
> is
> should be done.
>
> Thorsten
>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: [calligra] plugins/textshape/dialogs: Don't crash if there is no style set.

[Pierre Stirnweiss]

Just for information so there is no duplication of efforts: I am hitting a
number of assert linked to the style previewing. I am currently
investigating them (they are linked apparently to lists in paragraph
styles).

PierreSt

On Tue, Jun 28, 2011 at 10:05 AM, Boudewijn Rempt  wrote:

> On Tuesday 28 June 2011 Jun, Thorsten Zachmann wrote:
> > Git commit b82bffce9a36724fce869bcaf78ec112ad5200de by Thorsten Zachmann.
> > Committed on 28/06/2011 at 09:57.
> > Pushed by zachmann into branch 'master'.
> >
> > Don't crash if there is no style set.
> >
> > If you have a text shape with text that has no style id set it crashes as
> soon as you click on it.
> > Maybe we should show the default style when there is no style set.
>
>
> That sounds like a good idea to me.
> --
> Boudewijn Rempt
> http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Questions about Words

[Pierre Stirnweiss]

I have tried at one point to do the same, so I may also be able to help a
bit in this. In between quite a lot has changed in the text layout field, so
I am not sure how actual is my recollection of the code.

PierreSt


On Thu, Jul 7, 2011 at 10:38 PM, Steven Kakoczky
wrote:

> Hi all,
> I'm trying to understand how words is put together so I can add a Notes
> feature to it and was wondering if someone could explain to me what I need
> to know about the way the KWView, KWDocument, KWPage, and KWCanvas, or any
> related objects, work together so I can attach a sidebar to the margin of a
> page and put in a class to manage the rendering and placement of the comment
> balloons.
>
> Thanks for your help,
> Steven
>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Review Request: Move several commands from TextTool to the KoTextEditor interface

[Pierre Stirnweiss]

I thought we had planned to discuss the kotext/textlayout/textshape
architecture at the sprint.

Pierre



On Thu, Sep 22, 2011 at 10:08 PM, C. Boemann  wrote:

>This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/102679/
>
> In general quite nice. A few remarks, and then i just assumed you moved the 
> commands with maybe a little rename but i din't exactly read all of them. 
> Please advice if i need to.
>
>
> For the kotexteditor::paste i think we should irc a bit
>
>
>
> libs/flake/KoShapeController.cpp
>  (Diff
> revision 1)
>
> KUndo2Command* KoShapeController::addShapeDirect(KoShape *shape, 
> KUndo2Command *parent)
>
>   160
>
> KoToolManager::instance()->updateShapeControllerBase(shapeControllerBase, 
> canvas->canvasController());
>
>  158
>
> d->shapeBasedDocument = shapeBasedDocument;
>
>   do we loose funtionality here
>
> i later saw it being done in calligratables but are we sure of the other apps?
>
>
>
> libs/kotext/KoTextEditor.h
>  (Diff
> revision 1)
>
> public slots:
>
>231
>
>  * Insert the selection from the given KoTextEditor
>
>   please improve this description.
>
>
>
> libs/kotext/KoTextEditor.cpp
>  (Diff
> revision 1)
>
> bool KoTextEditor::paste(KoTextEditor *editor,
>
>978
>
> if (!editor->hasComplexSelection()) return;
>
>   so you only want to copy if the source selects part of a table??
>
>
>
> libs/kotext/KoTextEditor.cpp
>  (Diff
> revision 1)
>
> bool KoTextEditor::paste(KoTextEditor *editor,
>
>996
>
> editor->addCommand(new DeleteCommand(DeleteCommand::NextChar, 
> d->document, shapeController));
>
>   editor-> ?? are you sure
>
>
>
> libs/kotext/commands/TextPasteCommand.cpp
>  (Diff
> revision 1)
>
> void TextPasteCommand::redo()
>
>100
>
>   can this be fixed
>
>
>
> plugins/textshape/dialogs/ParagraphSettingsDialog.cpp
>  (Diff
> revision 1)
>
>   32
>
> ParagraphSettingsDialog::ParagraphSettingsDialog(TextTool *tool, QTextCursor 
> *cursor, QWidget* parent)
>
>  32
>
> ParagraphSettingsDialog::ParagraphSettingsDialog(TextTool *tool, QTextCursor 
> *cursor, QWidget* parent)
>
>   do we still need cursor here then?
>
>
> - C.
>
> On September 22nd, 2011, 7:14 p.m., Boudewijn Rempt wrote:
>   Review request for Calligra.
> By Boudewijn Rempt.
>
> *Updated Sept. 22, 2011, 7:14 p.m.*
> Description
>
> KoTextEditor is meant to be the one and only interface we allow to editing a 
> QTextDocument. TextTool breaks this encapsulation in many ways. This patch 
> improves the situation but doesn't solve it completely yet. Several commands 
> have been moved to kotext and encapsulated in KoTextEditor. This simplifies 
> the code in the textshape quite a bit. The other bits will follow later on.
>
> In order to make it possible to test this code, I wanted to be able to create 
> a KoShapeController without a canvas, so KoShapeController was refactored a 
> bit as well. Because KoShapeControllerBase was confusingly named, I renamed 
> that class after irc discussion.
>
>   Testing
>
> manual gui test + ran the unittests. Added more testing.
>
>   Diffs
>
>- braindump/src/SectionContainer.h (ec00b6f)
>- braindump/src/ViewManager.h (bf4e89c)
>- flow/plugins/dockers/stencilboxdocker/StencilShapeFactory.h (dffa96e)
>- flow/plugins/dockers/stencilboxdocker/StencilShapeFactory.cpp
>(318e483)
>- karbon/common/commands/KarbonBooleanCommand.h (9c49a74)
>- karbon/common/commands/KarbonBooleanCommand.cpp (947ba83)
>- karbon/ui/KarbonPart.h (2dc5f85)
>- karbon/ui/dockers/KarbonLayerDocker.h (55ee45d)
>- karbon/ui/dockers/KarbonLayerDocker.cpp (30e1ab2)
>- karbon/ui/dockers/KarbonLayerModel.cpp (f2f)
>- krita/plugins/formats/odg/kis_odg_import.cc (be07b8c)
>- krita/ui/canvas/kis_canvas2.h (cf1d633)
>- krita/ui/canvas/kis_canvas2.cpp (6dc2b95)
>- krita/ui/flake/kis_shape_controller.h (4e0540a)
>- krita/ui/flake/kis_shape_layer.h (2ec5170)
>- krita/ui/flake/kis_shape_layer.cc (8004eae)
>- krita/ui/flake/kis_shape_layer_paste.h (096896f)
>- krita/ui/kis_doc2.h (faa2e1f)
>- krita/ui/kis_doc2.cc (ed11964)
>- libs/flake/CMakeLists.txt (4311bd0)
>- libs/flake/KoCanvasBase.h (5f8f0ab)
>- libs/flake/KoCanvasBase.cpp (2361bc1)
>- libs/flake/KoCanvasController.h (3fc370e)
>- libs/flake/KoDataCenterBase.h (de447fa)
>- libs/flake/KoShape.h (84bdbfc)
>- libs/flake/KoShapeBasedDocumentBase.h (PRE-CREATION)
>- libs/flak

Re: Review Request: Move several commands from TextTool to the KoTextEditor interface

[Pierre Stirnweiss]

I didn't mean to make an assessement on the patch actually. I was answering
to the IRC suggestion actually. I indeed personnaly think that the textshape
is not the place for the commands.
However, we should also try to keep an open mind for the exercise at the
sprint. Otherwise we might format ourselves in merely tweaking the current
broken design of the textshape/kotext relationship.

Pierre (on his way to the Oktoberfest)

On Fri, Sep 23, 2011 at 10:01 AM, C. Boemann  wrote:

> Well yes but i thought we agreed on this. I mean, do you think this is not
> a
> step in the right direction?
>
>
>
> On Friday 23 September 2011 09:56:00 Pierre Stirnweiss wrote:
> > I thought we had planned to discuss the kotext/textlayout/textshape
> > architecture at the sprint.
> >
> > Pierre
> >
> > On Thu, Sep 22, 2011 at 10:08 PM, C. Boemann  wrote:
> > >This is an automatically generated e-mail. To reply, visit:
> > > http://git.reviewboard.kde.org/r/102679/
> > >
> > > In general quite nice. A few remarks, and then i just assumed you moved
> > > the commands with maybe a little rename but i din't exactly read all of
> > > them. Please advice if i need to.
> > >
> > >
> > > For the kotexteditor::paste i think we should irc a bit
> > >
> > >libs/flake/KoShapeController.cpp<
> http://git.reviewboard.kde.org/r/1026
> > >79/diff/1/?file=36769#file36769line160> (Diff
> > >
> > > revision 1)
> > >
> > > KUndo2Command* KoShapeController::addShapeDirect(KoShape *shape,
> > > KUndo2Command *parent)
> > >
> > >   160
> > >
> > >
> KoToolManager::instance()->updateShapeControllerBase(shapeControllerB
> > > ase, canvas->canvasController());
> > >
> > >  158
> > >
> > > d->shapeBasedDocument = shapeBasedDocument;
> > >
> > >   do we loose funtionality here
> > >
> > > i later saw it being done in calligratables but are we sure of the
> other
> > > apps?
> > >
> > >libs/kotext/KoTextEditor.h<
> http://git.reviewboard.kde.org/r/102679/dif
> > >f/1/?file=36803#file36803line231> (Diff
> > >
> > > revision 1)
> > >
> > > public slots:
> > >231
> > >
> > >  * Insert the selection from the given KoTextEditor
> > >
> > >   please improve this description.
> > >
> > >libs/kotext/KoTextEditor.cpp<
> http://git.reviewboard.kde.org/r/102679/d
> > >iff/1/?file=36804#file36804line978> (Diff
> > >
> > > revision 1)
> > >
> > > bool KoTextEditor::paste(KoTextEditor *editor,
> > >
> > >978
> > >
> > > if (!editor->hasComplexSelection()) return;
> > >
> > >   so you only want to copy if the source selects part of a table??
> > >
> > >libs/kotext/KoTextEditor.cpp<
> http://git.reviewboard.kde.org/r/102679/d
> > >iff/1/?file=36804#file36804line996> (Diff
> > >
> > > revision 1)
> > >
> > > bool KoTextEditor::paste(KoTextEditor *editor,
> > >
> > >996
> > >
> > > editor->addCommand(new DeleteCommand(DeleteCommand::NextChar,
> > > d->document, shapeController));
> > >
> > >   editor-> ?? are you sure
> > >
> > >libs/kotext/commands/TextPasteCommand.cpp<
> http://git.reviewboard.kde.o
> > >rg/r/102679/diff/1/?file=36818#file36818line100> (Diff
> > >
> > > revision 1)
> > >
> > > void TextPasteCommand::redo()
> > >
> > >100
> > >
> > >   can this be fixed
> > >
> > >plugins/textshape/dialogs/ParagraphSettingsDialog.cpp<
> http://git.revie
> > >wboard.kde.org/r/102679/diff/1/?file=36854#file36854line33> (Diff
> > >
> > > revision 1)
> > >
> > >   32
> > >
> > > ParagraphSettingsDialog::ParagraphSettingsDialog(TextTool *tool,
> > > QTextCursor *cursor, QWidget* parent)
> > >
> > >  32
> > >
> > > ParagraphSettingsDialog::ParagraphSettingsDialog(TextTool *tool,
> > > QTextCursor *cursor, QWidget* parent)
> > >
> > >   do we still need cursor here then?
> > >
> > > - C.
> > >
> > > On September 22nd, 2011, 7:14 p.m., Boudewijn Rempt wrote:
> > >   Review request for Calligra.
> >

compile error

[Pierre Stirnweiss]

Looks like there is again a export problem in ooxml filter:


Linking CXX shared module ..\..\..\bin\docximport.dll
   Creating library ..\..\..\bin\docximport.lib and object
..\..\..\bin\docximport.exp
DocxXmlDocumentReader.obj : error LNK2019: unresolved external symbol
"__declspec(dllimport) public: class QString __thiscall
MSOOXML::Utils::ParagraphBulletProperties::convertToListProperties(bool)const
" (__imp_?convertToListProperties@ParagraphBulletProperties@Utils@MSOOXML
@@QBE?AVQString@@_N@Z) referenced in function "protected: enum
KoFilter::ConversionStatus __thiscall DocxXmlDocumentReader::read_p(void)"
(?read_p@DocxXmlDocumentReader@@IAE?AW4ConversionStatus@KoFilter@@XZ)
DocxXmlDocumentReader.obj : error LNK2019: unresolved external symbol
"__declspec(dllimport) public: class KoXmlWriter * __thiscall
MSOOXML::Utils::XmlWriteBuffer::releaseWriter(class QString &)"
(__imp_?releaseWriter@XmlWriteBuffer@Utils@MSOOXML@@QAEPAVKoXmlWriter@
@AAVQString@@@Z) referenced in function "protected: enum
KoFilter::ConversionStatus __thiscall DocxXmlDocumentReader::read_tbl(void)"
(?read_tbl@DocxXmlDocumentReader@@IAE?AW4ConversionStatus@KoFilter@@XZ)
DocxXmlDocumentReader.obj : error LNK2019: unresolved external symbol
"__declspec(dllimport) public: void __thiscall
MSOOXML::Utils::ParagraphBulletProperties::setPrefix(class QString const &)"
(__imp_?setPrefix@ParagraphBulletProperties@Utils@MSOOXML@@QAEXABVQString@@@Z)
referenced in function "protected: enum KoFilter::ConversionStatus
__thiscall DocxXmlDocumentReader::read_buAutoNum(void)"
(?read_buAutoNum@DocxXmlDocumentReader@@IAE?AW4ConversionStatus@KoFilter
@@XZ)
DocxImport.obj : error LNK2019: unresolved external symbol
"__declspec(dllimport) protected: virtual void __thiscall
MSOOXML::MsooXmlImport::writeConfigurationSettings(class KoXmlWriter *)const
" (__imp_?writeConfigurationSettings@MsooXmlImport@MSOOXML@
@MBEXPAVKoXmlWriter@@@Z) referenced in function "protected: virtual void
__thiscall DocxImport::writeConfigurationSettings(class KoXmlWriter *)const
" (?writeConfigurationSettings@DocxImport@@MBEXPAVKoXmlWriter@@@Z)
..\..\..\bin\docximport.dll : fatal error LNK1120: 4 unresolved externals
LINK failed. with 1120
command failed with exit code 2
command failed with exit code 2
command failed with exit code 2
QProcess: Destroyed while process is still running.
command failed with exit code 2
command failed with exit code 2
command failed with exit code 2

PierreSt
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: compile error

[Pierre Stirnweiss]

Ok,I'll have a closer look at it then.

PierreSt


On Mon, Oct 3, 2011 at 11:48 AM, Uzak Matus  wrote:

> Hi,
>
> I don't see a reason for those linking problems (docx->libmsooxml) from the
> source code point of view.  There were no linking related changes for a few
> months. It would be great if some Windows guy could check that.
>
> -matus
>
> --
> Matus Uzak
> Software Designer
> Ixonos Slovakia s.r.o.
> Sturova 27, 040 01 Kosice, Slovakia
> mobile 0421 918 718 958
> email: matus.u...@ixonos.com
> http://www.ixonos.com
>
> 
> From: calligra-devel-boun...@kde.org [calligra-devel-boun...@kde.org] on
> behalf of Boudewijn Rempt [b...@valdyas.org]
> Sent: Monday, October 03, 2011 9:13 AM
> To: Calligra Suite developers and users mailing list
> Subject: Re: compile error
>
> On Saturday 01 October 2011 Oct, Pierre Stirnweiss wrote:
> > Looks like there is again a export problem in ooxml filter:
> >
> >
> > Linking CXX shared module ..\..\..\bin\docximport.dll
> >Creating library ..\..\..\bin\docximport.lib and object
> > ..\..\..\bin\docximport.exp
> > DocxXmlDocumentReader.obj : error LNK2019: unresolved external symbol
> > "__declspec(dllimport) public: class QString __thiscall
> >
> MSOOXML::Utils::ParagraphBulletProperties::convertToListProperties(bool)const
> > " (__imp_?convertToListProperties@ParagraphBulletProperties
> @Utils@MSOOXML
> > @@QBE?AVQString@@_N@Z) referenced in function "protected: enum
> > KoFilter::ConversionStatus __thiscall
> DocxXmlDocumentReader::read_p(void)"
> > (?read_p@DocxXmlDocumentReader@@IAE?AW4ConversionStatus@KoFilter@@XZ)
> > DocxXmlDocumentReader.obj : error LNK2019: unresolved external symbol
> > "__declspec(dllimport) public: class KoXmlWriter * __thiscall
> > MSOOXML::Utils::XmlWriteBuffer::releaseWriter(class QString &)"
> > (__imp_?releaseWriter@XmlWriteBuffer@Utils@MSOOXML@@QAEPAVKoXmlWriter@
> > @AAVQString@@@Z) referenced in function "protected: enum
> > KoFilter::ConversionStatus __thiscall
> DocxXmlDocumentReader::read_tbl(void)"
> > (?read_tbl@DocxXmlDocumentReader@@IAE?AW4ConversionStatus@KoFilter@@XZ)
> > DocxXmlDocumentReader.obj : error LNK2019: unresolved external symbol
> > "__declspec(dllimport) public: void __thiscall
> > MSOOXML::Utils::ParagraphBulletProperties::setPrefix(class QString const
> &)"
> > (__imp_?setPrefix@ParagraphBulletProperties@Utils@MSOOXML
> @@QAEXABVQString@@@Z)
> > referenced in function "protected: enum KoFilter::ConversionStatus
> > __thiscall DocxXmlDocumentReader::read_buAutoNum(void)"
> > (?read_buAutoNum@DocxXmlDocumentReader@@IAE?AW4ConversionStatus@KoFilter
> > @@XZ)
> > DocxImport.obj : error LNK2019: unresolved external symbol
> > "__declspec(dllimport) protected: virtual void __thiscall
> > MSOOXML::MsooXmlImport::writeConfigurationSettings(class KoXmlWriter
> *)const
> > " (__imp_?writeConfigurationSettings@MsooXmlImport@MSOOXML@
> > @MBEXPAVKoXmlWriter@@@Z) referenced in function "protected: virtual void
> > __thiscall DocxImport::writeConfigurationSettings(class KoXmlWriter
> *)const
> > " (?writeConfigurationSettings@DocxImport@@MBEXPAVKoXmlWriter@@@Z)
> > ..\..\..\bin\docximport.dll : fatal error LNK1120: 4 unresolved externals
>
> Erm... I've a hard time reading the error messages here, but I'll check
> with Stuart when he's at my place later today.
>
> --
> Boudewijn Rempt
> http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: on Words

[Pierre Stirnweiss]

On Fri, Oct 7, 2011 at 1:39 PM, C. Boemann  wrote:

> Hi fellow Words developers
>
> The sprint is nearing and I think it's time to start thinking about what we
> should do. The following is up for discussion at the sprint but I'd like to
> get a head start:
>
> Mission statement
> 
>

Ahhh, C.Boemann, you definitely know how to speak to the former Quality
Assurance Manager in me!!


> Inspired by Krita we should come up with a mission statement. Here is a
> suggestion:
>
> "Calligra Words is an all purpose word processor useful for writing such
> diverse documents as for example: A simple letter, a university
> dissertation,
> a rule book, school reports and much more.
>
> We will not provide very specialized features if they clutter the user
> interface, but on the other hand should try to be flexible enough that
> people
> can create their own plugins.
>
> As examples we find changetracking a core feature, but a function that
> generates custom documents based on external input is not"
>

I agree with the general scope given. I am not sure we need to give so much
specifics in a mission statement (practical examples do not fit to a mission
statement IMHO).
We ought to make a small session during the sprint about the subject, and
the one below (which is linked). I'll like it, it'll remind me of my former
life ;)
I can take on responsibility for animating this session too if you want.


>
> Road map
> 
> With such a broad mission statement we need to limit ourselves initially.
> Not
> to the point of excluding contributions, but in defining what we, the core
> developers, will focus on.
>
> I suggest that we will target the university student. Meaning we should be
> able to view MS Word documents and be able to create from scratch reports
> and
> dissertations.
>
> The viewer part is not strictly needed but if a user is not able to view
> documents the user will choose another tool for viewing, and thus choosing
> Words for creating documents becomes very unlikely.
>
> For the creation part we need to support creation and editing of tables,
> change tracking, foot notes, endnotes, bibliography, basic page setup,
> images,
> and style management.
>
> We are already pretty far along this road (it's been an unspoken roadmap
> for
> quite a while) I suggest that we just keep on pushing for these features to
> mature and stabalize.
>
> In 8 months we ought to be really strong with these kinds of tasks.
>
> User interface
> --
> At the usability sprint in Berlin two weeks after the first Calligra sprint
> (also in Berlin) Celeste lead a small design process for the overall user
> interface for Words. As with all usability designs it has to undergo
> iterative
> finetuning and experimentation, but I quite like it already.
>
> I've implemented the idea but we need to carry on from there and continue
> improving the user interface.
>
> http://wstaw.org/m/2011/10/04/wordsui.png
>

That is definitely something we need to plan at the sprint. I have made
quite some progress on the style widget (although i have had some IRL
constraints which pulled me a bit away as of late).


>
> kotext, textlayout, textshape, words division of responsibilities
>
> ---
> We should come up with a plan for how we want the code structured in the
> long
> run. We've come a long way already, but we should discuss what further
> things
> we can do.
>

As far as I know there is already a session planned that I'll animate on
this very topic.


>
> KoTextEditor hacking
> ---
> I'd like a hacking session where we start extending the functionality of
> KoTextEditor.
>

This is sort of influenced by the topic above.


>
> Changetracking
> 
> I'd like a brainstorm on how we proceed on change tracking. The current
> state
> leaves much to be desired.
>

For this, i think there are some external constraints that we do not control
entirely. There are some stuff needed internally though that we need to
discuss (like the "post-it notes"/"notes bubbles" stuff).

PierreSt
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: on Words

[Pierre Stirnweiss]

>
> kotext, textlayout, textshape, words division of responsibilities
>> --**--**
>> ---
>> We should come up with a plan for how we want the code structured in the
>> long
>> run. We've come a long way already, but we should discuss what further
>> things
>> we can do.
>>
>
> Long-term I would like to make it easy to extend Calligra Active with
> editing capabilities. That means our libraries and the functionality
> provided by Words can be reused for other UI's like the QML-based
> Active-UI, an alternate desktop-UI (think of a kids interface or an
> interface specialized on other use-cases or an interface for different
> form factors or one for star trek fans or whatever crazy and/or
> innovative things a developer likes to do build up with our
> frameworks).
>
>

>  KoTextEditor hacking
>> ---
>> I'd like a hacking session where we start extending the functionality of
>> KoTextEditor.
>>
>
> What is the goal? I mean what exactly do we like to change/extend
> in what direction? I ask cause that is not clear to me if it comes to
> the concrete code. Maybe it's not defined yet what will be part of
> the sprint-session?
>

The above two points are on the agenda of the sprint in our brainstorm
session about textshape/textlayout/kotext architecture.

>
> I btw will not attend the sprint but I can participate online :)
>
> Arf, it's too bad you can't be here. It would be real good if there could
be a way to have you live at least with sound (both directions), ideally
with video (at least from us to you).

>
>  Changetracking
>> 
>> I'd like a brainstorm on how we proceed on change tracking. The current
>> state
>> leaves much to be desired.
>>
> Identify problems and put them into bugzilla? But yes, that will not
> magically fix them. At least it would be a start and provide more
> details what exactly still leaves much to be desired.
>
> Well, there are bugs/fundamental design restrictions (mostly related to
deleted stuff) and there is the odf1.1/1.2 tiny difference in spec.

PierreSt
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Qt Fragment visibility

[Pierre Stirnweiss]

Hello,

With Qt Project announced and Qt5 coming, I had a thought on our previously
unsuccessfull go at fragment visibility. Now that BIC isn't an issue anymore
and Qt is more opened to change, wouldn't it be a good time to move forward
with QTextFragment visibility? That would allow a lot with the change
tracking.
Ganesh and Girish, you both have looked more into this, do you have insight
on what would be needed, what are the caveats and so on?

PierreSt
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Brainstorming about textshape/textlayout/kotext structure

[Pierre Stirnweiss]

At the sprint, I'll be animating a brainstorming session about the
structure of the text handling in calligra. This is about the structure we
want to have for the current textshape/textlayout/kotext triplet.
So I can organise a bit myself, and also for everyone to have a clear
picture of who is interested/will participate, can the people who want to
attend please make themselves known.
Ideally there should be between 5 and 7 people (excluding myself). We
should have the core words developers for sure. I'd also like to have some
non words consumers of our text API (calligra active comes to my mind as
very relevant). Also, I'd like one or two non user of our API, who still
have some knowledge of it but who can then provide a distanced point of
view.
I hope we can pull Seb in with skype.

Also for organisation of this: will there be an availability of post-its
and A4 paper in quantity? if not, i'd need to find a place where i can buy
this (i don't need the extra weight in the plane).

Pierre
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Review Request: Partly fixed rect position returned to input method through TextTool::InputMethodQuery.

[Pierre Stirnweiss]

IIRC, the spell-checking in words was (is still?) "swallowing" repeated
white spaces.
I don't know if there is a relation or not.

PierreSt


On Wed, Nov 9, 2011 at 9:57 AM, Yue Liu  wrote:

>This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103091/
>   Review request for Calligra and C. Boemann.
> By Yue Liu.
> Description
>
> Partly fixed rect position returned to input method through 
> TextTool::InputMethodQuery. But still some problems.
>
>   Testing
>
> repeat pressing space key does not work, it only work once, strange.
> while pressing a key when im is enabled, caretRect() return position 0 so 
> wrong rect is returned, no clue why it goes that way.
> in words an vertical offset is accumulated through pages.
> works in other apps, krita crashes due to other issues so haven't tested on 
> it.
>
>   Diffs
>
>- libs/flake/KoCanvasController.h (97a3e92)
>- libs/kopageapp/KoPACanvas.cpp (17dec46)
>- plugins/textshape/TextTool.cpp (e699319)
>
> View Diff 
>
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Calligra Words mission statement and roadmap (1st draft)

[Pierre Stirnweiss]

>
> Background: I indeed think that is a rather important feature
> cause it's the only way to get content into a document that
> can be in a centralized way edited/updated. Means you for
> example a document describing the features of Calligra as
> released and then add a user-variable field for the
> version-number (e.g. 2.5 in our case). Then in some months
> if the document is updated to reflect what 2.6 is about
> someone only need to change the content of the
> calligra-version variable and voila. The alternate is to find+
> replace for "2.5" manually which is error-prune.
>

Do you mean that the only difference between a 2.5 and 2.6 release
announcement would be the release number


PierreSt
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: results from

[Pierre Stirnweiss]

> > 1. Abacus  (Condorcet winner: wins contests with all other choices)
>
> Even if it won the competition it is a bad choice as there is already a
> spreadsheet application out there with this name. See
> http://www.freebsdsoftware.org/deskutils/abacus.html
>
> If there is already a spreadsheet application with this name, then this is
an absolute no-go for me. How would we feel if some other project was
developping an application suite with:
YetAnotherApplicationSuite Words: text processor
YAAS Stage: presentation
YAAS Kexi: DB
YAAS Krita: painting


Don't do others what you wouldn't want to be done to you.

My 2 cts,

PierreSt
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: results from

[Pierre Stirnweiss]

Well, if he has updated it to make it compile, it is still in a maintained
state. It shows the developer(s) is(are) still interrested at providing
their software. The very least we have to (and a strong emphasise on the
"have to") is to speak with him(them) before even pushing much further the
possibility of reusing the name.

PierreSt

On Mon, Nov 21, 2011 at 3:05 PM, C. Boemann  wrote:

> On Monday 21 November 2011 14:58:18 you wrote:
> > On 11/21/2011 02:03 PM, C. Boemann wrote:
> > > On Monday 21 November 2011 13:50:38 Pierre Stirnweiss wrote:
> > >>>> 1. Abacus  (Condorcet winner: wins contests with all other choices)
> > >>>
> > >>> Even if it won the competition it is a bad choice as there is
> already a
> > >>> spreadsheet application out there with this name. See
> > >>> http://www.freebsdsoftware.org/deskutils/abacus.html
> > >>>
> > >>> If there is already a spreadsheet application with this name, then
> this
> > >>> is
> > >>
> > >> an absolute no-go for me. How would we feel if some other project was
> > >> developping an application suite with:
> > >> YetAnotherApplicationSuite Words: text processor
> > >> YAAS Stage: presentation
> > >> YAAS Kexi: DB
> > >> YAAS Krita: painting
> > >> 
> > >>
> > >> Don't do others what you wouldn't want to be done to you.
> > >>
> > >> My 2 cts,
> > >>
> > >> PierreSt
> > >
> > > except that that other Abacus has been dead for 14 years or so
> >
> > 1) It's in the openSuse and Ubuntu repos.
> > 2) The last change in the changelog at
> >
> http://pkgs.org/opensuse-11.4/opensuse-contrib-i586/xabacus-7.4.1-1.2.i586
> .
> > rpm.html is from 2008 what makes it 3 years old and not 14.
> > 3) The last change in the changelog at
> > https://launchpad.net/ubuntu/+source/xabacus/+changelog is from 2011
> > what means it's still activly developed.
> >
> > In any case I think that are exactly the reasons why we should have a
> > discussion at the mailinglist before.
> Take a closer look at the changelog at:
> http://www.freebsdsoftware.org/deskutils/abacus.html
>
> It's quite clear it has only been updated to make it compile - no active
> development.
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Review Request: Show recent news in the startup screen

[Pierre Stirnweiss]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103373/#review8847
---


Is it possible to visually separate the pane from the rest of the left pane? It 
looks like it is part of the "custom document" options. Maybe have the pane 
take the whole width of the dialog?

PierreSt

- Pierre Stirnweiss


On Dec. 10, 2011, 10:33 a.m., Boudewijn Rempt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103373/
> ---
> 
> (Updated Dec. 10, 2011, 10:33 a.m.)
> 
> 
> Review request for Calligra.
> 
> 
> Description
> ---
> 
> This patch adds an extra pane to the startup screen that shows the latest 
> news from the calligra.org and krita.org feeds. I'm hesitating to propose 
> this for 2.4, because of the feature freeze... But I still wanted the patch 
> out for comments. It's not polished yet: the html could be better styled, the 
> feed urls taken from a config file and the whole pane could be made optional.
> 
> I use QTextView, not QWebView, because QWebView would drag in all of webkit 
> -- but this means that images aren't supported.
> 
> The code for getting and parsing the feeds comes from Qt Creator, which, 
> ironically, doesn't use it anymore in its latest version. It's LGPL, so that 
> should be fine.
> 
> I think it can help to connect users to our communities by getting our news 
> out to them, but it also has the disadvantage that we'll track every time the 
> open pane is used, which some users might find offensive.
> 
> 
> Diffs
> -
> 
>   libs/main/CMakeLists.txt f669db8 
>   libs/main/KoOpenPane.h 7e7e03d 
>   libs/main/KoOpenPane.cpp 1469131 
>   libs/main/KoOpenPaneBase.ui b824720 
>   libs/main/multifeedrssmodel.h PRE-CREATION 
>   libs/main/multifeedrssmodel.cpp PRE-CREATION 
>   libs/main/networkaccessmanager.h PRE-CREATION 
>   libs/main/networkaccessmanager.cpp PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/103373/diff/diff
> 
> 
> Testing
> ---
> 
> 
> Screenshots
> ---
> 
> news section in open pane
>   http://git.reviewboard.kde.org/r/103373/s/357/
> 
> 
> Thanks,
> 
> Boudewijn Rempt
> 
>

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Help regarding project

[Pierre Stirnweiss]

I'd like to point to this thread regarding kde on windows and poppler (by
the way is there a way in Googlemail to refer to a thread without
copy/paste it?):

From: *Pierre Stirnweiss* 
Date: Sun, Mar 20, 2011 at 9:26 AM
To: Calligra Suite developers and users mailing list 


Just something to keep in mind:
on windows MSVC, libpoppler is a static library ("because poppler does not
have import/export thing for the core(private) api" dixit pinotree).
Libpoppler is not meant to be used directly. For the karbon pdf filter this
is however what we do. This means that:
-either we disable the filter on windows MSVC
-or we link the filter to every library libpoppler was linked to. these
should be exactly the same ones. that solution is not very practical to
implement.

So if during the course of refactoring, this could be avoided/fixed, all
the better.

Pierre




--
From: *Boudewijn Rempt* 
Date: Sun, Mar 20, 2011 at 9:34 AM
To: Calligra Suite developers and users mailing list 


Yes, the words pdf import/export plugin should only use poppler-qt4 which
is a proper shared library. If that doesn't provide enough capabilities, we
will probably need to work together with the poppler guys to improve that
situation :-).

--
Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org

--
<https://mail.kde.org/mailman/listinfo/calligra-devel>
PierreSt





On Tue, Dec 20, 2011 at 8:25 AM, Sebastian Sauer  wrote:

> **
> On 12/20/2011 05:20 AM, Panks wrote:
>
>
>
> On Mon, Dec 19, 2011 at 11:05 AM, Sebastian Sauer  wrote:
>
>   On 12/18/2011 09:33 PM, Panks wrote:
>
> Hello everyone,
> This is Pankaj, I am a second year CS student at Indian Institute of
> Technology, Madras.
> I am interested in contributing to Calligra.
>
>  While going through last year (2011) gsoc idea page I found these ideas
> interesting:
> Project: PDF-Import and/or PDF-Export AND Integrate with Akonadi for
> Calligra Words
> and Project: PSD File import/export Support for Calligra Krita
>
>  I would like to work upon one or more(depends on time) of these ideas.
> But since I am new to KDE, I would like someone to mentor/help me along
> with the project.
> So, can someone please help me along with?
>
>  Credentials: I have knowledge of C++ and Qt.
>
>
>  and hello Pankaj,
>
> I would be willing to mentor you on getting a PDF-Import filter for
> Calligra Words done. I am available in our irc-channel #calligra (on
> irc://irc.freenode.net/calligra - use e.g. the "Konversation" application
> to connect to IRC) as "sebsauer".
>
> First steps would be;
> 1. Build Calligra yourself from the sources. See
> http://community.kde.org/Calligra/Building
> 2. Get a KDE git-account to commit work you do. See
> http://techbase.kde.org/Contribute/Get_a_Contributor_Account
> 3. Get familar with the area where the work will happen. That is the
> filter-framework. We are going to write a filter-plugin that reads
> PDF-files using the poppler library and then generating OpenDocument ODF.
> The filter-framework will take care of all the things around including
> passing the resulting ODT-file on to Calligra Words so it's
> loaded+displayed and the user can edit+save.
>
> For point 3 you may like to have a look at;
> * in our sources at the Text-file importer located at
> calligra/filters/words/ascii/AsciiImport.cpp to have an idea how a filter
> looks like.
> * at the poppler-library. For that install libpoppler (if not already
> installed cause it's a pretty standard-library used by applications like
> Okular to display PDF-files). There look at the header-files to have an
> idea how the API looks like.
>
> Once those initial steps are done we would create an initial filter
> skeleton for the PDF-import filter. We could basically copy the AsciiFilter
> linked above over and 1) change the CMakeLists.txt to link against
> libpoppler and 2) change the desktop file so we take PDF-files as input and
> not text-files like the text-filter does and 3) start to use the
> libpoppler-API to evaluate the PDF-document.
>
> So much for the start :-)
>
>   *
>
> *
> First of all thanks a lot for mentoring this project. :-)
> I am done with step 1 & 2 and in step 3 I am going through the code of
> AsciiImport.cpp and simultaneous giving a look to some implementations of
> poppler.
>
>
> Very great. Lot of thanks for sharing your progress. For poppler you may
> like to have a look at http://people.freedesktop.org/~aacid/docs/qt4/ and
> for implementations using it
> http://mail.kde.org/pipermail/okular-devel/2011-May/009429.html (
> http://quickgit.kde.org/index.php?p=okular.git&a=summary ).
>
> For the initial skeleton what means the very first code to start a
&

Re: Marketing Message for Calligra

[Pierre Stirnweiss]

I have to say I agree with Cyrille here. It always made me laugh when i was
in purchasing, to see our supplier's commercial guy starting his speech
with "we are leader in our market". To which I always answered by asking to
define me precisely what their market was (because their competitor, which
i met 2 days prior said the same).

Also, the web site says beta 5 as title, whereas the text underneath speaks
about the fourth beta being released and a fifth one eventually coming. Did
I miss something?

PierreSt


On Thu, Dec 22, 2011 at 10:51 AM, Cyrille Berger Skott
wrote:

> Hi,
>
> Since your message concerns as much the marketing message as the website, I
> have taken the liberty to split my answer in two.
>
> Here is the part concerning the marketing message.
>
> That is really great and important to start thinking about it. However, I
> would really like us to avoid any kind of disproportionate exagerating
> message
> like "the leader in free mobile office applications". That might be true,
> to
> some extent... First of all calligra does not have a mobile interface,
> being
> available on the N9 under the "Harmattan Office UI" (which is still closed
> source, or did I miss something ?) is more of a victory of the engine, not
> bad
> in itself. Secondly, and probably more important (and very sadly),
> Calligra is
> only available on the N9(xx), which has a market share of a maximum of
> 0.1%.
> It is nowhere to be seen on a widely spread smartphome platform ie Android
> (or
> iPhone or Symbian).
> Once it is available on Android, saying that we are the "the leader in free
> mobile office applications" will have a strong echo compared to being
> available
> on a marginal platform.
>
> In my opinion, being humble is really important, especially if you consider
> who is currently reading our marketting messages right now. We are mostly
> talking to people who are highly informed, most of them know where Calligra
> comes from, and many would labeled it as a project that makes promises but
> do
> not deliver.
>
> So saying something like "Calligra is available on a wide range of
> platform,
> from desktop to mobile." Or a bit more catchy, "Takes Calligra with you
> everywhere you go, from your desktop to your mobile", is really fine. But
> saying we are the leader in a market where we are only available to less
> than
> 0.1% seems too strong.
>
> Other than that, I agree with your list of strong points.
>
> --
> Cyrille Berger Skott
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Marketing Message for Calligra

[Pierre Stirnweiss]

well, doing a /s/market/segment does not improve the speech to me.
I am always really cautious of companies/organisations/individuals who
claim themselves to be the leader of something. Unless backed by other
independent sources, these claims seem a bit presumptuous/pompous to me.




On Thu, Dec 22, 2011 at 11:30 AM, Jaroslaw Staniek  wrote:

> On 22 December 2011 11:13, Pierre Stirnweiss 
> wrote:
> > I have to say I agree with Cyrille here. It always made me laugh when i
> was
> > in purchasing, to see our supplier's commercial guy starting his speech
> with
> > "we are leader in our market". To which I always answered by asking to
> > define me precisely what their market was (because their competitor,
> which i
> > met 2 days prior said the same).
>
> Definitely, I wouldn't like to read things like that on any FOSS web
> page especially on calligra.org.
> No word like market was used there, please see my previous mail. Once
> we are done with the basics, one can expect convincing analysis and
> statistics on the field.
> Let's work on that a bit.
>
> --
> regards / pozdrawiam, Jaroslaw Staniek
>  http://www.linkedin.com/in/jstaniek
>  Kexi & Calligra (kexi-project.org, identi.ca/kexi, calligra-suite.org)
>  KDE Software Development Platform on MS Windows (windows.kde.org)
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Marketing Message for Calligra

[Pierre Stirnweiss]

Perhaps something like:

Calligra Suite applications are built on a very flexible yet powerful
engine. This allows Calligra Suite applications to be developed
specifically for very broad range of devices, in particular to mobile
appliances, as opposed to being merely tweaked and squeezed to fit an
appliance it was never designed to fit to.
This architecture, which to our knowledge is second to none, particularly
in the mobile space, allows Calligra Suite to already be deployed on mobile
devices such as N9,

 PierreSt

On Thu, Dec 22, 2011 at 2:16 PM, Inge Wallin  wrote:

> On Thursday, December 22, 2011 10:51:18 Cyrille Berger Skott wrote:
> > Hi,
> >
> > Since your message concerns as much the marketing message as the
> website, I
> > have taken the liberty to split my answer in two.
> >
> > Here is the part concerning the marketing message.
> >
> > That is really great and important to start thinking about it. However, I
> > would really like us to avoid any kind of disproportionate exagerating
> > message like "the leader in free mobile office applications". That might
> > be true, to some extent...
>
> This statement is undoubtedly true. Remember that mobile is not just phones
> but also tablets which are normally (always?) included in mobile.  It's
> true
> that Calligra has a few installed applications but it is in fact the *only*
> free office suite which have any mobile users at all.  Hence it's the
> leader.
>
> > First of all calligra does not have a mobile
> > interface, being available on the N9 under the "Harmattan Office UI"
> > (which is still closed source, or did I miss something ?) is more of a
> > victory of the engine, not bad in itself.
>
> Why so specific?  The N900 UI is also mobile and is free.  And the
> community
> has at least one other UI (calligra active) which is aimed at mobile
> devices.
> Of course under all these is the engine which is indeed awesome and
> necessary
> but not sufficient to be the leader in free mobile applications.
>
> > Secondly, and probably more
> > important (and very sadly), Calligra is only available on the N9(xx),
> > which has a market share of a maximum of 0.1%. It is nowhere to be seen
> on
> > a widely spread smartphome platform ie Android (or iPhone or Symbian).
> > Once it is available on Android, saying that we are the "the leader in
> free
> > mobile office applications" will have a strong echo compared to being
> > available on a marginal platform.
>
> Fact: Calligra *is* the leader in free mobile office applications.  It is
> true
> that it will be a stronger lead when there is an Android port.  My guess is
> that this will happen sooner rather than later (hint, hint :) ).  Still it
> doesn't detract from the fact that we are already the only free office
> suite
> that has anything at all on any mobile device.
>
> LibreOffice has announced starting a port to Android and they got many
> articles about that rather empty statement. I am willing to bet good money
> that Calligra will run on Android before LibreOffice.  And further, I am
> willing to bet that whey they announce something it will still have the
> same
> desktop UI while Calligra's will be touch based and scalable.
>
> > In my opinion, being humble is really important, especially if you
> consider
> > who is currently reading our marketting messages right now. We are mostly
> > talking to people who are highly informed, most of them know where
> Calligra
> > comes from, and many would labeled it as a project that makes promises
> but
> > do not deliver.
> >
> > So saying something like "Calligra is available on a wide range of
> > platform, from desktop to mobile." Or a bit more catchy, "Takes Calligra
> > with you everywhere you go, from your desktop to your mobile", is really
> > fine. But saying we are the leader in a market where we are only
> available
> > to less than 0.1% seems too strong.
>
> With due respect, I think you are totally wrong here.  It never pays off in
> marketing to be humble.  Really, what do you hope to achieve (or avoid for
> that matter) by being humble?
>
> What Calligra needs is to take a strong position. I talked about this at an
> Akademy long ago and I still think it's immensely important. We are not
> exactly entering an empty arena here. LibreOffice is going very strong on
> the
> desktop and I wouldn't count out OOo yet since IBM gave a pretty convincing
> presentation at the LibreOffice conference *and* they have released a (non-
> free afaik) ODF viewer for Android based on the OOo code.
>
> This position should be "the leader in free mobile office applications" or
> something like it. Mobile is the future, LibO cannot go there due to
> problems
> with the code and we will be able to settle in this space and later move on
> from that position.
>
> The only thing that we can accomplish by being humble is to be made
> irrelevant.
>
> > Other than that, I agree with your list of strong points.
>
> I think we do actually agree on most things.

Re: Marketing Message for Calligra

[Pierre Stirnweiss]

A bit further down in the paragraph, it is stated that the RC will be
delayed and there is likely going to be a fifth beta. Well, since we
just announced the fifth beta, I guess we are talking about a very very
strong likelihood ;)

Pierre

On Thu, Dec 22, 2011 at 11:23 AM, Cyrille Berger Skott
wrote:

> On Thursday 22 December 2011, Pierre Stirnweiss wrote:
> > Also, the web site says beta 5 as title, whereas the text underneath
> speaks
> > about the fourth beta being released and a fifth one eventually coming.
> Did
> > I miss something?
> I did miss it :) Fixed now.
>
> --
> Cyrille Berger Skott
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Marketing Message for Calligra

[Pierre Stirnweiss]

On Fri, Dec 23, 2011 at 12:32 PM, Inge Wallin  wrote:

> On Thursday, December 22, 2011 20:18:48 Cyrille Berger Skott wrote:
> > On Thursday 22 December 2011, Inge Wallin wrote:
> > > On Thursday, December 22, 2011 17:47:54 Cyrille Berger Skott wrote:
> > > > You can make all the fun you want of LibreOffice attempt to port to
> > > > Android, but if you go outside of the Calligra community, people
> > > > perceive us as the people who have been trying for 14 years to
> deliver
> > > > an office suite for the desktop. And now, we will start bragging to
> be
> > > > leading on the free office suite market for mobile, and if you
> scratch
> > > > under the surface, you will discover that we are positionned on a
> dead
> > > > tiny fraction of that market.
> > >
> > > I haven't exactly made fun of it. If you think so you have
> misunderstood.
> > > My point, instead, is that LibreOffice has issued a press release
> saying
> > > they will start porting to Android (note: 'will start'. Not 'have
> done').
> > > They have in fact *nothing* to show here and if anybody runs the risk
> of
> > > being known to not deliver on these platforms it's them.
> > >
> > > But still it worked for them insofar as that journalists and bloggers
> > > parrotted this press release. Some real buzz was created around
> > > LibreOffice on Android. If we don't tell people that we have done more
> > > already and will do more still then we can never push Calligra to the
> > > front.
> >
>

Why did it worked for them is the question. My answer to it is that they
are known as a key player in the Office Suite. They are known because they
are the ones identified as "having successfully challenged Microsoft
supremacy on Office Suites". They have delivered on the desktop something
few believed possible before: a realistic and usable alternative (and free)
to MS Office. Therefore they are taken seriously when they say they will
port Libreoffice to Android.
When we go on this route, the non informed journalists will say "who are
these guys? I won't believe what an unknown group is telling", some
informed will think "the ones who failed to deliver on the desktop for a
decade now is bragging about mobile", and so on.
When Intel is telling the world they will be at 20nm engraving next year,
people believe them. Would a small nearly unknown company say the same,
journalists would not take them seriously (no matter what the reality of
their claim is).

As for the N9 Harmattan Office, not matter how proud i am that we are at
the core of it, it is still a document viewer. It was evewn listed as a
weak point in one review i read, that you couldn't edit documents. So even
on the N9 it is arguable if we can call ourselves an Office Suite.

PierreSt
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Working on deleting anchored objects in Words

[Pierre Stirnweiss]

Indeed, the change tracking system needs to know about it. And secondly, if
you remove a character from the QTextDocument, Qt will create an undo/redo
command internally. If you do not have a corresponding  command on your
application undoStack, you'll be out of sync with QTextDocument internal
undoStack.
This is the reason the current show/hide changes create an undo/redo action
(because they add/remove the text from the QTextDocument).

PierreSt


On Wed, Jan 4, 2012 at 9:34 AM, Boudewijn Rempt  wrote:

> On Wednesday 04 January 2012 Jan, Thorsten Zachmann wrote:
>
> > When there is a anchor belonging to the shape, it also removes the
> anchor from
> > the document. This is done by circumventing the command generation of
> > KoTextEditor. I do this because there should be no additional commands
> > generated besides the DeleteShapeCommand. As the data to recovering the
> > deletion is stored in the application data it is not needed that a undo
> > command for the actual removal of the anchor is created.
>
> Well, in my kotext-inlinecommand-rempt I was close to solving the same
> bug, but the other way around: I put the creation of the command in
> KoTextEditor instead because the change tracking mechanism needs to know
> about it. Also, anchors aren't only created in the addFrameSet method,
> afaik.
>
> --
> Boudewijn Rempt
> http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: text:id is deprecated

[Pierre Stirnweiss]

You either call KoTextEditor->beginEditBlock before doing all the
operations (ie, before deleting the shape and the anchor), and call
textEditor->endEditBlock(),
or alternatively you create a KUndo2Command and call
KoTextEditor->addCommand(yourCommand). I think the second method is better
as it allows you to specify the name of the command appearing in the undo
stack. (check in the textTool/commands for some examples.

PierreSt

On Thu, Jan 5, 2012 at 4:27 AM, Thorsten Zachmann wrote:

> On Wednesday, January 04, 2012 11:55:14 Boudewijn Rempt wrote:
> > On Thursday 15 December 2011 Dec, Boudewijn Rempt wrote:
> > > It turns out that currently, only the rdf system keeps the actual id
> > > strings after loading is finished, the other parts of calligra only
> > > use the id strings to build their mappings during loading, and
> > > recreate them during saving.
> >
> > Turns out that this isn't correct. The changetracking system also keeps a
> > map, so I'll have to create the a class that keeps the map, can update
> > items and a listener interface  that can be used to make sure all
> > dependent objects are informed when the xml-id is regenerated during a
> > save operation.
> >
> > This should in all likelihood improve the rdf code as well.
>
> Can you please point me to the place where you see this.
>
> The only place where I found it is the KoGenChanges. If that is the place
> you
> talk about then it is not needed to have a mapping as that is only used on
> saving.
>
> Thorsten
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Review Request: Replace the current half baked style selection widgets with a home brewed comboBox

[Pierre Stirnweiss]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103677/
---

Review request for Calligra.


Description
---

Merge request.
Merge branch textshape_stylesWidget_pierreSt into master.
The branch provides a replacement for the style selection widgets. The new 
provided widgets are a subclass of QComboBox.
They provide a style preview both in the main area and in the dropdown menu.
The dropdown menu provides a "show style manager" button, which call the whole 
style management dialog.
The dropdown also provides a "delete style" button, although this is for the 
moment disabled/commented out, because deleting a style is not currently really 
supported.
The combo also allows to create a style based on the current text format if it 
does not correspond to the original style (ie. the user changed a property).


Diffs
-

  libs/kotext/KoTextEditor.h 94bf433 
  libs/kotext/KoTextEditor.cpp 9f242e6 
  libs/kotext/styles/KoCharacterStyle.cpp f9e0741 
  libs/kotext/styles/KoParagraphStyle.h 12ab672 
  libs/textlayout/CMakeLists.txt af6d64a 
  libs/textlayout/FrameIterator.h c73d580 
  libs/textlayout/KoStyleThumbnailer.h 8645089 
  libs/textlayout/KoStyleThumbnailer.cpp 3529bbb 
  plugins/textshape/CMakeLists.txt fad7c04 
  plugins/textshape/TextTool.h f8de126 
  plugins/textshape/TextTool.cpp f6822bd 
  plugins/textshape/dialogs/SimpleCharacterWidget.h ad944a5 
  plugins/textshape/dialogs/SimpleCharacterWidget.cpp 6b2bb66 
  plugins/textshape/dialogs/SimpleCharacterWidget.ui e4f6d3b 
  plugins/textshape/dialogs/SimpleParagraphWidget.h bc167b4 
  plugins/textshape/dialogs/SimpleParagraphWidget.cpp cbfacfe 
  plugins/textshape/dialogs/SimpleParagraphWidget.ui b2e9adf 
  plugins/textshape/dialogs/StylesCombo.h PRE-CREATION 
  plugins/textshape/dialogs/StylesCombo.cpp PRE-CREATION 
  plugins/textshape/dialogs/StylesComboPreview.h PRE-CREATION 
  plugins/textshape/dialogs/StylesComboPreview.cpp PRE-CREATION 
  plugins/textshape/dialogs/StylesDelegate.h f5d216f 
  plugins/textshape/dialogs/StylesDelegate.cpp d1021f5 
  plugins/textshape/dialogs/StylesModel.h dbd17b4 
  plugins/textshape/dialogs/StylesModel.cpp 94deb24 
  plugins/textshape/dialogs/StylesWidget.cpp 4f31a01 
  plugins/textshape/dialogs/TableOfContentsStyleModel.cpp 48ee7c3 

Diff: http://git.reviewboard.kde.org/r/103677/diff/diff


Testing
---

The functionality exclusively linked to the comboBox seems to be working 
properly. Some defects have been identified (like no paragraph style is 
selected at startup), but these are actually outside the scope of this widget 
and affecting the current widget also.


Thanks,

Pierre Stirnweiss

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Review Request: Replace the current half baked style selection widgets with a home brewed comboBox

[Pierre Stirnweiss]

> On Jan. 12, 2012, 8:01 a.m., Thorsten Zachmann wrote:
> > libs/kotext/styles/KoCharacterStyle.cpp, lines 2130-2131
> > <http://git.reviewboard.kde.org/r/103677/diff/1/?file=46456#file46456line2130>
> >
> > This change seems to be wrong as it will return stuff that should not 
> > be returned here.

Well, these hard coded default are applied when the style is applied. And since 
this function does not return only what is defined in that particular style but 
also moves up the parenting chain, i think these properties should also be 
returned. If not, there is a discrepancy between what the styles apply on a 
format and what the style returns as a value:
If I have:
QTextCharFormat format;
style->applyStyle(format);
Then format.property(some hard coded property) returns a value, but 
style.value(that same property) is undefined. I don't find this discrepancy 
logical.


- Pierre


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103677/#review9762
-------


On Jan. 11, 2012, 11:11 p.m., Pierre Stirnweiss wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103677/
> ---
> 
> (Updated Jan. 11, 2012, 11:11 p.m.)
> 
> 
> Review request for Calligra.
> 
> 
> Description
> ---
> 
> Merge request.
> Merge branch textshape_stylesWidget_pierreSt into master.
> The branch provides a replacement for the style selection widgets. The new 
> provided widgets are a subclass of QComboBox.
> They provide a style preview both in the main area and in the dropdown menu.
> The dropdown menu provides a "show style manager" button, which call the 
> whole style management dialog.
> The dropdown also provides a "delete style" button, although this is for the 
> moment disabled/commented out, because deleting a style is not currently 
> really supported.
> The combo also allows to create a style based on the current text format if 
> it does not correspond to the original style (ie. the user changed a 
> property).
> 
> 
> Diffs
> -
> 
>   libs/kotext/KoTextEditor.h 94bf433 
>   libs/kotext/KoTextEditor.cpp 9f242e6 
>   libs/kotext/styles/KoCharacterStyle.cpp f9e0741 
>   libs/kotext/styles/KoParagraphStyle.h 12ab672 
>   libs/textlayout/CMakeLists.txt af6d64a 
>   libs/textlayout/FrameIterator.h c73d580 
>   libs/textlayout/KoStyleThumbnailer.h 8645089 
>   libs/textlayout/KoStyleThumbnailer.cpp 3529bbb 
>   plugins/textshape/CMakeLists.txt fad7c04 
>   plugins/textshape/TextTool.h f8de126 
>   plugins/textshape/TextTool.cpp f6822bd 
>   plugins/textshape/dialogs/SimpleCharacterWidget.h ad944a5 
>   plugins/textshape/dialogs/SimpleCharacterWidget.cpp 6b2bb66 
>   plugins/textshape/dialogs/SimpleCharacterWidget.ui e4f6d3b 
>   plugins/textshape/dialogs/SimpleParagraphWidget.h bc167b4 
>   plugins/textshape/dialogs/SimpleParagraphWidget.cpp cbfacfe 
>   plugins/textshape/dialogs/SimpleParagraphWidget.ui b2e9adf 
>   plugins/textshape/dialogs/StylesCombo.h PRE-CREATION 
>   plugins/textshape/dialogs/StylesCombo.cpp PRE-CREATION 
>   plugins/textshape/dialogs/StylesComboPreview.h PRE-CREATION 
>   plugins/textshape/dialogs/StylesComboPreview.cpp PRE-CREATION 
>   plugins/textshape/dialogs/StylesDelegate.h f5d216f 
>   plugins/textshape/dialogs/StylesDelegate.cpp d1021f5 
>   plugins/textshape/dialogs/StylesModel.h dbd17b4 
>   plugins/textshape/dialogs/StylesModel.cpp 94deb24 
>   plugins/textshape/dialogs/StylesWidget.cpp 4f31a01 
>   plugins/textshape/dialogs/TableOfContentsStyleModel.cpp 48ee7c3 
> 
> Diff: http://git.reviewboard.kde.org/r/103677/diff/diff
> 
> 
> Testing
> ---
> 
> The functionality exclusively linked to the comboBox seems to be working 
> properly. Some defects have been identified (like no paragraph style is 
> selected at startup), but these are actually outside the scope of this widget 
> and affecting the current widget also.
> 
> 
> Thanks,
> 
> Pierre Stirnweiss
> 
>

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Review Request: Replace the current half baked style selection widgets with a home brewed comboBox

[Pierre Stirnweiss]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103677/
---

(Updated Jan. 15, 2012, 2:03 p.m.)


Review request for Calligra.


Changes
---

Fixes issues raised by Zagge and Boemann.
Also fixes the appearance problem Zagge (and others) were experiencing. This 
was due to the use of a Qt4.8 method of QImage. Method replaced by a pre-4.8 
compatible one.
Also, fixes some crash on opening certain documents, now the 
SimpleCharacterWidget and SimpleParagraphWidget get initialised with the 
current block and formats.


Description
---

Merge request.
Merge branch textshape_stylesWidget_pierreSt into master.
The branch provides a replacement for the style selection widgets. The new 
provided widgets are a subclass of QComboBox.
They provide a style preview both in the main area and in the dropdown menu.
The dropdown menu provides a "show style manager" button, which call the whole 
style management dialog.
The dropdown also provides a "delete style" button, although this is for the 
moment disabled/commented out, because deleting a style is not currently really 
supported.
The combo also allows to create a style based on the current text format if it 
does not correspond to the original style (ie. the user changed a property).


Diffs (updated)
-

  libs/kotext/KoTextEditor.h 94bf433 
  libs/kotext/KoTextEditor.cpp 9f242e6 
  libs/kotext/styles/KoCharacterStyle.h 898ba43 
  libs/kotext/styles/KoCharacterStyle.cpp f9e0741 
  libs/kotext/styles/KoParagraphStyle.h 12ab672 
  libs/textlayout/CMakeLists.txt af6d64a 
  libs/textlayout/FrameIterator.h c73d580 
  libs/textlayout/KoStyleThumbnailer.h 8645089 
  libs/textlayout/KoStyleThumbnailer.cpp 3529bbb 
  merge_textshape.diff PRE-CREATION 
  plugins/textshape/CMakeLists.txt fad7c04 
  plugins/textshape/TextTool.h f8de126 
  plugins/textshape/TextTool.cpp f6822bd 
  plugins/textshape/dialogs/SimpleCharacterWidget.h ad944a5 
  plugins/textshape/dialogs/SimpleCharacterWidget.cpp 6b2bb66 
  plugins/textshape/dialogs/SimpleCharacterWidget.ui e4f6d3b 
  plugins/textshape/dialogs/SimpleParagraphWidget.h bc167b4 
  plugins/textshape/dialogs/SimpleParagraphWidget.cpp cbfacfe 
  plugins/textshape/dialogs/SimpleParagraphWidget.ui b2e9adf 
  plugins/textshape/dialogs/StylesCombo.h PRE-CREATION 
  plugins/textshape/dialogs/StylesCombo.cpp PRE-CREATION 
  plugins/textshape/dialogs/StylesComboPreview.h PRE-CREATION 
  plugins/textshape/dialogs/StylesComboPreview.cpp PRE-CREATION 
  plugins/textshape/dialogs/StylesDelegate.h f5d216f 
  plugins/textshape/dialogs/StylesDelegate.cpp d1021f5 
  plugins/textshape/dialogs/StylesModel.h dbd17b4 
  plugins/textshape/dialogs/StylesModel.cpp 94deb24 
  plugins/textshape/dialogs/StylesWidget.cpp 4f31a01 
  plugins/textshape/dialogs/TableOfContentsStyleModel.cpp 48ee7c3 

Diff: http://git.reviewboard.kde.org/r/103677/diff/diff


Testing
---

The functionality exclusively linked to the comboBox seems to be working 
properly. Some defects have been identified (like no paragraph style is 
selected at startup), but these are actually outside the scope of this widget 
and affecting the current widget also.


Thanks,

Pierre Stirnweiss

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Review Request: Replace the current half baked style selection widgets with a home brewed comboBox

[Pierre Stirnweiss]

> On Jan. 12, 2012, 5:05 a.m., C. Boemann wrote:
> > plugins/textshape/dialogs/SimpleParagraphWidget.cpp, line 217
> > <http://git.reviewboard.kde.org/r/103677/diff/1/?file=46469#file46469line217>
> >
> > we already discussed this on irc, but for now it will have to do

Have we?, I don't remember if we have.


- Pierre


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103677/#review9761
---


On Jan. 15, 2012, 2:03 p.m., Pierre Stirnweiss wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103677/
> ---
> 
> (Updated Jan. 15, 2012, 2:03 p.m.)
> 
> 
> Review request for Calligra.
> 
> 
> Description
> ---
> 
> Merge request.
> Merge branch textshape_stylesWidget_pierreSt into master.
> The branch provides a replacement for the style selection widgets. The new 
> provided widgets are a subclass of QComboBox.
> They provide a style preview both in the main area and in the dropdown menu.
> The dropdown menu provides a "show style manager" button, which call the 
> whole style management dialog.
> The dropdown also provides a "delete style" button, although this is for the 
> moment disabled/commented out, because deleting a style is not currently 
> really supported.
> The combo also allows to create a style based on the current text format if 
> it does not correspond to the original style (ie. the user changed a 
> property).
> 
> 
> Diffs
> -
> 
>   libs/kotext/KoTextEditor.h 94bf433 
>   libs/kotext/KoTextEditor.cpp 9f242e6 
>   libs/kotext/styles/KoCharacterStyle.h 898ba43 
>   libs/kotext/styles/KoCharacterStyle.cpp f9e0741 
>   libs/kotext/styles/KoParagraphStyle.h 12ab672 
>   libs/textlayout/CMakeLists.txt af6d64a 
>   libs/textlayout/FrameIterator.h c73d580 
>   libs/textlayout/KoStyleThumbnailer.h 8645089 
>   libs/textlayout/KoStyleThumbnailer.cpp 3529bbb 
>   merge_textshape.diff PRE-CREATION 
>   plugins/textshape/CMakeLists.txt fad7c04 
>   plugins/textshape/TextTool.h f8de126 
>   plugins/textshape/TextTool.cpp f6822bd 
>   plugins/textshape/dialogs/SimpleCharacterWidget.h ad944a5 
>   plugins/textshape/dialogs/SimpleCharacterWidget.cpp 6b2bb66 
>   plugins/textshape/dialogs/SimpleCharacterWidget.ui e4f6d3b 
>   plugins/textshape/dialogs/SimpleParagraphWidget.h bc167b4 
>   plugins/textshape/dialogs/SimpleParagraphWidget.cpp cbfacfe 
>   plugins/textshape/dialogs/SimpleParagraphWidget.ui b2e9adf 
>   plugins/textshape/dialogs/StylesCombo.h PRE-CREATION 
>   plugins/textshape/dialogs/StylesCombo.cpp PRE-CREATION 
>   plugins/textshape/dialogs/StylesComboPreview.h PRE-CREATION 
>   plugins/textshape/dialogs/StylesComboPreview.cpp PRE-CREATION 
>   plugins/textshape/dialogs/StylesDelegate.h f5d216f 
>   plugins/textshape/dialogs/StylesDelegate.cpp d1021f5 
>   plugins/textshape/dialogs/StylesModel.h dbd17b4 
>   plugins/textshape/dialogs/StylesModel.cpp 94deb24 
>   plugins/textshape/dialogs/StylesWidget.cpp 4f31a01 
>   plugins/textshape/dialogs/TableOfContentsStyleModel.cpp 48ee7c3 
> 
> Diff: http://git.reviewboard.kde.org/r/103677/diff/diff
> 
> 
> Testing
> ---
> 
> The functionality exclusively linked to the comboBox seems to be working 
> properly. Some defects have been identified (like no paragraph style is 
> selected at startup), but these are actually outside the scope of this widget 
> and affecting the current widget also.
> 
> 
> Thanks,
> 
> Pierre Stirnweiss
> 
>

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Review Request: Replace the current half baked style selection widgets with a home brewed comboBox

[Pierre Stirnweiss]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103677/
---

(Updated Jan. 15, 2012, 7:30 p.m.)


Review request for Calligra.


Changes
---

Fixed the issues.
Also, made the new character style set only the properties which have changed 
compared to the paragraph style.


Description
---

Merge request.
Merge branch textshape_stylesWidget_pierreSt into master.
The branch provides a replacement for the style selection widgets. The new 
provided widgets are a subclass of QComboBox.
They provide a style preview both in the main area and in the dropdown menu.
The dropdown menu provides a "show style manager" button, which call the whole 
style management dialog.
The dropdown also provides a "delete style" button, although this is for the 
moment disabled/commented out, because deleting a style is not currently really 
supported.
The combo also allows to create a style based on the current text format if it 
does not correspond to the original style (ie. the user changed a property).


Diffs (updated)
-

  libs/kotext/KoTextEditor.h 94bf433 
  libs/kotext/KoTextEditor.cpp 9f242e6 
  libs/kotext/styles/KoCharacterStyle.h 898ba43 
  libs/kotext/styles/KoCharacterStyle.cpp f9e0741 
  libs/kotext/styles/KoParagraphStyle.h 12ab672 
  libs/textlayout/CMakeLists.txt af6d64a 
  libs/textlayout/FrameIterator.h c73d580 
  libs/textlayout/KoStyleThumbnailer.h 8645089 
  libs/textlayout/KoStyleThumbnailer.cpp 3529bbb 
  merge1_textshape.diff PRE-CREATION 
  merge_textshape.diff PRE-CREATION 
  plugins/textshape/CMakeLists.txt fad7c04 
  plugins/textshape/TextTool.h f8de126 
  plugins/textshape/TextTool.cpp f6822bd 
  plugins/textshape/dialogs/SimpleCharacterWidget.h ad944a5 
  plugins/textshape/dialogs/SimpleCharacterWidget.cpp 6b2bb66 
  plugins/textshape/dialogs/SimpleCharacterWidget.ui e4f6d3b 
  plugins/textshape/dialogs/SimpleParagraphWidget.h bc167b4 
  plugins/textshape/dialogs/SimpleParagraphWidget.cpp cbfacfe 
  plugins/textshape/dialogs/SimpleParagraphWidget.ui b2e9adf 
  plugins/textshape/dialogs/StylesCombo.h PRE-CREATION 
  plugins/textshape/dialogs/StylesCombo.cpp PRE-CREATION 
  plugins/textshape/dialogs/StylesComboPreview.h PRE-CREATION 
  plugins/textshape/dialogs/StylesComboPreview.cpp PRE-CREATION 
  plugins/textshape/dialogs/StylesDelegate.h f5d216f 
  plugins/textshape/dialogs/StylesDelegate.cpp d1021f5 
  plugins/textshape/dialogs/StylesModel.h dbd17b4 
  plugins/textshape/dialogs/StylesModel.cpp 94deb24 
  plugins/textshape/dialogs/StylesWidget.cpp 4f31a01 
  plugins/textshape/dialogs/TableOfContentsStyleModel.cpp 48ee7c3 

Diff: http://git.reviewboard.kde.org/r/103677/diff/diff


Testing
---

The functionality exclusively linked to the comboBox seems to be working 
properly. Some defects have been identified (like no paragraph style is 
selected at startup), but these are actually outside the scope of this widget 
and affecting the current widget also.


Thanks,

Pierre Stirnweiss

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Review Request: Replace the current half baked style selection widgets with a home brewed comboBox

[Pierre Stirnweiss]

> On Jan. 12, 2012, 8:01 a.m., Thorsten Zachmann wrote:
> > plugins/textshape/TextTool.cpp, lines 1803-1810
> > <http://git.reviewboard.kde.org/r/103677/diff/1/?file=46464#file46464line1803>
> >
> > How about intializing charStyle with style?
> 
> Pierre Stirnweiss wrote:
> There is no KoCharacterStyle(KoCharacterStyle *otherStyle) constructor. 
> So I don't think we can.
> 
> Thorsten Zachmann wrote:
> That is not what I meant. My idead was the following:
> 
> KoCharacterStyle *charStyle = style;
> if (!charStyle) {
>charStyle = 
> }

Done


> On Jan. 12, 2012, 8:01 a.m., Thorsten Zachmann wrote:
> > plugins/textshape/dialogs/StylesModel.cpp, line 69
> > <http://git.reviewboard.kde.org/r/103677/diff/1/?file=46478#file46478line69>
> >
> > I think the As paragraph is not very descriptive of what it does. 
> > 
> > How about "Style of Paragraph used"?
> >  
> > Also I think we should translate this string.
> 
> Pierre Stirnweiss wrote:
> Is it ok to burden the translators right now? a translator listening to 
> this perhaps can answer?
> 
> Thorsten Zachmann wrote:
> I think it would help the application and make it more usefull. You can 
> ask Cyrille about it to be sure. But I'm all for it

Changed to "None" as per IRC conversation


- Pierre


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103677/#review9762
---


On Jan. 15, 2012, 7:30 p.m., Pierre Stirnweiss wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103677/
> ---
> 
> (Updated Jan. 15, 2012, 7:30 p.m.)
> 
> 
> Review request for Calligra.
> 
> 
> Description
> ---
> 
> Merge request.
> Merge branch textshape_stylesWidget_pierreSt into master.
> The branch provides a replacement for the style selection widgets. The new 
> provided widgets are a subclass of QComboBox.
> They provide a style preview both in the main area and in the dropdown menu.
> The dropdown menu provides a "show style manager" button, which call the 
> whole style management dialog.
> The dropdown also provides a "delete style" button, although this is for the 
> moment disabled/commented out, because deleting a style is not currently 
> really supported.
> The combo also allows to create a style based on the current text format if 
> it does not correspond to the original style (ie. the user changed a 
> property).
> 
> 
> Diffs
> -
> 
>   libs/kotext/KoTextEditor.h 94bf433 
>   libs/kotext/KoTextEditor.cpp 9f242e6 
>   libs/kotext/styles/KoCharacterStyle.h 898ba43 
>   libs/kotext/styles/KoCharacterStyle.cpp f9e0741 
>   libs/kotext/styles/KoParagraphStyle.h 12ab672 
>   libs/textlayout/CMakeLists.txt af6d64a 
>   libs/textlayout/FrameIterator.h c73d580 
>   libs/textlayout/KoStyleThumbnailer.h 8645089 
>   libs/textlayout/KoStyleThumbnailer.cpp 3529bbb 
>   merge1_textshape.diff PRE-CREATION 
>   merge_textshape.diff PRE-CREATION 
>   plugins/textshape/CMakeLists.txt fad7c04 
>   plugins/textshape/TextTool.h f8de126 
>   plugins/textshape/TextTool.cpp f6822bd 
>   plugins/textshape/dialogs/SimpleCharacterWidget.h ad944a5 
>   plugins/textshape/dialogs/SimpleCharacterWidget.cpp 6b2bb66 
>   plugins/textshape/dialogs/SimpleCharacterWidget.ui e4f6d3b 
>   plugins/textshape/dialogs/SimpleParagraphWidget.h bc167b4 
>   plugins/textshape/dialogs/SimpleParagraphWidget.cpp cbfacfe 
>   plugins/textshape/dialogs/SimpleParagraphWidget.ui b2e9adf 
>   plugins/textshape/dialogs/StylesCombo.h PRE-CREATION 
>   plugins/textshape/dialogs/StylesCombo.cpp PRE-CREATION 
>   plugins/textshape/dialogs/StylesComboPreview.h PRE-CREATION 
>   plugins/textshape/dialogs/StylesComboPreview.cpp PRE-CREATION 
>   plugins/textshape/dialogs/StylesDelegate.h f5d216f 
>   plugins/textshape/dialogs/StylesDelegate.cpp d1021f5 
>   plugins/textshape/dialogs/StylesModel.h dbd17b4 
>   plugins/textshape/dialogs/StylesModel.cpp 94deb24 
>   plugins/textshape/dialogs/StylesWidget.cpp 4f31a01 
>   plugins/textshape/dialogs/TableOfContentsStyleModel.cpp 48ee7c3 
> 
> Diff: http://git.reviewboard.kde.org/r/103677/diff/diff
> 
> 
> Testing
> ---
> 
> The functionality exclusively linked to the comboBox seems to be working 
> properly. Some defects have been identified (like no paragraph style is 
> selected at startup), but these are actually outside the scope of this widget 
> and affecting the current widget also.
> 
> 
> Thanks,
> 
> Pierre Stirnweiss
> 
>

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Review Request: Replace the current half baked style selection widgets with a home brewed comboBox

[Pierre Stirnweiss]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103677/
---

(Updated Jan. 15, 2012, 7:41 p.m.)


Review request for Calligra.


Changes
---

Remove patch files from branch


Description
---

Merge request.
Merge branch textshape_stylesWidget_pierreSt into master.
The branch provides a replacement for the style selection widgets. The new 
provided widgets are a subclass of QComboBox.
They provide a style preview both in the main area and in the dropdown menu.
The dropdown menu provides a "show style manager" button, which call the whole 
style management dialog.
The dropdown also provides a "delete style" button, although this is for the 
moment disabled/commented out, because deleting a style is not currently really 
supported.
The combo also allows to create a style based on the current text format if it 
does not correspond to the original style (ie. the user changed a property).


Diffs (updated)
-

  libs/kotext/KoTextEditor.h 0fc4ff4 
  libs/kotext/KoTextEditor.cpp 3ef31d6 
  libs/kotext/styles/KoCharacterStyle.h 898ba43 
  libs/kotext/styles/KoCharacterStyle.cpp e575b0d 
  libs/kotext/styles/KoParagraphStyle.h 12ab672 
  libs/textlayout/CMakeLists.txt af6d64a 
  libs/textlayout/FrameIterator.h c73d580 
  libs/textlayout/KoStyleThumbnailer.h 8645089 
  libs/textlayout/KoStyleThumbnailer.cpp 3529bbb 
  plugins/textshape/CMakeLists.txt fad7c04 
  plugins/textshape/TextTool.h 17a687b 
  plugins/textshape/TextTool.cpp 3ba9d33 
  plugins/textshape/dialogs/SimpleCharacterWidget.h ad944a5 
  plugins/textshape/dialogs/SimpleCharacterWidget.cpp 6b2bb66 
  plugins/textshape/dialogs/SimpleCharacterWidget.ui e4f6d3b 
  plugins/textshape/dialogs/SimpleParagraphWidget.h bc167b4 
  plugins/textshape/dialogs/SimpleParagraphWidget.cpp cbfacfe 
  plugins/textshape/dialogs/SimpleParagraphWidget.ui b2e9adf 
  plugins/textshape/dialogs/StylesCombo.h PRE-CREATION 
  plugins/textshape/dialogs/StylesCombo.cpp PRE-CREATION 
  plugins/textshape/dialogs/StylesComboPreview.h PRE-CREATION 
  plugins/textshape/dialogs/StylesComboPreview.cpp PRE-CREATION 
  plugins/textshape/dialogs/StylesDelegate.h f5d216f 
  plugins/textshape/dialogs/StylesDelegate.cpp d1021f5 
  plugins/textshape/dialogs/StylesModel.h dbd17b4 
  plugins/textshape/dialogs/StylesModel.cpp 94deb24 
  plugins/textshape/dialogs/StylesWidget.cpp 4f31a01 
  plugins/textshape/dialogs/TableOfContentsStyleModel.cpp 48ee7c3 

Diff: http://git.reviewboard.kde.org/r/103677/diff/diff


Testing
---

The functionality exclusively linked to the comboBox seems to be working 
properly. Some defects have been identified (like no paragraph style is 
selected at startup), but these are actually outside the scope of this widget 
and affecting the current widget also.


Thanks,

Pierre Stirnweiss

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Review Request: Replace the current half baked style selection widgets with a home brewed comboBox

[Pierre Stirnweiss]

> On Jan. 15, 2012, 8:17 p.m., C. Boemann wrote:
> > plugins/textshape/dialogs/SimpleCharacterWidget.cpp, line 131
> > <http://git.reviewboard.kde.org/r/103677/diff/4/?file=46799#file46799line131>
> >
> > = block.charformat
> >

The simpleCharacterWidget doesn't know anything about the current block. 
However, it seems to work like that.


> On Jan. 15, 2012, 8:17 p.m., C. Boemann wrote:
> > plugins/textshape/dialogs/SimpleCharacterWidget.ui, line 114
> > <http://git.reviewboard.kde.org/r/103677/diff/4/?file=46800#file46800line114>
> >
> > oooh you removed the SpecialButton too
> > 
> > please revert that part

Huh, I am not sure I follow you here, the whole exercise is to replace the 
SpecialButton.


> On Jan. 15, 2012, 8:17 p.m., C. Boemann wrote:
> > plugins/textshape/dialogs/SimpleParagraphWidget.ui, line 121
> > <http://git.reviewboard.kde.org/r/103677/diff/4/?file=46803#file46803line121>
> >
> > please dont remove the special button
> > it's very needed

Idem.


- Pierre


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103677/#review9842
---


On Jan. 15, 2012, 7:41 p.m., Pierre Stirnweiss wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103677/
> ---
> 
> (Updated Jan. 15, 2012, 7:41 p.m.)
> 
> 
> Review request for Calligra.
> 
> 
> Description
> ---
> 
> Merge request.
> Merge branch textshape_stylesWidget_pierreSt into master.
> The branch provides a replacement for the style selection widgets. The new 
> provided widgets are a subclass of QComboBox.
> They provide a style preview both in the main area and in the dropdown menu.
> The dropdown menu provides a "show style manager" button, which call the 
> whole style management dialog.
> The dropdown also provides a "delete style" button, although this is for the 
> moment disabled/commented out, because deleting a style is not currently 
> really supported.
> The combo also allows to create a style based on the current text format if 
> it does not correspond to the original style (ie. the user changed a 
> property).
> 
> 
> Diffs
> -
> 
>   libs/kotext/KoTextEditor.h 0fc4ff4 
>   libs/kotext/KoTextEditor.cpp 3ef31d6 
>   libs/kotext/styles/KoCharacterStyle.h 898ba43 
>   libs/kotext/styles/KoCharacterStyle.cpp e575b0d 
>   libs/kotext/styles/KoParagraphStyle.h 12ab672 
>   libs/textlayout/CMakeLists.txt af6d64a 
>   libs/textlayout/FrameIterator.h c73d580 
>   libs/textlayout/KoStyleThumbnailer.h 8645089 
>   libs/textlayout/KoStyleThumbnailer.cpp 3529bbb 
>   plugins/textshape/CMakeLists.txt fad7c04 
>   plugins/textshape/TextTool.h 17a687b 
>   plugins/textshape/TextTool.cpp 3ba9d33 
>   plugins/textshape/dialogs/SimpleCharacterWidget.h ad944a5 
>   plugins/textshape/dialogs/SimpleCharacterWidget.cpp 6b2bb66 
>   plugins/textshape/dialogs/SimpleCharacterWidget.ui e4f6d3b 
>   plugins/textshape/dialogs/SimpleParagraphWidget.h bc167b4 
>   plugins/textshape/dialogs/SimpleParagraphWidget.cpp cbfacfe 
>   plugins/textshape/dialogs/SimpleParagraphWidget.ui b2e9adf 
>   plugins/textshape/dialogs/StylesCombo.h PRE-CREATION 
>   plugins/textshape/dialogs/StylesCombo.cpp PRE-CREATION 
>   plugins/textshape/dialogs/StylesComboPreview.h PRE-CREATION 
>   plugins/textshape/dialogs/StylesComboPreview.cpp PRE-CREATION 
>   plugins/textshape/dialogs/StylesDelegate.h f5d216f 
>   plugins/textshape/dialogs/StylesDelegate.cpp d1021f5 
>   plugins/textshape/dialogs/StylesModel.h dbd17b4 
>   plugins/textshape/dialogs/StylesModel.cpp 94deb24 
>   plugins/textshape/dialogs/StylesWidget.cpp 4f31a01 
>   plugins/textshape/dialogs/TableOfContentsStyleModel.cpp 48ee7c3 
> 
> Diff: http://git.reviewboard.kde.org/r/103677/diff/diff
> 
> 
> Testing
> ---
> 
> The functionality exclusively linked to the comboBox seems to be working 
> properly. Some defects have been identified (like no paragraph style is 
> selected at startup), but these are actually outside the scope of this widget 
> and affecting the current widget also.
> 
> 
> Thanks,
> 
> Pierre Stirnweiss
> 
>

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Review Request: Replace the current half baked style selection widgets with a home brewed comboBox

[Pierre Stirnweiss]

> On Jan. 15, 2012, 8:17 p.m., C. Boemann wrote:
> > plugins/textshape/dialogs/SimpleCharacterWidget.cpp, line 131
> > <http://git.reviewboard.kde.org/r/103677/diff/4/?file=46799#file46799line131>
> >
> > = block.charformat
> >
> 
> Pierre Stirnweiss wrote:
> The simpleCharacterWidget doesn't know anything about the current block. 
> However, it seems to work like that.
> 
> C. Boemann wrote:
> No it does not work. I have a simple file where i can see it doesn't 
> work. So we need to figure out a way to get access to this info

Ok, I think I have thought out a way of using the autoStyle stuff in here (bus 
trip to the office can be productive). I'll need to check the feasibility when 
I see the code.
The idea is the following. Chamge the TextTool's signal 
charFormatChanged(QTextCharFormat charFormat) to 
charFormatChanged(QTextCharFormat charFormat, QTextCharFormat blockCharFormat). 
Then the SimpleCharacterWidget (which I think is the sole listener to that 
signal) can call the autoStyle with the current character style (or paragraph 
style) as parent. If the autoStyle is empty, we don't show the + sign, if not, 
then we show the + sign.


- Pierre


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103677/#review9842
-----------


On Jan. 15, 2012, 7:41 p.m., Pierre Stirnweiss wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103677/
> ---
> 
> (Updated Jan. 15, 2012, 7:41 p.m.)
> 
> 
> Review request for Calligra.
> 
> 
> Description
> ---
> 
> Merge request.
> Merge branch textshape_stylesWidget_pierreSt into master.
> The branch provides a replacement for the style selection widgets. The new 
> provided widgets are a subclass of QComboBox.
> They provide a style preview both in the main area and in the dropdown menu.
> The dropdown menu provides a "show style manager" button, which call the 
> whole style management dialog.
> The dropdown also provides a "delete style" button, although this is for the 
> moment disabled/commented out, because deleting a style is not currently 
> really supported.
> The combo also allows to create a style based on the current text format if 
> it does not correspond to the original style (ie. the user changed a 
> property).
> 
> 
> Diffs
> -
> 
>   libs/kotext/KoTextEditor.h 0fc4ff4 
>   libs/kotext/KoTextEditor.cpp 3ef31d6 
>   libs/kotext/styles/KoCharacterStyle.h 898ba43 
>   libs/kotext/styles/KoCharacterStyle.cpp e575b0d 
>   libs/kotext/styles/KoParagraphStyle.h 12ab672 
>   libs/textlayout/CMakeLists.txt af6d64a 
>   libs/textlayout/FrameIterator.h c73d580 
>   libs/textlayout/KoStyleThumbnailer.h 8645089 
>   libs/textlayout/KoStyleThumbnailer.cpp 3529bbb 
>   plugins/textshape/CMakeLists.txt fad7c04 
>   plugins/textshape/TextTool.h 17a687b 
>   plugins/textshape/TextTool.cpp 3ba9d33 
>   plugins/textshape/dialogs/SimpleCharacterWidget.h ad944a5 
>   plugins/textshape/dialogs/SimpleCharacterWidget.cpp 6b2bb66 
>   plugins/textshape/dialogs/SimpleCharacterWidget.ui e4f6d3b 
>   plugins/textshape/dialogs/SimpleParagraphWidget.h bc167b4 
>   plugins/textshape/dialogs/SimpleParagraphWidget.cpp cbfacfe 
>   plugins/textshape/dialogs/SimpleParagraphWidget.ui b2e9adf 
>   plugins/textshape/dialogs/StylesCombo.h PRE-CREATION 
>   plugins/textshape/dialogs/StylesCombo.cpp PRE-CREATION 
>   plugins/textshape/dialogs/StylesComboPreview.h PRE-CREATION 
>   plugins/textshape/dialogs/StylesComboPreview.cpp PRE-CREATION 
>   plugins/textshape/dialogs/StylesDelegate.h f5d216f 
>   plugins/textshape/dialogs/StylesDelegate.cpp d1021f5 
>   plugins/textshape/dialogs/StylesModel.h dbd17b4 
>   plugins/textshape/dialogs/StylesModel.cpp 94deb24 
>   plugins/textshape/dialogs/StylesWidget.cpp 4f31a01 
>   plugins/textshape/dialogs/TableOfContentsStyleModel.cpp 48ee7c3 
> 
> Diff: http://git.reviewboard.kde.org/r/103677/diff/diff
> 
> 
> Testing
> ---
> 
> The functionality exclusively linked to the comboBox seems to be working 
> properly. Some defects have been identified (like no paragraph style is 
> selected at startup), but these are actually outside the scope of this widget 
> and affecting the current widget also.
> 
> 
> Thanks,
> 
> Pierre Stirnweiss
> 
>

___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Review Request: Replace the current half baked style selection widgets with a home brewed comboBox

[Pierre Stirnweiss]

> On Jan. 16, 2012, 6:36 a.m., C. Boemann wrote:
> > I've committed three fixes.
> > 
> > I also note that:
> >  -paragraph combo always has + sign
> >  -default paragraph style should have a name (Default? None?)
> >  -launching stylemanager doesn't launch it with selected style
> >  -the combo should popup nomatter where you click in it (imho)
> > 
> > However I think we have come to the point where this code is better suited 
> > to live in master. There are so many other style issues in master and being 
> > able to work on it all in one place increases productivity. Besides it's a 
> > HUGE improvement already
> > 
> > I would prefer if we don't merge the branch but rather take the entire and 
> > make 2-3 new commits out of it. What do you think.
> >

- Where are the fixes? I don't seem to find them as a new revision of the diff.
- paragraph shows +: In which file is the paragraph always showing a + sign. It 
doesn't here.
- default should have a name: Well, there are both a "Standard" and a "Default" 
paragraph style. There is also a "" one which is selected at the begining. When 
you had your "non-visible" char patch applied, "Standard" was selected in the 
comboBox, as it is the style the template specifies for the blank document. I 
think this problem is outside the scope of the combo. Also when the "Special 
button" was used, nothing was selected ti start with.
- launching style manager: Indeed it doesn't, but in order to do that some 
changes are needed in the styleManager. I didn't want to start with this one on 
top of the comboBox. I was planning on working on the styleManager soon. There 
is also a StylesWidget in it, that needs replacing with a QListView, so we can 
get rid of the StylesWidget altogether.
- combo popup: i wondered about that one too. shouldn't be too hard i guess. 
(like emit the signal in the StylesComboPreview, and connect it in the 
StylesCombo).

About the merging, what would 3 commits bring? I actually doubt we would be 
able to cut this branch in 2-3 self contained (ie compilable and runnable) 
commits without quite a tiresome "git add --interactive" exercise. Everything 
is intertwined. I have made sure the branch compiles and run without major 
problems. I think a complete merge is the safest thing to do.


- Pierre


-------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103677/#review9852
---


On Jan. 15, 2012, 7:41 p.m., Pierre Stirnweiss wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103677/
> ---
> 
> (Updated Jan. 15, 2012, 7:41 p.m.)
> 
> 
> Review request for Calligra.
> 
> 
> Description
> ---
> 
> Merge request.
> Merge branch textshape_stylesWidget_pierreSt into master.
> The branch provides a replacement for the style selection widgets. The new 
> provided widgets are a subclass of QComboBox.
> They provide a style preview both in the main area and in the dropdown menu.
> The dropdown menu provides a "show style manager" button, which call the 
> whole style management dialog.
> The dropdown also provides a "delete style" button, although this is for the 
> moment disabled/commented out, because deleting a style is not currently 
> really supported.
> The combo also allows to create a style based on the current text format if 
> it does not correspond to the original style (ie. the user changed a 
> property).
> 
> 
> Diffs
> -
> 
>   libs/kotext/KoTextEditor.h 0fc4ff4 
>   libs/kotext/KoTextEditor.cpp 3ef31d6 
>   libs/kotext/styles/KoCharacterStyle.h 898ba43 
>   libs/kotext/styles/KoCharacterStyle.cpp e575b0d 
>   libs/kotext/styles/KoParagraphStyle.h 12ab672 
>   libs/textlayout/CMakeLists.txt af6d64a 
>   libs/textlayout/FrameIterator.h c73d580 
>   libs/textlayout/KoStyleThumbnailer.h 8645089 
>   libs/textlayout/KoStyleThumbnailer.cpp 3529bbb 
>   plugins/textshape/CMakeLists.txt fad7c04 
>   plugins/textshape/TextTool.h 17a687b 
>   plugins/textshape/TextTool.cpp 3ba9d33 
>   plugins/textshape/dialogs/SimpleCharacterWidget.h ad944a5 
>   plugins/textshape/dialogs/SimpleCharacterWidget.cpp 6b2bb66 
>   plugins/textshape/dialogs/SimpleCharacterWidget.ui e4f6d3b 
>   plugins/textshape/dialogs/SimpleParagraphWidget.h bc167b4 
>   plugins/textshape/dialogs/SimpleParagraphWidget.cpp cbfacfe 
>   plugins/textshape/dialogs/SimplePar

Re: Setting a final release schedule

[Pierre Stirnweiss]

Oh, you've merged the branch already? Arf, I was looking forward doing this
myself, sort of a good conclusion to a long time spent. Well,...

I've seen also that you changed the textTool to use a blank character style
as a base of the newly created style (if there isn't a base character
style). Isn't this leading to all the properties being set in that style?
And not just the ones differing from the paragraphStyle being used?

PierreSt



On Mon, Jan 16, 2012 at 1:00 PM, C. Boemann  wrote:

> So now the remaining big work has been merged. We still have a lot of
> fixing
> ahead of us, but I feel confident now that as far as Words goes the next
> beta
> will be the last.
>
> That means if we extrapolate that the RC could be tagged 17th February and
> final tagging 2nd March
>
> These dates are naturally subject to our release manager being available
> and
> no other issues popping up, but at least as far as Words go these should be
> safe. (famous last words)
>
> So the public release could be around 9th March
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

mapShape/mapTool causing a crash

[Pierre Stirnweiss]

Hello,

I have a crash on startup because of the mapShape it seems (see backtrace
below). I actually have disabled the comiplation of both maps and mapshape.
Untill yesterday, everything was fine. However now i get a crash on startup
in words.

PierreSt


Application: Words (calligrawords), signal: Segmentation fault

[KCrash Handler]

#6 0xb1a18714 in MapShape::marbleWidget (this=0x0) at
/home/pierre/Hacking/source/calligra_new/plugins/mapshape/MapShape.cpp:202

#7 0xb1a1957e in MapTool::createOptionWidget (this=0x8634698) at
/home/pierre/Hacking/source/calligra_new/plugins/mapshape/MapTool.cpp:112

#8 0xb7369951 in KoToolBase::qt_static_metacall (_o=0x8634698,
_c=QMetaObject::InvokeMetaMethod, _id=8, _a=0xbf9608e4) at
/home/pierre/Hacking/source/calligra_new_build/libs/flake/KoToolBase.moc:76

#9 0xb546e0ff in QMetaObject::activate(QObject*, QMetaObject const*, int,
void**) () from /usr/lib/libQtCore.so.4

#10 0xb732237d in KoCanvasResourceManager::resourceChanged (this=0x84cee50,
_t1=2, _t2=...) at
/home/pierre/Hacking/source/calligra_new_build/libs/flake/KoCanvasResourceManager.moc:99

#11 0xb7321c33 in KoCanvasResourceManager::setResource (this=0x84cee50,
key=2, value=...) at
/home/pierre/Hacking/source/calligra_new/libs/flake/KoCanvasResourceManager.cpp:52

#12 0xb7321f6b in KoCanvasResourceManager::setActiveBorder (this=0x84cee50,
border=...) at
/home/pierre/Hacking/source/calligra_new/libs/flake/KoCanvasResourceManager.cpp:121

#13 0xb2b0258f in StrokeDocker::applyMarkerChanges (this=0x8399540,
position=KoMarkerData::MarkerStart) at
/home/pierre/Hacking/source/calligra_new/plugins/dockers/strokedocker/StrokeDocker.cpp:147

#14 0xb2b028d9 in StrokeDocker::startMarkerChanged (this=0x8399540) at
/home/pierre/Hacking/source/calligra_new/plugins/dockers/strokedocker/StrokeDocker.cpp:202

#15 0xb2b03042 in StrokeDocker::qt_static_metacall (_o=0x8399540,
_c=QMetaObject::InvokeMetaMethod, _id=7, _a=0xbf960a80) at
/home/pierre/Hacking/source/calligra_new_build/plugins/dockers/StrokeDocker.moc:74

#16 0xb546e0ff in QMetaObject::activate(QObject*, QMetaObject const*, int,
void**) () from /usr/lib/libQtCore.so.4

#17 0xb766823d in KoStrokeConfigWidget::currentStartMarkerChanged
(this=0x83898f8) at
/home/pierre/Hacking/source/calligra_new_build/libs/widgets/KoStrokeConfigWidget.moc:153

#18 0xb7667f4f in KoStrokeConfigWidget::qt_static_metacall (_o=0x83898f8,
_c=QMetaObject::InvokeMetaMethod, _id=5, _a=0xbf960bc8) at
/home/pierre/Hacking/source/calligra_new_build/libs/widgets/KoStrokeConfigWidget.moc:70

#19 0xb546e0ff in QMetaObject::activate(QObject*, QMetaObject const*, int,
void**) () from /usr/lib/libQtCore.so.4

#20 0xb5efd085 in QComboBox::currentIndexChanged(int) () from
/usr/lib/libQtGui.so.4

#21 0xb5efd11f in ?? () from /usr/lib/libQtGui.so.4

#22 0xb5efd40b in ?? () from /usr/lib/libQtGui.so.4

#23 0xb5efd526 in QComboBox::setCurrentIndex(int) () from
/usr/lib/libQtGui.so.4

#24 0xb5efdd08 in QComboBox::setModel(QAbstractItemModel*) () from
/usr/lib/libQtGui.so.4

#25 0xb7685ca3 in KoMarkerSelector::updateMarkers (this=0x834bb88,
markers=...) at
/home/pierre/Hacking/source/calligra_new/libs/widgets/KoMarkerSelector.cpp:107

#26 0xb7667c80 in KoStrokeConfigWidget::updateMarkers (this=0x83898f8,
markers=...) at
/home/pierre/Hacking/source/calligra_new/libs/widgets/KoStrokeConfigWidget.cpp:274

#27 0xb2b02e47 in StrokeDocker::setCanvas (this=0x8399540,
canvas=0x84cec7c) at
/home/pierre/Hacking/source/calligra_new/plugins/dockers/strokedocker/StrokeDocker.cpp:276

#28 0xb736c061 in KoCanvasControllerWidget::Private::activate
(this=0x84d2868) at
/home/pierre/Hacking/source/calligra_new/libs/flake/KoCanvasControllerWidget.cpp:200

#29 0xb736c5c8 in KoCanvasControllerWidget::activate (this=0x84d0108) at
/home/pierre/Hacking/source/calligra_new/libs/flake/KoCanvasControllerWidget.cpp:261

#30 0xb73809de in KoToolManager::Private::attachCanvas (this=0x84cf5d0,
controller=0x84d011c) at
/home/pierre/Hacking/source/calligra_new/libs/flake/KoToolManager.cpp:509

#31 0xb7382ccf in KoToolManager::addController (this=0x84cf570,
controller=0x84d011c) at
/home/pierre/Hacking/source/calligra_new/libs/flake/KoToolManager.cpp:822

#32 0xb2b7f921 in KWGui::KWGui (this=0x84bc4d8, viewMode=...,
parent=0x836a3a0) at
/home/pierre/Hacking/source/calligra_new/words/part/KWGui.cpp:68

#33 0xb2b81164 in KWView::KWView (this=0x836a3a0, viewMode=...,
document=0x821bce0, parent=0x81dd880, __in_chrg=,
__vtt_parm=) at
/home/pierre/Hacking/source/calligra_new/words/part/KWView.cpp:114

#34 0xb2b76c85 in KWDocument::createViewInstance (this=0x821bce0,
parent=0x81dd880) at
/home/pierre/Hacking/source/calligra_new/words/part/KWDocument.cpp:217

#35 0xb77173c7 in KoDocument::createView (this=0x821bce0, parent=0x81dd880)
at /home/pierre/Hacking/source/calligra_new/libs/main/KoDocument.cpp:438

#36 0xb773ff9f in KoMainWindow::setRootDocument (this=0x81dd880,
doc=0x821bce0) at
/home/pierre/Hacking/source/calligra_new/libs/main/KoMainWindow.c

Re: release plan and request for merge

[Pierre Stirnweiss]

When I checked out the branch yesterday evening, the
KoTextEditor_format.cpp file was missing. This also meant that I couldn't
test the trick for the insertTable method. It wouldn't compile.

Pierre

On Thu, Feb 23, 2012 at 10:27 AM, C. Boemann  wrote:

> Hi all
>
> So the minisprint on undo in Words is over and we had success. I'm
> requesting
> merge of our branch but more on that below.
>
> Assuming we merge within a day or two, I propose we create a release branch
> one of the next days. And on next friday we tag an RC from that release
> branch. Then 3 weeks and tag the final.
>
> As for the merging of the text-undo-minisprint branch Pierre and I worked
> mostly in tandem so we have had constant peer review. However sitting so
> close
> we could be the victim of group-think so I would be glad if someone else
> could
> look through the branch. Creating a review request, can be done but since
> we
> have like moved everything it doesn't make much sense.
>
> Best regards
> C. Boemann
> ___
> calligra-devel mailing list
> calligra-devel@kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel