Re: [glib] malloc and bdwgc

[Krzysztof Kosiński]

On Jan 11, 2016 7:03 PM, "张海"  wrote:
>
> Yes, but the point of my previous email is that the third-party
GC_malloc() might eventually call malloc() itself, and by defining a
malloc() in my program, GC_malloc() will again call into my malloc() and
then GC_malloc() until stack overflow. Do you think this will happen?

One possible solution is to use something like libunwind to look at the
call stack. If your malloc detects it is called recursively, call
__libc_malloc instead of GC_malloc.

> Meanwhile since glib provides basic data structures for developers to
build their own data structure upon, and developers should be able to
decide which allocator their own data structure should use, I still think a
GMemVTable should be conceptually necessary. Is there anything that
prevents this from being implemented, for example with a
g_mem_vtable_init_hook() function? (Are weak symbols possible to be
portable? Or if not, missing such feature will still prevent many
applications from migrating to the new version of glib.)

It looks like almost nobody used this feature, and it had a performance
impact, so it was removed.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: A Gtk's build system ?

[Krzysztof Kosiński]

2014-08-05 15:41 GMT+02:00 Bernhard Schuster schuster.bernh...@gmail.com:
 If this ever happens, I hope for waf to get some traction, it is way faster
 and has the power of py and also prevents all the version incompatibility
 issues on different host machines as one can ship the waf with the
 repository itself (or as a git submodule). Not to mention that it is very
 easy to extend and is well documented with plenty of examples. Enough adv.

I also support this. Waf is stupidly simple to use compared to
autotools, does not require silly lists of files to work, and things
such as generating a file from a script and then compiling it are much
easier to implement.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: A Gtk's build system ?

[Krzysztof Kosiński]

2014-08-06 21:43 GMT+02:00 Colomban Wendling lists@herbesfolles.org:
 Le 06/08/2014 21:30, Krzysztof Kosiński a écrit :
 [Waf] does not require silly lists of files to work

 If that refers to using globs in the build system files, don't.  Glob
 showed on many a situation to be the source of various build problems,
 including, but not limited to, a file to be missing from the source tree
 (which would not be easily noticeable and would work on the author's
 setup), or unexpected files to be included in a build.

I am not really convinced by this.

1. If there are any uncommitted files, version control will tell you about this.
2. If you have 'unexpected files' in the source tree, you are doing
something wrong.
3. Another common argument in favor of file lists is determining what
to include in the tarball. This is only an issue because by default
Autotools create a giant mess by putting generated files in the same
directories as the sources (CMake does this as well). Waf always puts
all generated files in a separate directory, so everything that's not
in the build directory should be distributed.

 Also, FWIW patterns can generally be used just fine in Autotools -- but
 again, please, don't use them.

Autotools can't correctly use patterns / wildcards, because it
requires manually re-running automake whenever a file is added or
deleted.
http://www.gnu.org/software/automake/manual/html_node/Wildcards.html
Waf stores a database of files seen on last build and therefore
doesn't suffer from this problem.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Krzysztof Kosiński]

2014-06-21 3:00 GMT+02:00 Jasper St. Pierre jstpie...@mecheye.net:
 To better support Wayland with fewer copies and less drawing artifacts, I've
 pushed some potentially breaking changes to GDK, namely around
 gdk_cairo_create and gdk_window_begin_paint_region.

 https://git.gnome.org/browse/gtk+/commit/?id=d48adf9cee7e340acd7f8b9a5f9716695352b848
 https://git.gnome.org/browse/gtk+/commit/?id=be30e440c350f0f3e0f2572f7f3eab54ef96af0e

 With these changes, it is now illegal to call gdk_cairo_create outside of a
 begin_paint / end_paint. This was always sketchy, and would never work on
 Wayland anyway. If your code does this, we will print a warning and return a
 dummy surface which won't ever be composited back into the main surface.

This will also break the GTK 3 version of Inkscape, which paints its
canvas in an idle handler, and the draw signal only marks areas for
redraw. However, it may be fixable by using the begin_paint APIs.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Krzysztof Kosiński]

2014-06-24 3:02 GMT+02:00 Jasper St. Pierre jstpie...@mecheye.net:
 May I ask why you can't paint in the draw signal? GDK already tracks
 invalidated windows marked by exposes and gdk_window_invalidate_rect itself.
 It should be as efficient as drawing in an idle handler, and also cooperates
 with the paint clock, where we can be synchronized to a compositor's redraw
 cycle.

