Re: Autocorrect functionality

On Wednesday October 19 2022 21:57:14 Laurent Montel wrote: > >Or we need to move them in a repo which is a dependancy for pim* and calligra >=> in a framework module. >Otherwise kmail autocorrect will be always broken. judging from the results of autocorrect I see posted I'd remove the 1st two

Re: Option to hide the menu

On Thursday July 15 2021 00:51:59 Sergio Esaú Arambula Durán wrote: >tarnishes how modern this suite looks and feels, could you please add a >CTR+M / hide menu option in the next release? You may be able to do that yourself, by copying e.g. /usr/share/kxmlgui5/calligrawords/calligrawords.rc to

Re: Words and large files

On Monday March 22 2021 09:01:21 Dag wrote: >But, I think comparison with LO says a lot: Sadly this is also my experience. Generally speaking, LO has more features, and while it's monolithic behemoth it just works for the most part. I've really wanted Calligra to be an alternative because there

Re: Merging with OpenOffice.org

> My name is Suhail Ansari and I am from India. I have a suggestion, >I think that Calligra Office project should merge with OpenOffice.org. Not to turn this into a flame war but I think this is about as realistic as suggesting that India and Pakistan should merge because it would be so

T12815: Create Calligra Framework by separating out applications and libraries

rjvbb added a comment. > I sometimes find myself feeling this way about Frameworks too. A recent experience at a hackathon where I helped 8 students set up complete development environments from scratch reinforced this viewpoint. Not that I'm seriously recommending re-merging the

T12815: Create Calligra Framework by separating out applications and libraries

rjvbb added a comment. > As an aside, I think splitting up kdepim into so many repositories was a huge mistake. Ah yes, that was definitely one of the reasons why I never updated my kdepim4 packaging. That said, I also appreciate the fact that the few apps I use that depend on kdepim

Re: T12815: Create Calligra Framework by separating out applications and libraries

What's the size of the .git directory of the calligra repo these days? I seem to recall it was what I thought really huge already in KDE4 days. Last time I tried git wouldn't let you push from a clone that didn't have the full history. And yes, for me there's a point where I consider the value

Re: D26050: Fix build with poppler 82

> I am a firm +1 on splitting Calligra +++ At the very least, the build system should be able to generate the shared parts as well as the different components (wordprocessor, spreadsheet, ...) separately (and depending on the installed shared libraries, for the components). Once that's done

Re: D20400: Karbon: Enable multi page capability

