from:"Marko Käning"

Re: [KDE/Mac] Multiplatform frameworks

2015-03-02 Thread Marko Käning

Hi Ian,

On 02 Mar 2015, at 03:30 , Ian Wadham iandw...@gmail.com wrote:
 I am talking about regular apps, not Frameworks, but I am glad that 
 Frameworks'
 doctools is inserting the kf5/ subdir.

 But also I expect /Library/Application Support/kxmlgui5/“,

 If I have understood [2] correctly (BTW there seems to be a misprint under 
 KXMLGUI5DIR),
 it seems to me that kxmlgui5/, applications/ and icons/, *whatever* 
 they contain, would
 be out-of-place [3] in /Library/Application Support/ because they are not 
 apps.  

I remember to have had discussions about these locations with David a while ago
on KDE-MAC…

I recall him also pointing out that some apps might not be KDE-based, but using
KF5 libs back then, which complicates things even more.

Yes, I always also wondered about how all this could be kept consistent in an
Apple-ish manner in the light of KF5 apps also having stuff in kxmlgui5…

Greets,
Marko



P.S.: When starting off with OSX/CI I wanted to do everything OSX-compliantly, 
but
after all saw that I would get nowhere if I tried to do this monster-undertaking
all on my own. As you know, I finally had to come up with an OSX/CI system which
uses almost the same folder structure like KDE's Linux build slaves. (Except the
application install location in /Applications/KF5/ everything looks like on 
Linux.)

Re: Review Request 121390: make Qt5 theme build on Linux again

2015-03-01 Thread Marko Käning

On Dec. 8, 2014, 3:07 p.m., Martin Gräßlin wrote:
this is wrong - please have a look at various frameworks on how to do it
properly. In the end it should be:
#if HAVE_X11
// x11 specific stuff
#endif

obviously it also needs a runtime check:
if (QX11Info::isPlatformX11())

as we no longer should assume that X11 is the only platform on Unix(non
OSX).

René J.V. Bertin wrote:
I found a reference to HAVE_X11 online, but that token is not defined.
Note also that the Qt5 theme is supposed to build without KF5 too, for pure
Qt5 applications, so this kind of token should rather be provided by the Qt
cmake files rather than KDE's.

I'll leave the runtime checks to the QtCurve devs, as they obviously
should be made in lots of locations and it's their call. I myself don't see
the point in doing a runtime check whether a platform is X11, though. It's
known at build time if a platform is X11. Doing a runtime check before each
theming action if `Q11Info::isX11Active()` (or some such call) seems to be an
expensive concession to a rather improbable set-up. If distros really decide
to give the user a choice between X11 and Wayland at login ... let them
figure out how to streamline that first, and then add runtime checks for the
active graphics backend where really needed...
(In fact, I myself would avoid anything tied to the display layer as much
as possible; the fact I had to go back in a few months after the previous
porting effort goes to show how easy it is to break builds on other platforms
with that kind of functionality - as if my own error wasn't enough already.)

Martin Gräßlin wrote:
HAVE_X11 is neither defined by Qt5 nor by KF5. It needs to be set
manually depending on whether the source is built with or without X11 support.

Concerning the runtime check:
kwrite -platform wayland

and your app is going to crash like hell if there is no runtime checks.

René J.V. Bertin wrote:
``` neon5-exec /opt/project-neon5/bin/kwrite -platform wayland
This application failed to start because it could not find or load the Qt
platform plugin wayland.

Available platform plugins are: linuxfb, minimal, offscreen, xcb.

Reinstalling the application may fix this problem.
Abort (core dumped)
```

Right, so with runtime checks it doesn't crash, it just self-destructs.
Very useful difference :)
Of course an application will crash if it tries to use an unavailable
displaying method, or if the linker tries to load shared libraries that
aren't present. In fact, with X11 it might actually exit nicely with a
message about a display rather than crash.

This just underlines my point: the only use for runtime checks in this
context if is the same binaries are supposed to work with multiple displaying
backends (or platform plugins). Whether QtCurve ought to support that is a
call for its developers to make, like I said above. The only way to do that
properly without (too much) overhead is to do the check at initialisation
time rather than preceding each backend-specific call, i.e. use
functionpointers or some OO/C++ alternative. I don't know how preferable
Wayland is to X11; without that I see only an interest for people working on
Wayland development under X11 for this kind of runtime switch support.
To put this into context: I've often thought how it'd be nice if Qt-mac
would be able to use X11, but I've always dismissed the possibility that that
might be a runtime switch, exactly because it would introduce too much
overhead and/or complexity for a feature that'd be used only rarely.

Thomas Lübking wrote:
Right, so with runtime checks it doesn't crash, it just self-destructs.

You're missing the point entirely. The compile time checks have no
implication on the runtime environment.
Of course you cannot use the wayland platform plugin if it's not
available, but you *can* compile Qt/KDE w/ X11 and wayland present - but
making X11 calls when running on the wayland PP will crash the application -
thus you must check whether you're operating on X11/xdg at runtime.

Also testing for UNIX but not OSX to make X11 calls is plain wrong.
Could be framebuffer console or wayland and no X11 installed at all.

Martin Gräßlin wrote:
for more information please see my blog post:
http://blog.martin-graesslin.com/blog/2014/02/running-frameworks-powered-applications-on-wayland/

Btw. the QtWayland PPA will be available starting with Qt 5.4 - a version
I'm already using.

René J.V. Bertin wrote:
@Thomas: we're not talking about compile time checks. Those evidently
don't have any implication on the runtime environment (if done correctly :)).
I guess my point is simply that the fact that you can (= it's possible
to) compile Qt/KDE with every conceivable display/rendering

Re: Review Request 121390: make Qt5 theme build on Linux again

