|
Kernel Traffic Latest | Archives | People | Topics |
Wine Latest | Archives | People | Topics |
GNUe Latest | Archives | People | Topics |
| Czech |
| Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic |
Table Of Contents
| 1. | KDE Version of the Gimp? | ||
| 2. | Active Image/Display | ||
| 3. | Gimp as a library | ||
| 4. | Brush from an Image | ||
| 5. | <Image>/Layers/Stack | ||
| 6. | Gimp 1.1.6 |
Introduction
This is the initial issue of the Kernel Cousin Gimp. This first issue I'm actually covering threads from two weeks ago, because I feel they're important and worth reporting.
If anyone has a logo, or wants to harass me for missing a really important thread, please email me.
Mailing List Stats For This Week
We looked at 260 posts in 796K.
There were 59 different contributors. 31 posted more than once. 16 posted last week too.
The top posters of the week were:
1. KDE Version of the Gimp?
Archive Link: "[gimp-devel] Here we go again with KDE"
People: Tuomas Kuosmanen, Shawn T. Amundson,
There was some discussion recently on the kde-devel mailling list about creating a KDE image manipulation program on the same level as the Gimp.
One of the major complaints from the KDE folks is that the user interface to the Gimp is ``crappy''. This got a response from Tuomas Kuosmanen (aka tigert) who said "I just want to say that I like the current interface a LOT. And those who dont know me so well, I use Gimp for several hours almost daily."
On the matter of UI Shawn T. Amundson replied "The GIMP user-interface is far from perfect. I agree with Matthias that most the GIMP developers seem off in their own little world when they do UI decisions."
Others agreed that the current interface is far from perfect. And there was a lot of talk of fixing the main UI concern (several level nested menus) using a global button bar, or tear-off menus, to simplify the UI and using a current active image method for finding the image to act upon.
On the issue of a KDE version of the Gimp, most of the developers talked about seperating the UI from the core, but this would be a truly time consuming task, and they would probably need help from the KDE developers.
2. Active Image/Display
Archive Link: "[gimp-devel] Active_image patch!!!! ;-)"
People: Simon Budig, Michael Natterer,
Simon Budig wrote to the list:
I put together a first patch for the active_image concept. I implemented the addition to GimpSet to handle the active_changed signal (in gimpset.h was a comment about a signal "member_modified". I removed it, since this was the only place, where it appeared), changed some callbacks to change the active image when the user clicks the mouse or presses a key in the painting area (is there a way to get the events of the whole window?). The layers & channels dialog has a "Auto" Button, which makes him respect the active Image.
Since I had these automake Problems, this is a patch against Gimp-1.1.5. It patches smoothly in CVS from about 17.00 today. I hope it works in CVS too, but had no chance to test it.
Please tell me, if there are some problems. I probably will change the structure of this patch, to introduce gimp-intern functions gimp_set_active_image() and gimp_get_active_image() so that the callbacks do not have to fiddle around with gimp_set_set_active(...).
Also a PDB call gimp_get_active_image() will get implemented.
Please tell me, if it works for you and if it is useful.
This was welcomed after the KDE/UI problems thread (see above). Michael Natterer said that "Thanks, the patch looks like The Right Thing (TM) to do. I think I'll apply it tonight."
The development of the active image led to other ideas including creating custom toolbars, and tear-off menus to improve the interface, and to help power users more.
3. Gimp as a library
Archive Link: "[gimp-devel] gimp as library"
People: Marc Lehmann,
Andrey Zmievski asked if it was possible to build the Gimp as a library so a program can link in the Gimp and use it's image manipulation functionality.
Marc Lehmann replied:
No, this is somewhat planned, but it is a long-term goal.
The best that you can currently get away with is starting it in the background and control it via the script-fu-server (very very unsafe) or the Perl-Server.
4. Brush from an Image
Archive Link: "[gimp-devel] Brush from image, like DPaint?"
People: Chris Evans, Tuomas Kuosmanen,
Chris Evans asked, "Did the new brush enhancements in 1.1.5, 1.1.6 etc. include the ability to grab an arbitrary area of the image, and use it is a brush? Like Dpaint did on the good old Amiga?"
Tuomas Kuosmanen reponded that:
This has been around for a while. <Image> -> Script-Fu -> Selection -> To Brush
But gimp doesnt support color brushes yet, so it gets saved as grayscale. It basically takes the selection and saves it onto your ~/.gimp-1.1/brushes/
This is actually a feature in the 1.0.x series of the Gimp, but is buried in the menu structure. Once again the issue of the UI came up.
5. <Image>/Layers/Stack
Archive Link: "[gimp-devel] <Image>/Layers/Stack - Hack"
People: , Michael Natterer
Michael Natterer added image menu items under /Layers/Stack to allow keybindings to be associated with moving layers up and down, and also to navigate between layers.
This thrilled Tigert who quickly started using the new feature. He quickly found that the new hack broke the existing Ctrl-T keybinding that toggles the visibility of layer borders and selections. This caused a bit of head scratching as Michael had no idea how he broke the Ctrl-T keybinding. A solution was found though and fixed in the CVS. Afterward a threadlet was started about improving the keybindings.
6. Gimp 1.1.6
Archive Link: "[gimp-devel] ANNOUNCE: GIMP 1.1.6"
People: Manish Singh, , David Monniaux
A new development version of the Gimp was released. In the words of Manish Singh:
What's new?
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0. |