Re: Autocorrect functionality

[René J . V . Bertin]

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 
words from that last sentence...

and I'd be more in favour of a framework that teaches people to ego-correct :-/

R.

Re: Option to hide the menu

[René J . V . Bertin]

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 
~/.local/share/kxmlgui5/calligrawords/calligrawords.rc, and then find e.g. the 
 section to which you can add a line



Bump the version number on the file's 2nd line by one so that your version of 
the file is taken into account.

This will presumably get the shortcut automatically.

Similar instructions would apply to the other suite members; if you don't find 
the file installed in /usr/share/kxmlgui5 it may have been embedded. In that 
case you can grab it from the Calligra sources (I'd use your distro's command 
to fetch the sources they use).

R

Re: Words and large files

[René J . V . Bertin]

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 are things in 
its interface that I prefer (including the use of Qt), but at the end of the 
day it's sadly a bit like so many webbrowsers nowadays. Trying to play catch-up 
with the big guys (and those browser projects do have it a lot simpler, I 
realise). Great as a learning project and platform for testing out ideas when 
you're a developer, not so much when you're an end-user trying to be 
productive. The availability of official installer packages is a big plus for 
LO, too.

I do keep a special place for Karbon as I still sometimes need something with 
Adobe Illustrator capabilities (I'm not aware of other AI alternatives; 
Inkscape is more of a competitor). Idem for Krita.

R.

>

Re: Merging with OpenOffice.org

[René J . V . Bertin]

> 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 good for 
both of them...

T12815: Create Calligra Framework by separating out applications and libraries

[René J . V . Bertin]

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 frameworks, but I would like to challenge the 
notion that splitting a monolithic codebase across multiple repos is a boon to 
onboarding; I don't think it is. It may have other benefits, but I don't think 
onboarding is one of them.
  
  Apple were first to start calling their system libraries "frameworks" and 
they do have a nice feature that would address those issues. Something like the 
Accelerate framework is actually a collection of frameworks. You only specify 
the "interface" framework, and I *think* that "the system" figures out what to 
link. Of course they had to rewrite the linker driver (or linker itself) in 
order to understand how to deal with their framework bundles so they had every 
occasion to add some additional logic.

TASK DETAIL
  https://phabricator.kde.org/T12815

To: rjvbb
Cc: jtamate, rempt, anthonyfieroni, dcaliste, boemann, pino, rjvbb, ngraham, 
ognarb, Calligra-Devel-list, #calligra:_3.0, leinir, davidllewellynjones, 
cochise, vandenoever

T12815: Create Calligra Framework by separating out applications and libraries

[René J . V . Bertin]

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 features now require only to maintain packaging for smallish 
libraries (that often also don't evolve that quickly).
  
  But somehow I doubt that latter argument can be transferred to Calligra's 
libraries...

TASK DETAIL
  https://phabricator.kde.org/T12815

To: rjvbb
Cc: rempt, anthonyfieroni, dcaliste, boemann, pino, rjvbb, ngraham, ognarb, 
Calligra-Devel-list, #calligra:_3.0, leinir, davidllewellynjones, cochise, 
vandenoever

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

[René J . V . Bertin]

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 of my few and 
smallish contributions don't justify wasting "that much" disk space on what's 
literally old history.

FWIW, KDevelop moved in the opposite direction, pulled their "framework" bit 
(kdevplatform) with the other code into a single repo. Which, incidentally, 
made it harder to build only select parts (plugins), just like you cannot 
really build only a specific Calligra component against installed versions of 
the library components (last I checked).
Not that that's a necessary implication but it's a bit tricky to write a build 
system that can build against either just-build libraries or against the 
installed copies.

Re: D26050: Fix build with poppler 82

[René J . V . Bertin]

>  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 it should be possible to reorganise the source 
tree so releases can consist of separate tarballs for the shared bits and the 
individual applications even if you'll continue to use a single git repo (which 
would probably make sense).

Re: D20400: Karbon: Enable multi page capability

[René J . V . Bertin]

>  (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 uncommitted changes myself, either going through the 
Purpose/KDevelop plugin to upload a diff to phab, or using the web interface. 
That approach has its own quirks and inconveniences but ones I prefer.

D19216: Karbon: Enable multi page capability

[René J . V . Bertin]

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 
InDesign :)
  
  How to indicate a transparent area of an object is yet another subject, with 
a related but not identical purpose.
  
  >   That said it might make more sense for this "testing background" to be 
part of the document and not a general setting - if the use case is as you say 
then the testing background would also be different for different projects
  
  True. I was reacting to *re*moving a setting completely, not to moving it to 
a more appropriate context.

REPOSITORY
  R8 Calligra

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

To: danders, anthonyfieroni
Cc: boemann, rjvbb, Calligra-Devel-list, dcaliste, cochise, vandenoever

D19216: Karbon: Enable multi page capability

[René J . V . Bertin]

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 real canvas and 
draw/paint/whatever directly onto that. If you take a grid paper the grid will 
become part of your art, but does Karbon print the grid which you can have it 
show (except possibly via an option)?
  
  In drawing applications, the canvas is NOT part of your art, but simulates 
the canvas you'll be printing on. It's a backdrop layer that sits behind/below 
the lowest layer you can draw on. If you plan to print on a coloured piece of 
paper, or one with a canvassy texture, you'll probably want to adapt your 
virtual canvas so you can incorporate the physical canvas properties into your 
design. But you don't want that virtual canvas to print as that would be a 
waste of toner at best...
  
  That's not to say that the virtual canvas should not be exportable at all: 
you'd want to be able to include it when generating a PDF (SVG, JPG, etc) 
format version for use in on-screen only presentations. Of course you could 
just add a backdrop layer in that case.
  
  I'm not aware that Karbon has the equivalent of a slide/page design feature 
where you can define how each page will look. That could look be used to be 
achieve what I describe here but in Karbon that layer should probably not be 
printed by default (just like it isn't in presentation apps, IIRC).

REPOSITORY
  R8 Calligra

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

To: danders, anthonyfieroni
Cc: boemann, rjvbb, Calligra-Devel-list, dcaliste, cochise, vandenoever

D19216: Karbon: Enable multi page capability

[René J . V . Bertin]

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 dedicated option would seem wrong to me).
  
  What about when you use an inversed theme, isn't a custom canvas colour 
required then if you want to see your black line art on a light (white) canvas?

REPOSITORY
  R8 Calligra

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

To: danders, anthonyfieroni
Cc: rjvbb, Calligra-Devel-list, dcaliste, cochise, vandenoever

Re: D19216: Karbon: Enable multi page capability

[René J . V . Bertin]

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 Karbon 3.1 works well 
enough with them.

>Ported to use pageapp classes.
...
> A lot of code was duplicated between pageapp and karbon
> and has been removed from karbon:

Shouldn't that be a separate change - or does multi-page support come 
automatically with this change?

about QtWebKitWidgets

[René J . V . Bertin]

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 preferred in anything not 
aiming to be a full-blown webbrowser because it needs (much) less resources and 
tends to be noticeably faster.

There has been talk of re-integrating the rebooted version into Qt, I don't 
know what the status of that is.

HtH,
R.

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

[René J . V . Bertin]

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 doesn't work with my .key files - 
after I managed to force-build Stage which was uneventful once I had figured 
out which file to hack (is there an official way to say "ignore there's no 
current maintainer, just build it"?)

>+ NIH. Sending ODF files to users of MSO is no longer a blocker, why it
>would be different with Apple users?

Not sure what you mean here; I'm looking for import of my .pages documents.
I don't remember if and how well my version(*) of Pages exports to ODF format, 
but it's export to .doc is ... perfectable. 

*) From iWorks 09. Old, but one of the best releases before they started 
stripping more advanced features that may or may not have been restored in 
later versions which won't run on my OS version.

I'll see if and how LO deals with those .pages files (pardon, directories :) ) 
of mine.

R.

v3.1.0 ExcelImport.cpp fails to build on Mac

[René J . V . Bertin]

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 fixed 
by moving the 2 `using` lines up to just above the K_PLUGIN_FACTORY_WITH_JSON 
line in ExcelImport.cpp .

I built the same code on Linux with the same compiler ("stock" clang 5.0.2) and 
same Qt (5.9.7) and didn't get this error, not even with -stdlib=libc++. The 
file also builds with the fix described above.

Any idea what's going on here?

R.

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

[René J . V . Bertin]

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

[René J . V . Bertin]

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 
real good reason AFAICT.
(As a result I find myself backporting the necessary bits of 5.10 to my Qt 5.9 
build...)

R.

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

[René J . V . Bertin]

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

There's a reason why those LTS releases exist and that should probably be taken 
into consideration ESPECIALLY for the KF5 Frameworks (remember why kdelibs4 was 
split up)!

People working only on Linux may not realise it but even Qt 5.9 already dropped 
support for Mac OS versions that are still widely used.

IMHO, projects that use PIM libraries can decide for themselves how they want 
to deal with a Qt minimum version bump in those dependencies, while 
distribution maintainers *could* decide to keep those (and only those) 
dependencies on an earlier version in order to keep supporting whatever oldest 
Qt requirement they have (5.9 for my MacPorts packaging). Also, don't of those 
projects have only optional dependencies on PIM libraries?

I tend to see a CI as something that tests software on one or a handful of the 
most common configurations. Anyone not using such a configuration is either on 
their own or acting as a kind of additional CI.

Bumping the minimum Qt version across the line would decrease the burden on the 
CI, but probably increase the burden on distributions, or force them to stop 
following upgrades earlier than justified.

Also:
> (otherwise we'll end up chasing down build failures for a long time)

How so? If you want to install project B that requires Qt 5.9+ but also uses 
PIM library A which requires Qt 5.1x you're going to need to install something 
newer than Qt 5.9 . What kind of build failures we cannot already get ("B 
requires PIM library A which is not installed") are you expecting?
There could be errors from *other* projects not depending on PIM libraries, but 
if they intend to support an "older" Qt version that implies rather explicitly 
that they also intend to address build failures, no?


R.

D16406: Fix build with poppler<0.64

[René J . V . Bertin]

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 
obsolete code later on when support for Poppler < 0.64.0 is dropped.

REPOSITORY
  R8 Calligra

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

To: arojas, #calligra:_3.0, aacid, pino
Cc: rjvbb, pino, Calligra-Devel-list, dcaliste, cochise, vandenoever

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

[René J . V . Bertin]

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 on Prison, it's Calligra depending on
>Akonadi's contacts component, which in turn hard depends on Prison, that is
>the problem.

Does KDEPIM work on MSWin? If it doesn't (and I can easily imagine it won't), 
then there's probably little use in depending on akonadi-contacts, no?

R.

Re: Retirement of Reviewboard - Transition to Phabricator

[René J . V . Bertin]

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 collisions with other commits which previously did not exist.
>> Unfortunately there is nothing we can do about this.

This is probably a "wild thought", but would it be possible somehow to limit 
the issue by not letting the ReviewBoard software compare to each repo's HEAD 
but against whatever commit is current now (or when you retire the thing)?

And FWIW, you're aware of git-diff's --full-index option? ;)

R.

Re: Phabricator: All repositories registered - upcoming workflow changes

[René J . V . Bertin]

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 intermediate versions of diffs, abandoned diffs etc. is 
not to be able to apply them "as is". If there were no value in the kind of 
code those diffs (can) contain we'd not be using git or git wouldn't be 
preserving every single bit of history. 


Oh well. This is just another expression of FOSS's biggest weakness. Every 
project has this centre-of-the-universe tendency that apparently justifies 
breaking things for large parts of the user base whenever the project feels 
it's justified.

R

Re: Phabricator: All repositories registered - upcoming workflow changes

[René J . V . Bertin]

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:
https://secure.phabricator.com/T3179


On Thursday February 2 2017 22:09:34 Ben Cooksley wrote:

>For those who dismiss decay as an issue - problems with previous
>Reviewboard upgrades not taking cleanly have resulted in some reviews
>being damaged, causing their diffs to become unavailable. These sorts
>of problems do happen.

Yes, I bet they do, and I bet there are ways to prevent them from happening.
Bitrot should not be an issue with the ready availability of ZFS (on Linux or 
BSD, FreeNAS etc) and btrfs, and 

>Reviewboard has a WebAPI which should be usable by anyone interested
>to extract all the information regarding reviews, including their
>comments and the diff itself. This could be used to create a static
>snapshot of each review.

Is it just me or does this convey a suggestion that projects that would like to 
be able to use review procedures the way Francis described better run their own 
service if they want reliability and not have to cope with essentially random 
transitions that discard entire histories?

R

Re: Phabricator: All repositories registered - upcoming workflow changes

[René J . V . Bertin]

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 green light or more information how to proceed 
on 1 or 2 remaining issues.

On Wednesday February 1 2017 22:16:50 Ben Cooksley wrote:

> Reviewboard would still be running on the server - and all the issues that
> come with that.

So put it on an old or cheap/basic machine that runs no other services, or on a 
ditto virtual machine that runs in low priority?

R.

Re: Phabricator: All repositories registered - upcoming workflow changes

[René J . V . Bertin]

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 significant security risk 
could it pose?
I don't have the impression the software has been upgraded that frequently but 
I haven't been monitoring that either.

>I'd prefer to optimise our resources towards keeping what we are
>actively using in the best condition, rather than having to remain
>concerned with keeping legacy systems running for purely archival
>purposes.
>
>We have a significant amount of systems already (and associated
>technical debt in some instances). Let's not make the problem any
>worse please.

I guess it depends on the importance you attach on being able to retrieve 
things from revision and review histories. That's not to say it should be kept 
around online forever, but I'd say 2 years is a reasonable time to keep 
providing read-only access before archiving and taking everything offline for 
good.
I'd offer to help during that period but without any experience with the 
associated kind of sysadminship I'm not convinced that would be of much value.

