~Yes I am a Kiwi, No, I did not appear as an extra in 'Lord of the Rings'~ 1x AmigaOne X5000 2.0GHz 2gM RadeonR9280X AOS4.x 3x AmigaOne X1000 1.8GHz 2gM RadeonHD7970 AOS4.x
Yep, pretty interesting. But from my point of view (just an imho), better to integrate current version of Filer to os (because Filer for example have already thumb priview). Maybe not the fastest priviews (for example on mos/ambient thumbs generated faster in 2-3 times in compare with filer routines), but that area can be reworked by core-team and alt.
Well Filer is surely interesting but IMHO it's not ready (yet) for an "integration" as it needs some reworked stylish and common usability, for example thumbnails activation and so on, some options may be hidden (or showed in main GUI) while others may be reorganized as well
A GUI isn't that easy to implement, isn't just "features" but most work are about the user's usability
Better have a corrupted filesystem in 45 seconds then corrupted after some hours :)
scary thought..but thinking about it..that's actually a good point ! man we really need stable USB2.0 bad...I was 100% fine with Update 1 but Update 2 messed up a few of my old USB sticks real good...lucky I had the info backed up
It's a commercial project and they want to make a competitive product, NDAs as well. This is normal for the wider computer imdustry.
Another example is the X1000 mystery CPU. A-Eon have explained they have had to keep the CPU under wraps until the X1000 hits the shelves because the manufacturer, understandably, wants to minimise the possibility of it's product being associated with someone elses failed product.
AROS is open source and even AROS developers seem pretty quiet most of the time on what's coming next, talking about big or nice things in store over the coming months but rarely discussing specifics.
Just nit picking, when you install KingCon, you dismount the default con handler and install a new one in L: that gives you scrolling history. So, the new shell will be a new con-handler.kmod in Kickstart, but the common term is still "shell".
Look, only one leg, count em, one! X1000/PA6T@1800MHz/2Gb/Radeon 4850
I'm glad you guys took a look to my report... yep, it was me who noticed those new options in some of the preference programs of AmigaOS4.1 beta (update 3?)... I'm quite happy that I'll be able to get rid of that awful gray background color and turn it to black among other things...
It's a bit more than just nit-picking. It's the Shell that prompts for and executes your typed commands. The Shell hasn't changed in the new regime, so the commands that you are used to are unchanged.
The con-handler steers the Shell's I/O to the console.device which draws output in a window and reads input from the keyboard. The con-handler used to open the window and pass it to the console.device, but now the console.device does it. The con-handler still handles name-completion, command history, etc, but has been changed considerably.
The console.device opens the display, reads the keyboard, handles the display history, multiple consoles in the one window (tabs), the menu, etc. It has been restructured and largely rewritten.
@tonyw I don't think most people care about the implementation details, nor would even know what a CON handler was. It makes sense to call it a new Shell, since that's the end-result that matters to people (and the Shell is what people recognise it as).
I AM interested in the details Not that i understand fully what exactly has been done, still it is a nice interseting read...heck, if i'd had the possibility i'd play mouse and sniff around the OS4 bug/feature/patch trackers, just to get a glimpse of what is being worked on...what the drawbacks and problems are and what solutions the devs come up with
Really...it's awesome to follow the path of some bugs or features
It's the Shell that prompts for and executes your typed commands. The Shell hasn't changed in the new regime, so the commands that you are used to are unchanged.
The con-handler steers the Shell's I/O to the console.device which draws output in a window and reads input from the keyboard. The con-handler used to open the window and pass it to the console.device, but now the console.device does it. The con-handler still handles name-completion, command history, etc, but has been changed considerably.
The console.device opens the display, reads the keyboard, handles the display history, multiple consoles in the one window (tabs), the menu, etc. It has been restructured and largely rewritten.