Maybe I just also didn´t understand the idea, but wouldn´t it be more organized to extend Tracker´s edit option to edit al these attributes ? Then the task of editing attributs would stay centered in one place.
The Tracker’s Get Info window Attributs tab could be improved, maybe, to allow not just viewing the file attributes but also editing them (add/change/delete) attributes.
Sure but a generic standalone app can be handy anyway.
Also if we want people to contribute with native apps, they have to learn few things about the system first. A simple thing like that is somehow a good start.
The problem with extending tracker is that attribute data can be basically arbitrary. It could just aswell be a PNG image, but clearly there shouldn’t be a png image editor in tracker.
I think tracker should have the ability to edit numerical values, strings, and support the rest with drag and drop.
For anything more extravagant a native application is a better choice. : )
It’s already possible to update the attributes of a file from the Tracker
However :
- You will not be able to edit all the attributes of the files easily because the tracker is more a « view » than an editor. Why ? Because you need first to add them one by one in the view of the folder before editing these attributes (not very handy)
- I’m not sure we can distinguish today an editable versus a non editable attribute in a folder’s view
With a dedicated app you can :
- modify all the attributes of the file quickly (moving from one to another attribute with tab key) and make the saving when all your attributes are modified
- see the non modifiable attribute quickly( greyed out)
- see all the attributes by default (that’s not the case of the tracker)
- edit the attributes whatever the mime type is : that’s why I was talking about a « generic » people app
Sure but a generic standalone app can be handy anyway.
I fully agree.
In particular because moving such thing in the Tracker code could take way more time and effort, because Tracker has way more compatibility surface to manage than a new standalone app could ever have.
The People app support an image (which is stored in the file content in fact, not as an attribute of that file), but doesn’t include an image editor. It does only support “editing” the image by drag and drop and a small “delete” contextual menu.
The editing functionality, ideally, for a usecase as this should be in the “File Info” Dialog. and not only in the main view
Tracker also show, for a file, the whole list of its attributes (with values) in the Get Info window, Attributes tab.
But you can’t edit the values, nor add/delete attributes in that list.
So, a standalone, graphical, File Attributes app is fine and, indeed, quite missing as currently if one wants to have the full power on any file attributes, he has to resort to the command line tools:
Good day. Thank you for your work. There is a question with the implementation of People files, if they are transferred to the outside world via mail or messenger, the attributes will disappear. The same with To-Do, notes, etc. Even if you synchronize the People folders between 2 Haiku machines, for example, via syncthing in the future, will the attributes be transferred correctly?
If you compress files first and you’re using right compressing tool, they keep their attributes. Of course, you also need to decompress them on a file system that understand them. So actually only bfs. But while compressed they can be put on nearly any file system.
So normally, it should be possible without big troubles.
If you use our build in mail app it will attach the attributes in the mail aswell, but some mail servers reject this as suspicious.
One idea was to “project” the attributes data into the file content too, following the vCard file format. That way, People files will be also vCard standard compliant files.
At time, vCard wasn’t supporting officially an image “field”, but I just saw that it’s supported since, even embedded, via a Base64 encoding.
Could be an enhancement to People to write the content part of People file as vCard standard. That way, they will be platform interoperables.
wouldn’t it be nicer to throw this into a translator when sending it over? this seems quite unexpected for tools and could easily de-sync
You’re right, as these attributes can be edited at any moment outside People app too.
Yes, a People ↔ vCard translator make sense.
On that topic, it was part of this GSoC project long time ago:
AFAIK, it was never integrated into Haiku source code, but maybe some parts can be reused to make a translator add-on someone.
Actually, you can find on haiku depot a vcardpeople package providing a small utility to convert any People into a vCard file.
It’s not transparent as you have to manually use the tool to convert into a vcard file before addint this file to your mail, but it’s a start.
An upgraded BeMail app that would propose, on People file attachment, to translate it into a vCard, via a translator add-on for instance, will be way more user friendly for sure.
why not abandon the format People and go straight to vcard?
Vcard doesn’t make sense to use. With the people format I can write a mail and it will suggest the user directly based on a filesystem querry, with a vcard this isn’t possible.
if I send a Person via messenger, what can he do with it, how can he view the contact? The question is, what comes first, to isolate oneself from the external world and live only in the world of BeOS and Haiku or to have communications with the outside world except Haiku?
Just like I wouldn’t send an ArtPaint document to non-Haiku users, I wouldn’t send a Person file to them. When I know my interlocutor doesn’t run the software needed for some file, I convert it before sending, if possible.
A native messenger app could recognize a file has BFS attributes and offer to zip it up before sending or use a protocol preserving attributes, like the Muscle server used by BeShare.
Suggesting we shouldn’t use BFS attributes because non-Haiku users can’t deal with it ignores the purpose of creating our own OS.