Forget about analogies with the real world objects. Computer files are nothing but real life objects. They have different types, they are very easy to move around, and there are way too many of them.
File manager must provide convinience, and not an analogy.
Try copying bunch of files from one dir to another using keyboard in good old mc (Midnight Commander - grandfather of gnome file managers ), and then try doing same using mouse in spatial Nautilus. Whats faster and easier?
Using lots of different OSes over my 15 years of career in IT, I've seen it all, and I can attest that nothing beats simplicity and convinience of two pane file managers, originally introduced by Norton Commander. Proper GUI version of it is whats needed, not spatial-shmatial garbage.
Note that simple-minded users who may require this spatial mode are extremely unlikely to use any file manager at all. All they are going to do is open the word processor and save files in single directory. They almost never do any File management. It s a pity, that gnome developers can't see such a simple thing.
The fact that KDE is popular does not make it good. Windows is much more popular, but I think we all agree that its bloated out of proportions. IMHO KDE went the same way.
If you try and look at KDE sources, its bloatness becomes self-evident. Its full of duplicated, copy-pasted spagetti code. Often C++ classes are instantiated without regard on how expensive construction/destruction is. Dependancies are extremely convoluted. List goes on and on.
Basically KDE fell victim of its own popularity. It attracted too many inexperienced contributors. The fact that its written in C++ made things worse, as C++ tends to hide performance problems behind simple statements ( most notably object construction/destruction).
Another problem with KDE (and GNOME) is its bloated clipart selection. Icon sets often include numerous duplicate icons, icons that could be blended from simpler ones, same icon are duplicated for different screen resolution. For all I can see it does not have any effective loaded image management solution, and the truth is that images occupy most of the RAM space.
Ability to switch back to older behaviour does not fix the fact that default one is bad. All this talk about having "spatial interface" is utter nonsense.
The purpose of computers is to provide easy access to huge volums of information, and "spatial" does not serve this purpose at all. Average computer contains hundreds of thousands of files nowdays, and trying to present them as real life objects will create a huge pile of file cabinets clattering precious monitor space.
Consider this - when you enter the building - you are presented with directory of what is where, in a simple tabular format. You are not presented with 3D model of the building, nor you are presented with pile of cascading directories - one for each room. Its all there on a single sheet. All the essential information had been extracted for you, and presented in a form so you can readily see it all at once.
Going back to file managers, its easy now to see, that even tree/details approach, although still lacking, is more efficient then so called spatial one. But as it still requires you to drill down for information - its not perfect. The goal must be to present in a single window all the usefull things, no matter how deep down the directory tree they are, while leaving out everything else.
Novice users don't really care about how to traverse directory tree - in a single window or many windows, what they care about is that all things that they need, are right there on the desktop, so that they don't need to traverse anything.
I can understand proponents of spatial inteface, as its a very obvious idea, but hey, developers should think twice, before implementing things like that. Whats worse is that in thins particular case developers already had bad example before them, yet they decided to ignore it. Don't know if ignorance is a blessing in this particular case.
Large number of such. You would need to try it out to really get a scoop of it. For example AfterSTep maintains a database of styles to be used for different classes of windows, for example having vertical tbars on some, no move/resize handles on others, no decorations at all on even different windows. AS supports layers. Avoid Cover attribute could be assigned to some windows, which will make sure that this windows will never be covered. Window placement is very flexible - you can have smaller windows placed in one part of the screen, while bigger windows in another, or place certain class of windows on certain desktop only. Wharf the button bar is highly configurable, can virtually take any shape, based on your needs. Complete flexibility in how keys are mapped allows you to resolve conflicts with your favorite applications. Menus are treated as separate windows, allowing you to pin them to desktop, move/resize/shade them. there are 4 ways of switching between windows, depending on how you like it. AS does not depend on too many libraries, and in fact can fully function without any ( it has its own parser of XPM and XCF files image files). I can go on like that forever...
If you want to use gradients then colors number grows sufficiently. Overalll I counted about 30 colors required by minimal set. Considering that most of them you have to select matching Hues, and not plain rgb values that does grow into a problem. One could see it by simply browsing the selection of themes on t.o.
XML functionality does not just generates gradient and overlaps it with texture. It can scale,tile,crop,tint,shade,blur and overlay any number of images. It lets you change hue saturation value of the image, or part of it. For example you can convert all the blue pixels in it into red ones, or just saturate yellow pixels till the become almost white. It could do 15 types of overlaying of unlimited number of images ( alpha, tinting, add, sub, overlay, screen , etc. ). It allows you to draw antialiased text ( there are 6 3-D types of text BTW ). You can draw border/bevel around images. You can generate gradients or solid filled images. You can flip images, and list goes on and on and on.
Interesting, although I don't compress window buffers, since window management windows are too small for that. Instead I compress large images, such as root backgrounds, etc.
I doubt that NeXT had this feature, as it makes things abit more CPU intensive, something that is unnoticeable now, but was very noticeable back then.
But then again both OS X and NeXT are proprietary systems - while we are talking about open source stuff.
Color schemes is not the same as themes. How do you come up with colors in your themes? AfterSTep has nice feature where all you have to do is specify single color, and AfterStep will generate set of 31 matching colors that you can use in different parts of the interface. Whats more - XML images allow you to adjust colors accordingly even in textures and backgrounds, without actually changing the image. As the result all this hardle of mixing and matching different colors is gone.
BTW some of the icons suppliued with AS were borrowed from Rob Malda's excellent collection of PNG icons. Now lets see who will dare to complain:) grrrr
If you are running X over the net you are better off bnot using any textures at all. In that regards older AS or even things like twm are definately a better choice, since they don't do any text antialiasing and store all the images on the server, and generally use very net-safe Xlib calls. AfterSTep 2.0 does transfer alot of image data over the wire, although if you do things like transparency, you can't avoid it, and AS 2.0 handles it much better then older versions.
1)Colorschemes 2)Window edge snapping while moving/resizing windows 3) better virtual desktop implementation 4) Menus adjusting to your use pattern, by propping up recently used ubitems into higher level menus 5) XML images 6) Better ICCCM compliance 7) Extended WM specs compliance 8) I'm better then Alfredo:)
Dude, Image manipulation code in AS 2.0 being as advanced as it is is much smaller then in older versions, and is actually much smaller then venerable ImLib.
Saving few KB of png files is not an issue. Issue is when you need to convert all your icons from one colorscheme to another. I can do it with one click - can you ?
there are no new dependancies. built in xml parser takes like 50 lines of code ( as it does not do much of traditional XML bloat parsing )
Making prefs menu is not as easy as you think, and before you can do that - you need to fix all other basic parts of the system. Which we done. And now we can implement prefs menu, that will blow you away.
ON eof the purposes of using XML is to reduce number of images. I mean look at icon themes for KDE - they have many copies of the same image and many images that essentially look the same or could be compiled from simplier images. We solv that problem with XML.
We don't have too many ppl working on AS. I mean I do all the development, clipart design, support, and pretty much everything else. I don't have no time whatsoever to work on web site, and it was rather dead for quite a while, and only recently got revived by Remmy. One of the purposes of releasing this beta was to attract more ppl to the project, and get some help.
You can take a look at my devel site on SourceForge: http://afterstep.sf.net and screenshots on http://afterstep.sf.net/afterstep20beta/
Its not just the text antialiasing, although AfterStep 2 can antialias both TTF fonts and good old X bitmap fonts. AfterSTep has a very powerfull graphics engine with things like in-memory image compression, high quality image rendering with dithering, high quality and fast scaling, 15 ways to overlay image on top of each other (similar to GIMP) Hue Saturation Value manipulation, etc. Note that all of it is very fast and memory efficient.
Now AfterStep's desktop model is much more flexible then Window Maker's
Menu editor/prefs thingy is probably the only absent thing in AS 2, but I'm working on it.
Originally AS was anal about being too NeXT strict, which prompted creation of WM, and if you'd look into possibilities of WM's titlebar and frame decoration configuration, and compare it to AfterStep - you'll see enough advantage in AS.
both written in C, but let me tell ya, that you don't want to be messing around with WM's codebase - it sucks.
AfterSTep does not plays catch up - in 2.0 version we have several things that no other desktop environment has - XML images, Menus adjusting to use pattern, Colorschemes, to name just few.
As I noted before AfterStep 2 is complete new rewrite, and all the flaws had been fixed or will be fixed. BTW Alfredo Kojima wrote WindowMaker not becouse AS had flaws (which it did), but becouse he wanted strick compliance with NeXT interface, while AfterStep was moving towards being flexible and allow non-NeXTis features.
AfterStep 2.0 is a complete from scratch reimplementation, Its much more flexible then WM, its graphics subsistem is much more advanced and powerfull, resource management is better ( consider the fact that AS now compresses images in memory - something no other desktop environment could do). It was redesigned to be compliant with new window management specs, and as different from WM it is actually being developed right now.
I don't really see how WM could join AS. I mean WM's codebase is so messed up, that I would not want to take even a tiny bit of it into AS. Besides AS can do most everything WM does and plus much more already.
No, its not compatible with SVG, and actually has different goal. Afterstep's XML images merely provides interface to powerfull functionality of libAfterImage, including image overlaying, scaling, tiling, cropping, and so on. It has many uses, such as compiling complex icons from simplier clipart, creating scaled down thumbnails, changing colors of images to match that of colorscheme, and so on. It is very usefull in different fields, such as web design, where you can create a script that generates all of the website's images from some clipart ( including text rendering ). Note that AfterStep does not need to keep multiple copies of the same image for different pourposes, which is what KDE does with its icon themes, etc.
I've added complete support for new Extended WM Hints to devel branch of AfterStep, but since its still long way from completion, I'll be backporting this particular piece of code into stable branch sometime soon.
Slashdot Mirror
Forget about analogies with the real world objects. Computer files are nothing but real life objects. They have different types, they are very easy to move around, and there are way too many of them.
File manager must provide convinience, and not an analogy.
Try copying bunch of files from one dir to another using keyboard in good old mc (Midnight Commander - grandfather of gnome file managers ), and then try doing same using mouse in spatial Nautilus. Whats faster and easier?
Using lots of different OSes over my 15 years of career in IT, I've seen it all, and I can attest that nothing beats simplicity and convinience of two pane file managers, originally introduced by Norton Commander. Proper GUI version of it is whats needed, not spatial-shmatial garbage.
Note that simple-minded users who may require this spatial mode are extremely unlikely to use any file manager at all. All they are going to do is open the word processor and save files in single directory. They almost never do any File management. It s a pity, that gnome developers can't see such a simple thing.
If you try and look at KDE sources, its bloatness becomes self-evident. Its full of duplicated, copy-pasted spagetti code. Often C++ classes are instantiated without regard on how expensive construction/destruction is. Dependancies are extremely convoluted. List goes on and on.
Basically KDE fell victim of its own popularity. It attracted too many inexperienced contributors. The fact that its written in C++ made things worse, as C++ tends to hide performance problems behind simple statements ( most notably object construction/destruction).
Another problem with KDE (and GNOME) is its bloated clipart selection. Icon sets often include numerous duplicate icons, icons that could be blended from simpler ones, same icon are duplicated for different screen resolution. For all I can see it does not have any effective loaded image management solution, and the truth is that images occupy most of the RAM space.
Ability to switch back to older behaviour does not fix the fact that default one is bad. All this talk about having "spatial interface" is utter nonsense.
The purpose of computers is to provide easy access to huge volums of information, and "spatial" does not serve this purpose at all. Average computer contains hundreds of thousands of files nowdays, and trying to present them as real life objects will create a huge pile of file cabinets clattering precious monitor space.
Consider this - when you enter the building - you are presented with directory of what is where, in a simple tabular format. You are not presented with 3D model of the building, nor you are presented with pile of cascading directories - one for each room. Its all there on a single sheet. All the essential information had been extracted for you, and presented in a form so you can readily see it all at once.
Going back to file managers, its easy now to see, that even tree/details approach, although still lacking, is more efficient then so called spatial one. But as it still requires you to drill down for information - its not perfect. The goal must be to present in a single window all the usefull things, no matter how deep down the directory tree they are, while leaving out everything else.
Novice users don't really care about how to traverse directory tree - in a single window or many windows, what they care about is that all things that they need, are right there on the desktop, so that they don't need to traverse anything.
I can understand proponents of spatial inteface, as its a very obvious idea, but hey, developers should think twice, before implementing things like that. Whats worse is that in thins particular case developers already had bad example before them, yet they decided to ignore it. Don't know if ignorance is a blessing in this particular case.
Have you even tried it ?
dude, SVG is vector graphic, and has completely different purpose.
Also I'm yet to find any usable image in SVG format.
Large number of such. You would need to try it out to really get a scoop of it.
For example AfterSTep maintains a database of styles to be used for different classes of windows, for example having vertical tbars on some, no move/resize handles on others, no decorations at all on even different windows. AS supports layers. Avoid Cover attribute could be assigned to some windows, which will make sure that this windows will never be covered. Window placement is very flexible - you can have smaller windows placed in one part of the screen, while bigger windows in another, or place certain class of windows on certain desktop only.
Wharf the button bar is highly configurable, can virtually take any shape, based on your needs.
Complete flexibility in how keys are mapped allows you to resolve conflicts with your favorite applications. Menus are treated as separate windows, allowing you to pin them to desktop, move/resize/shade them. there are 4 ways of switching between windows, depending on how you like it. AS does not depend on too many libraries, and in fact can fully function without any ( it has its own parser of XPM and XCF files image files). I can go on like that forever...
If you want to use gradients then colors number grows sufficiently. Overalll I counted about 30 colors required by minimal set. Considering that most of them you have to select matching Hues, and not plain rgb values that does grow into a problem. One could see it by simply browsing the selection of themes on t.o.
XML functionality does not just generates gradient and overlaps it with texture. It can scale,tile,crop,tint,shade,blur and overlay any number of images. It lets you change hue saturation value of the image, or part of it. For example you can convert all the blue pixels in it into red ones, or just saturate yellow pixels till the become almost white. It could do 15 types of overlaying of unlimited number of images ( alpha, tinting, add, sub, overlay, screen , etc. ).
It allows you to draw antialiased text ( there are 6 3-D types of text BTW ). You can draw border/bevel around images. You can generate gradients or solid filled images. You can flip images, and list goes on and on and on.
Interesting, although I don't compress window buffers, since window management windows are too small for that. Instead I compress large images, such as root backgrounds, etc.
I doubt that NeXT had this feature, as it makes things abit more CPU intensive, something that is unnoticeable now, but was very noticeable back then.
But then again both OS X and NeXT are proprietary systems - while we are talking about open source stuff.
Obviously you never tried AS 20, yet pretend to know something about it.
Do me a favour and stay with Window Maker.
Color schemes is not the same as themes. How do you come up with colors in your themes? AfterSTep has nice feature where all you have to do is specify single color, and AfterStep will generate set of 31 matching colors that you can use in different parts of the interface.
Whats more - XML images allow you to adjust colors accordingly even in textures and backgrounds, without actually changing the image.
As the result all this hardle of mixing and matching different colors is gone.
http://afterstep.sourceforge.net/screenshot.glass. jpg
:) grrrr
let see if you like that.
BTW some of the icons suppliued with AS were borrowed from Rob Malda's excellent collection of PNG icons. Now lets see who will dare to complain
The fact that AS was too bloated and more of a hack was the reason for me to rewrite it. It is no more "just a hack" in 2.0
If you are running X over the net you are better off bnot using any textures at all. In that regards older AS or even things like twm are definately a better choice, since they don't do any text antialiasing and store all the images on the server, and generally use very net-safe Xlib calls.
AfterSTep 2.0 does transfer alot of image data over the wire, although if you do things like transparency, you can't avoid it, and AS 2.0 handles it much better then older versions.
1)Colorschemes :)
2)Window edge snapping while moving/resizing windows
3) better virtual desktop implementation
4) Menus adjusting to your use pattern, by propping up recently used ubitems into higher level menus
5) XML images
6) Better ICCCM compliance
7) Extended WM specs compliance
8) I'm better then Alfredo
Dude, Image manipulation code in AS 2.0 being as advanced as it is is much smaller then in older versions, and is actually much smaller then venerable ImLib.
Saving few KB of png files is not an issue. Issue is when you need to convert all your icons from one colorscheme to another. I can do it with one click - can you ?
there are no new dependancies. built in xml parser takes like 50 lines of code ( as it does not do much of traditional XML bloat parsing )
Making prefs menu is not as easy as you think, and before you can do that - you need to fix all other basic parts of the system. Which we done. And now we can implement prefs menu, that will blow you away.
ON eof the purposes of using XML is to reduce number of images. I mean look at icon themes for KDE - they have many copies of the same image and many images that essentially look the same or could be compiled from simplier images. We solv that problem with XML.
We don't have too many ppl working on AS.
I mean I do all the development, clipart design, support, and pretty much everything else.
I don't have no time whatsoever to work on web site, and it was rather dead for quite a while, and only recently got revived by Remmy. One of the purposes of releasing this beta was to attract more ppl to the project, and get some help.
You can take a look at my devel site on SourceForge:
http://afterstep.sf.net
and screenshots on
http://afterstep.sf.net/afterstep20beta/
Its not just the text antialiasing, although AfterStep 2 can antialias both TTF fonts and good old X bitmap fonts. AfterSTep has a very powerfull graphics engine with things like in-memory image compression, high quality image rendering with dithering, high quality and fast scaling, 15 ways to overlay image on top of each other (similar to GIMP) Hue Saturation Value manipulation, etc. Note that all of it is very fast and memory efficient.
Now AfterStep's desktop model is much more flexible then Window Maker's
Menu editor/prefs thingy is probably the only absent thing in AS 2, but I'm working on it.
Originally AS was anal about being too NeXT strict, which prompted creation of WM, and if you'd look into possibilities of WM's titlebar and frame decoration configuration, and compare it to AfterStep - you'll see enough advantage in AS.
both written in C, but let me tell ya, that you don't want to be messing around with WM's codebase - it sucks.
AfterSTep does not plays catch up - in 2.0 version we have several things that no other desktop environment has - XML images, Menus adjusting to use pattern, Colorschemes, to name just few.
As I noted before AfterStep 2 is complete new rewrite, and all the flaws had been fixed or will be fixed. BTW Alfredo Kojima wrote WindowMaker not becouse AS had flaws (which it did), but becouse he wanted strick compliance with NeXT interface, while AfterStep was moving towards being flexible and allow non-NeXTis features.
consider this small example that implements aterm's icon from two clipart images :
AfterStep 2.0 is a complete from scratch reimplementation, Its much more flexible then WM, its graphics subsistem is much more advanced and powerfull, resource management is better ( consider the fact that AS now compresses images in memory - something no other desktop environment could do).
It was redesigned to be compliant with new window management specs, and as different from WM it is actually being developed right now.
I don't really see how WM could join AS. I mean WM's codebase is so messed up, that I would not want to take even a tiny bit of it into AS.
Besides AS can do most everything WM does and plus much more already.
No, its not compatible with SVG, and actually has different goal. Afterstep's XML images merely provides interface to powerfull functionality of libAfterImage, including image overlaying, scaling, tiling, cropping, and so on. It has many uses, such as compiling complex icons from simplier clipart, creating scaled down thumbnails, changing colors of images to match that of colorscheme, and so on.
It is very usefull in different fields, such as web design, where you can create a script that generates all of the website's images from some clipart ( including text rendering ).
Note that AfterStep does not need to keep multiple copies of the same image for different pourposes, which is what KDE does with its icon themes, etc.
I've added complete support for new Extended WM Hints to devel branch of AfterStep, but since its still long way from completion, I'll be backporting this particular piece of code into stable branch sometime soon.
AfterStep supports Xinerama as of version 1.8.10