ok, folks, i've been reading more about QT. looks like it's a good choice. C#/.net/mono, although i would really like to use it, has perhaps the following problems: possible MS patent lawsuits, mono trails .net by a version or two, look and feel of gui written on PC has inadequate look and feel on OS X, i'd have to write my own midi and hi-res timing routines for each platform (if i understand correctly, QT/RTmidi takes care of all this). some of this is discussed here:
so, assuming i understand all of this properly (and i assure you i'm a very mediocre programmer with limited understanding of the above issues), i now have to choose which qt-compatible lang to write in. i'd rather avoid C++, if possible. i'm coming from delphi, i never liked the various non-ergonomic qualities of C++.
there appear to be QT "bindings" for various langs, including C#, Python (is Python even a compiled lang that runs quick?), etc. i have yet to understand whether those "bindings" include QT's hi-res timing routines (or whether the "bindings" are inherently slow in themselves, regardless of lang), and i have yet to understand how much of a pain it would be to get RTmidi up and running for PC and OS X platforms in this context.
it appears that at least PyQT (see above) is licensed under GPL, not under LGPL. i gather from our earlier discussions that that's bad for me, if i desire to release my software comm'ly, which i do.
the whole thing is quite confusing, to say the least. perhaps i should just "suck it up" and go at C++.
> > I tried to read the LGPL specs and it was a bit over my head. If I
> > can use QT open source edition to create software that I will sell,
> > and I don't have to publish the source code, why would anyone ever buy
> > the comm'l version? Or is it that QT open source edition projects
> > have to be distributed as freeware?
>It was GPL before so only GPL projects could use the open source
>edition hence the commercial version. they only changed recently LGPL
>now no one needs the commercial version unless you want all the
>commercial support.
>L.
> > -P
> > At 03:04 PM 9/9/2009, Louis wrote:
> >> Look for QT open source edition it is totally free of charge it is also
> >> free (as in freedom). it used to be licensed (like piano booster) under
> >> GPL meaning that commercial companies could not use it without also
> >> publishing their source code -- so they also sold a commercial version
> >> of QT. Now QT is licensed under LGPL and so there is no obligation to
> >> publish the source code.
I'm thinking of doing something similar. The only issue I need to
examine is the midi related stuff on each platform. I know windows,
but Linux and Mac are totally unknown to me. I do have a decent custom
Midi library. With that I should be able to plug in different port
impl's for each platform.
I was thinking of doing the app in C#. If I understand correctly QT
(or Qyoto) will render native looking UI on each platform (is that
your conclusion also?). If not, I use optimal UI technology for each
platform. This will force me write a different UI for each platform,
but with a good architecture that layer can be as thin as possible.
The core (business layer) of the application will be shared among
platform using mono.
I haven't looked into licensing yet, though. I would never go with
GPL, thats for sure. I also want to keep the option to go
commercial. ;-)
I have just started looking at cross-platform development and like the look of wxWidgets and Code::Blocks as the IDE. I also come from Delphi and intend to use C++ initially, but perhaps Python for the UI.
----- Original Message ----- From: Paul A. To: mididev@googlegroups.com Sent: Sunday, September 27, 2009 11:57 PM Subject: [mididev] QT/RTmidi (was "Re: Hello form the PianoBooster (open source) dev guy")
ok, folks, i've been reading more about QT. looks like it's a good choice. C#/.net/mono, although i would really like to use it, has perhaps the following problems: possible MS patent lawsuits, mono trails .net by a version or two, look and feel of gui written on PC has inadequate look and feel on OS X, i'd have to write my own midi and hi-res timing routines for each platform (if i understand correctly, QT/RTmidi takes care of all this). some of this is discussed here:
You ask me my conclusion. Before I give it to you let me remind you that if you were to call me a "mediocre programmer" with "limited understanding of these basic issues", that would be a huge and unwarranted compliment. Regarding these issues I am mostly, at this point, operating on fear, ignorance and superstition. Same regarding _all_ life issues, according to my teenage child. Well, "ignorance", anyway.
My understanding is, yes, that QT will do a good job of rendering native-looking UI on each platform. Since, like you, I'm ignorant about Mac/Linux, I don't have any feel for how much of the GUI look/feel on these other platforms is programmer-driven, and simply cannot be replicated with a clever cross-platform lib by pushing a compiler button.
Coming from Delphi, I myself would vastly prefer to use C#/qt/qyoto, but C#/.net/mono has the problems, or potential problems, I listed in my previous post. I'm wary of it. I also have no feel for how much a C# program would be write/compile once, and the Qyoto/RTMidi libs would be write once, compile three times. Obviously, the preceding sentence would be ideal. How much hacking would be needed to get the whole thing to set up, compile and run on all three platforms under C#/.net/mono, I have no idea. According to an earlier post here (Utku's post of Sept 10th), regarding the convenience of the scheme under C++:
>As for runtimes, there is none to install with Qt, you just deploy >the libraries you use along with your app.
"Deploy"? May I assume that means that one links in the libs to one's code, and they automagically compile properly for each platform, without any code change?
>I'm thinking of doing something similar. The only issue I need to
>examine is the midi related stuff on each platform. I know windows,
>but Linux and Mac are totally unknown to me. I do have a decent custom
>Midi library. With that I should be able to plug in different port
>impl's for each platform.
>I was thinking of doing the app in C#. If I understand correctly QT
>(or Qyoto) will render native looking UI on each platform (is that
>your conclusion also?). If not, I use optimal UI technology for each
>platform. This will force me write a different UI for each platform,
>but with a good architecture that layer can be as thin as possible.
>The core (business layer) of the application will be shared among
>platform using mono.
>I haven't looked into licensing yet, though. I would never go with
>GPL, thats for sure. I also want to keep the option to go
>commercial. ;-)
>No virus found in this incoming message.
>Checked by AVG - www.avg.com >Version: 8.5.409 / Virus Database: 270.13.113/2398 - Release Date: >09/27/09 05:51:00
Why C++ only "initially"? If you're willing to deal with C++ (which is not generally considered a RAD prototyping lang), why would you rewrite code later? And to what lang?
I believe that "Transcribe!" (slow down and/or change pitch of music and/or loop for transcription purposes) was done with wxWidgets. I believe the author told me that the cross-platform GUI would require some further programmer intervention to get the Mac look and feel more correct for Mac users (who are known to be particular about GUI look and feel issues), but at least the widgets were native and the program usable and sellable in its current form.
"Code::Blocks"? I never heard of it til now, but I remain confused about GPL licensing: http://www.codeblocks.org/license I thought we all had this discussion recently and concluded that Qt is of more interest because it's recently been amended to LGPL licensing, which allows proprietary for-profit programs to be written and marketed. Yes, I could RTFM, but I already tried and didn't really grasp all of the GPL verbiage.
>I have just started looking at cross-platform development and like >the look of wxWidgets and Code::Blocks as the IDE. >I also come from Delphi and intend to use C++ initially, but perhaps >Python for the UI.
>Regards >-Mike
>----- Original Message ----- >From: <mailto:sanitat...@earthlink.net>Paul A. >To: <mailto:mididev@googlegroups.com>mididev@googlegroups.com >Sent: Sunday, September 27, 2009 11:57 PM >Subject: [mididev] QT/RTmidi (was "Re: Hello form the PianoBooster >(open source) dev guy")
>ok, folks, i've been reading more about QT. looks like it's a good >choice. C#/.net/mono, although i would really like to use it, has >perhaps the following problems: possible MS patent lawsuits, mono >trails .net by a version or two, look and feel of gui written on PC >has inadequate look and feel on OS X, i'd have to write my own midi >and hi-res timing routines for each platform (if i understand >correctly, QT/RTmidi takes care of all this). some of this is discussed here:
> Why C++ only "initially"? If you're willing to deal with C++ (which is not generally > considered a RAD prototyping lang), why would you rewrite code later? And to > what lang?
I guess that came out wrong. I am concerned about performance issues playing multiple video files and want as few layers as possible between me and the hardware. I was planning to use C++ for the back end and possibly using Python for the UI. However, I have a long learning curve ahead of me and don't really know if what I want to do is even possible.
The problem with Qt vs wxWidgets is that they both make similar claims and I don't know anyone who has compared them on a resource critical application.
The reason I'm starting with wxWidgets is that I know someone who already uses it and is willing to help with teething problems. Unfortunately, he does not do multimedia so I'm on my own there.
> "Code::Blocks"? I never heard of it til now, but I remain confused about GPL > licensing:
It's just an IDE so none of the code from Code::Blocks appears in your program, so the GPL license doen't matter unless you are planning to extend it.
> choice. C#/.net/mono, although i would really like to use it, has
> perhaps the following problems: possible MS patent lawsuits, mono
At first (several years ago) it looked like that might be an issue,
but it doesn't look like that's the case anymore.
> trails .net by a version or two, look and feel of gui written on PC
> has inadequate look and feel on OS X, i'd have to write my own midi
I've done a lot of Mac development (see my post
http://groups.google.com/group/mididev/browse_thread/thread/7697e845f...).
Apple has a UI style guide that is much more tighter and stringent UI
style guide than Windows. If you design to Apple specifications your
application will be fine on both OSX and Windows. Designing on Windows
first and then porting 1:1 to the Mac is where problems will occur.
The first thing I would do is get a Mac, immerse yourself in the
platform, and figure out what you want to do. What you are doing is
akin to a Linux developer with no knowledge or understanding of
Windows jumping in and developing for Windows. I think that's why so
many Windows applications fail on OSX as they look very out of place
and klunky.
> My understanding is, yes, that QT will do a good job of rendering
> native-looking UI on each platform. Since, like you, I'm ignorant
> about Mac/Linux, I don't have any feel for how much of the GUI
> look/feel on these other platforms is programmer-driven, and simply
Qt draws everything so that everything looks native, but the issue is
from the UI layout and design, and the application workflow.
Applications on OSX (for the most part) are polished and have a
similar/common feel to them.
> cannot be replicated with a clever cross-platform lib by pushing a
> compiler button.
Unfortunately, no. One needs to know and understand the platform
before developing for it.
On Sep 28, 11:31 am, Jeff <jbeeg...@gmail.com> wrote:
> > choice. C#/.net/mono, although i would really like to use it, has
> > perhaps the following problems: possible MS patent lawsuits, mono
> At first (several years ago) it looked like that might be an issue,
> but it doesn't look like that's the case anymore.
Mono is not under any imminent threat of MS lawsuits. Even if it
were, I doubt very much that Microsoft would kill Mono without having
anything in hand to replace it (and there are rumors that they do have
something like it in development). There are two many large companies
already using it, and killing it would probably produce an extremely
negative backlash against MS.
> I've done a lot of Mac development (see my posthttp://groups.google.com/group/mididev/browse_thread/thread/7697e845f...).
> Apple has a UI style guide that is much more tighter and stringent UI
> style guide than Windows. If you design to Apple specifications your
> application will be fine on both OSX and Windows. Designing on Windows
> first and then porting 1:1 to the Mac is where problems will occur.
> The first thing I would do is get a Mac, immerse yourself in the
> platform, and figure out what you want to do. What you are doing is
> akin to a Linux developer with no knowledge or understanding of
> Windows jumping in and developing for Windows. I think that's why so
> many Windows applications fail on OSX as they look very out of place
> and klunky.
Yes, just like iTunes fails miserably in Windows, where it not only
looks out of place and klunky, but also behaves out of place and
klunky.
> Yes, just like iTunes fails miserably in Windows, where it not only
> looks out of place and klunky, but also behaves out of place and
> klunky.
Exactly! Even going Mac->Windows doesn't always work. I think the
best approach would be:
- Target Windows first (if that's the OS the Paul is developing on)
- Release
- Then develop a Mac-only version
- Release Mac-only version
- Then, after tackling all of the UI and performance issues, for 2.0
attempt a single codebase.
This is what I'd do, also, except that I would create my own UI
elements for everything (buttons, text display etc.). I think doing
this would be very bad practice for an app meant to run on only one
OS, but if you're explicitly intending to be multi-platform, why not
make your app look the same on all operating systems by making it look
different from all operating systems? Creating your own controls
in .Net is extremely easy, and I have aesthetic issues with both
Windows and Mac anyway.
On Sep 28, 12:37 pm, Jeff <jbeeg...@gmail.com> wrote:
> > Yes, just like iTunes fails miserably in Windows, where it not only
> > looks out of place and klunky, but also behaves out of place and
> > klunky.
> Exactly! Even going Mac->Windows doesn't always work. I think the
> best approach would be:
> - Target Windows first (if that's the OS the Paul is developing on)
> - Release
> - Then develop a Mac-only version
> - Release Mac-only version
> - Then, after tackling all of the UI and performance issues, for 2.0
> attempt a single codebase.
> This is what I'd do, also, except that I would create my own UI
> elements for everything (buttons, text display etc.). I think doing
> this would be very bad practice for an app meant to run on only one
> OS, but if you're explicitly intending to be multi-platform, why not
> make your app look the same on all operating systems by making it look
> different from all operating systems? Creating your own controls
This I disagree with (I'm assuming that you are referring to drawing
your own menus, dialog boxes, push buttons, check boxes and other
standards controls).
I've heard others use the same arguments before (I spent 10 years
working on projects which were either Mac-only, or Mac + Windows cross-
platform, and this topic came up before), but to the user, it just
looks weird. That approach has some merit if your users use your
application on multiple platforms, but 95% of all users will only use
your product on a single platform (that's just a WAG - I don't have
any hard numbers). So what ends up happening is the user will not
notice that they are exactly identical, they'll only notice that your
standard UI elements look different from the rest of the applications
on their machine.
At Adobe we did this - Adobe had their own UI design docs and
guidelines and everything was identical, down to the color of the
dialog box and the font in the dialog boxes, and it just ended up
looking weird.
> different from all operating systems? Creating your own controls
>in .Net is extremely easy,
Yes, they are, but that doesn't mean one should ;-). I see this akin
to the early days of desktop publishing. Just because you might have
thousands of fonts installed on your machine doesn't mean you should
use them all within a single page ;-).
>and I have aesthetic issues with both Windows and Mac anyway.
Ah, but your users don't. I personally like the 3D look of Mac OS 9
over OSX's appearance, but 100% of the Mac users that I know (and this
is a valid number) like OSX's appearance. Mac users LOOOOVE their
UI. If I were to develop an application which drew its own version of
the standard controls, to the user it just looks odd.
You also get users complaining (and they do) that changing the UI
settings in the system doesn't have any effect on your program.
Now, there are exceptions to this rule. MIDI and audio applications
tend to have very rich UIs, and our applications tend to have sliders
and knobs and graphical piano keyboards and all sorts of things, so if
your application's main window has quite a bit of custom controls, it
might look odd to mix them with the standard controls of the OS. This
particular scenario is a candidate for implementing your own standard
controls so the window looks aesthetically unified, however I would
still keep all dialog boxes standard with standard controls. I think
Leslie Sanford's applications are good example of this. His Cobalt
application (http://www.lesliesanford.com/Cobalt.shtml) is mostly made
up of sliders and knobs. If he used the standard combo box and radio
button controls it would just look weird, so in that situation, I
think using custom standard controls was the right way to go.
On the other hand, look at Overtone Analyzer (http://www.sygyt.com/).
It was custom controls in its window for displaying the wave and
frequencies, but the rest of the UI, like the menu bar, tool bars and
status bar, are all standard controls.
I guess it all depends on the situation. If your application just has
standard controls, then use the standard UI, but if the majority of
your window has custom controls then that is a candidate for
overriding the standard controls.
the uses of LGPL library is different as there is no requirement to release your source code when linking to a LGPL library.
As regards to QT and wxWidgets I have used them both (with C++) and they are both absolutely excellent. wxWidgets was the one first comprehensive libraries to used native widgets on all platforms and to have the LGPL license and so it was used by a lot of commercial companies. Qt
followed with native widgets some time later with LGPL and so there is now not much to choose between them. Qt is a bit more polished and easer perhaps to setup but you cannot go wrong with ether of them. Regarding C++ is a difficult language and took me a long time to learn, but as stated a previous email the use of "Implicitly Shared Classes" can make using these type of classes as easy as in C#/Java. I recommend using them for your own classes.
> But Qt does make life easier with a good toolkit and their Implicitly
> Shared Classes see these links below.
> Why C++ only "initially"? If you're willing to deal with C++ (which > is not generally considered a RAD prototyping lang), why would you > rewrite code later? And to what lang?
> I believe that "Transcribe!" (slow down and/or change pitch of music > and/or loop for transcription purposes) was done with wxWidgets. I > believe the author told me that the cross-platform GUI would require > some further programmer intervention to get the Mac look and feel more > correct for Mac users (who are known to be particular about GUI look > and feel issues), but at least the widgets were native and the program > usable and sellable in its current form.
> "Code::Blocks"? I never heard of it til now, but I remain confused > about GPL licensing: http://www.codeblocks.org/license I thought > we all had this discussion recently and concluded that Qt is of more > interest because it's recently been amended to LGPL licensing, which > allows proprietary for-profit programs to be written and marketed.
> Yes, I could RTFM, but I already tried and didn't really grasp all of > the GPL verbiage.
> -Paul
> At 04:36 PM 9/27/2009, you wrote:
>> I have just started looking at cross-platform development and like >> the look of wxWidgets and Code::Blocks as the IDE.
>> I also come from Delphi and intend to use C++ initially, but perhaps >> Python for the UI.
>> Regards
>> -Mike
>> ----- Original Message -----
>> *From:* Paul A. <mailto:sanitat...@earthlink.net>
>> *To:* mididev@googlegroups.com <mailto:mididev@googlegroups.com>
>> *Sent:* Sunday, September 27, 2009 11:57 PM
>> *Subject:* [mididev] QT/RTmidi (was "Re: Hello form the PianoBooster >> (open source) dev guy")
>> ok, folks, i've been reading more about QT. looks like it's a good >> choice. C#/.net/mono, although i would really like to use it, has >> perhaps the following problems: possible MS patent lawsuits, mono >> trails .net by a version or two, look and feel of gui written on PC >> has inadequate look and feel on OS X, i'd have to write my own midi >> and hi-res timing routines for each platform (if i understand >> correctly, QT/RTmidi takes care of all this). some of this is >> discussed here:
> tend to have very rich UIs, and our applications tend to have sliders
> and knobs and graphical piano keyboards and all sorts of things, so if
Speaking of which, there is an excellent application out there called
KnobMan which renders custom knobs (http://www.g200kg.com/en/software/ knobman.html). You still need to create your own custom control but
KnobMan will render the knob... you just draw it.
On Sep 28, 12:10 pm, "Paul A." <sanitat...@earthlink.net> wrote:
> >As for runtimes, there is none to install with Qt, you just deploy
> >the libraries you use along with your app.
> "Deploy"? May I assume that means that one links in the libs to
> one's code, and they automagically compile properly for each
> platform, without any code change?
> -Paul
I meant that the binary Qt framework is made up of a bunch of
libraries (DLLs on Windows) and you simply bundles these libraries
with your application. On Windows and Mac the libraries live under
your app folder so there is no issue of version conflicts. (I haven't
looked into Linux yet) The libraries themselves are precompiled for
each platform but you can also compile your own if you have different
requirements.
If you ask me, what you should do is simply install the various
frameworks mentioned here and try to write a simple project in each of
them (and maybe in each language as well) to see how each fares.
Then maybe install a "slightly modified" version of OS X in a spare
partition and see how the project translates with each framework.
I'm developing on Win, yes. While I may follow your advice here, I think I need to spend a little time starting to focus more on the reality of the cross-dev tools, so at least there's the possibility of a remote chance I'll be able to re-use substantial portions of the codebase.
>Exactly! Even going Mac->Windows doesn't always work. I think the >best approach would be:
>- Target Windows first (if that's the OS the Paul is developing on) >- Release >- Then develop a Mac-only version >- Release Mac-only version >- Then, after tackling all of the UI and performance issues, for 2.0 >attempt a single codebase.
> - Target Windows first (if that's the OS the Paul is developing on)
> - Release
> - Then develop a Mac-only version
> - Release Mac-only version
> - Then, after tackling all of the UI and performance issues, for 2.0
> attempt a single codebase.
No that is not way I would recommend (unless you WANT to have a
DIFFERENT UI for windows and mac -- which may be the only way IF you
want to follow all UI guidelines for both platforms -- granted). But
if you something that works across all platforms then I recommend that
you get a MAC + PC (plus Linux VM) and stick with a single codebase
right form the start as this is much easer. First compile the tool-kit
samples on all three platforms you should find that they all work just
fine on each platforms. You will find that with a good cross platform
tool kit like QT or wxWidgets that 100% of your code should work fine
on all three platforms. I had absolutely zero issues with RtMidi on
the different platforms they all just worked.
If you want to customise the UI behaviour on the different platforms
follow the UI guidelines/conventions then that is a different matter.
On Tue, Sep 29, 2009 at 5:27 PM, Paul A. <sanitat...@earthlink.net> wrote:
> Jeff:
> I'm developing on Win, yes. While I may follow your advice here, I think I
> need to spend a little time starting to focus more on the reality of the
> cross-dev tools, so at least there's the possibility of a remote chance I'll
> be able to re-use substantial portions of the codebase.
> Thanks.
> -Paul
> At 12:37 PM 9/28/2009, Jeff wrote:
> Exactly! Even going Mac->Windows doesn't always work. I think the
> best approach would be:
> - Target Windows first (if that's the OS the Paul is developing on)
> - Release
> - Then develop a Mac-only version
> - Release Mac-only version
> - Then, after tackling all of the UI and performance issues, for 2.0
> attempt a single codebase.
|