I take it you investigated whether there is any existing way to transfer 
existing records from ReviewBoard to Phabricator? That would make the whole 
issue moot.

R.

Re: Phabricator: All repositories registered - upcoming workflow changes

[René J . V . Bertin]

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

Hmmm, I think one doesn't need to be logged in in order to consult and download 
things, correct? If so, disabling authentication is all that's needed to make 
the site read-only.

R.

Re: Phabricator: All repositories registered - upcoming workflow changes

[René J . V . Bertin]

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?
>Checking the history of a review can tell a lot. Also for discarded reviews.

I'd vote for that too, because

>> In most cases mailing lists should have the history of reviews in
>> their archives, so those will continue to be accessible through list
>> archives in the long run.

That is true for the reviews, but not for the patches themselves. In my 
experience you get at most the extract reviewers commented on, and that was 
usually only a single line.

It can also be very useful to look at older versions of reviews. That kind of 
history isn't available elsewhere, at least not without significant digging 
around.
What also doesn't help is the fact that the email notifications that are 
archived via mailing lists each contain a big part if not the entire 
review/comment history.

Keeping the website alive as a read-only resource also makes it possible to 
download patchfiles and other resources that were added to reviews (which are 
*not* available via mailing list archives).
And last but not least: knowing myself I'm quite likely (and surely not the 
only one) to forget transfering open reviews to Phabricator before the 
transition is supposed to be final. 

In fact, even if no one forgets a single outstanding RR until it's too late, 
are we supposed to copy all review comments, or are reviewers supposed to take 
to mailing list archives to consult the review history? Both options aren't 
really acceptable if you ask me so unless there's an automatic 
transfer+conversion process this seems like an important argument to keep the 
reviewboard site around.

R.

Re: Phabricator: All repositories registered - upcoming workflow changes

[René J . V . Bertin]

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 doesn't mean complete disconnect; it would probably be a 
loss of as-yet unknown importance if all code reviews become unavailable.

I'll miss ReviewBoard. Phabrithingy may be more powerful and versatile, but RB 
had its advantages too which could be why it's still being used (quite a lot, 
as far as I can see) and hasn't been integrated with KDE's own IDE yet.

R.

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

[René J . V . Bertin]

