adding tests, refactoring the messy code, throwing away the UI
especially the JS-erb-controller logic duplication causes a lot of issues
how do you like the idea of removing features, to thin out the code and get rid of corresponding bugs?
I give up
see my recent comment
tracks is not in a state that can be worked with
I tried - for years - and did not get far with that
as much as I enjoy having many tests, this does not help in a code base full of code duplication and without static type checks
having a bunch of necessary tests that are slow and browser based (cucumber) doesn't help either
@C-Otto I was/am interested in working on tracks but ran into the issues you are talking about. I looked into converting some things to Bootstrap but it really just added even more code into the html while removing a little from the css so wasn't sure it was worth it.
re: UI changes - I personally run a branch that I made for myself that removes a lot from the UI. I haven't done anything about this on the main branch as I don't know how those kinds of changes would be received by most Tracks users.
rbndickson: I'd appreciate if you could raise this on the mailing list
hopefully something productive pops out
@rbndickson If you've got UI changes, we'd love to at least see them, even if we don't pull them into the main project.
@mattr- Is the general idea - mostly I changed the color scheme, tried to remove text from the UI (just removing it or replacing with icons), and reorganised the menus a little.
@rbndickson ooh, nice. I like it. Definitely digging the white background instead of the gray.
@mattr- Thanks! I have made a post on the mailing list to see what other people think. I guess the best solution would be to have a choice of themes but I don't know how to do that within the app at this point. I know how to easily change the color scheme using SCSS variables but not how to connect that to a setting in the app.
What do you think about using more icons e.g. for project settings, add note, minimizing the input box?
@C-Otto I have posted it on the mailing list - will see if there are any responses
any activity here?
Steven R. Baker
Steven R. Baker
I guess since this is async, I'll just start writing what my first plan is.
I need a concept of an "Inbox". Basically, the dumping ground I use during the Capture phase.
Right now the Todo model requires a context. Is this deliberate? Shall I use a "special" context for inbox, and then make some UI weirdness around that?
My overall goal is to add better "Capture" support to Tracks. (This is the first of several things I'm planning.)
Basically, I want an "inbox" view which is everything I've thought of that needs to be Processed. But also things that come from other places. GitHub notifications, etc.
So for instance, my Inbox view will have a Todo item for each GitHub notification. And I'll write a bunch of integrations for this.
So let's say, for instance, all GH Issues and PRs on TracksApp/tracks end up in my inbox. During Process, I'll do, delete, defer, or delegate.
The goal is that I want one inbox for all of my stuff.
I hope that makes sense.
Steven R. Baker
It occurs to me now that I've written that out, that perhaps Inbox is a completely separate feature?