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 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 Tue, 2009-10-20 at 14:33 +0200, Mark wrote: On Tue, Oct 20, 2009 at 1:08 PM, Philip Van Hoof s...@pvanhoof.be 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 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 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
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: 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 s...@pvanhoof.be: 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
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: 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: 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 s...@pvanhoof.be 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: 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 cferg...@gmail.com: 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
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: 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: '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-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-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
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
___
gtk-devel-list mailing list
[EMAIL PROTECTED]
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-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-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: '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-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
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: 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 glib.h
#include glib-object.h
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 glib.h
#include glib-object.h
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 *self, off_t offset, GSeekPolicy
Re: Storing GObject in GtkListStore
On Wed, 2006-08-02 at 15:51 +0200, Tomasz Jankowski wrote:
Hi!
Hey Tomasz!
Generally it isn't a problem, I'm only nosy :P I'd like to know if there is
some other (more recommended) way to store, for example GObject in
GtkListStore/GtkTreeStore. So far I do it, by creating column with type
G_TYPE_INT and storing there pointer to object.
Use G_TYPE_OBJECT if you want it to work behind for example a language
binding.
Checkout tinymail for this.
https://svn.tinymail.org/svn/tinymail/trunk/libtinymail-test/tinymail-python-test.py
What you see here is a GObject (actually a GTypeInterface) of the type
TnyMsgHeaderIface and in this case an implementation called TnyMsgHeader
being put in the store model, which is of type TnyMsgHeaderListModel.
This list-model type implements GtkTreeModel and TnyListIface.
I assume you at some point want language bindings to work, else you
perhaps shouldn't develop GObject/C but rather pick a higher programming
language like C#, D or Python, Ruby, whatevery (but that's a personal
opinion, remove this last line .. hehe)
def on_headerstree_selected (treeselection, msgview) :
model, iter = treeselection.get_selected ()
if iter:
header = model.get_value (iter,
tinymail.uigtk.MSG_HEADER_LIST_MODEL_INSTANCE_COLUMN)
if header:
folder = header.get_folder ()
msg = folder.get_message (header)
msgview.set_msg (msg)
If you don't use G_TYPE_OBJECT, you would get a PyGTK error/warning here.
You can see the INSTANCE_COLUMN in tny-msg-header-list-model.c
https://svn.tinymail.org/svn/tinymail/trunk/libtinymailui-gtk/tny-msg-header-list-model.c
static GType
tny_msg_header_list_model_get_column_type (GtkTreeModel *self, gint column)
{
...
case TNY_MSG_HEADER_LIST_MODEL_INSTANCE_COLUMN:
retval = G_TYPE_OBJECT;
break;
...
}
It's a custom tree model. But you can also do this with a GtkListStore
implementation of GtkTreeModel.
In tinymail you can see such a GtkTreeModel at
https://svn.tinymail.org/svn/tinymail/trunk/libtinymailui-gtk/tny-attach-list-model.c
and
https://svn.tinymail.org/svn/tinymail/trunk/libtinymailui-gtk/tny-account-tree-model.c
For example look at this:
static void
tny_account_tree_model_instance_init (GTypeInstance *instance, gpointer g_class)
{
GtkTreeStore *store = (GtkTreeStore*) instance;
TnyAccountTreeModel *me = (TnyAccountTreeModel*) instance;
static GType types[] = { G_TYPE_STRING, G_TYPE_UINT, G_TYPE_INT,
G_TYPE_OBJECT };
me-iterator_lock = g_mutex_new ();
gtk_tree_store_set_column_types (store,
TNY_ACCOUNT_TREE_MODEL_N_COLUMNS, types);
return;
}
--
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-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Opening a GtkWindow from a Thread
On Wed, 2006-08-02 at 11:07 +0300, Tor Lillqvist wrote: [EMAIL PROTECTED] writes: I am desperatly trying to open a dialog box from a thread on Windows XP. Using GTK+ from multiple threads doesn't work on Windows, see bug #60620. (And doing that is usually considered bad design anyway, I think.) Do all your GTK+ calls from the main thread. Use g_idle_add() to schedule GUI that happens in the main thread from other threads. Does this mean that gdk_threads_enter and _leave doesn't work on Windows? Auwch ... -- 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-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Trouble adding a lot of rows
On Wed, 2006-08-02 at 05:49 +0100, raul o wrote: Hello: Well, I have a trouble when I add a lot of rows (+700)in a list. I know that the problem are in the sort function that I defined using set_sort_function. In GTK+ 2.0 Tree View Tutorial I found the next: Secondly, you should make sure that sorting is disabled while you are doing your mass insertions... but I don't know how disable the sorting when I adding the rows. Any suggestion, code or paper? For really really really lots of rows, I suggest you take a look at this demo: https://svn.cronos.be/svn/custom-treemodel-demo/trunk/ -- 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-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: A GIterator type, but not as a simple type - as a GTypeInterface (GIterIface)
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)
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
Re: A better way to use GtkTreeView: Proxy classes and lazy instantiation
And a full example: https://svn.cronos.be/svn/custom-treemodel-demo/trunk/ -- 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-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GNOME Clipboard Manager status.
Hey Jonay, I forwarded your question to some of the gtk/gnome application development mailing lists. On Fri, 2005-08-19 at 10:35 +0200, Jonay Gomez wrote: Philip Van Hoof [EMAIL PROTECTED] wrote: On Fri, 2005-08-19 at 06:17 +0200, Jonay Gomez wrote: What are we the users to expect from GCM in the future? The project is discontinued (since three years now) because it solves a problem in the wrong way. Thanks for your answer. I don't know about the software design point of view, or the GNOME infrastructure point of view. As a user, I can say GCM's user interface is extremely useful to me, and the functionality it provides to the user is unmatched (in fact, other than xclipboard, which cannot handle UTF-8 nor has scrollbars for long text, etc., and uses the ugly plain X libraries for its widgets, there is no alternative). I was using xclipboard until recently, but GCM is better because it supports UTF-8 and you can scroll when you clip a long text, and has more functionality in general (and it consumes 10 times the memory, but I am more than willing to trade that memory for the extra functionality). What is going to be the supported alternative in the right way for GNOME regarding an applet to manage several clipboard selections? By answering this question and putting some mailing lists in CC, I forwarded the question to some of the desktop application development mailing lists. (for clipboard developers: I'm calling a TARGET a format in this E-mail to a desktop user. TARGET is way to cryptic) Storing the clipboard in a history or shelve is not the correct solution because the format of the clipboard can be generated on the fly by an algorithm deployed in the application that gives the clipboard to another application that requests it. Often such clipboard owning applications implement a lot such algorithms. A spreadsheet application can, for example, implement algorithms that can generate the clipboard in XML, Plain text, XHTML, comma separated value and possibly also a binary format only the authors of that software know about. OpenOffice.org has such specialized formats. They are publicised and well known, but only the OpenOffice.org components deals with such clipboard formats. The application Klipper (on KDE) solves the problem of storing clipboards incorrectly. In fact it shouldn't store the clipboards on a shelve for later usage. An application can't solve this, a standard might solve it. What we need is a standard for a (few) common clipboard formats, or a macro language for it (like xslt). If Klipper (or GCM) would like to store the clipboard of OpenOffice.org, it would in essence have to store ALL available formats. Not the algorithms but a copy of the available formats. This is an insane waste of memory resources and will cause an incredible amount of inter process communication using X (And the Xserver might be running on a different computer on the network, so all data goes over the tcp/ip link). You can read more about it in a blog from Sven, the maintainer of The GIMP. They finally implemented the clipboard of The GIMP correctly! Klipper made sure their STANDARD and CORRECT implementation is incompatible with KDE. http://svenfoo.geekheim.de/index.php/2005-06-18/why-klipper-is-bad/ I stopped GNOME Clipboard Manager because I realized that we need a standard, not just a piece of shit application (like Klipper or GNOME Clipboard Manager: Yes I just said that). The problem is that there's no real standard for clipboard formats. Thank you very much for your attention. These references will give you some more information about all this: http://www.pvanhoof.be/files/Problems%20of%20the%20X11%20clipboard.pdf http://pvanhoof.be/blog/index.php/2005/05/24/29-combatting-the-many-x11-clipboard-issues http://pvanhoof.be/blog/index.php/2005/05/25/31-the-save_targets-atom http://mail.gnome.org/archives/gnome-devel-list/2004-March/msg00046.html Short version of this E-Mail: Ad hoc solutions, like Klipper and GCM, are not the solution. -- 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-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
