Re: _wstat on Windows (actually stat stuff in general)

[Tor Lillqvist]

>> 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 in the C library sources that come with MSVC2008, I
see no sign of such a difference in _stat() vs. _wstat().

Both in stat.c and stat64.c (these are the files that contain the
actual implementation of both the "ANSI" and wide-char versions of the
stat family of functions) I see code that checks
(findbuf.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT) &&
(findbuf.dwReserved0 == IO_REPARSE_TAG_SYMLINK) . But on the other
hand, as far as I can see, this code is used to make stat() (etc) work
as lstat(), not to actually follow the symlink! (But just if the
symlink is the last component of the path; I assume symlinks in the
middle of the pathname are followed transparently by the
FindFirstFile().

So I wonder which is correct, the documentation, or what the code
seems to imply. Experimentation would be useful...

Of course, it might be that it is actually FindFirstFileA() vs.
FindFirstFileW() that exhibits some difference.

> Sure but if all I want to know how big a file is, do I *really* want to link
> in all of that extra crud? GIO is huge. There are times when the low level
> functions are just plain appropriate.

I would say, bah. Any actively maintained (or recently written)
GLib-using code that doesn't use GIO by now is just being maintained
or written in a misguided fashion.

> People really do want to use stat rather than GIO. I do, and I've had
> private emails from others who do too.

Well, then you just will have to live with the various breakages;) I
don't think you will be able to convince people it would be a good
idea to add more bells and whistles in the form of stat() -style APIs
when GLib already has a much cleaner and ABI/API
stability/extendability safe (and other nice words) way to get
information about files.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: _wstat on Windows (actually stat stuff in general)

[Tor Lillqvist]

> "_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 this, btw,
the system msvcrt.dll, or some of the MSVC-version-specific ones?

Anyway, I think the only sensible thing to do is then to not use
either _wstat() or _stat(). We don't want to miss the full Unicode
support, and I guess this symbolic link stuff is useful, too.

Instead, we should just use the Win32 API to fill in the meaningful
fields of a struct stat. Yeah, following symbolic links manually might
be painful; I have no idea how to do that.

(Of course, when I say "we", I actually mean "you", as I don't really
take much part in GLib/GTK+ development currently... sorry. Just
noticed this thread when browsing the gtk-devel-list archove, and
*had* to follow-up...)

Anyway, isn't g_stat() kinda deprecated? Should it be? Partly exactly
because of this horrible potential for confusion with the several
"struct stat" variants on Windows (and also on some Unixes, I guess,
although there at least there is typically only one C
library). Doesn't GIO's APIs to get file
properties/attributes/whatever they are called supersede g_stat()?

> Here's how I would define the GStatBuf data type:
> 
> typedef struct GStatBuf {
>guint32  st_dev;
>guint64  st_ino;
>guint16  st_mode;
>guint16  st_nlink;
>guint32  st_uid;
>guint32  st_gid;
>guint32  st_rdev;
>gint64   st_size;
>gint32   st_atime;
>gint32   st_mtime;
>gint32   st_ctime;
> } GStatBuf;

Er, no. NO.

This definitely is pointless, GIO supersedes g_stat() etc in much
cleaner fashion.

Why on earth would we want to use 32-bit timestamps in a new API? Or
just 16-bit st_nlink?

Why would we want the extremely Unix-specific st_mode to show up in a
portability layer at all? st_mode is on Windows always just a
best-effort (or not even that good an effort) fabrication. Many
POSIXes support ACLs in file systens and such might be common for some
file systems on some POSIX platforms.  Any software supposed to be
generic and good should take that into consideration anyway when
figuring out the protection of some file. A single st_mode field is
basically useless in modern portable APIs.

st_uid and st_gid are also totally Unix-specifc, of course.

> While in gstdio I'd also add the glaring-by-their-omission g_lseek, 
> g_fseek, and g_ftell all of which could take a gint32 as their argument or 
> return value.

That is a glaring omission only if you misunderstand the purpose of
gstdio.h. It is not supposed to be a wrapper for any file I/O related
functions. Its sole purpose (at least when it was created) is to take
care of the *file name* problems. It even says this in a comment:

/* Wrappers for C library functions that take pathname arguments. On
 * Unix, the pathname is a file name as it literally is in the file
 * system. On well-maintained systems with consistent users who know
 * what they are doing and no exchange of files with others this would
 * be a well-defined encoding, preferably UTF-8. On Windows, the
 * pathname is always in UTF-8, even if that is not the on-disk
 * encoding, and not the encoding accepted by the C library or Win32
 * API.
 */

Beafing up gstdio.h now is too late. All newer file system portability
related stuff in GLib is in GIO, surely.

--tml


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib without ipv6?

[Tor Lillqvist]

> 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
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib without ipv6?

[Tor Lillqvist]

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

Re: Replacing gdk_display_open(char*)

[Tor Lillqvist]

> * 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 X11-inspired terms "screens" and "displays" on Windows
correspond to "desktops" and "window stations"?

(See http://msdn.microsoft.com/en-us/library/ms681928%28v=VS.85%29.aspx
and relevant links from that to get an overview.)

What kind of cross-platform application would need such functionality?
I can't think of any... There is presumably enough fundamental
differences in how and why a client process accesses multiple screens
and/or display on X11, vs. multiple desktops and/or window stations on
Windows, to make it quite improbable that anyone would want to write
such an application using a cross-platform toolkit.

Please do prove me wrong if you can, though;)

> The docs haven't changed since 2002.
> 

Eek, some quite misleading text there, like "GdkScreen objects are the
GDK representation of a physical screen"... a GdkScreen is definitely
not always a single "physical screen". Presumably, to most readers,
"physical screen" would mean a monitor, and that is not what a
GdkScreen is. There is GdkMonitor for that.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk-OSX (was: Website proposal for usability)

[Tor Lillqvist]

> 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 this convention originated.
Only a bit later did the GTK+-on-Windows people (well, many of us, not
all) realize the same.

> I don't think that
> invalidates the idea that it would be very useful for app
> developers to have a GTK runtime package available, as we do for
> Windows.

As usual, people seem to be constantly jumping between talking about
"packages" for developers, and "packages" for end-users. There is no
"officially sanctioned" GTK end-user runtime package for Windows
available, in the sense that it would be something that could/should
be installed as such on end-user systems. It's the developer and/or
packager that is expected to pick out those files his application
actually needs at run-time from the run-time zip archives on
ftp.gnome.org (or from the "bundle" which just combines all the
run-time and developer zip archives for the GTK+ stack). This is not
the same set of files for all applications.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GDK_NATIVE_WINDOWS not working under Windows

[Tor Lillqvist]

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
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: disabling GTK+ features to shrink GTK+

[Tor Lillqvist]

> 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 tried.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: disabling GTK+ features to shrink GTK+

[Tor Lillqvist]

> 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?

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: disabling GTK+ features to shrink GTK+

[Tor Lillqvist]

> 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

Re: disabling GTK+ features to shrink GTK+

[Tor Lillqvist]

> 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
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: cross compiling GTK+ on Linux for Windows

[Tor Lillqvist]

> 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 natively on Windows only because I have a long experience
of doing that, and have acquired the necessary dark skills and hacks
required to make it work relatively smoothly.

For anybody new looking into it, I certainly recommend using
cross-compilation. Have a look at the spec files for the
cross-compiled GTK+ stack (and much more) for Windows in the OpenSUSE
Build Service. See
http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_11.0/src/
for the source RPMS, and sibling directories for "noarch" RPMs
containing in fact Windows binaries. My plan is that eventually the
Windows binaries offered from www.gtk.org / ftp.gnome.org will come
from the OpenSUSE Build Service projects.

As you also use an RPM-based distro, the concepts should be familiar
to you. And actually, there is a similar, in fact older, Fedora-based
effort to cross-compile GTK+ and stuff for Windows.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: help, glib 2.24.0 on windows

[Tor Lillqvist]

I wrote:

> sys/socket.h is not included when compiling on Windows in any source file

But I was wrong;) Will fix in git. You will have to wait for GLib
2.24.2 I guess... Or you could just remove the Unix-specific gio
source files from the gio.vcproj file and add the win32-specific ones
instead.

(As the README.txt file in build\win32\vs9 says, the solution/project
files are experimental.)

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: help, glib 2.24.0 on windows

[Tor Lillqvist]

Please use a mailing list for questions like this in the future, not
private email. Adding gtk-devel-list to the Cc, as your message is
about building GLib itself, not an applicaiton that uses GLib.

On 3 May 2010 19:04, vadym nikolaiev  wrote:
> I try to build glib 2.24.0 on windows
> using a solution file for VS2008,

What solution file exactly? The one from the glib 2.24.0 tarball, in
build\win32\vs9\glib.sln ?

>  Cannot open include file: 'sys/socket.h' :  No such file or directory

What file were you compiling when you got this error? sys/socket.h is
not included when compiling on Windows in any source file unless you
have broken something. The same holds for sys/wait.h and unistd.h.

> How Can i solve this problem

Well, asking for help is a good start, but you need to give more information.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gthread: how many cores do I have?

[Tor Lillqvist]

> 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 in existing APIs like Linux's sysconf(_SC_NPROCESSORS_ONLN)? Is
Intel going to rewrite computing literature to stop using the term
"multiprocessor"? Sheesh.

This is the last I will bother to write in this discussion.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gthread: how many cores do I have?

[Tor Lillqvist]

> 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 correct. "processor" is the traditional
term and that is also used by existing APIs in many operating systems.
One also talks about "multiprocessing", not "multicoring".  "SMP" =
symmetric multiprocessing for instance. "cores" are just a current
implementation detail.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [PATCH] GKeyFile: Switch gint to gint64

[Tor Lillqvist]

> 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
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gthread: how many cores do I have?

[Tor Lillqvist]

> 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 "processor" and not "core"
for this, like sysconf(_SC_NPROCESSORS_ONLN) on Linux and
SYSTEM_INFO.dwNumberOfProcessors on Windows.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gthread: how many cores do I have?

[Tor Lillqvist]

> 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 *long* time before multi-core chips
appeared on the market.

> int g_thread_get_cores( void );

Well, firstly the function name should use "processors" and not
"cores". But I think that in general such a function would be too
simplistic, and just look at things from the perspective of the
current low end of the market.

Whether it's worth to try to design a suitable GLib abstraction for
such things, I don't know. In serious parallelism,  you need more
advanced API anyway, you need to consider things like NUMA, asymmetric
multiprocessing etc. (Note, I am certainly not an expert here.) You
will almost certainly need some platform-dependent code, surely? Or
use other libraries that already do it for you?

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: help on disabling file-chooser

