Settings - ignore patterns

[crackcomm]

I am always having errors in Checks because of double definition in .rs.fmt files.
It would be nice to have a .gitignore like feature in settings.

I wanted also to ask why is .art directory necessary? Could it be just .art.yml file?

[crackcomm]

I can do some work on it.

[vitiral]

I'm curious, what is a rs.fmt file?

Yes, there should probably be an "exclude pattern" or something along those lines. I purposely avoided the .gitignore style since I personally used to find its use of paths confusing (all paths are relative to where the .gitignore file is.

Down the road, I plan on putting more data in the .art directory, including a data/ folder for faster loading of artifacts and maybe an sql-lite database or something for a beter web-server experience. I also want to keep it open for plugins to use (I don't want to litter .art.toml with stuff).

[vitiral]

Also heads up, but I will be doing a complete redesign of the loading piece of artifact over the comming month. Not that this should stop this feature (it's a pretty minor one), but just thought you should know. The current code base is a poorly designed and hard to read mess IMO.

[vitiral]

also, you COULD add all your .fmt files to the exclude_code_paths setting. Not that that is in any way a fun thing to do...

[crackcomm]

.rs.fmt files is left by rustfmt and I can't figure out a way to disable it.

I agree, assets directory can be used in the future but it could be configured in settings file too.

I love this tool and I am not sure I would change too much. I thought about creating this kind of tool before or creating my own - or rewriting this code base but now I can't see any benefit in that. We just need to few really small things.

See for example, the biggest bug for me, from the user experience point of view is this:

I can't believe how many times I clicked on 🛈 and got redirected. More than that - when you do, you have to "go back in history" twice.

When you create new artifact - you should be redirected to it, I think so.

Now I got used to it - but first when I tried artifact I struggled to even save document because the button was not visible (it is on navigation bar).

Some other thing that kind of strikes me as not fairly implemented - is when artifact has a single part. When part is implemented - should the artifact be 50% or 100% like it is now? There is no way to specify a single dependency (inside the scope of the project). The dependency could be filled - that would mean 50%. Let me know what is your motivation on that decision or is it just a bug.

Other than that - maybe I would place List link in navigation before Help.

[crackcomm]

It would be also useful to have the possibility of managing parts (not just partof).

This is all the feedback I can provide right now :)

EDIT: Please think about not using SQLite database and using something that could be revised on GIT.

[vitiral]

for rustfmt leaving backups, this is what I use in my justfile:

fmt-rust:
    {{pre}} cargo fmt -- --write-mode overwrite  # don't generate *.bk files

hopefully that helps :)

[crackcomm]

Thank you :)

[vitiral]

There are definitely issues in the web-ui. I am completely new to web development and basically stopped once it was working and haven't gotten back to it.

or rewriting this code base but now I can't see any benefit in that. We just need to few really small things.

Well, I am going to be redesigning the whole code base using flowcharts (using the tool itself), so if you really want to get involved in rewriting it that would be much appreciated! There's going to be a lot of work 😄

Some other thing that kind of strikes me as not fairly implemented - is when artifact has a single part. When part is implemented - should the artifact be 50% or 100% like it is now? There is no way to specify a single dependency (inside the scope of the project). The dependency could be filled - that would mean 50%. Let me know what is your motivation on that decision or is it just a bug.

This is a tough one, but the current behavior is intended.

The basic idea is that when you are designing a big feature its completion will be completely determined by its subfeatures. This is most obvious for REQ, since you literally cannot directly implement it.

However, I see your point. To aid in this, I am now implementing sublocations. So if you had a feature (SPC-foo) that had a large part as a separate spec (SPC-foo-bar) but also had two minor parts that were implemented directly in code (SPC-foo.baz, SPC-foo.lab), then those would show up as unimplemented if they were not implemented. You specify sublocations by just having [[.baz]] [[.lab]] anywhere in the text of your artifact, and then link with #SPC-foo.baz. See #186

[vitiral]

Let me say, I'm not sure the best way to balance all these pieces and am open to feedback. I think the sublocations are going to be the best way to do so, but I really don't know. Part of me is unconcerned since the "completion status" piece of artifact is a pretty minor feature IMO. It's nice to have, but its not the main attraction.

[vitiral]

(Being able to link code in the first place is the primary feature when it comes to "completion")

[vitiral]

Also on the web-ui stuff -- if a bug isn't open feel free to do so.

[vitiral]

Would moving the info boxes to be all to the left prevent acidentally pressing them?

[vitiral]

EDIT: Please think about not using SQLite database and using something that could be revised on GIT.

the SQLite database would only be for speeding up the web-ui and caching some of the data when re-running artifact (i.e. files that hadn't changed would not need to be reloaded). All actual data would still be stored on the local harddrive (the SQL db would be synced periodically to the filesystem, just like it is now).

[crackcomm]

I completely agree with you, it's not really an issue - but could be a feature - I think sublocations provide that.

Would moving the info boxes to be all to the left prevent acidentally pressing them?

Moving the info should be enough for a fix - but the select could be a little bigger too.

The UI is really good - I wouldn't want to change it entirely.

When you will be starting the work on redesign make sure to let me know :)

[vitiral]

When you will be starting the work on redesign make sure to let me know :)

Haha, will do :)

Moving the info should be enough for a fix - but the select could be a little bigger too.

What is the "select"?

[crackcomm]

I meant the html select field.

[vitiral]

See #198 for the info boxes.

I purposely shrunk that, but can't remember why. I'll have to look into it again.

[vitiral]

and #199 for the select field

Edit: @crackcomm I moved your comments there

[vitiral]

@crackcomm I've started working on the redesign here if you are interested:

https://github.com/vitiral/artifact-data

[vitiral]

probably implement globbing with: https://crates.io/crates/glob

Also see the dicussion in #210 for some possible settings names.