2015-03-01 Thread Marko Käning

 engine present 
 doesn't mean that indidual KDE applications or plugins can no longer decide 
 to support only a subset to be set at build time. *)
 
 No issue either with Unix but not OS X - that's what I came up with for 
 lack of something better. Turns out Yichao has his own alternative to 
 HAVE_X11, I'll see if I can make do with that.
 
 *) or else I'll start making a ruckus to have kwin and more Plasma 
 goodies on OS X!! ;)
 
 Martin Gräßlin wrote:
 Yes, it's not about compile time checks, it's about introducing runtime 
 checks as Thomas and I wrote ;-)
 
 René J.V. Bertin wrote:
 Actually, Thomas wrote The compile time checks have no implication on 
 the runtime. Surely a typo, but those can have devastating consequences 
 around code ;)
 
 René J.V. Bertin wrote:
 (published too fast again)
 
 Actually, that blog post of yours also starts out by talking exclusively 
 about compile-time checks for about 2/3 of its length. It's only after the 
 screenshot that it becomes clear you actually use the compile-time check to 
 include a runtime-check or not. A casual reader might be tempted to stop 
 reading early, thinking he got the message ...
 
 And I can't stop thinking something that has been stamped into me: ifs 
 are expensive. Guess that shows my age ...
 
 Thomas Lübking wrote:
 That's not a typo. Meaning distorting partial quote.
 I wrote:
 The compile time checks have no implication on the runtime 
 *environment*.
 
 Ifs are expensive might be stamped into your mind and/or true, but 
 they're completely inavoidable in this context.
 
 Just that X11 was available at runtime does NOT (no more w/ Qt5) mean 
 that it's available at runtime.
 = Keep the branching out of hot loops (as always) ;-)
 
 René J.V. Bertin wrote:
 yes, I know I didn't copy the last word of your statement. That doesn't 
 change the fact that your 2nd word was *compile* instead of *run*, in a 
 context where you (at least) seemed to be saying that I apparently claimed 
 that those (= compile time) checks had an impact on runtime performance.
 
 Anyway, yes, I understood perfectly well that X11 might not be available 
 at runtime while it was when compiling, and that an application trying to do 
 X11 calls will exit with an error when trying to connect to an inexisting X11 
 server. (Or crash if X11 was actually uninstalled ... but it would take other 
 runtime checks to protect against that, and frankly that'd just be crazy.)
 
  Ifs are expensive might be stamped into your mind and/or true, but 
 they're completely inavoidable in this context.
 
 Not true, see my remarks about using function pointers above. Not that 
 that would be particularly clever and less expensive when X11 is the only 
 platform that provides a certain functionality ... :)
 (I do seem to recall that using function pointers instead of normal 
 functions was hardly more expensive on x86)
 
 Yichao Yu wrote:
 Sorry somehow my filter missed this review request and I've just seen it 
 today...
 
 To answer Martin's concern, I totally agree and it's in my mind the first 
 time I added X11 support back to the Qt5 version. The X11 related stuff in 
 `libqtcurve-utils` have also always had that check. All X11 related functions 
 are guarded by both a compile time check (e.g. if libxcb/X11 is not found or 
 somehow the user simply don't want to link to them...) and a runtime check 
 (i.e. the X11 related functions are no-ops if X11 is not initialized first at 
 runtime).
 
 Now (AFAIK) the compile failure on OSX seems to be related to some 
 sturture name conflict (or whatever it is that causes a forward declaration 
 of `Display` not working...). The real issue is already addressed in another 
 review request and it is not necessary to disable calls to X11 related 
 functions (which might be no-ops) on OSX anymore.
 
 In any case, the issue related to this request should already be resolved 
 now and the status is also monitored on build.kde.org (and AFAIK both Qt4 and 
 Qt5 versions build successfully now). I think this review request can be 
 discarded.
 
 Marko Käning wrote:
 Just for the record, QtCurve currently fails to build on OSX/CI:
 
 
 /Users/marko/WC/KDECI-builds/kf5-qt5/qtcurve/qt5/config/qtcurveconfig.cpp:1085:
  Warning: Macro argument mismatch.
 In file included from 
 /Users/marko/WC/KDECI-builds/kf5-qt5/qtcurve/lib/utils/dirs.cpp:22:
 /Users/marko/WC/KDECI-builds/kf5-qt5/qtcurve/lib/utils/dirs.h:68:1: 
 error: implicit instantiation of undefined template 
 'std::__1::basic_stringchar, std::__1::char_traitschar, std::__1::
 allocatorchar '
 getConfFile(const std::string file)
 ^
 
 Shall I send the full build log of this failure to you via PM?
 
 Marko Käning wrote:
 For completeness: I haven't THIS RR applied to my OSX/CI system as of 
 now

Re: Review Request 119363: Port kde-baseapps to use docbook 4.5

2015-02-28 Thread Marko Käning


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

(Updated Feb. 28, 2015, 10:51 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Base Apps, Luigi Toscano and Nicolás Alvarez.


Repository: kde-baseapps


Description
---

This suggests to upgrade the docbook DTD from 4.2 to 4.5.

---

There is still an open issue here:

 Spaces in DATA_INSTALL_DIR need to be handled properly, so that the path in 
the DTD file

/Library/Application\ Support/kf5/kdoctools/customization/dtd/kdex.dtd

 is correctly set, i.e. using %20 instead of a space.


Diffs
-

  doc/konqueror/index.docbook a1f8565404be0289b51af37df1687e0911a01fe5 
  dolphin/docs/index.docbook 5fe85f5d130e3723af556fb02b53970206d1c765 
  kdepasswd/docs/index.docbook 2ecef470ac8a9384b7aeb16f123f834d040ee375 
  kfind/docs/index.docbook d46dfa4138991a356eec32a7043a883150eb81c2 
  kfind/docs/man-kfind.1.docbook ef2eb3b9fb1ed1a84ae33fa631b0295a029444e0 

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


Testing
---

Builds/installs fine (if one doesn't use any white-space in DATA_INSTALL_DIR 
path) 


Thanks,

Marko Käning

Re: Review Request 122556: Bump Qt version to 5.4

2015-02-13 Thread Marko Käning


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


I'd vote for keeping it compatible to Qt 5.3, if that's possible.

- Marko Käning


On Feb. 13, 2015, 9:06 a.m., Arjun AK wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/122556/
 ---
 
 (Updated Feb. 13, 2015, 9:06 a.m.)
 
 
 Review request for KDE Base Apps.
 
 
 Repository: kde-baseapps
 
 
 Description
 ---
 
 `QUrl::fromUserInput(userInput, workingDirectory, UserInputResolutionOptions 
 options)` seems to be Qt 5.4+. We either need to bump requirement to 5.4 or 
 do what kompare 
 [did](https://projects.kde.org/projects/kde/kdesdk/kompare/repository/revisions/master/entry/libdialogpages/diffpage.cpp#L45)
 
 
 Diffs
 -
 
   CMakeLists.txt 6df9015 
 
 Diff: https://git.reviewboard.kde.org/r/122556/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Arjun AK

Re: Review Request 121805: kconfig: fix building when KDE_INSTALL_DIRS_NO_DEPRECATED is set

2015-01-05 Thread Marko Käning


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

Ship it!


Thanks for fixing this, Jeremy! :)

- Marko Käning


On Jan. 3, 2015, 3:20 nachm., Jeremy Whiting wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/121805/
 ---
 
 (Updated Jan. 3, 2015, 3:20 nachm.)
 
 
 Review request for kdelibs and Marko Käning.
 
 
 Repository: kconfig
 
 
 Description
 ---
 
 Use KF5_INSTALL_TARGETS_DEFAULT_ARGS so kconfig will configure when 
 KDE_INSTALL_DIRS_NO_DEPRECATED is set.
 
 
 Diffs
 -
 
   src/kreadconfig/CMakeLists.txt 3804e16 
 
 Diff: https://git.reviewboard.kde.org/r/121805/diff/
 
 
 Testing
 ---
 
 It builds again on osx where it didn't previously.
 
 
 Thanks,
 
 Jeremy Whiting

Re: Review Request 120149: [OS X] improved menubar experience: protected Preferences menu and cleaner system tray

2014-11-29 Thread Marko Käning


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


Is this not yet committed to KDE?

- Marko Käning


On Sept. 25, 2014, 4:03 p.m., René J.V. Bertin wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/120149/
 ---
 
 (Updated Sept. 25, 2014, 4:03 p.m.)
 
 
 Review request for KDE Software on Mac OS X, kdelibs, KDEPIM, Qt KDE, Marco 
 Martin, and Olivier Goffart.
 
 
 Repository: kdelibs
 
 
 Description
 ---
 
 This review is for 2 sets of changes; an initial one to the way system tray 
 are rendered, and a newer set that protects the Preferences menu from getting 
 linked to any action with an appropriate title.
 
 -- the system tray:
 Until now, system tray menus had some rendering issues on Mac OS X:
 
 - The menu title, the 1st menu item that on Linux shows the application name, 
 remained empty
 - Menu items that can (in principle, potentially) show an icon always showed 
 the icon
 
 Point 1 was resolved by emulating the Linux addTitle/setTitle action in 
 `KStatusNotifierItemPrivate::init()` : the menu title is implemented as a 
 deactive standard menuitem followed by a separator. This makes the item stand 
 out on a GUI that doesn't support the kind of formatting in menus as used in 
 the Linux implementation.
 
 Point 2 was identified as a Qt issue: `isIconVisibleInMenu` is ignored for 
 systray menus. It was resolved by adding `KMenu::addAction` methods that 
 overload the ones from QMenu that were hitherto inherited unchanged by KMenu. 
 The only different method is `addAction(QAction*)` which removes the icon 
 from the `QAction` if `isIconVisibleInMenu()` is false. The other `addAction` 
 methods are overloaded with themselves with `using QMenu::addAction;` in 
 the header file.
 
 -- the Preferences menu item
 This is a menu item living in the Application menu, a menu that sits in the 
 menubar between the Apple (?) menu and the File menu. This menu also contains 
 the Quit command.
 KDE and Qt applications typically do not set up their menus in this fashion, 
 so Qt provides an automatic way to put relevant menu items (actions) in the 
 Application menu, using Apple's naming. The algorithm is described under 
 QMenuBar in the Qt documentation: for the Preferences action, it will 
 consider any action that has a text containing `config`, `options`, 
 `settings` or `preferences`, and put it under the Preferences label if its 
 menu role is set to `heuristic` (which appears to be the default).
 In practice, many applications provide a series of menu actions with names 
 that trigger this method, and they do not always create their own 
 preferences/settings/configuration menu first. Yet it is the first menu 
 action that matches that will be installed under the Preferences menu, with 
 the Command-, shortcut. A good example is KDevelop: it will have a 
 Preferences menu that activates the `Configure Selection` action - which does 
 not open a settings dialog but launches the configure or cmake procedure for 
 the selected project ...
 
 My proposed solution overrides this Qt behaviour. On OS X, the `KAction(const 
 QString text, QObject *parent)` constructor calls a modified (static) 
 function `setTextWithCorrectMenuRole` which checks the text against the 
 patterns Qt will consider for `PreferencesRole`. If it finds a match, it will 
 force the role to `NoRole`, unless it is a perfect match with the standard 
 KDE configuration action for the application (`Configuration appName...`) 
 in which case it sets the role to `PreferencesRole`. This latter 
 consideration allows kdelibs to catch the configuration menu for 
 applications like KMail, which appear not to be created using 
 KStandardActions.
 This approach can be extended to other menu actions that end up incorrectly 
 in the OS X Application menu.
 
 Applications that create menu actions using QAction or a different KAction 
 constructor will see no change (and should use `setMenuRole` selectively on 
 OS X).
 
 
 Diffs
 -
 
   kdeui/notifications/kstatusnotifieritem.cpp 1b15d40 
   kdeui/actions/kaction.cpp 9e8f7fb 
 
 Diff: https://git.reviewboard.kde.org/r/120149/diff/
 
 
 Testing
 ---
 
 Testing was done with kdelibs git/master and KDE/MacPorts on OS X 10.6.8 . 
 The modified code is in compile-time conditional blocks used only on OS X, so 
 no regressions are to be expected on other platforms.
 
 KF5 is not production ready on OS X, so I am not currently able to port these 
 modifications beyond KDE4. However, I did see that Qt5 has a new approach to 
 adding titles to menus, which can be described as a labelled separator. 
 Backporting that function from the Qt5

Re: KDE-CI IRC meeting - Your possible KDE contributions in non-C++

2014-11-25 Thread Marko Käning

Hi Mario,

thanks for organizing this!

 Prospective agenda for the IRC meeting:
 - Ben: Short introduction to KDE CI
 - Everybody: Short introduction incl. their skills and wishes for KDE CI
 - Ben: What needs to be changed
 - Everybody: Work on a roadmap and distribute work till next meeting
 - Everybody: Determine date for the next IRC meeting

I could give a short presentation about my OSX/CI system and describe where
I'd need support. Hey, we should go through our list of topics for the IRC
meetings, which we created months ago! :-)

Greets,
Marko

P.S.: I already see that Jeremy has a shifted time-slot wrt me. I'll have
  to check whether I can make it 3pm my time some day. The bigger problem
  will be to synchronize with Ben...

Re: Severe behavioural change regressions in release branch

2014-10-26 Thread Marko Käning

 Earlier this year, I was working on lots of performance metrics of CMake
 and this was part of it. There ended up being more than a dozen branches
 resulting from that work (some of them still unmerged). Doing some
 digging shows that this is where the commit finally hit master:
 
 commit bd20dd6b8a925a421167602027fff9b904fd0822
 Merge: b041fc1 e17a69b
 Author: Brad King brad.k...@kitware.com
 Date:   Thu Jun 12 11:28:44 2014 -0400

Yep, I can verify that I had to use on OSX/CI the version from June 3rd for 
quite
a while, since that was the only one which would give me the desired builds.

Greets,
Marko

Re: Review Request 120431: Fix and future-proof Dr Konqi security methods on Bugzilla

2014-10-06 Thread Marko Käning



 On Oct. 5, 2014, 9:43 a.m., Ben Cooksley wrote:
  As this is needed to restore the functionality of Dr Konqi, can someone 
  familiar with the codebase please review it so we can get this in?
 
 Ian Wadham wrote:
 Perhaps I am the person most familiar with the codebase of Dr Konqi, 
 having worked on it for a few months now.
 
 So, if nobody else steps forward within the next 24 hours, I will do my 
 own Ship It and commit to KDE 4 kde-runtime master in time for Thursday's 
 close of the KDE 4.14.2 bugfix release.
 
 If KDE core developers want the Dr Konqi bugs fixed in KF5, they will 
 have to forward-port this change and my earlier changes themselves. I cannot 
 do that. I work on Apple OS X and we do not have KF5 and Qt 5 building there 
 yet.
 
 I do not propose to address Thomas's comments. I have more important 
 things to do.
 
 Albert Astals Cid wrote:
 With my release team hat:
  - Sure commit to master if you can't find someone else to review and you 
 *know* your code is right and you're going to fix it when/if it break
  - No, don't commit to KDE/4.14 this is a huge change and I 
 don't feel like it is guaranteed to go in, you can be a good guy and review 
 https://git.reviewboard.kde.org/r/120376/ since it seems that one fixes the 
 immediate problems people are having, no? (you say you're the one that knows 
 the code more yet have not reviewed it, why?)
  - Your obsession to not contribute to KF5 based versions will byte you 
 again when you decide to move to KF5, you should really rethink it. Because  
 we do have KF5 and Qt5 building on MacOsX according to at least one of the 
 members of the MacOSX team, no?

I wouldn not phrase it an obsession to not to contribute to KF5. ;)

