qt-web-view-widget
qt-web-view-widget | lqml | |
---|---|---|
1 | 24 | |
1 | - | |
- | - | |
0.0 | - | |
over 2 years ago | - | |
C++ | ||
MIT License | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
qt-web-view-widget
-
Qt 6.3 Released
It really confuses me how anyone would have anything good to say about QML. Qt taking that direction just seems like a panicked decision to try and compete with Electron when they should really be doing the exact opposite.
My experience with QML/Quick is that while you get a little JavaScript runtime and a slightly less obtuse way of defining "widgets" and application layouts than the original Qt "forms", there are some clear drawbacks that make it a near non-starter for anything I've thought about using it for.
Right out of the box, you have to use QML, which is a weird hybrid of language/markup paradigms, and it's a proprietary language. What designer knows QML? Probably f$#%& zero. Electron wins right out of the gate because what designers don't know at least something about HTML and CSS? Sure, if QML was that groundbreaking then maybe people would learn it, but it's owned by a company and it brings nothing new to the table that HTML and CSS can't do better.
The solution to most things in QML is to write JavaScript. I've been a JavaScript engineer for most of my career, but when you're writing a Qt application then the obvious place to do anything useful or complex is in the host language of C++ or Python. So what if you want to tie behavior between your QML widget and a C++ library you either wrote yourself or have imported from a vendor? Well, you can kinda sorta do that, but it's hard to explain here; let's just say that tying a widget to C++ code is extremely clumsy, and good luck calling a function on a QML widget class because you just can't simply do that.
For instance, Qt provides a WebView widget, which was exactly what I needed recently. Uh oh, the decided to make it a QML widget only, rather that do the obvious thing of exposing it as a C++ class and providing a QML widget that wraps around it. Why did they do this? I guess it's because in the long term they think that they'll move away from classic widgets entirely. In any case, I wanted to call the `runJavaScript` method on the widget class without having to jump through hoops in QML. The only way to make that happen was to hack the build process to expose private methods.
But I realized that, at that point, there was no longer any point in using QML if I was going to have to use some neat tricks in C++.
So in just a day, I wrote a classic widget that implements the same WebView used in the QML version, just without any of the QML crap.
https://github.com/Ravenstine/qt-web-view-widget
And yeah, Qt does provide some form of a WebView in as a classic widget but, guess what, it involves bundling a browser runtime rather than using the browser engine of the host OS. Makes sense if you need more of the browser APIs exposed, but if all you want to do is show some simple things on a webpage and call JS from C++, then going through the effort of compiling Qt with support for that browser engine is overkill.
Overall, I don't mind most things about Qt. Despite how overcomplicated some of it is, it does what I want, which is to allow me to write native desktop apps without needing to invest much of my knowledge in OS-specifics. I like that I can use their Bluetooth library and, besides some quirks with how macOS handles device identifiers, I can compile it on other platforms and it will work for the most part.
I wish they'd abandon QML and just focus on making the experience of writing completely native apps better.
lqml
- Qt 6.6 and 6.7 Make QML Faster Than Ever: A New Benchmark and Analysis
- Trying to build ECL for iOS
-
Iām going to create a toy project for playing with different UI libs
Was wondering how practical using lqml for developing Android apps would be.
-
New LQML example: a simple proof-of-concept meshtastic messaging app
screenshot / repo / official meshtastic web site
-
Is Lispworks the only option for developing iOs apps in CL?
There is lqml, which is cross-platform, including iOS.
-
Lisp scripting on Android
Check out https://gitlab.com/eql/lqml and other repositories in this group.
-
Mobile app "cl-repl" (LQML) to replace "CL REPL" (EQL5)
The advantage of LQML is that you can develop your app on the desktop first (as I did with the cl-repl app), mostly without restarting anything, because QML can be reloaded at runtime. A good example to learn how this works would be this one: qml-auto-reload
-
Status update on my CL editor
Notably - 1. https://github.com/lispnik/iup/ 2. https://gitlab.com/eql/lqml 3. https://github.com/bohonghuang/cl-gtk4
- GTK4 Bindings for Common Lisp
-
Is there a way to call an objective C method from an lqml function?
In this example, there is an example call to Objective-C, which in turn is callable from Lisp.
What are some alternatives?
pub-dev - The pub.dev website
awesome-lisp-companies - Awesome Lisp Companies
CodeParadise - Framework for developing web applications and Node.js applications using Smalltalk
TodoMVC-QML - Minimal QML implementation of the classical TodoMVC
smallfunction - Stack allocated and type-erased functors š
clog - CLOG - The Common Lisp Omnificent GUI
swank-client - A Swank client implemented in JavaScript
clog-typeahead - CLOG Extension for https://github.com/twitter/typeahead.js
ledstudio
parrot - A cross-platform Common Lisp editor
imgui - Dear ImGui: Bloat-free Graphical User interface for C++ with minimal dependencies
clog - CLOG - The Common Lisp Omnificent GUI