CRiSP Weblog

I havent updated the blog in a while, and I do get a trickle of dtrace issues/questions, along with CRiSP support ones.

Firstly, to remind anyone, if I can, to avoid the crisp.demon.co.uk email addresses and use CrispEditor@gmail.com. I have yet to get my systems setup properly to send via demon, after they moved email to IMAP.

Although things are quiet, its mainly because I have been slowly creating a ribbon bar for CRiSP. Piecing together how a ribbon bar works opened my eyes to a number of things. I tend to spend a couple of months on one or other of CRiSP vs DTrace.

Sometimes, you get so close to the software you are writing, things either slow to a crawl - you lose "instinct" - and other times, you need to go away for a bit (could be an afternoon, a day, week, or month), and forget the lines of code. You come back to the code as an "outsider" and immediately see the deficiencies which you could not see before.

With DTrace, the biggest problem is addressing and ensuring all kernels build - and this is done piecemeal, not by some divine CI (continuous integration system). There are hundreds if not thousands of linux kernels out there (2.6.1, 2.6.2, 2.6.3, ...) and the number of permutations of compile options means its infeasible to test all variants. (Some people have built projects to try all permutations of compiler flags - just for one release, and even that is a huge computation task).

Anyway, back to the ribbon. I'm fairly proud of CRiSPs GUI controls - written from scratch, a long time back, and the use of "constraints" to allow widgets to stick together. This mentality dates back to the early origins of X windows and allows apps to resize whilst looking reasonable. Most Windows apps, on the other hand, use pixel coordinates - this is great for GUI Designer tools, but is why most dialogs are not resizable. Even Windows' Open File dialog is "slightly" resizable - all the spare real-estate is given to the filenames (as it should) but it has caused source code portability issues in each Visual Studio release. It wasnt a great source code design.

As a side note, most mobile apps work in a similar vein - as Apple and Google released new devices which had various screen sizes and pixel densities, there has been a rush of app upgrades to cater for these screens.

Another side note: Apple uses floating point pixel co-ordinates and not integer ones. When Apple (and Postscript before them) did this, at the start, they were simply insane - huge amounts of cpu work just to draw things - back in the days when floating point units were very slow (or nonexistant). However, fractional coordinates are brilliant in todays every increasing screen sizes. (I do find it strange that even Apple has had problems on the iPhone, allowing non-multiples of the base 320x480 screen size).

Anyway, back to the ribbon bar. The ribbon is technically very interesting. If you look at a GUI control like a "listbox" or "tree control" - things we are all very familiar with, the layout options are easy to comprehend, and to most programmers, can figure out how to build one. (Building one to scale to millions of items is a challenge).

The ribbon is complex. Very complex and clever. I started by creating a control with "panels". Bunches of bitmaps and controls go into the panels, and give the MS Word-like appearance, quite easily. But, if you play with MS Word or Outlook and watch what happens as you shrink or expand the window, its unobvious what is going on. If you do it enough, you can see whats happening, and it feels "natural".

Now, consider how to implement this - with each icon and column of the ribbon bar, as you grow/shrink, you effectively have to try all permutations of "restacking" to get the desired effect. I started doing this, but did a sanity check. What happens if you have 50 controls inside the ribbon and want to compute the optimum layout as the window shrinks, and they wont all fit? By my calculation, this involves around 3^50 permutation checks. I was astounded. 3^50 is not acceptable. Maybe 1,000,000 attempts are. What we have is akin to a travelling salesmen problem (where we try to compute the optimal route in order to visit a series of destinations).

I had to read the Microsoft Ribbon control docs to finally "get it". A ribbon is a collection of panels. Each panel is a collection of groups. Each group is a collection of controls. Rather than deal with, say 50 individual controls, you might be dealing with 10 groups. Now, each group can be resized and laid out, almost independently (not quite). 3^10 is 59049, which is much more reasonable compute power to use.

Where does the "3" come from? Each control on a ribbon bar has 3 visible modes (big bitmap, small bitmap + label, or small bitmap).

Do people like or want a ribbon bar? I dont know. Those of us who use Word or Outlook, get used to it. Despite losing the drop down menus, and taking ages to figure out where everything sits, it looks "modern" and is "enjoyable" to play with. (Of course the ribbon is now quite a few years old, and Microsoft is going for the "tiled" effect).