If all drawing happens in the draw signal and the document has a lot
of demanding effects, e.g. SVG filters, it would completely kill
responsiveness of the UI. The idle handler solution also allows us
easily move drawing to a separate thread in the near future.

In general, the document displayed in Inkscape cannot be drawn in one
piece; it must be rendered as a series of strips that are shown on the
screen once they are ready. Otherwise it takes far too long.

Although I heavily rewrote the lower levels of Inkscape canvas (those
dealing with SVG objects) to use Cairo and generally cleaned it up,
the upper levels, dealing with editing controls and scheduling the
rendering, are still barely changed from the Sodipodi days. It is
certainly possible to do all drawing in a draw signal, for example by
submitting an invalidate request once a piece of the drawing has
finished rendering, but it will require a nontrivial amount of work.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Heads-up: Potentially breaking changes to the GDK drawing model pushed

[Krzysztof Kosiński]

 On Mon, Jun 23, 2014 at 9:59 PM, Paul Davis p...@linuxaudiosystems.com
 wrote:
 as Jasper noted in his reply, but i'll describe differently: it is one thing
 to draw (even in a separate thread) in a cairo surface that can later to
 used during an actual redraw. and certainly many programs have excellent
 reasons to do this to speed up redrawing. but this doesn't involving cairo
 drawing operations on the surface derived from a GdkWindow. you are drawing
 to an image surface that is basically just memory inside your process. you
 can do this from any thread, at any time.

I am aware of this difference, and Inkscape already renders to
intermediate memory surfaces rather than directly to the window in the
idle callback, but due to some legacy code it also draws the finished
surface to the window in the idle callback. What currently happens is:

- draw signal received
- queue exposed areas for rendering
- render in idle handler
- draw to window in idle handler

and, as far as I understand, what needs to happen is:

- draw signal received
- queue exposed areas for rendering
- render in separate thread
- invalidate part of the window corresponding to the completed rendering
- draw result to window in the draw signal handler

The only problem we have is that the part of the code that does the
above is very old (most of it is around 10 years old) and fairly
convoluted, so this change will require some effort.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Directional Images

[Krzysztof Kosiński]

2013/10/17 Jasper St. Pierre jstpie...@mecheye.net:
 I think the thing that we'd want is to have a separate RTL icon theme that
 inherits from the LTR icon theme, but overrides some icons with flipped
 icons. This can be done with a few tweaks to the icon-theme specification,
 and in GTK+.

I vaguely recall that once upon a time there were a few stock icons
with an -rtl suffix, which would be used instead of the normal icons
in an RTL environment.

This approach could be used with named icons too. When you request
some-icon in an RTL locale, the icon name resolver should first look
for icon-name-rtl, and if that doesn't exist in the theme, use
icon-name. I think this solution is both very simple and adequate.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Removal of icons in buttons/menus

[Krzysztof Kosiński]

2013/10/15 Ryan Lortie de...@desrt.ca:
   Any icon that comes before a menu item’s text should be laid out as
   if it is the beginning of the text...

 and

   In particular, icons of this sort should not go inside the margin...

 (...)

 GtkImageMenuItem puts its icon in the margin.  We don't ever want noun
 icons to appear here.

So this extremely ugly layout is actually *by design*?

That's very disappointing. I thought that displaying the menu icons in
this absurd place is actually an Ubuntu-specific bug in globalmenu,
and will eventually be fixed.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Stock Items Deprecation

[Krzysztof Kosiński]

2013/9/11 Emmanuele Bassi eba...@gmail.com:
 as the author of GtkRecentAction, I'm honestly not concerned.
 GtkRecentAction was a stop-gap that covered users of the old
 EggRecent* API, and was never really useful; in a sense, it was a
 class used to paper over a deprecation. shoving a bunch of recently
 used files with only the name and a 16 px MIME type icon as a
 differentiating feature in a menu (or in a toolbar menu button) always
 seemed to me like a very bad UI. the file selection widget has a
 better list of recently used files, these days.

The recently used files thing in the open dialog is utterly
confusing. It looks exactly like a directory listing, but the shown
files and directories are not actually in a single directory. The
first few times I encountered it, I thought there was some filesystem
disaster that mixed all my files together.

