Your quibble with the pasted result not being a real layer is almost solved. GIMP can paste that data into a new layer straight away. Try "Paste as new layer". So this is an issue of what default behaviour is the best.
Taking the image size from the clipboard could be done, but I doubt that it would be useful.I sometimes find myself in workflows where I create a lot of images with the same resolution, so I'm glad that GIMP remembers the last one when I reopen the dialog. It would be annoying as hell if there happens to be image data in the clipboard (which I can't do squat about when creating a new image - the clipboard contents just is) and this overrides the cached values. And cluttering up the dialog with a "Take size from clipboard" button might not be worth it, either.
Still, I agree that simple tweaks can enhance a user interface a lot.
We are participating in one of ESA's scientific parbolic flight campaigns and I therefore had the chance to get some insight about the costs involved. The participation fee alone is about 60.000 Euros and more than twice the costs we had for building the experiments. For this we get 90 parabolas with 20 seconds of microgravity for experimenting.
Assuming that the cost structure for NASA's campaign participants is similar, NASA's offer to let these teams participate for free seems to be quite generous. Is there anyone here with more details?
Well, the average scientific experiment really is buggy, feature-incomplete and crash-prone. And this doesn't even include the software for controlling them. All that *really* matters is getting solid data.
I do not agree with your assessment that the software that's being used is highly specialized.
There is widely used off the shelf software for experiments. LabView is very common among scientists and engineers for controlling measurements. A lot of lab equipment has direct integration with LabView. Matlab is also used for this purpose on some occasions. Origin is a really good package for processing data recorded in an experiment. And if you have to calculate something that's a bit more complex you fire up Maple or Mathematica. Throw in the occasional odd control script or quick hack to get control over an interface and you've got a pretty typical working environment, based on software that's actually not that specialized. It's quite expensive, though. I am certain that a lot of scientists would go for cheaper alternative software packages, but there are none that come close enough to the commercial ones to replace them.
Excel is only usable for really basic processing of small datasets. Origin on the other hand is tailormade for scientific processing of huge datasets. There are loads of things that Excel cannot do, but are a breeze in Origin. Things that come to my mind here include FFT with a mouse click (not available in Excel at all), quick finding local maximums and minimums in a data set and similar operations, creation of advanced plots, powerful and robust curve fitting (although the user interface is absolutely terrible, the algorithms are more robust and stable than those in xmgrace and gnuplot) and most importantly the robust handling of really large data sets that Excel can't even load. So I don't understand why someone would recommend Excel when there are much, much better tools readily available.
Fortran is great - in some cases. Many physicists are stuck with a code base that started out in Fortran and has grown over years, sometimes even decades and contains such a huge amount of work that it just can't be thrown away reasonably. Ironically, this also means that manufacturers of high performance computers are required to provide reasonably well optimising Fortran compilers for their machines. This is what keeps that language alive. It's not actually a modern programming language, but it is kept alive because it was one of the first high level languages to be used widely for numerical computations.
Still, I'm glad that the simulation program that I'm working on as part of my thesis is written in C++.
I'm a physics student at the University of Bayreuth, Germany, working on my diploma thesis, and what follows is my perception of the situation at said university:
There are no strictly mandatory courses that teach programming. Even though, hearing a lecture on a programming language is recommended as is hearing a lecture on numerical computation which touches on numerical accuracy issues as well as basic numeric algorithms (interpolation, equation solving, splines...). Most students choose to follow that recommendation and end up hearing a lecture in C/C++ for the most part. Also, there is a lecture on computational physics, which introduces a wide set of useful tools for those that feel inclined to take that road. This lecture is purely optional and usually only attended by a couple of students.
I am not aware of any diploma thesis that was completed lately that did not include some basic scripting or programming by the author. Most topics require the students to do either considerable numerical computations (theoretical topics, mostly) or some heavy data processing, often in the form of image processing (experimental topics). Most students seem to be prepared well enough for these tasks by the time they start with the thesis work. I have never heard of any problems that arose because a topic required more elaborate programming skills than the student had or was able to develop during the thesis work (which lasts for a whole year).
Bottom line: the teachers here are quite aware that basic programming skills are necessary and although they do not force the students to acquire them, they still end up learning them.
Our setup was never designed for much more than simply on/off. We have no sensor feedback, either, so the controller can only act blindly. Also the system is pressurized only from a bottle of compressed air (a compressor would only add more weight). All in all this was designed to be small, lightweight, cheap and as simple as possible. Still, I think it works remarkably well.
We have been using one of these "muscle" actuators as a clutch actuator in our racing car for about half a year now. So the muscle itself is not a new product. So far we did not have any problems with it or any other component of the car's pneumatic system which were provided entirely by them. And I also have seen that hand demo months ago. However, I must admit that I am surprised at the precision with which these muscles are controlled in the demos. You cannot do that with a set of standard valves. We are using one intake and three outlet valves for different clutch release speeds and that's barely tuneable enough to get the job done for us (it's an on/off kind of thing with not quite reproducable timing).
I'm the main author of Moonlight|3D. Getting that program to where it is now is the result of many a long night of coding during the last couple of years. Some parts of that type of software really are hard to create. In that part you seem to have made the same experience. But I've also gained enough confidence in the basic design of that application (and learned many lessions from it, too) that I have a pretty good idea of what is possible. And I honestly believe that a project like K-3D can show a higher pace of development than Blender with equal manpower because the foundations are laid out properly.
This is not a plug for my project. I am fairly certain that my program is not the one that takes on Blender if that ever happens. I know that I have made my share of (incredibly stupid) mistakes and correcting them will take a considerable amount of time.
All the programs I tend to point out are usually built around a scene representation that is more than just a simple scene graph. There is some serious parametrization going on at some level. In Maya, for instance, every operation that goes beyond tweaking the positions of some mesh vertices is stored as a separate node in the graph with parameters that can be altered after the fact. This provides a base for lots and lots of features: it's easy to animate node parameters if that should be desired. Art of Illusion for instance allows those nodes to be user-defined scripts (maybe Maya allows that, too - I don't know). YOu can go back and change things you did earlier without rebuilding the entire object if you find out that you made a mistake (e.g. if a revolved or lofted shape doesn't quite look like you want).
If you know GEGL you could think of the design that I'm talking about as some sort of of 3D version of that approach. Every decent 3D modelling program that I've seen implements a variation of that, Blender being the big exception.
If done right, this design is incredibly versatile and modular. Implementing a proper user interface on top may be a bit tough, though.
This is to all those people who claim that you just have to learn to use Blenders user interface: My question really was initially not that much about the user interface, but the user interface really is at the core of the problem, but not in the way you probably expect.
The alternative applications that I have pointed out are really designed for a job. They adhere to basic MVC patterns and whatever else you would expect from such a big application. These patterns really are a big advantage when it comes down to coding stuff. Blender on the other hand has a "user interface driven design", as Ton once said. And this term fits well: the user interface - and I almost literally mean the buttons on screen and whatever event handling that is attached to it - are the only glue that keeps everything together. So when you talk about the user interface you also talk about Blender's internals. There is not much of an abstraction between the user interface and the data that is manipulated. So the bottom line is that any change to Blender's user interface is a change to Blender's design.
I don't think an aging codebase is a critical flaw. Too often people think redesigning the wheel is a panacea for repairing a kludgy system, without realizing that all code projects fall prey to this at some point in their life.
Well, I have two remarks for you here. First, what do you do when the current design stands in the way of a new feature you want to add? Second, a lot of applications have shown that there are proven designs for 3D modelling and 3D animation that can sustain growth into much bigger applications than blender. Why not use that knowledge?
Blender is a design that was never intended to grow into what it is now. Remember that it was an inhouse developement of an animation studio so the whole application was designed to get the job done that was at hand. But when the program itself was commercialized it started to outgrow itself. This was never anticipated and Blender still suffers from that. The other applications that I pointed out have a solid design which is able to grow. Commercial applications like Maya, Softimage and Houdini have demonstrated that. Comparing blender to all of those on a design level makes blender stand out as the toy.
No, but it touches on an aspect of Blender that I happend to be familiar with at the time: the crufty file loading and saving code. All that XML stuff would have helped to sanitize that part of the code. The basic idea behind Blender's file format is not bad, but with all the changes that were made to Blender's data structures the strong ties between the file format and data structures led to long lists of hacks that were introduced to keep the program compatible with older versions. I picked that example for two reasons: it's documented and easy to get into. Many other issues are only discussed in IRC so there is no real record of them.
Another problem is Blenders old user interface code. It dates back quite some time and it surely has been updated time and again. But because it is a library that does everything by itself on top of OpenGL and thin wrappers around the actual windowing system it did not get proper support for multiple screens yet although this has been called for some time now. User interface translations are a similar topic which has been tried time and again and still isn't fully accomplished. Back in the days when Blender ran on SGI workstations the decision for an own UI toolkit made sense. But times change.
Slashdot Mirror
But in most cases, Nautilus has already generated the thumbnails you require anyways.
Except when you don't use Nautilus at all (e.g. when using a GTK application in a KDE desktop).
That is, if you figure out how to clean up the mess - or what's left of it.
Your quibble with the pasted result not being a real layer is almost solved. GIMP can paste that data into a new layer straight away. Try "Paste as new layer". So this is an issue of what default behaviour is the best.
Taking the image size from the clipboard could be done, but I doubt that it would be useful.I sometimes find myself in workflows where I create a lot of images with the same resolution, so I'm glad that GIMP remembers the last one when I reopen the dialog. It would be annoying as hell if there happens to be image data in the clipboard (which I can't do squat about when creating a new image - the clipboard contents just is) and this overrides the cached values. And cluttering up the dialog with a "Take size from clipboard" button might not be worth it, either.
Still, I agree that simple tweaks can enhance a user interface a lot.
We are participating in one of ESA's scientific parbolic flight campaigns and I therefore had the chance to get some insight about the costs involved. The participation fee alone is about 60.000 Euros and more than twice the costs we had for building the experiments. For this we get 90 parabolas with 20 seconds of microgravity for experimenting.
Assuming that the cost structure for NASA's campaign participants is similar, NASA's offer to let these teams participate for free seems to be quite generous. Is there anyone here with more details?
Well, the average scientific experiment really is buggy, feature-incomplete and crash-prone. And this doesn't even include the software for controlling them. All that *really* matters is getting solid data.
I do not agree with your assessment that the software that's being used is highly specialized.
There is widely used off the shelf software for experiments. LabView is very common among scientists and engineers for controlling measurements. A lot of lab equipment has direct integration with LabView. Matlab is also used for this purpose on some occasions. Origin is a really good package for processing data recorded in an experiment. And if you have to calculate something that's a bit more complex you fire up Maple or Mathematica. Throw in the occasional odd control script or quick hack to get control over an interface and you've got a pretty typical working environment, based on software that's actually not that specialized. It's quite expensive, though. I am certain that a lot of scientists would go for cheaper alternative software packages, but there are none that come close enough to the commercial ones to replace them.
Excel is only usable for really basic processing of small datasets. Origin on the other hand is tailormade for scientific processing of huge datasets. There are loads of things that Excel cannot do, but are a breeze in Origin. Things that come to my mind here include FFT with a mouse click (not available in Excel at all), quick finding local maximums and minimums in a data set and similar operations, creation of advanced plots, powerful and robust curve fitting (although the user interface is absolutely terrible, the algorithms are more robust and stable than those in xmgrace and gnuplot) and most importantly the robust handling of really large data sets that Excel can't even load. So I don't understand why someone would recommend Excel when there are much, much better tools readily available.
Still, I'm glad that the simulation program that I'm working on as part of my thesis is written in C++.
There are no strictly mandatory courses that teach programming. Even though, hearing a lecture on a programming language is recommended as is hearing a lecture on numerical computation which touches on numerical accuracy issues as well as basic numeric algorithms (interpolation, equation solving, splines...). Most students choose to follow that recommendation and end up hearing a lecture in C/C++ for the most part. Also, there is a lecture on computational physics, which introduces a wide set of useful tools for those that feel inclined to take that road. This lecture is purely optional and usually only attended by a couple of students.
I am not aware of any diploma thesis that was completed lately that did not include some basic scripting or programming by the author. Most topics require the students to do either considerable numerical computations (theoretical topics, mostly) or some heavy data processing, often in the form of image processing (experimental topics). Most students seem to be prepared well enough for these tasks by the time they start with the thesis work. I have never heard of any problems that arose because a topic required more elaborate programming skills than the student had or was able to develop during the thesis work (which lasts for a whole year).
Bottom line: the teachers here are quite aware that basic programming skills are necessary and although they do not force the students to acquire them, they still end up learning them.
Our setup was never designed for much more than simply on/off. We have no sensor feedback, either, so the controller can only act blindly. Also the system is pressurized only from a bottle of compressed air (a compressor would only add more weight). All in all this was designed to be small, lightweight, cheap and as simple as possible. Still, I think it works remarkably well.
We have been using one of these "muscle" actuators as a clutch actuator in our racing car for about half a year now. So the muscle itself is not a new product. So far we did not have any problems with it or any other component of the car's pneumatic system which were provided entirely by them. And I also have seen that hand demo months ago. However, I must admit that I am surprised at the precision with which these muscles are controlled in the demos. You cannot do that with a set of standard valves. We are using one intake and three outlet valves for different clutch release speeds and that's barely tuneable enough to get the job done for us (it's an on/off kind of thing with not quite reproducable timing).
I'm the main author of Moonlight|3D. Getting that program to where it is now is the result of many a long night of coding during the last couple of years. Some parts of that type of software really are hard to create. In that part you seem to have made the same experience. But I've also gained enough confidence in the basic design of that application (and learned many lessions from it, too) that I have a pretty good idea of what is possible. And I honestly believe that a project like K-3D can show a higher pace of development than Blender with equal manpower because the foundations are laid out properly. This is not a plug for my project. I am fairly certain that my program is not the one that takes on Blender if that ever happens. I know that I have made my share of (incredibly stupid) mistakes and correcting them will take a considerable amount of time.
All the programs I tend to point out are usually built around a scene representation that is more than just a simple scene graph. There is some serious parametrization going on at some level. In Maya, for instance, every operation that goes beyond tweaking the positions of some mesh vertices is stored as a separate node in the graph with parameters that can be altered after the fact. This provides a base for lots and lots of features: it's easy to animate node parameters if that should be desired. Art of Illusion for instance allows those nodes to be user-defined scripts (maybe Maya allows that, too - I don't know). YOu can go back and change things you did earlier without rebuilding the entire object if you find out that you made a mistake (e.g. if a revolved or lofted shape doesn't quite look like you want). If you know GEGL you could think of the design that I'm talking about as some sort of of 3D version of that approach. Every decent 3D modelling program that I've seen implements a variation of that, Blender being the big exception. If done right, this design is incredibly versatile and modular. Implementing a proper user interface on top may be a bit tough, though.
This is to all those people who claim that you just have to learn to use Blenders user interface: My question really was initially not that much about the user interface, but the user interface really is at the core of the problem, but not in the way you probably expect.
The alternative applications that I have pointed out are really designed for a job. They adhere to basic MVC patterns and whatever else you would expect from such a big application. These patterns really are a big advantage when it comes down to coding stuff. Blender on the other hand has a "user interface driven design", as Ton once said. And this term fits well: the user interface - and I almost literally mean the buttons on screen and whatever event handling that is attached to it - are the only glue that keeps everything together. So when you talk about the user interface you also talk about Blender's internals. There is not much of an abstraction between the user interface and the data that is manipulated. So the bottom line is that any change to Blender's user interface is a change to Blender's design.
I don't think an aging codebase is a critical flaw. Too often people think redesigning the wheel is a panacea for repairing a kludgy system, without realizing that all code projects fall prey to this at some point in their life.
Well, I have two remarks for you here. First, what do you do when the current design stands in the way of a new feature you want to add? Second, a lot of applications have shown that there are proven designs for 3D modelling and 3D animation that can sustain growth into much bigger applications than blender. Why not use that knowledge?Blender is a design that was never intended to grow into what it is now. Remember that it was an inhouse developement of an animation studio so the whole application was designed to get the job done that was at hand. But when the program itself was commercialized it started to outgrow itself. This was never anticipated and Blender still suffers from that. The other applications that I pointed out have a solid design which is able to grow. Commercial applications like Maya, Softimage and Houdini have demonstrated that. Comparing blender to all of those on a design level makes blender stand out as the toy.
No, but it touches on an aspect of Blender that I happend to be familiar with at the time: the crufty file loading and saving code. All that XML stuff would have helped to sanitize that part of the code. The basic idea behind Blender's file format is not bad, but with all the changes that were made to Blender's data structures the strong ties between the file format and data structures led to long lists of hacks that were introduced to keep the program compatible with older versions. I picked that example for two reasons: it's documented and easy to get into. Many other issues are only discussed in IRC so there is no real record of them.
Another problem is Blenders old user interface code. It dates back quite some time and it surely has been updated time and again. But because it is a library that does everything by itself on top of OpenGL and thin wrappers around the actual windowing system it did not get proper support for multiple screens yet although this has been called for some time now. User interface translations are a similar topic which has been tried time and again and still isn't fully accomplished. Back in the days when Blender ran on SGI workstations the decision for an own UI toolkit made sense. But times change.