in reply to The browser as a (simple) window manager. (Updated)

but the Tk's inability to accept an image in raw binary makes that a non-starter. Forcing me to convert the raw image into base64, so that it can convert it back is just symptomatic of the whole architecture.

Move up to Gtk2. ;-)

Perl/Gtk2 will accept binary data for images, and the DrawingArea widget has alot more flexibility than GD, in terms of setting up axis, and fonts, since it uses Cairo

As a matter of fact, there is a module Gtk2::Ex::Graph::GD. Also consider if you are using Firefox, IT itself uses Gtk2 based widgets, so why deal with javascript and all that mess? Just write your own app. :-) Sample code in the readmore 

#!/usr/bin/perl
use strict;
use warnings;

use Gtk2::Ex::Graph::GD;
use GD::Graph::Data;
use Gtk2 -init;
use Glib qw /TRUE FALSE/;
use Data::Dumper;

my $graph = Gtk2::Ex::Graph::GD->new(500, 300, 'bars');

# All the properties set here go straight into the GD::Graph::* object
+ created inside.
# Therefore, any property acceptable to the GD::Graph::* object can be
+ passed through here
$graph->set (
    title           => 'Mice, Fish and Lobsters',
    x_labels_vertical => TRUE,
    bar_spacing     => 1,
    shadowclr       => 'dred',
    transparent     => 0,
    # cumulate        => TRUE,
    type => ['lisen', 'bars', 'bars'],
);

my @legend_keys = ('Field Mice Population', 'Fish Population', 'Lobste
+r Growth in millions');
$graph->set_legend(@legend_keys);

my $data = GD::Graph::Data->new([
    [ 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008,],
    [  1,  2,  5, 8,  3, 4.5,  1, 3,  4],
    [1.4,  4, 15, 6, 13, 1.5, 11, 3,  4],
    [11.4,  14, 22, 16, 1.3, 15, 1, 13,  14],
]) or die GD::Graph::Data->error;

$graph->signal_connect ('mouse-over' =>
    sub {
        #print Dumper @_;
    }
);

$graph->signal_connect ('clicked' =>
    sub {
        print Dumper @_;
    }
);

# This actually returns an eventbox instead of an image. 
# But you don't <really> care either way, do you ?
my $image = $graph->get_image($data);

my $window = Gtk2::Window->new;
$window->signal_connect(destroy => sub { Gtk2->main_quit; });
$window->set_default_size(700, 500);
$window->add($image);
$window->show_all;
Gtk2->main;

[download]
I'm not really a human, but I play one on earth.
Old Perl Programmer Haiku ................... flash japh

Replies are listed 'Best First'.
Re^2: The browser as a (simple) window manager.
by BrowserUk (Patriarch) on Dec 12, 2010 at 13:26 UTC

    First, let me thank you for your response. I'm about to dismiss your suggestion, but I hope to show that I'm not doing so without due thought and consideration :)

    Move up to Gtk2. ;-) Perl/Gtk2 will accept binary data for images,

    The first problem is that despite several attempts, I've never managed to get GTK* to build here. The last time I attempted it, I was using 32-bit and it failed hard. I have no expectation that it would be any easier for my 64-bit setup.

    But even if I could, it still doesn't answer most of the problems I have with such toolkits. Which essentially comes down to the fact they take over the whole application, forcing a particular (and abhorrent:) structure, and side-lining the raison d'etre for the applications existence.

    For the type of applications I'm describing, there purpose in life is to generate and.or process large amounts of data. They are just command line apps that you fire off into the background and forget till they are done. But sometimes, especially during development, I want to be able to visualise what they are doing. Because they are dealing with large amounts of data, producing huge swaths of trace output--just reams and reams of numbers--is effectively useless, because the detail gets lost in the noise.

    That's where the visualisation comes in. If you can throw a few lines or dots or blocks of color into an image and 'flicker compare' two different algorithms; or sequential iterations of same algorithm; the human brains uncanny ability for pattern recognition--hardwired and tuned over millions of years of evolution--can often detect patterns, trends and anomalies in huge amounts of data, that would be weeks of work to detect by looking at the same data represented as reams of numbers.

    But the visualisations are not the primary purpose of the applications. Or even a required part of the final programs. They are just a transient part of the development process. The are effectively just a debugging aid, used in much the same way as Data::Dumper, for a quick check of what the program is doing to or with the data. And just like Data::Dumper debug lines, once the program is working correctly, they should be easily either disabled, or remove completely from the program. Their purpose served.

    You just can't do that with a GUI toolkit.

    Also consider if you are using Firefox, IT itself uses Gtk2 based widgets, so why deal with javascript and all that mess? Just write your own app. :-)

    Why write an app when I have a browser that can already do everything I need? And more importantly, everyone has a browser. So if I want to share my visualisation with someone else--as in the OP of a question I am responding to here; or my brother in the states--they only have to install the BUI module (not a real suggestion for a name)--which should have no need for non-core dependencies and run anywhere perl does--and download the code I post and run it.

    No need to have to seek out and download 27 billion dependency libraries spread all across the web and work out how to try and build them all together as is the case wth GTK* and similar.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Meditations