Amazing to have someone using my work, can I ask what app you are using it in?

LGTM

P.S. i got query to work by arranging date as yyyy-mm-dd .... i had used dd-mm-yyyy

Following BT when doing the action:
Open database
Right click on query and select Design
When prompted that cannot open in design view, select option to open in text view
Crash

I tested a simple expression, such as
select #date# as expr1
and it worked
But a more complex query such as
SELECT mi_band_activity.*, timestamp_dt FROM mi_band_activity where timestamp_dt > #23-May-2018#
does not work, gives the following output:
org.kde.kdb.core: checking variable name: "mi_band_activity.*"
org.kde.kdb.core: checking variable name: "timestamp_dt"
org.kde.kdb.core: checking variable name: "timestamp_dt"
org.kde.kdb.core: error:
org.kde.kdb.core: at character 95 near tooken "#"
org.kde.kdb.core: KDbEscapedString:"SELECT mi_band_activity.*, timestamp_dt FROM mi_band_activity where timestamp_dt > #23-05-2018#"

I used arc patch D17336 on kdb
I get errors like
org.kde.kdb.core: error: syntax error, unexpected $undefined, expecting $end
org.kde.kdb.core: at character 8 near tooken "#"
org.kde.kdb.core: KDbEscapedString:"select #2018-05-23#"
org.kde.kdb.core: " ^"

• Dont use clipboard plugin on sailfish as it uses wayland

Move paramter fetching to open() from getSchema()

Out of interest, how can I use arc to update my local branch with your changes?

@dcaliste by my count there are atleast 3 apps using kf5 libs now, calligra, my watch client app and my kdeconnect port. there has/to be scope for sharing effort :) ive just been shiping the libs in openrepos with the apps

nice, btw, i have a kf5 repo on the mer obs where i build kf5 libs for sailfish...perhaps that is easier for you? i use them in a few sfos apps, even kdb! my version is 5.31 atm .... is 5.34 the last version to build with qt5.6? i could never find the archives as theyve disappeared from the kde servers, unless im misteken.

• Enable mpriscontrol also on sailfish
• Add features from kde app mpris control and use QtQuick Layouts
• Add layouts to .spec

built and tested ok on sfos

lgtm

Reverted the unnecessary change to daemon/CMakeLists.txt which came about as part of the merge. Hope all ok now.

• Remove unnescessary change

In D14486#301208, @staniek wrote:

In D14486#301205, @piggz wrote:

A few questions, in the interest of keeping our downastream happy, and potentially reducing our burden

1. do we carry patches ontop of mdb?
2. how much work would be neded in adding a switch to use the system lib? --I know this would initially be a little work, but could allow a phased approach to using the system supplied lib over time, as packagers choose. If after 1-2 years, all packagers are onboard, we could then make it the default and remove our version of mdb, and the need to maintain it.

Thanks for stepping up Adam. I am not sure if:

1. mdbtools carries version information .
2. It even does not maintain cmake module.
   
   This work is needed in mdbtools itself. And we have no evidence there's any other consumer apart of KEXI that uses mdbtools via cmake.
   
   If above bits are supplied and maintained, we could allow exact version of "system" mdbtools. Exact because it's the only one I test.
   
   IMHO it's more effort and risk than benefit, from history I remember that distros can:
3. skip mdbtools if we set it optional -> KEXI lacks major feature
4. skip KEXI if we set mdbtools required -> KEXI disappears from the distro at least for some time, for packagers it's "just" one release less
   
   Because I am all for seeing any contributions please go ahead to discuss[*] and contribute 1. and 2., then we can have opt-in "system" mdbtools support. We would keep mdbtools mandatory (as long as glib and iconv is present).
   
   Discuss[*]: your challenge would be that mdbtools is consisted of things orthogonal to MDB support KEXI needs: importer tool, exporter tool, SQL support. Whether that project will let you contribute just cmake files for the MDB C API for the read support is not clear. So there may be more work than KEXI needs.

In D14486#300988, @staniek wrote:

In D14486#300962, @pino wrote:

In D14486#300951, @pino wrote:

so your is proposal correct but of a very low priority for me.

Considering somebody else other than you invested their time in updating the embedded copy [...]

Sorry, I have to stand corrected by myself: you were the one doing this update. OTOH, the rest of my message still stands.

Of course this shall be a member of KEXI project because mdbtools is not a general purpose solution designed to plug to other GUI apps so easily. It's consisted of set of command line tools (they are always hard to integrate with a front end in other than naive way) or has some hard coded GUI, plus C APIs for all these needs exposed in one relevant header file. API stability through the fact that the header rarely changes is accidental.

Disclaimer: mdbtools is one of best reverse engineering projects I know and one of most important to me. Reverse engineering is the core of it, the rest is "just" necessary thing IMHO.

I can assure you that updating mdbtools, unlike sqlite (which is just big enough that it is fine grained and more general purpose), needs to be performed patch-by-patch. Long ago it was the same story with SQLite (version 2 vs 3, breaking compatibility after 3.0, and so on). Since then sqlite is used on every mobile phone and mdbtools is used, you know how frequently.

It's not just a separate situation. I can recall the story of issues that Okular had with (IIRC?) PDF backends. Or Krita with touch input device support in Qt. These projects were not even able to fork the dependencies, I guess mainly because of the size but number of workarounds added was noticeable. Of course we do not argue that forking or embedding is not a really unclean solution, but it's not true that it's not happening, just like it's not true that there are thousands of projects that use years old compilers.

