Re: Optimizing GtkListBox for many rows

[Sam Thursfield]

hi Timm

On Mon, Aug 31, 2015 at 10:49 AM, Timm Bäder  wrote:
> Hi,
>
> if you've ever worked with a GtkListBox that has many rows, you probably
> know about the performance problems.  These are mostly not even related
> to drawing or scrolling.  The biggest problem is just allocating all of
> those rows (bonus points if every row uses a composite template, so you
> have to parse XML and create all those widgets/objects, set the
> properties, etc.) and size allocation.
>
> And I guess basically everyone knows how mobile UIs solve (or avoid)
> thsi problem: they just estimate the list height, and only keep as many
> rows around as they need to cover the current viewport.  This way
> obviously needs a backing model implementation (which we have now with
> GListModel) and a function that just takes an item and assigns the data
> to the corresponsing widgets etc.
>
> Earlier this year I've started to play around with such a
> widget-recycling listbox implementation here:
> https://github.com/baedert/listbox-test (don't judge my commit
> messages).  It's currrently written in Vala (so I can write stuff
> faster).  The repo includes a few demos which work more or less, you
> just have to (un)comment the corresponding lines int the Makefile.  The
> ideal case, i.e. "all rows are visible and all rows have the same
> height" seems to work already.
>
> I've talked to at least 4 people about this and I know a few others have
> worked on an implementation, too, so I think it's better to just
> collect all the knowledge we have instead of smoeone writing it on
> their own.  The current implementation faces a few problems, mainly
> regarding scrolling:

...

> I hope I didn't forget anything and I'm curious what you alll think and
> what solutions you have for all those problems, cheers.


I started prototyping something similar a while back, but with kind of
a different angle.

GListModel has a 'g_list_model_get_n_items()' function. I am
interested in the case where the data model doesn't actually know how
many items it has, but might be able to estimate. This is useful when
you have a database query across a big data set, with a whole lot of
joins and stuff too so that even doing COUNT() of the number of rows
might take longer than 10 seconds.

I came up with a PagedDataModel interface with 5 methods:
first_page(), next_page(), prev_page(), last_page(),
estimate_row_count() and get_page_for_position(). Each page would hold
a certain number of rows in memory. The get_page_for_position()
function allows jumping through the model with the scroll bar: you
pass it a float between 0 and 1, and it returns you the page of data
*around* that position.

Row numbers are relative to the page. There are no absolute row
numbers at all. Pages have a 'normal' size (100 rows, for example) but
the model can return a smaller page, to ensure that each row is only
ever in one page.

To take the example of an SQL database, you could implement a
PagedDataModel interface by using OFFSET and LIMIT, and by using COUNT
on a simplified version of the query to estimate the number of rows
quickly.

It's a bit crazy and I never got far enough with it to prove that it
wasn't *too* crazy, or that it provided any speed/memory benefits in
real use cases.  It's also a fairly niche usecase, I don't think it's
necessarily something Gtk+ itself needs to support. But perhaps it's
good to have in mind.

Prototype code is here:
,
it's pretty bananas. I had a go at hacking GtkTreeView to display this
kind of model via a GtkTreeModel 'adaptor', too, but the code I linked
to doesn't work because it emits signals like row-changed and
row-added from *within* calls like gtk_tree_model_iter_next(), which
breaks everything.

I hope this is interesting, anyway
Sam
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: File chooser recent-files (was: Re: Guidelines for stable branch changes in GLib/Gtk)

[Sam Thursfield]

On Fri, Nov 16, 2012 at 7:27 PM, Federico Mena Quintero
feder...@gnome.orgwrote:

 On Sun, 2012-11-11 at 15:24 -0500, Ryan Lortie wrote:

  3) The file chooser recent folder changes that landed in 3.0 and also
  on 2.x.
 
  I consider the last case to be particularly egregious because nothing
  was broken to start with and the changes were highly visible from a UI
  standpoint.  As I understand it, GNOME enters UI freeze at a particular
  point in time and never leaves it (on a given stable release).  We can
  argue that Gtk is not GNOME, of course...


 ...

