Allow inline currency conversion input

[ghost]

Cone version used: Version 0.2.20

Hi there,

Is there a chance to put inline currency conversion into the list of future features?

Here is one example of what i meant by that

2020-05-04 * Conversion
  Pocket            EUR 10,00 @ USD 1.10
  Bank

This can quite be good since it works in ledger-cli and it is super convenient to convert and write down rates right away instead of defining changes right before you move your property between accounts.

So far, cone is allowing only numbers in that input field.

[bradyt]

This seems to be two issues. One is improving the data entry UI to handle this case, the other is making sure the parser can handle these entries, and any potential issues arising with a balance feature we might see implemented in the future.

I can think of a few things off the type of my head with respect to improving the data entry UI.

@alerque suggested some time ago that cone should allow users to edit the amount field as free form, instead of the more strict pair of quantity and commodity fields. Presumably, the latter strict case is convenient for a majority of data entries, so I'm imagining having some sort of action in the UI to flatten those two fields into a single free form edit amount field.

It's not obvious to me the best way to do that yet, but I'd like to hold on thinking that out, until cone has been ported to more platforms, like iOS, web, etc. Then we can consider how to make such a feature work on more platforms. Potentially, we could have the pair of fields initially only available on Android and iOS, and only implement a toggle feature for those two platforms.

