http://www.techworld.com.au/article/...urce_nx_server
http://www.eweek.com/c/a/Application...y-Apps-448913/

Since Chrome is in essence Linux and Open Source, might it be
economical to modify Chrome as a Pick front end that can be used in
the same room or over the web from any place in the world?

Designed a certain way, this could work for any database and once it
were used like for DB2 or MySql it would be much easier to create
interest in Pick.

Henry Keultjes
Mansfield Ohio USA

Henry, the purpose of a web browser is to render web pages. We don't
need to code into a specific browser, we just need to create web
pages. Anyone purchasing an application these days wants a
browser-based, Rich Internet Application. They don't want a green
screen, and they don't want a green screen rendered in a browser.

I find it ironic that people are moving from thick apps to the
browser, and then modern proposals run browsers that run as operating
systems. What's the real objective with any of this?

Maybe I'm missing something, Henry. Do you have a vision for
rendering an application which doesn't seem to be solved by standard
means?


hbkeultjeswrote:

On Aug 16, 3:54*am, Tony Gravagno <nos... (AT) nospam (DOT) invalid> wrote:
The steps/technology to "render" an image be that on the local PC
screen or the remote screen for a Linux or Linux/Pick application are
too complex period. An application works by "rendering" that
application in RAM so all I need is a way to see, printed or screen,
what's in RAM. That there have been hundreds, perhaps thousands,
perhaps millions of way to that is irrelevant to me. All I want to
is seeing it on a pixel screen and vector issues and such should be
irrelevant. As I have said many times, I am too uneducated in all
things IT to get hung up by these things. People like you and many
others on this Pick list have the knowledge to make this work.

Is Grigory still reading this list? Wasn't that Russion group
involved in the first GraPick or was that all Mark's work?

One thing I know for sure; X11 has to go!

Henry

Henry, I'm still not sure what problem you're trying to solve. Tell
us exactly what you'd like to do, what you'd like to see on a screen
from a user perspective, without using terms like RAM, Linux, and X11.

If you're not technical then why are you trying to solve a technical
problem, especially one that doesn't seem to exist? Browsers have
solved the issues related to creating a pleasant remote user
experience for all OS's. Granted, it's not StarTrek, but you're not
looking for a StarTrek experience anyway.

If you want to see your home PC screen from anywhere else, check into
LogMeIn, GoToMeeting, (Citrix) Remote Desktop, and similar desktop
sharing offerings - free and for-fee. I use these all the time
depending on the need.

GraPick was just another GUI generator. There are many others like it
these days, but better. Dave Zigray was on that project and he floats
around here once in a while.

You're combining a lot of apples n oranges here and no one seems to be
hungry for a fruit salad. Keep it simple. Rather than proposing
solutions and asking how they can work, tell us the problem and we can
probably recommend a solution that suits your style.

Regards,
T

On Aug 17, 3:37*pm, Tony Gravagno <nos... (AT) nospam (DOT) invalid> wrote:
Systemizing the Enterprise!

First, I am a Systems Architect, not a programmer. Like a building
architect, a Systems Architect does not have to be a "brick layer" or
a "carpenter" to understand the overall concept and purpose for the
system but (s)he is limited to using what exists. Thus I understand
how to use Pick for its only legitimate purpose which is increasing
productivity of the enterprise. Thus I was, over a roughly ten year
period, able to win my battles with series of Pick programmers to
achieve my goals because I held a paycheck over their head. Thus our
systemization resulted in roughly two and a half times the
productivity of the norm.

Since I have this great experience of increased productivity that is
badly needed in our economy, I attempt to explain to others that they
also can use Pick to systemize for *their* purposes. However, when
they look at the tools that they would need to use their eyes glaze
over.

So, Tony, ask yourself, is it my problem that I am not explaining it
well enough to either the potential Pick users or is it that I am not
holding a paycheck over the head of the Pick "carpenters" and "brick
layers" like yourself who are the ones that can make the system
functional in my image?

When I started my Pick Journey in about 1978 there were Microdata and
ADDS boxes and Wyse terminals and RS-232 wiring and such and new hires
were mostly amazed that we had no message pads simply because they did
not understand the other aspects of the system anyway. Therefore we
did not have to deal with new employees un-learning any computer
habits. Today everyone who comes into the workplace has too much
experience with computers. They all are used to working in a browser
and working with applications that are so very unproductive that the
abyss between that and Pick is too great to overcome unless something
gives.

So, just like I am constructing this message in a Mozilla browser,
"they" do not understand why "they" should not run Pick applications
in a browser and, quite frankly, I do not understand either but I am
keenly aware of Pick opportunities all around us that can not be
exploited until "they" see a familiar framework that gives them the
opportunity to exploit a better way to systemize the enterprise.

Thus, before me, at the beginning of the IT revolution, came a bunch
of Pick entrepreneurs who delivered a framework in which my
productivity concepts could flourish. Today the techy aspect of that
IT revolution is far ahead of us while in other ways it is sorely
behind. Are you seeing opportunity of fleshing out the Pick
productivity framework in Henry's image before others do that in
*their* image?

Henry Keultjes
Mansfield Ohio USA

