As I have promised before, here are some teasers from the upcoming 'Options' feature:



A lot more interesting features are on the whitepaper (which is only existent in my head) already, and I will keep some of them as a secret until their deployment. The RPC API's functions should really be improved though, as I will not be able to step further in stability and reliability whether the condition of reducing the amount of those BUSY messages isn't met: We need functionality without syncing the entire blockchain!

Remember: None of the altcoins' GUI wallets will ever be as featureful as Monero's

Monero Client's application data and the blockchain's path are not in correlation in any way. Differing from the Qt wallet (which is great to have for multiplatform support ), the Options tab will probably contain many settings (including the blockchain's path) which were only available by command-line arguments before.

I am constantly working on the application's structure, which would become a programming superhell if I wasn't taking the steps of prevention. The Views are going to be in subnamespaces (.Views.[...]Window) in order to keep things clear. As I have already mentioned, I am working on the UI for configuration (teaser screenshots are coming very soon ), but yesterday, I was too tired to program, so I decided to take a break for that day...

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.

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:

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.

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.

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

Do you mean my WPF wallet or BitKoot's project?

And thanks for everyone for all the support we get! I am currently working on making the logger's code better (so it should be limited to 300 lines at most), but making the scrollbar stay where it is (without autoscroll) is not as easy as I've expected.

Nevermind, I'll just simply comment this for TODO, and just leave it lying there, as it is a lot more important to implement the transactions tab correctly (so I can release the first test version).


EDIT: Look what I have for today!

Here we go, I've just successfully implemented process input/output logging. The next step is to make both the code and the log format cleaner.

Well yeah, you're right, but it could be used for prevention of bad stuff happening on PCs of non-tech-savvy people who don't know how the GUI's process wrapping works. Every application which depends on an internet connection should be handled very carefully. I have been using the concept of Launcher in EECloud, and it just worked like charm.

I know that in the long term, we are all going for perfectionism, but we can never be sure whether a new daemon version released silently contains message modifications which our Clients cannot handle correctly.


At the time of writing this post, I'm in the middle of creating a debug window in order to easily track and hunt down bugs, and reduce the amount of redundant calls (for example, refer to the case of trying to refresh the wallet while the daemon is busy).

I have an idea for avoiding zombie processes, which should be implemented to both .NET projects (WinForms and WPF):

There should be a Launcher application which doesn't create a window, but starts the Client (GUI). It should also read the settings of the GUI somehow, in order to get the file name of the wallet, the daemon, and the miner. After the Client exits, the Launcher should check whether those processes are still running, and if they are, it should just simply kill them. (If a crash has happened already, then it doesn't really matter whether the wallet and blockchain states are saved.)

TL;DR: There should be a wrapper called 'Launcher' for the GUI which kills all the related processes if the Client crashes.


EDIT: In order to implement transactions with dates visible, I would have to retrieve the information of a block height, which - with the current, process-wrapping, event-based reply system - is a lot of hassle. I would be very happy if the API evolved to a level which could be usable. (It should not return "busy" whether it hasn't yet synchronized with the network.)

Thank You for your generousity and handsomeness! Although, I would not like to concentrate on the globalization yet (only setting up the system was important). I will surely notify you whether it is time to start working on translations (currently, many strings have to be added and could be changing).

I already have an idea of implementing the Transactions tab like it is in Bitcoin Core, but as a student, I have to study for the last exams of the year. From Monday, I'll probably start having more free time, so I can work on Monero Client almost as much as I would like to.

It's so great of you for being cooperative! As I have promised, I'm improving the feature set of my WPF project day by day, so people can expect the first test release soon. Things which are non-functioning yet are:

• Ledger of transactions
• Address book
• Top menus

Some of the tasks with top priorities include localization support: The earlier it gets added, the less work it requires to be implemented.
Just to mention, the back-end already supports multiple transactions at once, and stores a list of all the transactions. I'm not planning to add support for multiple wallets running at once, as Monero provides privacy for a person with only one digital address. (So, not adding a 'Receive coins' tab is on purpose.)

As for closing the client, I have added a business indicator which shows a status message of shutting down.



EDIT: Aaaaaand, here comes the localization support!

(It's Hungarian, like me )

I have tested it already, but there is a huge faultiness which causes the RPC functions not to work while the daemon is busy, thus, the process of displaying data takes ages for a person with an unsynchronized blockchain.

It may be a good idea to port your project to WinForms, as I can see that your C# programming style fits that more than WPF. I would happily maintain my own project (https://github.com/Jojatekok/monero-client) as a WPF alternative with a lot of flexibility and clean design, while you could work quicker on a cross-platform solution. Porting for me would cause a lot more hassle, because I use MVVM with bindings for displaying data on WPF windows.




EDIT:

I would like to ask for the help of simplewallet developers! I noticed that when I use the argument '--password <key>' to forward the unlock key to the program, it simply just exits with the code of 1 whether the password is incorrect, without leaving an error message behind. It would be okay if the "normal" exit code of simplewallet would not be the same, or the wallet would print an "invalid password" error message before it terminates.

And also, I would appreciate if there was an option to encrypt a wallet later than its creation.

Well, it does not really function the way developers want it (it returns 'status: BUSY' in most of the cases), so that's why I prefer process wrapping at the moment. But I'm building my project like a C# API for Monero, so moving to RPC would not be a very big deal.

I am working on a version which will look more like the official Bitcoin wallet, and the GUI functions could easily be expanded.

Although, I am going on holiday tomorrow till sunday, but expect it to be revealed in some weeks. I may also post some screenshots soon


EDIT: Here is a quick teaser of the design itself, as the program currently works with the daemon only (wallet functionality is not yet implemented). As I have already said, I'll be working on this very hard from the weekend, and further development should take less and less time because of the flexible build-up I am using. I already have the ideas of what to add in the future, and it should end up being - at least - as comfortable as Bitcoin Core in the end.

It could also easily be rewritten when it's time for using a well-built RPC API.



https://github.com/Jojatekok/monero-client
I will make the binaries available once the GUI supports wallet methods.

I am also going to work on a wallet GUI in .NET, but based on Bitcoin-Qt

Bump!

MintPal API .NET is an Application Programming Interface for data transmission and retrieval from MintPal through the Microsoft .NET Framework. It is still in development as I am writing this post, but it should already be flawlessly working with the official v2 API.

https://github.com/Jojatekok/MintPalApi.Net
https://www.nuget.org/packages/MintPalApi.Net

Donations are highly appreciated in order to keep the development alive:

• Bitcoin: 14wHehBtFt321WTV15khon8Juaxh9drnfJ
• BlackCoin: B9nBaQSFV4Ns5L8Jze8vaxc176zeE8XjDQ

MintPal API .NET is an Application Programming Interface for data transmission and retrieval from MintPal through the Microsoft .NET Framework. It is still in development as I am writing this post, but it should already be flawlessly working with the official v2 API.

https://github.com/Jojatekok/MintPalApi.Net
https://www.nuget.org/packages/MintPalApi.Net

Donations are highly appreciated in order to keep the development alive:

• Bitcoin: 14wHehBtFt321WTV15khon8Juaxh9drnfJ
• BlackCoin: B9nBaQSFV4Ns5L8Jze8vaxc176zeE8XjDQ