Need help delete branch

[Yue Liu]

Hi,

Anyone has permission to delete a branch and its history? I pushed a
personal development branch "formula" to origin, thought I could
delete it later, but found I don't have permission. Can anyone help me
delete it?

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

Re: After 2.9.7

[Yue Liu]

On Aug 31, 2015 2:50 AM, "Dmitry Kazakov"  wrote:
>
>
>>> 1) I'm ok with forking Krita repository. We already depend from quite
few libraries from calligra libs. That is mostly, KoCanvasBase,
KoDocumentBase, flake and pigment.From all four only pigment looks
>>> reusable enough for me to have a separate repo. In our code we hack
quite a lot to adapt flake and document classes for our needs.
>>>
>>> 2) One more benefit of forking to another repository would be that the
size of the repo would become lower (correct me if I'm wrong). Since "Krita
for Cats" manual is still semi-official way of building
>>> Krita on some platforms this is really crucial for many users. Quite a
lot of people still have GPRS or limited internet, so downloading 700MiB
just to try Krita *is* a barrier. Another problem is
>>> translators. Basically, they need to have a full source tree around to
be able to check where the string comes from.
>>
>>
>> The repo size is one reason I'm actually considering to drop all
>> history. Create a fresh new repo with cleaned-up code only and start
>> again from commit 0. I know we check history a lot, but that history is
>> the history of Krita up to Krita 2.9.x, which is in the calligra repo.
>
>
> This will make our life really hard :(
>

For git there is a way to move files from one repo to another repo while
keeping history to only those files. You can do that for Krita split, first
create a branch to strip off office apps code, then create an empty krita
repo, then move all files and their history to the new repo.

This way you make repo smaller but still have krita history.

> --
> Dmitry Kazakov
>
> ___
> 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

[Differential] [Accepted] D128: Restore loading of defaultstyles.xml

[yue (Yue Liu)]

yue added a subscriber: yue.
yue accepted this revision.
yue added a reviewer: yue.
yue added a comment.
This revision is now accepted and ready to land.

LGTM


REPOSITORY
  rCALLIGRA Calligra

BRANCH
  fixFindingDefaultStylesXml

REVISION DETAIL
  https://phabricator.kde.org/D128

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: kossebau, yue
Cc: yue, zachmann, Calligra-Devel-list
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Review Request 123179: workaround Vc cmake issue

[Yue Liu]

/KF5/KI18n -isystem /usr/include/KF5/KNotifications -isystem 
/usr/include/KF5/KIconThemes -isystem /usr/include/KF5/KWindowSystem -isystem 
/usr/include/KF5/KGuiAddons -isystem /usr/include/KF5/KU
 nitConversion -isystem /usr/include/KF5/KTextWidgets -isystem 
/usr/include/KF5/SonnetUi -isystem /usr/include/KF5/KParts -isystem 
/usr/include/KF5/KItemModels -isystem /usr/include/KF5/KEmoticons
  OBJECT_DIR = libs/pigment/CMakeFiles/pigmentcms.dir
  OBJECT_FILE_DIR = libs/pigment/CMakeFiles/pigmentcms.dir/compositeops
  TARGET_COMPILE_PDB = libs/pigment/CMakeFiles/pigmentcms.dir/
  TARGET_PDB = libs/pigment/libpigmentcms.pdb
```

It seems vc's `ko_compile_for_all_implementations_no_scalar` macro used its own 
method to generate compiler command and arguments, which only has include 
directories defined in `add_directories`, but Qt5/KF5 include directories are 
added through `target_link_libraries`, which is described in [KF5 porting 
notes](https://community.kde.org/Frameworks/Porting_Notes#Build_System) and 
[CMake 
doc](http://www.cmake.org/cmake/help/v3.2/prop_tgt/INTERFACE_SYSTEM_INCLUDE_DIRECTORIES.html).

I think it's something should be fixed in Vc, for now we need to manually add 
Qt5/KF5 include directories in `add_directories`, and be careful about the 
order of those directories, if conflicting headers exists between 
`/usr/include` and other non-standard path, for example kdelibs4's `kdebug.h` 
is in `/usr/include`, KF5KDELibs4Support's `kdebug.h` is in 
`/usr/include/KF5/KDELibs4Support`, while a different non-cnflicting header is 
located in `/usr/include` and its include directory is added before 
KDELibs4Support include directory, then compiler will try `/usr/include` first 
when looking for KDELibs4Support's headers. That issue doesn't exist if 
compiler arguments are constructed by CMake's `add_library` because CMake will 
automatically remove any `/usr/include` include directory, as shown in the 
second piece of ninja code.


Diffs
-

  libs/pigment/CMakeLists.txt ae6651b82b8a26ed40d6f1ab4590ce13f753f8d9 

Diff: https://git.reviewboard.kde.org/r/123179/diff/


Testing
---

Build successful on arch linux


Thanks,

Yue Liu

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

Re: Problem using Vc with CMake 3.0 and kf5

[Yue Liu]

Ninja dosen't generate that quoted include line, for the short term, how
about stop supporting GNU Make, tell distro maintainers to generate ninja
target when running Cmake?
On May 23, 2015 5:06 AM, Aleix Pol aleix...@kde.org wrote:

 On Sat, May 23, 2015 at 11:51 AM, Boudewijn Rempt b...@valdyas.org
 wrote:
  Sorry for the extensive cross-posting in advance, please when replying,
 do a
  reply-all.
 
  Just so everyone is on the same page: Vc is a template library that
 makes it
  easy to build vectorized code using a single source file. Krita uses Vc
 to
  optimize blending colors, creating masks and much more. Krita uses the
 most
  recent Vc release, 0.7.4: http://code.compeng.uni-frankfurt.de/news/27
 
  We're currently porting Krita to Qt5 and KF5 and the way KF5 and Vc
 handle
  include directories is a big roadblock for us:
  https://git.reviewboard.kde.org/r/123179/ .
 
  In a nutshell: Vc builds many different object files from single cpp
 file.
  It does this by creating a custom command for each target vectorization
  extension. To do that, it needs to access the contents of
  INCLUDE_DIRECTORIES, like this (in VcMacros.cmake:
 
 http://code.compeng.uni-frankfurt.de/projects/vc/repository/entry/cmake/VcMacros.cmake?rev=0.7
 )
 
 get_directory_property(_inc INCLUDE_DIRECTORIES)
 foreach(_i ${_inc})
list(APPEND _flags -I${_i})
 endforeach()
 
  In the end the command is generated like this:
 
   add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${_out}
  COMMAND ${CMAKE_CXX_COMPILER} ${_flags} ${_extra_flags}
  -DVC_IMPL=${_impl}
  ${_outfile_flag}${_out}
  ${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
  MAIN_DEPENDENCY
 ${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
  IMPLICIT_DEPENDS CXX
  ${CMAKE_CURRENT_SOURCE_DIR}/${_vc_compile_src}
  COMMENT Building CXX object ${_out}
  WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
  VERBATIM
  )
  KF5 uses cmake generator expressions to derive the include directories
 from
  the target_link_libraries lines. This means that when we try to build our
  per-extensions object files we get this:
 
 
 
  [  0%] Building CXX object
  KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
  cd /home/boud/kde/build/calligra/libs/pigment  /usr/bin/c++
 -std=c++0x
  -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts
  -Wformat-security -Wno-long-long -Wpointer-arith -Wundef
 -Wnon-virtual-dtor
  -Woverloaded-virtual -Werror=return-type
 -D__GNUC_UBUNTU_VERSION__=0xf040a
  -Wabi -fabi-version=0 -ffp-contract=fast -mtune=core2 -fPIC
  -I/home/boud/kde/src/calligra/interfaces -I/home/boud/kde/build/calligra
  -I/home/boud/kde/src/calligra -I/home/boud/kde/src/calligra/libs/version
  -I/home/boud/kde/build/calligra/libs/version
  -I/home/boud/kde/src/calligra/libs/koplugin
  -I/home/boud/kde/src/calligra/libs/version
  -I/home/boud/kde/build/calligra/libs/version
  -I/home/boud/kde/src/calligra/libs/pigment
  -I/home/boud/kde/src/calligra/libs/pigment/compositeops
  -I/home/boud/kde/src/calligra/libs/pigment/resources -I/usr/include
  -I/usr/include -I/usr/include/OpenEXR -I/usr/include -mavx -DVC_IMPL=AVX
 -c
  -oKoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
 
 /home/boud/kde/src/calligra/libs/pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp
 
 
 /home/boud/kde/src/calligra/libs/pigment/compositeops/KoOptimizedCompositeOpFactoryPerArch.cpp:22:19:
  fatal error: QString: No such file or directory
   #include QString
 ^
  compilation terminated.
  libs/pigment/CMakeFiles/pigmentcms.dir/build.make:72: recipe for
 target
  'libs/pigment/KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o' failed
 
  On other words, INCLUDE_DIRECTORIES is empty, there's no Qt5, no Kf5 to
 be
  found.
 
  If we manually set include directories like this:
 
  if (HAVE_VC)
  message(. ${KDE4_INCLUDES})
  include_directories(${KDE4_INCLUDES} ${Qt5Core_INCLUDE_DIRS}
  ${Qt5Gui_INCLUDE_DIRS} ${Qt5Xml_INCLUDE_DIRS} ${PIGMENT_INCLUDES}
  ${Boost_INCLUDE_DIR})
  endif()
 
  We end up with the entire include line for the contents of KDE4_INCLUDES
  ($TARGET_PROPERTY:KF5::KDELibs4Support,INTERFACE_INCLUDE_DIRECTORIES)
  expanded to a string with quotes around it:
 
 [  0%] Building CXX object
 KoOptimizedCompositeOpFactoryPerArch_AVX.cpp.o
  cd /home/boud/kde/build/calligra/libs/pigment  /usr/bin/c++
 -std=c++0x
  -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts
  -Wformat-security -Wno-long-long -Wpointer-arith -Wundef
 -Wnon-virtual-dtor
  -Woverloaded-virtual -Werror=return-type
 -D__GNUC_UBUNTU_VERSION__=0xf040a
  -Wabi -fabi-version=0 -ffp-contract=fast -mtune=core2 -fPIC
  -I/home/boud/kde/src/calligra/interfaces -I/home/boud/kde/build/calligra
  -I/home/boud/kde/src/calligra -I/home/boud/kde/src/calligra/libs/version
  -I/home/boud/kde/build/calligra/libs/version
 
 

Re: The message about Calligra 3.x

[Yue Liu]

2015-04-30 15:55 GMT-07:00 Friedrich W. H. Kossebau kosse...@kde.org:

 Hi Jaroslaw,

 thanks for starting the discussion. And meh, I only wanted to write a short
 reply. No time to make it short again, sorry...

 Am Mittwoch, 29. April 2015, 23:36:09 schrieb Jaroslaw Staniek:
  Hi,
  I am proposing this looking more from users' optics than from developers':
 
  We're at 3.0 Pre-Alpha stage now.
 
  How about then releasing 3.0 Beta 1, 2,  and never the 3.0 _stable_.
  This approach would be announced in 3.0 Beta 1 already: 3.0 is a BETA
  series.
 
  Users read it as experimental, preview, whatever. Beta seems to
  be the best universally understood indicator.
  Just avoid the 3.0 stable but preview mantra, which does not seem
  to be a very safe bet (hint: Plasma 4.0).

 IMHO you raise a good point here. What is the purpose of 3.0? So far we
 defined it as something where Calligra has been ported to Qt5/KF5. Means,
 building against some version of Qt5 and the KF5 frameworks, including
 kdelibs4support module. Ideally without regressions and loss of features.

 And to not get lost during the port itself also do not any new features and do
 not any refactoring*.

 Which means to me, the average user is not the target group of this release.
 Because they do not gain anything from it (besides feeling at the cutting
 edge), rather risk regressions (cutting edge means wounds ;) ).
 Actually, the target group is more ourselves, the developers, no? 3.0 is
 defining a milestone, where we consider the port itself done, where we take
 that branch as the new master branch and where we open the gates for mass
 feature development on it, switching more and more over from doing that on the
 stable branch 2.9. It will also be the end of caring to allow merges from
 2.9 ;)

 So perhaps it might be an idea not to call it 3.0. But keep 3.0 as version
 id for the first real feature release based on Qt5/KF5, which we consider a
 real improvement over the last feature release based on kdelibs4, so e.g.
 distros should chose it for their users.

 So what about using e.g. 2.99 or something equally strange as version for
 the so far called 3.0 milestone? Would still fit the relative numbering. But
 also signal something is not really at a new stage yet, in case non-
 developers/non-community testers are exposed to that.

+1 for 2.99, we can bump to 2.100, 2.101, 2.102 ... until it's usable as 2.9.x


 What we might still need to agree on is when this milestone is reached.
 Because turning to feature developement might also result in API changes in
 the libs (and refactoring), and any app not yet ported will bitrot. So how
 long should we wait for those apps which are planned to be ported, but are not
 yet there? (BTW, right now behind are Author, Flow, Gemini, Kexi,
 while Active and Braindump staying drop candidates). Simply go with a time
 deadline?

 * Yes, IMHO we made a mistake with allowing the exception for KDb, KProperty
 and KReport, as it runs the risk to delay the port of Plan (at least the
 reporting feature) and Kexi, and in turn the whole of Calligra, if things
 should be kept together. But well, now it happened and so those interested
 have to work hard to catch up.

  What's with 3.1? For now I do not know. Maybe we can have 3.1 stable,
  maybe not. Depends on many factors.
 
  More active sub-projects would achieve their stable milestones by
  then. Or not if they are active or/and daring.

 I guess we should also start planning how to handle the Krita split-off that
 is going to happen (for bad or good), if only because the Calligra git repo
 just got too big. But then also the rest of Calligra does not match the
 development speed of Krita, which e.g. resulted in the fork of komain into a
 part of kritaui already. And surely soon in even more forks, because Krita
 devs do not enjoy also porting all the other Calligra apps (or introduce
 regressions which noone catches). Which is sad, but reality. It could be only
 stopped if more people are active again in the non-krita part of Calligra.

 So far plans have been uttered to do that after 3.0. No idea if plans are
 more concrete?

  Also, possible thing is that some apps wouldn't achieve stability
  milestone in the same time. So for example how 3.1 would be called?
  A common denominator would be my bet, i.e. marking all apps included
  as beta. Thus rather giving users a nice surprise (e.g. they would
  note that Krita is ready) than than disappointing them (by the fact
  that in 3.1 Stable some apps aren't so stable or feature-complete
  compared to 2.9).

 I would propose apps that are not stable again are tagged as STAGING, and thus
 disabled from release builds :) That way development can go on, but only those
 apps that are ready to be delivered to end users are part of the actual
 release.
 So if maintainers of Krita, Karbon and Kexi at the planned time of 3.1 release
 consider the state an improvement over the last official released version,
 they 

CLion Open Source License for Calligra

[Yue Liu]

Hi,

Jetbrains' Java-based C++ IDE CLion has been released for a while, I
tried it during frameworks porting and like it, so I applied several
CLion Open Source Licenses in the name of orgnization Calligra, it
includes 1-year upgrade subscription to CLion valid for open source
development.

I have 9 licenses available, if you're contributing to Calligra and
want to use CLion for development, send me an email to get a license!

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

Re: Phabricator!

[Yue Liu]

how to get an account?

2015-04-17 23:59 GMT-07:00 Boudewijn Rempt b...@valdyas.org:

 Hi!

 We've got a running instance of Phabricator now: phabricator.kde.org.
 It's still a test setup, but we're one of the projects doing the testing
 :-). The possibilities look great, I'm really glad we can test it already.

 So, now's the time to start using Phabricator instead of reviewboard, and
 explore all the other possibilities.

 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: Review Request 123315: Merge filter desktop files for some Karbon import/export filters

[Yue Liu]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123315/#review78782
---

Ship it!


Ship It!

- Yue Liu


On April 9, 2015, 11:27 p.m., Friedrich W. H. Kossebau wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/123315/
 ---
 
 (Updated April 9, 2015, 11:27 p.m.)
 
 
 Review request for Calligra and Yue Liu.
 
 
 Repository: calligra
 
 
 Description
 ---
 
 The SVG-Karbon filter supports both SVG and compressed SVG. Instead of 
 having one desktop file for the filter listing both mimetypes in the 
 `X-KDE-Import` entry (which is a stringlist with `,` as separator), there are 
 two separate desktop files.
 Same with the Karbon-Image (PNG,JPEG) filter, instead of listing both 
 supported mimetypes in the `X-KDE-Export` entry, there are two separate 
 desktop files.
 Which is fine in the current world where metadata about filters is stored in 
 separate desktop files. There can be multiple desktop files per binary plugin.
 
 But in the new world in the `frameworks` branch, metadata about filters is 
 stored embedded (in JSON format) in the actual binary plugin. Which also 
 means there can be only one metadata bundle per filter.
 
 To prepare the new world, I propose to merge the desktop files already in the 
 2.9 branch, so it is closer to the needs of the new world, and merging 
 branches is less in danger of conflicts.
 
 
 Diffs
 -
 
   filters/karbon/image/CMakeLists.txt 785527f 
   filters/karbon/image/calligra_filter_karbon2image.desktop PRE-CREATION 
   filters/karbon/image/calligra_filter_karbon2jpg.desktop a925282 
   filters/karbon/image/calligra_filter_karbon2png.desktop 628063c 
   filters/karbon/svg/CMakeLists.txt fc5bb40 
   filters/karbon/svg/calligra_filter_svg2karbon.desktop 48a3316 
   filters/karbon/svg/calligra_filter_svgz2karbon.desktop 107298c 
 
 Diff: https://git.reviewboard.kde.org/r/123315/diff/
 
 
 Testing
 ---
 
 Can still export both into JPG and PNG, and still import from SVG and SVGZ in 
 Karbon.
 
 
 Thanks,
 
 Friedrich W. H. Kossebau
 


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

Re: Rewriting Flow formulashape for 3.0? (Re: Qt5 Port Status)

[Yue Liu]

I agree we should port first then add new things, I'll drop ownership of
formulashape for now and continue working on libmathview.

For Flow it's just a kopageapp wrapper and a docker plugin that works in
all calligra apps, so the re-write actually means to move the plugin code
from Flow folder to Karbon folder, then fix all paths in cmake files,
#include lines, and identity strings in code. I can finish that before
releasing 3.0.

Cheers,
Yue

2015-04-08 14:16 GMT-07:00 Boudewijn Rempt b...@valdyas.org:

 As for me, I would say:

 * let's not already remove code until we're releasing 3.0. Just keep it
 UNPORTED -- otherwise, we'll get merge conflicts because of translations,
 if nothing else.

 * As for whether we should keep the formula shape or not, I think it's
 simple: if it hasn't been ported by 3.0 release time, we won't keep it.
 Otherwise, we will: and then we can replace it if there's an alternative.


 On Wed, 8 Apr 2015, Inge Wallin wrote:

  On Wednesday, April 08, 2015 22:07:46 Friedrich W. H. Kossebau wrote:

 Hi Yue,

 good to see that you among other things have already turned Karbon back
 to
 life in the Qt5/KF5 spheres :) Rock on!

 Now, the plan for Calligra 3.0 was to focus on porting all code to Qt5
 and
 KF5.

 No refactoring or rewriting should be done ideally, as that will only
 complicate things, like history (including Calligra's) teaches.
 One step at a time, they say surely in many languages.

 With KoReport, KoProperty, CalligraDB we are breaking this initial idea
 that
 we informally agreed on, makes me not that happy, would have like to work
 on Plan porting already now, and also am slightly fearing how much things
 changed with those libs. But at least it seems things are getting ready
 almost in time now... not yet git-cloned the repos, but soon will do.

 Seems you, Yue, want to do more for 3.0 as well, let me comment on that
 please:

 Am Samstag, 21. März 2015, 20:02:32 schrieb Yue Liu:
  I want to add something to the Stuff that can be removed part of the
  porting plan.
   plugins/formulashape/ - I will write a new formula plugin based on
  libmathview.

 How broken is the current shape?


 I would really not like to remove the formula shape until there actually
 *is* a replacement, not just a promise to create one.  I don't care how
 much the current shape sucks (well, actually I do, but work with me here).
 But even if interaction sucks, visualization sucks and other things suck,
 it still provides a roundtrip storage for formula objects.

 And if *that* fails, it should be fixed immediately and not removed. I
 worked on the formulashape myself not too long ago and I know that it has
 worked before.

 The same goes for the Flow application to some extent, but since the
 formula shape is shared between all apps it is very important that it not
 be destroyed now.

 ___
 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 123179: workaround Vc cmake issue

[Yue Liu]

/KNotifications -isystem 
/usr/include/KF5/KIconThemes -isystem /usr/include/KF5/KWindowSystem -isystem 
/usr/include/KF5/KGuiAddons -isystem /usr/include/KF5/KU
 nitConversion -isystem /usr/include/KF5/KTextWidgets -isystem 
/usr/include/KF5/SonnetUi -isystem /usr/include/KF5/KParts -isystem 
/usr/include/KF5/KItemModels -isystem /usr/include/KF5/KEmoticons
  OBJECT_DIR = libs/pigment/CMakeFiles/pigmentcms.dir
  OBJECT_FILE_DIR = libs/pigment/CMakeFiles/pigmentcms.dir/compositeops
  TARGET_COMPILE_PDB = libs/pigment/CMakeFiles/pigmentcms.dir/
  TARGET_PDB = libs/pigment/libpigmentcms.pdb
```

It seems vc's `ko_compile_for_all_implementations_no_scalar` macro used its own 
method to generate compiler command and arguments, which only has include 
directories defined in `add_directories`, but Qt5/KF5 include directories are 
added through `target_link_libraries`, which is described in [KF5 porting 
notes](https://community.kde.org/Frameworks/Porting_Notes#Build_System) and 
[CMake 
doc](http://www.cmake.org/cmake/help/v3.2/prop_tgt/INTERFACE_SYSTEM_INCLUDE_DIRECTORIES.html).

I think it's something should be fixed in Vc, for now we need to manually add 
Qt5/KF5 include directories in `add_directories`, and be careful about the 
order of those directories, if conflicting headers exists between 
`/usr/include` and other non-standard path, for example kdelibs4's `kdebug.h` 
is in `/usr/include`, KF5KDELibs4Support's `kdebug.h` is in 
`/usr/include/KF5/KDELibs4Support`, while a different non-cnflicting header is 
located in `/usr/include` and its include directory is added before 
KDELibs4Support include directory, then compiler will try `/usr/include` first 
when looking for KDELibs4Support's headers. That issue doesn't exist if 
compiler arguments are constructed by CMake's `add_library` because CMake will 
automatically remove any `/usr/include` include directory, as shown in the 
second piece of ninja code.


Diffs (updated)
-

  libs/pigment/CMakeLists.txt ae6651b82b8a26ed40d6f1ab4590ce13f753f8d9 

Diff: https://git.reviewboard.kde.org/r/123179/diff/


Testing
---

It builds, but I don't know how to get Qt5/KF5 include directories variables in 
CMake so hard-coded those path, can someone point out how to get those 
variables?


Thanks,

Yue Liu

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

Re: Review Request 123179: workaround Vc cmake issue

[Yue Liu]

/KNotifications -isystem 
/usr/include/KF5/KIconThemes -isystem /usr/include/KF5/KWindowSystem -isystem 
/usr/include/KF5/KGuiAddons -isystem /usr/include/KF5/KU
 nitConversion -isystem /usr/include/KF5/KTextWidgets -isystem 
/usr/include/KF5/SonnetUi -isystem /usr/include/KF5/KParts -isystem 
/usr/include/KF5/KItemModels -isystem /usr/include/KF5/KEmoticons
  OBJECT_DIR = libs/pigment/CMakeFiles/pigmentcms.dir
  OBJECT_FILE_DIR = libs/pigment/CMakeFiles/pigmentcms.dir/compositeops
  TARGET_COMPILE_PDB = libs/pigment/CMakeFiles/pigmentcms.dir/
  TARGET_PDB = libs/pigment/libpigmentcms.pdb
```

It seems vc's `ko_compile_for_all_implementations_no_scalar` macro used its own 
method to generate compiler command and arguments, which only has include 
directories defined in `add_directories`, but Qt5/KF5 include directories are 
added through `target_link_libraries`, which is described in [KF5 porting 
notes](https://community.kde.org/Frameworks/Porting_Notes#Build_System) and 
[CMake 
doc](http://www.cmake.org/cmake/help/v3.2/prop_tgt/INTERFACE_SYSTEM_INCLUDE_DIRECTORIES.html).

I think it's something should be fixed in Vc, for now we need to manually add 
Qt5/KF5 include directories in `add_directories`, and be careful about the 
order of those directories, if conflicting headers exists between 
`/usr/include` and other non-standard path, for example kdelibs4's `kdebug.h` 
is in `/usr/include`, KF5KDELibs4Support's `kdebug.h` is in 
`/usr/include/KF5/KDELibs4Support`, while a different non-cnflicting header is 
located in `/usr/include` and its include directory is added before 
KDELibs4Support include directory, then compiler will try `/usr/include` first 
when looking for KDELibs4Support's headers. That issue doesn't exist if 
compiler arguments are constructed by CMake's `add_library` because CMake will 
automatically remove any `/usr/include` include directory, as shown in the 
second piece of ninja code.


Diffs (updated)
-

  libs/pigment/CMakeLists.txt ae6651b82b8a26ed40d6f1ab4590ce13f753f8d9 

Diff: https://git.reviewboard.kde.org/r/123179/diff/


Testing (updated)
---

Build successful on arch linux


Thanks,

Yue Liu

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

Review Request 123179: workaround Vc cmake issue

[Yue Liu]

/KIconThemes -isystem /usr/include/KF5/KWindowSystem -isystem 
/usr/include/KF5/KGuiAddons -isystem /usr/include/KF5/KU
 nitConversion -isystem /usr/include/KF5/KTextWidgets -isystem 
/usr/include/KF5/SonnetUi -isystem /usr/include/KF5/KParts -isystem 
/usr/include/KF5/KItemModels -isystem /usr/include/KF5/KEmoticons
  OBJECT_DIR = libs/pigment/CMakeFiles/pigmentcms.dir
  OBJECT_FILE_DIR = libs/pigment/CMakeFiles/pigmentcms.dir/compositeops
  TARGET_COMPILE_PDB = libs/pigment/CMakeFiles/pigmentcms.dir/
  TARGET_PDB = libs/pigment/libpigmentcms.pdb
```

It seems vc's `ko_compile_for_all_implementations_no_scalar` macro used its own 
method to generate compiler command and arguments, which only has include 
directories defined in `add_directories`, but Qt5/KF5 include directories are 
added through `target_link_libraries`, which is described in [KF5 porting 
notes](https://community.kde.org/Frameworks/Porting_Notes#Build_System) and 
[CMake 
doc](http://www.cmake.org/cmake/help/v3.2/prop_tgt/INTERFACE_SYSTEM_INCLUDE_DIRECTORIES.html).

I think it's something should be fixed in Vc, for now we need to manually add 
Qt5/KF5 include directories in `add_directories`, and be careful about the 
order of those directories, if conflicting headers exists between 
`/usr/include` and other non-standard path, for example kdelibs4's `kdebug.h` 
is in `/usr/include`, KF5KDELibs4Support's `kdebug.h` is in 
`/usr/include/KF5/KDELibs4Support`, while a different non-cnflicting header is 
located in `/usr/include` and its include directory is added before 
KDELibs4Support include directory, then compiler will try `/usr/include` first 
when looking for KDELibs4Support's headers. That issue doesn't exist if 
compiler arguments are constructed by CMake's `add_library` because CMake will 
automatically remove any `/usr/include` include directory, as shown in the 
second piece of ninja code.


Diffs
-

  libs/pigment/CMakeLists.txt ae6651b82b8a26ed40d6f1ab4590ce13f753f8d9 

Diff: https://git.reviewboard.kde.org/r/123179/diff/


Testing
---

It builds, but I don't know how to get Qt5/KF5 include directories variables in 
CMake so hard-coded those path, can someone point out how to get those 
variables?


Thanks,

Yue Liu

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

Re: [KDE/Mac] OS X observations

[Yue Liu]

2015-01-03 3:26 GMT-08:00 Friedrich W. H. Kossebau kosse...@kde.org:

 Hi,

 Am Samstag, 3. Januar 2015, 11:15:51 schrieb René J.V. Bertin:
  On Saturday January 03 2015 10:53:39 Jaroslaw Staniek wrote:
  Just for the record, according to plans, we think about Kexi on Mac as
  a native, regular, shiny, standalone mac app. Let's see what's this
  interesting year brings.
 
  Then why isn't it included in the OS X product set?

 BTW, the OS X product set is an abuse of the product set system. Actually
 things not building on OS X (or other platforms) should be disabled in the
 central CMakeLists.txt in section Detect which products/features can be
 compiled.

 Yue did this for some reason I forgot, I just remember I did not want to stop
 any energy that was flowing at that time :) Yue, can you help me and tell what
 the reason was?

At that time something in Sheets cannot be compiled by Clang because
it used GNU C/C++.



 Well, now it has been mentioned again, I am going to set up a PR to remove
 that OSX product set in favour of the correct way.

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

Re: Review Request 115512: added add text popup menu to calligra

[Yue Liu]

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

(Updated Oct. 21, 2014, 5:43 a.m.)


Status
--

This change has been discarded.


Review request for Calligra and Camilla Boemann.


Repository: calligra


Description
---

Added Add Text action to popup menu in DefaultTool, if an application don't 
want it appear in popup menu, set AllowAddTextToShapePopupAction=false in rc 
file. Currently disabled in Words, Sheets, and Kexi.

There is a problem that KoTosContainer doesn't have API to delete text shapes 
in it, so undo doesn't work.

Another thing is this action supports adding text to multiple shapes, after 
texts are added, should it activate text tool automatically? If there are 
multiple shapes, which one should have text tool activated? The first in list, 
or the one under cursor? If the shape under cursor is not a KoTosContainer, 
then which KoTosContainer should have TextTool activated? My current idea is if 
the shape under cursor is KoTosContainer, then activate TextTool on it, 
otherwise don't activate TextTool.


Diffs
-

  kexi/data/kexirc 4c73bd0 
  libs/flake/CMakeLists.txt 839b861 
  libs/flake/commands/KoTosContainerAddTextCommand.h PRE-CREATION 
  libs/flake/commands/KoTosContainerAddTextCommand.cpp PRE-CREATION 
  plugins/defaultTools/defaulttool/DefaultTool.h dca6ae8 
  plugins/defaultTools/defaulttool/DefaultTool.cpp 453a727 
  sheets/sheetsrc 9b622fb 
  words/part/wordsrc 4cd2801 

Diff: https://git.reviewboard.kde.org/r/115512/diff/


Testing
---

Works on OSX

You can also test through branch add-text-popup-action-yue


Thanks,

Yue Liu

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

Re: Review Request 108481: Temporarily swith to path tool to change shape parameters without double click to switch tool

[Yue Liu]

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

(Updated Oct. 15, 2014, 4:44 p.m.)


Status
--

This change has been discarded.


Review request for Calligra.


Repository: calligra


Description
---

After patch is applied, is a single parameter shape is selected in default 
tool, parameter handles will be painted. If mouse move on the handles, will 
temporarily switch to path tool so users can edit shape parameters. In 
temporary path tool if mouse move off from the handles, current tool will be 
switched back to default tool.

Now double click in default tool can be used for other tasks, such as add a new 
textbox for current shape.


Diffs
-

  libs/flake/KoParameterShape.h 9c0db7a 
  libs/flake/tools/KoPathTool.h af906bb 
  libs/flake/tools/KoPathTool.cpp 9dd8caf 
  libs/flake/tools/KoPathToolFactory.h 2aacfe5 
  libs/flake/tools/KoPathToolFactory.cpp 1846c86 
  plugins/defaultTools/defaulttool/DefaultTool.cpp db7c489 
  plugins/defaultTools/defaulttool/SelectionDecorator.h 83e715e 
  plugins/defaultTools/defaulttool/SelectionDecorator.cpp 3e16cfa 

Diff: https://git.reviewboard.kde.org/r/108481/diff/


Testing
---

works in words, stage, flow, karbon


Thanks,

Yue Liu

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

Re: Review Request 108481: Temporarily swith to path tool to change shape parameters without double click to switch tool

[Yue Liu]

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

(Updated Oct. 15, 2014, 4:44 p.m.)


Status
--

This change has been marked as submitted.


Review request for Calligra.


Repository: calligra


Description
---

After patch is applied, is a single parameter shape is selected in default 
tool, parameter handles will be painted. If mouse move on the handles, will 
temporarily switch to path tool so users can edit shape parameters. In 
temporary path tool if mouse move off from the handles, current tool will be 
switched back to default tool.

Now double click in default tool can be used for other tasks, such as add a new 
textbox for current shape.


Diffs
-

  libs/flake/KoParameterShape.h 9c0db7a 
  libs/flake/tools/KoPathTool.h af906bb 
  libs/flake/tools/KoPathTool.cpp 9dd8caf 
  libs/flake/tools/KoPathToolFactory.h 2aacfe5 
  libs/flake/tools/KoPathToolFactory.cpp 1846c86 
  plugins/defaultTools/defaulttool/DefaultTool.cpp db7c489 
  plugins/defaultTools/defaulttool/SelectionDecorator.h 83e715e 
  plugins/defaultTools/defaulttool/SelectionDecorator.cpp 3e16cfa 

Diff: https://git.reviewboard.kde.org/r/108481/diff/


Testing
---

works in words, stage, flow, karbon


Thanks,

Yue Liu

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

Re: Review Request 109278: fix preedit string problem when layout the document, fix input method query problem in artistictext tool

[Yue Liu]

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

(Updated Oct. 15, 2014, 4:44 p.m.)


Status
--

This change has been discarded.


Review request for Calligra.


Repository: calligra


Description
---

when use input method with preedit string, application will crash when layout 
the document.
when using artistictext tool, input method context dialog won't update position.


Diffs
-

  libs/textlayout/KoTextLayoutArea.cpp afbd57e 
  libs/textlayout/KoTextLayoutArea_paint.cpp 6671e2d 
  plugins/artistictextshape/ArtisticTextTool.h 49cd7a1 
  plugins/artistictextshape/ArtisticTextTool.cpp dab0764 
  plugins/textshape/TextTool.cpp decb758 

Diff: https://git.reviewboard.kde.org/r/109278/diff/


Testing
---

most crash resolved. still one crash in testing, will investigate if that was 
the same issue.


Thanks,

Yue Liu

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

Re: Patch for kdelibs-stripped

[Yue Liu]

This version cut off kparts and kutils and works fine on my machine.

On Mon, Jul 21, 2014 at 11:34 PM, Boudewijn Rempt b...@valdyas.org wrote:
 On Monday 21 July 2014 Jul 21:10:36 Yue Liu wrote:
 when kparts is disabled, I got compile error where kprintutils ask for
 kparts. I don't know why it only happens on my machine, maybe because
 I have more dependencies available so kdelibs turned on more features?


 That's quite possible -- I really go for minimalism here. Btw, I've uploaded 
 my cmake project definition and patches that I use on OSX here:

 It's not perfect yet, and some dependencies don't build from the cmake 
 project definition, but the result is a build of Krita that doesn't use 
 anything from macports or any other osx build/packaging system.

 http://quickgit.kde.org/?p=scratch%2Frempt%2Fkritadeposx.git

 The Windows equivalent is here, btw:

 http://quickgit.kde.org/?p=scratch%2Frempt%2Fkritadepwin.git

 There is lots of stuff hardcoded for my build setup in it, so use with care.

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


stripped-osx-yue.patch
Description: Binary data
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Patch for kdelibs-stripped

[Yue Liu]

when kparts is disabled, I got compile error where kprintutils ask for
kparts. I don't know why it only happens on my machine, maybe because
I have more dependencies available so kdelibs turned on more features?

On Mon, Jul 21, 2014 at 1:55 AM, Boudewijn Rempt b...@valdyas.org wrote:
 On Saturday 19 July 2014 Jul 18:27:19 Yue Liu wrote:
 Hi Boud,

 I need to apply this patch to make kdelibs-stripped compile on OSX
 10.9 with dependencies installed through Homebrew.

 https://gist.github.com/philacs/32d62faaa03401baa068

 okay to push to your repo?

 It looks innocent enough, except for re-enabling kparts, I would prefer to 
 keep that disabled.

 --
 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: Review Request 118510: small rework of product sets: products, features and product sets

[Yue Liu]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118510/#review62727
---


How to disable a specific feature? I want to build SHEETS but disable 
FEATURE_SCRIPTING because kdelibs-stripped on OSX doesn't have kross. Cannot 
redefine it through commandline, cmake complain Feature FEATURE_SCRIPTING 
already defined, as .

- Yue Liu


On June 15, 2014, 11:20 p.m., Friedrich W. H. Kossebau wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/118510/
 ---
 
 (Updated June 15, 2014, 11:20 p.m.)
 
 
 Review request for Calligra, Yue Liu, Boudewijn Rempt, and Jarosław Staniek.
 
 
 Repository: calligra
 
 
 Description
 ---
 
 Based on the feedback, adaption and more own tinkering with the concepts, in 
 this patch I propose to do this:
 
 * split the old idea of a product into product, feature and productset
 * make no real difference between user-defined productsets and predefined ones
 * move the definition of the products into a separate file, for better 
 overview and discoverability
 * put the documentation directly into that separate file instead of hiding it 
 away in some README in some subdirectory noones knows about
 * generate a file with the graph of the dependencies, showing also the build 
 state (in DOT notation, see attached SVG file generated from that)
 * more patterns for the ids of the products
 * allow to have multiple productsets/products/features mentioned in the 
 -DPRODUCTSET flag (taken with WANTED property for now) (as asked for with 
 https://git.reviewboard.kde.org/r/118187)
 
 Surely this whole thing is in danger to be overengineered :) Especially given 
 that Krita devs have not picked up this for all the Sketch, Gemini, Steam etc 
 variants makes me wonder if it is perhaps. But then it might just be 
 underdocumented and uncommon and people have not yet discovered the nice 
 build customizations this offers over what is usually possible. Time to roll 
 the drums about this, mean, blog :)
 
 One thing still missing: proper disabling of products with selected product 
 sets. But lets leave that for a separate RR.
 
 
 Diffs
 -
 
   CMakeLists.txt 886e2c3 
   CalligraProducts.cmake PRE-CREATION 
   README.PACKAGERS 4ebc026 
   active/CMakeLists.txt 4361fb6 
   cmake/modules/CalligraProductSetMacros.cmake 697c046 
   cmake/productsets/README 5460955 
   cmake/productsets/active.cmake 089a085 
   cmake/productsets/all.cmake 4619358 
   cmake/productsets/creative.cmake 2b8fc45 
   cmake/productsets/desktop.cmake 83db3a1 
   cmake/productsets/kexi+sheets.cmake 3fe2f48 
   cmake/productsets/kexi.cmake 7dd2345 
   cmake/productsets/krita.cmake 2c814d3 
   cmake/productsets/osx.cmake 8e32b13 
   cmake/productsets/sheets.cmake 5de2103 
   devtools/CMakeLists.txt bfa5599 
   extras/CMakeLists.txt a534b0e 
   extras/quickprint/CMakeLists.txt 9ad61d2 
   extras/thumbnail/CMakeLists.txt 92156b3 
   filters/flow/visio/import/CMakeLists.txt 7f040f0 
   filters/flow/wpg/import/CMakeLists.txt caee3b4 
   filters/karbon/karbon1.x/CMakeLists.txt 87bdb73 
   filters/karbon/wmf/CMakeLists.txt c25ed2c 
   filters/karbon/wpg/CMakeLists.txt ffa7742 
   filters/karbon/xfig/CMakeLists.txt 1e0e2c6 
   filters/sheets/excel/import/CMakeLists.txt 07aa186 
   filters/sheets/xlsx/CMakeLists.txt 80d51aa 
   filters/stage/keynote/import/CMakeLists.txt f8d5781 
   filters/stage/kpr2odf/CMakeLists.txt 31c69b0 
   filters/stage/powerpoint/CMakeLists.txt 60e1ccc 
   filters/stage/pptx/CMakeLists.txt 31aef35 
   filters/words/docx/import/CMakeLists.txt d9f0cec 
   filters/words/msword-odf/CMakeLists.txt 8bd3806 
   filters/words/rtf/import/CMakeLists.txt df6f50d 
   filters/words/wordperfect/import/CMakeLists.txt 6e8446f 
   filters/words/works/import/CMakeLists.txt 93d40fb 
   kexi/plugins/CMakeLists.txt bf389f2 
   krita/plugins/formats/ora/CMakeLists.txt cd1a605 
   libs/CMakeLists.txt d482a4b 
   libs/kotext/CMakeLists.txt 9f9e506 
   plan/plugins/CMakeLists.txt e06e339 
   plugins/textshape/CMakeLists.txt f8d75f5 
   sheets/CMakeLists.txt a45829d 
   sheets/plugins/CMakeLists.txt 6a45389 
   stage/CMakeLists.txt eaf8ecf 
   words/CMakeLists.txt 033db4d 
   words/part/CMakeLists.txt 2bf1b0b 
   words/part/tests/CMakeLists.txt 6fd9b0c 
   words/plugins/CMakeLists.txt 229cff8 
 
 Diff: https://git.reviewboard.kde.org/r/118510/diff/
 
 
 Testing
 ---
 
 
 File Attachments
 
 
 Dependencies graph
   
 https://git.reviewboard.kde.org/media/uploaded/files/2014/06/04/b1958536-ca1c-4552-8c3d-120a9d8b786f__dependencies.svg
 Dependencies graph with just Kexi  Sheets built
   
 https://git.reviewboard.kde.org/media/uploaded/files/2014/06/04/8924bbdf-b05c-426d-b469

Patch for kdelibs-stripped

[Yue Liu]

Hi Boud,

I need to apply this patch to make kdelibs-stripped compile on OSX
10.9 with dependencies installed through Homebrew.

https://gist.github.com/philacs/32d62faaa03401baa068

okay to push to your repo?

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

Re: Review Request 114193: Added new cmake macros and find_package modules, added new dependency libodfgen, deleted writerperfect, use libodfgen instead

[Yue Liu]

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

(Updated July 7, 2014, 2:36 a.m.)


Status
--

This change has been marked as submitted.


Review request for Calligra.


Repository: calligra


Description
---

Use LibFindMacros.cmake to simplify package finding, fixed FindFFTW3, 
FindLIBWPD, FINDLIBWPG on mac, and some other mac fixes.
Added dependency libodfgen and future dependency libetonyek, deleteed 
writerperfet code.

To test the patch, just checkout branch cmake-fix-osx-yue


Diffs
-

  CMakeLists.txt 6587ecc 
  cmake/modules/FindFFTW3.cmake a4c8997 
  cmake/modules/FindLibEtonyek.cmake PRE-CREATION 
  cmake/modules/FindLibOdfGen.cmake PRE-CREATION 
  cmake/modules/FindLibVisio.cmake 69a598a 
  cmake/modules/FindLibWPS.cmake e34f382 
  cmake/modules/FindLibWpd.cmake PRE-CREATION 
  cmake/modules/FindLibWpg.cmake PRE-CREATION 
  cmake/modules/FindLibWps.cmake PRE-CREATION 
  cmake/modules/FindWPD.cmake 0f666b3 
  cmake/modules/FindWPG.cmake 066e579 
  cmake/modules/LibFindMacros.cmake PRE-CREATION 
  filters/CMakeLists.txt ba04b83 
  filters/flow/CMakeLists.txt c37d395 
  filters/flow/visio/import/CMakeLists.txt 55b8488 
  filters/flow/visio/import/VSDXImport.h 712d9d7 
  filters/flow/visio/import/VSDXImport.cpp 788379e 
  filters/flow/wpg/CMakeLists.txt PRE-CREATION 
  filters/flow/wpg/import/CMakeLists.txt PRE-CREATION 
  filters/flow/wpg/import/WPGImport.h PRE-CREATION 
  filters/flow/wpg/import/WPGImport.cpp PRE-CREATION 
  filters/flow/wpg/import/calligra_filter_wpg2odg.desktop PRE-CREATION 
  filters/flow/wpg/import/flow_wpg_thumbnail.desktop PRE-CREATION 
  filters/karbon/wpg/CMakeLists.txt e8600a0 
  filters/libodfhandler/DiskDocumentHandler.hxx PRE-CREATION 
  filters/libodfhandler/DiskDocumentHandler.cxx PRE-CREATION 
  filters/libodfhandler/FemtoZip.hxx PRE-CREATION 
  filters/libodfhandler/FemtoZip.cxx PRE-CREATION 
  filters/libodfhandler/OutputFileHelper.hxx PRE-CREATION 
  filters/libodfhandler/OutputFileHelper.cxx PRE-CREATION 
  filters/libodfhandler/StdOutHandler.hxx PRE-CREATION 
  filters/libodfhandler/StdOutHandler.cxx PRE-CREATION 
  filters/words/wordperfect/import/CMakeLists.txt cbcf650 
  filters/words/wordperfect/import/WPDImport.h ad515f7 
  filters/words/wordperfect/import/WPDImport.cpp e3b2c2c 
  filters/words/works/import/CMakeLists.txt 082cb31 
  filters/words/works/import/WPSImport.h 2d1b20c 
  filters/words/works/import/WPSImport.cpp e52d5b5 
  filters/writerperfect/CMakeLists.txt 1f57075 
  filters/writerperfect/DiskDocumentHandler.hxx 7b37ea3 
  filters/writerperfect/DiskDocumentHandler.cxx 799fdd0 
  filters/writerperfect/DocumentElement.hxx 5a03977 
  filters/writerperfect/DocumentElement.cxx 47a9d7e 
  filters/writerperfect/FemtoZip.hxx afecf5e 
  filters/writerperfect/FemtoZip.cxx c52a707 
  filters/writerperfect/FilterInternal.hxx eb2ddf8 
  filters/writerperfect/FontStyle.hxx 379b9c1 
  filters/writerperfect/FontStyle.cxx 111b46d 
  filters/writerperfect/InternalHandler.hxx 9223f1f 
  filters/writerperfect/InternalHandler.cxx 6ad9142 
  filters/writerperfect/ListStyle.hxx 94b31f8 
  filters/writerperfect/ListStyle.cxx dab5058 
  filters/writerperfect/OdfDocumentHandler.hxx d2911a9 
  filters/writerperfect/OdgGenerator.hxx 7296935 
  filters/writerperfect/OdgGenerator.cxx 49a3ac3 
  filters/writerperfect/OdtGenerator.hxx 425143d 
  filters/writerperfect/OdtGenerator.cxx bbcdc5c 
  filters/writerperfect/OutputFileHelper.hxx 48023b1 
  filters/writerperfect/OutputFileHelper.cxx 22a1895 
  filters/writerperfect/PageSpan.hxx 64c7053 
  filters/writerperfect/PageSpan.cxx c64a1dd 
  filters/writerperfect/SectionStyle.hxx bb52a55 
  filters/writerperfect/SectionStyle.cxx 2e5d352 
  filters/writerperfect/StdOutHandler.hxx de5d402 
  filters/writerperfect/StdOutHandler.cxx f8175f2 
  filters/writerperfect/Style.hxx 2682b24 
  filters/writerperfect/TableStyle.hxx bcd45a5 
  filters/writerperfect/TableStyle.cxx 1b99b6e 
  filters/writerperfect/TextRunStyle.hxx 63c297d 
  filters/writerperfect/TextRunStyle.cxx e34b2dd 
  filters/writerperfect/WriterProperties.hxx 8b61b65 
  krita/image/CMakeLists.txt da1102c 
  krita/image/kis_assert.cpp 17a85f8 
  krita/plugins/extensions/gmic/CMakeLists.txt 15291af 
  libs/main/KoDocument.cpp 0a17961 
  libs/widgets/KoEditColorSetDialog.cpp d683bcc 

Diff: https://git.reviewboard.kde.org/r/114193/diff/


Testing
---

Works on OSX 10.9, and Arch Linux. Please check if the FindXXX changes work on 
windows.


Thanks,

Yue Liu

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

Re: Review Request 109994: New implementation for handling formulas

[Yue Liu]

 On July 6, 2014, 2:13 p.m., Friedrich W. H. Kossebau wrote:
  Hi. Discussion on this review request has stopped more than a year ago. I 
  hope it could be started again soon by perhaps an updated version of the 
  patch? Without that though we better close this RR, given there is no 
  activity. Will close end of July.

formula rendering through qmmlwidget is ugly, there is a libmathview project 
providing TeX quality rendering with Opentype MATH table support, which is a 
gtkmathview fork, I made a qt5 backend for it, after we ported to qt5 we can 
use it in calligra.
https://github.com/khaledhosny/libmathview


- Yue


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/109994/#review61719
---


On April 19, 2013, 2:25 p.m., Gopalakrishna Bhat wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/109994/
 ---
 
 (Updated April 19, 2013, 2:25 p.m.)
 
 
 Review request for Calligra.
 
 
 Repository: calligra
 
 
 Description
 ---
 
 This new implementation for formulashape uses and improves on qtmmlwidgets 
 that was part of Qt Solutions. The code can be found in 
 plugins-formulashape2g-gopalK branch.
 
 Currently implemented features are
 1) Loading of formulas in document.
 2) Insert of MathML formulas generated from some other tools(viz FireMath 
 plugin for Firefox)
 3) Editing of existing formulas.
 
 Features that were there in old version of formulashape but missing now
 1) Insert of Elements, Symbols (in a very much unusable state)
 2) Edit formulas with LaTeX syntax (Will be done in coming days)
 
 I will remove the extra whitespace that exists in the uploaded diff before 
 merging :)
 
 
 Diffs
 -
 
   plugins/staging/CMakeLists.txt 754362f 
   plugins/staging/formulashape-2g/AlterFormulaCommand.h PRE-CREATION 
   plugins/staging/formulashape-2g/AlterFormulaCommand.cpp PRE-CREATION 
   plugins/staging/formulashape-2g/CMakeLists.txt PRE-CREATION 
   plugins/staging/formulashape-2g/ChangeFormulaCommand.h PRE-CREATION 
   plugins/staging/formulashape-2g/ChangeFormulaCommand.cpp PRE-CREATION 
   plugins/staging/formulashape-2g/FormulaCursor.h PRE-CREATION 
   plugins/staging/formulashape-2g/FormulaCursor.cpp PRE-CREATION 
   plugins/staging/formulashape-2g/FormulaDocument.h PRE-CREATION 
   plugins/staging/formulashape-2g/FormulaDocument.cpp PRE-CREATION 
   plugins/staging/formulashape-2g/FormulaPart.h PRE-CREATION 
   plugins/staging/formulashape-2g/FormulaPart.cpp PRE-CREATION 
   plugins/staging/formulashape-2g/FormulaShape.h PRE-CREATION 
   plugins/staging/formulashape-2g/FormulaShape.cpp PRE-CREATION 
   plugins/staging/formulashape-2g/FormulaShapeFactory.h PRE-CREATION 
   plugins/staging/formulashape-2g/FormulaShapeFactory.cpp PRE-CREATION 
   plugins/staging/formulashape-2g/FormulaShapePlugin.h PRE-CREATION 
   plugins/staging/formulashape-2g/FormulaShapePlugin.cpp PRE-CREATION 
   plugins/staging/formulashape-2g/FormulaTool.h PRE-CREATION 
   plugins/staging/formulashape-2g/FormulaTool.cpp PRE-CREATION 
   plugins/staging/formulashape-2g/FormulaToolFactory.h PRE-CREATION 
   plugins/staging/formulashape-2g/FormulaToolFactory.cpp PRE-CREATION 
   plugins/staging/formulashape-2g/Messages.sh PRE-CREATION 
   plugins/staging/formulashape-2g/formula_export.h PRE-CREATION 
   plugins/staging/formulashape-2g/formulashape2g.desktop PRE-CREATION 
   plugins/staging/formulashape-2g/qtmmlwidget/LGPL_EXCEPTION.txt PRE-CREATION 
   plugins/staging/formulashape-2g/qtmmlwidget/LICENSE.GPL3 PRE-CREATION 
   plugins/staging/formulashape-2g/qtmmlwidget/LICENSE.LGPL PRE-CREATION 
   plugins/staging/formulashape-2g/qtmmlwidget/QtMmlDocument PRE-CREATION 
   plugins/staging/formulashape-2g/qtmmlwidget/QtMmlWidget PRE-CREATION 
   plugins/staging/formulashape-2g/qtmmlwidget/README.TXT PRE-CREATION 
   plugins/staging/formulashape-2g/qtmmlwidget/qtmmlwidget.h PRE-CREATION 
   plugins/staging/formulashape-2g/qtmmlwidget/qtmmlwidget.cpp PRE-CREATION 
 
 Diff: https://git.reviewboard.kde.org/r/109994/diff/
 
 
 Testing
 ---
 
 
 File Attachments
 
 
 Snapshot
   
 https://git.reviewboard.kde.org/media/uploaded/files/2013/04/13/formulaShape.png
 
 
 Thanks,
 
 Gopalakrishna Bhat
 


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