(The file chooser is a bit peculiar; I've wanted to keep it as much in
 sync as possible between GTK+ 2.24 and GTK+ 3.x, because Big Important
 Apps(tm) still use 2.24.  I didn't want a situation where the main apps
 use a shitty file chooser and only small/new Gnome utilities use the
 improved file chooser.)


Interesting point. A colleague of mine once proposed that we move the file
chooser out of the toolkit completely and into a separate process, so that
all applications would use the same file chooser, and it would also be
easier for users to customise. I realise it would probably be a
non-starter, since Gtk+ currently allows embedding and modifying the file
chooser dialog, so to be at all compatible we would end up needing
GtkPlug/GtkSocket and it would be crazy mess. But I like it in theory


 In [1] I wrote a detailed reasoning for starting up in recently-used
 mode.  I still think that reasoning is correct.  However, you and other
 people clearly don't like the resulting behavior.

 Still, I've had even other people tell me that they like the new
 behavior.


The biggest issue I've had with the feature is that the list of recently
used folders in the 'Save As' dialog only displays the name of the folder,
not its full path. Which of the 6 folders named 'src' did I want to use
again?

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

Re: FW: Tree structure for a win32 application deployment

[Sam Thursfield]

Hi

On Sat, Feb 11, 2012 at 3:24 AM, Fan Chun-wei fanc...@yahoo.com.tw wrote:




 Sorry, I am resending this as I missed the mail list when I sent this last 
 night from my phone :)

 Setting PATH would work, or (assuming your app isn't intended to be run
 from the command line) you could use AppPaths:

 http://msdn.microsoft.com/en-us/library/windows/desktop/ee872121%28v=vs.85%29.aspx

I don' twant to  with the system environment PATH variable because I learned 
that's not the right way to work with GTK.
I tried AppPath
 I think what was meant is to start a cmd prompt and use the command set 
 PATH=some_path_seperated_by_; in it prior to running your program in it, 
 which means the set path is only valid for this cmd prompt.

 Another alternative is to use a simple .bat file containing the set 
 PATH=some_path_seperated_by_; followed by the call to your program's .exe

A more advanced way to do this is compile your application as a
library and then have a small loader stub resolve the paths to Gtk+
and then the application at runtime. This is how Pidgin works, for
example:

http://developer.pidgin.im/viewmtn/revision/file/77872b7f18741bca0e5bda735debf9ea3e3d386f/pidgin/win32/winpidgin.c

although that is a particularly complicated example :)
___
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)

[Sam Thursfield]

On Wed, Sep 28, 2011 at 10:27 AM, Kean Johnston kean.johns...@gmail.com wrote:
 Do you have a use case where hash-table lookups would be a bottleneck?

 Small mobile devices. Devices with only 64MB of RAM to play with. Embedded
 devices. Just because GLib is used mainly in GNOME don't make the assumption
 its the ONLY place. Not every deployment of GLib applications is on a
 multi-core CPU system with multi-gigs of memory, or even with traditional
 hard disks. Or even hard disks at all. Places where you are using GLib
 becuase its relatively small, not using the massive overhead that is GIO and
 which serves a different purpose entirely. Just becuase GLib and GIO come in
 the same tar does NOT mean they are always deployed side by side.

Writing embedded code and writing code that is portable between three
major desktop OSes are essentially orthogonal concerns. Scripting
languages such as Python use hash tables for all their namespace
lookups and as a common data structure - it's not a huge performance
concern.

 With dual-core CPUs we have nowadays, disk access is likely to be much
 slower than the hash-table work that GIO produces. And few programs
 would need to stat that many files anyway.

 Really? On what do you base that information? There are three applications I
 want to write that even brought me to the GLib / Gtk+ world and ALL of them
 use stat because they are dealing with files. The bottom line is, although
 stat may be a low level system call, applications deal with files. A LOT. A
 HELL of a lot. stat is a basic file operation. It can be made to be more
 portable. That's all I am trying to do. It can abstract 95% of all of the
 problem areas. If you have an application that needs very specific,
 tied-to-one-OS stat structures then by all means use stat. But when a
 *Platform* library isn't abstracting a basic *platform* call, that's a
 problem and I don't understand all the resistance to it.

