Re: Review Request: Add support for footnote's continuation

2012-02-23 Thread C. Boemann 

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


Trying it out interactively it's not up to the job yet. It writes text on top 
of text and doesn't create a new page.
We are also too close to RC and this is really a new feature, so I'm sory but 
this will have to wait until 2.5

Contact me on irc for details about what the problems I see are.


libs/textlayout/KoTextLayoutArea.cpp


i'm not sure the layout logic is strong enough here.





plugins/textshape/ReferencesTool.cpp





- C. Boemann


On Feb. 22, 2012, 7:05 p.m., Brijesh Patel wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104043/
> ---
> 
> (Updated Feb. 22, 2012, 7:05 p.m.)
> 
> 
> Review request for Calligra.
> 
> 
> Description
> ---
> 
> This patch adds a feature, continuation of footnotes on next page when 
> there's no space to fit on the same page, as part of footnote's configuration.
> 
> 
> Diffs
> -
> 
>   libs/odf/KoOdfNotesConfiguration.cpp 7a2ca81 
>   libs/textlayout/KoTextDocumentLayout.cpp 17192cb 
>   libs/textlayout/KoTextLayoutArea.h f919170 
>   libs/textlayout/KoTextLayoutArea.cpp 8700f11 
>   libs/textlayout/KoTextLayoutEndNotesArea.cpp c145e6e 
>   libs/textlayout/KoTextLayoutNoteArea.h 2b5178b 
>   libs/textlayout/KoTextLayoutNoteArea.cpp 92d63c6 
>   plugins/textshape/ReferencesTool.cpp 025b650 
>   plugins/textshape/dialogs/NotesConfigurationDialog.cpp 4e6f6d3 
> 
> Diff: http://git.reviewboard.kde.org/r/104043/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Brijesh Patel
> 
>

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

release plan and request for merge

2012-02-23 Thread C. Boemann 
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

Re: release plan and request for merge

2012-02-23 Thread 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

Re: release plan and request for merge

2012-02-23 Thread C. Boemann 
yes i commited the missing file late last night

On Thursday 23 February 2012 10:48:55 Pierre Stirnweiss wrote:
> 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

Re: release plan and request for merge

2012-02-23 Thread Elvis Stansvik 
2012/2/23 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.

It was a small miss by boemann. It's been added now.

Elvis

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

Re: release plan and request for merge

2012-02-23 Thread Elvis Stansvik 
2012/2/23 C. Boemann :
> 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.

Glad to hear the sprint was a success.

I'm definitely not savvy enough with the code and don't know enough
about the problems you've been solving to do a thorough review, so I
just have a few nitpicks:

 const QUrl KoTextDocument::FrameCharFormatUrl =
QUrl("kotext://frameCharFormat");
+const QUrl KoTextDocument::ShapeControllerURL =
QUrl("kotext://shapeController");

s/URL/Url/

+IndexGeneratorManager ,
+FrameCharFormat ,
+ShapeController

s/ ,/,/

-void KoTextEditor::deleteChar(MoveOperation direction,
KoShapeController *shapeController)
+void KoTextEditor::deleteChar(bool previous, KUndo2Command *parent)

Why change from enum -> bool for the direction here? IMHO enum tells a
richer story when you're looking at a random call deleteChar
somewhere, even though it'll just be two values.

+d->updateState(KoTextEditor::Private::Custom,
i18nc("(qtundo-format)", "Insert Footnote"));
+}
+else {

"else" on same line as }. (Same in a few other places to which it has
probably propagated through cut/paste).

+int inCustomCommand;

The name sounds like a bool but it's a counter of some sort (a
level?), can it be improved?

