If I am honest, I am not a big fan of any existing AmigaOS GUI toolkit...
Charsets, fonts : UTF-8 support
What really would be needed is support for UTF-8 and Unicode in graphics.library. Charsets are supported already.
GrimReaper : useable GDB that does not freeze the system one time of two when attaching a crashed process
GDB would need a completely new port, also to support the shared object files. Unfortunately, a crashed program is exactly that, a crashed program, and by its very nature, crashed programs make the system unstable until such time as there is proper memory protection.
fix refresh problem in WB scrollbars
What refresh problem? In any case, this would be a minor bug, not a feature to write home about
Clock, PlayCD, Blanker modules : there are a bit outdated, aren't they ?
Clock... well.. I don't exactly know what additional functionality you expect from a clock except for telling you what time it is
PlayCD.. well.. it plays CD's, doesn't it?
Blankers.. Yeah... some new ones wouldn't be bad, but that is certainly low priority
Input : Handling of multimedia keys, joypads
Multimedia keys are supported through the extended IDCMP. Joypads are a matter of AmigaInput, and they are supposed as far as they can be supported.
Workbench: A lister mode
If that refers to the text view, you will find this has improved in the meantime. It is a bit general too, since it might mean everything from just displaying filenames to God-knows-what.
Shell : improvements a la KingCON, addition of tabs, log for each console, settings (background color, ...)
In the works.
NVidia GFX-card support
Not very likely to happen. Considering that ATI has at least as good an offering as NVidia has, I do not really see the point either. ATI/AMD opened up their specs so it is possible to support those. No need to run after NVidia, they don't want to.
better profit of gfx-cards (tv and dvi -out, compositing, overlay, opengl etc)
DVI is supported IIRC, as is overlay... OpenGL is under construction.
Bluetooth stack (file transfer, etc.)
Agreed. Very useful.
TV Tuner card support
That's not an OS function in my book, at least none that could not be filled by a third-party program.
Firewire : for storage
Questionable. USB 2.0 would be much more usefil, firewire is rarely used.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Why is that so? I don't get this. Most of what is exposed as functionality in AmigaOS 4.0 is already available via the original released SDK. There are a few tidbits missing, but nothing critical. I don't get it, really.
A new SDK is in the make, but it takes time, as usual. We haven't dedicated much effort to it lately because there were other, more pressing issues.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Why is that so? I don't get this. Most of what is exposed as functionality in AmigaOS 4.0 is already available via the original released SDK. There are a few tidbits missing, but nothing critical. I don't get it, really.
A new SDK is in the make, but it takes time, as usual. We haven't dedicated much effort to it lately because there were other, more pressing issues.
If i remember correctly the Author of that tv-card driver needs AllocVecTags() for DMA-Buffers, it is not in current SDK. The full set of 64bit DOS functions would be nice too.
The sooner developpers get access to ne APIs the better it is. I don't beg for a complete new SDK at first a simple update of the includes would be enough. For example some old way of doing things might now have been deprecated for new ones (StackSwap comes to mind for example)
Anyway your previous post contained some good news
- AISS yes I agree totally, it must be integrated in the OS, but it would be good to have a way of caching in order to prevent applications spend ages to launch...
There is an image cache in intuition which is used by the ReAction classes. Unless you have TBImages: on an extremely slow file system like FAT or FFS even the time it takes to load the images for the first time shouldn't be noticeable.
(here I suppose you have added a system wide mime-type list as this would be rather stupid to have each application handling its own).
That's something that Datatypes could return as extended info, if ever system-wide MIME type support was needed.
Quote:
I agree, I just miss the possibility to use mouse wheel in amigaguides that's all.
AmigaGuide is something else that could do with being updated (search function, embedded images, something better than using line numbers when referencing links to certain parts of pages)
If i remember correctly the Author of that tv-card driver needs AllocVecTags() for DMA-Buffers, it is not in current SDK.
Yes, but how many people are writing TV-Card drivers?
Quote:
The full set of 64bit DOS functions would be nice too.
Granted, but those are not essential.
@abalaban
Quote:
The sooner developpers get access to ne APIs the better it is.
True, but still that doesn't make it anything essential.
Quote:
I don't beg for a complete new SDK at first a simple update of the includes would be enough.
That is about the same. For example, you need a new compiler for the SO support, so that needs to go in there. Same with the includes. The SO support right now is flakey too in so far that stripping a binary will break it, so new binutils are required.
You see now why there isn't an update yet.
@Chris Quote:
AmigaGuide is something else that could do with being updated (search function, embedded images, something better than using line numbers when referencing links to certain parts of pages)
Or ditched entirely. I would much prefer an HTML based solution, a bit like HTML pages from an archive of sorts (Like Microsoft's help files).
Why? Because I can save HTML files with about every office program around. AmigaGuide will always be a text editor only thing. It is far better to go for a tried and tested (and widely supported) format instead, especially if the capabilities for the format are far superior to AmigaGuide.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
I understand fully that packaging a full new SDK is time consuming, but I did not think that spreading the includes would require the whole shared object things and all... Too bad
@joerg
Quote:
- PartionWizard : better SFS support What's wrong with it?
I don't know I'm not using SFS and with FFS2 I never had to use PartitionWizard anyway (unless the first time I think in order to convert to long filenames IIRC)
Quote:
- AISS yes I agree totally, it must be integrated in the OS, but it would be good to have a way of caching in order to prevent applications spend ages to launch... There is an image cache in intuition which is used by the ReAction classes. Unless you have TBImages: on an extremely slow file system like FAT or FFS even the time it takes to load the images for the first time shouldn't be noticeable.
Is it supposed to be in the latest OS4Final for A1 ? If yes then I can assure you that it *is* noticeable, but I'm certain the problem comes from the apps not the system (for example CubicIDE has a lightning startup despite using AISS imagery, whereas other takes ages like pFTP for example).
pFTP starts here (A1G3) in less than 2 secs. For example AissAnimShow starts in an eye blink. (TBimages are in sys: which is FFS2. But those programs are on both SFS/FFS2 partitions.)
@orgin Quote:
with a license that would let Hyperion use the code in OS4
Did you start this thread alone or are you speaking for all OS4 devs ? Are OS4 devs willing to use an open source code in a closed source OS ? Who's going to write necessary license ? (I'm not going to write anything complicated myself especially in foreign language.) What if I want to use my code in any other projects too ? I don't want to get connected/involved to/in any court cases or any other problems ! Are there any future for OS4 anyway ?
Quote:
might some day be incorporated into os4 itself
You said it yourself "might some day be incorporated", you didn't say "will be incorporated immediately". At least people can use my software already. I didn't write it all so people can just ignore it. And if you want anything from me you can always try to ask in PM.
@thread Quote:
multiuser
Are there any news of that rumoured new filesystem for OS4 ? Or was it completely false rumour ?
Edited by TSK on 2008/7/2 2:34:32
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
Deselect all Vvolumes that should not be searched by default and save the settings (Amiga+S, or Pulldownmenu).
It is still very stupid because they should be disabled by default. As it is now whenever you add a new volume to the system you need to do this disable/save thing again.
If i remember correctly the Author of that tv-card driver needs AllocVecTags() for DMA-Buffers, it is not in current SDK. The full set of 64bit DOS functions would be nice too.
A fully up-to-date SDK is really nice to have, but what exactly stops you from starting a new project? Even if you currently cannot use the 64bit API of DOS, why not just use the existing functions, set everything up for 64bit file sizes (if that is really necessary), and at the time the updated SDK is released modify your code to use the new functions? So many people are constantly telling that they could start a project only with the latest unreleased SDK. Why? Ok, AllocVecTags() is a central function, no DMA capable driver is possible without it. But what else is absolutely impossible with the current SDK?
I've dropped this so it doesn't really matter. But I'll answer your questions anyway.
>Did you start this thread alone or are you speaking for all OS4 devs ?
It was a proposal to see if there was any devs interested in working in such an Open Amiga project.
>Are OS4 devs willing to use an open source code in a closed source OS ?
Yes. It all depends on the license. GPL wouldn't be of much use for something integrated into the OS for example. Open Source is not a synonym for GPL.
>Who's going to write necessary license ?
First fish for interest, then go figure out the details. The license issue is just one piece of the puzzle if something like this was going to work. You could double license with an already exiting license, you could write one or more license specifically for Open Amiga projects depending on what level of control you want Hyperion and others to have for a specific project. Though the less control you give to Hyperion the less likely that they would use it.
These are details that could have been worked out After people showed their interest and a work group was formed. You can't have everything worked out before even starting.
> What if I want to use my code in any other projects too?
I don't see why that wouldn't be possible?!?
> Are there any future for OS4 anyway ?
Does it matter? Either people do or they wait. I'm done waiting.
> You said it yourself "might some day be incorporated", you didn't say "will be incorporated immediately". At least people can use my software already.
Hyperion would have to decide when/if they want to use it, you on the other hand can use it directly. Open Amiga produces some nice function and releases in on OS4Depot or whatever, Hyperions likes it and adds it to OS4 in an update. It's not Hyperion exclusive, what would be the point of that.
> And if you want anything from me you can always try to ask in PM.
I'll restate it here : I think this is a great idea. maybe you should have been a bit more clear from the beginning on what you had in mind. This could be directed (like in showing the direction) by OS4 devs : for example "guys we would like to replace this" or "hey what about adding that to this ?", see it as some sort of applicated homework (like you had during your studies) :"you should use X", "you must avoid Y at all price", "if you wish you can research Z if it's suitable".
Quote:
> And if you want anything from me you can always try to ask in PM.
? copied something into the text by mistake ?
I think what TSK meant was that if someone missed a function in one of his programs, he's reachable by PM and might accept to code it.
EDIT: replaced "housework" by "homework", sorry for the mistake
I wrote up a draft work flow: (For the nitpickers: draft means draft and not something already cut in stone)
Gather initial interest (today)
Form a work group of at least 5 developers that are all interested in moving a project like this forward.
Create/find some kind of forum for the work group
Work group defines the overall goal
Work group discusses (but does not implement) initial issues like
- Infra structure: like source repositories, bounty systems, discussion forums - Licenses - Work flows and definitions - What projects to do, and which to not do. (defining What is an application, what is an OS function)
Work group contacts Hyperion, presenting the case and ask for their view
Work group discusses Hyperions' reaction and defines how to move on
Work group decides on infra structure
Work group implements the first license scheme(s)
Work group implements infrastructure
Work group defines project groups and initial projects
In parallel to this, projects can start and later move into the Open Amiga infrastructure
I'm definitely interested in this idea but I'm also quite busy with work right now (some of which needs to be finished within the first half of this month), hence I haven't had much time to put into any of my Amiga programming projects either.
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.
Now the post #56 sound better. Have you asked Hyperion already what they think ? Do you have a volunteer already who could write that license ?
@+all 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 ?
I don't see problem that people have to download and install third party commodities or installing them from a Contrib drawer on an OS CD. 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.
I don't want to make any promise but I might be able to help in this community open source project.
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
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
