Topic: Bounty for open source ByteCoin/Monero GUI - page 10. (Read 40808 times)

"settings are going to be stored at '%LocalAppData%\Jojatekok\MoneroClient\user.config"

please don't store the blockchain there otherwise on multi user computers, the blockchain will need to be downloaded and stored multiple times. Obviously the wallet needs to be user specific but I think bitcoin stores a lot of info in that file which is not specific to the user.

Thank you for this suggestion! I'll look forward to implement this in the future (with the addition of RPC API support). The support we receive from the community is just overwhelming, and always strenghtens me when thinking about my future carreer selection.

I am working hard to reach the feature set of Qt wallets, and have just finished implementing configuration support on the back-end (currently, settings are going to be stored at '%LocalAppData%\Jojatekok\MoneroClient\user.config', so they differ for each user of the computer.

I have also started working on the Address book, but only on the GUI. Regarding the wrapping of background processes (bitmonerod.exe and simplewallet.exe), I'm removing the support for storing the executables of multiple processor architectures, as that is redundant in the scope of a single PC.


Regarding further updates:

I am taking the last exams of this school year in these days, and after that, I am going on a trip with the class for 3 days. My passion about the success of Monero is still the same, I would just like to mention that will not be the case for the lack of progress reports.

The first release of Monero Client is being planned day and night, and I work a lot of hours a day to ensure that the software is easy to use and performing flawlessly. Initially, when I started this project, I thought that releasing the product fast with only some features functioning was a good idea, but then I decided not to do so, as that would have resulted in either bad coding, or a featureless wallet-look-alike without trivial functions such as transfering coins.

After the first grand release, I'll also have to deploy each new version professionally, meaning that I have to log changes and provide bundles of them for each processor architecture. So, the releases will happen when I decide they are really worth it. Don't worry, everyone will probably be pleased with the application and the upcoming updates for it.

You are right. My wallet looks for *.bin or *.wallet files. The extensions are configured in the settings file (CryptoNoteWallet.exe.config). When I create an option screen you will be able to change them yourself.

Right now fees are calculated as flat for all tx, at 0.005. If there is a lot of dust, it goes a bit higher, close to 0.01.

Know you guys have your hands full. Thought this might be the proper time to suggest a built-in fee calculator for regular/mixed transactions. Unknown transaction fees always bothered me about QT clients. Keep up the fine work.

Believe me that I have already tried to merge transactions (proof), but after further examination, I noticed that the spendability of those "TX parts" change after each new send. That's why I store them separately at the moment, but that could easily be changed (I would prefer displaying those with the same IDs with the properties 'spendable' and 'unspendable', grouped, so the summaries' correctness could be checked). That's not as easy as it sounds (especially because of sorting), so I will leave this task to the very end.

By the way, I'm working on simplifying the configuration system by using an object-based model. Even a child could understand this code snippet below:

Bug report for BitKoot wallet linked at Meanwhile I did another update (https://dl.dropboxusercontent.com/u/6522303/CryptoNoteWallet_latest.zip).

It does not support wallets created by CryptoNote Easy Miner 0.03, unless you rename the walletfile to walletfile.dat. (and the keys file too)
Please fix in next version.

(Sent a PM too)

/EDIT Not created by EasyMiner, but incorrectly named by myself, when generating the wallet and not adding the .bin to the walletname...

I haven't installed it yet but i can see the client still list a single transaction as broken down of smaller transactions with same hash. Is there any workaround to combine these to one transactions on the list ? Average users want to see a tx of 12.34 XMR instead of 4 tx with 10+2+0.3+0.04. Sorry if my question is stupid, i'm not a coder  

I thought I didnt like the logo but either it grew on me or it just look plain awesome on your software

Great!

thats beautiful, nice work Jojatekok!

also is anyone of you working on a deterministic wallet? i've recently fallen in love with electrum, and i would love to see something similar implemented to MRO.

In my WPF application, 'Balance' is called 'Spendable', so it isn't confusing at all. Currently, it is retrieved by using the 'refresh' or 'balance' command on the daemon (so whether it doesn't show the correct balance, it isn't our fault, but I have never seen it showing the balances wrong.



Thank you for confirming my idea! I hope that all the contestants have faith in XMR with its totally anonymous transactions, so the lucky developers are not going to dump all their winnings, but wait with patience and spend them wisely.


EDIT: Guess what's coming up! Right, Monero Client now supports user configurations. The GUI for options has yet to be implemented, though...


EDIT #2: Also, I forgot to mention that there is also an About dialog implemented using the official Monero icon. Notice that the number of transactions are showing up correctly too.

Can you explain why I see the same number for my Balance as I do for Unconfirmed? Very confusing. How do I get my XMR to confirm? (I'm mining at moneropool.com)

Great suggestions. The terms will be a 5:2:1 bounty split to be decided on July 1st. We have 2610 XMR collected currently so that will be the prize pool (plus anything that may be contributed over June). The decision will be made by the bounty funders over an IRC discussion.

The end goal here is really to get something the community will use in the medium/long term, not just a coding contest that ends on July 1st. So the winning GUIs will be decided based both on the current state and on future viability as a cross-platform GUI. It's fine if a submission doesn't quite meet the second part - it's still eligible to receive part of the 5:2:1 prize pool.

The bagholders are getting restless.

Please give your investors a SPECIFIC time frame...
For the release of a professional GUI wallet worthy of a world class coin.

Anyone has an ETA for a non-beta MRO GUI?

I agree. Some deadline on the bounty is a good idea. Some statement from the person holding the bounty (tacotime?) about the current work being done would be nice.

I wonder how many people are actually using one of the available wallets. There is a lot of talk about a GUI wallet being a necessity, but surprisingly little feedback about the available options.

I will hold of on adding new functions to my project until the rpc api is complete enough to take over communication with the wallet and daemon (I should have a look at the recently added RPC calls).

It's always great to have competition, as it makes products more perfect. From my side, I would happily agree to split the bounty between the developers of the most stable and easily usable wallets. There should be a voting at the 1st of July (?) of the best GUI, picked by the users.

The prizes could be the following ('x' is a variable which stands for the amount of the bounty, equally split into 8 parts):
1st place: 5 * x
2nd place: 2 * x
3rd place: 1 * x

Please give feedback about my idea!


EDIT: I have done a little bit of research of those T and F parameters when querying the transaction history. According to ByteCoin's simplewallet.cpp file, from lines 613-629, diving into the meaning of 'td.m_spent' took me to wallet2.cpp and wallet2.h. It's interesting to take a look at the struct 'transfer_details' in the header file, as there seem to be some nice parameters there which are useful. Anyway, I think that the 'm_spent' parameter indicates whether the money of a TX have already been spent on something, and 'm_tx' may contain some information we need.

Also, we shouldn't forget that values with a type of 'double' could be negative too. I've just started investigating further, and will update everyone about the case here.

EDIT #2: It looks like I was right, 'send' transactions should not be deducted from the account's balance. Proof:


EDIT #3: I have solved the problem in my client, it temporarily shows the types as "unknown" for safety. Don't worry though, the RPC integration will probably solve everything.

is bounty still on?

I can make a nice BCN/MRO GUI wallet if you like.

Thank you for notifying me, I'll surely have a look at this. But the incoming transaction parser should work perfectly. On a side note, I have noticed that a new cmd wallet is in the works on the base repository, ByteCoin. I hope that will fix those issues. I'm also curious about what the 1-4 digit number (some kind of index if I recall correctly - I'm writing these lines from mobile) means at the initial loading of transactions...

They should obviously be changed to block heights, as they would be easier to query from the RPC API than TX IDs. As you can see, I have already reduced the amount of commands given out by the wallet, and the refreshing cycle starts only after the daemon has synchronized with the network (so it isn't busy), see the RpcInitialized event of API/ProcessManagers/DaemonManager. I will be able to get transaction dates when I implement basic RPC support, which is easy to do (based on the concept of my MintPal API implementation.

https://github.com/Jojatekok/monero-client