> (Sorry for the inconvinience, I've never been very friendly with arc/phab) Understandable ;) Did you go the "official" route, committing your changes to a local branch and then using `arc diff` to create a review request? You probably should have used ` --update revision_id` . I always use

D19216: Karbon: Enable multi page capability

rjvbb added a comment. > That is actual a valid point, although in say Krita with transparent pixels a checkerboard is shown. Heh, I've had the opportunity to work closely with professional infographists so I picked up a thing or two about using applications like Illustrator and

D19216: Karbon: Enable multi page capability

rjvbb added a comment. > No, the canvas is part of the document and must never be themed. The canvas background is as much part of your drawing as any line you put on it. This hasn't been sitting right with me and I finally realised why. That statement is true when you work with a

D19216: Karbon: Enable multi page capability

rjvbb added a comment. > Canvas color: > I don't quite see what it is for. You can set a background color for the canvas but it is only for the views, it is not printed. A custom canvas colour feature doesn't strike me as odd, nor that it isn't printed (printing it WITHOUT setting a

Re: D19216: Karbon: Enable multi page capability

This would indeed be great to have; even a page selector when importing a multi-page document would be an improvement (the Adobe Illustrator version I've use had that; IIRC it would just leave all other pages of the document alone). You should also test with PDF documents; in my experience

about QtWebKitWidgets

Hi, About the CMake warning suggesting that Qt5WebkitWidgets no longer exists: are you aware this is no longer true? QWK has been rebooted a few years ago already (https://github.com/annulen/webkit/) and is thus once more an alternative to QtWebEngine. One that should (probably/IMHO) be

Re: support for other Apple iWorks documents (Pages, ...)?

On Friday February 01 2019 12:01:08 Jaroslaw Staniek wrote: Hi >I doubt it due to scope of the challenge. It's not matter of just plugging >the lib into Calligra filters. Looking at how lean the Keynote import plugin seems to be I was hoping it would. But I also just discovered that plugin

v3.1.0 ExcelImport.cpp fails to build on Mac

Hi, I'm updating my MacPorts packaging for Calligra and ran into a snag building ExcelImport.cpp, or rather, ExcelImport.moc . It raises an error because of a missing ExcelImportFactory symbol in the Swinder namespace. Looking at the moc file the error seems reasonable and indeed it can be

support for other Apple iWorks documents (Pages, ...)?

Hi, Has any work been done on using libetonyek to import other Apple iWorks documents, notably text documents from Pages? Supposing it's actually usable? Thanks, R.

Re: Bumping qt version

On Tuesday January 15 2019 12:53:03 Jaroslaw Staniek wrote: > If there's no reason to force upgrade, I would not. Also (guess what) LTS > distros seem refuse to upgrade without users doing extra steps. Amen to that! I'm very annoyed by the fact that KF5 Frameworks just moved to Qt 5.10, for no

Re: Transitioning CI builds of all non-Frameworks from Qt 5.9

Hi, Can't you just configure the CI to use Qt 5.10? I think it's not good to hardcode an "overzealous" (for lack of a better word) Qt version in projects that don't require them AND I think that one should support the current LTS release in as many projects as possible as a general rule of

D16406: Fix build with poppler<0.64

rjvbb added a comment. How about if (Poppler_VERSION VERSION_LESS "0.64.0") add_definitions("-DHAVE_POPPLER_PRE_0_64") That also removes the ambiguity while reading the code ("is this 0.64.0 and higher or only that specific version?") and *may* make it easier to clean

Re: KDE CI: Dependency Build Calligra kf5-qt5 WindowsMSVCQt5.10 - Build # 1 - Failure!

On Wednesday July 25 2018 22:33:33 Ben Cooksley wrote: >On Wed, Jul 25, 2018 at 9:03 PM, Jaroslaw Staniek wrote: >> One way I would imagine is to make Prison optional dependency. Another to >> make it temporarily off on Windows or optional on Windows. ... >Note that it isn't Calligra depending

Re: Retirement of Reviewboard - Transition to Phabricator

On Friday August 25 2017 07:33:43 Ben Cooksley wrote: Hi, >> Note that due to how Reviewboard stores diffs and reproduces them for >> use, some reviews may have decayed and may no longer be readable. This >> is due to short-hashes which are used by Git/Reviewboard in diffs now >> having

Re: Phabricator: All repositories registered - upcoming workflow changes

On Thursday February 2 2017 21:50:38 Nicolás Alvarez wrote: >You missed the point. This "bit rot" is not about disk damage but >about software incompatibility. ZFS doesn't help with that... You mean diffs that no longer apply cleanly? In that case you missed our point. Being able to consult

Re: Phabricator: All repositories registered - upcoming workflow changes

Could this be of any help? https://www.cloudpipes.com/integrations/phabricator/reviewboard A paying service, but if the integration allows migration of existing ReviewBoard stuff into Phabricator a well-timed 2-month trial (or multiple thereof ;)) might suffice? There's also this:

Re: Phabricator: All repositories registered - upcoming workflow changes

On Wednesday February 01 2017 23:03:53 Albert Astals Cid wrote: > You'd be surprised (yes i have a script that actually applies the MRs and > lots > of them even very old apply). Old also doesn't mean unmaintained. I have a number of RRs that I keep rebasing because I'm still waiting for a

Re: Phabricator: All repositories registered - upcoming workflow changes

On Wednesday February 1 2017 22:16:50 Ben Cooksley wrote: >We'd still have to keep the software running, and up to date (to avoid >it becoming a security risk). Running yes, but if log-in is disabled at the core and not linked to the central LDAP service or whatever it is you use, what

Re: Phabricator: All repositories registered - upcoming workflow changes

On Wednesday February 1 2017 20:59:46 Ben Cooksley wrote: Hi > >While I have yet to test it, Reviewboard does use quite a bit of AJAX >and other dynamic resources - so I won't be surprised to find out that >the usual mechanisms for creating static copies of sites don't produce >a workable

Re: Phabricator: All repositories registered - upcoming workflow changes

On Tuesday January 31 2017 20:10:42 Luigi Toscano wrote: >> It will be a complete shutdown of Reviewboard - we'll be archiving it >> in the event for some reason it becomes necessary to access the data >> it stores. > >Isn't it a way to change the site in static website and keep it alive?

Re: Phabricator: All repositories registered - upcoming workflow changes

On Sunday January 29 2017 08:32:21 Ben Cooksley wrote: Hi, >From this point forward, communities should be moving away from >Reviewboard to Phabricator for conducting code review. Sysadmin will >be announcing a timeline for the shutdown of Reviewboard in the near >future. I hope that shutdown

Re: Review Request 129800: [Mac] : prepare for "linuxy" vs. standalone app bundle builds

> On Jan. 10, 2017, 9:28 p.m., Anthony Fieroni wrote: > > So when Karbon works, i'm +1, please try words / sheets are they worked as > > well as Karbon? > > René J.V. Bertin wrote: > I cannot tell yet, but I'm not expecting any issues because of this > patch. As you can see it only

Re: isn't it time for...

... (on a related note) providing the handbooks/documentation, even if it means shipping the ones for 2.9 or transferring the user to the web-based docs as I've seen Calligra 2.9 apps do? The link between the "Help" menu and what documentation is ultimately opened (and how) is among the

Re: Review Request 129800: [Mac] : prepare for "linuxy" vs. standalone app bundle builds

> On Jan. 10, 2017, 9:28 p.m., Anthony Fieroni wrote: > > So when Karbon works, i'm +1, please try words / sheets are they worked as > > well as Karbon? > > René J.V. Bertin wrote: > I cannot tell yet, but I'm not expecting any issues because of this > patch. As you can see it only

Re: Review Request 129800: [Mac] : prepare for "linuxy" vs. standalone app bundle builds

> On Jan. 10, 2017, 9:28 p.m., Anthony Fieroni wrote: > > So when Karbon works, i'm +1, please try words / sheets are they worked as > > well as Karbon? > > René J.V. Bertin wrote: > I cannot tell yet, but I'm not expecting any issues because of this > patch. As you can see it only

Re: Review Request 129804: [Mac] enable app icon generation from the SVG icon (potentially for MS Windows too)

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129804/ --- (Updated Jan. 14, 2017, 8:19 p.m.) Review request for Calligra and KDE

Re: Review Request 129800: [Mac] : prepare for "linuxy" vs. standalone app bundle builds

> On Jan. 10, 2017, 9:28 p.m., Anthony Fieroni wrote: > > So when Karbon works, i'm +1, please try words / sheets are they worked as > > well as Karbon? > > René J.V. Bertin wrote: > I cannot tell yet, but I'm not expecting any issues because of this > patch. As you can see it only

Re: Review Request 129800: [Mac] : prepare for "linuxy" vs. standalone app bundle builds

> On Jan. 10, 2017, 9:28 p.m., Anthony Fieroni wrote: > > So when Karbon works, i'm +1, please try words / sheets are they worked as > > well as Karbon? > > René J.V. Bertin wrote: > I cannot tell yet, but I'm not expecting any issues because of this > patch. As you can see it only

Re: Review Request 129804: [Mac] enable app icon generation from the SVG icon (potentially for MS Windows too)

> On Jan. 11, 2017, 4:37 p.m., Anthony Fieroni wrote: > > karbon/CMakeLists.txt, line 55 > > > > > > Why only for Apple, it's needed some other changes ? You're right, I made that change yesterday and decided

Re: Review Request 129804: [Mac] enable app icon generation from the SVG icon (potentially for MS Windows too)

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129804/ --- (Updated Jan. 11, 2017, 4:30 p.m.) Review request for Calligra.

Review Request 129804: [Mac] enable app icon generation from the SVG icon (potentially for MS Windows too)

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129804/ --- Review request for Calligra. Repository: calligra Description ---

Re: Review Request 129800: [Mac] : prepare for "linuxy" vs. standalone app bundle builds

> On Jan. 10, 2017, 9:28 p.m., Anthony Fieroni wrote: > > So when Karbon works, i'm +1, please try words / sheets are they worked as > > well as Karbon? I cannot tell yet, but I'm not expecting any issues because of this patch. As you can see it only touches common/shared code at the moment,

Review Request 129800: [Mac] : prepare for "linuxy" vs. standalone app bundle builds

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129800/ --- Review request for Calligra. Repository: calligra Description ---

Karbon and import from Illustrator

Hi, I've been making my first steps getting Karbon to build on Mac. There's an issue with QStandardPaths in one of the central KO libraries that I'll need to address properly but that shouldn't be too hard. My current question is about import from Adobe Illustrator. For some curious reason

Re: Version stuff in CMakeLists.txt

On Wednesday January 4 2017 10:45:39 Dag wrote: >We have now released 3.0.0.1. Next should probably be 3.0.1. >So I gather current should be an alpha: >Major: 3 >Minor: 0 >Release: 89 > >But then we would go backwards to Release: 1 when releasing, >and after that we go to Release: 89 again and we

Re: map support, Marble and Mac

On Tuesday December 27 2016 16:47:53 Friedrich W. H. Kossebau wrote: > Calligra uses macro_optional_find_package with Marble currently: > https://cgit.kde.org/calligra.git/tree/CMakeLists.txt#n543 > > So what do you mean? Oops, apparently Jaroslaw was right that this should have gone to the

Re: packaging Calligra: common dependencies?

On Tuesday December 27 2016 16:39:27 Friedrich W. H. Kossebau wrote: > Currently the Calligra buildsystem expects the shared libs being part of the > sources that are build, not being imported from the outside. There is no > support for that. > > So pruning is what you will need to do

Re: calligra tarball contains kexi translations also contained in the kexi tarball (idem for krita)

On Tuesday December 27 2016 16:33:58 Friedrich W. H. Kossebau wrote: > See thread "calligra 3.0.0 tarball" on this mailinglist, with some background > info in email Apologies, I didn't read every message on that thread religiously ... R.

Re: calligra tarball contains kexi translations also contained in the kexi tarball (idem for krita)

On Monday December 26 2016 22:02:21 Jaroslaw Staniek wrote: > ​OK, heard about that already from somewhere but how is this possible since > if there's no trace of Kexi code in calligra.git since 3.0.0? The only thing I can imagine is that the translation team didn't pick up on this detail. >

Re: Kexi/Mac

On Monday December 26 2016 20:18:39 Jaroslaw Staniek wrote: >​These are great news​, ​René! >Maybe I am repeating myself but the enforcement of the widget style and >icon theme is dictated by a specific approach: maintainer of a style is >free to add the style/theme and even change the default or

calligra tarball contains kexi translations also contained in the kexi tarball (idem for krita)

Hi, The venom is all in the title: the calligra and kexi tarballs both contain translations for kexi. The same applies to krita. This is very annoying for packaging, unless I missed a CMake switch in Calligra's cmake file to filter out unwanted translations per product? R.

Kexi/Mac

Hi, A little FYI/thumbs-up ... despite plans to get Karbon working on Mac first it's Kexi that won in the end. Not the standalone, all-inclusive app bundle some might be hoping for, but a MacPorts package (port): https://github.com/RJVB/macstrop/tree/master/kf5/kf5-kexi I've committed a few

Re: map support, Marble and Mac

On Monday December 26 2016 17:12:07 Gilles Caulier wrote: > I just checked. Marble is optional for digiKam. If dependency is not > resolved, all code relevant are not compiled... Yes, true. From a packaging (and even more general) point of view it's better though if it's possible to skip the

Re: map support, Marble and Mac

On Monday December 26 2016 15:11:03 Gilles Caulier wrote: Hi Gilles, and happy belated 2016 to you too ;) >If i'm not too wrong, Marble cmake support has been completely re-written >from scratch and is now more flexible to bundle (OSX and Windows).

map support, Marble and Mac

Hi! Might I suggest to use macro_optional_find_package() to detect presence of Marble? From a packaging point of view it would be more elegant to be able to avoid opportunistic dependencies on large and complex projects like Marble. The reason: Marble is one of a tiny set of applications that

Qt5 components found but not Qt5 itself?!

Hi, Can anyone explain why I'm seeing this (on Mac OS X using Qt5 5.6.2 from MacPorts): > -- The following REQUIRED packages have been found: > * ECM (required version >= 1.7.0) > * KF5Archive (required version >= 5.7.0) > * KF5 (required version >= 5.7.0) > * Qt5Core > * Qt5Gui > *

packaging Calligra: common dependencies?

Hi, Sorry in advance if I could have scraped this information from the build instructions: I'm starting to look at creating MacPorts ports for Calligra (starting with Karbon). I see that it's possible to build and package a set of Calligra libraries and components shared among all or a major

Re: calligra 3.0.0 tarball

Hi, I can't remember if this has been suggested before: why not xz'ip the tarball as most all other KDE projects do? Should reduce the download size rather significantly... R.

Re: Review Request 129421: [karbon] Returning of Karbon as maintained product

On Saturday November 19 2016 21:52:21 Camilla Boemann wrote: >> As https://community.kde.org/Calligra/Maintainers Karbon has a maintainer, >> so i can be Co-Maintainer, i'm missing experience with graphics nor vector >> graphics software but i will try to help and fixing bugs. Let me just say

Re: "non standalone app bundle" builds on Mac

On Tuesday November 08 2016 15:03:40 Jaroslaw Staniek wrote: Hi, >> >Fine with me, what are the KF5 rules say? >It's a SoK period so it's pretty possible that some students can help with >such changes :) I have no idea, and I'm not convinced that a suggestion to change anything would get much

Re: "non standalone app bundle" builds on Mac

On Tuesday November 08 2016 13:20:37 Jaroslaw Staniek wrote: > > KDE software mostly uses the form > > > > #include > > > > whereas on Mac you'd include the main header of a Foo.framework with > > (presuming it's not ObjC) > > > > #include > > > > Maybe that can be seen as misfeature of Xcode

Re: "non standalone app bundle" builds on Mac

On Tuesday November 08 2016 12:17:23 Jaroslaw Staniek wrote: > > I hope special cases in a cmake buildsystem would not be a problem. I've > worked with cmake-based build systems that support Makefiles generator > (JOM/NMake) and VS generators in the same cmake scripts. The later is a >

Re: "non standalone app bundle" builds on Mac

On Monday November 07 2016 18:14:35 Jaroslaw Staniek wrote: Hi Jarek, >​Thanks for the interest! >In addition Kexi-specific things can be discussed at a ​kexi-devel list :) >There were enthusiastic people interested in contributing Mac builds of >Kexi but they disappeared so this task is open

