_wstat does not work with Windows Vista symbolic links. In these cases,
_wstat will always report a file size of 0. _stat does work correctly with
symbolic links.
Ugh, how weird and unexpected. (My expectation would have been that
neither supports symbolic links.) For which C runtime is
Ugh, how weird and unexpected. (My expectation would have been that
neither supports symbolic links.) For which C runtime is this, btw,
the system msvcrt.dll, or some of the MSVC-version-specific ones?
The MSDN documentation doesn't specify. I suspect its all of them TBH.
Actually, looking
that means glib and any app
using glib is indirectly dependent on compiler with C99 support.
Interesting. I guess nobody told those who continue to manage to build
GLib and the GTK+ stack in general with Microsoft's compiler, which
does not claim C99 compliance.
--tml
- doesn't compile on x86-32 linux with glibc when I remove all typedefes and
occurences of long long in header files
Equally interesting, it doesn't compile if you replace all instances
of the letter 'a' in your header files with the letter 'b'. Or, if you
feel really adventurous, with the
Glib just cannot require 64bit integer
type and be C89 standard compliant
Right. And as far as I know, nobody has claimed it is.
--tml
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
Glib just cannot require 64bit integer type and be C89 standard compliant
Right. And as far as I know, nobody has claimed it is.
Actually, thinking a bit more, isn't it perfectly OK for a fully C89
compliant compiler to provide whatever non-standard stuff it likes as
long as the identifiers
It's just a question of definition. Many people, me included, don't
consider once-only allocations of memory that stays accessible and
aren't freed before the program exits leaks. GTK+ and GLib isn't the
kind of libraries that you could load dynamically, use a bit, and then
unload, and expect to
Each time you call _CrtDumpMemoryLeaks() it dumps all the memory that's been
allocated but not yet released.
So it doesn't take into consideration at all whether the memory in
question is / can be used or not, i.e. whether there is any pointer to
it in local variables, etc. All memory that has
Am I right in
thinking that the engines that used to live in separate dlls
(libpixmap and libwimp) are now folded into one of the main dlls
-- presumably libgtk-win32-2.0-0.dll?
No, that would not work (without changes to the engine-loading code to
look for built-in engines). They are where
I managed to track down the missing files and libgnomecanvas is now compiling
just fine. I will need to build libgail though.
Isn't gail part of GTK+ nowadays? At least, in GTK+ a libgailutil is
built, and a gail.pc and include/gail-1.0 installed.
(Yes, it might be that the VS project files
I suppose it's entirely possible that this problem might be fixed in some
other version of libTIFF. Is there a recommended version of libTIFF that I
could try with libgdk_pixbuf instead of the FreeImage version?
I guess the newest libtiff in
I'm trying to build libgdk-pixbuf from source (actually, I'm building the
whole of libgtk-win32 but let's concentrate on libgdk-pixbuf, since that's
where my current confusion lies).
What version of GTK+? In the current version of GTK+, 2.22.x,
gdk-pixbuf has been split out into a separate
Have you heard the phrase patches welcome?
--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
I'm not sure that's true in this case.
Maybe not, but if he just does the work and attaches it to a bug or
otherwise makes it public, it might help the next person who has the
same idea.
--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
* BTW, are there any plans to add multihead on other platforms?
Not for Windows, at least. I am not even sure what multihead would
mean on Windows. Note that I am not talking about mutiple monitors in
a user session's Windows desktop; that works mostly fine in GTK+ since
a long time.
Would the
no one ever wants to volunteer to help.
Actually, that is not true. For instance, the ms-windows theme engine
is now effectively maintained once again and compiles and maybe even
works in gtk+ master. And for bulding the GTK+ stack for Windows (32-
and 64-bit), I very much plan to stop doing it
What about joining forces and make one unique official repository for
packages on Windows ?
You mean, like there is one unique official Linux distribution?
--tml
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
Would this approach work? It would have to be a multiple windowe application,
of course.
I very much doubt it. None of the code in gdk/win32 is written with
anything such in mind. And whether such an application would then be
portable to X11 I have no idea.
--tml
If I may ask, what is the main technical problem (deeper explanation) with
using GTK+ from multiple threads?
On Windows, the problem is that Windows GDI, being a local windowing
system with a quite tight coupling to the client code executing on the
same machine, is very much thread-aware.
This is sort of off topic, but since the stability of GTK on Windows was a
subject of this thread, I'd like to ask about GIMP?
How come GIMP is completely stable on WIndows?
Well, it is stable in the sense that it doesn't crash (knock on wood)
in normal use. I didn't mean there would be
Right now, GTK 3 is a moving target and developing for it is
likely to be quite frustrating. So I second the when it is
stable point.
And of course, in case you choose GTK+ because of the cross-platform
support, there is also the whenever it eventually maybe works
reliably on Windows point.
Sorry but this point is not clear enough to me.
Do you mean that GTK+ is not stable enough on Windows (XP,Vista,7)?!
Well, that depends on your definition of stable. It depends much on
what the GTK+-using program wants to do, and whether continuous
building and testing of the program has been
It's impressive to see someone promoting tech from the other camp :-)
Why not? It isn't like it would have any impact on my personal
happiness/income/status/reputation if people use Qt and not GTK+ for
cross-platform apps. Also, I am not employed by anybody to work on
GTK+ so I don't see saying
Having recently built it under Win32 (using Visual C++) I decided to run the
test application (testglib.exe). Everything runs fine until I get to the
File Functions test, at which point I keep getting debug assertions.
That is a problem in the C library then, that it generates debug
The window is created and I can interact without problem with it.
Now, here you are another little test programme that does not work:
It *does* work for me, both when running against GTK+ 2.20.1 and
2.22.0. (The official binaries from www.gtk.org, actually hosted on
ftp.gnome.org.)
window =
I'm calling gdk_draw_image with a 32-bit per pixel image with some pixels
having alpha=0 and some with alpha=255, and the transparent pixels come
through as black (not surprisingly). What is the correct was to get that on
to the screen? (for Win32 and X)
For Windows, you can't do any
(Sending a copy also to the gtk-app-devel-list. Please keep
discussions that start on a public mailing list public unless you
specifically have private personal or confidential matters to discuss
in some messages.).
I just found libwimp.dll off in some subfolder, but I don't think I added
that
Some such engines have been written, or attempted
(GTK-Wimp, GTK-Qt theme engine, ...)
Note that what you call GTK-Wimp is actually called the MS-Windows
theme and has been included in GTK+ itself for quite some time
already. (Just the actual theme engine DLL is called wimp. The theme
and the
the resize grip gets ugly between 2.18 and 2.20 on windows system.
You need to distill the problem down to a minimal but complete sample
program and file a bug at bugzilla.gnome.org against product:gtk+,
component:win32, and attach the sample program (as a single source
file).
--tml
It has certainly been explained that that is the situation on
Windows, and I fully accept it. It's less clear that it should be
the situation on OS X, with its *nix-type substructure.
You have it backwards. It was from the GTK-on-OS-X people (well, at
least those that I have heard from) that
Wait a minute, now I am confused. I thought you said that the look of
the resize grip had changed between two GTK+ versions on Windows? Can
you specify these two exact versions, that you used on Windows, or
not?
Did you use the same theme (or no theme at all) with both GTK+ versions?
--tml
Version on win32 (ugli resize grip):
And the versions with the non-ugly resize grip?
--tml
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Since the new 2.20 Win32 Bundle,
That doesn't say much. Instead give specific GTK+ version numbers
between which you see different behaviour. (If you have been using the
bundles, the exact version and build information of the components
included can be found in the components.lst file in thw
The short answer to the question in the subject is: You don't.
Is it possible to write a text editor which uses GTK+ and shows correctly the
file which is created
by the following code:
[ code that writes some hundreds of thousands printable ASCII characters
without newlines to a file ]
I'm wondering how to check the runtime version of the (glib and gtk for
example) DLLs, that the application is linking to.
You mean check at run-time? Using the API provided for that, if any.
For GLib, use the glib_major_version, glib_minor_version and
glib_micro_version variables (which are
Currently, if you want a GTK+ on Windows where more complex things
like OpenGL might work, to some degree, you should probably use GTK+
2.16. The situation might improve in the future, or not.
--tml
___
gtk-devel-list mailing list
Is there anything that I could do differently to increase the loading speed
or is this just something I need to just deal with and move on to the next
item on the list?
You need to find out what exactly it is that is taking a lot of time,
and experiment with different ways to do that. I.e.,
Does gtk+ have an API call for obtaining the user's screen resolution (in
pixels) ?
(Please, avoid the terms screen or display, as they have specific
meanings in X11 and gtk+ which don't match what you probably mean,
which I assume is an individual monitor of potentially several that
are part
Ah, maybe I've misunderstood is that in fact what
gdk_screen_get_monitor_geometry() will tell me?
Yes. Also note that there can be holes in the screen that no monitor covers.
--tml
___
gtk-app-devel-list mailing list
I very much doubt if anybody who actually is doing the work, i.e.
maintaining the gtk+ stack, has any interest at all in switching to
CMake. So this discussion is mostly pointless. (And anyway, this
discussion is on the wrong mailing list; gtk-devel-list would have
been the relevant one.)
Does anyone know of any apt repositories out there that already do this
for things like Gtk+ before we start making our own.
Not what you are easking for, but in the openSUSE Build Service there
is plenty of GTK+ and GNOME stuff (including, for instance, Evolution)
cross-compiled for both for
Hello, i installed cygwin, gtk+(available with cygwin) and eclipse on Windows
xp.
Gtk-WARNING **: cannot open display:
Are you aware that the GTK+ for Cygwin is built with the X11 backend,
i.e. software that uses it requires an X server (also know as
display)? (Either running on the same
Wouldn't it be possible to link gtk+ statically and rely on the linker to
drop all the unused symbols?
Not out-of-the-box currently, but working on that would be a better
idea, and enabling statically building the GTK+ stack would have a
better chance of getting upstream.
--tml
Why do they have little chance of going upstream?
Because the maintainer says so?
--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Is it good enough that the maintainer doesn't even give a reason?
It is good enough for me. I admire a maintainer that doesn't let
everything turn into bikeshedding.
Did I miss something?
The possibility to maintain patches for the features you are missing
in your own distro or whatever?
You can already build GTK+ statically, can't you? Or doesn't it work on
Windows?
Well, not only GTK+, but presumably then also everything else under it
in the stack, otherwise it would be a rather pointless exercise,
wouldn't it? I am fairly sure it doesn't work out-of-the-box. I have
never
How are the binaries in http://www.gtk.org/download-windows.html built?
Currently, locally on Windows, using MinGW and MSYS. Look in the
developer zip files for src/tml/packaging/*.{sh,log} which are the
shell scripts used to build the packages, and the output from those
scripts.
But, I build
This morning, everything worked fine until the build got to the gio branch -
which failed, due to unistd.h and sys/wait.h not being present.
There was a problem in the VS project files in 224.1, some source file
that should be built only on Unix was included by mistak. Simply drop
the source
If you want to show code, at least show something that compiles and
exhibits your problem (if any), i.e. a minimal but complete sample.
Anyway, I don't see what your problem has to do with GTK+.
--tml
___
gtk-app-devel-list mailing list
I found the VC++ .sln and .vcproj files, loaded the solution and just tried
to compile one of the modules in the glib branch. However, every module
fails to compile because config.h is missing.
I assume you are talking about GLib 2.24.1, from a tarball?
There is a Pre-Build Event for the
Fixed now in git, bug #621168.
--tml
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Is it possible to run the application on
Windows without installing GTK+ redistributable package? I guess yes.
You guess wrong, I'd say. You should bundle the GTK+ runtime, and any
other 3rd-party libraries needed, with your application. (As part of
its installer ideally.)
(I don't know why
I have meant any theme which improve the visual effects. Could you give
me more information how to use 'wimp' or 'pixmap'?
wimp is the internal slightly silly name for the theme engine that
implements the ms-windows theme. So you just need to have a file
etc/gtk-2.0/gtkrc in your gtk+
Is GTK available on windows 7 ??
No separate version or build of GTK+ is needed for Windows 7. The same
Windows GTK+ binaries work on XP, Vista and 7.
--tml
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
The msvcrt.dll runtime can hardly be said to be obsolete when a new
version is included with each version of Windows,can it? Also, it is
included even as a 64-bit version in 64-bit Windows. There is no MSVC6
that would generate 64-bit code, soI don't see how it could be said to
be specific to
Perhaps 'deprecated' is a better description than obsolete. msvcrt.dll is
provided nowadays purely and simply for backwards compatibility with older
apps
Why does even the 64-bit notepad.exe, to pick an example, then link to
the 64-bit msvcrt.dll? Or the 64-bit ws2_32.dll, to pick another
Under Linux, the app supports dragging and dropping of certain audio files
(for example, WAV files). So, using Nautilus, the user can select a WAV file
and drop it into one of several containers within the app. The WAV file is
then effectively imported for use in the app.
That kind of
I forgot to mention that I am using GTK Builder. From some googling, i found
that g_module_lookup() is in libglade. Am I correct?
No. Google harder.
--tml
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
libraries. Am I correct to assume that g_module_symbol is the replacement
for g_module_lookup()?
I think g_module_lookup() has never existed except in some comment
where somebody mistyped it when they meant g_module_symbol()...
--tml
___
But I'm using windows,so I think maybe I should use windows api to achieve it.
Could well be. Trying to use GTK+ for any exotic window management
tasks on Windows is likely to not work as intended because of bugs in
GTK+ on Windows.
--tml
___
1. Why shift modifies keyval value if it's included as a flag in
state anyway?
Because it is. If it wasn't, somebody would ask why it isn't. If you
think GDK was originally designed by a committee, deliberating for
years, determined to design the best imagineable API with no
inconsistencies at
I guess one last question on this, can I expect that my program will either
work or crash on start up if the dependencies are or are not there? Or is
there the possibility that it may crash further into its process if it
reaches a point where it does not have access to the functions it
You could also add separate get/set functions for longlong or int64,
That is obviously the correct way to do it. Your patch would break API.
You patch uses strtoll() unconditionally, and you use %lld to printf
gint64 values. Neither is portable. Use g_ascii_strtoll() and
G_GINT64_FORMAT.
--tml
Actually, he got the naming right. Even single-core cpus have cores...
Except that of course back when multiple-core chips were nonexistent,
nobody used the term core. So that isn't really a convincing
argument.
Often, processors is understood to be sockets.
So? That doesn't mean it's
It is traditional term, and it is ambiguous these days. CoreDuo is Intel
*processor*.
So what? Intel might call it a processor today, a flux capacitor
tomorrow. It isn't like they would be known to choose one name for
something and stay with it. Is Intel going to change the terminology
used
I am trying to build gtk-directfb on phoneme ….
Why do you assume people would know what phoneme is?
how to replace these with similar functions of gtk ……
By asking for help on the Interwebs? Or by doing the research and
coding required yourself? Which approach would you be more proud of?
I'd my program (a threaded image processing system based on gthread)
to be able to find out how many cores the host machine has.
First a terminological nit: Don't confuse cores with processors.
There were machines with a high degree of symmetrical multiprocessing
(i.e. lots of processors) a
Why? Isn't the interesting metric the number of cores, rather than the number
of fully-independent CPUs?
Depends on what you mean with CPU. You seem to use the terminology
CPU == chip?
Anyway, I didn't suggest using CPU but processor. Existing
platform APIs traditionally use the term
Could some one help me on this how to proceed further?
Read the code, understand how it works, debug, fix problems, submit
patches in bugzilla?
Please understand that the directdb stuff in gtk+ is very close to
unmaintained, as far as I know.
--tml
Can somebody help me with connecting a gtk interface with a backend
database, say, Posgres? How does one embed SQL queries in the C code.?
GTK+ has nothing to do with that.
--tml
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
is there any reason to believe that the glib functions are not working
correctly?
Your guess is as good as mine?
--tml
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
g_spawn_async_with_pipes() to launch an other executable (firefox in this
case).
Do you expect to provide input to Firefox's stdin, or get output from
its stdout, through the pipes then? (That would be a bit strange for a
GUI app like a web browser, wouldn't it?)
If not, instead of g_spawn_*,
You need to compile and link *both* the .c files into *one*
executable. Also, please don't get into the habit of using pkg-config
--cflags --libs, even if it happens to work most of the time on Linux.
Specify C compiler flags and libraries separately in the appropriate
locations on the command
Sounds like an exercise in futility.
If you are doing this to prevent people from saving something because
of commercial/security/whatever interests, and if the users will have
a real interest in working around the limitations you try to impose,
they will. And there is nothing you can do to stop
OK, fixed now as well as
it can be; i.e. if there is wspiapi.h when building GLib, it is used.
there's a 2.22.4 build in the
binaries/win32/glib/2.22 directory on ftp.gnome.org. However,
I've tried using this in my app package and I'm getting reports
from users on win2k that it doesn't
I think much of this boils down to the definition of leak. My
impression is that GTK+ and GLib developers don't consider as leaks
once-only allocations that either indeed truly are unreachable almost
right away after being used (as long as they are small) (but of
course, if possible one should
Looks like GTK indeed encoded the string in Unicode, although the
original string was not in Unicode.
What the string and theoriginal string? Where did they come from?
--tml
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
I wrote my first linux GUI app using GTK+, which seems to be a very
nice tool.
Well, GTK+ is not a tool but a library, also called a tooolkit, so
I wonder whether what you actually have been using some higher level
GUI application or toolt to write code that uses GTK+? Anyway, let's
assume that
Any ideas?
Most likely you cause a heap corruption in your code, which then can
cause seemingly random behaviour later in the program's execution.
(For instance such randomness that adding some g_debug() calls seem to
fix your problem.) Use valgrind.
--tml
You should probably open[1] a bug report about this if you wish to see it
fixed. Sometimes Tor visits this list, but it's not a 100% guarantee.
I do read this list, and did notice the original mail, but as I
couldn't do anything right then for it, and the reason to the problem
seemed obvious, I
We really need to get our story together here. Either we do our very
best to handle late g_thread_init(), or we should fail spectactularly.
Agree 100%.
My own humble opinion is that even GLib (not just GIO) should link to
-lpthread and work as if g_thread_init(NULL) would have been
implicitly
- Initialize GTK+: what should I use for the arguments of the gtk_init_check;
I do not have a main in the DLL
Just pass and empty argument vector then?
- Cleanup GTK+: how to free resources; I cannot exit the application
That is not really possible, sorry. There will always be some
Is it possible to do something similar with the Windows version of GTK+?
Yes and no. Note that there is nothing GTK+-specific in this.
Read up on Remote Desktop Services, earlier known as Terminal Services
(or Terminal Server). See
http://en.wikipedia.org/wiki/Remote_Desktop_Services
It is
The radix is locale dependent. You will need to set a C locale.
To be more specific, call setlocale(LC_NUMERIC, C)
GTK+ calls setlocale(LC_ALL, ) for you automatically in gtk_init()
unless you call gtk_disable_setlocale() first.
Read your C library's documentation to learn about setlocale().
I'm not sure that it will ever support passing win32
handles in the same way...
Nah, I assume it won't be necessary. To the extent it is possible to
pass Win32 HANDLES from one process to another, it uses a totally
different mechanism: The HANDLE is duplicated already in the source
process and
btw: I don't know if passing HANDLE on Windows is supported (and I would
guess not).
Sure it is. DuplicateHandle() can be used for this. I.e. a process A
that has the required access right (PROCESS_DUP_HANDLE) to two
processes U and V can take a HANDLE value valid in source process U
and
I think I am on the right track: I'm creating a Lua Socket, getting the file
descriptor (which is a normal fd/SOCKET), create a new GSocket using
g_socket_create_source, and attaching a callback that should fire on data
available on the socket.
Please note that the GSocket API is quite new,
my problem is that when my program crash i get from the backtrace only these
two rows
#0 0x77c035e4 in ?? ()
#1 0x in ?? ()
what am I doing wrong?
Nothing, probably, that would cause this unuseful backtrace, you just
have bad luck and the program crashes in an unfortunate context
- The libdbus-1 on Win32 / OS X story. Gah.
So either we a) restrict this to UNIX (put headers in gio-unix-2.0)
or; b) we just tell people they need to use e.g. WinDBus on Win32,
There is a relatively new effort to clear up the dbus situation on
Windows situation, dbus4win, see
(This discussion should have been on the gtk-devel-list in the first
place and not in personal mail to me. I am replying there. Please
let's continue there.)
The thing is that sinhala differs miles away from English.
Of course I know that. And Microsoft knows it too. As far as I can see
they
Any chance or problem for the windows binaries on the website/ftp?
Sorry, I had forgotten to upload them. Should be there soonish.
--tml
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
I think that this is from times where people
used to build GUIs in the code... When they were writing all the container
embedding and all, in C, building their dialogs.
Those times are still very much here. For instance in the application
that gave GTK+ the G in its name.
--tml
But since cairo has a small bug that prevents any win32 cairo based
program running,
Hmm, interesting. You probably should take that up on the cairo list.
I tested the bug 552678, it's not solved by my patch.
Fortunately we now know what will solve it (see the latest bug
comments and
I spent a day on building gtk head on win32 by utilizing OAH
(https://launchpad.net/oah) and came up with these small patches.
Thanks. I went through them and they looked fine. I wonder if the
patch to io-gdip-utils.c could fix the problem with the GDI+ -based
pixbuf loaders
it's open source
and the URL is here if you want to see the source code perhaps :
http://houbysoft.com/cc/
The download of fhe source code is hidden behind some silly enforced
30 second wait. If you want somebody to fix your problems in code, at
least you could make it easier to see the source
Any ideas how to make this work?
Install the svg pixbuf loader (and its dependencies), and edit the
gdk-pixbuf.loaders file (or use gdk-pixbuf-query-loaders).
See http://ftp.gnome.org/pub/GNOME/binaries/win32/librsvg/2.26/ for
Windows binaries for the svg pixbuf loader. You will have to trawl
Sigh, it was stupid of me to reply telling you to do what you already
told you had done. /me blushes and tries to be more careful in the
future.
Anyway, good that you got it working. Could you come up with some
short but to-the-point Windows-specific instructions that could be
included in some
Bundling GTK+ with your app is not an unnecessary hardship for the
developer since one has to build against a GTK+ environment anyway that
one had to assemble.
Yeah, but a clarification: the GTK+ environment one *builds* against
is of course a *development* one, not a *runtime* one. They don't
BTW, check out http://afuera.me.uk/jhbuild-windows/ where he says: My
big plan: write a versioned, dependency-tracking binary package
manager for Windows
(I am not endorsing nor criticising such an effort or its relation to
jhbuild. I am not using jhbuild myself, and have not really felt the
The mistake was I didn't notice py2exe didn't automatically package
int.dll, so now I include it manually.
Ah OK. intl.dll is loaded at run-time, if available. I.e., if an
application doesn't have localisation for its own messages, it makes
little sense to ship it with GTK+ localisation then
1 - 100 of 520 matches
Mail list logo
