DVS Light Wallet for Mac Open Beta

[modprobe]

OK, glad to hear the functionality is all there, it's just not presenting it correctly. Unfortunately, I am unable to reproduce the issue of failing to proceed after import, but I'll be seriously reworking that entire UX in the future anyways, so that'll probably render any current bugs defunct anyways.

And yes, that's the unfortunate hazard of doing your own builds. Gotta keep all the different dependencies in sync as well.

[arhag]

arhag: Needing to restart the client after restoring is a known issue in previous versions, but I haven't seen it in the latest version. Is your build up-to-date? Same with missing transactions in the history; that should not be happening anymore. In particular, try dragging down the history view to refresh it, and let me know if that pulls in the missing transactions.

I just pulled the latest updates (latest commit b0f66c9f77c569c10a96c15780d0b70504b04e57) and compiled again.

At first the client didn't load, because of this error:

Code: [Select]

QQmlApplicationEngine failed to load component
qrc:/qml/main.qml:353 Type BackupLayout unavailable
qrc:/qml/BackupLayout.qml:10 Cannot assign to non-existent property "onShowingChanged"
But I fixed that after I realized I had to rebuild/reinstall qml-material with all the updated changes. (I guess I will need to make a habit of checking that repository for any updates anytime I want to build a new latest version of LightWallet.)

Then, the client launched and I attempted recovering my account. Again, when I pressed Import Account nothing happened in the GUI, but I did get the following output in the terminal:

Code: [Select]

qml: PRESSED
2187674ms Wallet Im  json_connection.cpp:70        handle_message       ] recv: {"id":4,"result":{"id":473,"name":"arhag-light","public_data":null,"owner_key":"DVS8EyLcift3nU7zL73WhsGP3wd71p3GcbipDJ5kZw2yjaHAs4wiE","active_key_history":[["2015-02-01T03:48:50","DVS6AryKFGdYZRJmmT2HaSZcRcuv1Q6VvQjbWgfnGodWrUqriM8Uz"]],"registration_date":"2015-02-01T03:48:50","last_update":"2015-02-01T03:48:50","delegate_info":null,"meta_data":{"type":"public_account","data":""}}}
2188380ms Wallet Im  json_connection.cpp:70        handle_message       ] recv: {"id":5,"result":[[["DVS4DKUuFfL6dJfQ4kWhdayv11JHZ11MxVgy",{"condition":{"asset_id":0,"slate_id":0,"type":"withdraw_signature_type","data":{"owner":"DVSEmd5PghKWEGjnzSYQWvK4JNWwb8yHNo19","memo":null}},"balance":0,"restricted_owner":null,"snapshot_info":null,"deposit_date":"2015-02-01T06:36:00","last_update":"2015-02-01T06:38:50","meta_data":null}],["DVS6BCwPfrY1RmYQzP9CSNE6XJSGcZE9sq8G",{"condition":{"asset_id":0,"slate_id":11577634710984274078,"type":"withdraw_signature_type","data":{"owner":"DVSEmd5PghKWEGjnzSYQWvK4JNWwb8yHNo19","memo":{"one_time_key":"DVS8BE2mN2rsGgoaV1dgkPhwdYSi266kcKSUtUtQ3k5TQkUmsZapU","encrypted_memo_data":"cd8a8267d1f13a55eab3db9c0d41eecb07462d520dcac263fcb1e7b2a63429d5698b75e74228ebdc6857418e121c66fd5e4393350bb76bbb0ab205b789710acd"}}},"balance":0,"restricted_owner":null,"snapshot_info":null,"deposit_date":"2015-02-03T01:19:00","last_update":"2015-02-03T01:20:10","meta_data":null}],["DVSJNFNSppKT5EVUxZtVW5i2TWtxKsjziTC8",{"condition":{"asset_id":0,"slate_id":11577634710984274078,"type":"withdraw_signature_type","data":{"owner":"DVSEmd5PghKWEGjnzSYQWvK4JNWwb8yHNo19","memo":{"one_time_key":"DVS6kPMvYAjTFow5gAuD3rzF72iPEg1MV3NtK34g7DhVzhGgMwAFW","encrypted_memo_data":"4eaa40f41119d15a2dbdcd9db2605765e8c6919fbe00eb78e2352bd93c9be5dc6014e8c747fc66d006134976464f7422a2b6e7bf62c5e1f15f37c14d38af50d0"}}},"balance":0,"restricted_owner":null,"snapshot_info":null,"deposit_date":"2015-02-03T00:34:10","last_update":"2015-02-03T00:36:50","meta_data":null}]]]}

So I then closed the client and restarted it and like last time it had actually imported the old account despite the GUI problems. After unlocking the client I could appropriately see my 0 DVS balance and this time after refreshing the transaction history it pulled in all of my transactions. So, with the exception of that bug where pressing Import Account does nothing in the GUI (even though it really does import the account in the background), everything seems to be working now.

[modprobe]

The unfortunate fact is that building a windows installer is significantly more difficult and error-prone than building packages for Linux or Mac (I say this as someone with experience doing all three). Our Windows team is working on it, and I have full confidence they'll have something working for us soon. I'll definitely be letting you all know once they've got something.

The upside is that once the first one is done, all the hard part is out of the way and the rest will simply be swapping out the binary and re-running a script. Future releases will be much faster.

[clayop]

Just posted an updated binary (this change is not in the devshares branch yet) which should fix the junk data in the brain key.

As to the Windows folks, I've contacted the guys who do our normal Windows builds and installers, and they'll be working today on getting an installer working. I make no promises as to when it will be available, but there are now experienced people working on it.

Great work! I updated my post in Korean community asking testing. What is the current process about windows version?

[modprobe]

Just posted an updated binary (this change is not in the devshares branch yet) which should fix the junk data in the brain key.

As to the Windows folks, I've contacted the guys who do our normal Windows builds and installers, and they'll be working today on getting an installer working. I make no promises as to when it will be available, but there are now experienced people working on it.

[modprobe]

It seems that fc's decryption is adding some binary crap to the end of your brain key. Please try recovering your account using only the actual words, not the junk at the end. And to echo what arhag said, These accounts are now compromised (you've published your brain keys) and should never be used for anything but testing.

arhag: Needing to restart the client after restoring is a known issue in previous versions, but I haven't seen it in the latest version. Is your build up-to-date? Same with missing transactions in the history; that should not be happening anymore. In particular, try dragging down the history view to refresh it, and let me know if that pulls in the missing transactions.

[arhag]

I created an account with the previous version and wrote down id,pw,recovery pw.
Installed the new version and attempted to import, shows me this error.
"Could not claim registered account AAAA. Is your recovery password correct?"



I think I entered correct one

Recovery key has broken characters
http://www.ddengle.com/files/attach/images/894001/082/948/32893a73f961450a63d171b1a8b054ae.png

