WIP: Qt: add QML based mobile GUI

icota commented at 3:11 pm on September 16, 2019: contributor

qt-mobile mobile_screenshot_2 mobile_screenshot_3

This adds a Qt Quick Controls 2 based UI meant for mobile devices. This is work-in-progress meant to gauge interest, related to but not dependent on #16110, i.e. one can run the “mobile” GUI on desktop as well. You should install qtdeclarative5-dev and qtquickcontrols2-5-dev in addition to usual Qt dependencies and configure with --enable-mobile-gui.

As a proof-of-concept this PR aims to be light, about 400 lines of C++ code that is meant to be a drop-in replacement for bitcoingui with mostly the same public functions and a couple of #ifdefs in bitcoin.cpp. There is also an addition of roleNames to the transactiontablemodel to make it compatible with QML stuff.

Replacement class bitcoinmobilegui hooks up to the exact same signals, models and controllers as bitcoingui. At the moment the mobile GUI presented to the user is dead simple (no multi-wallet, no advanced options) but it has been tested to allow the user to send and receive.

My rationale for making this is the fact that in a couple years phones will be powerful enough to run Core without much hassle. If we add some platform code for

verifying transactions only while in foreground or charging (to preserve battery)
enabling phone to phone transactions (NFC or bluetooth for enhanced privacy)
providing services to other local apps (think Lightning wallets, they could get the blockchain state from Core, no wasting of resources)

and release an official Android package I believe that this has the potential to put a full node in the pockets of millions - empowering users and improving the network.

fanquake added the label GUI on Sep 16, 2019

fanquake added the label Needs Conceptual Review on Sep 16, 2019

DrahtBot commented at 3:22 pm on September 16, 2019: member

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#18914 (refactor: Apply override specifier consistently by hebasto)
#18361 (build: Make the help string for –with-gui configure option unambiguous by hebasto)
#18298 (build: Fix Qt processing of configure script for depends with DEBUG=1 by hebasto)
#18297 (build: Use pkg-config in BITCOIN_QT_CONFIGURE for all hosts including Windows by hebasto)
#18077 (net: Add NAT-PMP port forwarding support by hebasto)
#17659 (qt: Do not block GUI thread in RPCConsole by hebasto)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

BlockMechanic commented at 2:30 pm on September 17, 2019: contributor

Awesome, sorry could not make it home yesterday, fires still spreading! But iwill try tomorrow.

laanwj commented at 8:05 am on September 18, 2019: member

:eyes: This looks very slick, and having a mobile interface for Bitcoin Core would be neat for projects such as ABCore. @greenaddress something for you?

ryanofsky commented at 2:04 pm on September 18, 2019: member

Whilst I don’t think this is something that we’d merge into this repository

Are you saying we wouldn’t merge any QML UI into the repository, or that we wouldn’t merge this change in its current draft form with ifdefs and the like?

IIUC, one nice thing that QML enables in addition to a mobile UI, is a remotely accessible web UI: https://www.qt.io/blog/2018/11/23/qt-quick-webgl-release-512

promag commented at 2:17 pm on September 18, 2019: member

AFAIK considering the current QML state of the art it wouldn’t be accepted in core - because JS engine etc.

In Qt6, according to Lars Knoll in https://www.qt.io/blog/2019/08/07/technical-vision-qt-6:

Make JavaScript an optional feature of QML. Having a full JavaScript engine when using QML can complicate things and is an overhead especially when targeting low-end hardware such as microcontrollers. It is however extremely useful in many use cases.

IMHO it’s still too early to consider QML since that there are some issues regarding long operations blocking the Qt event loop.

Prototype ACK

sipa commented at 4:45 pm on September 18, 2019: member

@promag Is there an actual JS interpreter used at runtime? Some quick googling tells me that with “Qt Quick” the JS is compiled to C++, which seems much less worrisome.

Issues around blocking UI are orthogonal, as they equally apply to the current UI.

This sounds really cool actually. Assuming it’s feature complete, I wouldn’t object to merging it in as an optional UI module in the repo.

sipa commented at 5:34 pm on September 18, 2019: member

When I build with --enable-mobile-gui, the produced bitcoin-qt binary shows an empty non-updating window. Is there anything else needed to enable this?

fanquake commented at 0:19 am on September 19, 2019: member

