Skip to main content
Welcome guest. | Register | Login | Post

Firefox Thick Client Applications

29 replies [Last post]
supermike's picture
Offline
Joined: 2006-02-17

From Linux, is there a way to load Firefox on a particular file type (or perhaps something in the file) to cause it to load without anything except the web page with no menus or toolbars, etc? Is this what all this talk of XUL is all about?

(Note, yeah, like any web developer worth his own salt, I too can make an HTML page run some ECMAScript that causes a new window to open without menus or toolbars. The problem is that this is not what I want because then you have a delay and you are running two windows. I'm looking for something completely different. I just want one window to open exactly as I planned it.)

I was wondering because it might be a useful platform for deploying thick client applications on Linux. If you had a thick client application, where the client GUI, application logic and server, data logic and server, and all other components existed on one workstation, you could use Firefox as the front end and simply design the program as a web app with one exception. The exception would be that you would draw your own menus and provide some kind of toolbar (again, drawn) so that users could stop pending requests and retry, in the event of a web server glitch.

In this manner, if you are a web developer and know PHP, but don't know things like Python, C, or Perl, and don't know widget APIs like Qt, GTK2, or WxWidgets, then perhaps this is an avenue to pursue.

I look forward to your answer. This task would be exciting to see in action.

supermike's picture
Offline
Joined: 2006-02-17

I interacted at XUL Planet here after reading about XUL here.

I'm waiting on a response from someone there.

supermike's picture
Offline
Joined: 2006-02-17
What I learned is that XUL

What I learned is that XUL sucks. It's hard to get an app built to use this technology, hard to deploy and requires 9MB of a runtime (when that's stupid because Firefox is usually installed and is already a kind of runtime), and hard to run the app once you get it in this convoluted format. This is outrageous. The whole XUL project should be scrapped. Besides, we cannot beat up on Microsoft and say, "Your format only works in your browser," when XUL will only work in Firefox.

Microsoft, I have to admit, has invented a better technique and Linux has no equivalent. I've used it on a couple gigs back in the day when I did Microsoft work. It's called "HTML Application". For instance, with a code sample "app.hta" (source below), if you run it by doubleclicking it, Internet Exploder (on Windows), without warning, will open a pretty window with no menu bars or toolbars. It then tries to connect to http://www.google.com/. Now, if that SRC line below were replaced with a locally hosted web app, such as something like http://127.0.0.1:30932 (a web app you stick on port 30932 locally on this system), then you would see that app.

<html>
<head>
	<SCRIPT>
	  var sampleWidth = 750;
	  var sampleHeight = 550;
 	  window.resizeTo(sampleWidth,sampleHeight);

	  var screenPosX = (screen.availWidth - sampleWidth) / 2;
	  var screenPosY = (screen.availHeight - sampleHeight) / 2 ;
	//remove () and / 2 from above to make it go right above systray
	  window.moveTo(screenPosX, screenPosY);
	</SCRIPT>
<title>Sample Application</title>
<HTA:APPLICATION
ID="AppContainer" 
APPLICATIONNAME="Sample Application"
NAVIGABLE="yes"
CAPTION="yes" 
SHOWINTASKBAR="yes"
SINGLEINSTANCE="yes" 
SYSMENU="yes"
WINDOWSTATE="normal"
BORDER="thick"
BORDERSTYLE="raised"
CONTEXTMENU="yes"
INNERBORDER="yes"
SCROLL="no"
SCROLLFLAT="no"
SELECTION="yes"
ICON=""
MAXIMIZEBUTTON="no"
MINIMIZEBUTTON="yes"
>
</head>
<!-- <body bgcolor="#D6D3CE" topmargin=0 leftmargin=0> for grey control panel-like dialogs -->
<body bgcolor="#FFFFFF">
<p><IFRAME
        	NAME="AppFrame" 
        	ID="AppFrame" 
        	SRC="http://www.google.com/"
        	WIDTH="100%"
        	HEIGHT="100%"
        	SCROLLING="no"
        	BORDER="0"
        	BORDERCOLOR="#FFFFFF"
        	FRAMEBORDER="0"
		ALT="Loading Application..."></IFRAME></P>
</body>
</html>