Interesting bug. And just to be clear to both cryptfun and clayop (just in case you weren't aware already) those two accounts should be considered compromised now and you shouldn't ever store anything valuable with it.

[clayop]

Recovery key has broken characters
http://www.ddengle.com/files/attach/images/894001/082/948/32893a73f961450a63d171b1a8b054ae.png

[clout]

I can receive UIA but I cannot transfer them because the fee must be in DVS. When I attempt to transfer the UIA even with DVS in the wallet, a message pops up that says I do not have enough DVS to pay the fee.

[arhag]

Note: Because of the 30000 character limitation on this forum, I have removed the actual terminal output from this post. To see the full post, click on this link.

Hi, arhag. That was not implemented at the time of this beta release, but it is now implemented, albeit a bit buggy in the UX. If you rebuild from the devshares branch, you should get it.

I encountered a few problems with it. First I deleted "~/.config/DevShares" and "~/.local/share/DevShares".

I then ran the LightWallet and clicked on import account. I typed in my account name, recovery password, and new unlocking password. By the way, the recovery password field should be hidden by default just like the unlocking password field. After pressing "Import Account" nothing happened. However, I did see that the wallet created "~/.local/share/DevShares" and "~/.config/DevShares". Furthermore, looking at the contents of "~/.config/DevShares/BitShares DVS Light Wallet.conf" I can see that it recorded the arhag-light account with the encrypted private key.

I was running this in gdb by the way. Here is the output in the terminal during this process:

Code: [Select]

(see link provided for full output)

The Qt client wasn't doing anything when I pressed "Import Account" however the GUI was responsive. Pressing the button repeated messages like the following in the terminal:

Code: [Select]

(see link provided for full output)
and the command line wasn't responding so I pressed control-C which brought me back to the gdb prompt (and froze the Qt GUI). I then ran backtrace and got:

Code: [Select]

^C
Program received signal SIGINT, Interrupt.
0x00007ffff52aacbd in poll () at ../sysdeps/unix/syscall-template.S:81
81 ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) bt
#0  0x00007ffff52aacbd in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007ffff40bafe4 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ffff40bb0ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff64fa554 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /opt/Qt5.4.0/5.4/gcc_64/lib/libQt5Core.so.5
#4  0x00007ffff649deab in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /opt/Qt5.4.0/5.4/gcc_64/lib/libQt5Core.so.5
#5  0x00007ffff64a2dc5 in QCoreApplication::exec() () from /opt/Qt5.4.0/5.4/gcc_64/lib/libQt5Core.so.5
#6  0x000000000050e931 in main (argc=1, argv=<optimized out>)
    at /home/arhag/dev/bitshares/programs/light_wallet/main.cpp:53

Finally, I gave up and quit the program. I then ran it again, and this time it didn't show the new user screen but the screen that allowed me to unlock the existing user. After unlocking with my password I got a lot of terminal output similar to last time but it kept adding more. For that reason I was unable to copy all of it from the beginning (it scrolled up past my terminal history limit), but here is a portion of it:

Code: [Select]

(see link provided for full output)

Also, the GUI was simply a blank screen that said I haven't backed up my wallet yet, except the GUI was completely unresponsive (there are no "qml: Pressed events" logged in the terminal).

I closed the program and ran it again. This time things went better. Here is the terminal output:

Code: [Select]

(see link provided for full output)

This time it showed the screen with my balance (0 DVS) properly. Also, the transaction history page only showed the second to last transaction I made of 20 DVS from arhag to arhag-light (which is confirmed in the terminal output). None of my other transactions show up in the GUI. Here is a small portion of the terminal output while I am viewing the transaction history screen:

Code: [Select]

(see link provided for full output)
I haven't studied it carefully, but it appears to me that some of the other amounts I transferred are included in that output. So I am not sure why the GUI is only showing one of my transactions.

[cryptfun]

I created an account with the previous version and wrote down id,pw,recovery pw.
Installed the new version and attempted to import, shows me this error.
"Could not claim registered account AAAA. Is your recovery password correct?"



I think I entered correct one

[clayop]

Cool. I will let Korean community know and ask testing with DVS giveaway.

[modprobe]

I've just added a new OSX binary to the OP. Feel free to grab and test it. It will require you to reload your account from backup, so be prepared to test that for me too!

[modprobe]

As a matter of fact, I've redone the persistence framework, so you'll either have to regenerate from your brain key, or manually copy the data to the new storage, after upgrading to the version. I have yet to write the data portability code, sorry about that.

So note to all: make sure you've got a copy of your brain key before upgrading, if you want to build your own. I'll make an update utility if people need it, but for now it should be a simple matter of reloading the account from backup.

[modprobe]

Hi, arhag. That was not implemented at the time of this beta release, but it is now implemented, albeit a bit buggy in the UX. If you rebuild from the devshares branch, you should get it.

[arhag]

@modprobe, is there a way for me recover my account from the brain-key? I want to see if get my full transaction history to reappear if I get rid of "~/.local/share/DevShares/BitShares DVS Light Wallet/wallet_data.json" but when I do it forces me register a new account. I see no option of recovering an existing account. Is that not yet built into the light wallet?

[clayop]

This makes sense. Then GO! 

[modprobe]

And only 21 of those 35 registered accounts, and several of those never sent a transaction from the light wallet. So is anyone having trouble?

But I also note that the LW is currently very simple, so there's not much *to* test. The fact that 21 people registered accounts and many of them sent transactions to and from their wallets without reporting serious problems tells me that it's working pretty well so far, which was really the point of this release: get a minimal, useful product out there which is simple enough to be quick and easy to fully test.

[clayop]

That's the plan!

We're planning to release a beta of the LW on BitShares. Are there any critical issues in the light wallet that have been found which need to be fixed prior to releasing on the live BitShares network?

Unfortunately, there were only 35 downloads of DVS LW. I don't think we passed enough test. This can be reverting my argument, but we need windows binary to have enough test bed.

[modprobe]

That's the plan!

We're planning to release a beta of the LW on BitShares. Are there any critical issues in the light wallet that have been found which need to be fixed prior to releasing on the live BitShares network?

[clayop]

I'm afraid not, clayop. I spent about 5 hours on monday trying to get our windows dev box to build something, but neither I nor the resident windows user could get it working. Maybe cgafeng can give you a binary? At some point, we'll have to get the light wallet integrated into our normal windows build process, but we haven't done that yet.

Thanks. Keep working on LW and forget about windows binary!

[modprobe]

I'm afraid not, clayop. I spent about 5 hours on monday trying to get our windows dev box to build something, but neither I nor the resident windows user could get it working. Maybe cgafeng can give you a binary? At some point, we'll have to get the light wallet integrated into our normal windows build process, but we haven't done that yet.

[clayop]

No news about windows client?

[arhag]

To clarify, the light wallet always reports your balance correctly, but not always your history?

Correct.

I don't suppose you collected the command line output around said crash, or maybe even a backtrace, did you? :]

Unfortunately not. : (

[modprobe]

Since all of this information is recorded in the blockchain and associated to the active key of the light wallet accounts, why can't the light wallet client simply query the light wallet server to give it all the raw transactions from the blockchain that are associated with its public active key? Then the light wallet could reconstruct the transaction history even if didn't store it locally.

That's exactly what it does, although it caches things based on time, so I'm guessing your cache got damaged in the crash. Right now I'm just using FC to do persistence, but I think I need something a little more capable. I'll look into this. To clarify, the light wallet always reports your balance correctly, but not always your history? It's designed to be a bit more careful about reporting the balance correctly, so I'm glad that's working as intended.

I am curious about that crash, though. I haven't seen any crashes except crashes on exit. I don't suppose you collected the command line output around said crash, or maybe even a backtrace, did you? :]

