Re: Faster UTF-8 decoding in GLib
On Tue, 2010-03-16 at 14:09 -0400, Behdad Esfahbod wrote: > On 03/16/2010 01:18 PM, Daniel Elstner wrote: > > Hi, > > > > Am Dienstag, den 16.03.2010, 13:01 -0400 schrieb Behdad Esfahbod: > >>> > >>> I've made a glib branch where I tried to optimize the UTF-8 decoding > >>> routines: > >>> http://git.collabora.co.uk/?p=user/zabaluev/glib.git;a=shortlog;h=refs/heads/fast-utf8 > >> > >> Before any changes are made, can you provide real-world performance > >> profiles > >> suggesting that UTF-8 decoding is taking a noticeable time of any > >> particular > >> real-world use case? If no, I don't see the point. > > > > Well, I would see a point since UTF-8 decoding is a fairly generic > > operation. It cannot hurt to be as fast as possible at this task. > > Assuming, of course, that the optimization does not introduce other > > costs elsewhere, which I think the proposal unfortunately does. > > That's one of the worst ideas as far as software goes. If an operation takes > 1% of your application time and you make it 1000 times faster, you know how > much total faster your application would run? 1.01x faster... Because in Tracker we need to find word boundaries for indexing of free text searchable fields, I think UTF-8 performance enhancements would be a significant improvement for our project. > That developer time can be put somewhere more useful instead Like > optimizing something that is taking 20% time, or 50%, or 70%. The developer time has in this case already been committed, though. Cheers, Philip ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thumbnailing service project; opinions, suggestions?
On Tue, 2009-10-20 at 16:34 +0200, Mark wrote: > >> I do miss some vital parts: > >> - Designing the daemon and plugin architecture > >> - Making those 2 > >> > >> That's what i see missing now but i probably missed a few other parts. > > What does "Making those 2" mean? [CUT] > 1. designing a daemon With a specialized thumbnailer for PDF thumbnails you'll be designing a daemon. > 2. designing a plugin architecture I don't know what that means anyway. A plugin "architecture" can mean: - Registering yourself to a DBus service, so that it knows about your existence and can delegate work to you. This is what a specialized thumbnailer is wrt Tumbler. You could see such a thumbnailer as a plugin for Tumbler (or any other thumbnail service). - Implementing an interface in Java or .NET, or implementing Event handlers in .NET, or anonymous classes in Java, or delegates in C#, that provide functionality that a core application doesn't have and that you provide dynamically by installing an assembly (or .class file, in Java) somewhere "on demand". - Making a struct with a bunch of function pointers that you return at a "get_plugin_info"-like function that you find with dlsym after you dlopen a .so file from a core application "on demand". You can also use GModule in GLib to make all this a lot more easy. - etc ... > 3. making the daemon With a specialized thumbnailer for PDF thumbnails you'll be making a daemon. > 4. making the plugin architecture Same answer as #2 > like that Yes? > > I think you are just looking for a reason to make your own one. That's > > you decision of course. It's called NIH, but anyway (I can't and wont > > stop you from doing that). > > you just don't seem to get the point. I'm quite afraid that I do get the point ... :-\ > I need to build something from the ground up (making uml, class > diagrams and such).. and based on that i need to make the actual > program. Yes, you could do that for a specialized thumbnailer for PDF thumbnails. > Tumbler is existing already! i would be making those diagrams based on > the current inner working which is not the way to go. There's no specialized thumbnailer for PDF thumbnails (for Tumbler) yet. > Oke, i know that for each project i start outside of school i don't > make a design at all or a very simple one and in that case i could > perfectly help tumbler. You can help Tumbler by making a specialized thumbnailer that makes PDF thumbnails, for example. > That, sadly, isn't the case (which i told you already on irc) Untrue, specialized thumbnailer that makes PDF thumbnails. > Just for that reason alone tumbler isn't a fine project for me to join > in this case. > Also i would like to learn as much as possible and that is less likely > to happen if i join tumbler. Eh? I disagree. But oh well. > I am not looking for reasons to make it all myself.. the requirements > simple.. require that. Untrue, I know about your requirements. I read them. And a specialized thumbnailer, that for example makes PDF thumbnails, fits it perfectly. > Now can we please quit bashing the idea that there will be 2 > thumbnailing services in a few months time and can i get some > constructive feedback about the ideas in my first post? The replies of the people who have replied so far is the constructive feedback on your first post. > Can i get the: > - Git > - gnome sub domain > - blog for this project on planet gnome and/or gtk That's not up to me. > As said a few times. the outline is right there (in the first post) > now all i can do is steer some more in one direction or the other. I > personally would like to steer in the optimizing direction... -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thumbnailing service project; opinions, suggestions?
On Tue, 2009-10-20 at 14:33 +0200, Mark wrote: > On Tue, Oct 20, 2009 at 1:08 PM, Philip Van Hoof wrote: > > On Mon, 2009-10-19 at 21:35 +0200, Mark wrote: > >> For Jannis and Philip, > >> Nice tumbler talk but could you two make suggestions for my project? ^_^ > > As I already wrote: > > > > A PDF thumbnailer that implements the 'specialized thumbnailer' spec > > that doesn't need to link with gdkpixbuf. [CUT] Please reply inline and cut away non-relevant things. > I do miss some vital parts: > - Designing the daemon and plugin architecture > - Making those 2 > > That's what i see missing now but i probably missed a few other parts. If you want to make a functional analysis of Tumbler, then go ahead. If you want to draw cute UML diagrams with the classes and interfaces being used, yeah sure. Sounds like useful documentation that doesn't exist atm What does "Making those 2" mean? You still have to make the specialized PDF thumbnailer. You can reuse the maemo-video-thumbnailer for getting a quick skeleton of the code. But if you prefer making an all new one in C++ or whatever ... yeah sure. I think you are just looking for a reason to make your own one. That's you decision of course. It's called NIH, but anyway (I can't and wont stop you from doing that). -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thumbnailing service project; opinions, suggestions?
On Tue, 2009-10-20 at 13:08 +0200, Philip Van Hoof wrote: > - You'll have to work with a queue handling the thumbnailing, as > Create isn't allowed to block, which means that GThreadQueue could for > example be used (which means that your work will involve dealing with > threads). Sorry that's GThreadPool, not queue. I have too many 'queue' words in my head at the moment ;-) -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thumbnailing service project; opinions, suggestions?
On Mon, 2009-10-19 at 21:35 +0200, Mark wrote: > For Jannis and Philip, > Nice tumbler talk but could you two make suggestions for my project? ^_^ As I already wrote: A PDF thumbnailer that implements the 'specialized thumbnailer' spec that doesn't need to link with gdkpixbuf. I think that matches your project description, it fits in the architec- ture of Tumbler (and if done right we could make this a project that many people will use and install alongside Tumbler). It's much more simple than developing an entire thumbnailer, as you only need to implement one D-Bus method called "Create". - You'll have to work with a queue handling the thumbnailing, as Create isn't allowed to block, which means that GThreadQueue could for example be used (which means that your work will involve dealing with threads). - You'll need to deal with DBus .service registration - You'll need to code against a specification (which is in general harder than doing your own thing - but schools like that) - It's a thumbnailer service and it could work standalone (which means that it fits your requirements for school) - You wont have the NIH syndrome. Nobody has yet made a PDF thumbnailer that implements the 'specialized thumbnailer' spec - It sounds doable within 8 weeks I suggest that you set up a gitorious repository, start with making a skeleton out of the maemo-video-thumbnailer project, adapt all the files that you read about in the specification, hollow out the methods, and then implement them for PDF files instead of video (GStreamer). You can check out libpoppler for dealing with PDF files. Poppler can be compiled not to use gdkpixbuf, but instead cairo as far as I know. I strongly advise to do that. Anyway, it's up to you. Also, it wont be about free-choice unless your thumbnailer implements the specification. Each new home-brew specification that isn't agreed by multiple people adds API clutter to the platform. ps. Specialized thumbnailers spec: http://live.gnome.org/ThumbnailerSpec#head-83f1d6d2084e75742104681ad94c29b8d0dd2052 ps. Note that we might make minor changes to this spec in the following days. Among them might be the optional Cancel() method and a parameter to the Create() method called "scheduler" (which you can also ignore, for now). -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Thumbnailing service project; opinions, suggestions?
On Mon, 2009-10-19 at 16:20 +0100, Rob Taylor wrote: > We already have a thumbnailing service that is only just now starting to > be used. A complete reimplementation of soemthing existing will not be a > very useful thing. I also suggest that 13weeks for your entire plan is > very over optimistic. I would suggest a better option would be to do a > library with optimised thumbnailing routines. This would also be very > useful for existng projects and probably result in you code being used > in a number of situations. > To add complexity you could also branch out > into making thumbnail clips for videos. If you write up such a plan > completely, i think you'd find it's more than enough work for a 13 week > project. Agree that a video thumbnailer would be very useful. However, we're already developing (/ hopefully this week finishing) a video thumbnailer that implements the 'specialized thumbnailer' spec (spec is available on the page that Mark mentioned). http://live.gnome.org/ThumbnailerSpec Code can be found here (again, this week it'll receive some improve- ments). This will likely also be the video thumbnailer that will make thumbnails for videos on Harmattan devices. http://maemo.gitorious.org/maemo-af/maemo-video-thumbnailer A *very* useful thumbnailer for Maemo Harmattan would be a PDF one that doesn't link with gdkpixbuf. At the Maemo conference in Amsterdam I spoke with one of the KOffice guys. He told me that there's some interest in making thumbnailers for all of the formats that KOffice supports. Probably using Qt C++. We're doing all this thumbnailing stuff in the open, you can find feature branches for Tumbler's integration into Harmattan here: http://maemo.gitorious.org/maemo-af/tumbler Among the branches you'll find work that removes usage of GdkPixbuf. The reason for that is that on Harmattan all GdkPixbuf usage is being replaced with libquill. You can find the libquill project here: http://maemo.gitorious.org/maemo-image-editor That libquill library still depends on qtimagefilter which might be hard for some people to get (there's an opensource release of it somewhere, but it ain't easy to get this stuff installed). This week will the libquill people work on refactoring-away this dependency (they told me). (Quill is a different project, I wont go further into it) You can find upstream Tumbler at the XFCE project. We're trying very hard to ensure that each feature and change introduced for Maemo Harmattan goes into the upstream project. Jannis Pohlmann is the XFCE developer responsible for the upstream Tumbler project. http://git.xfce.org/apps/tumbler/ Key features (on Maemo Harmattan, most/all are in upstream too): o. Two schedulers each having their own queue: Background and foreground. The background one is set to SCHED_IDLE and uses IOPRIO_CLASS_IDLE for I/O priorities. o. DBus signals are emitted with dbus_message_set_destination to avoid DBus traffic waking up processes needlessly o. Ready and Error in case of foreground are emitted immediately o. Ready and Error in case of background are emitted in group o. Unqueue also cancels I/O operations o. The mount-pre-unmount cancels I/O operations in case I/O takes place on the device being unmounted o. Abstracted cache (makes it possible to implement your own thumbnail cache, although we probably wont use this on Maemo) o. In Maemo we store JPEG instead of PNG (PNG is ~ braindead for this, as often are thumbnails in PNG of a JPEG larger and slower to load as the original JPEG) o. The libquill library for rescaling large images rapidly o. We'll ship with a specialized video thumbnailer that uses GStreamer o. etc -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Status on the TLS support in gio
On Sun, 2009-10-18 at 21:50 +0200, Javier Jardón wrote: > 2009/10/18 Philip Van Hoof : > > With GIO now supporting things like GSocket and GSocketConnection, what > > are the plans for TLS support? > > It's in the plans for Glib 2.24 [1] ( TLS (SSL) support for GSocket ). > Take a look to bug 588189 [2] > > Regards, > > [1] http://live.gnome.org/JavierJardon/GTKRoadmap > [2] https://bugzilla.gnome.org/show_bug.cgi?id=588189 Awesome, the info in the bug is what I was looking for. Looking forward to seeing Dan's work on this landing in GLib. This is going to be very useful for all of us. So keep on rocking, Dan! Thanks. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Status on the TLS support in gio
Hi there, With GIO now supporting things like GSocket and GSocketConnection, what are the plans for TLS support? The original GNIO git repositories had a GTLSConnection class, will this class be ported-to and be made available in stock glib/gio? ps. In bug 598852 I ported gtls.c to the current GIO API https://bugzilla.gnome.org/show_bug.cgi?id=598852 ps. Ryan told me Dan is working on this, adding Ryan and Dan in CC. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GVariant support for Unix fds (Was Re: GDBus/GVariant plans for next GLib release)
On Thu, 2009-10-15 at 14:02 -0400, Ryan Lortie wrote: > On Thu, 2009-10-15 at 12:38 -0400, David Zeuthen wrote: > > Yeah, I think we need to support this from the get-go. > > > > Anyway, at the end of the day, UNIX fds are just integers so if you > > require that users (such as GDBus itself and apps using GDBus) keep the > > fds alive until the method/signal has been sent/received you should be > > able to treat them as such. Anyway, it's probably more complicated than > > this. > > I talked to Lennart on IRC and the 'h' type, as serialised, isn't a file > descriptor so much as it is an index into a table of file descriptors > that are stored separately (in a separate part of the DBusMessage). The fd-over-dbus is just the result of dup2(), right? Well actually either F_DUPFD or F_DUPFD_CLOEXEC if I read Lennart's patches correctly. What is the problem with using integer for that 'h' type? Well, other than the fact that when you'd serialize the GVariant onto disk, and deserialize it, then wouldn't the integer have any meaning anymore. of course. I guess that's inherent to this "fd over DBus" technique. > Keeping this in mind, we could support this by doing the same thing with > GDBus -- support 'file descriptor array offset' as a special type of > integer in GVariant (much like 'o'bject path is a special type of > string) and have a GDBus call for send_with_file_descriptors() or such. Yah - something like that. [cut] -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
On Wed, 2009-09-30 at 16:05 +0200, Mark wrote: > On Wed, Sep 30, 2009 at 3:27 PM, Philip Van Hoof wrote: > sounds interesting. > A few questions for that lib: > - Where can it be downloaded (i only found the documentation of it) The websites Alexander pointed to in his reply have pointers to source code. I don't think it has an upstream repository anymore, just source packages of distributions. > - Can it be used on it's own without a need of including other > dependencies other then libjpeg? Yes > - Are there any benchmarks existing? preferably compared to GdkPixbuff Problem with the benchmarks that I used is that they are proprietary. But you get most difference with large JPEG images. So take any large JPEG image and test it. The code to write an EPeg based thumbnailer is about 12 lines. The hildon-thumbnailer code got a bit messy and we have started redoing this together with the XFCE people as the Tumbler project, but you can find Fremantle's EPeg based thumbnailer plugin here: http://gitorious.org/maemo-af/hildon-thumbnail/blobs/master/daemon/plugins/epeg-plugin.c > and beating it by 5 times is unlikely. My threaded test took ~30 > seconds that would mean with epeg it can take just 6 seconds.. i just > doubt that's possible for my 1927 image test. Nod, that's the kind of differences that we measured ;) Which is also why we didn't hesitate to just switch to using it. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
On Fri, 2009-08-28 at 22:11 +0200, Mark wrote: > > Now for the results: > > Glib > -- > 1927 images thumbnailed in 2.29 minutes. That is roughly 0.07 seconds > per thumbnail > > GraphicsMagick > -- > 1927 images thumbnailed in 3.08 minutes. That is roughly 0.09 seconds > per thumbnail > > FreeImage > -- > 1927 images thumbnailed in 5.45 minutes. That is roughly 0.17 seconds > per thumbnail You want to override GdkPixbuf's support for Jpeg and thumbnail all JPEG images using EPeg. It'll beat GdkPixbuf by 5 times or something. That's because afaik does EPeg use libjpeg in a way that it skips rows and columns, and that way performs better on both I/O (having to read less of the original), memory (same reason) and CPU (having to decompress less, having to scale less or nothing). We are already using EPeg for this on the Maemo Fremantle platform, by the way. Scaling truly large JPEG images goes magically fast with it. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gobject-performance
On Wed, 2009-09-30 at 15:06 +0200, Alexander Larsson wrote: [CUT] > On Thu, 2009-09-24 at 15:37 +0200, Benjamin Otte wrote: > What about introducing some sort of ack rules. If you can get, say, > three detailed reviews with acks from well known developers (core > people, maintainers, etc) then we can commit stuff during to the > unstable branch. I'm not petitioning to become such a reviewer, as I don't think I'd be a very good one. But I like this idea very much. I propose to ask Jürg Billeter to help review gobject patches. With his work on Vala Jürg seems to have an in-depth knowledge of gobject. > Opinions? Thanks a lot for trying to get things moving here, Alex. Appreciated. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: tree model
Here's a GLib with a collection API http://git.codethink.co.uk/?p=glib;a=shortlog;h=collections On Mon, 2009-05-11 at 13:27 -0400, Jamie McCracken wrote: > I would hope iterators and models will be part of glib 3.0 to avoid 3rd > party duplication as well as all other Libgee functionality > > this would also make it more vala friendly > > jamie > > On Mon, 2009-05-11 at 19:16 +0200, Szilárd Pfeiffer wrote: > > What do you want to do with that? What about GNode? Isn't it good for you? > > > > > > regards, > > > > Szilárd > > > > > > Ryan Lortie wrote: > > > > > are there any 3ish plans for GtkTreeModel -> GTreeModel? > > > > > > cheers > > > ___ > > > 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 > > ___ > 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: Review of gnio, round 1
On Mon, 2009-04-27 at 22:16 +0200, Alexander Larsson wrote: > On Mon, 2009-04-27 at 11:39 -0400, Ryan Lortie wrote: > > Going forward from this point, you argue that there should be a massive > > reduction in the number of classes. I think that your decision-making > > here is influenced by the fact that we're working in C. I tried to > > think out a logical class structure that I would do as if I had a > > language like Vala to do the dirty work for me -- that is, I favoured > > subclassing where it makes sense for conceptual clarity rather than in > > order to avoid an explosion of classes. > > That is not quite correct. I don't mind having classes if it e.g. means > more typing for the implementation. In fact, this is pretty obvious if > you look at gio itself which is pretty well factored wrt classes and > interfaces. However, what I think is bad about the many classes is that > they increase the complexity (or at least the percieved complexity) of > the API. There is a lot more classes to understand when e.g. reading the > docs, and its a lot harder to keep the class hierarchies and > dependencies in your head. This is especially bad when many classes > don't add any advantages to the user. > > Its also a problem because it means its a pain in the ass to extend the > API. For instance, with the minor change i'm about to do in the socket > construction case we will already support SCTP sockets. However, we need > a full suite of useless subclasses in order for it to match the tcp > case. When in a design you use classes a lot you try to single out functionality into classes; you delegate solving the problems. The aim being that the API of the one delegating becomes sealed once all tests, unit and API-usability, for its own function(s) succeed. When developing this way changing behaviour means developing a new class, or subclassing another. It rarely means adapting an existing sealed class. And if you do, the requirement is that all its test must again succeed. Again both the unit tests and the API-usability tests. So when you say: > its a pain in the ass to extend the API. ... then that frightens me: Extending the API should mean making a new class. Rarely should it mean adapting an existing sealed one. It's supposed to be a pain in the ass to extend API by reopening sealed stuff. You're supposed to extend by adding components on top. You're supposed to design in such a way that this becomes possible (delegation and composition over inheritance). In my opinion, especially in the GNOME platform, should the majority of classes have been slit out into many smaller ones. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for the next cycle
On Wed, 2009-02-11 at 01:07 -0500, Matthias Clasen wrote: > - What do we do about collections ? EggDbus adds typesafe GObject > wrappers around GHashTable and GArray. Other people have grandiose plans > to force java/.net style collection interfaces into GObject. You are using the phrase "To force". Is this an indication that you personally don't like such collection APIs? If so, can you explain why? > My proposal: Dodge the issue by just adding the minimal necessities > to GObject: a type for GArray (GHashTable already has one), and an api > to associate element type information to arrays and hash tables. Applications may have different requirements for a collection API: o. Separate interface from implementation o. The current GLib datatypes are hard to use - no reference counting - no type information (GType and memory management) Although your proposal addresses the latter and makes sense for EggDBus's requirements, I don't see how it addresses the former. We have started a git branch that implements the proposal in gobject/. http://git.codethink.co.uk/?p=glib;a=shortlog;h=collections We are open to comments and proposals from the community. We plan to implement use-cases, like a GTreeModel, on top of this, at some point. Next to model-viewing widgets we have many other use-cases with which we will be experimenting in this git repo. Why is it an advantage to separate implementation from interface? First, why do we want one interface instead of many: - If you provide an API where you use a collection, it's important that when you change the implementation (of the collection), that your API doesn't have to change with it. This is a similar issue to Gtk+ exposing a lot implementation details in its API. - Bindings. Collection are usually bound in a special way to integrate with a higher language. - Consistency of the API. This makes it easier for app developers. Here's a list of examples with existing collection-like-apis: GVariant, GHashTable, G(S)List, GPtrArray, GArray, ... If we add a few (significant) libraries to the list, we get: Gtk+ : GtkTreeModel Clutter : ClutterModelIter Gee (Vala): GeeIterator, GeeIterable GStreamer : GstIterator Camel : CamelIterator EDS : EIterator Tinymail : TnyIterator, TnyIterable LibAnjuta : IAnjutaIterable This is the proposal, by the way: http://live.gnome.org/IteratorsAPI > When I sat down with David and tried to figure out what the minimal > necessities actually are, we came up with the following: > GLib GObject > > g_ptr_array_ref/unref > g_ptr_array_set_data > g_ptr_array_set_element_free_func >G_TYPE_PTR_ARRAY >g_ptr_array_set/get_element_type > > g_array_ref/unref > g_array_set_data > g_array_get_element_size >G_TYPE_ARRAY >g_array_set/get_element_type >g_array_new_with_type > >g_hash_table_set/get_key_type >g_hash_table_set/get_value_type > g_hash_table_new_with_types Greetings, Jürg and Philip (at a codecamp) -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Call for talks - GNOME Devroom at FOSDEM 2009
I was asked by some of the other Tracker developers to do a talk about Tracker. Not sure about the format yet, but feel free to keep a slot open if you still have one, for Tracker :) On Tue, 2009-01-06 at 22:20 +0100, Christophe Fergeau wrote: > Hello :) > > 2008/12/30 Christophe Fergeau : > > As for the last few years, we'll have a GNOME devroom at FOSDEM (7/8 > > feb in Brussels), and as always, we want *YOU* to give a talk about > > the cool project you are hacking on in this devroom > > > [...] > > Please send your talk proposals before Friday 9 January. As always, > > the sooner is the better wrt organisation. > > This is a reminder that the deadline is in just a few days, FOSDEM is > 3 weeks earlier than usual this year which is why the deadline is so > close. > > So if you want to give a talk in the gnome devroom or the freedesktop > devroom (on sunday), please get in touch with me as quickly as > possible. Otherwise, your talk won't appear on the printed schedule > and people might not be aware of it :-/ > > Thanks a lot, hope to see you there :) > > Christophe > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
FWD: Specifying thumbnailers as a service
I started a discussion on a specification for thumbnailers here: http://lists.freedesktop.org/archives/xdg/2008-August/009834.html -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Translucent Scrollbars
On Tue, 2008-08-19 at 18:53 +0300, Kalle Vahlman wrote: > 2008/8/19 Christian Dywan <[EMAIL PROTECTED]>: > > > Before even starting to think of all the layout-related technical > details, one should stop to think if one really wants interesting > content to be underneath mouse-usable scrollbars (ie. unreachable) and > why... You want it for small screens. That's yet another 20 or more pixels that you don't waste. For example Maemo has ultra thick scrollbars for people who use their full of mayonaise hanging greasy fingers, while eating French Fries in a good Belgian Frituur, instead of the Apple-ish stylish stylus. Some even use ketchup! Or even cheese??!! Strange Canadians and UK people. I do it all the times (tapping with my dirty greasy fingers). My devices look horrible and dirty. Indeed. And I plan to continue doing it too. (for hygienic reasons, I often clean my device, of course). I can't hold both food AND stylus pens in my hands. I could try tapping my Nokia devices's touchscreens with a fries ... though (hmm, that's a good idea). But that's why the scrollbar is thick, and as a result my working area feels smaller. And why a translucent scrollbar would be useful. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal for a collection API in glib
So, Do we have a conclusion on this proposal? On Thu, 2008-07-17 at 17:51 +0200, Philip Van Hoof wrote: > Hi there, > > I would like to propose this API to go into glib/gio: > > http://live.gnome.org/IteratorsAPI > > A working implementation of it can be found here (just replace Gee.List > with GLib.Seq, as that is the name that we have for it in mind): > > http://svn.gnome.org/viewvc/libgee/trunk/gee/ > > To see users of this API, take a look at for example the Vala project. > On the IteratorsAPI wiki page, at the bottom, there are also a lot of > examples of projects that are right now inventing their own collections. > > We are working on adding convenience functions for C to make things as > type safe as possible (the #1 problem with glib's current collection > types): > > gchar* g_iterator_get_as_string (GIterator *iter); > gdouble g_iterator_get_as_double (GIterator *iter); > > A normal use-case would be a GObject in a sequence, which would with the > caller-owns API 'g_iterator_get' mean that you need to unref what you > get. We are thinking about making it possible to pass a 'free-function' > to the owner of the items (the collection), and to allow annotating how > to free what you get from 'g_iterator_get' (as it's caller owns). > > Right now, with the usage of GHashTable, GPtrArray and GList, language > binding developers loose all meaningful type information. > > This means that they have to resort to using manually written glue code. > This is among the reasons that makes fully automated language binding > generation a nearly impossible task at this moment. > > In my opinion it's one of the reasons why we never really achieved > topnotch compelling language bindings, even though that was the #1 > promise of Gtk+ back when it all started. > > It's of course debatable whether or not they topnotch. They are not for > me and having a collection API that actually does make sense outside of > the C world would in my opinion be one more step in the direct direction > of improving this situation. > > This of course doesn't "magically" fix existing Cism APIs. But take a > look at the wiki page mentioned above for example on how this can easily > be improved. > > > Thanks, and please don't troll about how great doubly linked lists are. > > It's not the point. > > -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal for a collection API in glib
On Fri, 2008-07-18 at 14:33 +0100, Gustavo J. A. M. Carneiro wrote: > On Thu, 2008-07-17 at 14:23 -0400, Havoc Pennington wrote: > At leas Philip's iterators would shift some of the burden of making APIs > bindings friendly into the library authors themselves, and contribute > for language bindings to stop being second class citizens, as they are > now. This is indeed to the point. So I'm in agreement with Gustavo. It *IS* the "C" developer's responsibility to deal with boxing and unboxing of his arbitrary memory. Container types that are implemented as a C implementation detail are also arbitrary memory, just like any other structure that gets allocated on the heap. A collection API is a generic way to box C specific collections in such a way that on top of the boxing, the consumer of it gets a clean API to use them. That API is 1-1 with what you are seeing in the more popular higher programming of today (System.Collections for example in .NET). Meaning that binding to those languages will be a lot more simple (as illustrated on the wiki page http://live.gnome.org/IteratorsAPI at the bottom of the page - for C# -). With such an API we could also solve the boxing and unboxing of the elements that are owned by the collection (the things in the sequence). This way a majority of typing that the language binding developer needs is solved and/or available for automated code generation. Anything else on top of that that is needed can be provided by a library/tool like GObject introspection. At the same time could GObject introspection serve as a library for generating collections and iterators that box (that wrap) a known C container type (like a GList, GPtrArray, GSList, GHashTable) at runtime. But before you can do that, you need an API. One that also makes sense for people who don't care about C (at all). Like how GIO's Stream API makes sense, and how we needed that before we could start with bridging application's 'stream inventions'. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal for a collection API in glib
On Thu, 2008-07-17 at 14:22 -0400, Jamie McCracken wrote: > On Thu, 2008-07-17 at 13:37 -0400, Havoc Pennington wrote: > As philip's proposal centres around easier bindings this would only > affect public API dealing with licts/collections so all of the above > will probably have negligible impact. Exactly (I agree). > GList would still be around for internal usage or where performance > matters. The onus would still be on devs to make their api more binding > friendly by using iterators so I feel its important for them to have > that choice GList for performance?! :-) Not for the things the vast majority of GLib based library developers are using it for! And if GList must be used in a high performance situation, the kernel's list.h is better designed anyway: the item's data is in the same allocation as the next/prev ptrs, instead of having an allocation for the data and another allocation for the list node. Looking at how GList is used all over our project's code nearly always makes me conclude that most people who used a GList probably wanted a GPtrArray instead. Its realloc overhead is usually not expensive at all. There are specific uses for doubly linked lists, of course. For UI rich applications (where you usually want things like sorting and index based accessing your collections) I don't think GList is very useful. For index-based access and sorting it's even a performance 'mistake'. The problem is, I think, that GList's API is more easy than GPTrArray's. Which validates my POV that: - The simple, most common use cases, must be easy - The complex things must (just) be possible If a complex thing becomes even more complex caused by wanting to make a common use case even a little bit more simple, then don't even think about it and DO make the complex thing even more complex .. indeed. Just make a wiki page on Live explaining how to do the complex thing. The developers who feel brave (and have some competence) will figure it out anyway. But don't bother app developers, who spend 90% of their time codifying common use cases, with complexities. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal for a collection API in glib
On Thu, 2008-07-17 at 20:06 +0200, Philip Van Hoof wrote: > Vala is an excellent example of how community people who are true black > art masters and experts in GLib/GObject can provide excellent language > bindings. I meant "who are not true black art masters and ..." of course. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal for a collection API in glib
callee-owns setup. I still
think that for iterators caller-owns is the right way, though.
Looking at the samples on that wiki page, I don't think that having to
destroy the iterator is onerous. Just good programming.
> * the need to subclass a GObject is onerous for C programmers creating
> iterators
It's implementing an interface instead of subclassing a GObject. With
programming languages like Vala this is easy.
And yes, I think projects like Vala, gtk-sharp (Mono), pygtk, gtkmm, etc
are the future for application developers. Not C/Glib in .c files.
Those of us who still develop in C/GLib have the GObject macros:
static void
my_iterator_g_iterator_iface_init (MyIteratorface *iface)
{
iface->next = ...
...
}
G_DEFINE_TYPE_WITH_CODE (MyIterator,
my_iterator,
G_TYPE_OBJECT,
G_IMPLEMENT_INTERFACE (G_TYPE_ITERATOR,
my_iterator_g_iterator_iface_init))
http://live.gnome.org/Vala/MultiImplementInC
> * as Owen mentioned long ago when this was already discussed, we'd end
> up duplicating bunches of APIs just to make them use iterators instead
> of whatever they use now - this is both bloat and confusing. It would
> not be realistic to ever deprecate walking GList etc. - the iterator
> replacement is much less convenient, and there's way, way, way too
> much code using GList already. You can't deprecate something that
> touches this much code.
I didn't mention deprecating this code ...
Philip
--
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://pvanhoof.be/blog
http://codeminded.be
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal for a collection API in glib
On Thu, 2008-07-17 at 12:46 -0400, Yu Feng wrote: > > > > We are working on adding convenience functions for C to make things as > > type safe as possible (the #1 problem with glib's current collection > > types): > > > > gchar* g_iterator_get_as_string (GIterator *iter); > > gdouble g_iterator_get_as_double (GIterator *iter); > > > > It looks like a GValue. Can it be simplified by using GValue? GValue and other GBoxed solutions where measured by Jürg (Vala project) for performance. His analysis showed that boxing using GBoxed and/or GValue would be a lot slower (too slow). We would want the collection API to perform as fast as possible, or at least make it possible to have a high performing collection implementation: - Make it EASY (really easy) to make a normal performing one - Make it possible to make a high performance one > I think the problem is that lacking of reference management, GList is > not intended to be used in a language binding; whereas in the reality a > lot of GTK APIs take and return GList, forcing the binding programmers > to write glue code. Exactly. With this collection API, you'd have a very automatable and well known way to do reference management for the items that are owned by the collection. It's not the only reason, the other reason is that everybody seems to be reinventing iterator based APIs: In GLib + Gtk+ you already have three incompatible iterator APIs (or there will be three as soon as GVariant is going to be used by people); - GFileEnumerator - GVariant's iterators - GtkTreeModel If you add to that other projects, we get this interesting list: * Camel (CamelIterator) * libanjuta (IAnjutaIterable) * libedataserver (EIterator) * libgda (GdaDataModelIter) * libvala (using libgee) * Tinymail (TnyList and TnyIterator) * GVariant (g_variant_iter*, etc) * GIO (gfileenumerator.h) * Gtk+ (GtkTreeModel is an iterable) * Clutter and Tidy with ClutterModelIter * GStreamer with GstIterator Clearly, whoever decided that a collections API is not necessary (because GList, GSList, GHashTable and GPtrArray work just fine in C), must have made a significant error in his or her judgements. My conclusion (as usual, it's a harsh one) I think it's proven from not only the Java, C, C++ and C# world that a collections API is important, our own GLib based projects have and GLib itself has started inventing ad-hoc solutions around the lack of a generic collection API in glib. I'm not convinced that GList, GSList, GHashTable and GPtrArray are good components for making a sustainable and future proof API. Not convinced at all. Thanks for your reaction, Yu Feng. Philip -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Proposal for a collection API in glib
Hi there, I would like to propose this API to go into glib/gio: http://live.gnome.org/IteratorsAPI A working implementation of it can be found here (just replace Gee.List with GLib.Seq, as that is the name that we have for it in mind): http://svn.gnome.org/viewvc/libgee/trunk/gee/ To see users of this API, take a look at for example the Vala project. On the IteratorsAPI wiki page, at the bottom, there are also a lot of examples of projects that are right now inventing their own collections. We are working on adding convenience functions for C to make things as type safe as possible (the #1 problem with glib's current collection types): gchar* g_iterator_get_as_string (GIterator *iter); gdouble g_iterator_get_as_double (GIterator *iter); A normal use-case would be a GObject in a sequence, which would with the caller-owns API 'g_iterator_get' mean that you need to unref what you get. We are thinking about making it possible to pass a 'free-function' to the owner of the items (the collection), and to allow annotating how to free what you get from 'g_iterator_get' (as it's caller owns). Right now, with the usage of GHashTable, GPtrArray and GList, language binding developers loose all meaningful type information. This means that they have to resort to using manually written glue code. This is among the reasons that makes fully automated language binding generation a nearly impossible task at this moment. In my opinion it's one of the reasons why we never really achieved topnotch compelling language bindings, even though that was the #1 promise of Gtk+ back when it all started. It's of course debatable whether or not they topnotch. They are not for me and having a collection API that actually does make sense outside of the C world would in my opinion be one more step in the direct direction of improving this situation. This of course doesn't "magically" fix existing Cism APIs. But take a look at the wiki page mentioned above for example on how this can easily be improved. Thanks, and please don't troll about how great doubly linked lists are. It's not the point. -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Steps to get to GTK+ 3.0
On Thu, 2008-06-05 at 08:59 +0200, Jean-Yves Lefort wrote:
> On Thu, 05 Jun 2008 00:37:00 -0400
> Behdad Esfahbod <[EMAIL PROTECTED]> wrote:
>
> >
> Likewise, you can implement a class "Foo" containing an int property
> "bar" using the GObject way:
>
[CUT]
>
> or using the Qt way:
>
> class QFoo : public QObject
> {
> Q_OBJECT
>
> Q_PROPERTY(int bar READ bar WRITE setBar)
>
> public:
> void setBar (int value);
> int bar () const;
> };
>
> void QFoo::setBar (int value)
> {
> // ...
> }
>
> int QFoo::bar ()
> {
> // ...
> }
>
> Which way do you prefer?
The Vala way:
public class VFoo : GLib.Object {
public int Bar { get; set; }
}
Now thank you for your whining and let's get productive indeed.
--
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://pvanhoof.be/blog
http://codeminded.be
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 'reloading' gtktreeview when model changes drastically
On Sun, 2007-08-05 at 04:24 +0200, Milosz Derezynski wrote:
> Just FWIW, can we agree on one meaning of "transactional"?
> For me, the fact that the model shouldn't have to know about the
> number of views showing it has nothing to do with transactionality:
>
> > there may be multiple views on the model, and when changing the
> model, one
> > should not be required to know about the number of views. excellent
> > point, end of story for me. it ought to be "transactional".
>
> I think the most sensible meaning is the one we e.g. know from SQL and
> which Kris mentioned: One atomic changeset which can be "committed" to
> the model in one run. (It can probably not be rolled back, or if it
> would be possible, then it'd be quite expensive, but that's not really
> the point anyway).
For me, what is important is that MVC is that what it is supposed to be:
-> View observes Model
And not:
-> Some extra code done by the application developer observes for
the View the Model, because the View can't cope with the actual
MVC paradigm.
The simplicity of MVC is also what makes it so useful. By assuming that
the application developer will "solve" all the problems that the normal
"View observes Model" solves (he has to reset the model, he has to reset
the view's state, he has to detect changes to the model, ...) you void
the simplicity.
If the view internally actually resets its model, then that's fine.
It's a complexity that got solved by the View and didn't have to be
solved by the application developer. If it's more easy for Kris to
internally swap the Model (reloading everything and recovering the
state, like sorting --in case of a sortable -- or selection details),
then that's fine from the application developer's point of view.
> As for the model-should-be-view-ignorant issues, they have nothing to
> do with transactions, but are just as valid concerns of course.
>
>
> On 8/5/07, Paul Davis <[EMAIL PROTECTED]> wrote:
> On Sun, 2007-08-05 at 00:25 +0200, Philip Van Hoof wrote:
> > On Sat, 2007-08-04 at 16:51 -0400, Paul Davis wrote:
> > > On Sat, 2007-08-04 at 17:00 +0200, Philip Van Hoof wrote:
> > >
> > > > The model itself is the source. The view is just a
> viewer for it. The
> > > > source itself doesn't change. The content of the source
> changes. The
> > > > view, being an observer of the model in the MVC
> paradigm, should adapt
> > > > to the changes. It should not require a sudden set and
> unset of its
> > > > model.
> > >
> > > I'm a big user of MVC. Although on some level I agree with
> you, I would
> > > ask what the difference is between:
> > >
> > > void gtk_treeview_freeze (GtkTreeView* tv) {
> > > /* store model in tv, then unset */
> > > }
> > > void gtk_treeview_thaw (GtkTreeView* tv) {
> > > /* reset model in tv */
> > > }
> >
> > Owk .. it's a bit lengthy and there are a lot of "personal
> opinions
> > about MVC" embedded in this one:
>
> it didn't need to be so lengthy :) thats why i noted that i
> use MVC a
> *lot* myself. the key point you raise is one that i had
> forgotten: there
> may be multiple views on the model, and when changing the
> model, one
> should not be required to know about the number of views.
> excellent
> point, end of story for me. it ought to be "transactional".
>
> --p
>
>
>
> ___
> gtk-list mailing list
> [EMAIL PROTECTED]
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 'reloading' gtktreeview when model changes drastically
On Sat, 2007-08-04 at 16:51 -0400, Paul Davis wrote:
> On Sat, 2007-08-04 at 17:00 +0200, Philip Van Hoof wrote:
>
> > The model itself is the source. The view is just a viewer for it. The
> > source itself doesn't change. The content of the source changes. The
> > view, being an observer of the model in the MVC paradigm, should adapt
> > to the changes. It should not require a sudden set and unset of its
> > model.
>
> I'm a big user of MVC. Although on some level I agree with you, I would
> ask what the difference is between:
>
> void gtk_treeview_freeze (GtkTreeView* tv) {
> /* store model in tv, then unset */
> }
> void gtk_treeview_thaw (GtkTreeView* tv) {
> /* reset model in tv */
> }
Owk .. it's a bit lengthy and there are a lot of "personal opinions
about MVC" embedded in this one:
Well I'm in favour of having a strict separation between code that views
data (the view), and code that represents the data (the model).
If you require that "using the model" is to be adapted or adjusted to
certain limitations, you are requiring that the model's code becomes
specific for the view. Let me explain:
Let's take the example with a person and a view for a person:
Person p = new Person ();
PersonView v1 = new PersonView ();
v1.Model = p;
I have another PersonView open on (another) screen (whether it's another
computer or another process or another whatever is irrelevant for now):
PersonView v2 = new PersonView ();
v2.Model = p;
Imagine I'm working at the p's town administration and I change person
p's name. Let's say we did this in v1.
We'll assume a simple system where each person has one instance in this
global system or where each system gets notified by triggers on the
remote database (quite Utopical, I know. But it's irrelevant. You can
also imagine one computer, one application with two PersonView instances
being visible at the same time, showing the same model -- the same
person instance, as we got the instance from a factory and the instance
is, indeed, the exact same instance --).
In v1's instance (image on_name_textbox_changed indeed happens) :
public class PersonView
{
public Person Model;
private void on_name_textbox_changed (TextBox o, ...) {
this.Model.Name = o.Text;
}
}
Note that maybe some people want to do this with a separate Controller
type, in which case we're in the exact same situation.
Now if we'd require that you always now refresh v1 and v2's model before
either v1 OR v2 (not "AND", because v1 can indeed update itself in the
on_name_textbox_changed method, but since PersonView should rather
observer its Model, we usually don't do this --but it can, I know--) ...
... how will v2 get itself updated in time?
It can't, because the view requires getting updated by having it set its
model each time it needs an update.
Now this is a simple example. Whether model is a list of rows, a tree of
things, a bear, a person, a traffic light (which is a typical example),
a remote control for a television ...
Whether the model is a list of 800,000 E-mails. Whether its 300,000 song
titles, ...
Doesn't matter for the MVC theory. You can always have a v1 and a v2
showing the same model instance.
When v1 causes a change to its model, and v2 shares the same instance as
model with v1, v2 should update itself instantly. Because both v1 and v2
observe the model.
Now the "update" (which gets called by the notify of the observable
model) of PersonView can of course do this internally (resetting its
model, resetting its state, doing this or doing that). That's just an
implementation detail.
In case of GtkTreeView this would mean that GtkTreeView would have to
implement this implementation detail. Not the application developer.
In GtkTreeView's case, if the changes are big .. its right now only
practical (else the performance is very weak, yadi yada) if you unset
the model and reset the model. But that's broken as illustrated in the
example above.
> and just calling gtk_treeview_set_model (NULL) and
> gtk_treeview_set_model (NOTNULL).
>
> there are additional issues: freeze/thaw semantics require use of a
> counter, so that, for example, if 3 nested contexts call "freeze", only
> the 3rd subsequent call to "thaw" actually unfreezes. contrast this to
> the simplicity of code in which only the top level sets+unsets the
> model, and all lower levels act on the model regardless of whether its
> connected to a view or not.
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 'reloading' gtktreeview when model changes drastically
On Sun, 2007-06-24 at 15:19 +0200, Kristian Rietveld wrote: > I think a much better solution would be to be able to group a bunch of > changes together in a kind of "atomic changeset" which is then emitted > with a single signal. I agree with this and am in need of this kind of things too. I'll give some real world examples of how GtkTreeView and GtkTreeModel are being used today already: In Tinymail while headers are being downloaded I need to "prepend" those to a GtkTreeModel (during download, not while all are downloaded as that is not what people nowadays want from an E-mail client: they want to start using things 'as they get received'). Same for notify events (Push E-mail if you prefer the buzzword name): these are events that "happen" and "can happen in any thread or anywhere"). Such an even, for example in case the user used another E-mail client to move 80,000 E-mails, will cause 80,000 row insertions to happen. Although this number sounds "large", in fact .. it's small. Some people have over 300,000 items in their E-mail folders (talk to one of those Ubuntu bugzilla maintainers, who made a IMAP folder for each Ubuntu product on his IMAP server: he has thousands of folders and some folders have ten or hundred thousands of items in it. And this ain't "rare", really). Note that this is the guy being responsible for Ubuntu Mobile, and would like to use this as test on his Mobile device (imo this should be perfectly possible on a device that has 50MB of RAM). Or look at Rhythmbox or Banshee: some people have over half a million songs. A customer once asked me to make an analysis to port a software jukebox on Windows to GNOME. With the software it was a possible use-case or "event to support" to "suddenly" receive 300,000 new songs and have 700,000 old songs removed. The people in the bar, the listeners, don't want the software to stop playing. The guy at the bar does not want the software to change the sorting order or settings when this remotely invoked event happens. I know I'm using a lot of words. I'm just really trying to make it clear that unsetting the model and setting a new model is not a practical method and that it's wrong from a Model View Controller perspective: The model itself is the source. The view is just a viewer for it. The source itself doesn't change. The content of the source changes. The view, being an observer of the model in the MVC paradigm, should adapt to the changes. It should not require a sudden set and unset of its model. Finally, Kris, if you need any assistance with this: you know where to find me and you know that I'm interested in helping with this if necessary. > All connected views/models could then process the > full changeset in one pass. (Possibly this could also add/remove ranges > of nodes, etc). Thanks for your hard work on GtkTreeView and Model! Make it rock! -- Philip Van Hoof, software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://www.pvanhoof.be/blog ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Plans for gnome-vfs replacement
On Sun, 2006-09-24 at 14:51 +0200, Philip Van Hoof wrote:
> #define G_INPUT_STREAM_GET_IFACE(inst) (G_TYPE_INSTANCE_GET_INTERFACE
> ((inst), G_TYPE_INPUT_STREAM, TnyDeviceIface))
Search and replace issue. This should of course be something like:
#define G_INPUT_STREAM_GET_IFACE(inst) (G_TYPE_INSTANCE_GET_INTERFACE
((inst), G_TYPE_INPUT_STREAM, GInputStreamIface))
> #define G_SEEKABLE_GET_IFACE(inst) (G_TYPE_INSTANCE_GET_INTERFACE ((inst),
> G_TYPE_SEEKABLE, TnyDeviceIface))
And this one GSeekableIface
Also note that I would definitely start with a base GStreamIface,
continue with a GInputStreamIface and a GOutputStreamIface where the
input and output have as prerequisite the GStreamIface.
Or in .NET (and Java) that would mean:
namespace G {
interface IStreamIface { .. }
interface IOutputStream : G.IStreamIface { .. }
interface IInputStream : G.IStreamIface { .. }
interface ISeekable : G.IStreamIface { .. }
/* OR: interface ISeekable { .. }; */
}
In Java I think you can only extend an interface with one interface.
In .NET I know you can extend an interface with as much other interfaces
as you want.
Extending an interface is more or less the exact same thing as copy
pasting all the to-implement methods and properties (properties
translate to both a get and a set method in Java, depends on whether or
not it's a read-only property etc etc) in the final interface.
And now you would create a SomeStreamType like this:
public class SomeStreamType : G.IOutputStream, G.IInputStream, G.ISeekable
{
}
ps. To the Java warriors on this list: forgive me for my .NET style
syntax. I know you guys know it's all the same (Java and .NET) with just
a little bit different syntax sugar.
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Plans for gnome-vfs replacement
On Sun, 2006-09-24 at 14:33 +0200, Philip Van Hoof wrote:
> > Here is my current GInputStream:
> >
> > struct _GInputStreamClass
> > {
> > GObjectClass parent_class;
>
> Using GTypeInterfaceClass here would make it much more easy to let
> library and application developers implement the GInputStream interface
> in a for-their needs suitable way.
Also look at these prior art thingies:
http://tinymail.org/API/libtinymail-1.0/libtinymail-tny-stream.html
http://pvanhoof.be/files/libcamel-api/html/CamelStream.html
http://pvanhoof.be/files/libcamel-api/html/CamelSeekableStream.html
I know this API proposal MIGHT sound more complex. In reality, it most
certainly isn't. Just try it out. Fiddle around with it. Or see how I in
tinymail (and notzed and fejj in Camel) used something like this.
#ifndef _G_INPUT_STREAM_H
#define _G_INPUT_STREAM_H
#include
#include
G_BEGIN_DECLS
typedef struct _GInputStream GInputStream;
typedef struct _GInputStreamIface GInputStreamIface;
#define G_TYPE_INPUT_STREAM (g_input_stream_get_type ())
#define G_INPUT_STREAM(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj),
G_TYPE_INPUT_STREAM, GInputStream))
#define G_IS_INPUT_STREAM(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj),
G_TYPE_INPUT_STREAM))
#define G_INPUT_STREAM_GET_IFACE(inst) (G_TYPE_INSTANCE_GET_INTERFACE ((inst),
G_TYPE_INPUT_STREAM, TnyDeviceIface))
struct _GInputStreamIface
{
GTypeInterface parent_iface;
/* Sync ops: */
gssize (* read)(GInputStream *stream,
void *buffer,
gsize count,
GError **error);
gssize (* skip)(GInputStream *stream,
gsize count,
GError **error);
gboolean (* close) (GInputStream *stream,
GError **error);
/* Async ops: (optional in derived classes) */
guint(* read_async) (GInputStream *stream,
void *buffer,
gsize count,
int io_priority,
GMainContext *context,
GAsyncReadCallback callback,
gpointerdata,
GDestroyNotify notify);
guint(* close_async) (GInputStream *stream,
GMainContext *context,
GAsyncCloseCallback callback,
gpointerdata,
GDestroyNotify notify);
void (* cancel) (GInputStream *stream,
guint tag);
}
GType g_input_stream_get_type (void);
gssize g_input_stream_read (GInputStream *stream,
void *buffer,
gsize count,
GError **error);
gssize g_input_stream_skip (GInputStream *stream,
gsize count,
GError **error);
gboolean g_input_stream_close (GInputStream *stream,
GError **error);
guint g_input_stream_read_async (GInputStream *stream,
void *buffer,
gsize count,
int io_priority,
GMainContext *context,
GAsyncReadCallback callback,
gpointerdata,
GDestroyNotify notify);
guint g_input_stream_close_async (GInputStream *stream,
GMainContext *context,
GAsyncCloseCallback callback,
gpointerdata,
GDestroyNotify notify);
void g_input_stream_cancel (GInputStream *stream,
guint tag);
G_END_DECLS
#endif
#ifndef _G_SEEKABLE_H
#define _G_SEEKABLE_H
#include
#include
G_BEGIN_DECLS
typedef struct _GSeekable GSeekable;
typedef struct _GSeekableIface GSeekableIface;
#define G_TYPE_SEEKABLE (g_seekable_get_type ())
#define G_SEEKABLE(obj) (G_TYPE_CHECK_INSTANCE_CAST ((obj),
G_TYPE_SEEKABLE, GSeekable))
#define G_IS_SEEKABLE(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj),
G_TYPE_SEEKABLE))
#define G_SEEKABLE_GET_IFACE(inst) (G_TYPE_INSTANCE_GET_INTERFACE ((inst),
G_TYPE_SEEKABLE, TnyDeviceIface))
struct _GSeekableIface
{
GTypeInterface parent_iface;
off_t (*seek) (GSeekable *self, off_t offset, GSeekPolicy policy);
off_t (*tell) (GSeekable *stream);
}
GType g_seekable_get_type (void);
off_t g_seekable_seek (GSeekable
Re: Plans for gnome-vfs replacement
On Wed, 2006-09-20 at 12:31 +0200, Alexander Larsson wrote:
Hey Alex,
Great that you are planning to redesign the VFS.
> Here is my current GInputStream:
>
> struct _GInputStreamClass
> {
> GObjectClass parent_class;
Using GTypeInterfaceClass here would make it much more easy to let
library and application developers implement the GInputStream interface
in a for-their needs suitable way.
Because the gtype system has infrastructure that makes it more easy.
Using a GObject it would also be a lot more difficult to let such a type
implement multiple interfaces: the developer would have to inherit.
Unless in C++, you can't multi-inherit in most programming languages.
Language binding generators like gapi and pygtk's one know how to deal
with GTypeInterface. For example by putting define-virtual in the defs
file of a Python language binding generation helper-files, it would be
easy and possible to implement a GInputStream in Python.
In .NET it wouldn't (not at this moment) be possible to use the
GTypeInterface as a real "interface" as known in the .NET world. Nor
could a Java language binding do this (as this would require significant
adaptations to both the compiler and virtual machine of the
environment), but I know there's plans to ease creating language
bindings for situations like these. For example by creating an abstract
class where the developer has to implement the methods.
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: A GIterator type, but not as a simple type -> as a GTypeInterface (GIterIface)
ven more unpleasant for C programmers, but > yes, you'll solve this problem. My proposal is, indeed, GObject. Not C nor GLib. I'm more interested in making it more easy to use it in a higher language. If pure C developers burn and kill me, fine. A lot pure C developers already hate everything about glib for trying to reinvent everything. :-) > > > - Lack of robustness like a foreach() function; if iterators > > >contain pointers to internal data, they won't be > > >robust against structural changes. > > > > Oh? Can you give an example? > > Your iterator contains a pointer to a GList node. While your > iterator is kept around, the GList node is freed... Ah, right. But not all list-types aren't gobjects that can't do reference counting. I agree most are. So, good point :-) > > I'd say implement a library on top of GObject that makes it possible to > > start using a type like GIterIface. But not yet use it in gtk+. Perhaps > > refactoring the GtkTreeView so that letting it use a real iterator in > > stead of GtkTreeIter. I would in stead of putting a new > > GtkTreeModelIface in gtk+, put it in that library on top of GObject. For > > example with a name like GListModelIface and GTreeModelIface. > > I think we've just about got people over the GtkCList => GtkTreeView > hump now... not particularly looking forward to another switch. At the begin of my e-mail I wrote that gtk+ shouldn't be modified. I'm not advocating a new switch. One of the few problems I have with Gtk+ is that GtkTreeIter thingy. It could have been better. Other than that is gtk+ very usable for most high-level programming techniques already. Also note that the previous switch was also about learning people the MVC paradigm (and made gtk+ usable for these techniques). I can imagine this wasn't easy. It was a huge step. I don't think this means 'all' switches would be as huge. I also don't think any such changes should go into what we today call gtk+-2.0. This would be gtk+-3.0 or maybe gtk+-4.0, and gobject-x.y or not even gobject-x.y but a gobject-extra-1.0. In a few years, I think high-level programming environments will be even more important than today. Sure today we want to get gtk+ "just work". But what about tomorrow? s/gtk/xul/g ? -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
A GIterator type, but not as a simple type -> as a GTypeInterface (GIterIface)
elp the memory > management problem .. see above. > > GIterator doesn't solve the type information problem. > 4) Convenience. Maybe it is just easier to use GIterator > than the current APIs. I don't see this as the case ... > it's more function calls. It's not type safe. (Some > of the current calls aren't, some are.) You can't > make multiple passes through the data in an easy > fashion. Type safety can be implemented if you do the iterator type as an interface. > None of these is all that compelling to me. > > One other thing to note is that with iterators you have > to choose between > > - Lack of robustness like a foreach() function; if iterators >contain pointers to internal data, they won't be >robust against structural changes. Oh? Can you give an example? > - Lack of efficiency like returning an array. You can >make the iterator robust by just making it a wrapper >around an array. Efficiency is important for the core gtk+ libraries (internal gtk+ code). I don't think 90% of the desktop application developers are interested in such levels of efficiency. Anyway, you can let the implementer of a GIterIface for a specific type implement efficient foreach, next, previous and has_next methods and properties. The efficiency is now in the hands of the GIterIface implementer, it's no longer in the hands of the desktop application developer. This is in many cases going to lead to more efficient application code. > The fact that we can't achieve consistency is the killer objection > to me. Memory management does get better, language binding > support and convenience is a bit of a wash. But without > being able to use GIterator consitently everywhere, in the > end all we will be making it harder to learn how to use > GLib and GTK+, not easier. That way, you block 95% of all innovation, Owen ;-). I'd say implement a library on top of GObject that makes it possible to start using a type like GIterIface. But not yet use it in gtk+. Perhaps refactoring the GtkTreeView so that letting it use a real iterator in stead of GtkTreeIter. I would in stead of putting a new GtkTreeModelIface in gtk+, put it in that library on top of GObject. For example with a name like GListModelIface and GTreeModelIface. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[Fwd: A better way to use GtkTreeView: Proxy classes and lazy instantiation]
-- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be --- Begin Message --- >From the far far corners of the maemo development list, I bring you . . . A technique to use the GtkTreeView with a Proxy design pattern for the items in a list model. This technique (this pattern) gives you the possibility to use rich real subjects in enormous amounts in a Model View Controller paradigm like the GtkTreeView story on devices and or platforms with few memory resources. A sample implementation would, for example, have a memory expensive MsgHeader instantiation. The proxy's however, aren't expensive for the memory. Note that my wiki is indeed read-only, but .. if you ask for a login: I will ALWAYS give you one. I've done this to block spam bots. http://www.pvanhoof.be/wiki/index.php/Smart_ways_of_using_GtkTreeView The maemo wiki isn't read-only. On this page I try to explain how we could enhance the osso-email application by 'simply' redesigning it ;-) http://maemo.org/maemowiki/ImprovementIdeasForOssoEmail Suggestions and other techniques are welcome. It would be nice if other people would send me (to the wiki or by asking a login or e-mail) their design pattern implementations in a GObject style piece of code. If you did such stuff before: I'm highly interested in your work. Let's share it and put it on wiki's, webpages and documentation. For many application developers it's probably even more important than the many "performance" efforts on the libraries (being done these days by people like Federico -- thank you for that, by the way) to have a great documentation about techniques and implementing design patterns in GObject. I'm not saying the performance efforts aren't good or shouldn't be happening. I contrary. But also our application developer should be well educated not to use wrong techniques for less trivial designs. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be --- End Message --- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