If Linux and/or Firefox comes up with something similar in the future, I can tell you that this would take off and you would see a lot of things deployed with it as a kind of standard. Also, if you're looking for a lightweight web server to bundle with your project, you could consider lighthttpd. It has the power to run PHP in CGI mode.

Some downsides are that if you make an app like this, and you bundle a web server, SQL server, and PHP CGI component, you're probably looking at a lot of MB, even if you do use lighthttpd. The big size is probably going to be the SQL Server and the PHP CGI component. You might be able to use a lighter SQL Server than PostgreSQL's 48MB footprint, but then if you ever wanted to port your app easily to a true client/server interface, you might be faced with a huge rewrite of all those SQL statements. As well, the PHP CGI component probably has a big disk footprint, although my Ubuntu seems crazy because I cannot find the php4 install dir to see how big the CGI runtime would be. Therefore, in hindsight, a more viable option would probably be bundling with lighthttpd, using Berkeley DB, and Perl. Many systems may already have Berkeley DB and Perl on them already. Still, there might be a way to run PHP4 with minimal functionality against Berkeley DB and use that instead.

a thing's picture
Offline
Joined: 2005-12-20

You could take Epiphany (which uses Gecko) and remove the toolbars & menus there.

supermike's picture
Offline
Joined: 2006-02-17
I looked around at a lot of

I looked around at a lot of small, embeddable, GPL databases for such programs. Now HSQL is cool, but it's Java, so it sucks, in my opinion. So then it comes down to looking at something like tdb (a better implementation of Berkeley DB), msql, or sqlite. TDB had no SQL interface to it that I could find, but did have multi-user access and row locking, which Berkeley DB did not have. There was also no real PHP interface for it that I could find. Next comes msql but it has -- ack -- OEM licensing. So last is SQLite, which seems to have won an O'Reilly award at some sort of OSCON conference. When I looked at it, it had a very tiny 250K footprint, and had interfaces for a variety of languages including PHP, Perl, Python, etc. It has no stiff licensing requirements and doesn't even appear to be GPL -- just pure, plain jane public domain.

I installed sqlite3 and the PHP module for it with apt-get and then did this:

# sqlite3 names.sqlitedb
SQLite version 3.2.1
Enter ".help" for instructions
sqlite> create table names(
  ...> firstname varchar(60),
  ...> lastname varchar(60)
  ...> );
sqlite> select * from names;
sqlite> insert into names values ('Mickey','Mouse');
sqlite> insert into names values ('Mandy','Mouse');
sqlite> select * from names;
Mickey|Mouse
Mandy|Mouse
sqlite> .q
#