[arhag]

Now, I see that there was a commit just one hour ago that may solve this bug. When I posted "Great, I'm building now." I had already started the build, and now I realize I was building an older commit than the one you referenced (c6b6e4624d19a65cba0464aa06490f88f1a34b78). I guess it's time to build again...

Okay all clients running on new build (c6b6e4624d19a65cba0464aa06490f88f1a34b78). The transaction history in the full client is back. It now correctly interprets the back and forth transfers I made today (arhag -> arhag-light -15 DVS, arhag-light -> arhag +13 DVS), but it still inaccurately reports the transfer I did last time from the light wallet to the full client as (arhag -> arhag-light -8 DVS) which also then screws up the balances reported with "wallet_account_transaction_history". This remains true after full blockchain rescan (which btw brought back my lost vote_all transaction). And even more strange is that the balance of the most recent transaction in the GUI transaction history starts off consistent with that from "wallet_account_transaction_history" after refresh but then is for some reason replaced after a little bit of time by the amount that was sent in that transaction (e.g. 13 DVS).

The light wallet did not show the +15 DVS and -13 DVS transactions I made today. I tried repeating again with 20 DVS from arhag to arhag-light and 18 DVS from arhag-light to arhag. From the perspective of the full client everything went smoothly and those transactions accurately appeared in the transaction history. The light wallet was able to recognize the 20 DVS transfer to it with the included memo and sender info. I then initiated the 18 DVS transfer back to arhag. Once I hit confirm the light wallet segfaulted, but apparently the transaction went through anyway (as confirmed by my full client and dvs.bitsharesblocks.com). When I reload the light wallet the balance is 0 DVS as it should be, but when I look at the transaction history, not only are the two transactions I said were missing last time (+15 DVS and -13 DVS) still missing but the transaction where I received +20 DVS (which was in the transaction history in the light wallet before the segfault) is gone too (and of course the -18 DVS transaction isn't there as well).

Since all of this information is recorded in the blockchain and associated to the active key of the light wallet accounts, why can't the light wallet client simply query the light wallet server to give it all the raw transactions from the blockchain that are associated with its public active key? Then the light wallet could reconstruct the transaction history even if didn't store it locally.

[arhag]

Accounts can publish their preference to be a "public_account" or "titan_account". TITAN deposits should only be sent to registered accounts with the latter preference (but the current BTS release right now also attempts TITAN in other cases I believe). If you look at the spec for "wallet_account_register", it currently defaults to titan. You can update your preference using "wallet_account_update_registration". I'm not sure if the GUI currently shows the preference anywhere, or even if it's currently pretty printed in the CLI. If you do "enable_raw" to get the raw json output then do "blockchain_get_account <name>", you should be able to see the current setting. Light wallet always registers as public_account.

Thanks for your help. Although, the help for "wallet_account_update_registration" doesn't appear to allow an "account_type" argument.

I sent some DVS from arhag to arhag-light using the GUI and then sent it back (minus fees), which worked fine (as far as the balances are concerned).

Of course, now there is a different issue where the transactions are not showing up in the light wallet or the full client. In fact, none of the old transaction history is showing up in this new build of the full client (as of this commit). The output of "wallet_account_transaction_history" is:

Code: [Select]

>> wallet_account_transaction_history

20017 invalid_name: invalid account name
Invalid account name!
    {"account_name":"GENESIS"}
    th_a  wallet.cpp:809 is_valid_account

    {}
    th_a  transaction_ledger.cpp:1618 get_pretty_transaction_history

    {}
    th_a  wallet_api.cpp:979 wallet_account_transaction_history

    {}
    th_a  common_api_client.cpp:3474 wallet_account_transaction_history

    {"command":"wallet_account_transaction_history"}
    th_a  cli.cpp:626 execute_command

Now, I see that there was a commit just one hour ago that may solve this bug. When I posted "Great, I'm building now." I had already started the build, and now I realize I was building an older commit than the one you referenced (c6b6e4624d19a65cba0464aa06490f88f1a34b78). I guess it's time to build again...

[vikram]

Great, I'm building now. And I assume that also works from the GUI?

It should.

Can you provide more detail on this? What do I need to do to check this and change it if necessary? And specifically, what about accounts created with the light wallet? Are they public_accounts by default? I assume they should be because the light wallet can't handle TITAN and certainly doesn't currently provide any way to run advanced console commands.

Accounts can publish their preference to be a "public_account" or "titan_account". TITAN deposits should only be sent to registered accounts with the latter preference (but the current BTS release right now also attempts TITAN in other cases I believe). If you look at the spec for "wallet_account_register", it currently defaults to titan. You can update your preference using "wallet_account_update_registration". I'm not sure if the GUI currently shows the preference anywhere, or even if it's currently pretty printed in the CLI. If you do "enable_raw" to get the raw json output then do "blockchain_get_account <name>", you should be able to see the current setting. Light wallet always registers as public_account.

[arhag]

If you pull latest devshares branch (c6b6e4624d19a65cba0464aa06490f88f1a34b78 right now which should be good), you should just be able to do a normal wallet_transfer to arhag-light,

Great, I'm building now. And I assume that also works from the GUI?

assuming that it's set to a "public_account" on the blockchain.

Can you provide more detail on this? What do I need to do to check this and change it if necessary? And specifically, what about accounts created with the light wallet? Are they public_accounts by default? I assume they should be because the light wallet can't handle TITAN and certainly doesn't currently provide any way to run advanced console commands.

[vikram]

So what command should I use to properly (non-TITAN) send funds to a light wallet account with memo and sender info working?

If you pull latest devshares branch (c6b6e4624d19a65cba0464aa06490f88f1a34b78 right now which should be good), you should just be able to do a normal wallet_transfer to arhag-light, assuming that it's set to a "public_account" on the blockchain.

[arhag]

I helped Nathan fix that bug earlier today.

  This? I think that fix also explains why the withdraw was unnecessarily split into 2 DVS and 8 DVS rather than a single 10 DVS.

So what command should I use to properly (non-TITAN) send funds to a light wallet account with memo and sender info working?

[bytemaster]

I note that if you used transfer_to_address, memos will *not* be sent, as it's impossible to send a memo without a public key (and transfer_to_address doesn't use a key; only an address) so it's expected behavior that the recipient won't have the memo.

Oh, okay. Is there a way to send a non-TITAN (since I presume the light wallet has no way right now of knowing about received funds via TITAN) to an account rather than an address from the full client? I basically want to send some DVS to arhag-light, have the sending client grab the public key of arhag-light from the blockchain, use it as the address to send funds to (so the light wallet is aware of the funds received), and use the one-time key included with the transaction and the public key of arhag-light to derive the shared secret that encrypts the memo and sender information.

Are you reporting that the light wallet listed an incorrect balance, or an incorrect transaction display?

The main issue I was reporting is that a transfer initiated in the light wallet from arhag-light to another account (arhag) causes the full client holding the keys to that arhag account to believe (at least according to the transaction history) that it was the one that sent the funds rather than the one that received the funds.

