hildon will be supported?

[efa]

I saw GTK+/Clutter are supported for Moblin compatibility.
I cannot find mention for Hildon support in MeeGo.
Will tons of Maemo5 applications work on MeeGo?

[Ignacius]

If not oficially supported, I don't know of any issue for hildon not compiling for MeeGo. Even if I thought hildon requiered a highly patched gtk+, also libhildon is already in Ubuntu repositories.

[efa]

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

[jnwi]

If you're starting something new, you're much better off using Qt even if it means learning C++. It's not really that difficult, and Qt simplifies memory management. I recommend starting with this book (http://qt.nokia.com/developer/books/cpp-gui-programming-with-qt-4-2nd-edition/).

[efa]

I took 1-3y to learn C, and about 2y to learn GTK in spare time. I estimate 1y to learn the differencies of C++ and 1y to learn QT. Seems to me is not reasonable to write a simple application only for hobby. May I can change idea if I find some rapid guide to call C++ method from C, and continue use C for my code.

[KiberGus]

C++vas designed to be C compatible. Nearly every C program is a C++ program. So you can write a C programm with invocation of C++ methods and compile it with g++ instead of gcc.
But usually it is threated as bad stile programming and doesn't look well. You soon would fin out that you use too much of C++ features and your code is a strange combination of paradigms.

[efa]

if it is only a problem of stile and look I don't mind, I want to use C for my CLI/algorith code, as this is the standard, fast and very portable. The problem is that I do not know how to call a C++ method from C as now, and this is required for QT. Nokia do not officially support C language bindings, neither show some examples.
In my case (and I think in many hobbist), comparing hildon/GTK/C programming (0y training) with UX/QT/C++ (1y+ training), lead to dubt in choice.

[hqh]

if it is only a problem of stile and look I don't mind, I want to use C for my CLI/algorith code, as this is the standard, fast and very portable. The problem is that I do not know how to call a C++ method from C as now, and this is required for QT. Nokia do not officially support C language bindings, neither show some examples.

Compile your C program with a C++ compiler, that's all you need for bindings, basically. Or create the UI with Qt and C++ from the beginning, then use C for algorithms and lower level stuff as you like.

True that you'll have to spend some time getting used to object-oriented programming with the GUI part at least, but once that's out of the way learning the basics of Qt should be a matter of days.

[efa]

how to call a C++ method from C?

[SpideyBR]

Directly, no wrapper needed. You C code will actually compile to C++ code directly.

Since C is a subset of C++, you can design your UI with C++, maybe even with QTCreator or other tool, and then just add your algorithm source and header files and invoke then directly from C++.

If you have in your C source/headers:
void do_something(int myint, char *cool_array, float awesomeRate);

You just call them in C++ with:
do_something(i, charArray, 3.1);

C++ is C with powers, believe it!

[efa]

this require me to write my C code inside C++ file, that I do not know, and probably I will damage it.

Seems more easy to me, keep separate as much as possible the C++ and C, keeping them in different files.
For example the C++ code generated by QTCreator remain untouched with them methods, and the C algorithm in my hand written files the same. For sure I will add the C++ method invocation to my C part (like a C function call). It is possible?

// file GUI: C++ part generated by QTCreator
...


// file algorithm: C part hand written by me
...
/* other C code */
C++ method invocation
/* other C code */
...

and then compile both with a C++ compiler.

This let me have more confidence with algorithm file, because I understand error and warning better, as all the file is C syntax but the C++ method invocation only (I do not expect syntax error and problems on QTCreator generated files).
With this solution, the only thing I don't know (apart QT), is how to call a C++ method, the syntax needed (an example of course), taking care that arguments to be passed are variables defined with C syntax, keeping all previous C code intact.
This facilitate the port from a pure CLI C, and also from GTK+ C code.

I suppose will call functions by pointer, and pass variables by pointer (that it is probably what happen to C++ object code when is traslated to C at the start of compilation).

thanks

[Venemo]

Hildon-related things (libhildon and its friends) will definitely work on MeeGo.
Work is underway to port them.

[efa]

wow!!!
;-)

[nicolai]

this require me to write my C code inside C++ file, that I do not know, and probably I will damage it.

C++ syntax isn't that different from C.

Seems more easy to me, keep separate as much as possible the C++ and C, keeping them in different files.

As the C++ part and the C part are for different purpose, separating them is a good idea, like splitting one C program
in different modules.

For example the C++ code generated by QTCreator remain untouched with them methods, and the C algorithm in my hand written files the same. For sure I will add the C++ method invocation to my C part (like a C function call). It is possible?
...
and then compile both with a C++ compiler.

