It is a nice thing to have and it was present on the older UI.
The implementation of this was started on #33. However nana requires more careful design dealing with this, so I created a special task to isolate the risk.

Better display of Totals. The status bar is problematic. We need copyable and filter-able (per wallet at least) totals;

It allows the user see in detail the movement. It must:

-Show all fields;
-Edit all fields
-Integrate with MovementTimelinePresenter, both in creation and in editing.

Detect if it is an old version of the model and do the convertion.

Some way to filter.

They should count as one operation outside of it (on normal frame).

It will greatly simplify everything.

It should save before opening and after closing, informing accondingly. It should be similar with the wallet overview too, being the remove also disabled for now. Undo and redo are optionals, if are not too hard.

Nowadays it is created together with the budgets, but it should be created only when it is executed. We need instead have the budget amended to have a "initial_estimate" field, populated at its creation and a new table to relate budget per wallet, that is created at its execution.

It should be presented as the first row of every budget, but with a different color, untouched by filtering. It should have a custom dialog to edit, as it will be fed only once.

Any edition at a previous budget must be refreshed manually. The interface however, must offer that option.

It is a little confuse to have all in the same dir.

It has no benefit. We should disable the menus or otherwise nullify these effects.

For some reason when you close the execution dialog it saves. I need find why.

On totals suming, we should use a fixed estimate instead of pure estimate: The fixed use this math:

fixed = if( abs(accounted) >  abs(estimated) OR signal(accounted) != signal(estimated) 
    then accounted 
    else estimated;

Also is important to provide some way to choose if the you want to include the previous data into consideration [To be solved on #5 ]

Fix it.

Save before open and after close, warning accordingly. If not hard, create undo and redo options inside it.

The present form is bad as because it accumulates two roles, the summary and the tab switching mechanism. Other problem is the calling overhead caused in passing messages from MainPresenter to the Execution and Estimate lists.

The goal of this refactor is to relieve that last responsibility. For now it goes to MainPresenter, that really needs them to have easier communication to the presenters.

Important feature, as user always is prone to errors, we should give she a way to rollback. Also, it gives a more professional look to the project.

The ideal is to have a color code to indicate the payment status of things.

The current hot saving is very annoying. Its better let the user choose when to save.

It should be possible to create/edit/delete estimates, with all its fields.

Provide someway to get how close it is to the pay day of something, if not paid yet.

To fix #14, the best to do is tweak the triggers to do the same estimative than the totals. We will need to do a conversion from v0.1. Lastly, we must let the user edit the previous field from the first month.

Know what you pay is hard, you have to look at each estimate. Some sort of global view would be welcome.

It is a modal dialog that allows the view/editing of an EstimateView.

• It must show all fields;
• All fields but "fulfilled" must allow editing;
• It should be integrated to EstimateListPresenter through:
  1. When the user double clicks or press space in an estimate
  2. When the user inserts a estimate (Ctrl+ins)

Some recent code assumes we always have a selected budget, but sometimes we have dbs without selected budget. It is impossible to unselect the current budget and after loading we select the active budget by default. But when you create a new budget or load a budget without active budget it does not have a active budget to select so nothing is selected.

As the new model 0.4 was not well tested and the 0.5 will not create a proper model, we need to support 0.2, including write operations. But no extra UI will be done.

The reports to be available are:

1. Daily balance: Graphically, with options by wallet, by category, by debit, credit or transfer, and obviously, by date or default by everything in current budget;
2. Daily balance: Graphically, with options by category, debit, credit;
3. Monthly final balance: CSV or Graphic, with option by wallet, by category, by credit, debit, transfer. It overlays the estimate and the movement.

It does not take the #13 in account because it need to be coded in the model. So it give meaningless value. Maybe merge it with a major redesign of the model?

Create options to undo/redo, to delete budgets, to create out of order budgets and so on.

Having the model and the view coupled is bad and I should feel bad. Should decouple it in sort of document/view or MVC scheme.

Occurrences

• OrcamentoMainFrame;
• ExecutionDialog;
• WalletOverview;

This class is the glue among MainPresenter, ExecutionListPresenter and EstimateListPresenter.
It should be located on the main frame and have the the {Execution, Estimate}ListPresenter lists as item tabs. A third tab should have the totals (Summary) with the initial estimate, current estimate and executed categorized by income, expense and total.

It is barely usable and misleading in some cases (estimates). Must be addressed.

Fix the model, being the execution turned on movement, that can say which wallet is origin, and which is destiny, and with estimate being optional; The due date of estimate is now mandatory (the interface must default to the current day).

The execution should be now a view relating estimates with the total execution of them.

It need to create a Recorder stub for each presenter (maybe a template?), then use it for instead of the custom ones based on bool flags in use currently.

Allow the user export the CSV of the selected month; Also allow she to export estimates only or executions included.

They kind of violate the separations of concerns, as they does not deal with the widgets. A better approach would be put them as freestanding functions.

Currently we have a fixed order: first for category, then by name. It should be nice to have other orderings.

Some fractional values are being rounded in wrong way. This is due the storage of amounts as integer (Ironically I choose store that way to avoid rounding errors) and the consequential need to multiply by 100 and round before storing.

Example

Put the value 0.59 in any amount field. It will be shown as 0.58!

In many cases we expect lists to be filled with sequential integers without gaps and it is true by now (none of them has deletable items) but it will probably change in future. Storing the id directly will avoid me future headaches.

Occurences

It occurs on:

• Wallet Dialog;
• Budget List;
• The category listing (on estimate category changing);

Should search for more.

Test creating the ui using nana instead wxWidgets

It is to much complicated. Just put the as follows:

Entire line as*

• Green: Credit;
• Orange: Debit;
• White: Neutral;

*Except fields accounted and remaining, as they encode your current situation.

Accounted and remaining

-White if accounted is zero;
-Scale from white to green: if it's credit and it's value is between zero and the estimated, exclusive or if the estimated is zero and accounted is larger than zero;
-Blue: if credit and it is equal or more than the estimated;
-Scale from white to Orange: if it's debit and it's value is less than zero and more or equal to the estimated;
-Red if the accounted is less than estimated and it is not credit;

The table bellow summarizes the color schema