I helped Nathan fix that bug earlier today.

[arhag]

I note that if you used transfer_to_address, memos will *not* be sent, as it's impossible to send a memo without a public key (and transfer_to_address doesn't use a key; only an address) so it's expected behavior that the recipient won't have the memo.

Oh, okay. Is there a way to send a non-TITAN (since I presume the light wallet has no way right now of knowing about received funds via TITAN) to an account rather than an address from the full client? I basically want to send some DVS to arhag-light, have the sending client grab the public key of arhag-light from the blockchain, use it as the address to send funds to (so the light wallet is aware of the funds received), and use the one-time key included with the transaction and the public key of arhag-light to derive the shared secret that encrypts the memo and sender information.

Are you reporting that the light wallet listed an incorrect balance, or an incorrect transaction display?

The main issue I was reporting is that a transfer initiated in the light wallet from arhag-light to another account (arhag) causes the full client holding the keys to that arhag account to believe (at least according to the transaction history) that it was the one that sent the funds rather than the one that received the funds.

[modprobe]

Builds for android are technically possible, but no one has any idea how to build fc for android, so that's a non-starter for now. Someday I'll look into it further.

Unfortunately, robohash.org has taken to giving unreliable results for their hashes. The Qt wallet even shows different images for the same thing on different pages. This is not our bug.

@arhag: I'm not entirely sure what all issues you're describing... I note that if you used transfer_to_address, memos will *not* be sent, as it's impossible to send a memo without a public key (and transfer_to_address doesn't use a key; only an address) so it's expected behavior that the recipient won't have the memo. Are you reporting that the light wallet listed an incorrect balance, or an incorrect transaction display?

[cn-members]

I found the robohash is different on qt-wallet and light-wallet:




any suggestions?

[cn-members]

Build the window version by vs2013 is success.
But i try to build the android version by windows and looks like it can't be done.
I use the qt for android(windows) and need to build the boost by mingw, and the lib boost_context can't build on windows by mingw, any idea?


I think i figure out how to build the boost_context, will try it later.

guide please? I never get to know how to use VS, but certainly I want to build the Windows version. Thanks

不知道你是到哪一步卡住了，假设你已经能能用vs编译命令行的钱包，如果不行的话看BUILD_WIN32.md文件。

编译轻钱包另外用到了库qml-extras和qml-material，qt开发包Qt 5.4.0 for Windows 32-bit (VS 2013, OpenGL) ，Qt 5.4.0 for Android (Windows 32-bit)，可以在http://www.qt.io/download-open-source/#section-3下载。

Qt5.4或5.3版本应该都可以，用qt5.4 for android其实只是用来编译qml-extras和qml-material，用Qt 5.4.0 for Windows 32-bit (MinGW 4.9.1）也可以。
编译qml-extras和qml-material一样，都用命令行设置环境变量后用mingw编译。假设qt for android安装在d:/qt/qtAndroid

Code: [Select]

set PATH=D:\Qt\qtAndroid\5.4\mingw491_32\bin;D:\Qt\qtAndroid\Tools\mingw491_32\bin;%PATH%;
qmake
mingw32-make.exe
mingw32-make.exe check
mingw32-make.exe install
编译成功后D:\Qt\qtAndroid\5.4\mingw491_32\qml目录下就会有material，拷贝material到Qt for Window目录下D:\Qt\Qt5.4.0\5.4\msvc2013_opengl\qml。我觉着ubuntu下编译出来的material应该也可以直接拷贝过来用。


在能编译命令行钱包的基础上添加环境变量，设置vs使用的qt库目录
CMAKE_PREFIX_PATH D:\Qt\Qt5.3.0\5.3\msvc2013
添加编译轻钱包
INCLUDE_LIGHT_WALLET TRUE

这样就行了。

多謝 我再試試看

[cgafeng]

Build the window version by vs2013 is success.
But i try to build the android version by windows and looks like it can't be done.
I use the qt for android(windows) and need to build the boost by mingw, and the lib boost_context can't build on windows by mingw, any idea?


I think i figure out how to build the boost_context, will try it later.

guide please? I never get to know how to use VS, but certainly I want to build the Windows version. Thanks

不知道你是到哪一步卡住了，假设你已经能能用vs编译命令行的钱包，如果不行的话看BUILD_WIN32.md文件。

编译轻钱包另外用到了库qml-extras和qml-material，qt开发包Qt 5.4.0 for Windows 32-bit (VS 2013, OpenGL) ，Qt 5.4.0 for Android (Windows 32-bit)，可以在http://www.qt.io/download-open-source/#section-3下载。

Qt5.4或5.3版本应该都可以，用qt5.4 for android其实只是用来编译qml-extras和qml-material，用Qt 5.4.0 for Windows 32-bit (MinGW 4.9.1）也可以。
编译qml-extras和qml-material一样，都用命令行设置环境变量后用mingw编译。假设qt for android安装在d:/qt/qtAndroid

Code: [Select]

set PATH=D:\Qt\qtAndroid\5.4\mingw491_32\bin;D:\Qt\qtAndroid\Tools\mingw491_32\bin;%PATH%;
qmake
mingw32-make.exe
mingw32-make.exe check
mingw32-make.exe install
编译成功后D:\Qt\qtAndroid\5.4\mingw491_32\qml目录下就会有material，拷贝material到Qt for Window目录下D:\Qt\Qt5.4.0\5.4\msvc2013_opengl\qml。我觉着ubuntu下编译出来的material应该也可以直接拷贝过来用。


在能编译命令行钱包的基础上添加环境变量，设置vs使用的qt库目录
CMAKE_PREFIX_PATH D:\Qt\Qt5.3.0\5.3\msvc2013
添加编译轻钱包
INCLUDE_LIGHT_WALLET TRUE

这样就行了。

[cn-members]

Build the window version by vs2013 is success.
But i try to build the android version by windows and looks like it can't be done.
I use the qt for android(windows) and need to build the boost by mingw, and the lib boost_context can't build on windows by mingw, any idea?


I think i figure out how to build the boost_context, will try it later.

guide please? I never get to know how to use VS, but certainly I want to build the Windows version. Thanks

[cgafeng]

Build the window version by vs2013 is success.
But i try to build the android version by windows and looks like it can't be done.
I use the qt for android(windows) and need to build the boost by mingw, and the lib boost_context can't build on windows by mingw, any idea?


I think i figure out how to build the boost_context, will try it later.

[arhag]

By the way, I am pretty sure I have heard this bug discussed before, but I'll mention it here since it happened while interacting with the light wallet.

I used the full client's wallet_transfer_to_address  command to transfer 10 DVS from my arhag account to the active key of my arhag-light account (DVS6AryKFGdYZRJmmT2HaSZcRcuv1Q6VvQjbWgfnGodWrUqriM8Uz). I received the 10 DVS in my arhag-light account within the light wallet.  I then used the light wallet to send 8 DVS back to arhag (which reduced my arhag-light balance to 0 since 1 DVS was the transaction fee and 1 DVS was sent as a fee to Nathan's light wallet server).

Both transactions were noted by the light wallet and the full client. However:

• The light wallet was not able to identify the sender (arhag) or the memo I provided in the transaction that paid arhag-light 10 DVS.
• As currently expected, the transaction sending 10 DVS to arhag-light was sent to UNKNOWN from the perspective of the full client (since I used wallet_transfer_to_address).
• The full client thinks the transaction sending 8 DVS from arhag-light to arhag is a transaction in which arhag sent 8 DVS to arhag-light! As a result it mistakenly deducts 9 DVS from the balance column (as reported by "wallet_account_transaction history arhag") when it should instead add 8 DVS. What is even more bizarre is that in the GUI wallet, not only does it do the same reversal mistake, but it then reports that the balance after that transaction is -1.00 DVS! However, if I do the math manually based on what I remember of my transactions, the actual balance reported both in the summary balance for my account within the GUI and through the wallet_account_balance command are correct.

A portion of the output of "wallet_account_transaction_history arhag" from the full client:

Code: [Select]

TIMESTAMP           BLOCK     FROM                TO                  AMOUNT                  MEMO                                        BALANCE                 FEE                 ID     
==============================================================================================================================================================================================
...
2015-01-24T23:57:20 155748    arhag               UNKNOWN             100.00000 DVS           To: DVS2AgMj...                             (X)          DVS        1.00000 DVS         0162871b
2015-02-01T06:36:02 213806    arhag               UNKNOWN             10.00000 DVS            test                                        (X - 11)     DVS        1.00000 DVS         a95dc4a1
2015-02-01T06:39:00 213823    arhag               arhag-light         8.00000 DVS             testing                                     (X - 11 - 9) DVS        1.00000 DVS         cf9aa5c6
Obviously, I have modified the balance fields for the tiniest bit of privacy from lazy people (if you really want to know the value of X, you can get it from the blockchain with a little bit of work), but you should get the idea of what is going on from the mathematical expressions.

The transaction history has another problem as well. The value of X as reported by the transaction history is 1 DVS larger than it should be. This discrepancy can be noticed by comparing the account balance, which reports the correct (X - 11 + 7) DVS, to the account balance I would calculate if I were to simply correct transaction cf9aa5c6 in the transaction history, which would give me an account balance of (X - 11 + 8 ). The reason for this discrepancy is because the transaction history is missing my one (and only) vote_all transaction which cost me a 1 DVS fee. It used to be there, but somehow during this process (I upgraded clients a lot) it lost it.

[clayop]

For the windows users, I'm hoping to get my hands on a windows dev box tomorrow, so hopefully I'll get something together for you. Thanks for being patient!

Looking forward to it. Thanks!

[modprobe]

@fluxer: I agree with you, and I'd like to see such solutions deployed. The issues aren't insurmountable, but they need consideration, and I welcome new ideas on how to solve them (why waste time implementing one bad solution if someone else can think of a better one?). Right now I'm the only one running a light server because it's under heavy development (you think delegates have to upgrade a lot? Ha!) and I need to be able to debug and redeploy rapidly. Once I've got a relatively stable solution (which is, of course, the point of this beta -- to figure out what needs to be changed to sustain a reliable solution) then I'll be looking into multi-server models. Eventually, I'll make it configurable.

Still, the model of paying a centralized party to provide immediate, accurate information is a reasonable one, particularly when I deploy mobile apps where all matters of internet traffic are much more expensive (in time and money).

@cn-members: Thank you very much for taking the time to detail out those instructions. I'll add those to a README on GitHub soon.

@arhag: I'm glad you got it working! Yes, I do develop against 5.4. I think 5.3 would work, but you'll have to turn back the version numbers in the import statements until it works, and doing that might break something which depends on the later version. I haven't researched exactly when all the features I need were added, so I just use the latest version available at the time of writing.


Is anyone else still having trouble building? For the rest of you, do you have any comments or problems you've experienced?

For the windows users, I'm hoping to get my hands on a windows dev box tomorrow, so hopefully I'll get something together for you. Thanks for being patient!

[arhag]

Nice job on those build instructions cn-members. I'll post my (slightly different) guide on how to build the light wallet (as well as the CLI client, web wallet, and Qt client) on Ubuntu 14.04 x64. This guide can be used if you want to install Qt directly from its creators rather than relying on a PPA. Please note that I haven't actually tried these exact instructions on a fresh install, but they were reconstructed from memory based on various things I tried. So, let me know if it actually works for you.

Initial setup stage:
0) Set up a working directory in which everything will be done and install all pre-requisites from repositories:

