Sourcecode

I just wanted to let you all know that I will be releasing the sourcecode to several of my old projects, including webwidget and nanoplayer soon. As I don’t do Windows any more the code will be released as-is under the GPL v3 license.

The code will be published on my website, noccy.com as soon as I manage to package it properly.

A call to arms

bC-ng need more developers in order to take off. Since I have dropped Windows there is a need for people with win32-skills to develop the Windows-specific parts.

The plan right now is to build abstractions for win32 as well as x11 and then make the shell platform- agnostic.

If you think you could be of assistance, throw me a comment and make sure to include your email address.

Revival

It’s been a while since I have updated this blog, but it’s about time. The reason is as I have written earlier that I am currently using Linux rather than Windows, and thus development of a Windows shell is a bit far off for me.

However… I have been approached by Pitkon and asked to join in and help bring bb4win back on the map, and the way I can imagine doing this is by picking up bbClean-ng again, pretty much where I left off. This includes making it compile natively on both Windows and Linux, by abstracting the API enough to allow for native code to do the magic voodoo while the actual shell is oblivious about what is underneath. Creating this bridge could help unite the *boxes and take the concept to the next level.

The only thing that is working against me there is the fact that Xfce is awesome enough to use and enjoy. But then again, writing a cross platform shell/wm is definitely a challenge worth taking on.

So, who would like to contribute?

Dead or not dead?

I’m sorry for letting this blog linger as long as it has. As I am a multi-tinkerer none of my projects really are dead. That’s the up side

The downside is I have switched to Linux as the (d)evolution of Windows really did nothing besides pissing me off,  and as I don’t have a Windows build system any more, development has kind of stopped.

All the source code is still available, and I do not mind helping out and assisting if someone else is interested in taking over the code writing duties. The alternative would be to rewrite it as a truly platform independent shell replacement.

Drop me a line if any of this sounds interesting

bbTK in bbClean-ng

This morning I’ve done some poking around with the multi monitor functionality. There are quite a few things about bbClean that annoys me when it comes to the multi monitor aspect, such as windows on the secondary display not being listed in the leanbar and how activity takes place on the display with the focused window. bbClean-ng will definitely have more powerful multi monitor support than the previous versions.

I also did the first attempt at linking bbTK with bbClean-ng, as in just spawning a window on the desktop. Right now, no widgets whatsoever are implemented, so the window looks a bit dull and boring, but at least the window spawning works

bbClean-ng and bbTK

Left to do now for the support libraries is essentially to wrap the rendering code up in bRender, add the widgets to bbTK, and then start putting the pieces together.

If anybody is interested in giving us a hand with either of these parts, drop me a mail or so, and I will get back to you

bbtk and brender

I just commited the initial version of bbtk to the repository. I also moved the brender folder into the libs folder, the same as for bbtk, and there’s a good reason for this.

Both bbtk and brender are supposed to be somewhat independent. Obviously, bbtk will depend on brender, but these two modules will be built as standalone linkable modules. This will allow a developer to write an application or a plugin using bbtk to create and manage the UI, while depending on brender to paint the UI in the system style, or (in the case of the application running completely standalone) a custom style.

bbtk is progressing quite well. The current code for bbtk compiles both as a static and a dynamic library, and the test code makes use of both these to build two applications; one that uses the statically linked library, and one that uses the dynamic one (make sure to copy bbtk.dll to the test folder after building it for this version to work). No widgets or events are in there yet, but in time it will support a fully custom rendered interface with arrangement components and those lovely *box styles.

The goal is to have the new leanbar based on bbtk, but as the library might not be fully developed by the time the first milestone is released there’s no guarantee that it will be included in this.

I do however have some concept art that I will post here soon. It just needs a bit of additional work.

Repository moved from SourceForge

The changes that SourceForge has made to their design lately added with the utter slowness of the site and the repositories, we decided to move the entire project to a Trac site, running on Apache with SVN and Doxygen support.

This should hopefully give us a better platform for maintaining the project.

That also means that the tracker has been moved.

The new address us http://sophia.eani.net/projects/bbclean/

Status update and scripting

It’s been quiet for a while now, but that doesn’t mean nothing is going on. I’m currently experimenting with the first real abstractor, in order to develop and streamline the abstractor API. This will be the scriptrunner abstractor, that will be able to load script files just like any other plugin.

As for what languages that will be in there, the initial language will most probably be Lua. I suppose making a scripting plugin to support JavaScript wouldn’t be that difficult either, basing it on Mozilla’s Spidermonkey. And, with some luck and help from the community we will hopefully get to see Perl4ng, Python4ng, TCL4ng etc

To dive into the actual logic, scripts are loaded by scripting plugins. These plugins contain everything that’s needed to load a script into memory, execute functions in the script, and have the script call functions in the core. These plugins (which are not compatible with bb4win) are in turn loaded by the scripting abstractor. The scripting abstractor will be an integrated part of bc-ng, but it will also be possible to compile bc-ng without any scripting enabled.

Quick summary: Scripting Abstractor is an actual bbClean-ng core plugin that loads Scripting Plugins and also helps by resolving Scripts to the proper scripting plugin. From there on, events are passed through the scripting abstractor to the plugins, and function calls are passed from the plugins to the abstractor.

Any comments on the scripting subsystem can be posted here

New logger

Logging is probably the most essential part of ng right now. With no visible interface, all the feedback is sent to the log. Previously this was done with a mix of a custom logMessage method as well as dbg_printf, but that’s about to change. Elite just commited the new Logger code that uses streams to handle the output.

This should allow for neater code, as well as allowing more complex messages to be logged with a minimum effort.

A lower level logging will also be implemented that in essence captures the start and stop times of events into a log file as well as some event specific logging.

The bbTrace application displaying an ad-hoc log file

The good thing about this is that it allows us to streamline the code, but also that it allows us to easier track down bugs and crashes occuring at startup. If a user experiences a crash, the trace log has taken a snapshot into the belly of the beast, and will hopefully be able to provide some insight in what’s happening and where to look.

The first signs of an actual desktop

The work on the DesktopService has started. The first breakthrough came after tracking through the sourcecode for bbClean, and starting the DesktopService will now spawn an initial desktop, and render the windows desktop wallpaper in it. The desktop menu, however, hasn’t been added yet.

Progress progress. And a huge shoutout to everyone at #liquidfm@mixxnet who had to cope with my mumblings tonite as I tried to crack the DesktopService If you haven’t already, tune in to Liquid.fm – the only internet radio you need

I would post a screenshot, but as it currently consists mostly of debug output in a console window, it would probably not be the most exciting thing to put here. So instead I’ll settle for a quick recap of the project.

The shell itself is a complete rewrite of the bbClean shell. As the code just became too hairy to handle (after years of forking and developers leaving their footprints in there without adding any comments) we went ahead and decided to simply scrap it and start over. And do it right from the beginning.

The essential shell components are refered to as “Services”, and these can be started and stopped as needed from within the shell. At the time of writing, two of these services are at least partially implemented: the TaskService which is responsible for keeping track of the running tasks (i.e. the little neat buttons that show up in your Explorer taskbar) and the DesktopService which handles the desktop and all your virtual desktops. These two services are currently functioning at a basic level. Keep in mind that we are talking about the internals right now, so there are not yet any visible interface. Just the logic behind it.

The remaining services include the TrayService which will do pretty much the same thing as the TaskService, but with the system tray (or the “System Notification Area”, you know the corner of your screen where all those icons appear), the PluginManager that is responsible for loading the plugins (that was a huge simplification, more about that at a later time) and the ConfigurationManager which loads your settings and allow the other parts of the shell to access them.