In fact, it has been pointed out multiple times on KDE-MAC, in pm as well as in 
various RRs, that the MacOSX team at the moment mainly tries to get KDE4 into 
a working state, which is why Ian wants to push this forward.

And yes, we have KF5 on Qt5 in a state where my OSX/CI(/Jenkins) systems are 
able to build and install many projects successfully.
BUT, unfortunately, this does NOT mean that I am able to RUN every of these 
apps successfully, as the OSX/CI system's specifics (being that all frameworks, 
libs and apps live in their own install roots) in conjunction with a (still 
missing) working QStandardPaths patch lead to the problem that most of the apps 
can't find their config and data files at runtime at this point in time. :(

As I am *alone* on KF5, I haven't managed to proceed with the QStandardPaths 
issue, since many other things kept me far too busy (like the inclusion of new 
projects on OSX/CI, dealing with Jenkins master [also for Linux], tending 
project dependencies, creating a KDE4.13 branch on our macports-kde git repo, 
testing KDE4 applications, etc...).

Eventually I conclude herewith that the MacOSX team:

- does contribute directly to Qt5/KF5 big time - althought it is only me ATM,

- does indirectly contribute to Qt5/KF5, as many RRs can be modified easily for 
inclusion into KF5, as it has happened already for e.g. 
https://git.reviewboard.kde.org/r/119847/ and 
https://git.reviewboard.kde.org/r/119848/ 

- believes that 1st priority should be to get KDE4 in good shape on OSX, which 
is why Nicolas wants to release KDE 4.13.3 this week and will proceed with 
4.14.x right afterwards,
 
- needs decent user feedback with valuable backtraces which is why a 
non-dysfunctional DrKonqi is required on all OSX versions, hence this RR.


- Marko


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


On Oct. 5, 2014, 6:27 a.m., Ian Wadham wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/120431/
 ---
 
 (Updated Oct. 5, 2014, 6:27 a.m.)
 
 
 Review request for KDE Software on Mac OS X, KDE Runtime and Ben Cooksley.
 
 
 Bugs: 337742
 http://bugs.kde.org/show_bug.cgi?id=337742
 
 
 Repository: kde-runtime
 
 
 Description
 ---
 
 When bugs.kde.org changed over to Bugzilla 4.4.5 in July 2014, the security 
 method used by Bugzilla changed from cookies to tokens that had to be 
 supplied as parameters with every secure remote-procedure call. Further 
 changes to security methods have been announced by Bugzilla and are 
 documented for unstable 4.5.x versions of Bugzilla software. Tokens will be 
 deprecated and then discontinued. When this happens, Dr Konqi will need to 
 supply a user-login name and a password with every secure remote-procedure 
 call. Furthermore, the traditional User.login call presently used by Dr 
 Konqi will be deprecated and discontinued.
 
 This patch fixes

Re: Review Request 120363: proposal to use the NOGUI switch in CMake files to set the default value for GUIenabled

2014-10-04 Thread Marko Käning


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


See also bug 334174

- Marko Käning


On Sept. 25, 2014, 3:32 p.m., René J.V. Bertin wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/120363/
 ---
 
 (Updated Sept. 25, 2014, 3:32 p.m.)
 
 
 Review request for KDE Software on Mac OS X and kdelibs.
 
 
 Repository: kdelibs
 
 
 Description
 ---
 
 Applications can be defined in their CMake file as being `NOGUI`, but until 
 now this has had very limited effect. Especially on OS X, those applications 
 can still construct a minimal GUI and thus have visual presence in the Dock 
 and application switcher (and have a menubar as well).
 
 This patch proposes to define a preprocessor token, `KDE_WITHOUT_GUI`, for 
 those targets, and uses that token to set the default value for the 
 `GUIenabled` option of the `KApplication` and `KUniqueApplication` classes.
 
 This could potentially be combined on OS X with the CoreFoundation call that 
 turns a running application into an agent (see 
 https://git.reviewboard.kde.org/r/120354).
 
 
 Diffs
 -
 
   cmake/modules/KDE4Macros.cmake 073d726 
   kdeui/kernel/kapplication.h fa2ab26 
   kdeui/kernel/kapplication.cpp b093034 
   kdeui/kernel/kuniqueapplication.h e05dcd7 
 
 Diff: https://git.reviewboard.kde.org/r/120363/diff/
 
 
 Testing
 ---
 
 On OS X 10.6.8 with kdelibs 4.14.1 (git/kde4.14), rebuilt kdelibs, 
 kde-workspace, kde-runtime, kde-baseapps, kdepim-runtime and nepomuk-core.
 If the documentation I read is correct, the `GUIenabled` switch has no effect 
 on Linux, so this patch shouldn't have any either on that OS.
 
 
 Thanks,
 
 René J.V. Bertin

Re: Review Request 120363: proposal to use the NOGUI switch in CMake files to set the default value for GUIenabled

2014-09-27 Thread Marko Käning

Hi Thiago,

On 26 Sep 2014, at 07:01 , Thiago Macieira thi...@kde.org wrote:
 And still it needs to be studied for Qt5, unless the plan is to never 
 transition to Qt 5 (which means KDE-on-Mac will stop compiling within 2 
 years).

did you miss our efforts on KF5 including setting up an OSX/CI system [1]?

René has also produced patches for KF5 frameworks, which my OSX/CI system
could prove to be buildable already. :-)

So, we’re aware of it, but René is up to now focusing more on cleaning up
KDE4, since we’re not yet there with any KF5 ports on MacPorts. But we’re
getting there these days. :-D

Greets,
Marko



[1] https://trac.macports.org/wiki/KDEProblems/KDEMacPortsCI/Status

Re: Review Request 112991: Fix compilation rules of KDE-Workspace under OSX/Macports

2014-09-21 Thread Marko Käning

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

Thanks, Gilles, for letting us know, that this is covered anew by
https://git.reviewboard.kde.org/r/120287/ !

Please join our discussions on MacPorts-devel and KDE-MAC mailing lists.

Greets, Marko

- Marko Käning

On Oct. 26, 2013, 6:57 a.m., Gilles Caulier wrote:

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

(Updated Oct. 26, 2013, 6:57 a.m.)

Review request for kde-workspace.

Bugs: https://trac.macports.org/ticket/33780
http://bugs.kde.org/show_bug.cgi?id=https://trac.macports.org/ticket/33780

Repository: kde-workspace

Description
---

This patch fix broken compilation under OSX / macports about kde-workspace.

Patch do not touch implementation. Only compilation rules are changed in
cmake script to follow the way way than Windows rules, where no X11 lib are
available.

By this way, Oxygen is compiled and installed to macport and digiKam has a
suitable GUI under OSX.

See my Macports bug report for details :
https://trac.macports.org/ticket/33780

Gilles Caulier

Diffs
-

CMakeLists.txt c37ab8b
kcontrol/CMakeLists.txt a25aaa0
libs/CMakeLists.txt 9d71a03

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

