Re: Reg. modifying GTK+ to add menu option
Hello. Hmm... I use goldendict for similar functionality. goldendict has a special key (default win+alt). When special key is pressed, current selected word will be translated in pop-up window, as it is shown in your first screenshot. How does goldendict do it? I think he scan all keypress actions from X server, may be Qt helps him. As I know, GNOME can add user's action to keypress. May be you need hack GNOME dict and GNONE, not gtk+. I think, adding new context menu to gtk+ is a bad choice. gtk+ is toolkit for making GUI and is not suitable for this purpose. gtk+ is used on systems that do not have GNOME dict or GNOME. New context menu is useless for those systems. How I see the solution to this problem: GNOME must have special key with action look up word. On this action GNOME must send selected word (I think it's not a big problem to get selected word) to GNOME dict. dict shows pop-up window with definition. Good luck with this feature. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkAppChooser custom command patch
I did not look at your implementation, but the screenshots look very promising - in fact I think that is a highly desirable feature and your implementation is (imho) how it should be done! 2013/4/8 tarn...@tarnyko.net Hi folks, Could someone please review the following patch/suggestion : https://bugzilla.gnome.org/**show_bug.cgi?id=650284#c36https://bugzilla.gnome.org/show_bug.cgi?id=650284#c36 It adds a Use custom command on the lower part of the GtkAppChooser window, so users can specify an unlisted application (case of uncomplete mimetypes or .desktop associations). Screenshots are available in the comment. The patch itself is unfinished, I'm mostly asking for feedback about the general idea and design. Regards, Tarnyko __**_ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/**mailman/listinfo/gtk-devel-**listhttps://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkAppChooser custom command patch
It does not fix the issue on a permanent basis nor does it fix the issue for other users. But the single user can fix it _instantly_ himself without having to read the .desktop file specification. And I think that is an actual advantage. An alternative would be to create an application to write .desktop files (a bunch of entries with suggestions), probably linked from the application chooser dialog - that would be a viable solution, but on the other hand side, this is more nasty for the end-user. Best 2013/4/8 Matthias Clasen matthias.cla...@gmail.com On Mon, Apr 8, 2013 at 7:48 AM, Bernhard Schuster schuster.bernh...@googlemail.com wrote: There will always be the case that some application will not do it properly. Instead of annoying the end-user, give him/her the option to fix it him/herself. It is not that it would hurt, it's rather a salvation for the daily highcups and struggle with beta/commercial applications. But selecting 'custom command' doesn't fix it in any way. Fixing it would involved editing the desktop file, adding the necessary mime type, and sending a patch to the application author. I don't doubt that 'custom command' functionality is useful. But I don't think it should live in the app chooser dialog. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Abuse of 'const' ?
const is left binding unless there is nothing to the left - then it binds to the right. 2013/4/8 John Emmas john...@tiscali.co.uk 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, using g_free(). Good clarification Ryan. Thanks! __**_ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/**mailman/listinfo/gtk-devel-**listhttps://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: GTK+3 win32/64 build environment
What the software does not technically disallow and what the software license allows are two different things. IANAL, but the license appears to only allow it to run on a physical machine, not a virtual one. Kevin From: gtk-devel-list [gtk-devel-list-boun...@gnome.org] On Behalf Of tarn...@tarnyko.net [tarn...@tarnyko.net] Sent: Wednesday, April 10, 2013 5:10 AM To: gtk-devel-list@gnome.org Subject: Re: GTK+3 win32/64 build environment Colin, First, please note that we don't have to buy a Windows license. There is a *free* (as in free beer) edition of Windows named Hyper-V Server. It's stripped-down in terms of GUI, but works well for this purpose. Here is a link to licensing stuff : http://social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/db3f c7d7-1772-41fb-b878-4574b3c39703/ Hmmm...but it looks to me like this edition is only designed for physical deployments, whereas I think we'd really want it virtualized (both for developers running Linux on their laptops who want to test, and inside the GNOME infrastructure). Or does it run in a VM ok? At least for GNOME servers it'd likely be worth paying for an actually supported version of Windows so it gets security updates, even if it is completely firewalled off from the world. It runs in a VM. You have to allocate 2 Gb of RAM to it during install time, but can decrease that later. It can get security updates automatically, or manually via pre-downloaded packages, too. But you won't be able to use some software on it (MSVC e.g.). So if it's wanted, yes a mainstream version of Windows would be better in this case.e, MinGW under Linux is mostly installed via a package manager (yum install mingw32-gcc-c++ on Fedora e.g.). You don't get to choose which version of the compiler you install. Same thing for the dependencies (libtool, expat, perl, python...). These versions are likely to change regarding the distro your are using, and you cannot copy their files from one computer to another because binaries are compiled dynamically (= depend on this particular box' libc a.s.o). There are hybrid approaches here - the most realistic to me is to reuse a current distribution cross toolchain (e.g. we're not building mingw-gcc in GNOME), but if we need to update some other dependency, we could do so. I guess you're right though, the full SDK case does kind of explode due to the perl/python dependencies. Yes, Python and Perl are the worst problems. Doing this right on the long run with a cross-compile env would require some effort. A solution would be to have a standalone MinGW install for Linux. I've googled for one without success. If one doesn't exist, the ultimate solution whould be to create one by recompiling MinGW statically myself, that means recompiling the compiler : I don't know anything about that, it will take lots of time. That doesn't help us though even if it existed due to the Perl/Python deps among others. Correct, didn't even realize that. - GTK+3 build process sometimes needs to run the binaries it has just generated. Now an important part - gobject-introspection as used by the bindings at the moment requires doing this. But see: https://bugzilla.gnome.org/show_bug.cgi?id=592311 Ouch. Will see your link. For instance, it runs glib-compile-schemas on its XML files to create the schemas.compiled catalog. Without it, GTK+ programs won't run. The way this is solved for the e.g. GNU/Linux cross case is it's assumed you have glib-genmarshal on the host. See: https://git.gnome.org/browse/glib/tree/configure.ac#n2630 We can definitely do some of this for Windows, but we have to be careful about files that are architecture dependent. For glib-compile-schemas in particular, variants are host endianness by default. Didn't know about that, thanks, will take a look. - You won't be able to test and Q/A the binaries you just produced. That's where virtualization comes in. Wine cannot be used because it's not reliable with GTK+3 ; last time I tried under Debian, fonts were disproportional and pictures sometimes stripped. You have to run them on a native Windows OS. Wine admittedly is an insane monstrosity, but some of that is likely fixable. So at a high level...there's quite a bit to figure out. The SDK problem is just hard =/ Yes, that's why the native build option is easier, works around this problem and lots of others too. PS : Don't forget that I'm alone doing this work now. I'm documenting everything as time goes on, but choosing difficult options will make my work more difficult too ;-). Regards, Tarnyko ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org
RE: GTK+3 win32/64 build environment
I dug up the license for Microsoft Hyper-V Server. Here it is: http://www.microsoft.com/en-us/download/details.aspx?id=497 See USE RIGHTS. section 'e' bullet 2. Does compiling gtk mesh with bullet 2? If so, your good to go. If not, you do not have a license to do what you are attempting. Looking at it, unless you are running at least one vm under it, and you are building the software for the purposes of managing and servicing the virtual machine (One might be able to make that argument), I'd guess not. IANAL Thanks, Kevin From: gtk-devel-list [gtk-devel-list-boun...@gnome.org] On Behalf Of tarn...@tarnyko.net [tarn...@tarnyko.net] Sent: Wednesday, April 10, 2013 3:50 AM To: gtk-devel-list@gnome.org Subject: Re: GTK+3 win32/64 build environment OK folks. As the initial contributor of the win32 buildenv, here are my reasons for preferring a native build instead of cross-compiling from Linux. Sorry if it is long, but I think explaining things will help. First, please note that we don't have to buy a Windows license. There is a *free* (as in free beer) edition of Windows named Hyper-V Server. It's stripped-down in terms of GUI, but works well for this purpose. Here is a link to licensing stuff : http://social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/db3f c7d7-1772-41fb-b878-4574b3c39703/ and a screenshot of it running gtk3-demo while buildenv is compiling GLib : http://www.tarnyko.net/repo/hyperv_gtk3.png Short version : cross-compiling GTK+3 is a headaches generator. It's not easy nor efficient, and hard to maintain. Long version with individual points for techs : - MinGW/GCC for Windows is a standalone compiling environment : basically, you just drop all files in a directory, and it will work, regardless of the OS version you are using. That's because most of the base utils and libraries are compiled statically. MinGW under Linux is mostly installed via a package manager (yum install mingw32-gcc-c++ on Fedora e.g.). You don't get to choose which version of the compiler you install. Same thing for the dependencies (libtool, expat, perl, python...). These versions are likely to change regarding the distro your are using, and you cannot copy their files from one computer to another because binaries are compiled dynamically (= depend on this particular box' libc a.s.o). That means you depend on a precise distro version. Plus, my tests have proven that it matters while building. There are some fixes for libtool and the compiler itself in the buildenv (see the 64-bit one) ; if you use a different version, it will sometimes break the build. A solution would be to have a standalone MinGW install for Linux. I've googled for one without success. If one doesn't exist, the ultimate solution whould be to create one by recompiling MinGW statically myself, that means recompiling the compiler : I don't know anything about that, it will take lots of time. - GTK+3 build process sometimes needs to run the binaries it has just generated. For instance, it runs glib-compile-schemas on its XML files to create the schemas.compiled catalog. Without it, GTK+ programs won't run. You cannot obviously run Win binaries under Linux -and using wine is not an option here. The only way is to generate, at the same time, the Linux version of the same binary ; that is to say, generate the stack *twice*. One time you obtain glib-compile-schemas for Linux, put it safe somewhere, then later during the Windows build you tell it to use *this* particular binary at this particular point. Ugly patches. Or you let the end-user do this, which is not user-friendly. - You won't be able to test and Q/A the binaries you just produced. Wine cannot be used because it's not reliable with GTK+3 ; last time I tried under Debian, fonts were disproportional and pictures sometimes stripped. You have to run them on a native Windows OS. I think I have covered the most important points ; opinions and arguments are welcome. I'm sometimes available on IRC channel for discussions, too. Regards, Tarnyko ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: GTK+3 win32/64 build environment
No worries. Just trying to keep everyone safe. Thanks, Kevin From: gtk-devel-list [gtk-devel-list-boun...@gnome.org] On Behalf Of tarn...@tarnyko.net [tarn...@tarnyko.net] Sent: Wednesday, April 10, 2013 10:03 AM To: gtk-devel-list@gnome.org Subject: Re: GTK+3 win32/64 build environment Kevin, Fox, Kevin M writes: I dug up the license for Microsoft Hyper-V Server. Here it is: http://www.microsoft.com/en-us/download/details.aspx?id=497 See USE RIGHTS. section 'e' bullet 2. Does compiling gtk mesh with bullet 2? If so, your good to go. If not, you do not have a license to do what you are attempting. Looking at it, unless you are running at least one vm under it, and you are building the software for the purposes of managing and servicing the virtual machine (One might be able to make that argument), I'd guess not. IANAL You are making a point here. I didn't read this section carefully. IANAL neither, but if there is a doubt, we should not use the software. Sorry for having suggested that btw, shoud have been more precautionous. Regards, Tarnyko Thanks, Kevin From: gtk-devel-list [gtk-devel-list-boun...@gnome.org] On Behalf Of tarn...@tarnyko.net [tarn...@tarnyko.net] Sent: Wednesday, April 10, 2013 3:50 AM To: gtk-devel-list@gnome.org Subject: Re: GTK+3 win32/64 build environment OK folks. As the initial contributor of the win32 buildenv, here are my reasons for preferring a native build instead of cross-compiling from Linux. Sorry if it is long, but I think explaining things will help. First, please note that we don't have to buy a Windows license. There is a *free* (as in free beer) edition of Windows named Hyper-V Server. It's stripped-down in terms of GUI, but works well for this purpose. Here is a link to licensing stuff : http://social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/db3f c7d7-1772-41fb-b878-4574b3c39703/ and a screenshot of it running gtk3-demo while buildenv is compiling GLib : http://www.tarnyko.net/repo/hyperv_gtk3.png Short version : cross-compiling GTK+3 is a headaches generator. It's not easy nor efficient, and hard to maintain. Long version with individual points for techs : - MinGW/GCC for Windows is a standalone compiling environment : basically, you just drop all files in a directory, and it will work, regardless of the OS version you are using. That's because most of the base utils and libraries are compiled statically. MinGW under Linux is mostly installed via a package manager (yum install mingw32-gcc-c++ on Fedora e.g.). You don't get to choose which version of the compiler you install. Same thing for the dependencies (libtool, expat, perl, python...). These versions are likely to change regarding the distro your are using, and you cannot copy their files from one computer to another because binaries are compiled dynamically (= depend on this particular box' libc a.s.o). That means you depend on a precise distro version. Plus, my tests have proven that it matters while building. There are some fixes for libtool and the compiler itself in the buildenv (see the 64-bit one) ; if you use a different version, it will sometimes break the build. A solution would be to have a standalone MinGW install for Linux. I've googled for one without success. If one doesn't exist, the ultimate solution whould be to create one by recompiling MinGW statically myself, that means recompiling the compiler : I don't know anything about that, it will take lots of time. - GTK+3 build process sometimes needs to run the binaries it has just generated. For instance, it runs glib-compile-schemas on its XML files to create the schemas.compiled catalog. Without it, GTK+ programs won't run. You cannot obviously run Win binaries under Linux -and using wine is not an option here. The only way is to generate, at the same time, the Linux version of the same binary ; that is to say, generate the stack *twice*. One time you obtain glib-compile-schemas for Linux, put it safe somewhere, then later during the Windows build you tell it to use *this* particular binary at this particular point. Ugly patches. Or you let the end-user do this, which is not user-friendly. - You won't be able to test and Q/A the binaries you just produced. Wine cannot be used because it's not reliable with GTK+3 ; last time I tried under Debian, fonts were disproportional and pictures sometimes stripped. You have to run them on a native Windows OS. I think I have covered the most important points ; opinions and arguments are welcome. I'm sometimes available on IRC channel for discussions, too. Regards, Tarnyko ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___
Re: GtkAppChooser custom command patch
On Mon, Apr 08, 2013 at 01:53:37PM +0200, tarn...@tarnyko.net wrote: I won't debate this again, points have already been widely made before (Bernhard does have some here). Personally, what I regret the most is having spent time writing a useless patch. It does imply something for my past and future-planned contributions, too. It is good that you're trying to help, and I can understand you think a custom command is helpful. But what you really need is a desktop file. A desktop file ensures that things work correctly (correct mime types, startup notification, etc). There are programs which already allow you to create such desktop files, e.g. alacarte (though it had some issues). Note that some time will always be wasted. E.g. Mattias probably looks at various patches which have bugs in them. Pretty much wasted time because he wouldn't have to spend time if people did exactly what he visioned. Or in other words: accepting patches because you spend time on the patch is not how things are or should be done. -- Regards, Olav ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On Wed, Apr 10, 2013 at 11:05:07AM +0200, tarn...@tarnyko.net wrote: Marc-André Lureau writes: It would be better if you could check in your scripts in a repository, so one could more easily study and eventually contribute to your effort. All the binaries should be fetched or build from the source (and verified). It should be easy and safe to reproduce and modify the build, by anyone at anytime. Agreed. What's GNOME preferred repo system, Git ? Should I get a account on git.gnome.org ? Suggest to do so. Follow https://live.gnome.org/NewAccounts. Note that we want your real name. As 'module voucher' select 'bugzilla.gnome.org' and I'll vouch for you. Anyone on git.gnome.org can create repositories. -- Regards, Olav ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On 10/04/13 11:50, tarn...@tarnyko.net wrote: Plus, my tests have proven that it matters while building. There are some fixes for libtool and the compiler itself in the buildenv (see the 64-bit one) ; if you use a different version, it will sometimes break the build. If libtool as shipped by $DISTRO is broken, surely the solution to that is to report bugs and get it fixed, preferably upstream, but failing that, in your favourite distribution? Likewise for the (cross-)compiler. A solution would be to have a standalone MinGW install for Linux. There are several MinGW installations, in several distributions; I'm aware of at least Debian, OpenSUSE and Fedora having it. If the GNOME project wants to cross-compile Windows binaries, the minimum requirement is that building on *one* of those distributions works (OBS seems to be a popular choice); people who want broader support than that are welcome to improve their respective distributions' MinGW stacks, but that's some way off the critical path :-) While I'm sure it would be possible to put together a standalone MinGW tree that expects to be installed in /opt/mingw (or whatever), lots of distribution developers have already done the equivalent work for you. Doing a mini-distribution for that seems somewhat redundant. If users of one Linux distro need to do GNOME-for-Windows builds in a chroot, virtual machine or container with a different distro, that doesn't seem like the end of the world: best-practice in Debian/Ubuntu is to do production package builds in a chroot anyway (via pbuilder or sbuild). Also, if something works on (say) OpenSUSE's stack but not Debian's, then that's either a simple matter of the compiler is in a different place (probably meaning that something is insufficiently automatic), or a bug in Debian's stack (quite possibly of the form please upgrade to gcc x.y.z). Neither seems insurmountable. S ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On Wed, 2013-04-10 at 14:44 +0200, Marc-André Lureau wrote:
Hi
Their build requirements is similar to yours or anyone:
http://docs.gstreamer.com/display/GstSDK/Building+from+source+using
+Cerbero. We are building the same set of packages after all. Building
only gtk+ is really not enough in many cases. It's not going to fly if
each project distribute its own set of binaries.
Reading the code, Cerebo looks pretty nice. The only obviously lame
thing I saw so far is:
gstreamer-clutter.package:
...
sys_deps_devel = {
Distro.DEBIAN: ['libgl1-mesa-dev', 'libdrm-dev',
'libx11-dev', 'libxext-dev', 'libxfixes-dev',
'libxdamage-dev', 'libxcomposite-dev', 'libxi-dev'],
Distro.REDHAT: [
'libXrender-devel', 'libXv-devel',
'mesa-libGL-devel', 'libXcomposite-devel',
'libXi-devel']}
jhbuild's sysdeps implementation is a lot better because it avoids this
tedious duplicative package name hardcoding.
Maintenance of a shared and proven project can be easier than a new
standalone one. Many people who have experience with distro and
windows build contributed to it. Also I think cerbero isn't that
complicated, it looks quite elegant and powerful for what it does.
So, as far as doing native Windows builds, it looks to me like since
Cerebo is actively used in the GStreamer world which is architecturally
close to GTK+/GNOME, it'd make a lot of sense to use it here.
Tarnyko, have you looked at Cerebo at all?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
On Thu, Apr 11, 2013 at 8:47 AM, Colin Walters walt...@verbum.org wrote: So, as far as doing native Windows builds, it looks to me like since Cerebo is actively used in the GStreamer world which is architecturally close to GTK+/GNOME, it'd make a lot of sense to use it here. Tarnyko, have you looked at Cerebo at all? as was discussed on IRC, i think we need to differentiate clearly between the 3 different workflows that are involved here: (1) people building GTK+ Windows SDK's for official distribution or personal use (2) people use the GTK+ Windows SDK to develop/build applications on Windows (3) people attempting to package Windows applications that use GTK+ Cerebo looks useful for (1). A zip file with good documentation looks good for (2) Various Windows installers plus good documentation looks good for (3) --p ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
Arnel, Arnel A. Borja writes: I don't know that there's a free version of Windows :D. Now, regarding what Kevin digged out with the license, we know that it's not so free :-(. Short version : cross-compiling GTK+3 is a headaches generator. It's not easy nor efficient, and hard to maintain. I agree, it is hard to maintain. Though I still prefer cross-compilation, since it's faster in compiling. I sometimes fell asleep while compiling in MinGW in native Windows. Agreed, it's a lot faster. Just harder ;-). Long version with individual points for techs : - MinGW/GCC for Windows is a standalone compiling environment : basically, you just drop all files in a directory, and it will work, regardless of the OS version you are using. That's because most of the base utils and libraries are compiled statically. Is it really compiled statically? I don't see any difference when I moved from native MinGW to OBS. Some packages are static, most are not. Or atleast the old GTK+ 2 builds in www.gtk.org have most of libraries compiled dynamically. I was mostly speaking about MinGW core binaries (the compiler, linker, etc). ldd shows that the compilers refers to the current libc on Debian for instance. Could work though, but needs some trial-and-error. MinGW under Linux is mostly installed via a package manager (yum install mingw32-gcc-c++ on Fedora e.g.). You don't get to choose which version of the compiler you install. Same thing for the dependencies (libtool, expat, perl, python...). These versions are likely to change regarding the distro your are using, and you cannot copy their files from one computer to another because binaries are compiled dynamically (= depend on this particular box' libc a.s.o). Cross-compiled GTK+ and other libraries use msvcrt, so usually the difference in compiler versions is not a problem except for libstdc++. Don't get me into the libstdc++ thing, it will remind me of hard times :-D (I provide gtkmm packages for win32, was a pain to get right). I'm using Ubuntu, and use the builds for 32-bit and 64-bit Windows that are built using OpenSUSE 12.3. I mix my libraries and programs compiled using GCC 4.6.3 with the ones from OBS that use GCC 4.8.0. Seems to work fine (I've been using them for two years now, I think), except that you should make sure that you use the libstdc++ that comes with your compiler (though it is used by g++, not gcc, and there are no GTK+ dependency that use g++, I believe; I only got this problem last week when I started porting Anjuta since its C++ parser uses g++). Correct, C++ isn't used anywhere during the build process. The problem might be python though, the cross-compiled Python that OBS uses are quite old (2.6). I don't use python so I'm not sure how big the impact would be, but you could compile the base GTK+ stack without python. Because it doesn't work with newer Python (2.7 and ). I think GLib needs it ; could be patched around, have to check. That means you depend on a precise distro version. I recently moved from the builds for OpenSUSE 12.1 to 12.3 (and did that before many times before), upgraded my system many times too (since Ubuntu Oneiric I think), and been using it for about 2 years, so I don't think it is a problem. And I still use the packages I compiled myself before along with the newer set of libraries, seems like there are no problems. Plus, my tests have proven that it matters while building. There are some fixes for libtool and the compiler itself in the buildenv (see the 64-bit one) ; if you use a different version, it will sometimes break the build. A solution would be to have a standalone MinGW install for Linux. I've googled for one without success. If one doesn't exist, the ultimate solution whould be to create one by recompiling MinGW statically myself, that means recompiling the compiler : I don't know anything about that, it will take lots of time. Ubuntu, Fedora and OpenSUSE have the cross-compilers in their repos. OBS uses MinGW-w64 GCC 4.8 while I use MinGW-w64 GCC 4.6.3 in Ubuntu. I use their builds alongside each other. A year before I even combine MinGW-32 and MinGW-w64 builds, though I thought that might be a bad idea, and Ubuntu has MinGW-w64 cross-compilers anyway. If you want to build MinGW-w64, you could check OBS which have the most recent GCC cross-compilers. - GTK+3 build process sometimes needs to run the binaries it has just generated. For instance, it runs glib-compile-schemas on its XML files to create the schemas.compiled catalog. Without it, GTK+ programs won't run. You cannot obviously run Win binaries under Linux -and using wine is not an option here. The only way is to generate, at the same time, the Linux version of the same binary ; that is to say, generate the stack *twice*. One time you obtain glib-compile-schemas for Linux, put it safe somewhere, then later during the Windows build you tell it to use
Re: Reg. modifying GTK+ to add menu option
On 2013-04-10 19:52, Sindhu S wrote:
I want to add this to GTK+ because it will automatically benefit
every GNOME Application, and have consistency for the user.
Hi Sindhu,
Just some thoughts:
* It might be possible to do this as a GNOME Shell extension, where I
can imagine pressing some keyboard combination or whatever to activate
the query. Then, by using the accessibility framework a look-up
would not be limited to applications using GTK+ but you'd get support
for LibreOffice, Firefox, QT and anything else talking AT-SPI basically
for free.
As an example, attached is a standalone (very incomplete and not very
well tested) Python script using Atspi, Wnck and Gdk via
gobject-introspection
(originally based on code from Accerciser) that retrieves the word
under the mouse pointer (if any) using AT-SPI.
To test the script:
- open a terminal,
- type get_text_under_pointer.py
- put the mouse pointer somewhere, for example point at a word in a
GEdit or LibreOffice Writer document or web page in Firefox or
Epiphany etc
- your terminal still having focus, hit enter
* Maybe a translate option in addition to look up in dictionary
might be useful for some people too?
mvg,
Dieter
#!/usr/bin/python3
import os
from gi.repository import Atspi, Gdk, Wnck
my_pid = str(os.getpid())
def is_my_app(acc):
'''
Based on isMyApp() from https://git.gnome.org/browse/accerciser/tree/src/lib/accerciser/tools.py
'''
if not acc:
return False
else:
pid = str(acc.get_application().get_process_id())
if pid == my_pid:
return True
else:
return False
def inspect_under_pointer():
'''
Based on _inspectUnderMouse() from https://git.gnome.org/browse/accerciser/tree/plugins/quick_select.py
'''
gdk_display = Gdk.Display.open(Gdk.get_display())
screen, x, y, flags = gdk_display.get_pointer()
wnck_screen = Wnck.Screen.get_default()
wnck_screen.force_update()
wnck_workspace = wnck_screen.get_active_workspace()
window_order = [w.get_name() for w in wnck_screen.get_windows_stacked()]
top_window = (None, -1)
desktop_acc = Atspi.get_desktop(0)
desktop_acc_child_count = desktop_acc.get_child_count()
for desktop_acc_child in range(0, desktop_acc_child_count):
app_acc = desktop_acc.get_child_at_index(desktop_acc_child)
if not app_acc or is_my_app(app_acc):
continue
else:
app_acc_child_count = app_acc.get_child_count()
for app_acc_child in range(0, app_acc_child_count):
frame_acc = app_acc.get_child_at_index(app_acc_child)
if not frame_acc:
continue
else:
child_acc = get_component_at_coords(frame_acc, x, y)
if child_acc:
try:
z_order = window_order.index(frame_acc.get_name())
except ValueError:
pass
else:
if z_order top_window[1]:
top_window = (child_acc, z_order)
if top_window[0]:
return top_window[0], x, y
def get_component_at_coords(parent, x, y):
'''
Based on _getComponentAtCoords() from https://git.gnome.org/browse/accerciser/tree/plugins/quick_select.py
'''
container = parent
inner_container = None
while True:
container_role = container.get_role()
if container_role == Atspi.Role.PAGE_TAB_LIST:
try:
si = container.get_selection()
container = si.get_selected_child(0)
except NotImplementedError:
pass
try:
ci = container.get_component()
except:
break
else:
inner_container = container
acc_at_point = ci.get_accessible_at_point(x, y, Atspi.CoordType.SCREEN)
if acc_at_point is not None:
container = acc_at_point
else:
break
if not container or container.get_component() == ci:
# The gecko bridge simply has getAccessibleAtPoint return itself
# if there are no further children
break
if inner_container == parent:
return None
else:
return inner_container
def get_text_under_pointer():
acc, x, y = inspect_under_pointer()
if acc:
text = acc.get_text()
if text:
offset = text.get_offset_at_point(x, y, Atspi.CoordType.SCREEN)
text_range = text.get_text_at_offset(offset, Atspi.TextBoundaryType.WORD_START)
text_value = Atspi.Text.get_text(text, text_range.start_offset, text_range.end_offset)
return text_value
return None
if __name__ == '__main__':
text = get_text_under_pointer()
if text:
print(text.strip())
else:
print('No text found :(')
Re: GTK+3 win32/64 build environment
Thanks folks. Now, regarding what was said previoulsy in this thread, I will try to list pros and cons of, respectively, native build and cross-compilation. Points listed in the end of each list have less importance or accuracy than the first ones. Then a decision regarding the choice might be made. Native build + easier (works around most problems in configure scripts and Makefiles) + independant from OS/distro - harder integration with GNOME infrastructure - slower - might need a commercial license of Windows Cross-compilation - + better integration with GNOME infrastructure + faster - needs patches in most configure scripts - needs to use standalone versions of Perl/Python OR patch Makefiles to be compatible with most common versions of Perl/Python (possible ? needs study) - needs to build stack twice (Linux native versions of some tools needed). So the speed gain might be countered (needs study) - might not be independant from OS/distro (need to choose a particular distro/package manager and stick to it ?) Regardless of what will be decided, I think that I need a Git account to push the current build scripts to the GNOME infrastructure. Will apply for it now. Regards, Tarnyko ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
tarn...@tarnyko.net schreef op do 11-04-2013 om 15:12 [+0200]: Native build + easier (works around most problems in configure scripts and Makefiles) I'd have to disagree here. In order to build gtk on a windows host then you basically need to arrange these things yourself first: - Install msys (which contains sh.exe which is needed to run the configure script) - Install the mingw.org or mingw-w64 compiler - Manually build (or download precompiled files for) all gtk+ dependencies (like gettext, libiconv, pixman, cairo, libjpeg, ...) When you use the cross-compiled packages which various distros are providing then all these steps are already arranged for you. For example on Fedora it's sufficient to run 'yum-builddep mingw32-gtk3' and all dependencies which are needed to allow building of gtk3 will be installed automatically (including the compiler). Once all dependencies are installed it's sufficient to run 'mingw32-configure make' from your source tree and there you go. For Fedora we've created an instruction which describes how commonly used cross-compiling tasks can be performed: https://fedoraproject.org/wiki/MinGW/Tutorial Regards, Erik van Pienbroek Fedora MinGW SIG ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
Hacking on GTK-Win32 is very annoying if you have to cross compile copy every time you make a change. It would be nice if the build system that comes out of this thread would be useful for more than just making the stock GTK packages. Another flaw with cross compiling is I don't believe there's any way to link to a newer msvcrt.dll. The official windows version of python links against msvcr90 and mixing versions leads to a lot of subtle problems. On Thu, Apr 11, 2013 at 8:44 AM, Erik van Pienbroek e...@vanpienbroek.nlwrote: tarn...@tarnyko.net schreef op do 11-04-2013 om 15:12 [+0200]: Native build + easier (works around most problems in configure scripts and Makefiles) I'd have to disagree here. In order to build gtk on a windows host then you basically need to arrange these things yourself first: - Install msys (which contains sh.exe which is needed to run the configure script) - Install the mingw.org or mingw-w64 compiler - Manually build (or download precompiled files for) all gtk+ dependencies (like gettext, libiconv, pixman, cairo, libjpeg, ...) When you use the cross-compiled packages which various distros are providing then all these steps are already arranged for you. For example on Fedora it's sufficient to run 'yum-builddep mingw32-gtk3' and all dependencies which are needed to allow building of gtk3 will be installed automatically (including the compiler). Once all dependencies are installed it's sufficient to run 'mingw32-configure make' from your source tree and there you go. For Fedora we've created an instruction which describes how commonly used cross-compiling tasks can be performed: https://fedoraproject.org/wiki/MinGW/Tutorial Regards, Erik van Pienbroek Fedora MinGW SIG ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Windows 32/64bit downloads and/or bundles for 2.x and 3.x
Hello all, I was approached by Berke Viktor today and asked to include the site: http://gtk.hexchat.org On the GTK+ Win32/Win64 pages on gtk.org. I thought I would bring it up here for discussion. This is for v2.x only at this point. I've CCed Berke because he is not on the mailing list and sadly isn't interested in joining, so don't forget to reply-all ;) Berke insists he is interested in continuing maintenance of this site though. -- Just to be clear, I have no problem adding this to gtk.org, but my goal here is not to confuse end user/developers who want a win32/win64 build with multiple different hosted downloads. It doesn't look like _we_ the community are doing it if we do that and it's not a clear consistent well formed message either IMO. I am also aware of the bundles work that Tarnyko has been doing and am interested to know how that relates here. At this stage the fact that work is for GTK+ 3.x is the only main difference I can see from my quick look. In an ideal world, the goal would be to merge ALL works from Tarnyko, Berke and what we already have on the site into something that's well documented and clear to people wanting to use GTK+ 2.x and 3.x on Windows 32 and 64 bit. I am especially interested in hearing from Tarnyko on this since he has been pushing the win32 bundles for GTK+ 3.x lately. Including in this bug, which I'm in the process of working on with him: https://bugzilla.gnome.org/show_bug.cgi?id=695600 Thoughts? -- Regards, Martyn Founder and CEO of Lanedo GmbH. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
hi; On 11 April 2013 17:32, Daniel Sabo daniels...@gmail.com wrote: Hacking on GTK-Win32 is very annoying if you have to cross compile copy every time you make a change. It would be nice if the build system that comes out of this thread would be useful for more than just making the stock GTK packages. that's the optimal way to kill this thing in the crib. let's start with something that has fairly well specified constraints and targets and deliverables, and let's leave the future unicorns and rainbows to another time. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Composite GtkBuilder template
On Thu, 2013-04-11 at 13:36 +0900, Tristan Van Berkom wrote:
First, let me apologize for the rather harsh tone in my message
yesterday. I had a big WTF moment when I saw how the composite
templates patches played badly with my branch. Your message made things
look easier to fix than I expected.
So, this is how I propose we handle the situation:
o First, you rebase your branch in such a way
that the filechooserdefault is reverted as
the first commit in your branch.
I'll do something like this. First, revert the commit. Then, merge my
branch. Doing a straight rebase is not trivial, as places-sidebar has
gotten master merged into it a few times to keep up with general
development. And finally, apply your commit again with lots of changes.
o Second, I know you wont like this part but
I need you to put the instance members on
a private structure.
We do not support automatically assigning
component pointers to public structure offsets.
And frankly, using a public structure defined
openly in gtkfilechooserprivate.h is an open
invitation for other components to access
the components of GtkFileChooserDefault directly
(which I think we both feel is unintended).
I totally agree with this for *public* widgets, those that go into the
public API.
But for GtkFileChooserDefault, I have two objections:
1. It's a private, internal widget, never meant to be exported.
2. I'd really really really like to keep the file chooser's code as
similar as possible between gtk2 and gtk3. Otherwise, cherry-picking
fixes becomes much harder.
I do appreciate having the private stuff in the .c file. And I
definitely don't like the current state (well, before your patches)
where the GtkFileChooserDefault struct is not in
gtkfilechooserdefault.h, but in a gtkfilechooserprivate.h file. I don't
remember why it ended up there; probably so that the unit tests would be
able to poke at internal widgets. *That* is not the right thing to do,
anyway, so I'm happy to see the struct move elsewhere. But the
objections still stand.
I haven't even seen how the code for composite templates pokes at
structs... but why does it have to care whether the struct is private or
public? Could we have:
gtkfilechooserdefault.h:
/* no struct definitions at all */
typedef struct GtkFileChooserDefault *GtkFileChooserDefault;
typedef struct GtkFileChooserDefaultClass *GtkFileChooserDefaultClass;
gtkfilechooserdefault.c:
/* complete structure definitions */
struct GtkFileChooserDefault {
GtkBox parent;
blah blah;
}
?
o If you have made any changes to the UI, i.e.
changes like spacing settings, expand/align
settings of any widgets in the filechooser,
any newly added widgets, anything that actually
changes the UI components, I would like you
to list those changes to me so I can make
the changes while splitting up gtkfilechooserdefault.ui
into 2 .ui files.
Sorry, you lost me - what would those two files be for?
(GtkPlacesSidebar is a self-contained thing which is mostly a
GtkTreeView...)
Federico
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Windows 32/64bit downloads and/or bundles for 2.x and 3.x
Hello, I am a fellow Hexchat dev with bviktor, and I thought I'd just provide a few clarifications:- 1. The instructions to build GTK+ on gtk.hexchat.org are for building using Visual Studio 2012, as opposed to Tarnkyo's work that uses MinGW. We use VS to build our entire stack (GTK and its deps, openssl, and Hexchat itself). 2. We have indeed found several problems getting these to build with VS. To that end, we have a bunch of patches scoured from the GTK bug tracker and other places, as well as a few we've written ourselves. These patches can be seen on https://github.com/hexchat/gtk-win32 3. Our goal was to make it easy for the user to build the stack using our instructions, for which we also provide a build script on the same repository. (hexchat-build.ps1) Thanks, Arnav On Thu, Apr 11, 2013 at 10:17 AM, Martyn Russell mar...@lanedo.com wrote: Hello all, I was approached by Berke Viktor today and asked to include the site: http://gtk.hexchat.org On the GTK+ Win32/Win64 pages on gtk.org. I thought I would bring it up here for discussion. This is for v2.x only at this point. I've CCed Berke because he is not on the mailing list and sadly isn't interested in joining, so don't forget to reply-all ;) Berke insists he is interested in continuing maintenance of this site though. -- Just to be clear, I have no problem adding this to gtk.org, but my goal here is not to confuse end user/developers who want a win32/win64 build with multiple different hosted downloads. It doesn't look like _we_ the community are doing it if we do that and it's not a clear consistent well formed message either IMO. I am also aware of the bundles work that Tarnyko has been doing and am interested to know how that relates here. At this stage the fact that work is for GTK+ 3.x is the only main difference I can see from my quick look. In an ideal world, the goal would be to merge ALL works from Tarnyko, Berke and what we already have on the site into something that's well documented and clear to people wanting to use GTK+ 2.x and 3.x on Windows 32 and 64 bit. I am especially interested in hearing from Tarnyko on this since he has been pushing the win32 bundles for GTK+ 3.x lately. Including in this bug, which I'm in the process of working on with him: https://bugzilla.gnome.org/**show_bug.cgi?id=695600https://bugzilla.gnome.org/show_bug.cgi?id=695600 Thoughts? -- Regards, Martyn Founder and CEO of Lanedo GmbH. __**_ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/**mailman/listinfo/gtk-devel-**listhttps://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+3 win32/64 build environment
Hello, On Thursday, 11 April, 2013 08:52 PM, tarn...@tarnyko.net wrote: Short version : cross-compiling GTK+3 is a headaches generator. It's not easy nor efficient, and hard to maintain. I agree, it is hard to maintain. Though I still prefer cross-compilation, since it's faster in compiling. I sometimes fell asleep while compiling in MinGW in native Windows. Agreed, it's a lot faster. Just harder ;-). Usually the harder part is only in the GTK+ package, which includes some tools that it also uses during compilation. In the other packages, especially libraries, it-just-works, since Autoconf will do the stuff for you and most packages don't need porting anyway since they use GLib (and the developers of GLib and GTK+ are always working to ensure that cross-compilation and native compilation with Visual Studio works, so you don't need to worry much about it). In my my computer, I only run ./install glib-2.36.0 then I will get GLib after some minutes. For me, native compilation with MinGW is a lot harder than cross-compilation apart from the speed, since your distribution will provide most of the stuff you need (cross-compiler, libtool, autoconf, intltool, ...), they are up-to-date (OBS have the latest cross-compilers - GCC 4.8.0, while MinGW has 4.7.2; distros usually have the latest autotools, intltool, etc.). In MinGW in Windows, we have to look for things ourselves (intltool is in the GNOME FTP site, compilers in MinGW, etc.). Also, MinGW in Windows uses its own (older) versions of make, which sometimes have problems with sh and other stuff - I always get the headache when some packages will compile for infinity, trying to rebuild itself until the world ends :D (or you kill them using the task manager). The hard part in maintaining is usually checking if the packages are in their latest versions. And sometimes some releases of packages have bugs in Windows (for example, I have some problems with pixman-0.28.2, though I don't think the latest version is required anyway) Long version with individual points for techs : - MinGW/GCC for Windows is a standalone compiling environment : basically, you just drop all files in a directory, and it will work, regardless of the OS version you are using. That's because most of the base utils and libraries are compiled statically. Is it really compiled statically? I don't see any difference when I moved from native MinGW to OBS. Some packages are static, most are not. Or atleast the old GTK+ 2 builds in www.gtk.org have most of libraries compiled dynamically. I was mostly speaking about MinGW core binaries (the compiler, linker, etc). ldd shows that the compilers refers to the current libc on Debian for instance. Could work though, but needs some trial-and-error. You don't need to worry about them anyway, since Ubuntu, Fedora and OpenSUSE will provide them for you (other distros also have them). Let the distros themselves worry about their own tools. The problem might be python though, the cross-compiled Python that OBS uses are quite old (2.6). I don't use python so I'm not sure how big the impact would be, but you could compile the base GTK+ stack without python. Because it doesn't work with newer Python (2.7 and ). I think GLib needs it ; could be patched around, have to check. I could cross-compile GLib with Python 2.6 without any patches. I don't think GLib requires it, though if you are planning to cross-compile gobject-introspection, you will need (though as far as I know, it only requires Python 2.5). That means you depend on a precise distro version. I recently moved from the builds for OpenSUSE 12.1 to 12.3 (and did that before many times before), upgraded my system many times too (since Ubuntu Oneiric I think), and been using it for about 2 years, so I don't think it is a problem. And I still use the packages I compiled myself before along with the newer set of libraries, seems like there are no problems. Plus, my tests have proven that it matters while building. There are some fixes for libtool and the compiler itself in the buildenv (see the 64-bit one) ; if you use a different version, it will sometimes break the build. A solution would be to have a standalone MinGW install for Linux. I've googled for one without success. If one doesn't exist, the ultimate solution whould be to create one by recompiling MinGW statically myself, that means recompiling the compiler : I don't know anything about that, it will take lots of time. Ubuntu, Fedora and OpenSUSE have the cross-compilers in their repos. OBS uses MinGW-w64 GCC 4.8 while I use MinGW-w64 GCC 4.6.3 in Ubuntu. I use their builds alongside each other. A year before I even combine MinGW-32 and MinGW-w64 builds, though I thought that might be a bad idea, and Ubuntu has MinGW-w64 cross-compilers anyway. If you want to build MinGW-w64, you could check OBS which have the most recent GCC cross-compilers. - GTK+3 build process
