[Gambas-user] Developing MIDI app with Gambas

Rob sourceforge-raindog2 at ...94...
Fri Apr 22 19:46:21 CEST 2005


On Friday 22 April 2005 12:15, Jean-Francois Perreault wrote:
> I haven't really used activex controls outside of the one supplied
> with visual basic so I always found that limiting

You are not most VB programmers (and neither am I.)

> and the problem with the talk to another program through a pipe
> course is that the program has to exist , which it
> doesn't if you're not reinventing the wheel , so this means you
> need to know another programmation language -and-
> be good at it and at that point why are you using gambas ? just a
> frontend builder ? like glade ? , gambas is more than that

I think you have "form designer" and "front end builder" confused.  
It's easy to design a form in either glade or gambas, but only gambas 
lets you write the logic behind the form in a way that does not cause 
VB programmers' eyes to roll back in their heads.  Also, many 
programs (like cdparanoia, or the sox utilities, etc.) have 
interfaces which are understandable to people who are used to command 
line tools but not GUI users (which is, at this point, 95% of the end 
users or more.)  Building a front end to those tools is neither as 
easy as drawing a form nor a waste of time.

All that aside, though, there are many instances where a Gambas 
application may need to access functionality not embodied in a Gambas 
component, but not merely be a front end program.  For example, I 
wrote a removable media management system for a studio last year in 
Gambas.  It had to keep track of changes in mysql, deal with network 
disks, removable hard disks, and CD's, and handle differences in 
filename conventions between MacOS 9, OSX, Windows and Linux.  For 
the CD burning part, I used mkisofs and cdrecord over pipes.  Does 
that make the entire management program a front end to cdrecord?  
Should I have not written it and made a few grand just because there 
was no direct API for writing CD's?  On Windows I would have had to 
jump through a lot of hoops that don't exist on Linux, because Linux 
has many commands that are meant to be run over pipes just like that.

> I mean if I had been making a midi app , by today I would have a
> working demo , but without api calls I'd be making a module or
> external program if you make a module then you have to make
> something other can use and is somewhat well designed or else it
> won't get distributed with gambas and you won't be able to
> distribute you application without getting your users to recompile
> gambas !

Not true; I have made packages of Gambas components (like my posix 
one) that can be distributed separately from gambas, and the package 
management systems in any reasonable Linux distribution will 
automatically pull in gambas when you install the component.  
Obviously, I've used the Gambas package manager to package Gambas 
projects as well, with the same result.

Linux is not Windows, and rather than fighting that, Gambas 
programmers should embrace it.

> components are fine to extend the language and make a friendlier
> interface for beginners , they are not a replacement to full lib
> access and making an
> external program is well ... it's a hack , not a solution

Accessing C API's from an interpreted, structless, pointerless 
language like BASIC.... that's a hack.  Using programs over a pipe is 
"the Unix way".  If someone wants functionality that doesn't exist in 
Gambas, he's free to write a component, write a helper application in 
another language if he's not up to C, or apparently now, use Daniel's 
new gb.api component.  I just hope gb.api doesn't become a crutch for 
programmers to use instead of writing new well-designed components 
for Gambas.

Rob






More information about the User mailing list