Code: [Select]

~$ mkdir BitShares && cd BitShares
~/BitShares$ sudo apt-get install cmake git libreadline-dev uuid-dev g++ libdb++-dev libdb-dev zip libssl-dev openssl build-essential python-dev autotools-dev libicu-dev libbz2-dev libboost-dev libboost-all-dev npm nodejs-legacy
~/BitShares$ sudo npm install -g lineman

1) Install Qt 5.4:

Code: [Select]

~/BitShares$ wget http://download.qt-project.org/official_releases/qt/5.4/5.4.0/qt-opensource-linux-x64-5.4.0.run
~/BitShares$ sha256sum qt-opensource-linux-x64-5.4.0.run
Verify that the SHA-256 hash of the executable is correct by comparing to the hash listed here. Although, the website's current SSL security practices are pretty disappointing.   
Then run the installer to install Qt 5.4 in a system-wide location:

Code: [Select]

~/BitShares$ chmod +x qt-opensource-linux-x64-5.4.0.run
~/BitShares$ sudo ./qt-opensource-linux-x64-5.4.0.run
Then follow the GUI and install in "/opt/Qt5.4.0".

2) Install qml-extras and qml-material into the Qt5.4.0 folder:

Code: [Select]

~/BitShares$ git clone https://github.com/papyros/qml-extras.git
~/BitShares$ mkdir qml-extras-build && cd qml-extras-build
~/BitShares/qml-extras-build$ /opt/Qt5.4.0/5.4/gcc_64/bin/qmake ../qml-extras
~/BitShares/qml-extras-build$ make && make check
Make sure all the tests pass.

Code: [Select]

~/BitShares/qml-extras-build$ sudo make install
~/BitShares/qml-extras-build$ cd ..
~/BitShares$ git clone https://github.com/nathanhourt/qml-material.git
~/BitShares$ mkdir qml-material-build %% cd qml-material-build
~/BitShares/qml-material-build$ /opt/Qt5.4.0/5.4/gcc_64/bin/qmake ../qml-material
~/BitShares/qml-material-build$ make && make check
Make sure all the tests pass.

Code: [Select]

~/BitShares/qml-material-build$ sudo make install
~/BitShares/qml-material-build$ cd ..

3) Initial setup of DevShares:

Code: [Select]

~/BitShares$ rm -rf bitshares # Remove any prior bitshares folder
~/BitShares$ git clone https://github.com/BitShares/bitshares.git
~/BitShares$ cd bitshares
~/BitShares/bitshares$ git submodule init && git submodule update
~/BitShares/bitshares$ cd programs/web_wallet
~/BitSharesbitshares/programs/web_wallet$ npm install
~/BitSharesbitshares/programs/web_wallet$ cd ../../../


