Page 3 of 3 12 3
Reply
Thread Tools
daperl's Avatar
daperl is offline daperl
2010-09-04 , 13:56
Posts: 2,427 | Thanked: 2,986 times | Joined on Dec 2007
#21
Originally Posted by dannym View Post
Some mistakes are special to GObject and nobody would ever replicate:

the virtual methods "set_property" and "get_property" should not call their ancestor method (of the superclass).
All other virtual methods should. What gives?
Could this have something to do with the ability for "listeners" to monitor the access and changing of properties. If so, that's a powerful mechanism that I wouldn't want to lose.
__________________
N9: Go white or go home
 
vivainio is offline vivainio
2010-09-04 , 14:51
Posts: 222 | Thanked: 205 times | Joined on Jul 2009 @ Finland
#22
Originally Posted by dannym View Post
C++ and C&GObject, not so much. They're very similar, only GObject is more advanced because it came later and learnt from the silly mistakes C++ made (no reflection, no properties (and by that, no automatic notification or monitor pattern), no reference counting, broken virtual methods, making copies all over the place, no Variant datatype, no signals, ...)
Seems like you are trying to taste a food by reading a list of ingredients. Proof of the programming environment is in the pain of using it.

Here's a real world example with GObject (from libhildondesktop):

Code:
typedef struct _HDPluginLoader HDPluginLoader;
typedef struct _HDPluginLoaderClass HDPluginLoaderClass;
typedef struct _HDPluginLoaderPrivate HDPluginLoaderPrivate;


#define HD_TYPE_PLUGIN_LOADER            (hd_plugin_loader_get_type ())
#define HD_PLUGIN_LOADER(obj)            (G_TYPE_CHECK_INSTANCE_CAST ((obj), HD_TYPE_PLUGIN_LOADER, HDPluginLoader))
#define HD_PLUGIN_LOADER_CLASS(klass)    (G_TYPE_CHECK_CLASS_CAST ((klass),  HD_TYPE_PLUGIN_LOADER, HDPluginLoaderClass))
#define HD_IS_PLUGIN_LOADER(obj)         (G_TYPE_CHECK_INSTANCE_TYPE ((obj), HD_TYPE_PLUGIN_LOADER))
#define HD_IS_PLUGIN_LOADER_CLASS(klass) (G_TYPE_CHECK_CLASS_TYPE ((klass),  HD_TYPE_PLUGIN_LOADER))
#define HD_PLUGIN_LOADER_GET_CLASS(obj)  (G_TYPE_INSTANCE_GET_CLASS ((obj),  HD_TYPE_PLUGIN_LOADER, HDPluginLoaderClass))

struct _HDPluginLoader 
{
  GObject gobject;

  HDPluginLoaderPrivate *priv;
};

struct _HDPluginLoaderClass 
{
  GObjectClass parent_class;

  GObject *(* load) (HDPluginLoader  *loader,
                     const gchar     *plugin_id,
                     GKeyFile        *keyfile,
                     GError         **error);
};

...
And here's the equivalent in C++:

Code:
class HDPluginLoader 
{
  QObject* load(...)

...
};
I rest my case.

EDIT: ...and Qt metaobject system gives you the dynamic, introspective features you want.
__________________
'QtDone'. Getting things done (GTD) was never this cheap!

'QmlReddit' reads Reddit!
Last edited by vivainio; 2010-09-04 at 14:57.
 
mikecomputing is offline mikecomputing
2010-09-04 , 15:40
Posts: 3,464 | Thanked: 5,107 times | Joined on Feb 2010 @ Gothenburg in Sweden
#23
Originally Posted by efa View Post
thanks, I want to start developing something for my N900, but I do not know C++ so I cannot use QT. I know well C so I chosed GTK
imho its a bad choice to use gtk if you want future compability with Meego. the fact is that its not that hard to learn c++ also there is pyside (python for qt)

I am far from an expert but there is probadly many reason why hilldon will not be supported in meego. one is to minimize dependies cause of lack of nand memory on embedded small computers/phones.

as we all know QT is a bit slow on N900 probadly cause libqt is not in nand instead its on the eemmc memory and qt doesnt fit in nand... so in meego case qt is official and probadly will go in future phones nand(root), and hildon not, so apps written in hildon maybe will work but slow cause it will go on emmc.

I dont say this is 100 percent correct but
 
attila77 is offline attila77
2010-09-04 , 15:59
Posts: 3,319 | Thanked: 5,610 times | Joined on Aug 2008 @ Finland
#24
Originally Posted by daperl View Post
Could this have something to do with the ability for "listeners" to monitor the access and changing of properties. If so, that's a powerful mechanism that I wouldn't want to lose.
A common problem in comparisons like this is that people compare what GObject gives them with C++ (and go ranting on how this or that is ugly in C++ ). That is is the wrong comparison, as Qt is not just a set of libraries, but a full-blown framework (even more so than GObject/GTK) - if you're using Qt, the valid question is if Qt addresses the problems C++ has/had, and often the answer is yes, like in the case or various monitor patters, reference counting, etc (in fact, sometimes I feel as if it's a C++ compatible C derivative of it's own, given all the syntactic sugar and patterns it introduces)
__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
 
vivainio is offline vivainio
2010-09-04 , 16:41
Posts: 222 | Thanked: 205 times | Joined on Jul 2009 @ Finland
#25
Originally Posted by mikecomputing View Post
as we all know QT is a bit slow on N900 probadly cause libqt is not in nand instead its on the eemmc memory and qt doesnt fit in nand...
Qt is not particularly slow on N900 (I have no reason to think Hildon would be any faster). Even startup time is quite tolerable, less than 3 secs for a small Qt application.
__________________
'QtDone'. Getting things done (GTD) was never this cheap!

'QmlReddit' reads Reddit!
 