The problem is that stat is API from the 1970's. None of us really
want to prolong the life of code with such readable names as S_IFMT,
S_IFREG, st_blksize and EBADF. One of GIO's design goals was to come
up with a fully portable, modern abstraction on top of all this. I for
one would much rather be working with
G_FILE_ATTRIBUTE_STANDARD_IS_BACKUP, G_FILE_ATTRIBUTE_TIME_ACCESS etc.

GLib is a 21st century platform library, not a pile of portability
hacks. I admit that for convenience it's managed to acquire a bunch of
portability hacks, but this isn't a design goal. If you would like to
use GIO but find measurable performance problems or missing
functionality, bug reports are welcome.

Sam
___
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?

[Sam Thursfield]

On Thu, Sep 8, 2011 at 6:53 PM, Dieter Verfaillie
diet...@optionexplicit.be wrote:
 On Thu, 8 Sep 2011 14:18:41 +0100, Sam Thursfield wrote:
 Let me first remind everyone that
 https://live.gnome.org/Windows/Discussion has a good summary of all
 things that are being discussed here. We're kind of heading in four
 different directions at once (fedora-mingw, MSVC, native mingw, OBS)
 so it's important we keep track :)

 Maybe it would be a good idea to stop insisting our
 beloved GNOME platform should only have 1 blessed set
 of binaries for Windows altogether and embrace the
 diversity that has been created. All these options
 are there for a reason. All of them. At the end of
 the day, Free Software development and GNOME are all
 about choice, right?

I agree with you here - and I haven't seen anyone insisting otherwise,
it's more a case of time to make it happen. Qt for example provides a
separate SDK for MSVC and for mingw. A specific MSVC version could be
targetted to allow use of the MSVCRT9.DLL. Although more effort is
needed to do this, it seems to be available, and it's probably a good
thing not to have the MSVC import libs generated by an uninterested
mingw developer or vice versa.

 So then it comes down to properly advertising and
 documenting the choices we have. Something along the
 lines of What's the right option for my situation? on
 live.gnome.org and www.gtk.org. Intended audience being
 application developers and packagers, off course.

 For example:

 - I can't or don't want to write a native windows port
  for my application, but still want it to work on Windows:
     It must be your lucky day! Go have a look at Cygwin,
      it provides a POSIX emulation layer on top of Windows.
     Best bet for support is some place Cygwin related
    ! Note downsides here
    == Happy customer :)

 - I want or have to use Visual Studio on Windows:
     Sure, here's how to build GTK+ with Visual Studio
      Solution files.
     And here you can learn how to build your own applications
      with Visual Studio.
     These binaries are linked against msvcrA.dll, for use
      with Visual Studio B.
     And here's binaries that are linked against msvcrC.dll
      for use with Vidual Studio D.
     Best bet for support is ???
    ! Make sure you are allowed to redistribute msvcr?.dll.
      Consult ??? for more information.
    ! Note other downsides here.
    == Have a blast!

 - I don't have/want Visual Studio. gcc on windows?
     No problem. There's a complete Free toolchain
      called MinGW that can function together with a
      minimal POSIX emulation layer called MSYS.
     mingw-get update  mingw-get install gnome-sdk
     These binaries are linked against msvcrt.dll
      and can be used with mingw.org's compiler.
     These binaries come with gobject-introspection support
      out of the box. Well, not yet, but real soon now ;)
     Best bet for support is ???
    ! Only works on Windows XP or newer.
    ! Note other downsides here.
    == Have fun!

 - Hey, I want to cross compile my stuff from Linux?
     Cool, have a look at OBS and this script that
      automatically downloads everything you've ever
      dreamed of.
     These binaries are linked against msvcrt.dll and
      can be used with mingw-w64's compilers
     Best bet for support is ???
    ! Note downsides here.
    == Happy hacking!

     Or have a look at fedora-mingw
     These binaries are linked against msvcrt.dll and
      can be used with mingw.org's compilers (for now, but
      there's a message somewhere about migrating to mingw-w64
      whenever mingw-w64 has passed Redhat's legal audit).
     Best bet for support is ???
    ! Note downsides here.
    == Happy hacking!

     Or have a look at (Debian's||Gentoo's||...) MinGW
      environment:
     List specifics here
    ...

 - All good and well, but I don't want to bundle a complete
  and private set of dependencies of the GNOME platform?
     No problem. Here's how to use a shared version of
      the platform.
     Linked against msvcr10, for use with Visual Studio
      and the DDK.
     Best bet for support is ???
    ! Note downsides here.
    = Good luck!

 What do you think? Can we try and collaborate on such a
 text on live.gnome.org and/or windows-devel-list or something?