Testing
---

I tested this patch under my macbook pro, using a fresh install of Macports
(KDE 4.11.1 / Qt 4.8.5)

As kde-workspace macports package is broken, i checkout code from KDE
git/master repository and fixed compilation rules as well.

File Attachments

patch to fix compilation rules under OSX with KDE 4.11 branch

https://git.reviewboard.kde.org/media/uploaded/files/2013/10/26/644e987a-967f-44f0-a266-428f4c9b9579__compilerulesOSX-KDE411.patch

Thanks,

Gilles Caulier

Re: Review Request 120287: [OS X] make kde-workspace build

2014-09-20 Thread Marko Käning

On Sept. 20, 2014, 10:20 a.m., Martin Gräßlin wrote:
CMakeLists.txt, lines 225-234
https://git.reviewboard.kde.org/r/120287/diff/3/?file=313626#file313626line225

tabs instead of whitespaces

René J.V. Bertin wrote:
I looked into those yesterday, and cannot find tabs on my end. No idea
where they'd come from.

Martin Gräßlin wrote:
I'd guess the editor you use changes it somehow. I'd suggest to use Kate
and enable show all whitespaces.

René J.V. Bertin wrote:
No, really, those tabs aren't there. I re-reopened the CMakeLists.txt in
vi (which doesn't modify anything unless I ask for it) and there are no tabs
to be found. Same in KDevelop when I open the patch review tool. I wonder if
your editor isn't the culprit, or something on reviewboard?

I copied the .reviewboardrc file from another KDE project and edited the
obvious settings. I see nothing concerning tabs in there, but maybe there
ought to be?

René J.V. Bertin wrote:
See my local copy of the diff I just added.

Thomas Lübking wrote:
There're no tabs in the diff (checked teh only reliable way: okteta ;-)

Indention in those files is crazy (2 or 3 chars, never 4), what makes it
look like WS/tab intermix, but seems only a RB indication that the line
was altered only by shifting.

René J.V. Bertin wrote:
Just a question: would I still have triggered `-pedantic` mode if I had
included something like and relevant code tidy-ups in my RR title? :P

Also, is one supposed to go through an RR for each and every tidy-up one
might want to commit (now that I have commit access ...)?

Thomas Lübking wrote:
You can stuff as many patches (commits) into one review as you like, just
that one patch may delay the ship it to all others than and at some point
ppl. will refuse to look at 3MB of patches at once ;-)

I don't think that pure tidy up commits belong into KDE4 at all, if you
really consider one necessary, better have it reviewed.

For KF5/master you ideally clean up code while editing the area anyway.
Global astyle fixes should only be done when things become too much of a
mess - and be shown to the maintainer.
(Reason is that you introduce fences to git blame)

Reason being that fences to git blame get introduced is a very good point,
indeed! (Never thought of that, actually.)
That's somewhat a problem of the SCM's way of handling the code lines then!
Would be cool if white-space commits could be marked as such, so that git could
omit/bridge them in case of blame...

- Marko

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

On Sept. 20, 2014, 12:54 p.m., René J.V. Bertin wrote:

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

(Updated Sept. 20, 2014, 12:54 p.m.)

Review request for KDE Software on Mac OS X and kde-workspace.

Repository: kde-workspace

Description
---

A few rather straightforward patches to make the relevant bits of KDE4's
kde-workspace build and function on OS X.
The main interest is having the systemsettings control panel to control the
various relevant KDE settings among which desktop search, fonts, colours and
even style.
The oxygen style builds and looks good but shows some updating glitches due
to compositing.

I'm submitting this patch partly in hope it may be useful in bringing
kf5-workspace to OS X, one day.

Diffs
-

CMakeLists.txt 195f99c
kcontrol/CMakeLists.txt fc666b1
kcontrol/krdb/krdb.cpp 36fc99c
kcontrol/style/CMakeLists.txt d832b20
libs/CMakeLists.txt c0576fe

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

Testing
---

On OS X 10.6.8 and 10.9.4 with KDE/MacPorts (4.12.5 and more recently kdelibs
git/master, 4.14.1).

File Attachments

copy of the diff file saved locally, which had no tabs when I uploaded it.
Checksum: 3989cdd46af3c891e570974d66c330403dcd41c4ee5e17a372fa385080cbabd1

https://git.reviewboard.kde.org/media/uploaded/files/2014/09/20/b212730f-6258-4277-851c-226bc0673aa1__patchreview-20140920.patch

Thanks,

René J.V. Bertin

Re: Review Request 119497: Report crashes of KDE apps in Apple OS X (1) (fix kcrash)

2014-09-15 Thread Marko Käning

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

Hi Ian, shall I test this on a Mavericks VM before you're committing this? In
case I shall do it, do you have a test case for me? Greets, Marko

- Marko Käning

On Sept. 15, 2014, 3:59 a.m., Ian Wadham wrote:

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

(Updated Sept. 15, 2014, 3:59 a.m.)

Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and
Michael Pyne.

Repository: kdelibs

Description
---

*NOTE: Issues for KCrash have been fixed. Changes to kinit/kinit.cpp
(kdeinit4) have been discontinued. For a summary, scroll to the very end of
this page.

When a KDE app crashes in Apple OS X, it just disappears from the screen. At
the most, the user is invited to report the crash to Apple. AFAIK this has
been a problem in KDE on Apple OS X for years, leading to frustration with
KDE among Apple users and MacPorts developers and an attitude among KDE
developers of Why does nobody report the problem(s) on bugs.kde.org?

It is my strong belief that the failure to report crashes of KDE apps in
Apple OS X also exists in Frameworks.

So far I have identified a number of portability bugs in KDE on Apple OS X: 1
in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Patches for the first two are
submitted in this review. Patches for three more are submitted in part 2 of
this review, against kde-runtime. I am still investigating the other two
problems in Dr Konqi - and there could be more than two...

In this review we have two portability problems:

1. KCrash itself crashes (SIGILL) when it tries to close all file descriptors
and so Dr Konqi is not started. Some of the FDs belong to the Apple OS X
library (COCOA) and it crashes if they are closed prematurely.

2. The preferred way to start Dr K is via a socket message to kdeinit4, but
that fails in Apple OS X because kdeinit4 is listening with the wrong socket
name. The DISPLAY ID is missing from the end of the name. The fallback is for
KCrash to use fork() and exec(), which works, but could cause Dr K to be
polluted, depending on the nature of the crash.

This deafness of kdeinit4 (and klauncher) could be causing other failures
in KDE software in the Apple OS X environment.

Diffs
-

kdeui/util/kcrash.cpp 45eb46b

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

Testing
---

Using Apple OS X 10.7.5 (Lion) on a MacBook Pro, I have installed KDE libs
via MacPorts (at version 4.12.5) and I have adapted kdesrc-build to run in an
Apple OS X environment and used it to test against the KDE 4.13 branch. I
have been testing with a KDE app that I can crash at will and using stderr
and Apple OS X Console log output to determine the outcome.

Please note that I am the -only- KDE developer who has this kind of setup,
but I am NOT a KDE core developer. My experience before now has been in KDE
Games. However I used to be a UNIX and database guru before I retired in 1998.

I NEED HELP from KDE -core- developers to proceed further. These problems
also exist in FRAMEWORKS, but I am as yet unable to build or test Frameworks
on Apple OS X. And I am sure there are many more Apple OS X portability
problems in KDE software.

Without my patches, Dr Konqi is not started and, if it does get past its own
crash, KCrash reports:
KCrash: Attempting to start
/kdedev/kde4.13/kde4/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from
kdeinit
sock_file=/kdedev/kde4.13/home/.kde4.13/socket-Tara.local/kdeinit4__tmp_launch-svPd0L_org.x_0
Warning: connect() failed: : No such file or directory

With my patches, Dr Konqi can always be started directly (using fork()) and
it -will- start via kdeinit4 and klauncher but it immediately runs into a
privilege problem with Apple OS X (a problem which I am still investigating).

I would not have got this far without help from Michael Pyne, Thomas Lübking
and several of the MacPorts developers, as well as the unfailing enthusiasm
and encouragement of my friend Marko Käning.

Thanks,

Ian Wadham

Re: Review Request 119497: Report crashes of KDE apps in Apple OS X (1) (fix kcrash)

2014-09-15 Thread Marko Käning

On Sept. 15, 2014, 9:26 p.m., Marko Käning wrote:
Hi Ian, shall I test this on a Mavericks VM before you're committing this?
In case I shall do it, do you have a test case for me? Greets, Marko

Ian Wadham wrote:
Thanks, but please wait until I drop the other shoe, review 119498, fix
Dr Konqi.

The test case I use is to start Palapeli (jigsaw puzzle), open any puzzle
and start dragging a piece, then, without letting go of the mouse button, hit
menu item Game-Restart Puzzle. That will cause a crash every time. You need
to set up and use a shortcut key for the Game-Restart Puzzle action (use
Settings-Configure Shortcuts...).

If this depends on issue 119498 it would be good to enter that id in the
Depends On field of this RR, I guess. That makes clearer what has to be
installed to apply this patch cleanly, no?

- Marko

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

On Sept. 15, 2014, 3:59 a.m., Ian Wadham wrote:

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

(Updated Sept. 15, 2014, 3:59 a.m.)

Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and
Michael Pyne.

Repository: kdelibs

Description
---

