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
|
|
|
"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.
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...
|
|
|
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.
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.
|
|
|
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 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:
|
|
|
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)
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. 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! 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. 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.
|
|
|
is bounty still on?
I can make a nice BCN/MRO GUI wallet if you like.
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.
|
|
|
Actually no, but so far all of my attempts to send monero using your GUI have failed. If I leave the payment ID blank it gives me the error message that the Payment ID is in the wrong format. If I fill it in, then it tells me the payment address is invalid.
I'm sorry to hear you are having problems with my wallet. I have test the sending and receiving of coins with my wallet with and without payment id. They both still seem to work ok. Could it be there is a space somewhere in your destination address or in the payment id textbox?
EDIT: Look what I have for today! Looking good! I see you also have a 'spend/received' column. I just noticed in my own wallet this might be wrong. I had test wallets where the amount of spend and received combined dit not add up to the actual balance. When executing the 'incoming_transfers' command at the command line, with the 'available' or 'unavailable' argument you'll see you get the transactions of type 'F' or 'T' respectivly. I don't think the types correspond to received and spend. I changed the type column to 'Availablity'. Maybe someone else knows the relation between availablity, the 'T' and 'F' type transactions and spending and receiving coins? A minor update of my wallet: - Wallet update status is shown in status bar (just like updating the blockchain, updating the wallet can take some time) - Transaction grid now adds new transaction instead of clearing the whole grid every time it refreshes - Changed spend/received to unavailable/available 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.
|
|
|
I tried it on Ubuntu. Sometimes when I select text in the Daemon log window it crashes. Then bitmonerod becomes a zombie process http://pastebin.com/FKmifxY3I can't get it to transfer MRO either, and don't know why because there isn't any output in the wallet log window. Thanks for the feedback! The transfer should work now (redownload the files from the link in my previous post). I have been able to reproduce the crash when selecting log text (very weird, nothing special happens there so it seems this is one of the quircks where mono behaves differently from the .net framework). I will look into this (might be I just have to disable selecting text and add a copy to clipboard button to get around the problem). I tried it on Ubuntu. Sometimes when I select text in the Daemon log window it crashes. Then bitmonerod becomes a zombie process http://pastebin.com/FKmifxY3I can't get it to transfer MRO either, and don't know why because there isn't any output in the wallet log window. TL;DR: There should be a wrapper called 'Launcher' for the GUI which kills all the related processes if the Client crashes. This could be a solution, but I prefer it if I could prevent crashes al together. I think that should be the the goal instead of adding another process which monitors other processes. 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 tried it on Ubuntu. Sometimes when I select text in the Daemon log window it crashes. Then bitmonerod becomes a zombie process http://pastebin.com/FKmifxY3I can't get it to transfer MRO either, and don't know why because there isn't any output in the wallet log window. 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.)
|
|
|
Wow nice to see some screenshots, keep them coming! If you need someone to do the french translate, send me a PM.
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 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.
You caught me redhanded . I haven't used WPF before this project. I said before I wouldn't port to WinForms any time soon, but I changed my mind. I have it running on Ubuntu 14.04. It generally works, but needs some more testing before I'm confident enough to release it. It will be ready in a few days. If anybody is feeling adventurous, you can get the source from the github page and compile it yourself. The output of the CryptoNoteWallet.Gui project is the one you'll need. You will need to change the wallet and daemon executable names in the CryptoNoteWallet.Gui.exe.config (they don't have extensions on linux). 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 )
|
|
|
Make sure you have no spaces in any of your folders, that is what causes the error.
Thanks for pointing this out! I have released a fix for this problem: https://dl.dropboxusercontent.com/u/6522303/CryptoNoteWallet_latest.zip' getaddress' and ' mining_status' calls will be added if the code is accepted (value reading only). A ' network_bc_height' will be added soon if possible, in order to retrieve the target blockchain height and following sync status from a GUI. A Qt GUI is currently in development. (multi-platform) It will initially use the RPC API, but the final goal is to integrate the daemon and/or the wallet directly in it with high-level libraries ( Qt is good for interfacing UI with C/C++), providing more information and better reactivity. Designing the architecture and keeping it user-friendly will probably take some time. I haven't tested the C# wallets yet (tried 'xbuild' with Mono but throws errors), but it has probably more features for the time being It uses WPF, unfortunatly that is not supported on Mono. Should have gone with WinForms, that would have made it possible to run it on Mono without modifications. Good to hear the RPC API is getting more functionality, if it has enough features I can switch to using the RPC API. 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 have added simpleminer support.
Please add support for the built in miner (start_mining and stop_mining commands in the cli wallet). Many people who are not serious miners and don't want to figure out how to configure a pool can still solo mine in the regular wallet and help decentralize the network if it is as ease as a checkbox to turn on and off, with free coins occasionally being dropped into their wallet if they get lucky. A very successful coin could have millions of people doing this. This was Satoshi's original vision and unfortunately got lost in bitcoin but we can bring it back here. It is a game changer. 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-clientI 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.Nethttps://www.nuget.org/packages/MintPalApi.NetDonations 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.Nethttps://www.nuget.org/packages/MintPalApi.NetDonations are highly appreciated in order to keep the development alive: - Bitcoin: 14wHehBtFt321WTV15khon8Juaxh9drnfJ
- BlackCoin: B9nBaQSFV4Ns5L8Jze8vaxc176zeE8XjDQ
|
|
|
|