Here's a simple trick to get a more compact GIMP user interface: Uncomment the following line in your ~/.gimp-1.3/gtkrc:
# class "GtkWidget" style "gimp-small-style"
Re:I don't mean to gripe but....
on
GIMP goes SVG
·
· Score: 1
A bug being classified as duplicate doesn't mean it's unimportant or not useful. The classification as duplicate is used to keep the discussion concentrated on a single report. Every duplicate of course raises it's weight.
The need for adjustment layers is well understood by the GIMP developers. Any help on implementing this feature would be greatly appreciated. May it be code or any help designing and/or documenting the user interface.
Another easy way to draw a straight line is to use the path tool then stroke the path. This even gives you more control over the line style as if you'd use the paintbrush.
Re:What does this mean for Sodipodi?
on
GIMP goes SVG
·
· Score: 2, Interesting
Raphael, your last paragraph completely missed the point (while you are perfectly right in the first two). The SVG import plug-in that used to live in librsvg can only render SVG to a bitmap. This is sort of nice but it is indeed not worth mentioning. The significant difference is the fact the GIMP core can now import paths from SVG files. This functionality is not provided by the plug-in. It's just a nice add-on that the user interface for path import was also added to the SVG import plug-in.
Re:Am I missing something? GIMP sucks - for me
on
GIMP goes SVG
·
· Score: 1
What keeps you from installing a Pantone palette in The GIMP? It's just a matter of buying one from Pantone and putting it into your ~/.gimp-1.x/palettes folder.
What? Pantone doesn't sell you one? Perhaps it's time to ask them for it then. I am pretty sure they would do if people started to ask for it.
Re:isn't it best to keep
on
GIMP goes SVG
·
· Score: 1
Perhaps. But you also need a way to exchange data between the raster manipulation program (GIMP) and the vector manipulation program (Sodipodi?). That's when it becomes important that your raster app can import/export vectors and that your vectors app can import/export raster graphics.
This is simply not true; there is no dependency on Xft whatsoever. GIMP depends on fontconfig but that's just a library to manage fonts and it doesn't need Xft (although the two used to be distributed together).
What your script does is something completely different from the SVG import/export for GIMP paths that has been added now. If I understand your script correctly, it abuses SVG paths to create a SVG representation of raster graphics. This is a neat trick, but is it useful?
It should be trivial to port XSane to the GTK+-2.x and GIMP-2.0 APIs. Sooner or later someone will do it.
Re:I just want 1.4stable...
on
GIMP goes SVG
·
· Score: 2, Informative
GIMP-1.3 is actually a lot less messy and even considered to be more stable than the 1.2 releases. If it crashed on you, you should have tried to obtain a stack trace and file a bug-report then at bugzilla.gnome.org. If you don't do that, the GIMP developers have no chance to fix the bug that hit you.
BTW, the next version will be called 2.0, not 1.4.
The text tool has a button that allows you to create paths from a text layer. Text transformations (scale, rotate, shear,...) is being worked on and should make it into 2.0.
Re:DirectFB and non-english letters
on
Qt On DirectFB
·
· Score: 1
It uses the kernel console keymap and all DirectFB internals are based on Unicode.
Re:Before all the flamers get in.
on
Qt On DirectFB
·
· Score: 1
DirectFB has been ported to flavours of BSD already; it should compile on your NetBSD system. What is lacking is a port to the BSD framebuffer device (is there such a beast at all?). Currently you can only use the SDL backend. This doesn't give you all the niceties of hardware accelerated graphics that a decent Linux frame-buffer driver can offer now but it is a nice framework to start to develop such a driver for BSD.
Re:Before all the flamers get in.
on
Qt On DirectFB
·
· Score: 1
DirectFB windows can have a real alpha channel. In addition every DirectFB window has an adjustable overall opacity.
Re:Before all the flamers get in.
on
Qt On DirectFB
·
· Score: 1
Of course you can run remote apps on XDirectFB as well. After all it's just an X server.
Re:DirectFB Inherently Insecure?
on
Qt On DirectFB
·
· Score: 1
Only the first DirectFB application started accesses the hardware directly. Using the multi-application core you can have a very simple DirectFB app running as the master and all other DirectFB apps don't need root access. This is similar to your X server running as root. The difference is that the DirectFB app is only three lines of code (on top of the DirectFB library that you need to trust here).
The article doesn't mention much about the technical details and does not even tell us which version of GTK+ this port is based on. Unfortunately it seems to be a port of the older GTK+ version 1.2. This is a surprising at first glance since the 2.0 version of GTK+ is much better prepared for different rendering backends (and comes with GDK versions for Win32, linux-fb and DirectFB). Since this port is closely related to FilmGimp, which is unfortunately still dealing with the outdated 1.2 version, this choice becomes clear. Hopefully this project will soon lead to a GTK+-2.x port or Mac users will have to deal with outdated and mostly unmaintained GTK+ applications.
DirectFB has support for multiple applications running at the same time. This has been around for quite some time now but was considered experimental. Lately the IPC layer (dubbed Fusion) was changed from SysV IPC to a kernel space implementation. This gave a huge improvement on speed and stability and I'm now using it all the time. Check this screenshot showing The GIMP and a plug-in (GIMP plug-ins are separate processes) running on the same DirectFB desktop.
Convergence Integrated Media is dead, long live Convergence;-) The company changed its name but we are still there and we are still into Open Source as you can see at www.linuxtv.org and www.directfb.org.
Actually the result of hinting depends on two things. First, the font needs to be hinted well. Unfortunately only very few fonts are well-hinted. For those that aren't it makes indeed sense to turn hinting off entirely. Second, your font renderer needs to support the hinting information embedded into the font.
TrueType fonts have bytecode with hinting information that can be interpreted by the renderer. This is what freetype-2.0 did up to version 2.0.1. Due to patent issues this feature was turned off by default in version 2.0.2. All newer versions of freetype use something what they call autohinter. While this gives better results for badly hinted or unhinted fonts, it does not (yet) achieve the excellent results you get from using the hints embedded in well-hinted fonts.
The solution is thus not to disable hinting but to enable the bytecode interpreter in your freetype2 libs. Of course you also need some decent fonts.
Jim and Keith do a good job and this is an interesting quote (that I have of course read before), but I think the/. readers should have some more numbers to compare. The DirectFB library has less than 140 KB of code size. Depending on the usage, a few modules will be loaded for input devices, the gfx card's hardware acceleration, image and font loading, but DirectFB's codesize will normally not extend 200kB while the X developers are trying hard to get close to the 1MB limit.
Of course this doesn't matter much for the desktop, but it does matter if you are developing for the embedded market where the costs for RAM and CPU decide if a product has a chance on the market.Another problem with X we faced is that certain features like true alpha channel and color keying are simply not available. These are absolutely needed when developing software for digital TV. DirectFB not only replaces X for us, it gives us a whole lot more X can not (yet) do. It was meant as a replacement for X on settop boxes, not primarily as a replacement for X on your desktop.
You are thinking of something completely different. The default airbrush is still there. What I was talking about was a new airbrush tool Olof came up with that emulates a real airbrush more closely when used with a pressure/tilt sensitive tablet.
Slashdot Mirror
Here's a simple trick to get a more compact GIMP user interface: Uncomment the following line in your ~/.gimp-1.3/gtkrc:
# class "GtkWidget" style "gimp-small-style"
A bug being classified as duplicate doesn't mean it's unimportant or not useful. The classification as duplicate is used to keep the discussion concentrated on a single report. Every duplicate of course raises it's weight.
The need for adjustment layers is well understood by the GIMP developers. Any help on implementing this feature would be greatly appreciated. May it be code or any help designing and/or documenting the user interface.
Another easy way to draw a straight line is to use the path tool then stroke the path. This even gives you more control over the line style as if you'd use the paintbrush.
Raphael, your last paragraph completely missed the point (while you are perfectly right in the first two). The SVG import plug-in that used to live in librsvg can only render SVG to a bitmap. This is sort of nice but it is indeed not worth mentioning. The significant difference is the fact the GIMP core can now import paths from SVG files. This functionality is not provided by the plug-in. It's just a nice add-on that the user interface for path import was also added to the SVG import plug-in.
What keeps you from installing a Pantone palette in The GIMP? It's just a matter of buying one from Pantone and putting it into your ~/.gimp-1.x/palettes folder.
What? Pantone doesn't sell you one? Perhaps it's time to ask them for it then. I am pretty sure they would do if people started to ask for it.
Perhaps. But you also need a way to exchange data between the raster manipulation program (GIMP) and the vector manipulation program (Sodipodi?). That's when it becomes important that your raster app can import/export vectors and that your vectors app can import/export raster graphics.
This is simply not true; there is no dependency on Xft whatsoever. GIMP depends on fontconfig but that's just a library to manage fonts and it doesn't need Xft (although the two used to be distributed together).
What your script does is something completely different from the SVG import/export for GIMP paths that has been added now. If I understand your script correctly, it abuses SVG paths to create a SVG representation of raster graphics. This is a neat trick, but is it useful?
It should be trivial to port XSane to the GTK+-2.x and GIMP-2.0 APIs. Sooner or later someone will do it.
GIMP-1.3 is actually a lot less messy and even considered to be more stable than the 1.2 releases.
If it crashed on you, you should have tried to obtain a stack trace and file a bug-report then at bugzilla.gnome.org. If you don't do that, the GIMP developers have no chance to fix the bug that hit you.
BTW, the next version will be called 2.0, not 1.4.
It is written in the original article and there's even a link that you could click on. Try this one instead: Scalable Vector Graphics.
The text tool has a button that allows you to create paths from a text layer. Text transformations (scale, rotate, shear, ...) is being worked on and should make it into 2.0.
It uses the kernel console keymap and all DirectFB internals are based on Unicode.
DirectFB has been ported to flavours of BSD already; it should compile on your NetBSD system. What is lacking is a port to the BSD framebuffer device (is there such a beast at all?). Currently you can only use the SDL backend. This doesn't give you all the niceties of hardware accelerated graphics that a decent Linux frame-buffer driver can offer now but it is a nice framework to start to develop such a driver for BSD.
DirectFB windows can have a real alpha channel. In addition every DirectFB window has an adjustable overall opacity.
Of course you can run remote apps on XDirectFB as well. After all it's just an X server.
Only the first DirectFB application started accesses the hardware directly. Using the multi-application core you can have a very simple DirectFB app running as the master and all other DirectFB apps don't need root access. This is similar to your X server running as root. The difference is that the DirectFB app is only three lines of code (on top of the DirectFB library that you need to trust here).
The article doesn't mention much about the technical details and does not even tell us which version of GTK+ this port is based on. Unfortunately it seems to be a port of the older GTK+ version 1.2. This is a surprising at first glance since the 2.0 version of GTK+ is much better prepared for different rendering backends (and comes with GDK versions for Win32, linux-fb and DirectFB). Since this port is closely related to FilmGimp, which is unfortunately still dealing with the outdated 1.2 version, this choice becomes clear. Hopefully this project will soon lead to a GTK+-2.x port or Mac users will have to deal with outdated and mostly unmaintained GTK+ applications.
DirectFB has support for multiple applications running at the same time. This has been around for quite some time now but was considered experimental. Lately the IPC layer (dubbed Fusion) was changed from SysV IPC to a kernel space implementation. This gave a huge improvement on speed and stability and I'm now using it all the time. Check this screenshot showing The GIMP and a plug-in (GIMP plug-ins are separate processes) running on the same DirectFB desktop.
DirectFB has support for OpenGL for quite some time now. Check out this page.
Convergence Integrated Media is dead, long live Convergence ;-) The company changed its name but we are still there and we are still into Open Source as you can see at www.linuxtv.org and www.directfb.org.
Actually the result of hinting depends on two things. First, the font needs to be hinted well. Unfortunately only very few fonts are well-hinted. For those that aren't it makes indeed sense to turn hinting off entirely. Second, your font renderer needs to support the hinting information embedded into the font.
TrueType fonts have bytecode with hinting information that can be interpreted by the renderer. This is what freetype-2.0 did up to version 2.0.1. Due to patent issues this feature was turned off by default in version 2.0.2. All newer versions of freetype use something what they call autohinter. While this gives better results for badly hinted or unhinted fonts, it does not (yet) achieve the excellent results you get from using the hints embedded in well-hinted fonts.
The solution is thus not to disable hinting but to enable the bytecode interpreter in your freetype2 libs. Of course you also need some decent fonts.
Jim and Keith do a good job and this is an interesting quote (that I have of course read before), but I think the /. readers should have some more numbers to compare. The DirectFB library has less than 140 KB of code size. Depending on the usage, a few modules will be loaded for input devices, the gfx card's hardware acceleration, image and font loading, but DirectFB's codesize will normally not extend 200kB while the X developers are trying hard to get close to the 1MB limit.
Of course this doesn't matter much for the desktop, but it does matter if you are developing for the embedded market where the costs for RAM and CPU decide if a product has a chance on the market.Another problem with X we faced is that certain features like true alpha channel and color keying are simply not available. These are absolutely needed when developing software for digital TV. DirectFB not only replaces X for us, it gives us a whole lot more X can not (yet) do. It was meant as a replacement for X on settop boxes, not primarily as a replacement for X on your desktop.
You are thinking of something completely different. The default airbrush is still there. What I was talking about was a new airbrush tool Olof came up with that emulates a real airbrush more closely when used with a pressure/tilt sensitive tablet.
This feature has been around in The GIMP for ages.