Re: [open-cobol-list] OC_GTK help

[Michael]

David Essex wrote:
> If you have the screen extracts, then you can choose what ever toolkit
> you wish (winForms, GTK, web-interface, ...).
>   
True, but I need to choose wisely, because I'd rather write it one time.
> However, I don't think that a platform-independent solution for the 
> screen extracts is available.
>   
Yeah, the screen extract must run on the HP3000 platform, it does use 
some HP3000 intrinsic functions that are not found anywhere else. 
However, if I create listener process on the HP3000, to wait for socket 
connections . Then, a client process from any platform could connect to 
that socket on the HP3000 and receive a list of available forms files, 
then request a form to be sent seamlessly from the HP3000 to the client 
in `.glade` XML format. If the client is using OpenCobol and GTK+ it 
would be platform-independent, right?
> Perhaps an alternate approach would be to use the screen extracts to 
> generate platform-dependent code.
> The rest of the COBOL code should be platform-independent, in theory.
>
> BTW, I did find this Vala web-site 'Loading User Interface from XML 
> File' [1] by chance.
>
> On a side note, Vala looks very interesting.
> No screen painter with the IDE, yet.
> The Vala code looks like Java or C# and generates C/C++ for GTK/GTK+.
> Add a Perl Parrot [2] like back-end and you would have a Mono replacement.
>   
Vala is still beta, but I may use it to generate the c code to get 
started on the wrapper.
> Michael wrote:
>   
> > Good info David, thanks again. I still think GTK maybe the path of least 
> > resistance for HP3000 to Linux screens, even though Qt maybe more 
> > portable. I guess I've chosen GNOME over KDE. I still need to look more 
> > into Vala, as it generates C code for GTK, and intergrates with gedit, 
> > and IDE's like Anjuta and Eclipse.
> >
> > As far as the HP3000; The HP3000 is cousin to the AS/400, I heard rumors 
> > long ago that some of the same engineers worked on both machines prior 
> > to their conception. I've already written the screen scraper for the  
> > HP3000 screens. It does not technically scrape screens, what it does is 
> > read the source forms files on the HP3000 and extracts the meta data 
> > then exports it to various file formats, one being XML. What I need now 
> > is an API that will be able to function like the API on the HP3000, 
> > wrapping the new HP3000 forms API around the GTK (or whatever) API. The 
> > only objects on these screens are data fields, static text, and function 
> > keys (buttons). Besides blinking text, most of it should be very simple. 
> > So I was thinking that I could make this XML file match the glade XML 
> > namespaces, and then the GTK API would handle the rest....
> >     
>
>
> 1) Vala: 7:Loading User Interface from XML File
> http://live.gnome.org/Vala/GTKSample
>
> 2) Parrot 1.3.0 - Home
> http://docs.parrot.org/parrot/devel/html/index.html
>
>
>