Maybe if the display was changed so that it did not resemble a
directory listing so much, it would be less confusing; but for now I
find this feature unusable.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Stock Items Deprecation

[Krzysztof Kosiński]

2013/7/18 Emmanuele Bassi eba...@gmail.com:
 support for those features has already been developed and it is going
 to be added to GAction before we release GLib 2.38 and GTK 3.10, and
 improved in the future so that it matches with the overall spirit and
 design of the API. if you want to influence where the API is going,
 you can start looking at how to port your code, what you think it's
 missing, and file bugs. dropping on irc.gnome.org, in the #gtk+
 channel, is also a good idea.

OK, I guess that answers my question.

 you should *really* read the document linked in Jon's email; it
 answers the questions about when and where icons should be used inside
 menus. it's not a blanket removal (and it's not something done to
 emulate OSX; please, refrain from making snap judgements in the
 future).

I read the document before posting, and it did mention that icons are
OK for noun menu items. However, in your initial post you said
GAction replaces GtkAction; images on menus have been discouraged for
years...', and I was not aware that a replacement for the
presentation-related functionality of GtkAction will be added to
GAction - so this sounded like the ability to add icons to menu items
would be removed completely.

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: bugzilla cleanup

[Krzysztof Kosiński]

2013/2/4 Matthias Clasen matthias.cla...@gmail.com:
 Hi everybody,

 a while ago, we've talked about getting a handle on the enormous
 number of open bugs in glib and gtk.

This bug, which makes GOption useless on Windows and has accumulated
93 comments so far, could be easily fixed (it has patches) if someone
finally decided which way is preferable.
https://bugzilla.gnome.org/show_bug.cgi?id=522131

Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: g_filename_to_uri() issue in glib-win32

[Krzysztof Kosiński]

2012/5/22 John Emmas john...@tiscali.co.uk:
 So for example, if the input string is Göran (encoded as UTF-8) I get the 
 wrong output (hopefully, you can see that the 'o' has an umlaut).  
 g_filename_to_uri encodes 6 characters and returns G%C3%B6ran instead of 
 encoding just 5 characters to return the correct URI string G%F6ran.

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. It would also fail if you had
characters not representable in the locale encoding.

This is at most a documentation bug. It should be stated that this
function converts the string byte-by-byte, and everything outside of
the 0-127 range is converted to hex escapes. (I think this is the only
sensible behavior for this function.)

Regards, Krzysztof
___
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)

[Krzysztof Kosiński]

2011/9/26 Jernej Simončič jernej|s-gm...@eternallybored.org:
 Won't that fail on filenames that have characters outside of the active
 codepage instead?

You can use g_win32_locale_filename_from_utf8() to obtain a short
filename (8.3) that will refer to the filename with unrepresentable
characters. You can then use it with narrow functions of the Windows
API. This will not work if short filename generation is turned off in
the registry. I don't know whether it's still turned on by default.

Regards, Krzysztof
___
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)

[Krzysztof Kosiński]

2011/9/26 Kean Johnston kean.johns...@gmail.com:
 Despire the
 coolness of Windows supporting time fields 64-bits wide for the least amount
 of pain it would probably be best if the time fields were left at 32-bits
 (although it would be really cool and forward thinking if we used 64-bits),

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 the future than possible now.

Regards, Krzysztof
___
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)

[Krzysztof Kosiński]

2011/9/26 Jernej Simončič jernej|s-gm...@eternallybored.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)...

Based on the bugs reported against Inkscape that were caused by this
kind of filename, I would say the former (foreign characters) is much
more common. A lot of users have English Windows but have a local
keyboard layout and name their documents in their local language (e.g.
Russian, Polish) which is not representable in latin1.

Regards, Krzysztof
___
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)

[Krzysztof Kosiński]

2011/9/26 Kean Johnston kean.johns...@gmail.com:
 Plus I am
 fairly sure (but not 100%) that MBCS can represent all of the characters
 UTF-16 can (which is what the _wstat function uses).

MBCS is misleadingly named in Microsoft documentation. It is not
always a multibyte encoding. It is a locale-specific encoding that
depends on your localization of Windows and AFAIK is guaranteed to be
ASCII compatible, and in many cases it is actually a single-byte
encoding. On English Windows, this is cp1252 which is almost identical
to iso8859-1. On Polish Windows, this is cp1250. On Chinese Windows
it's probably gb18030. And so on. In many versions, MBCS can only
represent a little more than plain ASCII.

Funny characters (e.g. Unicode characters not representable in the
MBCS / locale encoding) are in fact rather common and cause tangible
bugs when using narrow Windows APIs (e.g. Inkscape opens all
drawings normally but this one won't open!), while it's rather hard to
pin down a case where the symlink problem you mention would affect the
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.

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

Re: Fwd: Plans for GTK+ Bundles for win32 and win64?

[Krzysztof Kosiński]

2011/9/8 Kean Johnston kean.johns...@gmail.com:
 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.

If you have the DLL, you can generate the MinGW-compatible import
library using the pexports and dlltool utilities. I'm not sure if i
works with all DLLs, but it definitely does with the ones in the
binary Windows bundle.
http://wiki.inkscape.org/wiki/index.php/Inkscape_Devlibs#Generating_import_libraries_from_DLLs

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

Deprecated symbols list

[Krzysztof Kosiński]

Hello

I recently finalized the removal of all deprecated Glib symbols from
Inkscape [1]. Now I'm exploring removing some of the deprecated GTK
symbols.
This site [2] has a link to a list of deprecated symbols in HTML
format, but there is no text file which could be used with the
provided egrep command.

Can I generate the relevant gtk-deprecated-symbols.txt in some
automated way from GTK sources?

Regards, Krzysztof

[1] https://bugs.launchpad.net/inkscape/+bug/367606
[2] http://live.gnome.org/GnomeGoals/RemoveDeprecatedSymbols/GTK%2B
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Updated GTK+ 2.24.5 binaries (and bundle)

[Krzysztof Kosiński]

W dniu 12 lipca 2011 19:17 użytkownik Dieter Verfaillie
diet...@optionexplicit.be napisał:
 Fair enough, using a custom build tool on Windows is your choice,
 not mine ;)

Maybe I wasn't clear enough. I worked on *getting rid* of this
Windows-only build tool, but didn't succeed yet. FWIW, Waf appears to
work best for me.

 Also msys-perl has been updated. Check this thread:
 http://article.gmane.org/gmane.comp.gnu.mingw.user/36263
 There a good chance most intltool vs (Active)Perl hacks/workarounds
 described all over the net to get a working MinGW/MSYS build system
 for the GNOME platform going are no longer valid.

Looking at the timestamp of the message, it looks like I last tried
building Glib from a source checkout some time before this updated
Perl was released, so my information was outdated.

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

Re: Updated GTK+ 2.24.5 binaries (and bundle)

[Krzysztof Kosiński]

2011/7/12 Dieter Verfaillie diet...@optionexplicit.be:
 I have been dreaming of having an msys-python port though (considered by
 most to be even more exotic than cross-compiling Python itself, I guess).
 Would make jhbuild, but also other tools written in Python that need to
 run at build-time like gi-scanner, much more reliable. And we'd be able
 to get rid of loads of subprocessing workarounds/bugs...

I worked on a cross platform build system for Inkscape. Currently we
use Autotools on Unix-like platforms and a custom build tool on
Windows. because we decided that we cannot depend on MSYS. Here are my
$0.02:

The whole raison d'etre of MSYS is to allow Autotools to work. Once
you get rid of Autotools, you no longer need MSYS. And if you are
serious about portability, you need to get rid of Autotools anyway,
because the last available version of MSYS Perl can no longer run the
recent automake releases. This makes building from a source checkout
(not a tarball) on Windows impossible.

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

Re: About gsettings aborting on unkown schemas

[Krzysztof Kosiński]

2011/5/27 Havoc Pennington h...@pobox.com:
 Config schemas that contain type checking and default values are part
 of the program; the program is either incorrect, or redundant in a way
 likely to create bugs, without the schemas. If schemas were just docs
 or something, it would be a different situation.

I think it's OK for schemas to be mandatory for programs, but problems
start when the program has several optional modules or plugins with
each having their own schemas, and the main program does not require
any of those optional modules to meaningfully work. So g_settings_new
unconditionally aborting might not be a bug, but it is very
inconvenient for the programmer.

I think the following could be done to fix this problem:
a) provide a function called g_settings_schema_exists that would check
whether creation of GSettings for a given schema name would succeed
b) provide g_settings_try_new as suggested before

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

Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)

[Krzysztof Kosiński]

