sintrastes / bedelibry-app Goto Github PK

The user should be able to load their own schema files from disk.

Currently, the app uses a built-in schema.

The user should have the ability to specify and edit their own schema. Features such as import/exporting schemas into .mont files should be supported as well.

Currently our modules for individual pages are stored in modules like Montague.Frontend.Types, Montague.Frontend.Schema.

It would be convenient if these were all grouped under a common Montague.Frontend.Pages module (e.x. Montague.Frontend.Pages.Types, Montague.Frontend.Pages.Schema) that re-exported all of the submodules.

Currently, support for obelisk on M1 OSX hardware is lacking.

My workaround for this currently is to just use reflex-platform rather than obelisk, and to build a jsaddle-warp executable via cabal when testing things on my macbook.

However, we may still want to support obelisk for how it handles Android builds (I'm not entirely sure how this works yet -- but it seems with the same main.hs they are able to compile something to either use jsaddle-warp, or jsaddle compiled via ghcjs.

It's currently unclear to me how we might accomplish this with nix. One thought was to use two separate cabal.nix files (as using plain reflex-platform + cabal, cabal has a hard time finding some of the obelisk dependencies, so the idea is to have one cabal.project file that excludes these for cabal builds, and one that includes them for obelisk builds), but I am unsure what the "right" way is to make nix use one or the other depending on the attribute.

Similarly to the entities page, we should also have a page for displaying types.

As this project is still in the prototype stages, I've decided to do all of my active development of "core montague" from this repo, in order to get the quickest possible feedback loop for the app.

Eventually, once some of the core MVP features become stable, I'll want to backport these changes into the core Montague repo, and publish to Hackage so we can use that as a dependency here.

When no types or entities are available, something such as "No entities have been entered" should be displayed -- possibly with a link to how the user could add new entities.

Currently, when entering in sentences into Montague, the only two possible results are a "Could not parse" error, or correctly displaying the parsed term and it's type.

While this capability will no doubt be expounded upon over time, as a first step, it would be nice to have some better error reporting (for instance: "Could not parse: Unknown word "bob"."

A possible extension of this capability in the future would be to add suggested fixes to the relevant problems (for instance, "Would you like to add "Bob" to the lexicon?")

Currently, our Page type is just an enum.

However, in order to support features such as #19, we will need to add "sub-routes" (such as "anchors" to specific types/entities) into this data type.

This should be fairly straightforward to do with Haskell's ADTs. Example:

data Route =
    Home
    ...
  | Entities { anchor :: Maybe EntityId }
    ...

As the application becomes more complex, this would also allow for things like specific preference pages.

Currently the iOS bottom nav bar looks pretty sad with just text. Adding some icons (from https://feathericons.com/) would make this look much nicer.

Now that the schema entry text is on its own page, it should extend to fit most of the screen space.

Note that this is also currently inconsistent between iOS and Android styles.

It would be nice to move the Page type to a separate module so we can import it qualified and use it like Route.Types, Route.Home, Route.Schema, etc...

This would allow (potentially?) for better auto-completion opportunities for HLS.

Currently, when there are too many entities or types, the main div in the entity and type pages will overflow.

The user should be able to scroll to see as many entities as are available.

In addition to simply being able to parse sentences with regard to a schema, the user should be able to make queries via the parsed logical forms of sentences via meriv-core.

The user should have the ability to enter in new entities and types via an entry form.

These could be displayed via modal dialogs on Android and iOS targets. Perhaps on Desktop targets we can look into using new windows via Tauri.

Note: The user should probably be warned when they do this that this will overwrite then hand-written schema.

See https://materializecss.com/select.html and https://codedgar.github.io/Puppertino/examples/forms.html

It is currently unclear to me how one would implement user preferences in a reflex app. The easiest thing to do would probably be to just dump preferences into something like a yaml file -- but how do we access the underlying file APIs necessary to do that?

I'm not sure if this is something that would be simple to do from the native Haskell .so that is built by nix, or if modifications need to be made on the Java side in order to get this to work properly with Android permissions. It would probably be worth it to reach out to others using reflex to see if there is already an easy solution for this.

In Materialize.css, when dropdown menus and modals are open, the rest of the screen is slightly darkened.

We should find a way to implement this with reflex.

Currently we only have desktop-oriented css styles for the app. We should add some more desktop-oriented ones as well.

Currently, I can't figure out a way to build montague-reflex via ghcjs, or to build reflex-platform's Android target on my M1 macbook. Thus, it is crucial to get CI working for these two targets in order to make sure these targets are being built properly.

install-nix should be able to do this.

Also, CI is just nice to have in general. 😄

Currently we do not have a nice way to package Montague as a desktop app. Either electron or tauri might be useful for this purpose -- and we may also want to bundle these as appimages or some other sort of bundle for easy installation (nix-bundle should be helpful for this).

Currently the user can only have one schema loaded at once.

The user should be able to pull multiple schemas from different sources, and be able to manage them -- so there should be a page for the user to be able to do this.

Once this is implemented, the current schema page should be changed to a page that the user can open to edit individual schema files, and should not be part of the standard navigation menu options.

Currently, we have a bunch of css style attributes used in various places in Haskell code.

Most (if not all of these) should probably be moved into main.css.

In the type and entity pages, we are displaying error messages like:

"No schema has been specified."
"You need to enter one in the schema page."

It would be helpful if "schema page" in the above was an actual link to the schema page.

This is something that I assume will require working from the Java side (though, maybe I'll be surprised!) -- however, the idea here is to use the "share" feature found on relevant apps on Android (I assume iOS has a similar feature if someone wants to work on that) to send a link to Bedelibry, which would then open up a UI for registering notes about a relevant article/video/etc... -- ideally working intelligently and guessing the correct type, and auto-filling some of the relevant metadata.

Doing this on the desktop/web side of things would probably require something like a browser extension.

e.x. text sizes.

The user should be able to specify a filter to use when searching entities in the entity page.

Currently it is hard to tell whether or not what is currently displayed in the schema page has been saved or not, and it is not possible to reset unsaved changes.

To remedy this, we should add a "saved" status indicator light, and a reset button.

Essentially, I think the API we want is something like this:

monadicTabDisplay $ do
    preferences  <- tab "Preferences" preferencePage 
    schemaResult <- tab "Schema" $ schemaPage preferences
    tab "Home" $ homePage preferences 

where the do block there is essentially a free monad for specifying the tabs and their dependencies. This could probably be a generalization of tabDisplay. We could maybe even make it a higher-order-component and backport these changes to reflex, as I think this kind of pattern would be very useful in general.

In the entities page, all references to types should link to the appropriate item in the types page.

Currently, the idea is to have lexicons specified in a special human-readable file format (.mont files) -- however, it would be nice if there was also a nice GUI for viewing/browsing a schema.

This could be a simple two-paned view which the user can easily switch between (one for types, one for lexicon entries) with a search bar that each displays a list of entries.

The entries could be something like:

1. One line with the name (and possibly some other relevant info such as synonyms for lexical entries).
2. 2-3 lines showing a preview of the "description" associated with the type/lexical entry.

Where the "description" is essentially documentation coming from a doc string in the .mont file about the relevant entry.

It would be nice to have a "welcome" page that greets the users whenever they open the app, and points them towards tutorials, and some basic tips for how to use the app.

This page would not be part of the standard navigation menu, and there should be an option to hide this page for advanced users (e.x. "Don't show this page on startup" preference).

The user should be able to export mont files to their hard-drive outside of Montague's internal storage location.

This would be particular useful for web targets, as we cannot directly save things to the user's hard drive.