Harald Prasse writes:
I have The GIMP installed under WIN2000 with Local language settings
set to Belgian...
I'd like to set it to English though, how do I get it done?
The set lang=c in the autoexec.bat doesn't do anything
Probably Win2k doesn't use autoexec.bat? Try setting it from
Martijn Weisbeek writes:
The current release-version BTW is not a good advertisement.
Well, luckily I don't have to worry about market share...
There's been an error while compiling somehow (which required some
patches) and those patches have not been implemented in the
download.
Guillermo S. Romero / Familia Romero writes:
From gimptool I have:
if test x${CC+set} != xset ; then
cc='gcc'
else
cc=$CC
fi
From his posted file:
cmd = g_strdup_printf (gcc %s %s -o %s%s %s %s %s %s,
Yes, that obviously is a FIXME. But hey, this was the first version of
a
Guillermo S. Romero / Familia Romero writes:
Another possible FIXME: does GTK provide a define or something for dir
separator? It will clean the code a bit.
Yes, GLib has G_DIR_SEPARATOR (and G_SEARCHPATH_SEPARATOR). But I
don't think a something like gimptool --cflags should blindly output
Branko Collin writes:
Maybe I am mistaken about this, but it would seem that Adobe offers
the Photoshop SDK and the Photoshop file format specifications for
free download at
http://partners.adobe.com/asn/developer/gapsdk/PhotoshopSDK.html.
Yep. Except that they don't document the
I REALLY REALLY need a plugin that mimics the Contact Sheet 2 plugin
for photoshop. The Gimp is awesome, fills a lot of my requirements, but
without the plug/script I still need photoshop.
Do you use the GIMP on Windows? Is Contact Sheet 2 a filter plug-in
(and not Format, Automation, or
Sven Neumann writes:
We've discussed several workarounds but none has made it into CVS
until now. I hope that Yosh and Tor will speak up and tell us why.
Well, I haven't dared touch configure.in any more until 1.2.3 has been
released. Basically, I am waiting for Yosh to decide how to resolve
I thought I saw some time ago somewhere that Photoshop 6 would have
multi-coloured brushes (like GIMP's pixmap brushes), but that I then
didn't find any documentation for their format in the Photoshop SDK.
Now, however, I can't find anything about this, nor does my Photoshop
6 Tryout seem to
Branko Collin writes:
I have not seen any announcement on www.gimp.org or this list, that
is why I am asking: is GIMP for Windows 1.2.3 official?
Umm, define official? Is GIMP for (pick your random Unix system)
official? Which of the prebuilt GIMPs for Solaris (I assume there are
several)
Lutz Müller writes:
If some Windows guy steps forward to port gphoto2
(http://www.gphoto.org) to Windows, you would even have digital
camera support _in_ the GIMP through gtkam's plugin (i.e. capture
from within the GIMP, download directly into the GIMP, etc.).
Umm, the gPhoto site says
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes:
Unfortunately, the developers who do the windows port don't use the same
config mechanisms as under unix/cygwin,
Actually, I do. (Hans doesn't.)
and Gtk is proven to be hard to port to that environment.
... but I still fear that porting
Philip Brown writes:
so far, you seem to have described a situation that implies that autoconf
can work without pkgconfig, but pkgconfig isnt that useful without
autoconf.
Sure it is, it can be used in simple hand-written Makefiles, or even
directly from the command line.
You did not
none of the symbols that start with an underscore should be exported.
If they really are, it's a bug and you should expect that they won't
be available in the next release.
OK, I'll remove them. (I have a vague recollection that *some* of the
underscore entry points really *is* used by
Tor Lillqvist writes:
I have a vague recollection that *some* of the underscore entry
points really *is* used by another DLL. Don't have time to check
right now.
Yes, _readchannel is used by libgimpui.
And the iwarp plug-in uses _gimp_layer_copy().
--tml
MecaT writes:
I wondering if ever gimp for windows with gtk2 will be builded? I am ot
waiting for any date of release, but can you tell me - will be gimp
1.3.x ported on windows?
Hans Breuer has done it (at least at some time) using MSVC. Hans, can
you tell us more?
If I understand
Carol Spears writes:
my first instinct is to tell you *not* to try to build anything for gimp
on windows.
Actually, if a plug-in is reasonably portably written, building it on
Windows isn't necessarily any more complicated than on Unix. To build
and install a plug-in foobar:
gimptool
Kevin Myers writes:
Sorry for the extra email, but one question: When using gimptool as you
describe below, what is the correct approach for handling the
configuration-specific files such as config.h, gdkconfig.h, and glibconfig.h
which aren't in the normal include paths in the developer
I am doing a remote start of GIMP for Windows from a Visual Basic 6
application. that looks something like this:
response = Shell(C:\Program Files\GIMP\bin\gimp.exe
C:\ImpImages\Main.SelectedImage)
Is there some way to force the default directory to be the same as the
directory I
[EMAIL PROTECTED] writes:
response = Shell(C:\Program Files\GIMP\bin\gimp.exe
C:\ImpImages\Main.SelectedImage)
Is there some way to force the default directory to be the same as
the directory I specified when remote starting GIMP?
(Didn't I already send a reply to this message to the
Steinar H. Gunderson writes:
Does GIMP use the X clipboard at all, BTW? I think the Windows version uses
its internal clipboard, at least (which is quite annoying :-)
For text or images? Annoying that it does, or doesn't? It uses the
Windows clipboard for text when you use the normal
Robin Rowe writes:
I guess you are unaware of the gimpwin-dev list.
That list is (with hindsight) misnamed, it doesn't in fact have much
discussion about GIMP itself at all. But the name goes back to the
early days of the GIMP port to Windows, when I had hopes there might
be lots of discussion
Hi,
I don't know if this is a silly question, I am quite confused and
tired, but could someone tell what the purpose of libgimpproxy is...?
Why do the functions it contains have to be duplicated in it and in
the GIMP core? Couldn't the GIMP core also use those functions from a
library?
--tml
I wrote:
I had to add a glue file for libgimptool, to enable the dynamic
linking to the main executable, either gimp.exe or
tool-safe-mode.exe (?).
Sven Neumann writes:
please note that we don't build any tool plug-ins on UNIX since it's
horribly broken and might even be removed
Sven Neumann writes:
Let's hope that Tor will find the time to do a new win32 build if we
finally come around to do the official 1.2.4 source release.
Sure. I'll do it ASAP after that.
I'd also welcome if we could get such an announcement mail (the one
Tor sent to gimpwin-dev) next time
Sven Neumann writes:
I had the impression that were was overall aggreement that
[EMAIL PROTECTED] should die and people should be asked to
subsribe to gimp-developer and/or gtk-devel lists instead.
Yes, there wasn't much opposition. I haven't done anything about it
yet, though. It will
Branko Collin writes:
Is not all your code in the GIMP CVS repository? If so, why not?
I have told this several times, most recently earlier today:
I have local changes I haven't committed to the (real) GIMP CVS,
true. [...] As soon as 1.2.4 has been officially released I'll try
to see
Raphaël Quinet writes:
From my point of view, I think that it would be better to integrate
these changes before the 1.2.4 release.
It's just that maybe half of the changes are really quite ugly hacks
to get non-ASCII file and directory names working somewhat better on
Windows, where GTK+
Sven Neumann writes:
IMO Tor should commit his filename-conversion hacks.
I wrote:
OK, I'll merge them in then, with ifdefs as appropriate not to affect
behaviour on Unix. I'll probably have time to do it next weekend.
It took some time before I could do it, but now I have merged in those
Sven Neumann writes:
We usually try to avoid to use terms as the Win32 GIMP port or the
OS X GIMP port since GIMP is multi-platform and there are no ports to
other operating systems.
Isn't it the terms version or project that should be avoided, not
port?
--tml
(gimpwin-users readers can largely ignore this message... just keeping
this thread there, too, as it started there)
Manish Singh writes:
It looks to be trio's fault, there is a bug similar to this opened already:
http://bugzilla.gnome.org/show_bug.cgi?id=101874
Perhaps special case
As Sven suggested a long time ago, the gimpwin-dev list has now been
closed... I directed people to subscribe to this list, gtk-devel, or
gtk-app-devel instead, as appropriate.
P.S: Anybody know of a way to get the archived gimpwin-dev messages
out from yahoogroups and into some not
What should one do with requests like this? If I recall correctly, I
already once have told these people that they don't need any more
permissions than what they already have to redistribute GIMP, and that
even if they did need some permission, I am not entitled to give them
it on the behalf of
Nathan Carl Summers writes:
Gimp plugins do not link with the Gimp and thus do not fall under Gimp's
licence. Gimp plugins do link with libgimp*, which is licensed under the
LGPL.
Are there any licensing issues, BTW, with the pspi plug-in? (The GIMP
plug-in that interfaces to Photoshop
Michael Schumacher writes:
According to Tor Lillqvist, there was something missing from Pango
1.2.3 and fixed shortly after the release.
BTW, I now made new pre-built pango-1.2.3 Win32 packages on
www.gimp.org/win32/downloads.html, with the missing exports added, so
building GIMP 1.3.x
Alan Horkan writes:
Any chance of binaries [for Win32] for testing?
If you ask nicely, I might be presuaded to zip up what I've
got... (Just built it on Win32 for the first time in a while.)
And what compiler did you use (wondering if I'll be able to get gtk-wimp
to work with the Gimp 1.3
Henrik Brix Andersen writes:
Removing the fallback definitions broke compilation on at least one
platform, namely GNU/Linux which doesn't define _O_BINARY and/or
_O_TEMPORARY. Most likely other unix-like platforms where affected as
well.
Since Unix systems don't distinguish between binary
Hans Breuer writes:
This is a regression of previous versions. IIRC it was caused
by the usage of gdk_eindow_new() with parameters 'in range' and
additional adjusted by SafeAdjustWindowRect and the code
later calling gdk_window_move with coordinates directly derived
from the current
Tor Lillqvist writes:
There also seems to be some handle leak when GIMP is starting up and
queries all the plug-ins. Also, something needs to be done to #98737
soon. (Perhaps related, I had to start GIMP at least four times before
it got past all the plug-ins and wrote out the pluginrc
www.gimp.org/win32/gimp-head-20030813.zip.
Haven't really tested GIMP HEAD much at all myself, but it starts OK
and some random painting and filtering did work.
Bug reports to bugzilla, please.
Plase don't tell end-users yet, until I have had a chance to do some
more testing myself, to avoid
Michael Schumacher writes:
The result of make after creating the libintl.a libiconv.a files:
Creating library file: .libs/libgimpui-1.3.dll.a
.libs/gimpui.o(.text+0x159):gimpui.c: undefined reference to `gimp_min_colors'
.libs/gimpui.o(.text+0x170):gimpui.c: undefined reference to
I won't take any stand on either side (or how many sides are there?) in
the ongoing discussion, just air some fresh thoughts...
Many of the image formats suggested are some kind of archive formats
(zip, ar) on the outside.
I understand that one important benefit from this is that you can
store
BTW, what happened to GNOME's libefs? From quickly browsing the
sources, it seems to have been included in bonobo still in
bonobo-1.0.22, but then bonobo was renamed to libbonobo, and I don't
see any trace of it in libbonobo-2.3.6. Was it such a badly designed
disaster that it was dropped? Or did
Michael Schumacher writes:
When compiling current cvs on win32, I get:
../../build/win32/compile-resource winsnap.rc winsnap-win32res.o
/bin/sh: ../../build/win32/compile-resource: No such file or directory
../../build/win32/compile-resource probably *is* there, but what
causes that message
Sorry if this is a silly question, but does the maximize button on
modern X11 window managers behave differently than in Windows? Doesn't
it always make the window fill the whole screen?
(Hmm, or is it so that even on Windows it is possible to make the
maximize button not always maximizing to
On Sun, Aug 17, 2003 at 07:23:39PM +, Tor Lillqvist [EMAIL PROTECTED] wrote:
Sorry if this is a silly question, but does the maximize button on
modern X11 window managers behave differently than in Windows? Doesn't
it always make the window fill the whole screen?
Sorry, I
Jakub Steiner writes:
I have sucessfully done this with an existing GIMP plugin - GAP's move
path. At PAL resolution. The only problem is it needs a lot of disk
space and RAM.
Hmm, didn't know GAP could do that. I don't think GAP is suitable for
this. Takes way too much disk space. Or does
Alan Horkan writes:
If you are particularly ambitious could it be an substantial Animation
Tool, an interface like a standalone application but substantially
reusing the GIMP components, a sister to the GIMP if you will? (If I am
being wildly unrealistic as usual, just say so).
Umm...
Henrik Brix Andersen writes:
Using gimp_pixel_rgn_set_row() may work for some images, but since
GdkPixbufs internally have aligned data which may result in padding
garbage inserted between two rows, you will need to use
gdk_pixbuf_get_rowstride() and iterate over the rows one by one.
But
Burton Samograd writes:
You should look at Cinellera.
Tor Lillqvist [EMAIL PROTECTED] writes:
Hmm... It was strangely hard to find Cinellera using Google, I
Umm yes, that was because it's spelled Cinelerra, not Cinellera...
Still, I find it odd that neither the heroinewarrior.com
Daniel Rogers writes:
hmm, last time I checked, plugins run in a different process space, so
setting up callbacks is a bit more difficult than normal.
Well, obviously I meant callbacks using the normal PDB mechanism, and
not directly.
--tml
___
Alan Horkan writes:
I was just asking because the code was being changed anyway.
Well, actually it's not certain at all that the screenshot code used
on Win32 will be changed. The winsnap plug-in works, and even if code
from it was copied into screenshot.c, it wouldn't still work the same
way
While talking about UI ideas, how about keyboard-mouse chording?
Currently, while painting with the mouse (or tablet pen), the other
hand is presumably idle. Would it be a good idea to be able to use
keyboard keys to modify the painting action? I am thinking of some
fresh ways to interact using
I was hoping that there was interest in getting rid of (almost) all
differences between platforms and doing a common screenshot plug-in
would be one more step towards this goal. Sad to hear that you prefer
to keep the winsnap plug-in alive.
Well yes, that is a good goal. But as it started to
tongue-in-cheek
So the huge image you generated is a fractal? Isn't it a bit silly to
render such images (especially if they are huge) with GIMP, where all
of the image's pixels are kept in memory (or the tile cache) all the
time? Aren't many fractals such that you could calculate the value of
Tino Schwarze writes:
You're right. If you could tell me such a program... I would have used
it. The nearest approximation was xfractint but it's cumbersome to use
and doesn't have a gradient editor (and I'm not sure whether it's
capable of rendering 2x14000 pixel images). ;-)
Built from CVS today.
www.gimp.org/win32/gimp-1.3.22-20031009.zip
www.gimp.org/win32/gimp-dev-1.3.22-20031009.zip
As earlier, the dependencies are downloadable from
www.gimp.org/win32/downloads.html. Check the end of the page. The
librsvg dependency is new compared to my previous build of GIMP
carloscrae writes:
i still have the same problem regarding plug-in installation
problems with directories that have spaces
Yes, that problem is in GLib, not GIMP. Should have mentioned that in
the announcement mail. I am not distributing new binaries for GLib
(yet). I probably should do a
David Moisan writes:
librsvg dependency is new compared to my previous build of GIMP
^^^ librsvg-2.4.0.zip 404 Not Found Oops. :)
Oops, sorry, forgot to upload the librsvg zipfiles. Now they are
there.
--tml
___
Gimp-developer mailing list
I just lost some 50 mail messages due to an unfortunate interaction
between my virus scanner and mail reader (and some carelessness on my
part), sigh. If you have sent me personal mail in the last 18 hours or
so, please re-send...
--tml
___
Tor Lillqvist writes:
Oops, sorry, forgot to upload the librsvg zipfiles. Now they are
there.
And now is there also zipfiles for libgsf, which is needed by the
librsvg DLL (which is needed by the svg plug-in)...
--tml
___
Gimp-developer mailing
I am getting tired of maintaining the .def files that list entry
points exported by DLLs. Gcc doesn't really need them anyway. If you
don't give it any .def file, it exports all global symbols, just like
Unix compilers/linkers traditionally work. (All the Windows binaries
of GLib, GTK, GIMP etc
Arnaud Charlet writes:
Is it really the case that MSVC can't create DLLs without .def files ?
No. But the alternative is to decorate every function and variable to
be exported with __declspec(dllexport). That would clutter the headers
unbearable. (The exported variables do have to be decorated
Tor Lillqvist writes:
No. But the alternative is to decorate every function and variable to
be exported with __declspec(dllexport).
To be more precise, preprocessor macros would have to be used in such
a way that when compiling the library in question, the compiler sees
__declspec(dllexport
Just my 2 euro cents: The linear histogram illustration Sven
provided looks a lot more like histograms of typical images do in
other applications than the logarithmic one.
I have often wondered why GIMP's (traditional logarithmic) histograms
look so different than the ones you see in other
---BeginMessage---
[EMAIL PROTECTED] writes on gimpwin-users:
[...] I just wanted to let everyone
know that I've created another 16 custom brushes for GIMP (in
addition to the initial 16 I offered a few days ago). I would like
to create about 10-15 per day but I'm running out of copyright-
Owen writes:
Anyway, most of them are pretty good.
but for this kind of images, image pipes (.gih brushes) would be even
better. (each image pipe brush containig a set of related images, for
instance diffferent kinds of fruit, different size and colour leaves,
etc.) toad_walker said he would
(Redirected to gimp-developer)
Is there any special reason that (almost?) all win32-specific stuff
seems to be missing from release tarballs
No. The reason is nobody has tried to build for Win32 from a tarball,
so nobody has noticed... or at least not reported her problems.
(the same thing
Sven Neumann writes:
I am not sure about the purpose of libgimpbase/gimpwin32-io.h. Is it
used only in the GIMP source tree or is it supposed to be installed so
external plug-ins can use it as well?
I assume it is to be used only in the source tree.
Anyway, it should certainly be added
I wrote:
If you are using MSVC, I guess the real question is, is there any
chance that we will be able to claim supporting a MSVC build out of
the box with a straight face?
Hans Breuer writes:
Probably not, at least not until the issues outlined in
Tor Lillqvist writes:
Then the build should be removed from gimp's line in
CVSROOT/modules . Will this have some odd consequences, or can it be
done right away?
Anyone object? It might be that people will have to re-get gimp from
CVS if build is removed from gimp's line in CVSROOT/modules
Tor Lillqvist writes:
Possibly the lcms.dll in the lcms11.zip file isn't suitable as such
to be used from GIMP, but will have to be rebuilt from source.
Yes, that seems to be the case. I don't know the technical reasons,
but when I built the lcms DLL from sources (a rather simple
./configure
A couple of small issues noticed after installing Jernej's build of
GIMP 1.3.23 for Windows (Thanks!):
- The fontconfic configuration file isn't included. It should be as
gimp-top\etc\fonts\fonts.conf. Without this file no fonts are found
for the text tool to use. This is easy to fix, just put
Tor Lillqvist writes:
I did build the latest libwmf (2.8.1). It required some minor patches
to its source. But it's not installation-location-independent (like
for instance GTK and GIMP are). It looks for its fonts in a I location
fixed at build time. This is not acceptable on Windows. I
Adam D. Moss writes:
The only thing I can think of would be if the
windows.h/windef.h/etc headers that get pulled into just about
every file on a win32 build expand into monsterous evil and add
measurably to the unit compilation time.
Well, that probably is the reason. windows.h *is*
Roger Leigh writes:
MSYS does not depend on cygwin, BTW. It's entirely standalone.
MSYS is a *fork* (version) of Cygwin. As the mingw FAQ says, The
POSIX layer used by MSYS is a fork of the 1.3.3 version of Cygwin.
(But maybe that was what you meant.)
They both have to implement fork()
Simon Budig writes:
This has the advantage that the behaviour is exactly predictable in
every zoom level, since always exactly the same rectangle of the
viewable area gets magnified.
Hear, hear! This seems like a big win to me. I'm all for this.
It seems that some people are scared away
codemastr writes:
Well the people in #gimp were telling me in Linux that's called a sticky
window.
If so, they probably misunderstood you (or I did). A sticky window
is (as I understand it) a window that is always on top of all other
windows, and stays sticked at the same place even if you
(Cc:ing to the gimp-developer list.)
[EMAIL PROTECTED] writes:
I wanted to add a feature to Windows Version of gimp but I don't
know how to get started developing for windows. It seems that the
dev site is mainly for the linux person. Or at least the
directions.
Most of the current
is there any hope for tablet (with pressure sensitivity at least)
support in win port of the gimp?
The issue isn't in the Windows port of *GIMP*. I am rather certain the
problems are in the Windows backend in *GTK* (GDK). It needs to have
some loving care applied to its tablet support. If it
Jakub Friedl (listy) writes:
this bug stops many users from using gimp.
Does it really? Aren't tablets (at least the more expensive, pressure-
and tilt-sensitive ones) mainly used by graphics arts professionals?
These guys typically live and breathe in Photoshop, don't they? I
doubt they would
Simon Budig writes:
If a windows user really needs scripting, I'd recommend to install
e.g. a bash.
True, but doesn't necessarily help. The Win32 process invokation API
(CreateProcess()) doesn't use a argument vector like Unix does. It
uses a command line. The argv that a C or C+++ main()
Sven Neumann writes:
It is not equivalent but similar. To execute commands from a file you use
cat filename | gimp --batch -
and I really don't see why this should not work on Windows.
Sorry, this is probably a very silly question, but could someone post
a minimal example of the
FYI:
---BeginMessage---
I uploaded a revised version of the installer, which now includes the help
files and gimp-freetype plug-in. This installer will also check for
possible DLL conflicts and offer you an option to rename the conflicting
files.
As usual, the installer is available from
Carol Spears writes:
TheGIMP is not photoshop. it was written so that linux people would not
not have to use a different operating system
Was it? GIMP was originally written on the commercial Unixes of the
time (Solaris, HP-UX etc), wasn't it? And it used Motif. And it still
runs as well on
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes:
According to you, this shouldn't be. Additionally, one would assume that
these are additional restrictions that are explicitly forbidden by the GPL
itself.
But these restrictions are placed by the MySQL copyright holders
themselves, aren't
I booked my flight yesterday, and registered at the conference
(although no email confirmation yet...?). See you in Kristiansand.
--tml
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Has anybody else received an confirmation after booking a student flat
when registering for the conference? I haven't. I did get a
confirmation for the conference registration, but on the other hand no
charge has showed up on my credit card yet. And no reply to my inqury
to the FiloNova address.
Brion Vibber writes:
How is image cut-n-paste handled on Win32? Windows apps use DIB (.bmp)
format for clipboard transfer; does the GDK backend handle DIB-PNG
conversion? I took a quick look around gdkselection-win32.c friends
but didn't see anything obvious.
There is a
Sven Neumann writes:
When an image file we open has an embedded color profile we should ask
the user if the image should be converted to linear sRGB (which is
what GIMP assumes internally).
Er, what's linear about sRGB? It's gamma encoded (and that's a good
thing). Doesn't the term linear
Sven Neumann writes:
What is the state of support for the GDK clipboard in the win32
backend?
For the *GDK* clipboard only cutpaste of text is supported. The
winclipboard plug-in uses the Windows clipboard directly.
Michael reported that he can't even copy and paste image data
from one
When I started to implement the GDK clipboard functionality I was
hoping there was better support for it in the win32 GDK backend.
Thinking a bit more on it, adding support for cutpaste of images to
gdk/win32 would probably not be hard at all. Much code from
winclipboard.c can be reused. For
The second is, I haven't looked at the code at all, but is the GIMP
multithreaded and/or does it absolutely require a multitasking OS?
You won't be able to use any plugin without a multitasking OS...
I think what the OP really meant to ask whether GIMP requires a
*pre-emptively*
I am afraid that this is not possible simply because the color
selector is not associated with an image. All we can do is to correct
the color selector using the monitor profile.
You mean that the colour selector would implicitly always be sRGB? I'm
afraid that's not a good idea.
Assume
Sven Neumann writes:
Almost all of the messages that cause this problem don't come from the
GIMP application. They are created by libraries that we are using and
these libaries aren't necessarily using g_print() and g_printerr().
Nope, you have it backwards. 3rd-party libraries who write to
Sven Neumann writes:
The information given above may be appropriate for adding fonts to
your win32 system but it is irrelevant for GIMP on Win32.
On Win32, fontconfig by default uses the Windows fonts directory,
i.e. the same fonts that Windows uses itself.
--tml
gtk-app-devel-list people, check the start of this thread from the
gimp-developer archives at
http://www.mail-archive.com/gimp-developer%40lists.xcf.berkeley.edu/msg07988.html
Sven Neumann writes:
There got to be a way to change this behaviour of g_print(), no?
Well, one could redirect stdout
William Skaggs writes:
What about a user who wants to file a bug report? Surely
they are relevant in that case?
They can then start the GUI app with explicit redirection of stdout
and stderr to a file.
--tml
___
Gimp-developer mailing list
[EMAIL PROTECTED] writes:
The messages would ideally be able to be shown in a real window
(not the console)
And what's so unreal about a console window? Is is just that they
are black and white and make (some) people think of MS-DOS?
(Some call console windows DOS boxes and seem to think
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
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
1 - 100 of 195 matches
Mail list logo
