Re: Kexi/Mac

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Kexi/Mac

Jaroslaw Staniek-3


On 26 December 2016 at 19:13,
​​
René J.V. Bertin <[hidden email]> wrote:
Hi,

A little FYI/thumbs-up ... despite plans to get Karbon working on Mac first it's Kexi that won in the end.

Not the standalone, all-inclusive app bundle some might be hoping for, but a MacPorts package (port):

https://github.com/RJVB/macstrop/tree/master/kf5/kf5-kexi

I've committed a few minor patches (building and installing the app icon, building the handbook) but there's need for more work: the interface is completely messed up when using the native Macintosh widget style.

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

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


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

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

​These are great news​, ​René!
Maybe I am repeating myself but the enforcement of the widget style and icon theme is dictated by a specific approach: maintainer of a style is free to add the style/theme and even change the default or add an alternative.
So there's open path to change of the default e.g. on Mac to a specific different default. It's possible as soon as the new default is not 'worse' than the Breeze one. Contributions are needed in kexi.git, kreport.git, kproperty.git it seems. Also once we have documentation updated, we need these contributions to be extended to the docs: Mac docs will need updates.
Unless these contributions are here I am a bit afraid we're risking inconsistencies between platforms and inferior experience on Mac (no docs, incomplete icon theme or styles).

I'm sorry if this conservative talk sounds like raising a bar.
A first step, a lower bar, could be an alternative icons set for Kexi. Icon sets are somehow supersets of icon themes from Linux, dedicated, and can be deployed separately, just like you know it from Firefox, etc. Support for this is not yet ready because, you guess it, lack of contributors willing to work on them.



R.



--
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
Reply | Threaded
Open this post in threaded view
|

Re: Kexi/Mac

Jaroslaw Staniek-3


On 26 December 2016 at 21:34, René J.V. Bertin <[hidden email]> wrote:
On Monday December 26 2016 20:18:39 Jaroslaw Staniek wrote:
>​These are great news​, ​René!
>Maybe I am repeating myself but the enforcement of the widget style and
>icon theme is dictated by a specific approach: maintainer of a style is
>free to add the style/theme and even change the default or add an
>alternative.

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

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

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

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

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

​I am sure current Kexi master may be inferior on Mac to what you see on Linux or Windows because ​it was not tested there at all. Nice to hear new from Wojtek too...
One thing, the 3.0 branch for 3.0.x series is explicitly unsupported for Mac - we're not changing it anymore for anything but more critical bugfixes.

The KDE's ​breeze-icons.rcc ​
​is ​built by default now from breeze-icons.git (my patch was accepted). Kexi's kexi_breeze.rcc is built in Kexi already the way you describe since 3.0.0. The same thing is used since 3.0.0 for KReport/KProperty. I recommend using  master branches for all the repos though.

All means are used to make Kexi work OK with stock Qt.


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

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

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

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

​Good, thanks for reporting any issues in detail. bugs.kde.org is preferred, and screenshots/videos help a lot. One good thing almost ready for Windows that can be good for Mac too: KFileWidget would be optional so native Open/Save dialogs (+KUrlRequester and a simple QFileSystemModel-based list view) would be available for non-Plasma platforms.


--
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek