Re: A different approach to generating a GUI

As far as browser-based guis go, I tend to think of the opposite direction, that is making a browser plugin that would allow a limited Perl and a limited Perl/gui module to run in the browser, not on the server. Like the Java Browser plugin, but for Perl. We could do lines, curves, animations , etc, like they do with Java through the browser. I wish I was smart enough to make a really functional browser plugin.

Another option is just to drop the browser all together, and make your gui server just send control signals and data to pure Perl GUis directly through sockets.

That is already the easiest thing to do. Just have your users download the special client programs, and let them connect. Why have the overhead of the browser at all?

I'm not really a human, but I play one on earth. flash japh

Comment on Re: A different approach to generating a GUI

Replies are listed 'Best First'.
Re^2: A different approach to generating a GUI by renodino (Curate) on Dec 29, 2005 at 14:58 UTC
Why have the overhead of the browser at all? Because everyone pretty much already has a browser installed on their desktop, and they're already familiar w/ navigating inside the browser. And, at least for Firefox (and maybe Opera), the browsers have already solved much of the platform/OS compatibility issues. GUI tookits, OTOH, - and esp, in my experience, Perl GUI toolkits - tend to have mixed success addressing the platform independence requirement. I think some of your assumptions wrt browser capabilities may be a bit dated; XUL brings much functionality to the Firefox browser, and when XAML becomes "official" in '06(?), it will likely further change user expectations wrt browser capabilities. Hence, the need for "plugins" may go away, and by writing MVC structured apps - w/ very loose coupling between the M and the V -, GUI apps become small local web servers, at the same time providing the option for remote execution for apps that need it. Whether the user needs a Perl - or Java or Python or C# or etc. - installation on their desktop will depend entirely on the complexity of the app, and the speed of their 'net connection (tho the security issues remain problematic). So, wrt the OP, it would be nice to have a decent Perl API in development now to address the likely future transition to browser based GUIs, even if the widget set were limited to XUL/Firefox for the time being.	[reply]

Replies are listed 'Best First'.

Re^2: A different approach to generating a GUI
by renodino (Curate) on Dec 29, 2005 at 14:58 UTC

Why have the overhead of the browser at all?

Because everyone pretty much already has a browser installed on their desktop, and they're already familiar w/ navigating inside the browser. And, at least for Firefox (and maybe Opera), the browsers have already solved much of the platform/OS compatibility issues.

GUI tookits, OTOH, - and esp, in my experience, Perl GUI toolkits - tend to have mixed success addressing the platform independence requirement.

I think some of your assumptions wrt browser capabilities may be a bit dated; XUL brings much functionality to the Firefox browser, and when XAML becomes "official" in '06(?), it will likely further change user expectations wrt browser capabilities.

Hence, the need for "plugins" may go away, and by writing MVC structured apps - w/ very loose coupling between the M and the V -, GUI apps become small local web servers, at the same time providing the option for remote execution for apps that need it. Whether the user needs a Perl - or Java or Python or C# or etc. - installation on their desktop will depend entirely on the complexity of the app, and the speed of their 'net connection (tho the security issues remain problematic).

So, wrt the OP, it would be nice to have a decent Perl API in development now to address the likely future transition to browser based GUIs, even if the widget set were limited to XUL/Firefox for the time being.

[reply]