I guess windows-devel-list is a good place :) My personal view is that
your list is daunting for a basic how to use Gtk+ page - we should
just suggest mingw and MSVC. For more advanced systems like Cygwin we
don't need to provide binaries (Gtk+ should be available in their
package repositories) so the most we really need to do is point users
towards them.

Sam
___
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?

[Sam Thursfield]

Let me first remind everyone that
https://live.gnome.org/Windows/Discussion has a good summary of all
things that are being discussed here. We're kind of heading in four
different directions at once (fedora-mingw, MSVC, native mingw, OBS)
so it's important we keep track :)

On Thu, Sep 8, 2011 at 1:12 PM, John Stowers
john.stowers.li...@gmail.com wrote:

 It takes a build description file like:
 https://github.com/dieterv/pygtk-installer/blob/master/wix/2.24.0.win32.xml
 downloads required files, extracts them, applies transformations if
 requested,
 repacks, etc until finally a .msi is produced.

 It is currently capable of packaging zips from ftp.gnome.org and also
 Python
 distutils generated .msi files (for PyCairo, PyGTK, PyGObject, etc).
 Cleaning this up and making it more generic and easier to use is
 something
 I've been wanting to do for a long time now...

 Cool!

 note: these are my uninformed ideas, I have not actually seen the
 implementation for the methods you describe...

 I think JHBuild is *almost* able to do this itself. If the binary/zip
 module type patch was applied to JHbuild then I think this would not be
 too much work to complete.

I'm actually not sure the binary module type is such a good idea any
more. It used to be the case that in my windows fork of jhbuild the
binary module type was used to upgrade and patch various parts of MSYS
and get hold of deps like libpng, zlib, etc. Since then, mingw-get has
arrived and the general state of MSYS is a lot stronger, to the point
where it doesn't really need patching at all any more. As for the deps
- I reckon the way forward is to come up with a script that will bring
together all of the build deps for the Gtk+ stack and provision them
for developers either in a mingw-get repo, or just as a massive the
entire build environment .ZIP file. I'm thinking of this from a
mingw-only point of view, but presumably the same script could
generate a build environment for MSVC too with a little extra code.

 AIUI JHbuild now tracks installed files and can create a manifest. This
 manifest + JHbuild supporting binary/zip module types would give you all
 the meta information to write msi/wix/nsi installers.

I agree that this should be possible and would be awesome. Not sure
how the binary module type is useful here - am I missing something?

Sam
___
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?

[Sam Thursfield]

