Even a 667MHz Sam440 can run most A500 games fairly well on E-UAE (have you tried RunInUAE?). I'm sure that Natami is good enough that you don't need to lie about that.
Quote:
I can get better performance out of my Intel Mac Mini
As we move on to multi-core support, more and more backwards compatibilities will break, and good riddance I say.
If I wanted to cling onto OS3, I'd fire up my A4000 again, after 8 years it could probably do with a blowout.
Amiga has always been multicore, just not symmetric multicore. Custom chips always were able to do things in parallel.
Quote:
The original compatibility layer was present in the system to give the users and developers a way to run software that may have been required in those days. Luckily, a lot of that software has been recreated for OS4, and can easily be recompiled to account for any subsequent changes in the system.
If SDL software can be recompiled for OS 4 it can be recompiled for anything. This even includes several OS 3 compatible systems planned.
Quote:
If I really get nostalgic, I'll fire up UAE to run something, but I've never had need so far in 8 years, I very much doubt I'll start now.
In short, OS4 is not about the past, but about the future. Once the software library is big enough I'm hoping the "compatibility" is simply disabled and we can really get on with moving forward.
I seldom get nostalgic myself. That's why I use my Mac every day and my MicroA1c hardly ever. It already supports dual-core architecture but I only use that feature for parallel builds compiling large software. There's a lot of large software around too!
I think the key to the future is keeping things slim and trim. The long pipelines in the processor are the product of inefficient MMU hardware capabilities. A short pipeline may be slower sometimes but is usually more responsive.
Managed code is the way of the future but there is no AmigaOS 4-compatible solution that can compete with the likes of .NET, Mono, and Java. Even if there were, most software for the Amiga is still written in C and C++. If Amiga was about the future we'd be breaking from the trends of the present and moving on. No MMU necessary for managed code to run on it. We'd need something that would not only compete with Windows but ditch the Windows comparisons altogether in favor of comparisons to Microsoft SingularityOS.
For example will be nice to have in ASL requester a feature, which allow to coders create one more gadget string or dropdown menu, in requester window, where user can choice format for saving (for example) and return to coder that file format value. For users it will looks like: user choice path for saving in program which want to save files in more than one format, press format button/or choice it in dropdown menu, and press save. So, program can detect more easily what format are choicen, without parsing the full string. It also will give user a list of all possible format for saving for that program. Imho will be very usable for Text editors which can save more than in one format, image editors, music editors and video editors.
In other words, some kind as on all modern oses: dropdown menu, or gadget buttons for choicing the file format for saving.
The other good feature for ASL can be (can be also used or not used by coder): automatic put of file format. I.e. user press Save, and coder for example add to ASL ASLM_SaveFormat, ".jpg". And in requester, user have ".jpg" all the time at end of file name, and that ".jpg" can't be remove from string, only add filename for it. That will solve all that problem when user think "need add file format for file manually, or not".
Imho both features are important and will give users and coders more easy and friendly usage of ASL.
The other good feature for ASL can be (can be also used or not used by coder): automatic put of file format. I.e. user press Save, and coder for example add to ASL ASLM_SaveFormat, ".jpg". And in requester, user have ".jpg" all the time at end of file name, and that ".jpg" can't be remove from string, only add filename for it. That will solve all that problem when user think "need add file format for file manually, or not".
Hmm ?? You are deeming this as a "modern feature" ??? Amiga never used file extension, on amiga file extensions are part of the filename and are only human understandable indaiction of what the file is but the system never used that to identify a file format (come on we are not on a certain Micr****t OS here IMHO a programmer should never only rely file extension in his programs.
@Rigo
I would only say : "Amen" !
Two things that disturb me in ASL are:
1) it's very un-understandable why/how some gadgets are or are not present on the dialog (for example the filter field and the gadget to its right) even for me Amigan since 1988. I think it's generally ergonomically unwise to add and/or remove gadgets, it tends to perturb users, I find it better to deactivate them when they are not usable (but for this specific case I don't see why the user would not be able to use a filter !?)
2) I like the new ASL, it adds interesting things, abstracting the fact there are some graphical glitches in the public version, there is however one thing I miss from the old version: the old one wasn't waiting for the whole directory to be parsed to start displaying things and/or react to user input (click on OK/Save for example) . It was a very pleasant feature of the old version that I would like to see again. I understand the 'inline displaying' might be a bit more tricky with the sortable columns, but the other one is easy to fix : just check intuition messages while reading directory and in case the user clicked OK (or cancel) then just exit even if the whole directory isn't fully loaded.
Hmm ?? You are deeming this as a "modern feature" ??? Amiga never used file extension, on amiga file extensions are part of the filename and are only human understandable indaiction of what the file is but the system never used that to identify a file format (come on we are not on a certain Micr****t OS here IMHO a programmer should never only rely file extension in his programs.
Well, that is not so important as first suggestion (dropdown menu with file name format choice). Because when you press save in any editor, which mean saving in different formats, then you still need to choice file format in any case.
I must admit I'm with Abalaban on this one. AmigaOS has never required the file extension to be able to ascertain what type of file is being handled, it is purely cosmetic. The addition of such a prompt can be added in the application if it is required, rather than inflicting all applications with the same.
@Abalaban
As for removing gadgets in the requester, I personally see this as the correct approach. If the requester is in DrawersOnly mode, why would the user need the filter and the filename gadgets, even if they are disabled? This only leads to confusion. Removing them completely offers a much cleaner interface and elimiates any possible confusion resulting from clutter.
The problem with trying to "thread" the requester to make the listing asynchronous is going to be inherently problematic due to the amount of compatibility baggage contained within the ASL requester framework. There were lots of hoops jumped through to make sure that the new version works in the same way as the old one, with all it's quirks and tag handling. By trying to expand it further may well break a lot of applications, and that is something we don't want.
Sure, we could create a requester that works more like "Windows", where thumbnails can be generated, and it becomes more like a small file utility, but just how much time would be invested in ensuring that it still works like the old ASL is going to be something that needs to be determined as to whether there is any value for the time spent testing it.
There are many other higher priority issues to be dealt with, and as the current ASL is a massive improvement over the old one, while retaining it's quirks and functionality, and it works, I can't see anyone dedicating bags of time for little gain.
If someone wants to tackle the task, and really wants to rewrite the requester sets to make them into something more "glorious", perhaps we might be able to work something out with regards to source-code access...
You misunderstood me I'm really not for going the Windows way. For me a file selector is just that: a file selector, not a file manager (too much possibility to mess your filesystem accidentally "oops I moved that (critical) file away").
However I never suggested threading the file scanning either : surely you (not specifically you Rigo, but the AOS4 developers as a whole) are using ExamineDir() in a loop to scan the directory I was suggesting to check for button clicks in this loop to be able to exit it so you can process the user input. Take this user case: I'm downloading all my archives in a single 'Downloads' directory. This directory contains tons of files and is long to display in ASL. Now when I want to download something from OWB, I must wait until the directory scanning is complete even if I know the path and the file name are good and only need to click 'Save'.
I agree with you that drawer selector might not have the same layout as a file selector. But I was speaking about file selector only for which sometime those gadgets appears, sometime not.
Well, I mostly agree with your sentiments, but I'm personally not too interested in going in and changing ASL. The code of full of traps and workarounds, and it's far too easy to break something by being too heavy-handed.
I'll leave it up to the current maintainer of ASL (who also performed the rework) to make a decision based on your points raised. He knows the code much better than anyone else, and he would be in a much better position to decide whether the changes you suggest are viable. I'm sure he'll see this thread eventually....
I must admit I'm with Abalaban on this one. AmigaOS has never required the file extension to be able to ascertain what type of file is being handled, it is purely cosmetic. The addition of such a prompt can be added in the application if it is required, rather than inflicting all applications with the same.
It can be not default, just as option for coder , like some ASL hook, to add dropdown menu with file formats. I.e. all who want can use it, other ones can not use it at all and ASL will be just the same as before.
For example right now i want to add to LodePaint "save as" with ASL. But i can save in many different formats. So, i need spawn one more window , with filename formats for choice, and only after - ASL. Looks a bit long and annoy imho. If ASL will have possibility to add one more gadget, where user can choice in which format do saving - it will looks imho much friendly. Maybe not classic amiga way, but better anyway (imho).
In short, OS4 is not about the past, but about the future. Once the software library is big enough I'm hoping the "compatibility" is simply disabled and we can really get on with moving forward.
So true. I want the OS to move forward even more that it did already.
@Elwood I second that... I hope fromnow on we see full focus on moving AOS forward. Personally I hardly ever use neither UAE or petunia for that matter as most if not all of my day to day use is with PPC applications.
I think most backwards compatibility could be handled via an improved version of UAE.
Quite a few things, actually. The smallest one being that the implicit name of a new drawer does not get highlighted when creating drawers from the requester. You'll want to put a new name anyway so why force the user to make the extra step of selecting the name manually? (We've already discussed it here, I was told someone's on it, but the behaviour is still the same in Update 2.)
But my bigger complaint is the fact that the requester has menus.
"What? The menu has been there for years!"
Yes I know but from the viewpoint of user interface design, it's wrong because requesters are not supposed to have menus. Requesters are not windows, and associating a menu with a requester is not in line with the requester metaphor. On non-Amiga(-ish) operating systems, do they have requesters with menus? No, simply because a normal user wouldn't expect a filerequester to have a menu providing extended functionality.
To prove my point, I asked two non-Amigans (a regular computer-literate person, and a guy who actually designs user interfaces for custom-made software solutions) to use the NotePad and save a piece of text, putting it in a new drawer created from the requester.
Both failed at that. They didn't find the Create Drawer function. They (quite rightly) expected to find it in the requester, and it wasn't there. None of them even TRIED to look for a menu, and when I told them, there was much surprise and frowning. You can try a similar experiment yourself but I am sure you see my point.
The fact that seasoned Amiga users know about all that can hardly be an excuse for a bad concept. If OS4 is to attract curious users who have never used an Amiga before, we should get rid of things that are confusing and discouraging. As far as filerequesters are concerned, they should provide full functionality directly, using gadgets. MorphOS developers have already made a step in the right direction.
There is a strong argument in favour of putting the Volume/Assign list next to the folder contents list, rather than requiring a special button to be pressed to see it. For a start it is more intuitive & faster to use. It has already been done on MOS & I think some 3rd-party OS3 hacks, and it's really nice.
@kas1e Quote:
For example right now i want to add to LodePaint "save as" with ASL. But i can save in many different formats.
IMHO it would be better if you could embed an "ASL Requester" as a BOOPSI/ClassAct object inside an Intuition window, then you can add whatever gadgets you like...
IMHO it would be better if you could embed an "ASL Requester" as a BOOPSI/ClassAct object inside an Intuition window, then you can add whatever gadgets you like...
Sorry, not so good understand what you mean. Did you mean i need write my own "asl like" requester ? Or i can somehow modify current one and add what i need already, with current ASL ?
@kas1e I meant it would be nice *if* you could ask OS4 to put functioning ASL Requester inside your own window. This is not possible yet (as far as I know), but it might be easier for OS4 devs than allowing custom buttons in the ASL Requester window.
For example right now i want to add to LodePaint "save as" with ASL. But i can save in many different formats. So, i need spawn one more window , with filename formats for choice, and only after - ASL. Looks a bit long and annoy imho.
This is definitely something that calls for improvement - the ASL save requester should allow selecting a file format. It's useful for not just paint programs but also word processors etc.
IMO an elegant programming solution would be introducing a tag named, say, ASLFR_Formats taking a pointer to a struct List. The structure would contain a list of text labels naming the individual file formats you want the user the choose from. If ASL finds a non-NULL value in the ASLFR_Formats tag (and ASLFR_DoSaveMode is TRUE), the requester will display a chooser gadget with the formats.
The question is how to retrieve the format the user has selected. File- and drawer names are read from struct FileRequester, and I don't think extending the structure would be a good solution. Frankly, this whole thing of reading data from system structures should be ditched. ASL requesters should behave like objects, and data should be retrieved through methods.
but it might be easier for OS4 devs than allowing custom buttons in the ASL Requester window.
Let's it be not buttons, but dropdown menu (just like cicled gadget button).
In others - all what Trixie say, that exactly about i talk.
@Trixie Yes, i talk about the same. Imho, asl can "return" just choicen file format, and coder works with it. It's just can return string data like ".xyz", and coder just parse that return.
But, if Rigo say that is not amigaos way, then something make me think, that we will never improve ASL for more easy usage, and all our wordpocessors, image editors, and maybe future video-converting toolz and alt will still use the same ulgy old-way :) (that all imho of course).
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
