of tools.
Kean Johnston
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
On 3/28/2011 1:12 PM, Paul Davis wrote:
On Mon, Mar 28, 2011 at 5:35 AM, Kean Johnstonkean.johns...@gmail.com wrote:
Hello everyone,
GtkApplication is a rather new piece of the GTK API. There has been
quite a bit of discussion about its role and its impact on cross
platform portability.
I'll
Yes I'm sorry about that. I innocently assumed it would be properly
portable as everything in GTK+ is portable, and there was no
proper notation that the application object was not available
on win32 or osx (like say, GtkUnixPrint widgets).
For the most part it seems that GTK+'s portability holds
The former windows maintainer doesnt have time anymore [2] to do the
windows binaries, so any help is very welcomed
Pedro,
You and I should talk. I too have compiled up everything for Win32 (busy
testing Win64 at the moment). My particular solution is a bit broader as it
compiles everything
There is no separate devel list for glib or gio, it all happens here.
Thanks for the info. I have some ideas I need to mull around for a bit
that I'll post about in the near future.
For the GtkApplication part I just think someone will have to spend some
time on the GtkApplication code making
$TITLE says it all
Kean
--- gio/glib-compile-schemas.c.orig.jUX 2011-03-14 00:52:40 +0200
+++ gio/glib-compile-schemas.c 2011-03-29 15:00:33 +0200
@@ -26,7 +26,9 @@
#include gstdio.h
#include locale.h
#include string.h
+#ifdef HAVE_UNISTD_H
#include unistd.h
+#endif
#include stdio.h
i think that this message was too long and contained too many issues.
i believe you'll get more traction if you:
(a) divide the issues
I wanted to do that but they are all pretty inter-related. I guess the
discussion on gstdio could be separate.
(c) attach fixes where applicable
Well, GApplication should grow a Win32 backend. I don't quite think
that's rethinking or a good bit .. it's just filling in the
missing bits...
Yeah I did perhaps over-state it :)
But in other good news further examination of glib showed me that it
already wraps, or provides if the system
On 4/7/2011 4:29 PM, Colin Walters wrote:
If your application deals with uids, I think you're going to end up
with platform-specific code; the complexities around identity are just
too high. That goes doubly for inode numbers, which - why would you
care unless you're a backup app, and then
But the dependency to the CRT is not the problem, if there is only one of
them in process.
Agreed, but that is becoming almost impossible to guarantee. If we go to
any lengths to ensure a binary-compiled Glib is linked against msvcrt.dll,
and an average Windows user uses VS2010, they will run
I've long had this dream of perfectly relocatable gnome libraries/apps
where the executable file itself contained all the information it needs.
Relocating something like that is trivial (LD_LIBRARY_PATH is all that
is needed).
Not even that. Check out the very-often overlooked ELF feature of
For simplicity, suppose that your all-in-one-files have the extension
.glick. Suppose also that we have a per-user-per-system daemon
watching (relevant parts of, such as only ~/Downloads, ~/Desktop and
~/Applications) $HOME for such files. That daemon could then make
resources in each .glick
On 8/7/2011 8:16 PM, Dieter Verfaillie wrote:
On 07/08/2011 19:33, Kean Johnston wrote:
I am trying to compile master on Windows. gclosure.c doesn't compile due to
not having ffi.h. The presence of this is not tested in configure, and
there is no mention of it being a requirement in INSTALL
GLib sources, but the response that I receive is that there is no plans
(at least at that time) to include the libFFI sources in the GLib sources,
and that was from one of the core devs, AFAICT.
I wonder if its a philosophical objection or just that no-one has signed up
to do it. Perhaps one of
asking for love without giving anything back in return except
complaints after the fact is not conducive to a positive development
Check your facts. I am hard at work trying to get Win32 up to speed. I'm
submitting patches when they are ready. I am doing a LOT of debugging,
experimentation
On 9/7/2011 6:34 PM, Shawn Bakhtiar wrote:
EmmanuelYour an ass (as in donkey)
Everyone just HAS to vent their spleen, don't they? I don't know John so
maybe I am off base here but I'm fairly certain he is capable of defending
himself quite well without that sort of useless comment.
On 9/8/2011 8:34 AM, Anders Broman wrote:
Hi,
Has the provision of binary bundles for Windows 32 bit and 64 bit been
discontinued?
I can't speak for the devs but I am putting together a full bundle for both
win32 and win64, including all of the dependent libraries. It's not quite
bleeding
As we would prefere to use binaries endorsed/provided by the project I
guess it's +1 for moving to another tollkit :-(
I think we may have prof-of-concept Qt code. A lot of work I had hoped
could be avoided.
I'd hold off on that decision for a week or two if I were you. Please give
me time to
Dieter has been speaking with the gtk developers on IRC, and has been
Would it be inappripriate to ask that that type of discussion happens on
the mailing list? Unless IRC logs are stored, they are ephemeral, can't be
searched or referred back to at a later date etc, and only have visibility
If there is consent amongst the team and this is available, I can set up
the gtk.org pages for this.
There isn't consent. Some people are against the notion of having GTK+ be a
shared component due to two main concerns (both addressable):
1. The myriad issues surrounding the choice of CRT to
That's a really bad idea for several reasons. First, we don't have the
resources to test ABI compatibility on windows, there has been cases where
some versions have crashed windows apps.
Are you talking about ABI compatibility between varying GTK releases or
between various Windows releases? If
At least bundling everything with my app let's me sleep at night, knowing
some unknown installer out there is not going to break my stuff which has
taken countless hours to build.
Why do you think this is unique to Windows? If you create a .rpm or .deb
that depends on version x.y.z of some
In theory, I agree with what you're trying to achieve here. However,
in practice I think there would be better places to direct your energy
- keeping in mind Windows takes up about 2GB of disk space these days,
12MB of DLL's for each of the maybe 10 Gtk apps I have on Windows
While I agree with
Note that many of us build programs with MinGW, so for such suite to be
useful, it should provide GCC-compatible import libraries.
If MinGW can't use standard microsoft import libraries that (from my
perspective) is Someone Else's Problem. The entire set of libraries
compiles easily enough on
Maybe it would be a good idea to stop insisting our
beloved GNOME platform should only have 1 blessed set
of binaries for Windows altogether and embrace the
diversity that has been created. All these options
are there for a reason. All of them. At the end of
Now THAT, good sir, is the most
And how exactly is doing that different from what we
already have today: libglib-2.0-0.dll?
Not in the least. The names were for illustrative purposes not intended to
be gospel.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
AFAIK, VC can use gccs .a files directly, but the other way around isn't
possible (since the .lib files don't contain something that gcc/ld needs).
Thanks for teh data point, I will certainly look into this.
As for Windows programmers preferring VS, this may be true, but is it also
true when
I'm pretty sure every reasonable installer won't let you overwrite newer
file version with an older one.
This is Window's we're talking about ... my faith is a little less than
yours :)
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
- use a __attribute__((constructor)) approach
That sounds wildly non-portable. It would break MSVC compilation for
openers, and any other compiler that is not-GNU.
Kean
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
On 9/19/2011 3:36 PM, Alexander Larsson wrote:
On Sun, 2011-09-18 at 13:11 -0400, Ryan Lortie wrote:
- use a __attribute__((constructor)) approach
I see you raised the portability concern, forget my previous mail
Unfortunately this is a pragma, which doesn't expand macro arguments, or
is
https://bugzilla.gnome.org/show_bug.cgi?id=660095
Its small, it doesn't affect anything except Windows and it fixes an actual
build problem if your environment does have dirent.h. Thank you.
Kean
___
gtk-devel-list mailing list
In at least gstdio.c, possibly other places (I am still looking) there is a
lot of code to use the wide versions of various functions like stat,
because it is assumed that the input argument is UTF-8 and the CRT doesn't
support UTF-8 directly but rather Microsoft's own multibyte character set
Won't that fail on filenames that have characters outside of the active
codepage instead?
Sure but that will actually fail rather than silently succeeding with an
incorrect value.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
But which is more likely to happen - user having a filename with foreign
characters, or user having a symlink (which on Windows can only be created
by administrators)...
You asked the question slightly incorrectly: which is more likely to
happen: a user have a file on their filesystem that
MBCS isn't able to represent all the characters (though depending on the
codepage, it does cover a fair amount), but that's not really relevant -
how do you represent тест in CP-1250?
Give that to me as a sequence of wchar_t's and I'll figure it out :)
But which is more likely to happen - user having a filename with foreign
characters, or user having a symlink (which on Windows can only be created
by administrators)...
Are you sure about that (I havent had the time to create a quick
application that tests this) but
user. The ordinary user is unlikely to create any symlinks, and I'm
not even sure that _wstat would be called when selecting the linked
file for opening in the file chooser.
Forget about a file chooser. I want to write a utility. I want to be able
to stat files and get their sizes to display how
I'm sure. Open an unelevated command prompt and use the mklink command.
That could be weirdness with the mklink command. I'll write a test using
the actual API's.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
Couldn't GLib directly use GetFileAttributesExW instead, or does this
Sadly the file attributes constants dont have anything like
FILE_ATTRIBUTE_SYMLINK etc, so we wouldn't be able to determine if the file
is a symbolic link or not. Which I guess would be OK because this is
g_stat() not
It's not - symlinks are intentionally restricted to administrators to
prevent the security issues they would introduce in applications predating
symlink support.
Ah ok cool, useful information, thank you!
___
gtk-devel-list mailing list
FWIW I'm in favor of 64 bit time fields, as the event horizon for
32-bit fields is only 27 years away. Even if you think that it's very
unlikely that any present day programs will still be used in 27 years,
you can think of this as enabling Unix timestamp calculations with
dates much further into
On 9/27/2011 9:08 AM, Steve Frécinaux wrote:
On 09/26/2011 08:59 AM, Kean Johnston wrote:
Here's how I would define
the GStatBuf data type:
Won't you break ABI if you're changing the layout of the struct on
linux/unixes? As I understand this is not an issue on Windows since
everyone ships
I disagree that we don't have an ABI to maintain on Windows. I think
people on Windows are somewhat likely to download precompiled binary
versions of our DLLs for use with developing their software (since the
build process is so complicated). We can easily introduce extremely
difficult-to-debug
time_t is typically a signed long, which is 64bit on all 64bit linux
versions.
Even more good reason to standardize then.
I don't see what advantages this gives you. It will break all existing
code that uses g_stat and struct stat, you can't share GStatBuf with
other struct stat using code,
Do you have a use case where hash-table lookups would be a bottleneck?
Small mobile devices. Devices with only 64MB of RAM to play with. Embedded
devices. Just because GLib is used mainly in GNOME don't make the
assumption its the ONLY place. Not every deployment of GLib applications is
on a
The problem is that stat is API from the 1970's. None of us really
So is malloc. So is chmod. They are wrapped.
want to prolong the life of code with such readable names as S_IFMT,
S_IFREG, st_blksize and EBADF. One of GIO's design goals was to come
up with a fully portable, modern abstraction
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.
Instead, we should
if GIO is measurably slower at doing I/O than a stat(), please: file
bugs along with profiling data.
This is WAY off topic but still ... how can you possibly believe it is NOT
slower? One system call versus:
1. Allocate arrays
2. Allocate hash tables
3. Do strdups
4. Calculate hashes
5.
Of course GIO is slower when you look at the LoC count, the question
is for the typical case is performance acceptable. If your
application is opening a million files then maybe it's not typical.
Maybe my application runs on a router and not on an 64-core Core i5000 with
16 petabytes of RAM.
If you are happy limiting yourself to a single platform and don't need
some the magic that comes with GIO, feel free to use stat(). It's not
UNIXWARE, SCO OpenServer, AIX, Solaris, MacOS X, Windows, Linux,
FreeBSD, OpenBSD, NetBSD, Minix, HP-UX ... did I miss any platforms? I'll
consider
Not sure if we're supposed to announce patches or just file bugs with
patches and wait (please educate me) but in case we are, please consider
the following small patches:
https://bugzilla.gnome.org/show_bug.cgi?id=660730
https://bugzilla.gnome.org/show_bug.cgi?id=660095
The only location device_manager is set (that I know of) is in
_gdk_input_init() in gdk/win32/gdkinput.c
1) is _gdk_input_init() called before you hit this problem?
2) Does the g_object_new (GDK_TYPE_DEVICE_MANAGER_WIN32, ...)
call in there return something sensible?
Actually I found the root
Sounds like that's related to D) No input devices are detected
from https://bugzilla.gnome.org/show_bug.cgi?id=653437#c4
Sadly, making it just load the DLL without a full path didn't fix this
problem. This really is a sequencing problem. That wintab initialization is
simply happening too early.
So one of the things I've been working on for my own purposes is to create
a full set of libraries for Win32 in order to be able to run GTK apps. My
intention is opposite to the typical advice given for GTK: I *want* this to
be a shared component, with a friendly installer, upgrade path etc
To those with commit powers,
There are three bugs that have stalled. I would greatly appreciate it if
someone could give them some attention.
https://bugzilla.gnome.org/show_bug.cgi?id=660095
https://bugzilla.gnome.org/show_bug.cgi?id=660731
https://bugzilla.gnome.org/show_bug.cgi?id=660761
Can any people interested in the win32 code please try this out and
report any issues, regressions against gtk-2-24 or just things that are
broken on windows related to windows and events.
I just updated jUXtapose to your code and things look OK to me. I'm not
100% sure exactly what your changes
Please can glib devs give https://bugzilla.gnome.org/show_bug.cgi?id=660761
a little love? Its been a month and a half since I posted the last patch
and there has been no traction on it.
Thanks in advance,
Kean
___
gtk-devel-list mailing list
57 matches
Mail list logo
