I implemented gestures for BeOS on a system-wide level, you can get the GPL'd software here: http://www.bebits.com/app/2281 It is based on libstroke which can be easily used in any applications.
The major advantage of MD over mp3 is for me that you don't need a computer for it. You can record MDs at a friend's house connecting your portable to her CD player or even make bootlegs on concerts. Try that with an mp3 player...
Programs of this kind are often forgotten in lists of "professional" music software. I guess that's primarily because MAX, PD, SuperCollider or CSound require that you're not only a musician but also a programmer.
I wish the KDE and Gnome developers would take OS X as a hint on the golden rule to provide a usable UI: Less is more. Don't spam the user with options, dialogs, shortcuts and themes. Keep it simple, straightforward and consistent. OS X doesn't even allow you to change the default UI fonts or colours, since it is not necessary at all. Just throw away everything that is not essential, and focus on core functionality instead of gimmicks.
Yeah, you guys can be joking around up there. Be glad you're not down here, Satan's bitching all day now about that freezing cold we have now. You know, hell used to be a lovely hot place, but now it's just friggin' cold down here and Satan is swearing all the time. No fun.
Companies were in fact happily busy porting to BeOS (Yes, there have been very early versions of Cubase and Nuendo) until the infamous focus shift and the death of Be. Why would they port on a super-niche OS like BeOS but not on Linux, which has not only much better hardware support and popularity? BeOS offered better performance on similar hardware compared to MacOS or Windows, together with proper APIs. Unless Linux can offer the same, no company will be interested in porting software on it.
Unfortunately, there are no comprehensive solutions like Logic or Cubase. So far there are only pure MIDI sequencers or 100% recording applications, but I haven't seen any package that integrates both of them so I could arrage samples, MIDI hardware and VSTi instruments in one central program. And further, for a complete solution you would not only need a good sequencing package but also plugins, synthesizers/samplers (ES2, Absynth, etc) and mastering software (I'll never let go of T-Racks!).
I can only agree with the previsous poster. $10 a month is a fair price for unlimited downloads, and eMusic's selection is excellent. Only the 128kBit/s are a bummer, that's why I mainly download artificial music (Matmos, Atom Heart, etc) where you don't notice the difference. Unfortunately, 128kBit/s really disturbing in Classical or Jazz recordings.
I never said it was. I did say however, that a KDE-based distro (e.g. Corel Linux) is an operating system, making KDE an essential part of that operating system. Corel Linux would be seriously crippled without KDE, and lose quite some functionality if Konqueror was removed.
Once again: KDE is not an operating system. But it's an integral part of various Linux-based operating systems.
KDE is not an OS. But neither is Linux. SuSE Linux is an OS, so is Mandrake and so is Debian GNU and various others. Some of those heavily rely on KDE (e.g. Corel Linux - there sure are newer ones, but I haven't run anything besides Debian for years now), removing Konqueror from that OS' would make some programs that were designed to run on those OS' fail. In these cases, Konqueror is an integral part of the OS as IE is in Windows.
Yes, this guy obviously doesn't have a clue what an operating system is. However, it's true that any KDE-based distro is in the same situation as Windows is: Sure you can remove the browser, but that will kill certain other programs that need to be replaced as well (e.g. the file browser) and other programs using the browser functionality will also lose freatures (e.g. no more HTML help in your IDE).
You won't get people to agree on this, not to mention that this specific feature is very cheap in resources.
The problem is that you arrange menu items in a global menu bar differently than in per-window menus. If you have to respect both models you compromise.
It's not important for the application if the icons are 2D or 3D or where the menubar is.
Yes it is. If the systems uses 2D icons, I will use 2D icons in my application. If it uses 3D icons, I will use 3D icons in my application.
So if I take advantage of KDE libraries that take care of many such things, my application won't fit in the system? Interesting.
The KDE libs provide widgets and a few standard dialogs, but they won't make my application comply to the systems metaphors and basic principles.
And after trying focus-follows-mouse, I didn't have any fun, the only difference I noticed was a focus policy that I don't like.
Ever tried to pick a menu item with both the global menu bar and focus-follows-mouse activated?
Also, you appear to be confused about what themeing/skinning is. [...] It DOES NOT, I repeat DOES NOT change the layout of the interface or how it works. It only affects what it looks like. Even worse. If it looks like MacOS, it should behave like MacOS. If it looks like Windows, it should behave like Windows. Unfortunately, this is not the case and confuses users even more.
Yes, I do have specific complatins about the KDE UI and I have expressed them in various places, but they will never be addressed, because they apply to the general concept of KDE: Not making any decisions. Wether the menu bar is global or inside the application window should never be optional - this is a fundamental decision that should be made by the developers once for all. The same goes for button placements and the terminology used in programs.
If you write an application, you want to know what the user's system looks like. Does it use 3D or 2D icons? How does the system use bevels and mouseovers? Is there a per-window or a per-application menu? Where am I supposed to put OK and Cancel buttons in dialogs? What colors am I supposed to use for which meaning? Making all of this a user option makes it impossible for developers to write applications that fit into the user's system. For example: Neither KDevelop nor Opera are able to deal with a global menu bar. Opera retains a per-window menu bar and KDevelop places some dialogs behind the menu bar, making their title bars inaccessable. And if you want real fun, activate global menu bars and focus-follows-mouse in KDE.
Wow, they did rate that as a troll? Your posting is one of the best comments I ever read on Slashdot. I assume people did mod you down because of your opinion on the one-click patent and not your comment on UIs.
I love how this comment is less trollish than it may sound at first: The MacOS UI guidelines are a classic example on how strict and consistent guidelines can help providing a good user experience. Microsoft has never been as strict and consistent in their guidelines (MDI: one day it's in, one day it's out) and that carries through to the applications. Different key bindings, different menu order, different metaphors and icon styles.
It is strange how many OSS fans relate to such things: On the one hand, they do not accept strict guidelines that tell you how an application has too look or behave - for them it is taking away their "freedom". OTOH, at the same time they're very strict and disciplined when it comes to following technical guidelines like RFCs, IEEE and W3C standards. No, I did not say hippocrats. But I did think it.
UIs that are good for the beginning user may not be good for the power-user...
That's a common point I have yet to see proven. Usually, expert users use different applications than beginners and the designer/developer of an application can adjust to that.
For applications that are being used by all kinds of users (e.g. a file manager), ease of use serves both sides. If you find something that makes a beginner's life easier, why should experts not be able to profit from that? It's not like having to throw annoying wizards all over the place was ever essential for an easy-to-use system.
The pure beginner is, IMSO, overrated. Easy to use should not mean beginnerfriendly but userfriendly. A homecomputer is not an ATM or ticket vending machine that needs to be understood immediately. If it's a little hard to learn, the user will bother once. If it's a pain in the ass to use, the user will bother every time. See the Anti-Mac Interface for details.
Now, that is finally a good article on OSS UIs. In a lot of places, UIs are misunderstood as fancy graphics shell with lots of features and options. Unfortunately, this is the direction I see KDE running.
A lot of people do not understand how themes and options do decrease the usability of the UI. If you are able to improve the UI significantly by changing a few options or applying a skin, then there was something wrong with the whole thing in the first place. People should not waste their energy on themeing engines or messy options dialogs (my favourite horror is the KDE control center) but focus on one UI style and make that the best. Rather one perfect UI than a dozen so-so ones.
Why should Microsoft not continue selling software for MacOS? They seem to make good money from it. As long as they will make cash from writing MacOS software, they will do it. And I am sure Microsoft would not hesitate to write Linux software as soon it was profitable for them. After all, it's just capitalism.
Slashdot Mirror
I implemented gestures for BeOS on a system-wide level, you can get the GPL'd software here:
http://www.bebits.com/app/2281
It is based on libstroke which can be easily used in any applications.
OS X is a chance for the clones to come back: This German vendor is selling OS X compatible Umax clones with G4 CPUs for EUR 729+.
The major advantage of MD over mp3 is for me that you don't need a computer for it. You can record MDs at a friend's house connecting your portable to her CD player or even make bootlegs on concerts. Try that with an mp3 player...
You might like Ableton Live's interface. Clean, not gimmicks, perfectly understandable.
(sorry for the link - Ableton.com is frame-based, unfortuately)
ReBorn comes only as a Intel binary - so much for running it on BSDs or PowerBooks. Too bad, I'd love to see that ported to BeOS or MacOS X.
Programs of this kind are often forgotten in lists of "professional" music software. I guess that's primarily because MAX, PD, SuperCollider or CSound require that you're not only a musician but also a programmer.
I wish the KDE and Gnome developers would take OS X as a hint on the golden rule to provide a usable UI: Less is more.
Don't spam the user with options, dialogs, shortcuts and themes. Keep it simple, straightforward and consistent. OS X doesn't even allow you to change the default UI fonts or colours, since it is not necessary at all. Just throw away everything that is not essential, and focus on core functionality instead of gimmicks.
Yeah, you guys can be joking around up there. Be glad you're not down here, Satan's bitching all day now about that freezing cold we have now. You know, hell used to be a lovely hot place, but now it's just friggin' cold down here and Satan is swearing all the time. No fun.
Companies were in fact happily busy porting to BeOS (Yes, there have been very early versions of Cubase and Nuendo) until the infamous focus shift and the death of Be. Why would they port on a super-niche OS like BeOS but not on Linux, which has not only much better hardware support and popularity? BeOS offered better performance on similar hardware compared to MacOS or Windows, together with proper APIs. Unless Linux can offer the same, no company will be interested in porting software on it.
Unfortunately, there are no comprehensive solutions like Logic or Cubase. So far there are only pure MIDI sequencers or 100% recording applications, but I haven't seen any package that integrates both of them so I could arrage samples, MIDI hardware and VSTi instruments in one central program.
And further, for a complete solution you would not only need a good sequencing package but also plugins, synthesizers/samplers (ES2, Absynth, etc) and mastering software (I'll never let go of T-Racks!).
I can only agree with the previsous poster. $10 a month is a fair price for unlimited downloads, and eMusic's selection is excellent. Only the 128kBit/s are a bummer, that's why I mainly download artificial music (Matmos, Atom Heart, etc) where you don't notice the difference. Unfortunately, 128kBit/s really disturbing in Classical or Jazz recordings.
8MB display memory should be still enough display memory for 1024x768 truecolor with double buffering.
Other than that: Wasn't AGP supposed to allow the GPU to access system RAM as well, albeit slower?
I never said it was. I did say however, that a KDE-based distro (e.g. Corel Linux) is an operating system, making KDE an essential part of that operating system. Corel Linux would be seriously crippled without KDE, and lose quite some functionality if Konqueror was removed.
Once again: KDE is not an operating system. But it's an integral part of various Linux-based operating systems.
KDE is not an OS. But neither is Linux. SuSE Linux is an OS, so is Mandrake and so is Debian GNU and various others. Some of those heavily rely on KDE (e.g. Corel Linux - there sure are newer ones, but I haven't run anything besides Debian for years now), removing Konqueror from that OS' would make some programs that were designed to run on those OS' fail. In these cases, Konqueror is an integral part of the OS as IE is in Windows.
Yes, this guy obviously doesn't have a clue what an operating system is. However, it's true that any KDE-based distro is in the same situation as Windows is: Sure you can remove the browser, but that will kill certain other programs that need to be replaced as well (e.g. the file browser) and other programs using the browser functionality will also lose freatures (e.g. no more HTML help in your IDE).
The problem is that you arrange menu items in a global menu bar differently than in per-window menus. If you have to respect both models you compromise.
It's not important for the application if the icons are 2D or 3D or where the menubar is.
Yes it is. If the systems uses 2D icons, I will use 2D icons in my application. If it uses 3D icons, I will use 3D icons in my application.
So if I take advantage of KDE libraries that take care of many such things, my application won't fit in the system? Interesting.
The KDE libs provide widgets and a few standard dialogs, but they won't make my application comply to the systems metaphors and basic principles.
And after trying focus-follows-mouse, I didn't have any fun, the only difference I noticed was a focus policy that I don't like.
Ever tried to pick a menu item with both the global menu bar and focus-follows-mouse activated?
Even worse. If it looks like MacOS, it should behave like MacOS. If it looks like Windows, it should behave like Windows. Unfortunately, this is not the case and confuses users even more.
Yes, I do have specific complatins about the KDE UI and I have expressed them in various places, but they will never be addressed, because they apply to the general concept of KDE: Not making any decisions. Wether the menu bar is global or inside the application window should never be optional - this is a fundamental decision that should be made by the developers once for all. The same goes for button placements and the terminology used in programs.
If you write an application, you want to know what the user's system looks like. Does it use 3D or 2D icons? How does the system use bevels and mouseovers? Is there a per-window or a per-application menu? Where am I supposed to put OK and Cancel buttons in dialogs? What colors am I supposed to use for which meaning? Making all of this a user option makes it impossible for developers to write applications that fit into the user's system. For example: Neither KDevelop nor Opera are able to deal with a global menu bar. Opera retains a per-window menu bar and KDevelop places some dialogs behind the menu bar, making their title bars inaccessable. And if you want real fun, activate global menu bars and focus-follows-mouse in KDE.
Yes, I did. Ah, the merits of not being a native speaker :-(
Wow, they did rate that as a troll? Your posting is one of the best comments I ever read on Slashdot. I assume people did mod you down because of your opinion on the one-click patent and not your comment on UIs.
It is strange how many OSS fans relate to such things: On the one hand, they do not accept strict guidelines that tell you how an application has too look or behave - for them it is taking away their "freedom". OTOH, at the same time they're very strict and disciplined when it comes to following technical guidelines like RFCs, IEEE and W3C standards. No, I did not say hippocrats. But I did think it.
That's a common point I have yet to see proven. Usually, expert users use different applications than beginners and the designer/developer of an application can adjust to that.
For applications that are being used by all kinds of users (e.g. a file manager), ease of use serves both sides. If you find something that makes a beginner's life easier, why should experts not be able to profit from that? It's not like having to throw annoying wizards all over the place was ever essential for an easy-to-use system.
The pure beginner is, IMSO, overrated. Easy to use should not mean beginnerfriendly but userfriendly. A homecomputer is not an ATM or ticket vending machine that needs to be understood immediately. If it's a little hard to learn, the user will bother once. If it's a pain in the ass to use, the user will bother every time. See the Anti-Mac Interface for details.
Did you even bother to read the article? UI design is not about being pretty, it's about being usable.
A lot of people do not understand how themes and options do decrease the usability of the UI. If you are able to improve the UI significantly by changing a few options or applying a skin, then there was something wrong with the whole thing in the first place. People should not waste their energy on themeing engines or messy options dialogs (my favourite horror is the KDE control center) but focus on one UI style and make that the best. Rather one perfect UI than a dozen so-so ones.
Why should Microsoft not continue selling software for MacOS? They seem to make good money from it. As long as they will make cash from writing MacOS software, they will do it. And I am sure Microsoft would not hesitate to write Linux software as soon it was profitable for them. After all, it's just capitalism.