Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor The File Store And GUI #143

Draft
wants to merge 27 commits into
base: develop
Choose a base branch
from

Conversation

dahenson
Copy link
Owner

@dahenson dahenson commented Nov 16, 2021

Purpose

This is a major refactor that started with my dissatisfaction with the close coupling of the GUI with the actual list store and file saving interface.

My intent is to separate the "backend" concerns from the "frontend" concerns by encapsulating the "backend" code in lib/ and the "frontend" code in src/. Once the two concerns are separated, it should be easier in the future to apply features without needing to intimately know how every piece of the app works. Refactors should be easier with an agreed-upon backend interface, and (hopefully) online syncing with services like libecal.

With this rewrite, I am switching to a ListBox for the GUI to allow for more customization with each task.

Before Merging!

In order to reach feature parity with the current GUI, the new app GUI needs to be able to do the following things:

  • Add a task to the list
  • Remove a task from the list
  • Edit a task currently in the list
  • Reorder the list by dragging (this will take some time and effort to implement)
  • Undo any of the above actions for the lifetime of the window instance
  • Redo any of the above actions for the lifetime of the window instance
  • Store a history of tasks that have been added
  • Clear the history
  • Implement all known keyboard shortcuts
    • <Esc> to quit
    • <Ctrl> + q to quit
    • <Ctrl> + w to quit
    • <Ctrl> + z to undo
    • <Ctrl> + y to redo
    • <Ctrl> + <Shift> + z to redo
@dahenson dahenson self-assigned this Nov 16, 2021
@gxhamster
Copy link
Contributor

gxhamster commented Nov 16, 2021

Absolutely agree. I will look into this.
Btw I am in no way an experienced Vala programmer. Just started two days ago

@gxhamster
Copy link
Contributor

I think we should first try to ge the app to compile. So it would be easier for development

@gxhamster
Copy link
Contributor

Why dont we use glade to construct the core widgets ?

@dahenson
Copy link
Owner Author

I think we should first try to ge the app to compile. So it would be easier for development

The rewritten app is currently compiling into [builddir]/app/agenda. You should be able to run it if you've already run meson install or ninja install to make sure the gschema is installed. At the moment, you can add a task and check or uncheck complete. Those two operations are persisted. I still have some work to do on editing, reordering, and removing tasks.

@dahenson
Copy link
Owner Author

Why dont we use glade to construct the core widgets ?

I prefer not to add glade as a dependency. If I was building the app using C, I might be tempted to avoid alll of the boilerplate involved in setting up custom widgets. In vala, it is much easier to declare your widgets, and the GUI and the business logic is all written in one common syntax.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
2 participants