+kDebug(32500) << "commandStack is now: " << commandStack.count();
+}
+else if (addNewCommand) {

else's in this construct on same line as {.

+textData =
qobject_cast(oldParent->userData());
+} else  if (container) {

s/  / /

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

Re: release plan and request for merge

2012-02-23 Thread Thorsten Zachmann 
On Thursday, February 23, 2012 10:27:38 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.

Good to hear.

> 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.

Can you please create a review request. I find it much easier to look at that.

Thanks,

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

Review Request: Undo redo framework for text refactored

2012-02-23 Thread C. Boemann 

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

Review request for Calligra.


Description
---

We have made changes to the undo framework in kotexteditor to make things work.
The DeleteCommand has become much more capable as it handles complex selections 
and bookmarks now
The KoTextEditor.cpp file has been split out into 3 files
The StyleChange commands and shapeAnchoring commands have been adapted to the 
new frame work


Diffs
-

  libs/flake/KoShapeController.h abc4358 
  libs/flake/commands/KoShapeDeleteCommand.cpp 519f047 
  libs/kotext/CMakeLists.txt 567649b 
  libs/kotext/KoTextDocument.h 56f55e6 
  libs/kotext/KoTextDocument.cpp 5608860 
  libs/kotext/KoTextEditor.h 689051b 
  libs/kotext/KoTextEditor.cpp 3c141c7 
  libs/kotext/KoTextEditor_format.cpp PRE-CREATION 
  libs/kotext/KoTextEditor_p.h 77725f3 
  libs/kotext/KoTextEditor_undo.cpp PRE-CREATION 
  libs/kotext/commands/ChangeAnchorPropertiesCommand.h 4206bb8 
  libs/kotext/commands/ChangeAnchorPropertiesCommand.cpp 7d4b912 
  libs/kotext/commands/ChangeStylesCommand.h accfd31 
  libs/kotext/commands/ChangeStylesCommand.cpp b9fa725 
  libs/kotext/commands/ChangeStylesMacroCommand.cpp 34c3822 
  libs/kotext/commands/ChangeTrackedDeleteCommand.cpp 89edde1 
  libs/kotext/commands/DeleteAnchorsCommand.cpp 621829f 
  libs/kotext/commands/DeleteCommand.h 89b448a 
  libs/kotext/commands/DeleteCommand.cpp 2a4527d 
  libs/kotext/commands/TextPasteCommand.cpp 6b9de68 
  libs/kotext/tests/TestKoTextEditor.cpp bd15b3a 
  libs/kundo2/kundo2stack.h c0539fe 
  libs/kundo2/kundo2stack.cpp 48d6625 
  libs/main/rdf/KoSemanticStylesheet.cpp 7853dd0 
  libs/main/tests/rdf_test.cpp fb57a5e 
  plugins/textshape/TextTool.cpp ddfe47f 
  plugins/textshape/commands/TextCutCommand.cpp bdb8eea 
  words/part/KWDocument.h 0005bc6 
  words/part/KWDocument.cpp 8e00cb6 
  words/part/dialogs/KWAnchoringProperties.cpp c742e26 
  words/part/dialogs/KWFrameDialog.cpp 0fcc0b7 
  words/part/frames/KWTextFrameSet.cpp ebd532f 

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


Testing
---

We have played around with undo redo in all the cases we knew were failing and 
quite a lot of other tests.
Undo of many things are still not implemented, but that is not really what this 
is about. It's about the basic undo, and getting the framework right. Fixing 
undo of individual stuff can always be done as bug fixes
One issue we have noted is insertion of table, whic we believe is a qt bug. We 
have one last workaround in our minds, but other than that we will just have to 
wait for a qt fix


Thanks,

C. Boemann

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

Re: How to easily validate an OpenDocument file (or: where is "oasisfilecheck"?)

2012-02-23 Thread Friedrich W. H. Kossebau 
Am Mittwoch, 22. Februar 2012, 22:50:34 schrieb Jos van den Oever:
> On Wednesday 22 February 2012 20:57:17 PM Friedrich W. H. Kossebau wrote:
> > Hi,
> > 
> > I would like to validate the odg files I create with my CDRv4 import
> > filter. Searching for a validator I found
> > 
> > http://community.kde.org/Calligra/KOffice_and_ODF#Validation
> > 
> > which references "oasisfilecheck" and "oasislint". But the link given is
> > out- dated (http://www.koffice.org/developer/fileformat/validate.php). And
> > I also did not see them in the repo.
> > 
> > That page also points to
> > 
> > http://opendocumentfellowship.com/validator
> > 
> > but which seems not to exist for me?
> > 
> > http://wiki.oasis-open.org/office/How_to_Validate_an_ODF_document also
> > only
> > links to the old koffice.org page.
> > 
> > So, where is "oasisfilecheck"? Anyone could help me here?
> 
> You can use calligra/tools/scripts/validateODF.py.

Thanks Jos, using that now, works fine for me (and of course it found errors 
:) )

Going to update the community wiki page now...
Friedrich
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: GSoC idea

2012-02-23 Thread Sebastian Sauer 

On 02/23/2012 01:31 PM, Smit Patel wrote:

Hi everyone,

I'd like to propose a GSoC project. Here's the brief description about 
project idea.
Provide a dbus API that provides an generic interface that can be used 
by external bibliography engines (xbiblio, kbibtex, bibus)


dbus is optional[1] and so would be everything that depends on it. So, 
why dbus? Why not just a plugin? If it should be in another process 
(stability, long-running things, shared among Words-processes, etc) then 
why not for example QLocalServer?


Calligra words doesn't have a good way to manage references. These 
engines can manage references and insert bibliography using interface 
provided.


Guess there would be quit some work needed in core-code to make it 
proper update references on loading/saving/editing. Does what ODF 
specifies cover what you propose? If yes then it should maybe not be 
optional and no be available for so many platforms[1]. If not then how 
to you plan to keep interoperability? I think your proposal includes 
loading/saving?




I like comments and hints for this project idea.



I like the idea (except the dbus-part) and while I think there are many 
things that could be done within a gsoc and have a higher priority I 
think it would make a good gsoc-proposal.


[1] not available on Symbian, Android, OSX and Windows at least

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

Re: GSoC idea

2012-02-23 Thread Jaroslaw Staniek 
On 23 February 2012 13:31, Smit Patel  wrote:
> Hi everyone,
>
> I'd like to propose a GSoC project. Here's the brief description about
> project idea.
> Provide a dbus API that provides an generic interface that can be used by
> external bibliography engines (xbiblio, kbibtex, bibus)
> Calligra words doesn't have a good way to manage references. These engines
> can manage references and insert bibliography using interface provided.

Hello,
That's nice idea. First question - would you see this as a project
emploing databases (e.g. SQLite) and adding some GUIs?
If so I am proposing a high-level layer on top of Calligra, i.e. used
by Kexi (KexiDB/Predicate), because regardless of what are your ideas,
Kexi _eventually_ will have bibliography module written in Kexi
itself, just like LibreOffice's bibligraphy is implemented on top of
LibreOffice (Base) foundations itself.

Regarding dbus I am not sure it is so useful as data
sharing/transmitting layer, it's an IPC after all. It's not like ODBC
and never was designed for this. From time to time I see such attempts
to relate these two distinct tools.

Moreover, a better approach at the moment would be to discuss what
'good managing references' means for us, and not such a detail as
IPC/storage. I mentioned Predicate only because of assumed integration
with Calligra, to show that there're tools in hand already available.

-- 
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

Re: release plan and request for merge

2012-02-23 Thread Jaroslaw Staniek 
On 23 February 2012 10:27, 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.

Hi, As always, please update official plan
http://community.kde.org/Calligra/Schedules/2.4/Release_Plan if needed

-- 
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

Karbon or Karbon14?

2012-02-23 Thread Friedrich W. H. Kossebau 
Hi,

IIRC the official name of Karbon14 is now (Calligra) Karbon. But in the 
sources (including the .desktop files) the name is still Karbon14. Something 
inside me wants to fix this :)