2011/4/18 Alberto Ruiz ar...@gnome.org:
 So yeah, .RPM/.DEB is absolutely fine for system level components
 (platform, shell...). But for applications, I have to say I really
 don't agree at all that it is the right mechanism, unless you come up
 with a sandboxed approach for apps installed by the user.

Apparently what's needed is some kind of per-user package manager.

Most things an application will need can be done by manipulating stuff
in the home directory. This includes things such as browser plugins. I
guess it would be best to ensure that application authors can use
every desktop feature without manipulating any root-owned files.

Automatically adding ~/bin to PATH if it exists and the .local
hierarchy are examples of this approach.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Glib: a Win32 discussion

[Krzysztof Kosiński]

2011/4/10 Tim Evans t.ev...@aranz.com:
 A combination of GetCommandLineW and CommandLineToArgvW can get you the
 arguments as wchar_t strings which could then be converted to utf8. Is this
 just something that glib needs to provide a convenience function for?
 g_win32_get_utf8_argv() maybe?

This is not about a convenience function. The real problem is that
GOption cannot parse UTF-8 argument lists. It will always consider the
argv to be in locale encoding, and the locale encoding cannot
accurately represent filenames on Windows. The input encoding for
GOption should be switchable at runtime.

Once GOption can parse UTF-8, the convenience function to get the
Unicode argv on Windows can be written. However, GetCommandLineW /
CommandLineToArgvW do not work, because globs are not expanded. You
need to use the function __wgetmainargs with glob expansion set to
true, the way it is used in glib/gspawn-win32-helper.c.
http://msdn.microsoft.com/en-us/library/ff770599.aspx

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

Re: Glib: a Win32 discussion

[Krzysztof Kosiński]

2011/4/6 Kean Johnston kean.johns...@gmail.com:
 Everyone,

 WARNING: long, detailed message. If you don't care about Win32, move on.

Other annoying Windows issues specific to glib:

1. GOption fails hard for filenames which are in a language different
than your Windows. E.g. Chinese or Russian filenames on English
Windows. The arguments passed to main() contain ? in place of the
Chinese / Russian characters and that's just not enough information to
correctly identify the file. More detail in the bug:
https://bugzilla.gnome.org/show_bug.cgi?id=522131

2. GApplication. Mentioned in the mail. This functionality is
traditionally implemented using named mutexes and shared memory.
http://stackoverflow.com/questions/2285110/restrict-application-to-one-instance-per-shell-session-on-windows

3. GSettings using the registry. This means portable apps (in the
sense of apps that you can carry with you on an USB stick:
http://portableapps.com/) cannot use it, because they have to store
the settings somewhere on the USB stick, not in the registry. It
should be possible to use dconf on Windows.

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

Patch review needed

[Krzysztof Kosiński]

Hello

There's a patch available for bug #522131 which severely affects the
usability of GOption on Windows. There is a patch available, but it
needs review. Can one of the developers look at it? It would enable a
few cross-platform applications to drop a dependency on popt.

https://bugzilla.gnome.org/show_bug.cgi?id=522131

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

Re: AC_MSG_RESULT(patching libtool to fix HIDEOUS BREAKAGE) [was Re:dconf 0.5]

[Krzysztof Kosiński]

2010/8/5 Simon McVittie simon.mcvit...@collabora.co.uk:
 ... but it appears to be distribution-hostile, at least in its current state:

    http://www.mail-archive.com/debian-de...@lists.debian.org/msg281373.html

 Yes, autofoo also results in embedding a copy of itself in tarballs, but
 distributions who have a newer/more-bugfixed version of autofoo than the
 upstream can generally autoreconf it. Waf doesn't seem to be upgradable in a
 similar way.

My take on this is:
1. Several projects using Waf had the binary in their tarball to
avoid any possible incompatibilities between Waf versions
2. Debian knew better and tried to replace them with one single copy the script
3. Build breakages ensued
4. Projects and Waf upstream got angry about this
5. Maintainer used some weird threats to get the system-wide Waf
package out of Debian
6. Debian attempted a compromise (e.g. they still knew better) but
finally capitulated
7. Now everyone thinks that Waf maintainer is uncooperative

The problem appears to be conceptual: Waf upstream regards Python as
the actual build system and the Waf binary as a local component
similar to the configure script, while Debian thinks Waf is like the
Autoconf or Automake executables.

Waf is also upgradable, but is not as API stable as Autotools. In
most cases you can drop a new version of the Waf binary into your
project directory and it will build without modification, but in some
cases it won't, so one ships the version that was verified to work. By
the way: why it's OK to bundle parts of build system code (like
libtool, m4 macros, preprocessed configure script, etc.) in the
tarball, but it's not OK to bundle the *entire* build system code?