Here in keximdb nothing changes for you as package author, right? When this patch gets integrated into KEXI there is the same situation from the packages' POV as you it was years ago.

If otherwise I just delegated the risk and testing to users (not packagers, since as we know they do not have just one project to support and are rather project-agnostic) it isn't impossible that packagers would have to know that we request version 0.7.1 supported and not >=0.7.2 for some compatibility or "exceptional" reason. I can't imagine how this contract can be assured distro-independently with tool we have not which is just a plain README file and so limited developer workforce. It's possible that users will have KEXI 3.1 running on their desktop 4 years later and mdbtools package completely unknown to us. Part of the issue come from the fact that we reserve right to use mdbtools not the way it was designed, to get all kind of instrumentation we need.

Jokes: I do not know how it is possible that chromium or Libreoffice or Firefox is packaged as larger monolytic packages (they both contain lots of unrelated tech compiled together). Or MySQL. Why the MySQL parser is not separate package so I can use it...

In D10703#296512, @nicolasfella wrote:

The diff contains a few unrelated changes, please remove them and do them in another commit if it seems necessary to you.
Looks quite good to me, but I can't test anything in regard to sailfish.
We already have a QML/Kirigami app in the app/ folder for e.g. Plasma Mobile. Can we use that one instead of creating a new one for SFOS?

• Fix removed plugin

Please note, the main change here is renaming the .json file, for the sendnotification plugin to .json.in, and using cmake to process the file

Addressed remaining comments

• Address review comments
• Move rpm folder
• Remove test code
• Fix icon
• Improve cover item
• Move sailfishdaemon to seperate file
• Port battery plugin to sailfish
• Copy qascont from qt 5.7
• Properly build the declarative plugin
• Address review comments
• Remove unnescessary changes
• Add features to app
• Tidy up plugin items
• Add rpm files for sailfish
• Merge branch 'pgz-sfos-initial' of https://github.com/piggz/kdeconnect-kde into pgz-sfos-initial
• Cleanups
• Build fixes
• Dont use a seperate json file for sailfish
• no need to check version as it is done in the header
• Merge branch 'master' into pgz-sfos-initial
• Merge remote-tracking branch 'origin/master' into pgz-sfos-initial

Other drivers affected?

Should get into master for stability testing before 3.2

Surprising how many changes for one crash!

In D10703#261761, @nicolasfella wrote:

Ping? It needs to be rebased to current master and then I think it can go in

Should we clean up the internal schema of non existing tables? Options would be automatic or prompt to user. Other consideration is other objects referring to non-existing tables like reports and queries.

Feel free, you'll have to implement the simple notification method in the Damon.

its not on obs yet. there is a spec in an earlier version of the diff, also take a look on my github maybe

I dont have permission to land this (unless ive got something misconfigured locally) could someone else, or check if I do have access?

• Address comments.

• Address review comments
• Remove unnescessary changes

In D10703#217493, @mtijink wrote:

I got some build errors, which I've added a comment for.

Nice to see KDE Connect spreading to a different platform. Do you have some screenshots?

In D10703#217173, @kossebau wrote:

@nicolasfella Thanks for pointing me to this. Happyness++

@piggz Hi :) By pure chance some hours before I came across https://github.com/R1tschY/harbour-sailfishconnect, is this some duplicated effort possibly or how does this relate? (no clue yet about KDE Connect details)

Can you give some build instructions? Seeing set(KF5_REQUIRED_COMPONENTS I18n DBusAddons CoreAddons), so not just using plain Qt, my old MarbleMaps@SailfishOS knowledge might not be sufficient :)

Happy to help out soon at least when it comes to MPRIS stuff (given master plan hinted to in D10972)

Guys, whats your thoughts about this?

• Use qasconst.h in notification listener

• Properly build the declarative plugin

• Copy qasconst from qt 5.7

One thing, in the home/start page, it says 'You in Kexi Project'

• Port battery plugin to sailfish
• Port the sendnotifications plugin
• Add all the experimatal app plugins

In D10703#215174, @piggz wrote:

In D10703#215140, @mtijink wrote:

In D10703#215044, @piggz wrote:

Do you guys know why the sendnotifications plugin wouldn't get loaded at runtime? I'll do some debugging in the plugin loader, but my phone advertises kdeconnect.notification and my computer has the receivenotification plugin loaded, but something in the loader is causing it to be missed I think.

I don't know, unfortunately. Setting a breakpoint in PluginFactory.java:208 should help with debugging, though.

Are you on irc at all?

I didn't even know we had irc 😋

Its not in the android app, its the C++/KDE project compiled for Sailfish, so im looking in pluginloader::pluginsForCapabilities

In D10703#215140, @mtijink wrote:

In D10703#215044, @piggz wrote:

Do you guys know why the sendnotifications plugin wouldn't get loaded at runtime? I'll do some debugging in the plugin loader, but my phone advertises kdeconnect.notification and my computer has the receivenotification plugin loaded, but something in the loader is causing it to be missed I think.

I don't know, unfortunately. Setting a breakpoint in PluginFactory.java:208 should help with debugging, though.

Are you on irc at all?

I didn't even know we had irc 😋

Do you guys know why the sendnotifications plugin wouldn't get loaded at runtime? I'll do some debugging in the plugin loader, but my phone advertises kdeconnect.notification and my computer has the receivenotification plugin loaded, but something in the loader is causing it to be missed I think.

• Improve cover item
• Move sailfishdaemon to seperate file

• Address review comments
• Move rpm folder
• Add ping notification
• Remove test code
• Fix icon

Why?

Ive got a bit to do, be prepared for a rev 2.