[Tor Lillqvist]

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 them.

The very purpose of the license of GTK+ (LGPL) is to allow your users
to replace GTK+ with a modified version. For instance one where they
have re-instated the functionality you have removed.

The same license that gives you the right to modify GTK+ gives the
end-users of your modified version the right to revert the
modification, and share such a reverted copy with others as they
please.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Valgrind and GTK

[Tor Lillqvist]

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 avoid these, too), or only unreachable
when the program is exiting. I tend to agree. Serious leaks are such
that keep leaking more and more as the program is running and as some
code path is executed again and again.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GIO will link with -pthread soon

[Tor Lillqvist]

> 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 called before any other GLib calls.
g_threads_got_initialized would be TRUE always. But I certainly admit
I don't understand all the implications of this, and implementation
details it would require, especially on Linux. (On Windows, ~all code
compiled by modern C compilers, certainly including the GTK+ stack,
use a multi-thread-aware C library always anyway, which corresponds
more or less to linking with -lpthread on Linux, I think.)

> I guess orbit needing this is the main reason why we can't just make it fail?

I attempted last year to make ORBit2 *not* call g_thread_init()
itself, "as it is usually too late", but had to revert it. See bug
#547885 .

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GVariant support for Unix fds (Was Re: GDBus/GVariant plans for next GLib release)

[Tor Lillqvist]

>  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 one gets the value it can be used as in the target
process, thus it can be passed as just a normal 32 (or 64) -bit
integer, no magic required.

And most likely, whatever application or library that would want to
pass Unix fds over dbus is totally Unix-specific otherwise too.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GVariant support for Unix fds (Was Re: GDBus/GVariant plans for next GLib release)

[Tor Lillqvist]

> 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 duplicate it into a HANDLE value valid in the target process V.
Then it just needs to pass that new HANDLE value (which is just a
number, does not have to be kept secret or anything) using whatever
normal inter-process messaging to process V and process V can use it.

If I understand the documentation correctly,  A must be either U or V,
and in most cases presumably A == U, i.e. a process wants to give
another process a duplicate of one of its own HANDLEs.

Note that the duplicated handle is indeed just a number so no special
mechanisms are needed to pass it to the target process. In process A,
the duplicated HANDLE is not valid. It might have the same numeric
value as some HANDLE (that refers to a totally unrelated object) in
process A, but that is just a coincidence then.

I hate to say this, but IMHO this a more obvious API than the fd
passing over socket thing, which I have always found inelegant,
non-obvious, and in a way quite non-Unixish.

But then, ha, having said that, I now see this gem in the documentation:

"You should not use DuplicateHandle to duplicate handles to the
following objects: [,,,] Sockets. No error is returned, but the
duplicate handle may not be recognized by Winsock at the target
process. Also, using DuplicateHandle interferes with internal
reference counting on the underlying object. To duplicate a socket
handle, use the WSADuplicateSocket function."

OK, so for sockets one needs to call WSADuplicateSocket() instead of
DuplicateHandle(), and WSADuplicateSocket() takes just a target
process parameter. Oh well, that corresponds to the most common case A
== U anyway.

(Windows named pipes also have functionality that I think could be
used in a vague sense to achieve the same end means that fd passing is
often used for, i.e. give another process access to something (an
opened file) it wouldn't have access to (be able to open) otherwise. I
am talking about the "impersonation" thing, but actually now that I
think of it, this functionality is presumably usually used not to give
the named pipe server access to something it wouldn't have access to
otherwise, but on the contrary, to make a named pipe server restrict
its rights to those of the client. And anyway, as Thiago has pointed
out on the dbus list, named pipes are a pain to use.)

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GDBus/GVariant plans for next GLib release

[Tor Lillqvist]

>  - 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
http://lists.freedesktop.org/archives/dbus/2009-April/011207.html ,
but last time when I asked about that I was told that the people doing
it consider it done, but haven't done any releases (source or binary),
or upstreaming efforts.

