[Gimp-developer] an idea for the screenshot plug-in
Hi, I can think of a nice addition to the screenshot plug-in that someone might want to try to implement. We could then perhaps include this for 2.6. The point of this idea is that it introduces a feature that is unique and cannot be done (easily) in the desktop environment's screenshot utility. Compositing window managers are becoming popular and GTK+ 2.10 even allows us to find out if the current screen is composited (gdk_screen_is_composited ()). On a composited screen it should be possible to traverse the window hierarchy and take screenshots of all visible windows. The screenshot plug-in could do that, create a layer for each screenshot and place it at the right offset. The result would be an image that looks like a screenshot of the whole screen. But it would have separate layers for each window (including popup menus). This would allow you to rearrange the screenshot later (hiding some windows for examples). This might be a nice idea for a Super Screenshot plug-in or just as a patch that we can include after the 2.4 release. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] changes in script-fu in 2.3.14
Hi, On Tue, 2007-01-30 at 12:53 -0800, Akkana Peck wrote: If someone can make a quick comprehensive list, I'd be happy to help with getting it into a more readable form, if that's the issue. I don't know enough about the changes to make the list myself: I know what I've done to convert a few small scripts, but we need someone with more general knowledge than that. Kevin should be able to answer all your questions on this. He is probably the only one who knows about all the changes in detail. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Saving black/white TIFF with 'CCITT Group 4' encoding
Hi, On Thu, 2007-01-25 at 16:16 +0100, Manfred Joerg wrote: I think that I fixed bug 162119. My patch allows the user to save TIFF images with CCITT Group 4. The advantage of this file format is that a scanned text page (600 dpi) takes only 100 KByte. The patch is based on version 2.3.14. I only added the option to the dialog and an error message which informs the user that only black / white images can be saved as CCITT Group 4. The tiff library already contains the necessary code. I attached my patch to the bug report. I've attached a revised patch some days ago. Did you (or anyone else) get a chance to try it? I would like to commit this as soon as possible but the patch needs some more testing before it can go in. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] updating (and categorizing) authors.xml
Hi, there's one more thing that we need to get done before 2.4 and that's updating the list of contributors. As we have discussed last year at LGM, it would be a good idea to also introduce some way to differentiate between active and inactive contributors. Currently when users look at the About dialog they see a lng list of authors and might get the impression that the GIMP project has plenty of active developers. We all know that this is not true. I would like to propose that we add some sort of attribute in the authors.xml file to mark active contributors (perhaps active=yes, or last-active=2.4). I propose that we define a contributor as active if she has done a substantial contribution in the last development cycle. The AUTHORS file in the source tree should probably continue to list all authors, perhaps categorized into active and inactive. But I would like the About dialog in 2.4 to display only active contributors. Does that sound reasonable? Do we have a volunteer for updating the list of contributors? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Fwd: Re: Meaning of delay in screenshot plugin
Duh! caught out by this ML reply-to sender policy once more. Sorry. --- Forwarded message --- From: [EMAIL PROTECTED] To: Sven Neumann [EMAIL PROTECTED] Cc: Subject: Re: [Gimp-developer] Meaning of delay in screenshot plugin Date: Wed, 31 Jan 2007 10:51:12 +0100 On Wed, 31 Jan 2007 08:38:21 +0100, Sven Neumann [EMAIL PROTECTED] wrote: But I don't know all the other desktop environments out there and I expected that they more or less all have a reasonably well working way of taking screen-shots. After all this is where the functionality belongs. Well there is no clear definition of the responsabilities of a desktop manager and different project chose different criteria. KDE tries to take over management of the whole system which I consider inappropriate but is very popular because it follows the windows thinking most people have been obliged to learn. Other window managers, like fvwm, take a very minimalist approach that is close to a bare windows manager without any concept of desktop. xfce4 aims for a balance somewhere in the middle, remaining light while providing basic desktop functions. I guess they think taking screen-shots is not part of desktop function and if you want that you'll install a tool like scrot or gimp. I have even seen comments here suggesting this is a OS function. That only makes sense in the MS use of the term where the operating system can re-size images , zip them, open an Internet connection and send them to your grandma. Clearly any correct use of the term has nothing to do with screen-shots, graphics or windows at all. It concerns making the hardware _operate_ . There is a blurring of lines. I don't see this as being out of place in a tool like gimp. It is after all a plugin , not part of the core. I don't think a desktop task-bar plugin is any more right than a image editor plugin. Why not both, I'll use the one that works best ;) In any case, after a busy day on this topic yesterday, it seems like everyone is pulling in the same direction , attitudes are a lot more positive and it looks like the resulting plugin will be a lot more functional than any other screen capture tool I've seen. That's great news. It raised my morale considerably to see a wide range of views, ideas and needs being distilled into an effective and flexible solution so quickly. This is OSS working the way it should work. Good day to all. gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] an idea for the screenshot plug-in
Sven Neumann [EMAIL PROTECTED] wrote: The screenshot plug-in could do that, create a layer for each screenshot and place it at the right offset. The result would be an image that looks like a screenshot of the whole screen. But it would have separate layers for each window (including popup menus). This would allow you to rearrange the screenshot later (hiding some windows for examples). Truly useful for some of the article-writing stuff I do from time to time. (-: I'd use it for replacing images with something harmless, highlighting display elements (like menu items) and the like. Maybe replacing furniture from one WM with chunks from another (e.g. paste GNOME or Win32 kit over the top of KDE or XFCE). From a presenter's point of view, it'd be dream-land. Cheers; Leon ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
Akkana wrote: I am an interaction architect, I have to take a decision what is the best solution for 1 million users. We spend time evaluating this feature systematically. We especially focussed on your use case. But we saw the cost in UI complexity to put in the second delay. This complexity slows down 99% of the users, Not being an interaction architect, I'm still not understanding. How did you arrive at the 99% number? I explained how I got to the 1%, the 99% are the rest of GIMP users. And 1% is already a very generous, on the safe side, estimate. Do you really think you can round up ten thousand GIMP users who ever have to take a screenshot of a window with something pressed AND consider GIMP actually the right tool for this? You'll struggle to find one thousand, exactly because most would not choose GIMP. But 1% is a convenient number and it drives the message home. I simply want you to concentrate on 99 GIMP users, who will never ever take a screenshot of a window with something pressed, with GIMP. Confront them with two delays, and you make them think what the difference is. You just stopped them working... Now you take the same decision as I had to take. [pre- vs. post- selection delay] I estimate the chance that one is not taking a screenshot of GIMP itself as higher than 50%. So you need time to get GIMP out of the way. To get the screenshot dialog out of the way, you mean? No, to get GIMP out of the way. The 800 pound gorilla that eats a million pixels of screen real-estate for breakfast. Is it really that common to screenshoot a single window which is so large that there isn't room for both it and the screenshot dialog on the screen at the same time? To the list: does anyone here actually uses the delay for that purpose? The people who have asked for before-screenshot delay mostly seem to want time to switch desktops (a valid reason but surely not a 99% case). In general the delay is 'time to get ready'. Get GIMP out of the way. This can be done in a multitude of ways, of which switching desktops is one. I also wonder about discoverability: Sometimes I have to click on the window after the delay, but sometimes I don't. Will people figure out that having a mouse button already pressed is what makes the difference? I already asked for the improvement that we use two lines of text to explain what happens (depending on the snap option) during and after the delay. Everything is cool with the interaction syntax, when the delay expires, the user says 'this one' by either clicking on it, or already holding it up by the ears. And you know what? It feels really good that I have sped up your workflow, compared to 2.2, without making 99 other users pay for that. Steve Stavropoulos' interface, with the two clearly explained delays, seems so much easier to understand than trying to intuit a mouse-already-down behavior. Only if you have been taking many screenshots of stuff pressed in windows with GIMP for the last few years. Putting the two delays in the UI on the same level is a big mistake, actually. Makes one even more think what is this selection..? The 2.2 dialog did that better. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
This discussion goes on too long and distracts too much. I am one who would prefer the plugin to work differently, but it is clear that no solution will be good for everybody, and the approach Sven has taken is certainly reasonable. It would also be reasonable, I think, to separately distribute a fancy-screenshot version, perhaps via the registry, that would allow more options for handling the delay. Best wishes, -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
peter sikking writes: I got the fling that ksnapshot manages to take a snapshot of the window + menu. There is where I got the idea. But reading the documentation again, they do not 100% promise this. I should have tried ksnapshot before! It does get the menus -- even on Edgy where GIMP's snapsnot just gets garbage. If you have the mouse over only a menu, ksnapshot will even give you just the menu without the window containing it. ksnapshot solves the delay problem in a nice clean way: they have only one (pre-selection) delay, but their window selection is Window under cursor -- you don't need to click to select the window. That solves everything without requiring two delays. It's a nice solution! (Now off to poke around X and think about Sven's fabulous super- layered-screenshot idea.) -- ...Akkana Beginning GIMP: From Novice to Professional: http://gimpbook.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Meaning of delay in screenshot plugin
Hi, On Thu, 2007-02-01 at 10:37 -0800, Akkana Peck wrote: If you have the mouse over only a menu, ksnapshot will even give you just the menu without the window containing it. ksnapshot solves the delay problem in a nice clean way: they have only one (pre-selection) delay, but their window selection is Window under cursor -- you don't need to click to select the window. That solves everything without requiring two delays. This is exactly how the GIMP screenshot plug-in in SVN behaves. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] LGM 2007 - Press Release - Spanish translation help
Hello all, We are a bit in an empasse with respect to the Spanish translation of our press release (http://create.freedesktop.org/wiki/index.php/Conference_2007_Press_Release) I want to ask if someone has the time to translate the first part of the press release (not the second with the descriptions of the programs). It would be even better if we had a list of Spanish computer and graphic art magazines (email addresses) to send the translations to. We want to fire up the press release on sunday night, after the official LGM website is online. I really apologise for asking that lately, but I really thought someone else had taken care of it. If you don't have the time, please don't mind. We are the beggars here :) Many thanks! Louis LGM 2007 organiser p.s. Sorry for sending this twice to the Create list. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] LGM 2007 - Press Release - Spanish translation help
Hello. I'll start to translate it here: http://create.freedesktop.org/wiki/index.php/Conferencia_2007_-_Bolet%C3%ADn_de_prensa And anyone is welcome and encouraged to help. manuq 2007/2/1, Louis Desjardins [EMAIL PROTECTED]: Hello all, We are a bit in an empasse with respect to the Spanish translation of our press release (http://create.freedesktop.org/wiki/index.php/Conference_2007_Press_Release) I want to ask if someone has the time to translate the first part of the press release (not the second with the descriptions of the programs). It would be even better if we had a list of Spanish computer and graphic art magazines (email addresses) to send the translations to. We want to fire up the press release on sunday night, after the official LGM website is online. I really apologise for asking that lately, but I really thought someone else had taken care of it. If you don't have the time, please don't mind. We are the beggars here :) Many thanks! Louis LGM 2007 organiser p.s. Sorry for sending this twice to the Create list. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