Building DevShares from scratch:
If this is the first time building DevShares, or you want to build an update of it from scratch, you must first do the following additional setup before compiling. If you think you can get away with a quick recompilation after some minor changes, skip to "Recompiling Devhares after minor changes".

4) Build from scratch:

Code: [Select]

~/BitShares$ cd bitshares
~/BitShares/bitshares$ git pull
~/BitShares/bitshares$ git checkout devshares
~/BitShares/bitshares$ git submodule update
~/BitShares/bitshares$ cd ..
~/BitShares$ rm -rf devshares-build  # Remove any prior devshares-build folder
~/BitShares$ mkdir devshares-build && cd devshares-build
~/BitShares/devshares-build$ cmake -DINCLUDE_QT_WALLET=ON -DINCLUDE_LIGHT_WALLET=ON -DCMAKE_PREFIX_PATH=/opt/Qt5.4.0/5.4/gcc_64/ ../bitshares/
~/BitShares/devshares-build$ make forcebuildweb
~/BitShares/devshares-build$ make
~/BitShares/devshares-build$ cd ..

The Qt client will be located in "~/BitShares/devshares-build/programs/qt_wallet/bin/DevShares". The light wallet will be located in "~/BitShares/devshares-build/programs/light_wallet/LightWallet". The CLI client will be located in "~/BitShares/devshares-build/programs/client/devshares_client". The CLI client can be run with the "--server" flag to run the backend of the web wallet (make sure to first set up the RPC parameters in the config.json file appropriately). The web wallet can be run from the "~/BitShares/bitshares/programs/web_wallet" folder using "npm start" and then accessed from the browser using http://localhost:8000/.


Recompiling DevShares after minor changes (assuming updating HEAD of same branch):
5) Get latest sources and recompile:

Code: [Select]

~/BitShares$ cd bitshares
~/BitShares/bitshares$ git pull && git checkout devshares && git submodule update && cd ../devshares-build
~/BitShares/devshares-build$ make forcebuildweb # Only needed if web_wallet code changed
~/BitShares/devshares-build$ make

If there are any problems from this quick recompilation procedure, then go back and do it properly with step 4, and if that has problems then go back to step 3.

[cn-members]

Finally I get it worked on ubuntu 14.04:


this is how I did it:
1. Install qt5.4 from PPA

Code: [Select]

add-apt-repository ppa:beineri/opt-qt54-trusty
apt-get update
apt-get install qt54-meta-full

2. set variables

Code: [Select]

export QTDIR=/opt/qt54/
export PATH=$QTDIR/bin:$PATH   
export MANPATH=$QTDIR/man:$MANPATH   
export LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH 
you can use:

Code: [Select]

qmake -vto check if the version is correct

3. build qml-extra & qml-material

Code: [Select]

git clone https://github.com/papyros/qml-extras
cd qml-extras
qmake
make
make check
sudo make install
cd ..

Code: [Select]

git clone https://github.com/nathanhourt/qml-material
cd qml-material
qmake
make
make check
sudo make install
cd ..
4. final thing: compile dvs-light wallet

Code: [Select]

git clone https://github.com/BitShares/bitshares
cd bitshares
git checkout devshares
git submodule init
git submodule update
cmake -DINCLUDE_LIGHT_WALLET=ON CMakeLists.txt
make
and the process is in
bitshares/programs/light_wallet/LightWallet

[fluxer555]

Hi, fluxer. Thanks for the thoughts. I would like to move to a multiple server model, but this does have some difficulties. One is performance (I've got to wait for N servers to respond instead of 1), and another is fragility (if I use 2 servers and they give different results... now what?) as well as ambiguity (If I query three servers and two never respond... now what?), as well as economics (each light server charges a fee for propagating transactions; if I have N lightservers, I have to pay N fees?). I haven't taken the time to come up with good answers to these questions, so the current version only supports one server. If we can come up with a good design, though, I'll be happy to implement a multiple server architecture.

As to the issue of delegates hosting servers, it's a great idea, but the light wallet has no way of knowing who the delegates are nor what they've published in their accounts. The light wallet would then need to trust a lightserver to give it accurate information about the delegates, which defeats the purpose.

My idea is to have a few initial 'seed' servers when you first download the client. There ideally should be more than 2, to avoid that problem you stated, as well as to be sufficiently distributed so to mitigate risk of server hacks / attacks. Once there is consensus of the initial seed servers as to who the delegates are and what their servers are, the delegates' servers are then added to the trusted servers list. From there, the data of the delegates' servers are compared against each other for authenticity, and any discrepancies can either be ignored if a very low percent (probably usually due to software malfunction rather than malicious intent), or if under a certain threshold can issue a warning to the user, much like the current system in the full client with the delegate participation rate. Since each delegate is paid (at the bare minimum) to run a server anyway, it should remain economical to have them set this up at no additional charge.

To address your points specifically,

One is performance (I've got to wait for N servers to respond instead of 1),

You might not need to wait for all servers to respond, as long as the number that do are above a threshold, and as long as you rotate through the servers you have (to not trust one source more than others). This is much much better than trusting a central entity that can be hacked or DDoS'd easily.

and another is fragility (if I use 2 servers and they give different results... now what?)

If you only have two results and they are different, you need more results, or you stop transactions. This would indicate that something is wrong, and the user should be glad their client checked more than once source before trusting the faulty one (whichever one that may be).

as well as ambiguity (If I query three servers and two never respond... now what?),

Related to answer above. You set a threshold, and if this threshold is not met, you either warn the user or stop transactions.

as well as economics (each light server charges a fee for propagating transactions; if I have N lightservers, I have to pay N fees?).

If delegates are hosting lightservers, then this problem is solved. You would just need a handful of 'seed' lightservers, which I suspect certain trusted patrons would run for free.

As to the issue of delegates hosting servers, it's a great idea, but the light wallet has no way of knowing who the delegates are nor what they've published in their accounts. The light wallet would then need to trust a lightserver to give it accurate information about the delegates, which defeats the purpose.

Answered in various ways throughout this post.


EDIT: Added "at no additional charge" to the end of my first paragraph to clarify.

[arhag]

I will try installing Qt 5.4 and building LightWallet against that next.

Woohoo! That worked. I will post detailed build instructions for Ubuntu 14.04 later.

[arhag]

For those on Qt 5.3, which I believe ships QtQuick 2.3, I've updated the imports in the QML files to reference QtQuick 2.3 instead of 2.4. I've also updated the light wallet to connect to my server on the devshares branch. Hopefully that will simplify building for you all.

Tried compiling the latest updates to the devshares branch that includes your 4eeaada384f018eb8a5dff5383002f36d2cfb283 commit, I made sure cmake is recognizing my Qt 5.3 installation, and verified with ldd that LightWallet is linked against the shared object files in my custom Qt 5.3 installation, and yet:

Code: [Select]

$ ./LightWallet
1502092ms th_a       thread.cpp:95                 thread               ] name:ntp tid:139931628037888
1502118ms ntp        ntp.cpp:77                    request_now          ] resolving... ["pool.ntp.org",123]
QML debugging is enabled. Only use this in a safe environment.
1502613ms ntp        ntp.cpp:81                    request_now          ] sending request to 132.163.4.102:123
QQmlApplicationEngine failed to load component
qrc:/qml/main.qml:116 Type WelcomeLayout unavailable
qrc:/qml/WelcomeLayout.qml:2 module "QtQuick.Controls" version 1.3 is not installed

