But the circles look like radio buttons, actually…
Tracker does work with the “Checkbox” boolean attribute. Please have a look at the Extra attributes section of the filetypes etc. workshop of the user guide. To quote the essential parts concerning a boolean attribute:
Boolean for binary data: 0 (false) or >=1 (true)
- Checkbox - Can be used to show either one of two symbols, see Special below.
- Special - Defines the two symbols used for a checkbox display. For example, “xo” will show a “x” for all values >0 and “o” for 0.
So, instead of the “x” and “o”, you can scour CharacterMap for suitable symbols.
The nice thing is, that this is on a per attribute basis. You can create one bool attribute that shows the special characters “x” and “o”, and another showing an empty and full circle, or checkmarks or anything else.
To illustrate:
Note: To see the changes, you’ll have to hide and re-show the boolean attribute in the Tracker window.
2 Likes
Thanks again Humdinger, should have read the User Guide 
Booleans will always be BCheckBox in the new Attribute Editor I’m toying with - I want to edit tags, description etc directly in ShowImage (code is dynamic and will work for MediaPlayer etc as well):
Width / Height should not really be set as editable in FileTypes…
Btw, you found a nicer symbol for a radiobutton true value. I could not find the code for this symbol, do you by any chance remember it?
It’s in the “Geometric shapes” of the Noto font.
◉ = \xe2\x97\x89
○ = \xe2\x97\x8b
◎ = \xe2\x97\x8e (fits maybe even better?)
2 Likes
I just came across an index_server add-on in Haiku src/add-ons/index_server but it won’t compile since it’s referring to a non-existing include file audioproperties.h. Seems to be dormant, too, last update is from Oct 28, 2010.
There was a CLucene analyzer for fulltext search, and an audio tags analyzer.
Would be great to reboot and extend this effort, any updates on this endeavour?
Well your research accurately shows the current state. This is clearly not on the TODO list for Haiku R1 and we are focusing our efforts on more important parts (web browser, drivers, printing support, bugfixes, …)
As usual if someone starts work in this area we will review patches and accept them if appropriate 
1 Like
I understand, but I’d really like to see this in R1.1 as it enables a variety of applications and thus is really more a central infrastructure service (I’d certainly love to contribute as it directly relates to my side project I’m now actively working on, finally).
Maybe put it in /attic, unmaintained or at least update the README until it gets more attention, as anything in the haiku/src tree should build imho.
Well, “attic” is innapropriate for things that are not complete yet, and in general this is not how we do things mainly because it makes the history more annoying to track with git when files are moved around.
As I said, if you want to work on it, we accept patches, and if it works well enough we’ll include it in the system.
Sorry – I’m late to this discussion, not having been following the forum recently, but I guess i should chime in!
Does nobody know about ‘xicon’ any more? An app that I wrote in the age of BeOS to run shell scripts from icons. I’m not sure what percentage of my day uses it, but it’s large! My Desktop is littered with xicon icons, from simple ones I just click on to read the BBC or fire up Ruby to ones that you drop files on to process them, such as ‘ShowAttr’ that uses listattr and catattr to display all the attributes of files.
I suppose it’s my fault that I’ve never pushed to get it into HaikuPorts – which seems the only way an app will ever be visible to the world. It’s just that the old zip file is still perfectly adequate!
In any case, here’s its current location:
http://goodeveca.net/beos/xicon.html
Back to the topic of photo attributes, I even have a script that uses ‘exiftool’ and my ‘gadgeteer’ (which someone has added to HaikuPorts) to edit the exif data of a file and add a “Comment” attibute (which was all I wanted). I could pass this on, but it’s rather tailored to my own needs.
3 Likes
So now it’s my turn to say sorry for not getting back to you - xicon would make a lot of sense here and more manageable for a larger collection of scripts. Gadgeteer also looks really interesting - I tried to build both on my x64-install of beta2 but sadly didn’t manage to get them to build (the haikuports-recipe for gadgeteer is for 32bit only).
Ackk – yes. I suppose there might be problems switching to 64-bit. Not sure what they would be, though, as i have little interest in switching myself. My Linux Mint partition is 64-bit, and I notice no difference except that apps from my old 32-bit Ubuntu won’t run!
Do you have any hints as to what fails? I suppose it might just be the newer gcc. They’re both gcc2. Gadgeteer uses libYAML, which I just built in as a static library. That would have to be rebuilt too. I’ll have to look at the HaikuPorts recipe, (I didn’t create that.) When I get a chance, I’ll see if at least they compile with the new gcc.
For xicon, I just get a few undefined references to “operator delete” and “operator new”, as you say may be related to gcc version but I have no clue…
You should use g++ instead of gcc.
1 Like
Hah! (and Ha Ha…
) I had just tried to compile xicon with gcc8 (setarch x86 in 32-bit) and got exactly the same error! A quick visit to the mailing list and Waddlesplash sorted me out.
In the Makefile, just add a term to the LIBS= line:
LIBS= $(STDCPPLIBS) be
Try that, and see if that’s all 64-bit needs. (I got a couple of warnings, too, but I ignored them for now.)
Thanks!
1 Like
What’s the (specific) difference? (Xicon just builds with the Makefile engine.)
Well, that was embarrassing (not having a clue why new / delete gave errors 
), but YES now it compiles and runs just fine! Thanks a lot!!!
When you link using g++ instead of ld, it adds the C++ libraries automatically. In the context of the makefile engine, the change you did to LIBS is equivalent.
Index Server itself build, index_server will not work, from what i recall, because it will index the own index recursively So excluding files & paths are missing (and therefore a setting gui and backend)
you tried to build all addons there, the audiotags plugin is broke because i think it requires taglib (audioproperties.h Source File (TagLib)) so you need have installed Haiku Depot Server (i guess this should be added to the jam file somehow… but i am a noob there 
1 Like
So I guess my question is, then, why isn’t the Makefile Engine doing this by default? It’s supposed to take the hassle out of things, after all. Where is ‘$(CXX)’ that it uses defined? Actually it looks as if it always uses $(CC) for LD, anyway.
And are there any docs? Anywhere? Can’t find them.