Okay if I provide a patch to change the name from "Karbon14" to "Karbon" in 
all places left?

Cheers
Friedrich

PS: Have I already told how awesome I find Karbon? So far whatever I created 
as ODG file was nicely displayed, as expected! Only now I might have found the 
first bug (x y attributes in tspan ignored, but have to check this).
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Karbon or Karbon14?

2012-02-23 Thread Boudewijn Rempt 

On Thu, 23 Feb 2012, Friedrich W. H. Kossebau wrote:


Hi,

IIRC the official name of Karbon14 is now (Calligra) Karbon. But in the
sources (including the .desktop files) the name is still Karbon14. Something
inside me wants to fix this :)

Okay if I provide a patch to change the name from "Karbon14" to "Karbon" in
all places left?


That's for Jan to say, I wouldn't object though.



Cheers
Friedrich

PS: Have I already told how awesome I find Karbon? So far whatever I created
as ODG file was nicely displayed, as expected! Only now I might have found the
first bug (x y attributes in tspan ignored, but have to check this).


Great to hear!


___
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: Karbon or Karbon14?

2012-02-23 Thread C. Boemann 
On Thursday 23 February 2012 15:40:04 Boudewijn Rempt wrote:
> On Thu, 23 Feb 2012, Friedrich W. H. Kossebau wrote:
> > Hi,
> > 
> > IIRC the official name of Karbon14 is now (Calligra) Karbon. But in the
> > sources (including the .desktop files) the name is still Karbon14.
> > Something inside me wants to fix this :)
> > 
> > Okay if I provide a patch to change the name from "Karbon14" to "Karbon"
> > in all places left?
> 
> That's for Jan to say, I wouldn't object though.
Indeed for Jan to decide, But yeah Karbon14 is never used in conversation or 
blogs or anything, so it will cause confusion if we keep it. Besides Karbon14 
sounds too geekish for my taste anyway.
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Karbon or Karbon14?