> 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 touches common/shared code at the moment, and I 
> am NOT building with `-DAPPLE_STANDALONE_BUILD`.
> 
> I *think* I should have most external dependencies installed for Words 
> and Sheets, so I'll be looking at building them in the near future, and 
> update this ticket accordingly.
> 
> I'm my point of view that's icing on the cake that can come after we've 
> reached feature parity with Linux. I can imagine others think different 
> (that's what Macs are for ;)). Hence this patch, it'll make it easier to 
> follow both approaches simultaneously.
> 
> René J.V. Bertin wrote:
> BTW: I do hope for some collaborative brainstorming w.r.t. using info 
> from KoResourcePaths.h more widely, instead of using QStandardPaths types 
> directly. That's a rather delicate intervention which I'd prefer not to take 
> the sole responsibility for.
> 
> René J.V. Bertin wrote:
> I can confirm Words works too with this patch.
> 
> (I did have to fix a small issue in the words-odf filter, I've taken the 
> liberty to push the fix: 
> https://cgit.kde.org/calligra.git/commit/?id=a8fd10d8b0a24e581eeb4754b458ba98ddbf0167)
> 
> René J.V. Bertin wrote:
> Sheets works nicely too!
> 
> Anthony Fieroni wrote:
> I response for only Karbon, wait for Camilla and Dag Andersen.
> 
> René J.V. Bertin wrote:
> Evidently.
> 
> Plan also works as far as I can tell (I never used it before).
> 
> There is an issue with `calligraplanwork` however, but given the error I 
> think it has nothing to do with my changes. If anything, I may have missed a 
> location where a change is required, for instance to install required DBus 
> service files.
> 
> Dag Andersen wrote:
> Afaics this should be ok.
> The defines in KoResourcePaths.h doesn't seem to be used?
> Can't comment on apple stuff, never seen one close up ;)
> 
> René J.V. Bertin wrote:
> > The defines in KoResourcePaths.h doesn't seem to be used?
> 
> No indeed. As I tried to explain in the description, they're more a 
> proposal:
> 
> > the change to KoResourcePathsImpl::mapTypeToQStandardPaths() only has a 
> real interest if it's used throughout the code to replace the explicit use of 
> QStandardPaths locations.
> > For now I have set this up through build-type specific preprocessor 
> macros in KoResourcePaths.h [...]
> 
> I don't want to start changing a huge amount of unknown code to use those 
> macros because there are lots of places that would have to be changed, and I 
> don't think it can be done by a few simple search-and-replace runs in an 
> editor. Above all, I want to be sure that you agree about this approach.
> 
> And let me repeat: this isn't necessary for the kind of build that 
> interests me on Mac, so there's no hurry as far as I'm concerned ;)
> 
> Dag Andersen wrote:
> Afaik KoResourcePaths is used in all calligra.
> There are issues and I have a patch waiting 
> (https://phabricator.kde.org/D2577) that didn't get into 3.0.
> It's fairly big so I'm waiting for 3.1 to look at it again.
> 
> Different thing: in KoApplication line 242 you added a comment:
> // add the paths that Krita5 sets in XDG_DATA_DIRS
> Krita is not using any calligra libs anymore, so this could possibly be 
> removed but I don't know if any other app depends on this, so...

> Afaik KoResourcePaths is used in all calligra.

True, but there are also many places where QStandardPaths locations are used 
directly. I don't know the code so cannot say if that's because they were never 
converted or because the current KoResourcePaths mapping function is too 
expensive. my rewrite should reduce the calling cost significantly but using 
preprocessor macros will of course be even cheaper but again, I don't know 
whether that cost is relevant.
Standardising (making sure the right locations are used) is a different topic 
altogether of course.

> // add the paths that Krita5 sets in XDG_DATA_DIRS
Krita is not using any calligra libs anymore, so this could possibly be removed 
but I don't know if any other app depends on this, so...

The point is not that Krita uses calligra libs (or not), but how it handles the 
QSP locations problem on MS Windows. It's been released for a while now so I 
presume it's seen more testing too, so adding the locations it defines should 
only help if anything.
OTOH I haven't tried to figure out if and how it actually uses the value of 
XDG_DATA_DIRS. From what I can tell that variable is used only by the 
Unix/Linux QStandardPaths, and it isn't read out anywhere in Calligra's code. 
But without a Windows dev system to verify this I cannot propose to 

Re: isn't it time for...

[René J . V . Bertin]

...
(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 things I haven't yet figured out in KDE, otherwise I'd 
probably be suggesting this via a RR...

R.

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

[René J . V . Bertin]

> 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 touches common/shared code at the moment, and I 
> am NOT building with `-DAPPLE_STANDALONE_BUILD`.
> 
> I *think* I should have most external dependencies installed for Words 
> and Sheets, so I'll be looking at building them in the near future, and 
> update this ticket accordingly.
> 
> I'm my point of view that's icing on the cake that can come after we've 
> reached feature parity with Linux. I can imagine others think different 
> (that's what Macs are for ;)). Hence this patch, it'll make it easier to 
> follow both approaches simultaneously.
> 
> René J.V. Bertin wrote:
> BTW: I do hope for some collaborative brainstorming w.r.t. using info 
> from KoResourcePaths.h more widely, instead of using QStandardPaths types 
> directly. That's a rather delicate intervention which I'd prefer not to take 
> the sole responsibility for.
> 
> René J.V. Bertin wrote:
> I can confirm Words works too with this patch.
> 
> (I did have to fix a small issue in the words-odf filter, I've taken the 
> liberty to push the fix: 
> https://cgit.kde.org/calligra.git/commit/?id=a8fd10d8b0a24e581eeb4754b458ba98ddbf0167)
> 
> René J.V. Bertin wrote:
> Sheets works nicely too!
> 
> Anthony Fieroni wrote:
> I response for only Karbon, wait for Camilla and Dag Andersen.
> 
> René J.V. Bertin wrote:
> Evidently.
> 
> Plan also works as far as I can tell (I never used it before).
> 
> There is an issue with `calligraplanwork` however, but given the error I 
> think it has nothing to do with my changes. If anything, I may have missed a 
> location where a change is required, for instance to install required DBus 
> service files.
> 
> Dag Andersen wrote:
> Afaics this should be ok.
> The defines in KoResourcePaths.h doesn't seem to be used?
> Can't comment on apple stuff, never seen one close up ;)

> The defines in KoResourcePaths.h doesn't seem to be used?

No indeed. As I tried to explain in the description, they're more a proposal:

> the change to KoResourcePathsImpl::mapTypeToQStandardPaths() only has a real 
> interest if it's used throughout the code to replace the explicit use of 
> QStandardPaths locations.
> For now I have set this up through build-type specific preprocessor macros in 
> KoResourcePaths.h [...]

I don't want to start changing a huge amount of unknown code to use those 
macros because there are lots of places that would have to be changed, and I 
don't think it can be done by a few simple search-and-replace runs in an 
editor. Above all, I want to be sure that you agree about this approach.

And let me repeat: this isn't necessary for the kind of build that interests me 
on Mac, so there's no hurry as far as I'm concerned ;)


- René J.V.


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


On Jan. 10, 2017, 5:34 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129800/
> ---
> 
> (Updated Jan. 10, 2017, 5:34 p.m.)
> 
> 
> Review request for Calligra and Camilla Boemann.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> This proposal is an initial implementation of things discussed on the ML a 
> short while back.
> 
> Building KF5 software on Mac as if on any Unix variant (with "Cocoa" instead 
> of X11) is possible and is what you get without specific changes to the build 
> system. With a few tweaks to Qt's QStandardPaths (provided by MacPorts) this 
> kind of build works flawlessly and with an identical feature set as on Linux 
> c.s.
> 
> NB: this build also puts applications in an app bundle "wrapper", but one 
> that contains just the minimal resources (executable, app icon and 
> Info.plist).
>  
> One can also tweak the build so that a relocatable and standalone app bundle 
> results which contains the application and all its 3rd-party dependencies 
> (Qt5, KF5 frameworks, etc.). This works with a stock Qt5 build but still 
> requires patches throughout KF5 code and build systems. Several projects 
> already provide "official" builds of this type for Mac: Kate, KDevelop, 
> Marble and Krita to name a few.
> 
> The current patch prepares for allowing a choice for either a standalone app 
> bundle build or a more traditional build via a CMake option 
> `APPLE_STANDALONE_BUNDLE` and preprocessor token of the same name. This makes 
> it easy to 

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

[René J . V . Bertin]

> 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 touches common/shared code at the moment, and I 
> am NOT building with `-DAPPLE_STANDALONE_BUILD`.
> 
> I *think* I should have most external dependencies installed for Words 
> and Sheets, so I'll be looking at building them in the near future, and 
> update this ticket accordingly.
> 
> I'm my point of view that's icing on the cake that can come after we've 
> reached feature parity with Linux. I can imagine others think different 
> (that's what Macs are for ;)). Hence this patch, it'll make it easier to 
> follow both approaches simultaneously.
> 
> René J.V. Bertin wrote:
> BTW: I do hope for some collaborative brainstorming w.r.t. using info 
> from KoResourcePaths.h more widely, instead of using QStandardPaths types 
> directly. That's a rather delicate intervention which I'd prefer not to take 
> the sole responsibility for.
> 
> René J.V. Bertin wrote:
> I can confirm Words works too with this patch.
> 
> (I did have to fix a small issue in the words-odf filter, I've taken the 
> liberty to push the fix: 
> https://cgit.kde.org/calligra.git/commit/?id=a8fd10d8b0a24e581eeb4754b458ba98ddbf0167)
> 
> René J.V. Bertin wrote:
> Sheets works nicely too!
> 
> Anthony Fieroni wrote:
> I response for only Karbon, wait for Camilla and Dag Andersen.

Evidently.

Plan also works as far as I can tell (I never used it before).

There is an issue with `calligraplanwork` however, but given the error I think 
it has nothing to do with my changes. If anything, I may have missed a location 
where a change is required, for instance to install required DBus service files.


- René J.V.


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


On Jan. 10, 2017, 5:34 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129800/
> ---
> 
> (Updated Jan. 10, 2017, 5:34 p.m.)
> 
> 
> Review request for Calligra and Camilla Boemann.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> This proposal is an initial implementation of things discussed on the ML a 
> short while back.
> 
> Building KF5 software on Mac as if on any Unix variant (with "Cocoa" instead 
> of X11) is possible and is what you get without specific changes to the build 
> system. With a few tweaks to Qt's QStandardPaths (provided by MacPorts) this 
> kind of build works flawlessly and with an identical feature set as on Linux 
> c.s.
> 
> NB: this build also puts applications in an app bundle "wrapper", but one 
> that contains just the minimal resources (executable, app icon and 
> Info.plist).
>  
> One can also tweak the build so that a relocatable and standalone app bundle 
> results which contains the application and all its 3rd-party dependencies 
> (Qt5, KF5 frameworks, etc.). This works with a stock Qt5 build but still 
> requires patches throughout KF5 code and build systems. Several projects 
> already provide "official" builds of this type for Mac: Kate, KDevelop, 
> Marble and Krita to name a few.
> 
> The current patch prepares for allowing a choice for either a standalone app 
> bundle build or a more traditional build via a CMake option 
> `APPLE_STANDALONE_BUNDLE` and preprocessor token of the same name. This makes 
> it easy to dissociate the Apple build types from general Apple build 
> requirements. Testing for build flavour is done by checking 
> `APPLE_STANDALONE_BUNDLE`, testing for build platform by checking `APPLE` 
> (CMake) or `Q_OS_MACOS` (Qt/C++) (or `__APPLE__` in code not using Qt).
> 
> In addition to the introduction of the CMake option, the patch
> 
> - updates `KoApplication::start()`. Judging from Kate's approach it shouldnt' 
> be necessary on Mac to set `XDG_DATA_DIRS`, which isn't used anywhere in code 
> (except in MacPorts tweaked QStandardPaths!). The `PATH` env. variable also 
> shouldn't be *re*set and only needs changing (potentially!) in a standalone 
> app bundle build. I don't have a MS Windows dev. system so I've merged 
> Krita's way of setting `XDG_DATA_DIRS` with Calligra's current code. Note 
> that Qt/Win also doesn't seem to use that variable in `QStandardPaths`.
> - rewrites `KoResourcePathsImpl::mapTypeToQStandardPaths()` to use a much 
> more efficient static `QHash` table. *A priori* it should be possible to use 
> `QStandardPaths::AppDataLocation` to obtain the location of the app bundle 

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

[René J . V . Bertin]

---
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 Software on Mac OS X.


Changes
---

Give calligraworkplan an app icon too.


Repository: calligra


Description
---

Hinted at in my previous RR: this patch concern the generation of app icons on 
Mac and potentially on MS Windows.

Several points:

- The `iconutils` utility is limited or incorrectly invoked by 
`ecm_add_app_icon`, leading to errors on OS X 10.9 when using PNG files larger 
than 256x256px . 
- `ecm_add_app_icon` takes care of copying the icon (.icns) file into the app 
bundle; no need to install it explicitly
- a recent change I committed to the ECM allows `ecm_add_app_icon` to accept an 
SVG (or SVGz) file, and will create the app icon using that file if the 
`ksvg2icns` utility is available (provided by KIconThemes so it should always 
be available).

I hope that this modification will be released with ECM 5.30.0 . The ECM being 
what they are there should be no issue requiring its latest version, but the 
changes in the present patch will be transparent with older ECM versions 
(except for warnings about ignoring unsupported icon source files).

There is an equivalent `svg2ico` utility in the KDEWin project which also 
provides a `png2ico` implementation. I plan to propose an updated version for 
inclusion with KIconThemes. That would allow feature parity for 
`ecm_add_app_icon` on MSWin, but I would need someone else to test it (I don't 
have a MSWin dev system).


Diffs (updated)
-

  braindump/src/CMakeLists.txt 95e0772 
  flow/part/CMakeLists.txt f5d0893 
  gemini/CMakeLists.txt c8713d6 
  karbon/CMakeLists.txt ba775ad 
  plan/CMakeLists.txt 25427da 
  plan/workpackage/CMakeLists.txt ec50d6d 
  sheets/CMakeLists.txt 0256de5 
  stage/app/CMakeLists.txt b5b4464 
  words/app/CMakeLists.txt 8cf0157 

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


Testing
---

tested on Mac and Linux with Qt 5.7.1 and FWs 5.29.0 , currently only for 
Karbon and Words.


Thanks,

René J.V. Bertin

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

[René J . V . Bertin]

> 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 touches common/shared code at the moment, and I 
> am NOT building with `-DAPPLE_STANDALONE_BUILD`.
> 
> I *think* I should have most external dependencies installed for Words 
> and Sheets, so I'll be looking at building them in the near future, and 
> update this ticket accordingly.
> 
> I'm my point of view that's icing on the cake that can come after we've 
> reached feature parity with Linux. I can imagine others think different 
> (that's what Macs are for ;)). Hence this patch, it'll make it easier to 
> follow both approaches simultaneously.
> 
> René J.V. Bertin wrote:
> BTW: I do hope for some collaborative brainstorming w.r.t. using info 
> from KoResourcePaths.h more widely, instead of using QStandardPaths types 
> directly. That's a rather delicate intervention which I'd prefer not to take 
> the sole responsibility for.
> 
> René J.V. Bertin wrote:
> I can confirm Words works too with this patch.
> 
> (I did have to fix a small issue in the words-odf filter, I've taken the 
> liberty to push the fix: 
> https://cgit.kde.org/calligra.git/commit/?id=a8fd10d8b0a24e581eeb4754b458ba98ddbf0167)

Sheets works nicely too!


- René J.V.


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


On Jan. 10, 2017, 5:34 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129800/
> ---
> 
> (Updated Jan. 10, 2017, 5:34 p.m.)
> 
> 
> Review request for Calligra and Camilla Boemann.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> This proposal is an initial implementation of things discussed on the ML a 
> short while back.
> 
> Building KF5 software on Mac as if on any Unix variant (with "Cocoa" instead 
> of X11) is possible and is what you get without specific changes to the build 
> system. With a few tweaks to Qt's QStandardPaths (provided by MacPorts) this 
> kind of build works flawlessly and with an identical feature set as on Linux 
> c.s.
> 
> NB: this build also puts applications in an app bundle "wrapper", but one 
> that contains just the minimal resources (executable, app icon and 
> Info.plist).
>  
> One can also tweak the build so that a relocatable and standalone app bundle 
> results which contains the application and all its 3rd-party dependencies 
> (Qt5, KF5 frameworks, etc.). This works with a stock Qt5 build but still 
> requires patches throughout KF5 code and build systems. Several projects 
> already provide "official" builds of this type for Mac: Kate, KDevelop, 
> Marble and Krita to name a few.
> 
> The current patch prepares for allowing a choice for either a standalone app 
> bundle build or a more traditional build via a CMake option 
> `APPLE_STANDALONE_BUNDLE` and preprocessor token of the same name. This makes 
> it easy to dissociate the Apple build types from general Apple build 
> requirements. Testing for build flavour is done by checking 
> `APPLE_STANDALONE_BUNDLE`, testing for build platform by checking `APPLE` 
> (CMake) or `Q_OS_MACOS` (Qt/C++) (or `__APPLE__` in code not using Qt).
> 
> In addition to the introduction of the CMake option, the patch
> 
> - updates `KoApplication::start()`. Judging from Kate's approach it shouldnt' 
> be necessary on Mac to set `XDG_DATA_DIRS`, which isn't used anywhere in code 
> (except in MacPorts tweaked QStandardPaths!). The `PATH` env. variable also 
> shouldn't be *re*set and only needs changing (potentially!) in a standalone 
> app bundle build. I don't have a MS Windows dev. system so I've merged 
> Krita's way of setting `XDG_DATA_DIRS` with Calligra's current code. Note 
> that Qt/Win also doesn't seem to use that variable in `QStandardPaths`.
> - rewrites `KoResourcePathsImpl::mapTypeToQStandardPaths()` to use a much 
> more efficient static `QHash` table. *A priori* it should be possible to use 
> `QStandardPaths::AppDataLocation` to obtain the location of the app bundle 
> resources directory; it could be populated with symlinks into 
> `/path/to/foo.app/Contents/share` so resources can be found with minimum 
> changes to the build system (install locations). This will need to be 
> established going forward (knowing that my own main interest is with "linuxy 
> builds").
> - the change to `KoResourcePathsImpl::mapTypeToQStandardPaths()` only has a 
> real interest if it's used throughout the code instead of 

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

[René J . V . Bertin]

> 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 touches common/shared code at the moment, and I 
> am NOT building with `-DAPPLE_STANDALONE_BUILD`.
> 
> I *think* I should have most external dependencies installed for Words 
> and Sheets, so I'll be looking at building them in the near future, and 
> update this ticket accordingly.
> 
> I'm my point of view that's icing on the cake that can come after we've 
> reached feature parity with Linux. I can imagine others think different 
> (that's what Macs are for ;)). Hence this patch, it'll make it easier to 
> follow both approaches simultaneously.
> 
> René J.V. Bertin wrote:
> BTW: I do hope for some collaborative brainstorming w.r.t. using info 
> from KoResourcePaths.h more widely, instead of using QStandardPaths types 
> directly. That's a rather delicate intervention which I'd prefer not to take 
> the sole responsibility for.

I can confirm Words works too with this patch.

(I did have to fix a small issue in the words-odf filter, I've taken the 
liberty to push the fix: 
https://cgit.kde.org/calligra.git/commit/?id=a8fd10d8b0a24e581eeb4754b458ba98ddbf0167)


- René J.V.


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


On Jan. 10, 2017, 5:34 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129800/
> ---
> 
> (Updated Jan. 10, 2017, 5:34 p.m.)
> 
> 
> Review request for Calligra and Camilla Boemann.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> This proposal is an initial implementation of things discussed on the ML a 
> short while back.
> 
> Building KF5 software on Mac as if on any Unix variant (with "Cocoa" instead 
> of X11) is possible and is what you get without specific changes to the build 
> system. With a few tweaks to Qt's QStandardPaths (provided by MacPorts) this 
> kind of build works flawlessly and with an identical feature set as on Linux 
> c.s.
> 
> NB: this build also puts applications in an app bundle "wrapper", but one 
> that contains just the minimal resources (executable, app icon and 
> Info.plist).
>  
> One can also tweak the build so that a relocatable and standalone app bundle 
> results which contains the application and all its 3rd-party dependencies 
> (Qt5, KF5 frameworks, etc.). This works with a stock Qt5 build but still 
> requires patches throughout KF5 code and build systems. Several projects 
> already provide "official" builds of this type for Mac: Kate, KDevelop, 
> Marble and Krita to name a few.
> 
> The current patch prepares for allowing a choice for either a standalone app 
> bundle build or a more traditional build via a CMake option 
> `APPLE_STANDALONE_BUNDLE` and preprocessor token of the same name. This makes 
> it easy to dissociate the Apple build types from general Apple build 
> requirements. Testing for build flavour is done by checking 
> `APPLE_STANDALONE_BUNDLE`, testing for build platform by checking `APPLE` 
> (CMake) or `Q_OS_MACOS` (Qt/C++) (or `__APPLE__` in code not using Qt).
> 
> In addition to the introduction of the CMake option, the patch
> 
> - updates `KoApplication::start()`. Judging from Kate's approach it shouldnt' 
> be necessary on Mac to set `XDG_DATA_DIRS`, which isn't used anywhere in code 
> (except in MacPorts tweaked QStandardPaths!). The `PATH` env. variable also 
> shouldn't be *re*set and only needs changing (potentially!) in a standalone 
> app bundle build. I don't have a MS Windows dev. system so I've merged 
> Krita's way of setting `XDG_DATA_DIRS` with Calligra's current code. Note 
> that Qt/Win also doesn't seem to use that variable in `QStandardPaths`.
> - rewrites `KoResourcePathsImpl::mapTypeToQStandardPaths()` to use a much 
> more efficient static `QHash` table. *A priori* it should be possible to use 
> `QStandardPaths::AppDataLocation` to obtain the location of the app bundle 
> resources directory; it could be populated with symlinks into 
> `/path/to/foo.app/Contents/share` so resources can be found with minimum 
> changes to the build system (install locations). This will need to be 
> established going forward (knowing that my own main interest is with "linuxy 
> builds").
> - the change to `KoResourcePathsImpl::mapTypeToQStandardPaths()` only has a 
> real interest if it's used throughout the code instead of explicit use of 
> QStandardPaths locations. For now I have set this up through 

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

[René J . V . Bertin]

> 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 later that I could just 
as well pretend SVG support also already works on MS Windows. Like this it will 
as soon as `ecm_add_app_icon` can handle SVG files on MS Windows.


- René J.V.


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


On Jan. 11, 2017, 4:30 p.m., René J.V. Bertin wrote:
> 
> ---
> 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 and KDE Software on Mac OS X.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> Hinted at in my previous RR: this patch concern the generation of app icons 
> on Mac and potentially on MS Windows.
> 
> Several points:
> 
> - The `iconutils` utility is limited or incorrectly invoked by 
> `ecm_add_app_icon`, leading to errors on OS X 10.9 when using PNG files 
> larger than 256x256px . 
> - `ecm_add_app_icon` takes care of copying the icon (.icns) file into the app 
> bundle; no need to install it explicitly
> - a recent change I committed to the ECM allows `ecm_add_app_icon` to accept 
> an SVG (or SVGz) file, and will create the app icon using that file if the 
> `ksvg2icns` utility is available (provided by KIconThemes so it should always 
> be available).
> 
> I hope that this modification will be released with ECM 5.30.0 . The ECM 
> being what they are there should be no issue requiring its latest version, 
> but the changes in the present patch will be transparent with older ECM 
> versions (except for warnings about ignoring unsupported icon source files).
> 
> There is an equivalent `svg2ico` utility in the KDEWin project which also 
> provides a `png2ico` implementation. I plan to propose an updated version for 
> inclusion with KIconThemes. That would allow feature parity for 
> `ecm_add_app_icon` on MSWin, but I would need someone else to test it (I 
> don't have a MSWin dev system).
> 
> 
> Diffs
> -
> 
>   braindump/src/CMakeLists.txt 95e0772 
>   flow/part/CMakeLists.txt f5d0893 
>   gemini/CMakeLists.txt c8713d6 
>   karbon/CMakeLists.txt ba775ad 
>   plan/CMakeLists.txt 25427da 
>   sheets/CMakeLists.txt 0256de5 
>   stage/app/CMakeLists.txt b5b4464 
>   words/app/CMakeLists.txt 8cf0157 
> 
> Diff: https://git.reviewboard.kde.org/r/129804/diff/
> 
> 
> Testing
> ---
> 
> tested on Mac and Linux with Qt 5.7.1 and FWs 5.29.0 , currently only for 
> Karbon and Words.
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

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

[René J . V . Bertin]

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


Changes
---

Added a note about MSWin


Repository: calligra


Description (updated)
---

Hinted at in my previous RR: this patch concern the generation of app icons on 
Mac and potentially on MS Windows.

Several points:

- The `iconutils` utility is limited or incorrectly invoked by 
`ecm_add_app_icon`, leading to errors on OS X 10.9 when using PNG files larger 
than 256x256px . 
- `ecm_add_app_icon` takes care of copying the icon (.icns) file into the app 
bundle; no need to install it explicitly
- a recent change I committed to the ECM allows `ecm_add_app_icon` to accept an 
SVG (or SVGz) file, and will create the app icon using that file if the 
`ksvg2icns` utility is available (provided by KIconThemes so it should always 
be available).

I hope that this modification will be released with ECM 5.30.0 . The ECM being 
what they are there should be no issue requiring its latest version, but the 
changes in the present patch will be transparent with older ECM versions 
(except for warnings about ignoring unsupported icon source files).

There is an equivalent `svg2ico` utility in the KDEWin project which also 
provides a `png2ico` implementation. I plan to propose an updated version for 
inclusion with KIconThemes. That would allow feature parity for 
`ecm_add_app_icon` on MSWin, but I would need someone else to test it (I don't 
have a MSWin dev system).


Diffs
-

  braindump/src/CMakeLists.txt 95e0772 
  flow/part/CMakeLists.txt f5d0893 
  gemini/CMakeLists.txt c8713d6 
  karbon/CMakeLists.txt ba775ad 
  plan/CMakeLists.txt 25427da 
  sheets/CMakeLists.txt 0256de5 
  stage/app/CMakeLists.txt b5b4464 
  words/app/CMakeLists.txt 8cf0157 

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


Testing
---

tested on Mac and Linux with Qt 5.7.1 and FWs 5.29.0 , currently only for 
Karbon and Words.


Thanks,

René J.V. Bertin

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

[René J . V . Bertin]

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

Review request for Calligra.


Repository: calligra


Description
---

Hinted at in my previous RR: this patch concern the generation of app icons on 
Mac and potentially on MS Windows.

Several points:

- The `iconutils` utility is limited or incorrectly invoked by 
`ecm_add_app_icon`, leading to errors on OS X 10.9 when using PNG files larger 
than 256x256px . 
- `ecm_add_app_icon` takes care of copying the icon (.icns) file into the app 
bundle; no need to install it explicitly
- a recent change I committed to the ECM allows `ecm_add_app_icon` to accept an 
SVG (or SVGz) file, and will create the app icon using that file if the 
`ksvg2icns` utility is available (provided by KIconThemes so it should always 
be available).

I hope that this modification will be released with ECM 5.30.0 . The ECM being 
what they are there should be no issue requiring its latest version, but the 
changes in the present patch will be transparent with older ECM versions 
(except for warnings about ignoring unsupported icon source files).


Diffs
-

  braindump/src/CMakeLists.txt 95e0772 
  flow/part/CMakeLists.txt f5d0893 
  gemini/CMakeLists.txt c8713d6 
  karbon/CMakeLists.txt ba775ad 
  plan/CMakeLists.txt 25427da 
  sheets/CMakeLists.txt 0256de5 
  stage/app/CMakeLists.txt b5b4464 
  words/app/CMakeLists.txt 8cf0157 

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


Testing
---

tested on Mac and Linux with Qt 5.7.1 and FWs 5.29.0 , currently only for 
Karbon and Words.


Thanks,

René J.V. Bertin

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

[René J . V . Bertin]

> 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, and I am NOT 
building with `-DAPPLE_STANDALONE_BUILD`.

I *think* I should have most external dependencies installed for Words and 
Sheets, so I'll be looking at building them in the near future, and update this 
ticket accordingly.

I'm my point of view that's icing on the cake that can come after we've reached 
feature parity with Linux. I can imagine others think different (that's what 
Macs are for ;)). Hence this patch, it'll make it easier to follow both 
approaches simultaneously.


- René J.V.


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


On Jan. 10, 2017, 5:34 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129800/
> ---
> 
> (Updated Jan. 10, 2017, 5:34 p.m.)
> 
> 
> Review request for Calligra and Camilla Boemann.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> This proposal is an initial implementation of things discussed on the ML a 
> short while back.
> 
> Building KF5 software on Mac as if on any Unix variant (with "Cocoa" instead 
> of X11) is possible and is what you get without specific changes to the build 
> system. With a few tweaks to Qt's QStandardPaths (provided by MacPorts) this 
> kind of build works flawlessly and with an identical feature set as on Linux 
> c.s.
> 
> NB: this build also puts applications in an app bundle "wrapper", but one 
> that contains just the minimal resources (executable, app icon and 
> Info.plist).
>  
> One can also tweak the build so that a relocatable and standalone app bundle 
> results which contains the application and all its 3rd-party dependencies 
> (Qt5, KF5 frameworks, etc.). This works with a stock Qt5 build but still 
> requires patches throughout KF5 code and build systems. Several projects 
> already provide "official" builds of this type for Mac: Kate, KDevelop, 
> Marble and Krita to name a few.
> 
> The current patch prepares for allowing a choice for either a standalone app 
> bundle build or a more traditional build via a CMake option 
> `APPLE_STANDALONE_BUNDLE` and preprocessor token of the same name. This makes 
> it easy to dissociate the Apple build types from general Apple build 
> requirements. Testing for build flavour is done by checking 
> `APPLE_STANDALONE_BUNDLE`, testing for build platform by checking `APPLE` 
> (CMake) or `Q_OS_MACOS` (Qt/C++) (or `__APPLE__` in code not using Qt).
> 
> In addition to the introduction of the CMake option, the patch
> 
> - updates `KoApplication::start()`. Judging from Kate's approach it shouldnt' 
> be necessary on Mac to set `XDG_DATA_DIRS`, which isn't used anywhere in code 
> (except in MacPorts tweaked QStandardPaths!). The `PATH` env. variable also 
> shouldn't be *re*set and only needs changing (potentially!) in a standalone 
> app bundle build. I don't have a MS Windows dev. system so I've merged 
> Krita's way of setting `XDG_DATA_DIRS` with Calligra's current code. Note 
> that Qt/Win also doesn't seem to use that variable in `QStandardPaths`.
> - rewrites `KoResourcePathsImpl::mapTypeToQStandardPaths()` to use a much 
> more efficient static `QHash` table. *A priori* it should be possible to use 
> `QStandardPaths::AppDataLocation` to obtain the location of the app bundle 
> resources directory; it could be populated with symlinks into 
> `/path/to/foo.app/Contents/share` so resources can be found with minimum 
> changes to the build system (install locations). This will need to be 
> established going forward (knowing that my own main interest is with "linuxy 
> builds").
> - the change to `KoResourcePathsImpl::mapTypeToQStandardPaths()` only has a 
> real interest if it's used throughout the code instead of explicit use of 
> QStandardPaths locations. For now I have set this up through build-type 
> specific preprocessor macros in KoResourcePaths.h (because an enum would 
> probably have to be cast to work with the QSP methods). I haven't changed any 
> code to use those macros.
> 
> Not yet incorporated: tweaks to the `ecm_add_app_icon` calls to use its new 
> capability to generate an app icon from an SVG file (currently tested with 
> Karbon).
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt 13ac88f 
>   libs/main/KoApplication.cpp 7b23f8d 
>   libs/widgets/KoResourcePaths.h 8830a5a 
>   libs/widgets/KoResourcePaths.cpp 7df9dc6 
> 
> Diff: 

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

[René J . V . Bertin]

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

Review request for Calligra.


Repository: calligra


Description
---

This proposal is an initial implementation of things discussed on the ML a 
short while back.

Building KF5 software on Mac as if on any Unix variant (with "Cocoa" instead of 
X11) is possible and is what you get without specific changes to the build 
system. With a few tweaks to Qt's QStandardPaths (provided by MacPorts) this 
kind of build works flawlessly and with an identical feature set as on Linux 
c.s.

NB: this build also puts applications in an app bundle "wrapper", but one that 
contains just the minimal resources (executable, app icon and Info.plist).
 
One can also tweak the build so that a relocatable and standalone app bundle 
results which contains the application and all its 3rd-party dependencies (Qt5, 
KF5 frameworks, etc.). This works with a stock Qt5 build but still requires 
patches throughout KF5 code and build systems. Several projects already provide 
"official" builds of this type for Mac: Kate, KDevelop, Marble and Krita to 
name a few.

The current patch prepares for allowing a choice for either a standalone app 
bundle build or a more traditional build via a CMake option 
`APPLE_STANDALONE_BUNDLE` and preprocessor token of the same name. This makes 
it easy to dissociate the Apple build types from general Apple build 
requirements. Testing for build flavour is done by checking 
`APPLE_STANDALONE_BUNDLE`, testing for build platform by checking `APPLE` 
(CMake) or `Q_OS_MACOS` (Qt/C++) (or `__APPLE__` in code not using Qt).

In addition to the introduction of the CMake option, the patch

- updates `KoApplication::start()`. Judging from Kate's approach it shouldnt' 
be necessary on Mac to set `XDG_DATA_DIRS`, which isn't used anywhere in code 
(except in MacPorts tweaked QStandardPaths!). The `PATH` env. variable also 
shouldn't be *re*set and only needs changing (potentially!) in a standalone app 
bundle build. I don't have a MS Windows dev. system so I've merged Krita's way 
of setting `XDG_DATA_DIRS` with Calligra's current code. Note that Qt/Win also 
doesn't seem to use that variable in `QStandardPaths`.
- rewrites `KoResourcePathsImpl::mapTypeToQStandardPaths()` to use a much more 
efficient static `QHash` table. *A priori* it should be possible to use 
`QStandardPaths::AppDataLocation` to obtain the location of the app bundle 
resources directory; it could be populated with symlinks into 
`/path/to/foo.app/Contents/share` so resources can be found with minimum 
changes to the build system (install locations). This will need to be 
established going forward (knowing that my own main interest is with "linuxy 
builds").
- the change to `KoResourcePathsImpl::mapTypeToQStandardPaths()` only has a 
real interest if it's used throughout the code instead of explicit use of 
QStandardPaths locations. For now I have set this up through build-type 
specific preprocessor macros in KoResourcePaths.h (because an enum would 
probably have to be cast to work with the QSP methods). I haven't changed any 
code to use those macros.

Not yet incorporated: tweaks to the `ecm_add_app_icon` calls to use its new 
capability to generate an app icon from an SVG file (currently tested with 
Karbon).


Diffs
-

  CMakeLists.txt 13ac88f 
  libs/main/KoApplication.cpp 7b23f8d 
  libs/widgets/KoResourcePaths.h 8830a5a 
  libs/widgets/KoResourcePaths.cpp 7df9dc6 

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


Testing
---

Karbon works as expected with this patch on Mac OS X 10.9.5 (and Linux) with Qt 
5.7.1 and KF5 5.29.0 installed under /opt/local . 

Without the patch Karbon crashes or aborts immediately on Mac because it 
doesn't find a single resource in the locations indicated by the inappropriate 
`XDG_DATA_DIRS` value.


Thanks,

René J.V. Bertin

Karbon and import from Illustrator

[René J . V . Bertin]

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 this works on Mac but not in the equivalent build I did on Linux.

As far as I've been able to determine from the sources there is only a filter 
for exporting to .ai . Could it be somehow that the mimetype is reported 
differently on Mac, despite the fact I'm using the same shared-mime-info 
install?

Either way, I can confirm that import of all .ai documents I tried until now 
worked fine on both platforms, "as is" on Mac, and on Linux after tricking 
Karbon by changing the extension to .eps or .pdf . The document information 
dialog shows the same icon (PDF) for both approaches btw.

NB: these are documents made with Illustrator CS, the first from the Creative 
Suite series (Illustrator 7.0 if I remember correctly). I always made a point 
to save my work in PDF compatibility mode so I could use a PDF viewer for quick 
visualisation, but AFAIK the .ai format was always EPS with the additional info 
stored in comments.

In other words, it should be straightforward to support a basic form of import:

- using the PDF filter if the file is actually PDF (mine have "%PDF-1.4" as the 
first few bytes in the file)
- using the EPS importer otherwise.

Or the other way round if that allows preserving more editing information.

I'd appreciate feedback and hints helping me find the correct locations in the 
source pile (or how to "do this right TM").

Thanks,
R.

Re: Version stuff in CMakeLists.txt

[René J . V . Bertin]

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 can't see
>what 3.0.89 actually means as it will crop up for every new 3.0 release.
>Is it just me being confused, or...

No, that's something that's been confusing me in other projects too. 

FWIW, KDevelop 5.1 will be released soon, up from 5.0.3 . Their current version 
(in CMakeLists.txt and the git tag) is 5.0.80. Who knows, maybe that'll become 
5.0.99 for the gold release candidate whatever version.

So what would be wrong with 3.0.0.89? Conveys clearly enough the message that 
it's not just a patch release, and that it's closer to 3.0.1 than to 3.0.0 .

R.

Re: map support, Marble and Mac

[René J . V . Bertin]

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 
kexi-devel ML. I wasn't aware of its existence, BTW.

R.

Re: packaging Calligra: common dependencies?

[René J . V . Bertin]

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

That also means that you'll end up with lots of conflicting (= already 
installed) items if you build, say, Words and Sheets separately?

The problem is that there's a *lot* to prune, and it becomes increasingly 
tricky to do this correctly when you start adding packages.

R.

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

[René J . V . Bertin]

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)

[René J . V . Bertin]

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.

> Is this just about file name clashes?

Yes, files installed by more than 1 project. Not an issue if you install from 
source, but once you start packaging it becomes a problem.

R

Re: Kexi/Mac

[René J . V . Bertin]

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 add an
>alternative.

I didn't deactivate anything to force a particular applications style, so I'm 
not sure which enforcement of widget style you're hinting at. For Breeze I just 
deactivate the check in the toplevel CMake file because the packaging system 
ensures that the icon theme is present.

Do note that all this probably won't work with an unpatched Qt where 
QStandardPaths returns very different locations and icon themes can only be 
installed as an embedded resource. For application styles it's even more 
difficult: if you want the full theming including fonts and colour palettes you 
need to provide your own platform theme plugin (basically, the KDE platform 
theme plugin from plasma-integration, or rather the Mac-specific version from 
my osx-integration "scratch" repo).

>Unless these contributions are here I am a bit afraid we're risking
>inconsistencies between platforms and inferior experience on Mac (no docs,
>incomplete icon theme or styles).

You must have misunderstood something: the experience *is* inferior on Mac ATM, 
with a stock Qt and without jumping through a certain number of hoops. It would 
be much easier and in line with consensus among KDE devs to ensure that Kexi 
works with the Macintosh native theme. Using Breeze icons with that isn't an 
issue of course; there are even instructions on creating the required 
embeddable resource (by Kate's author, Christoph Cullmann).

Those instructions might even be useful to figure out how to create the 
icons.rcc resource during Kexi's build (and then to be installed as a 
Kexi-specific resource), I think that would be a more elegant and cleaner 
approach than depending on the resource's presence.

>I'm sorry if this conservative talk sounds like raising a bar.

I don't mind. I really don't like Breeze (theme nor style), but as long as I 
don't have any use for Kexi personally (currently a simple fact) I'm much less 
concerned by choices that affect the interface appearance than I would be with, 
say, KDevelop or digiKam. 

I may have a bit of time this week to look at the file dialog question.

About that: Kexi just finished building on my Linux rig, and I get a very 
similar issue when I use the import wizard to import a database and then open 
the dialog configure drop-down menu. With the QtCurve menu the mouse and 
keyboard are grabbed, meaning I have to use a remote connection (or a timed 
kill command) to get out of the ensuing deadlock. This doesn't happen in any 
other application, so something fishy is going on here. (Evidently there's no 
mouse or keyboard grab on Mac, not in the X11 sense in any case).

R.

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

[René J . V . Bertin]

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

[René J . V . Bertin]

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 minor patches (building and installing the app icon, 
building the handbook) but there's need for more work: the interface is 
completely messed up when using the native Macintosh widget style.

This *may* be the kind of glitch that made KCalc unusable with the native style.

https://bugs.kde.org/show_bug.cgi?id=374177


Additionally there's an issue with the file dialog; the menu for choosing the 
sorting and display mode opens but doesn't work, and drop-down completion lists 
appear in the background. These features work in other KF5 applications.

Maybe Kexi shouldn't try to impose the Breeze iconset on Mac?

R.

Re: map support, Marble and Mac

[René J . V . Bertin]

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 test altogether. This prevents linking 
opportunistically. A user might have a dependency like Marble available because 
s/he had just been playing with it, but might now want to link against it, in 
order to be able to uninstall Marble (or whatever dependency) freely. There are 
CMake macros that make it very easy to provide a configure switch which is on 
by default.

Re. the packaging: systems like MacPorts usually want to do reproducible 
builds, where you get the same result on a build bot that makes the binary 
distribution images doing every build from scratch, and on a user's machine 
that may have all kinds of things already installed.

> But your request is more to Marble team. If something need to be improved
> with OSX support (and Windows to bundle application), this must be done in
> Marble, not in client applications.

I also have a request for them, sure. But whether or not dependent projects 
provide a configure-time switch to depend or not to depend is not up to the 
Marble team to decide.

Although their .cmake module could of course provide a switch, but that 
wouldn't be very usual :)

R.

Re: map support, Marble and Mac

[René J . V . Bertin]

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).
>https://frinring.wordpress.com/2016/12/15/marble-in-your-cmake-or-qmake-based-project-now-more-easy/

I don't see anything about OS X or MS Windows on that page and in fact the 
remark that this was already possible since 16.08 makes me a bit suspicious. My 
current MacPorts package provides Marble from 16.08.2, and I this is the patch 
to make it build for shared & shareable resources:

https://github.com/RJVB/macstrop/blob/master/kf5/kf5-marble/files/patch-build-for-macports-16082.diff

The principle is simple: unlink the installation mode from the platform tokens, 
and introduce an option with a default value that does depend on a platform 
token. Hardly more difficult to maintain, it just requires the goodwill to ask 
oneself if a new Mac-specific addition is purely related to the installation 
mode or to the platform. 

I'll admit that I didn't even try to build it in stock version, but making a 
standalone and thus *relocatable* Marble app bundle is by definition 
incompatible with sharing libMarble.

My bad btw: I updated the RR on ReviewBoard once but forgot it was supposed to 
go on Phabricator... Guess that means I'll have to give it another try ...

R.

map support, Marble and Mac

[René J . V . Bertin]

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 try very (too) 
hard to be as Mac-like as possible when built on Mac, and has a build system 
that forces a standalone (= all-inclusive) app bundle on that platform. This 
means that the Marble library cannot be found and most likely not even be 
shared with other applications.

It's not impossible to patch the build system to provide choice during the 
Marble build, and this is what I've done a couple of times to create a proper 
MacPorts package, where Marble's shared resources go into their traditional 
designated locations. I've put that patch up for review, but have had no 
feedback on it at all. As a result of that lack of interest for being able to 
use the Marble library in other apps (on Mac), and also because the patch 
requires refactoring at almost every update I am considering seriously to drop 
the port.

Cheers,
René

PS: Google Earth can be driven by external apps IIRC, and it's even possible to 
open Google Maps in a browser with a set of GPS co-ordinates. Maybe it wouldn't 
be too hard to use that in a fallback plugin?

Qt5 components found but not Qt5 itself?!

[René J . V . Bertin]

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
>  * Qt5Network
>  * Qt5PrintSupport
>  * Qt5Svg
>  * Qt5Test

>  * Qt5Quick

>  * Qt5Xml
>  * Qt5Widgets
>  * Qt5WebKitWidgets

> -- The following REQUIRED packages have not been found:
>  * Qt5 (required version >= 5.3.0)

That doesn't make much sense, does it? 

Thanks,
R.

packaging Calligra: common dependencies?

[René J . V . Bertin]

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 subset of components. 
That's great because with the MacPorts approach the build and packaging steps 
are linked, meaning it's not possible to build everything once and then 
generate packages for individual components.

But support I build and package LIB_CALLIGRA, LIB_KOMAIN and family on their 
own, how does this work out when building say Karbon or Kexi? Will the build 
system pick up the fact that the required dependencies are already installed, 
is their a way to instruct CMake that this is the case, or will I have to prune 
everything already installed from the package (during the "post-destroot", in 
MacPorts speak)?

The Calligra 2.9 port I made used a different approach with different 
installation variants corresponding to different product sets. This time I'd 
like to make it possible for users to decide exactly which of the supported 
applications they install or uninstall independently. That will also make it 
easier for me to concentrate on the different applications in turn without 
having to uninstall everything when I start adding support for a new Calligra 
application.

Thanks,
R.

Re: calligra 3.0.0 tarball

[René J . V . Bertin]

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

[René J . V . Bertin]

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 that's great news! I'll try to follow this, and as soon as 
there's some stability (I think I heard about a 3.1 series?) I'll start looking 
into bring this and other Calligra components into my MacPorts KF5 tree so they 
can be tested on Mac too.

R.

Re: "non standalone app bundle" builds on Mac

[René J . V . Bertin]

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 support. There'd an awful lot of changes to make, and there are 
other ways to get around the issue without changing code and which would limit 
the compiler command length. This is something that concerns only the building 
step, and I guess it wouldn't shock anyone if building cross-platform apps 
isn't as native as building native apps, no matter how natively the result 
looks and behaves :)

R.

Re: "non standalone app bundle" builds on Mac

[René J . V . Bertin]

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 and related tools because a
> point  is that the header is _silently_ found even if you're not

No, I don't think you can say that. Support for this (and frameworks bundles) 
has even made it into gcc (on Linux too); I doubt that would have happened if 
there were anything wrong with the principle.

I'm fairly certain that Qt also use the  notation in their code and 
examples (#include ).

I see your point about protection, but it's simple enough to avoid that. How 
can you pick up the wrong Foo/Foo headers but pick the right corresponding 
libFoo or Foo.framework, or vice versa? If that happens there's something wrong 
with your install.

The KF5 framework headers all live under ${prefix}/include/KF5, meaning that 
even with a  notation you still have to point the compiler to the 
appropriate parent directory.

As a bonus you do not end up with endless compiler command lines on which you 
can no longer find relevant information (or which might even lead to issues 
when they become too long).

> you, you get much nicer preprocessor error if you missed certain entry in
> target_link_libraries().

I don't think the preprocessor cares what cmake did or didn't do :)

R.

Re: "non standalone app bundle" builds on Mac

[René J . V . Bertin]

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
> multi-generator so it adds so much extra work since it's different than the
> Makefiles gen. For now I have not checked if the current xCode generator is
> as complex in use as the VS in this regard. Thoughts?

I have no idea how it compares to the VS generator. It's been improved recently 
and I've checked a few projects, but haven't gone much beyond that. I think 
manual tuning of the project would be required, esp. if you want to do things 
that you cannot really achieve directly with CMake.

> or large apps were packaged using scripts. I'd appreciate some info on how
> do you see the current situation (of xCode cmake generator?) if we don't
> want to require manual mouse clicks in xCode to prepare builds.

See above, Xcode projects are like MSVC projects in that you maintain them 
manually ("what you see is all you get" ...). I actually have little experience 
with the current Xcode versions as I've drifted away from development requiring 
its use since I'm no longer using OS X 10.6 . However, as with MSVC there is 
usually little more you have to do than simply adding new files to targets.
Once you have a project though you can build it from the commandline, there's 
an xcodebuild utility that knows quite a few tricks for that.

> 

> >
> 
> Nope, really, clang shall build them ​just fine and they should work; only
> plugin paths are most probably something to test if we want to use non-Unix
> approach to paths.

Yes, QStandardPaths is a problem. Qt folks may disagree, but I have the 
impression it wasn't designed with much regard for the potential special needs 
of complex software like KDE's on platforms that don't use XDG-compliant 
locations (that's what we're really talking about here).
It's also a pity that there is nothing (in the ECM for instance) that 
determines the install locations from the QStandardPath locations, that should 
remove the need for a lot of hacking and additional testing.

> ​As programming frameworks, so programmers can pick up them as they pick up
> parts of KF5 or some other extra Qt modules for they project. In a

I repeat, "framework" is a term that's already taken in the Mac universe :)
One habit that I see which stands in the way of building KF5 libraries 
(including those with framework status) as a Mac framework is the way headers 
are included.
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 

this tells the compiler to search for 
{/System,}/Library/Frameworks/Foo.frameworks/Headers/Foo in addition to 
/usr{/local,}/include/Foo/Foo plus any in other paths you may have specified. 
You'd have to add the individual .framework/Headers directories to include them 
if you don't use the "rich" specification. Not the easiest thing to do in Xcode 
(the interface is a bit clunky).

A bit of a missed chance: most all of KF5's framework headerfiles install in a 
way that would make them accessible using the Foo/Foo notation...

R

Re: "non standalone app bundle" builds on Mac

[René J . V . Bertin]

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 for maintainer. Bundling or
>discovering server installation(s) (pgsql, mysql), bundling dependencies --
>these are all task for adoption.
>​
>
>In my opinion Kexi fits to a standalone path, just like on Windows, to
>become as native as possible, well, but not more native than that. For

Right, then there was Kexi too :) It that has been split off the rest of 
Calligra it's likely to be much smaller. It's also much more unique in its 
approach - if I'd discovered a use for it myself I would have started working 
on a port a while ago (port in MacPorts speak; ideally that's just a build 
script, Portfiles, that tells CMake where to install and get dependencies from).

I've never been against making more-or-less standalone app bundles for Mac, 
though I do feel that for an application family like KDE it would make sense to 
put as much of the shared resources as possible into something that's 
installable independently, e.g. a "meta framework" (a bundled collection of 
libraries, for which Apple used the term before KDE, the confusion is not on me 
;)). It'd be an interesting exercise for a more seasoned Mac developer than I 
am in this aspect, but it ought to be possible to bundle all KF5 frameworks 
that way into an object that can be installed into /Library/Frameworks. That'd 
be a perfectly native approach too, with a priori significant maintenance 
advantages, but out of scope in this conversation.

Either way, I've always felt that making applications really work well on OS X 
was a higher priority than the kind of ribbon you wrap it up with. If you want 
to know what's feasible to preserve in a feature set used on a different 
platform you start by working in conditions that are as close as possible to 
those on that platform. In this case, installing shared resources into a prefix 
much like pkgsrc and gentoo prefix do, as well as MacPorts, Fink and HomeBrew 
on Mac (which some consider "nice for linux refugees" which isn't untrue but 
completely beside the point).

Anyway, it's an approach I've been following for about a year now, and it's 
allowed me to contribute back quite a few improvements to KDE. The thing is 
that even if I were personally motivated to move on to tweaking the build 
system to make nicely wrapped-up autonomous app bundles where each app ships 
with yet another copy of all those Qt and KF5 libraries, I'd still have enough 
hay on my fork maintaining those MacPorts packages. Adding to that collection 
is a lesser and to me more satisfying investment than changing course.

In short, I'll try to look into Kexi soonish, but I think I shouldn't be be 
getting involved while it's still undergoing review (remember, hays and forks).

FWIW, as I wrote to Boudewijn, I think it'd make sense to investigate dumping 
cmake as the build system for "really native Mac" builds. Figure out once how 
to invoke cmake so that a project is built and installs as much as possible the 
way it should end up inside an autonomous app bundle (i.e. using Contents/MacOS 
and Contents/Resources, those are the only imperative folders I know of). Then 
use the CMake Xcode generator to create an Xcode project. Use the Xcode project 
from there on for Mac "bundled build"s, and cmake for everything else.

>example KFileWidget being very Plasma-oriented is close to be removed on
>Windows and could be also removed on Mac, in favour of a Url field + [..]
>button (KUrlRequester).

I have mixed feelings towards the KDE file widget. It's not uncommon that 
applications provide a non-stock file widget (in fact that's almost exactly 
what Qt's file dialog is) and KDE's has a number of very useful features that 
are missing in the Mac file dialog (like tree view). Put it into 
directory-selection mode however and it's really feels out of place (I much 
prefer the Mac approach here).

>I've also not seen Mac builds of Kexi-derived projects: KDb, KReport,
>KProperty. These are general-purpose frameworks and Kexi dependencies. If
>they are missing for Mac it would be nice to see them available too as

If? Is there reason to suspect that building them on Mac is going to require 
patching?

>frameworks for general use.

Framework in which sense? :)

R.

Re: "non standalone app bundle" builds on Mac

[René J . V . Bertin]

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 it'd probably be 
best to get involved sooner rather than later, this is not just any other 
reasonably sized project for which it's a relatively small effort to do 
preliminary builds.
Calligra 2.x already had numerous external dependencies (it'd help if they 
don't all have to be updated to the latest, greatest or Qt5-specific versions), 
but even without Krita the source repository is probably still huge. Being able 
to work with snapshot or (pre)release tarballs could be very useful.

R.

Re: "non standalone app bundle" builds on Mac

[René J . V . Bertin]

> 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 required in order to
 * launch the installer with User Account Control enabled.

#else // Q_OS_MAC

#ifdef Q_WS_MAC
QDir bundleDir(qApp->applicationDirPath());
#endif

#endif  // Q_OS_WIN

```

On Sunday November 06 2016 14:26:41 Friedrich W. H. Kossebau wrote:

> 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 to discuss how-to-macOS. Which means if it does not break/screw the
> Linux build (or Windows when it comes to Kexi & Co.), your chance to rule.

That sounds more like it :) (Not that I'm intent on ruling, but sometimes it's 
nice to be first ;))

Truth be told, MacPorts provides a very nice "meta build system" with some 
nifty features like port de/activation, so I'm using the same build "scripts" 
to build KF5 things on my KUbuntu 14.04 system with its trusty Plasma4 desktop. 
I still prefer the stability of that legacy desktop, but appreciate running 
select KF5 applications from a parallel prefix (guess what, /opt/local). So, 
basically every patch I make for MacPorts is tested on Linux too before I 
consider submitting it.

R.

Re: "non standalone app bundle" builds on Mac

[René J . V . Bertin]

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 another build with yet another set of bugs that I would need yet another 
> system for to reproduce and try to fix. I don't want to support a macports 
> version of Krita, and I wish I could be sure there wouldn't be one, so I 
> don't have to ask every Apple user who accidentally uses the "macports" field 
> instead of "app bundle" whether that's really what they're using.

Well, that's the point: it's NOT another build. It's a build that's just about 
exactly as it is on any other (BSD) Unix which doesn't use exactly the same 
libraries as Linux. Any bugs that occur as a direct result of building a 
different way would evidently be for us to fix, but it'd still be easier to 
determine responsibilities if we could agree at least on an official switch to 
turn from a supported to an unsupported build.


I'd go one step further and say that I'm not convinced that modifying the 
existing build system to generate a self-contained app bundle is the best way 
to go. What I've seen with Marble and now Krita looks brittle, (almost) hacks 
here and there where something needs to be done differently. In contrast, 
digiKam can also be built (and is distributed as) a self-contained app bundle, 
but there it's done much more like how Qt seems to suggest. Build normally, and 
then run an additional deployment step that bundles everything. Ditto for Kate 
and KDevelop: all 3 applications build in MacPorts as they do under Linux, with 
the only difference that GUI applications end up being app bundles that depend 
on stuff under ${prefix}.

I just checked, BKO doesn't have an "app bundle" field, not even for Krita 
bugs. 

Of course you can disgust us (me) enough that I just drop any efforts I might 
otherwise spend on the code, but in that case I also will not hide the reason 
why we're not providing a Krita port to anyone who requests one (and I have 
already had requests).

> Argh... Did they change that again? And, lovely, now that OSX is no longer 
> called OSX, are they going to go back from Q_OS_OSX to Q_OS_MAC or Q_OS_MACOS?

Well good morning! ... This changed with Qt 5.0.0 . I don't know how they plan 
to follow Apple's own naming inconstancy, I guess we'll see when 6.0 comes out.

> That's needed to find the translations.

What's different with Krita translations that they cannot be found simply 
through QStandardPaths and the GenericDataLocation?


R.

Re: "non standalone app bundle" builds on Mac

[René J . V . Bertin]

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 subscription ... :)


The question I raised isn't relevant to them only, of course, but also for the 
rest of Calligra.

And FWIW: if it's not obvious I can spend a few words explaining why the 
MacPorts KF5 ports us "linuxy" builds.


R.

"non standalone app bundle" builds on Mac

[René J . V . Bertin]

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 Linux, to 
ensure the largest possible feature set, including an adapted KDE platform 
theme plugin allowing central selection of an application style, etc.

Overall this works fine but there are a select few exceptions that require 
extensive patching to the build system because the devs have made the 
assumption that builds on Mac are always supposed to lead to standalone app 
bundles. To be clear: most apps with a GUI should indeed live in an app bundle, 
that bundle need not contain more than the bundle exec, an Info.plist and the 
app icon. All the rest can be in traditional locations under a shared prefix 
(/opt/local by default in MacPorts).

It turn out that Krita is one of those select fews. I haven't followed the 
split-off closely so I don't know if this ML is still the best place to raise 
questions about building on Mac, but I hope I can still reach at least some 
Krita devs here.

Just how (un)sympathetic an attitude can I expect towards the idea of doing a 
"linuxy" build on Mac? Would you consider patches that make this optional, IOW, 
that uncouple the build type from CMake's platform token ("APPLE") but put it 
under control of an option (e.g. "APPLE_STANDALONE_BUNDLE") which could 
perfectly well be ON by default? Would there motivation to help me find 
"obscure" locations in the source code where build type and install location 
assumptions are being made?

Concerning that last aspect, and re: Krita, I notice:
- the code uses a legacy (but still working) Qt token (Q_OS_MAC) but also an 
obsolete token (Q_WS_MAC) which I thought is no longer defined
- seems to try to bypass QStandardPaths by setting up an XDG_DATA_DIRS env. 
variable

After a few hours of work I'm now at a point where Krita builds and doesn't 
immediately abort or exit with an error message (nb: qFatal() just provokes 
what looks like a crash on Mac with stock Qt; the error message is never 
shown). It crashes immediately though when I open the preferences (settings) 
dialog - which starts DrKonqi just as you'd expect it to. I haven't yet had the 
time to figure out the reason for this crash, but it's an example of the sort 
of issue I might be asking for guidance about.

While I could work around the whole issue with a few patches to the build 
system and symlinks in the app bundle to emulate a standalone bundle, I'd 
prefer to do this properly. Once committed (in all senses of the term), that 
should be easier to maintain and feel less like an uphill battle.

Thanks,
René

Re: Qt version

[René J . V . Bertin]

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 minimum required by calligra master now.)

Qt 5.6 is LTS itself, but don't forget that the KF5 frameworks are requiring 
5.5 if not 5.6 nowadays...

R.

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

[René J . V . Bertin]

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 see in the KCharSelect app, selection of unicode range is a
>function of given font - different ranges are supported by different fonts.

FWIW, I think OS X has something like this on the OS level, available if you 
activate the keyboard selection menu and the corresponding option (there's also 
a keyboard viewer). Those keyboard and character viewer options open the 
equivalent of floating dock windows attached to the application active when you 
evoke the feature. The character viewer allows you to browse all known Unicode 
ranges and will show the glyphs from installed fonts that have the selected 
Unicode key, plus known variants. And of course allow to input the glyph in 
question.

So yeah, it's up to the OS or desktop environment to provide such a feature...

Preferences to select which font to use for which Unicode range can make sense, 
but IMHO more in applications like web browsers that can encounter just about 
any kind of content conceivable and that aren't designed to *create* _coherent_ 
documents.

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

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

[René J . V . Bertin]

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 a theme, so expecting QIcon::fromTheme() to return them seems a bit 
of a misunderstanding.

>Without that I'd have to duplicate logic of icon themes just to make 
>QIcon::fromTheme() work cross-platform.

Why? Why not do as Kate and use QIcon(":/icon-from-rcc") instead of 
QIcon::fromTheme() for app-specific icons that should be independent of the 
user's icon theme choice, and ::fromTheme() for those icons that are supposed 
to reflect his/her choice of theme?

I don't think there's any need whatsoever to duplicate (reimplement) the logic 
of icon themes. AFAIK, QIcon::fromTheme() will work anywhere once you define an 
icon theme search path and the expected icon theme is installed somewhere in 
that path.

BTW, am I right that using a builtin binary rcc icon set could make you lose in 
terms of memory (RAM) footprint overhead what you gain in terms of disk space 
overhead?

R

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

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

[René J . V . Bertin]

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 XDG is the standard, but you can add any 
location.

Anyway, if you want to make any application look "more pro", you'll need to use 
icons that match the ones used in native applications. I know of no existing 
theme that achieves that for OS X, but I tend to find that Oyxgen doesn't look 
too much out of place. I happen to dislike the Breeze theme and icons. Apart 
from that I understand they were created as part of a sort of "fresh start 
movement" and if true that could mean almost by definition that it won't blend 
in on other systems.

> Yes but mainly in the Qt (so also KDE) world :) ​I hope that making any
> valuable Qt app look more pro thanks to that is even better investment than

I think you're talking only about KDE applications here. Most every Qt 
application I know of that respects itself and cares about it looks on OS X 
(and MS Windows) already uses appropriate icons and tweaks to the UI. KDE 
applications OTOH typically don't look pro at all (on OS X) because they're 
designed to rely on theming aspects that aren't supported with an 
out-of-the-box Qt build. That's not hard at all to activate BTW (on OS X), so 
definitely an option for applications that bundle their own Qt libraries.

> ​Yes, I'll try that in the same way as Kate on win/mac. And share the
> results, for sure.

Personally the only thing I'm interested in is that the build system isn't 
going to require unnecessary hacking to deactivate this kind of feature which 
is not desirable for MacPorts.

> ​In short either all icons used by a given app are supported by selected
> theme, or theming is a waste of effort. After years I generally think

I think icons are a peripheral aspect of theming, but that's undoubtedly 
because I've been working with Macs and PCs for desktop work since the late 
80s. Icons only show up in buttons or toolbars that have no text (and my 
toolbars are almost always set to "text only" because it's less distracting and 
in 85+% of cases I understand a text label quicker than the associated icon.
As such I would probably applaud it if more applications provided their own 
custom-designed icons for image-only buttons (and toolbars).

> theming is very special statistically a low-priority task. In most cases
> for Linux software if there's no single default worldwide for given app;
> distros change that to naturally differentiate themselves. Only web apps

Don't forget the angry teenagers and prop artists behind the Nth CSI:Humbug 
series who seem to be a major target population for all those distributions :)

> are immune to that because the environment they run in is consistent.

Yes, and they tend to set a trend to applications that look the same everywhere 
(argument I already used to justify the existence/creation of a Mac KDE 
platform theme plugin a.k.a. OS X integration framework O:-)).

> Then when even you, the author, do not know how your app looks on the
> user's desktop, even things such as documentation is hard to prepare (if it
...
> app" action, because on non-Plasma desktop the help icon was completely
> different.

Only 2 possible "hard" solutions that I can see: either you ensure that an 
application adheres to native guidelines and uses native or native-looking 
icons (where icons are allowed). Or you ensure that the application looks the 
same everywhere because widgets can also have very different looks on different 
platforms (in which case the built-in Fusion style would be a good choice).

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

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

[René J . V . Bertin]

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 need to work on Calligra, if LO UI would 
>already be what I want.

That sounds like a perfect alternative wording of the kind of argument (La)TeX 
fans use to explain why they don't use a WYSIAYG contraption ;)

In practice, don't most users simply open an existing document of their own 
that comes closest to whatever new document they're going to create, and work 
from there? That is certainly how I tend to work, regardless of the kind of 
document or the application used to create it. I also tend to prefer to start 
with a truly empty and virgin slate in the (rare) cases I really start 
something new.

end of noise :)

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

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

[René J . V . Bertin]

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 with those decisions "coded" through a much nice user interface called 
>a 
>wordprocessor is well.. stupid.

I'm not sure I agree. I'm quite sure that in OpenOffice and a few other 
wordprocessors, things like the default styles, page size etc. are configured 
at a different level than the document template (though a template could 
probably override them). I may be wrong, of course, but I'd certainly 
appreciate it if templates have the option to omit specifying things like 
styles and page size so that my own preference in these matters applies.

Anyway, go ahead, forget I made some noises :)

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

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

[René J . V . Bertin]

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 blank template
>
>but as i said i fear it's not such a low hanging fruit at all

I've never understood why applications would ever need an actual on-disk 
template for a blank document. Even without using an OO programming language 
proper initialisation of the internal document structure should give you (wait 
for it) an empty document. 

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

Re: making a poster/flyer

[René J . V . Bertin]

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 
along this time!

René

>Hello,
>
>  If you don't find any calligra module appropriate for this task, you can
>always try http://www.scribus.net. It allows more precise placing than
>words and is not so drawing oriented as krita, it is a publishing
>application.
>
>Best Regards.
>
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

making a poster/flyer

[René J . V . Bertin]

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, for which I used Star/OpenOffice Impress and later 
InDesign (though I think also did one or twice in PowerPoint and maybe even 
Excel...)

What's the most appropriate Calligra module to use for this kind of thing? I 
think Krita would probably (a bit) overkill on the one hand and (maybe?) lack a 
number of convenience function for text layout on the other hand (and I simply 
have an almost complete lack of experience with PhotoShop-like applications). I 
gave Calligra Stage a quick look but the version (2.9.2) on the system I tried 
wouldn't even auto-size a text frame to keep up with changing text dimensions, 
surely that was an operator error?

Thoughts?

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

Re: Reminder: Calligra 2.9.9

[René J . V . Bertin]

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

Re: Reminder: Calligra 2.9.9

[René J . V . Bertin]

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.

>Hi,
>Dear Maintainers, it would help if you prepare your change logs very soon.
>
>According to our plan we have:
>
>Tagging Sat, October 31st
>Release Wed, November 4th
>
>Everyone: blogging about your 2.x and 3.x status/plans/impressions
>will be appreciated too.
>
>

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

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

[René J . V . Bertin]

---
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 marked as submitted.


Review request for Calligra and KDE Software on Mac OS X.


Changes
---

Submitted with commit 0b4834c346300bb6d14ef3ddd8dd56e006882183 by René J.V. 
Bertin to branch calligra/2.9.


Repository: calligra


Description
---

Builds on OS X currently generate icons for most Calligra applications, but 
those are installed only for a happy few (Krita, Braindump and Kexi). The other 
applications require an explicit install command of the generated `.icns` file 
into the app bundle's Resources directory.

The attached patch takes care of that.

In addition, it corrects the picture source directories for calligragemini and 
calligraauthor so those applications can have icons on other platforms too, and 
replaces the `Q_WS_MACOS` token with the (IMHO) more appropriate `APPLE` token.


Diffs
-

  cmake/modules/MacroCalligraAddBenchmark.cmake 9e7e282 
  flow/part/CMakeLists.txt 58882f1 
  gemini/CMakeLists.txt 85123fa 
  karbon/CMakeLists.txt b574779 
  plan/CMakeLists.txt ad39f57 
  plan/workpackage/CMakeLists.txt f6eb20f 
  sheets/CMakeLists.txt b0cc134 
  stage/app/CMakeLists.txt 079bece 
  words/app/CMakeLists.txt 1e73971 
  words/part/CMakeLists.txt 9143176 

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


Testing
---

On OS X 10.9 with KDELibs 4.14.12 and MacPorts 2.3.4 .


Thanks,

René J.V. Bertin

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

Re: Calligrastage 2.9.8/Mac : dynamic_cast error message

[René J . V . Bertin]

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 `git describe` in the 2.9 branch returns 
"v2.9.7-151-g0b4834c", is that intentional?

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

Re: Calligrastage 2.9.8/Mac : dynamic_cast error message

[René J . V . Bertin]

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 normally exported 
> class with implementation of constructor/destructor inside libflake?

It would seem so. I've had to do a similar fix with KDE PIM's ktimetracker; 
there, the issue was not a mysterious error message in the logs, but downright 
failure of a dynamic_cast.


R.diff --git a/libs/flake/CMakeLists.txt b/libs/flake/CMakeLists.txt
index 7a97edc..b927d1d 100644
--- a/libs/flake/CMakeLists.txt
+++ b/libs/flake/CMakeLists.txt
@@ -102,6 +102,7 @@ set(flake_SRCS
 KoSnapData.cpp
 SnapGuideConfigWidget.cpp
 KoShapeShadow.cpp
+KoSharedLoadingData.cpp
 KoSharedSavingData.cpp
 KoViewConverter.cpp
 KoInputDeviceHandler.cpp
diff --git a/libs/flake/KoSharedLoadingData.cpp b/libs/flake/KoSharedLoadingData.cpp
new file mode 100644
index 000..4af8dc2
--- /dev/null
+++ b/libs/flake/KoSharedLoadingData.cpp
@@ -0,0 +1,28 @@
+/* This file is part of the KDE project
+   Copyright (C) 2007 Thorsten Zachmann 
+
+   This library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Library General Public
+   License as published by the Free Software Foundation; either
+   version 2 of the License, or (at your option) any later version.
+
+   This library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Library General Public License for more details.
+
+   You should have received a copy of the GNU Library General Public License
+   along with this library; see the file COPYING.LIB.  If not, write to
+   the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
+ * Boston, MA 02110-1301, USA.
+*/
+
+#include "KoSharedLoadingData.h"
+
+KoSharedLoadingData::KoSharedLoadingData()
+{
+}
+
+KoSharedLoadingData::~KoSharedLoadingData()
+{
+}
diff --git a/libs/flake/KoSharedLoadingData.h b/libs/flake/KoSharedLoadingData.h
index 0d9ed71..ce0372c 100644
--- a/libs/flake/KoSharedLoadingData.h
+++ b/libs/flake/KoSharedLoadingData.h
@@ -20,16 +20,18 @@
 #ifndef KOSHAREDLOADINGDATA_H
 #define KOSHAREDLOADINGDATA_H
 
+#include "flake_export.h"
+
 /**
  * The KoSharedLoadingData class is used to share data between shapes during loading.
  * These data can be added to the KoShapeLoadingContext using KoShapeLoadingContext::addSharedData().
  * A different shape can then get the data from the context using KoShapeLoadingContext::sharedData().
  */
-class KoSharedLoadingData
+class FLAKE_EXPORT KoSharedLoadingData
 {
 public:
-KoSharedLoadingData() {}
-virtual ~KoSharedLoadingData() {}
+KoSharedLoadingData();
+virtual ~KoSharedLoadingData();
 };
 
 #endif /* KOSHAREDLOADINGDATA_H */
___
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel

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

[René J . V . Bertin]

> 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 the `Q_WS_MAC` fix will need porting to the master branch?
> 
> René J.V. Bertin wrote:
> No, Q_WS_MAC is not something that cmake provides by default, so I guess 
> you're right. 
> 
> Do calligragemini and calligraauthor get icons on Linux? For the former 
> it seems that that should only be the case if the icon .png file(s) is/are 
> already installed, but if that's the intended behaviour shouldn't my patch be 
> Mac-specific? Calligraauthor's `kde4_add_app_icon` call is commented out, was 
> that intended or should that patch *not* be Mac-specific?
> 
> I have no idea at the moment what has changed in KF5/ECM. If ECM provides 
> a function `ecm_add_app_icon` then it would make sense that it does all the 
> required work.
> Note however that the sole use of `kde4_add_app_icon` isn't enough. It 
> generates the icon file, and it adds the corresponding entry in the 
> application's `Info.plist`, but that's not always enough. I haven't yet 
> figured out why certain applications always got an icon, and why others 
> require explicit installation of the icon resource.
> 
> Friedrich W. H. Kossebau wrote:
> Yes, calligragemini has icons on linux, they are installed by the 
> CMakeLists.txt in gemini/pics. And Author has icons as well.
> For both it was "just" those kde4_add_app_icon that were broken or not 
> active (they do nothing on linux IIRC, that's why not noone noticed so far. 
> And Windows builds are only done for CalligraGemini, Krita & Kexi).
> 
> For `ecm_add_app_icon` see here for the sources, ll. 223-224:
> 
> https://quickgit.kde.org/?p=extra-cmake-modules.git=blob=modules%2FECMAddAppIcon.cmake
> ```
> # Install the icon into the Resources dir in the bundle
> set_source_files_properties(${_outfilename}.icns PROPERTIES 
> MACOSX_PACKAGE_LOCATION Resources)
> ```
> No idea what effect that has and if that is better than what is there in 
> `kde4_add_app_icon`, but you might :)

No, sorry I don't. Not without delving into the cmake code. I can guess though: 
it installs `${_outfilename}.icns` into the `Resources` directory of the app 
bundle created at `MACOSX_PACKAGE_LOCATION`. It's a bit suspicious that that 
variable (or token) uses the term `package` instead of `bundle` (but I've 
learned it's useless to argue with cmake developers about such things).

Two things are required for providing an  app bundle with an icon. The icon 
resource itself (.icns) which is expected in `foo.app/Contents/Resources`, and 
an entry in the `Info.plist` which declares the name of that resource. 
`kde4_add_app_icon` appears to guarantee only the former requirement; 
`ecm_add_app_icon` may be better behaved. However, looking at the 
`kde4_add_app_icon` source:

```
set(MACOSX_BUNDLE_ICON_FILE ${appsources}.icns)

# Append the icns file to the sources list so it will be a 
dependency to the
# main target
list(APPEND ${appsources} ${_outfilename}.icns)

# Install the icon into the Resources dir in the bundle
set_source_files_properties(${_outfilename}.icns PROPERTIES 
MACOSX_PACKAGE_LOCATION Resources)
```

The first line tackles the Info.plist entry, and the last line is identical to 
the one from `ecm_add_app_icon`.

I was going to suggest that someone more intimate with KDE's cmake build system 
could port the 2.9x CMake files to use ECM (ECM doesn't depend on KF5 and AFAIK 
it can be used with KDE4 too). However, it seems this won't change anything.

I do think that some applications didn't get icons because they were declared 
as kdeinit applications, but that doesn't appear to apply to all of them.

In short, it seems that for calligra 3x
- my modifications to `kde4_add_app_icon` calls can be applied to the 
corresponding `ecm_add_app_icon` calls
- the explicit install instructions can be copied to the corresponding 
locations, with syntax or name corrections where required, and then commented 
out so that the fixes I made here won't get lost or forgotten.

Re: `Q_WS_MAC` : it appears that this token is defined by `FindQt4.cmake` (file 
provided by kdelibs). To token is deprecated in Qt, so it's best not to use it.


- René J.V.


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


On Oct. 15, 2015, 10:55 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, 

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

[René J . V . Bertin]

---
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 Software on Mac OS X.


Repository: calligra


Description
---

Builds on OS X currently generate icons for most Calligra applications, but 
those are installed only for a happy few (Krita, Braindump and Kexi). The other 
applications require an explicit install command of the generated `.icns` file 
into the app bundle's Resources directory.

The attached patch takes care of that.

In addition, it corrects the picture source directories for calligragemini and 
calligraauthor so those applications can have icons on other platforms too, and 
replaces the `Q_WS_MACOS` token with the (IMHO) more appropriate `APPLE` token.


Diffs (updated)
-

  cmake/modules/MacroCalligraAddBenchmark.cmake 9e7e282 
  flow/part/CMakeLists.txt 58882f1 
  gemini/CMakeLists.txt 85123fa 
  karbon/CMakeLists.txt b574779 
  plan/CMakeLists.txt ad39f57 
  plan/workpackage/CMakeLists.txt f6eb20f 
  sheets/CMakeLists.txt b0cc134 
  stage/app/CMakeLists.txt 079bece 
  words/app/CMakeLists.txt 1e73971 
  words/part/CMakeLists.txt 9143176 

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


Testing
---

On OS X 10.9 with KDELibs 4.14.12 and MacPorts 2.3.4 .


Thanks,

René J.V. Bertin

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

Calligra 2.9.8 / Mac

[René J . V . Bertin]

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 specific:
- another test was added (TestKoLcmsColorProfile) that attempts to use a plugin 
module as a shared library. That may work on Linux, but it's bad practice and 
breaks the build on OS X. I now have to patch 4 CMakefiles for this.
- CalligraFlow and Karbon still load the other's kpart, that is, to work in 
Karbon one needs to start Flow. I can file a bug report for this, but will only 
do that if someone is interested to figure out what goes wrong.
- Krita fails to detect the available RAM (undoubtedly because the underlying 
KDE API isn't implemented on OS X) and should provide a configure setting on 
platforms where auto-detection doesn't work, or refrain from using it as a 
limit in the Performance config sheet.

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.

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

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

[René J . V . Bertin]

> 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 the `Q_WS_MAC` fix will need porting to the master branch?

No, Q_WS_MAC is not something that cmake provides by default, so I guess you're 
right. 

Do calligragemini and calligraauthor get icons on Linux? For the former it 
seems that that should only be the case if the icon .png file(s) is/are already 
installed, but if that's the intended behaviour shouldn't my patch be 
Mac-specific? Calligraauthor's `kde4_add_app_icon` call is commented out, was 
that intended or should that patch *not* be Mac-specific?

I have no idea at the moment what has changed in KF5/ECM. If ECM provides a 
function `ecm_add_app_icon` then it would make sense that it does all the 
required work.
Note however that the sole use of `kde4_add_app_icon` isn't enough. It 
generates the icon file, and it adds the corresponding entry in the 
application's `Info.plist`, but that's not always enough. I haven't yet figured 
out why certain applications always got an icon, and why others require 
explicit installation of the icon resource.


- René J.V.


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


On Oct. 15, 2015, 10:55 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125649/
> ---
> 
> (Updated Oct. 15, 2015, 10:55 p.m.)
> 
> 
> Review request for Calligra and KDE Software on Mac OS X.
> 
> 
> Repository: calligra
> 
> 
> Description
> ---
> 
> Builds on OS X currently generate icons for most Calligra applications, but 
> those are installed only for a happy few (Krita, Braindump and Kexi). The 
> other applications require an explicit install command of the generated 
> `.icns` file into the app bundle's Resources directory.
> 
> The attached patch takes care of that.
> 
> In addition, it corrects the picture source directories for calligragemini 
> and calligraauthor so those applications can have icons on other platforms 
> too, and replaces the `Q_WS_MACOS` token with the (IMHO) more appropriate 
> `APPLE` token.
> 
> 
> Diffs
> -
> 
>   flow/part/CMakeLists.txt 58882f1 
>   gemini/CMakeLists.txt 85123fa 
>   karbon/CMakeLists.txt b574779 
>   plan/CMakeLists.txt ad39f57 
>   sheets/CMakeLists.txt b0cc134 
>   stage/app/CMakeLists.txt 079bece 
>   words/app/CMakeLists.txt 1e73971 
>   words/part/CMakeLists.txt 9143176 
> 
> Diff: https://git.reviewboard.kde.org/r/125649/diff/
> 
> 
> Testing
> ---
> 
> On OS X 10.9 with KDELibs 4.14.12 and MacPorts 2.3.4 .
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

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

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

[René J . V . Bertin]

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


Description
---

Builds on OS X currently generate icons for most Calligra applications, but 
those are installed only for a happy few (Krita, Braindump and Kexi). The other 
applications require an explicit install command of the generated `.icns` file 
into the app bundle's Resources directory.

The attached patch takes care of that.

In addition, it corrects the picture source directories for calligragemini and 
calligraauthor so those applications can have icons on other platforms too, and 
replaces the `Q_WS_MACOS` token with the (IMHO) more appropriate `APPLE` token.


Diffs
-

  flow/part/CMakeLists.txt 58882f1 
  gemini/CMakeLists.txt 85123fa 
  karbon/CMakeLists.txt b574779 
  plan/CMakeLists.txt ad39f57 
  sheets/CMakeLists.txt b0cc134 
  stage/app/CMakeLists.txt 079bece 
  words/app/CMakeLists.txt 1e73971 
  words/part/CMakeLists.txt 9143176 

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


Testing
---

On OS X 10.9 with KDELibs 4.14.12 and MacPorts 2.3.4 .


Thanks,

René J.V. Bertin

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

Re: Calligra 2.9.8 / Mac

[René J . V . Bertin]

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 is often a consequence
> of nested layouts, each adding to the margin or spacing. (yes I know

Heh, maybe that means the native style feels less oversized than in other 
applications. Will see. I'll have to find a slot to sit down and make 
screenshots (and then find an appropriate place to upload them).

> But there are Qt apps that look native on various platforms, to I hope
> it's possible to do it well enough and show professional look

There are damn few Qt applications that don't feel off one way or another. Many 
things are just slightly different (like how Carbon apps used to have their own 
look and feel) but less so then with Java apps, for instance.
But in such cases I just as well have something that has a well-matched but 
clearly different style.

> > I'm part of those users for whom one of KDE's benefits is the possibility 
> > to use something other than the OS X look without having to resort to iffy 
> > 3rd party software that inject code into rendering engines.
> 
> If I understood correctly. Well, isn't the whole idea of plugins is
> injecting external code? QStyle works this way, and it's API is common

No. Plugins are code that's intended to be imported by code conceived to work 
with those plugins. Here I'm talking about injecting code in foreign code, 
typically using undocumented hooks.

> As a power user with own taste, you're free to use any style you want.

I'd hope so :) Except that Krita and probably a few other applications override 
that, in a way that even `-style Foo` has no effect. I'm not exactly sure how 
that works (and if it's intended to work like that), but I identified the 
locations.
(I think I ended up with the Plastique style in Krita.)

> Even if changing style is a matter of editing a config file once, by
> hand, I guess it's bearable. But if we're talking about defaults,

We have the systemsettings app in MacPorts (I made that happen among the 1st 
things I did) :)

> certain decisions have their consequences. For example I am not sure
> how style not designed for Mac behaves in the upper area of the window
> where the mac toolbar is placed.

You mean the menubar? It's not themeable, which is fine with me. Menu items are 
themeable to some extent, but not enough that KMenu::addTitle has the intended 
effect with all styles, for instance.
The main and secondary toolbars work just like you'd expect them to work, 
except of course for any kind of merging with the titlebar.

> > "Get it"? Get what?
> 
> Styling using any style available. Sorry.

Some won't work as well as others, that seems likely. If that's a reason to 
allow only a tested subset ... I don't think so.

> Again it would be great for me to see Kexi screenshots for Mac :) Please.
> I don't have access to Macs this time anymore.

Ok, I'll include Kexi when I get to doing screenshots. Remind me after next 
week if I take too long.
Be warned that I'm running my own font config which may seem surprising 
(Novarese for certain UI elements), but then I'm not even sure what the default 
font settings are on OS X. I imported the ~/.kde directory from my Linux box 
*very* early during my KDE/Mac adventure.

> application. Menus can disappear, and be replaced by different shell
> of choice. Kexi projects are actually entire recipes that users define

I recall a discussion about this, a while back. I can't remember if I asked 
"like Filemaker" - because that's what this description makes me think of.

> Styling for them is like the style of web page in a browser that can
> affect the browser's own UI too (there are early browsers like this
> already).

In a browser I usually hate it and turn it off when possible (Opera :)). It 
depends on the UI element(s) affected. Scrollbars and other elements that also 
exist elsewhere in the GUI should not look different than their siblings, IMHO.

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

Calligrastage 2.9.8/Mac : dynamic_cast error message

[René J . V . Bertin]

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, 23KoTextSharedLoadingData.

Demangling:
19KoSharedLoadingData -> "KoSharedLoadingData"
23KoTextSharedLoadingData -> "KoTextSharedLoadingData"

I've been seeing similar messages for some Akonadi classes, but have never been 
able to figure out neither how to fix the code, nor if anything actually 
doesn't work because of this.

Maybe someone here has an idea?

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

Re: Calligra 2.9.8 / Mac

[René J . V . Bertin]

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

Re: Calligra 2.9.8 / Mac

[René J . V . Bertin]

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 out that 
QtCurve works just fine from what I've been able to see.
And FYI: Oxygen and Breeze do *not* work properly on OS X. Not in KDE4 at 
least, but from what I hear that applies to KF5 too.

Also, the native Mac theme can lead to button mis-alignment in KDE 
applications; there again it appears that KF5 is affected too (the showcase app 
is kcalc).
As a result, KDE/MacPorts suggests using QtCurve as the default theme (the port 
ships with presets that blend in nicely with the rest of the OS).

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

Re: Calligra 2.9.8 / Mac

[René J . V . Bertin]

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 also 
wastes way too much space.
I'm part of those users for whom one of KDE's benefits is the possibility to 
use something other than the OS X look without having to resort to iffy 3rd 
party software that inject code into rendering engines.

> 2. current development branch i.e. 3.x.
My resources are spread too thin to jump into development branches of something 
as big as Calligra (and if 3.x is for KF5 it's a no-go for the foreseeable 
future anyway).

> so in the end of the day I see real users preferring consistency and
> predictability.

Indeed, I prefer consistency. If I chose and configure a style for my desktop, 
I do not want applications to think they know better. If really needed there is 
always the possibility to pick another style for applications that have issues 
with the local default...

> For Qt5/KF5, isn't the native style for simple layouts just fine? See [1]

(Please use inline URLs). 
That's on a high res screen, and (thus) not at all a reference for what happens 
on normal screens.
I also don't think Kate was ever particularly affected by the rendering issues 
with the native theme, at least not in the default window shown.

> To be honest, I don't expect to get it for free for complex layouts
> like sidebars. Neither on Windows. In mid term even some specific

"Get it"? Get what?

> (even if style guide isn't strictly codified on Windows, apps can look

It isn't on OS X either; the HiG are just guidelines (and AFAIK they also don't 
forbid using a different theming even if they evidently assume you don't. Apple 
themselves are among the worst offenders of their own HiG, btw.)

Kexi is a bit of a foreign duck in the pond in that it has an interface that 
appears to be inspired a lot by mobile devices. It doesn't strike the eyes as 
much when it uses a different style (it is affected by the glitches in the 
native Aqua style, btw, at least in the welcome view).
In fact, its look seems to be determined mostly by the user's choice of fonts, 
which are *not* part of the style...

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

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

[René J . V . Bertin]

 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 two things, after we've split up the repositories:
rename everything to camelcase, or everything to underscores. As
for me, Qt Creator makes it much easier to work with files that 
have the same names as the class themselves.

I'd advise against using case filenames, or at least be very attentive not to 
depend on filename differences that are in case only. This *will* lead to 
problems on MS Windows and Mac OS X.

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

Re: What If OpenDocument Used SQLite?

[René J . V . Bertin]

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 
text-based format means you can get at the text with only very basic tools, and 
I consider that an insurmountable advantage. Esp. once you've seen how 
relatively easy it is to corrupt an sql file in just the ways to make the 
entire file unreadable.

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

Re: Calligra Icons

[René J . V . Bertin]

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 
where they are supposed to be the object the user interacts with to launch an 
application or open a document of a certain type. IMVHO they're too abstract, 
crucial details will get lost when rendered at a representative screen size and 
colour contrast is badly chosen. I haven't checked, but I think more than a few 
esp. from the 2nd set will look much too similar for daltonians and people with 
other colour sight issues.

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

Re: phabricator.kde.org reviews (differential)

[René J . V . Bertin]

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 login screen. Is there a 
reason the site does (did?) not accept the usual KDE identity or BKO creds?

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

about font handling (and restore)

[René J . V . Bertin]

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 doesn't always return the expected typeface because Qt only recognises 
a (very) limited subset of known weights, with (almost) no support for synonyms 
at all.
KDE4 appears to mitigate the issue, but I'd not be surprised if that extra 
layer has disappeared in KF5, or has been incorporated somehow into Qt 5.

And Qt 5 (5.4) is just as affected by this issue, possible more even on Linux 
because the xcb platform plugin lacks helper functionality that exists on OS X 
and that can provide additional logic to disambiguate the potential matches for 
the user's request.

I admit I haven't yet had the chance to assess how this affects Calligra (Krita 
and Karbon most I'd guess), but before I spend a lot more time on the Qt 
patches that address this issue I thought I'd ask on here:

About Calligra/KDE4:
- how do you store fonts and then restore them when opening a document or 
parsing a settings file?
- does that work reliably, even less common fonts, weights and styles? Good 
test fonts are the Avenir Next and Helvetica Neue families (system fonts on OS 
X), or even the Segoe UI family that comes with all MS Windows machines.

And of course, has this already been done and tested for the KF5/Qt5 port?

I'm a bit in limbo here ... OTOH I hope my assessment is right and I'm at least 
making appropriate changes to improve a (probably flawed) implementation and 
OTOH I'm hoping I'm fighting windmills (because the Qt guys seem to think this 
is only a nice to have fix).

I just can't see the windmill when I do (in Qt 5.4, or without the this 
argument in Qt 4.8):

QFont font = QFontDialog::getFont(ok, QFont(), this, Select Font, options);
QFont font2 = QFont(font.family(), font.pointSize(), font.weight(), 
font.italic());
QFont font3 = QFontDialog::getFont(ok, font2, this, Select Font, options);

and the second dialog gives me a different font than the one selected in the 
1st and indeed font3==font2!=font ...

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

krita window size

[René J . V . Bertin]

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 window it actually resized too 
large. Is there a hardcoded minimum window size in Krita?

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

Re: krita window size

[René J . V . Bertin]

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 krita too big to fit in 
that resolution.

Hmmm, unless you have very good eye-sight (or as good as mine once was ^^) I 
doubt my fonts are larger than yours. I run Kubuntu 14.04 with a rather 
standard Oxygen style/theme, WM buttons set to small (and other settings 
tailored to be as compact as possible). I do set my text DPI (Xft.dpi) to 86 
rather than 96, but that too causes text to render *smaller*.

Anyway, you seem to confirm that Krita overrides the window dimensions it 
receives in the resize event? I could try to detach elements to see if that has 
any effect, but right now Krita actually crashes when I start it. It must have 
corrupted something in the graphics stack ... how actual/accurate is that 
OpenGL texture buffer comment about not working on AMD/Radeon ?

R.


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

Re: Qt5 Port Status

[René J . V . Bertin]

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
  ^^^
 I guess that you could use macros or something similar to fold those 
 different areas to a single one after the conversion?


Well, we want to have a lot of different areas, Calligra is so complex 
that we need a fine-grained way to turn debug on/off.

I thought you wanted to keep sharing the same area across different libraries, 
which is something we do a lot in Calligra?

 Does that mean that the KDE (4 and 5) headers are not conceived to co-exist 
 (the libraries are, I'd presume) or else, why is that?
 If in general one cannot have a system that allows you to build KDE4 
 applications as well as KF5 applications that's something we're going to 
 want to know and deal with (as soon and as far as possible) in MacPorts ...

The problem is kde4libs support: that framework conflicts with the regular 
kde4 headers.

So we should be fine if we configure KF5 to put its headers in, say, 
/opt/local/include/kf5 instead of just /opt/local/include like KDE4 does (in 
MacPorts)?
(Or we'd have to re-organise KDE4 too so it puts its headers into 
/opt/local/include/kde4, to prevent accidental confusion ...)

It's surprising though that KF5 wasn't conceived to avoid this kind of name 
clashing , e.g. by putting the kde4support headers in a subdirectory and 
inciting devs to change their #include statements to add that path (#include 
kde4support/kfoo.h instead of #include kfoo.h).

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

Re: Qt5 Port Status

[René J . V . Bertin]

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 
  ^^^
I guess that you could use macros or something similar to fold those different 
areas to a single one after the conversion?

 Note that you cannot have both a kde4 and a kf5 development system unless 
 you do some weird stuff. I found opensuse 13.2 the easiest platform to 

Does that mean that the KDE (4 and 5) headers are not conceived to co-exist 
(the libraries are, I'd presume) or else, why is that?
If in general one cannot have a system that allows you to build KDE4 
applications as well as KF5 applications that's something we're going to want 
to know and deal with (as soon and as far as possible) in MacPorts ...

 setup, even so, it took quite a bit of effort to get all the kf5 libraries 
 installed with their devel packages.

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

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

[René J . V . Bertin]

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 you're right from what I can tell. 
The fact that dlopen and friends are now part of the system libraries made me 
forget completely about the unloading peculiarity, and the efforts I put into 
making plugins for my own pet project unloadable. Not that I ever actually use 
the feature, but what can be loaded should also be unloadable, eh? :)

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