I'll repeat my ideas from over a year on this board.
A WordPress website with a popular crowd funding plugin (e.g. Ignition Deck) so you can mimic the functionally and design quality of something alng the lines of Kickstarter. Alternatively use Kickstarter itself, awareness, engagement and trust are already much better. If you go the self-crowdfunding route the Theme needs to look modern to appeal to today's users, I stress 'today's users' as the site should continually attempt to engage with people outside the community.
I definitely feel I'm being limited, by many things in AmigaOS, I also feel I'm spending a lot of time writing things I think should have been provided in the OS.
Some of the API's like Picasso96 feels old, and primitive.
The File Notification API is inadequate from what I want.
UTF8 is poorly supported whit in the OS. There is not simple way for me to even display a UTF8 text string, unless I write my own Graphics.Library / Text() replacement.
Doing installation scrips that changes preferences is impossible, unless you replace the preferences, by replacing the file. No programmable API to add or change records whit in DefIcons prefs.
You might ask what the big deal is about, the issue is if I copy a old prefs file into, ENVARC: the old prefs file might be outdated, and system might not work, or the old file might not have settings that should be in the newer prefs files, the result is that AmigaOS/workbench might not work or work unexpected, and there might settings you did not want to change, that also get changed.
I know core developers do not care about it because they can deploy a new prefs file whit AmiUpdate, this is however not some thing a 3rd party developer can do, or want to do.
And also not having access to AmigaOS source code means that I can't change that, well I might spend time on Open reimplementation of some things, that already exists but just need some tweaking, and so the OpenAmiga effort is not really some thing, I see as some thing useful at all.
I can't just go a head and make my own replacement, graphic.library or replacement dos.library, its not how this works. All we get is incompatible versions and nor is it a option to write patches.
Edited by LiveForIt on 2014/2/23 12:00:35 Edited by LiveForIt on 2014/2/23 19:54:52
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
And also not having access to AmigaOS source code means that I can't change that
I've said it elsewhere and I'll say it again: Hyperion should open non-critical parts of the OS for contracted third-party access (the keyword here being "contracted", not "open-source"). If they don't want to do it, well, stupid but we still have OpenAmiga.org, so we had better make sure it comes to good use.
At least make easier for 3rd party developers to contribute to part of AmigaOS, it does not need to be open sourced, but at least provide away for 3rd party develops to do what they need, if core developers do not have time to do it.
I can understand that they do not want anything in there, but there most be possible to cooperate on things.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
I've said it elsewhere and I'll say it again: Hyperion should open non-critical parts of the OS for contracted third-party access (the keyword here being "contracted", not "open-source"). If they don't want to do it, well, stupid but we still have OpenAmiga.org, so we had better make sure it comes to good use.
But is this not the current situation? Frederick and Lyle spring to mind, but really any member of the dev team fits into this defintion of "contracted" acces.
You earlier sited BOOPSI for seperating out for special consideration but I know from bug reporting experience and resulting discussion with developers that BOOPSI is not easy to sepeate from intuition so simplistic third party access can't fix some of the issues.
Having said that nothing stops you from writing a third party class that you feel is needed and making it available to OpenAmiga -> AmigaOS (except possibly lack of example code) .
PS: IMHO third party devs should get on with writing apps, and so in the process find and report the bugs in the GUI componets etc, and *not* work arround them, at least not till they have fully described them. I do have the feeling that many devs simple think oops that doesn't work and then work around the issue with fully discussing it. I've specific examples of this from people wgho should no better but I'm not going to name names as I quite understand the need to get your app working come what may. Now there is a forum to do this it becomes much less excusable.
I must admit I have an advantage being a beta tester as I can submit my uissues direct to Bugzilla, but a number of issues have been fixed that enable sketchblock to progress. An example now public would be support for tablets in window.class windows. I could have ignored that issue and reverted to a plain intuition window for the main window but instead I made a full report and the issue got adddressed.
Having said that nothing stops you from writing a third party class that you feel is needed and making it available to OpenAmiga -> AmigaOS
Of course, I have no problem with that route. Looking at my first post in this thread you'll see that I have actually been advocating an improvement along the OpenAmiga -> AmigaOS channel. It's just that the OpenAmiga.org vehicle needs attention and repairing here and there.
Quote:
I must admit I have an advantage being a beta tester as I can submit my issues direct to Bugzilla
That indeed is an advantage. Why is Bugzilla only available to betatesters and not common developers is quite beyond me. Especially when a developer is more likely to spot a bug deep in the system. Xenic's and Chris' recent finding of messaging being broken in amigaguide.library is a good example - a betatester would have never found this bug; it needed a developer who started fiddling with the messages.
Bugzilla access for developers is another thing that could speed up OS development. I'm putting that on my list.
Especially when a developer is more likely to spot a bug deep in the system. Xenic's and Chris' recent finding of messaging being broken in amigaguide.library is a good example - a betatester would have never found this bug; it needed a developer who started fiddling with the messages.
This emphasises my point about third party developers building application, and so finding the bugs.
Quote:
Bugzilla access for developers is another thing that could speed up OS development. I'm putting that on my list.
I've no idea whether that could be facilitated or not, but in the mean time we do have the hyperion forum for reporting such issues as they are found.
Well I have asked for UTF8 support in Graphic.libary years ago, but nothing has happened, I was asked to make my own using bullet API, really is that easiest way to display a UTF8 string.
I have also asked for a way to import setting using XML or JSON, years ago, but nothing has happened.
The Picasso96 API has bugged me for years, I have always created my own functions to draw stuff, but way should I need to do that, yes I know it is possible to use Graphic library to do stuff, but that require you to setup a RastPort, a Palette and Pens and so on.
Essentially I think the API is primitive.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
Well I have asked for UTF8 support in Graphic.libary years ago, but nothing has happened, I was asked to make my own using bullet API, really is that easiest way to display a UTF8 string.
I believe I have too - but there's a forum for these requests now, so it's worth mentioning again.
Bugzilla access for developers is another thing that could speed up OS development
Yes, but you can still report some bug to all betatesters. Just provide a binary and an explanation of the bug, and we'll add it to bugzilla. We have done so several times. No need to wait here