[KDE/Mac] Bug reporting in KDE on Apple OS X

[Ian Wadham]

On 01/07/2014, at 7:04 PM, Boudewijn Rempt wrote:

> On Monday 30 June 2014 Jun 21:44:56 Ian Wadham wrote:
> 
>> I am thinking of bypassing the need for kded4 in Dr Konqi at least,
>> otherwise we cannot be sure Dr Konqi will run properly after a crash
>> and make it possible to report KDE bugs from Apple platforms.
> 
> Well, my problem here is that Dr Konqui is most useful if you're also shipping
> debug symbols. For Krita, that's not something I intend to do, so I might actually
> extend the use of Google Breakpad -- we already do that on Windows.

https://code.google.com/p/google-breakpad/wiki/GettingStartedWithBreakpad
That's really elegant.  I wonder if MacPorts could build something like that
into every port.  Have a look MacPorts developers!

>> DBus we are comfortable with in MacPorts.
>> 
>> Did you see my post on kde-devel re kded4?  Do you know the answers
>> to my questions?  So far no response… :-{
> 
> When I was focusing on Windows I had the same problem with kded4, and I just remove it. That broke Dr Konqui, but then, on Windows that wasn't all that useful anyway. I had to make a couple of really tough decisions and I find I'm in the same position now on OSX: I want to make a package of Krita that conforms to what the regular users expect, so I just cannot have any daemon running. I cannot even have kbuildsycoca4 run after installation, because that's not what Mac users expect.
> 
> So right now I'm working on an alternative way of locating and loading plugins. Good exercise, I guess, for the Qt5 port. What I don't get, yet, is the difference between running "bla.app/Contents/MacOS/bla" and "open bla.app"…

Well it's like the naked electron of Quantum Field Theory versus the "clothed"
electron we encounter in real life… :-)  Speaking seriously, you can get away
with "bla.app/Contents/MacOS/bla" a lot of the time when you are testing, but
"open" is how an OS X app starts when a user clicks it.  Basically OS X and
iOS like to make a "bundle" of everything an app needs, in one directory
structure <appname>.app, rather than scattering files around as in KDE.

As an example of Linux v. Apple style, when I was working on Palapeli,
I could use Linux-style to load and solve jigsaw puzzles, but it would crash if
if I needed to create a puzzle.  Slicer plugins were failing to load.  One day
I discovered that it would all work fine if I used "open", with stdout and stderr
going to system logs, which you can view with Apple's Utilities Console app.

See [1] for a good overview and [2] for the doco.  CMake builds a very basic
bundle for each KDE app, but you may like to look further re Krita.  The .plist
file, for example, has XML tags for things like default command-line options
and parameters.

>>> This is the repo I use:
>>> 
>>> git://anongit.kde.org/clones/kdelibs/rempt/kdelibs-stripped.git
>>> 
>>> branch: stripped
>> 
>> I cloned that and had a look, but found only branch "master".  However
>> there are certainly hundreds and thousands of diffs.
> 
> http://quickgit.kde.org/?p=clones%2Fkdelibs%2Frempt%2Fkdelibs-stripped.git&a=shortlog&h=42379c18b2923a94db337a7adb2c060304b63a82

Thanks, Boudewijn.

> I've also noticed a weird bug in kservice, where the type of the variant for custom desktop file keys isn't inferred correctly. That's to say service->property("X-KDE-bla") return nothing unless you specifiy the type like this: service->property("X-KDE-bla", QVariant::StringList)
> 
>> 
>>> It also removes a host of other things I don't  need for krita, so it isn't immediately reusable.
>>> For instance, no plasma, no kparts, ssl is hacked out…
>> 
>> I think we need some "pruning" of KDE in MacPorts, but I do not have
>> much idea what as yet.  It would help if KDE 4 had some architecture
>> documentation, but I have never been able to find any.  And I have
>> never really understood what KParts are or why we need them.
> 
> well, kparts were originally KDE's answer to Microsoft's OLE architecture. They were meant to build compound documents -- so you'd have a text document kpart that would embed a spreadsheet document kpart. That sort of extended into a generic document + gui embeddable object thing. We no longer use it in Calligra, even though it was originally designed for KOffice by Reginald Stadlbauer. There is a big disadvantage to kparts in that it ties together the qwidget-based gui and the document: load the document and you get the gui with it.

Ah, thanks again.  That puts it in perspective.

>> I gather you must have an Apple machine for testing.  Are you able to
>> help us?
> 
> Yes, I've got a small and slow macmini. I'm not sure I dare install macports on it,
> though, because I'm afraid it might interfere with my regular builds.

Well, if you are feeling adventurous, have a look at README_FIRST in
http://quickgit.kde.org/?p=osx-patches.git&a=tree     # Item KDEMacPortsTools
https://projects.kde.org/projects/playground/base/osx-patches/repository
https://projects.kde.org/projects/playground/base/osx-patches/repository/revisions/master/show/KDEMacPortsTools

Maybe you can suggest some improvements… :-)

>> Will you put Krita on the App Store?  Heh, heh… ;-)
> 
> If the rest of the krita community is fine with that, I might actually do that. I've also created
> the Krita Foundation to fund Krita development, so we've got a full-time developer on Krita
> now, and I would like to extend that.

Apple is big in Arts applications, so maybe the App Store will be a good location for you.

Cheers, Ian W.

[1] http://en.wikipedia.org/wiki/Application_bundle
[2] https://developer.apple.com/library/mac/documentation/corefoundation/conceptual/cfbundles/Introduction/Introduction.html