You forget Linux programs already uses the clib / newlib functions.
The 32 bit functions and data types, not the newlib 64 bit ones.
Quote:
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.
That doesn't work, changing the standard functions (fopen(), fstat(), ftello(), fseeko(), ...) and data types (off_t, struct stat, ...) to 64 bit would break all existing static link libraries, shared objects and programs using shared objects. The statically linked executables are no problem since the old functions could stay in the interface and new 64 bit versions added at a different offset with the same name, but that doesn't work for executables using shared objects and for libraries, no matter if they are static or shared ones, which only have the names of the missing functions and would use the wrong (64 bit) functions with the old 32 bit data types (32 bit off_t, a way too small struct stat, ...).
Quote:
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.
You can't mix C library and dos.library I/O, but you have to change the code anyway and there is no big difference if you change it to use the 64 bit C library functions (fopen64(), fstat64(), ftello64(), fseeko64(), ...) and data types (_off64_t, struct stat64, ...) or the dos.library 64 bit functions (IDOS->FOpen(), IDOS->ExamineObject(), IDOS->GetFilePosition(), IDOS->ChangeFilePosition(), ...) and data types (int64, struct ExamineData, BPTR, ...).
>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.
I'm agree with you on this, on MUI I believe it's the price to pay for not having a dedicated button class separated from MUIC_Text. In certain cases this make UI adaptable to many situation, but in other context (even many simple ones) it's a plauge, I know ;)
>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.
eheh I hated macros on GUIs I written a guide to Amiga portable programming (soon it'll all translated in english, you can read part of it on http://shinkuro.amiga.it/guida/english) and I've avoided MUI macros because they give always problems when you port a source from an Amiga flavour to another one, so I agree
>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.
On MUI4 it's all simpler...
>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.
MUI4 list class is more simple and advanced than old MUI... btw I love swing, I love its way to give to user many layout managment...sure on MUI you can add with an hook new layout algoritms, but you must have good knowledge to write a layout algoritm, so... btw some expert programmers can write some subclasses which have many chooses on layout...from this point of view MUI can be enanced...
>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.
IMO MUI its the last historical GUI framework on Amiga which is yet considerable modern, sure it contains many old things, but it's born when there was Windows95 :) I believe that an APL version of MUI, like Zune is, it's an opportunity to not forget...
>But looking at things like SWT and SWING, I know what I >would like to future AmigaOS GUI toolkits to look like.
btw swing has many users and programmers that work on it in so many (strange or conventional) ways and thus each bug it's found and fixed, so it has a relative good "history" of develop which makes it stable. A totally new GUI framework on Amiga could not have this lucky...see Reaction... MUI behaviour it well documented, and there are many programs which uses it, I don't tell you to go to MUI, but for example to take Zune, to mantain a certain MUI compatibility (right to run old programs and thus to have a base of testing) and to make it more integrated to OS4 in its inner parts... It's even an advantage from an OEM MUI version, which is limited...
>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,
Uhm with this I'm not agree MUI it's "Magic" because gives to user the power to customize like he wants all GUI aspects. It can seems against the usability and coerence aspects, but it's not true. You can give to user a coherent GUI, but leave to him the choose to adapt a GUI of a program to his way to work, and so the concept of usability becomes around a person in particular, not olny for a category ("the user") in general. It's something of ingenious, which must not lost.
>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.
Me too, and I tried on myself for example with my NoWinED (http://shinkuro.altervista.org/software/nowined.htm) OS3 version which doesn't appears very well on OS4, but I've fixed that (OS4 version has another type of GUI aspects), so I believe that in certain cases is the developer to have to test his program with standard gui customization, to understand if some of his chooses are visible on many differnt situations... In addition to this, an user is not fool, he can fix his custom gui aspect for olny that program...
>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.
A wonderful evolution from 1.4.2 Even if I don't love its monolithic nature...
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 have just had a look at the avcodec lib (which has no proper documentation ), and it handles all memory allocation for frames internally. I want to make the new API in such a way that animation datatypes writers can use avcodec.library if they wish. That way they we won't have to write our own version of codecs every time a new one comes out.
What I hate in MUI is all classes are spread around the internet. Some of them are on people personal websites, some in sourceforge, some of OS4 ports might be on os4depot and they're everywhere. I've never understood why MUI classes can't be all in aminet. Epistula is good (bad) example. The author ported 68k version quickly and users have to install and mix some parts of both versions manually. If people love depency hell and that s**t I wish you a happy trip to the Linux community. I don't want that c**p to Amiga. I as a developer if I want to use Intuition v52 then I'm sure all people who have Intuition v52 installed they must have certain versions of Reaction/Boopsi classes too. So I know always what I can expect users to have and users don't need to do any extra work.
If we are going to do any open source work as community there must be one solid leader for this project. The leader will decide *alone* which code is going to the archive and what is not.
Amiga must stay unique and better than other OSes in those areas where it can be better. If we copy/imitate Linux and Winblows too much then there is no reason to keep using AmigaOS any longer. Of course ports of open source software is important because this community is already too small to do everything itself.
@Rogue Quote:
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
You are an OS4 developer yourself. Go and change default values of CHILD_WeightedWidth/Height. Make it Button objects will get always CHILD_WeightedHeight,0 by default and ListBrowser objects will always get CHILD_WeightedHeight,100 and CHILD_WeightedWidth,100.
Quote:
this macro-chain-orgies of generating an UI
It's possible to get use to it in time.
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
TSK wrote: What I hate in MUI is all classes are spread around the internet. Some of them are on people personal websites, some in sourceforge, some of OS4 ports might be on os4depot and they're everywhere. I've never understood why MUI classes can't be all in aminet.
Well this one of the reasons why AmiUpdate came about, to try and get things into one central place even though the actual files can be hosted anywhere.
Unfortunately, the maintainers of those MUI classes have not taken the system onboard, which is a shame. I started adding the MUI classes myself, but I soon got fed up with trawling the internet looking for new versions of stuff, as you can imagine.
Hm... I've looked at the postings in this topic and I'm surprised that so far every idea brought forward works within the limits of what AmigaOS currently can do. As in: let's improve upon what we have.
Improving upon what we have is what essentially went on during the last 6-7 years. What we have today grew out of the need to port the Amiga operating system to a new hardware platform, and fill in the areas where today's hardware can do things that the old Amiga platform hardware could do not, e.g. truecolour screen rendering, USB device support, etc. This was some major effort, and for my own part, I was happy to have been a part of it
However, I believe that there is only so far you can go if you keep looking at what the operating system components can do, and go about improving them. Parts such as the datatypes subsystem or the shell's GUI are, as always, in need of improving. But, at the end of the day, how much more useful is AmigaOS going to be if there's a shell with a tabbed GUI, a datatypes system that can process more kinds of data?
I'm not knocking gradual improvements. After all, this is what we have been busily doing for years, and this kind of work was badly necessary. It was also tough work, since there is probably nothing tougher than having to work within an existing framework, fixing and updating existing code.
What I'm missing is something else, and I hope to direct your attention to it. We need AmigaOS to be useful. If we look at the individual operating system components for ways to make it more useful, then we'll only succeed at making isolated changes that individually might have an impact that won't help as much as a different approach to looking for improvements.
An example: let's say we want to make it possible for several users to share the same Amiga without each user being able to access the other user's files. That's a plan which implies a purpose and has its own requirements: you need multiuser support in the operating system. Now, what can be done to make this useful, and get it to work? What would make it hard to implement this?
Compare this to the isolated requirement of implementing multi-user support in the operating system. What it is good for? What would make it hard to implement it? It's much harder to answer these questions since the isolated improvements lack context and a specific task the changes should enable.
I think it would be very useful to view improvements to AmigaOS in context rather than in isolated form. If we stick to the latter, then we'll have it much harder to make the operating system useful beyond what it can be used for today. What we have today is still very much useful for the kind of tasks AmigaOS used to do in 1994, and not much beyond that.
"What I hate in MUI is all classes are spread around the internet. Some of them are on people personal websites, some in sourceforge, some of OS4 ports might be on os4depot and they're everywhere. I've never understood why MUI classes can't be all in aminet. Epistula is good (bad) example."
It's not MUI fault if some programmers have a bad behaviour... Believe me, it's not necessary a degree to make some check code which show you what classes you don't have and where they are on net... And sure, there is always the documentation of a source to read for understanding how are mcc are necessary...
"If we are going to do any open source work as community there must be one solid leader for this project. The leader will decide *alone* which code is going to the archive and what is not."
I've dropped this idea. But I'll answer this anyway.
The idea was that the community organization would be an open source R&D department. (Research & Development). With no limits on what they do as long as it's something that would normally reside in an OS distribution, built for and targeting OS4. A linux port, like firefox, would not be a candidate for example. "Archive" is not a concept that could be used to describe it, since there would be no centralized distribution (like a CD or whatever). Just a bunch of individual tools, utilities, patches, guides, research papers etc under the umbrella of the Open Amiga organization. Both released individually for the community to download and use as well as from which Hyperion could pick and choose for the OS4 distribution.
I really agree with the Open Amiga project. What we need now is native software for our computer, which would be open sourced so that more people could use parts of the source and make something new or make a program better.
Also we need from our best programmers to be leaders, by leading projects that are necessary for others to continue their work. They could work on implementing necessary libraries and make things, like the GUI, better.
And also we need a small programming team to gather all the information which is spread over the internet and categorise it, so that all of the new developers could find a good place to look for anything they want.
I would like to participate in such a project. We could set up a new web site, with all these things gathered.
I see the points you made, but I have a very different view on the actual situation of AmigaOS and its "development crisis".
@all
First of all, developers and users are divided into many slightly different groups, each one preferring their "preferred system of doing things" for every price. There are people preferring MUI, there are people preferring open source software, there are people constantly comparing AmigaOS to un*x like systems, people who are in an enduring race after most modern methods without a real use for AmigaOS, people that want to use one very modern programming language for all tasks only and so on. I ask you: Why should AmigaOS development take all these preferences in account? Why isn?t chosen a practical solution that can be used to build upon and is developed further?
So, let?s have a look on what have been achieved so far. We had a transition to different platforms now and it was more or less successfull. There were some modifications to the OS that are urgently needed and many that doesn?t made a real sence, except for very few people that needed them, e.g. for porting things over from the Linux world. There is support for the two mayor GUI systems.
Still people are complaining, and I think this is because they miss a straight direction in all this.
For example, what was achieved in regard to native AmigaOS software, except (more or less successfull) bug fixing of isolated OS parts (GUI, several libraries etc.), with all this modifications done to AmigaOS?
I will tell you: Very few. Head development people are complaining instead, e.g. complaining about ReActor as a mere super-duper texteditor. But what is done against this? Well, nothing. Is there any help in building GUIs on the Amiga to avoid the "macro madness"? Does the "ease of porting" paradigm help on this? (this is not meant as a personal offend, btw., it is a simple example for one of the biggest problems we have: No straight line of future development, just "use all nifty things some Linux oder Java nerds are proud of, regardless if it fit to the OS philosophy or not")
No, it doesn?t. Developers still have to search for documentation all over the web, are waiting for updated SDKs, struggling with GUI element bugs all over the place (or in half hearted ports like SDL), so they?re loosing drive for development over time, which in turn is complained about by the users.
All that is done against this is talking about e.g. GUI systems used on POSIX OSses that are contrary to productivity but filled up with "features we have just because it can be done and it is canonic!" (exaggeration).
Some very good improvement ideas for AmigaOS are talked to death instead of being supported, e.g. trying to set up a more modern datatypes system that doesn?t break compatibility as far as it goes and doesn?t try to adopt the bloatware method of "we have enough CPU power and RAM, let?s waste it for some nerd toys!" and "XML is a must, you can edit preferences easily, using a simple text editor (but we will not tell you about the fact that most users don?t want to edit preferences as ASCII text and want to have a GUI driven prefs program instead, as they are not willing to learn a "simple" programming language in order to find the right TRUE or FALSE value within a bunch of ASCII files of some hundred KB size each)".
The problem is very simple and very basic: What we now have is FIAT (fix it again Tony!) since a long time and with several paradigm changes within this process. Today we have the use-POSIX-and-open-source-wherever-you-can paradigm as lead paradigm and that opened Pandora?s box. More and more construction sites are opened without any idea of to what these paths may lead in regard to AmigaOS and its philosophy.
All these construction sites try to deal with several and very different ideas how AmigaOS could be improved using open source solutions, but they lead to nothing than half-ready solutions and some more or less useful ports yet.
Astonishingly, most native and usefullest applications we have today are developed without using these "improvements".
So, we need Amiga instead of open source Fiat
IMHO, we should have a go on ONE paradigm only and that is "AmigaOS". We should work on the problems that evolved over the years, trying to get a clean, lean and comfortable system again, then we can proceed with really new ideas (this definetly not means simply trying to adopt some "funky" academic fashions/solutions from the Un*x world over and over).
This includes heavy work on the development tools we have so far respectively that we are missing, e.g. GUI builders, source level debuggers, new shared libraries/devices for some badly needed functions, documentation, bug fixing or rewriting of key components that are known to be buggy (some ReAction classes like the listview, or, as mentioned, the good ol? Workbench or even multi-user-capability on a simpler level) and many, many more we forgot about for nearly a decade now (e.g. non-academic programming examples showing good programming practices, not like some of the OS4 ReActions examples that in some cases contain serious errors and bad practices).
Let?s face it, it doesn?t count if we implement nerd features that are told to be a must-have nowadays. 99,999% of all PC users out there doesn?t care if e.g. the system supports XML preference files for each and every occasion (and I don?t know any real Amiga user caring about it!). They simply care about how good they can actually use a system and that is a field AmigaOS still is very modern (besides the lack of some key applications that are constantly discussed but never really worked on because it has to be a port and a port of these "very portable solutions" isn?t possible because AmigaOS is not Un*x!).
I don?t talk about such pure eye-candy features like "3D-Desktops" or "transparent windows", I talk about pure usability. Eyecandy is nice and attracts many users as long as it?s "new", but in the end the user only sees how easy or hard the work is using a computer system. A good example for this is Windows Vista. Most users don?t like it and try to get back to XP, if they can. Vista has lesser usability than XP despite the fact that it contains lots of nerd features and eye candy!
AmigaOS could be even more usable as it is right now, if we would concentrate on its very own strengths and a good developer support, so more Amiga-like applications will be released and more new ideas could be tried out again.
Hope this helps a bit, thank you for your patience.
olsen wrote: However, I believe that there is only so far you can go if you keep looking at what the operating system components can do, and go about improving them. Parts such as the datatypes subsystem or the shell's GUI are, as always, in need of improving. But, at the end of the day, how much more useful is AmigaOS going to be if there's a shell with a tabbed GUI, a datatypes system that can process more kinds of data?
Ok, I'll explain exactly what I want this for. Firstly, have a look at Quicklook on Mac OS X. I think that this quick preview of files system is incredibly useful; just click the quicklook button and then change the preview by clicking on files. The datatypes system could do this, it it were improved.
Given that datatypes are also BOOPSI gadgets, animation could be incorporated into GUIs instead of people having to "roll their own."
Most importantly, I've always wanted to write video editing software for the Amiga. The avcodec/avformat API is pretty-much undocumented and foreign to the system. Also, we only have the avcodec library at present. If I had a better animation datatype with an encoding API, I would have an app up and running by now.
Hence my interest in improving datatypes, and improving the animation datatype in particular.
My post was ment as what it is, polarizing, but not as a complain about the topic itself.
But if you go back a few years of AmigaOS development you may see what I?m talking about and that most of it is not entirely prejudice or presentation of guesswork. You will see lots of examples even right here in this thread, no need to search in the past.
I just see AmigaOS development stalling in the effort to make it more and more similar to the established systems like Un*x and Windows and I fail to see the advantage of that. All efforts to e.g. implant things from the Un*x world so far lead to severe problems with AmigaOS software development, hence hindering active native development instead of supporting it.
Same goes for "to MUI or not to MUI", this struggle hinders development, as well as "ReAction is crap, do more work on integrating foreign GUI systems that will lead to even more work in order to get it integrated". This is pure nonsense and I don?t get why people still insist on that. Same goes for open source, as good as the idea itself is. How many open sourced projects grew mature in all this years? Not many and that is IMHO caused by misconception in using as many foreign solutions and paradigms as possible, completely ignoring the abilities AmigaOS has.
Hope this explanation was a little bit better to understand.
"I just see AmigaOS development stalling in the effort to make it more and more similar to the established systems like Un*x and Windows and I fail to see the advantage of that. All efforts to e.g. implant things from the Un*x world so far lead to severe problems with AmigaOS software development, hence hindering active native development instead of supporting it."
Define in detail what you mean by "more similar to the established systems like Un*x and Windows". And define "severe problems".
"Same goes for "to MUI or not to MUI", this struggle hinders development, as well as "ReAction is crap, do more work on integrating foreign GUI systems that will lead to even more work in order to get it integrated". This is pure nonsense and I don?t get why people still insist on that."
Who's said that we should integrate foreign GUI systems for the core OS (I'm genuinely interested in a source for this)? If you are referring to what Rogue said in this thread then I think he's just expressing that there is a need for a new better GUI system, one that has neither the weak points of MUI nor reaction. That itself does not mean that is has to be a foreign one. I'm sure Rogue would answer a direct question on that if you want a deeper explanation.
"Same goes for open source, as good as the idea itself is. How many open sourced projects grew mature in all this years? Not many and that is IMHO caused by misconception in using as many foreign solutions and paradigms as possible, completely ignoring the abilities AmigaOS has."
Open source is not a concept that dictates where the source comes from. Open source just means that the source is open for anyone to read and use within the confines of its license. Nor does the concept dictate whether you use AmigaOS abilities or not. For example, the foundation of a would be Open Amiga is of course to use and extend the AmigaOS capabilities. Open Source itself is not something that dictates whether you do that or not.
whose wrote: "XML is a must, you can edit preferences easily, using a simple text editor
Tell me about it. There is very little need for XML, especially in prefs files. Most of what you can do with XML you can do with IFF, and it's a lot easier to read IFF (you can quickly scan through chunked formats, and of course we have iffparse.library to do much of this work).
Outside of things like HTML, which it is useful to be able to edit in a text editor, I see very very little need for XML-based formats. I find them an utter nightmare to parse and would much rather deal in IFF. It's also no easier to write XML (and it takes up more disk space with mostly unnecessary start and end tags), so no benefit there either.
I have two projects on the go that need to read XML. I've pretty much given up with both of them (one is the WebDAV interface of http-handler) because of the hassle of trying to get data out of the XML.
Is our standard open? You betcha, we're using XML. Never mind that it would be easier and cheaper to get our data storage routines through industrial espionage than to figure out what on earth we're storing in it
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
I written a guide to Amiga portable programming (soon it'll all translated in english, you can read part of it on 
), and it handles all memory allocation for frames internally. I want to make the new API in such a way that animation datatypes writers can use avcodec.library if they wish. That way they we won't have to write our own version of codecs every time a new one comes out. 