However, when I catted out the file, to my surprise I saw it was plain-text with binary codes between things, and the creation schema stuck at the top of the file. Therefore, if you plan to embed this with your program, and you are particularly concerned about someone messing with it, you may want to use a Blowfish cypher on the file that runs when you launch your app and then recyphers the file when done. (That's to keep out prying eyes from an app, say, that may store financial data and which is network-accessible.)

All and all, I'm sold on SQLite for fat client apps, without a doubt! (However, for web apps, I put my support behind PostgreSQL.)

supermike's picture
Offline
Joined: 2006-02-17

Now the question is, how small can one get a custom PHP build that can interface with CGI and SQLite? It would take a custom-compile, I'm sure.

supermike's picture
Offline
Joined: 2006-02-17

I did a lot of thinking and it doesn't look like Firefox is ready to the challenge of being loadable in a format like an "HTML Application" that you doubleclick and get a menuless, toolbarless, HTML page that acts as a thick client application. So then what else does? One could use a customized Epiphany browser, but then you have to bundle with that and it would be more code than you would need. I realized that many GNOME-based distros support Python and PyGTK, so I figured it would have to start with something like that, but only long enough to pull open a GTK browser gadget. Once you got that loaded, a CGI PHP app could run in the background with this application and you can forget about all the complexities of Python. The trick is, how do you get there? That's when I discovered this wonderful article, "Creating a GNOME Web Browser with Python". In this, you can see he uses something called pygtkmoz in Python, which is an embedded Mozilla widget. You can't draw this in Glade, unfortunately, but you can load it at runtime to occupy the space of a frame widget, overriding the existing frame window handle.

Therefore, my final assumption about building the easiest, most reliable thick client application on Linux is to utilize:

* A minimum of Python just long enough to load a window to hold PyGTKMoz.

* The PyGTKMoz widget to be the entire GUI of the application.

* The PyGTKMoz widget connects over something like http://127.0.0.1:30932 back to lighthttpd.

* The lighthttpd supports PHP through CGI mode. Lighthttpd can be compiled only with the necessary options you want to include.

* The PHP can be compiled only with capabilities for CGI interaction (cookies, headers, redirection, etc.), SQLite, process I/O (shelling out), math, date/time, sorting, strings, arrays, sockets, compression, encryption, regexps, conf file I/O, and XML. (And perhaps even slimmer than that if your app won't use any of these.) PHP4 would probably be the best option, even way into the future when PHP6 and 7 come out. This is because PHP4, plain-and-simple, just works and can handle many jobs without issue. Besides, you want an embeddable platform here that's very compact and which can utilize a skill that many developers may already have.

* The PHP can interface with a SQLite database file. Because this file is unencrypted, you'd have to use a string cipher (simple, medium, or complex) to encrypt/unencrypt data to/from the database in order to protect data security.

* Meanwhile, the PHP can be used mostly for what you would normally use it for with a web app, and whatever you don't have included in that web app, you could shell out to Bash and run a BSD or GNU utility (or other utility) and parse the result for processing.

* Besides Python and PyGTK, which many distros already have, all of these components can be compiled and dropped into the same directory as the application you are building, and use a very tiny footprint.

Here's Why It Might Be Important To All Linux Programmers
You might not get it at first, but if someone (say, me), were to gather all this together for you as a kind of SDK, then any programmer who knows PHP and SQL could easily use this SDK without worrying about learning Python, PyGTK, lighthttpd, or compiling PHP in CGI mode. They could be abstracted from all that. They could get some skills in PHP, HTML, ECMAScript, and SQLite (and not much skills are necessary with SQLite) and be off and running with their very own PHP-based thick client (standalone) application. Pretty much these days, when you say, "web developer", you can already assume that's someone with this experience, anyway. Therefore, the average newbie web developer could build standalone applications quickly and painfully on Linux, doing most of the work in PHP. The rest would be abstracted and pre-built for him using such an SDK.

Now, the most ideal solution would have been:

* Replace the need for Python and PyGTK. Instead, build a container for GTKMoz with GCC and the C language. This could be one single binary file. In fact, perhaps there could be a way to include all the components of GTKMoz as static objects so that it's compiled right inside the single binary file. Upon launch, it could look for a special <your app name>.conf file in the same directory as itself that would define the application title, titlebar icon, x-y screen position, window width, window height, and what localhost website port to connect to so that the application loads.

Switching the context to the end user, not the programmer, the end user could apt-get this package and it would download this application loader, a special version of lighthttpd, a special version of PHP4, and SQLite. It would drop these all into one single directory and put a softlink in /usr/bin. It could create a menu launcher for them for it. When they run it from the menus, in a snap it would open and show your standalone web app.

No need for Mono and C# app-building, ceding anything to Microsoft. No need to purchase something like RealBasic. No need for WxWidgets and to use C. No need to learn anything except ordinary PHP and SQL. And within a matter of minutes you could be coding standalone web apps just fine. Now all I need to do is find the time to combine all this and get it done.

supermike's picture
Offline
Joined: 2006-02-17

If you're interested in permanently storing the article, "Creating a GNOME Web Browser with Python", on your hard drive, you can do it with:

wget -k -r --referer=http://nuxified.org/ -c http://patrick.wagstrom.net/tutorials/pygtkmozembed/pygtkmozembed.html
supermike's picture
Offline
Joined: 2006-02-17

Wow, was I ever wrong on this XUL thing. The only thing really wrong with XUL is the poor documentation for the direction in where I want to take it. I'll have more info soon with a short sample that anyone can run. I'm working on it now. It will show you how to make a quick and easy standalone application.

kode's picture
Offline
Joined: 2006-04-19

I'm currently building what you call a 'think client application' -- deploying with firefox has been simplistic half the time and a complete pain in the arse for the rest.

This is the first time I've actually missed VB6's GUI widgets. I've grown tired of the {JS/CSS/XHTML/PHP} widget crap required to do simple things like an image combo box (example on my blog). Unfortunately, web-based application interfaces are far too primitive to deploy on a large scale for many application types.

It's almost impossible to maintain a clean codebase when every single 'page' has 500 lines of special JS/CSS/etc just for that particular 'page'.

One of the many problems was in replacing Kicker, and embedding application launch icons into the application itself. Within normal applications, this is easy, but since web pages can't actually execute local binaries, it got interesting. In the end, the solution was simplistic enough, but it took some time to get there.

Don't even get me started about having to deploy web applications for more than one browser base...

DISCLAIMER: While I do get paid to build them, I'm biased against web-based applications. I think the web is almost useless and should be replaced with a better system. (I'll write more on that subject at another time, I hope.)

PS: To disable menubars, etc, search for "Kiosk" plugins for firefox on mozilla.org -- they do fullscreen by default, etc.

supermike's picture
Offline
Joined: 2006-02-17

welcome, kode.

supermike's picture
Offline
Joined: 2006-02-17
I'll have a sensational doc

I'll have a sensational doc on this perhaps this week or this weekend. For now, here's something you can experiment with. I think you'll be surprised with the results.

Create a file called ~/myapp.xul. Inside, paste this:

<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>
<window
id = "myapp"
title = "My Application"
screenX = "40"
screenY = "40"
height = "420"
width = "640"
sizemode = "normal"
xmlns = "http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" >
<iframe
id = "webframe"
flex = "1"
src = "http://www.google.com/"
type = "content-primary"
style = "border: 1px solid #f8f8f8" />
<statusbar>
<vbox flex="1" style="height: 10px">
<label style="height: 2px" />
<statusbarpanel id="statuslabel" crop="end" label="" flex="1" style="border: 1px inset #f0f0f0; width: 100%" />
</vbox>
</statusbar>
</window>

Then, from your command line either under a different ID (unless you shut down this browser window), run this:

$ firefox -chrome file:$PWD/myapp.xul

or, you can do an explicit path like:

$ firefox -chrome file:/home/supermike/myapp.xul

This should load a small application window and point you to a website!

And by the way, did you notice how fast it loaded? It loads much faster than a browser window.

Okay, so what is this? Well, did you know that Ubuntu's help system, yelp, is built it in it?

That's just the sample. It's also just pointing you to Google. Imagine if it were your thick client app and it pointed to a local website on the same workstation, hosted with lighthttpd (embedded with your app), loaded with a standalone PHP-CGI, loaded with SQLite. Now all of a sudden this is a powerful interface. For instance, the website could be http://127.0.0.1:30832/myapp/.

Now imagine if you could go a few different routes with this:

* Add menus and toolbars and all kinds of widgets into the XUL file to provide a richer client experience. The downside -- having to use ECMAScript to interact with it.

* Add all interface elements from the PHP page and style them with CSS or put some ECMAScript in the PHP page to enhance it.

And that, my friends, is how to build a thick client / fat client / rich client on Linux (as well as Mac, Windows) using Firefox.

Therefore, and I'm sure you know where this is going. Think of the opportunities:

* For all those applets you wanted to make on Linux but were afraid to learn Python, PyGTK, WxWidgets, Qt, or some other API -- you now have an option to forget about them. Just edit this little XUL file with new properties and point it to your local web app hosted through lighthttpd, PHP4-CGI, and SQLite.

* The ability to put a window in any corner of the screen (much like alerts or chat windows), using ECMAScript to move the window there.

* The ability to make a really robust thick client application on Linux with nothing but web skills.

* The ability to build an application that works on Linux, Mac, and Windows with some small modification to the PHP code.

* The ability to leverage your PHP skills so that you can improve your Linux workstation with handy small or large applications.

Enjoy!

kode's picture
Offline
Joined: 2006-04-19

This could become a very interesting thread this week...

I just modified your XUL for my thick app, and it's beautiful!

I'll be modifying it further this week, and deploying it in the next round of updates.

I'm gone to LinuxWorld Toronto tomorrow (Apr 25th), but I'll be back to play on Wednesday...

supermike's picture
Offline
Joined: 2006-02-17

Now isn't that interesting. I actually helped someone in a significant way, simply by goofing around. Glad to hear it.

BTW, at XULPlanet, they show an example where I can include a Javascript page (or set of pages) as well as CSS instead of doing it inline in the XUL. However, my take on that is that I want the CSS and Javascript stuff to be pushed from the server, not built up in the client. That way, I can use this XUL script just to get the client attached and then move rapidly forward on doing things as if it were a web app. And if I want to make that web app look more like a rich client with menus and tabs, no problem -- I can simulate it in the web page. Other people, however, may want to actually use the XUL to build those menus and tabs, but not me. In fact, some people can use the XUL to go as far as building an Explorer-like interface. However, the more XUL elements that you introduce, the harder work you have to do with ECMAScript/Javascript to interact with that, and I'm not a fan of that.

Oh, and for the thoroughly confused reading this, when I say, "pushed from the server", regarding a rich/thick client, I'm actually talking about a local server, not a remote one.

free-zombie's picture
Offline
Joined: 2006-03-08

kode (on the combobox thing): nogo on konqueror. thus probably nogo on Safari as well.

supermike's picture
Offline
Joined: 2006-02-17

Driving home on my long 1 hour commute last night near midnight, I wondered what would happen if someone forked the code of PHP4 such that it was redeployable much easier with lighthttpd in CGI mode, and would have the necessary modules added on to be minimalistic but useful, as well as have hookups for SQLite. For anything else that this forked code was not powerful enough to include, they could either shell out to Bash and run some command there, or simply go with regular PHP4 or PHP5 in CGI mode. I would think it would be really useful if someone could do that. I may have to give it a look. I'm really rusty with C programming, but I just might learn how to custom compile a PHP that can run everything out of one single, non-standard directory, via lighthttpd, as well as only include those minimal things one really needs for a rich client.

And once that was achieved, then an exciting new rich client SDK could be built from this, and perhaps a wizard-interface, such that someone could run through the wizard and make a default XUL file, SQLite database (with or without string encryption), and lighthttpd/PHPCGI local webservice. The end user could then simply write the PHP scripts, flesh out the tables in the SQLite database, run the XUL chrome file through Firefox, and be off and running with rich client apps superfast.

Want to make the next "Quickbooks" for Linux? No problem with this technique.

kode's picture
Offline
Joined: 2006-04-19

I'm using a custom (static) compiled PHP binary as an installer / package manager for my linux distro -- it's not hard to get PHP down to the core so you can run it anywhere you want.

supermike's picture
Offline
Joined: 2006-02-17

Oh, dude, you have to tell me how you do that! And can I do it with PHP4 to keep it in a smaller footprint?

What I have is PHP4 and Apache for other web development I'm doing. But when I want to flip over and work on my rich client app, I want to be able to have this custom PHP4-CGI in a directory, hooked through lighthttpd (instead of Apache2), along with PHP4 mod that ties it to SQLite.

supermike's picture
Offline
Joined: 2006-02-17

Mark down 4/25/2006. That's the day I coined a new programming acronym, XPSL, which stands for:

XUL GUI
PHP CGI Code
SQLite Embedded Database
Lighthttpd Embedded Web Server

I'm going to work on a doc for Nuxified.org soon called, "Making Rich Client Apps on Linux with XPSL". The only catch is explaining how to bundle these together rapidly and get started using it.

That is, unless you can come up with something more clever with the acronym, and I'll go with that. Here's a jumble of letters:

XSLP
SXLP
SLXP
SLPX
SPLX
PSLX
PLSX
PLXS
...

Got anything catchier or will XPSL work just fine?

kode's picture
Offline
Joined: 2006-04-19

I'm back to work on my thick app tomorrow, and I'll be concentrating on building a menu object using the appropriate PHP/XUL/JS/CSS.

I think we might have the beginning of an all-new GUI development framework happening here.

I like PLXS -- you can say it like 'PLeXuS'.

Um... plxs.net is available... supermike?

Um again... plxs.com is Plexus Research company...

supermike's picture
Offline
Joined: 2006-02-17
Great, you're on the project

Great, you're on the project team.

Okay, PLeXuS appears to potentially get us in trouble on trademark. XPSL sort of sounds like XML and HTML, which was what caught on in my mind. What do you think?

Yep, we have a whole new framework here, about to begin. If I could just learn the steps to building an SDK, I could put one out on the web in DEB and RPM format so that you would do something like:

$ sudo vi /etc/apt/sources.list

Put in reference to a freeware APT server I have commandeered.

$ sudo apt-get update
$ sudo apt-get install xpsl
$ sudo whereis xpsl

/usr/share/xpsl, /usr/bin/xpsl

$ xpsl --installsdk /home/me/xpsl
$ cd xpsl
$ ./startsdk

A wizard would then open up (built with XPSL of course) asking you what you want to name your project, where you want to put your project files. It asks you what web port you want to use or randomly comes up with one in the 54000-58000 range. It then creates the project directory, drops in an XUL file designed to go to the port you want, builds a SQLite database with no tables in it, drops a <myapp>.conf file for you to configure and reuse, and creates a default index.php page. It then tells you what to do to finish the code, how to launch your app, and tells you about a readme for redeploying your app. It then quits and launches the default "hello, world" app. It uses the .conf file to demonstrate how to read/write to that. Oh, and I guess we should build at least one dummy table ('names') so that end users know how to read/write to that too.

Devs then create tables in SQLite, edit the index.php and other PHP pages, add items that they want to read/write in the <my app>.conf file, and finish the app.

When finished, they could read the DEPLOY.TXT file to understand license requirements and how to run a tool to build an installer.

The installer is another XPSL app? Or would it be better to do it in C? Or what about PyGTK? Anyway, the end user runs the installer and it ungzips and untars the app into their /usr/share directory and sticks a Bash file in /usr/bin to run the app. The user also has the option to override this and install it simply in their /home/me directory. It then offers to show a README.TXT and/or to launch the app.

free-zombie's picture
Offline
Joined: 2006-03-08

XPLS can be pronouced as x pals

or SLXP - with a 1337speek x->ck transformation that makes SLiCK Php

supermike's picture
Offline
Joined: 2006-02-17

Do I have takers on the new XUL, Lighthttpd, SQLite, PHP rich client platform being called SLXP, pronounced "Slick PHP"? I guess I need to put it to vote.

libervisco's picture
Offline
Joined: 2006-05-04

Interesting... I don't exactly know what you guys just came up with (since I don't really know anything about XUL stuff), but it sounds like something interesting. Smiling