When I looked at it it seemed to work, but unfortunately the upstream
dbus code has in the meantime diverged quite a bit from when the
dbus4win repo was cloned. No idea how hard it will be to merge back.
(One minor problem in dbus4win is that they use a different build
system (cmake) and their code hardcodes some pathname assumption that
differ from what a "normal" "./configure --prefix=/whatever && make
install" does.)

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Where is gvfs-mount's source

[Tor Lillqvist]

The sources of gvfs-mount are in the gvfs package‽
http://ftp.gnome.org/pub/GNOME/sources/gvfs/1.4/

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gimp/GTK+ unicode on windows

[Tor Lillqvist]

(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 are trying hard to accommodate more and more scripts, each
Windows version brings support for new ones (both input and output
(shaping)).

(Trying to make this into some kind of cultural imperialism issue is
not going to work. The majority of people working on GTK+ and Pango
are not native English speakers. internationalisation and Unicode is
very central to the philosophy of the GTK+ stack and GNOME in
general.)

> It has around 800
> different letters so typing them through a 102 or 101 key keyboard is some
> what hard.

Sure. it requires some specific convention and mechanism, keyboard
layout or IME, just like other non-trivial scripts, the other Indic
ones being the ones presumably most familiar ones to you.

> The actual layout that comes with the OS is an age old typewriter scheme,

Which OS is that then? XP (which SP?) Vista? Windows 7?

> with that the user doesn't have access to those 800 or so letters.
> And some symbol keys are assigned letters - which really pisses me off :P.

That the input mechanism pisses you off personally is not that
interesting. What does the majority of Sinhala computer users actually
use? How satisfied are they? I don't think it is not worth it for
volunteers like me who have no personal gain to put in any effort to
support something that just a small circle of "hackers" use. But as
the saying goes, "patches welcome". As long as they are clean and
don't break anything else.

Similar claims have been made from users of other scripts/languages,
too, that "yeah, the keyboard layout for our language that comes with
Windows is no good, nobody uses it". But I somehow find that hard to
believe, would Microsoft, with all its resources, really fail to
understand the real needs in a market? Is it just so that the hacker
communities are not aware of what the actual majority of computer
users is using?

It is well known that GTK+ on Windows doesn't support all keyboard
layouts 100%. Not even European ones (for instance the Czech layout is
known to be less than perfectly supported), and for instance the "US
International" layout is problematic too. There has been several bug
reports about various 3rd-party keyboard layouts, or 3rd-party add-on
keyboard software ("KeyMan" is the name of one I think I recall being
mentioned) not working with GTK+.

A clean partial rewrite of the low-level keyboard interface in GTK+ on
Windows might be needed to fix the known problems (and perhaps fix
problems not even known yet). Of course, one should take care to avoid
regressions.

GTK+ is Free Software. Bugzilla is open, waiting for patches.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: patches to make gtk head build on win32 with MSVC

[Tor Lillqvist]

> 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 
http://aruiz.typepad.com/siliconisland/2009/08/dear-lazyweb-gtk-need-gdi-help.html
), it is just waiting to be applied and committed.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: patches to make gtk head build on win32 with MSVC

[Tor Lillqvist]

> 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 (http://bugzilla.gnome.org/show_bug.cgi?id=552678 )?

The 0004-include-gdk-gdkinternals.h.patch isn't necessary. There is a
declaration of struct _GdkWindowObject also in gdkwindow.h (in
addition to the one in gdkinternals.h) which is the one that should be
seen when compiling gtkmain.c. Presumably you don't get that in your
compilation because you incorrectly have GDK_COMPILATION defined also
when compiling the gtk DLL?

The 0005-export-_gdk_drawable_impl_win32_get_type-for-gtkplug.patch
should not be necessary either. Do you have INSIDE_GDK_WIN32 defined
while compiling gtk? It is supposed to be defined only when compiling
the code in gdk/win32.

I will apply the other patches, commit and push.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Error converting a pipe (Handler) to fd on vs 2003 to use with g_io_channel_win32_new_fd

[Tor Lillqvist]

puzzlecracker's message was sent first to gtk-list, let's keep the
discussion there, where it belongs. (gtk-app-devel-list would also
have been good.) Not here. This list is about development of GTK+
itself.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: g_stat() did not work for large file (>2B) under WIN32

[Tor Lillqvist]

> Why didn't
> they make it use 64-bit size from the beginning? For something like
> Windows, or SunOS/Solaris, with much longer history, one can
> understand it better.

Actually, I take that back: When 32-bit Windows was introduced, and
the msvcrt.dll API and ABI defined, was it really that hard to predict
that at some time files larger than 2 (or 4) GB will be common? Ditto
for when the SPARC replaced the m68k, and code needed recompilation
anyway.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: g_stat() did not work for large file (>2B) under WIN32

[Tor Lillqvist]

> But I still think it's not a bad idea to make g_stat() to have the same 
> behavior
> as stat() on Linux.

But it *has* the same behaviour, more or less, to the extent possible.
What makes you think using -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 is the "standard" thing to do on Linux? If it
was "the standard" thing one always must do, why is it then needed at
all, shouldn't it be the *non-standard* case that requires extra
compiler options? (Yeah, I am mostly just playing devil's advocate
here.)

It is not really possible to change this now. Remember that g_stat()
takes a struct stat, and we can't change what struct stat is in the
Microsoft C library. Also, I honestly don't think the Linux way to
handle this is ideal either. It is, in my eyes, a bit ugly that
compiler options affect the sizes of fields in a "standard" structure
like struct stat. If some library out of your control has struct stat
as part of its API, how can you know if that library has been compiled
with  -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 or not?

Was it really that hard to predict that in the future file sizes can
be over 2 GB back when the Linux struct stat was defined? Why didn't
they make it use 64-bit size from the beginning? For something like
Windows, or SunOS/Solaris, with much longer history, one can
understand it better.

You should know that the g_stat(), g_fopen() etc so-called gstdio
wrappers were introduced for one single reason: to make it easy to
handle arbitrary file names on Windows by offering an API that uses
UTF-8. Around that time it was becoming more and more clear that all
of GTK+ will be very UTF-8 -oriented, so it fit in nicely to use UTF-8
also for file names (and other strings passed to/from the OS) on
Windows.

In retrospect, it might have been a good idea back then to make
g_stat() take not a struct stat, but some new struct GStat type, which
then on Linux would have been identical to struct stat as it is when
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 are used (regardless if
these macro definitions would be present when GStat-using code is
compiled or not), and on Windows would have been identical to struct
_stati64.

But that can't be changed now because it would of course break stuff
horribly. And anyway, GIO is the "modern" API in GLib to get file
attributes, and it obviously uses a 64-bit size.

Maybe we could introduce a *new* function, though, g_gstat(), which
would take a GStat, defined as described above?

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: g_stat() did not work for large file (>2B) under WIN32

[Tor Lillqvist]

> I recently found that g_stat() didn't work for large file (>2B) under WIN32.

True, because the struct stat that it uses is the one with a just
32-bit st_size. Use gio instead, i.e. get the
G_FILE_ATTRIBUTE_STANDARD_SIZE. Or call the _stati64() (or
_wstati64()) function.

> I use "-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64" during compilation

What makes you think these compiler and C library specific macro
definitions would have any effect on GLib or on the Microsoft C
library? Those macros affect the Linux C library (glibc) only. They
should not be used with any other C library (they might after all have
some entirely unexpected effect on some random C library.) They have
no standard meaning. Such C library feature selection macros are by
definition implementation specific as they start with an underscore.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK on Windows

[Tor Lillqvist]

> For example Pidgin didn't use it's own GTK library (GTK 2.14.7 rev A or
> something like that), but used another one(Gtk 2.16),
> that was installed with another application. I don't remember wich one this 
> was.

OK. Seems that other application then had managed to force its bundled
version of GTK+ on other applications? Perhaps by installing it in the
system32 folder?

Of course, in an ideal world, each new version of GTK+ (or GLib, or
Pango) would be just better than earlier ones (and include new APIs),
but especially for Win32, there are always regressions, and some
applications might work better with a particular not-the-latest
version.

(As such each version, as long as the DLL names don't change, *is*
backward compatible. Just like, as long as the soname doesn't change,
versions are backward compatible on Linux. A regression might be in
some detail (which then for some apps might be more obviously apparent
than for others).)

 > Should there be environment variables for the GTK on windows?

Not really. Ideally, all that is needed is that the GTK+ DLLs are in
the same folder as the application's EXE(s).

Of course, in some cases, this is not enough. For instance GIMP
plug-ins are executables, and GIMP learns what plug-ins are available
in an installation by looking for EXE files in a certain folder (which
thus must be different than the folder where the GIMP executable
itself is). It would make little sense to have copies of the GTK+ DLLs
in both these folders, thus the GIMP applications sets the PATH
environment variable (which is inherited by child processes, just like
on POSIX) to include the folder where its bundled copy of GTK+'s DLLs
is so that the plug-ins processes will find them.

> And two of the installed GTK library's have folders in C:\Program Files.

Directly below Program Files? Weird...

> The first GTK application i used was gimp, and I had to install gtk
> seperatly when I started using it.

That was ages ago (in internet years). Nowadays GIMP comes with a
bundled copy of GTK+, no separate installation.

> But I'm on your side. Best way would be, if people wouldn't even have to 
> know...

Fine;)

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK on Windows

[Tor Lillqvist]

> I'm happy with this apps, but ...
> at the moment under system->software there are three GTK+ Libraries
> installed,

What is "system->software"? You mean the "system" subfolder of the
Windows folder? There should be no GTK+ there. (And not in system32
either.) If there is, some installer is doing a very ugly thing and
needs to have its wrists slapped.

> And what about the GTK+ apps bundled with their own gtk in their own folders.

That is the how it should be.

> And wich gtk library does a certain application use when i start it now.

Unless some badly written application installer puts the GTK+ stack
DLLs in the system32 or system folder under the windows folder, each
application uses the GTK+ stack bundled with it. Either by having the
GTK+ stack DLLs in the same folder as the application's exe file, or
by using a registry entry that makes the application's exe files use
GTK+ from a specific location.

As there is no centralized package management (as in a Linux machine
running a specific distro), each application packager in effect is a
different "distro" that distributes the version of GTK+ (and other
3rd-party libraries) that they know fits their application. GTK+ is
from Windows's point of view a 3rd-party library.

> From the view of a user this is realy confusing.

Huh? A typical Windows user or a GTK-using application does not and
should not need to know what GTK+ is, and that the application uses
it, or that on a Linux box there is just one system-managed GTK+
installation.

It's people with some experience of Linux that have the misguided
conception that Open Source packages on Windows should somehow be
installed like they are on Linux, i.e. system-wide, and thus find it
confusing that there can in fact be several installations of some
3rd-party library, one per application that bundles it.

> It would be really nice to have a standardized gtk installer.

Why not start the discussion with something more basic, like zlib? How
many copies of zlib code do you think exist on a Windows machine with
a typical mix of freely available software installed? Firefox includes
it, it's in OpenOffice.org, and surely in a bunch of other widely used
software. (Presumably it is in some disguise also in Windows itself,
even if the zlib API as such is not offered as a public documented API
by Windows.) Ditto for libjpeg, libpng, expat perhaps, etc. Now, once
you have convinced these projects to have a standardized installers
for these libraries, let's get back to GTK+...

> And if an application bundles it's gtk library with it's installer, the
> installer should be able to check if there is already
> a library installed and which version.

Trust me, this just doesn't work. It is less pain if each application
(or each person/company having control of their own installer(s))
bundles an own copy.

> The other problem with gtk on Windows is, that a lot of people tell me, that
> it still looks alien on the window platform.

Have you tried using the ms-windows theme?

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [windows\dev-c++] manual installation of gtk+

[Tor Lillqvist]

> and to the linker this:
> -gtk-win32-2.0

You forgot the "l".

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gmem.c 175 failed to allocate 175 bytes ....

[Tor Lillqvist]

This is the wrong list. (This list is for the development of GTK+ and
GLib themselves, not apps that use them.) Use gtk-app-devel-list or
gtk-list in the future.

2009/7/14 Kuang-Chun Cheng :
> but the problem did not show up under Linux  :-(

Could be just by luck. The Windows C library is often more sensitive
to small buffer overruns. Did you try running your code under valgrind
on Linux, to check for heap corruption errors in your code? Remember
to set G_SLICE="always-malloc" when using valgrind.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK on Macintosh OSX

[Tor Lillqvist]

> I believe Tor is the only win32 contributor;

Not true, there are several other people who contribute, too. Cody
Russell (bratsche), Hans Breuer, and Dominic Lachowicz are ones that
immediately come to mind. Myself, I work much less on it than I would
like to. (Oh well, to be frank, I am just fooling myself; if I
*really* was highly motivated, I would find the time...) My visibility
is perhaps higher because I build the "official" win32 and win64
binaries (but then, traditionally there is or has been "non-official"
binaries in perhaps more widespread use), and I often take part in
Windows-related threads on the mailing lists.

Just like apparently in the Mac OSX port, there are areas in the Win32
port that are well known to be broken and nobody has had the
inspiration to fix properly. Some issues are truly hard to solve and
perhaps not that important after all (we have managed so far), others
"just" require inspiration and some intensive hacking.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Can not find any function definition in GTK library files.

[Tor Lillqvist]

Note that your question was posted to the wrong list. gtk-devel-list
is for discussion about the development of GTK+ itself. Not for
discussion about using GTK+.

> I replaced the GTK source file (gtk+-2.16.1\gtk) where i found the library
> definition in the GTK bundle (C:\MinGW\include) but it is not referencing
> the file containing gtk_button_new_with_label function definition.

Sorry, I don't really understand what you mean here. Of course,
putting a source file in the directory where headers are won't make
anything special happen.

> Normally in C the definition of printf can be found in stdio.h file.

No it is definitely not. A *declaration* of printf is found in
stdio.h. Not the *definition*. Please understand the difference.

You might be confused by a convention common in many C++ libraries,
where the header files contain also definitions of class methods.
(Especially true for template-based classes, where I guess it is the
only possible way? I am not a C++ expert.)

> but GTK libraries does using the file containing their function definition.
> how is it compiling its library function.

Are you asking how to build GTK+? For Windows? It can be rather hard
if you don't know what you are doing. For many people, it is easiest
to cross-build from Linux. It might be the easiest way for you, too.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: G_SOCKET_FAMILY_UNIX conditional define?

[Tor Lillqvist]

> I think I saw a comment somewhere that Win32 defines AF_UNIX too, is
> that not true?

It's true. AF_UNIX is defined in the relevant header.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: glist manipulation and reference count

[Tor Lillqvist]

> I think I had some confusion here, I thought GObject is part of GLib, and
> apparently that's not true.

You are confusing GLib and libglib. The "GLib" software consists of
five (shared) libraries: libglib, libgmodule, libgthread, libgobject
and libgio. Sure, with hindsight, it perhaps would have made sense to
combine the functionality of the first three into one, or even more,
but that can't be changed now. The GObject API is in libgobject, so it
is part of GLib, but not of libglib. Hope this helps.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+ problem with time-consuming threads

[Tor Lillqvist]

>> You can't use GTK+ from multiple threads on Windows. That is just how
>> it is. It is a consequence of GTK+ originally being written just for X11.

> I always thought it was because of how the Windows event model works.

Yes, exactly. That is what I mean. With its dichotomy of "sending" and
"posting" of messages, creator thread -aware windows, etc, it is quite
different from X11 which is a network protocol. The GTK+ code was
written originally only for X11. That it was possible to port it to
Windows is in retrospect a bit surprising, I must say, even though I
did it myself.

(I don't know how toolkits that have been written from scratch with
both X11 and Windows in mind (like presumably Qt) then differ in the
general working of their low-level machinery, but I assume they do in
some significant way.)

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+ problem with time-consuming threads

[Tor Lillqvist]

> (FYI: I programs using C language and compile it with gcc compiler on
> MinGW.)

You can't use GTK+ from multiple threads on Windows. That is just how
it is. It is a consequence of GTK+ originally being written just for
X11.

> Could someone please give me little sample code that provide only one
> button. When that button is clicked some number of threads will do something
> time-consuming in the background (something simple like multiplying numbers
> 1 times in the for loop, just to give me an idea).

#include 

static GtkWidget *label;

static gboolean
update_label (gpointer data)
{
  gchar *text = g_strdup_printf ("%"G_GINT64_FORMAT, (gint64) (gintptr) data);

  gtk_label_set_text (GTK_LABEL (label), text);

  g_free (text);

  return FALSE;
}

static gpointer
thread_func (gpointer data)
{
  static volatile int counter = 1;
  gintptr me = counter++;

  g_print ("Thread %"G_GINT64_FORMAT" starting\n", (gint64) me);

  /* Pretend doing some heavy computation here. Actually do nothing,
   * just sleep for ten seconds.
   */
  g_usleep (10*1000*1000);

  /* Set the label to this thread's number. Note that there of course
   * is no guarantee that the threads will finish in the same order as
   * started. That is not the point of this sample program.
   */
  g_idle_add (update_label, (gpointer) me);

  g_print ("Thread %"G_GINT64_FORMAT" finishing\n", (gint64) me);

  return NULL;
}

static void
doit (void)
{
  g_thread_create (thread_func, NULL, FALSE, NULL);
}

int
main (int argc, char *argv[])
{
  GtkWidget *window;
  GtkWidget *hbox;
  GtkWidget *button;

  g_thread_init (NULL);
  gtk_init (&argc, &argv);

  window = g_object_connect (g_object_new (GTK_TYPE_WINDOW,
   "user_data", NULL,
   "type", GTK_WINDOW_TOPLEVEL,
   "title", "Multiple threads",
   "border_width", 10,
   NULL),
 "signal::destroy", gtk_main_quit, NULL,
 NULL);

  hbox = g_object_new (GTK_TYPE_HBOX,
   "GtkWidget::parent", window,
   "GtkWidget::visible", TRUE,
   NULL);

  label = g_object_new (GTK_TYPE_LABEL,
"GtkLabel::label", "0",
"GtkWidget::parent", hbox,
"GtkWidget::visible", TRUE,
NULL);

  button = g_object_connect (g_object_new (GTK_TYPE_BUTTON,
   "GtkButton::label", "Click here",
   "GtkWidget::parent", hbox,
   "GtkWidget::visible", TRUE,
   NULL),
 "signal::clicked", doit, NULL,
 NULL);

  gtk_widget_show (window);

  gtk_main ();

  return 0;
}

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Review of gnio, round 1

[Tor Lillqvist]

> I remember reading recently that there was all kinds of issues with
> local pipes on win32, but I don't remember any details. It was on some
> gnome list, maybe even this.

It was on the dbus list. Quoting myself and Thiago Macieira:

> Em Terça-feira 21 Abril 2009, às 16:32:15, Tor Lillqvist escreveu:
>> My guess is that a Windows equivalent to Unix domain sockets would be
>> named pipes? (Should not be confused with Unix named pipes; Only the
>> name is the same.)

2009/4/21 Thiago Macieira :
> That's what we used for the Windows version of QLocalSocket
> (http://doc.trolltech.com/4.5/qlocalsocket.html), but now that we have used
> it, I wouldn't recommend it for D-Bus.
>
> First of all, they're a bit slow. We have an open suggestion in our task
> tracker system to replace the backend with completion ports. I have not yet
> investigated what those things are, so I can't comment on them, except that
> the person who made the suggestion thinks they're faster.
>
> Second, named pipes on Windows are very hard to use. Named pipes use a
> separate namespace on the filesystem hierarchy than files. And unlike a TCP
> server socket or Unix server socket, one file descriptor cannot accept 
> multiple
> connections. Instead, the daemon must create a series of backup pipes with the
> same name. That's not such a big problem, if you consider the "backlog"
> argument to listen(2).
>
> But named pipes only get worse: Windows doesn't have the concept of non-
> blocking calls like Unix does (except for sockets, which are technically
> imported from BSD). The "overlapped" concept is similar, but not exactly. And
> to make matters worse, you can't get a notification that the HANDLE is ready 
> to
> write: so you need to keep a thread running that constantly tries to write.
>
> And if you're not satisfied, then here's one more: named pipes are not
> available on Windows CE. So the Windows CE version of QLocalSocket uses...
> TCP/IP :-)
> [So I would actually go as far as implement the nonce+TCP/IP suggestion as a
> fallback for QLocalSocket itself, to match what D-Bus and libassuan do.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: What gives us the macro GSEAL()?

[Tor Lillqvist]

> So to protection is enable - must include gdkconfig.h.win32 in my
> aplications?

Eek, no. Include gdkconfig.h. Including the normal GTK+ headers
already does that for you.

When building GTK+ for Windows with MSVC, gdkconfig.h.win32 is copied
to gdkconfig.h.

If building GTK+ for Windows using mingw (either natively or
cross-building), the configure script creates gdkconfig.h.
gdkconfig.h.win32 is supposed to be effectively identical to the one
that the configure script produces (for the win32 backend case), to be
useable by people who build GTK+ with MSVC and thus have no POSIXish
environment to run the configure script in, that's the point with it.

> Now I don't see where gdkconfig.h.win32 include in GTK+ source

You don't believe this GSEAL thing is somehow Windows-specific, do you?

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gdk_window_set_skip_taskbar_hint issue

[Tor Lillqvist]

> So, is there any ETA to get this resolved or any workaround available?

Not unless you have a patch to offer?

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: g_malloc overhead

[Tor Lillqvist]

> I don't think it is so confusing since I think strncpy() expects ASCII
> characters,

No. strncpy() expects C chars, half of which are not even in ASCII! In
other words bytes. It doesn't care at all whether the bytes represent
ASCII, EBCDIC, or whatever.

strncpy() works fine for C strings that represent text in whatever
multi-byte codeset (as long as it lacks zero bytes), like UTF-8,
Microsoft's double-byte codepages, etc.

(Well, I exaggerate, obviously if you want to be sure that multi-byte
characters don't get truncated you shouldn't use strncpy(), but some
encoding-aware function.)

> this is even more true if you see there's a memcpy() function that is quite
> the same as what strncpy() is.

No it isn't. strncpy() stops when it encounters a zero char (byte).
memcpy() always copies exactly the requested number of chars (bytes).

> Then considering both strncpy() and
> g_utf8_strncpy() takes the number of chars as the size argument

That is a quite misleading misuse of the term "char". g_utf8_strncpy()
takes the number of Unicode characters (code points), each of which is
represented by one or more bytes. Not "chars". Please let's stick to
using the term "char" to always mean what it means in C, i.e. "byte"
or "octet" (as long as we ignore weird architectures). If you mean the
more abstract concept "character", say so!

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: g_malloc overhead

[Tor Lillqvist]

> I think strncpy() is one of the few that needs an utf8 equivalent,
> because a char may span several bytes.

Well, he didn't say exactly what semantics he wanted his
g_utf8_strncpy() and g_utf16_strncpy() to have. In the UTF-8 case,
should the "size" mean characters or bytes? In the UTF-16 case,
characters or 16-bit units?

The existing g_utf8_strncpy() has it meaning characters. As such I
think the name is bit unfortunate, because of the similarity to
strncpy() but then different semantics of the "size" parameter.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: g_malloc overhead

[Tor Lillqvist]

> What is wrong with:
> gchar*  g_utf8_strncpy  (gchar *dest,const gchar *src,gsize n);

It isn't needed. The nice thing about UTF-8 is that strings in UTF-8
can be handled with normal C str* functions just fine.

> gunichar2 *  g_utf16_strncpy  (gunichar2*dest,const gunichar2*src,gsize n);

Such a function might well be useful in some circumstances dealing
with interoperability or data formats, and I don't oppose adding it to
GLib. (Together with g_utf16_strcpy(), g_utf16_strcat() etc.)

But I don't think I have ever personally needed such a function in
platform-independent GTK code;)

(And in code that is inside a Windows ifdef, such functions aren't
needed either. The C library on Windows already has wcsncpy(),
wcscpy(), wcscat() etc.)

> and the macro:
> gtext*  g_text_strncpy  (gtext*dest,const gtext*src,gsize n);

Never, ever. Didn't the previous replies get this across strongly
enough? This idiocy is not something we want to copy from the stone
age Windows programming style.

(In current-day Windows-specific programming in C, I see no reason to
uglify your code with those TEXT() macros, TCHAR types, etc. Just use
wchar_t for characters, wchar_t literals (L'A'), and wchar_t string
literals (L"Foo"), and call the wide-char versions of C library and
Win32 API functions explicitly. Win9x is dead. No reason not to use
Unicode explicitly all the time.)

(And actually, why would one want to do Windows-specific programming
in general in C (or C++) any more... C# and Java are so much nicer.
And neither of them has any of this silly TEXT and TCHAR stuff.)

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: g_malloc overhead

[Tor Lillqvist]

> Malloc is a system call and has quite bad performance on certain
> platforms (windows in particular i think).

Malloc is not a system call. And please don't make performance
assumptions without having benchmark data to back it up. Note that it
is not necessarily that clear what is a "system call" on Windows, as
far as I know.

> Something like the gslice allocator could probably improve performance a bit.

At least the g_slice_free() API requires passing the size of the
block, so it is not possible to simply have g_malloc() call
g_slice_alloc(), and g_free() and g_realloc() call g_slice_free().

If you start adding a bookkeeping layer to keep track of the size of
each allocation, you end up with a bunch of code that might well
correspond to what the C library's malloc, or the heap management code
in the kernel32 library (which is code running at user level, not in
the kernel, as far as I know) that it calls, already does anyway.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: struggling with the non-recursive gdk_threads_enter

[Tor Lillqvist]

> The code need to be protected so that its execution is not interrupted
> by GDK activities in other threads. How can I do this without a
> recursive gdk critical section?

Don't use GTK+ from multiple threads. Makes the code a lot cleaner.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: About the Glib porting for My custom os

[Tor Lillqvist]

Listen, if you have single-handedly written an operating system, and a
C library, a C++ library, etc, as you seem to imply, surely reading
and understanding some thousands of lines of C code in the
platform-dependent parts of GLib and GTK+ can't be that hard?

A good way to find which parts are platform-dependent is to look for
which parts are different for Unix and Windows.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Fwd: [GDK] generic patch

[Tor Lillqvist]

-- Forwarded message --
From: Steve Lhomme <[EMAIL PROTECTED]>
Date: 2008/10/28
Subject: [GDK] generic patch
To: Tor Lillqvist <[EMAIL PROTECTED]>, Tor Lillqvist <[EMAIL PROTECTED]>


Hi (again) Tor,

While working on GDK I found a nasty bug. I attach a patch to fix it.

In my code I use gdk_add_client_message_filter() to get some custom
events that I want to receive in the UI thread. The problem is that
deep down in GDK, it use GdkClientFilter and GdkEventFilter. They are
both pased to apply_filters where it's assumed to be a GdkEventFilter,
but this is not the case with GdkClientFilter... Plus the structures
are not "compatible" (ie you can use a GdkClientFilter where a
GdkEventFilter is expected). The patch fixes that. And so GDK doesn't
call the callback pointed by my data...

Please forward to the relevant people to fix this (either with my
patch or something else). The bug exists on Win32, Linux and DirectFB.

Steve

diff -pruN ./directfb/gdkevents-directfb.c
\Software\used\gtk\src-tar\gtk+\gdk/directfb/gdkevents-directfb.c
--- ./directfb/gdkevents-directfb.c Mon Oct 27 17:34:04 2008
+++ \Software\used\gtk\src-tar\gtk+\gdk/directfb/gdkevents-directfb.c
 Thu Sep 18 22:44:41 2008
@@ -901,8 +901,8 @@ gdk_display_add_client_message_filter (G
  GdkClientFilter *filter = g_new (GdkClientFilter, 1);

  filter->type = message_type;
-  filter->event.function = func;
-  filter->event.data = data;
+  filter->function = func;
+  filter->data = data;
  client_filters = g_list_append (client_filters, filter);
 }

diff -pruN ./gdkinternals.h \Software\used\gtk\src-tar\gtk+\gdk/gdkinternals.h
--- ./gdkinternals.hMon Oct 27 17:25:34 2008
+++ \Software\used\gtk\src-tar\gtk+\gdk/gdkinternals.h  Thu Sep 18 22:44:44 2008
@@ -65,8 +65,9 @@ struct _GdkEventFilter {
 };

 struct _GdkClientFilter {
-  struct _GdkEventFilter event;
  GdkAtom   type;
+  GdkFilterFunc function;
+  gpointer  data;
 };

 typedef enum {
diff -pruN ./win32/gdkevents-win32.c
\Software\used\gtk\src-tar\gtk+\gdk/win32/gdkevents-win32.c
--- ./win32/gdkevents-win32.c   Mon Oct 27 17:26:50 2008
+++ \Software\used\gtk\src-tar\gtk+\gdk/win32/gdkevents-win32.c Thu
Sep 18 22:44:43 2008
@@ -820,8 +820,8 @@ gdk_add_client_message_filter (GdkAtom
  GdkClientFilter *filter = g_new (GdkClientFilter, 1);

  filter->type = message_type;
-  filter->event.function = func;
-  filter->event.data = data;
+  filter->function = func;
+  filter->data = data;

  client_filters = g_list_append (client_filters, filter);
 }
diff -pruN ./x11/gdkevents-x11.c
\Software\used\gtk\src-tar\gtk+\gdk/x11/gdkevents-x11.c
--- ./x11/gdkevents-x11.c   Mon Oct 27 17:34:09 2008
+++ \Software\used\gtk\src-tar\gtk+\gdk/x11/gdkevents-x11.c Thu
Sep 18 22:44:44 2008
@@ -380,8 +380,8 @@ gdk_display_add_client_message_filter (G
  filter = g_new (GdkClientFilter, 1);

  filter->type = message_type;
-  filter->event.function = func;
-  filter->event.data = data;
+  filter->function = func;
+  filter->data = data;

  GDK_DISPLAY_X11(display)->client_filters =
g_list_append (GDK_DISPLAY_X11 (display)->client_filters,
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Pango 1.22 for Windows?

[Tor Lillqvist]

> Will build 1.22.0 soonish and upload. (Also have to build and upload
> cairo 1.7.6 then, as Pango 1.22 depends on that.)

Done. Lightly tested, seems to work.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Pango 1.22 for Windows?

[Tor Lillqvist]

> Tor, do you plan to provide a pango 1.22 binary for Windows? There's
> just pango 1.20 at the moment:

Oh, yes, sure. I hadn't noticed that a Pango 1.22 had been relased. (I
thought Behdad was waiting for cairo 1.8 first...)

Will build 1.22.0 soonish and upload. (Also have to build and upload
cairo 1.7.6 then, as Pango 1.22 depends on that.)

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: glib on Symbian

[Tor Lillqvist]

> For example, in gdate.c,
>
> static gboolean using_twodigit_years = FALSE;
>
> would become
>
> #if defined(__SYMBIAN32__) && defined(EMULATOR)
>PLS(using_twodigit_years,gdate, gboolean)
>#define using_twodigit_years   (*FUNCTION_NAME(using_twodigit_years
> ,gdate)()
> #else
> static gboolean using_twodigit_years = FALSE;
> #endif

OK, I see, I think it would be cleaner to do it like this: in gdate.c
the only change would be to have:

GLIB_STATIC (gboolean, using_twodigit_years, FALSE);

and then have the GLIB_STATIC macro defined in some suitable header:

#if defined(__SYMBIAN32__) && defined(EMULATOR)
#  define GLIB_STATIC(type, name, initvalue) \
  PLS(name, type) \
  static type PTR_name(void) \
  { \
static type value = initvalue; \
return &value; \
  }
#else
#  define GLIB_STATIC(type, name, initvalue) type name = initvalue
#endif

and then have a preprocessing script that changes all occurences of
identifiers that are seen in GLIB_STATIC() macros to
(*PTR_identiifier) instead, i.e. for instance it would change all uses
of using_twodigit_years to *(PTR_using_twodigit_years) after it sees
the GLIB_STATIC (gboolean, using_twodigit_years, FALSE) in gdate.c

(This is just a quick sketch, no idea if it actually would work in
general, etc.)

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: glib on Symbian

[Tor Lillqvist]

> There is one more issue that needs addressing. The Symbian OS emulator does
> not support global static data in libraries. We found a fair amount of
> global static data in the code and to work around these, we have symbian
> specific code inserted within '#ifdef SYMBIAN32' . The problem here is that
> these changes are peppered throughout the code and rack up nearly 2000 lines
> of changed code.

Please show some concrete (minimal) example... I have a hard time to
understand *exactly* what you mean.

There must be some better way around this than adding 2000 ifdefs all
around the code, which frankly doesn't sound acceptable to me. Sure,
some ifdefs can be added, but in as few places as possible. Some
clever use of the C preprocessor defining names of  global variables
as function calls retuning a pointer to function-local static data
instead, or some clever preprocessing script used for Symbian
compilations, or whatever.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Lacking of a ref-counted string.

[Tor Lillqvist]

> Is it possible to introduce them in the next major ABI breaking?

New API can be introduced in any new minor version. (And has been,
every time.) Adding new API doesn't break any old API or ABI.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: When to call g_thread_init(), again...

[Tor Lillqvist]

> "If your program uses threads (or other libraries that use threads),
> then you must call g_thread_init() before calling any other GLib
> function"

It's not using threads that is the key point here. Calling
g_thread_init() is. That already changes some GLib functions to work
in different ways, incompatible with how they work before
g_thread_init() is called. Whether any threads then are created or not
is not relevant, not for this discussion at least;)

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: When to call g_thread_init(), again...

[Tor Lillqvist]

> For example, Glib have g_mem_set_vtable() that alose requires to be first.

Whee, so GLib documentation is internally inconsistent then. What a mess.

> Current wording of the g_thread_init() documentation doesn't
> introduces such ambiguility at least...

It doesn't? I think "You must call g_thread_init() before executing
any other GLib functions in a threaded GLib program." is pretty
unambiguous assuming you can decide what "threaded program" means.

Or do you interpret this as "once you have created a thread (thus
turning your program into a threaded one), you must call
g_thread_init()" ? I don't think that makes sense.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

When to call g_thread_init(), again...

[Tor Lillqvist]

The documentation for g_thread_init() says (in the stable branch):

  "You must call g_thread_init() before executing any other GLib
   functions in a threaded GLib program."

(The term "threaded GLib program" here is very vague. What it
efffectively means, to the best of my knowledge, is "a program that
calls g_thread_init() at any point at all". Specifically, it does
*not* mean "a program that actually creates threads and calls GLib API
from several threads", I think. In trunk I added more warnings to this
documentation. Read on.)

However, as has been pointed out before, unfortunately that
requirement isn't very effectively enforced, and especially on Linux
many programs that end up calling g_thread_init() after *tons* of
others (even quite complex) GLib API work just fine anyway. So nobody
cares, and few even know about that requirement. Except then when
something is changed in GLib in such a way that failing to meet the
requirement actually causes problems. Then GLib maintainers are quick
to point out that this requirement has been documented a long time,
and that properly written code should always have been written so that
it calls g_thread_init() first, if it will be called at all.

Now, it turns out that the following simple program hangs on Windows:

#include 

static GStaticRecMutex rec_mutex = G_STATIC_REC_MUTEX_INIT;

int
main (int argc, char **argv)
{
  g_static_rec_mutex_lock (&rec_mutex);
  g_thread_init (NULL);
  g_static_rec_mutex_unlock (&rec_mutex);

  g_static_rec_mutex_lock (&rec_mutex);/* Hangs in this call */
  g_static_rec_mutex_unlock (&rec_mutex);

  return  0;
}

(Note that no threads whatsoever are created.)

Clearly when distilled down to the above simple code, it is pretty
obvious that the call to g_thread_init() is done in a somewhat risky
place, and might cause odd effects. This is very obvious especially if
one knows that the g_static_rec_mutex_*() calls are NOPs if
g_thread_init() has not been called. (So what happens here is
effectively that the GStaticRecMutex gets unlocked without having been
locked, which screws up it royally in the Windows implementation.).

The real use case reported on gtk-list looked much more innocent,
though. Its main() started with:

  gtk_init (&argc, &args);

  html = gtk_html_new_from_string (html_source, -1);

How can the poor application programmer know that
gtk_html_new_from_string() will cause g_thread_init() to be called
deep in the bowels of libORBit2? What should be fixed? Should gtkhtml
be fixed to call g_thread_init() itself, from functions that might
conceivably be the first ones that user code calls? But still that
wouldn't help strictly speaking, as gtk_init() of course also calls
lots of GLib functions, so it is too late to call g_thread_init()
somewhere in libgtkhtml in this case. Should ORBit2 g_error() out if
it notices that it wants to use threads but g_thread_init() has not
been called, instead of calling it itself?

gtk_init() can hardly know if other libraries used by the program will
eventually call g_thread_init(), so it's impossible for it to know
whether to call g_thread_init().

So, should the requirement for g_thread_init() being called before any
other GLib API, if it is called at all, be removed? (After all,
failing it apparently is harmless anyway, on Linux. No idea about
other POSIX platforms.) I think that the GStaticRecMutex problem above
can be fixed on Windows in that case.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib String support

[Tor Lillqvist]

> Strings in glib/gtk always are UTF-8. Always.

Not *all* strings. I would say for GTK+ what you say is true (except
for file names), but GLib has many APIs that deal with nl-terminated
generic C strings that don't have to be in any consistent encoding at
all, or for file names are in the "GLib file name encoding", which is
just a shorter way to say "on POSIX, for existing files, whatever
sequence of non-nul bytes the file name on disk happens to consists
of, and for creating files, the locale encoding".

(On Windows the "GLib file name encoding " *is* UTF-8, because that is
1-1 convertible to/from the on-disk UTF-16 encoding.)

> So there is absolutely no need for "current locale" versions of string 
> handling functions.

That I agree with.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: working version of GTK for win64

[Tor Lillqvist]

> Also we should use
> [...]

> instead of
> [...]

> for correct MSVC build of applications.

If you check glibconfig.h.win32.in you will see that it already does
it exactly like you say. glibconfig.h.win32.in is a hand-maintained
file that includes _MSC_VER ifdefs, from which the glibconfig.h that
is in the official GLib Win32 packages on ftp.gnome.org is generated.

A glibconfig.h generated by the configure script is as such not usable
by other compilers than that which the configure script used, and
should thus not be distributed as part of developer packages that
claim to be usable by several compilers.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: working version of GTK for win64

[Tor Lillqvist]

>  First of all, configure script is used only for gcc and automake routines.

Currently, in practise, yes. It is quite possible that at some point
automake and libtool could handle also a build that uses the Microsoft
compiler. (Either through directly supporting it, or by using some
wrapper. There are a few such wrappers already, and I have too been
tinkering on one now and then, see
http://svn.gnome.org/viewvc/build/trunk/win32/cl-wrapper.c?view=log )

And then there are other compilers for Windows than gcc and
Microsoft's, too, like Intel's for instance.

> This part of script requires an predefined type in one word (!) which has the
> size of "long long". In this case, int64 is correct answer for win32 and 
> win64.

It doesn't have to be one word. Just adding some quotes to
configure.in makes "long long" work fine, too, I think. And __int64 is
the more portable name for a 64-bit integer on Windows, I would say.
("portable" in the sense known to both MSVC and gcc.)

> Also we should use
[ inline stuff ]

OK, will check and fix.

>  In any case during compilation we'll have a lot of warnings about INT to
> POINTER conversions.

Yep. I will try to get rid of those.

(Now running 64-bit Vista on the "living room" computer, so I can
actually even run the 64-bit GTK+ stack eventually...)

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: working version of GTK for win64

[Tor Lillqvist]

> http://rapidshare.com/files/130142294/gtk-2.12.9-win64-src.tar.bz2.html

A couple of questions about your changes in the source:

In glib's configure.in, you do:

--- ./configure.in.orig 2008-05-09 22:50:12.0 +0300
+++ ./configure.in  2008-05-06 12:10:18.0 +0300
@@ -871,6 +871,9 @@
   $ac_cv_sizeof_long)
   glib_size_type=long
   ;;
+  $ac_cv_sizeof_long_long)
+  glib_size_type=int64
+  ;;
   *)  AC_MSG_ERROR([No type matching size_t in size])
   ;;
 esac

What is this int64 type? Is it a predefined type in gcc for win64? Is
it available also when more strict standard conformance is asked for?
What about MSVC? Shouldn't __int64 be used instead? Or probably long
long. Anyway, if you add a new possible value for glib_size_type, more
changes are needed later in configure.in where it does a

case $glib_size_type in
...

I also notice that configure.in tests:

case $ac_cv_sizeof_void_p in
$ac_cv_sizeof_int)  glib_gpi_cast=''glib_gpui_cast='' ;;
$ac_cv_sizeof_long) glib_gpi_cast='(glong)' glib_gpui_cast='(gulong)' ;;
*)  glib_unknown_void_p=yes ;;
esac

Surely ac_cv_sizeof_void_p will be 8? Won't that then set
glib_unknown_void_p=yes which will cause echo '#error SIZEOF_VOID_P
unknown - This should never happen' ?

I downloaded the 64-bit mingw cross-compiler (the one hosted on 32-bit
Windows) and tested cross-compiling. But actually I really should
install 64-bit XP or Vista on some suitable machine. Not that I have
that many to choose from.. it will have to be the one in the living
room that mostly acts as a media machine now.

I committed a change to configure.in in trunk that (as far as I can
see) when run using 64-bit mingw produces a correct glibconfig.h that
matches rhult's patch in this thread. I still need to go through your
changes and commit them as such or slightly modified. I will also make
sure it compiles for 64 bits without warnings.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: working version of GTK for win64

