His project is to port some old PrimeOS (!!) Cobol code to Linux.
So I gave him an x86 box with Linux and OpenCOBOL installed on it.
And he was off. Till the buggers he contracted with sprung a surprise on
him - they are demanding that he produce a Linux GUI.
(damn bank! damn bank#2!)
Does anyone have any experience with hooking OpenCOBOL into
XWindows? And if so, would you be willing to share a few tips
with me on how to go about doing it??
Ill help him do this someway or another, by hooking in C wrapper
routines if I have to, but I sure would like to avoid taking all the time
to do that if there is a faster way. I am a bit in overload myself right
now... :(
<mutter> PrimeOS! In 2009. To XWindows!
Unbelievable...<cuss>*(*&@&#!</cuss></mutter>
Thanks
-Paul
If anyone could help you, I would think they might. There is also a list for
the project that might have some ideas. See:
https://lists.sourceforge.net/lists/listinfo/open-cobol-list
*OBVIOUSLY* if the end-user (bank) were to pay for it, going with one of the
"commercial" compilers (e.g. Fujitsu, Micro Focus - or the "AcuCOBOL" part of
Micro Focus) would give him INSTANT support for GUI's under Linux. However,
those are not cheap.
--
Bill Klein
wmklein <at> ix.netcom.com
"Paul" <paul-nospamat...@mac.com> wrote in message
news:49979fb9$0$5472$bbae...@news.suddenlink.net...
> Have you tried asking this at:
> http://www.opencobol.org/
>
> If anyone could help you, I would think they might. There is also a list for
> the project that might have some ideas. See:
> https://lists.sourceforge.net/lists/listinfo/open-cobol-list
>
> *OBVIOUSLY* if the end-user (bank) were to pay for it, going with one of the
> "commercial" compilers (e.g. Fujitsu, Micro Focus - or the "AcuCOBOL" part of
> Micro Focus) would give him INSTANT support for GUI's under Linux. However,
> those are not cheap.
I scanned the web site Bill, but I didn't find a good answer. A good
bit of religion, but
nobody that had actually used it. Besides, I am far more used to seeing
real answers
from this group. :)
I would move him to MicroFocus in an instant, but the customer won't
pay, and $22K
per server is a bit high for my charity budget at this point. Besides,
I am not at all
sure Microfocus is even supporting GUI under LInux- they seem to be pretty
Windows Centric lately- with .NET being their primary target.
Thanks -Paul
When the customer changes the specs, that changes the price.
Well, to be sure, the info is a little sketchy but having worked with
Primes quite a bit in a previous life I can guess at the complexity and
UI that the programs might have. That being said, how about just porting
the programs and then putting a TK/TCL frontend on them to provide the
GUI?
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
As long as he is paid by the hour and can push the 'go live' date out
appropriately as the changes to the spec arrive then he probably can
spin this out until retirement (or even after).
> Does anyone have any experience with hooking OpenCOBOL into
> XWindows? And if so, would you be willing to share a few tips
> with me on how to go about doing it??
>
> Ill help him do this someway or another, by hooking in C wrapper
> routines if I have to, but I sure would like to avoid taking all the time
> to do that if there is a faster way. I am a bit in overload myself right
> now... :(
Generally text mode screens are 'program driven', that is the program
determines the sequence of interactions with the user. GUIs are
usually event driven, the user indicates what should happen.
This is not just changing the face of the application, it is changing
the way the program works, and often means a rewrite unless the
program was written originally to cope with such a change.
For GUIs on Linux I use Glade, but I haven't done this with Cobol yet,
I do it with Python. Glade has a designer which draws the screens and
generates an XML file of these. The program then 'just' has to call
glade to draw the screens and link the events to code. With Python/
Glade it just works on Linux, Windows, and my pocket computer.
I would be more inclined with Cobol to make the system run as web-
based 'in the cloud', The GUI will be frames and forms in tables with
Ajax validating the fields and lookups back to the OpenCobol code
running under Apache.
Of course this is also a complete rewrite and uses several languages
(HTML, JavaScript, Cobol).
That is an excellent idea- you wouldn't happen to have an example of doing just
that laying around you would be willing to share would you? :)
I had forgotten about TK/TCL. That might just be the very best way to do it.
-Paul
If it was me, especially in this case, it would cancel the whole deal.
(damn bank!)
But Kyle ain't me, and he has two small kids and a mortgage. I won't comment
on why he would work for people so - dishonorable. He feels that he is very
desperate. (damn bank!)
-Paul
MMM- an Ajax based screen does have a lot of advantages. It is pseudo
conversational, and much more similar to a green screen than a normal
GUI. Probably less rewrite in the code.
I think a couple of us could put together web screens quickly enough,
and OpenCOBOL deals well with web CGI programs.
This is worth thinking. Hopefully they will buy off on that. Maybe then
he could spin it into a client/server on Windows or MacOS or something
he can charge a lot more money for.
Thanks -
-Paul
[snip]
>> When the customer changes the specs, that changes the price.
>
>If it was me, especially in this case, it would cancel the whole deal.
If it were I, in most cases, I would use the subjunctive... and cancel the
deal. I do not contract to paint a shed and then get told 'Oh, and while
you're at it - and and no change in price, of course - do the rest of the
house'.
Contracts (when properly written) protect all parties involved.
>(damn bank!)
>
>But Kyle ain't me, and he has two small kids and a mortgage.
He also has specifications - I am assuming this is what is intended by 'on
spec' - and as a result is bound, by law and contract, to meet them...
*not* them and the 'and while you're at it'.
DD
Hi Paul,
If I am going to port my Windows (MF) Cobol GUI to Linux, this is
simply no conversion at all. Ubuntu Linux runs with "Wine" application
from within the Linux OS. So simply install the application using
Wine.... of course with MF, you need to install Application Server
module as well.
Tried running MF Cobol application from it and it works well. I do not
know OpenCOBOL though, but if you can manage to have a Cobol-GUI in
Windows using OpenCobol... might as well install it using wine and add
your application. No need of "OS-porting", it is all compatible in
Linux Wine.
Rene
Paul wrote:
--
Vaclav Snajdr
Well, I don't, but ecven if I had examples laying aroiund there has hardly
been enough info about the project provided for anyone to post a reasonable
example of how to do it. I just threw that out as an option. Even the
concept GUI is undefined. If a Web interface is considered an acceptable
"Linux GUI" it is even easier as OpenCOBOL works find for CGI.
Okay Bill - how about a screen that sets up one input field, edit
checked to be numeric, and displays a text message after the user hits
enter.
-Paul
Not replying for Bill. But I've done a little bit with GTK+ for
OpenCOBOL. The plan is a near full on binding to the GnomeToolKit,
but for now. Buttons, Labels, Menus, File Dialog, a Calendar widget
(and a few odds and sods), enough for simple but fully functional
GUIs.
A sample screenshot and some source code can be seen at
http://add1tocobol.com/tiki-index.php?page=GTK+Sample
We've also taken Rildo's Tcl/Tk engine from TinyCOBOL and interfaced
that into OpenCOBOL as well. For that layer most of the GUI work is
squarely on the Tk side.
Cheers,
Brian
Bingo! Perfecto! This will do the job! THANK YOU! :)
-Paul
And just as a follow up, let me say Thank You again for all the quick
and helpful responses - especially Bill Klein. :)
Got a prototype up and working last night.
-Paul
Hope it works out Paul. (Assuming the bingo has to do with GTK and
OpenCOBOL - as the thread response is such that I can't be 100% on
that), there will be a lot more to this layer as the days progress.
The functions are fairly easy to wrap (rote programming), but testing
takes a while. And if it is OpenCOBOL; thanks to Roger and Keisuke
too ... smart cookies ... and we all get to benefit and learn from
their efforts.
Cheers,
Brian
Yep, I was replying to you. Thanks!
It is great to have this wonderful Open Source stuff around.
-Paul
What, are we ignoring the option of calling XLib directly? :-)
Of course, a Real Programmer would just open a connection to the X
server and stream hand-crafted X11 protocol requests to it.
(Back in my callow youth, I wrote a number of X clients - including a
window manager - that talked directly to XLib. 'twas a trifle
tiresome. Wrote big chunks of an X11 server too, come to think of it.
In C, though, not COBOL.)
Out of curiosity, Paul, which of Bill's options did you end up going
with - GTK+ or TK?
--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
> Besides, I am not at all
> sure Microfocus is even supporting GUI under LInux- they seem to be pretty
> Windows Centric lately- with .NET being their primary target.
This isn't particularly relevant to your problem - since, as you've
explained, your friend isn't in a position to use MF COBOL anyway -
but we're just as committed to our Unix / Linux product line as ever.
The MS stuff has been getting most of the press lately, and it's
certainly an area where we're doing a lot of new stuff; but new
versions of the Unix line (Server Express) are coming out on schedule,
largely from the same code base as the Windows line.
But *that* said, I don't think we actually offer a GUI facility as
such for COBOL on Unix / Linux these days. Dialog System on Unix is
character-only.
For our customers who want Unix / Linux GUIs for MF COBOL programs, we
might recommend HTML (using accept/display HTML, or AJAX plus Web
Services, or various other options), or creating a front end in Java
and using our Java interop technology.
New news! New discovery (for me, perhaps old hat for others). Vala,
http://live.gnome.org/Vala A programming language designed for
writing code to interface with the Gnome libraries at a high level but
keeping to a C binary interface. Vala, like OpenCOBOL, does
intermediate C so the object files are directly callable with no
linker name mangling inherent with C++ and many other higher
conceptual programming systems.
I had the valac compiler built from sources, and a GtkTreeView wrapped
in a GtkBuilder (Glade and XML ui files) called from OpenCOBOL all
within an hour. The OpenCOBOL gui binding layer will now be orders of
magnitude easier to write and manage. GtkBuilder was already slated
to be one of the nexts piece added to the CBL_OC_GTK_ callables, but
moving from a C based layer to the much higher conceptual Vala level
there will be a lot less glue code required.
While the posted sample doesn't really do much data passing, as I was
in a giddy rush to get the news to the OpenCOBOL folk, I've started a
thread on opencobol.org. More soon;
http://www.opencobol.org/modules/newbb/viewtopic.php?topic_id=526&forum=1&post_id=2700#forumpost2700
OpenCOBOL programmers won't really need to have a Vala compiler when
the binding layer is complete, as it can and will still be published
in object form, but as with all open things, source code will be
available and the compiler is freedom free and zero-cost free.
Very exciting.
Cheers,
Brian
Gee did I say zero-cost free, when I meant free-beer free? There are
always costs; freedom doesn't really come without a price. ;)
Cheers again,
Brian
Not used it for real, but consider about :
ruby
fx-ruby fxruby
fox-library (C++/ C compatibility)
for quick and eseay dev...
i libfox-1.6-0 - The FOX C++
GUI Toolkit
i libfox-1.6-dev - Development
files for the FOX C++ GUI Toolkit
i libfox-1.6-doc -
Documentation of the FOX C++ GUI Toolkit
Built an easy GUI front-end and interface it with either cobol or C
produced result...