Sunday, March 1, 2015

A Java icon for Haiku

Today's project was a Java icon for Haiku. I tweaked my earlier version and made the steam a bit more opaque and removed it from the 16x16px view. Hopefully the devs like it.

Monday, February 9, 2015

Some recent confusion and frustration for me

So this one is going to be a little long, and while it might sound grumbly, I'm just venting a little frustration while thinking out loud about possible improvements to the ecosystem of a community I love.

I've been doing a little tinkering with Haiku recently and ended up wanting to submit some patches to BeMines. This led to me stumbling across some slightly confusing bumps in the road.

The first one that caught my attention was hitting a wall with my BeMines development (on HaikuArchives) because of a compilation error and having to stop working on it, then finding out the next day that a patch already existed for it but was only being applied downstream as part of the build recipe on HaikuPorter. Thankfully one of the devs was around to push the patch upstream, to the very Haiku controlled repo where Haikuporter was pulling the source from to build it.

So today I'm digging around through HaikuArchives, HaikuPorts, HaikuDepot etc... getting a feel for what software is where, which patches may need to be pushed upstream, how the Haiku software ecosystem might be streamlined a little, etc. It feels like there is a fair amount of redundancy which can make it confusing for newbies to figure out where they should be going for their software.

For example, after some digging around I figured out that the Haikuporter page that comes up first on Google is not actually the correct site anymore, but there was nothing on that page telling you this, and I didn't figure it out until searching that site for "install" and finding a buried page that there actually pointed me to the correct page and let me know the site has moved to a completely different server/service. (I'd have been fine if I'd googled for "HaikuPorts" instead of "HaikuPorter".)

And of course if I'd gone to the front page I'd have seen the notice, but I had just followed the top Google result for Haikuporter and ended up very confused (as other people are sure to do).

This isn't the only such source of such confusion for Haiku. There's also the deprecated download pages that have a subtle disclaimer at the top saying they're just an archive and the actual page has moved to the new download page which looks basically identical. I've seen multiple people come in the IRC channel having grabbed a nightly off the outdated site...

I've even stumbled back onto the old one a few times myself.