In any case, I'm not saying that current Waf is better than current
Autotools, but that its model of execution (execute user's Python
script that defines the targets to build, use the Python interpreter
to spawn tasks) is superior to Autotools (preprocess Makefile.am,
preprocess shell script, run shell script, run make to spawn tasks).
I want this model, not Waf in particular.

 See this mail from Piotr Ożarowski (who packages a large proportion of the
 Python modules in Debian), which lists use waf as build-system alongside
 release different tarballs with the same version number (!) among things
 to avoid:

    http://www.mail-archive.com/python-...@python.org/msg47681.html

It looks out of place on this list. Comparing Waf use to version
number aliasing is dramatizing. Debian people should get over the
assumption that every respectable build system should work like
Autotools or CMake.

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

Re: AC_MSG_RESULT(patching libtool to fix HIDEOUS BREAKAGE) [was Re:dconf 0.5]

[Krzysztof Kosiński]

2010/8/4 Havoc Pennington h...@pobox.com:
 automake is fine, but libtool is a real problem. It seriously
 lengthens compile/install times in a way that's probably wasted tens
 of thousands of developer hours over the years, *at least*. In all
 honesty, most likely any of us who write a lot of C code could get
 back the time spent patching libtool out of automake *just in time
 saved personally*, let alone time saved for everyone else.

I have used Waf for some time and it changed my opinion about
Autotools and CMake.

Only demigods can really understand the inner workings of Autotools to
the point of being able to meaningfully modify them, and getting it to
work on Windows is an exercise in masochism. CMake's scripting
language is incredibly unexpressive and it takes lots and lots of code
to do anything moderately complicated. Meanwhile Waf is
architecturally quite simple and allows you to write concise scripts
in Python. It's also infinitely faster than SCons.

Of course, it doesn't have all the features required by GNU projects
(for example tarball creation is very limited), but I think it would
be more productive to enhance Waf to the point it's a feasible
Autotools replacement, rather than wasting time on the current
mainstream choices.

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

GtkRange API is incomplete

[Krzysztof Kosiński]

Hello

Here is my use use case (in Inkscape). I have a set of sliders
(GtkScale) that control some values in the document. I want to update
the view of the document in real time, but only push the change on the
undo stack when the drag is finished. But the only signal I can
connect to is value-changed. When I connect to it, I have only two
choices:
1. Update policy GTK_UPDATE_DISCONTINUOUS. This will give me correct
undo behavior but won't update the display in real time.
2. Update policy GTK_UPDATE_CONTINUOUS. This will update the display
correctly but will flood the undo stack with partial changes.

The problem would be solved if there was some additional signal that
would only be emitted when the user finishes the drag, or when the
slider is moved using the keyboard. It could be called value-set.
Essentially, it should be emitted after the value-changed signal
whenever the value-changed signal would be emitted if the update
policy was GTK_UPDATE_DISCONTINUOUS.

Here's the relevant bug report from our tracker.
https://bugs.launchpad.net/inkscape/+bug/579932

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

Re: GtkRange API is incomplete

[Krzysztof Kosiński]

W dniu 27 lipca 2010 18:06 użytkownik Alberto Ruiz ar...@gnome.org napisał:
 Hi there,
 You can just connect to the GtkRange's GtkAdjustment value-changed
 signal for the view update.

The problem is not the view update but the undo stack update. It
should only be updated when the drag is finished.

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

Re: GtkRange API is incomplete

[Krzysztof Kosiński]

W dniu 27 lipca 2010 23:32 użytkownik Sven Neumann s...@gimp.org napisał:
 You could implement undo compression as we do in GIMP. Multiple
 consecutive position changes are compressed into a single undo step.
 This can be easily implemented by looking at the top-most step on the
 undo stack and checking if it is of the same type as the step you are
 pushing.

We also have undo stack compression (or rather coalescing). I
discovered there was an error in one of our internal functions that
required the undo keys to be constant strings, and the affected dialog
used dynamically generated keys. This prevented undo event coalescing
from working.