Re: libetonyek, odfgen etc packages for ubuntu?

[Yue Liu]

http://mail.kde.org/pipermail/calligra-devel/2014-June/011310.html

On Sun, Jun 29, 2014 at 9:37 AM, René J.V. rjvber...@gmail.com wrote:
 On Sunday June 29 2014 14:40:49 Jonathan Riddell wrote:

Let me know what's missing and I'll get it updated.

 Check out https://launchpad.net/~rjvbertin/+archive/calligra-dev (as a source 
 for source packages that appear to fit the bill, not for anything official ;) 
 )

 R.

 ___
 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: libetonyek, odfgen etc packages for ubuntu?

[Yue Liu]

On Sun, Jun 29, 2014 at 11:02 AM, René J.V. rjvber...@gmail.com wrote:
 On Sunday June 29 2014 10:42:07 Yue Liu wrote:

http://mail.kde.org/pipermail/calligra-devel/2014-June/011310.html

 Thanks, I'd already begun to understand that much from the cmake output.
 The 0.1 libodfgen and 0.10 libwpd versions are still development branches, 
 right? Any idea what happens if I package them up in the most straightforward 
 way - will the previous/stable versions of those libraries be uninstalled, 
 possibly causing problems with applications other than Calligra (LibreOffice 
 for example ...)?