(In turn, to help towards cone being ported more quickly to other platforms, I'm considering adding a feature for usage of third party plugins for file import/export, as then relying on another project would speed up the initial porting step for cone.)

I might also want to prioritize how the code base is structured, to make it easier to improve responsive layout, to deal with variation in screen size, orientation, etc.

I may feel various other features may block on myself working on implementing this feature, but just wanted to offer some examples at the outset.

[ghost]

If i may suggest: in the beginning, we could just have the option to add commented lines into transactions so we can mark the transactions when we sync the ledger db from phone onto PC or anything with a decent text editor really.

Cone is awesome for data entry,, with great looking color scheme and very clean and simple UI, however adding comments can allow delay some features while allowing its users to save comments and tips for ourselves when we review the data later on.

As for the base code and importance of it: you have my vote. Clean, small and yet robust base set can be more than enough while plugins can extend the core set indefinitely.

[bradyt]

That's a good idea.

(I would have made this message shorter if I invested more time.)

We might want to parse comments as top level journal items, as well as comments appearing in transactions, either appearing as entire commented indented lines, or, as well, as comments appearing as trailing after description or postings. Then we hope to display the comments in the home page view. I've also considered some sort of "raw view" toggle, in case current state of parsing is hiding some part of the users file.

But besides parsing and displaying, there is yet again the issue of how do we add this to the UI, preferably, in a nice elegant way, allowing for other future possibilities. And if we modify the UI, are we doing it before other priorities, like responsive layout, or considerations of how cone can handle both screen interaction, as well as keyboard, and another aspect I didn't mention above, is any accessibility improvements we might come up with, like for blind, or difficulty with vision, larger text, screen readers, etc.

So any comments on how the UI might look is appreciated. Potentially we could be researching how other data entry apps are doing this. I've already taken some inspiration from the MoLe app, with the design of the form.

Just to point out a particular problem, some of this might be done with a long press, or more simply, a menu button in the app bar. But with a long press, I'm not sure how to make that option work if a user is at a keyboard, rather than touching their screen. And then across multiple platforms. And accounting for any accessibility issues.

[ghost]

Well, I have an idea.

Before I present it, let me tell you my point of view: I started using ledger in plain text format less than 7 days ago. It is a good system but it requires some fast learning. I have zero accounting background but I am learning quick enough and ledger with cone and plain text db seems like a perfect way to bridge the gap with different OS ecosystems since all apps are missing that badly.

With that being said, there are 2 ways to implement this comment insertion in my opinion and guided with different applications saw so far:

1. Allow comments for whole property transactions. If that is the way maybe an option would be to add # sign at the bottom, next to floating + (above it?) creating that option visible only when user inputs something. The biggest challenge here for newcomers is the lack of values for input fields in cone so far since ledger can be quite intimidating at first. From my perspective, I thought this at first: what a clean a nice UI, I cannot get lost here. When I started typing things though, the UI became irrelevant since I had to focus on typing. All in all, here are 3 ideas idea for this way (not a pro ui designer, forgive my beginner level GIMP skills):

Now I have added these on purpose like this to show that screen will not look busy even when you add things to UI.

2. Other way is to allow creation of plain comments from main page of the app (add # above + for example). I dont think that this is the way since adding new comments should be handled from "Add new" since it makes sense. Unless you plan on expanding cone and adapt it for other usage as well? While I was browsing the not so great tutorials over the web for ledger format recognizable by ledger, I saw that somebody mentioned capabilities of using this format for time tracking as well. If you want to extend use cases for cone then add this "Comment" part to the main screen.

Last but not least: I like the way you are maintaining this application in general and bits and pieces here and there make it unique. It is modern, with modern UI and design language yet super simple and ready for usage.

With that being said, you mentioned iOS and WEB app? If that is the case here, please make sure that there is enough data for consistency in UI eg. iOS may not allow smaller floating circle with # above larger + circle by design.

[bradyt]

For some reason I was trying to imagine how you indicate to the app which posting is selected, but I just realized that could be implicit by where focus is, and that is even platform independent. Though, you can't then tab through the focus items to get to the menu, that would lose the focus and a notion of implied selection. But anyways, the initial intention for the app design is to make it easier to deal with our small touch screens. Maybe we could later come up with some sort of keyboard shortcut or convenient mouse action, for when users want to act on a posting without using a touch screen.

I am thinking that a comment button would go in an ellipsis menu at the top right, in the app bar, for now. We could easily end up with various features competing for screen real estate, and we still have an issue with potentially trying to read text that is behind the buttons, which we've yet to solve (maybe the buttons should disappear if we pull up after already scrolled up). I'd like to keep only the most common actions as part of as simple a view as possible, at least for now.

Maybe we could add a "merge cells" action too, in the ellipsis menu, that would use the context of a focus field to merge appropriate cells. If focus is in quantity or commodity fields, it could merge them into a single free form text editing amount field, where a user could add a conversion rate, for example. If focus is in account or amount field, it could merge the entire row into a free form text editing field. And possibly yet another context/situation could allow users to merge the entire journal item into a large multiline text editing field.

With that being said, you mentioned iOS and WEB app? If that is the case here, please make sure that there is enough data for consistency in UI eg. iOS may not allow smaller floating circle with # above larger + circle by design.

I'm using Material design, and I think Flutter is in some sense, "painting everything itself". In other words, it's rarely using native widgets, if I understand correctly. But it's a good point, I'll have to watch out for differences as I attempt to port cone to iOS (I'm hoping that porting cone to iOS is the next step in the project). For example, the next issue is dealing with linking a journal file to cone in iOS. You might notice that cone is using Android's native system UI to link a file.

[ghost]

For some reason I was trying to imagine how you indicate to the app which posting is selected, but I just realized that could be implicit by where focus is, and that is even platform independent. Though, you can't then tab through the focus items to get to the menu, that would lose the focus and a notion of implied selection. But anyways, the initial intention for the app design is to make it easier to deal with our small touch screens. Maybe we could later come up with some sort of keyboard shortcut or convenient mouse action, for when users want to act on a posting without using a touch screen.

Yes. For bigger screens, when you select comment icon, it may even show line selector so you can select lines and comment them and/or reverse the action by un-commenting them. maybe this can be achieved on android with material design without "select buttons" and just highlight the lines? I have noticed some programs are using this approach: you select an action allowing multiple selections by graying out the header of the app and in it showing list of selected items while highlighting the selected lines. If i remember where i saw this, i will post it. Please be aware that this can be done without adding check boxes at the beginning of the row thus saving screen estate and that example is what i cannot think at this time (one of the F-Droid apps perhaps? hmm).

I am thinking that a comment button would go in an ellipsis menu at the top right, in the app bar, for now. We could easily end up with various features competing for screen real estate, and we still have an issue with potentially trying to read text that is behind the buttons, which we've yet to solve (maybe the buttons should disappear if we pull up after already scrolled up). I'd like to keep only the most common actions as part of as simple a view as possible, at least for now.

Sounds valid! For screen estate and prevention, you might wanna explore the "3 dot" option as well. That could bury the option beneath one more action (one click/tap is required to reveal the menu) however it may be good for adding various options and then determining what to do with them in UI and where to place them. So clutter will be removed from main screen.