Closed danieltomasz closed 1 year ago
Creating (and deleting) new notes isn't really the tricky part here (it's the editing). I've disabled creating/deleting mostly as a precaution until we figure out the UX for it.
Like you say, the first thing that comes to mind would be to define a folder where new notes are created. I don't use Dataview myself, so I would love to understand how Dataview users would like it to work. For example, Dataview queries can query notes from any folder. Would it even be useful if you only could add notes to a single folder? Are there other alternatives?
I often combine different sources in a dataview query; for example I display notes from certain folder or from certain tags; Other case is to display notes from certain folder satysfying certain tags;
For me having optional one folder for creating new files is sufficient, I can move them later to other folder (so the folder where new files are created might be called "project inbox" (in the GTD sense) and be defined both for dataview and folder-sourced projects; Creating and editing notes might be a separate issue;
For you plugin, I would really differentiate between editing the note itself and editing the metadata (fields) visible in the view
I dont need to edit the notes inside the project view, I can edit them as a normal note outside obsidian; what I need is to have to ability to edit the values of the fields that are displayed in the current view, from yaml or defined as property:: (like metaedit and some others plugin offers)
If you want to find good UX for editing value of the fields maybe the way that Kanban plugin is doing this might be a good start (at least for a board view)? After hoovering over the text field 3 dots and "more options" became visible and user can make changes
For me having optional one folder for creating new files is sufficient, I can move them later to other folder (so the folder where new files are created might be called "project inbox" (in the GTD sense) and be defined both for dataview and folder-sourced projects;
I also think being able to assign a single folder for new notes is sufficient. I often use the vault root folder, but it can also be any other folder within the vault.
It will be great feature! I need this.
I have folders Inbox and PDB. And I want to use dw query in projects to combine notes from two folders and create new notes Inbox. Vote for this! :)
@marcusolsson maybe you can use settings from Obsidian? I recently use this:
const Folder = this.app.vault.getConfig("newFileFolderPath")
I want to make to sure that adding a note from within a project isn't just duplicating the built-in functionality. Users can already create new notes in Obsidian without using the Projects plugin, so this needs to add something more. Reusing the newFileFolderPath
would integrate well with core Obsidian, but I'm not sure what it would add?
To support operations like adding events in Calendar or cards in Board, we'd also need to the note to add the date or status. Right now, in a Dataview project, the plugin wouldn't know if it should add a front matter property, or an inline attribute.
Even if could figure that out, we currently have no way of knowing if a user has aliased the fields in their DV query. For example, if the user has a query TABLE date AS "Due" ...
, the plugin would add a property called Due
rather than date
.
I opened an issue in the Dataview repository for this a while ago.
As the person who started this thread I might comment on the above issues
I dont know if this is much harder to implement than in the path
based project,
but for me UX might be really simple and it might be almost the same as in the path
based project
Users can already create new notes in Obsidian without using the Projects plugin, so this needs to add something more. Reusing the newFileFolderPath would integrate well with core Obsidian, but I'm not sure what it would add?
Even if could figure that out, we currently have no way of knowing if a user has aliased the fields in their DV query. For example, if the user has a query TABLE date AS "Due" ..., the plugin would add a property called Due rather than date.
the decision here might be to allow only new files that will be created from the template with predefined paths per template
To support operations like adding events in Calendar or cards in Board, we'd also need to the note to add the date or status. Right now, in a Dataview project, the plugin wouldn't know if it should add a front matter property, or an inline attribute.
The field in the first iteration might be added to front matter proper
Basically what I proposing is to incoporate some elements of "QickAdd" workflow to the dataview project, my example use case:
Currently sometimes I have notes from meetings, zettelkasten type notes, literature notes (coming from Zotero), milestone tasks in separate folders, but all of them are tagged with unique project tag with I can query them using dataview to one table or one project
Would be great for such projects:
Basically solution would be to add some elements of QuickAdd workflow inside dataview type projects so it will be on par with "filepath" type of projects (the author of the plugin might say 'use quick add plugin in addition to achieve this so I dont need to implement this' but I think there is still much value in adding this possibility to Projects
)
if the user specify wrong template or wrong path, it should be the problem of the user, this addition of features to the dataview project might be flagged as "experimental" and "that user is responsable for ensuring proper templates and dataqueries" and not enabled by default, only if user change the settings to not confuse the users
I dont know if this is much harder to implement than in the path based project, but for me UX might be really simple and it might be almost the same as in the path based project
While I'm confident that we can figure out the UX for this, until we've resolved the Dataview issue I mentioned, we'd need to reimplement (non-trivial) parts of Dataview to solve this. Preferably, I'd like to accomplish this using Dataview's own developer API.
Path-based projects don't have the same technical limitations and, like you say, it would be pretty straightforward to add the support.
Currently dataview query is only read only. To have more flexibility and limitation of it one solution is to allow the user to define a folder path where new files might be created.
It should be user responsibility to ensure the files appear in the query after creating (maybe via template), opening the file from plugin just after creating or adding the path to the dataview query.
This might be marked as experimental as first to not confuse the users.