Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #4516 > unrolled thread

approaches to PHP-based application interface?

Back to article view | Back to comp.lang.php

Contents

  approaches to PHP-based application interface? crankypuss <no@email.thanks> - 2012-01-19 04:18 -0700
    Re: approaches to PHP-based application interface? The Natural Philosopher <tnp@invalid.invalid> - 2012-01-19 15:00 +0000
      Re: approaches to PHP-based application interface? crankypuss <no@email.thanks> - 2012-01-20 01:53 -0700
        Re: approaches to PHP-based application interface? "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-20 10:27 +0100
          Re: approaches to PHP-based application interface? crankypuss <no@email.thanks> - 2012-01-20 02:43 -0700
            Re: approaches to PHP-based application interface? "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-20 11:05 +0100
              Re: approaches to PHP-based application interface? Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-01-20 11:37 +0100
                Re: approaches to PHP-based application interface? The Natural Philosopher <tnp@invalid.invalid> - 2012-01-20 11:04 +0000
                  Re: approaches to PHP-based application interface? Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-01-20 12:24 +0100
                    Re: approaches to PHP-based application interface? The Natural Philosopher <tnp@invalid.invalid> - 2012-01-20 11:34 +0000
                      Re: approaches to PHP-based application interface? Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-20 07:03 -0500
                      Re: approaches to PHP-based application interface? Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-01-20 13:13 +0100
        Re: approaches to PHP-based application interface? Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-01-20 10:43 +0100
          Re: approaches to PHP-based application interface? crankypuss <no@email.thanks> - 2012-01-20 05:21 -0700
            Re: approaches to PHP-based application interface? Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-01-20 14:46 +0100
    Re: approaches to PHP-based application interface? "Peter H. Coffin" <hellsop@ninehells.com> - 2012-01-21 12:10 -0600
    Re: approaches to PHP-based application interface? Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-01-26 16:12 +0100

#4516 — approaches to PHP-based application interface?

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.

[toc] | [next] | [standalone]

#4526

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.

[toc] | [prev] | [next] | [standalone]

#4530

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.

[toc] | [prev] | [next] | [standalone]

#4531

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.

[toc] | [prev] | [next] | [standalone]

#4533

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.

[toc] | [prev] | [next] | [standalone]

#4534

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.

[toc] | [prev] | [next] | [standalone]

#4537

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

[toc] | [prev] | [next] | [standalone]

#4538

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.

[toc] | [prev] | [next] | [standalone]

#4539

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

[toc] | [prev] | [next] | [standalone]

#4540

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
> 

[toc] | [prev] | [next] | [standalone]

#4541

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@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#4542

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

[toc] | [prev] | [next] | [standalone]

#4532

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

[toc] | [prev] | [next] | [standalone]

#4543

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.

[toc] | [prev] | [next] | [standalone]

#4546

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

[toc] | [prev] | [next] | [standalone]

#4555

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

[toc] | [prev] | [next] | [standalone]

#4626

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web