I wrote the Calendar Home Widget, this is a GTK(hildon) based
widget, just like every other hildon home widget. I use the GTK api,
plain old C datatypes and some C++ objects. But it is actually C++ code and it is compiled with c++.
I had to use this, as the calendar api (calendar-backend) IS a c++ library.
You won't see much difference.

This let me have more confidence with algorithm file, because I understand error and warning better, as all the file is C syntax but the C++ method invocation only (I do not expect syntax error and problems on QTCreator generated files).
With this solution, the only thing I don't know (apart QT), is how to call a C++ method, the syntax needed (an example of course), taking care that arguments to be passed are variables defined with C syntax, keeping all previous C code intact.
This facilitate the port from a pure CLI C, and also from GTK+ C code.

I suppose will call functions by pointer, and pass variables by pointer (that it is probably what happen to C++ object code when is traslated to C at the start of compilation).


This depends on the type of C++ functions you want to call.

regards
Nicolai

[vivainio]

Hildon-related things (libhildon and its friends) will definitely work on MeeGo.
Work is underway to port them.

Note that there are no guarantees for hildon implementation, including quality/maintenance; it may not be the smartest way to start developing a new application.

[vivainio]

this require me to write my C code inside C++ file, that I do not know, and probably I will damage it.


Just for kicks, why won't you just bite the bullet and try it?

One area where C and C++ differ is that if you are using lot's of void pointers, you may need to add a few casts. That's 10 minutes of work.

[lcuk]

Hey, I submitted a keynote about this to the Meego Conference this year

see the thread here: http://talk.maemo.org/showthread.php?t=61269

Maemo Community, Standing on the shoulders of giants

The Maemo community built up around the Nokia Internet Tablets has grown steadily over the last 6 years.

Over 25,000 developers have been involved in the community at different stages creating a wealth of products and knowledge, ranging from little hacks that soothed an itch, to full-blown games, kernel modules and even quality assurance procedures.
....
This planning is underway at the moment and Maemo and Meego team members are working together to port the first shining light examples of GTK/Hildon applications within the handset image.

Combined with the lessons learned in community builds of the Hildon libraries and the skilled OBS hackers we believe its possible to achieve this task.

Many great Maemo applications will hopefully become available on your Meego handset devices for your continued enjoyment.

[dannym]

efa:
Use what you think is right. Programming languages aren't that important and if it comes to porting it from one low-level language like C to another low-level language like C++, they're all very similar anyway :-)


SpideyBR said:
>Since C is a subset of C++

No, it isn't anymore. But almost.

> you can design your UI with C++, maybe even with QTCreator or other tool, and then just add your algorithm source and header files and invoke then directly from C++.

True, to a point. C++ function declarations aren't that much different from C function declarations. The naming convention is different, though. And the standard data structures are all different.

>If you have in your C source/headers:
>void do_something(int myint, char *cool_array, float awesomeRate);

efa:
If you mix C and C++ code, you have to add the following stuff to your C header file:

#ifdef __cplusplus
extern "C" {
#endif

void my_function(int x); /* or whatever */

#ifdef __cplusplus
};
#endif

ONLY then you can #include the header file into a C++ source file. This is so it looks the C functions up using the C naming convention.

And only then, :
>You just call them in C++ with:
>do_something(i, charArray, 3.1);

And this isn't the most difficult thing.
The difficult thing is to call a C++ method from within a C function.
If you specify the name of a C++ method, it will pick up only the CODE BLOCK address.
A C++ object instance has the data part (called "this"), without it, you can't call any C++ method that stores data in its object.
So you have to carry around both the code address and the data address and get it in a C callback and once you do that, how is it any different from just using plain C structs in the first place?

And if you are in an C source file, C++ types are not there so you cannot specify the signature of the function to call and since there's no reflection, that would be it. The only practical to get that to work is to compile the "C" code in C++ as well, which technically makes it (really weird) C++ code.

On the other hand, if you specify a callback in a modern language, it will of course automatically carry both the code and the data pointers (and eventual curried arguments).

Note that Qt adds a lot of customizations (they even have their own *callback compiler*) on top of C++ to make it bearable.
The library "Boost" does as well.
However, this is bandaids on top of bandaids and in the end the C++ compiler will use up 500 MB RAM in normal operation and take long to compile anything. And the error messages look like they are from another planet.

SpideyBR said:
>C++ is C with powers, believe it!

C++ makes me despair for computer science.

If I want to have actual fun doing programming, I use Python.

And about the comment about memory management, Glib does reference counting memory management and the GObject system already is an object system. How does it get better than that? Does Qt do garbage collection? Add anything of value to the object system?

As for using Qt because it will be used in upcoming MeeGo devices, that's a valid reason. On the other hand, they have Gtk as well.

As for how C++ is preprocessed to C:

----------------- C++ ----------------------------
class S {
protected:
int m_common;
public:
S();
}; // note semicolon

