Re: GtkSourceView build for Windows?
On lun, 2008-09-08 at 14:35 +0200, Miroslav Rajcic wrote: > Does anyone know a good Windows build for GtkSourceView and its dependencies > ? > > I've managed to find only this build: > http://code.google.com/p/bpad/wiki/GtksourceviewForWindows > > When unpacked, it provides .a file instead of .lib format. > I could link against that, but then my application crashes on startup (I was > using Visual Studio 2005). > > I would like to see the Windows build GtkSourceView and dependencies > being offered at the official http://www.gtk.org pages. > Official gtksourceview windows binaries are available at http://ftp.gnome.org/pub/gnome/binaries/win32/gtksourceview/ and are linked from the download page of gtksourceview web site at http://projects.gnome.org/gtksourceview Ciao Paolo > ___ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: large performance difference between gtktextview and gtksourceview
Actually, gtksourceview is a subclass of gtktextview so it supports BiDi and i18n as good as gtktextview does. If it doesn't it is a bug. With regard to the performance differences, it seems very strange that you see a difference, especially one where gtksourceview is faster. Are you sure you are comparing apples to apples? (E.g is the program is exactly the same except for using sourceview/buffer? Or do thay load the content differently and one feeds it in chunks to the buffer while the other doesn't or other things). That said if you are going to look into textview performance that would only make me happy. Feel free to drop by on irc in the #gedit channel to discuss gtksourceview any time. Ciao Paolo On Fri, 2010-11-05 at 11:47 +0200, Dov Grobgeld wrote: > Last time I checked (which was a long time ago) gtksourceview did not > support BiDi and possibly other i18n issues. But this per se is no > explanation for it being slower. And yes, performance can always be > improved. > > Regards, > Dov > > On Thu, Nov 4, 2010 at 18:12, Olivier Sessink wrote: > > > Hi all, > > > > loading 1Mb of UTF-8 encoded text into a gtk text view seems to take > > much more time than loading the same buffer into gtksourceview. Since > > gtksourceview has all of the functionality of gtktextview and more, > > where is this difference coming from? And does this mean that we can > > improve the performance of gtktextview? > > > > regards, > > Olivier > > ___ > > gtk-app-devel-list mailing list > > gtk-app-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > > > ___ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtksourceview-2.0 with custom paths
Hi Allin, gtksourceview by default uses the XDG base directory specification to lookup .lang files and style schemes, so it should "just work" without having to manually force the search path with gtk_source_language_manager_set_search_path. For instance gedit is ported to both windows and osx and the path of lang files does not have any special treatment as far as I recall. The important thing (at least for windows) is that your package follows the right conventions in the name of directories _relatively_ to your binary, for instance gedit's installer has: bin gedit.exe share gtksourceview-2.0 language-specs c.lang ... Ciao Paolo Il giorno lun, 22/08/2011 alle 20.00 -0400, Allin Cottrell ha scritto: > First off, sorry if this is the wrong place to ask. I see from > http://projects.gnome.org/gtksourceview//development.html that the > recommendation is to ask about gtksourceview on gnome-devtools, but > that list appears to be pretty much moribund so I'm trying here. > > I work on a cross-platform GTK app, and I'm trying to get > gtksourceview-2.0 working in the context of packages for Windows and > OS X, where I don't know the final installation path and so I need > to specify the search paths for language-specs and style files at > runtime. > > Right now I'm emulating this situation on Linux, and while I seem to > be close to success, no cigar yet. Any help would be appreciated. > (BTW, my testing is with version 2.10.5, which I take to be "latest > stable" in the 2.0 series, but should I be using 2.11.N?) > > Step 1: Specify a non-standard location for the lang files. Before > displaying any text I grab the default languages manager with > >gtk_source_language_manager_get_default() > > and set a custom location using > >gtk_source_language_manager_set_search_path > > Result: Success. I get syntax highlighting OK, even if I hide the > standard language-specs directory. > > Step 2: Specify a non-standard location for the style files. Again, > before displaying anything I grab the default style scheme manager > with > >gtk_source_style_scheme_manager_get_default() > > and set a custom directory using > >gtk_source_style_scheme_manager_set_search_path() >gtk_source_style_scheme_manager_force_rescan() > > (I'm not sure the latter call is necessary, but I threw it in for > good measure.) > > Result: Failure: no syntax highlighting. > > Though I don't need styles other than "classic", I've tried this > with the custom directory containing the entire contents of the > standard styles directory. > > I guess I must be missing something. By inserting print statements I > can see that after Step 2, > >gtk_source_style_scheme_manager_get_scheme_ids() > > is giving an apparently valid list of ids, corresponding to the > style xml files in the non-standard location (which in some > experiments was a subset of the full list, but including "classic"). > > One more observation: In each case my setting of the "non-standard > location" was an array of just two *gchars, the custom path followed > by NULL. In the style-scheme-manager case (only), the result (syntax > highlighting or none) was conditional on whether or not the standard > styles directory was "visible" or hidden (renamed) at runtime. > ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Re[2]: Compiling for Windows [Was: argv revisited]
On Tue, May 3, 2016 at 9:32 PM, Andrew Robinson wrote: > Been there, done that. The latest version of GTK+ that GNOME has is 2.24, > i.e. > -- there are no 3.x binaries. > > There are many ways to have good gtk3 binaries for Windows: - if you are using mingw you can fetch updated gtk3 binaries from msys2 ( https://github.com/Alexpux/MSYS2-packages) - if you are cross compling Fedora and other distros provide mingw binaries - if you are using MSVC, there are no pre-built binaries, but https://github.com/wingtk/gtk-win32 provides a script to build them easily We decided to not distribute binaries from gtk.org/gnome.org anymore since we do not have the resources to do that for all the possible platforms and toolchain combinations. Other projects like msys2 are much better equipped to provide binaries (and this is the same on linux where binaries are provided by distros). Paolo ___ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Re[2]: Re[2]: Compiling for Windows [Was: argv revisited]
On Tue, May 3, 2016 at 11:52 PM, Andrew Robinson wrote: > The website, https://github.com/wingtk/gtk-win32, looks really good at > first > glance, until you read the fine print where it says, "Any version of VS > apart > from 2013 is not supported". What if I don't have VS 2013, what then? You > can't download it from Microsoft's website although you can buy it for > $400+ > from Amazon. MSVC Community Edition if free (free as in beer, not free software) and works just fine. Mingw doesn't have any binaries for GTK+, it is a compiler and you have to > download 27 sub-projects that the GTK+ toolkit is comprised of, then > compile > them all with the (hopefully) proper command line switches to get > binaries. It > is a laborious and a very, very poorly documented process. Again, no thank > you. > > Not really. It is a matter of running a couple of commands and you fetch the compiled binaries for gtk. This old blog post is still valid https://blogs.gnome.org/nacho/2014/08/01/how-to-build-your-gtk-application-on-windows/ I have never seen a cross-compiled version of Fedora. Is it related to the > mythical Chimera? > > Not sure because I do not do cross compiling (we use both the above methods in production to distribute windows applications). As far as I know it is just a matter of "dnf installl gtk3-mingw64" or something similar. Paolo ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: WIN32 - GTKSourceview
Il giorno dom, 24/07/2005 alle 23.39 +0800, Joseph Turner ha scritto:
> Hello,
> Got a rather intriguing issue under windows.
>
> Got a gtksourceview with some text that I've put in there
> When I press enter in the box it doesn't add extra lines to the text,
> but it does increment the line number on the LHS
> (as shown by http://leederville.net/~joeman/gsview.jpg )
>
> This issue does not occur in Linux.
>
> Could this be a CR/LF issue of some kind?
>
Yup, looks like one. Does it happen only with "auto indent" turned on? I
seem to recall that with "auto indent" on, gtksourceview intercepts the
"Return" key press and probably it hardcodes insert("\n").
You may try to patch the relevant code in gtksourceview.c.
By the way, I cannot speak for Paolo Maggi, but I'm pretty sure that the
modifications made to build on Windows would be very welcome upstream.
Paolo
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