daperl's Avatar
daperl is offline daperl
2010-09-04 , 17:25
Posts: 2,427 | Thanked: 2,986 times | Joined on Dec 2007
#26
Originally Posted by attila77 View Post
A common problem in comparisons like this is that people compare what GObject gives them with C++ (and go ranting on how this or that is ugly in C++ ). That is is the wrong comparison, as Qt is not just a set of libraries, but a full-blown framework (even more so than GObject/GTK) - if you're using Qt, the valid question is if Qt addresses the problems C++ has/had, and often the answer is yes, like in the case or various monitor patters, reference counting, etc (in fact, sometimes I feel as if it's a C++ compatible C derivative of it's own, given all the syntactic sugar and patterns it introduces)
I was just speculating at a reason for an idiosyncrasy. But if you're implying that idiosyncrasies can cause brittleness, I agree with you. Does Qt have any idiosyncrasies?

Originally Posted by vivainio View Post
Qt is not particularly slow on N900 (I have no reason to think Hildon would be any faster). Even startup time is quite tolerable, less than 3 secs for a small Qt application.
Qt apps seem to run very well on the n900, it's when building one on the n900 that Hell starts to freeze.
__________________
N9: Go white or go home
 
thp's Avatar
thp is offline thp
2010-09-04 , 17:36
Posts: 1,391 | Thanked: 4,272 times | Joined on Sep 2007 @ Vienna, Austria
#27
MeeGo feature request: http://bugs.meego.com/show_bug.cgi?id=5977

(if you want to vote or subscribe there)
 
TheBootroo is offline TheBootroo
2010-09-05 , 06:21
Posts: 138 | Thanked: 164 times | Joined on Aug 2009 @ Chateauroux, FRANCE
#28
c++ with qt4 is very very very simple and powerfull :

i've learn C/Gtk two years ago and 6 months after i've gone to qt because gtk was not enough powerfull for my project (no troll here, just a point of view)

why the hell do you want gtk hildon be supported in meego ? what will be the main force of meego is surely is consistency and it will be broken if we accept (like in almost all linux distro) a too large variety of toolkits, languages ....

that's what is doing Apple's force (and i hate them) : their products are really uniforms and integrated, so if we want MeeGo handset to be a full success like the iphone, we have as developper to stay stuck with ONE framework (meegotouch based on plain C++/Qt4) and do everything in the rules of art.

to many freedom is killing freedom, and IMO a free open platform will NEVER grow up enough to be visible if there are no limit and no unity in it.

we are not talking about a geeky OS the enjoy with hacking, there are Maemo and many other to do that, but if you want many apps, you need many customers, and to have many customers your product needs to be brillant, attractive and consistent.

and technically talking, get a look at meego theming system, based on layouts, css and svg and you will see in one second that Qt is greatly better than Gtk (with or without hildon) to give your handset a decent modern look, in the ways that end users like today.


Cheers.

PS : excuse my poor english, i'm french and just trying to get perfectly bilingual but that's not that easy....
Last edited by TheBootroo; 2010-09-07 at 10:26.
 
vlg's Avatar
vlg is offline vlg
2010-09-10 , 21:57
Posts: 44 | Thanked: 26 times | Joined on Jan 2006 @ Rockville, MD, USA
#29
Originally Posted by vivainio View Post
Seems like you are trying to taste a food by reading a list of ingredients. Proof of the programming environment is in the pain of using it.
This is not an entirely fare comparison. I suggest comparing Qt to Gtkmm which is the official C++ wrapper of GTK+.

To get a better perspective, please, refer to this discussion date back to 2004.

Back in the day, GTK+/Gtkmm came to existence to counter-balance success of Qt as multi-platform GUI toolkit. At that time Qt was not an open-source solution at least on Windows. So, GTK+ was a solution to an ethical problem related to Linux desktop (R. Stallman on GTK+ vs. Qt dilemma).

Here are some pointers:

GTK+
=====
1. GTK+ is favored by those C developers who need speed or find themselves strangled in an embedded world. In addition, most of electrical engineers who never had a chance to learn OOD with C++/Java/C# choose GTK+ to write GUIs for embedded platforms.

2. GTK+ is well documented with number of books published.

3. There is virtually 0 jobs that require GTK+. So, to me it seems that GTK+ is mostly used by free software developers or in-house jobs.

Gtkmm
======
1. Favored by C++ developers who wanted a guarantee from day one that the framework is open-sourced across Unix/Win/Embedded platforms.

2. Aside from user's guide for beginners and developer's mailing list, there is no documentation touching more complex aspects of s/w development. This is hacker's nirvana where you derive masochistic pleasure of debugging both GTK+ and Gtkmm with gdb to figure out why your tiny app crashes all of the sudden.

3. Same as for GTK+, there is no commercial market for Gtkmm developers. So, it is a hobby rather than a career.

Qt
===

1. A commercially-supported multi-platform C++ GUI toolkit long before Java/C#/Python gained the ground.

2. Well-documented from early days on.

3. There is some commercial work with Qt and hopefully with Nokia throwing its weight behind Qt across their fleet of mobile devices, there would be more of job offerings with Qt required.

So, GTK+, Gtkmm, and Qt appeal to 3 vastly different segments of programmers.

It would be really nice if Hildon were supported by next Nokia MeGo phone. Otherwise, developers of a whole bunch of Gtk+/Gtkmm embedded applications face a choice to either

1) abandon MeGo altogether or

2) abandon Gtk+/Gtkmm, bite the bullet and move on to Qt.
Last edited by vlg; 2010-09-10 at 22:36.
 
Reply
Page 3 of 3 12 3

« Previous Thread | Next Thread »

 
Forum Jump


All times are GMT. The time now is 09:52.

Contact Us - Home - Archive - Top