Re: OpenGL within GTK?
On Friday 06 March 2009 16:31:05 Feng Yu wrote: > Dear list, > > What is the usual way of using opengl to display 3d models within a > GTK application? > > I tried to search for GtkGlArea and GtkGlExt on the net. They all seem > to be old. Are they the correct tools? Yes. GlExt is newer and more complicated. Both are still in use, GlArea still being popular among Perl and OCaml developers (IIRC). I'm not sure that either support modern OpenGL fully (e.g. multisample). -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: OpenGL, GtkGlArea, GtkGLExt
On Thursday 06 March 2008 14:55:13 Emmanuele Bassi wrote: > GdkGLContext * > gdk_gl_create_context (GdkDrawable *drawable, > guint *gl_attributes); > > and, if the cached GdkGLContext gl_attributes are different than the > passed ones (with NULL meaning "use the default"), then scratch the > current context and return a new one - otherwise, return the context > created the first time the function was invoked. That sounds fine to me. I'd replace the guint with a struct, of course. Just to clarify, I have experienced some frustration using various OpenGL-based rendering techniques (glut, sdl, glarea etc.) because of the slow uptake to incorporate support for multisampling even though FSAA has been widely available on consumer-level hardware for many years. Multisampling is an unusual requirement in that it is part of creating a GL context rather than something you can address using ordinary OpenGL calls once the context has been created for you. For example, I added this multisampling to the OCaml bindings to Glut only to discover that freeglut library only had dummy support for multisampling. The existing OCaml bindings to Gtk using GlArea also cannot support multisampling because GlArea does not. The OCaml community discussed the idea of adopting maintainence of GlArea to solve this problem but I think it would be better for everyone if we just moved to something unified and future proof as you suggest. I assume widgets rendered using OpenGL will want the maximum possible multisampling anyway. So the default will probably be fine. Many thanks, -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: OpenGL, GtkGlArea, GtkGLExt
On Wednesday 05 March 2008 13:03:04 Behdad Esfahbod wrote: > On Tue, 2008-03-04 at 19:37 +0000, Jon Harrop wrote: > > I'm not sure who you are referring to as "we" but many people need little > > beyond GlArea. I have no desire to create Gtk-compatible widgets. I only > > want to render general graphics quickly and easily using OpenGL. > > Yes, what you want is "to render general graphics quickly and easily > using OpenGL". What you don't want is GlArea. Tell us (developers) what you > need instead of what *you* think the solution is. We would like compatibility with GLArea. > In the current plan, you will simply use GtkDrawingArea or any other > widget you like instead of GlArea. It's the same level of API, just > works with any widget. Provided it is either compatible with GLArea or working OCaml bindings are created, that is fine. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: OpenGL, GtkGlArea, GtkGLExt
On Wednesday 05 March 2008 09:35:46 Emmanuele Bassi wrote: > On Tue, 2008-03-04 at 19:37 +0000, Jon Harrop wrote: > > > No, gtkglarea is dead. > > > > GlArea still has many users and is the defacto standard for some > > languages. > > it may have many users, but it's unmaintained, so it is ipso facto > "dead". Yes. Nobody has added FSAA support to GlArea AFAIK. > > I'm not sure who you are referring to as "we" but many people need little > > beyond GlArea. I have no desire to create Gtk-compatible widgets. I only > > want to render general graphics quickly and easily using OpenGL. > > on the bug linked in the thread, and in many gtk+ developers team > meetings it was reached a consensus for an integration towards a > cairo-style approach: inside the ::expose-event handlers you can > retrieve a GL context, draw on it using the GL API and the result will > be rendered on the widget's window. > > that's what "we" means. I see. Thank you. > > If anyone is interested in improving the situation for scientists and > > engineers then I would recommend taking this into account: keep it simple > > to bind. > > you can't really get much simpler than a: > > GLXContext gl_context; > > gl_context = gdk_glx_create_context (GDK_DRAWABLE (widget->window)); How would I provide parameters for the GL context (e.g. multisample)? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: OpenGL, GtkGlArea, GtkGLExt
On Wednesday 05 March 2008 18:37:22 Carlos Pereira wrote: > I just ported my app (more than 200,000 lines, totally independent and > unlimited number of OpenGL areas, sharing pre-compiled OpenGL lists, > etc.) last night from Gtkglarea to Gtkglext, so I am in a good position > to highlight the differences, from the user's point of view. > ... > This is ALL that is needed, to port applications from Gtkglarea to > Gtkglext! > > Gtkglext looks slightly more lower level and flexible than Gtkglarea, > closer to the (X) metal as they say, but for users differences are small > indeed... That was very interesting, thank you. Perhaps the authors of the OCaml bindings is being too optimistic in wanting to bind the entire functionality of GlExt (which is pointless, IMHO) and could do something similar. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: OpenGL, GtkGlArea, GtkGLExt
On Tuesday 04 March 2008 18:14:39 Behdad Esfahbod wrote: > On Tue, 2008-03-04 at 17:04 +, Carlos Pereira wrote: > > 2) change the name, for example to Gtkglarea 2.0*, the legitimate > > sucessor to Gtkglarea 1 (the last version of Gtkglarea that I downloaded > > last week is 1.99 and still comes with gtk_signal_connect and other Gtk > > 1.2* functions deprecated long ago) > > No, gtkglarea is dead. GlArea still has many users and is the defacto standard for some languages. > We don't want a new widget. We want being able > to render to widgets using OpenGL as an alternative to using cairo. > That is, the GtkGlExt approach. I'm not sure who you are referring to as "we" but many people need little beyond GlArea. I have no desire to create Gtk-compatible widgets. I only want to render general graphics quickly and easily using OpenGL. > > I believe this would make Gtk more appealing, particularly for > > scientific/engineering/architecture applications. > > Carlos I am a scientist writing software for scientists and engineers using Gtk from OCaml via the LablGTK2 bindings. There are OCaml bindings for GlArea but not GlExt because GlExt is considered too complicated to be worth binding. If anyone is interested in improving the situation for scientists and engineers then I would recommend taking this into account: keep it simple to bind. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: OpenGL interface
On Thursday 03 January 2008 19:02:03 Peter Hildebrandt wrote: > Happy new year everyone, > > I'd like to use opengl in my gtk application. I've come across GtkGLArea > [1] and GtkGLExt [2]. The former appears to be undocumented, while the > latter is according to the website no longer actively maintained. The latter website says: "GtkGLExt has new maintainers! More information will be available soon." > Which one should I use? Or is there a different solution out there? > > I am working on linux (Ubuntu 7.10, GTK 2.20). You can use the package popularity contest to find out what most other people are using. This is an excellent way to jump straight to mature software! I get: libgtkglext1: 42,020 gtkglarea5:8,148 libgtkglext1-dev: 2,614 gtkglarea5-dev: 652 So the newer GTKGLExt library is substantially more common among both users and developers. I actually use GLArea from OCaml and haven't had any difficulties (although I don't distribute in compiled form). -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: C vs C++ for GTK
On Thursday 13 December 2007 08:28, Dan H wrote: > On Wed, 12 Dec 2007 09:26:25 -0700 > Michael L Torrie <[EMAIL PROTECTED]> wrote: > > GTKmm is based on some very nice C++ abstractions around pointers, > > providing many of the same benefits as any managed language with > > pure C++. They are called smart pointers and for GUI development, > > they work very very well. > > Isn't "smart pointers" just a reference counting scheme? Exactly, yes. It is no substitute for accurate GC, of course. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: C vs C++ for GTK
On Wednesday 12 December 2007 15:19, Dan H wrote: > Jon Harrop <[EMAIL PROTECTED]> wrote: > > My recommendation is to choose a garbage collected language for GUI > > work as it makes everything so much easier. Lots of GCd languages > > have GTK bindings these days. > > Just for the record, garbage collection (which is a good idea) doesn't have > to be a feature of the language itself (it isn't for C++, by the way). Just > build and link your C (or C++) program with libgc (the renowned Boehm > garbage collector) and you're fine. I would strongly recommend choosing a language that provides accurate GC rather than using something like Boehm's GC with C/C++. The main reason is that using Boehm on C/C++ code that wasn't designed for Boehm can break working code (see, for example, numerical recipies). Another reason is that languages designed to be GCd will be a lot faster. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: C vs C++ for GTK
On Saturday 24 November 2007 22:11, Patrick wrote: > I thought that C++ must be the way to go as it can do everything that C > can "plus plus" but some heavy hitters don't seem enthused with it, > Linus Torvalds in particular has been quoted as calling it a "horrible > language". IIRC, Linus said that specifically in the context of systems programming. My recommendation is to choose a garbage collected language for GUI work as it makes everything so much easier. Lots of GCd languages have GTK bindings these days. Incidentally, has anyone tried GTK# from C# on Mono? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: C vs C++ for GTK
On Saturday 24 November 2007 22:11, Patrick wrote: > Hi Everyone. > > Sorry for the flame war bait, I know how passionate language debates > get but I need some guidance. I am using PyGTK right now and I am happy > with it, but a day is coming soon were the speed limitations... You might like to look at OCaml and the LablGTK2 bindings to GTK+. OCaml is high-level like Python and fast like C++. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Vector drawing question.
On Wednesday 07 November 2007 21:29, Vadim Gutnik wrote: > Should I be looking at some other toolkit or package for this? Smoke Vector Graphics provides hardware-accelerated 2D vector graphics with a declarative scene graph description: http://www.ffconsultancy.com/products/smoke_vector_graphics/?gtk You might also try Cairo, although it is a lot slower: http://cairographics.org/bindings/ -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Graphing widget (oscilloscope-like)?
On Tuesday 17 July 2007 17:27:20 [EMAIL PROTECTED] wrote: > (I'm about to use bad language here, be forewarned): the license is > important, as this will be going into code that is, unfortunately, > proprietary - as such GPL is out, but LGPL is acceptable. We have a commercial high-performance hardware accelerated vector graphics renderer that targets OpenGL and can be used with GTK via gtkglarea: http://www.ffconsultancy.com/products/smoke_vector_graphics/?gtk -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. OCaml for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists/?e ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Catching window.destroy
When a user clicks on the "X" of the main window of my GTK app, I'd like to handle the signal (e.g. to check for unsaved data). How do I handle this signal to prevent the window from disappearing? Many thanks, -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. OCaml for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists/?e ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