2012-02-23 Thread Boudewijn Rempt 

On Thu, 23 Feb 2012, C. Boemann wrote:


On Thursday 23 February 2012 15:40:04 Boudewijn Rempt wrote:

On Thu, 23 Feb 2012, Friedrich W. H. Kossebau wrote:

Hi,

IIRC the official name of Karbon14 is now (Calligra) Karbon. But in the
sources (including the .desktop files) the name is still Karbon14.
Something inside me wants to fix this :)

Okay if I provide a patch to change the name from "Karbon14" to "Karbon"
in all places left?


That's for Jan to say, I wouldn't object though.



Indeed for Jan to decide, But yeah Karbon14 is never used in conversation or
blogs or anything, so it will cause confusion if we keep it. Besides Karbon14
sounds too geekish for my taste anyway.


Oh for those wonderful days of yesteryear, when geeks were still geeks and 
small furry creatures from alpha centauri were still real small furry 
creatures from alpha centauri! Life was easier, then, and the grass was 
greener, also the beer cheaper, and for a penny we'd walk to school and 
back, uphill both times!


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

Re: Karbon or Karbon14?

2012-02-23 Thread Friedrich W. H. Kossebau 
Am Donnerstag, 23. Februar 2012, 15:44:08 schrieb C. Boemann:
> On Thursday 23 February 2012 15:40:04 Boudewijn Rempt wrote:
> > On Thu, 23 Feb 2012, Friedrich W. H. Kossebau wrote:
> > > Hi,
> > > 
> > > IIRC the official name of Karbon14 is now (Calligra) Karbon. But in the
> > > sources (including the .desktop files) the name is still Karbon14.
> > > Something inside me wants to fix this :)
> > > 
> > > Okay if I provide a patch to change the name from "Karbon14" to "Karbon"
> > > in all places left?
> > 
> > That's for Jan to say, I wouldn't object though.
> 
> Indeed for Jan to decide, But yeah Karbon14 is never used in conversation or
> blogs or anything, so it will cause confusion if we keep it. Besides
> Karbon14 sounds too geekish for my taste anyway.

I must confess I like the name Karbon14 more, for various reasons :)

But e.g. calligra.org gave me the impression the new name was already decided 
on during the Great Rename. So, may Jan decide (/me hopes for Karbon14 now 
again ;) ).

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

Re: Karbon or Karbon14?

2012-02-23 Thread C. Boemann 
On Thursday 23 February 2012 15:55:46 Friedrich W. H. Kossebau wrote:
> Am Donnerstag, 23. Februar 2012, 15:44:08 schrieb C. Boemann:
> > On Thursday 23 February 2012 15:40:04 Boudewijn Rempt wrote:
> > > On Thu, 23 Feb 2012, Friedrich W. H. Kossebau wrote:
> > > > Hi,
> > > > 
> > > > IIRC the official name of Karbon14 is now (Calligra) Karbon. But in
> > > > the sources (including the .desktop files) the name is still
> > > > Karbon14. Something inside me wants to fix this :)
> > > > 
> > > > Okay if I provide a patch to change the name from "Karbon14" to
> > > > "Karbon" in all places left?
> > > 
> > > That's for Jan to say, I wouldn't object though.
> > 
> > Indeed for Jan to decide, But yeah Karbon14 is never used in conversation
> > or blogs or anything, so it will cause confusion if we keep it. Besides
> > Karbon14 sounds too geekish for my taste anyway.
> 
> I must confess I like the name Karbon14 more, for various reasons :)
> 
> But e.g. calligra.org gave me the impression the new name was already
> decided on during the Great Rename. So, may Jan decide (/me hopes for
> Karbon14 now again ;) ).
> 
Geek ! ;)
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: GSoC idea