They are released version. I'm not familiar with package structure on
Ubuntu. LibreOffice use their own copy of those libraries, only
software I know of using them other than Calligra is writerperfect.

Yue

 R.
 ___
 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: libetonyek, odfgen etc packages for ubuntu?

[Yue Liu]

On Sun, Jun 29, 2014 at 11:47 AM, René J.V. rjvber...@gmail.com wrote:
 On Sunday June 29 2014 11:26:01 Yue Liu wrote:

They are released version. I'm not familiar with package structure on
Ubuntu. LibreOffice use their own copy of those libraries, only
software I know of using them other than Calligra is writerperfect.

 They're not release according to http://libwpd.sourceforge.net/download.html 
 ... but that page is simply not uptodate and even SourceForge's Files 
 thingy thinks the latest libwpd release is 0.9.9 
 (http://sourceforge.net/projects/libwpd/files/libwpd/libwpd-0.10.0/). 
 Apologies!
 And at least on Ubuntu, the LibreOffice packages depend on libodfgen and thus 
 libwpd . If the newer version ABI is backwards compatible with the previous 
 version there ought to be no problem though.
ABI is not backwards compatible but it's possible to install multiple
versions at the same time.

 R.
 ___
 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: libetonyek, odfgen etc packages for ubuntu?

[Yue Liu]

I made by mistake by assuming Libreoffice use internal libwpd thing on
Ubuntu, had a look at different distro I found most linux distros use
as much system libs as possible.

Multiple libwpd thing can be installed in parallel if don't build
binary program and don't link libwpd-0.10.so to libwpd.so and don't
change default include path.

The update to libwpd-0.10 is driven by the needs from Archlinux and
Fedora, LibreOffice on Archlinux now requires libwpd-0.10. For other
already released distros, just package new dependencies as mentioned
above.


On Sun, Jun 29, 2014 at 2:04 PM, René J.V. rjvber...@gmail.com wrote:
 On Sunday June 29 2014 21:41:20 Jaroslaw Staniek wrote:

Thanks for mentioning this. For any dependencies that are for our
understanding not mature enough (in term of release management, read:
ABI, API) I recommend having our own copy. You just mentioned
LibreOffice doing similarly.

Bug-free deployment is a #1 value I think.

 I fully agree.

 I just don't really see what you mean with LibreOffice having their own copy 
 (of libwpd c.s.) :

 On Ubuntu:
  apt depends libreoffice-writer

 libreoffice-writer

   Depends: libreoffice-base-core
   Depends: libreoffice-core
   Depends: libc6
   Depends: libgcc1
   Depends: libicu52
   Depends: libstdc++6
   Depends: libwpd-0.9-9
   Depends: libwpg-0.2-2
   Depends: libwps-0.2-2
  

  apt rdepends libwpd-0.9-9

 libwpd-0.9-9

 Reverse Depends:
   libreoffice-writer
   libreoffice-impress
   libreoffice-draw
   wps2odt
   wpg2odg
   wpd2odt
   vsd2odg
   pub2odg
   mwaw2odt
   libwps-tools
   libwpg-tools
   libwpd-tools
   libvisio-tools
   libodfgen-0.0-0
   libmwaw-tools
   libmwaw-0.1-1
   libmspub-tools
   libetonyek-0.0-0
   libcdr-tools
   karbon
   etonyek-bin
   cdr2odg
   calligrawords
   calligraflow
   abiword
   libwps-0.2-2
   libwpg-0.2-2
   libwpd-dev
   libvisio-0.0-0
   libreoffice-writer
   libreoffice-impress
   libreoffice-draw
   libmspub-0.0-0
   libcdr-0.0-0
   inkscape

 Of course, I *think* that a package libwpd-0.10 can be installed perfectly 
 fine in addition to libwpd-0.9-9, idem for libwps, libwpg etc. (but the -dev 
 packages ought to follow the same principle!)

 R.
 ___
 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: [PATCH] rebase import libraries

[Yue Liu]

Hi David,

Thanks for the patch. Somehow keynote import filter related diff is
missing so I also imported writerperfect 0.9 code after applying your
patch to fix it.

Yue

On Mon, Jun 9, 2014 at 11:12 AM, David Tardon dtar...@redhat.com wrote:
 Hello,

 The import interfaces provided by libwpd, libwpg and libetonyek have
 been merged into a new library called librevenge (see announcement of
 the first release here:
 http://listarchives.documentliberation.org/www/discuss/msg00070.html).
 The old interfaces have been removed. That means all the projects that
 used one of the libraries need to be switched to the new interface.
 Patch for calligra master can be found here:
 http://dtardon.fedorapeople.org/calligra/0001-switch-to-librevenge-based-import-libs.patch
  .

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

[PACKAGING] import filter dependencies update

[Yue Liu]

Packagers, start from Calligra 2.9.0, these dependency changes will apply:

New:

librevenge = 0.0.0

Update:

libodfgen = 0.1.0
libetonyek = 0.1.0
libodfgen = 0.1.0
libvisio = 0.1.0
libwpd = 0.10.0
libwpg = 0.3.0
libwps = 0.3.0

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

Re: Krita Sprint 2014, Saturday Meeting

[Yue Liu]

On May 22, 2014 1:57 AM, Boudewijn Rempt b...@valdyas.org wrote:

 On Tuesday 20 May 2014 May 22:12:07 Jaroslaw Staniek wrote:

  I wouldn't like to see any app and feature put in a drawer, so how
  about a call for volunteers as early as possible?

 I'm of course fine with that. I just don't expect any response
whatsoever. We've already got the Unmaintained!!! splashes for Karbon and
Plan, with zero response. Maybe because they are disabled for the release,
which means nobody but people who build from scratch see them... But I
simply doubt that people will volunteer following a call for action,
especially when there are so few people to welcome them.

I'm interested in porting Karbon.
  As a backup plan perhaps some who uses, maintains rule can be
  applied by releasing early, simple version of Qt-only Calligra Engine
  so new people can try it, maybe use it, join us, maintain it and
  develop. So the target users would be software engineers. We're
  stronger in this area or to put it differently: our competition
  (especially FOSS one) is weaker there. That gives natural opportunity.

 I'm not sure how this helps with unmaintained applications or with the
problem that the shared engine isn't a good fit for both artistic
applications and for office applications. I would like to sort of have our
base libraries be comparable to Tier1 KF5 frameworks after the Qt5 port,
though.


  Regarding Calligra 3.0 marketing. It's very important to me and we
  won't have another try. I'd like to propose using a popular Web 2.0
  meaning of Beta for a longer time, asking distros to package our
  releases earely and often. Display a beta sign on all prominent
  places: 3.0 Beta, then _no_ 3.0 stable but 3.1 Beta if needed, ...
  then when we're ready, 3.x stable.
  Alternative that I don't like would be a series of 3.0 Beta 1, 3.0
  Beta 2,   - a bit complex for users and suggests stagnation. I
  learned that in the time of 5 Betas of Kexi 0.1
  (
http://www.kexi-project.org/wiki/wikiview/index@releaseschedule0.x.html)
  10 years ago.
  I know the new approach is nonstandard but indicates the special
  stage. After we would be back to the usual rules.

 But is that really needed? The port to Qt5 isn't really difficult, and if
we're disciplined and do _no_ refactoring at all during the port, we should
be able to release with confidence. I definitely do not want to go without
our regular two releases a year, having a release is too important to keep
users involved and happy. I also don't want to play number games: 2.9 is
the last Qt4-based release, 3.0 is the first Qt5-based release.

I've made a qt backend to a gtkmathview fork, it depends on qt5 so I
haven't make any formula plugin based on that yet. It's very likely
kformula will be replaced by it after port to qt5, in this case do we still
need to port kformula to qt5 if the porting is complicated? (I hope it's
straightforward)
 
  From Kexi side, there are the following stages during the transition:
  - finalization of porting from Qt3Support to Qt 4 - ongoing last
  larger part is being ported - 5 calendar weeks for me
  - porting Predicate lib (aka KexiDB 2) from Qt4 to Qt5 - 3 calendar
weeks for me
  - then, these steps are needed in parallel:
  -- porting Kexi (and a bit of Plan, Words?) from KexiDB to Predicate
  -- 2 months for me (?)

 That's something you either need to do _now_, for 2.9, or after the Qt5
port, for 3.1. Don't try to do anything but a straight Qt5 port during the
Qt5 port, that way lies the KOffice 2 madness!

  -- porting Kexi to Qt5 to make it mostly work -- 2 months for me (?)
  - then this is Kexi 3.0 Beta, and we can start taking benefits from
  access to KF5 (less deps so attractive for 3rdparty computing
  environments) and new candies of Qt5 (solid scripting,
  distro/architecture-independent extensions, forming  community around
  such things)
 
  Regarding possibility of Krita forking some shared UI infra, I would
  welcome Krita continuing of taking usability and convenience/appeal
  for the user as a starting point. Sharing UIs between business/office
  and creative apps shouldn't have higher priority IMHO. And this is not
  a not-invented-here syndrome in Krita (or Kexi where there were
  similar challenges due to specialization of the app). There's still so
  much to be shared, our integration and frameworks won't go  away.
 
 

 --
 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: Review Request 118172: wpg2odg import filter: add missing include dir

[Yue Liu]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118172/#review58083
---

Ship it!


Ship It!

- Yue Liu


On May 16, 2014, 6:46 p.m., Heiko Becker wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/118172/
 ---
 
 (Updated May 16, 2014, 6:46 p.m.)
 
 
 Review request for Calligra.
 
 
 Bugs: 334900
 http://bugs.kde.org/show_bug.cgi?id=334900
 
 
 Repository: calligra
 
 
 Description
 ---
 
 Without this the build failed for me when passing DWITH_LibWpd=ON 
 -DWITH_LibWpg=ON -DWITH_LibOdfGen=ON (amongst others) to cmake.
 
 
 Diffs
 -
 
   filters/flow/wpg/import/CMakeLists.txt 
 524d1b1e2ceab81a1cb06ecf213d3b2f31cb9f31 
 
 Diff: https://git.reviewboard.kde.org/r/118172/diff/
 
 
 Testing
 ---
 
 successfully ran cmake and make
 
 
 Thanks,
 
 Heiko Becker
 


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

Re: Review Request 118106: Simplify dep rule of writeodf.h to rng2cpp, work properly Windows

[Yue Liu]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118106/#review57954
---

Ship it!


Ship It!

- Yue Liu


On May 12, 2014, 8:02 p.m., Friedrich W. H. Kossebau wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/118106/
 ---
 
 (Updated May 12, 2014, 8:02 p.m.)
 
 
 Review request for Calligra, Yue Liu, Boudewijn Rempt, and Jos van den Oever.
 
 
 Repository: calligra
 
 
 Description
 ---
 
 find_program(RNG2CCP_EXECUTABLE rng2cpp [...]), as used to find the path to 
 the rng2cpp executable on Windows, has the disadvantage that it will only 
 work once rng2cpp has been build the first time.
 
 Instead I propose to use the built-in resolution of the created executable 
 and dependency creation with add_custom_command, see 
 http://www.cmake.org/cmake/help/v2.8.0/cmake.html#command:add_custom_command:
 
 [...]
 If COMMAND specifies an executable target (created by ADD_EXECUTABLE) it will 
 automatically be replaced by the location of the executable created at build 
 time. Additionally a target-level dependency will be added so that the 
 executable target will be built before any target using this custom command. 
 However this does NOT add a file-level dependency that would cause the custom 
 command to re-run whenever the executable is recompiled.
 [...]
 
 Keeping rng2cpp and ${RNGFILE} as DEPENDS ensure that there is file-level 
 dependency also to the executable.
 
 Works for me on Linux. Does it also work on Windows and OSX?
 
 
 Diffs
 -
 
   libs/odf/writeodf/CMakeLists.txt 9a99d48 
 
 Diff: https://git.reviewboard.kde.org/r/118106/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Friedrich W. H. Kossebau
 


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

Re: 2.8.1 Changelogs

[Yue Liu]

Flow: Fixed stencil box icon view drag  drop bug. (Bug #331821)

On Thu, Mar 27, 2014 at 5:40 AM, Jaroslaw Staniek stan...@kde.org wrote:
 Hi,
 Dear maintainers, please put 2.8.1 changelogs in this thread.

 Kexi: http://community.kde.org/Kexi/Releases/Kexi_2.8.1

 --
 regards / pozdrawiam, Jaroslaw Staniek
  Kexi  Calligra  KDE | http://calligra.org/kexi | http://kde.org
  Qt for Tizen | http://qt-project.org/wiki/Tizen
  Qt Certified Specialist | http://www.linkedin.com/in/jstaniek

 ___
 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 116844: update minimum cmake requirement to 2.8.10, use cmake built-in FindGLEW.cmake

[Yue Liu]

We can do that if there are platforms without 2.8.10 we need to support.

On Sun, Mar 23, 2014 at 2:29 PM, Jaroslaw Staniek stan...@kde.org wrote:
 Hi, can't we just back port the cake file?


 On Sunday, 23 March 2014, Yue Liu yue@mail.com wrote:
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/116844/

 This change has been marked as submitted.

 Review request for Calligra.
 By Yue Liu.

 Updated March 23, 2014, 6:22 p.m.

 Repository: calligra

 Description

 Current FindGLEW doesn't work on OSX. The one from cmake = 2.8.10 works.
 From information on http://pkgs.org/search/?query=cmaketype=name, most
 distro already has that version.
 Cent6 needs EPEL repo, Debian Wheezy needs backports repo, slackware 14.0
 needs ktown repo, Ubuntu 12.04 needs Kubuntu backports, Ubuntu 12.10 not
 supported, newer version of these distros and other popular distros are
 supported. Homebrew and Macports supported, not sure the situation on
 Windows.

 Testing

 Works on OSX 10.9.2, Windows 7 x64, Arch Linux x64.

 Diffs

 CMakeLists.txt (e376487)
 cmake/modules/FindGLEW.cmake (adcc452)
 krita/CMakeLists.txt (b9745ce)

 View Diff

 --
 regards / pozdrawiam, Jaroslaw Staniek
  Kexi  Calligra  KDE | http://calligra.org/kexi | http://kde.org
  Qt for Tizen | http://qt-project.org/wiki/Tizen
  Qt Certified Specialist | http://www.linkedin.com/in/jstaniek

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

Re: Review Request 116844: update minimum cmake requirement to 2.8.10, use cmake built-in FindGLEW.cmake

[Yue Liu]

ok. I'll revert the change.

On Sun, Mar 23, 2014 at 4:46 PM, Jaroslaw Staniek stan...@kde.org wrote:
 I have 2.8.9 on my pretty modern machine. Also I know people using Ubuntu
 12.10 or 12.04 not willing to install backports for THIS single reason :)

 Summing up I really recommend to just backport; I've followed this approach
 with mysql/pgsql detection code and I am still using
 FindCalligraSqlite.cmake.
 Convenience for users is a priority.



 On 23 March 2014 21:37, Yue Liu yue@mail.com wrote:

 We can do that if there are platforms without 2.8.10 we need to support.

 On Sun, Mar 23, 2014 at 2:29 PM, Jaroslaw Staniek stan...@kde.org wrote:
  Hi, can't we just back port the cake file?
 
 
  On Sunday, 23 March 2014, Yue Liu yue@mail.com wrote:
  This is an automatically generated e-mail. To reply, visit:
  https://git.reviewboard.kde.org/r/116844/
 
  This change has been marked as submitted.
 
  Review request for Calligra.
  By Yue Liu.
 
  Updated March 23, 2014, 6:22 p.m.
 
  Repository: calligra
 
  Description
 
  Current FindGLEW doesn't work on OSX. The one from cmake = 2.8.10
  works.
  From information on http://pkgs.org/search/?query=cmaketype=name, most
  distro already has that version.
  Cent6 needs EPEL repo, Debian Wheezy needs backports repo, slackware
  14.0
  needs ktown repo, Ubuntu 12.04 needs Kubuntu backports, Ubuntu 12.10
  not
  supported, newer version of these distros and other popular distros are
  supported. Homebrew and Macports supported, not sure the situation on
  Windows.
 
  Testing
 
  Works on OSX 10.9.2, Windows 7 x64, Arch Linux x64.
 
  Diffs
 
  CMakeLists.txt (e376487)
  cmake/modules/FindGLEW.cmake (adcc452)
  krita/CMakeLists.txt (b9745ce)
 
  View Diff
 
  --
  regards / pozdrawiam, Jaroslaw Staniek
   Kexi  Calligra  KDE | http://calligra.org/kexi | http://kde.org
   Qt for Tizen | http://qt-project.org/wiki/Tizen
   Qt Certified Specialist | http://www.linkedin.com/in/jstaniek
 




 --
 regards / pozdrawiam, Jaroslaw Staniek
  Kexi  Calligra  KDE | http://calligra.org/kexi | http://kde.org
  Qt for Tizen | http://qt-project.org/wiki/Tizen
  Qt Certified Specialist | http://www.linkedin.com/in/jstaniek
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Review Request 116844: update minimum cmake requirement to 2.8.10, use cmake built-in FindGLEW.cmake

[Yue Liu]

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

(Updated March 23, 2014, 9:31 p.m.)


Status
--

This change has been discarded.


Review request for Calligra.


Repository: calligra


Description
---

Current FindGLEW doesn't work on OSX. The one from cmake = 2.8.10 works.
From information on http://pkgs.org/search/?query=cmaketype=name, most distro 
already has that version.
Cent6 needs EPEL repo, Debian Wheezy needs backports repo, slackware 14.0 needs 
ktown repo, Ubuntu 12.04 needs Kubuntu backports, Ubuntu 12.10 not supported, 
newer version of these distros and other popular distros are supported. 
Homebrew and Macports supported, not sure the situation on Windows.


Diffs
-

  CMakeLists.txt e376487 
  cmake/modules/FindGLEW.cmake adcc452 
  krita/CMakeLists.txt b9745ce 

Diff: https://git.reviewboard.kde.org/r/116844/diff/


Testing
---

Works on OSX 10.9.2, Windows 7 x64, Arch Linux x64.


Thanks,

Yue Liu

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

Re: Review Request 116816: Small patches for building on Mac OS X against KDE

[Yue Liu]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116816/#review53870
---


do you still have the gmic clang issue?

- Yue Liu


On March 16, 2014, 8:17 a.m., RJVB Bertin wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/116816/
 ---
 
 (Updated March 16, 2014, 8:17 a.m.)
 
 
 Review request for Calligra.
 
 
 Repository: calligra
 
 
 Description
 ---
 
 Small modifications for building on Mac OS X against KDE, Qt and other 
 libraries installed through MacPorts installed under /opt/local. MacPorts 
 installs GLEW as a simple dylib in /opt/local/lib, FindGLEW.cmake has been 
 modified accordingly. I installed Vc (not in MacPorts) by hand into 
 /opt/local; the modification to FindVc.cmake is possibly redundant. The 
 modification to kis_opengl_canvas2_p.h enables building on systems that do 
 not have the (optional!) GLEW framework.
 
 Note that gmic.cpp is so huge that clang 3.3 needs almost 20GB memory at some 
 time, and takes an enormous time to compile.
 
 
 Diffs
 -
 
   cmake/modules/FindGLEW.cmake adcc452 
   cmake/modules/FindVc.cmake bb9823f 
   krita/ui/opengl/kis_opengl_canvas2_p.h 3b1e369 
 
 Diff: https://git.reviewboard.kde.org/r/116816/diff/
 
 
 Testing
 ---
 
 With these modifications the non-packager OSX productset builds correctly on 
 my OS X 10.6.8 system (after also modifying cmake's 
 CMAKE_SHARED_MODULE_CREATE formulas), using the clang-3.3 compiler from 
 MacPorts.
 Basic functionality appears correct in all member applications, and 79% of 
 the unittests succeed.
 
 I have not tested my patch to kis_opengl_canvas2_p.h exhaustively as if 
 figured out why GLEW wasn't found shortly after patching the file, but it's a 
 step in the right direction if GLEW is indeed to be an optional dependency.
 
 
 Thanks,
 
 RJVB Bertin
 


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

Re: Review Request 115611: KoFileDialogHelper = KoFileDialog refactor

[Yue Liu]

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

(Updated March 23, 2014, 12:21 a.m.)


Status
--

This change has been marked as submitted.


Review request for Calligra.


Repository: calligra


Description
---

When I'm porting Q/KFileDialog thing to KoFileDialogHelper I found there are 
some design issues so refactored KoFileDialogHelper.

Now it names as KoFileDialog and moved to kowidgets.

Some use cases of file dialog check return value of dialog.exec(), so static 
methods are abandoned and a getDialog() method is provided to do whatever you 
want to the QFileDialog object, using static methods also results in parameter 
list too long.

Some use cases just use name filters instead of mimetype, so filter setter 
refactored to 3 methods:
setNameFilter(QString), setNameFilters(QStringList), 
setMimeTypeFilters(QStringList)

Qt 5.2 introduced QFileDialog::setMimeTypeFilters(QStringList) but its not 
available through static methods, another excuse to abandon static methods.

Added getXXX() methods as convenience for what static methods usually do.


Diffs
-

  krita/gemini/desktopviewproxy.cpp 489a440 
  krita/plugins/assistants/RulerAssistant/kis_ruler_assistant_tool.cc dc4faa2 
  krita/plugins/extensions/dockers/flipbook/flipbookdocker_dock.cpp ad95ef6 
  krita/plugins/extensions/dockers/lut/lutdocker_dock.cpp bd5a8e3 
  krita/plugins/extensions/imagesplit/imagesplit.cpp 1928893 
  krita/plugins/extensions/separate_channels/kis_channel_separator.cc d6d1769 
  krita/ui/dialogs/kis_dlg_file_layer.cpp ec5aa52 
  krita/ui/dialogs/kis_dlg_preferences.cc c02577f 
  krita/ui/kis_image_manager.cc 8aeddd3 
  krita/ui/kis_node_manager.cpp 25ca964 
  krita/ui/widgets/KisFlipbookSelector.cpp 9384790 
  krita/ui/widgets/kis_color_space_selector.cc 73bde3b 
  libs/main/CMakeLists.txt ac708c8 
  libs/main/KoDocument.cpp 70c838c 
  libs/main/KoFileDialogHelper.h 4afafd4 
  libs/main/KoFileDialogHelper.cpp 2483bc4 
  libs/main/KoMainWindow.cpp 11a7248 
  libs/main/KoOpenPane.cpp bf5b219 
  libs/widgets/CMakeLists.txt 01f015b 
  libs/widgets/KoEditColorSetDialog.cpp bf4eabe 
  libs/widgets/KoFileDialog.h PRE-CREATION 
  libs/widgets/KoFileDialog.cpp PRE-CREATION 
  sheets/dialogs/CSVDialog.cpp 4e9d7ed 

Diff: https://git.reviewboard.kde.org/r/115611/diff/


Testing
---

Works on OSX.

But I remember the reason static methods are used is related to some 
kfiledialog-related bugs on Windows, please test whether KFileDialog is still 
used when setting UseNativeDialog=true in kdeglobals on Windows.


Thanks,

Yue Liu

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

Review Request 116844: update minimum cmake requirement to 2.8.10, use cmake built-in FindGLEW.cmake

[Yue Liu]

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

Review request for Calligra.


Repository: calligra


Description
---

Current FindGLEW doesn't work on OSX. The one from cmake = 2.8.10 works.
From information on http://pkgs.org/search/?query=cmaketype=name, most distro 
already has that version.
Cent6 needs EPEL repo, Debian Wheezy needs backports repo, slackware 14.0 needs 
ktown repo, Ubuntu 12.04 needs Kubuntu backports, Ubuntu 12.10 not supported, 
newer version of these distros and other popular distros are supported. 
Homebrew and Macports supported, not sure the situation on Windows.


Diffs
-

  CMakeLists.txt e376487 
  cmake/modules/FindGLEW.cmake adcc452 
  krita/CMakeLists.txt b9745ce 

Diff: https://git.reviewboard.kde.org/r/116844/diff/


Testing
---

Works on OSX, need testing on Linux and Windows.


Thanks,

Yue Liu

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

Re: 2.8 changelog and stories

[Yue Liu]

On Wed, Mar 5, 2014 at 5:31 AM, Jaroslaw Staniek stan...@kde.org wrote:
 On 3 March 2014 18:22, Yue Liu yue@mail.com wrote:
 Not much happened to Flow.

 * Added SVG stencil support.

 OK, would you mind to provide a screenshot?
This is no changes to the GUI



 On Mon, Mar 3, 2014 at 3:40 AM, Boudewijn Rempt b...@valdyas.org wrote:
 On Monday 03 March 2014 Mar 00:25:31 Jaroslaw Staniek wrote:
 Hello,
 2.8.0 has been tagged by Cyrille today.
 As we're getting closer to public 2.8 release on Wednesday March 5,
 changelog and short stories from each maintainer is needed by Tuesday.

 My part for Kexi:
 http://community.kde.org/Kexi/Releases/Kexi_2.8#List_of_changes




 Here's the draft for the release article for krita.org:

 https://docs.google.com/document/d/1-_z_ofFCQfb4Vm09WsUMxT04xmM-RxD7UutpYhXUMV0/edit?usp=sharing


 Short summary for the calligra.org announcement:

 Krita 2.8.0 is the first stable release of Krita for Windows. Supported by 
 the Krita Development Fund (http://krita.org/support-krita#general), an 
 enormous amount of work has been done improving the support for graphics 
 tablets. Both Huion (http://huiontablet.com/) and Wacom (wacom.com) have 
 generously donated hardware to help us realize the improved support. The 
 OpenGL support has been rewritten and now sports an amazingly high-quality 
 scaling algorithm which is very suitable for working with detailed high-res 
 lineart.

 Artists working on games will be pleased with the wrap-around mode that 
 tiles artwork dynamically, making creating seamlessly tiled textures really 
 easy. The clones array feature gives games developers an easy way to create 
 artwork for tiled games.

 G'Mic integration means opening up the enormous set of filters and image 
 manipulaiton algorithms developed by David Tschumperle 
 (http://gmic.sourceforge.net/) at the Greyc lab in Caen. There are many 
 improvements and additions to Krita's native filters as well, thanks to 
 Sahil Nagpal's Google Summer of Code project.

 And, of course, more than seven hundred bugs have been fixed, there are 
 many usability enhancements, performance improvements, improvements in file 
 import/export compatibility. For a full report, go to krita.org (XXX) or 
 read the introduction to Krita 2.8 (XXX)

 


 The last two links will go live on Wednesday :-)

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



 --
 regards / pozdrawiam, Jaroslaw Staniek
  Kexi  Calligra  KDE | http://calligra.org/kexi | http://kde.org
  Qt for Tizen | http://qt-project.org/wiki/Tizen
  Qt Certified Specialist | http://www.linkedin.com/in/jstaniek
 ___
 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: 2.8 changelog and stories

[Yue Liu]

Not much happened to Flow.

* Added SVG stencil support.

On Mon, Mar 3, 2014 at 3:40 AM, Boudewijn Rempt b...@valdyas.org wrote:
 On Monday 03 March 2014 Mar 00:25:31 Jaroslaw Staniek wrote:
 Hello,
 2.8.0 has been tagged by Cyrille today.
 As we're getting closer to public 2.8 release on Wednesday March 5,
 changelog and short stories from each maintainer is needed by Tuesday.

 My part for Kexi:
 http://community.kde.org/Kexi/Releases/Kexi_2.8#List_of_changes




 Here's the draft for the release article for krita.org:

 https://docs.google.com/document/d/1-_z_ofFCQfb4Vm09WsUMxT04xmM-RxD7UutpYhXUMV0/edit?usp=sharing


 Short summary for the calligra.org announcement:

 Krita 2.8.0 is the first stable release of Krita for Windows. Supported by 
 the Krita Development Fund (http://krita.org/support-krita#general), an 
 enormous amount of work has been done improving the support for graphics 
 tablets. Both Huion (http://huiontablet.com/) and Wacom (wacom.com) have 
 generously donated hardware to help us realize the improved support. The 
 OpenGL support has been rewritten and now sports an amazingly high-quality 
 scaling algorithm which is very suitable for working with detailed high-res 
 lineart.

 Artists working on games will be pleased with the wrap-around mode that tiles 
 artwork dynamically, making creating seamlessly tiled textures really easy. 
 The clones array feature gives games developers an easy way to create artwork 
 for tiled games.

 G'Mic integration means opening up the enormous set of filters and image 
 manipulaiton algorithms developed by David Tschumperle 
 (http://gmic.sourceforge.net/) at the Greyc lab in Caen. There are many 
 improvements and additions to Krita's native filters as well, thanks to Sahil 
 Nagpal's Google Summer of Code project.

 And, of course, more than seven hundred bugs have been fixed, there are many 
 usability enhancements, performance improvements, improvements in file 
 import/export compatibility. For a full report, go to krita.org (XXX) or read 
 the introduction to Krita 2.8 (XXX)

 


 The last two links will go live on Wednesday :-)

 --
 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: Final release date?

[Yue Liu]

+1

On Fri, Feb 28, 2014 at 3:13 AM, Jaroslaw Staniek stan...@kde.org wrote:
 +1


 On Thursday, 27 February 2014, Dmitry Kazakov dimul...@gmail.com wrote:
 Maintainers, ping! Are we releasing next Wednesday? :)


 On Wed, Feb 26, 2014 at 11:44 PM, Boudewijn Rempt b...@valdyas.org
 wrote:

 Ping... _Will_ we be able to release next week? I'd like some
 confirmation this time.

 On Tuesday 25 February 2014 Feb 11:25:04 Boudewijn Rempt wrote:
  On Tuesday 04 February 2014 Feb 10:41:20 Boudewijn Rempt wrote:
   I wouldn't mind an extra beta. We've fixed most of the bugs on the
   list
   already, and getting some testing would be nice. I would like to
   release
   2.8.0 this month, though.
  
   So maybe tag the beta this weekend, and then tag for release 22nd,
   with
   the release on the 26th?
 
  So we don't have a release on the 26th :-(. Nobody apparently took the
  effort to read this proposal or answer it, and I was stupid enough to 
  assume
  that meant assent. Quite a few people are waiting for the 2.8.0 release, 
  and
  I was dumb enough to tell them the 26th... For me, this is a bit of a
  disaster.
 
  09:06:39  boud CyrilleB: did you tag 2.8.0 already?
  09:09:56  CyrilleB no not yet
  09:10:12  boud ok
  09:10:47  boud apart from really wanting to figure out a way to
  restore krita to a working state after enabling opengl on a broken windows
  install, we're good to go as
   far as krita is concerned
  09:10:54  CyrilleB possibly next week-end, but I need to talk to
  ingwa to plan the announcement better for that release
  09:11:10  boud aw... I thought we'd planned on releasing the 26th
 
  But I want to really fix the release date, there are a lot of press
  releases and other marketing stuff to get ready and send out.
 
  Can we fix the relase on March 5th? If it's only the calligra.org
  announcement coordination that's blocking the release, that should be
  doable, right?
 
 

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



 --
 Dmitry Kazakov

 --
 regards / pozdrawiam, Jaroslaw Staniek
  Kexi  Calligra  KDE | http://calligra.org/kexi | http://kde.org
  Qt for Tizen | http://qt-project.org/wiki/Tizen
  Qt Certified Specialist | http://www.linkedin.com/in/jstaniek


 ___
 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 116054: Remove some irritating warnings

[Yue Liu]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116054/#review50872
---

Ship it!


Ship It!

- Yue Liu


On Feb. 25, 2014, 7:03 p.m., Inge Wallin wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/116054/
 ---
 
 (Updated Feb. 25, 2014, 7:03 p.m.)
 
 
 Review request for Calligra.
 
 
 Repository: calligra
 
 
 Description
 ---
 
 This patch removes some very irritating warnings about missing definitions of 
 __x86_64__ and __ppc64__. Problem is that they were given in *every* compiled 
 file.
 
 Ok to backport?
 
 
 Diffs
 -
 
   KoConfig.h.cmake c56c3ac 
 
 Diff: https://git.reviewboard.kde.org/r/116054/diff/
 
 
 Testing
 ---
 
 No warnings anymore and seems not to affect anything else.
 
 
 Thanks,
 
 Inge Wallin
 


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

Review Request 115611: KoFileDialogHelper = KoFileDialog refactor

[Yue Liu]

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

Review request for Calligra.


Repository: calligra


Description
---

When I'm porting Q/KFileDialog thing to KoFileDialogHelper I found there are 
some design issues so refactored KoFileDialogHelper.

Now it names as KoFileDialog and moved to kowidgets.

Some use cases of file dialog check return value of dialog.exec(), so static 
methods are abandoned and a getDialog() method is provided to do whatever you 
want to the QFileDialog object, using static methods also results in parameter 
list too long.

Some use cases just use name filters instead of mimetype, so filter setter 
refactored to 3 methods:
setNameFilter(QString), setNameFilters(QStringList), 
setMimeTypeFilters(QStringList)

Qt 5.2 introduced QFileDialog::setMimeTypeFilters(QStringList) but its not 
available through static methods, another excuse to abandon static methods.

Added getXXX() methods as convenience for what static methods usually do.


Diffs
-

  krita/gemini/desktopviewproxy.cpp 489a440 
  krita/plugins/assistants/RulerAssistant/kis_ruler_assistant_tool.cc dc4faa2 
  krita/plugins/extensions/dockers/flipbook/flipbookdocker_dock.cpp ad95ef6 
  krita/plugins/extensions/dockers/lut/lutdocker_dock.cpp bd5a8e3 
  krita/plugins/extensions/imagesplit/imagesplit.cpp 1928893 
  krita/plugins/extensions/separate_channels/kis_channel_separator.cc d6d1769 
  krita/ui/dialogs/kis_dlg_file_layer.cpp ec5aa52 
  krita/ui/dialogs/kis_dlg_preferences.cc c02577f 
  krita/ui/kis_image_manager.cc 8aeddd3 
  krita/ui/kis_node_manager.cpp 25ca964 
  krita/ui/widgets/KisFlipbookSelector.cpp 9384790 
  krita/ui/widgets/kis_color_space_selector.cc 73bde3b 
  libs/main/CMakeLists.txt ac708c8 
  libs/main/KoDocument.cpp 70c838c 
  libs/main/KoFileDialogHelper.h 4afafd4 
  libs/main/KoFileDialogHelper.cpp 2483bc4 
  libs/main/KoMainWindow.cpp 11a7248 
  libs/main/KoOpenPane.cpp bf5b219 
  libs/widgets/CMakeLists.txt 01f015b 
  libs/widgets/KoEditColorSetDialog.cpp bf4eabe 
  libs/widgets/KoFileDialog.h PRE-CREATION 
  libs/widgets/KoFileDialog.cpp PRE-CREATION 
  sheets/dialogs/CSVDialog.cpp 4e9d7ed 

Diff: https://git.reviewboard.kde.org/r/115611/diff/


Testing
---

Works on OSX.

But I remember the reason static methods are used is related to some 
kfiledialog-related bugs on Windows, please test whether KFileDialog is still 
used when setting UseNativeDialog=true in kdeglobals on Windows.


Thanks,

Yue Liu

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

Re: Announcement of 2.8beta

[Yue Liu]

On Sat, Dec 7, 2013 at 5:45 PM, Inge Wallin i...@lysator.liu.se wrote:
 I have now written an announcement but I am lacking a few pieces of the
 puzzle.



 * The krita changelog is too long to inclue in its entirety. Is there a
 changelog on krita.org that we could link to?



 * I have seen nothing in the thread about changes in Plan but I know that
 there have been such changes. Friedrich: could you give me a short list?



 * Same question for Sheets, Stage, Flow, Brainstorm and any other that I
 didn't see a changelog for. (I got the info about Kexi from jaroslaw in real
 time.)



 * Yue: Is there anything to write about Calligra on OSX or is that too
 early?
Nothing for now.




 I also felt insecure to publish the announcement without proof reading so I
 am grateful for any feedback. The preview link is
 http://www.calligra.org/?p=3989preview=true (you need to be logged in to do
 that).



 If you answer these questions, we can publish the announcement tomorrow.



 -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

Re: Review Request 114193: Added new cmake macros and find_package modules, added new dependency libodfgen, deleted writerperfect, use libodfgen instead

[Yue Liu]

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

(Updated Dec. 4, 2013, 6:09 p.m.)


Review request for Calligra.


Repository: calligra


Description (updated)
---

Use LibFindMacros.cmake to simplify package finding, fixed FindFFTW3, 
FindLIBWPD, FINDLIBWPG on mac, and some other mac fixes.
Added dependency libodfgen and future dependency libetonyek, deleteed 
writerperfet code.

To test the patch, just checkout branch cmake-fix-osx-yue


Diffs
-

  CMakeLists.txt 6587ecc 
  cmake/modules/FindFFTW3.cmake a4c8997 
  cmake/modules/FindLibEtonyek.cmake PRE-CREATION 
  cmake/modules/FindLibOdfGen.cmake PRE-CREATION 
  cmake/modules/FindLibVisio.cmake 69a598a 
  cmake/modules/FindLibWPS.cmake e34f382 
  cmake/modules/FindLibWpd.cmake PRE-CREATION 
  cmake/modules/FindLibWpg.cmake PRE-CREATION 
  cmake/modules/FindLibWps.cmake PRE-CREATION 
  cmake/modules/FindWPD.cmake 0f666b3 
  cmake/modules/FindWPG.cmake 066e579 
  cmake/modules/LibFindMacros.cmake PRE-CREATION 
  filters/CMakeLists.txt ba04b83 
  filters/flow/CMakeLists.txt c37d395 
  filters/flow/visio/import/CMakeLists.txt 55b8488 
  filters/flow/visio/import/VSDXImport.h 712d9d7 
  filters/flow/visio/import/VSDXImport.cpp 788379e 
  filters/flow/wpg/CMakeLists.txt PRE-CREATION 
  filters/flow/wpg/import/CMakeLists.txt PRE-CREATION 
  filters/flow/wpg/import/WPGImport.h PRE-CREATION 
  filters/flow/wpg/import/WPGImport.cpp PRE-CREATION 
  filters/flow/wpg/import/calligra_filter_wpg2odg.desktop PRE-CREATION 
  filters/flow/wpg/import/flow_wpg_thumbnail.desktop PRE-CREATION 
  filters/karbon/wpg/CMakeLists.txt e8600a0 
  filters/libodfhandler/DiskDocumentHandler.hxx PRE-CREATION 
  filters/libodfhandler/DiskDocumentHandler.cxx PRE-CREATION 
  filters/libodfhandler/FemtoZip.hxx PRE-CREATION 
  filters/libodfhandler/FemtoZip.cxx PRE-CREATION 
  filters/libodfhandler/OutputFileHelper.hxx PRE-CREATION 
  filters/libodfhandler/OutputFileHelper.cxx PRE-CREATION 
  filters/libodfhandler/StdOutHandler.hxx PRE-CREATION 
  filters/libodfhandler/StdOutHandler.cxx PRE-CREATION 
  filters/words/wordperfect/import/CMakeLists.txt cbcf650 
  filters/words/wordperfect/import/WPDImport.h ad515f7 
  filters/words/wordperfect/import/WPDImport.cpp e3b2c2c 
  filters/words/works/import/CMakeLists.txt 082cb31 
  filters/words/works/import/WPSImport.h 2d1b20c 
  filters/words/works/import/WPSImport.cpp e52d5b5 
  filters/writerperfect/CMakeLists.txt 1f57075 
  filters/writerperfect/DiskDocumentHandler.hxx 7b37ea3 
  filters/writerperfect/DiskDocumentHandler.cxx 799fdd0 
  filters/writerperfect/DocumentElement.hxx 5a03977 
  filters/writerperfect/DocumentElement.cxx 47a9d7e 
  filters/writerperfect/FemtoZip.hxx afecf5e 
  filters/writerperfect/FemtoZip.cxx c52a707 
  filters/writerperfect/FilterInternal.hxx eb2ddf8 
  filters/writerperfect/FontStyle.hxx 379b9c1 
  filters/writerperfect/FontStyle.cxx 111b46d 
  filters/writerperfect/InternalHandler.hxx 9223f1f 
  filters/writerperfect/InternalHandler.cxx 6ad9142 
  filters/writerperfect/ListStyle.hxx 94b31f8 
  filters/writerperfect/ListStyle.cxx dab5058 
  filters/writerperfect/OdfDocumentHandler.hxx d2911a9 
  filters/writerperfect/OdgGenerator.hxx 7296935 
  filters/writerperfect/OdgGenerator.cxx 49a3ac3 
  filters/writerperfect/OdtGenerator.hxx 425143d 
  filters/writerperfect/OdtGenerator.cxx bbcdc5c 
  filters/writerperfect/OutputFileHelper.hxx 48023b1 
  filters/writerperfect/OutputFileHelper.cxx 22a1895 
  filters/writerperfect/PageSpan.hxx 64c7053 
  filters/writerperfect/PageSpan.cxx c64a1dd 
  filters/writerperfect/SectionStyle.hxx bb52a55 
  filters/writerperfect/SectionStyle.cxx 2e5d352 
  filters/writerperfect/StdOutHandler.hxx de5d402 
  filters/writerperfect/StdOutHandler.cxx f8175f2 
  filters/writerperfect/Style.hxx 2682b24 
  filters/writerperfect/TableStyle.hxx bcd45a5 
  filters/writerperfect/TableStyle.cxx 1b99b6e 
  filters/writerperfect/TextRunStyle.hxx 63c297d 
  filters/writerperfect/TextRunStyle.cxx e34b2dd 
  filters/writerperfect/WriterProperties.hxx 8b61b65 
  krita/image/CMakeLists.txt da1102c 
  krita/image/kis_assert.cpp 17a85f8 
  krita/plugins/extensions/gmic/CMakeLists.txt 15291af 
  libs/main/KoDocument.cpp 0a17961 
  libs/widgets/KoEditColorSetDialog.cpp d683bcc 

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


Testing
---

Works on OSX 10.9, and Arch Linux. Please check if the FindXXX changes work on 
windows.


Thanks,

Yue Liu

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

Re: Review Request 114193: Added new cmake macros and find_package modules, added new dependency libodfgen, deleted writerperfect, use libodfgen instead

[Yue Liu]

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

(Updated Dec. 3, 2013, 5:05 p.m.)


Review request for Calligra.


Summary (updated)
-

Added new cmake macros and find_package modules, added new dependency 
libodfgen, deleted writerperfect, use libodfgen instead


Repository: calligra


Description (updated)
---

Use LibFindMacros.cmake to simplify package finding, fixed FindFFTW3, 
FindLIBWPD, FINDLIBWPG on mac, and some other mac fixes.
Added dependency libodfgen and future dependency libetonyek, deleteed 
writerperfet code.


Diffs (updated)
-

  CMakeLists.txt 6587ecc 
  cmake/modules/FindFFTW3.cmake a4c8997 
  cmake/modules/FindLibEtonyek.cmake PRE-CREATION 
  cmake/modules/FindLibOdfGen.cmake PRE-CREATION 
  cmake/modules/FindLibVisio.cmake 69a598a 
  cmake/modules/FindLibWPS.cmake e34f382 
  cmake/modules/FindLibWpd.cmake PRE-CREATION 
  cmake/modules/FindLibWpg.cmake PRE-CREATION 
  cmake/modules/FindLibWps.cmake PRE-CREATION 
  cmake/modules/FindWPD.cmake 0f666b3 
  cmake/modules/FindWPG.cmake 066e579 
  cmake/modules/LibFindMacros.cmake PRE-CREATION 
  filters/CMakeLists.txt ba04b83 
  filters/flow/CMakeLists.txt c37d395 
  filters/flow/visio/import/CMakeLists.txt 55b8488 
  filters/flow/visio/import/VSDXImport.h 712d9d7 
  filters/flow/visio/import/VSDXImport.cpp 788379e 
  filters/flow/wpg/CMakeLists.txt PRE-CREATION 
  filters/flow/wpg/import/CMakeLists.txt PRE-CREATION 
  filters/flow/wpg/import/WPGImport.h PRE-CREATION 
  filters/flow/wpg/import/WPGImport.cpp PRE-CREATION 
  filters/flow/wpg/import/calligra_filter_wpg2odg.desktop PRE-CREATION 
  filters/flow/wpg/import/flow_wpg_thumbnail.desktop PRE-CREATION 
  filters/karbon/wpg/CMakeLists.txt e8600a0 
  filters/libodfhandler/DiskDocumentHandler.hxx PRE-CREATION 
  filters/libodfhandler/DiskDocumentHandler.cxx PRE-CREATION 
  filters/libodfhandler/FemtoZip.hxx PRE-CREATION 
  filters/libodfhandler/FemtoZip.cxx PRE-CREATION 
  filters/libodfhandler/OutputFileHelper.hxx PRE-CREATION 
  filters/libodfhandler/OutputFileHelper.cxx PRE-CREATION 
  filters/libodfhandler/StdOutHandler.hxx PRE-CREATION 
  filters/libodfhandler/StdOutHandler.cxx PRE-CREATION 
  filters/words/wordperfect/import/CMakeLists.txt cbcf650 
  filters/words/wordperfect/import/WPDImport.h ad515f7 
  filters/words/wordperfect/import/WPDImport.cpp e3b2c2c 
  filters/words/works/import/CMakeLists.txt 082cb31 
  filters/words/works/import/WPSImport.h 2d1b20c 
  filters/words/works/import/WPSImport.cpp e52d5b5 
  filters/writerperfect/CMakeLists.txt 1f57075 
  filters/writerperfect/DiskDocumentHandler.hxx 7b37ea3 
  filters/writerperfect/DiskDocumentHandler.cxx 799fdd0 
  filters/writerperfect/DocumentElement.hxx 5a03977 
  filters/writerperfect/DocumentElement.cxx 47a9d7e 
  filters/writerperfect/FemtoZip.hxx afecf5e 
  filters/writerperfect/FemtoZip.cxx c52a707 
  filters/writerperfect/FilterInternal.hxx eb2ddf8 
  filters/writerperfect/FontStyle.hxx 379b9c1 
  filters/writerperfect/FontStyle.cxx 111b46d 
  filters/writerperfect/InternalHandler.hxx 9223f1f 
  filters/writerperfect/InternalHandler.cxx 6ad9142 
  filters/writerperfect/ListStyle.hxx 94b31f8 
  filters/writerperfect/ListStyle.cxx dab5058 
  filters/writerperfect/OdfDocumentHandler.hxx d2911a9 
  filters/writerperfect/OdgGenerator.hxx 7296935 
  filters/writerperfect/OdgGenerator.cxx 49a3ac3 
  filters/writerperfect/OdtGenerator.hxx 425143d 
  filters/writerperfect/OdtGenerator.cxx bbcdc5c 
  filters/writerperfect/OutputFileHelper.hxx 48023b1 
  filters/writerperfect/OutputFileHelper.cxx 22a1895 
  filters/writerperfect/PageSpan.hxx 64c7053 
  filters/writerperfect/PageSpan.cxx c64a1dd 
  filters/writerperfect/SectionStyle.hxx bb52a55 
  filters/writerperfect/SectionStyle.cxx 2e5d352 
  filters/writerperfect/StdOutHandler.hxx de5d402 
  filters/writerperfect/StdOutHandler.cxx f8175f2 
  filters/writerperfect/Style.hxx 2682b24 
  filters/writerperfect/TableStyle.hxx bcd45a5 
  filters/writerperfect/TableStyle.cxx 1b99b6e 
  filters/writerperfect/TextRunStyle.hxx 63c297d 
  filters/writerperfect/TextRunStyle.cxx e34b2dd 
  filters/writerperfect/WriterProperties.hxx 8b61b65 
  krita/image/CMakeLists.txt da1102c 
  krita/image/kis_assert.cpp 17a85f8 
  krita/plugins/extensions/gmic/CMakeLists.txt 15291af 
  libs/main/KoDocument.cpp 0a17961 
  libs/widgets/KoEditColorSetDialog.cpp d683bcc 

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


Testing (updated)
---

Works on OSX 10.9, and Arch Linux. Please check if the FindXXX changes work on 
windows.


Thanks,

Yue Liu

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

Review Request 114193: Use LibFindMacros.cmake to simplify package finding, fixed FindFFTW3, FindLIBWPD, FINDLIBWPG on mac, and some other mac fixes.

[Yue Liu]

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

Review request for Calligra.


Repository: calligra


Description
---


Diffs
-

  CMakeLists.txt 6587ecc 
  cmake/modules/FindFFTW3.cmake a4c8997 
  cmake/modules/FindLIBWPD.cmake PRE-CREATION 
  cmake/modules/FindLibWpg.cmake PRE-CREATION 
  cmake/modules/FindWPD.cmake 0f666b3 
  cmake/modules/FindWPG.cmake 066e579 
  cmake/modules/LibFindMacros.cmake PRE-CREATION 
  filters/flow/visio/import/CMakeLists.txt 55b8488 
  filters/karbon/wpg/CMakeLists.txt e8600a0 
  filters/words/wordperfect/import/CMakeLists.txt cbcf650 
  filters/words/works/import/CMakeLists.txt 082cb31 
  filters/writerperfect/CMakeLists.txt 1f57075 
  krita/image/CMakeLists.txt da1102c 
  krita/image/kis_assert.cpp 17a85f8 
  krita/plugins/extensions/gmic/CMakeLists.txt 15291af 
  libs/main/KoDocument.cpp 0a17961 
  libs/widgets/KoEditColorSetDialog.cpp d683bcc 

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


Testing
---

Works on OSX 10.9, but I feel something wrong for windows. Please check if the 
FindXXX changes work on windows.


Thanks,

Yue Liu

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

Re: Review Request 109907: Use platform native file dialogs

[Yue Liu]

 On Oct. 12, 2013, 10:34 a.m., Boudewijn Rempt wrote:
  Builds and works fine on Windows. Weird thing is that for instance the File 
  Layer dialog in Krita uses the KDE dialog now.

Thats because i haven't changed that one yet.


- Yue


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


On Oct. 2, 2013, 1:44 a.m., Yue Liu wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/109907/
 ---
 
 (Updated Oct. 2, 2013, 1:44 a.m.)
 
 
 Review request for Calligra.
 
 
 Repository: calligra
 
 
 Description
 ---
 
 Currently kfiledialog and kofiledialog is widely used, this results in 
 non-native file dialog on Mac/Windows/Gnome. However, qfiledialog static 
 methods does not support modal sheet in Mac, so a KoModalFileDialog is 
 created for window-modal file dialog, such as save as or import, while other 
 file dialog such as open will use qfiledialog static methods.
 
 This is a very first version which blocks save as encrypted since encrypted 
 odf has same suffix as normal odf while when using native dialog you have to 
 use suffix to distinguish different format. My idea is to create another menu 
 item Save As Encrypted... where encrypted odf will be saved.
 
 There are still many file dialogs not touched yet, and for places where 
 kfilewidget is used, such as startup file open widget, kexi file widget, 
 export to pdf widget, it is impossible to use native dialog. My idea is 
 redesign those widget and split the configure part and file chooser part into 
 two separate dialogs, then use native file dialogs.
 
 
 Diffs
 -
 
   flow/part/flow.rc f6fa60a 
   krita/plugins/extensions/bigbrother/bigbrother.cc 5ba4ac5 
   libs/main/CMakeLists.txt 3a9110c 
   libs/main/KoDetailsPaneBase.ui d692a00 
   libs/main/KoExistingDocumentPane.h fd7b4fd 
   libs/main/KoExistingDocumentPane.cpp 2ea6746 
   libs/main/KoFileDialog.h da94281 
   libs/main/KoFileDialog.cpp c5a7fc2 
   libs/main/KoFileDialogHelper.h PRE-CREATION 
   libs/main/KoFileDialogHelper.cpp PRE-CREATION 
   libs/main/KoMainWindow.h 1b3503f 
   libs/main/KoMainWindow.cpp 10cef0e 
   libs/main/KoOpenPane.h 4e9ac13 
   libs/main/KoOpenPane.cpp 53d4b48 
   libs/main/KoOpenPaneBase.ui 0b2f2cf 
   libs/odf/KoDirectoryStore.cpp da4949e 
   plan/workpackage/application.cpp b3642d6 
   sheets/dialogs/CSVDialog.h 0763538 
   sheets/dialogs/CSVDialog.cpp 4d6a19d 
   sheets/sheets.rc 76439c0 
   stage/part/stage.rc 2dba463 
   stage/stage.rc d0b912f 
   stage/stage_only.rc 73c743b 
   words/part/author/author.rc b5567f5 
   words/part/words.rc 31cabbd 
 
 Diff: http://git.reviewboard.kde.org/r/109907/diff/
 
 
 Testing
 ---
 
 Works fine on OS X 10.8
 
 
 File Attachments
 
 
 save as dialog
   
 http://git.reviewboard.kde.org/media/uploaded/files/2013/04/08/Screen_Shot_2013-04-07_at_11.54.47_PM.png
 
 
 Thanks,
 
 Yue Liu
 


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

Re: Review Request 109907: Use platform native file dialogs

[Yue Liu]

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

(Updated Oct. 12, 2013, 5:43 p.m.)


Status
--

This change has been marked as submitted.


Review request for Calligra.


Repository: calligra


Description
---

Currently kfiledialog and kofiledialog is widely used, this results in 
non-native file dialog on Mac/Windows/Gnome. However, qfiledialog static 
methods does not support modal sheet in Mac, so a KoModalFileDialog is created 
for window-modal file dialog, such as save as or import, while other file 
dialog such as open will use qfiledialog static methods.

This is a very first version which blocks save as encrypted since encrypted odf 
has same suffix as normal odf while when using native dialog you have to use 
suffix to distinguish different format. My idea is to create another menu item 
Save As Encrypted... where encrypted odf will be saved.

There are still many file dialogs not touched yet, and for places where 
kfilewidget is used, such as startup file open widget, kexi file widget, export 
to pdf widget, it is impossible to use native dialog. My idea is redesign those 
widget and split the configure part and file chooser part into two separate 
dialogs, then use native file dialogs.


Diffs
-

  flow/part/flow.rc f6fa60a 
  krita/plugins/extensions/bigbrother/bigbrother.cc 5ba4ac5 
  libs/main/CMakeLists.txt 3a9110c 
  libs/main/KoDetailsPaneBase.ui d692a00 
  libs/main/KoExistingDocumentPane.h fd7b4fd 
  libs/main/KoExistingDocumentPane.cpp 2ea6746 
  libs/main/KoFileDialog.h da94281 
  libs/main/KoFileDialog.cpp c5a7fc2 
  libs/main/KoFileDialogHelper.h PRE-CREATION 
  libs/main/KoFileDialogHelper.cpp PRE-CREATION 
  libs/main/KoMainWindow.h 1b3503f 
  libs/main/KoMainWindow.cpp 10cef0e 
  libs/main/KoOpenPane.h 4e9ac13 
  libs/main/KoOpenPane.cpp 53d4b48 
  libs/main/KoOpenPaneBase.ui 0b2f2cf 
  libs/odf/KoDirectoryStore.cpp da4949e 
  plan/workpackage/application.cpp b3642d6 
  sheets/dialogs/CSVDialog.h 0763538 
  sheets/dialogs/CSVDialog.cpp 4d6a19d 
  sheets/sheets.rc 76439c0 
  stage/part/stage.rc 2dba463 
  stage/stage.rc d0b912f 
  stage/stage_only.rc 73c743b 
  words/part/author/author.rc b5567f5 
  words/part/words.rc 31cabbd 

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


Testing
---

Works fine on OS X 10.8


File Attachments


save as dialog
  
http://git.reviewboard.kde.org/media/uploaded/files/2013/04/08/Screen_Shot_2013-04-07_at_11.54.47_PM.png


Thanks,

Yue Liu

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

Re: Review Request 109907: Use platform native file dialogs

[Yue Liu]

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

(Updated Oct. 1, 2013, 10:38 p.m.)


Review request for Calligra.


Changes
---

Todo:
apply KoFileDialogHelper to minor dialogs which load/save custom 
config/resource files
all Kexi stuff (KexiFileWidget - native file dialogs)

Testing Done:
old features still work on mac.
I don't have QCA on mac, so didn't test whether it actually save as encrypted, 
but the createStore part is not modified so it should work as it used to be.

Known Issues:
when saving to directory it cannot create new dir but save to current dir 
selected in file dialog
menu entries sometimes lost in Flow but that is another issue


Repository: calligra


Description
---

Currently kfiledialog and kofiledialog is widely used, this results in 
non-native file dialog on Mac/Windows/Gnome. However, qfiledialog static 
methods does not support modal sheet in Mac, so a KoModalFileDialog is created 
for window-modal file dialog, such as save as or import, while other file 
dialog such as open will use qfiledialog static methods.

This is a very first version which blocks save as encrypted since encrypted odf 
has same suffix as normal odf while when using native dialog you have to use 
suffix to distinguish different format. My idea is to create another menu item 
Save As Encrypted... where encrypted odf will be saved.

There are still many file dialogs not touched yet, and for places where 
kfilewidget is used, such as startup file open widget, kexi file widget, export 
to pdf widget, it is impossible to use native dialog. My idea is redesign those 
widget and split the configure part and file chooser part into two separate 
dialogs, then use native file dialogs.


Diffs (updated)
-

  flow/part/flow.rc f6fa60a 
  krita/plugins/extensions/bigbrother/bigbrother.cc 5ba4ac5 
  libs/main/CMakeLists.txt 3a9110c 
  libs/main/KoDetailsPaneBase.ui d692a00 
  libs/main/KoExistingDocumentPane.h fd7b4fd 
  libs/main/KoExistingDocumentPane.cpp 2ea6746 
  libs/main/KoFileDialog.h da94281 
  libs/main/KoFileDialog.cpp c5a7fc2 
  libs/main/KoFileDialogHelper.h PRE-CREATION 
  libs/main/KoFileDialogHelper.cpp PRE-CREATION 
  libs/main/KoMainWindow.h 1b3503f 
  libs/main/KoMainWindow.cpp 10cef0e 
  libs/main/KoOpenPane.h 4e9ac13 
  libs/main/KoOpenPane.cpp 53d4b48 
  libs/main/KoOpenPaneBase.ui 0b2f2cf 
  plan/workpackage/application.cpp b3642d6 
  sheets/dialogs/CSVDialog.h 0763538 
  sheets/dialogs/CSVDialog.cpp 4d6a19d 
  sheets/sheets.rc 76439c0 
  stage/part/stage.rc 2dba463 
  stage/stage.rc d0b912f 
  stage/stage_only.rc 73c743b 
  words/part/author/author.rc b5567f5 
  words/part/words.rc 31cabbd 

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


Testing
---

Works fine on OS X 10.8


File Attachments


save as dialog
  
http://git.reviewboard.kde.org/media/uploaded/files/2013/04/08/Screen_Shot_2013-04-07_at_11.54.47_PM.png


Thanks,

Yue Liu

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

Re: Review Request 109907: Use platform native file dialogs

[Yue Liu]

 On Oct. 2, 2013, 12:15 a.m., Andrius da Costa Ribas wrote:
  In my work I use to save documents. In remote (sftp) places because I have 
  not much disk in my local machine. This is not possible using native win 
  dialog. IMHO this should be a configurable setting, as it is with KDE4 in 
  general (not sure how this is working on KF5)

now I feel maybe I should just use plain static qfiledialog methods at first..

So what this patch did is, for open it internally called static qfiledialog 
methods, so it will use kfiledialog and when you don't specify native=true in 
kdeglobals it still use kfiledialog on Windows and Mac. For saving I used 
qfiledialog-exec() in window modal, somehow it does not use kfiledialog (not 
sure if it is a bug or intentionally designed in kfiledialog), replacing save 
dialogs code with static qfiledialog methods solves your concern, and the code 
would be even simpler, but we'll lost sheet style dialog in osx.


- Yue


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


On Oct. 1, 2013, 10:38 p.m., Yue Liu wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/109907/
 ---
 
 (Updated Oct. 1, 2013, 10:38 p.m.)
 
 
 Review request for Calligra.
 
 
 Repository: calligra
 
 
 Description
 ---
 
 Currently kfiledialog and kofiledialog is widely used, this results in 
 non-native file dialog on Mac/Windows/Gnome. However, qfiledialog static 
 methods does not support modal sheet in Mac, so a KoModalFileDialog is 
 created for window-modal file dialog, such as save as or import, while other 
 file dialog such as open will use qfiledialog static methods.
 
 This is a very first version which blocks save as encrypted since encrypted 
 odf has same suffix as normal odf while when using native dialog you have to 
 use suffix to distinguish different format. My idea is to create another menu 
 item Save As Encrypted... where encrypted odf will be saved.
 
 There are still many file dialogs not touched yet, and for places where 
 kfilewidget is used, such as startup file open widget, kexi file widget, 
 export to pdf widget, it is impossible to use native dialog. My idea is 
 redesign those widget and split the configure part and file chooser part into 
 two separate dialogs, then use native file dialogs.
 
 
 Diffs
 -
 
   flow/part/flow.rc f6fa60a 
   krita/plugins/extensions/bigbrother/bigbrother.cc 5ba4ac5 
   libs/main/CMakeLists.txt 3a9110c 
   libs/main/KoDetailsPaneBase.ui d692a00 
   libs/main/KoExistingDocumentPane.h fd7b4fd 
   libs/main/KoExistingDocumentPane.cpp 2ea6746 
   libs/main/KoFileDialog.h da94281 
   libs/main/KoFileDialog.cpp c5a7fc2 
   libs/main/KoFileDialogHelper.h PRE-CREATION 
   libs/main/KoFileDialogHelper.cpp PRE-CREATION 
   libs/main/KoMainWindow.h 1b3503f 
   libs/main/KoMainWindow.cpp 10cef0e 
   libs/main/KoOpenPane.h 4e9ac13 
   libs/main/KoOpenPane.cpp 53d4b48 
   libs/main/KoOpenPaneBase.ui 0b2f2cf 
   plan/workpackage/application.cpp b3642d6 
   sheets/dialogs/CSVDialog.h 0763538 
   sheets/dialogs/CSVDialog.cpp 4d6a19d 
   sheets/sheets.rc 76439c0 
   stage/part/stage.rc 2dba463 
   stage/stage.rc d0b912f 
   stage/stage_only.rc 73c743b 
   words/part/author/author.rc b5567f5 
   words/part/words.rc 31cabbd 
 
 Diff: http://git.reviewboard.kde.org/r/109907/diff/
 
 
 Testing
 ---
 
 Works fine on OS X 10.8
 
 
 File Attachments
 
 
 save as dialog
   
 http://git.reviewboard.kde.org/media/uploaded/files/2013/04/08/Screen_Shot_2013-04-07_at_11.54.47_PM.png
 
 
 Thanks,
 
 Yue Liu
 


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

Re: Review Request 109907: Use platform native file dialogs

[Yue Liu]

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

(Updated Oct. 2, 2013, 1:15 a.m.)


Review request for Calligra.


Changes
---

Use configurable kfiledialogs on all platforms eexcept osx. Now everyone should 
be happy, unless someone tell me he want kfiledialog on mac...


Repository: calligra


Description
---

Currently kfiledialog and kofiledialog is widely used, this results in 
non-native file dialog on Mac/Windows/Gnome. However, qfiledialog static 
methods does not support modal sheet in Mac, so a KoModalFileDialog is created 
for window-modal file dialog, such as save as or import, while other file 
dialog such as open will use qfiledialog static methods.

This is a very first version which blocks save as encrypted since encrypted odf 
has same suffix as normal odf while when using native dialog you have to use 
suffix to distinguish different format. My idea is to create another menu item 
Save As Encrypted... where encrypted odf will be saved.

There are still many file dialogs not touched yet, and for places where 
kfilewidget is used, such as startup file open widget, kexi file widget, export 
to pdf widget, it is impossible to use native dialog. My idea is redesign those 
widget and split the configure part and file chooser part into two separate 
dialogs, then use native file dialogs.


Diffs (updated)
-

  flow/part/flow.rc f6fa60a 
  krita/plugins/extensions/bigbrother/bigbrother.cc 5ba4ac5 
  libs/main/CMakeLists.txt 3a9110c 
  libs/main/KoDetailsPaneBase.ui d692a00 
  libs/main/KoExistingDocumentPane.h fd7b4fd 
  libs/main/KoExistingDocumentPane.cpp 2ea6746 
  libs/main/KoFileDialog.h da94281 
  libs/main/KoFileDialog.cpp c5a7fc2 
  libs/main/KoFileDialogHelper.h PRE-CREATION 
  libs/main/KoFileDialogHelper.cpp PRE-CREATION 
  libs/main/KoMainWindow.h 1b3503f 
  libs/main/KoMainWindow.cpp 10cef0e 
  libs/main/KoOpenPane.h 4e9ac13 
  libs/main/KoOpenPane.cpp 53d4b48 
  libs/main/KoOpenPaneBase.ui 0b2f2cf 
  plan/workpackage/application.cpp b3642d6 
  sheets/dialogs/CSVDialog.h 0763538 
  sheets/dialogs/CSVDialog.cpp 4d6a19d 
  sheets/sheets.rc 76439c0 
  stage/part/stage.rc 2dba463 
  stage/stage.rc d0b912f 
  stage/stage_only.rc 73c743b 
  words/part/author/author.rc b5567f5 
  words/part/words.rc 31cabbd 

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


Testing
---

Works fine on OS X 10.8


File Attachments


save as dialog
  
http://git.reviewboard.kde.org/media/uploaded/files/2013/04/08/Screen_Shot_2013-04-07_at_11.54.47_PM.png


Thanks,

Yue Liu

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

Re: Review Request 109907: Use platform native file dialogs

[Yue Liu]

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

(Updated Oct. 2, 2013, 1:44 a.m.)


Review request for Calligra.


Changes
---

All bugs fixed. Please test if works on all platforms.


Repository: calligra


Description
---

Currently kfiledialog and kofiledialog is widely used, this results in 
non-native file dialog on Mac/Windows/Gnome. However, qfiledialog static 
methods does not support modal sheet in Mac, so a KoModalFileDialog is created 
for window-modal file dialog, such as save as or import, while other file 
dialog such as open will use qfiledialog static methods.

This is a very first version which blocks save as encrypted since encrypted odf 
has same suffix as normal odf while when using native dialog you have to use 
suffix to distinguish different format. My idea is to create another menu item 
Save As Encrypted... where encrypted odf will be saved.

There are still many file dialogs not touched yet, and for places where 
kfilewidget is used, such as startup file open widget, kexi file widget, export 
to pdf widget, it is impossible to use native dialog. My idea is redesign those 
widget and split the configure part and file chooser part into two separate 
dialogs, then use native file dialogs.


Diffs (updated)
-

  flow/part/flow.rc f6fa60a 
  krita/plugins/extensions/bigbrother/bigbrother.cc 5ba4ac5 
  libs/main/CMakeLists.txt 3a9110c 
  libs/main/KoDetailsPaneBase.ui d692a00 
  libs/main/KoExistingDocumentPane.h fd7b4fd 
  libs/main/KoExistingDocumentPane.cpp 2ea6746 
  libs/main/KoFileDialog.h da94281 
  libs/main/KoFileDialog.cpp c5a7fc2 
  libs/main/KoFileDialogHelper.h PRE-CREATION 
  libs/main/KoFileDialogHelper.cpp PRE-CREATION 
  libs/main/KoMainWindow.h 1b3503f 
  libs/main/KoMainWindow.cpp 10cef0e 
  libs/main/KoOpenPane.h 4e9ac13 
  libs/main/KoOpenPane.cpp 53d4b48 
  libs/main/KoOpenPaneBase.ui 0b2f2cf 
  libs/odf/KoDirectoryStore.cpp da4949e 
  plan/workpackage/application.cpp b3642d6 
  sheets/dialogs/CSVDialog.h 0763538 
  sheets/dialogs/CSVDialog.cpp 4d6a19d 
  sheets/sheets.rc 76439c0 
  stage/part/stage.rc 2dba463 
  stage/stage.rc d0b912f 
  stage/stage_only.rc 73c743b 
  words/part/author/author.rc b5567f5 
  words/part/words.rc 31cabbd 

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


Testing
---

Works fine on OS X 10.8


File Attachments


save as dialog
  
http://git.reviewboard.kde.org/media/uploaded/files/2013/04/08/Screen_Shot_2013-04-07_at_11.54.47_PM.png


Thanks,

Yue Liu

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

Re: Review Request 109907: Use platform native file dialogs

[Yue Liu]

 On Sept. 24, 2013, 7:47 p.m., Sven Langkamp wrote:
  What are the possible downsides of this? Any functionality that we miss 
  from KFileDialog? KIO maybe?

In theory, under KDE it will use KFileDialog, in Gnome use Gtk file dialog, in 
Windows and Mac also use their native one. But currently only tested under Mac.


- Yue


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


On Sept. 23, 2013, 3:01 a.m., Yue Liu wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/109907/
 ---
 
 (Updated Sept. 23, 2013, 3:01 a.m.)
 
 
 Review request for Calligra.
 
 
 Description
 ---
 
 Currently kfiledialog and kofiledialog is widely used, this results in 
 non-native file dialog on Mac/Windows/Gnome. However, qfiledialog static 
 methods does not support modal sheet in Mac, so a KoModalFileDialog is 
 created for window-modal file dialog, such as save as or import, while other 
 file dialog such as open will use qfiledialog static methods.
 
 This is a very first version which blocks save as encrypted since encrypted 
 odf has same suffix as normal odf while when using native dialog you have to 
 use suffix to distinguish different format. My idea is to create another menu 
 item Save As Encrypted... where encrypted odf will be saved.
 
 There are still many file dialogs not touched yet, and for places where 
 kfilewidget is used, such as startup file open widget, kexi file widget, 
 export to pdf widget, it is impossible to use native dialog. My idea is 
 redesign those widget and split the configure part and file chooser part into 
 two separate dialogs, then use native file dialogs.
 
 
 Diffs
 -
 
   krita/plugins/extensions/bigbrother/bigbrother.cc 5ba4ac5 
   libs/main/CMakeLists.txt 3a9110c 
   libs/main/KoDetailsPaneBase.ui d692a00 
   libs/main/KoExistingDocumentPane.h fd7b4fd 
   libs/main/KoExistingDocumentPane.cpp 2ea6746 
   libs/main/KoFileDialog.h da94281 
   libs/main/KoFileDialog.cpp c5a7fc2 
   libs/main/KoFileDialogHelper.h PRE-CREATION 
   libs/main/KoFileDialogHelper.cpp PRE-CREATION 
   libs/main/KoMainWindow.cpp d5fbde0 
   libs/main/KoOpenPane.h 46c291d 
   libs/main/KoOpenPane.cpp a1a7411 
   libs/main/KoOpenPaneBase.ui 0b2f2cf 
   plan/workpackage/application.cpp b3642d6 
   sheets/dialogs/CSVDialog.h 0763538 
   sheets/dialogs/CSVDialog.cpp 4d6a19d 
 
 Diff: http://git.reviewboard.kde.org/r/109907/diff/
 
 
 Testing
 ---
 
 Works fine on OS X 10.8
 
 
 File Attachments
 
 
 save as dialog
   
 http://git.reviewboard.kde.org/media/uploaded/files/2013/04/08/Screen_Shot_2013-04-07_at_11.54.47_PM.png
 
 
 Thanks,
 
 Yue Liu
 


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

Re: Review Request 109907: Use platform native file dialogs

[Yue Liu]

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

(Updated Sept. 23, 2013, 2:04 a.m.)


Review request for Calligra.


Changes
---

Re-designed KoOpenPane, open dialog in application modal, save/import/export 
dialog in window modal, support save recent file dialog directory in config 
file.

TODO:
add logic for special mimefilters (directory, flat xml)
put document encryption feature in File menu (currently as special mimefilter, 
won't work for native dialogs because same extension name)
apply QFileDialog or KoFileDialogHelper to minor file dialogs in various 
applications (export pdf, import resources files).
all Kexi stuff (KexiFileWidget - native file dialogs)`


Summary (updated)
-

Use platform native file dialogs


Description
---

Currently kfiledialog and kofiledialog is widely used, this results in 
non-native file dialog on Mac/Windows/Gnome. However, qfiledialog static 
methods does not support modal sheet in Mac, so a KoModalFileDialog is created 
for window-modal file dialog, such as save as or import, while other file 
dialog such as open will use qfiledialog static methods.

This is a very first version which blocks save as encrypted since encrypted odf 
has same suffix as normal odf while when using native dialog you have to use 
suffix to distinguish different format. My idea is to create another menu item 
Save As Encrypted... where encrypted odf will be saved.

There are still many file dialogs not touched yet, and for places where 
kfilewidget is used, such as startup file open widget, kexi file widget, export 
to pdf widget, it is impossible to use native dialog. My idea is redesign those 
widget and split the configure part and file chooser part into two separate 
dialogs, then use native file dialogs.


Diffs (updated)
-

  sheets/dialogs/CSVDialog.cpp 4d6a19d 
  sheets/dialogs/CSVDialog.h 0763538 
  plan/workpackage/application.cpp b3642d6 
  libs/main/KoOpenPaneBase.ui 0b2f2cf 
  libs/main/KoOpenPane.cpp a1a7411 
  libs/main/KoOpenPane.h 46c291d 
  libs/main/KoMainWindow.cpp d5fbde0 
  libs/main/KoFileDialogHelper.cpp PRE-CREATION 
  libs/main/KoFileDialogHelper.h PRE-CREATION 
  libs/main/KoFileDialog.cpp c5a7fc2 
  libs/main/KoFileDialog.h da94281 
  libs/main/KoExistingDocumentPane.cpp 2ea6746 
  libs/main/KoExistingDocumentPane.h fd7b4fd 
  libs/main/KoDetailsPaneBase.ui d692a00 
  libs/main/CMakeLists.txt 3a9110c 
  krita/plugins/extensions/bigbrother/bigbrother.cc 5ba4ac5 

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


Testing
---

Works fine on OS X 10.8


File Attachments


save as dialog
  
http://git.reviewboard.kde.org/media/uploaded/files/2013/04/08/Screen_Shot_2013-04-07_at_11.54.47_PM.png


Thanks,

Yue Liu

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

Re: Review Request 109907: Use platform native file dialogs

[Yue Liu]

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

(Updated Sept. 23, 2013, 3:01 a.m.)


Review request for Calligra.


Description
---

Currently kfiledialog and kofiledialog is widely used, this results in 
non-native file dialog on Mac/Windows/Gnome. However, qfiledialog static 
methods does not support modal sheet in Mac, so a KoModalFileDialog is created 
for window-modal file dialog, such as save as or import, while other file 
dialog such as open will use qfiledialog static methods.

This is a very first version which blocks save as encrypted since encrypted odf 
has same suffix as normal odf while when using native dialog you have to use 
suffix to distinguish different format. My idea is to create another menu item 
Save As Encrypted... where encrypted odf will be saved.

There are still many file dialogs not touched yet, and for places where 
kfilewidget is used, such as startup file open widget, kexi file widget, export 
to pdf widget, it is impossible to use native dialog. My idea is redesign those 
widget and split the configure part and file chooser part into two separate 
dialogs, then use native file dialogs.


Diffs (updated)
-

  krita/plugins/extensions/bigbrother/bigbrother.cc 5ba4ac5 
  libs/main/CMakeLists.txt 3a9110c 
  libs/main/KoDetailsPaneBase.ui d692a00 
  libs/main/KoExistingDocumentPane.h fd7b4fd 
  libs/main/KoExistingDocumentPane.cpp 2ea6746 
  libs/main/KoFileDialog.h da94281 
  libs/main/KoFileDialog.cpp c5a7fc2 
  libs/main/KoFileDialogHelper.h PRE-CREATION 
  libs/main/KoFileDialogHelper.cpp PRE-CREATION 
  libs/main/KoMainWindow.cpp d5fbde0 
  libs/main/KoOpenPane.h 46c291d 
  libs/main/KoOpenPane.cpp a1a7411 
  libs/main/KoOpenPaneBase.ui 0b2f2cf 
  plan/workpackage/application.cpp b3642d6 
  sheets/dialogs/CSVDialog.h 0763538 
  sheets/dialogs/CSVDialog.cpp 4d6a19d 

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


Testing
---

Works fine on OS X 10.8


File Attachments


save as dialog
  
http://git.reviewboard.kde.org/media/uploaded/files/2013/04/08/Screen_Shot_2013-04-07_at_11.54.47_PM.png


Thanks,

Yue Liu

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

Re: Review Request 109278: fix preedit string problem when layout the document, fix input method query problem in artistictext tool

[Yue Liu]

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


I found the patch cause problem when you insert preedit string in the middle of 
a line.

- Yue Liu


On March 10, 2013, 9:30 a.m., Yue Liu wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/109278/
 ---
 
 (Updated March 10, 2013, 9:30 a.m.)
 
 
 Review request for Calligra.
 
 
 Description
 ---
 
 when use input method with preedit string, application will crash when layout 
 the document.
 when using artistictext tool, input method context dialog won't update 
 position.
 
 
 Diffs
 -
 
   libs/textlayout/KoTextLayoutArea.cpp afbd57e 
   libs/textlayout/KoTextLayoutArea_paint.cpp 6671e2d 
   plugins/artistictextshape/ArtisticTextTool.h 49cd7a1 
   plugins/artistictextshape/ArtisticTextTool.cpp dab0764 
   plugins/textshape/TextTool.cpp decb758 
 
 Diff: http://git.reviewboard.kde.org/r/109278/diff/
 
 
 Testing
 ---
 
 most crash resolved. still one crash in testing, will investigate if that was 
 the same issue.
 
 
 Thanks,
 
 Yue Liu
 


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

Re: Review Request 109082: Separate files for the app into own subdir app/ for Stage and Words

[Yue Liu]

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


Any directory change is fine with Mac. Only cmake configuration decides what 
should be packaged into app bundle.

- Yue Liu


On Feb. 22, 2013, 11:01 a.m., Friedrich W. H. Kossebau wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/109082/
 ---
 
 (Updated Feb. 22, 2013, 11:01 a.m.)
 
 
 Review request for Calligra, C. Boemann, Yue Liu, and Thorsten Zachmann.
 
 
 Description
 ---
 
 Splitting out the app-related files from the part/ directory makes the 
 sources easier to grasp (should also help beginners with Calligra code). And 
 it also results in having the complete sources for the product Stage 
 executable and Words executable in a separate dir structure, so decision 
 about building it or not is not some if-defed longer span in a CMakeLists.txt 
 file (of part/), but instead can be done in simply-to-overlook lines in the 
 dir level above, like
 --- 8 ---
 if (SHOULD_BUILD_WORDS_APP)
 add_subdirectory( app )
 endif (SHOULD_BUILD_WORDS_APP)
 --- 8 ---
 
 In preparation for https://git.reviewboard.kde.org/r/109071/ which currently 
 also includes this changes.
 
 Possibly should be done for all programs which have such a part/ dir and 
 still include the app-related files there. But for now only Sheets, Stage and 
 Words are to be separated in two products each, the core/part (also used by 
 CalligraActive) and the executable (not needed with CalligraActive).
 
 
 Diffs
 -
 
   words/app/main.cpp PRE-CREATION 
   words/app/words.desktop PRE-CREATION 
   words/part/CMakeLists.txt 56b8c6f 
   words/part/Info.plist.template 97e1728 
   words/part/main.cpp 875eb5d 
   words/part/words.desktop 35bc4c3 
   stage/app/stage.desktop PRE-CREATION 
   stage/part/CMakeLists.txt de57a0f 
   stage/part/Info.plist.template 857a8d7 
   stage/part/main.cpp 5ef9509 
   stage/part/stage.desktop 447858f 
   words/CMakeLists.txt e6336a2 
   words/Messages.sh 3f2c3d2 
   words/app/CMakeLists.txt PRE-CREATION 
   words/app/Info.plist.template PRE-CREATION 
   stage/CMakeLists.txt 94dd31c 
   stage/app/CMakeLists.txt PRE-CREATION 
   stage/app/Info.plist.template PRE-CREATION 
   stage/app/main.cpp PRE-CREATION 
 
 Diff: http://git.reviewboard.kde.org/r/109082/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Friedrich W. H. Kossebau
 


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

Re: Review Request 108579: remove file FindKOfficeLibs.cmake.in and a duplicated line for creating FindCalligraLibs.cmake

[Yue Liu]

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


One more duplication in the install command in line 6

- Yue Liu


On Jan. 25, 2013, 12:59 p.m., Friedrich W. H. Kossebau wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/108579/
 ---
 
 (Updated Jan. 25, 2013, 12:59 p.m.)
 
 
 Review request for Calligra.
 
 
 Description
 ---
 
 Seems that in the switch from Calligra to KOffice 
 FindCalligraLibs.cmake.in was copied from FindKOfficeLibs.cmake.in, but the 
 latter not removed.
 And additionally the old line to turn FindCalligraLibs.cmake.in into 
 FindCalligraLibs.cmake got a nameswitch, instead of being removed.
 
 But already turning FindCalligraLibs.cmake.in into FindCalligraLibs.cmake 
 once is enough ;)
 
 Attached patch removes the duplicated line and also the file 
 cmake/modules/FindKOfficeLibs.cmake.in (somehow git diff did not add it to 
 the patch I uploaded).
 
 Problem found by Yue and reported this morning on #calligra.
 
 
 Diffs
 -
 
   cmake/modules/CMakeLists.txt 59f6186 
 
 Diff: http://git.reviewboard.kde.org/r/108579/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Friedrich W. H. Kossebau
 


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

Review Request 108481: Temporarily swith to path tool to change shape parameters without double click to switch tool

[Yue Liu]

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

Review request for Calligra.


Description
---

After patch is applied, is a single parameter shape is selected in default 
tool, parameter handles will be painted. If mouse move on the handles, will 
temporarily switch to path tool so users can edit shape parameters. In 
temporary path tool if mouse move off from the handles, current tool will be 
switched back to default tool.

Now double click in default tool can be used for other tasks, such as add a new 
textbox for current shape.


Diffs
-

  libs/flake/KoParameterShape.h 9c0db7a 
  libs/flake/tools/KoPathTool.h af906bb 
  libs/flake/tools/KoPathTool.cpp 9dd8caf 
  libs/flake/tools/KoPathToolFactory.h 2aacfe5 
  libs/flake/tools/KoPathToolFactory.cpp 1846c86 
  plugins/defaultTools/defaulttool/DefaultTool.cpp db7c489 
  plugins/defaultTools/defaulttool/SelectionDecorator.h 83e715e 
  plugins/defaultTools/defaulttool/SelectionDecorator.cpp 3e16cfa 

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


Testing
---

works in words, stage, flow, karbon


Thanks,

Yue Liu

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

Re: Review Request: Readd formats menu (Select Masterpage, Edit Page layout) to Flow

[Yue Liu]

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

Ship it!


- Yue Liu


On Jan. 6, 2013, 4:03 a.m., Friedrich W. H. Kossebau wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/108220/
 ---
 
 (Updated Jan. 6, 2013, 4:03 a.m.)
 
 
 Review request for Calligra and Yue Liu.
 
 
 Description
 ---
 
 KoPAView::initActions() is adding actions for selecting the Master Page... 
 and setting the Page Layout..., but they do not make it into the menu of 
 Calligra Flow, because the flow.rc misses to have the proper entries 
 format_masterpage and format_pagelayout (and these are also not part of 
 ui_standards.rc).
 
 Attached patch adds a menu Format with the two entries, for consistency 
 like Stage has (though Stage adds own menu entries as well).
 
 Okay to also backport to 2.6?
 
 There is one flaw, but that also exist with Stage now: switching to another 
 format does not trigger a repaint. Has to be fixed separately.
 
 
 Diffs
 -
 
   flow/part/flow.rc 3e90a63 
 
 Diff: http://git.reviewboard.kde.org/r/108220/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Friedrich W. H. Kossebau
 


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

Re: Review Request: Readd formats menu (Select Masterpage, Edit Page layout) to Flow

[Yue Liu]

 On Jan. 10, 2013, 1:25 a.m., Yue Liu wrote:
 

please also backport to 2.6.


- Yue


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


On Jan. 6, 2013, 4:03 a.m., Friedrich W. H. Kossebau wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/108220/
 ---
 
 (Updated Jan. 6, 2013, 4:03 a.m.)
 
 
 Review request for Calligra and Yue Liu.
 
 
 Description
 ---
 
 KoPAView::initActions() is adding actions for selecting the Master Page... 
 and setting the Page Layout..., but they do not make it into the menu of 
 Calligra Flow, because the flow.rc misses to have the proper entries 
 format_masterpage and format_pagelayout (and these are also not part of 
 ui_standards.rc).
 
 Attached patch adds a menu Format with the two entries, for consistency 
 like Stage has (though Stage adds own menu entries as well).
 
 Okay to also backport to 2.6?
 
 There is one flaw, but that also exist with Stage now: switching to another 
 format does not trigger a repaint. Has to be fixed separately.
 
 
 Diffs
 -
 
   flow/part/flow.rc 3e90a63 
 
 Diff: http://git.reviewboard.kde.org/r/108220/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Friedrich W. H. Kossebau
 


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

Re: Review Request: Added retina compatible (1024x1024) icons for most apps.

[Yue Liu]

 On Dec. 16, 2012, 9:38 a.m., Inge Wallin wrote:
  The patch itself looks fine.
  
  But I wonder: Is it really necessary to install icons with that high 
  resolution? I thought that's why we use SVG to begin with, to get 
  scalability. In very low resolutions there is often need for manual 
  tweaking but is this also true at 256x256 and up?
 
 Boudewijn Rempt wrote:
 Well, it's the os/desktop environment that needs to support svg icons to 
 show high-res app icons, so I guess OSX doesn't support that.

osx don't support svg


- Yue


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


On Dec. 16, 2012, 7:49 a.m., Yue Liu wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/107753/
 ---
 
 (Updated Dec. 16, 2012, 7:49 a.m.)
 
 
 Review request for Calligra.
 
 
 Description
 ---
 
 Added retina compatible (1024x1024) icons for most apps.
 
 
 Diffs
 -
 
   braindump/data/icons/hi1024-app-braindump.png PRE-CREATION 
   braindump/data/icons/hi128-app-braindump.png PRE-CREATION 
   braindump/data/icons/hi256-app-braindump.png PRE-CREATION 
   braindump/data/icons/hi512-app-braindump.png PRE-CREATION 
   braindump/data/icons/hi64-app-braindump.png PRE-CREATION 
   braindump/src/CMakeLists.txt c009e20 
   flow/CMakeLists.txt 571e87e 
   flow/part/CMakeLists.txt 41a9ecf 
   flow/pics/CMakeLists.txt PRE-CREATION 
   flow/pics/hi1024-app-calligraflow.png PRE-CREATION 
   flow/pics/hi128-app-calligraflow.png PRE-CREATION 
   flow/pics/hi16-app-calligraflow.png PRE-CREATION 
   flow/pics/hi256-app-calligraflow.png PRE-CREATION 
   flow/pics/hi32-app-calligraflow.png PRE-CREATION 
   flow/pics/hi512-app-calligraflow.png PRE-CREATION 
   flow/pics/hi64-app-calligraflow.png PRE-CREATION 
   flow/pics/hisc-app-calligraflow.svgz PRE-CREATION 
   karbon/pics/app/hi1024-app-karbon.png PRE-CREATION 
   karbon/pics/app/hi128-app-karbon.png PRE-CREATION 
   karbon/pics/app/hi16-app-karbon.png 47f1a67 
   karbon/pics/app/hi22-app-karbon.png 5ed414d 
   karbon/pics/app/hi256-app-karbon.png PRE-CREATION 
   karbon/pics/app/hi32-app-karbon.png 9783605 
   karbon/pics/app/hi48-app-karbon.png 09fb40f 
   karbon/pics/app/hi512-app-karbon.png PRE-CREATION 
   karbon/pics/app/hi64-app-karbon.png PRE-CREATION 
   karbon/pics/app/hisc-app-karbon.svgz e757469 
   kexi/CMakeLists.txt 4afc425 
   krita/CMakeLists.txt 6641610 
   krita/pics/hi1024-app-krita.png PRE-CREATION 
   krita/pics/hi512-app-krita.png PRE-CREATION 
   plan/pics/hi1024-app-calligraplan.png PRE-CREATION 
   plan/pics/hi256-app-calligraplan.png PRE-CREATION 
   plan/pics/hi512-app-calligraplan.png PRE-CREATION 
   sheets/CMakeLists.txt 1544b58 
   sheets/data/pics/hi1024-app-calligrasheets.png PRE-CREATION 
   sheets/data/pics/hi128-app-calligrasheets.png PRE-CREATION 
   sheets/data/pics/hi16-app-calligrasheets.png PRE-CREATION 
   sheets/data/pics/hi16-app-sheets.png 2fc3d86 
   sheets/data/pics/hi22-app-calligrasheets.png PRE-CREATION 
   sheets/data/pics/hi22-app-sheets.png 9f8c807 
   sheets/data/pics/hi256-app-calligrasheets.png PRE-CREATION 
   sheets/data/pics/hi32-app-calligrasheets.png PRE-CREATION 
   sheets/data/pics/hi32-app-sheets.png 5161357 
   sheets/data/pics/hi48-app-calligrasheets.png PRE-CREATION 
   sheets/data/pics/hi48-app-sheets.png b908ae9 
   sheets/data/pics/hi512-app-calligrasheets.png PRE-CREATION 
   sheets/data/pics/hi64-app-calligrasheets.png PRE-CREATION 
   sheets/data/pics/hisc-app-calligrasheets.svgz PRE-CREATION 
   stage/part/CMakeLists.txt ab45f1d 
   stage/pics/hi1024-app-calligrastage.png PRE-CREATION 
   stage/pics/hi128-app-calligrastage.png PRE-CREATION 
   stage/pics/hi16-app-calligrastage.png PRE-CREATION 
   stage/pics/hi16-app-stage.png 76bd391 
   stage/pics/hi22-app-calligrastage.png PRE-CREATION 
   stage/pics/hi22-app-stage.png d2a21d9 
   stage/pics/hi256-app-calligrastage.png PRE-CREATION 
   stage/pics/hi32-app-calligrastage.png PRE-CREATION 
   stage/pics/hi32-app-stage.png e75e9e4 
   stage/pics/hi48-app-calligrastage.png PRE-CREATION 
   stage/pics/hi48-app-stage.png 0fff633 
   stage/pics/hi512-app-calligrastage.png PRE-CREATION 
   stage/pics/hi64-app-calligrastage.png PRE-CREATION 
   stage/pics/hisc-app-calligrastage.svgz PRE-CREATION 
   words/part/CMakeLists.txt 3dca430 
   words/pics/hi1024-app-calligrawords.png PRE-CREATION 
   words/pics/hi128-app-calligrawords.png PRE-CREATION 
   words/pics/hi16-app-calligrawords.png PRE-CREATION 
   words/pics/hi16-app-words.png 8c63f72 
   words/pics/hi22-app-calligrawords.png PRE-CREATION 
   words/pics/hi22-app-words.png ef8fbef 
   words/pics/hi256-app-calligrawords.png PRE-CREATION 
   words/pics

Review Request: Added retina compatible (1024x1024) icons for most apps.

[Yue Liu]

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

Review request for Calligra.


Summary (updated)
-

Added retina compatible (1024x1024) icons for most apps.


Description (updated)
---

Added retina compatible (1024x1024) icons for most apps.


Diffs (updated)
-

  braindump/data/icons/hi1024-app-braindump.png PRE-CREATION 
  braindump/data/icons/hi128-app-braindump.png PRE-CREATION 
  braindump/data/icons/hi256-app-braindump.png PRE-CREATION 
  braindump/data/icons/hi512-app-braindump.png PRE-CREATION 
  braindump/data/icons/hi64-app-braindump.png PRE-CREATION 
  braindump/src/CMakeLists.txt c009e20 
  flow/CMakeLists.txt 571e87e 
  flow/part/CMakeLists.txt 41a9ecf 
  flow/pics/CMakeLists.txt PRE-CREATION 
  flow/pics/hi1024-app-calligraflow.png PRE-CREATION 
  flow/pics/hi128-app-calligraflow.png PRE-CREATION 
  flow/pics/hi16-app-calligraflow.png PRE-CREATION 
  flow/pics/hi256-app-calligraflow.png PRE-CREATION 
  flow/pics/hi32-app-calligraflow.png PRE-CREATION 
  flow/pics/hi512-app-calligraflow.png PRE-CREATION 
  flow/pics/hi64-app-calligraflow.png PRE-CREATION 
  flow/pics/hisc-app-calligraflow.svgz PRE-CREATION 
  karbon/pics/app/hi1024-app-karbon.png PRE-CREATION 
  karbon/pics/app/hi128-app-karbon.png PRE-CREATION 
  karbon/pics/app/hi16-app-karbon.png 47f1a67 
  karbon/pics/app/hi22-app-karbon.png 5ed414d 
  karbon/pics/app/hi256-app-karbon.png PRE-CREATION 
  karbon/pics/app/hi32-app-karbon.png 9783605 
  karbon/pics/app/hi48-app-karbon.png 09fb40f 
  karbon/pics/app/hi512-app-karbon.png PRE-CREATION 
  karbon/pics/app/hi64-app-karbon.png PRE-CREATION 
  karbon/pics/app/hisc-app-karbon.svgz e757469 
  kexi/CMakeLists.txt 4afc425 
  krita/CMakeLists.txt 6641610 
  krita/pics/hi1024-app-krita.png PRE-CREATION 
  krita/pics/hi512-app-krita.png PRE-CREATION 
  plan/pics/hi1024-app-calligraplan.png PRE-CREATION 
  plan/pics/hi256-app-calligraplan.png PRE-CREATION 
  plan/pics/hi512-app-calligraplan.png PRE-CREATION 
  sheets/CMakeLists.txt 1544b58 
  sheets/data/pics/hi1024-app-calligrasheets.png PRE-CREATION 
  sheets/data/pics/hi128-app-calligrasheets.png PRE-CREATION 
  sheets/data/pics/hi16-app-calligrasheets.png PRE-CREATION 
  sheets/data/pics/hi16-app-sheets.png 2fc3d86 
  sheets/data/pics/hi22-app-calligrasheets.png PRE-CREATION 
  sheets/data/pics/hi22-app-sheets.png 9f8c807 
  sheets/data/pics/hi256-app-calligrasheets.png PRE-CREATION 
  sheets/data/pics/hi32-app-calligrasheets.png PRE-CREATION 
  sheets/data/pics/hi32-app-sheets.png 5161357 
  sheets/data/pics/hi48-app-calligrasheets.png PRE-CREATION 
  sheets/data/pics/hi48-app-sheets.png b908ae9 
  sheets/data/pics/hi512-app-calligrasheets.png PRE-CREATION 
  sheets/data/pics/hi64-app-calligrasheets.png PRE-CREATION 
  sheets/data/pics/hisc-app-calligrasheets.svgz PRE-CREATION 
  stage/part/CMakeLists.txt ab45f1d 
  stage/pics/hi1024-app-calligrastage.png PRE-CREATION 
  stage/pics/hi128-app-calligrastage.png PRE-CREATION 
  stage/pics/hi16-app-calligrastage.png PRE-CREATION 
  stage/pics/hi16-app-stage.png 76bd391 
  stage/pics/hi22-app-calligrastage.png PRE-CREATION 
  stage/pics/hi22-app-stage.png d2a21d9 
  stage/pics/hi256-app-calligrastage.png PRE-CREATION 
  stage/pics/hi32-app-calligrastage.png PRE-CREATION 
  stage/pics/hi32-app-stage.png e75e9e4 
  stage/pics/hi48-app-calligrastage.png PRE-CREATION 
  stage/pics/hi48-app-stage.png 0fff633 
  stage/pics/hi512-app-calligrastage.png PRE-CREATION 
  stage/pics/hi64-app-calligrastage.png PRE-CREATION 
  stage/pics/hisc-app-calligrastage.svgz PRE-CREATION 
  words/part/CMakeLists.txt 3dca430 
  words/pics/hi1024-app-calligrawords.png PRE-CREATION 
  words/pics/hi128-app-calligrawords.png PRE-CREATION 
  words/pics/hi16-app-calligrawords.png PRE-CREATION 
  words/pics/hi16-app-words.png 8c63f72 
  words/pics/hi22-app-calligrawords.png PRE-CREATION 
  words/pics/hi22-app-words.png ef8fbef 
  words/pics/hi256-app-calligrawords.png PRE-CREATION 
  words/pics/hi32-app-calligrawords.png PRE-CREATION 
  words/pics/hi32-app-words.png 60dc06d 
  words/pics/hi48-app-calligrawords.png PRE-CREATION 
  words/pics/hi48-app-words.png 5a401ec 
  words/pics/hi512-app-calligrawords.png PRE-CREATION 
  words/pics/hi64-app-calligrawords.png PRE-CREATION 
  words/pics/hi64-app-words.png f6d448c 
  words/pics/hisc-app-calligrawords.svgz PRE-CREATION 
  words/pics/hisc-app-words.svgz 3290137 

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


Testing (updated)
---

works on mac


Thanks,

Yue Liu

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

Re: Review Request: Implement triple button widget

[Yue Liu]

 On Dec. 3, 2012, 9:49 a.m., C. Boemann wrote:
  I don't think we want this button to be used here. We should follow the 
  lead of the text tool, where the buttons have become frameless. Also the 
  design work done at Akademy determined that join and cap are rarely used 
  and should be demoted to option menus to save space.
  
  In any case the screenshot was something I asked for privately with Morice, 
  so we could see it in action. Btw, I am working on implementing the design 
  we did at Akademy.
  
  Nevertheless, the triple button on it's own can be useful in dialogs, and 
  so I think it will be a usefull addition to Calligra as a new class 
  regardless if we have a usecase for it right now or not.
  
  But like Thorsten I would like to see the diff. Though I had seen an 
  earlier diff and had comments that I know have been worked on it's always 
  nice to see the final diff.

This button can be used to simulate segmented control in OS X


- Yue


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


On Dec. 3, 2012, 10:55 a.m., Jean-Nicolas Artaud wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/107530/
 ---
 
 (Updated Dec. 3, 2012, 10:55 a.m.)
 
 
 Review request for Calligra and C. Boemann.
 
 
 Description
 ---
 
 Implement triple button widget in the calligra widget libs.
 This also can be used for double buttons (like in gwenview for instance).
 
 
 Diffs
 -
 
   libs/widgets/CMakeLists.txt 10e4e09 
   libs/widgets/KoStrokeConfigWidget.cpp d0a8eb9 
   libs/widgets/KoTripleButton.h PRE-CREATION 
   libs/widgets/KoTripleButton.cpp PRE-CREATION 
 
 Diff: http://git.reviewboard.kde.org/r/107530/diff/
 
 
 Testing
 ---
 
 Use the triple button on the property docker.
 
 
 Screenshots
 ---
 
 Strocke properties docker with the triple buttons
   http://git.reviewboard.kde.org/r/107530/s/865/
 
 
 Thanks,
 
 Jean-Nicolas Artaud
 


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

Re: Review Request: Removed use of kde_deprecated api

[Yue Liu]

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

(Updated Nov. 30, 2012, 12:50 a.m.)


Review request for Calligra.


Changes
---

combined more fixes in removing kde_deprecated thing.


Summary (updated)
-

Removed use of kde_deprecated api


Description (updated)
---

Removed various use of kde_deprecated api so calligra can compile with 
kdelibs-mobile


Diffs (updated)
-

  braindump/src/SectionsIO.cpp 73343d4 
  braindump/src/View.cpp 3258d3e 
  kexi/widget/tableview/kexiblobtableedit.cpp ac33513 
  krita/plugins/formats/exr/exr_converter.cc a58a7e9 
  tools/calligra/main.cpp e2d0716 

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


Testing (updated)
---

Can compile, not well tested.


Thanks,

Yue Liu

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

Review Request: Fix use of deprecated kio api in braindump

[Yue Liu]

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

Review request for Calligra.


Description
---

Removed use of deprecated api KIO::NetAccess::move


Diffs
-

  braindump/src/SectionsIO.cpp 73343d4 

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


Testing
---

Can compile, not sure if this is the right way to use new api KIO::move


Thanks,

Yue Liu

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

Re: Architecture Refactor Suggestion: App-irrelevent Format Filters

[Yue Liu]

2012/10/23 Inge Wallin i...@lysator.liu.se:
 On Sunday, October 21, 2012 18:11:18 Yue Liu wrote:
 2012/10/21 Boudewijn Rempt b...@valdyas.org:
  On Sunday 21 October 2012 Oct, Yue Liu wrote:
  Hi,
 
  Currently filters are loaded based on application's native mime-type.
  And now we have multiple applications with same native format, such as
  Karbon and Flow, Words and Authors. Applications with same native
  format should have same set of format filters, but format filter codes
  are sorted under application categories.
 
  So I suggest change it from current structure
 
  filters/xxx_app/[im,ex]port/xxx_filter
 
  It's even messier in some places, where the odf2html filter is embedded
  in the epub filter.
 
  to
 
  filters/xxx2xxx
 
  I wouldn't mind that change, but then, for Krita, we moved all the
  filters to the Krita folter anyway.
 
  And tell distributions package filters as one component, not with
  apps, to avoid conflicts between same-format apps. At least Arch and
  Chakra is already doing it this way.
 
  Fedora also did/does that already, which meant lots of bug reports since
  people only installed the app, not the filter component and then
  complained that they couldn't even open a simple jpeg in Krita!
 
  There's a complication here with the Tables filters: some of them link
  directly to Tables and actually don't go though an ODS intermediate.
  Those probably should be moved to the tables folder itself.

 We can keep the dependency on App and involve new mime-types for those
 filters. Just like Friedrich suggested before:
 http://mail.kde.org/pipermail/calligra-devel/2012-May/005041.html

 For example, if karbon filter depends on KarbonPart, we can make a
 mime-type calligra/karbon.document and use it in the filter, so Flow
 won't load this filter since karon.document is not supported by Flow.

 And we can place the codes of this kind of app-dependent filters under
 app/filters/xxx2xxx, and place those general filters under
 filters/xxx2xxx, when packaging, app-dependent filters are packaged
 with apps, general filters are packaged as a single package and every
 app depends on it.

  Note: this is a problem for some Karbon filters, since they used
  KarbonPart to access shapes for shape painting. We can modify
  KoDocument::paintContent(painter, rect) to do that instead.
 
  Ah, so Karbon has the same problem already, too.
 
 
  --
  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

 Yue, it seems that your filter thread got a bit hijacked -- or at least
 expanded.  Sorry for that.
Expansion made discussion more valuable:)


 Is there anything we can do about this filter problem for Flow in the short
 term?  I guess that using the Karbon core is not bad in itself. Or should the
 Karbon core be extracted into a kind of vector document core in libs/ ? That
 way the Flow filter will not be dependent on another application but instead
 just of a library.
I prefer the latter idea. Already got some suggestion from Cyrille in
another thread.

 ___
 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: Architecture Refactor Suggestion: App-irrelevent Format Filters

[Yue Liu]

2012/10/21 Boudewijn Rempt b...@valdyas.org:
 On Sunday 21 October 2012 Oct, Yue Liu wrote:
 Hi,

 Currently filters are loaded based on application's native mime-type.
 And now we have multiple applications with same native format, such as
 Karbon and Flow, Words and Authors. Applications with same native
 format should have same set of format filters, but format filter codes
 are sorted under application categories.

 So I suggest change it from current structure

 filters/xxx_app/[im,ex]port/xxx_filter

 It's even messier in some places, where the odf2html filter is embedded in 
 the epub filter.


 to

 filters/xxx2xxx

 I wouldn't mind that change, but then, for Krita, we moved all the filters to 
 the Krita folter anyway.


 And tell distributions package filters as one component, not with
 apps, to avoid conflicts between same-format apps. At least Arch and
 Chakra is already doing it this way.

 Fedora also did/does that already, which meant lots of bug reports since 
 people only installed the app, not the filter component and then complained 
 that they couldn't even open a simple jpeg in Krita!

 There's a complication here with the Tables filters: some of them link 
 directly to Tables and actually don't go though an ODS intermediate. Those 
 probably should be moved to the tables folder itself.

We can keep the dependency on App and involve new mime-types for those
filters. Just like Friedrich suggested before:
http://mail.kde.org/pipermail/calligra-devel/2012-May/005041.html

For example, if karbon filter depends on KarbonPart, we can make a
mime-type calligra/karbon.document and use it in the filter, so Flow
won't load this filter since karon.document is not supported by Flow.

And we can place the codes of this kind of app-dependent filters under
app/filters/xxx2xxx, and place those general filters under
filters/xxx2xxx, when packaging, app-dependent filters are packaged
with apps, general filters are packaged as a single package and every
app depends on it.



 Note: this is a problem for some Karbon filters, since they used
 KarbonPart to access shapes for shape painting. We can modify
 KoDocument::paintContent(painter, rect) to do that instead.


 Ah, so Karbon has the same problem already, too.


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

Share karbon format filters between karbon and flow

[Yue Liu]

Hi,

I'm trying to find a way to make Karbon format filters work also in Flow.
After KoPart/KoDocument split, Karbon filters ImageExport, SvgExport,
SvgImport, and WmfExport still require Karbon object KarbonDocument
and KarbonKoDocument (derived from KoDocument). So those cannot be
used by Flow.

First I think KarbonDocument and KarbonKoDocument can be merged to
single KarbonDocument.

Then we can create an abstract class KoGraphicsDocument, define the
interface with methods used in filters, then derive FlowDocument from
KoPADocument and KoGraphicsDocument, make KarbonDocument also inherit
KoGraphicsDocument.

Now the problem is filters require access of shapes(layers) of a page,
but I'm not sure how to access shapes(layers) from KoPAPage. What is
the recommended way to do that?

Best regards,
Yue Liu
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Architecture Refactor Suggestion: App-irrelevent Format Filters

[Yue Liu]

Hi,

Currently filters are loaded based on application's native mime-type.
And now we have multiple applications with same native format, such as
Karbon and Flow, Words and Authors. Applications with same native
format should have same set of format filters, but format filter codes
are sorted under application categories.

So I suggest change it from current structure

filters/xxx_app/[im,ex]port/xxx_filter

to

filters/xxx2xxx

And tell distributions package filters as one component, not with
apps, to avoid conflicts between same-format apps. At least Arch and
Chakra is already doing it this way.

Note: this is a problem for some Karbon filters, since they used
KarbonPart to access shapes for shape painting. We can modify
KoDocument::paintContent(painter, rect) to do that instead.


Best Regards,
Yue Liu
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Review Request: Disable unneeded plugins

[Yue Liu]

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

Review request for Calligra.


Description
---

Disabled krita plugins in flow, karbon, braindump so they don't crash on start 
up when opengtl is compiled in a wrong way.


This addresses bugs 295774, 302556, 306356, and 306422.
http://bugs.kde.org/show_bug.cgi?id=295774
http://bugs.kde.org/show_bug.cgi?id=302556
http://bugs.kde.org/show_bug.cgi?id=306356
http://bugs.kde.org/show_bug.cgi?id=306422


Diffs
-

  braindump/data/CMakeLists.txt 357a4c104ed9f84399b1f51bef7a8ebe428e223b 
  flow/part/flowrc 3f21155df61b0538fe99055dc0fa72fc1e6a8d66 
  karbon/data/karbonrc 33ac9b333895d1cdc59e2ed29194ae6d0fe1a97e 

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


Testing
---

Tested on Flow, Karbon, Braindump.


Thanks,

Yue Liu

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

Re: Review Request: Disable unneeded plugins

[Yue Liu]

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

(Updated Oct. 17, 2012, 7:37 p.m.)


Review request for Calligra.


Description
---

Disabled krita plugins in flow, karbon, braindump so they don't crash on start 
up when opengtl is compiled in a wrong way.


This addresses bugs 295774, 302556, 306356, and 306422.
http://bugs.kde.org/show_bug.cgi?id=295774
http://bugs.kde.org/show_bug.cgi?id=302556
http://bugs.kde.org/show_bug.cgi?id=306356
http://bugs.kde.org/show_bug.cgi?id=306422


Diffs
-

  braindump/data/CMakeLists.txt 357a4c104ed9f84399b1f51bef7a8ebe428e223b 
  flow/part/flowrc 3f21155df61b0538fe99055dc0fa72fc1e6a8d66 
  karbon/data/karbonrc 33ac9b333895d1cdc59e2ed29194ae6d0fe1a97e 

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


Testing
---

Tested on Flow, Karbon, Braindump.


Thanks,

Yue Liu

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

Re: Review Request: Change Stage and Flow to have infinite type canvas

[Yue Liu]

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


The patch caused a problem when you drag a shape to the canvas. When you are 
dragging and cursor just past the edge of the canvas, canvas will expand, if 
you drag slowly, canvas will continue expanding and you lost your position in 
the canvas. I think it would be better letting canvas expand after drag  drop 
is done. It will make canvas less jumping. It won't hurt the feature of canvas 
expanding since users don't need to expand too much.

- Yue Liu


On May 17, 2012, 7:14 p.m., C. Boemann wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/104928/
 ---
 
 (Updated May 17, 2012, 7:14 p.m.)
 
 
 Review request for Calligra.
 
 
 Description
 ---
 
 KoPageApp applications Stage and Flow used to have extra space reserved 
 around the page/slide so objects could be put there. However that made it 
 really hard for the user to work with.
 
 This patch changes that so there si no space around the page/slide. But.. 
 instead you can drag objects outside the page/slide without any limit at all
 
 
 Diffs
 -
 
   libs/flake/KoShapeManager.h 520381d 
   libs/flake/KoShapeManager.cpp 88c522f 
   libs/kopageapp/KoPACanvas.cpp 4a4748c 
   libs/kopageapp/KoPAView.h 01fbdf1 
   libs/kopageapp/KoPAView.cpp 4d13dfa 
   libs/kopageapp/KoPAViewModeNormal.cpp d5aa5f6 
   libs/widgets/KoZoomController.h 4f4c6a2 
   libs/widgets/KoZoomController.cpp e10c5b4 
   stage/part/KPrViewModeNotes.h b707770 
   stage/part/KPrViewModeNotes.cpp c951ade 
 
 Diff: http://git.reviewboard.kde.org/r/104928/diff/
 
 
 Testing
 ---
 
 I've tested zooming in and out in Stage normal, notes, and sorter viewmodes, 
 and in Flow.
 
 I've tested that running presentations still work, however I've not tested 
 presenterview.
 
 I've tested moving shapes outside the page/slide in both Stage and Flow.
 
 
 Thanks,
 
 C. Boemann
 


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

How to open external document to a second canvas in a docker?

[Yue Liu]

Hi,

Currently for flow stencil box each shape in a stencil is an ODG file.
It's not convenient for designers to create stencils, and it's
difficult to display object not in a rectanglar shape. So I'm thinking
of using one ODG file to represent the whole stencil, and display it
in a canvas so user will see the whole stencil as exactly what the ODG
document looks like.

This way has following advantages:

 - Designers can work in a single ODG document.
 - Object with special shape, such as long curve lines, can be shown
in the docker clearer.
 - Designers can organize object positions in creative ways to make
stencil better understood by users, for example, if object is arranged
like a real use case, users will understand where to use what stencil
shape better.

But to implement this, I have to show a canvas and external document
in a docker, I'm not sure how to do it right. My idea is:

 - class StencilDocument inherited from KoOdfDocument and
KoShapeBasedDocumentBase
 - class StencilCanvas inherited from KoCanvasBase
 - put StencilCanvas in the docker, load StencilDocument to the canvas
 - user drag shapes from the docker and drop to the application main canvas

Is this practical? If not, what would be a practical way of doing
this? If it's totally wrong to do this, what do you think is a better
solution for stencil box docker?

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

Re: Review Request: fix iconname of Flow runtime to an existing icon

[Yue Liu]

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

Ship it!


Ship It!

- Yue Liu


On July 22, 2012, 1:09 a.m., Friedrich W. H. Kossebau wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/105654/
 ---
 
 (Updated July 22, 2012, 1:09 a.m.)
 
 
 Review request for Calligra and Yue Liu.
 
 
 Description
 ---
 
 Currently there is no app icon installed at all for Calligra Flow. The 
 desktop files set the iconname to kivio, which is existing in the Oxygen 
 icon set. But the AboutData of Flow sets the iconname indirectly to flow, 
 for which no icon exists at all.
 
 Attached patch fixes this by setting the iconname for AboutData to kivio as 
 well. (As a temporary solution, until there is an Flow app icon).
 
 Okay to backport to 2.5?
 
 
 Diffs
 -
 
   flow/part/FlowAboutData.h 4e301e9 
 
 Diff: http://git.reviewboard.kde.org/r/105654/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Friedrich W. H. Kossebau
 


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

Re: Review Request: New integration design to connection tool

[Yue Liu]

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

(Updated June 15, 2012, 12:22 p.m.)


Review request for Calligra.


Description
---

The original design to connection tool used several edit mode to manipulate 
connections and connection points, it works but user may not find out how to 
use it easily, so I added an option widget providing tool buttons to the usual 
actions user might want to use when manipulating connections, and disabled the 
double click to change edit mode feature in case user may accidentally enter 
unintended edit modes.

Other improvements are,
double click blank region to back to default tool, so now connection tool is 
consistent with path tool in this behavior,
added text box to new connectors created by default.


Diffs (updated)
-

  libs/flake/KoConnectionShape.h 37984022f0154696d47385c5119f559978f9d9f2 
  libs/flake/KoConnectionShapeConfigWidget.h 
f3947d412533f516bd04f3beb1dac0d224107d74 
  libs/flake/KoConnectionShapeConfigWidget.cpp 
c4e46cc09e4536401f5f66dcfea09ee25821a6b5 
  pics/oxygen/ox16-action-curve-connector.png PRE-CREATION 
  pics/oxygen/ox16-action-lines-connector.png PRE-CREATION 
  pics/oxygen/ox16-action-standard-connector.png PRE-CREATION 
  pics/oxygen/ox16-action-straight-connector.png PRE-CREATION 
  plugins/defaultTools/connectionTool/ConnectionPointWidget.cpp 
42f88225364dbc7d8dce726521bc9a15b8f889ef 
  plugins/defaultTools/connectionTool/ConnectionPointWidget.ui 
824814dc072d012257ef74e485f41c9a9a2bfd3f 
  plugins/defaultTools/connectionTool/ConnectionTool.h 
172eb7fd919b22ee60d2c3a594f09bebed43eea8 
  plugins/defaultTools/connectionTool/ConnectionTool.cpp 
d95a34f02850719b13c7acbf5f57381fd53c6908 

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


Testing
---

Tested in every application. connector path update not work in Words, but I 
think that's irrelevant with my patch.


Thanks,

Yue Liu

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

Review Request: New integration design to connection tool

[Yue Liu]

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

Review request for Calligra.


Description
---

The original design to connection tool used several edit mode to manipulate 
connections and connection points, it works but user may not find out how to 
use it easily, so I added an option widget providing tool buttons to the usual 
actions user might want to use when manipulating connections, and disabled the 
double click to change edit mode feature in case user may accidentally enter 
unintended edit modes.

Other improvements are,
double click blank region to back to default tool, so now connection tool is 
consistent with path tool in this behavior,
added text box to new connectors created by default.


Diffs
-

  libs/flake/KoConnectionShape.h 37984022f0154696d47385c5119f559978f9d9f2 
  pics/oxygen/ox16-action-curve-connector.png PRE-CREATION 
  pics/oxygen/ox16-action-lines-connector.png PRE-CREATION 
  pics/oxygen/ox16-action-standard-connector.png PRE-CREATION 
  pics/oxygen/ox16-action-straight-connector.png PRE-CREATION 
  plugins/defaultTools/CMakeLists.txt 1f160106067dddba0d1ec0390669d31f66caf270 
  plugins/defaultTools/connectionTool/ConnectionEditModeWidget.h PRE-CREATION 
  plugins/defaultTools/connectionTool/ConnectionEditModeWidget.cpp PRE-CREATION 
  plugins/defaultTools/connectionTool/ConnectionTool.h 
172eb7fd919b22ee60d2c3a594f09bebed43eea8 
  plugins/defaultTools/connectionTool/ConnectionTool.cpp 
d95a34f02850719b13c7acbf5f57381fd53c6908 

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


Testing
---

Tested in every application. connector path update not work in Words, but I 
think that's irrelevant with my patch.


Thanks,

Yue Liu

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

Re: Review Request: New integration design to connection tool

[Yue Liu]

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

(Updated June 13, 2012, 10:32 a.m.)


Review request for Calligra.


Description
---

The original design to connection tool used several edit mode to manipulate 
connections and connection points, it works but user may not find out how to 
use it easily, so I added an option widget providing tool buttons to the usual 
actions user might want to use when manipulating connections, and disabled the 
double click to change edit mode feature in case user may accidentally enter 
unintended edit modes.

Other improvements are,
double click blank region to back to default tool, so now connection tool is 
consistent with path tool in this behavior,
added text box to new connectors created by default.


Diffs (updated)
-

  libs/flake/KoConnectionShape.h 37984022f0154696d47385c5119f559978f9d9f2 
  pics/oxygen/ox16-action-curve-connector.png PRE-CREATION 
  pics/oxygen/ox16-action-lines-connector.png PRE-CREATION 
  pics/oxygen/ox16-action-standard-connector.png PRE-CREATION 
  pics/oxygen/ox16-action-straight-connector.png PRE-CREATION 
  plugins/defaultTools/CMakeLists.txt 1f160106067dddba0d1ec0390669d31f66caf270 
  plugins/defaultTools/connectionTool/ConnectionEditModeWidget.h PRE-CREATION 
  plugins/defaultTools/connectionTool/ConnectionEditModeWidget.cpp PRE-CREATION 
  plugins/defaultTools/connectionTool/ConnectionTool.h 
172eb7fd919b22ee60d2c3a594f09bebed43eea8 
  plugins/defaultTools/connectionTool/ConnectionTool.cpp 
d95a34f02850719b13c7acbf5f57381fd53c6908 

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


Testing
---

Tested in every application. connector path update not work in Words, but I 
think that's irrelevant with my patch.


Thanks,

Yue Liu

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

Re: Review Request: New integration design to connection tool

[Yue Liu]

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

(Updated June 13, 2012, 2:08 p.m.)


Review request for Calligra.


Description
---

The original design to connection tool used several edit mode to manipulate 
connections and connection points, it works but user may not find out how to 
use it easily, so I added an option widget providing tool buttons to the usual 
actions user might want to use when manipulating connections, and disabled the 
double click to change edit mode feature in case user may accidentally enter 
unintended edit modes.

Other improvements are,
double click blank region to back to default tool, so now connection tool is 
consistent with path tool in this behavior,
added text box to new connectors created by default.


Diffs (updated)
-

  libs/flake/KoConnectionShape.h 37984022f0154696d47385c5119f559978f9d9f2 
  pics/oxygen/ox16-action-curve-connector.png PRE-CREATION 
  pics/oxygen/ox16-action-lines-connector.png PRE-CREATION 
  pics/oxygen/ox16-action-standard-connector.png PRE-CREATION 
  pics/oxygen/ox16-action-straight-connector.png PRE-CREATION 
  plugins/defaultTools/CMakeLists.txt 1f160106067dddba0d1ec0390669d31f66caf270 
  plugins/defaultTools/connectionTool/ConnectionEditModeWidget.h PRE-CREATION 
  plugins/defaultTools/connectionTool/ConnectionEditModeWidget.cpp PRE-CREATION 
  plugins/defaultTools/connectionTool/ConnectionTool.h 
172eb7fd919b22ee60d2c3a594f09bebed43eea8 
  plugins/defaultTools/connectionTool/ConnectionTool.cpp 
d95a34f02850719b13c7acbf5f57381fd53c6908 

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


Testing
---

Tested in every application. connector path update not work in Words, but I 
think that's irrelevant with my patch.


Thanks,

Yue Liu

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

Re: Review Request: New integration design to connection tool

[Yue Liu]

 On June 13, 2012, 11:35 a.m., Thorsten Zachmann wrote:
  I have some strange behaviours with your patch:
  o When I load the file http://www.zagge.de/files/6_Slides.odp and go to 
  page e.g. 5 and activate the connection tool not all connections poits of 
  every shape is shown. Therefore it is not possible to start a connection 
  from these point. I can however end the connection at those points. 
  o When clicking onto a connection I have the possibility to move the points 
  where this connection is connected. However after that there seems to be no 
  way back to create a new connection.
  o When creating a new connection and after I started dragging from the 
  first connection point in the odp given above I get very stange jumping of 
  the connection to someplace where my cursor is not during dragging.

p1 fixed in r4
p2 partly fixed, you have to click the blank region or choose the action from 
the docker, but since sometimes the bounding box to connection covers too much 
space, click the blank region method is not very useful.
p3 needs investigation


- Yue


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


On June 13, 2012, 2:08 p.m., Yue Liu wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/105237/
 ---
 
 (Updated June 13, 2012, 2:08 p.m.)
 
 
 Review request for Calligra.
 
 
 Description
 ---
 
 The original design to connection tool used several edit mode to manipulate 
 connections and connection points, it works but user may not find out how to 
 use it easily, so I added an option widget providing tool buttons to the 
 usual actions user might want to use when manipulating connections, and 
 disabled the double click to change edit mode feature in case user may 
 accidentally enter unintended edit modes.
 
 Other improvements are,
 double click blank region to back to default tool, so now connection tool is 
 consistent with path tool in this behavior,
 added text box to new connectors created by default.
 
 
 Diffs
 -
 
   libs/flake/KoConnectionShape.h 37984022f0154696d47385c5119f559978f9d9f2 
   pics/oxygen/ox16-action-curve-connector.png PRE-CREATION 
   pics/oxygen/ox16-action-lines-connector.png PRE-CREATION 
   pics/oxygen/ox16-action-standard-connector.png PRE-CREATION 
   pics/oxygen/ox16-action-straight-connector.png PRE-CREATION 
   plugins/defaultTools/CMakeLists.txt 
 1f160106067dddba0d1ec0390669d31f66caf270 
   plugins/defaultTools/connectionTool/ConnectionEditModeWidget.h PRE-CREATION 
   plugins/defaultTools/connectionTool/ConnectionEditModeWidget.cpp 
 PRE-CREATION 
   plugins/defaultTools/connectionTool/ConnectionTool.h 
 172eb7fd919b22ee60d2c3a594f09bebed43eea8 
   plugins/defaultTools/connectionTool/ConnectionTool.cpp 
 d95a34f02850719b13c7acbf5f57381fd53c6908 
 
 Diff: http://git.reviewboard.kde.org/r/105237/diff/
 
 
 Testing
 ---
 
 Tested in every application. connector path update not work in Words, but I 
 think that's irrelevant with my patch.
 
 
 Thanks,
 
 Yue Liu
 


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

Re: Review Request: Change Stage and Flow to have infinite type canvas

[Yue Liu]

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


would be better if grid is painted only inside page.

- Yue Liu


On May 14, 2012, 11:42 p.m., C. Boemann wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 http://git.reviewboard.kde.org/r/104928/
 ---
 
 (Updated May 14, 2012, 11:42 p.m.)
 
 
 Review request for Calligra.
 
 
 Description
 ---
 
 KoPageApp applications Stage and Flow used to have extra space reserved 
 around the page/slide so objects could be put there. However that made it 
 really hard for the user to work with.
 
 This patch changes that so there si no space around the page/slide. But.. 
 instead you can drag objects outside the page/slide without any limit at all
 
 
 Diffs
 -
 
   libs/kopageapp/KoPACanvas.cpp 4a4748c 
   libs/kopageapp/KoPAView.h 01fbdf1 
   libs/kopageapp/KoPAView.cpp 4d13dfa 
   libs/kopageapp/KoPAViewModeNormal.cpp d5aa5f6 
   libs/widgets/KoZoomController.h 4f4c6a2 
   libs/widgets/KoZoomController.cpp e10c5b4 
   stage/part/KPrViewModeNotes.h b707770 
   stage/part/KPrViewModeNotes.cpp c951ade 
 
 Diff: http://git.reviewboard.kde.org/r/104928/diff/
 
 
 Testing
 ---
 
 I've tested zooming in and out in Stage normal, notes, and sorter viewmodes, 
 and in Flow.
 
 I've tested that running presentations still work, however I've not tested 
 presenterview.
 
 I've tested moving shapes outside the page/slide in both Stage and Flow.
 
 
 Thanks,
 
 C. Boemann
 


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

Re: Words filter compiler error with GCC 4.7

[Yue Liu]

Hancom Office now supports odf. http://www.hancom.com/en/product/product2010.jsp

2012/3/26 Matus Uzak matus.u...@ixonos.com:
 Hi,

 I recommend to use filters/libmso/pole.cpp in the starwriter and the
 hancomword filter.  I can take care of the starwriter filter.



 On Sat, Mar 24, 2012 at 3:30 AM, Yue Liu yue@mail.com wrote:

 looks like it's okay to rename r with other name.

 2012/3/24 Christoph Feck christ...@maxiom.de:
  Hi,
 
  The calligra master builds fails with GCC 4.7 due to an error in the
  hancomwords import filter.
 
  The loop in filters/words/hancomword/pole.cpp:869 reads:
 
         for (unsigned r = 0; r  header-num_mbat; r++) {
             unsigned long r = loadBigBlock(mblock, buffer2, bbat-
 blockSize);
             if (r != bbat-blockSize) {
                 delete[] buffer2;
                 return;
             }
             for (unsigned s = 0; s  bbat-blockSize - 4; s += 4) {
                 if (k = header-num_bat) break;
                 else  blocks[k++] = readU32(buffer2 + s);
             }
             mblock = readU32(buffer2 + bbat-blockSize - 4);
         }
 
  The error is that the variable r is used as the loop counter, as
  well recomputed inside the loop. This clearly is a bug, but I do not
  know the code to fix it.
 
  Christoph Feck (kdepepo)
  KDE Quality Team
  ___
  calligra-devel mailing list
  calligra-devel@kde.org
  https://mail.kde.org/mailman/listinfo/calligra-devel



 --
 Best Regards,
 Yue Liu
 ___
 calligra-devel mailing list
 calligra-devel@kde.org
 https://mail.kde.org/mailman/listinfo/calligra-devel




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

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




-- 
Best Regards,
Yue Liu
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Words filter compiler error with GCC 4.7

[Yue Liu]

looks like it's okay to rename r with other name.

2012/3/24 Christoph Feck christ...@maxiom.de:
 Hi,

 The calligra master builds fails with GCC 4.7 due to an error in the
 hancomwords import filter.

 The loop in filters/words/hancomword/pole.cpp:869 reads:

        for (unsigned r = 0; r  header-num_mbat; r++) {
            unsigned long r = loadBigBlock(mblock, buffer2, bbat-
blockSize);
            if (r != bbat-blockSize) {
                delete[] buffer2;
                return;
            }
            for (unsigned s = 0; s  bbat-blockSize - 4; s += 4) {
                if (k = header-num_bat) break;
                else  blocks[k++] = readU32(buffer2 + s);
            }
            mblock = readU32(buffer2 + bbat-blockSize - 4);
        }

 The error is that the variable r is used as the loop counter, as
 well recomputed inside the loop. This clearly is a bug, but I do not
 know the code to fix it.

 Christoph Feck (kdepepo)
 KDE Quality Team
 ___
 calligra-devel mailing list
 calligra-devel@kde.org
 https://mail.kde.org/mailman/listinfo/calligra-devel



-- 
Best Regards,
Yue Liu
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Review Request: Added Microsoft Visio and Works import filters, updated WordPerfect Document/Graphics import filters

[Yue Liu]

/StdOutHandler.hxx PRE-CREATION 
  filters/writerperfect/StdOutHandler.cxx PRE-CREATION 
  filters/writerperfect/Style.hxx PRE-CREATION 
  filters/writerperfect/TableStyle.hxx PRE-CREATION 
  filters/writerperfect/TableStyle.cxx PRE-CREATION 
  filters/writerperfect/TextRunStyle.hxx PRE-CREATION 
  filters/writerperfect/TextRunStyle.cxx PRE-CREATION 
  filters/writerperfect/WriterProperties.hxx PRE-CREATION 
  filters/writerperfect/writerperfect_export.h PRE-CREATION 
  flow/part/flow.desktop 53d93fa 
  flow/part/flowpart.desktop f1e3d4c 

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


Testing
---

vsd to odg conversion runs well through calligraconverter, but the visio format 
cannot be seen from import dialog in Flow, I'm not sure where need to add those 
strings...
new wpd/wpg/wps filters are not tested for I don't have any test document in 
those formats but the workflows are similar to vsd filter so they should work.


Thanks,

Yue Liu

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

Re: Review Request: Add config option to make grid shown behind the shapes in kopageapp

[Yue Liu]

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

(Updated Dec. 24, 2011, 12:19 p.m.)


Review request for Calligra.


Changes
---

now use *rc files to set the grid painting strategy. Added a bool type variable 
in KoPAViewBase.


Description
---

Add config option to make grid shown behind the shapes in kopageapp, one new 
option added in Settings - Configure - Grid.


Diffs (updated)
-

  flow/part/FlowView.cpp deaabd0 
  flow/part/flowrc 1d69f73 
  libs/kopageapp/KoPACanvasBase.h b9e8e8c 
  libs/kopageapp/KoPACanvasBase.cpp 3ae8f64 
  libs/kopageapp/KoPAViewModeNormal.cpp 7402f3f 

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


Testing
---

works well, no problem found.


Thanks,

Yue Liu

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

Re: UI suggestion: make grid behind shapes

[Yue Liu]

2011/12/20 Boudewijn Rempt b...@valdyas.org:
 On Tuesday 20 December 2011 Dec, Yue Liu wrote:
 Hello,

 I investigated a set of commercial diagramming applications and found
 they put grid behind shapes, while currently we're doing the opposite.
 The advantage of making grid behind shapes is the user will have a
 better impression to the shapes they are manipulating, while this may
 cause trouble to creative apps like Karbon and Krita where grid on top
 of shape is needed for tweaking overlap of two shapes, so I suggest
 paint grid before shapes in kopageapp and words while keep the current
 strategy in Karbon and Krita.

 What do you think about this idea?

 Well -- the current grid already shows on top of the shapes, doesn't it? At 
 least in Karbon.
Yes, my main point is the grid painting should be different in stage
and flow compared to what is already in karbon and krita.

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



-- 
Best Regards,
Yue Liu
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Review Request: Add config option to make grid shown behind the shapes in kopageapp

[Yue Liu]

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

Review request for Calligra.


Description
---

Add config option to make grid shown behind the shapes in kopageapp, one new 
option added in Settings - Configure - Grid.


Diffs
-

  libs/kopageapp/KoPAViewModeNormal.cpp 7402f3f 
  libs/main/KoGridData.h 296c812 
  libs/main/KoGridData.cpp f37d36f 
  libs/main/config/KoConfigGridPage.cpp a3e1d6f 

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


Testing
---

works well, no problem found.


Thanks,

Yue Liu

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

Review Request: Explicitly accept mouse event on canvas level to prevent move window around

[Yue Liu]

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

Review request for Calligra.


Description
---

In oxygen and bespin widget style, drag any part of the window will move window 
around, but our user may accidently do that on canvas by mistake or when a 
shape is locked, so we should explicitly accept mouse press event to prevent a 
drag event sent to parent widget.


Diffs
-

  braindump/src/Canvas.cpp 92b34de 
  karbon/ui/widgets/KarbonCanvas.cpp 172662c 
  krita/ui/canvas/kis_canvas_widget_base.cpp 04395ff 
  libs/kopageapp/KoPACanvas.cpp 7b8fb83 
  words/part/KWCanvas.cpp 7561b4f 

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


Testing
---

No problem found but dragging on the gray region in Words, don't know how to 
fix that.


Thanks,

Yue Liu

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

Re: Calligra Logo and Stencils

[Yue Liu]

Hello Gajendra,

Calligra Flow currently used stencils from Dia so their look and feel
are not that perfect. It would be great if you'd like to redesign some
set of stencils in Flow:) Currently we only support odg format but we
also plan to support svg in near future, so feel free to use your
favorite tool. I'm not a designer so I cannot give much guidance in
art, but we don't have any design consistency guidance yet, so feel
free to create your stuff.


Best Regards,
Yue Liu
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: Suggestion: depend on writerperfect directly for wordperfect/visio/works import filter

[Yue Liu]

I've give up depend on writerperfect and is working on visio filter with
some codes from writerperfect, for the performance.

On Wed, Nov 23, 2011 at 4:47 AM, Cyrille Berger Skott
cber...@cberger.netwrote:

 On Tuesday 22 November 2011, Sven Langkamp wrote:
   hm... What is writerperfect actually? If it isn't too big  saves us a
   lot of code, especially code that's copied from it, it might be worth
   it.
 
  writerperfect provides executables that do what our filters are doing.
  The difference is minimal, in one case you call the library directly
  and in the other case you call a seperate executable. As you can see
  in the wpg filter, the amount of code isn't big.
 
  Currently there are three converters, each with a size of 50-100kb on
  ubuntu.
 I actually saw that the source code of writerperfect also offer library
 call
 (didn't check if the headers were installed, or not).

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




-- 
Best Regards,
Yue Liu
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Suggestion: depend on writerperfect directly for wordperfect/visio/works import filter

[Yue Liu]

Hello,

Recently when working on visio import filter I found I'm basically
copy codes from writerperfect. Then I investigated wpd import filter
in words and found it used codes from a old version of writerperfect,
wpg import filter in karbon used a convenience method from libwpg to
convert to svg but some apps don't support svg well. If I implement
vsd2odg and wpg2odg I have to copy codes again from writerperfect.

So I think why not depend on writerperfect directly? It will save a
lot of maintenance effort, and if we want to do any improvement we can
go upstream directly. Writerperfect is maintained by the authors of
libwpd,libwps,libvisio,libwpg, and many distros already have
package(libvisio has no stable release yet so we need to depend on git
version currectly, i've made PKGBUILDs for Arch).


Best Regards,
Yue Liu
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

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

[Yue Liu]

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

Review request for Calligra and C. Boemann.


Description
---

Partly fixed rect position returned to input method through 
TextTool::InputMethodQuery. But still some problems.


Diffs
-

  libs/flake/KoCanvasController.h 97a3e92 
  libs/kopageapp/KoPACanvas.cpp 17dec46 
  plugins/textshape/TextTool.cpp e699319 

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


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.


Thanks,

Yue Liu

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

Re: New panel for Calligra Flow

[Yue Liu]

Ok so this feature will be added in 2.5

On Sun, Oct 23, 2011 at 5:30 PM, Thorsten Zachmann t.zachm...@zagge.de wrote:
 On Sunday, October 23, 2011 06:58:18 Yue Liu wrote:
 To other developers, is it okay to add them to 2.4? They are just some
 data, so no code will be broken.

 if it does not add new strings that need to be translated I think it should be
 fine to add them. However if new strings are added I think it is not possible
 as we are already in string freeze.

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




-- 
Best Regards,
Yue Liu
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: New panel for Calligra Flow

[Yue Liu]

Currently we are concentrated on application development and not
enough man power for stencil creations, but Flow uses Get Hot New
Stuff component so you can create your own stencil set and submit it
to us or upload to kde-files.org. Here is the tutorial
http://community.kde.org/Calligra/Build_Stencils_for_Flow

On Sat, Oct 22, 2011 at 6:09 PM, C. Boemann c...@boemann.dk wrote:
 On Friday 21 October 2011 23:46:06 Sergey Chernouhov wrote:
 Dear Sirs,

 My name is Sergey Chernouhov. I am the author of CH-1 notation for
 business process modelling.

 I'll be very pleased if a panel containing symbols of CH-1 notation
 may be included in Calligra Flow.

 The basic data on CH-1 notation are here:
 http://ch1-notation.livejournal.com/ (including links to CH-1
 Specifications at Google Docs, both in English and in Russian, pdf
 format).

 Looking forward to hearing from you,

 Author of CH-1 notation, PhD
 Sergey Chernouhov
 ___
 calligra-devel mailing list
 calligra-devel@kde.org
 https://mail.kde.org/mailman/listinfo/calligra-devel
 I'm not saying that it couldn't be included, but wouldn't BPMN 2.0 be a better
 notation to work on if we as a project should spend time on it.

 As far as having CH-1 (no offense but I've never heard of it nor could I find
 any reference to it) I don't think anyone would object, but I also think it
 will take some effort on your own. Our manpower is spread rather thin. And as 
 I
 said if anything BPMN 2.0 sounds a much better candidate if we were to include
 such a notation.

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




-- 
Best Regards,
Yue Liu
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Re: New panel for Calligra Flow

[Yue Liu]

On the website it says it's included in Dia Shape Repository, then it
should be easy to be included in flow, there is a set of tools to
convert dia shapes to flow stencils using an openoffice extension.
I'll try convert them, maybe last time i missed them when converting
dia shape repository.

To other developers, is it okay to add them to 2.4? They are just some
data, so no code will be broken.

On Sun, Oct 23, 2011 at 10:23 AM, Yue Liu yue@mail.com wrote:
 Currently we are concentrated on application development and not
 enough man power for stencil creations, but Flow uses Get Hot New
 Stuff component so you can create your own stencil set and submit it
 to us or upload to kde-files.org. Here is the tutorial
 http://community.kde.org/Calligra/Build_Stencils_for_Flow

 On Sat, Oct 22, 2011 at 6:09 PM, C. Boemann c...@boemann.dk wrote:
 On Friday 21 October 2011 23:46:06 Sergey Chernouhov wrote:
 Dear Sirs,

 My name is Sergey Chernouhov. I am the author of CH-1 notation for
 business process modelling.

 I'll be very pleased if a panel containing symbols of CH-1 notation
 may be included in Calligra Flow.

 The basic data on CH-1 notation are here:
 http://ch1-notation.livejournal.com/ (including links to CH-1
 Specifications at Google Docs, both in English and in Russian, pdf
 format).

 Looking forward to hearing from you,

 Author of CH-1 notation, PhD
 Sergey Chernouhov
 ___
 calligra-devel mailing list
 calligra-devel@kde.org
 https://mail.kde.org/mailman/listinfo/calligra-devel
 I'm not saying that it couldn't be included, but wouldn't BPMN 2.0 be a 
 better
 notation to work on if we as a project should spend time on it.

 As far as having CH-1 (no offense but I've never heard of it nor could I find
 any reference to it) I don't think anyone would object, but I also think it
 will take some effort on your own. Our manpower is spread rather thin. And 
 as I
 said if anything BPMN 2.0 sounds a much better candidate if we were to 
 include
 such a notation.

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




 --
 Best Regards,
 Yue Liu




-- 
Best Regards,
Yue Liu
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

Review Request: Create text box when double click in default tool

[Yue Liu]

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

Review request for Calligra.


Summary
---

Changed double click behavior of default tool. Previously double click on a 
path shape will enter path edit mode, but more often user expect creating a 
text box on the shape. Now double click will create a textbox on the shape in 
all applications except karbon, which is more concentrated on graphic editing.


Diffs
-

  libs/flake/KoTosContainer.h a2162f0 
  plugins/defaultTools/defaulttool/DefaultTool.cpp ccfce0e 

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


Testing
---

Runs correctly on each app. But when moving textshape attached shapes there are 
some flickers when updating the textshape.


Thanks,

Yue

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

Re: Features changelog for Calligra 2.4 Beta

[Yue Liu]

Flow don't have much features, just the stencil docker, knewstuff
support for downloading stencils, and dia shapes converted to odg
stencils. Some important features are not finished yet and blocked by
some bugs in library so didn't enter master. Quite busy so the
development suspended recently, I'll be back around November.

On Mon, Sep 12, 2011 at 6:56 PM, C. Boemann c...@boemann.dk wrote:
 Sorry, yes indeed, ingwa please make it so

 On Monday 12 September 2011 12:50:34 Arjen Hiemstra wrote:
 On Sunday 11 September 2011 16:24:02 C. Boemann wrote:
  Calligra sees a new wordprocessor named Words. Though it has a heritage
  from KOffice's KWord it can in many ways be seen as a completly new
  appliction. We still have not addressed the user interface, and know we
  are not yet near what we want and need to achieve.
 
  Words has focused on it's textlayout engine and import filters, making it
  an excellent viewer of doc, docx and odt files. The docx is even better
  than LibreOffice is capable of.
 
  We have idetified the student/academic user as our first target user, and
  have been implementing Table of Contents, improved table support, support
  for citations and bibliography. These features even include user
  interface to some degree.
 
  Words is by no means a finished product. For document viewing and light
  editing tasks we would recommend it but the academic user writing a
  report wil not yet find it adaquate.
 
  Stay tuned for a great future for Calligra Words

 It might be interesting to mention something about the new Find/Replace
 code as well. Currently it is only used in Words, so it most likely makes
 sense to mention it in the Words section. Reading the rest of the words
 bit, it seems to also be the only bit that has a relatively finished ui.
 :p

 - Arjen

 ___
 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




-- 
Best Regards,
Yue Liu
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel