Re: [Gimp-developer] Console window on Win32
I wrote: Except that on Windows it's not or, but and. Just starting a GUI application from a command shell in a console window doesn't make its stderr and stdout connected. Iago Rubio writes: True, but I think my point of view is still valid. No Windoze app opens a console for output. Yes. My point was mostly directed to Unix-oriented people to warn them not to think or advice Windows users that just start the application from a command prompt and you will see the output. It isn't that easy. For instance to see the help text from gimp --help on Windows one has to pipe its output to more. (Currently, with the console-window-opening still in GLib, the text output appears in a console window that opens but that then immediately closes when GIMP terminates...) Unfortunately there doesn't seem to be any way for a Windows application to check whether it has actually been started from a command interpreter in a console window, and not Explorer (so that it might in that case attach its stdout and stderr to that console window). Or is there? I can't even find any API to find out the parent process of a process...? --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Console window on Win32
Tor Lillqvist wrote: I wrote: Except that on Windows it's not or, but and. Just starting a GUI application from a command shell in a console window doesn't make its stderr and stdout connected. Iago Rubio writes: True, but I think my point of view is still valid. No Windoze app opens a console for output. Yes. My point was mostly directed to Unix-oriented people to warn them not to think or advice Windows users that just start the application from a command prompt and you will see the output. It isn't that easy. For instance to see the help text from gimp --help on Windows one has to pipe its output to more. (Currently, with the console-window-opening still in GLib, the text output appears in a console window that opens but that then immediately closes when GIMP terminates...) When started from the MinGW (and probably Cygwin) bash, this doesn't happen. The output appears in the same console (rxvt window). Of course, it isn't really running on Windows in this case, but at least developers using thiese environments shouldn't be affected by the lack of the output then (or will they?). Michael -- The GIMP http://www.gimp.org| IRC: irc://irc.gimp.org/gimp Wiki http://wiki.gimp.org | .de: http://gimpforum.de Sodipodi http://sodipodi.sf.net | IRC: irc://irc.gimp.org/sodipodi ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Console window on Win32
Michael Schumacher writes: When started from the MinGW (and probably Cygwin) bash, this doesn't happen. The output appears in the same console (rxvt window). Wow. Didn't know that. I seldom use MSYS and its rxvt. I assume rxvt's window isn't a console window, it's a normal graphics window that just happens to contain only text, handled by the rxvt application itself. (I.e. it's like xterm etc on X11. A Unix equivalent of console windows would be built-in text-only windows in the X server, or something.) Rxvt itself presumably passes some pipes for stdout/stderr to applications it starts and then shows whatever comes through those pipes. Few end-users have rxvt, though. --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Console window on Win32
Few end-users have rxvt, though. huh, that is wrong, many people in Asia really perfer it, coz its nice wide-width characters handling. Regards, Cai Qian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Console window on Win32
On Sunday, September 19, 2004, 15:13:31, Cai Qian wrote: Few end-users have rxvt, though. huh, that is wrong, many people in Asia really perfer it, coz its nice wide-width characters handling. Does that include Windows users? -- Jernej Simoncic http://deepthought.ena.si/ for personal mail, replace guest.arnes.si with isg.si Random events tend to occur in groups. -- Law of Probability ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] how floating selection actually anchor?
in PDB, Doc of gimp-floating-sel-anchor reads: This procedure anchors the floating selection to its associated rawable. This is similar to merging with a merge type of ClipToBottomLayer. The floating selection layer is no longer valid after this operation. What is the exact merging algorithm for ClipToBottomLayer? can someone describe it in details using pixel operations? ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] how floating selection actually anchor?
Hi, bear [EMAIL PROTECTED] writes: in PDB, Doc of gimp-floating-sel-anchor reads: This procedure anchors the floating selection to its associated rawable. This is similar to merging with a merge type of ClipToBottomLayer. The floating selection layer is no longer valid after this operation. What is the exact merging algorithm for ClipToBottomLayer? can someone describe it in details using pixel operations? What exactly are you trying to find out? IMO the docs are quite clear here. Perhaps you could tell us what motivates this question? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Console window on Win32
Does that include Windows users? No, only those Cygwin people. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Bug...or do we turn it into a feature?
On Sun, 19 Sep 2004 18:39:29 -0300, Joao S. O. Bueno Calligaris [EMAIL PROTECTED] wrote: Hi, I just came across a GIMP behavior that although is a programing error, I have liked, and as it may be hard to fix, it could be documented to become more a feature than a bug. It has to do with Quick Mask: If one enables it, and while it is on, click to select a new working drawable (either in the Layers or in the dialogs channel), the QuickMask will still be visible, but drawing will take place on the newly selected drawable. It seems to me that the correct behavior is that the new drawable becomes activated, but quickmask is still on -- that is, the paint tools still affect the selection mask. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Bug...or do we turn it into a feature?
Hi, Joao S. O. Bueno Calligaris [EMAIL PROTECTED] writes: I just came across a GIMP behavior that although is a programing error, I have liked, and as it may be hard to fix, it could be documented to become more a feature than a bug. It has to do with Quick Mask: If one enables it, and while it is on, click to select a new working drawable (either in the Layers or in the dialogs channel), the QuickMask will still be visible, but drawing will take place on the newly selected drawable. How is that a bug? QuickMask is just a regular channel. The button in the lower left of the image window is just a shortcut to using a channel to edit the selection mask. Nothing but a quicker UI for it. It seems the only way to come back to the quickmask is to togle it off and on back. Or by choosing the Qmask channel in the Channel tabs of course. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Bug...or do we turn it into a feature?
On Sunday 19 September 2004 20:48, Nathan Summers wrote: On Sun, 19 Sep 2004 18:39:29 -0300, Joao S. O. Bueno Calligaris [EMAIL PROTECTED] wrote: Hi, I just came across a GIMP behavior that although is a programing error, I have liked, and as it may be hard to fix, it could be documented to become more a feature than a bug. It has to do with Quick Mask: If one enables it, and while it is on, click to select a new working drawable (either in the Layers or in the dialogs channel), the QuickMask will still be visible, but drawing will take place on the newly selected drawable. It seems to me that the correct behavior is that the new drawable becomes activated, but quickmask is still on -- that is, the paint tools still affect the selection mask. Sven pointed me out that the QuickMask is just a normal Gimp Channel, and behaves exactly like one, except for the fact it has interface shortcuts - i.e. the quickmask button and context menu. So there is no bug at all, it is only a matter of letting this being widely known. People @ gimp-docs, is it in the manual already? Rockwalrus JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