2012-02-23 Thread Smit Patel 
On Thu, Feb 23, 2012 at 3:36 PM, Sebastian Sauer  wrote:

> **
> On 02/23/2012 01:31 PM, Smit Patel wrote:
>
> Hi everyone,
>
> I'd like to propose a GSoC project. Here's the brief description about
> project idea.
> Provide a dbus API that provides an generic interface that can be used by
> external bibliography engines (xbiblio, kbibtex, bibus)
>
>
> dbus is optional[1] and so would be everything that depends on it. So, why
> dbus? Why not just a plugin? If it should be in another process (stability,
> long-running things, shared among Words-processes, etc) then why not for
> example QLocalServer?
>

If dbus is not available for windows and OSX then we can rule that out. We
can consider what bibliography engines like bibus, kbibtex etc are using
for the same thing with LO and MS Office. For other options I haven't try
studying them in detail. We'll discuss about it on IRC.

>  Calligra words doesn't have a good way to manage references. These
> engines can manage references and insert bibliography using interface
> provided.
>
>
> Guess there would be quit some work needed in core-code to make it proper
> update references on loading/saving/editing. Does what ODF specifies cover
> what you propose? If yes then it should maybe not be optional and no be
> available for so many platforms[1]. If not then how to you plan to keep
> interoperability? I think your proposal includes loading/saving?
>

Yes. I need to change some core-code but bibliography engine is in place.
So it won't be a big problem. I think the confusion is because I haven't
merged my branch words-references-bibliography-smit with master. My branch
has all the changes done so far for bibliography support.

>  I like comments and hints for this project idea.
>
>
> I like the idea (except the dbus-part) and while I think there are many
> things that could be done within a gsoc and have a higher priority I think
> it would make a good gsoc-proposal.
>
> [1] not available on Symbian, Android, OSX and Windows at least
>
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: GSoC idea

2012-02-23 Thread Boudewijn Rempt 
On Thursday 23 February 2012 Feb, Smit Patel wrote:
> On Thu, Feb 23, 2012 at 3:36 PM, Sebastian Sauer  wrote:
> 
> > **
> > On 02/23/2012 01:31 PM, Smit Patel wrote:
> >
> > Hi everyone,
> >
> > I'd like to propose a GSoC project. Here's the brief description about
> > project idea.
> > Provide a dbus API that provides an generic interface that can be used by
> > external bibliography engines (xbiblio, kbibtex, bibus)
> >
> >
> > dbus is optional[1] and so would be everything that depends on it. So, why
> > dbus? Why not just a plugin? If it should be in another process (stability,
> > long-running things, shared among Words-processes, etc) then why not for
> > example QLocalServer?
> >
> 
> If dbus is not available for windows and OSX then we can rule that out.

Well, actually dbus _is_ available on both Windows and OSX. It's just a bit of 
a bother on Windows and rather a big bother on OSX.

-- 
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

Re: GSoC idea

2012-02-23 Thread Smit Patel 
On Thu, Feb 23, 2012 at 3:47 PM, Jaroslaw Staniek  wrote:

> On 23 February 2012 13:31, Smit Patel  wrote:
> > Hi everyone,
> >
> > I'd like to propose a GSoC project. Here's the brief description about
> > project idea.
> > Provide a dbus API that provides an generic interface that can be used by
> > external bibliography engines (xbiblio, kbibtex, bibus)
> > Calligra words doesn't have a good way to manage references. These
> engines
> > can manage references and insert bibliography using interface provided.
>
> Hello,
> That's nice idea. First question - would you see this as a project
> emploing databases (e.g. SQLite) and adding some GUIs?

No. But this has to be done for sure (not necessarily part of this GSoC
project).

> If so I am proposing a high-level layer on top of Calligra, i.e. used
> by Kexi (KexiDB/Predicate), because regardless of what are your ideas,
> Kexi _eventually_ will have bibliography module written in Kexi
> itself, just like LibreOffice's bibligraphy is implemented on top of
> LibreOffice (Base) foundations itself.
>
> Regarding dbus I am not sure it is so useful as data
> sharing/transmitting layer, it's an IPC after all. It's not like ODBC
> and never was designed for this. From time to time I see such attempts
> to relate these two distinct tools.
>
Think dbus as a way of doing RPC. But now dbus/RPC is not the concern.