On Thu, Sep 8, 2011 at 2:15 PM, Kean Johnston kean.johns...@gmail.com wrote:
 At least bundling everything with my app let's me sleep at night, knowing
 some unknown installer out there is not going to break my stuff which has
 taken countless hours to build.

 Why do you think this is unique to Windows? If you create a .rpm or .deb
 that depends on version x.y.z of some library, you have absolutely NO
 guarantees that during a system update (or some other package requiring a
 later version of that library) thatt the library isn't updated in some way
 that breaks you. In fact, due to conventions of using different namespaces
 for conflicting versions on Windows, that problem is rather neatly avoided.

 Having a shared runtime leads to extremely hard to debug situations as
 the shared part is in a continues state of unknown: Who has done what
 to it? Why? Been there, done that, moved on :)

 Just because you've had some difficulties with it doesn't mean its not an
 easily solved problem. Just because its been badly done in the past doesn't
 mean the concept of having a shared component is invalid, just that the
 implementation of it was. And as for things being in a state of unknown,
 that's just absolutely untrue. If constructed properly, you can query the
 *exact* version of each library you depend on, using an OS-provided API, and
 store information about each exact version in one very easy to use,
 centrally managed location.

 No need to fiddle with %PATH% when your executable lives right next
 to libglib-2.0.dll, libgtk-2.0.dll etc. In other words, put your .exe
 and .dll's in the bin directory. Have a look at how GIMP does things,
 it's a fine example of how to package things for Windows in a sane way.

 I disagree, its a piss-poor and lazy way. it may WORK, but it is far from
 fine if things were done properly (which I am trying very hard to do). GTK
 absolutely *CAN* be created as a well-managed, stable, centrally available
 component. The authors of an individual application (like GIMP) may *choose*
 to bundle their own copies if they have some reason (or even just desire) to
 do so but it is NOT a shining example of how things should be done. If you
 believe it is then I fully expect to see you championing the
 install-with-application notion for GTK on Linux, because the problem domain
 is identical.

 These days, I don't think it matters much having a couple of different
 copies of GTK+ and it's dependencies on disk. As long as things work

 Sure, when there are only about 5 apps that use it that may be true. When
 you have a larger agenda, where you are trying to attract not only other
 open source projects but also commercial ones, that falls flat on its face
 I'm afraid.

 hit a button and have a .zip and/or .msi produced automatically. The zip
 would be the equivalent of the GTK+ bundle but crafted especially for
 your project and the .msi a full fledged installer, giving your users
 the choice of how they want to install your project on their machines.

 OMG NO! That's abhorent! Ask yourself this question: would you accept that
 behaviour on Linux? Every application that uses GTK bundling its own copy?
 That is .. *every single gnome application* bundling its own copy of GTK? Of
 course you wouldn't. Why are you then suggesting it for Windows?

In theory, I agree with what you're trying to achieve here. However,
in practice I think there would be better places to direct your energy
- keeping in mind Windows takes up about 2GB of disk space these days,
12MB of DLL's for each of the maybe 10 Gtk apps I have on Windows
really doesn't make much of an impact, and using shared libraries
probably always be more fragile than just bundling them (extra
complexity always introduces bugs). App developers have to manage
their own updates on Windows anyway, so keeping deps as well as the
actual app up to date shouldn't be any extra effort. Do you any other
reasons for doing this?

I don't want to demotivate you here, my point is just that there is a
lot of work to be done to get Gtk+ 3 up to scratch on Windows (writing
an entire theme engine, for example) so we need to be smart about what
we spend time on.

Sam
___
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)

[Sam Thursfield]

Hi

On Fri, Jul 22, 2011 at 5:35 AM, Fan Chun-wei fanc...@yahoo.com.tw wrote:
 I don't know whether this might be helpful with this part and regard, but I
 am posting my point of view here anyways for references...

 Currently I am maintaining the Visual C++ build files for the GTK+ stack
 (GLib, ATK, GDK-Pixbuf, Pango, GTK+-2.x/3.x), and these files are kept
 up-to-date as far as possible in the master branch-and there are at least
 Visual C++ 2008 build files for these packages in their latest unstable
 tarball releases (in fact Visual C++ 2010 build files are also in every
 one of these except for Pango and GTK+-2.x, as they are under review for
 Pango and I am seeing whether people are interested for them for GTK+-2.x),
 and even (Visual C++ 2008/2010) in the stable releases of GLib, ATK and
 GTK+-2.x/3.x.  These files will help to enable building the GTK+ stack
 on Windows (for those who will use the Microsoft toolchain) much easier
 and faster on Windows (I think MinGW is a formidable project, but I don't
 think it suits my purposes well, AFAICT).

 I would also like to be able to help in getting GOBject-Introspection (GI)
 being buildable/workable for Visual C++, especially as the official Python
 builds are built with Visual C++ 2008.  I might need help though on the
 python scripts as they call GCC directly... but anyways for now

 By hacking the pkg-config .pc files and purging C99isms
 from the various code, it is possible for one to build pycairo[1],
 pygobject (sans GI support), pygtk2 and pygtksourceview2 entirely with the
 MSVC 2008 toolchain, for example using distutils.

It's a small step but I just added a page to the wiki:

https://live.gnome.org/Windows/Discussion

Since there's a few of us all doing different things in this area I
think it would be helpful if we at least all kept that up to date with
what we are doing and why, and hopefully it can be the first step to a
bit more collaboration.

Sam
___
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)

[Sam Thursfield]

Hi Dieter

On Mon, Jul 11, 2011 at 9:22 PM, Dieter Verfaillie
diet...@optionexplicit.be wrote:
 Hi,

 Some time ago I've asked Tor how his Windows build environment
 looked like and he shared everything to be able to recreate
 it (thanks again!). The various mails we exchanged and the
 resulting directory structure and scripts can be found here:
 https://www.github.com/dieterv/legacynativebuilds [1]

It's great that you've taken on to do this work, many thanks! I've
done some work on windows builds myself[1], and in fact there's more
people interested than it might appear so feel free to bring issues up
on this list. The more we coordinate our effort the better.

 The only differences between these and the packages already on
 ftp.gnome.org/www.gtk.org are:
 - the MSVC-compatible import libraries are missing from
  gtk+-dev_2.24.5-1_win32.zip (lib/gailutil.lib, lib/gdk-win32-2.0.lib
  and lib/gtk-win32-2.0.lib), I simply don't own a copy of
  Visual Studio 6 so these files have not been generated during
  build...

You can get the Visual C++ toolchain for free from the Windows SDK[2],
if you're interested in making these. Generating the import libs for
VC is super easy, you just need the .def file for the DLL (and not
even the actual DLL).

 As such, is there any interest in hosting these files on
 ftp.gnome.org/www.gtk.org? If there is, I'll gladly do the work
 and also provide a patch for http://www.gtk.org/download/win32.php

I'm sure there is, I don't know who is the person to give you access

 After that, I can go ahead and build an updated PyGTK All-in-one
 installer (see www.pygtk.org or
 ftp.gnome.org/pub/GNOME/binaries/win32/pygtk/2.24/) and
 glade3-bundle_3.8.0 (https://bugzilla.gnome.org/show_bug.cgi?id=634978).
 And before someone asks, both are *not*
 compatible with the binaries provided on build.opensuse.org (due
 to intl.dll/libintl-8.dll differences).

That's a whole new can of worms :) I share the dream that one day it
would be great to use the mingw cross compiler and an automated build
service but I think it's important to get native builds working more
reliably to begin with ..

Again, props for being a man of action
Sam

[1] http://afuera.me.uk/jhbuild-windows/
[2] 
https://www.microsoft.com/downloads/en/details.aspx?FamilyID=c17ba869-9671-4330-a63e-1fd44e0e2505displaylang=en
___
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)

[Sam Thursfield]

On Tue, Jul 12, 2011 at 1:10 PM, Dieter Verfaillie
diet...@optionexplicit.be wrote:
 Quoting Sam Thursfield sss...@gmail.com:
 You can get the Visual C++ toolchain for free from the Windows SDK[2],
 if you're interested in making these. Generating the import libs for
 VC is super easy, you just need the .def file for the DLL (and not
 even the actual DLL).

 Hmm, I thought lib.exe was no longer available in the Windows 7 SDK?

 I did discover yesterday evening, a couple of hours after sending
 my original message, that what I suppose is the last version of lib.exe
 still available for download can be found in the Windows Server 2003
 R2 Platform SDK:
 http://www.microsoft.com/download/en/details.aspx?id=12675 [1]

I've got version 6.0 of the SDK and lib.exe is definitely there. Can't
remember if I saw it in 7.0 or not.

 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...

actually not such a crack idea, there's a lot of hacks in different
apps that could go in there. But why not just put them in mainline?

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

Re: Glib: a Win32 discussion

[Sam Thursfield]

2011/4/7 Krzysztof Kosiński tweenk...@gmail.com:
 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:

 snip

 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.

GSettings has switchable backends. An app, or a user, can choose
between the registry backend or the keyfile backend at runtime.

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

Re: Precompiled GTK3 for windows?

[Sam Thursfield]

Hi Lothar,