Well.. maybe that article you write about it supermike will enlighten me. Anyway, keep it up! :-)

kode's picture
Offline
Joined: 2006-04-19

I vote 'no'...

What if I want to write an app in Pike, Python, Ruby, Bash, Perl, etc? Nothing about this is PHP specific...

Dunno what to call it with that in mind...

supermike's picture
Offline
Joined: 2006-02-17

kode: Ah, so you think the framework needs to be XUL, Lighthttpd, SQLite, and whatever language you want to hook up via CGI? The problem is that compiling a specialized install of Lighthttpd and PHP is not a whimsical exercise. It's some serious work.

kode's picture
Offline
Joined: 2006-04-19

I just did it in less than an hour... did I miss something?

free-zombie's picture
Offline
Joined: 2006-03-08

SLXP -> SLX?
like SLXPy (python), SLXR (ruby) etc etc
SLXP(hp) could just be the default distribution method...

Offline
Joined: 2006-05-04

There's a small http server that's built for embedding at http://zild.org/index.csp . I haven't used it, but came accross it when I wanted to do the same thing. It can run PHP through SAPI i think as can just about anythhing. And the last poster is correct, don't limit the project to only PHP.
There are different approaches; I think you could build a firefox plugin /xpi, or you could do the work of building an RPM, or XAMPP that works like XAMPP. Java isn't FOSS at the moment, but there are XPIs that can do all this , there's even a PHP interpereter written in java by caucho.

thing about XUL is that it's not AJAX and the thing about AJAX is that it's not Flash, and the thing about Flash is that it's not a rich client.

But it'd be great to have a compact and complete embeddable webserver like XAMPP in a way.

Just some random thoughts for cannon fodder.

supermike's picture
Offline