>
> Moreover, a better approach at the moment would be to discuss what
> 'good managing references' means for us, and not such a detail as
> IPC/storage. I mentioned Predicate only because of assumed integration
> with Calligra, to show that there're tools in hand already available.
>
> --
> 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: Karbon or Karbon14?

2012-02-23 Thread Algot Runeman 

On 02/23/2012 09:44 AM, C. Boemann wrote:

On Thursday 23 February 2012 15:40:04 Boudewijn Rempt wrote:

On Thu, 23 Feb 2012, Friedrich W. H. Kossebau wrote:

Hi,

IIRC the official name of Karbon14 is now (Calligra) Karbon. But in the
sources (including the .desktop files) the name is still Karbon14.
Something inside me wants to fix this :)

Okay if I provide a patch to change the name from "Karbon14" to "Karbon"
in all places left?

That's for Jan to say, I wouldn't object though.

Indeed for Jan to decide, But yeah Karbon14 is never used in conversation or
blogs or anything, so it will cause confusion if we keep it. Besides Karbon14
sounds too geekish for my taste anyway.
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

It might be worth looking at the main page of the Web site: 
http://www.calligra.org/karbon/

The images on at least that page say Karbon 14.
--Algot (a lurking user wannabe, patiently but eagerly awaiting the release)


--
-
Algot Runeman
47 Walnut Street, Natick MA 01760
508-655-8399
algot.rune...@verizon.net
Web Site: http://www.runeman.org
Twitter: http://twitter.com/algotruneman/
sip:algot.rune...@ekiga.net
Open Source Blog: http://mosssig.wordpress.com
MOSS SIG Mailing List: http://groups.google.com/group/mosssig2

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

Re: GSoC idea

2012-02-23 Thread Jaroslaw Staniek 
On 23 February 2012 19:56, Smit Patel  wrote:
>
> On Thu, Feb 23, 2012 at 3:47 PM, Jaroslaw Staniek  wrote:
>>
>> On 23 February 2012 13:31, Smit Patel  wrote:
>> > Hi everyone,
>> >
>> > I'd like to propose a GSoC project. Here's the brief description about
>> > project idea.
>> > Provide a dbus API that provides an generic interface that can be used
>> > by
>> > external bibliography engines (xbiblio, kbibtex, bibus)
>> > Calligra words doesn't have a good way to manage references. These
>> > engines
>> > can manage references and insert bibliography using interface provided.
>>
>> Hello,
>> That's nice idea. First question - would you see this as a project
>> emploing databases (e.g. SQLite) and adding some GUIs?
>
> No. But this has to be done for sure (not necessarily part of this GSoC
> project).

I see. Then what do you thing would be the main part if not the
backend or the data abstraction with sharing interface? GUIs?

-- 
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

Re: GSoC idea

2012-02-23 Thread Smit Patel 
On Fri, Feb 24, 2012 at 2:26 AM, Jaroslaw Staniek  wrote:

> On 23 February 2012 19:56, Smit Patel  wrote:
> >
> > On Thu, Feb 23, 2012 at 3:47 PM, Jaroslaw Staniek 
> wrote:
> >>
> >> On 23 February 2012 13:31, Smit Patel  wrote:
> >> > Hi everyone,
> >> >
> >> > I'd like to propose a GSoC project. Here's the brief description about
> >> > project idea.
> >> > Provide a dbus API that provides an generic interface that can be used
> >> > by
> >> > external bibliography engines (xbiblio, kbibtex, bibus)
> >> > Calligra words doesn't have a good way to manage references. These
> >> > engines
> >> > can manage references and insert bibliography using interface
> provided.
> >>
> >> Hello,
> >> That's nice idea. First question - would you see this as a project
> >> emploing databases (e.g. SQLite) and adding some GUIs?
> >
> > No. But this has to be done for sure (not necessarily part of this GSoC
> > project).
>
> I see. Then what do you thing would be the main part if not the
> backend or the data abstraction with sharing interface? GUIs?
>
Main part of the project will be providing an API that provides an
interface that is specifically geared towards bibliography engines like
bibus[1], kbibtex [2] . While still being generic enough that different
citation tools can all use it.

