If things would be "open" (in your definition), would you contribute any more than you do now?
Yes, I would.
Would it make any difference from you whether the Os sources would be accessible for you?
Yes, it would make a big difference.
If so, why?
Because sources are often where one find the best documentation. Because with sources available one can actually read what the code is supposed to do. Because with sources available one can alter them, build, test out, debug etc, and potentially improve the code and submit patches. Most important though - and I am sure you would not approve - is that would allow regular users to build and share "special versions" among each other, and allow fixes to be dealt with swiftly, instead of having to wait months/years for updates that may or may not include fixes for the bugs I (and others) are struggling with.
What does the current model stop you from doing right now you would be able to do otherwise?
The current model prevents me from having any clue what bugs are known and which bugs are not, or even know what is bug and what intended feature, as both changelogs and list over known bugs are kept "secret".
and just be happy.
Who says I am not happy? I am happy, Amiga is just a hobby, and if there was less to complain about regarding the OS development, I would happily complain less - but the things way are now, there is just so much... nonsense... going on.
Instead of contributing to the solution, you stick around, spread bad mood, complain, keep naging, and otherwise.... do nothing.
Well, you know what? Complaining, nagging etc has proven be to be most effective method of getting useful information. Yeah, it's a sad thing.
WBLoad is _only_ for opening programs that for some weird reason cannot be opened from CLI directly - personally I don't even know of any such program (and I would find such a program that only can be launched from Workbench to be rather broken).
No, it is for programs where you put parameters into icons as tooltypes, and you want to pass over exactly these arguments in the tooltypes to the program run, and not use the CLI parsing branch of the program. Thus, where you must ensure that the program behaives exactly as if double clicked from the workbench.
Again, you write "program", and yes, for exactly that, it works.
If it at least could open files/drawers that have "project" type icons and an associated default tool,
Which it does. So, you haven't tried. See what I mean by "users"?
I have tried, and it did not work...
So it is supposed to work, you say....well after some testing I can say that it _only_ works if default tool is specified with full path - it doesn't care about shell path, and it doesn't care about workbench path - it only uses current directory as path. Where is this documented? Guess I just reported another bug, then... ouch, that was unintended.
Secondly, it does not return until the started program returns, not sure why this is a feature, but perhaps if you have some obscure (broken) program that you insist on puttin in startup-sequence, and you don't want to continue startup-sequence until user has exited....
It can. Put a "&" as last argument. Oh, that's an "obscure" shell feature? Nevermind, it does work.
Well, I prefer to stick with old "run >NIL:" which one can rely on, regardless of which broken version of Amiga shell that is used. But I still don't understand _why_ it should not detach by itself - by not detaching, it suggest that one can do something useful with the input, but nothing is described, and it doesn't handle ctrl-signals... so what is the point of not detaching?
It also does not pass on ctrl-signals to the program that is started, even when those programs accept ctrl-signals themselves...
Since when do workbench programs care about ^C? You can send them a signal if you want.
Well, don't just about all programs that ship with Workbench care about ctrl-c? All prefs programs, all commodities, tools like multiview etc.
bug, lacking feature, who knows.
I know. You troll.
In most cases, it looks like you are the only one who knows, even people like Gulliver more often than not, does not know and must check with you.
Thirdly - does it even care about the associated .info file?
If you ask this question, you don't know how WBStartup works.
WBStartup? Or did you mean WBLoad?
WBStartup cares about tooltypes like DONOTWAIT and WAIT - imagine if WBLoad could support those too, _that_ would actually have been useful - DONOTWAIT would detach, and WAIT, if present, could be used to specify for how long to wait before detaching. Consider this a feature request... oh now, I did again - sorry, not my intention to contribute with constructive criticism and ideas - I am really just here to whine!
I admit I have not tested... but I am not be surprised if it does not. Meh... pfew...
No, you haven't.
And I admitted it, it was the one example I took reservation with.
You just come around trolling, complaining, not willing to contribute in any particular form.... Kolla, you are a shame for this "Community", and you are one of the top reasons why any form of "open development model" is a very bad idea.
So you are saying that *I* am the number one reason why keep the development model as it is? Wow, I am flattered!
Seriously, sit on your bottom, and write programs yourself. Help, contribute, then you are entitled to criticize because you've proven that you can do better. Actually, all you show is "I don't care, I don't want to do better, I just want to complain".
What's just wrong with you? Do you enjoy complaining instead of doing?
Dr. Thomas is at it again? Why can you not stick to the topic instead of going on rants with personal attacks and asking suggesting questions? For the your information, nothing is wrong with me, I am also not complaining for the sake of complaining, you just take any sort of criticism of the product as a personal attack against yourself.