So, that gives you a little perspective of "ribbon controls".

Interestingly, when the ribbon first appeared in MS Office, it wasnt customisable. Now, it is. They must have gone through a lot of effort to implement it, and then reimplement it. If you look at the ribbon in the many MS products, they are all subtly different, and differently "quirky".

I spent nearly a week trying to figure out where the X11 message had come from. I knew where, but not why it was different from the other parts of the CRiSP code.

Of course, 30mins after posting that, I resolved the problem.

Definitely a case of being short sighted and not remembering how my own code worked.

When a tooltip pops up, the keyboard is grabbed, and we track the mouse - looking to see it move outside of the original area, so we can pop down the icon.

I assumed some magic was being used to drop the tooltip, but it was more basic than that. I had forgotten to look for the mouse moving outside the bounds of the image which gave rise to the tooltip. (I had nearly spotted the problem a few days back, but got side tracked as I locked the X server up, and hadnt spotted the "missing code").

The ribbon most likely wont make it in to the next release of CRiSP, as its not ready. A ribbon implementation is interesting, because of the behavior of the control, but also due to the various things that happen and can be embedded into a ribbon. (Popping up tooltips, complex tip-like helper windows, complete with embedded images, and a menu selector).

CRiSP does most of this now. (I have also been cleaning up the freetype font display for some of the controls, because getting the ribbon work was showing the ugly default fonts).

Now..off to see if this code even builds on Windows, as I have a couple of customer bugs to examine/fix.

I wanted to publicise this. It has always been possible to contact me and get support for CRiSP via the crisp.demon.co.uk email address. Demon - a UK based internet provider - were literally the first in the UK, starting around 1991. Using a 9600baud modem, one could finally ftp to sites around the world - predating HTML and web browsers.

The price was very cheap - in fact the price hasnt moved in the last 20 years or so.

Demon got bought up by other companies, went into the broadband business and have always been non-competitive in terms of pricing or technology.

In 2012, they moved from a POP3 mail service to IMAP. The POP3 mechanism and the design of the domains meant I could use as many mail addresses for any purpose I liked, and collecting email was very simple since they all mail sat in the same inbox.

With IMAP, this is no longer true. I cant even remember what mailnames I have used in the past, and having to try each one to poll for new mail is pointless.

Quite a few years back, I set up CrispEditor-at-gmail.com and many people use that. The nature of the IMAP service is so bad I may finally stop paying for the Demon account - the mail will bounce and the ftp hosting location will disappear. (I will find some alternate location or update the links, so people can still find CRISP).

The Demon IMAP interface is pretty - on a par with hotmail, but it is so badly thought out, and the migration to IMAP was so badly publicised or managed, that Demon has fallen out of my good books.

I've been spending the Xmas period working on CRiSP. One feature I had been pondering for a long while was addition of a ribbon bar, like Microsoft tools. The ribbon can be effect, and aesthetically pleasing in its design, and quite complex in terms of implementation semantics.

I have a prototype working - still more work to do.

I spend most of my live development on Linux - its easier and more convenient, using the tools. (Windows 7 build speeds are pretty impressive, and I use MINGW when I need to debug, using gdb, rather than Visual Studio).

Over the years, one thing has always annoyed me: programming paradigms where messages are received to effect an action or event, but where you have no idea what or why they are delivered, or where from.

The Xlib protocol is simple and of high performance, but due to the multiprocess nature of an X-Windows system, determining what is going on can be problematic. CRiSP has built into it an X11 message tracing facility (set the env var XDEBUG=1 if you are curious). Its very helpful to see what is happening.

The particular area causing me problems at the moment relates to tooltips. CRiSP has had for tooltips for an awful long time - floating text labels next to items in the GUI (tabbed windows, icons, etc). In the ribbon and image implementation, the popup of the tooltip, is immediately dismissed - the act of the popup causes a LeaveNotify event to be delivered, but I dont know where from. (Most likely the window manager, but finding out "why" is difficult). Bear in mind its the same subroutines which implement this - this effect doesnt happen elsewhere.

As with all difficult programming problems, most likely, I am looking in the wrong place. Hopefully I wont have to waste too much time on this.