Ok, I guess I'll be the one to ask...

".. I attempt to explain to others that they also can use Pick to systemize
...etc"

Is 'systemize' really a word?

dmm

"hbkeultjes" <hbkeultjes (AT) gmail (DOT) com> wrote

On Aug 17, 3:37 pm, Tony Gravagno <nos... (AT) nospam (DOT) invalid> wrote:
Systemizing the Enterprise!

First, I am a Systems Architect, not a programmer. Like a building
architect, a Systems Architect does not have to be a "brick layer" or
a "carpenter" to understand the overall concept and purpose for the
system but (s)he is limited to using what exists. Thus I understand
how to use Pick for its only legitimate purpose which is increasing
productivity of the enterprise. Thus I was, over a roughly ten year
period, able to win my battles with series of Pick programmers to
achieve my goals because I held a paycheck over their head. Thus our
systemization resulted in roughly two and a half times the
productivity of the norm.

Since I have this great experience of increased productivity that is
badly needed in our economy, I attempt to explain to others that they
also can use Pick to systemize for *their* purposes. However, when
they look at the tools that they would need to use their eyes glaze
over.

So, Tony, ask yourself, is it my problem that I am not explaining it
well enough to either the potential Pick users or is it that I am not
holding a paycheck over the head of the Pick "carpenters" and "brick
layers" like yourself who are the ones that can make the system
functional in my image?

When I started my Pick Journey in about 1978 there were Microdata and
ADDS boxes and Wyse terminals and RS-232 wiring and such and new hires
were mostly amazed that we had no message pads simply because they did
not understand the other aspects of the system anyway. Therefore we
did not have to deal with new employees un-learning any computer
habits. Today everyone who comes into the workplace has too much
experience with computers. They all are used to working in a browser
and working with applications that are so very unproductive that the
abyss between that and Pick is too great to overcome unless something
gives.

So, just like I am constructing this message in a Mozilla browser,
"they" do not understand why "they" should not run Pick applications
in a browser and, quite frankly, I do not understand either but I am
keenly aware of Pick opportunities all around us that can not be
exploited until "they" see a familiar framework that gives them the
opportunity to exploit a better way to systemize the enterprise.

Thus, before me, at the beginning of the IT revolution, came a bunch
of Pick entrepreneurs who delivered a framework in which my
productivity concepts could flourish. Today the techy aspect of that
IT revolution is far ahead of us while in other ways it is sorely
behind. Are you seeing opportunity of fleshing out the Pick
productivity framework in Henry's image before others do that in
*their* image?

Henry Keultjes
Mansfield Ohio USA

On Aug 22, 5:32*am, "dmm" <none> wrote:
If you understand the meaning of what I am trying to convey, systemize
or systemise is indeed a word. However, if you do not understand I
will have to explain of find you a link to an article or a book
because that understanding is absolutely critical to any successful
Pick implementation.

Henry Keultjes
Mansfield Ohio USA

OK, I believe I understand what you're saying: Pick is simple but the
common tools used to put a front-end on Pick are complex. My answer
is a regretful "that's just the way it is". The UI of the past was
not sexy but it was simple to create. Today's user demands a sexy UI,
and the tools required to make that happen are more complex than the
PRINT @(10,4) of yesteryear. But I believe your point is that you
don't believe creating a sexy UI should be so complex. You want to
find something between PRINT @, and the common GUI rocket science that
boggles even competent and intelligent developers. You don't believe
the browser is the right UI, and you were impressed with GraPick's
ease of creating a thick client GUI.

Before continuing, is that an accurate starting point for a discussion
of "solutions"?

Regards,
T

On Aug 23, 9:42 am, hbkeultjes <hbkeult... (AT) gmail (DOT) com> wrote:
<SNIP>
Why do you actually want to store ALL THE DATA in a pick database? For
example, if I received an order as a PDF or fax (tiff format) I'd be
more than happy to control/index access via Pick, but let the actual
data/image reside elsewhere, and jjust keep a link to this.

Of course the actual data content of the order (products, quantites,
deliver address etc) would be replicated as ascii "inside" pick, but
the source document? .... Whilst it CAN be done, I wouldn't bother as
I can not see any benefit in doing so.

By leveraging the strengths of each level of an application stack,
deficits in one layer can be offset by capabilities & resources in
another, yielding a bigger & better "whole"

Just a thought

On Aug 23, 1:47*am, Ross Ferris <ro... (AT) stamina (DOT) com.au> wrote:
Like an old colleague used to ay "It's an idea Henry but not a good
one". because first of all, I don't want to receive an order as a PDF
because I can take that fill-in PDF data and convert it to Pick data.
and so on. Even when there are source documents that are not in
ASCII, Pick could store those as BLOBS but the real value of Pick
remains its ability to be all inclusive in managing the organizations
data in order to systemize the enterprise. That other IT companies
have screwed the user over with their inefficient ideas does not mean
that we in the Pick world have to accept their ideas as gospel. I
don't want to hear about deficits in the Pick stack.

Like I said Tony, if it were easy any idiot could do it so put your
brainpower to work to turn those Pick deficits into something that is
much better than what others have in their stack.

Don't do your best, do what is required!!

Henry