A new OBOS-Newsletter is out: In this Issue you can read about an “OBOS App_Server Overview”, “How to Write a BeOS R5 Printer Driver” and “Against Directories”.
OpenBeOS Newsletter; Issue 51 is Out
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I’ve always liked the idea of publishing an in-depth, technical newsletter, and its nice to see the OpenBeOS developers continue this tradition.
And I agree with the “Against Directories” article. Live-query folders are the wave of the future.
though i am not sure of some of the ideas presented in the newsletter, i am a fan of Queries. A few apps under Be (like Tracker / SoundPlay / ImageShow / etc.) treat Queries as directories already. personally i thing this is enough to accomplish the type of flexability that OBOS (GE) was shooting for.
the problem is that developers have to explicitly write in code to ‘fake’ a query being a directory. (not difficult, just read in some attributes and build a BQuery, then your provided with the similar interfaces as BDir)
first suggestion would be to add this into the base B* api. So it become transparent to the developer, thus making it transparent to the user.
I don’t think there is a big need to abandon dir structure at all. as for most static data (/boot/system) its not needed.
i use queries to sort, find and organize my images / mp3s / text data / etc, though, all of this data is also stored in a overall hierarchical static dir structure, providing multiple search methods.
the second addition would be thus to add the ability to query based upon Dir structure.
I think with the integrated Query and Dir searching queries (along with lots of apps and examples for users) queries could be presented to the users as a extremely useful organization tool (which it IS
)
—
not that i have a opinion on this or anythign
The way BeOS (and OpenBeOS too, now) seems to handle things impress me with it’s elegance and it’s “DUH!” simplicity.
You can just tell by the way they communicate that when they do release their beta and final products, they will be *impressive*. Call it a lucidity of thinking if you will..
I think that if they can run on a good sound card and an ATI/NVidia Video card, then the rest of it to go, then, they could have a “build your own OBBox” kind of How-To on the ir website.
that should hold over the masses until more hardware support gets built in.
all nvidia and ati cards run on BeOS, just we don’t have any hardware opengl…it might be in r2
BQuery just like BDirectory derive from BEntryList.
It’s just about using the baseclass where BDirectory specific things aren’t needed, that way most of the code can be made query aware.
if you get it into r2, then I hope that r3 has an OGL accelerated desktop like OS X and Longhorn will have.
I tell you, OBOS is gonna be the OSS desktop of choice.
Rayiner:
And I agree with the “Against Directories” article. Live-query folders are the wave of the future.
Live-queries to complement the static directories, yes; but to replace them completely – that’d be throwing out the child with the bath water. Directories didn’t survive for 50 years out of pure inertia alone.
As long as we can get proper hardware support from the drivers in time, it is very likely that OpenGL accelerated desktop will make it into r2 (I would be the one working on it). Of course, I can’t make any promises since it is still too early to tell.
> BQuery just like BDirectory derive from BEntryList.
agreed, however you still have to manually pull the Query from the Attributes and build the BQuery in the first place.
would be a nobrainer if it were at the same level as BDirectory. Maybe derived from BStatable with the addition of the IsQuery() method. So you would recv the BEntry/BNode (as a BQuery) from the system the say way any other dir/file (don’t recall if its a BNode or BEntry right now, belive that BDir is Node/EntryList, however it all would get pieced together and would make it so the query-file would appear as a direcotry to the StorageKit API)
ie: Zero work for developers to magicly have query support
Well, Michael Phipps managed to win me over to the queries idea in that I finally believe they are a true win over directories and linking. I’ve never actually used queries before though I’ve been using BeOS for several years now. A well-factored directory structure and symlinks do the trick for me.
If the OBOS people do eliminate directories from BeFS, I hope I wouldn’t have to write a query just to select a file to open. Also, a hierarchy allows you to quickly narrow the search space so you can use simpler queries. Given a suitable hierarchy, this could lower the cognitive load when the user goes to write a query. This would be especially useful if queries were as widespread as Michael is proposing, at least for people like me that think in terms of hierarchies. (Yeah, I’m a programmer.)
Eugenia, could you please change the story icon to the more appropriate “BeOS” one?
Thank you.
-Chris Simmons,
Avid BeOS User.
The BeOSJournal.