Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
GUI PHP Programming Software IT Technology

Skinnable, Portable Desktop Apps In PHP 36

joeldg writes "With the new Zend coding contest getting underway, a lot of PHP coders are hacking out some amazing new test code. In that vein and in response to the lack of skinning with PHP-GTK apps, I just finished up writing a tutorial with source code for doing skinnable desktop applications in PHP that run on both Linux and Windows."
This discussion has been archived. No new comments can be posted.

Skinnable, Portable Desktop Apps In PHP

Comments Filter:
  • Slashdot (Score:4, Funny)

    by coyote4til7 ( 189857 ) on Monday June 14, 2004 @08:25PM (#9425852) Homepage
    ... leading cheerleader for in-appropriate php apps
    • Re:Slashdot (Score:4, Interesting)

      by JabberWokky ( 19442 ) <slashdot.com@timewarp.org> on Monday June 14, 2004 @09:51PM (#9426396) Homepage Journal
      Several of my CLI apps are now PHP. It is a good language for interfacing to databases and especially good at creating CLI tools to manage websites written in PHP. From there it was a natural jump to do things like manage my mp3 collection in PHP, a couple cron jobs and things like that.

      PHP compiled in CLI mode is pretty good as a quick tool to make other tools. I'm a die hard shell scripter, but the need to interface with web facing code on many servers led me down the path of using it, and it has really proven to be fairly good. There's a lag on slow machines when first executed, as it compiles to memory whenever a script is executed, and that's about my only complaint.

      --
      Evan "Not as portable as sh, not as common as perl"

      • Re:Slashdot (Score:1, Insightful)

        by Anonymous Coward
        Would it be that much of a intellectual hurdle to switch to Perl, where you can leverage CPAN? You know, the whole "right tool, right job" mantra?

        Syntatically they might as well be the same langauge except the hash and array symbols.
        • Would it be that much of a intellectual hurdle to switch to Perl, where you can leverage CPAN?

          To accompany the addition of the CLI interface to PHP in 4.3.x, the PEAR [php.net] repository was created. It is very much CPAN-like with a couple hundred [php.net] maturing PHP OOP modules. Noteworthy among them is a DB module [php.net] that provides database abstraction. Installing modules is as easy as

          pear install MODULE

          from the command line.

          Currently you aren't seeing PEAR used much because of its late addition to the 4.x seri

        • No, syntactically, they are not the same language. They are very different. Yes, they both use $'s. So do accountants. Thats really about it. PHP is much more rigid, much better defined, and much much easier to read.

          Which isn't to say that perl doesn't have it's place -- it does: one liners written to mangle up some text.

          -T
    • Re:Slashdot (Score:3, Interesting)

      by joeldg ( 518249 )
      I think it is quite appropriate saying it is for 'rapid' prototyping of windowed apps that can be used by both the developers (linux) and managers (windows) and they are both looking at the same thing.
      Besides, in this situation you don't have to have the windows people going in and logging into the unix machines via putty or whatever to see the ncurses version of the monitor.
      Just have them download php-gtk which is practically a plugin at this point and they can create desktop icons or whatever for the app.
    • Re:Slashdot (Score:2, Insightful)

      by turnin ( 698827 )
      >in-appropriate php apps
      you are correct, BUT, the struggle for existence will force us to take many directions, independent of the appropriateness.
      The struggle here is to find a means to deliver apps on to multiple platforms(OSs).
      Existence of such a means are getting closed, due to *PURE* commercial interests.
      The developers are finding those means for their better life, appropriate or in-appropriate doesn't matter here.
  • by Guspaz ( 556486 ) on Monday June 14, 2004 @08:43PM (#9425989)
    This is probably a good time to mention EncPHP, a program I wrote that encapsulates a PHP script along with most of what it needs to run inside an EXE. Both console and GUI PHP apps are supported, though for GUI apps, if you choose to embed all of GTK inside the app, it's going to be huge.

    It hasn't been updated in ages, but you can check out the latest version here: EncPHP on SourceForge [sourceforge.net]

    The sourcecode is included... it uses a free BASIC compiler to dynamically compile a dependance-free EXE with the PHP script, PHP interpreter, and required DLLs, inside an EXE. When the EXE is run, it extracts it all and runs the PHP script with the parameters passed on the command line. There are some simple options you can add to the start of your PHP script to tell it to include other files, and if it is a console or GUI app (to show or hide a console).
    • "When the EXE is run, it extracts it all and runs the PHP script with the parameters passed on the command line. There are some simple options you can add to the start of your PHP script to tell it to include other files, and if it is a console or GUI app (to show or hide a console)."

      So your saying this is basicly a self-extracting archive that executes when run? PriadoBlender [priadoblender.com] (not for production use still in alpha) is a open-source php-compilier/packager that uses the cross-platform PHP Embed API and P

      • Pretty much, yeah, it's a glorified self-extracting archive. Of course, you can't acheive the same functionality with WinZIP or WinRAR, as they can't hide the PHP console for GUI apps, or pass command line parameters to the PHP script.

        I'm sure all those programs are vastly superior to mine; Mine was only a kludge designed to fill a specific need to which I could not find a usable solution.

        I should point out that my program, EncPHP, which was released under the LGPL, predates PriadoBlender by over a month;
      • One small advantage my crappy program has, it runs under Win9x, unlike PriadoBlender :p

        Regardless, portable PHP applications seem to be making progress since I first started messing with it. Soon I might switch over all my Windows development from C# to PHP. All I code is personal projects anyhow.
  • by bergeron76 ( 176351 ) * on Monday June 14, 2004 @09:28PM (#9426272) Homepage
    What ever happened to PHP-Qt? I saw an implementation of it a few years ago, and it's since been stagnant...

    Anyone know what's up with that?

    • I'm gonna venture and say that PHP-Qt is not as attractive as PHP-GTK. The PHP people probably want PHP-GTK to spread as far as possible, or at least cross equally well between Windows and Linux. And Qt has those licensing issues for commercial apps on Windows.
  • ...NOOOOOOOO!

    As much as PHP might be a decent language for writing server-side web logic, PHP is Perl rewritten by people who don't grok Perl [ukuug.org]. Unfortunately, I have yet to find a webpage-embedded language that I like enough to replace PHP.

    • Or perhaps it's simply another language written by people who do not want to have the issues that perl has, and perhaps want a language that lends itself to knowing what you were doing 15 minutes after you started doing it.

      Go away perl fanboy, or come up with somethingbetter, after all TIMTOWTT (There Is More Then On Way To Troll).

      -T
      • Face it; PHP is the 'slower' little brother of Perl.

        No language that puts the ENTIRE standard library in the global namespace is suited for actually writing applications. I mean, if you're going to stuff your namespace full of crap, can't you at least make the naming conventions consistant?
      • Or perhaps it's simply another language written by people who do not want to have the issues that perl has, and perhaps want a language that lends itself to knowing what you were doing 15 minutes after you started doing it.

        Oh, come on. On what planet does it make sense to require e.g. generating SWF (Macromedia Flash) files to either be built in to the core language, or excluded altogether requiring a recompile to install that functionality?

        Is adding a use Module; line *really* that much harder for a

        • You have 'NO' idea what you are talking about.
          take a look at http://us2.php.net/manual/en/function.dl.php
          whic h is the function to load a PHP extension at runtime. ...
          • I have 'EVERY' idea what I'm talking about. I've f***ing written loadable modules in C for PHP -- which, BTW, has absolutely no namespace support other than manually naming every function "foo" as "module_foo" (and thus being unable to shorten it by importing the namespace). I've also read the entire PHP manual from start to finish. Don't go telling me that I'm not aware of PHP's language "features".

            • From:
              Oh, come on. On what planet does it make sense to require e.g. generating SWF (Macromedia Flash) files to either be built in to the core language, or excluded altogether requiring a recompile to install that functionality?
              Specifically:
              "either be built in to the core language, or excluded altogether requiring a recompile to install that functionality"
              Is a complete untrue statement, I dynamically load modules all the time in code where in places (I.e. dedicated hosting platforms) I do not want to c
              • The extension modules that come with PHP go to extraordinary lengths to keep them from being compiled independently of building a new copy of PHP, even if you're just trying to build them as extensions for an existing PHP. It's not like Perl where you can just do a perl -MCPAN -e 'install Package::Name', or Apache where you can use the APXS tool to easily build outside the Apache tree. It's *possible*, but it's extraordinarily creaky. Plus, it's impossible to install it for only one host in a virtual hos

  • I added a few things, thoughts etc from people on the NYPHP list and others who have contacted me.
    I added in a few base functions for doing XPM alpha-blending as well as the output from Glade to see how easy it would be to write a Glade->php-gtk parser.

    As for the "perl duuudes" on here, perl is fine for what it is, I use it. However, in this particular instance perl is not an option as I work in a PHP shop and this is actually a project for my work.. On that note however, I 'have' been steadily replacin
  • Tahya al-Moqawama al-Iraqiya!
    Fuck the American imperialists!
    Death to them all!!

We are each entitled to our own opinion, but no one is entitled to his own facts. -- Patrick Moynihan

Working...