"QML_IMPORT_TRACE=1 ./LightWallet" shows that it is looking in the right place "/opt/Qt5.3.0/5.3/gcc_64/qml" for the the various modules.

I will try installing Qt 5.4 and building LightWallet against that next. Is that the version of Qt you have installed on your machine Nathan?

[modprobe]

For those on Qt 5.3, which I believe ships QtQuick 2.3, I've updated the imports in the QML files to reference QtQuick 2.3 instead of 2.4. I've also updated the light wallet to connect to my server on the devshares branch. Hopefully that will simplify building for you all.

[modprobe]

Yeah, for some reason it's still pointing at localhost. I thought I fixed that. Anyways, just change "localhost" to "nathanhourt.com" and you'll be set.

[xeroc]

Xeroc: You're using papyros's copy of qml-material, not my fork. Make sure to get qml-material from github.com/nathanhourt/qml-material and to use the develop branch. Edit: scratch that, you've got an old version of the light wallet. Are you sure you're building on the devshares branch?

Oh .. I was compiling the tag dvs/0.6.2 .. the devshares branch compile fine and the client start up all fine .. however, no connection can be made. What  steps are required to make the client connect to your host? I found this in the code (main.qml):

Code: [Select]

54    function connectToServer() {
 55       if( !wallet.connected )
 56          wallet.connectToServer("localhost", 5657, "DVS8GV6nP15gBZQbuEGamH95gYR5EioxkUbEYjpDHMjPEeRWsvR63")                                                                                                     
 57    }


[modprobe]

Hi, fluxer. Thanks for the thoughts. I would like to move to a multiple server model, but this does have some difficulties. One is performance (I've got to wait for N servers to respond instead of 1), and another is fragility (if I use 2 servers and they give different results... now what?) as well as ambiguity (If I query three servers and two never respond... now what?), as well as economics (each light server charges a fee for propagating transactions; if I have N lightservers, I have to pay N fees?). I haven't taken the time to come up with good answers to these questions, so the current version only supports one server. If we can come up with a good design, though, I'll be happy to implement a multiple server architecture.

As to the issue of delegates hosting servers, it's a great idea, but the light wallet has no way of knowing who the delegates are nor what they've published in their accounts. The light wallet would then need to trust a lightserver to give it accurate information about the delegates, which defeats the purpose.

[fluxer555]

Some ideas, maybe you've thought of them:

- The ability to add 'trusted sources' to a list
- Delegates should be able to host public data servers / list their addresses under their accounts, and light wallets should be able to automatically add these servers to its list of 'trusted sources'

[modprobe]

Xeroc: You're using papyros's copy of qml-material, not my fork. Make sure to get qml-material from github.com/nathanhourt/qml-material and to use the develop branch. Edit: scratch that, you've got an old version of the light wallet. Are you sure you're building on the devshares branch?

Arhag: Your version of Qt is older than the lightwallet expects. You can update Qt, or you can try modifying the wallet to use an older version of Qt by turning down the version number in the qml files (change `import QtQuick 2.4` to 2.3 or lower)

[xeroc]

Code: [Select]

./LightWallet --help                                                                                                                                                                                   ─┘
1553542ms th_a       thread.cpp:95                 thread               ] name:ntp tid:2956073792
1553542ms ntp        ntp.cpp:77                    request_now          ] resolving... ["pool.ntp.org",123]
QML debugging is enabled. Only use this in a safe environment.
1553554ms ntp        ntp.cpp:81                    request_now          ] sending request to 141.82.25.201:123
1553594ms ntp        ntp.cpp:147                   read_loop            ] received ntp reply from 141.82.25.201:123
1553594ms ntp        ntp.cpp:161                   read_loop            ] ntp offset: 5618, round_trip_delay 39713
1553594ms ntp        ntp.cpp:177                   read_loop            ] ntp_delta_time updated to 5618
QQmlApplicationEngine failed to load component
file:///files/git/bitshares/programs/light_wallet/qml/main.qml:284 Type TransferLayout unavailable
file:///files/git/bitshares/programs/light_wallet/qml/TransferLayout.qml:67 Cannot assign to non-existent property "showHelperText"

on ArchLinux .. any idea how to fix this?

[xeroc]

ah .. thanks ..

[cn-members]

where are the sources for the light-client? I'd like to compile locally

it's in the original repository:
https://github.com/BitShares/bitshares

just cmake with
-DINCLUDE_LIGHT_WALLET=ON

also you need to build& install:
https://github.com/papyros/qml-extras
https://github.com/nathanhourt/qml-material

however, I still encountered the problem that arhag mentioned:
3453531ms th_a       thread.cpp:95                 thread               ] name:ntp tid:140008780953344
QML debugging is enabled. Only use this in a safe environment.
3453531ms ntp        ntp.cpp:77                    request_now          ] resolving... ["pool.ntp.org",123]
3453538ms ntp        ntp.cpp:81                    request_now          ] sending request to 120.119.28.1:123
3453549ms ntp        ntp.cpp:147                   read_loop            ] received ntp reply from 120.119.28.1:123
3453549ms ntp        ntp.cpp:161                   read_loop            ] ntp offset: -210141, round_trip_delay 11227
3453549ms ntp        ntp.cpp:177                   read_loop            ] ntp_delta_time updated to -210141
QQmlApplicationEngine failed to load component
qrc:/qml/main.qml:1 module "QtQuick" version 2.4 is not installed

[xeroc]

where are the sources for the light-client? I'd like to compile locally

[arhag]

Update for the Ubuntu users: I can't get qml-extras and qml-material to build their tests. My best guess is that the old version of Qt that ships with Ubuntu just can't handle it. As a workaround, disable the tests by editing qml-extras.pro and qml-material.pro and removing the references to the tests subdir. Then you can just `sudo make install` and it should work.

I was actually able to get the tests to run except for

Code: [Select]

FAIL!  : extras::HttpTests::test_getgoogle() Uncaught exception: HttpLib is not defined
when running "make check" for qml_extras.

It required me to adjust environment variables so that qmake knew to use the Qt 5.3 installation I custom installed in /opt/Qt5.3.0 rather than the one that came with my Ubuntu system which is an older version.

I was also able to install qml_extras and qml_material, which were installed within the /opt/Qt5.3.0/5.3/gcc_64/ directory. 

But I think I may be doing something wrong with the compilation of the LightWallet. I worry that cmake is pointing to the system-wide old version of Qt and not the custom version I installed. It does build LightWallet, but when I run it I get:

Code: [Select]

2703390ms th_a       thread.cpp:95                 thread               ] name:ntp tid:140644392490752
2703391ms ntp        ntp.cpp:77                    request_now          ] resolving... ["pool.ntp.org",123]
2703397ms ntp        ntp.cpp:81                    request_now          ] sending request to 50.116.38.157:123
QML debugging is enabled. Only use this in a safe environment.
2703485ms ntp        ntp.cpp:147                   read_loop            ] received ntp reply from 50.116.38.157:123
2703485ms ntp        ntp.cpp:161                   read_loop            ] ntp offset: 87993113, round_trip_delay 88388
2703485ms ntp        ntp.cpp:177                   read_loop            ] ntp_delta_time updated to 87993113
QQmlApplicationEngine failed to load component
file:///home/arhag/devshares/programs/light_wallet/qml/main.qml:1 module "QtQuick" version 2.4 is not installed
and then it just hangs there and does nothing (no windows show up).