Re: "non standalone app bundle" builds on Mac

On Sunday November 06 2016 14:26:41 Friedrich W. H. Kossebau wrote: Hi, > When it comes to Calligra and MacPorts, I do have not seen anyone working on > macOS-related stuff. So if you have patches/improvements, there might be > noone I forgot to ask: how far off from a release are you? While

Re: "non standalone app bundle" builds on Mac

> On Sun, 6 Nov 2016, René J.V. Bertin wrote: > (Q_WS_MAC) which I thought is no longer defined I was right. And when I say some of the Mac adaptations look (almost) like quick hacks: ``` #ifdef Q_OS_MAC #include #include #include /** * Native Win32 method for starting a process. This is

Re: "non standalone app bundle" builds on Mac

On Sunday November 06 2016 14:21:00 Boudewijn Rempt wrote: > I'm still here on this mailing list. To be frank, I don't really want a > macports version of Krita: macports is fine and dandy for things that > otherwise wouldn't be available, but in the case of Krita, it would only be > yet

Re: "non standalone app bundle" builds on Mac

On Sunday November 06 2016 13:47:13 Friedrich W. H. Kossebau wrote: Hi, > For properly reaching Krita devs please use the ml kimageshop (sic, named > like > that for historic reasons): > https://mail.kde.org/mailman/listinfo/kimageshop Thanks. Great, yet another mailing list

"non standalone app bundle" builds on Mac

Hi, As some of you may have picked up from my posts on other KDE MLs, I've been working to bring "KF5" to MacPorts via a set of ports that continue the tradition started with the KDE4 ports, and that correspond to MacPorts' approach. Everything is built as much as possible the way it is on

Re: Qt version

On Wednesday August 10 2016 14:49:35 Jaroslaw Staniek wrote: >I think traditionally even 5.6+ -only things shall be ifdef'd. > >I am sure 5.7+ things *should* be and the code should compile with 5.5. >(Assuming we're targeting LTS distros and alike that may even have 5.3, >which is a reasonable

Re: Introduction of a "type mode" and an "unicode mode" of input

On Sunday July 03 2016 11:28:28 Jaroslaw Staniek wrote: >On a GUI level: There's KDE GUI for that (there are many equivalents): >https://utils.kde.org/projects/kcharselect/ Does that have a KF5 equivalent yet? >It's not the input method so someone needs to turn that input method. As >you can

Re: RCC for icons - update: Re: Icons installed by apps

On Monday March 07 2016 12:41:52 Jaroslaw Staniek wrote: >I am trying to use app-defined icons through QIcon::fromTheme() in Kexi. That sounds inherently wrong unless the application adds icons to specific themes. Icons that are specific to an application are (almost) by definition not part of

Re: RCC for icons - update: Re: Icons installed by apps

On Thursday February 18 2016 19:47:04 Jaroslaw Staniek wrote: > ​Sure but we all agree that outside of desktops adjusted for the taste of > geeks XDG isn't part of these OSes. You are missing the point. The icon theme search path will contain the XDG icon location by default on systems where

Re: [Maniphest] [Commented On] T665: Show default (empty) document on startup in document-based Calligra apps

On Tuesday January 19 2016 10:07:25 kossebau wrote: >Unless I have seen and read the reports of the UI designers of MS, LO & Co. >and their reasoning for why it is like this, it seem just blind copying of >their UI, which does not make sense to me and my needs. >And otherwise I also would not

Re: [Maniphest] [Commented On] T665: Show default (empty) document on startup in document-based Calligra apps

On Monday January 18 2016 12:47:59 C. Boemann wrote: >Well what you would get is a really empty document then - not pages, no font, >no margins, no nothing - all of those decisions is what is stored in a >template. Having to code all those decisions just for the sake of not loading >a file

Re: [Maniphest] [Commented On] T665: Show default (empty) document on startup in document-based Calligra apps

On Monday January 18 2016 10:05:32 boemann wrote: >One thing tohugh - it shouldn't be an empty document - I wan to get away from >this as we need all sorts ofinitial setup, and i want to remove the custom >dialog for the same reason - but anyway the default startup document should be >the

Re: making a poster/flyer

On Tuesday December 29 2015 16:06:49 Jaime wrote: Hello! Ah, yes, Scribus, the FOSS alternative to InDesign. I always forget about that one, possibly because I've never really gotten the hang of it (and I find its file dialogs a bit annoying :)). I'll play around with it and see how we get

making a poster/flyer

Hi, A bit of a generic question ... I've been asked to make a poster to advertise an event of a club where I'm about the only one with computer knowledge (as if that's got anything to do with it :)) The posters I've made before were all big, complex affairs for use in scientific conferences,

Re: Reminder: Calligra 2.9.9

On Friday October 30 2015 12:33:02 Boudewijn Rempt wrote: >KoDocumentEntry, I think... Who knows, but what about KoDocumentEntry would explain this? I guess it's a mix-up between kparts(?) but how/where to trace the load process? R. > >> On Friday October 30 2015 10:44:27 Jaroslaw Staniek

Re: Reminder: Calligra 2.9.9

On Friday October 30 2015 10:44:27 Jaroslaw Staniek wrote: Hi, I presume it's too late to look into why on OS X calligraflow actually launches (loads) karbon, and karbon launches calligraflow, when both applications are installed? I have no idea where to start tackling that mystery... R.

Re: Review Request 125649: [OS X] install icon resources in app bundles where this doesn't happen automatically

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125649/ --- (Updated Oct. 27, 2015, 6:41 p.m.) Status -- This change has been

Re: Calligrastage 2.9.8/Mac : dynamic_cast error message

On Monday October 19 2015 00:05:35 Friedrich W. H. Kossebau wrote: > Please commit to calligra/2.9 and master. Can cherry-pick to master myself, > if > you do not have that branch present. Done (commit ff0f7766), and indeed please do the cherry pick to master yourself. BTW, I noticed that

Re: Calligrastage 2.9.8/Mac : dynamic_cast error message

On Friday October 16 2015 01:17:50 Friedrich W. H. Kossebau wrote: > On my system with gcc version 5.1.1 it seems that does not result in a Not, I've never seen this kind of error with gcc. Nor very often with clang, fortunately... > A workaround/fix might be to make KoSharedLoadingData a

Re: Review Request 125649: [OS X] install icon resources in app bundles where this doesn't happen automatically

> On Oct. 16, 2015, 12:30 a.m., Friedrich W. H. Kossebau wrote: > > `Q_WS_MAC` is not a cmake var, or? Seems someone accidentally used the c++ > > macro/define here, and noone ever noticed? :) > > > > In Qt5/KF5/ECM worlds ecm_add_app_icon does the respective installation, > > right? So only

Re: Review Request 125649: [OS X] install icon resources in app bundles where this doesn't happen automatically

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125649/ --- (Updated Oct. 16, 2015, 6:28 p.m.) Review request for Calligra and KDE

Calligra 2.9.8 / Mac

Hi, I've finally gotten around to rebuilding the current stable Calligra version through my MacPorts port. Here are a couple of observations: Generic: - git describe still gives a 2.9.7 version - the "stable/calligra-latest" link on the release image server still points to v2.9.7 too OS X

Re: Review Request 125649: [OS X] install icon resources in app bundles where this doesn't happen automatically

> On Oct. 16, 2015, 12:30 a.m., Friedrich W. H. Kossebau wrote: > > `Q_WS_MAC` is not a cmake var, or? Seems someone accidentally used the c++ > > macro/define here, and noone ever noticed? :) > > > > In Qt5/KF5/ECM worlds ecm_add_app_icon does the respective installation, > > right? So only

Review Request 125649: [OS X] install icon resources in app bundles where this doesn't happen automatically

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125649/ --- Review request for Calligra and KDE Software on Mac OS X. Repository:

Re: Calligra 2.9.8 / Mac

On Thursday October 15 2015 21:39:27 Jaroslaw Staniek wrote: > Maybe you did so in the past and I just lost the links, but would you I never did for Calligra, it's a generic issue. > Not that it's ideal on Linux too: the sidebar isn't too freely > shrinkable. Some margins are not needed. This

Calligrastage 2.9.8/Mac : dynamic_cast error message

Hi, Running a quick test of CalligraStage 2.9.8 on OS X 10.9, I see this error in my system.log: Oct 15 22:35:09 Portia.local calligrastage[80756]: dynamic_cast error 1: Both of the following type_info's should have public visibility. At least one of them is hidden. 19KoSharedLoadingData,

Re: Calligra 2.9.8 / Mac

On Thursday October 15 2015 22:34:51 Jaroslaw Staniek wrote: > Thanks a lot, René, added a notification on 26th for you :) Heh, I'll just be back from a trip on the 26th, but who knows, maybe I'll be bored without anything better to do some time during said trip ;) R.

Re: Calligra 2.9.8 / Mac

On Thursday October 15 2015 17:56:29 René J.V. Bertin wrote: > Possibly generic: Krita isn't particularly well-behaved and ignores the > system-wide style setting. Using an internal theme is fine, but only if it's > optional. FWIW, after removing the hard-coded style specifications, it turns

Re: Calligra 2.9.8 / Mac

On Thursday October 15 2015 19:47:10 Jaroslaw Staniek wrote: > If you ask, personally I'd be rather interested in caring for 1. > native look, As I said, the best way to approach native look to date is to use QtCurve, at least with KDE4. The native Qt style has given us too many issues, and

Re: Big reformat of sources before unfreeze of master (was: Re: Schedule to switch back to master for feature development)

3) Renaming files into CamesCaseStyle.cpp instead of underscore_style.cpp will break my workflow. You have to expect me to spent at least 2 working days on readjusting my workflow. I'm ok with it, though I would prefer to spend this time on something more useful for Krita. Well, we can do

Re: What If OpenDocument Used SQLite?

On Tuesday August 25 2015 00:59:28 Jos van den Oever wrote: 5) Content is inaccessible. XML matches office documents much closer than SQL. Formatting XML is easy and automatically done by most viewers. I'd cite 5) for content stored in sql files ... Storing a text document in a

Re: Calligra Icons

On Monday July 27 2015 10:14:20 C. Boemann wrote: I'd prefer to not change our application icons at all - I'm sorry but I find you new ones very anonymous and I would prefer if we keep our current ones Amen to that! In fact, I'd add that those proposed icons are useless in a GUI environment

Re: phabricator.kde.org reviews (differential)

On Monday June 01 2015 09:28:01 Jaroslaw Staniek wrote: Hi, At least the Krita and Kexi guys use phabricator.kde.org. Step by step we're looking at comfortable use cases. When this was brought up I tried to have a look (after reading the claim referring to gerrit ;)) but couldn't get beyond a

about font handling (and restore)

Hi, Any experts on font handling implementation on here? It's been a while since I noticed that Qt 4.8 has problems in its typeface handling (weight style combinations), noticeable esp. on OS X but not absent on Linux either. In a nutshell, creating a QFont from a family,weight,style triplet

krita window size

Hello, I just ran a quick check of a few Calligra components on my Linux netbook, that worked fine. Only Krita didn't seem to want to respect the window manager instructions and (vertical) screen size. As a result, I couldn't get the whole window on screen, and using KWin to maximise the

Re: krita window size

On Friday April 03 2015 11:00:49 Boudewijn Rempt wrote: No, but the dockers and or the toolbox may make the window too big. I test Krita on 1024x768 with KDE and default font settings; bigger fonts, The netbook's screen is a typical 1366x768 ... smaller resolution or another desktop may make

Re: Qt5 Port Status

On Monday March 23 2015 11:01:11 Boudewijn Rempt wrote: doesn't support sharing the same area across different libraries, which is something we do a lot in Calligra. We have three options: remove all the areas (as I did in koplugin), make areas per library or create a new

Re: Qt5 Port Status

On Saturday March 21 2015 11:03:21 Boudewijn Rempt wrote: doesn't support sharing the same area across different libraries, which is something we do a lot in Calligra. We have three options: remove all the areas (as I did in koplugin), make areas per library or create a new

Re: [KDE/Mac] about the kde4_add_plugin macro, and shared vs. module building

On Monday March 09 2015 18:15:46 Benjamin Reed wrote: All of my memories of this are from the OSX 10.3/10.4 timeframe, back when we were first figuring out how to make dynamic loading play well with KDE on OSX, so I may be getting some details wrong. :) Good memories. Mine were a bit buried, but

  1   2   >