Comment 1 Tommi Komulainen 2007-02-06 21:40:53 UTC

-> Guillem

Comment 2 Guillem Jover 2007-02-14 18:22:58 UTC

(In reply to comment #0)
> maemo-launcher does not install any headers. For  instance, there is no -dev
> debian package. This makes it impossible to implement new booster modules
> without adding them to maemo-launcher itself.

When I added support for the modular boosters I had that in mind, but there
was no need at that point, and didn't want to expose the API yet. I've a .pc
and debheleper dh_maemo-launcher that could be included as well.

Would you need this soon, or is this a general wish?

Actually, yes, it would be very helpful to me if that was committed soon. I'd
like to make a gtkmm booster for a customer.

Hi. Has that been committed already?

This does not seem to have been committed? Do you need a patch?

Created an attachment (id=191) [details]
Patch install headers and adds pkg-config file

With this patch the public headers (report.h and booster.h) are installed to
{includedir}/maemo-launcher-1.0/maemo-launcher and a pkg-config file
(maemo-launcher-1.0.pc) is installed in the pkg-config path.

Please tell if there is anything that needs to be changed or if I should also
add a -dev debian package.

Comment 7 Guillem Jover 2007-02-28 23:09:23 UTC

Hey guys,

Sorry for the delay, have been a bit busy lately.

(In reply to comment #6)
> Created an attachment (id=191) [details]
> Patch install headers and adds pkg-config file

Thanks for the patch, although it's a bit wrong. ;)
The .pc should not Require all those packages, those are specific to the
launcher no to the boosters. Anyway as I said I've .pc files around I'll
polish them tomorrow.

> With this patch the public headers (report.h and booster.h) are installed to
> {includedir}/maemo-launcher-1.0/maemo-launcher and a pkg-config file
> (maemo-launcher-1.0.pc) is installed in the pkg-config path.

Also I've been meaning to get rid of the report.h dependency from the
boosters, so that I can stop using -rdynamic on the launcher. And I'll have
to remove the booster_load_module from the header as I don't want to expose
that one.

> Please tell if there is anything that needs to be changed or if I should also
> add a -dev debian package.

It's a bit late now, so I'm heading home, but don't worry will take care of
the fixes and commit tomorrow.

> Also I've been meaning to get rid of the report.h dependency from the
> boosters, so that I can stop using -rdynamic on the launcher. And I'll have
> to remove the booster_load_module from the header as I don't want to expose
> that one.

Could you please keep booster_load_module? It could be very handy because as I
guess our gtkmm booster will be gtk booster + x and it would be nice if we could
load the gtk booster using booster_load_module and call its methods at the
beginning of our preinit/init/reload methods.

Comment 9 Guillem Jover 2007-03-02 00:19:35 UTC

(In reply to comment #8)
> > Also I've been meaning to get rid of the report.h dependency from the
> > boosters, so that I can stop using -rdynamic on the launcher. And I'll have
> > to remove the booster_load_module from the header as I don't want to expose
> > that one.
> 
> Could you please keep booster_load_module? It could be very handy because
> as I guess our gtkmm booster will be gtk booster + x and it would be nice
> if we could load the gtk booster using booster_load_module and call its
> methods at the beginning of our preinit/init/reload methods.

Ah right, long time since I've been messing with the launcher. At the time I 
thought about extending the support to be able to load several boosters, but
in that case that would not take into account dependencies, no big deal if you 
sort them properly like "--booster gtk,gtkmm" or similar.

Thinking twice about this, my main concern is about exposing any kind of API, 
as then supposedly I'll have to go through our API process, and that might take 
time (just sent a mail now for confirmation). Also I found a non-commited
patch I wrote to select making the boosters builtin.

Another possibility would be to merge back your changes, and then create a 
separete binary package with the gtkmm booster, what about that?

> Ah right, long time since I've been messing with the launcher. At the time I 
> thought about extending the support to be able to load several boosters, but
> in that case that would not take into account dependencies, no big deal if you 
> sort them properly like "--booster gtk,gtkmm" or similar.

That would be a clean solution of course! At least because we already plan to
have a gtkmm and a maemomm booster and both will depend on the gtk booster.

> 
> Thinking twice about this, my main concern is about exposing any kind of API, 
> as then supposedly I'll have to go through our API process, and that might take 
> time (just sent a mail now for confirmation). Also I found a non-commited
> patch I wrote to select making the boosters builtin.
> 
> Another possibility would be to merge back your changes, and then create a 
> separete binary package with the gtkmm booster, what about that?

Well, I don't know about you API process but we need the gtkmm booster without
too much delay. I already created a package (depends on the patch) with a simple
gtkmm booster which does just call the gtk booster in the moment. You can have a
look at the sources here:
https://garage.maemo.org/plugins/scmsvn/viewcvs.php/trunk/gtkmm-booster/?root=maemomm

I guess we can just duplicate the gtk booster initialization in our gtkmm
booster if necessary, if we can't have the API to call the gtk booster from our
gtkmm booster.

For me, that's far preferrable than being part of the actual maemo-launcher
module. That would make us dependent on Nokia's internal processes in future,
just in order to avoid one of their internal processes now. That sounds
ungrateful, but I think it's practical. Thanks.

Created an attachment (id=195) [details]
Patch to add multi-booster support

This patch adds support for multiple booster if they a pass them sorted (like
"gtk,gtkmm" to the --booster argument.

Tested against a full af-sb-init start without problems.

The patch also contains a stripped down package file and does only install the
booster.h header. You also can savely remove booster_module_load now.

Created an attachment (id=196) [details]
Fixes pkg-config file in patch above

Sorry, the .pc file still contained requirements which are wrong because it
should simply require nothing as meamo-launcher is only linked against glibc.

The rest of the patch has not changed.

Comment 14 Guillem Jover 2007-03-08 00:19:37 UTC

(In reply to comment #13)
> Created an attachment (id=196) [details]
> Fixes pkg-config file in patch above
> 
> Sorry, the .pc file still contained requirements which are wrong because it
> should simply require nothing as meamo-launcher is only linked against glibc.
> 
> The rest of the patch has not changed.

Hey, thanks again for the patch. Did some rewritting but it's now commited.
Tell me if everything is fine, and I'll poke again internally for the API
process thingy.

Thanks. Is this likely to get into the Maemo Bora release, or only into Bora+1?

Created an attachment (id=249) [details]
Add libdir to .pc file

Thanks for cleaning up the code. I have used glib for years so my plain C
knowledge is a bit limited.

This patch adds libdir to the pkg-config file which is necessary to install
additional launchers in the correct directory.

Comment 17 Guillem Jover 2007-03-08 19:38:34 UTC

(In reply to comment #16)
> Thanks for cleaning up the code. I have used glib for years so my plain C
> knowledge is a bit limited.

No problem.

> This patch adds libdir to the pkg-config file which is necessary to install
> additional launchers in the correct directory.

Yeah thanks, I've added the proper variable and the needed ones, and changed 
the includedir one as well.

I'm exporting the api as C, so you can remove that from your code. I've cleared 
with the guys here that we don't need to go through the api process, as long as 
anything from the release is using it. That does not mean I'm not going to 
handle it properly, I've been thinking to export the api version in the .pc 
file so that it could be checked from the configure.ac for compatibility.

Comment 18 Guillem Jover 2007-03-08 19:41:13 UTC

(In reply to comment #15)
> Thanks. Is this likely to get into the Maemo Bora release, or only into
> Bora+1?

Hmm I'll have to check with the sdk guys, I don't exactly know how to push 
updates to packages there. I'll post something when I get the info. For sardine 
I could ask Marius or Carlos to take the packages, but that will need the gtk 
2.10 fixes/workarounds and probably branching for now.

Comment 19 Carlos Guerreiro 2007-03-08 22:01:27 UTC

The SDK goes in sync with the product. It's just another configuration of the 
same software. There's no separate path. 
However, whatever goes in Sardine will end up in the next major release of 
Maemo in both the product and then SDK.
Guillem, you are the maintainer of maemo-lancher, so it's up to you what and 
when to push of maemo-launcher to sardine. You can get help in the sardine-
developers mailing list about how.
Right now, we are transitioning to the new gtk/hildon in sardine-experimental 
so for the future it's more useful to apply patches there.

> but that will need the gtk 2.10 fixes/workarounds

By the way, if you already have a patch for this somewhere, we'd be interested.
Otherwise, we will try to fix that.


Carlos. Thanks, yes, this could be much clearer with a module list such as GNOME
has, so we know what branches are used for what.

I have created a booster module that works with 2.10 but does not use the
Display hacks. At least it does no crash with gtk 2.10. You need SVN TRUNK of
maemo-launcher to compile it.

Have a look:
https://garage.maemo.org/plugins/scmsvn/viewcvs.php/trunk/gtk2.10.booster/?root=maemomm

(In reply to comment #21)
Wrong bug, sorry was meant for #952

When will the new maemo-launcher (0.22) be availible for bora?

I ask because we need at least version 0.22 to be able to create a working
gtkmm-boster package.

Thanks!

Could we please have a new package, or some timeline for a new package, so we
can deploy the gktmm booster?

Please? This is frustrating.

OK, so I'm giving up on seeing this in Bora.

But what package in maemo sardine/Chinook has this .pc file and the header?

Comment 27 Guillem Jover 2007-08-02 02:07:51 UTC

This has been fixed in 0.22-1.

Note to self: This is in the maemo-launcher-dev package.

maemo-launcher-dev does not seem to be in the chinook beta, though it is in
sardine.

Comment 30 Natalia Dobrovolskaya 2007-10-30 17:54:22 UTC

(In reply to comment #29)
> maemo-launcher-dev does not seem to be in the chinook beta, though it is in
> sardine.
> 
You are right! Good point! I will check it and try to fix.

maemo-launcher-dev is in the Maemo Chinook SDK. Thank you.

Comment 32 Andre Klapper 2008-12-06 13:19:13 UTC

(changing Version from "sardine" to "unspecified" for consistency with other
products)