| approaches to PHP-based application interface? [message #176706] |
Thu, 19 January 2012 11:18  |
crankypuss
Messages: 147
Registered: March 2011
Karma: 0
|
Senior Member |
|
|
I'm not even sure how to ask the question. Maybe it's several questions.
Supposing one wants to run a local apache server that supports a
PHP-based system interface, things like file editing, file management,
archive support, and various other applications. For some things like
file management it may need root privileges. It also needs to be "safe"
so that the applicable parts of it can run on a public server. Are
there approaches to this that have been successfully used in the past?
One major advantage of sticking with PHP is that my fairly large
codebase won't need to be rewritten. The html/browser paradigm is
perfectly adequate to all the things that I can foresee doing. On
Windows there is this thing, http://www.zzee.com/php-gui/
What it does is let you plug your PHP browser-based application into a
stripped-down browser so it runs as a Windows application without any
apache involvement. But I wish to do this on Linux.
Failing both those approaches, can anyone recommend a good GUI package
that supports PHP applications, preferrably something gtk-based?
Sorry this is such a scattered question. Basically I'm working on
building a system-independent PHP-based system front-end, parts of which
can be made available on a public web server.
|
|
|
|
| Re: approaches to PHP-based application interface? [message #176716 is a reply to message #176706] |
Thu, 19 January 2012 15:00  |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
crankypuss wrote:
> I'm not even sure how to ask the question. Maybe it's several questions.
>
> Supposing one wants to run a local apache server that supports a
> PHP-based system interface, things like file editing, file management,
> archive support, and various other applications. For some things like
> file management it may need root privileges. It also needs to be "safe"
> so that the applicable parts of it can run on a public server. Are
> there approaches to this that have been successfully used in the past?
>
> One major advantage of sticking with PHP is that my fairly large
> codebase won't need to be rewritten. The html/browser paradigm is
> perfectly adequate to all the things that I can foresee doing. On
> Windows there is this thing, http://www.zzee.com/php-gui/
> What it does is let you plug your PHP browser-based application into a
> stripped-down browser so it runs as a Windows application without any
> apache involvement. But I wish to do this on Linux.
>
> Failing both those approaches, can anyone recommend a good GUI package
> that supports PHP applications, preferrably something gtk-based?
>
> Sorry this is such a scattered question. Basically I'm working on
> building a system-independent PHP-based system front-end, parts of which
> can be made available on a public web server.
well look at webmin first, before you decide to 'go php' for everything.
There are good reasons NOT to be TOTALLY php as well.
Vis if the whole php regime has 'root access' ten you are in deep
trouble if someone hacks the php layer.
Better to write specific tools in - say C - that are expressly 'su root'
type programs designed to edit just one part of the installation.
So you might write a C program that can READ any file in /var/log with
any permissions, but not WRITE one. So as to get to your log files for
example. But not alter them.
That the way we access mysql - we cant from php access the raw data
files, but mysqld is a daemon that can, and we talk to that...
Miking this easier for yourself always makes it easier for an
incompetent or malicious person to screw things up as well.
|
|
|
|
| Re: approaches to PHP-based application interface? [message #176720 is a reply to message #176716] |
Fri, 20 January 2012 08:53 |
crankypuss
Messages: 147
Registered: March 2011
Karma: 0
|
Senior Member |
|
|
On 01/19/2012 08:00 AM, The Natural Philosopher wrote:
> crankypuss wrote:
>> I'm not even sure how to ask the question. Maybe it's several questions.
>>
>> Supposing one wants to run a local apache server that supports a
>> PHP-based system interface, things like file editing, file management,
>> archive support, and various other applications. For some things like
>> file management it may need root privileges. It also needs to be
>> "safe" so that the applicable parts of it can run on a public server.
>> Are there approaches to this that have been successfully used in the
>> past?
>>
>> One major advantage of sticking with PHP is that my fairly large
>> codebase won't need to be rewritten. The html/browser paradigm is
>> perfectly adequate to all the things that I can foresee doing. On
>> Windows there is this thing, http://www.zzee.com/php-gui/
>> What it does is let you plug your PHP browser-based application into a
>> stripped-down browser so it runs as a Windows application without any
>> apache involvement. But I wish to do this on Linux.
>>
>> Failing both those approaches, can anyone recommend a good GUI package
>> that supports PHP applications, preferrably something gtk-based?
>>
>> Sorry this is such a scattered question. Basically I'm working on
>> building a system-independent PHP-based system front-end, parts of
>> which can be made available on a public web server.
>
> well look at webmin first, before you decide to 'go php' for everything.
>
> There are good reasons NOT to be TOTALLY php as well.
>
> Vis if the whole php regime has 'root access' ten you are in deep
> trouble if someone hacks the php layer.
>
> Better to write specific tools in - say C - that are expressly 'su root'
> type programs designed to edit just one part of the installation.
>
> So you might write a C program that can READ any file in /var/log with
> any permissions, but not WRITE one. So as to get to your log files for
> example. But not alter them.
>
> That the way we access mysql - we cant from php access the raw data
> files, but mysqld is a daemon that can, and we talk to that...
>
>
> Miking this easier for yourself always makes it easier for an
> incompetent or malicious person to screw things up as well.
"Webmin is a web-based interface for system administration for Unix."
I'm not really much interested in "system administration", but thanks
for the thought.
What I'm really looking at is more about replacing user interfaces like
Ubuntu's Unity with something "browser-based" but which does not require
an apache server.
And I'm not looking to grant everyuser the privileges of root for that
matter, just not wanting to restrict those who have access to root
privileges via sudo for example.
I'm starting to wonder if what Firefox calls a content-plugin could be
used to recognize php and invoke the interpreter to run a file in the
user's available realm in the "non-cli" mode that apache runs php in.
Apache can't very well determine what user on localhost has sent it a
request, as far as I've been able to find. Maybe there's some way to
determine that based on the remote-user's port number but I'd really
prefer not even to have apache involved if I can avoid it.
I found php-gtk but it doesn't seem very much alive.
Still scratching my head on this one. It isn't even clear to me why
most every browser supports client-side javascript but client-side php
is an unmentionable. In a nutshell it may be that what I'm looking for
is a browser that supports client-side php.
|
|
|
|
| Re: approaches to PHP-based application interface? [message #176721 is a reply to message #176720] |
Fri, 20 January 2012 09:27 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 20.01.2012 09:53, schrieb crankypuss:
> On 01/19/2012 08:00 AM, The Natural Philosopher wrote:
>> crankypuss wrote:
>>> I'm not even sure how to ask the question. Maybe it's several questions.
>>>
>>> Supposing one wants to run a local apache server that supports a
>>> PHP-based system interface, things like file editing, file management,
>>> archive support, and various other applications. For some things like
>>> file management it may need root privileges. It also needs to be
>>> "safe" so that the applicable parts of it can run on a public server.
>>> Are there approaches to this that have been successfully used in the
>>> past?
>>>
>>> One major advantage of sticking with PHP is that my fairly large
>>> codebase won't need to be rewritten. The html/browser paradigm is
>>> perfectly adequate to all the things that I can foresee doing. On
>>> Windows there is this thing, http://www.zzee.com/php-gui/
>>> What it does is let you plug your PHP browser-based application into a
>>> stripped-down browser so it runs as a Windows application without any
>>> apache involvement. But I wish to do this on Linux.
>>>
>>> Failing both those approaches, can anyone recommend a good GUI package
>>> that supports PHP applications, preferrably something gtk-based?
>>>
>>> Sorry this is such a scattered question. Basically I'm working on
>>> building a system-independent PHP-based system front-end, parts of
>>> which can be made available on a public web server.
>>
>> well look at webmin first, before you decide to 'go php' for everything.
>>
>> There are good reasons NOT to be TOTALLY php as well.
>>
>> Vis if the whole php regime has 'root access' ten you are in deep
>> trouble if someone hacks the php layer.
>>
>> Better to write specific tools in - say C - that are expressly 'su root'
>> type programs designed to edit just one part of the installation.
>>
>> So you might write a C program that can READ any file in /var/log with
>> any permissions, but not WRITE one. So as to get to your log files for
>> example. But not alter them.
>>
>> That the way we access mysql - we cant from php access the raw data
>> files, but mysqld is a daemon that can, and we talk to that...
>>
>>
>> Miking this easier for yourself always makes it easier for an
>> incompetent or malicious person to screw things up as well.
>
> "Webmin is a web-based interface for system administration for Unix."
>
> I'm not really much interested in "system administration", but thanks for the thought.
>
>
> What I'm really looking at is more about replacing user interfaces like Ubuntu's
> Unity with something "browser-based" but which does not require an apache server.
Not very convincing. Browser based GUIs are far behind the possibilities of a true
GUI like Qt or Gtk+ or Tk.
You want to carry over the browser like link n click to the desktop? MS is on this
way with all the management consoles, and it is as fast as flowing rubber.
Start some true GUI programming and you will see there is nothing to win in the way
you think now.
/Str.
|
|
|
|
| Re: approaches to PHP-based application interface? [message #176722 is a reply to message #176720] |
Fri, 20 January 2012 09:43 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 1/20/2012 9:53 AM, crankypuss wrote:
> On 01/19/2012 08:00 AM, The Natural Philosopher wrote:
>> crankypuss wrote:
>>> I'm not even sure how to ask the question. Maybe it's several questions.
>>>
>>> Supposing one wants to run a local apache server that supports a
>>> PHP-based system interface, things like file editing, file management,
>>> archive support, and various other applications. For some things like
>>> file management it may need root privileges. It also needs to be
>>> "safe" so that the applicable parts of it can run on a public server.
>>> Are there approaches to this that have been successfully used in the
>>> past?
>>>
>>> One major advantage of sticking with PHP is that my fairly large
>>> codebase won't need to be rewritten. The html/browser paradigm is
>>> perfectly adequate to all the things that I can foresee doing. On
>>> Windows there is this thing, http://www.zzee.com/php-gui/
>>> What it does is let you plug your PHP browser-based application into a
>>> stripped-down browser so it runs as a Windows application without any
>>> apache involvement. But I wish to do this on Linux.
>>>
>>> Failing both those approaches, can anyone recommend a good GUI package
>>> that supports PHP applications, preferrably something gtk-based?
>>>
>>> Sorry this is such a scattered question. Basically I'm working on
>>> building a system-independent PHP-based system front-end, parts of
>>> which can be made available on a public web server.
>>
>> well look at webmin first, before you decide to 'go php' for everything.
>>
>> There are good reasons NOT to be TOTALLY php as well.
>>
>> Vis if the whole php regime has 'root access' ten you are in deep
>> trouble if someone hacks the php layer.
>>
>> Better to write specific tools in - say C - that are expressly 'su root'
>> type programs designed to edit just one part of the installation.
>>
>> So you might write a C program that can READ any file in /var/log with
>> any permissions, but not WRITE one. So as to get to your log files for
>> example. But not alter them.
>>
>> That the way we access mysql - we cant from php access the raw data
>> files, but mysqld is a daemon that can, and we talk to that...
>>
>>
>> Miking this easier for yourself always makes it easier for an
>> incompetent or malicious person to screw things up as well.
>
> "Webmin is a web-based interface for system administration for Unix."
>
> I'm not really much interested in "system administration", but thanks
> for the thought.
>
>
> What I'm really looking at is more about replacing user interfaces like
> Ubuntu's Unity with something "browser-based" but which does not require
> an apache server.
>
> And I'm not looking to grant everyuser the privileges of root for that
> matter, just not wanting to restrict those who have access to root
> privileges via sudo for example.
>
> I'm starting to wonder if what Firefox calls a content-plugin could be
> used to recognize php and invoke the interpreter to run a file in the
> user's available realm in the "non-cli" mode that apache runs php in.
>
> Apache can't very well determine what user on localhost has sent it a
> request, as far as I've been able to find. Maybe there's some way to
> determine that based on the remote-user's port number but I'd really
> prefer not even to have apache involved if I can avoid it.
>
> I found php-gtk but it doesn't seem very much alive.
>
Just a "me too!".
I have been looking into this also, without success.
I tried php-gtk and gave up on it. After a few days fiddling around with
it I only became frustrated.
> Still scratching my head on this one. It isn't even clear to me why most
> every browser supports client-side javascript but client-side php is an
> unmentionable. In a nutshell it may be that what I'm looking for is a
> browser that supports client-side php.
That ZZEE sounds promising indeed. But W$ only.
http://www.zzee.com/php-gui/
Drawback is possibly that it is IE-based. It uses the IE installed on
the system of the one that executes the ZZEE-program.
That means you have to be careful with your HTML (in case of IE6 or
something like that) if you distribute the program.
I gave up on it and decided to go with Java. QT is another option, but I
knew how to program in Java already, so that was the obvious choice.
If you find anything, please let us know in here. :-)
Good luck.
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
| Re: approaches to PHP-based application interface? [message #176723 is a reply to message #176721] |
Fri, 20 January 2012 09:43 |
crankypuss
Messages: 147
Registered: March 2011
Karma: 0
|
Senior Member |
|
|
On 01/20/2012 02:27 AM, M. Strobel wrote:
> Am 20.01.2012 09:53, schrieb crankypuss:
>> On 01/19/2012 08:00 AM, The Natural Philosopher wrote:
>>> crankypuss wrote:
>>>> I'm not even sure how to ask the question. Maybe it's several questions.
>>>>
>>>> Supposing one wants to run a local apache server that supports a
>>>> PHP-based system interface, things like file editing, file management,
>>>> archive support, and various other applications. For some things like
>>>> file management it may need root privileges. It also needs to be
>>>> "safe" so that the applicable parts of it can run on a public server.
>>>> Are there approaches to this that have been successfully used in the
>>>> past?
>>>>
>>>> One major advantage of sticking with PHP is that my fairly large
>>>> codebase won't need to be rewritten. The html/browser paradigm is
>>>> perfectly adequate to all the things that I can foresee doing. On
>>>> Windows there is this thing, http://www.zzee.com/php-gui/
>>>> What it does is let you plug your PHP browser-based application into a
>>>> stripped-down browser so it runs as a Windows application without any
>>>> apache involvement. But I wish to do this on Linux.
>>>>
>>>> Failing both those approaches, can anyone recommend a good GUI package
>>>> that supports PHP applications, preferrably something gtk-based?
>>>>
>>>> Sorry this is such a scattered question. Basically I'm working on
>>>> building a system-independent PHP-based system front-end, parts of
>>>> which can be made available on a public web server.
>>>
>>> well look at webmin first, before you decide to 'go php' for everything.
>>>
>>> There are good reasons NOT to be TOTALLY php as well.
>>>
>>> Vis if the whole php regime has 'root access' ten you are in deep
>>> trouble if someone hacks the php layer.
>>>
>>> Better to write specific tools in - say C - that are expressly 'su root'
>>> type programs designed to edit just one part of the installation.
>>>
>>> So you might write a C program that can READ any file in /var/log with
>>> any permissions, but not WRITE one. So as to get to your log files for
>>> example. But not alter them.
>>>
>>> That the way we access mysql - we cant from php access the raw data
>>> files, but mysqld is a daemon that can, and we talk to that...
>>>
>>>
>>> Miking this easier for yourself always makes it easier for an
>>> incompetent or malicious person to screw things up as well.
>>
>> "Webmin is a web-based interface for system administration for Unix."
>>
>> I'm not really much interested in "system administration", but thanks for the thought.
>>
>>
>> What I'm really looking at is more about replacing user interfaces like Ubuntu's
>> Unity with something "browser-based" but which does not require an apache server.
>
> Not very convincing. Browser based GUIs are far behind the possibilities of a true
> GUI like Qt or Gtk+ or Tk.
>
> You want to carry over the browser like link n click to the desktop? MS is on this
> way with all the management consoles, and it is as fast as flowing rubber.
>
> Start some true GUI programming and you will see there is nothing to win in the way
> you think now.
>
> /Str.
Thank you for your opinion, but I've done "true GUI programming" and
I've had a bellyful of talking paper-clips and wiggling icons.
|
|
|
|
| Re: approaches to PHP-based application interface? [message #176724 is a reply to message #176723] |
Fri, 20 January 2012 10:05 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 20.01.2012 10:43, schrieb crankypuss:
> On 01/20/2012 02:27 AM, M. Strobel wrote:
>> Am 20.01.2012 09:53, schrieb crankypuss:
>>> On 01/19/2012 08:00 AM, The Natural Philosopher wrote:
>>>> crankypuss wrote:
>>>> > I'm not even sure how to ask the question. Maybe it's several questions.
>>>> >
>>>> > Supposing one wants to run a local apache server that supports a
>>>> > PHP-based system interface, things like file editing, file management,
>>>> > archive support, and various other applications. For some things like
>>>> > file management it may need root privileges. It also needs to be
>>>> > "safe" so that the applicable parts of it can run on a public server.
>>>> > Are there approaches to this that have been successfully used in the
>>>> > past?
>>>> >
>>>> > One major advantage of sticking with PHP is that my fairly large
>>>> > codebase won't need to be rewritten. The html/browser paradigm is
>>>> > perfectly adequate to all the things that I can foresee doing. On
>>>> > Windows there is this thing, http://www.zzee.com/php-gui/
>>>> > What it does is let you plug your PHP browser-based application into a
>>>> > stripped-down browser so it runs as a Windows application without any
>>>> > apache involvement. But I wish to do this on Linux.
>>>> >
>>>> > Failing both those approaches, can anyone recommend a good GUI package
>>>> > that supports PHP applications, preferrably something gtk-based?
>>>> >
>>>> > Sorry this is such a scattered question. Basically I'm working on
>>>> > building a system-independent PHP-based system front-end, parts of
>>>> > which can be made available on a public web server.
>>>>
>>>> well look at webmin first, before you decide to 'go php' for everything.
>>>>
>>>> There are good reasons NOT to be TOTALLY php as well.
>>>>
>>>> Vis if the whole php regime has 'root access' ten you are in deep
>>>> trouble if someone hacks the php layer.
>>>>
>>>> Better to write specific tools in - say C - that are expressly 'su root'
>>>> type programs designed to edit just one part of the installation.
>>>>
>>>> So you might write a C program that can READ any file in /var/log with
>>>> any permissions, but not WRITE one. So as to get to your log files for
>>>> example. But not alter them.
>>>>
>>>> That the way we access mysql - we cant from php access the raw data
>>>> files, but mysqld is a daemon that can, and we talk to that...
>>>>
>>>>
>>>> Miking this easier for yourself always makes it easier for an
>>>> incompetent or malicious person to screw things up as well.
>>>
>>> "Webmin is a web-based interface for system administration for Unix."
>>>
>>> I'm not really much interested in "system administration", but thanks for the
>>> thought.
>>>
>>>
>>> What I'm really looking at is more about replacing user interfaces like Ubuntu's
>>> Unity with something "browser-based" but which does not require an apache server.
>>
>> Not very convincing. Browser based GUIs are far behind the possibilities of a true
>> GUI like Qt or Gtk+ or Tk.
>>
>> You want to carry over the browser like link n click to the desktop? MS is on this
>> way with all the management consoles, and it is as fast as flowing rubber.
>>
>> Start some true GUI programming and you will see there is nothing to win in the way
>> you think now.
>>
>> /Str.
>
> Thank you for your opinion, but I've done "true GUI programming" and I've had a
> bellyful of talking paper-clips and wiggling icons.
Yeah. But the forced limitations in web design is not the solution.
It's like in music. When you learn mastering your instrument(s), you will play
faster, more complicated (like pressing 20 keys on the piano at a time), play only in
variations of the leitmotiv without repeating yourself, perfection syncopation...
This will most often be hard to listen to. The simple melodies are best, played with
a master touch.
/Str.
|
|
|
|
| Re: approaches to PHP-based application interface? [message #176727 is a reply to message #176724] |
Fri, 20 January 2012 10:37 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 1/20/2012 11:05 AM, M. Strobel wrote:
> Am 20.01.2012 10:43, schrieb crankypuss:
<snip>
>> Thank you for your opinion, but I've done "true GUI programming" and I've had a
>> bellyful of talking paper-clips and wiggling icons.
>
> Yeah. But the forced limitations in web design is not the solution.
Hi Strobel,
You cannot say that in such general terms.
If you are fluent in PHP and web-related technics, it is very tempting
to want more and develop desktop-apps using those technologies.
I know I want to.
Comparing them to slow M$ stuff makes no sense.
M$ seldom do things right.
>
> It's like in music. When you learn mastering your instrument(s), you will play
> faster, more complicated (like pressing 20 keys on the piano at a time), play only in
> variations of the leitmotiv without repeating yourself, perfection syncopation...
>
> This will most often be hard to listen to. The simple melodies are best, played with
> a master touch.
>
Erm.....
Poor analogy.
This situation is more like you DID master one instrument already
(PHP/html/javascript), and now you must master yet another just to make
a few sounds.
No matter how great that new instrument is, it will take a lot of time
to master it like your first.
Regards,
Erwin Moller
> /Str.
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
| Re: approaches to PHP-based application interface? [message #176728 is a reply to message #176727] |
Fri, 20 January 2012 11:04 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Erwin Moller wrote:
> On 1/20/2012 11:05 AM, M. Strobel wrote:
>> Am 20.01.2012 10:43, schrieb crankypuss:
>
> <snip>
>
>>> Thank you for your opinion, but I've done "true GUI programming" and
>>> I've had a
>>> bellyful of talking paper-clips and wiggling icons.
>>
>> Yeah. But the forced limitations in web design is not the solution.
>
> Hi Strobel,
>
> You cannot say that in such general terms.
> If you are fluent in PHP and web-related technics, it is very tempting
> to want more and develop desktop-apps using those technologies.
> I know I want to.
> Comparing them to slow M$ stuff makes no sense.
> M$ seldom do things right.
>
Look in philosophical terms what you are saying here is more or less 'I
want to use a browser and associated web server as my GUI API rather
than the underlying native GUI API'
Which is all fine and dandy if that GUI suits the application.
And is one accepts platform independent and WAN ready from the word 'go'.
BUT is not always the optimal paradigm, and usually means writing in
rather badly implemented and poor languages, that are deliberately
crippled for security reasons - javascript/PHP and the like.
That's not to say you can't write web apps but it is possibly making a
rod for your own back if you do.
|
|
|
|
| Re: approaches to PHP-based application interface? [message #176729 is a reply to message #176728] |
Fri, 20 January 2012 11:24 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 1/20/2012 12:04 PM, The Natural Philosopher wrote:
> Erwin Moller wrote:
>> On 1/20/2012 11:05 AM, M. Strobel wrote:
>>> Am 20.01.2012 10:43, schrieb crankypuss:
>>
>> <snip>
>>
>>>> Thank you for your opinion, but I've done "true GUI programming" and
>>>> I've had a
>>>> bellyful of talking paper-clips and wiggling icons.
>>>
>>> Yeah. But the forced limitations in web design is not the solution.
>>
>> Hi Strobel,
>>
>> You cannot say that in such general terms.
>> If you are fluent in PHP and web-related technics, it is very tempting
>> to want more and develop desktop-apps using those technologies.
>> I know I want to.
>> Comparing them to slow M$ stuff makes no sense.
>> M$ seldom do things right.
>>
>
>
> Look in philosophical terms what you are saying here is more or less 'I
> want to use a browser and associated web server as my GUI API rather
> than the underlying native GUI API'
>
Exactly.
That is exactly what I am saying.
>
> Which is all fine and dandy if that GUI suits the application.
Of course.
That goes without saying, I presumed.
If it didn't another approach would be advisable.
>
> And is one accepts platform independent and WAN ready from the word 'go'.
>
> BUT is not always the optimal paradigm, and usually means writing in
> rather badly implemented and poor languages, that are deliberately
> crippled for security reasons - javascript/PHP and the like.
"optimal paradigm" can mean anything, depending on the situation.
In case you need speed: Go C(++), or even assembly, and write smart fast
code.
In case you need supersmall memory footprint (like sometimes in embedded
software): Go assembly.
In case you want a very high level to approach a problem: Throw in some
framework, or do it yourself in some high level language.
etc.etc.
And I do not understand why you deem PHP a "deliberately crippled
language for security reasons", because it isn't.
Also, Javascript isn't crippled at all.
I think you are confusing Javascript implementation in browsers with the
language itself.
Of course the browser must "cripple" the language by not exposing
everything on the computer to the language.
Your way of thinking is like saying: "No animal can fly because I know
of a dog who cannot fly."
Javascript isn't a crippled language. It's implementation is browsers is
(luckily) "crippled". Big difference.
>
> That's not to say you can't write web apps but it is possibly making a
> rod for your own back if you do.
I am not sure what you mean by that.
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
| Re: approaches to PHP-based application interface? [message #176730 is a reply to message #176729] |
Fri, 20 January 2012 11:34 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Erwin Moller wrote:
> On 1/20/2012 12:04 PM, The Natural Philosopher wrote:
>> Erwin Moller wrote:
>>> On 1/20/2012 11:05 AM, M. Strobel wrote:
>>>> Am 20.01.2012 10:43, schrieb crankypuss:
>>>
>>> <snip>
>>>
>>>> > Thank you for your opinion, but I've done "true GUI programming" and
>>>> > I've had a
>>>> > bellyful of talking paper-clips and wiggling icons.
>>>>
>>>> Yeah. But the forced limitations in web design is not the solution.
>>>
>>> Hi Strobel,
>>>
>>> You cannot say that in such general terms.
>>> If you are fluent in PHP and web-related technics, it is very tempting
>>> to want more and develop desktop-apps using those technologies.
>>> I know I want to.
>>> Comparing them to slow M$ stuff makes no sense.
>>> M$ seldom do things right.
>>>
>>
>>
>> Look in philosophical terms what you are saying here is more or less 'I
>> want to use a browser and associated web server as my GUI API rather
>> than the underlying native GUI API'
>>
>
> Exactly.
> That is exactly what I am saying.
>
>
>>
>> Which is all fine and dandy if that GUI suits the application.
>
> Of course.
> That goes without saying, I presumed.
> If it didn't another approach would be advisable.
>
>>
>> And is one accepts platform independent and WAN ready from the word 'go'.
>>
>> BUT is not always the optimal paradigm, and usually means writing in
>> rather badly implemented and poor languages, that are deliberately
>> crippled for security reasons - javascript/PHP and the like.
>
> "optimal paradigm" can mean anything, depending on the situation.
> In case you need speed: Go C(++), or even assembly, and write smart fast
> code.
> In case you need supersmall memory footprint (like sometimes in embedded
> software): Go assembly.
> In case you want a very high level to approach a problem: Throw in some
> framework, or do it yourself in some high level language.
> etc.etc.
>
> And I do not understand why you deem PHP a "deliberately crippled
> language for security reasons", because it isn't.
>
well in the sense that apache or whatever invokes it with apaches own
privileges and the concept of a users own privileges is not inherent in it.
> Also, Javascript isn't crippled at all.
Perhaps you need to write more of it. It cannot access much at all. It
has no concept of full system access.
It cant even access a local printer..
> I think you are confusing Javascript implementation in browsers with the
> language itself.
> Of course the browser must "cripple" the language by not exposing
> everything on the computer to the language.
>
Of course thats what I mean. The language on its own as an intellectual
abstraction is as worthless as piece of used toilet paper when what you
have is a browser running (a usually highly buggy) implemenation of it.
> Your way of thinking is like saying: "No animal can fly because I know
> of a dog who cannot fly."
> Javascript isn't a crippled language. It's implementation is browsers is
> (luckily) "crippled". Big difference.
>
No, My stance is more 'pigs may fly, in theory, but I have yet to find
one that did'
>
>>
>> That's not to say you can't write web apps but it is possibly making a
>> rod for your own back if you do.
>
> I am not sure what you mean by that.
>
I am saying that when all you decide to use is a hammer, you may find
watchmaking a difficult task.
> Regards,
> Erwin Moller
>
|
|
|
|
| Re: approaches to PHP-based application interface? [message #176731 is a reply to message #176730] |
Fri, 20 January 2012 12:03 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 1/20/2012 6:34 AM, The Natural Philosopher wrote:
> Erwin Moller wrote:
>> On 1/20/2012 12:04 PM, The Natural Philosopher wrote:
>>> Erwin Moller wrote:
>>>> On 1/20/2012 11:05 AM, M. Strobel wrote:
>>>> > Am 20.01.2012 10:43, schrieb crankypuss:
>>>>
>>>> <snip>
>>>>
>>>> >> Thank you for your opinion, but I've done "true GUI programming" and
>>>> >> I've had a
>>>> >> bellyful of talking paper-clips and wiggling icons.
>>>> >
>>>> > Yeah. But the forced limitations in web design is not the solution.
>>>>
>>>> Hi Strobel,
>>>>
>>>> You cannot say that in such general terms.
>>>> If you are fluent in PHP and web-related technics, it is very tempting
>>>> to want more and develop desktop-apps using those technologies.
>>>> I know I want to.
>>>> Comparing them to slow M$ stuff makes no sense.
>>>> M$ seldom do things right.
>>>>
>>>
>>>
>>> Look in philosophical terms what you are saying here is more or less 'I
>>> want to use a browser and associated web server as my GUI API rather
>>> than the underlying native GUI API'
>>>
>>
>> Exactly.
>> That is exactly what I am saying.
>>
>>
>>>
>>> Which is all fine and dandy if that GUI suits the application.
>>
>> Of course.
>> That goes without saying, I presumed.
>> If it didn't another approach would be advisable.
>>
>>>
>>> And is one accepts platform independent and WAN ready from the word
>>> 'go'.
>>>
>>> BUT is not always the optimal paradigm, and usually means writing in
>>> rather badly implemented and poor languages, that are deliberately
>>> crippled for security reasons - javascript/PHP and the like.
>>
>> "optimal paradigm" can mean anything, depending on the situation.
>> In case you need speed: Go C(++), or even assembly, and write smart
>> fast code.
>> In case you need supersmall memory footprint (like sometimes in
>> embedded software): Go assembly.
>> In case you want a very high level to approach a problem: Throw in
>> some framework, or do it yourself in some high level language.
>> etc.etc.
>>
>> And I do not understand why you deem PHP a "deliberately crippled
>> language for security reasons", because it isn't.
>>
>
> well in the sense that apache or whatever invokes it with apaches own
> privileges and the concept of a users own privileges is not inherent in it.
>
>
Which has absolutely nothing to do with the language. But you don't
understand the difference.
>
>> Also, Javascript isn't crippled at all.
>
> Perhaps you need to write more of it. It cannot access much at all. It
> has no concept of full system access.
>
> It cant even access a local printer..
>
Which has absolutely nothing to do with the language. But you don't
understand the difference.
>> I think you are confusing Javascript implementation in browsers with
>> the language itself.
>> Of course the browser must "cripple" the language by not exposing
>> everything on the computer to the language.
>>
>
> Of course thats what I mean. The language on its own as an intellectual
> abstraction is as worthless as piece of used toilet paper when what you
> have is a browser running (a usually highly buggy) implemenation of it.
>
Which has absolutely nothing to do with the language. But you don't
understand the difference.
>> Your way of thinking is like saying: "No animal can fly because I know
>> of a dog who cannot fly."
>> Javascript isn't a crippled language. It's implementation is browsers
>> is (luckily) "crippled". Big difference.
>>
>
> No, My stance is more 'pigs may fly, in theory, but I have yet to find
> one that did'
>
>>
>>>
>>> That's not to say you can't write web apps but it is possibly making a
>>> rod for your own back if you do.
>>
>> I am not sure what you mean by that.
>>
>
> I am saying that when all you decide to use is a hammer, you may find
> watchmaking a difficult task.
>
>> Regards,
>> Erwin Moller
>>
But these are typical comments from you. No wonder you try to hide
behind a 'nym. You wouldn't want a possible employer to find out just
how stoopid you are.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: approaches to PHP-based application interface? [message #176732 is a reply to message #176730] |
Fri, 20 January 2012 12:13 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 1/20/2012 12:34 PM, The Natural Philosopher wrote:
> Erwin Moller wrote:
>> On 1/20/2012 12:04 PM, The Natural Philosopher wrote:
>>> Erwin Moller wrote:
>>>> On 1/20/2012 11:05 AM, M. Strobel wrote:
>>>> > Am 20.01.2012 10:43, schrieb crankypuss:
>>>>
>>>> <snip>
>>>>
>>>> >> Thank you for your opinion, but I've done "true GUI programming" and
>>>> >> I've had a
>>>> >> bellyful of talking paper-clips and wiggling icons.
>>>> >
>>>> > Yeah. But the forced limitations in web design is not the solution.
>>>>
>>>> Hi Strobel,
>>>>
>>>> You cannot say that in such general terms.
>>>> If you are fluent in PHP and web-related technics, it is very tempting
>>>> to want more and develop desktop-apps using those technologies.
>>>> I know I want to.
>>>> Comparing them to slow M$ stuff makes no sense.
>>>> M$ seldom do things right.
>>>>
>>>
>>>
>>> Look in philosophical terms what you are saying here is more or less 'I
>>> want to use a browser and associated web server as my GUI API rather
>>> than the underlying native GUI API'
>>>
>>
>> Exactly.
>> That is exactly what I am saying.
>>
>>
>>>
>>> Which is all fine and dandy if that GUI suits the application.
>>
>> Of course.
>> That goes without saying, I presumed.
>> If it didn't another approach would be advisable.
>>
>>>
>>> And is one accepts platform independent and WAN ready from the word
>>> 'go'.
>>>
>>> BUT is not always the optimal paradigm, and usually means writing in
>>> rather badly implemented and poor languages, that are deliberately
>>> crippled for security reasons - javascript/PHP and the like.
>>
>> "optimal paradigm" can mean anything, depending on the situation.
>> In case you need speed: Go C(++), or even assembly, and write smart
>> fast code.
>> In case you need supersmall memory footprint (like sometimes in
>> embedded software): Go assembly.
>> In case you want a very high level to approach a problem: Throw in
>> some framework, or do it yourself in some high level language.
>> etc.etc.
>>
>> And I do not understand why you deem PHP a "deliberately crippled
>> language for security reasons", because it isn't.
>>
>
> well in the sense that apache or whatever invokes it with apaches own
> privileges and the concept of a users own privileges is not inherent in it.
>
If you want PHP to run with different privileges/as another user, set it
up like that.
You wrote: "the concept of a users own privileges is not inherent in it"
Do you mean by user the visitor of some website? I hope not, because
that would make no sense at all.
If you mean the privileges for the PHP process under Apache, set it up
like that.
>
>
>> Also, Javascript isn't crippled at all.
>
> Perhaps you need to write more of it. It cannot access much at all. It
> has no concept of full system access.
>
> It cant even access a local printer..
From a browser? No, not directly (luckily and by design).
>
>> I think you are confusing Javascript implementation in browsers with
>> the language itself.
>> Of course the browser must "cripple" the language by not exposing
>> everything on the computer to the language.
>>
>
> Of course thats what I mean. The language on its own as an intellectual
> abstraction is as worthless as piece of used toilet paper when what you
> have is a browser running (a usually highly buggy) implemenation of it.
Maybe you should broaden your horizon a little.
Serverside javascript:
http://nodejs.org/docs/latest/api/all.html
Javascript (ECMAscript actually, contact our friend PointedEars for
details) isn't limited to a browser.
It is a language that can bind-to, manipulate, etc objects that are
exposed to it by the environment it is in.
>
>> Your way of thinking is like saying: "No animal can fly because I know
>> of a dog who cannot fly."
>> Javascript isn't a crippled language. It's implementation is browsers
>> is (luckily) "crippled". Big difference.
>>
>
> No, My stance is more 'pigs may fly, in theory, but I have yet to find
> one that did'
Then look at nodejs to see your "flying pig".
(It wasn't a pig in the first place in my opinion.)
>
>>
>>>
>>> That's not to say you can't write web apps but it is possibly making a
>>> rod for your own back if you do.
>>
>> I am not sure what you mean by that.
>>
>
> I am saying that when all you decide to use is a hammer, you may find
> watchmaking a difficult task.
Indeed it would be difficult, probably impossible.
But that isn't relevant.
Using the power of PHP/HTML/Javascript combination as a desktop
application would be great in my opinion, and that was what we were
discussing, I thought.
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
| Re: approaches to PHP-based application interface? [message #176733 is a reply to message #176722] |
Fri, 20 January 2012 12:21 |
crankypuss
Messages: 147
Registered: March 2011
Karma: 0
|
Senior Member |
|
|
On 01/20/2012 02:43 AM, Erwin Moller wrote:
> On 1/20/2012 9:53 AM, crankypuss wrote:
>> On 01/19/2012 08:00 AM, The Natural Philosopher wrote:
>>> crankypuss wrote:
>>>> I'm not even sure how to ask the question. Maybe it's several
>>>> questions.
>>>>
>>>> Supposing one wants to run a local apache server that supports a
>>>> PHP-based system interface, things like file editing, file management,
>>>> archive support, and various other applications. For some things like
>>>> file management it may need root privileges. It also needs to be
>>>> "safe" so that the applicable parts of it can run on a public server.
>>>> Are there approaches to this that have been successfully used in the
>>>> past?
>>>>
>>>> One major advantage of sticking with PHP is that my fairly large
>>>> codebase won't need to be rewritten. The html/browser paradigm is
>>>> perfectly adequate to all the things that I can foresee doing. On
>>>> Windows there is this thing, http://www.zzee.com/php-gui/
>>>> What it does is let you plug your PHP browser-based application into a
>>>> stripped-down browser so it runs as a Windows application without any
>>>> apache involvement. But I wish to do this on Linux.
>>>>
>>>> Failing both those approaches, can anyone recommend a good GUI package
>>>> that supports PHP applications, preferrably something gtk-based?
>>>>
>>>> Sorry this is such a scattered question. Basically I'm working on
>>>> building a system-independent PHP-based system front-end, parts of
>>>> which can be made available on a public web server.
>>>
>>> well look at webmin first, before you decide to 'go php' for everything.
>>>
>>> There are good reasons NOT to be TOTALLY php as well.
>>>
>>> Vis if the whole php regime has 'root access' ten you are in deep
>>> trouble if someone hacks the php layer.
>>>
>>> Better to write specific tools in - say C - that are expressly 'su root'
>>> type programs designed to edit just one part of the installation.
>>>
>>> So you might write a C program that can READ any file in /var/log with
>>> any permissions, but not WRITE one. So as to get to your log files for
>>> example. But not alter them.
>>>
>>> That the way we access mysql - we cant from php access the raw data
>>> files, but mysqld is a daemon that can, and we talk to that...
>>>
>>>
>>> Miking this easier for yourself always makes it easier for an
>>> incompetent or malicious person to screw things up as well.
>>
>> "Webmin is a web-based interface for system administration for Unix."
>>
>> I'm not really much interested in "system administration", but thanks
>> for the thought.
>>
>>
>> What I'm really looking at is more about replacing user interfaces like
>> Ubuntu's Unity with something "browser-based" but which does not require
>> an apache server.
>>
>> And I'm not looking to grant everyuser the privileges of root for that
>> matter, just not wanting to restrict those who have access to root
>> privileges via sudo for example.
>>
>> I'm starting to wonder if what Firefox calls a content-plugin could be
>> used to recognize php and invoke the interpreter to run a file in the
>> user's available realm in the "non-cli" mode that apache runs php in.
>>
>> Apache can't very well determine what user on localhost has sent it a
>> request, as far as I've been able to find. Maybe there's some way to
>> determine that based on the remote-user's port number but I'd really
>> prefer not even to have apache involved if I can avoid it.
>>
>> I found php-gtk but it doesn't seem very much alive.
>>
>
> Just a "me too!".
Thanks, it's good to know I'm not the only nut in this asylum! <g>
> I have been looking into this also, without success.
> I tried php-gtk and gave up on it. After a few days fiddling around with
> it I only became frustrated.
Sounds as though my instincts on that one were lucky for a change...
basically I couldn't find a debian-type repository, didn't want to build
from source, and didn't like the idea of an object-oriented interface,
so I decided to keep looking and thinking.
>> Still scratching my head on this one. It isn't even clear to me why most
>> every browser supports client-side javascript but client-side php is an
>> unmentionable. In a nutshell it may be that what I'm looking for is a
>> browser that supports client-side php.
>
> That ZZEE sounds promising indeed. But W$ only.
> http://www.zzee.com/php-gui/
> Drawback is possibly that it is IE-based. It uses the IE installed on
> the system of the one that executes the ZZEE-program.
If so, that's a change from the version I tried, it had a built-in browser.
> That means you have to be careful with your HTML (in case of IE6 or
> something like that) if you distribute the program.
I tried ZZEE a year or three back, and thought it was really quite good.
It used a built-in browser, but at the time it didn't provide the
basic "find" command, which I considered a significant issue for my
purposes. Since the browser is/was fixed/builtin, Microschmoo can do
whatever they want without affecting apps. But it's Windows-only, and
they want money for it... might be a good open-source project to build
such a thing, I dunno enough about gecko et-al to know how much work it
would be. But only fairly trivial mods were needed to make the
applicable parts of my existing web code work under it, all of them
related to system-identification and easily done.
I went to wampserver instead and was very satisfied with it for
developing on Windows, but now that I'm on Linux it's easy enough just
to install apache2 and php5.
> I gave up on it and decided to go with Java. QT is another option, but I
> knew how to program in Java already, so that was the obvious choice.
>
> If you find anything, please let us know in here. :-)
>
> Good luck.
> Regards,
> Erwin Moller
Thanks, Erwin.
I was forced at near-gunpoint about a decade ago to write a Java
application... ahem, not my cuppa, no further comment. <g>
After some little thought I've concluded that a content-plugin that
allowed client-side PHP would be a real can of worms since PHP is not
designed to be sandboxed like javascript.
The approach I'm currently considering is basically to have the web
server run as root, if a request is coming from offsystem su to a less
privileged userid, if it's an onsystem request determine who the userid
is that owns the incoming port and su to his userid. Sort of like
mod_userdir only for privileges. But I'm skittish about it and will
have to do lots of thinking before I actually go there.
Read your subthread about GUI and not-GUI and music and stuff... one of
the big reasons I'm doing this is to build the kind of interface that I
want to use, which does *not* mean clicking the mouse every time I want
to scratch something. There's a place for GUI certainly, and a place
for key-by-key interaction, but I can pick up enough key-by-key using
some javascript on the front-end. Whatever, eh? <g>
BTW, does anyone know how to code a Linux script that will use PHP if
it's installed but fall back to bash if not? There is probably some
funky combination of comment strings will do that but I don't yet know
what it is.
|
|
|
|
| Re: approaches to PHP-based application interface? [message #176736 is a reply to message #176733] |
Fri, 20 January 2012 13:46 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 1/20/2012 1:21 PM, crankypuss wrote:
> On 01/20/2012 02:43 AM, Erwin Moller wrote:
<snip>
>> Just a "me too!".
>
> Thanks, it's good to know I'm not the only nut in this asylum! <g>
>
Nope. :-)
But I fear PHP is poorly suited for such implementations.
If it was really easy, people would have made is somewhere.
>>
>> That ZZEE sounds promising indeed. But W$ only.
>> http://www.zzee.com/php-gui/
>> Drawback is possibly that it is IE-based. It uses the IE installed on
>> the system of the one that executes the ZZEE-program.
>
> If so, that's a change from the version I tried, it had a built-in browser.
>
From:
http://www.zzee.com/php-gui/help.html#zzee_link_25_1255218950
=======================================================
4.2. The built-in webbrowser
ZZEE PHP GUI has a webbrowser, which is based on Internet Explorer. It
conforms to that version of IE, which is installed on your computer.
Therefore it is highly compatible.
Because it deals primarily with trusted content, the browser runs with
high permissions and has enabled most of the things that a browser may
support, including:
Javascript
ActiveX
Flash
Image displaying
Session cookies
Availability of these features doesn't depend on whether they are turned
on or off in your Internet Explorer.
=======================================================
Sounds like ZZEE uses IE DLL's to me, since it "confirms to the version
installed".
But I am not sure. :-)
>
> The approach I'm currently considering is basically to have the web
> server run as root, if a request is coming from offsystem su to a less
> privileged userid, if it's an onsystem request determine who the userid
> is that owns the incoming port and su to his userid. Sort of like
> mod_userdir only for privileges. But I'm skittish about it and will have
> to do lots of thinking before I actually go there.
>
> Read your subthread about GUI and not-GUI and music and stuff... one of
> the big reasons I'm doing this is to build the kind of interface that I
> want to use, which does *not* mean clicking the mouse every time I want
> to scratch something. There's a place for GUI certainly, and a place for
> key-by-key interaction, but I can pick up enough key-by-key using some
> javascript on the front-end. Whatever, eh? <g>
>
> BTW, does anyone know how to code a Linux script that will use PHP if
> it's installed but fall back to bash if not? There is probably some
> funky combination of comment strings will do that but I don't yet know
> what it is.
Something like this maybe:
#!/bin/bash
PHPTEST=`which php`
if [$PHPTEST = ""]; then
echo "No PHP found"
else
echo "PHP Found in:" $PHPTEST
fi
save it as phptest for example.
Then chmod +x phptest
Then: ./phptest
See here for more info on BASH:
http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO.html
Of course, you'll have to replace my echo's with something sensible. ;-)
I am not sure how you are implementing it.
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
| Re: approaches to PHP-based application interface? [message #176745 is a reply to message #176706] |
Sat, 21 January 2012 18:10 |
Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Thu, 19 Jan 2012 04:18:19 -0700, crankypuss wrote:
> I'm not even sure how to ask the question. Maybe it's several questions.
>
> Supposing one wants to run a local apache server that supports a
> PHP-based system interface, things like file editing, file management,
> archive support, and various other applications. For some things like
> file management it may need root privileges. It also needs to be "safe"
> so that the applicable parts of it can run on a public server. Are
> there approaches to this that have been successfully used in the past?
>
> One major advantage of sticking with PHP is that my fairly large
> codebase won't need to be rewritten. The html/browser paradigm is
> perfectly adequate to all the things that I can foresee doing. On
> Windows there is this thing, http://www.zzee.com/php-gui/
> What it does is let you plug your PHP browser-based application into a
> stripped-down browser so it runs as a Windows application without any
> apache involvement. But I wish to do this on Linux.
>
> Failing both those approaches, can anyone recommend a good GUI package
> that supports PHP applications, preferrably something gtk-based?
>
> Sorry this is such a scattered question. Basically I'm working on
> building a system-independent PHP-based system front-end, parts of which
> can be made available on a public web server.
If nothing on
http://www.webresourcesdepot.com/category/goodies/file-folder/ meets
your needs, you may need to "unscatter" the question.
--
40. I will be neither chivalrous nor sporting. If I have an unstoppable
superweapon, I will use it as early and as often as possible instead
of keeping it in reserve.
--Peter Anspach's list of things to do as an Evil Overlord
|
|
|
|
| Re: approaches to PHP-based application interface? [message #176814 is a reply to message #176706] |
Thu, 26 January 2012 15:12 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 1/19/2012 12:18 PM, crankypuss wrote:
> I'm not even sure how to ask the question. Maybe it's several questions.
>
> Supposing one wants to run a local apache server that supports a
> PHP-based system interface, things like file editing, file management,
> archive support, and various other applications. For some things like
> file management it may need root privileges. It also needs to be "safe"
> so that the applicable parts of it can run on a public server. Are there
> approaches to this that have been successfully used in the past?
>
> One major advantage of sticking with PHP is that my fairly large
> codebase won't need to be rewritten. The html/browser paradigm is
> perfectly adequate to all the things that I can foresee doing. On
> Windows there is this thing, http://www.zzee.com/php-gui/
> What it does is let you plug your PHP browser-based application into a
> stripped-down browser so it runs as a Windows application without any
> apache involvement. But I wish to do this on Linux.
>
> Failing both those approaches, can anyone recommend a good GUI package
> that supports PHP applications, preferrably something gtk-based?
>
> Sorry this is such a scattered question. Basically I'm working on
> building a system-independent PHP-based system front-end, parts of which
> can be made available on a public web server.
Hi,
A late response, but I just ran into this:
http://en.wikipedia.org/wiki/PHP-Qt
I am working with QT from C++ right now and saw QT support for PHP (or
the other way around).
I never used PHP-QT, but QT is good.
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]