[Tor Lillqvist]

> I have been doing some 64-bit building as well, and used the attached patch
> for the sizes/types.

Thanks. Committed to trunk.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: working version of GTK for win64

[Tor Lillqvist]

(Sorry for replying a bit late.)

>  I've tried to build and run gtk for 64-bit Windows. At last I can upload
> working version for usage:

Great! I hope people who are interested will try them out. (Personally
I don't have any machine running 64-bit Windows, unfortunately.)

> http://rapidshare.com/files/130142295/gtk-2.12.9-win64-devel.zip.html
> http://rapidshare.com/files/130142294/gtk-2.12.9-win64-src.tar.bz2.html

>  For build I've use cross-compile mode for mingw compiler:

Nice.

> with CFLAGS="-s -O2 -mms-bitfields".

Is the -mms-bitfields flag still needed for Win64? I am a bit
disappointed in that case, why can't they simply make it the default?
Presumably for Win32 it was noticed only when gcc had been available
for a while that there are differences in struct packing compared to
the "official" ABI, and they then introduced that switch (which
actually first was named -fnative-struct). But as gcc for Win64 is a
relatively recent development, why not be struct packing compatible
with MSVC from the beginning?

> $EGREP -e 'file format pe-i386(.*architecture: i386)?' >/dev/null ; then

> to
> $EGREP -e 'file format pe-(.*architecture: i386)?' >/dev/null ; then

Hmm, this needs to be filed in upstream libtool, I guess. Will take a
while before such a patch, if accepted, then trickles down into actual
tarballs, of course. So that is then something one must take care of
as part of the build process, add to one's build scripts.

> and in glib/gmain.h for polling:
>
> #ifdef G_OS_WIN32
>  void* fd;
> #else
>  gint  fd;
> #endif

Hmm, GLib already has:

#if defined (G_OS_WIN32) && GLIB_SIZEOF_VOID_P == 8
  gint64fd;
#else
  gint  fd;
#endif

isn't that enough?

>  3) for all Windows API calls in gtk/gdk/win32 use new declarations:
> SetWindowLongPtr instead of SetWindowLong, GWLP_HWNDPARENT for
> GWL_HWNDPARENT and so on.

Could you produce a proper patch, and file a bug and attach the patch please?

> From my point of view it will be very useful to
> incorporate code changes or some cleanups which work with win32 and win64
> versions of gtk and we'll continue to use gtk libraries in more areas and
> applications.

Yep. I will work on integrating the necessary changes into trunk in SVN.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gdk_cursor_new_from_pixmap color parameters no effect in MS windows

[Tor Lillqvist]

Please file a bug report at http://bugzilla.gnome.org (product: gtk+,
component: win32) and attach a minimal but complete sample program to
reproduce the problem as a single C or Python source file.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Adding more "gstdio" wrappers

[Tor Lillqvist]

> Wouldn't most of those be deprecated in favour of their GIO equivalents?

I don't think GIO will deprecate the C library;)

In other words, sure, GIO is a good thing, and newly written code
(that one knows will be run on systems with GLib 2.18 or later) surely
should use that as much as possible and maybe then not C library
functions. But for lots of existing code, it would/will be much
simpler to just change C library calls to the corresponding gwrappers
than to change to GIO.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Adding more "gstdio" wrappers

[Tor Lillqvist]

It would make it easier for people who build GLib-using code using
recent Microsoft compilers (Visual C++ 2003, 2005 and 2008) if there
were "gstdio" wrappers for all C library functions that pass file
descriptors (including the file descriptor that is a member in FILE
structs).

Another thing that would benefit from more wrappers would be >2GB file
support on Windows.

So I suggest adding the wrappers listed at the end. On G_OS_UNIX they
would simply be #defines, like most of the current ones in gstdio.h.
Would this be acceptable?

Background information: The problem that this would help solve is
caused by the unfortunate fact that there are several C libraries (as
shared libraries) on Windows The GNU toolchain ("MinGW") builds code
that uses the msvcrt.dll C library, and the prebuilt GLib (and GTK+)
binaries on ftp.gnome.org are built with MinGW. Recent Microsoft
compilers (the last three versions, after the venerable MSVC6)  each
build code that use a C library that is specific to the compiler
version (msvcr71.dll, msvcr80.dll, msvcr90.dll).

"file descriptors" (the small integers as returned and used by the
open(), read(), write(), fdopen() etc functions) are references to
data in the C library instance, not the operating system. So for
instance the file descriptor returned by g_file_open_temp() can not be
passed to write() in user code compiled by Microsoft Visual C++ 200x.

The original rationale for the gstdio wrappers was the file name
issue: file names on Windows are actually in Unicode, but the strings
one passed to the "normal" functions like open(), mkdir() etc are in
an encoding specific to the Windows localisation on the machine (the
"system code page"), and can not express all possible file names. To
handle all possible file names, one must use the "wide" (wchar_t)
versions of these functions. Thus the gstdio wrappers, and all other
GLib functions that return file names or take file name parameters,
use UTF-8 on Windows. GLib converts the names between wide character
strings and UTF-8 and calls the wide character API.

Adding wrappers because of the file descriptor issue would mean that
the name of the gstdio.h header is even more misleading than today
(not all functions wrapped in it have anything to do with stdio). So
probably it should be renamed to gwrappers.h. gstdio.h can not be
removed, obviously, but it would not be "advertised" in documentation
any longer and it would just #include .

The list of new wrappers:

g_read(), g_write(), g_close(), g_seek(), g_tell(), g_dup(), g_dup2(),
g_fileno(), g_pipe(), g_ftruncate()

g_stdin, g_stdout, g_stderr

g_fdopen(), g_setvbuf(), g_setbuf(), g_fread(), g_getc(), g_fgetc(),
g_putc(), g_fputc(), g_fwrite(), g_scanf(), g_fscanf(), g_feof(),
g_ferror(), g_fseek(), g_ftell(), g_rewind(), g_fflush(), g_fclose()

g_popen(), g_pclose();

Did I forget some?

g_printf(), g_fprintf(), g_vprintf(), and g_vfprintf() already exist,
and they function fine as is, no separate new wrappers for them are
needed.

g_stdin, g_stdout and g_stderr would on Windows be macros that expand
to calls to functions g_win32_get_stdin() etc that return the
corresponding FILE pointers in the C library GLib uses. On POSIX they
would just expand to stdin, stdout and stderr.

g_seek() and g_fseek() would take gint64 offsets.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK 3.0: an app developer's view

[Tor Lillqvist]

> 20 years ago, everyone was hand-coding assembly routines.

We were? I think you are generalising slightly. 20 years ago, I would
assume most programmers were happily writing Cobol, Fortran, Pascal,
C, etc high-level languages.

("high-level" compared to machine language, that is. Of course, in the
academic world, people have always been busy inventing even higher
level languages. And some of them have even eventually been used for
"Real Work".)

 >Today, more and more behaviour is moving into "higher"
> level constructs, softcode, bytecode interpreters, etc..

