after a week of research, I’m pretty convinced that for the project I’m
planning Ruby might be a sensible choice. Let me explain: I programmed
with Max/MSP for several years, but what I’m about to do right now goes
beyond its limits. So I’m looking for another programming language. As
I’m a musician and no programmer, I’d like to use something not too
difficult to learn, preferably with a nice IDE. First I had a look at
RealBasic, but too many users complain about it. So I’m here now.
My application is going to be a large one, and firstly I’d like it to
run on a maximum of OS (Mac / Windows / Linux / if possible also Android
/ iOS / Windows Mobile or whatever it’s called these days). If my
research results are correct, there’s a chance to do that with Ruby +
QT. (Is there?)
I’d also like to be able to use custom UI elements (probably this
depends more on QT or any other IDE I may choose). But the language I’ll
use must offer a sound library with the specific ability of time
stretching and pitch shifting of sound files. Meaning: my program uses
sounds of a certain length and frequency that may be altered or in terms
of duration (without changing their pitch) or, on the contrary,
regarding their pitch (but not the duration).
So my question is: does this kind of library exist? As I have no idea as
to how and where to look for it, I hope someone may just tell me.
I’d also like to be able to use custom UI elements (probably this
depends more on QT or any other IDE I may choose). But the language I’ll
use must offer a sound library with the specific ability of time
stretching and pitch shifting of sound files. Meaning: my program uses
sounds of a certain length and frequency that may be altered or in terms
of duration (without changing their pitch) or, on the contrary,
regarding their pitch (but not the duration).
So my question is: does this kind of library exist? As I have no idea as
to how and where to look for it, I hope someone may just tell me.
I don’t know if it exists, but if you find it available for Java, then
you
can program in JRuby with a very good interface to the Java libraries.
Since you are new to Ruby, I wanted to point out the existence of Ruby
that runs on the JVM.
– Matt
It’s not what I know that counts.
It’s what I can remember in time to use.
after a week of research, I’m pretty convinced that for the project I’m
planning Ruby might be a sensible choice. Let me explain: I programmed
with Max/MSP for several years, but what I’m about to do right now goes
beyond its limits. So I’m looking for another programming language.
I have a couple of comments.
First, the “One UI to rule them all” wish is as close to utopia as it
can get. I can comment on Android (a good half of the mobile
platform): there, Java is the only way. It means that you can
certainly use Ruby (via Ruboto), but the UI is built up in its own
specific ways, quite hard to map to QT or Cocoa, or whatever
else. You’d have to have separate copies of the UI code for each
supported platform. Big work.
Second. I developed lots of audio/video code. I can tell you that,
while playing an audio file faster or slower is easy (you just skip
frames or play frames multiple times), it is much more expensive to
change pitch without changing length, or the reverse: you have to pass
each block of samples to Fourier transform, modify the resulting
spectrum, and reverse the transform. You need very good hardware to do
that live.
Thank you very much, Carlo, as your comment does clear several things
up. But it also produces other questions.
I may stress I’m a musician, not a programmer. As I worked with
Max/MSP all times, I know virtually nothing about IDEs, libraries, or
even different GUI guidelines for all these OS platforms. With Max/MSP
on my Mac, I’m able to develop little sound utilities as standalones,
and there’s a Max runtime app that permits to run those standalones even
to those who don’t own Max. So they cannot edit the standalone, but they
can use it, and the Max runtime app exists for Mac and Windows. (It’s
like the Adobe Acrobat concept: most people use the Acrobat Reader to
read PDFs, but only a few have got Acrobat to build PDFs.) So that’s my
background.
Evidently the UI elements I built in my sound utilities look and work
the same under Mac and Windows, and it’s impossible to respect the GUI
guidelines of both with the same UI as they differ, like everybody
knows. And even for what I’m planning to program this time I think it’s
not that important that it feels like an application specifically built
for this or that OS. So I’m aware of the fact that many professional
programmers prefer to invest time in the development of specific UIs for
different platforms. I only hoped that an IDE like QT may effectively
take charge of the compilation of an UI you may have to develop only
once even if it runs on several OS.
So if I get you right, it’s not reasonable to use Ruby if I’ve to get
a UI for Android. My question: If I was to write my program with Ruby,
is there a way to “combine” this with a Java part for the Android UI,
with an Objective-C part for the iOS, with a silverline part for Windows
Phone and so on? It seems quite confusing to me, and in addition I’d
have to learn all these languages… Probably I’m mistaken, but I
thought that it was the IDE you choose that defines on what platforms
your program will be able to run, and as long as a programming language
like Ruby is supported by the IDE, everything’s fine…
Now to the pitch shifting method (or library or whatever). I already
know that libraries for a certain programming language may be written in
another language. I also know that pitch shifting is a time sensitive
operation and that a library that takes charge of it must be written in
assembler or C or something like that. But if I get the idea of
libraries right, they exist to incorporate this kind of function in a
programming language that may not be able to deliver it on its own, and
once you compile your program for a certain OS, it runs this function.
Now you tell me that there’s an OS specific “underlying audio layer” to
deal with. What does that actually mean? Let’s say for the argument’s
sake that I’m to write my program in Java. Java runs on Android, but
also on Windows. Do you suggest I’d have to actually use two different
libraries for pitch shifting depending on the OS I’ll compile my program
for? Even if Java runs on both?
This comes as a surprise to me as in Max/MSP, pitch shifting exists as
an object you simply put in your data stream, and you get what you
want…
Ok, Carlo, you’re actually contributing to clear up the usual pile of
misunderstandings and lack of knowledge shown by people like me who find
the numerous layers of computer code quite difficult to grasp… I’m
sorry you have to endure this, but I’m also very grateful some things
begin to light up in my mind.
So you’re telling me the ‘big work’ that would be involved in my project
and that would come from two directions (inclusion of custom UI elements
and a pitch shifting mechanism that could be incorporated in a simple
way) has not yet been done. OK, bad news. I just wasn’t aware of the
fact that changing OS could mean more than having slightly different
looking buttons and sliders in slightly different positions of slightly
different windows… I hoped the “solid common frame” to overcome these
differences would be an IDE (by the way, I’m not at all specifically
attracted to Qt; it simply seemed to be able to construct GUIs for
several platforms – I’m already told that maybe WxWidgets would make a
better job of it), but obviously that’s not enough.
Concerning custom UI elements, I thought to create simply some buttons
and sliders with Cinema4D, to get images from them in all their states
and to ‘overrun’ somehow the original images used by the OSes. Clearly
this is a bad idea, and to be frank, it’s not that important. The scanty
‘charm’ of Max/MSP UI elects made me wish for something shinier.
What would be important, however, would be to be able to use my program
at least on iOS and Android, better if on MacOS and Windows also,
because what my program offers is done best during all these more or
less dead moments of a day you’re out or going somewhere or waiting for
something, and in these moments you won’t have your laptop with you, or
you won’t want to open it and to fire it up. But you could quickly get
your smartphone that accompanies you wherever you are, even on the
toilet :-).
And Max/MSP (or even Pure Data) don’t provide this, because there’s no
Max runtime for Android or iOS, and it seems that there won’t be any
anytime soon, because the guys of Cycling74 have been asked for a long
time to develop this kind of thing, and they simply don’t do it. So does
that mean that I’ve to learn both Java for Android and Objective-C for
iOS? What are the projects like Ruboto and RubyMine for, then?
As to the pitch shifting problem, you’re describing two different
strategies to solve it. To “feed the DAC” seems absurdly complicated
after your explanation. So what I’d have to do is to create this
“daemon” that processes my sound files (fortunately they’re very short,
so one can hope it won’t take too much time even for the relatively weak
ARM processors of today’s smartphones) and stuffs them into a tmp folder
before they’re used. Very well, but right now you made me suspicious:
how (that is to say, in which program language) am I to create this
daemon, how does it link to ANSI C, what kind of frame work (IDE /
compilers / ?) must I add? Because I imagine that this kind of stuff is
not part of the normal SDK of whichever programming language…
Anyway, thanks a lot for your comments, Carlo. You’re achieving
something that has not happened in several other forums.
I may stress I’m a musician, not a programmer. As I worked with
Max/MSP all times, I know virtually nothing about IDEs, libraries, or
even different GUI guidelines for all these OS platforms. With Max/MSP
on my Mac, I’m able to develop little sound utilities as standalones,
and there’s a Max runtime app that permits to run those standalones even
to those who don’t own Max. So they cannot edit the standalone, but they
can use it, and the Max runtime app exists for Mac and Windows. (It’s
like the Adobe Acrobat concept: most people use the Acrobat Reader to
read PDFs, but only a few have got Acrobat to build PDFs.) So that’s my
background.
Each platform has a different executable acrobat reader. The source
code is not public, but I believe that the various codebases only
share the library that interprets the PDF language (the language is
public, by the way, so I can read and write PDF without using anything
from Adobe). For the rest, Adobe will have some programmers who know
how to write user interfaces for each platform. Remember that Adobe is
a megacorp.
I am familiar with PureData, rather than Max. When Miller wrote
PureData, he used an existing UI: Tcl/TK. This has also been the
choice of the early Ruby developers. But Tcl/TK is a bit lame, and
Miller did a HUGE work to massage Tcl/TK to do what he wanted. I
believe that the code in Max draws and manages its own graphic
components directly (because they are very specific to the
application). If true, at the moment of porting Max from Mac to
Windows, the problem was just to provide the way to draw graphic
primitives (i.e. coloured rectangles, lines, characters…). The big
work had been done before.
Basically, what you do not have is a solid common frame that would
make such an effort as yours easy. And the reason for this is
obvious: each platform has a UI, and nobody wants to discard it in
favour of another one. This is why we do not all speak Esperanto,
after all…
Evidently the UI elements I built in my sound utilities look and work
the same under Mac and Windows, and it’s impossible to respect the GUI
guidelines of both with the same UI as they differ, like everybody
knows. And even for what I’m planning to program this time I think it’s
not that important that it feels like an application specifically built
for this or that OS. So I’m aware of the fact that many professional
programmers prefer to invest time in the development of specific UIs for
different platforms. I only hoped that an IDE like QT may effectively
take charge of the compilation of an UI you may have to develop only
once even if it runs on several OS.
It is not the fact of them looking different. The fact is that the model that they are based on is completely different. Not only the
graphics model, specifically the way the loop of events is handled.
About QT I am not an expert because it is written in C++, and I also
do not like the look of it from pure aesthetic reasons. Maybe it cuts
your cake.
So if I get you right, it’s not reasonable to use Ruby if I’ve to get
a UI for Android.
Even under Android, you can get ownership of the bitmap of the screen,
so if you develop your UI the hard way, you can reach your holy grail,
like Adobe and the people behind Max do. What I mean is that
downloading the Android SDK and looking at some examples brings you
quite quickly to the point where you can spit out your app with two
buttons and an image. Operating any other way is not only much more
difficult: it goes against the grain of what Google wants you to do,
so they help you a lot less on your way… The UI is the bottleneck: a
daemon in C is easy to write.
sake that I’m to write my program in Java. Java runs on Android, but
also on Windows. Do you suggest I’d have to actually use two different
libraries for pitch shifting depending on the OS I’ll compile my program
for? Even if Java runs on both?
A library for the stretch/compress most probably exists in ANSI C -
you can compile it wherever ANSI C is understood. So you can have a
daemon that gets an audio file, processes it, and dumps it into
another file. What is different is when you have to send your samples
to the DAC. There, you must be sure that the audio chip is
appropriately initialized and configured (and each chip is different),
then you must be sure that the sample size, the speed, the number of
channels, and a few other parameters are set the way you need them to
be. Then you must start feeding to the DAC samples, at the right
speed. Trying not to be disturbed by other tasks being run.
All this is not trivial. And it has been solved in different ways by
those who tackled it for the various OSes.
This comes as a surprise to me as in Max/MSP, pitch shifting exists as
an object you simply put in your data stream, and you get what you
want…
From what I know, Max is very well optimized. Lots of work went into
it.
So you’re telling me the ‘big work’ that would be involved in my project
and that would come from two directions (inclusion of custom UI elements
and a pitch shifting mechanism that could be incorporated in a simple
way) has not yet been done.
I could never say this, since I do not know exactly what you want to
do. What I say is that covering unix, windows, mac, android and iphone
translates to ‘big work’ for any application that would want to
interact with the user, and that would want to generate live sound (I
am rather certain your application would want both of these).
I hoped the “solid common frame” to overcome these
differences would be an IDE
IDE = integrated development environment. It is a tool to help
developers along the development process. What you are searching for
is a widget toolkit. WxWidgets seemingly would cover all your target
platforms apart from Android. About WxWidgets, I have no comments
(never had anything to do with it).
What would be important, however, would be to be able to use my program
at least on iOS and Android,
From what I know, you need two separate codebases for that.
What are the projects like Ruboto and RubyMine for, then?
RubyMine is an IDE. For your concern it is irrelevant.
Ruboto is an effort to map Android’s SDK to Ruby. A honourable
effort, but it just tries to map Android’s SDK objects one to one. I
did a little work with it, but decided to drop it, mainly because it
is a layer above Jruby, which itself is a layer above Java. Too many
layers, for my taste. Since I had to get familiar with the messy
lifetime of android apps anyway, for my experimental work I found it
more straightforward to do the UI coding in Java, leaving as much as I
could to C.
Ruboto does not go in the direction of developing a multiplatform
UI. The target of the developers is to offer the possibility to
develop Android apps under Ruby in a relatively straightforward way.
In Android, the UI is much intertwined with the handling of the
lifetime of the app. In typical Google fashion, Android is very nosy
about your app. This is very different even from X. I know nothing
about iOS, but it would be very complex to port, say, Gnome to
Android. You may want to skim this article to get an idea:
not part of the normal SDK of whichever programming language…
This is very much offtopic here. Let me say that, in one way or
another, you need to feed samples to the DAC in order to hear anything
from your loudspeaker. That’s how numbers are translated to a voltage
that itself translates to the moving of a magnet inside your
loudspeaker. This is the vibration you perceive. Anything else remains
at the level of numbers. And this is where all operating systems
seriously differ.
Thus: in order to have a process that performs acceptably in the audio
part, you NEED to have a very well-performing end-stage. If you want
to generate a CD-quality audio output, you must be SURE that, 44100
times every second, at regular intervals, your end-stage will feed a
new sample to the DAC. Each OS has developed some form of providing
this. Unfortunately, each approach, for what I know, is different.
The actual best way to tackle your holy grail would require a lot of
thought. I, for one, would never accept this challenge even as a
paid-for job, because covering multiple platforms is not my piece of
cake. I mourn the fact that the only real Linux-based phone (the Nokia
N900) was killed in the cradle by Nokia management. I am looking into
Android because I want to understand how my chinaphone works, but what
I see I do not like. Android is crippled Linux.
Dear Carlo (as it seems that nobody else is going to contribute to this
conversation),
thanks again for your time. Every message you write opens new levels of
discussion for me. Take one of the last informations you wrote: “What
I’m looking for is not an IDE, but a widget toolkit”. Well, it’s this
kind of stuff that makes me google another couple of hours to make sure
I’m not completely out of order when I try to respond. Why is that so?
Because I obviously didn’t know I’m looking for a widget toolkit! I
thought it should be enough to check if a certain programming language
dispose of compilers for the platforms I try to cover, and then to
choose an adequate IDE. Now I know that IDE != widget toolkit, even if
some IDEs can contain one.
(So just to be clear: one could program also without a widget toolkit,
but it would mean a lot of additional work because they’d have to
program from scratch all those buttons, sliders and other graphical
elements we’re used to get from the GUI builder. Right?)
Very well. I also saw that I asked a wrong question about Ruboto and
Rubymine. You answered the first part about Ruboto so well that actually
I doubt if programming for the Android platform is a good idea at all
(especially after reading your link about Android and Gnome). I wrote
the second part of that question wrongly; I didn’t mean “RubyMine”, but
“RubyMotion”. There, it seems, they’re trying to make a bridge between
Ruby and iOS. Is this to be seen as the Ruboto initiative?
But a fundamental question remains. Even before learning Max/MSP, I was
well aware of the fact that as a musician I’d like to use so-called
‘high-level’ programming languages. Because in doing so I wouldn’t be
bothered with problems like memory addressing or other low-level,
hardware-near decisions to make. So I thought that in choosing a
high-level language like Ruby, even a problem like “How do I make my
hardware play a cd quality sound file” would been answered by something
like
if condition a is met
get soundfile(xy)
play soundfile(xy)
on sound file(xy).end
continue with whatever
(Don’t bite me, I don’t know yet how to write that in Ruby.)
And evidently this is everything but “a lot of thought” you’re stating
to be necessary to get done a simple thing like play a sound file. I
thought that I wouldn’t even been touched by the level of “How do I
handle the DAC chip”, let alone by questions like “How do I set
parameters of this or that specific chip and make sure that it’s fed
44100 times per second with a sample”. But if I understand your point
right, I have to face somehow these very problems if I am to try and
cover several platforms. I find this astonishing. In my imagination, no
programmer who didn’t specifically wish to must be bothered with
problems like that one. Evidently very much progress has yet to be made.
Thanks, Carlo, for getting me in the real world.
For what it’s worth, neither I feel enthusiastic about covering several
platforms. My problem is that all my computer experience since 1992 is
connected to Apple Macintosh. If I’d used Windows for 20 years, I
probably would try to program for Windows and Windows Mobile, telling
myself that in doing so I cover a big part of computer users, and who
cares about the rest. But now I’d feel uneasy to cut out MacOS and iOS,
and Android seems to be the future of all those handheld devices. So all
this becomes a very hard decision. Even if you show me that I’d
have to choose one platform for my project because it’ll be really
difficult for me to entertain other OSes as well, I would not know which
one to choose. Entertaining two or even more codebases on top of
learning the belonging languages and IDEs / widget toolkits is
definitely beyond my resources.
Thanks anyway, Carlos. I hope to continue to hear from you.
(So just to be clear: one could program also without a widget toolkit,
but it would mean a lot of additional work because they’d have to
program from scratch all those buttons, sliders and other graphical
elements we’re used to get from the GUI builder. Right?)
Yes you can: below the hood you will always find that level. But
drawing is not the largest part of the work: the elements of the UI
must receive information (either from your program or from the user)
and generate events, which must be acted upon. This exchange has to
happen as smoothly as possible from the point of view of the user. It
is under this aspect that the various user interfaces differ most:
every UI designer started with different ideas on how best to provide
the service.
I didn’t mean “RubyMine”, but
“RubyMotion”. There, it seems, they’re trying to make a bridge between
Ruby and iOS. Is this to be seen as the Ruboto initiative?
As I mentioned in another recent thread, I am too poor to own anything
made by Apple. A couple of times I had to dabble with a Mac for
work-related reasons, but both times I put Linux on it. Thus, I cannot
share my experience.
I heard that iOS and MacOS are much more homogeneous than Linux and
Android, from the application programmer’s point of view. Macruby is
an Objective-C implementation, so it has to be directly in contact
with the OS internals. RubyMotion must be a nifty tool for generating
iOS apps.
But of one thing I am certain: the RubyMotion developers have NO
interest in making it easier for you to develop Android apps.
I thought that I wouldn’t even been touched by the level of “How do
I handle the DAC chip”, let alone by questions like “How do I set
parameters of this or that specific chip and make sure that it’s fed
44100 times per second with a sample”. But if I understand your
point right, I have to face somehow these very problems if I am to
try and cover several platforms. I find this astonishing.
Everyone who invests in knowledge, time, and maybe money, on a
specific platform, will then try, more or less gently, to steer you
towards that platform. Nobody in the market is concretely interested
in the “One UI to rule them all” ideal, unless the UI is their own
adopted one. Knowledge is power…
For what it’s worth, neither I feel enthusiastic about covering several
platforms. My problem is that all my computer experience since 1992 is
connected to Apple Macintosh.
I have several friends in the same situation. It was most astonishing
for me to follow Mac followers as they obediently followed Steve
as he did that complete somersault from Os9 to OsX.
If I’d used Windows for 20 years, I probably would try to program
for Windows and Windows Mobile, telling myself that in doing so I
cover a big part of computer users, and who cares about the rest.
Probably not; 20-year Window users have a different profile…
But now I’d feel uneasy to cut out MacOS and iOS, and Android seems
to be the future of all those handheld devices. So all this becomes
a very hard decision. Even if you show me that I’d have to choose
one platform for my project because it’ll be really difficult for me
to entertain other OSes as well, I would not know which one to
choose. Entertaining two or even more codebases on top of learning
the belonging languages and IDEs / widget toolkits is definitely
beyond my resources.
That’s why I suggest that you do not follow the multiple-platform
goal. If you have a good idea, the best you can do is try to prove the
pudding. While focusing on MacOS/iOS will not cover the large slice of
potential users that you dream of reaching, it may reach enough of
them anyway. In the process, you will learn a lot. Most important: you
will learn if your idea is feasible.
MacRuby, from what I read, is comfortably solid, and if you can afford
RubyMotion (I have no idea about the costs), you will most probably
find a gentle enough path to exploring this world. Most important, due
to the kind of public who chooses Apple products, I believe the
media-related part should have been given proper attention.
Your last paragraphs seem to nudge me into the direction of MacOS /
iOS.
That’s because it is in your history… It would allow you to break
the problem into first learning to develop an app, and later maybe to
make it multiplatform.
If I were you, I would face the whole problem (if you can manage
financially, of course) as a way to gain experience. These pet
projects tend to become stale quite quickly if the only motivation is
a financial one (even if only in the form of small voluntary
payments). The drive should be to wish to see how the idea translates
into practice.
• attention to what you call the media-related part
This last comment of yours is a bit cryptic for me. You say that “the
media-related part should have been given proper attention”. Why “should
have been”? Is it already too late? Do you reckon Mac or iOS
applications can’t meet success without giving the medias a considerable
attention?
What I meant is that most of the people I know who shell out the $$$'s
for a mac do it because they use it professionally, mostly in media
environments. If Apple began to be perceived as flaky in the media
sector, a lot of bad consequences would befall…
• every Android version (of every future hardware) will engender
necessary
code changes
This is not necessarily true. A recompilation may be sufficient. OTOH
problems may happen between one implementation and another one. The
chinese company that produced my phone did invest a fraction of the
resources that Samsung does in its development process. A lot of
surprises may happen.
Hm. Not really convincing either. And, as always, an important question
raises after all that. Would it still be a good idea realizing this
one-platform approach with Ruby? Wouldn’t it be more straightforward to
choose Objective-C for MacOS or Java for Android? (Or even C# in the
less probable case of Windows?) Sure, my starting point was the choice
of a modern, relatively simple and interesting programming language, but
that was closely linked to my multi-plaatform hope. That being
shattered, isn’t the linguistic disadvantage of Objective-C or Java
counterbalanced by the fact that they’re the most direct, maybe failsafe
ways to address their OSes?
Every person I know who has tried ruby has become fond of it. As you
can read on the Ruby site, Ruby is a programmer’s best friend. My
experience is that it makes the whole coding procedure cleaner and
more enjoyable.
But maybe you would find it preferrable to start with Objective-C, so
later you could notice the difference?
Sorry for this delay, guys, I’m actually on a short journey.
@ Damián: thanks for your first link. Indeed it may help to get
assistance if
I decide to use Ruby for my project (after this discussion, I can’t be
sure anymore). Your second link is about a project that has to do
nothing
whatsoever with mine; but it was interesting nonetheless.
What I didn’t tell you: it’s quite sure my project will become freeware,
maybe with an invitation to donate But I’d like to avoid spending
hundreds of Euros for IDEs, GUI builders or other helping tools on top
of spending lots of time and not being payed if it’s not strictly
necessary. So even if it’s worth its price, I don’t think I’ll buy
RubyMine.
@ Carlo: Ok, I think I get it. Thanks again for sharing your experience
with this multi-platform problem. But if I am to abandon the idea of
offering my project to as many users as thinkable, the moment of
decision for one platform at the expense of all others approaches. Your
last paragraphs seem to nudge me into the direction of MacOS / iOS.
Let’s say (just as a hypothesis) I’ll go for these two. As I see it,
arguments would be (correct me if I miss essential points):
Pro:
• familiarity with the UI environment
Con:
• various expenses (Apple developer cost: 99 $ per year / XCode is free,
but if I’d like to use Ruby, RubyMotion for iOS costs > 200 $)
• covers a little part of the users only
• attention to what you call the media-related part
This last comment of yours is a bit cryptic for me. You say that “the
media-related part should have been given proper attention”. Why “should
have been”? Is it already too late? Do you reckon Mac or iOS
applications can’t meet success without giving the medias a considerable
attention? Would that be less important with other platforms? (As I’m
completely new to this, I never thought about this aspect of
programming…)
Well, the (surely incomplete) list of cons seems larger to me than the
pros list. Let’s try the same procedure with Android:
Pro:
• big part of the “market”
• free of expenses (?)
Con:
• “Crippled Linux” (I have no idea what that means concretely, but it
just
sounds bad)
• every Android version (of every future hardware) will engender
necessary
code changes
• no UI familiarity
Hm. Not really convincing either. And, as always, an important question
raises after all that. Would it still be a good idea realizing this
one-platform approach with Ruby? Wouldn’t it be more straightforward to
choose Objective-C for MacOS or Java for Android? (Or even C# in the
less probable case of Windows?) Sure, my starting point was the choice
of a modern, relatively simple and interesting programming language, but
that was closely linked to my multi-plaatform hope. That being
shattered, isn’t the linguistic disadvantage of Objective-C or Java
counterbalanced by the fact that they’re the most direct, maybe failsafe
ways to address their OSes?
By the way: you stated that you don’t know Qt and never
worked with WxWidgets. What GUI builder do you use, then?
Oops. There was a question here…
For my rare graphical user interfaces, I use Gtk+. I used it from C,
and found the Ruby wrapper quite nice to use (much more comfortable
than C!). Needless to say, I live in a Linux-only world.
I do not use the Gtk+ builder (Glade), though. I create each UI
component from source code.
well, making the decision to develop for one OS only will certainly
simplify my task. That’s not the path I intended to take, but I’m here
to
listen to people like you who obviously know what kind of venture is
reasonable.
If my motivation for this project was only a financial one, I’d’ve
dumped it long ago. It should attract a lot of people, but it may very
well call the attention of only a few of those who’re concerned by it.
Im’ doing
it because it seems to me that for once I might be the right person to
do it
As to the choice between Objective-C and Ruby: I’m already sure that
Ruby is going to be much more pleasant than Objective-C. I have just to
try out how Ruby is going to include Apple’s XCode UI elements and which
IDE and/or widget toolkit works best. Maybe a good idea to confront
Objective-C with Ruby may be to write a micro-application and see who’s
doing better… By the way: you stated that you don’t know Qt and never
worked with WxWidgets. What GUI builder do you use, then?