class A : public S {
private:
bool m_flag;
public:
A();
void checkSomething();
bool getFlag() const;
}; // note semicolon

S::S() {
this->m_common = 42;
}

A::A() {
this->m_flag = false;
}

void A::checkSomething() {
...
this->m_flag = true;
}

bool A::getFlag() const {
return this->m_flag;
}

int main() {
A a;
a.checkSomething();
a.getFlag();

or
A* b = new A;
b->checkSomething();
b->getFlag();
return 0;
}

----------------- C ----------------------------

typedef struct {
int m_common;
} S; // note semicolon

typedef struct {
S super;
bool m_flag;
} A; // note semicolon

void Z1SZ4ctor(S* this) {
this->m_common = 42;
}

void Z1AZ4ctor(A* this) {
Z1SZ4ctor((S*) this);
this->m_flag = FALSE;
}

void Z1AZ14checkSomething(A* this) {
this->m_flag = TRUE;
}

int Z1AZ7getFlagC(A* this) {
return this->m_flag;
}

int main() {
A a;
Z1AZ4ctor(&a); // this is done automatically in C++
Z1AZ14checkSomething(&a);
Z1AZ7getFlagC(&a);

or
A* b = malloc(sizeof(A));
Z1AZ4ctor(b); // this is done automatically in C++ (and in Glib because of g_object_new)
Z1AZ14checkSomething(b);
Z1AZ7getFlagC(b);
return 0;
}
---------------------
Not in the example:
- As I said, C++ method pointers are really really weird, which is why C++ programmers avoid them usually and just hardcode the method calls (like C programmers do except for signals). Qt went out of their way to make them less-sucky by autogenerating code, this is called the Meta-Object compiler (MOC).
- Virtual functions

class A {
public:
A();
virtual void foo();
};

A::A() {
... your code
}

void A::foo() {
}

A a;
a.foo();

is C++-speak for:

struct A {
void (*Z1AZ3foo)(A* this);
};

void Z1AZ4ctor(A* this) {
this->Z1AZ3foo = Z1AZ3foo; // note that this is inserted into the actual constructor of the object where the new method is defined. This means that "foo" can still be NULL in below _even though_ it was defined and a method exists. Fun.
... your code.
}

void Z1AZ3foo(A* this) {
}

A a;
Z1AZ4ctor(&a);
a.Z1AZ3foo(&a); // NOT Z1AZ3foo(&a);

- C++ has exceptions. These are like setjmp() / longjmp(), but you can define automatic code blocks.
- C++ has templates which are like macros.
- the C++ macro language (templates etc) is (barely) turing complete while compiling, which means anything you could do at runtime you also can do at compiletime (note, nobody said it would look in any way readable :-) )
- C++ has namespaces which can be automatically prepended to your names. i.e.
using W = gtk_window;
W::new();

or whatever :-)

[vivainio]

And about the comment about memory management, Glib does reference counting memory management and the GObject system already is an object system. How does it get better than that? Does Qt do garbage collection? Add anything of value to the object system?

You rarely see GObject being considered better than something (/anything) else. Only small set of even Gtk+ programmers are willing to deal with it (and use PyGtk instead).

[dannym]

Well, I think the preference of PyGtk is because of Python.
Of course comparing Python and C&GObject, C&GObject loses. It's like comparing a modern train and a horse carriage.

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, ...)
Some mistakes they share, like automatically calling the superclass constructor at the beginning of the constructor of this class (as opposed to anywhere in it).
Some mistakes are very special to C++ and nobody would ever replicate:

#include <iostream>

class A {
public:
A();
virtual void foo();
};

class B : public A {
public:
virtual void foo();
};

void A::foo() {
std::cout << "How in the world did I get here?" << std::endl;
}

void B::foo() {
std::cout << "Hello world" << std::endl;
}

A::A() {
this->foo();
}

int main() {
B b;
return 0;
}

*runs it*
"How in the world did I get here?"
*shakes head*

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?

But as I said, with Qt and Boost, C++ is bearable.

[daperl]

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.

[vivainio]

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):



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++:


class HDPluginLoader
{
QObject* load(...)

...
};



I rest my case.

EDIT: ...and Qt metaobject system gives you the dynamic, introspective features you want.

[mikecomputing]

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]

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)

[vivainio]

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.

[daperl]

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?

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.

[thp]

MeeGo feature request: http://bugs.meego.com/show_bug.cgi?id=5977

(if you want to vote or subscribe there)

[TheBootroo]

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....

[vlg]

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 (http://www.telegraph-road.org/writings/gtkmm_vs_qt.html) 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 (http://www.linuxtoday.com/news_story.php3?ltsn=2000-09-05-001-21-OP-LF-KE)).

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.