Are you saying we wouldn’t merge any QML UI into the repository, or that we wouldn’t merge this change in its current draft form with ifdefs and the like?

What I meant was do we actually want to add another GUI to this repository? If we do, what are the plans / objectives for it?

Would it just exist as a bare-minimum, “here’s an example of how you might build a QML based/mobile GUI”? Or would it get built out to add features similar to those mentioned in the PR description, and one day we’d be releasing a Bitcoin Core Android package? If it’s the later, is this repository where we want to be doing all that development / having those discussions?

Assuming it’s feature complete, I wouldn’t object to merging it in as an optional UI module in the repo.

What should we consider feature complete here, basic send/receive functionality? I’m concerned that if it’s optional, it wont get built / tested 99% of the time and will likely just break / rot.

promag commented at 0:25 am on September 19, 2019: member

Previous discussions in:

luke-jr commented at 0:55 am on September 19, 2019: member

Regardless of the below, General Concept ACK.

I think it would be best as a separate frontend/repo, though. No need to embed into the main repo just to be split out later…

My rationale for making this is the fact that in a couple years phones will be powerful enough to run Core without much hassle.

We’re headed in the opposite direction (it’s getting harder, not easier, since technology can’t keep pace with the block size).

providing services to other local apps (think Lightning wallets, they could get the blockchain state from Core, no wasting of resources)

We already have that?

release an official Android package

Can this be done via gitian?

jonasschnelli commented at 7:27 am on September 19, 2019: contributor

Great work! Support for mobile devices is something we should not dismiss since those platforms (Android/iOS) are fairly popular.

I would not be opposed to merge something like this as an experimental feature – if the risks of breaking the current GUI is at minimum.

A web based JS/CSS frontend, as most desktop and some mobile apps use it today, is something a lot of contributors to this project dislike.

But AFAIK QML/JS compiles to native code…

I think we should follow this. Eventually merge something like this. If it will not be maintained, used, followed, remove it (as long as it is marked as experimental).

icota commented at 10:23 am on September 19, 2019: contributor

What should we consider feature complete here, basic send/receive functionality?

My idea is to eventually have 90% of the features available to the QtWidgets GUI user, but hidden away behind a prompt of some kind so a normal user doesn’t need to know or touch anything. I believe most of the users (especially on mobile) just want idiot-proof send/receive so don’t want to overwhelm them. Perhaps this PR is the ‘dumb’ rather than ‘mobile’ GUI.

providing services to other local apps (think Lightning wallets, they could get the blockchain state from Core, no wasting of resources)

We already have that?

Correct me if I’m mistaken but doesn’t RPC have loads of dangerous calls (wallet stuff, etc…)? Can one connect to Core RPC with just a subset for chain monitoring? I was thinking about a ‘hardened RPC’ for local apps, perhaps even permissioned.

When I build with –enable-mobile-gui, the produced bitcoin-qt binary shows an empty non-updating window. Is there anything else needed to enable this?

If you have qtdeclarative5-dev and qtquickcontrols2-5-dev installed I reckon that should be enough. Care to share your logs when this happens?

BlockMechanic commented at 10:35 am on September 19, 2019: contributor

@icota see #16916 for the promised PR that contains my working android build. My command is :-

make HOST=i686-linux-android ANDROID_API_LEVEL=24 ANDROID_TARGET_ARCH=x86 ANDROID_TOOLCHAIN_BIN=/opt/android_ndk/toolchains/llvm/prebuilt/linux-x86_64/bin ANDROID_SDK=/opt/android-sdk-linux ANDROID_NDK=/opt/android_ndk -j 4

promag commented at 11:13 am on September 19, 2019: member

Is there anything else needed to enable this? @sipa which Qt, etc?

luke-jr commented at 12:05 pm on September 19, 2019: member

Correct me if I’m mistaken but doesn’t RPC have loads of dangerous calls (wallet stuff, etc…)? Can one connect to Core RPC with just a subset for chain monitoring?

RPC whitelisting is a thing now

promag commented at 3:23 pm on September 20, 2019: member

I think we could start by writing basic developer notes for qml code - component recommendation, how to name properties/vars, order , etc, where to write JS (inlined?), what is acceptable in QML, translations, etc.

In this PR I’d drop all unnecessary stuff, for instance everything related to multimedia.

BlockMechanic commented at 2:40 pm on September 22, 2019: contributor

