| Age | Commit message (Collapse) | Author |
|---|
|
Not everything needs to start with Config
|
|
Do this by making the fragment transition functions idempotent.
|
|
|
|
|
|
|
|
This fixes list selection to survive renaming configurations.
|
|
|
|
|
|
|
|
This allows simplifies the code a bit. Also, a few other minor changes.
|
|
|
|
This works much better with a data-bound UI -- no confusing erasing of
the text box, and no crashes, either!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Highlight the selected configuration, and add a border between the two
panes.
|
|
This will be used for future sorting.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This was accidentally missed earlier when adding the optimization to
omit binding the service when unnecessary.
|
|
It will be reused for entering public keys of peers.
|
|
|
|
|
|
|
|
It may share the layout with a FAB, and that requires a parent
ViewGroup.
|
|
|
|
|
|
|
|
|
|
Apparently "configuration" is the proper term, not "profile".
|
|
|
|
|
|
Prefer updating an object instead of replacing it. This preserves the
selection in the UI list. Also make renaming atomic as it should be. Now
the only possibility for data loss is if the old file can be opened but
not written to.
|
|
|