I feel like the content from these pages either needs to be absorbed into the new location (like a link to a sub-page of the same site with older builds archived or something, even if they're actually hosted off-site), or seriously archived (zipped up and stored somewhere just in case) and the existing URLs killed or redirected to the new ones. There should be a single working source for this kind of stuff. Not scores of pages with little disclaimers tacked on here and there saying they don't work anymore or aren't updated anymore that redirect you to some other newer page where you hope you've finally reached the correct place. Following deep links from Google or the like is a good way to not realize you're reading archived or deprecated information.

So for Haiku software we have a number of options... HaikuPorts (with the deprecated and current pages) as shown above...

HaikuArchives, with two separate URLs; one for the software, and one that serves as a sort of index to it...

So if you add something to the main HaikuArchives, you then need to also be sure it gets added to the index on the .io site...

HaikuDepot (both the actual application within Haiku where you find software to install, and the web based front end to it to manage the software etc)... The Haiku Depot page on Wikipedia provides a nice overview of this relationship.

And then of course the other places still like Haikuware and BeBits.

For part of this I think the basic hierarchy is HaikuArchives to serve as our upstream repository for all Haiku software (not just that which doesn't have another stable home), then HaikuPorter which can pull from there to build the packages that then end up in HaikuDepot.

If I want to help work on some Haiku software, I don't want to run into these kinds of issues where I have to make sure I submit the changes to, and coordinate with, multiple places because one time one place might have a patch another doesn't, but another time the patch might be somewhere else and not at the first place etc...

Let's look at BeMines for example. These are the options I end up looking at for where to make my changes:

  1. - "official site" now(?)
  2. - had Haiku compilation fix patch not present at #1.
  3. - points to #1 as web site.
  4. - points to #8 as web site.
  5. - .hpkg here - points to #6 as web site.
  7. - several bug reports here - points to #8 as web site.
  8. (

With a little digging I settled on #1 as my choice of where to work from, but then of course I missed the patch from #2.

And that's just the software sources... not mentioning the community being split up between facebook (several different groups etc), google plus (several different pages/groups), the official site (where it is split between the forums, blogs, and article comments etc), IRC, the mailing lists, etc... or about how even development is split between github, bitbucket, itself, and private sites... and let's not forget BeShare, dropbox, etc.

On Facebook...

On Google+...

On the official site...

The first and last of those, the blogs and news articles, have their updates listed on the main page of I've honestly never really used the forum.

I suppose once someone is more familiar with the community then they know the best places to go etc... but for a newbie it can be a little daunting. There are sites, or parts of the official site, where I essentially never go... the youtube channel, subreddit, the forums, twitter, vkontakte, flickr, etc.

And now we're even talking about adding another site to this collection by splitting icons and artwork out of the main source tree. While I can understand a need going forward to get the art resources better organized and not necessarily in the main OS source tree directly, it seems like this growing hydra needs a little taming as well lest it get out of hand.

The main site is serving as a decent central hub for now I suppose. I'm just a little frustrated after trying to figure out the software sources issue and still running into essentially duplicate sites that are now only archived. That HaikuPorter one has bit me before and I fell for it again now after not having done any development for a number of months.

I don't mean to sound overly negative. Just kind of grumbling out loud while I try to get a better handle on the ecosystem and see where maybe some concentration or automation might improve things.

Saturday, February 7, 2015

A new icon for BeMines

I've been working on a fork of BeMines on HaikuArchives to merge in the Haiku theme I did for it so I can then do a pull request and have it merged back in, and decided to also do an icon for it. I'd considered using the mine icon I'd made for Minesweeper, but didn't want to contribute even more to the existing confusion between BeMines and Minesweeper, so I made a custom version of the icon for BeMines.

Hopefully the bright red color with the Be "eyear" logo on it will make it easily recognizable as a different app from Minesweeper.

I had to do some reading about resources and .rdef files, but I think I have the icon added to the rdef file that I created from the existing .rsrc file (the old Be binary format) by using rc -d BeMines.rsrc which output BeMines.rdef. Unfortunately I then ran into a compilation error when trying to compile BeMines to test my changes. Hopefully that gets fixed soon and I can move forward with adding my theme and icon.

UPDATE: the compilation bug had already been fixed in Haikuports by Pulkomandy, but hadn't been pushed upstream to HaikuArchives, despite pulling from that source for its recipe and applying the patch there before compiling. So diver upstreamed Pulkomandy's patch and I then forked the HaikuArchives/BeMines git repo, applied my changes (added my theme, icon, etc), and put in a pull request. It was a learning experience but not much of a fun one by the end... git and I aren't friends. ;)

Thursday, February 5, 2015

Some miscellaneous icon updates

I decided to devote a post to some miscellaneous icons I've updated, some recent and some a few years ago now. Just to be clear, I didn't originally do most of these icons. They were either from the app directly (BePDF), from data/artwork/icons/ in the Haiku source tree, or from Zumi's icon collection. I simply cleaned them up or reworked most them. Credit should go to the original authors for their work.

First let's address the FontBoy icon. I noticed recently that work had resumed on FontBoy and wondered if they were going to use the new hvif icon I'd done for it back in 2012, and decided to check it out... only to notice that humdinger had redone another new hvif icon for it, apparently unaware I'd already done one. I polished mine up a little further and will offer it here. Maybe it's just me but I'm a little partial to mine. ;)

The original Be raster version is on top, then the current FontBoy icon by humdinger in the middle, and finally my FontBoy icon on the bottom.

For all the remaining icons on this page the original icon will be on the left side and my "fixed" version will be on the right side.

Next we have the TARDIS icon. This one was hanging out in the data/artwork/icons folder in the Haiku source tree, and I felt it could use a little polishing (right side windows, light beams, highlights, and shadow).

Then we have the BePDF bee icon that needs to have the Adobe PDF logo removed from it. This one might be able to use a little tweaking to the legs to make them more visible irrespective of the background color?

Next are the two USB icons from data/artwork/icons. They looked a little skewed to me, so I cleaned up the hvif files for them (removing unused shapes, paths, and styles) and added a bit of polishing to them as well. A little added shadowing, enlarged holes, and angle correction on the male connector, and tweaked the cords a bit. (Also made the USB logo match on both.)

Next is the Hand icon. For this one I did quite a bit of cleaning up "under the hood" so to speak. The border around the hand for example had been created as a separate path/shape rather than as a stroke on the existing path around the hand. There were also quite a lot of extra points in the path. So I cleaned a bunch of that up and reduced the file size by over 20%, then used that freed up room to add in a bit of "shine" on the wrist and thumb to make it more like the original again.

Then I took the Coretex app icon and added it to the hand (merging the shadow, and removing the shapes and path data under the Coretex icon to reduce file size) to create a CoretexAddOnHost icon to replace the old Be raster icon still in use by the system. I'm not sure if this is the correct icon to use for this? I need to find out if this works, or if I need to create a version that matches the raster one... one of the devs will need to enlighten me on this one.

Finally we have some icons from Zumi's great icon collection.

First are some GTalk icons. These I barely tweaked. Just changed the large G to be a little more solid and similar to the official Google logo, made it not overlap the balloon, and then tweaked yellow to make it a bit more visible and fixed the bottom right borders of the balloons where they got a bit too thin.

And last, but not least, I wanted to make Zumi's frogs actually look like frogs, so I redid the original 2 icons to be more frog-like, and then added yet another color variation to match the blue poison dart frog that used to be used a few years ago as the logo for the Java based bittorrent client called Azureus. The company changed its name and that of its software platform in part in 2006, then more fully in 2008 (although the client engine apparently still retains the name), and the logo is now simply a monochrome frog silhouette rather than the more specific blue poison dart frog it used to be.

Wednesday, January 28, 2015

A Haiku Minesweeper update and a theme for BeMines

Since my original mockups there's been at least some progress on Minesweeper in general. It's been added to the HaikuArchives at least.

A new ticket has been created on the github repo version referring to my old ticket on trac discussing my ideas for the Haiku style enhancements.

Let's have a look at the updated style work I've done recently, including a preview of both the new icons I've created, and the couple from Zumi's excellent icon collection that I'd like to use in the app.

The emoticons and clock icon are from Zumi's collection and the rest were created by me.

While I was at it, I also created a similar theme based on that style for Darkwyrm's BeMines. This is just a bitmap based theme based on the mockups work I was doing for the actual Minesweeper style work.

While I was working on that theme I noticed an interesting bug in BeMines... two related bugs actually. First, the game finishes when all flags are placed, not when all tiles are cleared as in the Windows version I'm familiar with. This allows instances where you can basically cheat by guessing flag placements in a few final squares where you might otherwise be forced to guess at clearing a tile at the risk of hitting a mine. This leads to another side effect bug where clearing every tile except the mine location doesn't finish the map. You have to manually place the final flag to finish the map, again unlike the Windows version I'm familiar with, and unlike the Haiku Minesweeper version at the top of this post which functions exactly as I recall in the Windows version.

Friday, January 9, 2015

Visualization of Haiku git repository activity - January 8th, 2015 update

Here is another update of the Haiku git repository Gource visualization. The last one I did of this was well over 2 years ago, and I've been meaning to do a new and improved one ever since.

For convenience I'll include the full description here;

Visualization of activity on the Haiku OS git repository done with Gource.

I used a combination of the Gravatar script ( ) and some custom done icons for some of the users, replaced the default user icon with a modified "People" icon from Haiku, dropped in the Haiku logo, and did a number of other tweaks.

Command line:

gource --load-config gource.cfg -r 25 -o gource.ppm

Encoding line:

ffmpeg -y -i audio.mp3 -vcodec ppm -r 88 -f image2pipe -i gource.ppm -vcodec mpeg4 -r 29.97 -preset veryslow -q:v 1 -threads 8 -b:v 10000k -bf 0 -comp_duration 204 -ac 2 -acodec copy gource.mp4

Config file:


font-size=24 font-colour=ff7600
logo=HAIKU logo - white on transparent - small.png

As you might notice, I did this one in full 1080p this time around and the video quality came out far better.

The music in the video is from "Flight of the Bumblebee", which seemed perfectly fitting to the frenetic pace of the development shown in the video.

Sunday, March 10, 2013

Using the actual Thumbnail attribute in Tracker

While working on my earlier post about updating the Thumbnail application, I was reminded of a nagging irritation I've had not only since I started using Thumbnail, but especially since larger icon size options in tracker were added by John Scipione back in hrev44422.

In essence the problem is that currently Tracker uses either the BEOS:M:STD_ICON or BEOS:L:STD_ICON attributes to display the icon for the file in Tracker. But since these icons come from more than 15 years ago back in the BeOS days, those icon sizes are 16px and 32px respectively, on top of being dithered. (See the "GetIcon(), SetIcon(), GetTrackerIcon()" section of the BNodeInfo page in the BeBook for more info.)

While those may not look too terrible at those very small sizes (and even that is definitely arguable), the problem is that the 32px BEOS:L:STD_ICON is the biggest one we have to work with when it comes to showing a preview of the actual image for image files. So this gets scaled up double for even 64px sizes, triple for 96px, and quadruple for 128px sizes.

You can see the result of this for 96px sizes in the image below showing the current way it's done. And that's not even the worst example.

Now, what I noticed while tweaking the binaries for that earlier release was that there is also a GRAFX:Thumbnail attribute set, which includes a high quality (up to) 96px actual thumbnail version of the image. I kept finding myself wondering why the heck Tracker refused to use this far superior thumbnail even when I was using the largest icon size options.

I haven't gotten an answer to that question yet... as to whether or not it just hasn't been coded yet... or there is actually an ideological reason why not to do it, or even something architectural preventing it.

In the meantime, here are two images... the first of the way it is now... and the second showing how it could look if Tracker used the GRAFX:Thumbnail attribute instead.

Current Tracker settings
Mockup of using Thumbnail attribute