"Have you asked Hyperion already what they think ?"
No comment ;) In any case, that's something that should be done after the work group has defined some of the overall parameters. Not before.
And if it's not possible to even create a work group of dedicated people then there's no point in contacting Hyperion in the first place.
"Do you have a volunteer already who could write that license ?"
Nope, but again that's something for the work group to get into. Depending on how to go about licensing there could be lots of work to do or not so much work to do.
"I want one clarification ? That thread title is 'Workbench enhancement' but people are talking enhancing the whole OS. So is it WB only or the whole OS you want to enhance ?"
My idea began as a small seed that grew into something bigger ;) An Open Amiga project would deal with any type of os4 enhancement issue, not just the WB. If accepted by the work group the first post would result in one or a few projects under the Open Amiga umbrella so to speak.
"But if you want such code to integrated into the OS4 you will need help from OS4 devs themselves. You might need access to the source code of some OS4 libraries. It's different if everything we have in mind is possible to implement as plugins f.ex. And orgin's idea is only to make a license to let Hyperion to include those plugins in the OS installer. But everything is not possible to implement that way."
It's too early to say what kind of projects Open Amiga would be able to handle, it depends on Hyperions' reactions. I doubt it would get access to source code. OS4 developers acting in an advisory role is more likely though. Even if we get limited support there's still lots of things that could be done, not just plugins (tools, utilities, research into advanced topic etc). The relationship with Hyperion might start out small and if Open Amiga would become a useful resource then it could grow, it's all to early to say.
First line of business would be to form a work group of dedicated people and then move on from there.
I'll just repeat that I am too busy at this point in time to join such an effort, but I do like the idea.
@joerg
Quote:
joerg wrote: @TSK
Quote:
@thread Quote:
multiuser
Are there any news of that rumoured new filesystem for OS4 ? Or was it completely false rumour ?
There is nothing multiuser related a file system can change, FFS2 and SFS support UID, GID and the group/other protection bits as well, there is just nothing in AmigaOS which uses them. You can set the owner and group/other protection bits with the commands in C: and display them with "C:List groups", but they are ignored. ixemul.library uses them, FTP and HTTP servers should as well, but AmigaOS itself doesn't.
So what's missing is enforcement of the permissions at the OS level (shouldn't the filesystem be involved in this too?), and multi-user support in the sense of having the option to log in, and per-user environments.
Per-user environments would probably be pretty easy to do; enforcing access restrictions would require API level changes.
I feel a little bit embarrassed. We don't need a new FS because SFS has everything. It's fast, journaling and multiuser. How big task it would be to add multiuser into the OS ? (I'm curious only.) Not too big or very big ?
Rock lobster bit me - so I'm here forever X1000 + AmigaOS 4.1 FE "Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
I feel a little bit embarrassed. We don't need a new FS because SFS has everything. It's fast, journaling and multiuser. How big task it would be to add multiuser into the OS ? (I'm curious only.) Not too big or very big ?
It depends on your definition of "multiuser".
You could of course make e.g the DOS Open call respect ownership. It would be some effort, but not undoable.
You will still have issues. For example, people could use packet-level I/O to access the file system. That would need to be changed. Also, since there is no memory protection, it would be relatively easy to kill this method and gain access.
A few things are under consideration, for example, the possibility to enable a "Login" window and load settings based on the user, as well as provide something like a "Home" directory. ]
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
abalaban : I don't agree myself with each point of the list :) I summarized it from information of the thread you mentionned.
ShInKurO : It is not about reinventing the wheel but about highlighting priorities concerning the Workbench and the system.
Hans : I have to send you few comments about datatypes. I agree with Rogue, a complete rework must be done. They are very difficult to program with different behaviours depending on versions and OS branches.
Rogue : Thanks for giving us some clues :)
Some of the listed features are maybe under development but we (external developers) don't know. What would be cool and efficient : the OS team could tell what they won't do (so developers can start the work) and what they need help for. Maybe things are needed by users but does not have to be developed and managed by the OS team.
Great to see that someone works on the shell, as I told in the french thread : withtout KingCON, I would develop nothing on OS4 ...
You could of course make e.g the DOS Open call respect ownership. It would be some effort, but not undoable.
Only little changes are required, but in lot's of places in dos.library, and small exec changes (not only dos processes but exec tasks need an owner, exec task can't do much I/O, but they can create dos processes which have to have the same owner as their parent task). It was done alreay on AmigaOS in multiuser, by patching some exec and lots of dos functions.
Quote:
You will still have issues. For example, people could use packet-level I/O to access the file system. That would need to be changed.
It's no problem to block all packet-level I/O in a file system if they are done using exec/PutMsg() instead of dos/DoPkt() or dos/SendPkt(), and the dos.library packet functions just have to check the permissions like all other dos functions.
Quote:
Also, since there is no memory protection, it would be relatively easy to kill this method and gain access.
Of course, just like with the old multiuser/MuFS where all you had to do was to change the boot block file system ID back to the FFS one to get full access to all files on a "protected" MuFS partition. It wont be a secure system, but it's enough for supporting multiple users/logins where one user can't access or even delete the files of the other users by accident.
corto wrote: Hans : I have to send you few comments about datatypes. I agree with Rogue, a complete rework must be done. They are very difficult to program with different behaviours depending on versions and OS branches.
I'll be interested to hear your ideas on doing this without killing backward compatibility. My approach so far with the animation datatype has been to deprecate all the old stuff, but I'd like a good method to recognize when the new API is available.
Maybe you could PM me once you're done to check if I received it, and/or use the contact details on my website (see the sig. below).
So what's missing is enforcement of the permissions at the OS level (shouldn't the filesystem be involved in this too?), and multi-user support in the sense of having the option to log in, and per-user environments.
The file systems must not be involved, they have to do way too much already which should be in dos.library instead of having to duplicate it in each file system, for example notifications had to supported by the file systems themself. At least half of the code of most AmigaOS file systems has nothing to do with the file system but are just support functions which are the same in all file systems and should be in dos.library instead.
Quote:
Per-user environments would probably be pretty easy to do; enforcing access restrictions would require API level changes.
No API changes are required, except for one new function to change the owner of a task/process (of course only if the current owner is the superuser), and maybe some other settings like an umask.
Per-user environments would probably be pretty easy to do; enforcing access restrictions would require API level changes.
Make ENVARC: a multi-assign which points to ENVARC:<user> and ENVARC: (and searches in that order).
A login prompt to select <user> and you're done.
Without locking the FS down you're implementing Windows 95 security (ie. none).
@corto
Quote:
Hans : I have to send you few comments about datatypes. I agree with Rogue, a complete rework must be done. They are very difficult to program with different behaviours depending on versions and OS branches.
I don't think they're quite that bad (I've not seen those compatiblity issues), but they do need a lot of work! If you write one, there's a truck-load of duplicate code, but once you've got the template (use one of Frederik's ;)) you only need to write one or two functions for picture datatypes. animation datatypes are a bit of a nightmare, as well as not supporting truecolour you seem to have to do a lot of extra work which I'm sure animation.datatype could handle (like caching previous frames). Sound datatypes I've never tried writing, but they need 16-bit support and the streaming ability is suspect (the datatype itself plays the file, you can't get the data out - which is the whole point of a datatype, surely?). Text datatypes look way to limited, only seemingly supporting plain text. They need to be based on something better than FTXT, although you could argue this is what the document data type is for - but as there isn't a standard way of getting data of these, you're stuck with only viewing these files.
There are a buch of superclasses that would be useful too (structured 2D drawings, 3D models to name two).
Anyway, there's an existing thread on Amigans about this stuff, and a couple over at UtilityBase too.
@hans Quote:
My approach so far with the animation datatype has been to deprecate all the old stuff, but I'd like a good method to recognize when the new API is available.
There's an existing method v44 animation.datatype uses to decide on whether to use the new format frame loading method or the old one... it's in the AutoDocs:
Quote:
If your subclass needs to use the extended adtNewFormatFrame format messages, it must say so by providing a list of supported methods for animation.datatype to query through the OM_GET/DTA_Methods tag. If both ADTM_LOADNEWFORMATFRAME and ADTM_UNLOADNEWFORMATFRAME are among the methods supported by your subclass, you will receive adtNewFormatFrame format messages instead of the compatible adtFrame messages.
So, it might be a good idea to do it that way, as you'll probably need to support it anyway for backwards-compatiblity - and it looks sensible.
Well your wrong there you have full access to DOS.library 64bit commands.
AFAIK the last public SDK only included the 4 (Get|Change)File(Postition|Size)() functions but not the new directory scanning functions yet and ExAll() can't return file sizes > 4 GB - 2 bytes, without a new SDK you have to Open() a file and use GetFileSize() to get the real size.
Quote:
but we do not have working clib and newlib functions for 64bit reading and writing.
so you can write your own software thats easy, but its hard to port Linux programs that does require 64bit newlib or clib functions.
Ctorrent for exsample
Changing such software to use the 64 bit C library functions wont be much easier than changing it to use the 64 bit dos.library functions, which you can do already with the last public SDK.
That looks much easier than I thought it would be.
@Chris
Quote:
Chris wrote:
animation datatypes are a bit of a nightmare, as well as not supporting truecolour you seem to have to do a lot of extra work which I'm sure animation.datatype could handle (like caching previous frames).
If this caching is for decoding purposes (e.g., the format requires the previous frame), then the child-datatype should handle that. If you mean the annoying caching due to the loadframe/unloadframe API, then I agree, it places a lot of unnecessary load on the child-datatype. Likewise I don't like all the wide-range of attributes that were meant for things such as colour remapping, etc.; these are confusing and meaningless too, now that everyone uses truecolour screens. Another item that needs to be changed is the way that child datatypes have to know what kind of data source (e.g., memory, file, etc.) it is reading data from.
Quote:
@hans Quote:
My approach so far with the animation datatype has been to deprecate all the old stuff, but I'd like a good method to recognize when the new API is available.
There's an existing method v44 animation.datatype uses to decide on whether to use the new format frame loading method or the old one... it's in the AutoDocs:
... snip ...
So, it might be a good idea to do it that way, as you'll probably need to support it anyway for backwards-compatiblity - and it looks sensible.
I'm thinking about a way for applications to detect the new base-class APIs. What I'm really hoping for is something simple (i.e., a single line of code). My code can already recognize old animation datatypes.
Changing such software to use the 64 bit C library functions wont be much easier than changing it to use the 64 bit dos.library functions, which you can do already with the last public SDK.
You forget Linux programs already uses the clib / newlib functions. What is mostly required is to get programs that?s already uses fopen() fclose(), fprintf() to work whit dos.library 64 bit commands, but this commands seams incompatible. fopen returns a int or FILE, but Open() in dos returns BPTR, if you have idea or example on how you can mix commands then please, write some examples, or else large quantizes of code needs to be rewritten to only use 64bit commands in dos.library. Quote:
ExAll() can't return file sizes > 4 GB - 2 bytes
ExAll() that supports more then 4GB is only useful when your scanning directories, I think most developers can live whit out this ExAll(), you even have work around for it, open the file and check.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
If I am honest, I am not a big fan of any existing AmigaOS GUI toolkit...>
What do you think about Feelin? If we want a rock OOP framework, in the actual Amiga conditions (few users) the olny way to have a good framework always supported is into opensource in which any user can fix a problem and add more feature. MUI has an its history with ages of testing and this make it and its MUI build-in classes very stable and coherent and with many features, ClassAct/Reaction hasn't the same history of developed program with it, and so Reaction classes are not enough mature as MUI's ones. You can see all this by third part programs produced from first OS4 prerelease to now (wookiechat, epistula, ecc...). Reaction classes are too few, too young, with few features to work on a serious project without lost much time. These "third parts" points of view are very important and should be considered. To overcome this "history" problem we can use an opensource framework which gains faster this "history". Sure, we can make Reaction opensource, but I believe that you have some licence problems with this issue...in addition to this many Reaction aspects are obsolete, and MUI better follows OOP paradigm.
And sure, if you want mantain compatibility issue on OS4 and don't use a new thing like Feelin is, there is always Zune to port on OS4, modifing it to better follow OS4 chooses... You can mantain in this way API signatures friendly to "old" programmers...
The same issue we should make with a modern workbench replacement, you should see how Ambient is evolved from its first opensource version from now. A fight between MOS team and Ambient author has given a good fruit for all mos users.... I believe that a new Workbench should be open source (obviously I don't think about GPL, but one of licences used by Apple/Sun/whatever), it should follow the same road taken by Ambient...
It wont be a secure system, but it's enough for supporting multiple users/logins where one user can't access or even delete the files of the other users by accident.
I don't want to speak for other, but when I listed this feature that's exactly what I had in mind : only a way to enable multiple customized environments and protect files from accidental deletion. That's all, since you are mentionning MuFS that's exactly what I had in mind, back when I was still under OS 3.0 I managed to build such system with MuFS : with help of some multiassigns for ENVARC: for instance that enabled me to have some sort of "inheritance" of a default env but with possiblity to customize it for anyone. However I agree that this won't be secure because it would be easily defeatable by some clever experienced user, but I think this is not really a matter until the OS become used in public places : you are trusting your family members, don't you ? That's just a matter of preventing accidents.
PS: to be complete here is the sourceforge page of MultiuserFileSystem
I can tell you what gripes I have with most AmigaOS user interfaces.
For one thing, they all promote resizability. That is a good thing, of course, but there are limits. I don't understand for example why buttons must resize the same way as e.g. a listview does. When I resize a window with a listview in it, I first and foremost would expect to get a bigger listview, but most of the time,you get proportionally larger buttons as well, which does not make sense IMO. Sure, you can go ahead and distribute weights, but the point is I should not have to do that in the first place.
Secondly, since MUI invented them, this macro-chain-orgies of generating an UI seems to be the preferred choice, and I cannot understand why. It's a clumsy method that is very prone to errors that are very difficult to detect since the compiler will bitch about the whole statement only, not about the real offending line.
Third, the type of functionality the toolkits offer are far behind what other platforms offer. Just look at e.g. Eclipse's SWT, the way you can reorganize tabs, dock toolbars where you want to, etc. Granted, MUI offers similar toolbars, but for the most part, they are either awkward to use or require special programming.
The possibilities that e.g. SWING has for listviews alone makes any AmigaOS toolkit pale in comparison. Not only the way it can display things (SWING can e..g use HTML to format the entries in a listview) but also the way they are programmed (subclassing the item type to get specialized display of items in a list). All of this is way too much effort under AmigaOS to justify it.
This is not even mentioning the absence of a usable GUI designer (and I don't mean a glorified text editor like Reactor was).
I am not saying the grass is always greener on the other side. Windows shows a lot of potential to allow programmers to totally screw up a user interface. But looking at things like SWT and SWING, I know what I would like to future AmigaOS GUI toolkits to look like.
I also do not like the individual over-customizability of MUI. Being able to change some aspects of a GUI like fonts and maybe highlight colors are fine, but other than that, I've seen programs that look perfectly fine on one GUI configuration look totally botched on another one. Themes are the way to go there, since they add predictability that we do not have right now.
No idea about Ambient. I've seen MorphOS maybe two or three times in action (version 1.4.2 IIRC) and wasn't exactly thrilled by Ambient, but that was a long time ago and if I understand it correctly, it seems to have evolved in the meantime.
I also don't think that Open Source is a must for anything GUI-related. Especially with something like GUI's, I see a lot of potential for forks that would result in a myriad of incompatible versions. GUI's touch a very important aspect of human-machine interaction, namely the usability. Plainly, usability is something that is very difficult to achieve, and IMO people with knowledge in that field should be concerned with that. In that respect, the GUI should try to enforce some guidelines for programmers to follow.
The frequently quoted argument for open source is that the user can fix issues himself, but in reality, that rarely ever happens.Especially on the Amiga market. That does not mean I oppose open source, quite the contrary,
Uh, er.. sorry for the long post
(edit: fixed typo)
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Hans wrote: If this caching is for decoding purposes (e.g., the format requires the previous frame), then the child-datatype should handle that. If you mean the annoying caching due to the loadframe/unloadframe API, then I agree, it places a lot of unnecessary load on the child-datatype.
Both, really. The majority of animation formats require the previous frame in order to create the next one (and often many frames before that if you are skipping). animation.datatype should be able to keep hold of the previous frame (and maybe the previous key frame) and allow the child datatype to make a copy of it (or, even better, provide a copy).
It makes no sense for every child datatype to have to remember previous frames, when (a) this is something that needs to be implemented in 99% of all anim/video formats and (b) animation.datatype caches something like 10 frames anyway. It's a lot of unnecessary work if that's the only thing you want to cache.
Quote:
Likewise I don't like all the wide-range of attributes that were meant for things such as colour remapping, etc.; these are confusing and meaningless too, now that everyone uses truecolour screens.
I would disagree with this. Sometimes palette-mapped screens are beneficial (especially if you're writing an emulator, granted you're probably not involving datatypes on the same screen), and sometimes it can be useful to remap a picture to a particular palette.
Quote:
Another item that needs to be changed is the way that child datatypes have to know what kind of data source (e.g., memory, file, etc.) it is reading data from.
Never understood this - the child datatype doesn't need to know, as DTST_MEMORY emulates a file somehow.
Quote:
I'm thinking about a way for applications to detect the new base-class APIs. What I'm really hoping for is something simple (i.e., a single line of code). My code can already recognize old animation datatypes.
The easy way is to bump the version number, but that's thwart with danger. Perhaps add a method that can be called, and returns a list of valid methods (inverse of what my quote said). If the method fails, it's the old API, if it doesn't you have a way of extending the API in the future.
Chris wrote: It makes no sense for every child datatype to have to remember previous frames, when (a) this is something that needs to be implemented in 99% of all anim/video formats and (b) animation.datatype caches something like 10 frames anyway. It's a lot of unnecessary work if that's the only thing you want to cache.
I think that the animation datatype root class should take care of allocating and deallocating frames, but maintaining pointers to the previous frame (and maybe even more for bidirectionally coded frames) really is the child-datatype's job.
why buttons must resize the same way as e.g. a listview does. When I resize a window with a listview in it, I first and foremost would expect to get a bigger listview, but most of the time,you get proportionally larger buttons as well, which does not make sense IMO.
That's bad programming!
If developers wrote it like this then only list view part is resized, (I'm using macros in this example.)
Secondly, since MUI invented them, this macro-chain-orgies of generating an UI seems to be the preferred choice, and I cannot understand why. It's a clumsy method that is very prone to errors that are very difficult to detect since the compiler will bitch about the whole statement only, not about the real offending line.
Yes thats where annoying better if the GUI was some kind of XML format, so GUI was loaded when needed.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
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
