PHP Cross-Platform Desktop GUI Framework | Hacker News Reader

PHP Cross-Platform Desktop GUI Framework

github.com

147 pointspsykovsky67 comments

Can i just say that clearly everyone knows its not the best tool for an actual serious project, but theres nothing wrong with whimsy. Its fun to do things because you can, that doesnt mean its going to become a serious tool. We just had a story about "Stupid Projects From The Stupid Hackathon"[1], just because its not a serious tool doesnt mean we should be throwing the hate, lets just take it for what it is, a bit of fun and a project you do because you can.

[1] https://news.ycombinator.com/item?id=8621886

The problem with whimsical projects is that eventually people make things in them thinking they are serious, and then other people have to maintain said things.

kind of like javascript (originally created in 10 days)...[1]

Eventually if people like the core idea, these things enter a positive feedback loop and the quality goes up. If nobody likes it or uses it...no harm.

[1] https://www.w3.org/community/webed/wiki/A_Short_History_of_J...

well, some people would argue javascript is [still] a mess. Douglas Crockford has spent a career pointing out a lot of the weak spots (while still loving the language mind you). PHP started out as a non-serious project, and today it's had some serious problems (multi-threading to name one).

However, on the other hand, there are also projects that start out as non-serious and get serious quick - the Linux kernel comes to mind.

I guess it can go two ways, but I'd contend a project that is started out with short-cuts because the author doesn't anticipate or plan for it to scale, will have a much tougher time doing so.

>(multi-threading to name one)

This isn't a problem in 5.5+ if you know what you're doing. That the language has a lot of people with no idea what they're doing is a testament to the fact PHP is easy to use and most others aren't for a novice, not that the language sucks.

I'm not the biggest PHP fan but since 5.3 most of the criticisms are unwarranted.

> PHP started out as a non-serious project, and today it's had some serious problems (multi-threading to name one).

What's the multi-threading problem? The engine is thread-safe.

it wasn't always... that is a relatively new thing.

Isn't that how PHP was created in the first place? And it just caught liek wildfire ... the rest is history as they say

No PHP was not created as "stupid project" (meaning knowingly not a good idea), it was a very real project for Rasmus meant for his own webpages and after with a few other people. He merely didn't expect so many people to start using too.

Originally he was not creating a language, but a set a scripts for common features.

>then other people have to maintain said things.

No they don't.

Well, it's the responsibility of the people who think some implementation requires this library to maintain it themselves, and as such whether or not that secondary implementation is intractable or not shouldn't really have any bearing on evaluation of OP's project... I could agree with this precautionary argument if somehow you were being forced to create/maintain such an application (for your job or something), but otherwise there's no difference.

>and then other people have to maintain said things.

Only if they chose to. Last time I checked, developers aren't slaves.

>Can i just say that clearly everyone knows its not the best tool for an actual serious project, but theres nothing wrong with whimsy.

Besides it just starting and not having a big community atm, I don't see nothing "clear" about it now being "the best tool for an actual serious project".

Is it the "eww PHP" knee-jerk reaction some people have?

This is really cool. We have a few internal automation scripts built with PHP but its a pain to train non-technical users on using the command line. This would make it very easy to create a simple UI and make those tools more accessible, not to mention easier to bundle and distribute.

I agree. I inherited some perl scripts around my work, and getting users up and running on them is kinda a pain (plus playing find the cpan depenency...)

New functionality is in php on the internal site which makes distributing better. Another way to distribute tools though is not a bad thing.

I used Zenity to provide some dialogs to PHP scripts with little effort.

When it said "GUI framework", I kind of expected a way to make cross-platform apps with their native UI controls, not a web view with an embedded PHP executable.

Bindings with native GUI would have been great.

Can you list some native UI controls that you'd like to use but can't recreate in HTML? I am writing a similar framework and would like to know the use-cases for doing this.

Edit: besides Window and Menu, of course

You can recreate almost anything in css/html but you'd have to write a different style for each OS yourself, and it will never match the actual "feel" of the UI. It'll be a little off.

Also, for example Mac OS X has lots of little widgets like the share button.

Maybe someone could make a Bootstrap-like project for these kinds of things?

There's tint2 for doing native apps with JS.

I recently spent an afternoon trying to get a webapp to accept drag and drop emails from outlook. I didn't manage. I am considering making a native app to interact.

maybe see wxPHP [1]

[1] http://wxphp.org/

There used to be a GTK binding for PHP. It wasn't a good idea then, and I don't see how it is now as a self-contained web app.

http://gtk.php.net/ - it was a noble effort but I think they all hit the same realization we expect and everyone walked away 4 years ago.

The only "realization" they hit was that both GTK and the port was poorly maintained in most platforms.

If it was better done and with more manpower, there would be absolutely no problem with people using it...

I can see this being pretty useful for utility type apps on the desktop. If you already have a lot invested in PHP then it seems like it would be really comfortable. Since it's basically just running a local server, it's going to be just like writing a web app except (I assume) with access to the local file system and system calls.

