Amiga.org
Amiga News and Community Announcements => Amiga News and Community Announcements => Amiga Software News => Topic started by: amigamad on April 12, 2003, 02:02:57 PM
-
Amiga has released an article describing its application launcher AmiDock in AmigaOS4 with pictures. os.amiga.com (http://os.amiga.com)
-
Hands up who agrees then!
I reckon AmiDock is gonna be one of those, "Why hasn't it been done like THIS before?" applications.
Nice, nice & nice!
-
I must say those screenshots are really shaping up ... I
know i it depends on what developer's machine they are
taking it from, but this was actually really decent, even for
a standard look (I still think the community should get to
vote on a few pre-set looks presented by the developers
though, if nothing else it is a good PR thing letting the
community have an influence).
The application.library and the AmiDock can be a useful
pair. Looking forward to what clever programmers can do
with this. I can for example envision a clipboard lister in a
'dockie' -invaluable. All those nifty alpha-channel effects
could come in handy too. Eye-candy abound! :-D
On a different note, it's good to see content of the CAM
being released to the general public. Not so surprising as
this is what was said to happen from the beginning. And I
didn't notice paying anything to read this info from AInc. Did
you?
.
SlimJim
-
Keep in mind that the current design in the screenshots is not the final one.
I for one am curious to see what they will come up with concerning the design and layout of OS4 (new iconset?, backdrops,...).
There still is no doubt in my mind that OS4 will be a quality product. I really hope they can release it in time. I've got my cash ready and the first day of release, i will buy myself AOne + OS4.
Wishing the OS4 team luck and courage for what are hopefully the last months before release.
-
Look at the options on the screengrabs!
I guess these are there to give a hint of the power the user will have over the look. Fantastic stuff!
As for the AmiDoc I hope we see browser controls there so that the web is truelly integrated into the computer.
Another would be to have a propper history of documents and apps used. This could even include search results. Find 'catagory' opens a window containing e.g .mpg files or Yoga_* files.
I still think a modern variation of the WB1.3 would be a great place to start.
-
Very nice screenshots ... :-D :-D
I thought the article "AmiDock and application.library in AmigaOS 4" was well written and very interesting.
Thanks, Stefan.
As a member of Club Amiga, I read the article when it came out in the online magazine. I think it was a good idea to release it to the general "Amiga" community for their perusal and comment. Perhaps other articles will also be released soon.
Some may call me crazy .... I'm looking forward to AmigaOS 4 :-D :-D
---------------
redfox
-
AmiDock looks same as it always has, a pale shadow of similar docks found in other OS's, such as MacOS X, WM and OS/2. An improvement over the existing AmiDock, but still nothing to write home to mama about. (note, ad a general rule, I don't like Docks much to begin with, never have)
application.library, on the other hand, appears to be one of the worst kludges I've ever seen. Rather than design a future-looking mechanism that operates behind the scenes, Amiga's fallen on the same approach that has belegered WOS applications for years.
-
System wide global xml based preferences/configuration system!
Stroke of genius guys.
-
@teotwin
a system-wide xml based configuration system would be dog-slow compared to text or binary-based configuration systems. The more apps access it, and thereby hit the interpreter, the slower the system runs.
-
a system-wide xml based configuration system would be dog-slow compared to text or binary-based configuration systems. The more apps access it, and thereby hit the interpreter, the slower the system runs.
Explain that, please. The prefs are read when the application starts, and written when the application wants to save it (which is quite rare).
Why should that have any impact on performance? That would only happen if you would re-parse the XML file every time the application wants to access on of its prefs items, but that would be braindead. Application.library caches the file in parsed format in memory.
And if you want to guard against external modifications of the XML file, you set up a DOS file notification and re-parse only if there has been an external access.
So why should this have any more impact on the system than your run-of-the-mill text preferences file, or a binary file?
-
application.library, on the other hand, appears to be one of the worst kludges I've ever seen. Rather than design a future-looking mechanism that operates behind the scenes, Amiga's fallen on the same approach that has belegered WOS applications for years.
Are you sure you understood how this system works? I can't seem to find how this relates to WOS in any aspect.
-
Application library appears to clone functionallity in commodities. Why was commodities not simply extended when most applications implement a commodities interface as is? To say "long-missed feature of AmigaOS" is simply wrong!
Also, the other aspect of applications.library - configurations. Is iffparse.library and ENV not standard in AmigaOS? Again, the sentence "Until now, there was no default system within ..." is simply wrong. Yes, there is work envolved in using iffparse, but surely we could build on this rather than create another library to do similar things! (But yes, XML is the way to go currently).
Simplicity is the key of operating systems, and certainly always has been AmigaOS's API's selling point. Applications.library doesn't seem to have been well thought out at all; certainly it seems more like a 3rd party tool than an OS component.
-
On the 'Why hasn't it been done this way before?" note, it has- NeXT pretty much brought the concept of extensible docks to bear, as someone one had to point out to me on AmiOpen. (In that case, I was arguing in favor of vectorized/scalable displays; apparently NeXT had more prominent user control over scaling of 'dockapps,' or so was said. I've never seen screenshots, and I gathered GNUStep/WindowMaker was taking credit for invention of active content in docks... not really sure, even today.) This new system gives a lot more control over presentation of NeXT-ish docks, though, while most other UIs have followed the Lisa / CDE? / Windows model of limited functionality.
As a UI nut, I'd say there's a conceptual difference between the two approaches; an extensible dock is an area of reserved screen real-estate where overlap doesn't occur. (Those who know me know I'm not a big fan of overlap, especially as relates to the conventional 'cluttered desk' metaphor of interface presentation. ;)) A special-purpose dock is 'just' a funny-shaped window made such to get around the limitations of the windowed environment; it's the UI designer's way of saying, "Well, the interface to *my* product- the OS/Workbench/IE- deserves to be special, but you peonic third-parties only get regular windows, or a little tray on the right, or reimplement your own d*mn solution." I've got nothing against controls reserved to the OS, of course, *if* non-OS software can be allowed to achieve the same level of usability/consistency. (Hey, modern systems have this problem licked! They just make sure *nothing* is usable or consistent! :-D)
...An area of reserved screen real-estate that behaves differently from all other areas (regular windows) can't help but be 'special,' of course... so looked at in that light, the OS X dock does almost as good a job as the NeXT dock, if having failings on aesthetic/efficiency (screen real-estate) grounds; I haven't used it much, but IIRC they've chucked in a sort of "Harvard architecture" enforcement between the left and right sides, which is probably good UI except for the inflexibility in choosing other arrangements (documents organized next to the creating application, say). AmiDock has the potential to do it all, including NeXT/Apple-style persistence (with the automatic adding feature)... with the more flexibility than most previous implementations.
To shoot down one example- OS/2 certainly had good ergonomics with the WarpCenter, but zip for extensibility. Usually, apps didn't bother seeking the same level of presentation (mostly a sign of the times; today, every app, no matter how trivial, seems to demand its own odd-shaped window or 'remote control' dock/tray app); I think I remember one ICQ client that claimed to change its desktop icon based on status, but 1. I never got that to work, and 2. I have no idea if it was a cheap hack or a relatively sane API call.
If I had to call hiatus on AmiDock for anything, it might be for perpetuating the 'everything a [file|object], some objects dockies' arrangement, rather than shooting straight towards 'everything a docky, some dockies can hold/present files.' I have no idea what the code looks like, so it's probably quite feasible to switch over to that approach/probably arranged internally that way, anyway.
I should also note that, once we all have videowalls (literally; I give it 20 years or so, maybe 50 before we can actually put up displays *exactly* like wallpaper- insert horrific Windows Powered 'Blue Room' visions here), user-positioned windows do become less of an issue... in tradeoff, if you think 'skins' and aesthetic candy are a problem *now*... Well, hopefully we'll see more stuff in the vein of e-mail fishtanks (props to DALiworld) and network-monitoring cricket chirps.
---
[Edited after I posted the main glob with my browser on the brink of crashing, and refreshed my understanding of Commodities.]
As to commodities- I was wondering about that in the back of my mind, myself. If I understand things properly, commodities.library is simply about allowing background I/O - though I'm not quite sure what "background I/O" means, in this case. Application.library does sound like it could become a bit monolithic if left unchecked, but on the other hand, it could equally be 'just' the routines required to interface neatly/consistently to the OS at large... and if it does become a "system API in a box," at least there'd *be* a definite API?
-
Application library appears to clone functionallity in commodities.
No. Commodities is a way to install custom input handlers into the input.device's even stream. Application.library is something different.
Is iffparse.library and ENV not standard in AmigaOS?
No. There is no standard on the Amiga. Some programs store their settings in S:, others in ENV:, and others in the application's own directory. To the best of my knowledge, only IPrefs stores its settings as IFF in ENV: Others do whatever they feel like. Application.library is meant to provide a standarized way to do this.
Applications.library doesn't seem to have been well thought out at all; certainly it seems more like a 3rd party tool than an OS component.
Your highly-acclaimed commodities library *did* start out as a 3rd pary tool (on a fish-disk, I think somewhere around 50 or so, if you know what that is), and is now an OS component. Application.library is as much an OS component as e.g. datatypes.
-
@Rouge
No. There is no standard on the Amiga. Some programs store their settings in S:, others in ENV:, and others in the application's own directory. To the best of my knowledge, only IPrefs stores its settings as IFF in ENV: Others do whatever they feel like. Application.library is meant to provide a standarized way to do this.
So you mean, introducing yet another way to do it,
is setting a standard ??
And shouldnt a new standard be a better one ?
How about taking some time to read up on that
"old" and "outdated" IFF that already exists.
Not saying its the best there is, but a good starting point.
And btw.. Here is all the .prefs files in my ENV:Sys
(IFF)
ahi.prefs font.prefs
fullpalette.prefs input.prefs
locale.prefs midi.prefs
palette.prefs printer.prefs
printergfx.prefs screenmode.prefs
wbconfig.prefs WBPattern.prefs
-
So you mean, introducing yet another way to do it,
is setting a standard ??
No, not "yet another way". The way it should officially be handled. We're trying to outline a way that future applications should handle it, to get people away from the "I store my config files whereever I like" kind of attitude.
And shouldnt a new standard be a better one ?
What's so hot about the old way of storing your prefs files wherever you like?
How about taking some time to read up on that
"old" and "outdated" IFF that already exists.
Not saying its the best there is, but a good starting point.
Did that, and decided that we have a better solution. I am not going into this brainless discussion again that I just left on ANN. Like it or not, XML is it. I don't see any reason to pursue your or anyone's fictious super-extended IFF when there is an ad-hoc solution that draws from industry standards.
And btw.. Here is all the .prefs files in my ENV:Sys
(IFF)
ahi.prefs font.prefs
fullpalette.prefs input.prefs
locale.prefs midi.prefs
palette.prefs printer.prefs
printergfx.prefs screenmode.prefs
wbconfig.prefs WBPattern.prefs
If that was a try to prove your point, it was rather pointless. Most of the files are system preferences. Fullpalette and ahi aren't, so they don't have any point in residing in env:sys in the first place. So if at all, this serves as a good example why things should be changed in the first place.
OTOH, I am not going to list the contents of my S: drawer now, or the myriads of files that are in env: If you still insist that this is the way to go, suit yourself :-)
-
No, not "yet another way". The way it should officially be handled. We're trying to outline a way that future applications should handle it, to get people away from the "I store my config files whereever I like" kind of attitude.
Ok, like the move from S: to ENV: you mean ?
What's so hot about the old way of storing your prefs files wherever you like?
Well, S: is not a good place, it wasnt even intended for that either. ENV: is good for smaller files, especially single "variables". PROGDIR: is good too,
for larger files.
Did that, and decided that we have a better solution. I am not going into this brainless discussion again that I just left on ANN. Like it or not, XML is it. I don't see any reason to pursue your or anyone's fictious super-extended IFF when there is an ad-hoc solution that draws from industry standards.
Okey, from what I understand, its not about
a super extended IFF, it could be done with IFF
"as is", only some useful "specifications on paper"
is needed, and practically no new code needed.
But, whatever, its decided already :-(
-
Ok, like the move from S: to ENV: you mean ?
It doesn't really matter where stuff is saved, the point is consistency.
Well, S: is not a good place, it wasnt even intended for that either. ENV: is good for smaller files, especially single "variables". PROGDIR: is good too,
for larger files.
I think that every application which is a bit larger and has its own directory on disk should also store its prefs file there. This way, you can make a backup and restore the backup later without worrying about "auxilary files" (or the stuff that windows refers to as "shared system files"). An Application should be a neat package without spreading its files all over the place.
practically no new code needed
There are other implications. If you want to, check the thread on ANN. An ascii based file format makes the most sence, mostly since the prefs files are usually small.
-
(I have absolutely no idea how this web interfaces quotes stuff, so you'll have to use some imagination :)
No. Commodities is a way to install custom input handlers into the input.device's even stream. Application.library is something different.
Commodities Exchange appears to offer some of the functionality offered through Amidock using application.library, with the infrastructure in place to do much more. At least, *I've* been using it in this way for years. I can't speak for others.
No. There is no standard on the Amiga. Some programs store their settings in S:, others in ENV:, and others in the application's
I believe that even with application.library it would be possible to save settings in S: (unless S: is replaced with /etc/rc/ or something). Just because people don't follow The Ways Things Are Done (TWTAD) doesn't mean that TWTAD isn't a defined standard.
Your highly-acclaimed commodities library
Do not put words into my mouth. I am perfectly capable of speaking for myself without anyone else voicing their opinions in my name.
*did* start out as a 3rd pary tool (on a fish-disk, I think somewhere around 50 or so, if you know what that is),
Don't be rude. It doesn't help to win arguments and influence people.
It's on disk 83.
and is now an OS component. Application.library is as much an OS component as e.g. datatypes.
I don't deny this and didn't suggest it would not be the case. Originally I only stated my disappointment that duplicated functionally appears to be included in the OS. I can't influence this at all, and god knows I'd rather let competent people do the hard work for me anyway.
So, I'd prefer an explanation of the reasoning behind it rather than what I've read so far!
-
Commodities Exchange appears to offer some of the functionality offered through Amidock using application.library, with the infrastructure in place to do much more. At least, *I've* been using it in this way for years. I can't speak for others.
The same functionalty is more or less offered by both "More" and "Multiview" (viewing text). That doesn't mean that the any of these should be gotten rid off, since Multiview will not work from the initial boot.
Commodities does *not* offer an application the possibility to display status information in an icon, add a popup menu, or save its preferences in any way.
I believe that even with application.library it would be possible to save settings in S: (unless S: is replaced with /etc/rc/ or something). Just because people don't follow The Ways Things Are Done (TWTAD) doesn't mean that TWTAD isn't a defined standard.
Of course it is possible. However, you are wrong if you claim that there is a standard. Application library offers an obvious way. Of course you can't force people to use it, but then, we cannot forbid people to call Open/Read/Write/Close. So I don't see your point against application.library.
Do not put words into my mouth. I am perfectly capable of speaking for myself without anyone else voicing their opinions in my name.
Huh? Wasn't it you that brought up the commodities example? It was you, IIRC, who said that application.library duplicates functionatliy.
Don't be rude. It doesn't help to win arguments and influence people.
Rude? You *are* aware that the fish-series has been stopped *quite* some time ago. Of course you are free to interpret this as rudeness, but I am quite sure that a lot of people here never heard of the fish disk series. If that offended you, I apologize, It was not intended as such.
Originally I only stated my disappointment that duplicated functionally appears to be included in the OS.
Like I said, some duplicate functionality is already there, but commodities is something completely different (I found your comment about not being well-though about rather rude, but let's not dwell on this).
So, I'd prefer an explanation of the reasoning behind it rather than what I've read so far!
People will probably not believe me when I say that we have given a lot of thought about things (at least not from the comments I always read). We don't decide on this or another feature without lengthy (and sometimes very heated) discussion.
The reasoning is there, but I don't feel the urge to explain it all, since we are adding quite a number of features, and the usual reply to this specific feature is "IFF is better than XML"
-
@Valan,
I still think a modern variation of the WB1.3 would be a great place to start.
Yes! I'd love to see someone do a re-interpretation of the 1.2-1.3 interface. If OS4 is as skinable as the screen-shots indicate, this shouldn't be a problem for someone to do.
Zoltan
-
"a system-wide xml based configuration system would be dog-slow compared to text or binary-based configuration systems."
Explain that, please. The prefs are read when the application starts, and written when the application wants to save it (which is quite rare).
@Rogue,
Good point. I could see the advantages off a binary-based preference system in 1985, but I think the advantage of having a human-readable prefs file trumps the (tiny) performance hit from parsing an XML file.
Zoltan
-
So why should this have any more impact on the system than your run-of-the-mill text preferences file, or a binary file?
If the XML handler was only dealing with just these configuration files, there would not be any performance issues beyond a nominal setup cost.
However, XML is also the core language for XHTML, the standard in web pages now. It is likely that the XML parsing engine would be used for additional material, including but not limited to: web page rendering, object file decoding, and document object viewing. Now, suddenly, your application is waiting in cue to be handled by the parser. I don't know about you, but long load times hurt a systems perceptions.
Note, this only works *if* the XML parser is shared as opposed to fixed-purpose.
-
I used WOS as it is the best case that 90% of the other people out here understand. The basic meaning is you're tying *every* application to a single library, and pray that no virus or trojan comes along and borks that up. I have had WOS apps that fail to load because the WOS library got corrupted. This kind of functionality should be handled by the kernel invisibly, which is actually easy to do. (surprisingly, the mechanism for this was explained in the very document linked to)
While, yes, it will work, it remains to be an external, and thereby vulnerable, component to the system. This results in all sorts of back doors and opportunities for errant code to do damage to the system. Imagine a trojan that replaces application.library with a new one that runs normally, but also snoops your inputs in order to get such things as credit card information or personal data. Extremely easy to do via this method.
Then there is the bigger problem: You are running the system, by default, in emulation. Only apps which use application.library are flagged as being native apps. This is a horrid design, and creates more overhead in the architecture than is necessary. This results in a complete slowdown due to an overload of latency-inducing checks and balances for the system. "We don't have those checks and balances" is the only answer that would mean you aren't bogged down, but then you'd be unstable as all hell. Talking you'd make AmigaOS 0.9 seem like a rock-solid UNIX contender.
-
Note, this only works *if* the XML parser is shared as opposed to fixed-purpose.
That would only be the case if there is a single process that decodes XML. The application.library only handles preferences, and the application using it doesn't even know it's XML. Generic XML services will be available in the form of a shared library, that can be used like e.g. iffparse.library. There is no system performance hit.
-
The basic meaning is you're tying *every* application to a single library, and pray that no virus or trojan comes along and borks that up
A much better target for attacks of these kinds would be DOS, Intuition, Graphics, or what have you. Granted, they are rom-resident, but it is so easy to patch a rom resident library, or replace the SetPatch program. Or the LoadWB program.
This kind of functionality should be handled by the kernel invisibly, which is actually easy to do
It depends on what you define as an "Application". I definitely don't want every "dir" or "list" to pop up an icon somewhere. OTOH if I start an editor, this is when I want its icon to appear in the Dock. There is no way you can find this out, and it is much better to leave this to an application author.
While, yes, it will work, it remains to be an external, and thereby vulnerable, component to the system.
AmigaOS is no secure system. It will need to go a long way to actually become one. Like I mentioned, SetPatch would be my primary goal for a trojan attack, or LoadWB, BindDrivers, Or a monitor. Everything that is executed on all system at startup.
You are running the system, by default, in emulation. Only apps which use application.library are flagged as being native apps
No, that is wrong. The system is running mostly native. Only a few components are going to stick in emulation. Most of all, no application is flagged as being anything, because there is no distinction between native and emulated applications. This is the exact reason why we didn't go for a sandbox approach but instead treat 68k tasks exactly like PowerPC-Native tasks.
application library only serves as a means to communicate with the dock. If a 68k program calls it, it would get the exact same treatment. We don't usually provide 68k interfaces to new services, so this pretty much excludes 68k programs from calling it.
-
There is no system performance hit.
Would you like to take a bet on that, that XML based files render slower than ANSI or binary files? Remember, I am quoting you here, stating that there is no performance loss whatsoever by using an XML based configuration system over ones closer to the hardware.
-
application library only serves as a means to communicate with the dock. If a 68k program calls it, it would get the exact same treatment. We don't usually provide 68k interfaces to new services, so this pretty much excludes 68k programs from calling it.
See, this was not the impression I got from the overview. application.library, from the overview, looked to be more akin to a userstate kernel than an interface for AmiDock. Now it makes sence and does not look like some kind of mish-mash. Thank you for explaining.
-
Would you like to take a bet on that, that XML based files render slower than ANSI or binary files?
Either I am missing a word here, or that doesn't make sense. What does "render" speed have to do with this?
What I meant was that it doesn't matter how many applications use an XML parser simultaneously. There is no such thing as an "XML parser server" that needs to serialize the parsing (that is how I understood your first comment). The XML parsing is a normal library, and will work in a multitasking context like a custom parser for a custom prefs format (or IFFParse for the matter).
Also, the overhead of parsing an XML file vs. parsing any ASCII based file is so small that it doesn't matter. Of course a binary file formwat would be slightly faster, but the difference will barely be noticable.
So yes, XML is slower than binary, and might be slower than another ASCII based format (although that is debatable and depends on the format of this thing). I don't see however how the fact that a web browser might use an XML parser would have any impact on the startup speed of an application.