[1] http://bibus-biblio.sourceforge.net/wiki/index.php/Main_Page
[2] http://www.unix-ag.uni-kl.de/~fischer/kbibtex/

>
> --
> 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: Karbon or Karbon14?

2012-02-23 Thread jaham 
On Thursday 23 February 2012 15:37:59 Friedrich W. H. Kossebau wrote:
> Hi,
> 
> IIRC the official name of Karbon14 is now (Calligra) Karbon. But in the
> sources (including the .desktop files) the name is still Karbon14. Something
> inside me wants to fix this :)
> 
> Okay if I provide a patch to change the name from "Karbon14" to "Karbon" in
> all places left?
> 

Yeah I think nobody is calling it Karbon14, it is too bothersome to call it 
like that. However I am not sure about it, but I think the name was chosen to 
avoid any legal/trademark issues which might come up (i.e. not to repeat 
history as with the KIllustrator name).
So to sum it up, i would prefer dropping the 14 and just call it Karbon (which 
we all do already), provided nobody thinks we might get into any legal 
trouble.


> Cheers
> Friedrich
> 
> PS: Have I already told how awesome I find Karbon? So far whatever I created
> as ODG file was nicely displayed, as expected! Only now I might have found
> the first bug (x y attributes in tspan ignored, but have to check this).

Thanks for you kind words, it is highly appreciated!
Regarding the bug, that refers to the svg:tspan child element from svg:text, 
right? It should support the x and y attributes, but I am sure there are still 
issues with that, so might be a real bug. 

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

Re: GSoC idea

2012-02-23 Thread Sebastian Sauer 

On 02/23/2012 05:59 PM, Boudewijn Rempt wrote:

On Thursday 23 February 2012 Feb, Smit Patel wrote:

On Thu, Feb 23, 2012 at 3:36 PM, Sebastian Sauer  wrote:


**
On 02/23/2012 01:31 PM, Smit Patel wrote:

Hi everyone,

I'd like to propose a GSoC project. Here's the brief description about
project idea.
Provide a dbus API that provides an generic interface that can be used by
external bibliography engines (xbiblio, kbibtex, bibus)


dbus is optional[1] and so would be everything that depends on it. So, why
dbus? Why not just a plugin? If it should be in another process (stability,
long-running things, shared among Words-processes, etc) then why not for
example QLocalServer?


If dbus is not available for windows and OSX then we can rule that out.

Well, actually dbus _is_ available on both Windows and OSX.
1. re Windows; Not per default what means you need to ship your own 
version of it in the installer. If any app does that then it completely 
voids what dbus is for. dbus is and always will be be an alien on that 
platforms cause all other software is using the native IPC mechanism. 
You end with an IPC only used by you (not exactly what it is for) and 
even more worse, you exclude yourself from the outer world by shipping 
something own.


2. re OSX; my knowledge is a few years old but back then when I hacked 
on dbus making it running at >=Vista I did not found a single line of 
code that handles OSX. But I can imagine that it changed meanwhile. In 
any case I doubt it's well maintained and it definitively is not straith 
forward to work on that code-base.



It's just a bit of a bother on Windows and rather a big bother on OSX.


And here I ask myself why we should bother at all? What gain does this 
bring to Calligra? I would say exactly zero, none, null, nil, nada.


But yes, technical it should be possible to just port dbus to e.g. 
Symbian, Android, OSX, QNX, etc. pp. It's just not related to Calligra.


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

Re: GSoC idea

2012-02-23 Thread Sebastian Sauer 

On 02/23/2012 05:52 PM, Smit Patel wrote:


On Thu, Feb 23, 2012 at 3:36 PM, Sebastian Sauer > wrote:


On 02/23/2012 01:31 PM, Smit Patel wrote:

Hi everyone,

I'd like to propose a GSoC project. Here's the brief description
about project idea.
Provide a dbus API that provides an generic interface that can be
used by external bibliography engines (xbiblio, kbibtex, bibus)


dbus is optional[1] and so would be everything that depends on it.
So, why dbus? Why not just a plugin? If it should be in another
process (stability, long-running things, shared among
Words-processes, etc) then why not for example QLocalServer?