*NOTE: Issues for KCrash have been fixed. Changes to kinit/kinit.cpp
(kdeinit4) have been discontinued. For a summary, scroll to the very end of
this page.

It is my strong belief that the failure to report crashes of KDE apps in
Apple OS X also exists in Frameworks.

In this review we have two portability problems:

This deafness of kdeinit4 (and klauncher) could be causing other failures
in KDE software in the Apple OS X environment.

Diffs
-

kdeui/util/kcrash.cpp 45eb46b

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

Testing
---

I would not have got this far

Re: Review Request 119497: Report crashes of KDE apps in Apple OS X (1) (fix kcrash)

2014-09-15 Thread Marko Käning

On Sept. 15, 2014, 9:26 p.m., Marko Käning wrote:
Hi Ian, shall I test this on a Mavericks VM before you're committing this?
In case I shall do it, do you have a test case for me? Greets, Marko

Ian Wadham wrote:
Thanks, but please wait until I drop the other shoe, review 119498, fix
Dr Konqi.

Marko Käning wrote:
If this depends on issue 119498 it would be good to enter that id in the
Depends On field of this RR, I guess. That makes clearer what has to be
installed to apply this patch cleanly, no?

Sorry, above I don't mean issue, but review request 119498. :)

- Marko

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

On Sept. 15, 2014, 3:59 a.m., Ian Wadham wrote:

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

(Updated Sept. 15, 2014, 3:59 a.m.)

Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and
Michael Pyne.

Repository: kdelibs

Description
---

*NOTE: Issues for KCrash have been fixed. Changes to kinit/kinit.cpp
(kdeinit4) have been discontinued. For a summary, scroll to the very end of
this page.

It is my strong belief that the failure to report crashes of KDE apps in
Apple OS X also exists in Frameworks.

In this review we have two portability problems:

This deafness of kdeinit4 (and klauncher) could be causing other failures
in KDE software in the Apple OS X environment.

Diffs
-

kdeui/util/kcrash.cpp 45eb46b

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

Testing
---

With my patches, Dr Konqi can always be started directly (using fork()) and
it -will- start via kdeinit4 and klauncher but it immediately runs into a
privilege problem

Re: Review Request 119498: Report crashes of KDE apps in Apple OS X (2) (fix drkonqi)

2014-09-15 Thread Marko Käning

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

And this should be marked as depending on RR 119497 in Depends On.

- Marko Käning

On July 30, 2014, 3:04 p.m., Ian Wadham wrote:

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

(Updated July 30, 2014, 3:04 p.m.)

Review request for KDE Software on Mac OS X, KDE Runtime, kdelibs, and
Michael Pyne.

Repository: kde-runtime

Description
---

It is my strong belief that the failure to report crashes of KDE apps in
Apple OS X also exists in Frameworks.

So far I have identified a number of portability bugs in KDE on Apple OS X: 1
in KCrash, 1 in kdeinit4 and 5 in Dr Konqi. Three patches for Dr Konqi are
submitted in this review. Patches for KCrash and kdeinit4 are submitted in
part 1 of this review, against kdelibs. I am still investigating the other
two problems in Dr Konqi - and there could be more than two...

In this review we have three portability problems:

1. On Apple OS X, Dr Konqi's dialog box hides itself underneath the main
window of the app that has just crashed, so is effectively useless. This
appears to be because Dr Konqi is started by a Linux/Unix method (fork() +
exec()?). If an app is started with the Apple OS X open command, it always
appears on top. The patch just raises the dialog box.

2. When formatting the backtrace output, Dr Konqi crashes (with an ASSERT) on
the last line. This appears to be an error in the algorithm used (i.e. also a
bug in Linux KDE), but the patch is treating it as an Apple OS X portability
problem for now.

3. Dr Konqi checks whether the user can save cookies in kcookiejar and, if
not, stops reporting the crash. On Apple OS X, cookies would be kept in
another browser (e.g. Safari or Firefox) and not in KDE's default browser
(Konqueror) and cookie jar. IMHO, Dr K should report the crash no matter
what, as long as it can connect to bugs.kde.org and log in.

Diffs
-

drkonqi/reportassistantpages_bugzilla.cpp 86ca327
drkonqi/gdbhighlighter.cpp 7cd0aa9
drkonqi/main.cpp 75e060e

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

Testing
---

I NEED HELP from KDE -core- developers to proceed further. These problems
will also exist in Dr Konqi for KF 5, but I am as yet unable to build or test
Frameworks on Apple OS X and I cannot find Dr Konqi among the Frameworks
repositories. I am sure there are many more Apple OS X portability problems
in Dr Konqi and other KDE software.

Without my patches, Dr Konqi, on Apple OS X, remains invisible to the user,
often fails to complete the backtrace report and then fails to connect to
bugs.kde.org.

With my patches, Dr Konqi on Apple OS X can generate a full crash report,
including the backtrace and the results of the dialog with the user.
Sometimes, however, it fails to submit the completed report to bugs.kde.org.
This problem is still under investigation.

I would not have got this far without help from Michael Pyne, Thomas Lübking
and several of the MacPorts developers, as well as the unfailing enthusiasm
and encouragement of my friend Marko Käning.

File Attachments

Log of Dr K ASSERT problem

https://git.reviewboard.kde.org/media/uploaded/files/2014/07/30/a3f99f00-94df-4b10-bc47-66b1c966f893__DrKonqiASSERT.kcrash.txt

Thanks,

Ian Wadham

Re: Review Request 119363: Port kde-baseapps to use docbook 4.5

2014-08-24 Thread Marko Käning



 On Aug. 23, 2014, 6:26 p.m., Scarlett Clark wrote:
  I had to use this patch to get the frameworks branch to build while 
  packaging for Kubuntu. Anyway we can get this pushed to at least frameworks 
  branch?

I suggested the commit to frameworks to Luigi back then, but he had some 
arguments against it at the time.
Let's see what he thinks now, as I don't want to override him there.


- Marko


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


On July 20, 2014, 12:08 a.m., Marko Käning wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119363/
 ---
 
 (Updated July 20, 2014, 12:08 a.m.)
 
 
 Review request for KDE Base Apps, Luigi Toscano and Nicolás Alvarez.
 
 
 Repository: kde-baseapps
 
 
 Description
 ---
 
 This suggests to upgrade the docbook DTD from 4.2 to 4.5.
 
 
 Diffs
 -
 
   doc/konqueror/index.docbook a1f8565404be0289b51af37df1687e0911a01fe5 
   dolphin/docs/index.docbook 5fe85f5d130e3723af556fb02b53970206d1c765 
   kdepasswd/docs/index.docbook 2ecef470ac8a9384b7aeb16f123f834d040ee375 
   kfind/docs/index.docbook d46dfa4138991a356eec32a7043a883150eb81c2 
   kfind/docs/man-kfind.1.docbook ef2eb3b9fb1ed1a84ae33fa631b0295a029444e0 
 
 Diff: https://git.reviewboard.kde.org/r/119363/diff/
 
 
 Testing
 ---
 
 Builds/installs fine (if one doesn't use any white-space in DATA_INSTALL_DIR 
 path) 
 
 
 Thanks,
 
 Marko Käning

Re: Review Request 119363: Port kde-baseapps to use docbook 4.5

2014-08-24 Thread Marko Käning


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

(Updated Aug. 24, 2014, 6:33 p.m.)


Review request for KDE Base Apps, Luigi Toscano and Nicolás Alvarez.


Changes
---

Add still open issue of proper handling of spaces in DATA_INSTALL_DIR to 
description


Repository: kde-baseapps


Description (updated)
---

This suggests to upgrade the docbook DTD from 4.2 to 4.5.

---

There is still an open issue here:

 Spaces in DATA_INSTALL_DIR need to be handled properly, so that the path in 
the DTD file

/Library/Application\ Support/kf5/kdoctools/customization/dtd/kdex.dtd

 is correctly set, i.e. using %20 instead of a space.


Diffs
-

  doc/konqueror/index.docbook a1f8565404be0289b51af37df1687e0911a01fe5 
  dolphin/docs/index.docbook 5fe85f5d130e3723af556fb02b53970206d1c765 
  kdepasswd/docs/index.docbook 2ecef470ac8a9384b7aeb16f123f834d040ee375 
  kfind/docs/index.docbook d46dfa4138991a356eec32a7043a883150eb81c2 
  kfind/docs/man-kfind.1.docbook ef2eb3b9fb1ed1a84ae33fa631b0295a029444e0 

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


Testing
---

Builds/installs fine (if one doesn't use any white-space in DATA_INSTALL_DIR 
path) 


Thanks,

Marko Käning

Review Request 119363: Patch for kde-baseapps to make it build on the OSX/CI system

2014-07-19 Thread Marko Käning


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

Review request for KDE Base Apps, Luigi Toscano and Nicolás Alvarez.


Repository: kde-baseapps


Description
---

I need to upgrade the docbook DTD from 4.2 to 4.5 to be able to build this 
project.

---

I have done similar checkins for other projects like step and kgeography, but I 
am unsure whether this is really the way to go, although Nicolas made the same 
for kalgebra lately.

Luigi wrote in 
http://mail.kde.org/pipermail/kde-frameworks-devel/2014-July/017471.html that 
this should work with kdelibs4support installed. It is installed on the OSX/CI 
system, but still it doesn't work.

---

So, perhaps it is worthwhile diagnosing what goes wrong there instead of 
committing this RR?!

What can I do to let kdoctools tell me where exactly it expects to find its 
catalogues?


