Now that SAM is imminent, maybe new developers can help with old projects. Hence I wonder....
We need a wxWidgets port... that'd open the doorway to things like Audacity, which would be great (AmiSoundEd is a nice little program but doesn't have the capabilities of Audacity (yet?)).
There must be other projects...
Is there a nice webpage somewhere describing what projects should be done? Maybe prioritising them according to usefulness. I'm talking realistic projects here, like wxWidgets or MAME rather than OpenOffice or something.
If we prioritise correctly, we can start with team efforts on small projects which will allow us to work on larger projects as the necessary dependencies are fulfilled.
Is there such a resource? If so we need everyone who has an OS4 machine to know about it, and there'll be plenty more of them now SAM is (more or less) here!
I know that wxWidgets has a sourceforge project but it's very out of date now. We need a concerted effort, a proper coding team, to get the ball rolling... maybe SAM's arrival is the kick up the backside we all needed!
I don't know of any list. However, JAmiga (Java) is high up on my list of things that we want. Someone should have a look at Firefox 3's dependencies. I'd still like to see Firefox ported.
Yes, WxWidgets is important. That's what I will be using when I start writing cross-platform apps, so having it on the Amiga would be great.
Could use the OpenAmiga.org website engine to set up a website for such an effort.
But: 1, Getting people in the amiga community to help out is very very very, times infinity, hard. 2, I won't run the website for you, I have too much on my plate already. But I could provide the website engine to anyone who would want to do it.
I would like see some kind of graphics package for Python. I use python all the time instead of old BCPL. It's way more powerful via object orientation/classes. I don't now how to compile new modules yet.
If we prioritise correctly, we can start with team efforts on small projects which will allow us to work on larger projects as the necessary dependencies are fulfilled.
Is there anything more recent happening that than sourceforge thing? Looks awfully quiet and most of the cvs repository is dated two years ago. A couple things are 11 months or 9 months old, but still not terribly inspiring. And no user package for download. I've found a couple apps using wxwidgets that I'd love to see ported.
wxWidgets has just been suggested on www.amigabounty.net and it seems like a VERY good project if you ask me.
Which applications will be within reach if we get wxWidgets. I mean applications that doesn't have many other dependencies.
Would it be possible to make a list of our most desired applications (f.ex. a top ten). Then take this list and work out the dependencies the applications have. Then start work on the most needed dependencies in prioritized order?
It's very important we are realistic in what can be achieved.
One good thing about wxWidgets is that it would allow Amiga developers to reach a larger target audience.
Lets face it, AmigaOS4 is a very small market to develop for but if you used wxWidgets your applications would be easier to port to all major operating systems.
Example is Audio-Evolution that now uses wxWidgets (from v5) and runs on windows, macos, linux but not OS4(yet). Just mailed Davy and we will get a port as well when/if wxWidgets becomes available.
Because it is C++, I think it might be easier to port than if it was done in C. Especially wxWidget is largely designed with portability in mind using clever OO concept to abstract system specific parts. Althought it does not change the fact it is a huge task to port it to AmigaOS especially if you want to do a true clean port (as we started to do with yomgui back in 2005 or was it 2004 ?)
In general, anything C++ rather makes it more complicated than C to port (and not only on AmigaOS :)), but I fear this will be seen as a troll (even though it really isn't).
With C++, you don't really have a well-defined standard, unfortunately. As a consequence, each compiler interprets C++ as it likes. And even between gcc versions, you can get incompatibilites/weirdness. Let's not even talk about binary compatibily between libs compiled for a version linked to a project compiled for another version.
Even about readability (which can be helpful for a port :)), it can sometimes be harder to follow. Things like references, inheritance and templates can make it harder to follow codepath (of course it's doable, but it just takes more time). All this heavily depends on projects of course.
@spirantho
I think you never received my late reply about mame, but i still have mame morphos source code at hand if you want to have a well amigaized port (and not only a plain sdl port).
With C++, you don't really have a well-defined standard, unfortunately. As a consequence, each compiler interprets C++ as it likes. And even between gcc versions, you can get incompatibilites/weirdness. Let's not even talk about binary compatibily between libs compiled for a version linked to a project compiled for another version.
The language standard is pretty well defined. What's missing is a standard for the ABI. Basically, it's up to the compiler to decide how classes/objects are implemented. This appears to be true of pretty much any OOP language. If there were a standard ABI then it would be possible to pass OOP objects to shared libraries without worrying which compiler it came from.
Quote:
Even about readability (which can be helpful for a port :)), it can sometimes be harder to follow. Things like references, inheritance and templates can make it harder to follow codepath (of course it's doable, but it just takes more time). All this heavily depends on projects of course.
A lot of this has to do with poor coding style. I've seen some really unreadable code in C as well. Granted, C++ is harder to come to grips with (being a superset of C, it's not surprising), but it is very powerful. I wouldn't write a huge app. in C because OOP really helps dealing with large complex systems.
One good thing about wxWidgets is that it would allow Amiga developers to reach a larger target audience.
This is exactly why I want a wxWdigets port, and why I'll be using wxWidgets when I write a new app. This is also why I signed up to the wxWdigets-aos project on sourceforge. Unfortunately, I need someone else to update to the latest wxWidgets version and get things moving. I'm not good at porting stuff, and my knowledge of wxWigdets and the Amiga OS GUI system is limited. We need a team of several people to make this happen.
@Hans The language may be defined with a standard by a committee and all, but I don't know any compiler that follows it completely. So that doesn't help much. :)
About ABI, well, you said it, there's no standard there too.
And about readability, you certainly can do awful things in C (or in any language for that matter), but since C++ adds sophisticated stuff (or should i say cryptical or obfuscated) compared to C, you can produce even uglier code in C++ (which often happens, unfortunately). But I don't say you can't have proper C++. My original point was just to disagree about the idea a lambda project should be more portable just because C++ was chosen over C.
I remember saying that already back when the wxwidget-aos project was brought up on aw.net:
Coincidently i started to look at wxWidgets myself just some days before that thread and it took me only some hours to update the wxwidget-aos stuff to the latest official wxWidgets.. thats really no big deal if you know how to use "diff" or if you cheat like me with using WinMerge on Winblows
I wanted to contribute that stuff but i never found the time to clean it up and then i also just forgot about it..
Well, it's outdated again in the meantime probably so it wouldn't be of great use anyway, but if you want i will note it down to my todo-list and have a look again on that code, update it to the latest wxWidgets and send it to you. But be warned: it will take some time until i can spend some time on it again. AND: I probably won't contribute to the project itself anything.. at least not in the foreseeable future (i.e. implementing the AOS backend).
@ all In general to wxWidgets: A "port" of wxWidgets isn't just a matter of getting the thing to compile.. but it isn't as hard as one might think either.. the porter has first to get the very basic stuff compiling and working (wxWidgets-aos and wxBase are good starting points), then implement one widget (and maybe one or another classe) after each other to slowly build the AOS backend. It's by all means doable if the porter(s) are somewhat familar with C++ (fortunately wxWidgets doesn't use the really weird stuff of C++.. or at least not extensively ;) ) and of course with Intuition / Gadgets programming.. i'm not sure if a BOOPSI based approach would be usefull/feasable in the wx backend..
And regarding the bounty suggestion: I also think it is a very good bounty candidate. We just would need a proper description of the bounty and especially it's goals.. i.e. what has to be implemented and how has it to be to fullfill the bounty requirements (which also have yet to be defined).
Please have a look over in the Amigabounty.net forum which i just started and tell us your thoughts in this thread
AmigaOS 4 core developer www.os4welt.de - Die deutsche AmigaOS 4 Gemeinschaft
"In the beginning was CAOS.." -- Andy Finkel, 1988 (ViewPort article, Oct. 1993)
Cyborg wrote: @Hans Well, it's outdated again in the meantime probably so it wouldn't be of great use anyway, but if you want i will note it down to my todo-list and have a look again on that code, update it to the latest wxWidgets and send it to you. But be warned: it will take some time until i can spend some time on it again. AND: I probably won't contribute to the project itself anything.. at least not in the foreseeable future (i.e. implementing the AOS backend).
Please if you ever do a diff again send it to me (I'm one of the project Admin on SF.net) I'll then be able to commit it. Feel free either to post it as a path on SF.net that would do the same. Also even if you did not have the time to update it, maybe you can anyway send the patch it would be better on SF.net with someone having the oportunity to use it rather than lying on your HD doing nothing Anyway we (Yomgui and me) when we started it thought that rather than constantly running behind the latest CVS (at that time it was CVS) version we would better work on the latest (again at that time) stable release version. When you have finish it will always be possible to update to any more recent stable version. I guess the bounty should also fix the version number.
@Fab
Ok my turn to be a troll that's true that C++ is more complicated to port than C when you are still using 10 years old GCC with half working C++ support Ok serious again now, what I meant was that generally with well written C++ (no so common I admit) porting might consist "only" in porting some well defined classes really doing system operations, no need to hunt for the entire code looking for any fork() or execvp() calls Reading your post I guess you are really a pro-C guy, I remember I was too until I discover C++ back in 1997 which was really a revelation and an amazement. I can't see where C++ is more cryptic than C (try to explain C/=(A!=0?A:^A) which is plain C to an Eiffel fan or a Delphi adept you will see how understandable C is for them
Ok my turn to be a troll that's true that C++ is more complicated to port than C when you are still using 10 years old GCC with half working C++ support
For the record, I made several ports to MorphOS using GCC3.4.6 & GCC 4.2.0, especially for C++ projects. If GCC 2.95 is the only one officially supported, the later versions are available anyway, but unsupported, and for a good reason, but that's another topic. I also stumbled on code generation errors with these cutting-edge GCCs btw (which 2.95 was compiling flawlessly). :) There for the troll. :)
Quote:
Ok serious again now, what I meant was that generally with well written C++ (no so common I admit) porting might consist "only" in porting some well defined classes really doing system operations, no need to hunt for the entire code looking for any fork() or execvp() calls
As for your fork()/execve() example, it's really badly chosen. Encapsulation/Separation has nothing to do with C or C++. In any good C or C++ project, you can have a well defined and separated backend avoiding you from reading the whole source code (mame being a good example for a C project, or ScummVM for a C++ example). C++ doesn't help more than C there, not at all. But I somehow fear you think OOP might only doable with C++ and not C, which is really really wrong.
Quote:
Reading your post I guess you are really a pro-C guy, I remember I was too until I discover C++ back in 1997 which was really a revelation and an amazement. I can't see where C++ is more cryptic than C (try to explain C/=(A!=0?A:^A) which is plain C to an Eiffel fan or a Delphi adept you will see how understandable C is for them
I may be a pro-C guy, but I also know C++ for ten years now, and using it everyday at work (fortunately we avoid the most stupid and useless C++ extensions). But once again, your example is badly chosen since it applies to C++ as well. Let's take templates syntax, references and operators overloading as examples of syntax horrors and readability issue/error-prone code. :) And don't assume I don't know C++ enough (I know how to use the things I criticize), I just happen to not like them, and I'm not the only one. :)
For the record, I made several ports to MorphOS using GCC3.4.6 & GCC 4.2.0, especially for C++ projects. If GCC 2.95 is the only one officially supported, the later versions are available anyway, but unsupported, and for a good reason, but that's another topic. I also stumbled on code generation errors with these cutting-edge GCCs btw (which 2.95 was compiling flawlessly). :) There for the troll. :)
I hope you understood that I was deliberately teasing you, didn't you ? hence the "my turn to be a troll" introduction followed by a smiley.
Quote:
These posix calls have nothing to do with C or C++, and in any C or C++ project, you can have a well defined and separated back-end avoiding you from reading the whole source code (mame being a good example for a C project, or ScummVM for a C++ example). C++ doesn't help more than C there, not at all.
The idea was to say that generally it's much more localized than in C. Nothing more, anyway I agree that they are tons of very well written (considering portability) C programs at least as much as very badly written C++ ones
Quote:
But I somehow fear you think OOP might only doable with C++ and not C, which is really really wrong.
Not at all, BOOPSI is a good example of OOP programming in C, and its beginning C++ (which was named at that time "C with classes") was implemented as a preprocessor generating C code. OOP can be implemented in any language given you have enough motivation (yes even ASM), but it's always easier to use OOP language when you want to do OOP programming (no need to reinvent the wheel, "the suitable tool for the required task" as we say in French )
Quote:
But once again, your example is badly chosen since it applies to C++ as well.
Yes that was the point : C is not less cryptic than C++.
Quote:
Let's take templates syntax, references and operators overloading as examples of syntax horrors and readability issue/error-prone code.
Those are concepts, that if you don't understand them fully you don't see there interest and will find them only obscure. However that's were some of the C++ strength resides : - just see how java programmers were laughing at C++'s templates just to adopt them in there latest language incarnation claiming its the best thing on the earth) - references are nothing more than the IN/OUT modifier of ADA (any Java programmer can tell me how I can have a Boolean function that also updates one of its String parameter ?) - operators overloading enables consistency in the language however some people are (over)abusing it to do things not related to them... That's the problem.
You have as much the right to prefer C than me to prefer C++. But we are highly out of topic here
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
