I’ve discovered that the People app is working really great with the FileTypes preference.
Example below :
It would mean we could create a kind of generic people app for any kind of data under Haiku ?
recipe, books, etc ?
I guess that is the idea! 
I remember a schedule / todo application for BeOS where each “To-Do” element and “Schedule” appointment were a file with different custom attributes (in a similar approach to Mail and People file). I do not remember the name, but was something like “BeOrganized” or something like that.
The tracker is already able to do that : display and edit the attributes depending on the mime type 
So having the same via an application like people should be possible I think (ie a more generic visualizer/editor app for the data).
you may want to read about SEN on the forum …
Already done But I will only look at it when it’s pre-released
I had an app like that once. It was called FreeVerse
I should look at that code again some day.
Must have been this if you remembered the name right: https://web.archive.org/web/20111212144646/http://bebits.com/app/3248
There’s an old binary package of it in the BEOS5PEWARE archive.
I’ve got a first “dirty” app with drag/drop to verify it’s possible to mix various mime types and adapt the input fields.
The concept is really powerful, so let’s take good habits and use fresh new app on Haiku.
I will start to write it from scratch, it will be a good exercise for me… and might be useful
Note : the People app is missing drag/drop so I guess it has not been updated for a long time.
3 different MIME types displayed which confirm initial idea for such app
Still in draft version, many things to learn, and GUI with Layout not so easy to write.
Looks good so far,but I’d probably use a BGridLayout to have all input fields nicely arranged below each other with the same size.
You can use something like that:
AddChild(BLayoutBuilder::Grid<>(B_USE_HALF_ITEM_SPACING, B_USE_HALF_ITEM_SPACING)
.Add(textcontrol1->CreateLabelLayoutItem(), 0, 0)
.Add(textcontrol1->CreateTextViewLayoutItem(), 1, 0)
.Add(textcontrol2->CreateLabelLayoutItem(), 0, 1)
.Add(textcontrol2->CreateTextViewLayoutItem(), 1, 1)
);
Unless you have some reason to do this (it’s rarely needed), it’s better to do BLayoutBuilder::Grid<>(this, ....
Can you point to documentation regarding the difference between these two things and the advantages?
I have seem this pattern before but have always been confused why this was used.
One of them creates a new view and adds it to the parent view.
The other one directly takes a view and add widgets to it.
So if you do this:
BView* grid = new BView(...);
grid->AddChild(BLayoutBuilder::Grid<>(...));
You have two views, one inside the other.
But if you do this:
BView* grid = new BView(...);
BLayoutBuider::Grid<>(grid, ...);
You have only one view. The layout builder will jsut attach a layout to the existing view. You use less memory for the same thing, your window is easier to debug, etc.
Thanks for pointing me to that.
I have used the AddChild variant because that’s what’s documented at Laying It All Out, Part 1 | Haiku Project which is slightly outdated (but still extremely useful for getting started with the Layout Kit) anyway.
Now I’ll have to rewrite my app again to use the other way 
It’s starting to look as a graphical generic File Attributes editor, right?
If it can support in an user friendly way the edition of attribute of complex types, like image (for Person image attribute, for instance), but also support attributes “flags” to allow an attribute to be present only once or multiples times, I’m all for it.
The current FileTypes preferences don’t handle the complex data types AFAIK.
The application will rely on it, so until there’s an enhancement on the preferences app in Haiku, the short answer is no
Doesn’t matter yet, as some app can register its own file type with its own attributes list, including attributes of type not supported currently by FileTypes preflet.
But, indeed, for more flexibility, FileTypes preflet may need to be improve to allow user to add attributes of some more complex type
I’m a bit confused, these DVD attributes would normally be on a file representing that DVD. Why are they here “on their own”? if both cases exist that may confuse a bit.
The main usecase for these “indexed” attributes is not that the People app can view them, but that the mail app can!
You can habe People files wherever you want on your filesystem and Mail will still find them and let you shoot them an email!
In the same vain a dvd player software would be able to find and list your dvds based on their dvd title for example.
I’m not trying to critizise your idea, but curious what you want to use this for.
Maybe we should not focus on this DVD attributes use case.
The idea behing this application is that as the MIME types attributes attached to a data file can be visualized/edited (when possible) under the Tracker, it could be nice to have the same in one application.
For instance in today’s audio MIME type, the below attributes are available. Some of them are editable via the Tracker and so this application will allow to have an easy way also to view/edit all attributes :