The bytecode concept (that specific term wasn't used though) was
invented over 40 years ago...

> 30 years ago, everyone hand-picked their registers for individual assembly 
> statements.

We did?

Please understand that many "advanced" concepts are not necessarily
that new at all. People were programming in Lisp *40* years ago, at
least. And Lisp surely is quite far from "hand-picking registers".
Smalltalk is over 30 years old. So is Prolog. Not much register
hand-picking in APL, PL/1, Fortran, Pascal, Cobol or Simula either, to
pick some old languages.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Is this a bug of GMainLoop?

[Tor Lillqvist]

> Yu's patch, to *current* trunk giowin32.c (I just committed a change
> that improved the G_IO_WIN32_DEBUG output a bit) is as follows. Please
> test it, all who can. (It should be trivial to apply it manually to
> the glib-2-16 branch, too.)

Hello, anyone ? Please...

--tml

> Index: glib/giowin32.c
> ===
> --- glib/giowin32.c (revision 6898)
> +++ glib/giowin32.c (working copy)
> @@ -849,6 +849,13 @@
>  if (channel->debug)
>g_print ("\n  setting last_events=0");
>  channel->last_events = 0;
> +
> + if ((event_mask & FD_WRITE) && !channel->write_would_have_blocked)
> +   {
> + if (channel->debug)
> +   g_print (" WSASetEvent(%#x)", watch->pollfd.fd);
> + WSASetEvent ((WSAEVENT) watch->pollfd.fd);
> +   }
>}
>   break;
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Is this a bug of GMainLoop?

[Tor Lillqvist]

> I will try your suggestion, too, and try to check whether it affects
> adversely the use patterns of GIOChannels and main loops in some other
> applications.

As far as I could see briefly testing, Yu's patch didn't have any ill
effects. I would love if more people could test it, though.

(There was a slight glitch in the context of the patch in Yu's
message, maybe a copy/paste error? I mean the line
"channel->last_events = 1;" which actually is "channel->last_events =
0;" in the source.)

Yu's patch, to *current* trunk giowin32.c (I just committed a change
that improved the G_IO_WIN32_DEBUG output a bit) is as follows. Please
test it, all who can. (It should be trivial to apply it manually to
the glib-2-16 branch, too.)

--tml

Index: glib/giowin32.c
===
--- glib/giowin32.c (revision 6898)
+++ glib/giowin32.c (working copy)
@@ -849,6 +849,13 @@
  if (channel->debug)
g_print ("\n  setting last_events=0");
  channel->last_events = 0;
+
+ if ((event_mask & FD_WRITE) && !channel->write_would_have_blocked)
+   {
+ if (channel->debug)
+   g_print (" WSASetEvent(%#x)", watch->pollfd.fd);
+ WSASetEvent ((WSAEVENT) watch->pollfd.fd);
+   }
}
   break;
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Is this a bug of GMainLoop?

[Tor Lillqvist]

> But I don't know whether it affects other part of glib program.

