Re:Any chance we can draw circles and boxes now
on
GIMP 2.6 Released
·
· Score: 1
Why are you listening to him? He is a random person on the internet.
The train of thought rather usually goes like this: "It is already doable but rather awkward to use. I don't need this feature very often though, and I have more interesting/important things to work on."
The GIMP developers would of course not reject a patch that implemented this in a nice way.
The GIMP developers are completely aware of the UI problems GIMP has, and GIMP 2.6 will be the first version where there will be obvious UI improvements.
No GIMP 2.6 will not have support for more than 8 bits per channel since that is a huge project. The transition to more than 8 bits per channel will happen incrementally. The important change in 2.6 with regards to this is elementary integration of GEGL, but that's about it. Good support for more than 8 bits per channel will probably take several years of work.
This problem doesn't exist in GIMP 2.5 if you use a window manager with descent support for window hints.
The default setup in GIMP 2.5 is to have the toolbox and dialogs/docks with a Utility window-hint and this causes for example Metacity to not show them in the task bar (i.e. the taskbar is not cluttered by GIMP windows). If you bring up an image the toolbox and dialogs/docks will be brought up as well.
GIMP has since long offered the Utility window-hint but it was not useful until now when there is a window that hosts the menu while no images are opened.
Well GIMP development is far from stalled; the next version will be an important milestone.
It will have a non-optional GEGL dependency (although from a user point of view the GEGL integration will not be very visible yet) and the first major UI change will take place (removing the menu from the toolbox and merge it with the image window menu, and keep a special variant of an image window up to hold this menu when there are no images opened). This work has already been done and you can try it out in SVN trunk.
The GIMP developers are fully aware of the shortcomings of GIMP, and the plan for the UI is pretty clear. The bottleneck is lack of developer resources. Putting the Mozilla UI people on GIMP team would not make the "delivery" of GIMP with an awesome UI happen faster. (Unless these UI people also would contribute a considerable amount of code.)
The process of building the new engine went much more smoothly than anything we have done before, because I was able to do all the groundwork while the rest of the company worked on TeamArena. By the time they were ready to work on it, things were basically functional. I did most of the early development work with a gutted version of Quake 3, which let me write a brand new renderer without having to rewrite file access code, console code, and all the other subsystems that make up a game. After the renderer was functional and the other programmers came off of TA and Wolf, the rest of the codebase got rewritten. Especially after our move to C++, there is very little code remaining from the Q3 codebase at this point.
Historically, compilers for many languages, including C++ and Fortran, have been implemented as "preprocessors" which emit another high level language such as C. None of the compilers included in GCC are implemented this way; they all generate machine code directly. This sort of preprocessor should not be confused with the C preprocessor, which is an integral feature of the C, C++, Objective-C and Objective-C++ languages.
Indeed, and besides, they are not explaining it to lawyers, so it does not really need to be juridically accurate as long as their explanation captures the basic spirit of the GPL, which it did.
I really don't see DRM as a threat in the long term. The reason is that I think the market will simply not tolerate DRM. Once people begin to realize that DRM sucks, they will begin to avoid DRM content and hardware, forcing the manufacturers to abandon DRM as well. DRM will extinct itsef.
As a hobbyist game programmer, I immediately began to think about what games you could write for the keyboard itself. My general idea is that you could make all the keys act as one big (low-res) screen.
You could have a Whack-a-Mole type game, where a mole would display on the keys and you'd have to whack him by pressing one of the keys the mole occupies.
Or you could make a Snake clone where you would maneuver the snake by tapping on the direction the snake would go.
The core of the.NET Framework, and what has been patented by Microsoft falls under the ECMA/ISO submission. Jim Miller at Microsoft has made a statement on the patents covering ISO/ECMA, (he is one of the inventors listed in the patent). [...] Basically a grant is given to anyone who want to implement those components for free and for any purpose.
The risky part is the implementations of ASP.NET, ADO.NET and Windows.Forms.
For people who need full compatibility with the Windows platform, Mono's strategy for dealing with any potential issues that might arise with ASP.NET, ADO.NET or Windows.Forms is: (1) work around the patent by using a different implementation technique that retains the API, but changes the mechanism; if that is not possible, we would (2) remove the pieces of code that were covered by those patents, and also (3) find prior art that would render the patent useless.
As long as we use for example Gtk# instead of Windows.Forms, there should be no problems.
I agree with Linera Algebra, if you know linear algebra, you can pick up on 3D rendering APIs easily, and making 3D games is great fun, and you learn a lot about programming in general, like the need to structure your code (source code of 3D games without good structure is hell to modify).
Also, a lot of geometrical problems can be solved using Linear Algebra, things that can be useful in GUI code for instance (like, which of these arbitrary line segments are closest to the cursor, what angle does these lines form, etc etc).
Slashdot Mirror
Why are you listening to him? He is a random person on the internet.
The train of thought rather usually goes like this: "It is already doable but rather awkward to use. I don't need this feature very often though, and I have more interesting/important things to work on."
The GIMP developers would of course not reject a patch that implemented this in a nice way.
The GIMP developers are completely aware of the UI problems GIMP has, and GIMP 2.6 will be the first version where there will be obvious UI improvements.
Download GIMP 2.5.3 and see for yourself.
The extremely long development cycle of GIMP 2.4 was not intentional and is something the developers wants to avoid for GIMP 2.6.
No GIMP 2.6 will not have support for more than 8 bits per channel since that is a huge project. The transition to more than 8 bits per channel will happen incrementally. The important change in 2.6 with regards to this is elementary integration of GEGL, but that's about it. Good support for more than 8 bits per channel will probably take several years of work.
This problem doesn't exist in GIMP 2.5 if you use a window manager with descent support for window hints.
The default setup in GIMP 2.5 is to have the toolbox and dialogs/docks with a Utility window-hint and this causes for example Metacity to not show them in the task bar (i.e. the taskbar is not cluttered by GIMP windows). If you bring up an image the toolbox and dialogs/docks will be brought up as well.
GIMP has since long offered the Utility window-hint but it was not useful until now when there is a window that hosts the menu while no images are opened.
Well GIMP development is far from stalled; the next version will be an important milestone.
It will have a non-optional GEGL dependency (although from a user point of view the GEGL integration will not be very visible yet) and the first major UI change will take place (removing the menu from the toolbox and merge it with the image window menu, and keep a special variant of an image window up to hold this menu when there are no images opened). This work has already been done and you can try it out in SVN trunk.
The GIMP developers are fully aware of the shortcomings of GIMP, and the plan for the UI is pretty clear. The bottleneck is lack of developer resources. Putting the Mozilla UI people on GIMP team would not make the "delivery" of GIMP with an awesome UI happen faster. (Unless these UI people also would contribute a considerable amount of code.)
That's only true for some keyboard layouts. The Swedish keyboard layout for example does not require modifiers for + and -.
That is fixed in GIMP 2.4 which btw is out pretty soon. GIMP 2.4 rc2 has been released since a while.
You are wrong about 3):
Source: http://archive.gamespy.com/e32002/pc/carmack/
And 4) as well:
Source: http://gcc.gnu.org/onlinedocs/gcc-4.2.1/gcc/G_002b _002b-and-GCC.html
Indeed, and besides, they are not explaining it to lawyers, so it does not really need to be juridically accurate as long as their explanation captures the basic spirit of the GPL, which it did.
`Can't` as in `are unable to`
"So, who's right -- Hawking or Stross?"
They are not saying opposite things, one is saying that we can't colonize other solar systems, the other that we must. They are probably both true.
Why install any kde libs by yourself first? Just 'sudo apt-get install kopete' is all you need, it downloads any dependencies automatically.
Good to hear :)
I wonder what mushrooms he were on when he came up with that coding style... (yes, this is the actual indentation he used):
Void change_score(short num_points)
{
if (num_points < 0)
{
// maybe some error message
return;
}
score += num_points;
if (num_points > 0)
make_sparkles_on_score();
}
If I don't get to code I get bored. What's the news?
I'm on a stable 10 Mbit up/10 Mbit down line for $7.23 per month.
:)
Downloads are usually quickly around 800-900 KB/s, and popular torrents come to me with 1200 KB/s, apt-get:ing goes in 700 KB/s.
I'm in Sweden
For the lazy ones:
.tar.gz with the patches:s /attachments/20070216/d6c4ac6a/attachment-0001.bin
This is a
http://lists.osdl.org/pipermail/desktop_architect
I really don't see DRM as a threat in the long term. The reason is that I think the market will simply not tolerate DRM. Once people begin to realize that DRM sucks, they will begin to avoid DRM content and hardware, forcing the manufacturers to abandon DRM as well. DRM will extinct itsef.
If you define "same ground" as "same name and same concept" then yeah.
But the differences between those titles are quite major if you see to the differences in features.
As a hobbyist game programmer, I immediately began to think about what games you could write for the keyboard itself. My general idea is that you could make all the keys act as one big (low-res) screen.
You could have a Whack-a-Mole type game, where a mole would display on the keys and you'd have to whack him by pressing one of the keys the mole occupies.
Or you could make a Snake clone where you would maneuver the snake by tapping on the direction the snake would go.
Or some kind of piano game, á la Guitar Hero.
You would be right if Java/JVM and C#/.NET were the same thing, but they are not, which makes Mono valuable anyway.
You can read about this at this Mono page
Summary:
The Mono/C# implementation itself is safe.
The risky part is the implementations of ASP.NET, ADO.NET and Windows.Forms.
As long as we use for example Gtk# instead of Windows.Forms, there should be no problems.
I agree with Linera Algebra, if you know linear algebra, you can pick up on 3D rendering APIs easily, and making 3D games is great fun, and you learn a lot about programming in general, like the need to structure your code (source code of 3D games without good structure is hell to modify).
Also, a lot of geometrical problems can be solved using Linear Algebra, things that can be useful in GUI code for instance (like, which of these arbitrary line segments are closest to the cursor, what angle does these lines form, etc etc).