Also go the depends system to behave, if anyone wants the mods to make it build via depends, let me know.

icota force-pushed on Sep 22, 2019

icota commented at 4:19 pm on September 22, 2019: contributor

mobile_screenshot_new_1 mobile_screenshot_new_2 I’ve rebased on top of master and added:

transaction dialog
about pane
settings pane
dark mode

I’ll try to do weekly updates like this.

I think we could start by writing basic developer notes for qml code - component recommendation, how to name properties/vars, order , etc, where to write JS (inlined?), what is acceptable in QML, translations, etc.

Probably best to adopt the coding conventions off Qt’s website? I’ve added a link to developer notes.

In this PR I’d drop all unnecessary stuff, for instance everything related to multimedia.

Multimedia is neccessary for camera QR code scanning, this is a placeholder right now but will be enabled as soon as I find out the least painful way to add an image processing dependency like qzxing. I’m also using bits of multimedia to invert the icons colour for dark mode.

laanwj added the label Android on Sep 30, 2019

laanwj added the label Feature on Sep 30, 2019

icota commented at 3:51 pm on September 30, 2019: contributor

mobile_screenshot_newer_1 mobile_screenshot_newer_2 Another week another update. Added:

ability to change display unit
console pane :computer:
clipboard handling
internationalisation (system locale used unless otherwise specified - bitcoinTr to reuse the current QtWidgets translations and the standard qsTr for new mobile-specific strings)

hebasto commented at 7:22 pm on October 6, 2019: member

Concept ACK.

DrahtBot added the label Needs rebase on Oct 26, 2019

Qt: add QML based mobile GUI fdb10568c9

mobile: expose licenceInfo and version to QML a1d23b73e8

mobile: remove unnecessary newlines in splash progress string c8defba58f

qml: add settings and about panes, dark mode and transaction info 397bf45ccb

qml: adopt official Qt conventions 6b4feb75bb

mobile: add method to set clipboard from QML 31d941a6d8

mobile: copy address to clipboard when tapping QR code 46a60a8d10

mobile: only activate camera when on send pane c14b0274e1

qml: expose units and confirmation targets to QML c08586f576

qml: add ability to send RPC calls and console pane 1b7b09a403

qml: don't translate the < symbol c3090bc04f

qml: add snap and clip to transactions list 6d942b83fc

qml: set current display unit as main context property and handle amount input accordingly b2fe56e166

Qt: don't show QtWidgets splash if using mobile GUI f8db7e67e9

qml: disable dark mode for now c53ece1a6d

qml: show correct unit in combobox 9ae348eeaa

qml: make transaction info scrollable f84d58baa1

qml: use own 'about' string 7237e1439d

icota force-pushed on Nov 5, 2019

icota commented at 10:11 am on November 5, 2019: contributor

Rebase and some small fixes.

DrahtBot removed the label Needs rebase on Nov 5, 2019

promag commented at 0:00 am on April 12, 2020: member

@icota are you planning to working on this?

I think this should be split - probably start with build support and with qtquickcompiler enabled?

in src/Makefile.qt.include:41 in 7237e1439d outdated

37@@ -38,6 +38,7 @@ QT_MOC_CPP = \
38   qt/moc_bitcoinamountfield.cpp \
39   qt/moc_bitcoin.cpp \
40   qt/moc_bitcoingui.cpp \
41+  qt/moc_bitcoinmobilegui.cpp \

promag commented at 4:36 pm on April 12, 2020:

Avoid “mobile” for now? I’d prefer “touch”.

icota commented at 7:46 pm on April 12, 2020:

Agreed that it shouldn’t be “mobile”. But “touch” implies touchscreens when it’s perfectly usable with a mouse & keyboard combo. perhaps “qml”? “modern”? “nextgen”? :smile:

promag commented at 1:05 pm on August 31, 2020:

🤷

icota commented at 7:58 pm on April 12, 2020: contributor

@icota are you planning to working on this?

Yes, but lately I’m not sure if this is the right approach. I don’t like the #ifdefs so I’d like to find a way to keep this GUI separate in line with the general multi-process direction Core is taking.

I promised in #18179 to open an issue about this “in the coming days”. l’ll try to do it soon™.

DrahtBot commented at 6:45 pm on May 11, 2020: member

🐙 This pull request conflicts with the target branch and needs rebase.