Diffs
-

  doc/konqueror/index.docbook a1f8565404be0289b51af37df1687e0911a01fe5 
  dolphin/docs/index.docbook 5fe85f5d130e3723af556fb02b53970206d1c765 
  kdepasswd/docs/index.docbook 2ecef470ac8a9384b7aeb16f123f834d040ee375 
  kfind/docs/index.docbook d46dfa4138991a356eec32a7043a883150eb81c2 
  kfind/docs/man-kfind.1.docbook ef2eb3b9fb1ed1a84ae33fa631b0295a029444e0 

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


Testing
---

Builds/installs fine


Thanks,

Marko Käning

Re: Review Request 119363: Patch for kde-baseapps to make it build on the OSX/CI system

2014-07-19 Thread Marko Käning


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

(Updated July 19, 2014, 2:09 p.m.)


Review request for KDE Base Apps, Luigi Toscano and Nicolás Alvarez.


Changes
---

Add notes regarding kdoctools setup on the OSX/CI system


Repository: kde-baseapps


Description (updated)
---

I need to upgrade the docbook DTD from 4.2 to 4.5 to be able to build this 
project.

---

I have done similar checkins for other projects like step and kgeography, but I 
am unsure whether this is really the way to go, although Nicolas made the same 
for kalgebra lately.

Luigi wrote in 
http://mail.kde.org/pipermail/kde-frameworks-devel/2014-July/017471.html that 
this should work with kdelibs4support installed. It is installed on the OSX/CI 
system, but still it doesn't work.

---

So, perhaps it is worthwhile diagnosing what goes wrong there instead of 
committing this RR?!

What can I do to let kdoctools tell me where exactly it expects to find its 
catalogues?

Let me add that kdoctools definitely expects its files in /Library/Application 
Support/kf5/kdoctools in my case, because I had to copy them to there manually 
after successfully building kdoctools:

```bash
$ ls /Library/Application\ Support/kf5/kdoctools
customization
```

Also note, that I use this global setting for configurePlatformArgs: 
-DDATA_INSTALL_DIR=Library/Application Support.


Diffs
-

  doc/konqueror/index.docbook a1f8565404be0289b51af37df1687e0911a01fe5 
  dolphin/docs/index.docbook 5fe85f5d130e3723af556fb02b53970206d1c765 
  kdepasswd/docs/index.docbook 2ecef470ac8a9384b7aeb16f123f834d040ee375 
  kfind/docs/index.docbook d46dfa4138991a356eec32a7043a883150eb81c2 
  kfind/docs/man-kfind.1.docbook ef2eb3b9fb1ed1a84ae33fa631b0295a029444e0 

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


Testing
---

Builds/installs fine


Thanks,

Marko Käning

Re: Review Request 119363: Patch for kde-baseapps to make it build on the OSX/CI system

