Re: How to get a transparent GtkWindow (fremantle)
On Tue, 2009-11-10 at 16:15 +0100, ext Luca Donaggio wrote: > I thought it was somewhat related to transparency because doing this: > > gdk_window_reparent(win->window,gtk_widget_get_window(GTK_WIDGET > (mainwin)),300,200); > > makes the HildonAppMenu work again at the price of loosing the > transparency effect (modified code attached). Reparenting 'win->window' makes it a child of 'mainwin'. That is completely different ballgame than the original code, which keeps 'win- >window' a top-level window (child of the root). When the window is not top-level, it's not managed by the window manager anymore, but it could also cause something in Gtk/Hildon (at least I have checked all places deleting windows in hildon-desktop to no avail). -Kimmo > -- > Luca Donaggio > > 2009/11/10 Kimmo Hämäläinen > On Tue, 2009-11-10 at 14:12 +0100, ext Luca Donaggio wrote: > > Hi Kimmo, > > > > I'm sorry to bother you again, but the problem I'm facing is > not how > > to get a transparent window, but that if I create such a > window the > > HildonAppMenu of its parent HildonWindow doesn't show > anymore. > > I (slightly) modified your code to exemplify my situation. > > > Ah, yes, I can see it. Looks like the menu is unmapped > immediately when > it is shown. It's weird, I'm not yet sure what unmaps it... > Now it > looks like hildon-desktop is not unmapping it, so it could be > widget > side problem also. I'll try to find out. > > BTW. this problem is not related to the transparency: opaque > window does > the same. > > -Kimmo > > > > > > > > Thanks for your time, > > > > Luca Donaggio > > > > 2009/11/10 Kimmo Hämäläinen > > Hi, > > > > Sorry, took some time, I was busy with some bug > fixing... I > > started > > with the Home applet example and managed to whip up > a small > > example > > (attached) that shows a transparent pop-up window. > > > > -Kimmo > > > > > > > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Mapping the N900 keyboard?
Now that the N900 has been released, I will post this question on
maemo-developers, in the hopes that some Nokia devs can help me here.
I would like to know how to remap the keyboard on the N900. I've received
some help from Marius Gedminas, as you will see below, but I'd like to know
how to map the keyboard permanently, without having to run xkbcomp every
time.
Here is the help that I've received so far:
On Sun, Oct 25, 2009 at 4:23 AM, Marius Gedminas wrote:
>
> I've had partial success by doing this:
>
> $ xkbcomp :0 default.xkb
> $ vi default.xkb
>
> comment out the two rules that cause syntax errors:
>
> // interpret AccessX_Enable+AnyOfOrNone(all) {
> // action= LockControls(controls=);
> // };
>
> // interpret MouseKeys_Accel_Enable+AnyOfOrNone(all) {
> // action= LockControls(controls=);
> // };
>
> Now you can restore the settings back by running
>
> $ xkbcmp default.xkb :0
>
> if you screw up and end up with a nonfunctional keyboard.
>
> Next
>
> $ cp default.xkb mg.xkb
> $ vi mg.xkb
>
>key {
>type= "FOUR_LEVEL",
>symbols[Group1]= [ Right, Right, Tab, Tab ]
>};
>
> $ xkbcomp mg.xkb :0
>
> and now Fn+Right arrow is a Tab key.
>
> Sadly I don't know enough about xkbcomp to see if it's possible to make
> it load incomplete maps on top of the current configuration, just to
> update a few symbols without replicating the full configuration.
>
> > None of the changes I make to /usr/share/X11/xkb/symbols/nokia_vndr/rx-51
> > have any effect (yes I reboot after changing the file).
>
> Maybe the files in /var/cache/xkb contain precompiled versions of those?
>
> I'm not adventurous enough to go and start editing files in /usr/.
> Although creating a new symbols file in there and loading it on top of
> the defaults with setxkbmap ought to maybe work...
>
> Marius Gedminas
>
(I have already replied with the following:
Replace
type= "FOUR_LEVEL",
symbols[Group1]= [ Right, Right, Tab, Tab ]
with
type= "PC_FN_LEVEL2",
symbols[Group1]= [ Right, Tab ]
and you will retain the ability to highlight text with shift-right arrow.)
--
enthusiast, n. "One whose mind is wholly possessed and heated by what
engages it; one who is influenced by a peculiar fervor of mind; an ardent
and imaginative person."
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Retail FIASCO image for users of real operating systems
Any news on when tablets-dev might be updated for those of us without access to Windows XP installs? You know, most of us with pre-release devices. ;) http://tablets-dev.nokia.com/nokia_N900.php is 404 as of now. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Package does not end up in DIABLO extras-devel
Yes it compiled successfully. The log (https://garage.maemo.org/builder/diablo/eboard_1.0.3-9-maemo1/) says: [2009-11-10 11:10:13] Processing package eboard 1.0.3-9-maemo1. Uploader: bforsberg, builder: builder2 [2009-11-10 11:10:23] Building eboard 1.0.3-9-maemo1 for target 'maemo-diablo-armel-extras-devel' [2009-11-10 11:42:17] OK [2009-11-10 11:42:19] Building eboard 1.0.3-9-maemo1 for target 'maemo-diablo-i386-extras-devel' [2009-11-10 12:17:36] OK [2009-11-10 12:17:37] Signing build results [2009-11-10 12:17:38] eboard 1.0.3-9-maemo1 has been queued for loading into diablo extras-devel repository It says it has been queued. But I never see it in extras-devel. Bruce On Tue, Nov 10, 2009 at 11:31 AM, Frank Banul wrote: > You should have received an email from the Maemo Extras Builder, in it > there should be a link to the logs. > > https://garage.maemo.org/builder/diablo/ > > Frank > > On Tue, Nov 10, 2009 at 1:19 PM, Bruce Forsberg > wrote: >> I am working on porting eboard, which is in OS2007, to OS2008 DIABLO. >> I have got it to compile successfully with the autobuilder but the >> package never ends up in extras-devel. I have a Section: entry of >> user/games. Is there a log somewhere that I can look at to find what >> is wrong with my package so that I can fix it? >> >> Thanks, >> Bruce >> ___ >> maemo-developers mailing list >> maemo-developers@maemo.org >> https://lists.maemo.org/mailman/listinfo/maemo-developers >> > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Package does not end up in DIABLO extras-devel
You should have received an email from the Maemo Extras Builder, in it there should be a link to the logs. https://garage.maemo.org/builder/diablo/ Frank On Tue, Nov 10, 2009 at 1:19 PM, Bruce Forsberg wrote: > I am working on porting eboard, which is in OS2007, to OS2008 DIABLO. > I have got it to compile successfully with the autobuilder but the > package never ends up in extras-devel. I have a Section: entry of > user/games. Is there a log somewhere that I can look at to find what > is wrong with my package so that I can fix it? > > Thanks, > Bruce > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Package does not end up in DIABLO extras-devel
I am working on porting eboard, which is in OS2007, to OS2008 DIABLO. I have got it to compile successfully with the autobuilder but the package never ends up in extras-devel. I have a Section: entry of user/games. Is there a log somewhere that I can look at to find what is wrong with my package so that I can fix it? Thanks, Bruce ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to get n900 IMEI code in C
Here is a quick example I've posted up: http://talk.maemo.org/showpost.php?p=371496&postcount=45 Best Regards, Faheem On Tue, Nov 10, 2009 at 12:01 PM, ibrahim wrote: > greetings; > > I wonder if there is an API to get the n900 device IMEI code . I've been > searching for a long time with no result except for : > http://talk.maemo.org/showthread.php?t=34058 > which didn't give me sufficient information. > > Can anybody help??? > thanx alot > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PyMaemo (Python for Maemo) final release for Maemo 5 (Fremantle)
2009/11/10 Benoît HERVIER : > https://bugs.maemo.org/show_bug.cgi?id=5871 > > Is it fixed ? (i ll try :) At least two people tried but could not reproduce this bug on N900 (using the latest 0.10 package). Can you please try again and check if you are using the 0.10-1maemo1 version ? Thanks! -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Problems Panning/Clicking with GtkIconView
On Tue, 2009-11-10 at 09:08 -0800, Jonathan Blake wrote: > Hi Daniel, > > I'm using the PreFinal from http://maemovmware.garage.maemo.org/ - > Does that sound like it would be the cause of my problems? The PreFinal vmware image contains the Final Maemo SDK. So I guess the answer is no. Just a guess though... Conny ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Problems Panning/Clicking with GtkIconView
Hi Daniel,
I'm using the PreFinal from http://maemovmware.garage.maemo.org/ -
Does that sound like it would be the cause of my problems?
Cheers
Jon
On Tue, Nov 10, 2009 at 12:15 AM, daniel wilms wrote:
>
> Hi Jonathan,
>
> which VMWare image and SDK are you using? This was an issue in the Beta SDK
> and with the Final SDK it should work.
>
> Cheers Daniel
>
> ext Jonathan Blake wrote:
>>
>> Hi everyone,
>>
>> I am having a hell of a time trying to get an GtkIconView working correctly
>> with the pannable area widget. Using hildon.GtkIconView I am able to pan by
>> using the scrollwheel on my mouse, but if i click anywhere to start panning,
>> it immediately activates whatever was clicked on. gtk.IconView does pretty
>> much exactly the same thing. Removing the connect function obviously allows
>> you to pan freely.
>>
>> Code is as follows (I've left in various settings etc for completeness'
>> sake):
>>
>> pan_area = hildon.PannableArea()
>> model = gtk.ListStore(str, gtk.gdk.Pixbuf)
>>
>> for item in xmlf:
>> thumbnail_data = gtk.gdk.pixbuf_new_from_file(
>> cache_path_thumbs + item["filename"])
>> model.append([str(item['name']), thumbnail_data])
>> grid = hildon.GtkIconView(gtk.HILDON_UI_MODE_NORMAL, model)
>> grid.set_selection_mode(gtk.SELECTION_SINGLE)
>> grid.set_pixbuf_column(1)
>> grid.set_columns(4)
>> grid.set_item_width(190)
>> grid.set_spacing(thumbnail_spacing)
>> grid.connect('selection-changed', self.thumbnailSelect, model, window)
>> pan_area.add_with_viewport(grid)
>>
>>
>> Points of note: I'm using the Vmware SDK. I know that has a few bugs so
>> maybe this is one of them. As mentioned, the scrollwheel does pan the area,
>> so pannable area is working as intended.
>>
>> Does anyone have any ideas? this is a pretty critical issue and I don't know
>> of anyone else who's managed to get this working.
>>
>> What am I doing wrong?
>>
>> Thanks!
>
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PyMaemo (Python for Maemo) final release for Maemo 5 (Fremantle)
Le 10 novembre 2009 17:22, Anderson Lizardo a écrit : > 2009/11/10 Benoît HERVIER : >> "(such as some remaining documentation)" >> >> Oh no Please no >> >> Did you think it s possible to keep it in a separate package as for >> example there is still some python modules which has an interactive >> help() and it s really usefull for onboard developpers like me (i >> don't know if i not the only one :) ) > > I was referring specifically to the static documentation (HTML, PDF) > which have no need to be installed on the device. The built-in > documentation from the docstrings are still there, and would only be > removed if it can be proven they take considerable space. > > Unfortunately you will notice that, except for Python standard > modules, other PyMaemo bindings lack useful built-in documentation > accessible through help(). > > BTW, you might want to try ipython if you like to develop on the > device, helps a lot IMHO :) > > Regards, > -- > Anderson Lizardo > OpenBossa Labs - INdT > Manaus - Brazil https://bugs.maemo.org/show_bug.cgi?id=5871 Is it fixed ? (i ll try :) Yes i use it on my n810 :) -- Benoît HERVIER - http://khertan.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Optification (was Re: PyMaemo (Python for Maemo) final release for Maemo 5 (Fremantle))
On Tue, Nov 10, 2009 at 16:33, Anderson Lizardo wrote: > > Nice to hear that! We decided to leave out the optification for the > final release, just not to delay it even more. But now I believe we > can work on it as an update through extras-devel (I just hope that > that QA process will take any possible regressions with the new > packages we upload). Agreed. > Do you think it can be made a generic dh_* like tool that handles this > automatically? This way it could be called from debian/rules as e.g.: > > maemo-python-optify /usr/lib/python2.5 > > and the init scripts be generated automatically. What do you think? Could do. After a discussion on #maemo, it seems something might have to go in /etc/event.d and I tricked myself into thinking the mount happened at boot. > Did you do any kind of upgrade tests? I'm worried how that would work > if you are upgrading from an older non-optitified python installation. This should work as we're not replacing anything with a symlink (the big problem with upgrading an existing install). > I also suppose that this implicitly moves files from other packages to > /opt/python2.5 ? E.g. from python-hildon, python-gtk2 etc. ? There are two things we probably have to do: 1) Install /opt/python2.5/lib/... using dpkg. 2) Move anything left in /usr/lib/python2.5/ manually after install. Future installs of something like python-hildon will be into the bind mount, and so go to the right place automatically. maemo-optify will be updated to not touch anything which depends on Python if we do this, so Python libraries will continue to install into /usr/lib/python2.5/site-packages. It's just that this will now be on the eMMC. > What about the /usr/bin/python2.5 binary (which takes some MB) did you > move it to /opt too? No, I didn't try that. Do you think a symlink should work for that? Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Optification (was Re: PyMaemo (Python for Maemo) final release for Maemo 5 (Fremantle))
On Tue, Nov 10, 2009 at 12:11 PM, Andrew Flegg wrote: > On Tue, Nov 10, 2009 at 16:00, Anderson Lizardo > wrote: >> >> The PyMaemo team is pleased to announce the final release of PyMaemo >> for Maemo 5! > > BTW, I've tested with bind mounts and /opt. > [...] Nice to hear that! We decided to leave out the optification for the final release, just not to delay it even more. But now I believe we can work on it as an update through extras-devel (I just hope that that QA process will take any possible regressions with the new packages we upload). > I've done the following and it seems to work well: > > * Created /opt/python2.5/lib > * Moved the contents of /usr/lib/python2.5 to /opt/python2.5/lib > * Created an init script, symlinked to S20python-optify, which does > (on start): > > mount --bind /opt/python2.5/lib /usr/lib/python2.5 > > This freed up lots of space on the rootfs and does not seem to have > impacted start-up time of Python apps particularly noticably. > > I can share the startup/shutdown script and maybe even package this as > a "Python Optifier" if you want. Do you think it can be made a generic dh_* like tool that handles this automatically? This way it could be called from debian/rules as e.g.: maemo-python-optify /usr/lib/python2.5 and the init scripts be generated automatically. What do you think? > I think this is one of the best ways of optifying Python and without > any patches. I'd suggest this gets included in the next release of > PyMaemo. Did you do any kind of upgrade tests? I'm worried how that would work if you are upgrading from an older non-optitified python installation. I also suppose that this implicitly moves files from other packages to /opt/python2.5 ? E.g. from python-hildon, python-gtk2 etc. ? What about the /usr/bin/python2.5 binary (which takes some MB) did you move it to /opt too? Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PyMaemo (Python for Maemo) final release for Maemo 5 (Fremantle)
2009/11/10 Benoît HERVIER : > "(such as some remaining documentation)" > > Oh no Please no > > Did you think it s possible to keep it in a separate package as for > example there is still some python modules which has an interactive > help() and it s really usefull for onboard developpers like me (i > don't know if i not the only one :) ) I was referring specifically to the static documentation (HTML, PDF) which have no need to be installed on the device. The built-in documentation from the docstrings are still there, and would only be removed if it can be proven they take considerable space. Unfortunately you will notice that, except for Python standard modules, other PyMaemo bindings lack useful built-in documentation accessible through help(). BTW, you might want to try ipython if you like to develop on the device, helps a lot IMHO :) Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PyMaemo (Python for Maemo) final release for Maemo 5 (Fremantle)
Hi, 2009/11/10 Anderson Lizardo : > Hi, > > The PyMaemo team is pleased to announce the final release of PyMaemo > for Maemo 5! really thank you guys :) -- Andrea Grandi email: a.grandi [AT] gmail [DOT] com website: http://www.andreagrandi.it PGP Key: http://www.andreagrandi.it/pgp_key.asc ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: PyMaemo (Python for Maemo) final release for Maemo 5 (Fremantle)
And the most important : T H A N K S !!! Le 10 novembre 2009 17:11, Benoît HERVIER a écrit : > "(such as some remaining documentation)" > > Oh no Please no > > Did you think it s possible to keep it in a separate package as for > example there is still some python modules which has an interactive > help() and it s really usefull for onboard developpers like me (i > don't know if i not the only one :) ) > > Thanks > > 2009/11/10 Anderson Lizardo : >> Hi, >> >> The PyMaemo team is pleased to announce the final release of PyMaemo >> for Maemo 5! >> >> For users, no manual installation steps are necessary. If you want to >> enjoy Python on your tablet, simply install a Python application from >> the repository. >> >> For developers which want to try the latest versions of PyMaemo >> packages, make sure to add extras-devel repository to the Scratchbox >> target and/or tablet. For instructions, see >> http://pymaemo.garage.maemo.org/installation.html. Due to the auto >> promotion of dependencies in Fremantle, many packages have their >> latest versions in extras-testing/extras already, but some are still >> on extras-devel only. >> >> What is it? >> -- >> Python for Maemo (PyMaemo for short) main objective is to make >> possible to use Python programming language as the scripting and >> development language for Maemo Platform, providing a better >> alternative for fast prototyping and programming in Maemo environment >> besides the C programming language. >> >> Python is for serious programming and to have fun. Python has a nice >> syntax, it is easy to learn and powerful enough for a vast range of >> applications, this is why we choose Python for Maemo. >> >> What has changed? >> --- >> >> Removed packages: >> >> * libffi >> + Now installed by default on N900 >> >> * pyid3lib >> + Unmaintained upstream, not used by any package in Fremantle >> >> Updated packages: >> >> * pygobject 2.16.1-1maemo1 >> + Update to latest version from Ubuntu jaunty >> * pygtk 2.12.1-6maemo9 >> + Update gtk.Dialog with Maemo changes >> * python-hildondesktop 0.1.0-1maemo1 >> + Bump version due to (unavoidable) API changes. >> + Fix current maintainers in AUTHORS and debian/copyright. >> * python-setuptools 0.6c9-1maemo2 >> + make easy_install always be called with the default Python version >> (/usr/bin/pythonX.Y) >> * python-xml 0.8.4-10.1maemo4 >> + Integrate fixes for python2.6 (taken from Ubuntu jaunty) >> (NOTE: this is just a compatibility fix, Fremantle will only have python2.5) >> >> Bugs fixed: >> >> MB#5091, MB#5141, MB#5154, MB#5232, MB#5275, MB#5467 >> >> Known issues >> - >> >> python-mafw (Python bindings for MAFW) is still considered alpha >> quality, and there are a couple of known issues on it: >> MB#4824: python-mafw: source_browsing.py example does not work >> MB#4839: python-mafw: mafw.Registry lacks list_plugins() method >> MB#4849: python-mafw: MafwPluginDescriptorPublic structure is missing >> MB#4919: python-mafw: list of missing types to complete methods bindings >> MB#4932: python-mafw: mafw.Source.browse() method is missing >> MB#4934: python-mafw: MetaData class missing >> >> There are no bindings for GUPnP (MB#4829), libhildonmime (MB#5157), >> liblocation (MB#5748) as well for various other Maemo 5 components. We >> plan to work on providing bindings for these components during the >> Maemo 5 life cycle. >> >> The PyMaemo base set of packages take considerable storage space >> (MB#5364). We already started experiments with the "maemo-optify" tool >> to install biggest things out of root fs, and we also plan to reduce a >> plenty of storage usage by cutting unnecessary things (such as some >> remaining documentation). Expect next releases to reduce storage usage >> gradually. >> >> We will not migrate to python2.6 in Maemo 5 due to a (unresolved) bug >> (MB#4734), where a core SDK package explicitly conflicts with python >>>= 2.6, preventing any further upgrades from the 2.5.x series. >> >> This release is supposed to be compatible with previous releases. If >> you have any issues regarding building or running your Python >> application on Maemo 5, feel free to contact us (see below for how to >> contact the PyMaemo team and report bugs). >> >> Acknowledgments: >> - >> >> Thanks to everybody who helped making this release possible. >> >> Bug reports, as always, should go to our Bugzilla [1]. Use the >> pymaemo-developers mailing list [2] for help, feedback or suggestions. >> >> References >> -- >> [1] https://bugs.maemo.org/enter_bug.cgi?product=PyMaemo >> [2] https://garage.maemo.org/mailman/listinfo/pymaemo-developers >> >> Thanks, >> -- >> Anderson Lizardo >> OpenBossa Labs - INdT >> Manaus - Brazil >> ___ >> maemo-developers mailing list >> maemo-developers@maemo.org >> https://lists.maemo.org/mailman/listinfo/maemo-developers >> > > > > -- > Benoît HERVIER - http://khertan.net/ > -
Re: PyMaemo (Python for Maemo) final release for Maemo 5 (Fremantle)
"(such as some remaining documentation)" Oh no Please no Did you think it s possible to keep it in a separate package as for example there is still some python modules which has an interactive help() and it s really usefull for onboard developpers like me (i don't know if i not the only one :) ) Thanks 2009/11/10 Anderson Lizardo : > Hi, > > The PyMaemo team is pleased to announce the final release of PyMaemo > for Maemo 5! > > For users, no manual installation steps are necessary. If you want to > enjoy Python on your tablet, simply install a Python application from > the repository. > > For developers which want to try the latest versions of PyMaemo > packages, make sure to add extras-devel repository to the Scratchbox > target and/or tablet. For instructions, see > http://pymaemo.garage.maemo.org/installation.html. Due to the auto > promotion of dependencies in Fremantle, many packages have their > latest versions in extras-testing/extras already, but some are still > on extras-devel only. > > What is it? > -- > Python for Maemo (PyMaemo for short) main objective is to make > possible to use Python programming language as the scripting and > development language for Maemo Platform, providing a better > alternative for fast prototyping and programming in Maemo environment > besides the C programming language. > > Python is for serious programming and to have fun. Python has a nice > syntax, it is easy to learn and powerful enough for a vast range of > applications, this is why we choose Python for Maemo. > > What has changed? > --- > > Removed packages: > > * libffi > + Now installed by default on N900 > > * pyid3lib > + Unmaintained upstream, not used by any package in Fremantle > > Updated packages: > > * pygobject 2.16.1-1maemo1 > + Update to latest version from Ubuntu jaunty > * pygtk 2.12.1-6maemo9 > + Update gtk.Dialog with Maemo changes > * python-hildondesktop 0.1.0-1maemo1 > + Bump version due to (unavoidable) API changes. > + Fix current maintainers in AUTHORS and debian/copyright. > * python-setuptools 0.6c9-1maemo2 > + make easy_install always be called with the default Python version > (/usr/bin/pythonX.Y) > * python-xml 0.8.4-10.1maemo4 > + Integrate fixes for python2.6 (taken from Ubuntu jaunty) > (NOTE: this is just a compatibility fix, Fremantle will only have python2.5) > > Bugs fixed: > > MB#5091, MB#5141, MB#5154, MB#5232, MB#5275, MB#5467 > > Known issues > - > > python-mafw (Python bindings for MAFW) is still considered alpha > quality, and there are a couple of known issues on it: > MB#4824: python-mafw: source_browsing.py example does not work > MB#4839: python-mafw: mafw.Registry lacks list_plugins() method > MB#4849: python-mafw: MafwPluginDescriptorPublic structure is missing > MB#4919: python-mafw: list of missing types to complete methods bindings > MB#4932: python-mafw: mafw.Source.browse() method is missing > MB#4934: python-mafw: MetaData class missing > > There are no bindings for GUPnP (MB#4829), libhildonmime (MB#5157), > liblocation (MB#5748) as well for various other Maemo 5 components. We > plan to work on providing bindings for these components during the > Maemo 5 life cycle. > > The PyMaemo base set of packages take considerable storage space > (MB#5364). We already started experiments with the "maemo-optify" tool > to install biggest things out of root fs, and we also plan to reduce a > plenty of storage usage by cutting unnecessary things (such as some > remaining documentation). Expect next releases to reduce storage usage > gradually. > > We will not migrate to python2.6 in Maemo 5 due to a (unresolved) bug > (MB#4734), where a core SDK package explicitly conflicts with python >>= 2.6, preventing any further upgrades from the 2.5.x series. > > This release is supposed to be compatible with previous releases. If > you have any issues regarding building or running your Python > application on Maemo 5, feel free to contact us (see below for how to > contact the PyMaemo team and report bugs). > > Acknowledgments: > - > > Thanks to everybody who helped making this release possible. > > Bug reports, as always, should go to our Bugzilla [1]. Use the > pymaemo-developers mailing list [2] for help, feedback or suggestions. > > References > -- > [1] https://bugs.maemo.org/enter_bug.cgi?product=PyMaemo > [2] https://garage.maemo.org/mailman/listinfo/pymaemo-developers > > Thanks, > -- > Anderson Lizardo > OpenBossa Labs - INdT > Manaus - Brazil > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > -- Benoît HERVIER - http://khertan.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Optification (was Re: PyMaemo (Python for Maemo) final release for Maemo 5 (Fremantle))
On Tue, Nov 10, 2009 at 16:00, Anderson Lizardo wrote: > > The PyMaemo team is pleased to announce the final release of PyMaemo > for Maemo 5! BTW, I've tested with bind mounts and /opt. I've done the following and it seems to work well: * Created /opt/python2.5/lib * Moved the contents of /usr/lib/python2.5 to /opt/python2.5/lib * Created an init script, symlinked to S20python-optify, which does (on start): mount --bind /opt/python2.5/lib /usr/lib/python2.5 This freed up lots of space on the rootfs and does not seem to have impacted start-up time of Python apps particularly noticably. I can share the startup/shutdown script and maybe even package this as a "Python Optifier" if you want. I think this is one of the best ways of optifying Python and without any patches. I'd suggest this gets included in the next release of PyMaemo. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
PyMaemo (Python for Maemo) final release for Maemo 5 (Fremantle)
Hi, The PyMaemo team is pleased to announce the final release of PyMaemo for Maemo 5! For users, no manual installation steps are necessary. If you want to enjoy Python on your tablet, simply install a Python application from the repository. For developers which want to try the latest versions of PyMaemo packages, make sure to add extras-devel repository to the Scratchbox target and/or tablet. For instructions, see http://pymaemo.garage.maemo.org/installation.html. Due to the auto promotion of dependencies in Fremantle, many packages have their latest versions in extras-testing/extras already, but some are still on extras-devel only. What is it? -- Python for Maemo (PyMaemo for short) main objective is to make possible to use Python programming language as the scripting and development language for Maemo Platform, providing a better alternative for fast prototyping and programming in Maemo environment besides the C programming language. Python is for serious programming and to have fun. Python has a nice syntax, it is easy to learn and powerful enough for a vast range of applications, this is why we choose Python for Maemo. What has changed? --- Removed packages: * libffi + Now installed by default on N900 * pyid3lib + Unmaintained upstream, not used by any package in Fremantle Updated packages: * pygobject 2.16.1-1maemo1 + Update to latest version from Ubuntu jaunty * pygtk 2.12.1-6maemo9 + Update gtk.Dialog with Maemo changes * python-hildondesktop 0.1.0-1maemo1 + Bump version due to (unavoidable) API changes. + Fix current maintainers in AUTHORS and debian/copyright. * python-setuptools 0.6c9-1maemo2 + make easy_install always be called with the default Python version (/usr/bin/pythonX.Y) * python-xml 0.8.4-10.1maemo4 + Integrate fixes for python2.6 (taken from Ubuntu jaunty) (NOTE: this is just a compatibility fix, Fremantle will only have python2.5) Bugs fixed: MB#5091, MB#5141, MB#5154, MB#5232, MB#5275, MB#5467 Known issues - python-mafw (Python bindings for MAFW) is still considered alpha quality, and there are a couple of known issues on it: MB#4824: python-mafw: source_browsing.py example does not work MB#4839: python-mafw: mafw.Registry lacks list_plugins() method MB#4849: python-mafw: MafwPluginDescriptorPublic structure is missing MB#4919: python-mafw: list of missing types to complete methods bindings MB#4932: python-mafw: mafw.Source.browse() method is missing MB#4934: python-mafw: MetaData class missing There are no bindings for GUPnP (MB#4829), libhildonmime (MB#5157), liblocation (MB#5748) as well for various other Maemo 5 components. We plan to work on providing bindings for these components during the Maemo 5 life cycle. The PyMaemo base set of packages take considerable storage space (MB#5364). We already started experiments with the "maemo-optify" tool to install biggest things out of root fs, and we also plan to reduce a plenty of storage usage by cutting unnecessary things (such as some remaining documentation). Expect next releases to reduce storage usage gradually. We will not migrate to python2.6 in Maemo 5 due to a (unresolved) bug (MB#4734), where a core SDK package explicitly conflicts with python >= 2.6, preventing any further upgrades from the 2.5.x series. This release is supposed to be compatible with previous releases. If you have any issues regarding building or running your Python application on Maemo 5, feel free to contact us (see below for how to contact the PyMaemo team and report bugs). Acknowledgments: - Thanks to everybody who helped making this release possible. Bug reports, as always, should go to our Bugzilla [1]. Use the pymaemo-developers mailing list [2] for help, feedback or suggestions. References -- [1] https://bugs.maemo.org/enter_bug.cgi?product=PyMaemo [2] https://garage.maemo.org/mailman/listinfo/pymaemo-developers Thanks, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Geocoding library for Fremantle?
Hi all, I'm looking for a geocoding library to run on the N900. I want to take the location string attached to those N900 using online contacts who provide it, and plot that on a map (Emerillon). Of course having to parse the message string and then do the geocoding is rather wasteful (of CPU, network traffic and accuracy) and it would be vastly more efficient and useful to just have a contact contain the raw lat/lon/accuracy data, but we've got to work with what we've got. GeoClue offers a geocoding api, but as we use liblocation rather than GeoClue, and as I remember someone saying at the summit (in the presentation on location stuff) that there would be an api to do (reverse)geocoding, I was just wondering if this is indeed the case and when we might see such a thing? Named libaddress perhaps? Thanks, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to get a transparent GtkWindow (fremantle)
I thought it was somewhat related to transparency because doing this:
gdk_window_reparent(win->window,gtk_widget_get_window(GTK_WIDGET
(mainwin)),300,200);
makes the HildonAppMenu work again at the price of loosing the transparency
effect (modified code attached).
--
Luca Donaggio
2009/11/10 Kimmo Hämäläinen
> On Tue, 2009-11-10 at 14:12 +0100, ext Luca Donaggio wrote:
> > Hi Kimmo,
> >
> > I'm sorry to bother you again, but the problem I'm facing is not how
> > to get a transparent window, but that if I create such a window the
> > HildonAppMenu of its parent HildonWindow doesn't show anymore.
> > I (slightly) modified your code to exemplify my situation.
>
> Ah, yes, I can see it. Looks like the menu is unmapped immediately when
> it is shown. It's weird, I'm not yet sure what unmaps it... Now it
> looks like hildon-desktop is not unmapping it, so it could be widget
> side problem also. I'll try to find out.
>
> BTW. this problem is not related to the transparency: opaque window does
> the same.
>
> -Kimmo
>
> >
> >
> > Thanks for your time,
> >
> > Luca Donaggio
> >
> > 2009/11/10 Kimmo Hämäläinen
> > Hi,
> >
> > Sorry, took some time, I was busy with some bug fixing... I
> > started
> > with the Home applet example and managed to whip up a small
> > example
> > (attached) that shows a transparent pop-up window.
> >
> > -Kimmo
> >
> >
>
>
/*
gcc -Wall `pkg-config gtk+-2.0 hildon-1 --cflags --libs` rgba-window-example-1.c -o rgba-window-example-1
*/
#include
#include
static gboolean
handle_expose (GtkWidget *widget, GdkEventExpose *event)
{
cairo_t *cr;
/* Create cairo context */
cr = gdk_cairo_create (GDK_DRAWABLE (widget->window));
gdk_cairo_region (cr, event->region);
cairo_clip (cr);
/* Draw alpha background */
cairo_set_operator (cr, CAIRO_OPERATOR_SOURCE);
cairo_set_source_rgba (cr, 0.5, 0.5, 0.5, 0.5);
cairo_paint (cr);
/* Free context */
cairo_destroy (cr);
return FALSE;
}
int main ()
{
HildonProgram *prog;
HildonWindow *mainwin;
GtkWidget *win, *label1, *label2;
GdkScreen *screen;
HildonAppMenu *menu;
GtkWidget *button;
hildon_gtk_init (NULL, NULL);
prog = HILDON_PROGRAM (hildon_program_get_instance ());
mainwin = HILDON_WINDOW (hildon_window_new ());
hildon_program_add_window (prog, mainwin);
menu = HILDON_APP_MENU (hildon_app_menu_new ());
button = gtk_button_new_with_label ("Quit");
g_signal_connect_after (button, "clicked", G_CALLBACK (gtk_main_quit), NULL);
hildon_app_menu_append (menu, GTK_BUTTON (button));
gtk_widget_show_all (GTK_WIDGET (menu));
hildon_window_set_app_menu (mainwin, menu);
label2 = gtk_label_new ("This is the main Hildon window\nThis is the main Hildon window\nThis is the main Hildon window\nThis is the main Hildon window");
gtk_container_add (GTK_CONTAINER (mainwin), label2);
gtk_widget_show_all (GTK_WIDGET (mainwin));
win = gtk_window_new (GTK_WINDOW_POPUP);
screen = gtk_widget_get_screen (win);
gtk_widget_set_colormap (win, gdk_screen_get_rgba_colormap (screen));
gtk_widget_set_app_paintable (win, TRUE);
gtk_widget_realize (win);
gdk_window_set_back_pixmap (win->window, NULL, FALSE);
gtk_window_set_transient_for (GTK_WINDOW (win), GTK_WINDOW (mainwin));
gtk_window_set_destroy_with_parent (GTK_WINDOW (win), TRUE);
gdk_window_reparent(win->window,gtk_widget_get_window(GTK_WIDGET (mainwin)),300,200);
gtk_window_move (GTK_WINDOW (win), 300, 200);
label1 = gtk_label_new ("This is an RGBA window");
gtk_container_add (GTK_CONTAINER (win), label1);
gtk_widget_show_all (win);
g_signal_connect (win, "expose-event", G_CALLBACK (handle_expose), win);
gtk_main ();
return 0;
}
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to get a transparent GtkWindow (fremantle)
On Tue, 2009-11-10 at 14:12 +0100, ext Luca Donaggio wrote: > Hi Kimmo, > > I'm sorry to bother you again, but the problem I'm facing is not how > to get a transparent window, but that if I create such a window the > HildonAppMenu of its parent HildonWindow doesn't show anymore. > I (slightly) modified your code to exemplify my situation. Ah, yes, I can see it. Looks like the menu is unmapped immediately when it is shown. It's weird, I'm not yet sure what unmaps it... Now it looks like hildon-desktop is not unmapping it, so it could be widget side problem also. I'll try to find out. BTW. this problem is not related to the transparency: opaque window does the same. -Kimmo > > > Thanks for your time, > > Luca Donaggio > > 2009/11/10 Kimmo Hämäläinen > Hi, > > Sorry, took some time, I was busy with some bug fixing... I > started > with the Home applet example and managed to whip up a small > example > (attached) that shows a transparent pop-up window. > > -Kimmo > > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: debhelper-maemo-package-icons
On Tue, Nov 10, 2009 at 13:50, Gabriel Schulhof wrote: > > I, for one, will stick to 26x26, because older version of Hildon > Application Manager do not work with higher rez icons, and I don't want > yet another reason to split my source package along distro lines. AIUI, Diablo and Chinook HAM's both work fine with 48x48 icons (they scale down); whereas none of them will scale up. If you want a single icon size, make it 48px square as this won't look silly in Fremantle and will look acceptable on earlier releases. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: debhelper-maemo-package-icons
Hey! On Tue, November 10, 2009 14:59, Marius Vollmer wrote: > ext David King writes: >> You mean 48x48 pixels, right? >> http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging%2C_Deploying_and_Distributing#Icons > > Ouch, somebody needs to be tickled to death for this. (Maybe me for not > catching this earlier.) Assuming that person is ticklish ... > Why do people think the field is named Maemo-Icon-26. Twenty-six. > Rings a bell? Hmm? Like, 26x26 pixels? Could there be a connection? > > Anyway, trying to fix this seems to be moot. Christ. Kids these days. *sigh* ... what can you do. Anyway, you can take any file and call it debian/package-name.png and it will uuencode it and it will append it to the debian/control section named Package: package-name ... No file type/pixel size checks are performed on the debian/package-name.png file. I, for one, will stick to 26x26, because older version of Hildon Application Manager do not work with higher rez icons, and I don't want yet another reason to split my source package along distro lines. As for why we chose an odd size like 26x26 to begin with, instead of 24x24 or 32x32, I will never understand. But that is a story for another time ... Gabriel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-release
On Tue, Nov 10, 2009 at 9:16 AM, Frantisek Dufka wrote: > But still it could be useful to set different compiler flags for arm > (vfp, thumb mode) [...] For that I think the standard way is to use dpkg-architecture in debian/rules, e.g.: HOST = $(shell dpkg-architecture -qDEB_HOST_ARCH) ... ifeq ($(HOST),armel) # some ARM specific commands go here endif > [...] or workaround some stuff not available in stratchbox > environment. I see some packages checking for scratchbox environment by looking for presence of "/targets/links/scratchbox.config". This file is only available when you are inside a scratchbox target. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-release
Mikko Vartiainen wrote: >> How can I differentiate between arm and x86 builds? Example - x86 may >> use vorbis package but arm can use tremor so Build-Depends: can be >> different for x86 vs ARM. arm may also benefit from arm specific >> compiler flags. How can I solve that? > > > I'm not sure why would you want to do that in maemo context. Well, yes, my example was vorbis vs tremor but true that tremor/libivorbisdec is in x86 target too so I can use tremor in both. I don't have any other real world example. But still it could be useful to set different compiler flags for arm (vfp, thumb mode) or workaround some stuff not available in stratchbox environment. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to get a transparent GtkWindow (fremantle)
Hi Kimmo,
I'm sorry to bother you again, but the problem I'm facing is not how to get
a transparent window, but that if I create such a window the HildonAppMenu
of its parent HildonWindow doesn't show anymore.
I (slightly) modified your code to exemplify my situation.
Thanks for your time,
Luca Donaggio
2009/11/10 Kimmo Hämäläinen
> Hi,
>
> Sorry, took some time, I was busy with some bug fixing... I started
> with the Home applet example and managed to whip up a small example
> (attached) that shows a transparent pop-up window.
>
> -Kimmo
>
>
/*
gcc -Wall `pkg-config gtk+-2.0 hildon-1 --cflags --libs` rgba-window-example-1.c -o rgba-window-example-1
*/
#include
#include
static gboolean
handle_expose (GtkWidget *widget, GdkEventExpose *event)
{
cairo_t *cr;
/* Create cairo context */
cr = gdk_cairo_create (GDK_DRAWABLE (widget->window));
gdk_cairo_region (cr, event->region);
cairo_clip (cr);
/* Draw alpha background */
cairo_set_operator (cr, CAIRO_OPERATOR_SOURCE);
cairo_set_source_rgba (cr, 0.5, 0.5, 0.5, 0.5);
cairo_paint (cr);
/* Free context */
cairo_destroy (cr);
return FALSE;
}
int main ()
{
HildonProgram *prog;
HildonWindow *mainwin;
GtkWidget *win, *label1, *label2;
GdkScreen *screen;
HildonAppMenu *menu;
GtkWidget *button;
hildon_gtk_init (NULL, NULL);
prog = HILDON_PROGRAM (hildon_program_get_instance ());
mainwin = HILDON_WINDOW (hildon_window_new ());
hildon_program_add_window (prog, mainwin);
menu = HILDON_APP_MENU (hildon_app_menu_new ());
button = gtk_button_new_with_label ("Quit");
g_signal_connect_after (button, "clicked", G_CALLBACK (gtk_main_quit), NULL);
hildon_app_menu_append (menu, GTK_BUTTON (button));
gtk_widget_show_all (GTK_WIDGET (menu));
hildon_window_set_app_menu (mainwin, menu);
label2 = gtk_label_new ("This is the main Hildon window\nThis is the main Hildon window\nThis is the main Hildon window\nThis is the main Hildon window");
gtk_container_add (GTK_CONTAINER (mainwin), label2);
gtk_widget_show_all (GTK_WIDGET (mainwin));
win = gtk_window_new (GTK_WINDOW_POPUP);
screen = gtk_widget_get_screen (win);
gtk_widget_set_colormap (win, gdk_screen_get_rgba_colormap (screen));
gtk_widget_set_app_paintable (win, TRUE);
gtk_widget_realize (win);
gdk_window_set_back_pixmap (win->window, NULL, FALSE);
gtk_window_set_transient_for (GTK_WINDOW (win), GTK_WINDOW (mainwin));
gtk_window_set_destroy_with_parent (GTK_WINDOW (win), TRUE);
gtk_window_move (GTK_WINDOW (win), 300, 200);
label1 = gtk_label_new ("This is an RGBA window");
gtk_container_add (GTK_CONTAINER (win), label1);
gtk_widget_show_all (win);
g_signal_connect (win, "expose-event", G_CALLBACK (handle_expose), win);
gtk_main ();
return 0;
}
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: debhelper-maemo-package-icons
ext David King writes: > You mean 48x48 pixels, right? > > http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging%2C_Deploying_and_Distributing#Icons Ouch, somebody needs to be tickled to death for this. (Maybe me for not catching this earlier.) Why do people think the field is named Maemo-Icon-26. Twenty-six. Rings a bell? Hmm? Like, 26x26 pixels? Could there be a connection? Anyway, trying to fix this seems to be moot. Christ. Kids these days. :-( ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-release
> How can I differentiate between arm and x86 builds? Example - x86 may > use vorbis package but arm can use tremor so Build-Depends: can be > different for x86 vs ARM. arm may also benefit from arm specific > compiler flags. How can I solve that? I'm not sure why would you want to do that in maemo context. You should be able to define architecture specific depencies this way "Build-Depends: package-name [armel], package2 [!armel]". Haven't actually tested it, but I think it should work. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: debhelper-maemo-package-icons
Hi, On Tue, Nov 10, 2009 at 12:30 PM, Gabriel Schulhof wrote: > Hey! > > On Tue, November 10, 2009 13:49, Aniello Del Sorbo wrote: > > This means we should remove our manually added XB-Maemo-Icon-26 line > > from our control file and let this > > command do the job for us ? > > Using this package is completely optional. I like it, because I don't have > to do this manually. With this helper, the package icon is not located in > two places (introducing the potential of being out-of-sync): in a file, > /and/ in a control file field. > > > Where does it expect the .png file to be? > > If you have an icon debian/package-name.png, then > package-name_version_arch.deb will have the icon. the helper assumes that > debian/package-name.png is a 26x26 PNG file. > What about Maemo5 packages ? These should use a 48x48 PNG file[1]. [1] - http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging%2C_Deploying_and_Distributing#Icons Best regards, -- Valério Valério http://www.valeriovalerio.org > HTH, > > > > Gabriel > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: autobuilder oddity
On Nov 8, 2009, at 20:20, Andrea Borgia wrote: > Hi, all. > > I just submitted a minor change to my openvpn package and I got a > strange message in the reply: > > -cut-cut- > [2009-11-08 21:04:58] ERROR running /etc/buildme.d/check_build: > Fatal error: Call to undefined method stdClass::update() in > /usr/local/bin/packages/package-buildlog-parse.php on line 461 > -cut-cut- > (full text: > https://garage.maemo.org/builder/fremantle/openvpn_2.1~rc20-3maemo1/summary.log > > ) > > Any clues about the cause? The previous builds had no such message. It looks like a php library problem. I can see if I can dig out some more info. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: debhelper-maemo-package-icons
On 2009-11-10 14:30, Gabriel Schulhof wrote: >On Tue, November 10, 2009 13:49, Aniello Del Sorbo wrote: >> Where does it expect the .png file to be? > >If you have an icon debian/package-name.png, then >package-name_version_arch.deb will have the icon. the helper assumes that >debian/package-name.png is a 26x26 PNG file. You mean 48x48 pixels, right? http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging%2C_Deploying_and_Distributing#Icons -- David King | http://amigadave.blogspot.com/ | dav...@openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: debhelper-maemo-package-icons
Hey! On Tue, November 10, 2009 14:28, Jeremiah Foster wrote: > Is there a public code repo so people can download and integrate this? Ummm ... I haven't really thought beyond apt-get source debhelper-maemo-package-icon. I mean, it's a tiny package. Cheers, Gabriel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
On Nov 4, 2009, at 8:29, Andrew Flegg wrote: > Jeremiah wrote: >> >> On Nov 3, 2009, at 19:25, Tim Teulings wrote: >> >>> P.S.: Don't trust my version numbers! Trust my checkbox choice! >> >> That is totally fine with me. I thought a version number was less >> intrusive, developers didn't have to do anything, just remember which >> part of their version to change. But as version numbers are so >> invariant an excellent argument against this has been presented. > > Agreed. It seemed like a nice hack, but isn't going to work in > practice. > >> Shall we put a checkbox by the package promotion page, or somewhere >> where we remember, which keeps all accrued karma? > > That's probably a good first step, however I wonder if long term > something like Marius suggested might be better: remaining karma for > an app is... > > * proportional to current app karma > * proportional to developer's karma > * proportional to testers' karma > * inversely proportional to the time between > last build and this build. > > This'd mean that if I released an app and had it voted up by Ryan, > Tim, Daniel, Quim and a few others on the first karma page; and I > released a new version the next day (short time => probable bug > fix); my app might only lose one or two points. > > Maybe this works for time too (or vote by high roller reduces time?) > Or maybe it's just too complicated? This is cool, and I think it could be done, but the karma calculation algos are starting to be a little complicated. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: debhelper-maemo-package-icons
Hey! On Tue, November 10, 2009 13:49, Aniello Del Sorbo wrote: > This means we should remove our manually added XB-Maemo-Icon-26 line > from our control file and let this > command do the job for us ? Using this package is completely optional. I like it, because I don't have to do this manually. With this helper, the package icon is not located in two places (introducing the potential of being out-of-sync): in a file, /and/ in a control file field. > Where does it expect the .png file to be? If you have an icon debian/package-name.png, then package-name_version_arch.deb will have the icon. the helper assumes that debian/package-name.png is a 26x26 PNG file. HTH, Gabriel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: debhelper-maemo-package-icons
Is there a public code repo so people can download and integrate this? Jeremiah On Nov 10, 2009, at 12:49, Aniello Del Sorbo wrote: > This means we should remove our manually added XB-Maemo-Icon-26 line > from our control file and let this > command do the job for us ? > > Where does it expect the .png file to be? > > Aniello > > 2009/11/10 Gabriel Schulhof : >> Hey, all! >> >> Let's hope this package doesn't duplicate some functionality too >> (like >> maemo-release did ... *scratch head*). So, here's the scoop.: >> >> debhelper-maemo-package-icons adds the command >> dh_maemo_package_icons, >> which you can use in the binary-arch section of debian/rules. You >> should >> add it right at the top of the section, and add it again with -r at >> the >> bottom of the section, like this: >> >> ... >> binary-arch: >>dh_maemo_package_icons >>... >> >>... >>dh_maemo_package_icons -r >> >> some-other-target: >> ... >> >> This will add a XB-Maemo-Icon-26: line to all >> control >> file sections where an icon file whose name is the same as that of >> the >> package mentioned in the section is found. >> >> Later, after the packages are built, running dh_maemo_package_icons >> -r >> will remove these lines to restore the control file. >> >> This package has actually been present for quite a while now, and >> I've >> used it for Pidgin's packages, but I never really announced it as >> such. >> >> HTH, >> >> >> >> Gabriel >> ___ >> maemo-developers mailing list >> maemo-developers@maemo.org >> https://lists.maemo.org/mailman/listinfo/maemo-developers >> > > > > -- > anidel > Sent from London, Eng, United Kingdom > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-release
On Nov 10, 2009, at 13:17, Frantisek Dufka wrote: > Gabriel Schulhof wrote: >> I suppose I should've asked around some more. > > We can still have interesting discussion now :-) > > Actually I am not sure if maemo-version solves every problem > maemo-release wanted to solve or developers need to solve to have same > package for more SDK versions. > > maemo-version/maemo-release can solve different Build-Depends: fields > > maemo version provides also /etc/maemo_version so one can check it in > /debian/rules when building the package and act differently (include > different files, define different variables) > > What else is needed? Can we change the name of the package? I know that is PITA, but you risk running afoul of Nokia if your package name begins with maemo, trademark and all that. Can you just swap it around to version-maemo? Maybe it is just enough to keep in mind that there may be potential naming conflicts in the future and leave the name as it is. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-release
Gabriel Schulhof wrote: > I suppose I should've asked around some more. We can still have interesting discussion now :-) Actually I am not sure if maemo-version solves every problem maemo-release wanted to solve or developers need to solve to have same package for more SDK versions. maemo-version/maemo-release can solve different Build-Depends: fields maemo version provides also /etc/maemo_version so one can check it in /debian/rules when building the package and act differently (include different files, define different variables) What else is needed? How can I differentiate between arm and x86 builds? Example - x86 may use vorbis package but arm can use tremor so Build-Depends: can be different for x86 vs ARM. arm may also benefit from arm specific compiler flags. How can I solve that? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
How to get n900 IMEI code in C
greetings; I wonder if there is an API to get the n900 device IMEI code . I've been searching for a long time with no result except for : http://talk.maemo.org/showthread.php?t=34058 which didn't give me sufficient information. Can anybody help??? thanx alot ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: debhelper-maemo-package-icons
This means we should remove our manually added XB-Maemo-Icon-26 line from our control file and let this command do the job for us ? Where does it expect the .png file to be? Aniello 2009/11/10 Gabriel Schulhof : > Hey, all! > > Let's hope this package doesn't duplicate some functionality too (like > maemo-release did ... *scratch head*). So, here's the scoop.: > > debhelper-maemo-package-icons adds the command dh_maemo_package_icons, > which you can use in the binary-arch section of debian/rules. You should > add it right at the top of the section, and add it again with -r at the > bottom of the section, like this: > > ... > binary-arch: > dh_maemo_package_icons > ... > > ... > dh_maemo_package_icons -r > > some-other-target: > ... > > This will add a XB-Maemo-Icon-26: line to all control > file sections where an icon file whose name is the same as that of the > package mentioned in the section is found. > > Later, after the packages are built, running dh_maemo_package_icons -r > will remove these lines to restore the control file. > > This package has actually been present for quite a while now, and I've > used it for Pidgin's packages, but I never really announced it as such. > > HTH, > > > > Gabriel > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > -- anidel Sent from London, Eng, United Kingdom ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
debhelper-maemo-package-icons
Hey, all! Let's hope this package doesn't duplicate some functionality too (like maemo-release did ... *scratch head*). So, here's the scoop.: debhelper-maemo-package-icons adds the command dh_maemo_package_icons, which you can use in the binary-arch section of debian/rules. You should add it right at the top of the section, and add it again with -r at the bottom of the section, like this: ... binary-arch: dh_maemo_package_icons ... ... dh_maemo_package_icons -r some-other-target: ... This will add a XB-Maemo-Icon-26: line to all control file sections where an icon file whose name is the same as that of the package mentioned in the section is found. Later, after the packages are built, running dh_maemo_package_icons -r will remove these lines to restore the control file. This package has actually been present for quite a while now, and I've used it for Pidgin's packages, but I never really announced it as such. HTH, Gabriel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to get a transparent GtkWindow (fremantle)
Hi,
Sorry, took some time, I was busy with some bug fixing... I started
with the Home applet example and managed to whip up a small example
(attached) that shows a transparent pop-up window.
-Kimmo
/*
gcc -Wall `pkg-config gtk+-2.0 --cflags --libs` rgba-window-example.c -o rgba-window-example
*/
#include
static gboolean
handle_expose (GtkWidget *widget, GdkEventExpose *event)
{
cairo_t *cr;
/* Create cairo context */
cr = gdk_cairo_create (GDK_DRAWABLE (widget->window));
gdk_cairo_region (cr, event->region);
cairo_clip (cr);
/* Draw alpha background */
cairo_set_operator (cr, CAIRO_OPERATOR_SOURCE);
cairo_set_source_rgba (cr, 0.5, 0.5, 0.5, 0.5);
cairo_paint (cr);
/* Free context */
cairo_destroy (cr);
return FALSE;
}
int main ()
{
GtkWidget *win, *label;
GdkScreen *screen;
gtk_init (NULL, NULL);
win = gtk_window_new (GTK_WINDOW_POPUP);
screen = gtk_widget_get_screen (win);
gtk_widget_set_colormap (win, gdk_screen_get_rgba_colormap (screen));
gtk_widget_set_app_paintable (win, TRUE);
gtk_widget_realize (win);
gdk_window_set_back_pixmap (win->window, NULL, FALSE);
gtk_window_move (GTK_WINDOW (win), 300, 200);
label = gtk_label_new ("This is an RGBA window");
gtk_container_add (GTK_CONTAINER (win), label);
gtk_widget_show_all (win);
g_signal_connect (win, "expose-event", G_CALLBACK (handle_expose), win);
gtk_main ();
return 0;
}
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-release
Hey! On Mon, 2009-11-09 at 14:59 +0100, ext Frantisek Dufka wrote: > > I added a package to the extras(-devel)? repositories called > > maemo-release. It has version 1.0.0 in gregale, 2.0.0 in bora, 3.0.0 in > > Chinook, etc. ... > > There already is package named "maemo-version" in the SDK. And the > numbering is different (and consistent with SDK releases), Gregale is > 2.2, Bora 3.x, Chinook 4.0, Diablo 4.1, D'oh! I looked for such a package, but I was looking only in extras-devel. I suppose I should've asked around some more. > Not good :-( /me is embarrassed Gabriel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Looking for a tag cloud widget (like the one in "Edit tags")
Hi Thomas, Thomas Perl wrote: > I need a widget that can display a "tag cloud" out of a list of items > that I provide (with different font sizes depending on a weight > associated with each item). In Fremantle, the Images and Camera apps > have such a tag cloud (the dialog is called "Edit tags"), but I don't > think that the widget itself is open (if it is, please kindly point me > to its source ;). > > If there's no such thing, maybe I'll do one for Hildon Extras; just > don't want to duplicate work that someone else might have done already > :) A quick search found this: http://www.mail-archive.com/tracker-l...@gnome.org/msg02732.html I don't know of one in Hildon, but then I don't know Hildon very well :) Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: read XML files
Le 10/11/2009 09:27, Tim Teulings a écrit : > Hello! > >> Is there a way to read XML files in the Maemo distribution ? > > The GNOME XML library is available (should be libxml2-dev, libxml2). > See also http://xmlsoft.org/. Thanks a lot > > It is also possible that QT has a XML library, too (I'm not using QT). PasswordSafe is based on GTK > >> If not can you recommend one available in extras ? >> If not can you recommend one ? > > libxml is a C library. I'm happy with it, but a C++ (QT) library might have > (or might not) an easier interface. and written in C so libxml2 is fine for me too > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: read XML files
Hello! > Is there a way to read XML files in the Maemo distribution ? The GNOME XML library is available (should be libxml2-dev, libxml2). See also http://xmlsoft.org/. It is also possible that QT has a XML library, too (I'm not using QT). > If not can you recommend one available in extras ? > If not can you recommend one ? libxml is a C library. I'm happy with it, but a C++ (QT) library might have (or might not) an easier interface. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Problems Panning/Clicking with GtkIconView
Hi Jonathan,
which VMWare image and SDK are you using? This was an issue in the Beta
SDK and with the Final SDK it should work.
Cheers Daniel
ext Jonathan Blake wrote:
> Hi everyone,
>
> I am having a hell of a time trying to get an GtkIconView working
> correctly with the pannable area widget. Using hildon.GtkIconView I am
> able to pan by using the scrollwheel on my mouse, but if i click
> anywhere to start panning, it immediately activates whatever was
> clicked on. gtk.IconView does pretty much exactly the same thing.
> Removing the connect function obviously allows you to pan freely.
>
> Code is as follows (I've left in various settings etc for
> completeness' sake):
>
> pan_area = hildon.PannableArea()
> model = gtk.ListStore(str, gtk.gdk.Pixbuf)
>
> for item in xmlf:
> thumbnail_data = gtk.gdk.pixbuf_new_from_file(
> cache_path_thumbs + item["filename"])
> model.append([str(item['name']), thumbnail_data])
>
> grid = hildon.GtkIconView(gtk.HILDON_UI_MODE_NORMAL, model)
> grid.set_selection_mode(gtk.SELECTION_SINGLE)
> grid.set_pixbuf_column(1)
> grid.set_columns(4)
> grid.set_item_width(190)
> grid.set_spacing(thumbnail_spacing)
> grid.connect('selection-changed', self.thumbnailSelect, model, window)
> pan_area.add_with_viewport(grid)
>
>
> Points of note: I'm using the Vmware SDK. I know that has a few bugs
> so maybe this is one of them. As mentioned, the scrollwheel does pan
> the area, so pannable area is working as intended.
>
> Does anyone have any ideas? this is a pretty critical issue and I
> don't know of anyone else who's managed to get this working.
>
> What am I doing wrong?
>
> Thanks!
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
read XML files
Hi, Is there a way to read XML files in the Maemo distribution ? If not can you recommend one available in extras ? If not can you recommend one ? I want to read keepassx xml files for importing in passwordSafe Thanks Fred ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
