[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