<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 8 November 2016 at 10:36, René J.V. Bertin <span dir="ltr"><<a href="mailto:rjvbertin@gmail.com" target="_blank">rjvbertin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Monday November 07 2016 18:14:35 Jaroslaw Staniek wrote:<br>
<br>
Hi Jarek,<br>
<span class="gmail-m_270985621152932329gmail-m_170816817999404272gmail-"><br>
>Thanks for the interest!<br>
>In addition Kexi-specific things can be discussed at a kexi-devel list :)<br>
>There were enthusiastic people interested in contributing Mac builds of<br>
>Kexi but they disappeared so this task is open for maintainer. Bundling or<br>
>discovering server installation(s) (pgsql, mysql), bundling dependencies --<br>
>these are all task for adoption.<br>
><br>
><br>
>In my opinion Kexi fits to a standalone path, just like on Windows, to<br>
>become as native as possible, well, but not more native than that. For<br>
<br>
</span>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).<br>
<br>
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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
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).<br>
<br>
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.<br></blockquote><div><br><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">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?<br><br>In some pre-CMake times (qmake times) I've worked with bundling Mac binaries and once we have tools that work in batch mode we were OK. Medium 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.<br></div><span class="gmail-m_270985621152932329gmail-m_170816817999404272gmail-"><br></span><span class="gmail-m_270985621152932329gmail-m_170816817999404272gmail-"></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_270985621152932329gmail-m_170816817999404272gmail-">
>example KFileWidget being very Plasma-oriented is close to be removed on<br>
>Windows and could be also removed on Mac, in favour of a Url field + [..]<br>
>button (KUrlRequester).<br>
<br>
</span>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).<br></blockquote><div><br><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">Yes, first motivation is, not to be worse than competition.<br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">Mostly UX-wise; under the mask we're rather safe.<br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default"><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-m_270985621152932329gmail-m_170816817999404272gmail-"><br>
>I've also not seen Mac builds of Kexi-derived projects: KDb, KReport,<br>
>KProperty. These are general-purpose frameworks and Kexi dependencies. If<br>
>they are missing for Mac it would be nice to see them available too as<br>
<br>
</span>If? Is there reason to suspect that building them on Mac is going to require patching?<br></blockquote><div><br><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">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.<br>Would be also nice to have nightly builds one day. I'd like to add the same for Windows.<br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">For now having someone who prepares binaries before release and runs tests is sufficient minimum.<br></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
>frameworks for general use.<br>
<br>
Framework in which sense? :)<br></blockquote><div><br><div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default">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 realistically easy way within their preferred IDE. <br>That's a side topic from Kexi, if you have some interest. For Kexi these 3 frameworks would be rather bundled.<br><br></div><div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default">Thanks for the good work.<span class="gmail-m_270985621152932329gmail-m_170816817999404272gmail-HOEnZb"><font color="#888888"><br>
</font></span></div></div></div><br><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">PS: Home page of any Mac-related notes is <a href="https://community.kde.org/Kexi/Mac." target="_blank">https://community.kde.org/<wbr>Kexi/Mac.</a><br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">Feel free to use that space.<br></div><br clear="all"><br>-- <br><div class="gmail-m_270985621152932329gmail-m_170816817999404272gmail_signature">regards, Jaroslaw Staniek<br><br>KDE:<br>: A world-wide network of software engineers, artists, writers, translators<br>: and facilitators committed to Free Software development - <a href="http://kde.org" target="_blank">http://kde.org</a><br>Calligra Suite:<br>: A graphic art and office suite - <a href="http://calligra.org" target="_blank">http://calligra.org</a><br>Kexi:<br>: A visual database apps builder - <a href="http://calligra.org/kexi" target="_blank">http://calligra.org/kexi</a><br>Qt Certified Specialist:<br>: <a href="http://www.linkedin.com/in/jstaniek" target="_blank">http://www.linkedin.com/in/jst<wbr>aniek</a></div>
</div></div>