There's a few comments here about using native GUI widgets and such but I think that's a tricky approach. Dealing with long-running state of a native app seems very un-PHP. I consider myself fairly experienced with PHP but I'm not familiar with creating background threads with PHP which you'd need for a responsive GUI.

My greatest fear with all of these various wrapper frameworks is that they become abandoned. With a node.js/Javascript one at least there are several out there and the code is likely to be portable from one to the next. With this PHP one, you'd be committed to Nighttrain.

There is pthreads, PCNTL on posix systems, and Semaphores. The Implementation is pretty basic, but it works. The main issue are no native framework bindings other than the very old PHP-GTK... (edit, just read about wxPHP and QT...whoops)

Honestly, I still have a soft spot for PHP, mainly because its so easy to develop small things quickly. I'd love to see it move into other applications, much like JavaScript has...but the world is against the language, so I dont see that happening.

A cool. I knew there was some type of thread support. I figured most PHP devs would be more comfortable with the short running "page" concept rather than diving into threads and long-running stateful apps.

Anyway, I feel the same way about PHP. It's simple and easy and if you use it for the right job then it just works great. I think a lot of the hate is based on old, sloppy PHP code. Modern PHP apps are organized and use frameworks that don't look radically different from more popular languages.

The problem with things like pthreads in PHP is that 98% of the time your runtime is via mod_php5, and spinning threads off of an Apache worker instance is one of the worst ideas imaginable.

I (once, ignorantly) tried to do some kind of super lightweight background-like worker with pthreads in PHP instead of bringing in a full queue and worker design and it turned out that there is absolutely 0 capability of doing it with the slightest hint of sanity. Having libraries like that is cool, but it's not for what PHP was designed for: web pages. Arguably and controversially, web applications are even a stretch for the language, but the support is and has been getting better with actual classes, namespaces, and tooling support like Composer and agreed-upon libraries like Doctrine. Then again, I just fled a company who's entire infrastructure was dependent on cronjobs running tasks using relational databases as queuing mechanisms with very little use of ORMs. It doesn't really matter if the language gets better, because the bar isn't really getting raised, unfortunately. After making the language more desirable (which has been done), a community effort needs to be made to shame and call out bad code, which might end up requiring a jump to 6.0 finally and breaking backwards compatibility with everything that's changed since 4.x (mysql_escape_string, mysql_x instead of mysqli_x or PDO, etc.) At least non-parseable code isn't going to fester bad practices.

> 98% of the time your runtime is via mod_php5

Not true anymore, a lot of code is running in php-fpm nowadays.

yea that is kinda what I was thinking as far as why native GUI widgets wouldn't be a good idea - because that leads down the path of long-running stateful UI process which I think is very un-PHP in lots of ways!

First it's not a GUI Framework,it's a webview that uses a Python GUI framework with a PHP server. I bet one could create the exact same tool on top of node-webkit,since you'll be basically running a server.

The hell,you could do the exact same stuff with next to no "serverside" javascript by launching a PHP server yourself in node-webkit,with the advantage of using a better webview because i'm pretty sure the one used in wxPython is pretty old.

edit:s/bindings/server

HTML/CSS is a GUI framework and besides you said it yourself:

Python GUI framework with PHP "bindings"

I don't think you should be dismissive of what the OP has done. You clearly believe this should be done differently. If that's the case I encourage you to spend your time and effort to do so just as the OP did. And then be brave enough to post your work on HN just as the OP was.

I feel the title isnt accurate.

> HTML/CSS is a GUI framework

Sure,it's just not WPF,Flex,Swing,Gtk or whatever.That's what I expect when I hear GUI framework.

Just because I found the title of this news vague doesnt mean I'm dismissive of anything.

Finally I just pointed out that it's likely the webview used in that project wont run any modern javascript lib or framework.

node-webkit runs Webgl and all the latest web techs

I don't understand why this would not be a good idea for some of the commenters here. It can be useful to develop something for the desktop without learning c++ or c# (even if c# is rather easy), Adobe Air is not a solution of course. Yes it's a webview but how many developers know how to create a web app ? More than c#/c++/java/...

I enjoy projects like this (and others like node-webkit and cordova) because it lets me build prototypes relatively quick for my company (an ad agency). I'm strongest in HTML/CSS/JS and PHP so I don't have to spend time learning another language for something that is meant to be a demo anyways. I always tell them that if they want to get serious with one of the prototypes that we'd have to look into doing it the proper way. Although sometimes a project can be simple enough to just continue using it.

It is nice and everything, but don't really see the point. By the look of it is just a webview + a server running on localhost:8000.

Much rather prefer using node-webkit for this kind of desktop app (note: PHP is my go-to language)

Isn't node-webkit basically the same thing? If php is your goto language, why not use this?

Because people love to shit on whatever they can

node-webkit lets me fiddle with the chrome + i have the ability to install packages with npm.

