Talk:GObject

Untitled

I removed some things that made the article C++-centric:

Unlike C++, object orientation with GObject does not allow multiple inheritance.

Important drawbacks of the GObject framework are the absence of operator overloading, exceptions and namespaces. Despite some missing features GObject is easier to learn and get started with than object orientation in C++.

If you want C++ (in the STL and Boost's heavily templated style) features, look at gtkmm, the C++ binding of GTK.

Perhaps some mention of alterative C OO libraries would be appropriate. Do such libraries exsist?

GObject is heavily runtime oriented, and as such interfaces very badly with compile-time type systems such as C++. GTKmm is a possible wrapper of GObject/Glib/GTK+, but it's not perfect.

Internal link "class structure" send user to wrong page. —Preceding unsigned comment added by 83.21.0.21 (talk) 16:49, 5 October 2007 (UTC)

Internal link "GObject Tutorial Aug 2004" is obsolete. —Preceding unsigned comment added by 195.60.68.148 (talk) 08:56, 16 January 2009 (UTC)

Should the part about closure link up to Closure (computer science)?? 99.58.236.137 (talk) 20:05, 3 July 2009 (UTC)

On a paragraph about the lack of an ABI standard, it's said that COM serves that purpose in Windows. I don't use COM for many years now, but I believe this is not true. —Preceding unsigned comment added by 187.23.81.60 (talk) 02:50, 14 November 2009 (UTC)

Agree: the comment about COM has little relevance here, as this is describing C++ the language, not Windows the runtime environment. One improvement maybe to state: In general C++ does not have a standard ABI, although in some OS environments de-fecto ABIs do exist (for example, EABI for C++ on ARM processors, as used by Symbian OS amongst others.) http://en.wikipedia.org/wiki/Application_binary_interface#EABI —Preceding unsigned comment added by 74.125.57.49 (talk) 15:09, 26 January 2010 (UTC)

I believe the following is just a mistake. Of course no one needs to copy hundreds of lines of code. GObject is not too hard, i never copied that many lines of code for subclassing! PC2st (talk) 19:15, 8 July 2010 (UTC)

... For example, creating a non-trivial subclass (even just a subclass of GObject) can require writing and/or copying hundreds of lines of code.

Archived forum discussion
The following discussion has been closed. Please do not modify it.
The following is forum discussion, so archiving it. mjog (talk) 05:38, 22 November 2017 (UTC) Problems Many developers/admins have issues with icons installed that are "not found" or "G_IS_OBJECT", Feature improvements have added complication before fixing the issues, resulting in "icons wont load" bugs since the 1990's still being an issue, for both non-gobject developers or users. It's true depending on gdk gtk used to be simple, and still works trivially. However to get most any today's apps happy (ie, able to present a button with an icon), an insideous cross-dependancy problems arise in building gtk (then part of gnome for icons) which requires several not one build of serveral packages and still fails without "middle-man special configurations" (ie, c++ namespace for X11 Display failure). When trying to find help one is merely told to try a newer version, when trying to find help on newest version one is told "use the binary, not all fixes are out". Lack of acknowlegement also has been a gnome issue since 90's. Simple apps (ie, eog image viewer) now require ld.so to load 100 dependancy libs before showin a simple image on X11 (which requires 0 depends and a small binary). Apps that were avalable when all else fails (ie, gedit basic editor) now are hacked to be broken with depends as well (ie, gedit now wont load if gobject-instrospection, and many other 5th toe features, are not ready), in other words it's all-in-each or none, is your choice. In the past Gnome had warned programmers not to depend on gnome libs except for gnome-specific desktop items - however today they seem to ignore this and suggest apps be made and also libraries be inserted which will create a need to n-fold compile the gtk toolchain to absorb cross-depends. Today gdk/gtk is heraled as cross-platform to microsoft product. However it's history is copy lefted from the Gimp project (GW usa., unix software from a university, allot of linux is, that and gleened from commercial unix products). Cross platform meant cross-unix platform: not "microsft may hack in any kind of changes into competing product for their purposes" (i would say win32 wasn't even released when Gimp was being made). In summary gnome,gtk,gdk etc began as open source GPL however it quickly became and still is a thing which works for, and is controlled by, un-named few. Everyone else gets build failures and continual chaffed when trying to find answers. Like so many things these days: there is simply no accountability or reasoning to choices made that impact ... too many things. As a "great way to save time using X11 wrappers instead of using X11 code" ... it may be for some but not all, and some problems seem to be intentionally never fixed and made worse. In short: it's a legacy that's been depreciated for everyone but a few before it's been released — Preceding unsigned comment added by 72.219.201.25 (talk) 16:49, 27 August 2015 (UTC) Bugs There is poor management and no support in USA universities anymore (which are heavy in microsoft anti-competition unix firings). > Problem compiling gobject-introspection on Snow Leopard > > [.. thousands of bug reports omitted ...] > > Namespace conflict for 'Display' > make[2]: *** [Gdk-2.0.gir] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 "Why are you using 2.9? I recommend you to try with 3.0, which is were most efforts are going right now" (why are you using 2.8? we're werking on 2.9 now!, why ...) one of several shrink wrapped excuses todays "big linuxes" and those who have acess to pushing changes on others, use. This kind of reply is just hiku when one has hundreds of apps depending on gtk2 that need to show icons and there are gtk build chain failures and if there arent: no icons shown in app. Just hiku, and same bull being pushed by ??? since late 90's, same result: bugs and failures for most everyone except a few or for those willing to take binary-only complete distributions that remove privacy and even the right of "root access" to GPL driven unix, and a right to be fully sourced as is the GPL mandate. Lastly, blazenly deleting original source histories and authors is now rampant. Many of today's linux works are past university, commercial, or contributor products (some even famous) that have been simply deleted with other authors replaced. Simply taken and deleted. Today's (gnome or many linux apps) are simply lying about origins of the work - and often destroy the usefulness of the original work to cause it to work only for a few (or only if a binary). I can go back to an old linux CD and see contributions by Sun Micro or X11 contribs from Pixar (Disney funding SGI for movies). Many usa universities (euro ones too, much less so early on though). If I look at the things that took the code (and I know which) they never admit where they got their base or give GPL access to it, nor show the authors. Yet they offer pro-versions for sale and also put GPL on the code: in clear violation of previous permissions of use (to show orig authors and orig code). ie, Qt is full of such absolutely corrupt copyright files: naming europeans as holders of works made in usa. If I could find any rules not being broken I'll tell you - that will be easier.