On Sun, Mar 13, 2011 at 3:19 PM, Lothar Scholz llot...@web.de wrote:
 Hello gtk-devel-list,

 Is there any place where i can download it. The GTK site only provides 
 binaries for the 2.22 version.

Nobody has had time to create these yet, and in truth I don't know if
Gtk 3 is very stable on Win32 at this point.

You can try to build it yourself using jhbuild, some out-of-date
instruction are here: http://afuera.me.uk/jhbuild-windows (you would
need to use the new mingw/msys packages however)

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

[ann] gsettings support in waf

[Sam Thursfield]

Hi everyone!
I wrote a patch to add gsettings support to waf, which has just been
merged into SVN.

Here is how it is used:

http://code.google.com/p/waf/source/browse/trunk/demos/glib2/wscript

Presumably it will be released in waf 1.6.0, whenever that is
released, or you can easily use waf SVN (but be warned you have a few
changes to do to old wscript files to make them work with the 1.6
branch)

hope this is useful!
Sam
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Proposal for Introducing a high level framework of concurrent asynchronous programming

[Sam Thursfield]

On Tue, Sep 7, 2010 at 9:02 AM, cee1 fykc...@gmail.com wrote:
 Hi all,
 Glib has GMainLoop for asynchronous programming and GThread  GThreadPool
 for concurrent programming. To combine the advantages of them two, users
 need to take care of threads themselves in sources' callbacks. This
 introduces some kind of complexity and also duplicate works.
 So introducing a high level framework of concurrent  asynchronous
 programming will make writing high performance code more easily.
 Apple has made this in its GCD(Grand Central
 Dispatch, http://lwn.net/Articles/352978/), and I've written some slides
 about it:

 http://dev.lemote.com/files/upload/people/~chenj/libdispatch/libdispatch.pdf
 http://dev.lemote.com/files/upload/people/~chenj/libdispatch/libdispatch-event.pdf

       Here are odp versions:

 http://dev.lemote.com/files/upload/people/~chenj/libdispatch/libdispatch.odp
 http://dev.lemote.com/files/upload/people/~chenj/libdispatch/libdispatch-event.odp

 My ideas are:

 Implement a similar framework in glib.
 Make full use of epoll and eventfd, etc.
 Rewrite some code in GIO, using this new framework.


Have a look at chergert's Iris library, which heads down the same road
you are proposing:

http://github.com/chergert/iris

 --
 Regards,
 - cee1

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


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

Re: disabling GTK+ features to shrink GTK+

[Sam Thursfield]

On Mon, Jun 14, 2010 at 11:24 PM, Andrew Ziem ahz...@gmail.com wrote:
 Would GTK+ upstream accept patches to disable GTK+ features?  For example,

    ./configure --disable-file-chooser-disable

 would make the GtkFileChooser() an empty stub.

 I ship GTK+ in my application's Windows installer, and I'd like to
 shrink GTK+ because my application's dependencies are ~95% of the
 installer size and GTK+ is about half.  I tried other methods [1] with
 mixed results.

A more socially-minded approach would be to work on the problem of
sharing a GTK+ runtime between all apps on a system. It's perhaps not
an easy problem, due different requirements in versions and specific
libraries, but it's a more long-term solution to the problem of GTK+'s
big runtime than for each app using GTK+ on Windows to build and
distribute their own incompatible versions.

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

GtkTreeView and lazy population

[Sam Thursfield]

Hi,
I have developed a tree model which takes a long time to find all its
root nodes. Short batches of 50-100 execute in negligible time, but it
will be operate in cases with upwards of 100k root nodes.

It seems as though the first thing GtkTreeView does on receiving the
model is to iterate through every root node, calling iter_has_child
and iter_next for each until iter_next returns FALSE. This then leads
to my question - does anyone think it possible to modify GtkTreeView
to give it much lazier population? To display itself, surely it only
needs however many rows are visible .. and even these could be left
blank and drawn as its queries return.

My initial instinct is that the only issue would be the scroll bar
going nuts, which I'm sure could be solved with an
tree_model_estimate_n_children or something stupid. Can anyone advise
me on if this seems like a good/bad plan, or a problem that's been
tackled before?

Thanks for any help
Sam
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list