Re: libglade frustration
On Sun, 2007-02-11 at 16:06 -0700, Michael Torrie wrote: On Sun, 2007-02-11 at 14:58 -0700, Michael Torrie wrote: I've attached one that compiles thusly: gcc -o gladetest gladetest.c `pkg-config --cflags --libs gtk+-2.0 libglade-2.0` The attachment doesn't seem to have made it through the mailing list. How about: http://www.torriefamily.org/~torriem/gladetest/ The testlibglade program that comes with libglade is about 100 lines of code + some helpfull comments about using the library and about how the library works. I hope that this source file in the libglade tarball was easy to find. Regards, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GObject docs improvements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Feb 12, 2007 at 09:49:46PM +0100, David Nečas (Yeti) wrote: On Mon, Feb 12, 2007 at 02:05:27PM -0600, Shixin Zeng wrote: [...] 2)How its intefaces handled, when a class is derived? Will the child classes possess the same interfaces, if they don't want to reimplement them? Yes, it will (a non-transitive is-a relation would be very very strange). Ha! Gotcha. When talking about interfaces you might rather say implements-a rather that is-a :-) I do belong to the camp that believes that interfaces are just poor man's multiple inheritance (whether you believe that or not deends, I think, on whether you maintain that an object is defined by its behaviour). But don't take me all too seriously here, I tend to be an OO heretic and risk every time getting burnt .-) Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFF0eKUBcgs9XrR2kYRAlfXAJwNLH77FITeugw9UG0v3HC/LOnPJACfVa43 AOGxRJF92AgXVDIPvsRVkBU= =Oqsg -END PGP SIGNATURE- ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GObject docs improvements
A point I miss in the tutorial is to mention the G_DEFINE_TYPE()-like macros which should be prefered over manually defining a _get_type() function whenever possible. I never did get that G_DEFINE_TYPE() stuff at all... It'd be good to see some clear documentation on it. The G_DEFINE_TYPE() stuff is a macro that expands to the common boilerplate code. If you have this and are able to write the boilerplate code manually, what other documentation is needed? How about a real-world example, and a note on advantages (other than less typing) and disadvantages compared to doing it the long-winded way (spelling out the whole lot of boilerplate code). What are the cases where the G_DEFINE_TYPE() macros are commonly useful, for what common cases AREN'T they useful (but might look useful at for glance, for example), and where applicable, notes on how to get around certain limitations of the macro (eg. there's a lot of NULLs in the type info structure shown in the documentation) and why or why not to do it that way. That kind of thing might be helpful... Fredderic ___ Join Excite! - http://www.excite.com The most personalized portal on the Web! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: libglade frustration
On Tue, 2007-02-13 at 09:47 -0500, Tristan Van Berkom wrote: The testlibglade program that comes with libglade is about 100 lines of code + some helpfull comments about using the library and about how the library works. I hope that this source file in the libglade tarball was easy to find. Good to know. In fact I found it on my FC6 box as part of the libglade2-devel package, installed to /usr/share/doc/libglade2-devel-2.6.0/test-libglade.c Of course to find it I had to do rpm -ql libglade2-devel. Alas most developers who are going to be using libglade won't be compiling libglade from source so they likely won't find this file straight away. But the file is still there, even under binary packaged systems. thank you. Michael Regards, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: libglade frustration
On Tue, 2007-02-13 at 10:28 -0700, Michael Torrie wrote: On Tue, 2007-02-13 at 09:47 -0500, Tristan Van Berkom wrote: The testlibglade program that comes with libglade is about 100 lines of code + some helpfull comments about using the library and about how the library works. I hope that this source file in the libglade tarball was easy to find. Good to know. In fact I found it on my FC6 box as part of the libglade2-devel package, installed to /usr/share/doc/libglade2-devel-2.6.0/test-libglade.c Of course to find it I had to do rpm -ql libglade2-devel. Alas most developers who are going to be using libglade won't be compiling libglade from source so they likely won't find this file straight away. But the file is still there, even under binary packaged systems. This is a real real real shame, this file that sits in svn as a part of the package, is situated in the most obvious place to find out things about the actual package, its in the actual package itself. How much more obvious can this be to find ? Cheers, -Tristan PS: This is not a personal thing, countless hordes have come in search of a libglade example without ever consulting the tarball, its just getting a little frustrating by now - but what can we do to improve the situation ? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: libglade frustration
On Tue, 2007-02-13 at 14:16 -0500, Tristan Van Berkom wrote: PS: This is not a personal thing, countless hordes have come in search of a libglade example without ever consulting the tarball, its just getting a little frustrating by now - but what can we do to improve the situation ? I was pondering that as I wrote my post. Obviously this is an issue with the linux distribution. I feel sheepish myself because while looking for this file on my FC6 box, I discovered an entire directory populated by the various gtk+ devel packages that has complete API docs for gtk, glib, pango, gnome, etc. I had been relying on the web pages for that before (not a bad thing though). One thing that might help here is to have a compiled executable that demonstrates libglade be installed as part of the normal compilation process. This would then be picked up by the packagers and installed as part of the -devel package. The demo program would be similar to gtk-demo where the different aspects of libglade would be demonstrated along with the source code window where users could see the source code and the glade files. That way, rather than pointing files at the .c file, just say run libglade-demo and expect it to be self documenting in every way. I think this may be a better thing than just the test-libglade.c file. Of course I'm not sure exactly what things would want to be demoed exactly. Maybe just a couple of glade-created windows and callbacks. Michael ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: libglade frustration
On Tue, 2007-02-13 at 12:53 -0700, Michael Torrie wrote: [...] One thing that might help here is to have a compiled executable that demonstrates libglade be installed as part of the normal compilation process. This would then be picked up by the packagers and installed as part of the -devel package. Somehow I think that downloading the actual tarball from wherever the website of a said software said to go download it from is much more obvious a place then in a -devel package, that may or may not be available for whatever your distribution flavor of the month happens to be. I dont know, I'm trying to think constructively and its not working very well, lets say ideally the test-libglade.c program should be included in the api docs either as a reference or even inline. Feel free to write a patch to libglade and poke James to apply it... OTOH it does seem like an excersize in futility to work on the improvement of an api documentation of an api that has only like 3 function calls to document. Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: libglade frustration
On Tue, 2007-02-13 at 14:03 -0700, Michael Torrie wrote: On Tue, 2007-02-13 at 15:12 -0500, Tristan Van Berkom wrote: Somehow I think that downloading the actual tarball from wherever the website of a said software said to go download it from is much more obvious a place then in a -devel package, that may or may not be available for whatever your distribution flavor of the month happens to be. You're right. FC6 decided to package gtk-demo with the main gtk2 rpm. If there was a similar program to gtk-demo for libglade I'm sure they'd put it in libglade2 also. In any event, if a user wants to develop with libglade, he'd need to install the rpms or debs or whatever. Most users aren't going to be using the raw tarballs. The problem with the raw tarballs is that they cause would-be users a lot of grief. I and many others on the list no longer recommend that new developers compile and install the various parts of gtk from tarballs. Without the proper understanding of the prefix, the pkg_config environment variable, and the LD_LIBRARY_PATH, users end up with completely broken systems. Sure, people dont generally use lfs as thier chosen distro, the tarball is also probably something you dont want to go just installing in any old prefix, but when it comes to looking at the package that was provided by the developers and maintainers of a said software, you download the tarball and look, at least thats what I do. Lets put a different spin on it, is it fair to blame the maintainers of a module for not providing information that was in fact included in thier tarball ? if people dont think thats fair, then why wouldnt they just look in the tarball ? From that perspective, considering that we are speaking of a user base of developers that probably have experience dealing with third party software packages, I find it stunning that people dont just run an 'ls' in the package root. [...] Agreed. Perhaps when GTK includes the libglade stuff in the version 3.x releases, gtk-demo can be partially rewritten to be use some glade files and thus have a ready example of using the gladexml calls. The builder documentation will be a part of gtk+ ofcourse, that will be better. Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: libglade frustration
On Tue, Feb 13, 2007 at 02:03:29PM -0700, Michael Torrie wrote: In any event, if a user wants to develop with libglade, he'd need to install the rpms or debs or whatever. Most users aren't going to be using the raw tarballs. Install it and use it are two very different things. Sure, one installs the library from rpms, debs, ports, ... But programming with a library without looking at its source code? If one is legally permitted to, who would throw away such a source of examples (whether they are dedicated examples or not), a style guide, ..., and above all the ultimate reference? So I would expect most people to get the source code anyway...(cont) The problem with the raw tarballs is that they cause would-be users a lot of grief. I and many others on the list no longer recommend that new developers compile and install the various parts of gtk from tarballs. I recommend everyone to *compile* the source code. Install it only if you know what you are doing though. Without the proper understanding of the prefix, the pkg_config environment variable, and the LD_LIBRARY_PATH, users end up with completely broken systems. (cont)...the fact they often use it to destruct their systems instead of studying it is sad, and I must admit I don't know how to change this -- aside from adding more examples to the API reference itsefl and adding the information the source code tarball contains more examples to a prominent place in the API reference. But the prospect of each library package (and worse, its *non*-developer package on distros that make this difference) coming with some demo executables with the sole purpose to provide examples to clueless developers does not fill me with joy either. Isn't /usr/bin already cluttered enough? Moreover, if somone can neither find an example using Google nor grab and unpack the source code, would he be able to figure out there is some foo-demo sample program in libfoo package? Yeti -- Whatever. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: EggSequence
On 04 Feb 2007 00:30:54 +0100 Soeren Sandmann [EMAIL PROTECTED] wrote: Soeren Sandmann [EMAIL PROTECTED] writes: If accepted, I'll write API documentation and port GtkListModel to use it. There is already a through testsuite SVN. I wrote API documentation and committed it. Maybe you can explain how the name sequence is more appropriate for your container than for a GList, GSList, GQueue, GString, GArray, GPtrArray or GByteArray? -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgpfUS1U4aoQh.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Treap instead of splaytree for GSequence
On 13 Feb 2007 03:46:11 +0100, Soeren Sandmann [EMAIL PROTECTED] wrote: GSequence is currently implemented with a splaytree which, even though it is a neat data structure, has some downsides: * They are only O(log n) in the amortized sense This means individual operations can take a long time. This is a problem for interactive applications where predictable performance is often more important than good average performance. Well, treaps have amortized time O(lg n) for their operations as well. The performance as reported by testtreemodel is slightly worse with treaps than with with splaytrees. The reason for this is that - gtk_list_store_compare_func() is really slow, so what is getting measured here is more than anything how many times that function gets called. Well, if this is the case, then it does sound like a splay makes more sense for this kind of application. Still, treaps are cool. nikolai ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkTreeView and fixed_height mode
On Wed, Feb 07, 2007 at 03:37:07PM +0100, Emmanuel Briot wrote: I do agree with your analysis that the other modes do not make sense, but if things work anyway shouldn't it just be documented that best practice recommend using fixed width mode, but have the code not enforce it ? Maybe, I am not really sure about that. Fixed height mode is really limited and we have always discouraged to use it. However, for really large data sets there is not really another option. Are there any other limitations that not having things resize automatically ? Not that I know of, but of course from the name it is clear that all rows in the tree view will be forced to have the same height. It is not possible to have both rows with a single line of text and multiple lines of text, etc, etc. regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkTreeView and fixed_height mode
On Wed, Feb 07, 2007 at 10:06:13AM -0500, Morten Welinder wrote: You would measure cells only as they become visible and adjust the width of the columns as needed. That would probably mean that the columns will be busy resizing as you are scrolling. I am not sure if that is really nice ... regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Adding foreign_new_xdisplay for Gdk X11
On Tue, 6 Feb 2007, Ricardo Cruz wrote: Hello, Btw, could the GtkStyle painting methods signature be changed so they take a generic GdkDrawable rather than a GdkWindow? Because I don't see a reason for why engines would need a GdkWindow and passing a GdkPixmap is sometimes useful. I understand if it breaks stuff, but at least document that a GdkPixmap is also acceptable. there's an extra bug report + patch in the queue adressing off screen / pixmap rendering in generell: http://bugzilla.gnome.org/show_bug.cgi?id=318807 --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkTreeView and fixed_height mode
Morten Welinder [EMAIL PROTECTED] writes: That depends on the data and how much we have seen before, but if we initially did a fair-sized sample -- last I looked we were doing 1000 rows -- then the probability is low and hence it is not annoying. If you did that, then you could also completely avoid having the fixed-height mode by estimating the total height based on the initial sampling, then adjusting the scrollbar as needed. If the distribution of heights is reasonable, then the initial guess will be close to the correct one. In the common case where all rows have the same size, the initial guess would be exact. This is particularly appealing since programmers in general don't have the information to answer the question is this tree fixed height, because the answer depends on what fonts are installed and what text is actually in the tree. Soren ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: EggSequence
Jean-Yves Lefort [EMAIL PROTECTED] writes: Maybe you can explain how the name sequence is more appropriate for your container than for a GList, GSList, GQueue, GString, GArray, GPtrArray or GByteArray? It is not. I don't think GSortedList is accurate either, since a GSequence does not have to be sorted. Soren ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Why file system abstraction layer in GTK+ is only private stuff?
Hi! I'm working on small application, which make some operations on files and I must say, that I have serious problems with it. so far I can't port my program on this platform. While I'm developing my program on Linux I had searched how to obtain MIME types on files. I went through www.freedesktop.org, www.google.com and I finished in GTK+ repository. I found it's code very helpful and I can say, that file system abstraction layer seems to be quite complete (in basic range) and very clear. That's why I can understand, why you didn't add it to public API and it's still only library's internal code?! Maybe, there are some specific reasons, which i don't know. It's very hard to develop application for Linux and win32, which do some operations on files and directories, because there is no cross-platform library, which can do such things. On Linux we can use GNOME VFS, but it's still solution only for Linux. Maybe you should think about public support fre some file system and add it in one future releases? I know, that file system support is quite far from GUI, so maybe it can be good idea to move it to GLib or even create independent library? -- Cya! Tom ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Why file system abstraction layer in GTK+ is only private stuff?
Hi, On Tue, 2007-02-13 at 23:39 +0100, Tomasz Jankowski wrote: Maybe you should think about public support fre some file system and add it in one future releases? I know, that file system support is quite far from GUI, so maybe it can be good idea to move it to GLib or even create independent library? Maybe you should search the mailing-list archives before posting? There has been a very detailed thread about this topic only a few months ago. Look for Plans for gnome-vfs replacement. Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