Anyway, thanks for your suggestion, because it pointed me in the right
direction.

Regards, Krzysztof
___
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

[Krzysztof Kosiński]

2010/6/14 Tor Lillqvist t...@iki.fi:
 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.

Is there any sanctioned way of doing this on Debian?
Regards, Krzysztof
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Old Windows-specific bug in GOption

[Krzysztof Kosiński]

If anyone is interested in fixing this highly annoying bug that
prevents serious projects from using GOption on Windows, please see
the new patch I created:
https://bugzilla.gnome.org/show_bug.cgi?id=522131

It defines a new structure, GCommandLine, that can be created from
various sources. The default constructor (g_command_line_new) does
the right thing for all platforms.

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

Old Windows-specific bug in GOption

[Krzysztof Kosiński]

Hello

First, I would like to send a big thank you to Murray Cumming for
committing the fix for the lingering libsigc++ accumulator bug! It
will allow everyone to write more powerful signals code.

There's a second serious bug that impacts Inkscape, and it's one of
the reasons we still uses libpopt for option parsing. This time it's
in Glib.
https://bugzilla.gnome.org/show_bug.cgi?id=522131

The comment thread in the bug is rather long, so I will outline what's
the problem. I'll call it The Immigrant Problem, since it is most
likely to impact people who changed their country of residence.

On Windows, the command line passed to main() is in the system
codepage (glib term: locale encoding). Usually it's some
ASCII-compatible single byte encoding, but on Asian systems it might
be multibyte. It's all fine when the user only opens files with names
in his local language. Problems start to happen when, for example,
someone tries to open Russian-named files on an English copy of
Windows. To be more precise, it happens whenever someone tries to open
a filename that contains characters not representable in the locale
encoding.

The arguments of main() simply do not contain the information needed
to unambiguously locate the Russian-named files. If there are two
plain text files with three-character Russian names in one folder,
both of them will be passed to main() as ???.txt and there is no way
to tell which one should be opened. It means the arguments of main()
are useless in this case.

Right now, GOption assumes that the argv passed to it is in locale
encoding and converts it to UTF-8 when parsing, so even if we have the
Unicode command line from somewhere else, we cannot parse it using
GOption. If we converted the Unicode command line to locale encoding,
we would lose the necessary additional information it contains. More
complicated tricks undermine the merit of using GOption at all.

The Unicode command line can be retrieved on Windows using one of the
following ways:
- GetCommandLineW() - functions retrieves the full command line as a
single string as it was entered, without shell expansion.
- __wargv - undocumented global variable equivalent to __argv that
contains argv in UTF-16.
- _wmain() - undocumented alternative entry point that receives UTF-16
argv. I heard that MinGW doesn't support it, though didn't check it.

There a few possible solutions to this problem:
1. On Windows, ignore the arguments of g_option_context_parse, and use
__wargv instead.
2. Same as above, but use the new behavior for a new method and
deprecate g_option_context_parse.
3. Introduce a helper function that retrieves UTF-8 command line
arguments, based on global variables and arguments of main(), and
provide g_option_context_parse_utf8 method which takes UTF-8 encoded
argv.
4. Same as 3, but use an option context property to select the input encoding.
5. Introduce a method that always parses argv based on global data.
6. Same as 1, but try to guess whether the passed argv was modified by
comparing it to __wargv. If it wasn't, use __wargv.

Each has a downside:
1: Can break programs that modify the arguments of main() before
passing them to GOption.
2: Requires changes to existing code and disallows modifying argv
before parsing when using GOption (probably not a bad thing).
3: Requires changes to existing code and using a non-obvious function
that does nothing on Gnome's primary platform (Unix), so it's possible
most programs will not use it and remain broken on Windows until
someone discovers this relatively rare bug for each of them.
4: Overloads one method to take 2 different types of data.
5: Requires depending on highly platform-specific features. There is a
__wargv equivalent called __libc_argv, which works at least on Linux,
but probably not on other Unixes.
6: Still doesn't fix the problem if argv is modified, causing
unobvious breakage.

I would favor solution #2, since it's the simplest and least probable
to cause confusion, but bug commenters apparently wanted to go with
#6. I sent a few patches implementing #6 but they weren't committed.
What do others think about this?

Regards, Krzysztof Kosiński
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list