If dbus is not available for windows and OSX then we can rule that 
out. We can consider what bibliography engines like bibus, kbibtex etc 
are using for the same thing with LO and MS Office.


I just had a quick look at xbiblio, kbibtex:and bibus. Am I right that 
none of them comes with a dbus daemon? So, I seriously ask myself why 
you like to drag dbus in? Why not just do it the same way it's done in 
e.g. Kile (I assume linking against a lib)?


I just bring up the topic cause your proposal explicit names dbus but 
does not name a reason why and for what. So, I suggest to either make 
very clear in your proposal for what and why you will use dbus XOR 
change the proposal do not make that given but turn it into something 
you need to investigate/research during the gsoc-time to see if that's 
the best approach. So, something like "investigate and research 
technology-choices to integrate bibliography engines like xbiblio, 
kbibtex and bibus into Calligra".


For other options I haven't try studying them in detail. We'll discuss 
about it on IRC.



Calligra words doesn't have a good way to manage references.
These engines can manage references and insert bibliography using
interface provided.


Guess there would be quit some work needed in core-code to make it
proper update references on loading/saving/editing. Does what ODF
specifies cover what you propose? If yes then it should maybe not
be optional and no be available for so many platforms[1]. If not
then how to you plan to keep interoperability? I think your
proposal includes loading/saving?


Yes. I need to change some core-code but bibliography engine is in 
place. So it won't be a big problem. I think the confusion is because 
I haven't merged my branch words-references-bibliography-smit with 
master. My branch has all the changes done so far for bibliography 
support.


Ah, good to know[1] :) I would definitively add to your proposal 
references of the work you did already. Its a *huge* advantage your 
proposal has over all other proposals that you already did some of the 
work. So, imho your proposal should include some words what you have 
already and how exactly you like to spend the gsoc-time to improve that.


[1] Well, I did know you worked on that topic before but have no clue in 
what state that work is. Means what is done and what you like to do 
during the gsoc-time. But yes, that's maybe a bit to much input for a 
first "gsoc idea" mail but more material for the final proposal. In any 
case lot of thanks for hacking on that important topic!


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

Re: GSoC idea

2012-02-23 Thread Sebastian Sauer 

On 02/24/2012 05:33 AM, Sebastian Sauer wrote:

On 02/23/2012 05:59 PM, Boudewijn Rempt wrote:

On Thursday 23 February 2012 Feb, Smit Patel wrote:

On Thu, Feb 23, 2012 at 3:36 PM, Sebastian Sauer  wrote:


**
On 02/23/2012 01:31 PM, Smit Patel wrote:

Hi everyone,

I'd like to propose a GSoC project. Here's the brief description about
project idea.
Provide a dbus API that provides an generic interface that can be 
used by

external bibliography engines (xbiblio, kbibtex, bibus)


dbus is optional[1] and so would be everything that depends on it. 
So, why
dbus? Why not just a plugin? If it should be in another process 
(stability,
long-running things, shared among Words-processes, etc) then why 
not for

example QLocalServer?


If dbus is not available for windows and OSX then we can rule that out.

Well, actually dbus _is_ available on both Windows and OSX.
1. re Windows; Not per default what means you need to ship your own 
version of it in the installer. If any app does that then it 
completely voids what dbus is for. dbus is and always will be be an 
alien on that platforms cause all other software is using the native 
IPC mechanism. You end with an IPC only used by you (not exactly what 
it is for) and even more worse, you exclude yourself from the outer 
world by shipping something own.


2. re OSX; my knowledge is a few years old but back then when I hacked 
on dbus making it running at >=Vista I


As extension; the core-work on that was done by our KDE@Windows folks 
who did all the amazing work to bring dbus to Windows. I just did 
contribute some patches on top.


did not found a single line of code that handles OSX. But I can 
imagine that it changed meanwhile. In any case I doubt it's well 
maintained and it definitively is not straith forward to work on that 
code-base.



It's just a bit of a bother on Windows and rather a big bother on OSX.


And here I ask myself why we should bother at all? What gain does this 
bring to Calligra? I would say exactly zero, none, null, nil, nada.


But yes, technical it should be possible to just port dbus to e.g. 
Symbian, Android, OSX, QNX, etc. pp. It's just not related to Calligra.


___
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