Oh, and remember to use my fork of qml-material at github.com/nathanhourt/qml-material -- I've made some changes that haven't been merged upstream.

Hmm... this might have something to do with it. I will try that out and report back.

Edit: Nope. I now get errors in make check for qml-material.

Code: [Select]

********* Start testing of materials *********
Config: Using QtTest library 5.3.0, Qt 5.3.0
PASS   : materials::Card Test::initTestCase()
PASS   : materials::Card Test::test_showCard()
PASS   : materials::Card Test::cleanupTestCase()
QWARN  : materials::UnknownTestFunc() file:///home/arhag/qml-material/tests/tst_pagestack.qml:27:5: Type ApplicationWindow unavailable
         ApplicationWindow {
         ^
QWARN  : materials::UnknownTestFunc() file:///home/arhag/qml-material/modules/Material/ApplicationWindow.qml:82:5: Type Toolbar unavailable
         Toolbar {
         ^
QWARN  : materials::UnknownTestFunc() file:///home/arhag/qml-material/modules/Material/Toolbar.qml:150:5: Type Tabs unavailable
         Tabs {
         ^
QWARN  : materials::UnknownTestFunc() file:///home/arhag/qml-material/modules/Material/Tabs.qml:44:13: Type Ink unavailable
                 Ink {
                 ^
QWARN  : materials::UnknownTestFunc() file:///home/arhag/qml-material/modules/Material/Ink.qml:166:13: CircleMask is not a type
                 CircleMask {
                 ^
QWARN  : materials::tst_pagestack::compile()
  /home/arhag/qml-material/tests/tst_pagestack.qml produced 5 error(s):
    /home/arhag/qml-material/tests/tst_pagestack.qml:27,5: Type ApplicationWindow unavailable
    /home/arhag/qml-material/modules/Material/ApplicationWindow.qml:82,5: Type Toolbar unavailable
    /home/arhag/qml-material/modules/Material/Toolbar.qml:150,5: Type Tabs unavailable
    /home/arhag/qml-material/modules/Material/Tabs.qml:44,13: Type Ink unavailable
    /home/arhag/qml-material/modules/Material/Ink.qml:166,13: CircleMask is not a type
  Working directory: /home/arhag/qml-material/tests
  View: QQuickView, import paths:
    '/home/arhag/qml-material/modules'
    '/home/arhag/qml-material/tests'
    '/opt/Qt5.3.0/5.3/gcc_64/qml'
  Plugin paths:
    '.'

FAIL!  : materials::tst_pagestack::compile() Type ApplicationWindow unavailable
   Loc: [/home/arhag/qml-material/tests/tst_pagestack.qml(27)]
Totals: 3 passed, 1 failed, 0 skipped
********* Finished testing of materials *********


[modprobe]

Oops, I spoke too soon. Looks like the qml tests build after installing qtdeclarative5-dev

[modprobe]

Update for the Ubuntu users: I can't get qml-extras and qml-material to build their tests. My best guess is that the old version of Qt that ships with Ubuntu just can't handle it. As a workaround, disable the tests by editing qml-extras.pro and qml-material.pro and removing the references to the tests subdir. Then you can just `sudo make install` and it should work.

Oh, and remember to use my fork of qml-material at github.com/nathanhourt/qml-material -- I've made some changes that haven't been merged upstream.

[clayop]

For the windows folks, I think I can get a binary for you

Sounds promising

[modprobe]

I'll try and set up an Ubuntu VM to test building in. I'm building on ArchLinux right now, and it's going buttery smooth. Installing qml-extras and qml-material didn't give me any difficulty, but those are packaged for Arch so it's laughably easy. :}

For the windows folks, I think I can get a binary for you, but I'm not certain how hard it'll be to pull all the dependencies together.

[Overthetop]

a milestone, thanks devs.

 

[cgafeng]

Great. I'll wait for the build instructions for Linux.

Out of curiosity I attempted to build the light wallet a couple days ago and ran into some major problems trying to get it to work with Qt 5.3 (which is not installed by default on my Ubuntu 14.04 system)  and qml-material. So, I hope you will have clear instructions on how to build from source on Ubuntu 14.04.

qml-material need to install.

[CurrencyMaster]

 

[arhag]

Great. I'll wait for the build instructions for Linux.

Out of curiosity I attempted to build the light wallet a couple days ago and ran into some major problems trying to get it to work with Qt 5.3 (which is not installed by default on my Ubuntu 14.04 system)  and qml-material. So, I hope you will have clear instructions on how to build from source on Ubuntu 14.04.

[alt]

great! 

[lzr1900]

Amazing！

[bytemaster]

Great work!

[clayop]

 
Waiting for windows version. 

[modprobe]

Hello, all!

It's finally time to publish an open beta for my light wallet, currently available for DevShares. For those who want to skip the intro and get straight to the download, a Mac binary is available here:
http://ge.tt/1eflUa92/v/0
http://ge.tt/9uSSL0A2/v/0 Update! Just ignore the error about assets at startup.
http://ge.tt/1eDoNAA2/v/0 Should fix the junk characters in the brain key
Windows binaries will hopefully be available at some point. I would post build instructions, but we need to merge everything necessary into the official DevShares release first.

The usual disclaimers. This is beta software. It has bugs. It sometimes crashes on exit. It might lose your money, it might start thermonuclear war, and it might eat your lunch. Use it at your own risk. I'm happy to support it, but I'm not liable for anything it does. Also, the source code is available in the programs/light_wallet folder on the BitShares code repository, though this particular binary is built using a custom merge of the develop and devshares branches which is not published anywhere, as some of the features it requires have not yet been tagged into a devshares release. It does not have any code which is not available on one of those two branches, though.

This wallet is a light wallet; it uses my server at nathanhourt.com to query the blockchain and also to register accounts. The light wallet manages your private keys, and never sends them to anyone else, as you would expect. It also creates its transactions locally, then scans them and confirms them with the user before signing and submitting to my server for broadcast. This way, I give the user reasonable certainty that a bug in the code will not cause them to sign an unintended transaction.

At present, the wallet only allows one account to be created, and it requires that the account be registered by my server. It does not support BitShares Logins or other BTS URLs. Future versions will allow more options, but I want to keep it as simple as possible for the beta test, so that I can fix bugs in the code now, as this will be the platform upon which all future features are built. I also want to get it out there in hopes that it can be useful to people sooner rather than later, and I can prioritize further development based on feedback.

Finally, I note that the full-node web/qt wallet currently has a bug which prevents it from displaying transactions from my light wallet in the history. This is purely a history display bug; the full wallet does include the received funds in your balance and can spend them. I also note that at present, our extended memos are buggy and memos longer than 19 bytes are not displayed correctly.

Thanks for reading, and let me know what you think, and vote for dev.nathanhourt.com