That is indeed the problem;) The code in giowin32.c is extremely
fragile and somewhat ad-hoc. I spent several hours yesterday going
over the debugging output, attempting small changes here and there. (I
didn't come up with your suggested patch, but some similar ideas.) I
will try your suggestion, too, and try to check whether it affects
adversely the use patterns of GIOChannels and main loops in some other
applications.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Is this a bug of GMainLoop?

[Tor Lillqvist]

Have you, by the way, verified that the corresponding program works on Linux?

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Is this a bug of GMainLoop?

[Tor Lillqvist]

> and think of the vast amount of gtk+ based software
> out there, it's quite unlikely that you hit a massive bug like this.

I wouldn't be so sure actually. As far as I can see, Yu's sample
program might well use GIOChannels and watches of them in a new way
that hasn't been tested before... I am still debugging it and trying
to understand what is actually going on. There might very well be some
clear bug in giowin32.c that is triggered here. (But whether fixing
that bug so that Yu's program works won't then cause some other
program to fail is another thing...) (There are bug reports open
against giowin32.c that contain patches even that I haven't had the
courage to apply for the same reason...)

That is the problem with the GIOChannel and main loop stuff on
Windows; there are so many ways one can combine the calls that it is
very hard to verify that everything that is supposed to work actually
does. On Unix the GIOChannel and main loop implementations are much
more straightforward, and it is likely that it works whatever
innovative new way a programmer uses it...

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [PATCH] Use autopoint for GLib

[Tor Lillqvist]

It's pretty trivial to effectively disable NLS without GLib knowing by
writing a minimal dummy libintl.c (and corresponding libintl.h) and
compile it into a "fake" libintl.a, and then point the GLib configury
at those with CPPFLAGS and LDFLAGS.

I did something similar mainly for Windows, but somebody told me it is
useful on MacOSX, too: a "proxy" libintl that dynamically tries to
load and use the real libintl, and falls back to nop semantics if it
isn't found. The point with this is that end-user application
packagers can then decide whether to include the real libintl binaries
in their package or not, but still use the same GLib binaries in both
cases. After all, if an app isn't localised, it doesn't make much
sense if (just) messages from GLib (or GTK+) are localised. See
http://ftp.gnome.org/pub/GNOME/binaries/win32/dependencies/proxy-libintl-20080418.zip
.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ 2.12.9 released

[Tor Lillqvist]

>  Should we remove the "dependency" link and switch over to ftp.gnome.org
>  for the other links too?

Personally I have long tried to suggest dumping ftp.gtk.org altogether
and instead making that an alias for ftp.gnome.org, and creating
suitable symlinks there so that at least some old links still would
work.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: glib cygwin build patch.

[Tor Lillqvist]

> Glib currently doesn't build on cygwin. I attached a patch that fixes it.

Thanks, committed.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Move to LGPL3

[Tor Lillqvist]

>  If this would be the case, than it
>  wouldn't be possible for GPL code to use something like the Windows
>  API or DirectX either.

And don't forget proprietary Unixes with proprietary C libraries. That
was after all the expected runtime for the original GPL programs (like
Emacs, gcc, bison, etc) that existed long before there was any LGPL C
library on a GPL kernel to run them.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Minutes: Foreign OSes BoF

[Tor Lillqvist]

>  Will cairo move away from libpng too?

If somebody just writes the code, I think it would be accepted to have
a configure-time choice to either use GDI+ or libpng on Windows. Dunno
what the Mozilla folks think.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Minutes: Foreign OSes BoF

[Tor Lillqvist]

> (Unless there is some way to read and
>  write text chunks also through GDI+ after all.)

GDI+ does provide access to *some* tEXt chunks that it knows about a
priori. At least the Description chunk is available as
PropertyTagImageDescription and the Software chunk as
PropertyTagSoftwareUsed. But that doesn't help, as libgimpthumb wants
to read and write chunks that GDI+ has no idea about, like Thumb::URI
and Thumb::X-GIMP::Type.

This is a design mistake in the GDI+ library IMHO... Surely they have
known that in many image formats one can have a set of arbitrary
tag-value pairs, and they should have provided a way to access these,
not just those properties they chose to enumerate in GdiPlusImaging.h.

Oh well, we will have to continue using the libpng-based PNG loader
then. We could link libpng statically, though, if we want to minimize
the number of "external" DLLs we depend on.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Minutes: Foreign OSes BoF

[Tor Lillqvist]

> This change would still break the thumbnailing system built into
>  libgimpthumb. This code uses the PNG module from gdk-pixbuf to load and
>  save thumbnails and it relies on the ability to read PNG text chunks
>  from PNG images and to set the PNG text chunk when creating PNG files.

Ah, thanks for the heads-up. This means we can't use a GDI+ -based
gdk-pixbuf loader for PNG then. (Unless there is some way to read and
write text chunks also through GDI+ after all.)

>  It's also important to support the JPEG quality option on the JPEG save 
> module.

That is handled, yes. Also setting the PNG compression level is possible,

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Minutes: Foreign OSes BoF

[Tor Lillqvist]

Tentative patch at http://tml.pp.fi/gdip-in-gtk.diff . Comments, please.

By default, with this patch, the GDI+ loaders are built when targeting Windows.

If one uses the --with-included-loaders (without any further
specification) option to configure, the GDI+ loaders (and the others,
too) are built-in, otherwise they are built as DLLs.

If one uses --disable-gdiplus-loaders, no GDI+ loaders are built, and
instead the "traditional" ones are built.

Other combinations of options probably won't work, or require listing
all the gdip-foo loaders, or something like that. Will have to work on
this. Or maybe all this optionality is unnecessary bling when
targeting Windows, and it should just always build the GDI+ loaders
and the non-external-library ones as built-in.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Minutes: Foreign OSes BoF

[Tor Lillqvist]

> Hmm, there are the ImageCodecFlagsSupportBitmap and
>  ImageCodecFlagsSupportVector bits in the ImageCodecInfo::Flags field,
>  is that enough?

Apparently not. Running the attached test program (from the Plaform
SDK docs, with some additions) prints for me on XP:

Decoders:
 image/bmp: *.BMP;*.DIB;*.RLE: Built-in BMP Codec
  BMP
  Encoder Decoder SupportBitmap Builtin
 image/jpeg: *.JPG;*.JPEG;*.JPE;*.JFIF: Built-in JPEG Codec
  JPEG
  Encoder Decoder SupportBitmap Builtin
 image/gif: *.GIF: Built-in GIF Codec
  GIF
  Encoder Decoder SupportBitmap Builtin
 image/x-emf: *.EMF: Built-in EMF Codec
  EMF
  Decoder SupportBitmap Builtin
 image/x-wmf: *.WMF: Built-in WMF Codec
  WMF
  Decoder SupportBitmap Builtin
 image/tiff: *.TIF;*.TIFF: Built-in TIFF Codec
  TIFF
  Encoder Decoder SupportBitmap Builtin
 image/png: *.PNG: Built-in PNG Codec
  PNG
  Encoder Decoder SupportBitmap Builtin
 image/x-icon: *.ICO: Built-in ICO Codec
  ICO
  Decoder SupportBitmap Builtin
Encoders:
 image/bmp
 image/jpeg
 image/gif
 image/tiff
 image/png

Note that for EMF and WMF it just says "SupportBitmap" like for the
true bitmap formats. Sigh.

--tml
#include 
#include 
#include 

using namespace Gdiplus;

int 
main (int argc, char **argv)
{
  // Initialize GDI+.
   GdiplusStartupInput gdiplusStartupInput;
   ULONG_PTR   gdiplusToken;

   GdiplusStartup(&gdiplusToken, &gdiplusStartupInput, NULL);
  
   UINT  num;// number of image decoders
   UINT  size;   // size, in bytes, of the image decoder array

   ImageCodecInfo* pImageCodecInfo;

   // How many decoders are there?
   // How big (in bytes) is the array of all ImageCodecInfo objects?
   GetImageDecodersSize(&num, &size);

   // Create a buffer large enough to hold the array of ImageCodecInfo
   // objects that will be returned by GetImageDecoders.
   pImageCodecInfo = (ImageCodecInfo*)(malloc(size));

   // GetImageDecoders creates an array of ImageCodecInfo objects
   // and copies that array into a previously allocated buffer. 
   // The third argument, imageCodecInfos, is a pointer to that buffer. 
   GetImageDecoders(num, size, pImageCodecInfo);

   // Display the graphics file format (MimeType)
   // for each ImageCodecInfo object.
   printf("Decoders:\n");
   for(UINT j = 0; j < num; ++j)
   { 
 printf (" %S: %S: %S\n"
 "  %S\n",
 pImageCodecInfo[j].MimeType,
 pImageCodecInfo[j].FilenameExtension,
 pImageCodecInfo[j].CodecName,
 pImageCodecInfo[j].FormatDescription);
 printf (" ");
#define BIT(x) if (pImageCodecInfo[j].Flags & ImageCodecFlags ## x) printf (" 
%s", #x)
 BIT (Encoder);
 BIT (Decoder);
 BIT (SupportBitmap);
 BIT (SupportVector);
 BIT (SeekableEncode);
 BIT (BlockingDecode);
 BIT (Builtin);
 BIT (System);
 BIT (User);
#undef BIT
 printf ("\n");
   }

   // Ditto for encoders
   GetImageEncodersSize(&num, &size);
   pImageCodecInfo = (ImageCodecInfo*)(malloc(size));
   GetImageEncoders(num, size, pImageCodecInfo);
   printf("Encoders:\n");
   for(UINT j = 0; j < num; ++j)
   { 
  printf(" %S\n", pImageCodecInfo[j].MimeType);   
   }

   free(pImageCodecInfo);
   GdiplusShutdown(gdiplusToken);
   return 0;
}
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Minutes: Foreign OSes BoF

[Tor Lillqvist]

>  * The loader's "create by type" function uses the module's name (i.e.
>  "gdi+" or "png"), rather than a mime-type. Lots of programs assume a
>  1:1 relationship (eg. "give me the 'wmf' loader").

OK, so the internal interface between the gdk-pixbuf "main" code and
built-in loaders could then be enhanced (without affecting the public
API) so that gdk-pixbuf upper level code creates as many
"pseudo-loaders/savers" as needed when a built-in loader/saver tells
that it actually supports multiple formats. That way to the user
programs it would still be a 1:1 relationship between "pseudo-" loader
name and image types.

>  * The query-loaders mechanism requires that the supported formats be
>  known ahead of time

With built-in GDI+ (and ani, pnm, ras, xpm etc) loaders, no
gdk-pixbuf.loaders file is needed.

>  * There is no way that I know of to distinguish between a
>  metafile/vector format and a raster format, except maybe to try
>  loading everything as a metafile and see if something fails.

Hmm, there are the ImageCodecFlagsSupportBitmap and
ImageCodecFlagsSupportVector bits in the ImageCodecInfo::Flags field,
is that enough?

>  * The functions that enumerate GDI+'s loaders simply don't exist in
>  the 1.0 version of the GDI+ DLL.

Are you sure? The sample program from the GDI+ documentation in the
Platform SDK that lists encoders using GetImageDecodersSize() and
GetImageDecoders() works fine for me on XP. The version of the
GdiPlus.dlls I find in the WinSxS folders is 5.1.3102.2180.

I really would love to be able to have the GDI+ loader as a built-in...

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Minutes: Foreign OSes BoF

[Tor Lillqvist]

While hacking on integrating the GDI+ loader into the GTK+ tree I
started wondering: If we build the GDI+ loader into the gdk-pixbuf DLL
(instead of having it as a separate DLL), then it should be possible
to determine the supported formats at run-time, right? (And thus
automatically get support for whatever new formats are added to GDI+,
or have been added on the machine by installing some extension or
plug-in to GDI+.)

Presumably the GDI+ loader would then have to appear to gdk-pixbuf as
two separate loaders, one for the read-only formats, and one for the
read-write ones, even if both are implemented in the same source
file(s).

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Minutes: Foreign OSes BoF

[Tor Lillqvist]

>  GIMP will continue to link in libpng, libjpeg, and etc., so
>  that won't be affected by this regression.

Yep. GIMP needs all the information it can get, especially for JPEG,
where it needs to actually have a look at the quantization tables from
the image file.

I think it should be fine to start integrating gdip-pixbuf-loader into
gtk+/trunk now then? Will start on it this evening, probably, unless
somebody else beats me to it.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Minutes: Foreign OSes BoF

[Tor Lillqvist]

>  I think that they're ready to go. Outside of the GTK+ tree, they won't
>  get much testing.

Do you think they cam unconditionally replace the "traditional"
loaders that depend on external libraries for Win32, or should we add
some --disable-gdiplus-loaders switch to the configury?

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Minutes: Foreign OSes BoF

[Tor Lillqvist]

>  Relatedly, I believe we should also consider bundling the 'native'
>  pixbuf loaders that have seen the light of day recently.

Sure. Will do soonish for the Win32 GDI+ one.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Using more verbose ChangeLog format for GLib and GTK+

[Tor Lillqvist]

>  I believe we are meant to put the patch author's name on the first line.

I do that sometimes. Especially if the patch author bothers to include
a patch for ChangeLog, too (patch authors, please do take this as a
hint...). But if it is a random smallish one-off patch and I don't
even know if the author is comfortable with having his/her email
address in the ChangeLog, I usually just mention the author's name in
the entry.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: glib gio win32 directory monitor

[Tor Lillqvist]

>  I suppose the directory can be changed but no other name crossed my mind  
> then.

Ah, sorry. I hadn't been paying attention, I now see that indeed gio
has separate subdirs for inotify and fam, so it does make sense then
to have this in the same way in a separate subdir.

> Also, it could be linked-in just like the inotify monitor,

Yes.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: glib gio win32 directory monitor

[Tor Lillqvist]

>  I don't know if there's any interest / work in progress on this, but
>  noticing that the new Gio implementation lacks a directory monitor for
>  windows I wrote one (patch against 2.15.4 attached, should work on
>  2.15.5 too)

This is great! I am sure this will gladly be accepted into GLib
sources. (I am not sure about the use of a new "gio/win32" directory,
though. That has not traditionally been done in GLib. But that's of
course just a triviality easy to change.)

Please open a bug report in bugzilla.gnome.org and attach your source
code there.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [WWW] Broken link to pkg-config

[Tor Lillqvist]

>  On http://www.gtk.org/download-windows.html the links to pkg-config are  
> broken.

Fixed now.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib and 64-bit Windows

[Tor Lillqvist]

> does struct timeval use 32 or 64 bit fields on win64?

Is uses "long", so 32 bits.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ Website Review - Hosting Windows Binaries

[Tor Lillqvist]

> 1. Would anyone object to putting the Windows binaries on the gtk.org
> site instead of Tor's site? It makes sense to me to have it there. Tor,
> any input here?

The binaries *are* on ftp.gtk.org (actually more completely on
ftp.gnome.org). With my "site" you probably mean the
www.gimp.org/win32/downloads.html page, which just has links to
ftp.gnome.org. This downloads.html page would fit better on
www.gtk.org indeed, especially as there isn't much GIMP-specific on
the page any more.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Suggested even/odd convention for the micro version numbers (like cairo)

[Tor Lillqvist]

> Is this a current problem now?

Not a major problem, as far as I know.

I was prompted to (re-?) post the suggestion by a message to the
evolution-hackers list where it was suggested that Evolution changes
from using pre-release version bump to using post-release bump. So
clearly at least some people find it important and beneficial that
right after a release the version in SVN is incremented, to clearly
separate the release and subsequent development. Presumably, other
people then again have the opposite view, they find it important that
the version is incremented when a release is made, to make a clean cut
between the development up to the release and the actual release.
Doing both pre- and post-release bumping should satisfy both groups,
shouldn't it?

> Would  there be any other advantages?

Not as far as I know.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Suggested even/odd convention for the micro version numbers (like cairo)

[Tor Lillqvist]

I humbly suggest that the versioning recommendation for the GTK+ stack
and GNOME in general is amended for the third "micro" part of the
version numbers to match the convention used in cairo.

See http://cairographics.org/manual/cairo-Version-Information.html .

In a nutshell, the idea is that released tarballs have an even micro
version. The micro version is bumped both immediately before and after
building the release tarball. The even micro number is never committed
to SVN. In SVN the micro number is always odd.

This has the advantage that there is never any confusion whether
pre-release or post-release bump is used. Code from a SVN checkout can
always be recognised by its odd micro number, and correspondingly code
from a released tarball is recognised by its even micro number.

One could imagine a module using a macro FOO_IS_DEVELOPMENT_VERSION()
that would return true either if 1) the minor version is odd (as the
convention already is in most (?) GNOME modules), or 2) the micro
number is odd (a build from SVN, presumably thus intended for local
hacking and not distribution).

I guess one disadvantage of this is that it might take a time before
people stop asking "what happened to version x.y.z". Also, one
probably needs to script the bump-make dist-bump sequence in order not
to forget it, at least initially.

I think the use of this convention is regarded as a success by people
working on cairo?

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Static compose table in gtkimcontextsimple.c

[Tor Lillqvist]

I wrote:
> > a "dead"
> > accent followed by a letter can be mapped to the corresponding
> > precomposed character without an explicit table.

On 06/12/2007, Paul LeoNerd Evans <[EMAIL PROTECTED]> wrote:
> Really..? Last time I checked, the precomposed letters weren't in any
> particularly easy-to-find locations;

Well, obviously there has to be some tables somewhere (in GLib's case
I guess it's in the generated header files like gunicomp.h), but I
meant, the information shouldn't have to be effectively duplicated in
gtk.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Static compose table in gtkimcontextsimple.c

[Tor Lillqvist]

> GDK_dead_circumflex, GDK_C, 0, 0, 0, 0x0108, /* 
> LATIN_CAPITAL_LETTER_C_WITH_CIRCUMFLEX */
> [...]
> GDK_dead_circumflex, GDK_c, 0, 0, 0, 0x0109, /* 
> LATIN_SMALL_LETTER_C_WITH_CIRCUMFLEX */
> [...]

The sequences you list are exactly of the straightforward kind that in
my opinion can and should be handled algorithmically. I.e. a "dead"
accent followed by a letter can be mapped to the corresponding
precomposed character without an explicit table. I have a patch in bug
#321896 that implements such an algorithm (and which would handle your
cases, too.) Basically it's waiting for a second opinion from the GTK+
maintainers.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list