Hello World.
It’s been almost 3 weeks since my last update. The first evaluation was complete, I’d like to thank Haiku for recognizing my work so far. And here’s an update on what I worked on for the past few weeks.
Looks good, but a little bit chaotic too for me 
I had hoped the super prefs something is the one in a window can serve, all preferences in a window select and adjust able.
Do not misunderstand, the work I appreciate and certainly the idea behind
it is a good, but I do not currently see any distinction between a
preferences menu which I open and this super prefs window.
I’m not entirely sure. It looks like the actual prefs applets are still separate programs. This is just a different way to access them. So we could have both the existing setup and this as a separate option under Menu | Applications for a while to give existing users a chance to get used to the idea and shake the bugs out.
I think the labels should be placed under the icons as this would be very similar to system prefs found in Mac OS, Windows (Control Panel - Classic View), and GNU/Linux (regarding GNOME and KDE).
Interesting, how the new GUI will react to additional preferences’ apps thrown or symlinked to the “Preferences” directory. When I was developing the “Eventual” calendar manager application, I created a separate preferences app for it, which was, quite obviously, located in the “Preferences” directory. Do you provide an API to “register” the preferences applet under a specific category?
I assume the new GUI should recognize additional, non-system preferences’ apps as soon as they’re placed in a correct directory. (It’s pretty easy to achieve, even on-the-fly, — just set up a watcher with a BMessage notification when the new preferences app is running).
[quote=“hitech, post:5, topic:5880, full:true”]
Interesting, how the new GUI will react to additional preferences’ apps thrown or symlinked to the “Preferences” directory. When I was developing the “Eventual” calendar manager application, I created a separate preferences app for it, which was, quite obviously, located in the “Preferences” directory. Do you provide an API to “register” the preferences applet under a specific category?[/quote]
Good point, I also have a separate preferences app for Einsteinium. Even if there is an API or attributes used for defining a category, if that is not used by a preflet it should default to the Uncategorized section.
Yes it should! Right now it’s all hard coded but anirudhm has written that he is looking into using attributes or some other means for the preflets to categorize themselves.
I plan to try this out and make comments once I try it myself, been busy getting my PC rebuilt after a power surge took out my PS.
[quote=“Perelandra0x309, post:6, topic:5880, full:false”]been busy getting my PC rebuilt after a power surge took out my PS.[/quote]Well, wishing your PC a quick and painless recovery!
+1
I have quite a few such apps on my repo.
this is gorgeous
Thanks for your comment. 
It now supports non-system preferences too, yet to provide support for custom categories.
Your weekly report#5 isn’t appearing here yet, so I am just making this comment here before I forget. The Einsteinium preflet wasn’t showing up for me, then I realized maybe it was because I have my package installed in /boot/home/config/packages, so my preflet executable actually shows up under /boot/home/config/preferences. Don’t forget to check that path as well.
Also, with no custom preferences found the box still showed but was empty. Would be a good idea to hide that if there are no custom preferences to show.
Great job so far! I have a few other comments but I will wait until the weekly #5 thread shows up.
One could use BPathFinder to locale all the preferences directories on the system, I think (system and user, packaged and non-packaged). Then enumerate all of them for apps to show.
