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".
Post created by CRiSP v11.0.14a-b6519
No comments:
Post a Comment