2014-07-19 Thread Marko Käning



 On July 19, 2014, 2:18 p.m., Luigi Toscano wrote:
  Where does kdelibs4support install the compatibility docbook elements? For 
  example, dtd/kdex.dtd.cmake, and what is its content? It should install 
  them on the same directory as the kdoctools files (usually), but even if 
  they are installed in a different prefix like in the CI environment, it 
  should work, as paths in dtd/kdex.dtd.cmake are fixed accordingly (see 
  https://git.reviewboard.kde.org/r/116670 
  
  Anyway, as you can see https://git.reviewboard.kde.org/r/11678 all the 
  paths where catalogues are installed are considered, BUT it relies on 
  QStandardPaths; that's why I think it could be related with the other 
  QStandardPaths issues. 
  See also the questions at the end of review 116670.
  
  I would suggest to continue the discussion on that mailing list thread.
  
  (as a side note: I've seen those commits with a commit message like Fix 
  compilation on MacOSX, I would rather use Part docbook to 4.5 and the 
  comment about the compilation on MacOSX in the other lines, as this is not 
  real a fix but a workaround).

Yes, you are right, it would have made sense to write port docbook to 4.5 
instead of fixing being workarounding. :)
(Turns out I was editing my below review comment when you had already sent 
yours - which I hadn't seen yet.)

OK, I'll return to the ML thread as soon as there are news.


- Marko


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


On July 19, 2014, 2:09 p.m., Marko Käning wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119363/
 ---
 
 (Updated July 19, 2014, 2:09 p.m.)
 
 
 Review request for KDE Base Apps, Luigi Toscano and Nicolás Alvarez.
 
 
 Repository: kde-baseapps
 
 
 Description
 ---
 
 I need to upgrade the docbook DTD from 4.2 to 4.5 to be able to build this 
 project.
 
 ---
 
 I have done similar checkins for other projects like step and kgeography, but 
 I am unsure whether this is really the way to go, although Nicolas made the 
 same for kalgebra lately.
 
 Luigi wrote in 
 http://mail.kde.org/pipermail/kde-frameworks-devel/2014-July/017471.html that 
 this should work with kdelibs4support installed. It is installed on the 
 OSX/CI system, but still it doesn't work.
 
 ---
 
 So, perhaps it is worthwhile diagnosing what goes wrong there instead of 
 committing this RR?!
 
 What can I do to let kdoctools tell me where exactly it expects to find its 
 catalogues?
 
 Let me add that kdoctools definitely expects its files in 
 /Library/Application Support/kf5/kdoctools in my case, because I had to 
 copy them to there manually after successfully building kdoctools:
 
 ```bash
 $ ls /Library/Application\ Support/kf5/kdoctools
 customization
 ```
 
 Also note, that I use this global setting for configurePlatformArgs: 
 -DDATA_INSTALL_DIR=Library/Application Support.
 
 
 Diffs
 -
 
   doc/konqueror/index.docbook a1f8565404be0289b51af37df1687e0911a01fe5 
   dolphin/docs/index.docbook 5fe85f5d130e3723af556fb02b53970206d1c765 
   kdepasswd/docs/index.docbook 2ecef470ac8a9384b7aeb16f123f834d040ee375 
   kfind/docs/index.docbook d46dfa4138991a356eec32a7043a883150eb81c2 
   kfind/docs/man-kfind.1.docbook ef2eb3b9fb1ed1a84ae33fa631b0295a029444e0 
 
 Diff: https://git.reviewboard.kde.org/r/119363/diff/
 
 
 Testing
 ---
 
 Builds/installs fine
 
 
 Thanks,
 
 Marko Käning

Re: Review Request 119363: Port kde-baseapps to use docbook 4.5

2014-07-19 Thread Marko Käning


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

(Updated July 19, 2014, 2:30 p.m.)


Review request for KDE Base Apps, Luigi Toscano and Nicolás Alvarez.


Changes
---

Change title of RR according to the real topic


Summary (updated)
-

Port kde-baseapps to use docbook 4.5


Repository: kde-baseapps


Description
---

I need to upgrade the docbook DTD from 4.2 to 4.5 to be able to build this 
project.

---

I have done similar checkins for other projects like step and kgeography, but I 
am unsure whether this is really the way to go, although Nicolas made the same 
for kalgebra lately.

Luigi wrote in 
http://mail.kde.org/pipermail/kde-frameworks-devel/2014-July/017471.html that 
this should work with kdelibs4support installed. It is installed on the OSX/CI 
system, but still it doesn't work.

---

So, perhaps it is worthwhile diagnosing what goes wrong there instead of 
committing this RR?!

What can I do to let kdoctools tell me where exactly it expects to find its 
catalogues?

Let me add that kdoctools definitely expects its files in /Library/Application 
Support/kf5/kdoctools in my case, because I had to copy them to there manually 
after successfully building kdoctools:

```bash
$ ls /Library/Application\ Support/kf5/kdoctools
customization
```

Also note, that I use this global setting for configurePlatformArgs: 
-DDATA_INSTALL_DIR=Library/Application Support.


Diffs
-

  doc/konqueror/index.docbook a1f8565404be0289b51af37df1687e0911a01fe5 
  dolphin/docs/index.docbook 5fe85f5d130e3723af556fb02b53970206d1c765 
  kdepasswd/docs/index.docbook 2ecef470ac8a9384b7aeb16f123f834d040ee375 
  kfind/docs/index.docbook d46dfa4138991a356eec32a7043a883150eb81c2 
  kfind/docs/man-kfind.1.docbook ef2eb3b9fb1ed1a84ae33fa631b0295a029444e0 

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


Testing
---

Builds/installs fine


Thanks,

Marko Käning

Re: Review Request 119363: Port kde-baseapps to use docbook 4.5

2014-07-19 Thread Marko Käning



 On July 19, 2014, 2:18 p.m., Luigi Toscano wrote:
  Where does kdelibs4support install the compatibility docbook elements? For 
  example, dtd/kdex.dtd.cmake, and what is its content? It should install 
  them on the same directory as the kdoctools files (usually), but even if 
  they are installed in a different prefix like in the CI environment, it 
  should work, as paths in dtd/kdex.dtd.cmake are fixed accordingly (see 
  https://git.reviewboard.kde.org/r/116670 
  
  Anyway, as you can see https://git.reviewboard.kde.org/r/11678 all the 
  paths where catalogues are installed are considered, BUT it relies on 
  QStandardPaths; that's why I think it could be related with the other 
  QStandardPaths issues. 
  See also the questions at the end of review 116670.
  
  I would suggest to continue the discussion on that mailing list thread.
  
  (as a side note: I've seen those commits with a commit message like Fix 
  compilation on MacOSX, I would rather use Part docbook to 4.5 and the 
  comment about the compilation on MacOSX in the other lines, as this is not 
  real a fix but a workaround).
 
 Marko Käning wrote:
 Yes, you are right, it would have made sense to write port docbook to 
 4.5 instead of fixing being workarounding. :)
 (Turns out I was editing my below review comment when you had already 
 sent yours - which I hadn't seen yet.)
 
 OK, I'll return to the ML thread as soon as there are news.

BTW, your 2nd link is missing a trailing 1, but in your ML post you give the 
correct one as https://git.reviewboard.kde.org/r/116781/


- Marko


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


On July 19, 2014, 2:30 p.m., Marko Käning wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119363/
 ---
 
 (Updated July 19, 2014, 2:30 p.m.)
 
 
 Review request for KDE Base Apps, Luigi Toscano and Nicolás Alvarez.
 
 
 Repository: kde-baseapps
 
 
 Description
 ---
 
 I need to upgrade the docbook DTD from 4.2 to 4.5 to be able to build this 
 project.
 
 ---
 
 I have done similar checkins for other projects like step and kgeography, but 
 I am unsure whether this is really the way to go, although Nicolas made the 
 same for kalgebra lately.
 
 Luigi wrote in 
 http://mail.kde.org/pipermail/kde-frameworks-devel/2014-July/017471.html that 
 this should work with kdelibs4support installed. It is installed on the 
 OSX/CI system, but still it doesn't work.
 
 ---
 
 So, perhaps it is worthwhile diagnosing what goes wrong there instead of 
 committing this RR?!
 
 What can I do to let kdoctools tell me where exactly it expects to find its 
 catalogues?
 
 Let me add that kdoctools definitely expects its files in 
 /Library/Application Support/kf5/kdoctools in my case, because I had to 
 copy them to there manually after successfully building kdoctools:
 
 ```bash
 $ ls /Library/Application\ Support/kf5/kdoctools
 customization
 ```
 
 Also note, that I use this global setting for configurePlatformArgs: 
 -DDATA_INSTALL_DIR=Library/Application Support.
 
 
 Diffs
 -
 
   doc/konqueror/index.docbook a1f8565404be0289b51af37df1687e0911a01fe5 
   dolphin/docs/index.docbook 5fe85f5d130e3723af556fb02b53970206d1c765 
   kdepasswd/docs/index.docbook 2ecef470ac8a9384b7aeb16f123f834d040ee375 
   kfind/docs/index.docbook d46dfa4138991a356eec32a7043a883150eb81c2 
   kfind/docs/man-kfind.1.docbook ef2eb3b9fb1ed1a84ae33fa631b0295a029444e0 
 
 Diff: https://git.reviewboard.kde.org/r/119363/diff/
 
 
 Testing
 ---
 
 Builds/installs fine
 
 
 Thanks,
 
 Marko Käning

Re: Review Request 119363: Port kde-baseapps to use docbook 4.5

2014-07-19 Thread Marko Käning


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

(Updated July 20, 2014, 12:08 a.m.)


Review request for KDE Base Apps, Luigi Toscano and Nicolás Alvarez.


Changes
---

Remove distracting information


Repository: kde-baseapps


Description (updated)
---

This suggests to upgrade the docbook DTD from 4.2 to 4.5.


Diffs
-

  doc/konqueror/index.docbook a1f8565404be0289b51af37df1687e0911a01fe5 
  dolphin/docs/index.docbook 5fe85f5d130e3723af556fb02b53970206d1c765 
  kdepasswd/docs/index.docbook 2ecef470ac8a9384b7aeb16f123f834d040ee375 
  kfind/docs/index.docbook d46dfa4138991a356eec32a7043a883150eb81c2 
  kfind/docs/man-kfind.1.docbook ef2eb3b9fb1ed1a84ae33fa631b0295a029444e0 

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


Testing (updated)
---

Builds/installs fine (if one doesn't use any white-space in DATA_INSTALL_DIR 
path) 


Thanks,

Marko Käning

Re: Review Request 119240: Preventing a crash in the KWindowInfo::Private destructor on OSX

2014-07-15 Thread Marko Käning


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

(Updated July 15, 2014, 11:02 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Software on Mac OS X, kdelibs, David Faure, Martin 
Gräßlin, Ian Wadham, Thomas Lübking, and RJVB Bertin.


Bugs: 337154
http://bugs.kde.org/show_bug.cgi?id=337154


Repository: kdelibs


Description
---

Preventing a crash in the KWindowInfo::Private destructor on OSX (thanks to 
René J.V. Bertin) for Qt4!

(Unclear is atm where this would have to be fixed in KF5.)

See also this: 
https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFTypeRef/Reference/reference.html#//apple_ref/c/func/CFRelease


Diffs
-

  kdeui/windowmanagement/kwindowinfo_mac.cpp 
ca502a3c643af36f4a52bb6dcbc7b54fbe3f42a9 

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


Testing
---

For more details see associated bug


Thanks,

Marko Käning

Re: Review Request 119243: Better OSX integration: native file dialogs and unified title/toolbar

2014-07-14 Thread Marko Käning


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

(Updated July 14, 2014, 7:08 p.m.)


Review request for KDE Software on Mac OS X, kdelibs, Christoph Feck, and Ian 
Wadham.


Changes
---

Assigning this RR to group kde-mac (Thanks, Ian!)


Bugs: 337356
http://bugs.kde.org/show_bug.cgi?id=337356


Repository: kdelibs


Description
---

This bundles both patches submitted by René J.V. Bertin in the associated issue


Diffs
-

  kdeui/widgets/kmainwindow.cpp 85beaccdb6f123d2996b8c2b5e38435265c63ff8 
  kio/kfile/kfiledialog.h 2b11796897ff095279e7c254a383a9e8e323ea0f 
  kio/kfile/kfiledialog.cpp 4005ba304a18b59572cc1aece3fcd122ce05fda9 

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


Testing
---

See issue for more info from René.

---

I myself haven't yet tested this. Will report back as soon as I got to it.


Thanks,

Marko Käning

Re: Review Request 119240: Preventing a crash in the KWindowInfo::Private destructor on OSX

2014-07-14 Thread Marko Käning


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

(Updated July 14, 2014, 7:10 p.m.)


Review request for KDE Software on Mac OS X, kdelibs, David Faure, Martin 
Gräßlin, Ian Wadham, and Thomas Lübking.


Changes
---

Assigning to kde-mac (Thanks, Ian!)


Bugs: 337154
http://bugs.kde.org/show_bug.cgi?id=337154


Repository: kdelibs


Description
---

Preventing a crash in the KWindowInfo::Private destructor on OSX (thanks to 
René J.V. Bertin) for Qt4!

(Unclear is atm where this would have to be fixed in KF5.)

See also this: 
https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFTypeRef/Reference/reference.html#//apple_ref/c/func/CFRelease


Diffs
-

  kdeui/windowmanagement/kwindowinfo_mac.cpp 
ca502a3c643af36f4a52bb6dcbc7b54fbe3f42a9 

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


Testing
---

For more details see associated bug


Thanks,

Marko Käning

Re: Review Request 119240: Preventing a crash in the KWindowInfo::Private destructor on OSX

2014-07-14 Thread Marko Käning


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

(Updated July 14, 2014, 7:59 p.m.)


Review request for KDE Software on Mac OS X, kdelibs, David Faure, Martin 
Gräßlin, Ian Wadham, Thomas Lübking, and RJVB Bertin.


Changes
---

Added René!


Bugs: 337154
http://bugs.kde.org/show_bug.cgi?id=337154


Repository: kdelibs


Description
---

Preventing a crash in the KWindowInfo::Private destructor on OSX (thanks to 
René J.V. Bertin) for Qt4!

(Unclear is atm where this would have to be fixed in KF5.)

See also this: 
https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFTypeRef/Reference/reference.html#//apple_ref/c/func/CFRelease


Diffs
-

  kdeui/windowmanagement/kwindowinfo_mac.cpp 
ca502a3c643af36f4a52bb6dcbc7b54fbe3f42a9 

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


Testing
---

For more details see associated bug


Thanks,

Marko Käning

Re: Review Request 119243: Better OSX integration: native file dialogs and unified title/toolbar

2014-07-14 Thread Marko Käning


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

(Updated July 14, 2014, 8:15 p.m.)


Review request for KDE Software on Mac OS X, kdelibs, Christoph Feck, Ian 
Wadham, and RJVB Bertin.


Changes
---

Added René (This wouldn't be needed, if he were making himself member of group 
kde-mac on RB.)


Bugs: 337356
http://bugs.kde.org/show_bug.cgi?id=337356


Repository: kdelibs


Description
---

This bundles both patches submitted by René J.V. Bertin in the associated issue


Diffs
-

  kdeui/widgets/kmainwindow.cpp 85beaccdb6f123d2996b8c2b5e38435265c63ff8 
  kio/kfile/kfiledialog.h 2b11796897ff095279e7c254a383a9e8e323ea0f 
  kio/kfile/kfiledialog.cpp 4005ba304a18b59572cc1aece3fcd122ce05fda9 

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


Testing
---

See issue for more info from René.

---

I myself haven't yet tested this. Will report back as soon as I got to it.


Thanks,

Marko Käning

Re: Review Request 119240: Preventing a crash in the KWindowInfo::Private destructor on OSX

2014-07-14 Thread Marko Käning


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

(Updated July 14, 2014, 11:26 p.m.)


Review request for kdelibs, David Faure, Martin Gräßlin, Ian Wadham, Thomas 
Lübking, and RJVB Bertin.


Changes
---

Remove the comment, as it will finally be kept in this RR as well as the commit 
message.


Bugs: 337154
http://bugs.kde.org/show_bug.cgi?id=337154


Repository: kdelibs


Description
---

Preventing a crash in the KWindowInfo::Private destructor on OSX (thanks to 
René J.V. Bertin) for Qt4!

(Unclear is atm where this would have to be fixed in KF5.)

See also this: 
https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFTypeRef/Reference/reference.html#//apple_ref/c/func/CFRelease


Diffs (updated)
-

  kdeui/windowmanagement/kwindowinfo_mac.cpp 
ca502a3c643af36f4a52bb6dcbc7b54fbe3f42a9 

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


Testing
---

For more details see associated bug


Thanks,

Marko Käning

Re: Review Request 119240: Preventing a crash in the KWindowInfo::Private destructor on OSX

2014-07-14 Thread Marko Käning


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

(Updated July 14, 2014, 11:49 p.m.)


Review request for KDE Software on Mac OS X, kdelibs, David Faure, Martin 
Gräßlin, Ian Wadham, Thomas Lübking, and RJVB Bertin.


Changes
---

Oops, kde-mac got lost during updating the RR.


Bugs: 337154
http://bugs.kde.org/show_bug.cgi?id=337154


Repository: kdelibs


Description
---

Preventing a crash in the KWindowInfo::Private destructor on OSX (thanks to 
René J.V. Bertin) for Qt4!

(Unclear is atm where this would have to be fixed in KF5.)

See also this: 
https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFTypeRef/Reference/reference.html#//apple_ref/c/func/CFRelease


Diffs
-

  kdeui/windowmanagement/kwindowinfo_mac.cpp 
ca502a3c643af36f4a52bb6dcbc7b54fbe3f42a9 

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


Testing
---

For more details see associated bug


Thanks,

Marko Käning

Re: Review Request 119240: Preventing a crash in the KWindowInfo::Private destructor on OSX

2014-07-14 Thread Marko Käning



 On July 12, 2014, 8:49 p.m., David Faure wrote:
  Seems clear enough.
  
  In KF5 the file is in frameworks/kwindowsystem/src/kwindowinfo_mac.cpp
 
 Marko Käning wrote:
 Thanks for the info about KF5!
 
 Which branch should this be committed to on kdelibs4? Simply on master or 
 also on (an)other branch(es)?
 
 David Faure wrote:
 Commit to KDE/4.13, and merge (or ask someone to merge) to KDE/4.14 and 
 master.
 
 [Or if you don't care for the 4.13 branch on mac, commit to KDE/4.14 
 directly and merge to master.]

I have committed this to KDE/4.13 no problem in 
http://commits.kde.org/kdelibs/d32b52996ce48d484bbf54a62321872a482e8d74 but I 
am unsure about how to MERGE this properly into KDE/4.14 and master without 
effecting other files.

Can someone jump in and explain how to achieve those two merges without 
cherry-picking using git?


- Marko


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


On July 14, 2014, 11:49 p.m., Marko Käning wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119240/
 ---
 
 (Updated July 14, 2014, 11:49 p.m.)
 
 
 Review request for KDE Software on Mac OS X, kdelibs, David Faure, Martin 
 Gräßlin, Ian Wadham, Thomas Lübking, and RJVB Bertin.
 
 
 Bugs: 337154
 http://bugs.kde.org/show_bug.cgi?id=337154
 
 
 Repository: kdelibs
 
 
 Description
 ---
 
 Preventing a crash in the KWindowInfo::Private destructor on OSX (thanks to 
 René J.V. Bertin) for Qt4!
 
 (Unclear is atm where this would have to be fixed in KF5.)
 
 See also this: 
 https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFTypeRef/Reference/reference.html#//apple_ref/c/func/CFRelease
 
 
 Diffs
 -
 
   kdeui/windowmanagement/kwindowinfo_mac.cpp 
 ca502a3c643af36f4a52bb6dcbc7b54fbe3f42a9 
 
 Diff: https://git.reviewboard.kde.org/r/119240/diff/
 
 
 Testing
 ---
 
 For more details see associated bug
 
 
 Thanks,
 
 Marko Käning

Review Request 119240: Preventing a crash in the KWindowInfo::Private destructor on OSX

2014-07-12 Thread Marko Käning


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

Review request for kdelibs, Martin Gräßlin, Ian Wadham, and Thomas Lübking.


Bugs: 337154
http://bugs.kde.org/show_bug.cgi?id=337154


Repository: kdelibs


Description
---

Preventing a crash in the KWindowInfo::Private destructor on OSX (thanks to 
René J.V. Bertin)


Diffs
-

  kdeui/windowmanagement/kwindowinfo_mac.cpp 
ca502a3c643af36f4a52bb6dcbc7b54fbe3f42a9 

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


Testing
---

For more details see associated bug


Thanks,

Marko Käning

Review Request 119243: Better OSX integration: native file dialogs and unified title/toolbar

2014-07-12 Thread Marko Käning


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

Review request for kdelibs, Christoph Feck and Ian Wadham.


Bugs: 337356
http://bugs.kde.org/show_bug.cgi?id=337356


Repository: kdelibs


Description
---

This bundles both patches submitted by René J.V. Bertin in the associated issue


Diffs
-

  kdeui/widgets/kmainwindow.cpp 85beaccdb6f123d2996b8c2b5e38435265c63ff8 
  kio/kfile/kfiledialog.h 2b11796897ff095279e7c254a383a9e8e323ea0f 
  kio/kfile/kfiledialog.cpp 4005ba304a18b59572cc1aece3fcd122ce05fda9 

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


Testing
---

See issue for more info from René.

---

I myself haven't yet tested this. Will report back as soon as I got to it.


Thanks,

Marko Käning

Re: Review Request 119240: Preventing a crash in the KWindowInfo::Private destructor on OSX

2014-07-12 Thread Marko Käning


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

(Updated July 12, 2014, 4:22 p.m.)


Review request for kdelibs, Martin Gräßlin, Ian Wadham, and Thomas Lübking.


Bugs: 337154
http://bugs.kde.org/show_bug.cgi?id=337154


Repository: kdelibs


Description
---

Preventing a crash in the KWindowInfo::Private destructor on OSX (thanks to 
René J.V. Bertin)


Diffs (updated)
-

  kdeui/windowmanagement/kwindowinfo_mac.cpp 
ca502a3c643af36f4a52bb6dcbc7b54fbe3f42a9 

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


Testing
---

For more details see associated bug


Thanks,

Marko Käning

Re: Review Request 119240: Preventing a crash in the KWindowInfo::Private destructor on OSX

2014-07-12 Thread Marko Käning



 On July 12, 2014, 6:01 p.m., Martin Gräßlin wrote:
  Which branch should that go in? I do not know what is currently a release 
  branch.
  
  It should probably also be forward ported to frameworks even if the Mac 
  part is currently not compiled (hint: if someone adjusts the code it could 
  be included again ;-) ).

I do not know where fixes like this should go to. This patch is based on master.


 On July 12, 2014, 6:01 p.m., Martin Gräßlin wrote:
  kdeui/windowmanagement/kwindowinfo_mac.cpp, line 54
  https://git.reviewboard.kde.org/r/119240/diff/2/?file=289759#file289759line54
 
  what's the RJVB 20140706 standing for?

That's René's original comment. It will be taken out once this is ready for 
commit, since credit will be given by the commit message then. :)


- Marko


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


On July 12, 2014, 4:22 p.m., Marko Käning wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://git.reviewboard.kde.org/r/119240/
 ---
 
 (Updated July 12, 2014, 4:22 p.m.)
 
 
 Review request for kdelibs, Martin Gräßlin, Ian Wadham, and Thomas Lübking.
 
 
 Bugs: 337154
 http://bugs.kde.org/show_bug.cgi?id=337154
 
 
 Repository: kdelibs
 
 
 Description
 ---
 
 Preventing a crash in the KWindowInfo::Private destructor on OSX (thanks to 
 René J.V. Bertin)
 
 
 Diffs
 -
 
   kdeui/windowmanagement/kwindowinfo_mac.cpp 
 ca502a3c643af36f4a52bb6dcbc7b54fbe3f42a9 
 
 Diff: https://git.reviewboard.kde.org/r/119240/diff/
 
 
 Testing
 ---
 
 For more details see associated bug
 
 
 Thanks,
 
 Marko Käning

Re: Review Request 119240: Preventing a crash in the KWindowInfo::Private destructor on OSX

2014-07-12 Thread Marko Käning


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

(Updated July 12, 2014, 7:02 p.m.)


Review request for kdelibs, Martin Gräßlin, Ian Wadham, and Thomas Lübking.


Changes
---

Add RVJB's link to Apple's documentation


Bugs: 337154
http://bugs.kde.org/show_bug.cgi?id=337154


Repository: kdelibs


Description (updated)
---

Preventing a crash in the KWindowInfo::Private destructor on OSX (thanks to 
René J.V. Bertin)

See also this: 
https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFTypeRef/Reference/reference.html#//apple_ref/c/func/CFRelease


Diffs
-

  kdeui/windowmanagement/kwindowinfo_mac.cpp 
ca502a3c643af36f4a52bb6dcbc7b54fbe3f42a9 

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


Testing
---

For more details see associated bug


Thanks,

Marko Käning

39 matches

Mail list logo