Showcase

@keksi-venksi

Hi,
nice,
maybe you want to move this topic to the Showcase category as it is not a question or an issue, but already a solution you want to share.

https://forum.qt.io/category/8/showcase

(Or you wait until some @moderators might move it)

@qxorm said in QxOrm 1.5.0 and QxEntityEditor 1.2.8 released (Qt ORM/ODM):

Hello,

QxOrm library 1.5.0 and QxEntityEditor application 1.2.8 just released.

QxOrm library 1.5.0 changes log :

Fix qx::dao::fetch_by_id_with_relation() when a table alias is used (table alias is now used in the WHERE part instead of table name)
Fix qx::IxDataMember::getType() method when used in a multi-thread environment
New method qx::IxSqlRelation::linkRelationKeyTo() for MongoDB database to simulate lazy loading for relationships (GitHub #107)
Fix qx::QxSqlDatabase and multi-thread issue when the OS assigns an old and destroyed thread identifier to a new one (GitHub #42) + add method qx::QxSqlDatabase::removeDatabaseByThread() to call at the end of a thread execution
Fix qx::QxSimpleCrypt class with Qt version >= 5.10 and error "Attempted to overwrite a QRandomGenerator to system() or global()"
Fix database not opened using async queries (GitHub #109)
QxEntityEditor application 1.2.8 changes log :

New export plugin 'QxEESourceControlExport' : export a *.qxee QxEntityEditor project file to a list of JSON files which can be easily check-in in a source control repository (Git, Perforce, CVS, etc...)
New import plugin 'QxEESourceControlImport' : import a list of JSON files (generated using 'QxEESourceControlExport' export plugin) inside a *.qxee QxEntityEditor project file
These 2 new plugins allow a team development to work simultaneously on a same *.qxee QxEntityEditor project file
A typical workflow could be (with 2 developers named dev A and dev B) :
dev A and dev B work on a same *.qxee QxEntityEditor project file
dev A create/modify/change some entities in QxEntityEditor application
dev B create/modify/change other entities in QxEntityEditor application
dev A and dev B export the *.qxee project file using the new 'QxEESourceControlExport' export plugin
Once exported, dev A and dev B check-in the JSON files inside the source control manager (Git, Perforce, CVS, etc...) on their own branch
dev A and dev B integrate from their own branch to the DEV (or MAIN or MASTER) branch (if there are some conflicts to resolve, it should be easy because JSON files are easy to read and understand)
dev A and dev B can now get latest JSON files from the DEV (or MAIN or MASTER) branch : these JSON files contain both modifications from dev A and dev B
dev A and dev B can import these JSON files inside QxEntityEditor application using the new 'QxEESourceControlImport' import plugin
These 2 new plugins can be executed using command line (like all other QxEntityEditor plugins), here are 2 examples :
Export : QxEntityEditor --no_gui --project="C:\Temp\qxBlog.qxee" --plugin=QxEESourceControlExport --QxEESourceControlExport_path="C:\Temp\source_control"
Import : QxEntityEditor --no_gui --project="C:\Temp\qxBlog.qxee" --plugin=QxEESourceControlImport --QxEESourceControlImport_path="C:\Temp\source_control\qxBlog.qxee.export.json"

The recent updates for QxOrm library and QxEntityEditor application bring several important improvements:

QxOrm Library 1.5.0 includes fixes for issues like table alias handling in queries, multi-threading problems, and database async queries. New features include a method for simulating lazy loading in MongoDB and improvements to handle thread identifiers and cryptographic functions.

QxEntityEditor 1.2.8 introduces new plugins for source control integration. The QxEESourceControlExport and QxEESourceControlImport plugins facilitate team development by allowing multiple developers to export and import .qxee project files as JSON, which can be easily managed in source control systems like Git or CVS. These plugins support a streamlined workflow for simultaneous project modifications and conflict resolution.

For more details and to use these new features, refer to the QxOrm and QxEntityEditor documentation or the GitHub repository.

@SimonSchroeder I doubt this library can help here. Can you please provide a minimal, compilable example in a bug report? I can take a look on it. Sounds similar to https://bugreports.qt.io/browse/QTBUG-122403 which needs a QIcon instead a QPixmap to make scaling work for your situation.

@J-Hilk I have spent couple days to update it to current SDK as half of stuff are deprecated.
Its 100% based on your example :D
would there be possible you could have a quick look to see why it returns 0 when obviously it shall return a values?
I think there would be only some import missing... however as I never worked with java, I can not know :(

package org.myapp.activity; import org.qtproject.qt.android.QtNative; import org.qtproject.qt.android.bindings.QtActivity; import android.os.*; import android.content.*; import android.app.*; import android.content.res.Resources; import android.content.res.Configuration; import android.util.DisplayMetrics; import android.view.Display; import android.hardware.display.DisplayManager; import android.view.Surface; import android.view.View; import android.view.DisplayCutout; import android.view.Window; import android.view.WindowManager; import android.view.WindowInsets; import android.view.WindowInsetsController; import android.graphics.Color; import androidx.core.view.WindowInsetsCompat; import androidx.core.view.WindowInsetsCompat.Type.InsetsType; public class MyActivity extends QtActivity { @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setCustomStatusAndNavBar(); } // onCreate void setCustomStatusAndNavBar() { // First check sdk version, custom/transparent System_bars are only available after LOLLIPOP if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) { Window window = getWindow(); // The Window flag 'FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS' will allow us to paint the background of the status bar ourself and automatically expand the canvas // If you want to simply set a custom background color (including transparent) for the statusBar/navigationBar, use the following addFlags call window.addFlags(WindowManager.LayoutParams.FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS); // The Window flag 'FLAG_TRANSLUCENT_NAVIGATION' will allow us to paint the background of the navigation bar ourself // But we will also have to deal with orientation and OEM specifications, as the navigationBar may or may not depend on the orientation of the device //window.addFlags(WindowManager.LayoutParams.FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS | WindowManager.LayoutParams.FLAG_TRANSLUCENT_NAVIGATION); // DEPRECATED (NOTE: is this needed as also setStatusBarColor() and setNavigationBarColor() are deprecated?) window.getDecorView().setSystemUiVisibility(View.SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN); // DEPRECATED // TODO: Use WindowInsetsController instead (NOTE: is this needed as also setStatusBarColor() and setNavigationBarColor() are deprecated?) // Set StatusBar Transparent window.setStatusBarColor(Color.TRANSPARENT); // DEPRECATED // TODO: Draw proper background behind WindowInsets.Type#statusBars()} instead //Set NavigationBar to desired color (0xAARRGGBB) set alpha value to 0 if you want a solid color window.setNavigationBarColor(Color.TRANSPARENT); // DEPRECATED // TODO: Draw proper background behind WindowInsets.Type#navigationBars() instead // Statusbar background is now transparent, but the icons and text are probably white and not really readable, as we have a bright background color // We set/force a light theme for the status bar to make those dark View decor = window.getDecorView(); decor.setSystemUiVisibility(decor.getSystemUiVisibility() | View.SYSTEM_UI_FLAG_LIGHT_STATUS_BAR); // DEPRECATED (NOTE: is this needed as also setStatusBarColor() and setNavigationBarColor() are deprecated?) } } // outdated https://medium.com/javarevisited/how-to-get-status-bar-height-in-android-programmatically-c127ad4f8a5d public double statusBarHeight() { // Method 1: Using Resources (still working, but preferable use current API solution) // double result = 0; // int resourceId = getResources().getIdentifier("status_bar_height", "dimen", "android"); // if (resourceId > 0) { // result = getResources().getDimension(resourceId); // } // return result; // Method 2: Using Window Insets (API 30+) WindowInsets windowInsets = getWindow().getDecorView().getRootWindowInsets(); double statusBarHeight = windowInsets.getInsets(WindowInsets.Type.statusBars()).top; // returns 0 (wrongly) return statusBarHeight; // Method 3: Using Display Metrics // Rect rectangle = new Rect(); // Window window = getWindow(); // window.getDecorView().getWindowVisibleDisplayFrame(rectangle); // int statusBarHeight = rectangle.top; // return statusBarHeight; } public int safeAreaTop() { // Still working, but preferable use current API solution // DisplayCutout cutout = getWindow().getDecorView().getRootWindowInsets().getDisplayCutout(); // if(cutout != null) { // int cutoutHeight = cutout.getSafeInsetTop(); // if (cutoutHeight > 0) { // return cutoutHeight; // } // } // return 0; // Using Window Insets (API 30+) WindowInsets windowInsets = getWindow().getDecorView().getRootWindowInsets(); int cutoutHeight = windowInsets.getInsets(WindowInsets.Type.displayCutout()).top; // returns 0 (wrongly) return cutoutHeight; } // If we decide to draw the behind the navigationBar, we need to know the new safearea, // so to not draw text or position buttons behind the nav bar. // Those would be unclickable and potentially unreadable. // ATTENTION: // Compared to the statuBbar, there is no guarantee that the behind will be at the bottom of your screen // This function returns the hight of the Navigation bar */ public double navBarHeight() { // Method 1: Using Resources (still working, but preferable use current API solution) // double result = 0; // int resourceId = getResources().getIdentifier("navigation_bar_height", "dimen", "android"); // if (resourceId > 0) { // result = getResources().getDimension(resourceId); // } // return result; // Method 2: Using Window Insets (API 30+) WindowInsets windowInsets = getWindow().getDecorView().getRootWindowInsets(); double navigationBarHeight = windowInsets.getInsets(WindowInsets.Type.navigationBars()).top; // returns 0 (wrongly) return navigationBarHeight; // Method 3: Using Display Metrics // Rect rectangle = new Rect(); // Window window = getWindow(); // window.getDecorView().getWindowVisibleDisplayFrame(rectangle); // int navigationBarHeight = rectangle.bottom; // return navigationBarHeight; } public int getNavBarPosition() { Resources res = getResources(); int resourceId = res.getIdentifier("config_showNavigationBar", "bool", "android"); boolean hasMenu = false; if (resourceId > 0) { hasMenu = res.getBoolean(resourceId); } if (!hasMenu) { return -1; } // https://stackoverflow.com/questions/69724946/getdisplay-return-display // Display display = getWindowManager().getDefaultDisplay(); // getDefaultDisplay() deprecated DisplayManager displayManager = (DisplayManager) getSystemService(Context.DISPLAY_SERVICE); Display display = displayManager.getDisplay(Display.DEFAULT_DISPLAY); int rotation = display.getRotation(); switch (rotation) { case Surface.ROTATION_90: return 1; case Surface.ROTATION_180: return 3; case Surface.ROTATION_270: return 2; default: return 0; } } }

@Axel-Spoerl
Thanks! I usually compile for older Linux and Windows (also for newer versions!). And it's so easy to upload.
It would be good if Qt themselves offered online downloads with the "MaintenanceTool" 12 months after the commercial version is launched.

I'm very aware of signals and slots. IMO JS-like promises solve a slightly different problem. Qt signals are shared among all subscribers. Promises are specific to a single function call.

In my lib I implemented promises using signal and slots. The difference is that there is a new QObject for each function call. In my experience this prevents potential issues with clients connecting to the same signal in the same object and then receiving multiple signals or having to manually disconnect after the first signal...

Also signals and slots are scattered in the class header and in many functions, while the promise approach is more self-contained.

@posktomten Thanks! That's exactly the audience it's aimed at. Let me know if there is any feedback.

The latest coverage report for ShoopDaLoop is here.

Grateful for the enriching insights provided in the recent blog regarding OHT+Behavior: heat-maps and path-maps for Qt GUIs, alongside user-interaction abstraction! If you're keen on delving further into this fascinating realm, I encourage you to explore our dedicated blog section on UX heatmap. Dive in and uncover more about enhancing user experiences!

Version 0.1.5 was released.

Changes:

New major feature: SDAPPS Support QML page autoresizing Loading progressbar Bug fixes & improvements

This release provide quite new feature - SDAPPS (Serverless DAPP), which allow users communicate with Web 3.0 without centralized server! You can install Serverless Decentralized Application (SDAPPS) directly from git source and ther run it locally.