I can see this being used in internal systems (to replace command line commands for non-technical colleges) but can't see the value in actual end user products

not to mention that the webview this one uses on windows is MSIE 7.0 which is less than ideal for front-end development

As people are noting, there are other GUI toolkits for PHP. In fact there is growing interest in using PHP for more than just web apps, and I think this is only going to increase as PHP develops further as a general purpose language, and more and more non-web libraries mature. Then again I may be biased [1]

[1] http://www.phpbeyondtheweb.com

I think the title is a bit misleading; proper GUI frameworks currently available for PHP are wxPHP (working, and you may export PHP code from wxFormBuilder), Qt (experimental, I think) and GTK (probably abandoned).

About the title, see my other reply: https://news.ycombinator.com/item?id=8631506

I wish there was something like this for Haskell :(... Currently I'm aware of threepenny-gui[0], but that launches in the actual browser (correct me if I'm wrong), which isn't exactly what you'd want.

[0] https://hackage.haskell.org/package/threepenny-gui

Found this recently. Bindings for Haskell to Chromium Embedded Framework:

* https://github.com/fluffynukeit/bindings-cef3

* https://code.google.com/p/chromiumembedded/

I should maybe add that the main reason I posted this project to HN was I noticed they need a push, i.e.: contributors.

Oh, yeah, about the submission title, I couldn't find anything that described it better, even after a lot of head scratching. No, I'm not eloquent, I know... ;)

I can't think of many use cases for this but it does look like a cool project.

This is a good project, it opens the desktop platform to PHP developers.

I am no fan of PHP myself and for this kind of requirement I would use node-webkit which provides seamless integration of the webview and host JS (node.js)

But the most important thing here is that it opens the doors to desktop programming to PHP devs and therefore we may see more useful apps for the desktop being developed, previously some PHP devs may have had some interesting concepts for the desktop but they weren't able to make them happen due to their lack of skills or time to learn GUI programming.

See also PHPDesktop: https://code.google.com/p/phpdesktop/

anyone else remember WinBinder [1] or wxPHP [2]?

[1] http://winbinder.org/ (inactive since '10)

[2] http://wxphp.org/ (active)

I shuddered when I saw this. It was like looking at the inverse of Java Applets. While interesting as a flight of fancy for the developer; I would hope a real GUI toolkit would be used for a serious application.

Seems to work by using Python's wx module for html display. I cannot find info on what kind of HTML5/CSS3/JS support it has, anyone know?

Looks like a clone of node-webkit. What are the serious frameworks for cross platform GUI these days??

This is really a good question. I haven't done any native GUI in quite some time, but last time I did Qt and WxWidgets were sort of "top tier" for cross platform. Are people still largely on these, are are there better alternatives now?

@PHP_CEO is going to be ecstatic...

How is this different than MacGap etc.?

Looks awesome! Any examples though?

Worst idea ever.

> Create your next OS X, Windows or Linux desktop application in pure PHP

No, thank you.

More specifically, I spent last Saturday setting up PocketMine (a Minecraft server) for my kids. This remarkable piece of engineering is a console app done completely in PHP and one of the first things it logged was "Can't keep up! Is the server overloaded?". That's a completely idle server on a beefy box. And all I could think was how regrettable it was that a clearly capable programmer voluntarily painted himself in a corner by picking a language that wasn't fit for the job. Same thing with GUI in PHP - yes, it's doable, yes, there's probably a demand for it, but this demand is misplaced and misguided and it's not worth of endorsing. It's like giving devs a heavier weight to sink deeper into a tar pit instead of giving them a rope for getting out. Desktop apps should never ever be written in PHP unless it's some sort of quick and disposable hack, which is likely not what this project has in mind.

>Same thing with GUI in PHP

I'd more call it a GUI in HTML/CSS/JS. PHP is just for the backend.

I understand that. It's a clever and elegant hack and I appreciate it, but ultimately it is not a viable cross-platform desktop app development option, which is, however, what it says on a tin.

That is, I have a problem with the labeling, not the contents.

In what way is the labeling misrepresenting what it accomplishes?

I don't see anywhere in the documentation where it boasts as being more viable or comparing itself to other options in any way.

the "Can't keep up!" error is common in a regular minecraft server, so it may not have as much to do with the fact that pocketmine was written in php. Although, i could be completely wrong about this (probably).

Nope, you're not wrong. That's part of minecraft and had nothing to do with PHP. I have a 200 meg server.log file that was run on a dedicated server, and in it there are 570,000 lines that say that -- out of 2,461,927. In other words, 23%.

Yes, because programs written in all other kinds of languages don't write stupid messages and don't have BS bugs...

And to dispell the ignorance and knee jerk reaction, the message comes from Minecraft, not his PHP code itself:

http://minecraftserverhq.com/blog/can't-keep-up/

I'd rather hire an engineer that doesn't blame a language because of ignorance, and even knows how to Google to find out the root cause.

Reply on news.ycombinator.com