[KDE/Mac] Repository for patches to fix KDE Problems on OS X
mk-lists at email.de
Fri Jun 27 07:24:51 UTC 2014
On 27 Jun 2014, at 05:03 , Ian Wadham <iandw.au at gmail.com> wrote:
> That's an interesting and far-reaching observation, Marko.
that’s what I thought as well…
> I have been developing KDE apps on MacPorts for about three years now
> and had always assumed that Dr Konqi was automatically on the dependency
> list for KDE apps. It *is* so in a Linux desktop. Dr Konqi kept failing to run
> properly whenever my tests would crash and was a long-running source
> of annoyance for me.
Same for me.
> But now I find:
> Tara:~>port rdependents kde4-runtime
> The following ports are dependent on kde4-runtime:
> And neither kde4-baseapps nor kde4-runtime are on my "requested"
> list, so it must have been good old kmymoney4 that has been getting
> me Dr Konqi all along … :-)
Yep, I included kde4-runtime at some stage, because I was missing some
functionality in KMM back then - i.e. more than 3 years ago:
$ svn log -r 76233
r76233 | mk at macports.org | 2011-02-19 02:51:22 +0100 (Sat, 19 Feb 2011) | 2 lines
kmymoney4(-devel): require kdebase4-runtime as dependency
I think it had to do with some standard settings of the KDE infrastructure
which KMM relies on and which were mis- or probably rather still UNconfigured
making this necessary. (Too bad I wasn’t a little more verbose back than!)
> Which raises the question of what do Macports users usually see when
> a KDE app crashes? An Apple OS X backtrace? Sudden death followed
> by mysterious disappearance into that great bit-bucket in the sky? An
> invitation to tell Apple all about it? … ;-)
> That is why KDE developers often ask for a backtrace when you report
> a bug on bugs.kde.org. They need to know the exact spot where the
> problem arose. And it is why I gave priority to investigating problems
> with Dr Konqi and KCrash (which is part of kdelibs4).
I highly appreciate your efforts there! I meant to comment on that already
2 weeks ago, but my time was very limited, since holidays with my daughter
had higher priority! :)
> When a KDE app crashes, it is supposed to run Dr Konqi and there is
> a button in Dr K to get a backtrace, if you are a developer. There is also a
> bug-reporting dialog in Dr Konqi that prompts an end-user for details of
> how the crash occurred and automatically raises a report on bugs.kde.org,
> appending the backtrace details.
Yes, the bug reporting dialog also crossed my ways…
> I got this entire sequence to work a few days ago. See
> https://bugs.kde.org/show_bug.cgi?id=336075#c3 … :-) and I now
> have to find out how to make it work every time. Ditto for the Help->
> Report Bug… menu item in every KDE app. I got it to work once,
> but in that case I do not really know why or what I did right… :-(
… which is why I can give you some support on that front. Check out posts
around  for more info, where it turned out that the web browser
configuration is actually responsible for this mess!
> Re making kde4-runtime an automatic dependency of every KDE
> app in MacPorts, that would be an overkill IMHO. It *is* a dependency
> in a KDE desktop on Linux, but there is a lot of stuff in it that would be
> irrelevant in Apple OS X, see the list in:
I see, but there was more than one good reason to include it as a dependency
back than for KMM, so I guess it would be a better idea to make other KDE
software ports also depend on it.
> I need to at least finish working on getting the KDE bug dialogs to
See above. :)
> and then we could patch kdelibs4 and kde4-runtime in MacPorts.
> Maybe, as a quick fix, we could then declare kde4-runtime as a
> dependency of all KDE apps, depending on what comes out of my
> further investigations and what Nicolas and Bradley think.
Yup, sounds like a good idea.
More information about the kde-mac