DrahtBot added the label Needs rebase on May 11, 2020

jonasschnelli commented at 7:34 am on May 29, 2020: contributor

@icota are you still maintaining this? Any idea how we could proceed with something like this in smaller, more digestible PRs?

icota commented at 0:03 am on May 30, 2020: contributor

@jonasschnelli I’m sad to say that right now I don’t have the spare time to maintain this. Should I close the PR or let it linger? What’s the procedure in cases like this?

Any idea how we could proceed with something like this in smaller, more digestible PRs?

As it stands it’s a “minimum viable” GUI with just the bare send/receive functionality. However the QR scanning code could probably be removed to make it a tad smaller. Most of the linecount is in the .qml files.

BlockMechanic commented at 4:38 pm on June 21, 2020: contributor

@icota i amy be coming into some free time soon. If it works out, i’ll push this along.

BlockMechanic commented at 2:06 am on June 27, 2020: contributor

@icota what modifications did you do to the depends to make it compile ? I cant seem to get the dependencies right. I added qtgraphicaleffects, qtdeclarative, qtquickcontrols and qtquickcontrols2. During compilation it then states : -

Some of the required modules (qtHaveModule(quick)) are not available.

Any ideas ?

MarcoFalke deleted a comment on Jun 27, 2020

icota commented at 8:59 am on June 30, 2020: contributor

Any ideas ? @BlockMechanic Try installing qtquick as well, in Debian derivatives it’s libqt5quick5.

hebasto commented at 5:31 pm on August 30, 2020: member

@icota How easy would it be to integrate Qt5Qml, Qt5Quick, and Qt5QuickControls2 into our depends to make statically linked builds?

icota commented at 10:08 pm on August 30, 2020: contributor

@hebasto It doesn’t seem too hard, I took a quick stab at it here

hebasto commented at 11:48 am on August 31, 2020: member

@hebasto It doesn’t seem too hard, I took a quick stab at it here

Thanks for that stab. Having an error when cross-compiling it for macOS:

0$ make -C depends HOST=x86_64-apple-darwin16
1...
2make[3]: x86_64-apple-darwin16-ar: Command not found
3make[3]: *** [Makefile:936: ../../lib/libQt5Qml.a] Error 127

promag commented at 12:54 pm on August 31, 2020: member

We need multimedia too for qzxing, but I guess that can come next.

