Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
PHP Programming

PHP 5 Release Sparks Up PHP-GTK 2.0 44

Posted by simoniker from the inhale-exhale dept.
joeldg writes "Since the release of PHP5 a lot of interest has reverberated down through the whole PHP community. In particular, there's a call for a PHP-GTK 2.0 which will utilize GTK2 and will have an entire rewrite of it from the ground up to make use of new features. Additionally there is an open call to help add to the documentation and to help with the website, post to and join the php-gtk-general mailing list to follow along with the activity. The forthcoming PHP-GTK version 2.0 will bind GTK+ 2 to PHP 5. Until then, PHP-GTK 1.0.0 works only with PHP 4."
This discussion has been archived. No new comments can be posted.

PHP 5 Release Sparks Up PHP-GTK 2.0 More

PHP 5 Release Sparks Up PHP-GTK 2.0

Comments Filter:

  • I still want a wxWindows binding (Score:3, Interesting)

    by dJCL ( 183345 ) on Wednesday July 21, 2004 @07:37PM (#9765669) Homepage
    sure, writing gui code in a web language is more an entertaining trick then really good practice... but I'd still prefer a binding to wxWindows(or whatever they have decided to rename it too) then just gtk...

    That's one of the reasons I bothered to learn python, so I could write once, run anywhere and the code would look native on any given gui

    ah well

  • I am running a PHP project at Uberhacker.Com [uberhacker.com] . The goal of the project is to promote secure PHP programmming. The need has grown due to the recent popularity of the language and the short learning curve which allowed many unexperienced scriptors on the internet.
  • With the new class features, Qt and PHP would go well together.

    PHP is the nicest language I know, aside from Javascript. With both I can just think about the data and it arranges it that way. I don't have to deal with the low level issues.

    Qt does the same for windowing.

    It'd be a match made in heaven. For those that want Qt+Javascript, look at KJSEmbed. It's a stnadard part of KDE Bindings.

    • Re:I still want a Qt binding (Score:5, Funny)

      by DAldredge ( 2353 ) <SlashdotEmail@GMail.Com> on Thursday July 22, 2004 @12:08AM (#9767184) Journal
      "PHP is the nicest language I know, aside from Javascript."

      That's sad, thats really really really sad. You have NO idea how sad that is, but trust me, it's sad.

      Sad so so sad.

      • Re:I still want a Qt binding (Score:4, Insightful)

        by scorp1us ( 235526 ) on Thursday July 22, 2004 @07:49AM (#9768748) Journal
        LOL. Even I laughed.

        Well, you have a low UID, so I can't dismiss you right off the bat. ;-) But I've tried the following:
        C, C++, Java, JavaScript, Perl, Python, BASIC (and variant) Fortran, Pascal, and ASM. I've red about LISP, but have yet to actually write in it; though I think its right up my alley.

        I've been around the block enough to not care about the low-level implementation issues. The older you get the less you care about re-inventing the wheel, and you just want to get things to work and get on to the next thing. That's why Linux is turning me off. I just want to install it and get the damned thing working, so I can get working. No etitinf fstab or my Xfree86 config file. No recompiling the kernel, etc. I come back to it periodically and I have to say It's made great strides, so I'm more interested than ever. Programming is very much like that. The more times you've been around the block, the more times you've been down that road, the faster you just want to get where you're going to get your task done. If I'm writing s/w for the space shuttle, I don't want to have to be insmoding drivers, unless I an writing them myself.

        So when I said PHP and JS are nice, it is because they (like most scriping langs) don't bother me with low level implementation issues (unless I want to be bothered by them).

        The other great observation I've made in my many years, is that it's not about the code, it's about the data. C is really bad at allocating memory and designing data structures. PHP and JS make that trivially easy.

        I am a firmware devloper. I work in C 99% of the time. When I'm writing support software for the C code, I do it in some scripting language because it takes 20 times less to develop and I have no performance constraints. For the stuff I'm doing now, I have my scripts generate C files. I also generare SQL files from PHP structures.

        JS and PHP may have thier quirks but such annoyances are [usually] inconsequntial. Dealing with a quirk or too is more time-saving than doing it in a strict, clean language like C.

        What this is all getting to is that PHP and JS are great languages to me and my job. Or, IOW, YMMV.
        • I have to agree with the immediate parent. I've written substantial code in everything from C to Lisp to Python to vimscript, and I have found that for actually getting things done, especially when there's a good library binding available, languages like python, javascript, and php are my platform of choice.

          sure, there have been times I've wanted to do something and couldn't, or couldn't easily--but more often than not, its a function of ignorance, rather than a deficit in the language. and yeah, there a
  • Someone wake me when Apache 2.0 support stabilizes for production use. Yes, that includes the database drivers and other support libraries. It's been two years since Apache 2.0 went stable. I mean c'mon.

    Oh yeah, namespaces would be nice too.
    • I agree with you that 2 years out is just too long to sit around waiting for a fix. From everything that I've read, its not the core of PHP that is incompatible with Apache 2 threading, but its the various misc modules. The PHP group needs to step up to the plate and make a hard decision. They should declare the incompatible modules depreciated and stop distributing them until they are fixed. That will be the only thing that motivates the module maintainers to get off their duffs and get the darn things f
    • I guess this would be a good time to puth forth Rasmus Lerdorf's excellent explanation [theaimsgroup.com] for this issue. In short, due to there being many many different packages and applications and libs on Linux, and not ALL of them being threadsafe, I don't see anytime soon that Apache 2 will be "stable".
      • First off, Apache 2 is stable. PHP -- the underlying libraries, but much the same from a user point of view -- on Apache 2 is not stable. That was another pet peave about the PHP page warning not to use Apache 2 in a production environment. The implication to someone who doesn't know the underlying architecture differences is that Apache 2 is faulty. It is not.

        The major feature that draws people to Apache2 is threading. On Windows where most basic libraries are, and must be, threadsafe, Apache2 does

      • Apache project's priorities largely focus on java. If you can get perl cgi's or php to run, fine, but Apache is being designed with java in mind (check the project list at www.apache.org - it's java java java.

        The PHP group should just write its own minimal web server designed exclusively to run PHP so that PHP can run "standalone" without Apache.
        • You know if you are going to point out a list, perhaps, just maybe, you should read the damn thing first.

          http://perl.apache.org/

          mod_perl gives you a persistent Perl interpreter embedded in your web server. This lets you avoid the overhead of starting an external interpreter and avoids the penalty of Perl start-up time, giving you super-fast dynamic content.

          As you'd expect from the Perl community, there are hundreds of modules written for mod_perl, everything from persistent database connections, to templ
          • And apparently the Perl folks can get a working model running with Apache 2 even though they're using the same underlying libraries as PHP. Hmmm...
    • Someone wake me when Apache 2.0 support stabilizes for production use. Yes, that includes the database drivers and other support libraries. It's been two years since Apache 2.0 went stable. I mean c'mon.

      I figured that since Apache2.0 was an RPM on Fedora Core 1 that it was "stable". Boy, was that a mistake. I very quickly ran into a strange memory problem, where a php value passed via the httpd.conf would get passed randomly to other sites as well.

      Caused no end of grief, until I rpm -e the apache binarie
      • You're using a threading web server with PHP, a scripting environment whose underlying libraries are NOT threadsafe, and you are running into random problems.

        What a coincidence!

        Did you try the prefork MPM or did you just assume Apache was to blame?

  • I've long thought web browsers could use better interactive vector graphics, fancier widgets, etc.

    Does PHP-GTK provide this only on the server side?

    Does any of the functionality overlap with what could be provided using SVG, JavaScript and XForms (or even XUL)?

  • C# (Score:1)

    by TPoise ( 799382 )
    Okay, just use C#/Mono and be done with it.

  • PHP was designed with websites in mind. I've googled and am unable to come up with an answer to a pretty basic question: does PHP5 even have a garbage collector?

    Python has mature GTK/GNOME bindings and a much more developer-friendly syntax than PHP. Not to mention, it takes virtually no time to learn the language.

    Why not use the right tool for the job?

    • Python has mature GTK/GNOME bindings and a much more developer-friendly syntax than PHP. Not to mention, it takes virtually no time to learn the language.

      Why not use the right tool for the job?

      I did - using PHP-GTK. I have a rather large, distributed, server-based application. The client programs are written in PHP-GTK, and periodically sync up with the server. Everything is in PHP, so getting the clients and servers to communicate was not only easy, they use the exact same functions and API to communica

      • A "Garbage collector" is simply irrelevant to PHP. Memory management is taken care of for you.

        That was my question. Memory management is taken care of when PHP is run as a server in a simplistic way: it allocates memory as it needs it, and then deallocates everything when the process is complete. When PHP is run as a memory-resident application, it needs to be able to keep track of which variables are no longer referenced so that it can free up their memory; otherwise it will keep growing and growing in

Slashdot Top Deals

"jackpot: you may have an unneccessary change record" -- message from "diff"

Close