Hi there - I've been using Glib for Windows programming for over a year and am
very pleased with it. I'm still on the version I first downloaded (2.24) but
I've no particular objection to upgrading if this problem's already been
fixed
The problem itself is that 'g_rename()' only works
On 25 Mar 2012, at 10:20, John Emmas wrote:
'g_rename()' only works properly (in the Windows version) if there are no
open handles to the file being renamed. On Linux, I think a file can be
renamed at any time - even if some process already has it open. A handle is
a handle
On 26 Mar 2012, at 17:53, Stef Walter wrote:
Reaching back into my memory of windows development past here ... but won't
reading/writing to such a windows file handle after a rename/delete return an
error?
Hi Stef - I've only tried writing to a renamed file, which does work (with my
On 26 Mar 2012, at 18:44, John Emmas wrote:
On 26 Mar 2012, at 17:53, Stef Walter wrote:
Reaching back into my memory of windows development past here ... but won't
reading/writing to such a windows file handle after a rename/delete return
an error?
Hi Stef - I've only tried
On 26 Mar 2012, at 19:26, John Emmas wrote:
the only relevant cases are rename() and MoveFile() - and of course
g_rename() - all of which now work.
Oh - one thing I'm struggling with is sharing permissions.
If a process opens a file read only should this deny write access to any
I made the changes that were needed to make g_rename() more consistent but
they're fairly extensive and would probably benefit from being reviewed by
somebody else. Initial reports from our end though, seem to suggest that the
renaming issue is greatly improved (on Windows).
But is this
On 31 Mar 2012, at 18:55, Tristan Van Berkom wrote:
The appropriate thing to do next would be to create a patch against glib
git master, open a bug report in gnome bugzilla (if one does not exist
for the g_rename() issue yet, please try to search for an existing bug first)
and then attach
On 31 Mar 2012, at 18:55, Tristan Van Berkom wrote:
Yes this is the right mailing list to discuss glib development.
The appropriate thing to do next would be to create a patch against glib
git master, open a bug report in gnome bugzilla (if one does not exist
for the g_rename() issue
that - or the
documentation's wrong).
Can anyone confirm if this is a bug or intended behaviour? If it's a bug, is
it fixed yet in the latest glib version? Thanks though for an otherwise great
product.
John Emmas
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http
On 23 May 2012, at 00:22, Krzysztof Kosiński wrote:
What you get is an URI encoding of the UTF-8 bytes. I think this is
the expected and correct behavior: there are multiple incompatible
locale encodings and there's no way for this function to know what
encoding you want to use for the URI.
On 23 May 2012, at 08:40, Jürg Billeter wrote:
U+00F6 is the Unicode codepoint but URI percent encoding never directly
uses codepoints as you can encode only a single byte at a time and the
range of Unicode codepoints is much larger than that (up to U+10).
As Krzysztof already wrote,
On 23 May 2012, at 10:05, John Emmas wrote:
Still a bit confused really... :-(
Not any more
My confusion arose from the fact that the notes for g_filename_to_uri() (i.e.
the note inside gconvert.c) states that its based on the requirements of RFC
2396:-
http://www.ietf.org/rfc
On 21 Jul 2012, at 05:32, Michael Torrie wrote:
Now that you mention this, I have noticed practically no traffic on any
of the devel lists in the last few years. I am probably not alone in
thinking GTK development had stalled (though GTK 3 is obvious evidence
to the contrary!)
[...]
On 21 Jul 2012, at 13:54, Emmanuele Bassi wrote:
So, I would like a concrete proposal: how do you think we can change this
trend?
Well the first requirement would be to identify the problem(s). I'm guessing
that the biggest problem for developers is the huge amount of their free time
On 22 Jul 2012, at 02:14, Michael Torrie wrote:
I consider web-based forums to be the scourge of the internet.
Curiously, that's exactly how I feel about mailing lists. Mailing lists work
well as long as the volume of traffic is relatively low. They probably also
work well if you're a
On 22 Jul 2012, at 15:02, Michael Torrie wrote:
On 07/22/2012 04:20 AM, John Emmas wrote:
That's been my experience anyway.
With no facts stated to support your response, it is merely your
opinion. My opinion is also just an opinion
Michael - you're right to say that both viewpoints
On 22 Jul 2012, at 20:44, Simon Feltman wrote:
It does not really matter how developer discussions take place as long as
they are documented and searchable. Transparency of reasoning behind
decisions is just as important as the decision for anyone trying to
understand the code base. For
Maybe a year or so ago I built glib from source, using MSVC. I downloaded the
source in a zip file of some sort and it was then (approximately) at version
2.24.
A few days ago I decided to re-install my sources from git, so that I can keep
everything up-to-date. I'm just trying to repeat the
On 29 Nov 2012, at 18:33, Matthias Clasen wrote:
We cut out pcre source files that are not needed for the gregex
functionality - it is quite possible that the vs project files haven't
be adapted after the latest pcre update.
Thanks Matthias, that did turn out to be the problem. I simply
On 30 Nov 2012, at 09:49, John Emmas wrote:
3) In the Windows build, function g_get_monotonic_time() makes a call to the
Windows function 'timeGetTime()'. AFAICT this is only available from
mmtimer.lib which, in turn, is only built for ARM processors (not x86
processors).
I stand
On 30 Nov 2012, at 14:14, Fan Chun-wei wrote:
Hi John,
It shouldn't require pthreads at all. Please make sure that gthread-posix.c
is not among the files you build, as it is not a source meant for native
Windows builds.
Thanks Fan,
I just checked that I wasn't accidentally including
On 30 Nov 2012, at 14:44, Simon McVittie wrote:
You might need to define G_ATOMIC_LOCK_FREE to tell GLib to use that
implementation?
On 30 Nov 2012, at 14:50, Fan Chun-wei wrote:
Can you check the glibconfig.h that you are using? As you are using Visual
C++, it needs to match the
On 30 Nov 2012, at 17:10, John Emmas wrote:
BUT are the symbols files up to date? For example 'glib.symbols' gets
used to generate 'glib.def' which, in turn, determines which functions get
exported from my DLL. If any of the symbols files are out-of-date I guess
that might screw
As many of you will know, GTK's MSVC project files have gotten quite a long way
out of date now (presumably since Tor's departure, which was a great pity).
I'm trying to bring mine up-to-date so that they'll build from the latest GIT
sources. I'm starting with glib which is currently at
On 26 Dec 2012, at 19:20, John Ralls wrote:
ARGV should be a hint: It means the same thing in perl as it does in C. It
seems that glib-mkenums either isn't getting an @ARGV or it's somehow getting
cleared before that line.
Thanks John. I think the fact that ARGV[0] is involved might be
On 26 Dec 2012, at 20:12, John Ralls wrote:
If you run:
perl -e 'print(join(\n, @ARGV));' foo bar
you should get the output
foo
bar
Do you?
No John, in fact I got this output
Can't find string terminator ' anywhere before EOF at -e line 1.
To be certain, I copied and
On 26 Dec 2012, at 20:12, John Ralls wrote:
If you run:
perl -e 'print(join(\n, @ARGV));' foo bar
you should get the output
foo
bar
Hi John, I discovered something quite interesting this morning... I have 5
different versions of Perl installed (on different machines) - namely:-
On 27 Dec 2012, at 10:05, kevin.a...@ubs.com wrote:
I just tried on my Windows machine in a regular cmd.exe (command
window). You need to change the double quotes. Windows be damned!
I always forget to translate single quote to double quote. Windows
cmd.exe gives some very strange
Hi Fen,
I'm sure you're right about the tarball VCPROJ files being up-to-date but the
stable tarballs themselves are a long way out of date. At least it seems so,
if this web page is to be believed:-
http://www.gtk.org/download/win32.php
According to the information there, version 2.28.8 is
Thanks for everyone's help with this. The problem with glib-mkenums did indeed
turn out to be a missing list of header files. Now that I've added that,
things are getting a lot further. MSVC users might be interested to hear that
I'm now tantalizingly close to being able to build glib using
On 29 Dec 2012, at 09:55, David Nečas wrote:
Anything ending with .in is usually processed by configure
(config.status) which you obviously don't have so you must replace
@VARIABLE@s with the corresponding values using whatever you have. But
the only two variables present there are unused
On 29 Dec 2012, at 16:41, John Ralls wrote:
That's because gio/gdbus-2.0/codegen/config.py doesn't exist, but
config.py.in does -- another file that needs to have its @variables@
substituted -- in this case @datarootdir@, @prefix@, and @VERSION@.
This one *is* done by configure, which
On 29 Dec 2012, at 21:12, John Emmas wrote:
On 29 Dec 2012, at 16:41, John Ralls wrote:
That's because gio/gdbus-2.0/codegen/config.py doesn't exist, but
config.py.in does -- another file that needs to have its @variables@
substituted -- in this case @datarootdir@, @prefix
I've come to the conclusion that gio has a missing set of enumerations of this
form:-
typedef enum {
G_REGISTRY_BACKEND_blah
G_REGISTRY_BACKEND_blah_blah
G_REGISTRY_BACKEND_blah_blah_blah
etc
} GRegistryBackend;
which should either be in gio/gioenums.h or alternatively,
On 31 Dec 2012, at 17:53, David Nečas wrote:
This all goes to a strange direction.
First, GRegistryBackend is not an enum, it is a subclass of
GSettingsBackend. glib-mkenums will not generated
g_registry_backend_get_type() for you.
The get-type function g_registry_backend_get_type()
On 30 Dec 2012, at 16:40, jose.ali...@gmail.com wrote:
It seems you are missing the empty __init__.py in the codegen/ directory.
This is a requirement for a directory so python may consider it as a package.
On 30 Dec 2012, at 16:36, John Ralls wrote:
Hmm. Your python doesn't seem to
On 1 Jan 2013, at 15:54, John Emmas wrote:
If anyone has a flash of inspiration, please let me know.
I had a flash of inspiration myself...
Traceback (most recent call last):
File
F:/+GTK-SOURCES/gnu-win32/src/glib/gio/gdbus-2.0/codegen/gdbus-codegen.in,
line 39, in module
On 30 Dec 2012, at 16:36, John Ralls wrote:
Hmm. Your python doesn't seem to agree that codegen is a package, in spite of
being imported into gdbus-codegen.
On 30 Dec 2012, at 16:40, jose.ali...@gmail.com wrote:
I don't know if this is related, but It seems you are missing the empty
On 13 Jan 2013, at 11:36, Kevin Connor Arpe wrote:
Hello,
I am relatively new to this project. On 26 Dec 2012, I submitted a (mostly)
documentation patch, but I have seen no reviews/comments.
https://bugzilla.gnome.org/show_bug.cgi?id=690737
What is the normal process?
For this bug
On 4 Jan 2013, at 10:49, Matthew Brush wrote:
From the last few messages on this thread, it kind of sounds like your module
search path is not set up correctly, that is, Python doesn't know where to
look to import your modules/packages (try print(sys.path) to see which
paths I mean).
On 19 Feb 2013, at 15:37, Bernhard Schuster wrote:
I would like to see that information - even if I have no instant use
for it - but I am pretty sure it will help a lot of people digging for
information.
No problem. At the moment, I've made a couple of dozen changes in my efforts
to track
On 20 Feb 2013, at 21:44, Markus Elfring wrote:
Why do you prefer to use an enumeration instead of the other general
application
programming interface?
Hi Markus. Until a couple of days ago I'd never even encountered GVariant so
forgive me if I've misunderstood the concept - but from
On 20/02/2013 06:50, Fan Chun-wei wrote:
Hi John,
I'm sorry if this sounds a bit off-topic, but can you check your
Visual Studio 2005 build (if I recalled correctly, that's the version
of Visual Studio you are using) of
gspawn-win32-helper.exe/gspawn-win32-helper-console.exe whether
I just discovered an interesting Perl script in my main 'glib' folder.
It's a small script called 'win32-fixup.pl' and I've reproduced it below
(after adjusting shebang for my particular system). It looks like the
intention is to iterate through some files and change various
declarations
On 24/02/2013 08:34, John Emmas wrote:
Can anyone tell me what the correct syntax is for running the script?
I tried perl win32-fixup.pl (without any command-line options) and
although it did work, it only processed the first file in the list and
then skipped the others.
I realised what
I recently built libglib (version 2) using MSVC. I noticed that there
are several dozen test modules available (i.e. 'C' source modules) but
it looks as if they all need to be built as individual apps. Does
anyone think it would be a good idea to have one app that could run all
the tests?
On 6 Mar 2013, at 12:14, Tristan Van Berkom wrote:
Is this question stemming from the fact that you got glib to
compile using MSVC, where I suppose you are hacking the source
tree severely and not using the autotools/makefiles at all ?
I wouldn't say I've hacked anything too severely
On 06/03/2013 13:33, Jernej Simončič wrote:
This isn't actually true - while msvcrt.dll originally was VC6
run-time, it's nowadays a Windows component, and every new Windows
version comes with an updated msvcrt.dll. Every Windows component
links to it, and you can create programs that link to
On 06/03/2013 13:03, Tristan Van Berkom wrote:
On Wed, 2013-03-06 at 12:41 +, John Emmas wrote:
Undoubtedly, yes. If you build the binaries with MinGW, then later
change something and rebuild, MinGW does not seem to guarantee that
the second build will use the same ordinal values as your
On 06/03/2013 14:06, Allin Cottrell wrote:
In GTK development, series with an even minor number (6 in this
case) are stable while those with an odd minor number are work in
progress.
That's really interesting Allin. I had no idea about the odd / even
thing but it's a great idea.
John
On 06/03/2013 14:24, Jernej Simončič wrote:
I distribute GIMP built with MinGW (actually cross-compiled from Linux)
You mean you run MinGW under Wine or something like that?
John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
Hello guys,
This morning I updated from git and found a minor problem in
glib/gatomic.c. At around line 530 there's a section of code that looks
like this:-
/* mingw32 does not have MemoryBarrier.
* MemoryBarrier may be defined as a macro or a function.
* Just make a failsafe version for
Hi Behdad - to answer your questions:-
On 08/03/2013 00:33, Behdad Esfahbod wrote:
Do all versions of MSVC have MemoryBarrier? In that case, we should
make sure we never try the function path for MSVC. Perhaps I should
just do that for mingw32?
I had to do some research into this so I may
/* mingw32 does not have MemoryBarrier.
* MemoryBarrier may be defined as a macro or a function.
* Just make a failsafe version for ourselves. */
#ifdef MemoryBarrier
#define _GMemoryBarrier MemoryBarrier
#else
static inline void _GMemoryBarrier (void) {
long dummy = 0;
On 09/03/2013 09:42, Behdad Esfahbod wrote:
Humm. I thought I removed the MemoryBarrier fallback completely. Where are
you seeing inline?
Oh, how strange... I just did another pull and now it works fine!
I'm using TortoiseGit on Windows and I must admit, I've seen a few
little funnies
On 06/03/2013 23:34, tarn...@tarnyko.net wrote:
Thanks, didn't know GTK+ used the odd/even versioning method, you
people are all really helpful !
Just out of curiosity - I'm assuming that when the minor number becomes
even, it probably doesn't stay even for very long. Suppose I wanted to
Hi there,
This morning I built libatk v2.7.91 (Windows / MSVC) from the latest git
code (downloaded about 4 days ago). Having built the library I decided
to build the two test modules. Unfortunately, testrelation.c gave me
this error at run-time:-
Relation test module loaded
On 22/03/2013 14:27, Piñeiro wrote:
On 03/22/2013 01:05 PM, John Emmas wrote:
Note that the actual entry has no hyphen. I'm assuming that the test
and the table entry can't both be right. Which should I change? The
table entry or the test? Thanks.
This is a bug on the test. On GNOME we
Hi Alejandro,
I just committed a second bug report for another test that's failing. I
realise that neither of these is urgent. Best regards,
John
https://bugzilla.gnome.org/show_bug.cgi?id=696466
___
gtk-devel-list mailing list
If I'm working on an application which still uses GTK+ version 2, is it
still possible to obtain the sources (using subversion or git) or is
version 2 only available from tarballs now?
John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
On 24/03/2013 13:12, Paul Davis wrote:
git clone git://git.gnome.org/gtk+ http://git.gnome.org/gtk+
cd gtk+
git checkout --track -b gtk-2-24 origin/gtk-2-24
That worked, thanks!
John
___
gtk-devel-list mailing list
On 08/04/2013 14:09, Ryan Lortie wrote:
A 'const gchar **' is (in this case) an array of 'const gchar *' (ie:
const string pointers). It is the strings that are immutable. The
array itself is fully writable, and indeed you should free what
g_variant_get_bytestring_array() returns to you,
On 16 Apr 2013, at 00:24, Michael Torrie wrote:
Is it desirable
to continue to compile against msvcrt.dll instead of a more recent,
VS-compatible version? Is the issue simply one of licensing for the dll
itself (IE distributing it to Linux environments to compile against is
not
On 16 Apr 2013, at 10:38, Fan Chun-wei wrote:
The latest stable release tarballs of GLib, Pango, ATK, GDK-Pixbuf and GTK+
(2 and 3) should be building as long as the dependencies outlined in
https://live.gnome.org/GTK%2B/Win32/MSVCCompilationOfGTKStack are met. Please
let us know via
The last time I updated glib (from git) was around a fortnight ago. I'm
building using MSVC but up until now, everything's been building and
running okay.
This morning I updated to the latest git sources and re-built (after
adding a new source module, 'gio/gbytesicon.c'). Everything still
On 28/04/2013 15:33, Colomban Wendling wrote:
Proposed patch fixing the test attached. Regards, Colomban
Thanks Colomban. The patch looks promising but I can't seem to apply it
with TortoiseGit (error = patch format detection failed). The only
obvious difference I can see between your
On 28/04/2013 16:37, John Emmas wrote:
The only obvious difference I can see between your patch and my others
is that you seem to be using Git v1.7.10.4 whereas I'm still on v1.7.10.1.
I'll ask on the TortioseGit mailing list to see if that really is the
problem.
Hi Colomban,
I posted
On 28/04/2013 17:45, Colomban Wendling wrote:
That's not normal, and I'm afraid it's your email client that did
something wrong. If I fetch the attachment from my mail I get the
exact patch Git generated, which doesn't include this weird character.
Yes, you were absolutely right. I tried a
Just updated from Git and tried to build libglib using MSVC. The build
fails because a couple of files are now referencing 'STDOUT_FILENO'
and/or 'STDERR_FILENO'. From the (admittedly, limited) research I did,
it seemed as if they're only relevant for *nix, bash and Wine. Here are
the
On 19/05/2013 12:23, John Emmas wrote:
Just updated from Git and tried to build libglib using MSVC. The
build fails because a couple of files are now referencing
'STDOUT_FILENO' and/or 'STDERR_FILENO'. From the (admittedly,
limited) research I did, it seemed as if they're only relevant
On 20/05/2013 13:45, Erik van Pienbroek wrote:
When an executable is built with '-mwindows' (instead of '-mconsole') then
there is no stdout/stderr by default. To get a stdout/stderr one has to use
the win32 API functions AttachConsole and freopen which in turn will
return different file
On 20/05/2013 14:44, Erik van Pienbroek wrote:
So when there is no valid stdout/stderr the fileno call will return
either -1 or -2. When this value is passed as argument to a write call,
then the write call itself will fail with an 'invalid file descriptor',
but other than that there's shouldn't
On 20/05/2013 17:09, John Emmas wrote:
A few lines further down, 'total' gets incremented like this:-
total += nwrote;
So if nwrote == (-1) we'll probably get stuck in an endless loop :-(
Actually, is there a bug here anyway? Here's what that section of code
looks like currently
On 22/05/2013 18:53, Dan Winship wrote:
fixed now, along with using stdio instead of write(), so it should
compile again on Windows now.
Great stuff Dan, thanks. It seems to be working fine now.
John
___
gtk-devel-list mailing list
Inside the 'gdk' source directory there's a file called testgdk.c. Is
it considered to be up-to-date? In other words, if I build it, should
the tests pass?
Having recently built gdk from source (on Windows 7, 32-bit) I decided
to compile and run that module, just to see what happens - but a
On 27/05/2013 08:22, John Emmas wrote:
One test which seems to always fail is the test at line 493:-
case GDK_NOR:
QTEST (newpixel == (~oldpixel ~mask));
FWIW if I change the test to this, it always seems to pass:-
case GDK_NOR:
QTEST (newpixel == (((~oldpixel
On 28/05/2013 01:38, Matthias Clasen wrote:
git log will tell you that the last non-cosmetic edit of that file was
in 2000. So: no, not an up-to-date or useful test. It doesn't exist in
the current tree, even.
Thanks Matthias, I should have mentioned that I'm working with the most
recent
I just wondered if someone could help me with something that's puzzling me
about a recent Glib commit...
On 27th May, Dan Winship made a commit whose description is Add Makefile.glib
and GLIB_CONFIG configure macro. According to my Git package (TortoiseGit) it
looks as if the following two
On 31 May 2013, at 09:15, John Emmas wrote:
what would cause the appearance that some files have been removed when
(apparently) they're still present and needed. Maybe they did get added back
later but I just can't find it?
Ah, I think maybe the penny just dropped from a closer
On 05/06/2013 00:26, Timothy Arceri wrote:
Thanks John. I have attached a document with all the Windows bugs. Broken down
into three categories.
1. Testing needed (old bugs that need to be confirmed still exist)
2. Bugs that someone can probably start work on right away.
3. Bugs needing some
.
John Emmas
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Thanks guys.
My memory is hazy now but from what I can recall, any lines like this
were always problematic;-
from . import some_module
No matter what I did, I couldn't get (Windows) Python to understand what
from . meant. If the module to be imported was in a subfolder - e.g.
On 18/07/2013 02:04, Fan Chun-wei wrote:
I also ran Python 2.7 in both x86 and x64 flavors in the same way
Tarnyko ran the script (which I built myself using Visual Studio, so
this is a native Windows build/version of Python, running under
cmd.exe), and this worked for me too.
Thanks
Just a long shot but can anyone tell me where to obtain the sources for
CairoCanvas (either git / svn / tarball or whatever). I don't know if
I'm typing all the wrong stuff into Google but it seems remarkably
difficult to track down. I found something called 'Lazarus' (which I
took to be a
On 03/09/2013 10:39, Emmanuele Bassi wrote:
hi;
the Cairo graphics library is available at: http://cairographics.org
there is no CairoCanvas that I know of.
Hi Emmanuele,
I was sure there was something called CairoCanvas. I must be getting
mixed up. Thanks.
John
I just updated libglib from git and discovered that a new function got
added to 'glib/gio/glocalfile.c'. The new function is called
g_local_file_measure_size_of_contents() and I think there are a couple
of other functions supporting it.
g_local_file_measure_size_of_contents() appears to
On 11 Sep 2013, at 19:10, John Emmas wrote:
g_local_file_measure_size_of_contents() appears to assume a posix compliant
compiler. It calls opendir(), readdir() and closedir() and therefore cannot
be compiled with MSVC. Maybe there's a #define somewhere that I haven't
noticed or maybe
On 11/09/2013 23:16, A. Walton wrote:
The best way to get this reviewed is to get on IRC, get the attention
of one of the GLib
maintainers, and have them review the code. Ryan Lortie (desrt on
IRC) wrote that code,
so he's probably the first person to run this change by.
On 11/09/2013
On 12/09/2013 12:05, Fan Chun-wei (范君維- wrote:
Hello John,
The case in gdir.c is that it includes the dirent.h and wdirent.c to
provide for MSVC builds, which was also what my initial patch tried to do.
Hope this explains it a bit.
Yes it does, Fan. Well spotted.!
So the real problem here
On 17/09/2013 17:22, Ryan Lortie wrote:
GLib 2.37.92 contained a couple of bugs in the new
g_file_measure_disk_usage() so I did a 2.37.93 to fix them. This should
be the one used in the upcoming release.
Slightly off topic but how do I find out when the upcoming stable
version gets
On 23/09/2013 22:44, Ryan Lortie wrote:
hi all,
I just branched off GLib 2.38 as glib-2-38.
'master' is now fully unfrozen and will become 2.40.
Off topic, slightly - but does anyone know if glibmm will be creating a
corresponding branch - i.e. glibmm-2-38 to match with glib's new branch?
I'm not sure if this is the right place for my question but if not,
maybe someone will point me in the right direction
About 2 years ago I built the Ardour DAW which was then at version 2. I
built it for Windows, using MSVC. Naturally there were a few problems
but eventually it all
Thanks for the advice, guys. I should be able to try your suggestions
either today or tomorrow.
However, on a less obvious note the product I'm working on (Ardour)
does already use its own theme which (I think) gets handled by
Clearlooks. I hope it's not a dumb question - but if Ardour
TEST: a couple of my posts to this list have failed to turn up (after
48 hours!!) so I'm just trying from a different email client. Sorry for
the noise.
John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
Hi guys - is this an appropriate place for posting questions about ATK?
I tried looking for a specific ATK mailing list but I couldn't find
one. Please let me know if I'm posting in the wrong place.
Anyway, my question concerns the version numbering strategy for libatk.
When updating from
On 18/11/2013 17:54, Piñeiro wrote:
There is not mailing list for ATK. We usually use
gnome-accessibiliy-devel [1] for any question about any of the GNOME
accessibility modules.
Thanks Piñeiro, I'll try to remember in future - though admittedly I've
got a pretty bad memory... :-)
Version
On 22/02/2014 22:30, Syed Akbar wrote:
I am afraid this is might not be the right place to ask: there is a
dnd problem with GTK + Win 7/8 + Kaspersky or TuneUp Utilities or
Camtasia. I've tried to debug the problem, but I am not very familiar
with C/C++ and Win32 programming.
I just
On 23/02/2014 10:55, Syed Akbar wrote:
I am able to provoke the error purposefully as desired (just starting
and closing Kaspersky). I then decided to try to solve it on my own
although I am no expert in C/GTK/Win32 development.
Hi Syed,
Unfortunately, I'm not on the GTK+ development
On 28/03/2014 03:38, William Swanson wrote:
Before ctrl+c and ctrl+v were standardized, a lot of old MS-DOS
software used ctrl-insert for copy and shift-insert for paste. I'm
surprised these old shortcuts are still supported.
Most Windows programs still support them and it's probably a good
Currently I'm building from gtk-2-24. I updated this morning and
discovered that 'gdk/win32/gdkselection-win32.c' no longer builds with
MSVC. The problem is in function
'_gdk_win32_selection_convert_to_dib()' which is at approximately line
1280. The problem is caused by the recent addition
1 - 100 of 358 matches
Mail list logo