in src/qt/res/qml/AboutPane.qml:10 in 7237e1439d outdated

 5+
 6+Pane {
 7+    id: aboutPane
 8+
 9+    ColumnLayout {
10+        id: aboutColumn

promag commented at 1:00 pm on August 31, 2020:

I think we could use same convention used in c++, this (ids and variables var/let/const) could be about_column. Property names could be camelCase and components CamelCase. Anyway, unused ids could be removed.

in src/qt/bitcoinmobilegui.cpp:133 in 7237e1439d outdated

128+    this->rootContext()->setContextProperty("version", QString::fromStdString(FormatFullVersion()));
129+
130+    connect(this->rootObject(), SIGNAL(copyToClipboard(QString)), this, SLOT(setClipboard(QString)));
131+    connect(this->rootObject(), SIGNAL(changeUnit(int)), this, SLOT(setDisplayUnit(int)));
132+
133+    m_walletPane = this->rootObject()->findChild<QObject*>("walletPane");

promag commented at 1:05 pm on August 31, 2020:

I kind of NACK this approach but I don’t mind to refactor this later.

in src/qt/res/qml/WalletPane.qml:185 in 7237e1439d outdated

180+
181+                        MenuItem {
182+                            text: qsTr("About")
183+                            font: theme.thinFont
184+                            onTriggered: {
185+                                stackView.push(aboutPane)

promag commented at 1:07 pm on August 31, 2020:

I think this is in the wrong place. This is similar to use global variables and IMO it’s fragile (but convenient). I’d suggest to add a property required Action aboutAction to this component and set it in main.qml.

icota commented at 2:33 pm on August 31, 2020: contributor

Thanks for that stab. Having an error when cross-compiling it for macOS:

0$ make -C depends HOST=x86_64-apple-darwin16
1...
2make[3]: x86_64-apple-darwin16-ar: Command not found
3make[3]: *** [Makefile:936: ../../lib/libQt5Qml.a] Error 127

@hebasto I hit the same error. I’ll take a look. @promag Thank you for the feedback. I see a general consensus towards a QML-based next-gen UI (but please correct me if I’m wrong everyone). Seeing we now have actual designers working on Core (who also seem to be keen on QML) should we not focus on implementing whatever awesome device agnostic UI that team comes up with rather than pushing this PR any further.

What’s vaulable here is the code reusing bitcoin-qt data models and signals and not the mobile-focussed very monochrome UI.

Insomma I think a good way forward would be:

Designers mock up a next-gen UI
Devs implement it in QML, adding qzxing and qtdeclarative to depends, statically linking

Doesn’t seem to me this PR is a good vehicle for #2 but perhaps it might make sense to keep it open for visibility of the reusable bits.

promag commented at 2:39 pm on August 31, 2020: member

I’d suggest to make this draft PR then.

icota marked this as a draft on Aug 31, 2020

michaelfolkson commented at 6:54 pm on September 2, 2020: contributor

What are your latest thoughts on QML @promag? You said you thought it was too early in September 2019. Are you of the same view now?

We are proceeding on the basis that QML is worth exploring but with no guarantee that it is an overall Concept ACK. The Concept (N)ACK will only become clear when there is a PR opened using QML where the upsides/downsides of using it are clearer and there is code to review.

BlockMechanic commented at 7:05 pm on September 2, 2020: contributor

I’d suggest to make this draft PR then. @icota Hey, I noticed however that clicking close does not actually close/shutdown the wallet, just the GUI, i end up having to kill the process. A bit of research shows that this likely comes from using QQmlEngine instead of QQmlApplicationEngine. Is there any particular reason you chose QQmlEngine ?

Bosch-0 commented at 5:33 am on September 3, 2020: none

Seeing we now have actual designers working on Core (who also seem to be keen on QML) should we not focus on implementing whatever awesome device agnostic UI that team comes up with rather than pushing this PR any further.

From a design perspective QML would give designers much more flexibility and save a lot of time (instead of having to do mockups for Mac, Linux and Windows we could just do one). There also seems to be some minor design inconsistencies translating between the OS’s using Qt widgets which could be avoided using QML

Designers mock up a next-gen UI

I’d be happy to do this. Having some designs prior to concept ACK could help with ACK by illustrating the flexibility that QML could offer.

icota commented at 12:09 pm on September 5, 2020: contributor

Hey, I noticed however that clicking close does not actually close/shutdown the wallet, just the GUI, i end up having to kill the process. A bit of research shows that this likely comes from using QQmlEngine instead of QQmlApplicationEngine. Is there any particular reason you chose QQmlEngine ? @BlockMechanic QQmlApplicationEngine is a convenience function for instantiating QQmlEngine within a QApplication. But we already have a BitcoinApplication class that inherits QApplication. See here: https://github.com/bitcoin/bitcoin/blob/81a19e725304bc77c39491f312913b47b76a6dac/src/qt/bitcoin.h#L55

What I failed to do is to connect to or call QApplication::quit somewhere in bitcoinmobilegui. It’s on my todo list :spiral_notepad:

hebasto commented at 12:38 pm on September 5, 2020: member

@icota This bug is fixed in #19882.

BlockMechanic commented at 0:45 am on September 13, 2020: contributor

@icota I managed to solve the close/shutdown issue.

If anyone wants the fix, just let me know and I’ll make a PR.

icota commented at 5:04 pm on September 13, 2020: contributor

@icota I managed to solve the close/shutdown issue.

If anyone wants the fix, just let me know and I’ll make a PR.

Sounds great. Obvious improvements like that are of course more than welcome. :+1:

BlockMechanic commented at 6:44 pm on September 13, 2020: contributor

@icota I managed to solve the close/shutdown issue. If anyone wants the fix, just let me know and I’ll make a PR.

Sounds great. Obvious improvements like that are of course more than welcome.

Pull request now on your git.

Qt: implement mobile UI shutdown 2b8f9226e6

BlockMechanic commented at 4:14 am on November 16, 2020: contributor

Currently the notificator does not have code specific to android. Anyone want to collaborate on this and other small stuff ? Here is a list of some stuff i’ve noticed and been working on. or completed already

App Drawer navigation (complete)
Coin control (idea only)
Wallet encryption, backup (incomplete)
Multi-wallet support (idea only)
Simpler color scheme( theme )support (idea only )

Anyone interested in working on these with me can let me know and we can get it done.

icota commented at 7:11 pm on November 16, 2020: contributor

Hi @BlockMechanic, if you are looking to collaborate on such subjects perhaps join Bitcoin Design community on Slack. There is a bitcoin-core-gui channel.

promag commented at 1:40 am on December 9, 2020: member

What are your latest thoughts on QML @promag? You said you thought it was too early in September 2019. Are you of the same view now?

We are proceeding on the basis that QML is worth exploring but with no guarantee that it is an overall Concept ACK. The Concept (N)ACK will only become clear when there is a PR opened using QML where the upsides/downsides of using it are clearer and there is code to review. @michaelfolkson

I’d say Qt Quick is the best option to a) have bitcoin core GUI running on android and iOS b) have a modern GUI. Qt Quick Controls are getting better each release and QML has received lots of improvements. Concept ACK in this regard.

hebasto commented at 3:42 am on December 9, 2020: member

~Kindly reminder to reviewers who is interested in QML – please test and review #19882 :)~

Bosch-0 commented at 8:59 am on December 11, 2020: none

If a switch to QML is likely going to occur (which I think is the way to go going forward for reasons outlined above) in the future I think it would be good to start working on first principles, ground up, fresh UI designs for the GUI instead of bolting on changes to the current very restrictive widgets. Continuing to do this will just incur technical and design debt that we can’t afford to take on.

To save resources I’d like to propose a design freeze of sorts on the current GUI widgets implementation and just focus on adding new protocol changes in a very low fidelity way whilst a complete new design is worked on and ready by the time a technical implementation of QML happens. Design foundations (such as clarity around branding and a design system) would also be established in parallel to designing this fresh new GUI.

We could start by creating a project to track these designs and have an issue posted and pinned to the GUI repo for “WIP: GUI re-designs” that can have a link to active Figma design work being conducted by community members such as myself. Any comments / suggestions / discussions should be posted on that issue, and not on Figma, to keep the discussions here and prevent any designer / developer divide.

Would this PR also not be more relevant in the GUI repo?

hebasto commented at 9:01 am on December 11, 2020: member

Would this PR also not be more relevant in the GUI repo?

Build system changes belong to the main repo.

icota commented at 9:39 am on December 11, 2020: contributor

To save resources I’d like to propose a design freeze of sorts on the current GUI widgets implementation and just focus on adding new protocol changes in a very low fidelity way whilst a complete new design is worked on and ready by the time a technical implementation of QML happens. Design foundations (such as clarity around branding and a design system) would also be established in parallel to designing this fresh new GUI.

We could start by creating a project to track these designs and have an issue posted and pinned to the GUI repo for “WIP: GUI re-designs” that can have a link to active Figma design work being conducted by community members such as myself. Any comments / suggestions / discussions should be posted on that issue, and not on Figma, to keep the discussions here and prevent any designer / developer divide. @Bosch-0 I agree that this is the way forward. However, current widgets design freeze might not be wise because we don’t know when the QML implementation will be production ready.

I’d like to propose the new design be adaptive to both mobile and desktop. But both of these discussion are for the GUI repo issue.

promag commented at 9:34 am on December 14, 2020: member

@sipa

@promag Is there an actual JS interpreter used at runtime? Some quick googling tells me that with “Qt Quick” the JS is compiled to C++, which seems much less worrisome.

@sipa I think “compiled to C++” needs clarification, there’s still runtime execution, see https://stackoverflow.com/a/41287809/1978589.

But in Qt 6, from https://www.qt.io/blog/2019/08/07/technical-vision-qt-6:

Make JavaScript an optional feature of QML. Having a full JavaScript engine when using QML can complicate things and is an overhead especially when targeting low-end hardware such as microcontrollers. It is however extremely useful in many use cases.

hebasto commented at 9:45 am on December 14, 2020: member

@sipa

@promag Is there an actual JS interpreter used at runtime? Some quick googling tells me that with “Qt Quick” the JS is compiled to C++, which seems much less worrisome.

To compile QML source code into the final binaries the Qt Quick Compiler could be used.

promag commented at 10:02 am on December 14, 2020: member

@hebasto

@sipa

@promag Is there an actual JS interpreter used at runtime? Some quick googling tells me that with “Qt Quick” the JS is compiled to C++, which seems much less worrisome.

To compile QML source code into the final binaries the Qt Quick Compiler could be used.

I was already assuming qtquickcompiler would be enabled, but there’s still the JVM. See https://stackoverflow.com/a/62393490/1978589.

BlockMechanic commented at 9:26 am on December 28, 2020: contributor

Has anyone built this using depends for windows and succeeded ? I Am running into an issue :-

2020-12-27T16:26:43Z GUI: qrc:/qml/main.qml:1:1: module "QtQuick" is not installed 2020-12-27T16:26:43Z GUI: qrc:/qml/main.qml:3:1: module "QtQuick.Controls.Material" is not installed 2020-12-27T16:26:43Z GUI: qrc:/qml/main.qml:4:1: module "QtQuick.Layouts" is not installed 2020-12-27T16:26:43Z GUI: qrc:/qml/main.qml:2:1: module "QtQuick.Controls" is not installed 2020-12-27T16:26:43Z GUI: QObject::connect: Cannot connect (null)::copyToClipboard(QString) to BitcoinMobileGUI::setClipboard(QString) 2020-12-27T16:26:43Z GUI: QObject::connect: Cannot connect (null)::changeUnit(int) to BitcoinMobileGUI::setDisplayUnit(int)

This is only on windows so far. Any ideas?

icota commented at 10:51 am on December 28, 2020: contributor

@BlockMechanic Unless I missed something, depends doesn’t include QtQuick (yet) so I don’t think it matters which OS you’re building on.

BlockMechanic commented at 11:05 am on December 28, 2020: contributor

@BlockMechanic Unless I missed something, depends doesn’t include QtQuick (yet) so I don’t think it matters which OS you’re building on.

I am using a modified depends based on the PR I made.

in build-aux/m4/bitcoin_qt.m4:463 in 2b8f9226e6

459 
460   BITCOIN_QT_CHECK([AC_CHECK_HEADER([QtPlugin],,BITCOIN_QT_FAIL(QtCore headers missing))])
461   BITCOIN_QT_CHECK([AC_CHECK_HEADER([QApplication],, BITCOIN_QT_FAIL(QtGui headers missing))])
462   BITCOIN_QT_CHECK([AC_CHECK_HEADER([QLocalSocket],, BITCOIN_QT_FAIL(QtNetwork headers missing))])
463+  BITCOIN_QT_CHECK([AC_CHECK_HEADER([QQmlApplicationEngine],, BITCOIN_QT_FAIL(QtQml headers missing))])
464+

BlockMechanic commented at 1:10 am on January 2, 2021:

There are some missing parts to this file that enable static linking. If you compile the depends statically, there is an additional folder ‘qml’ which contains libs required for statically linking, such as libqtquick2plugin.a .

laanwj referenced this in commit 23b15601df on Mar 24, 2021

hebasto commented at 9:43 pm on June 13, 2021: member

All devs who are interested in the next-gen QML-based GUI for Bitcoin Core, please consider joining the dedicated https://github.com/bitcoin-core/gui-qml repo.

hebasto referenced this in commit 955fa34231 on Jul 7, 2021

fanquake referenced this in commit 4315dc02a1 on Jul 18, 2021

sidhujag referenced this in commit 4a59fda74b on Jul 23, 2021

DrahtBot commented at 11:22 am on December 15, 2021: member

Is it still relevant? ➡️ Please solve the conflicts to make it ready for review and to ensure the CI passes.
Is it no longer relevant? ➡️ Please close.
Did the author lose interest or time to work on this? ➡️ Please close it and mark it ‘Up for grabs’ with the label, so that it can be picked up in the future.

MarcoFalke commented at 11:29 am on December 15, 2021: member

I guess this is now superseded by https://github.com/bitcoin-core/gui-qml?

hebasto commented at 11:36 am on December 15, 2021: member

I guess this is now superseded by https://github.com/bitcoin-core/gui-qml?

Yeap :tiger2:

MarcoFalke commented at 11:37 am on December 15, 2021: member

Ok, closing for now.

MarcoFalke closed this on Dec 15, 2021

fanquake referenced this in commit 3eaf7be6ad on Dec 8, 2022

sidhujag referenced this in commit 5dde8cb2a6 on Dec 8, 2022

DrahtBot locked this on Dec 15, 2022

WIP: Qt: add QML based mobile GUI #16883

Conflicts