Maemo support for pyzim

[maacruz]

This patch adds support for zim in maemo platform.
Patch against 0.44 release
Feel free to ask any question.

[Jaap Karssenberg (jaap.karssenberg)]

Patch looks quite good in terms of functionality. I see some parts where I would like to change the coding a little bit. I will work on that and create a patch with those changes for you to review before merging.

One thing you might want to add is a page in the HACKING notebook explaining a little bit of the restriction on maemo for developers like me who don't have their own maemo device to test with. This will help keeping things compatible in the future.

Zim 0.45 will be released today, so I guess we can target zim 0.46 for including maemo support in the main branch.

[maacruz (maacruz)]

> Patch looks quite good in terms of functionality. I see some parts where
> I would like to change the coding a little bit. I will work on that and
> create a patch with those changes for you to review before merging.
Fine

> One thing you might want to add is a page in the HACKING notebook
> explaining a little bit of the restriction on maemo for developers like
> me who don't have their own maemo device to test with. This will help
> keeping things compatible in the future.
I'll upload it at soon as it is done.

> Zim 0.45 will be released today, so I guess we can target zim 0.46 for
> including maemo support in the main branch.
Fine, that will let us time to polish any rough edge.

[maacruz (maacruz)]

Updated patch against 0.46

[Jaap Karssenberg (jaap.karssenberg)]

Just merged this into a bazaar branch in order to start hacking on it. Two things I would like to do:

First is to refine the configuration module to accommodated maemo specific settings. I will introduce a config manager object which can keep track of global settings and will know if we are running maemo or not. Also I would like to put all UI changes that are not necessarily maemo specific behind a "small screen" config setting, so others can use it as well.

Second thing is to refine the build system a bit so we can separate maemo specific .desktop files and keep them out of the default packages. For this purpose setup.py would have some special cases for building maemo specific packages.

I don't see any changes to the Makefile or to the debian control files in the patch, how do you compile the maemo specific package - do you have a built script for that ?

[Jaap Karssenberg (jaap.karssenberg)]

Another question, from some quick look at the maemo design guide I gather that dialgos should always run full screen, basically only allowing a strict modal interface.

Based on the changes in zim.gui.widgets I see all file dialogs are running at 800 x 480 (which I assume is full screen) but for other dialogs the preference setting is user specific. Is this intended, or should we force all dialogs into full screen mode ?

[Jaap Karssenberg (jaap.karssenberg)]

To be more specific, all dialogs should use the full width of the window according to the style guide. Height can vary.

[maacruz (maacruz)]

Actually I have a very dirty bash script for compiling, because I'm building the deb packages by hand (with pypackager, a gui application) and distributing them from the maemo garage web page, but to have the package included in the maemo repository, it must be built with the autobuilder, so it will need a proper Makefile.

Yes, the maemo interface is strict modal.Application windows are always maximized or fullscreen, only one window can be shown. Dialogs are always strict modal, on top of application window. Even if a dialog is set to 800x480, it won't be fullscreen unless the application window is fullscreen, but it will use the window available area. No window is resizeable, and only application windows have the minimize/close buttons.

About the dialogs width and height, they don't follow their own style guide (maemo file dialogs don't use the full width) so we can use what we see fit.
Sometimes the witdth is more trouble than the heigh (usually when there are two or more panels), but usually the height is more trouble than the width (it is 480 when fullscreen, 420 when not).
I've left the preference setting as default when the default dialog size (-1,-1) is right, I force a size when it is not, it is a case by case decision.

[Jaap Karssenberg (jaap.karssenberg)]

Just pushed my work so far to lp:~pardus-cpan/zim/pyzim-maemo

I put .desktop files in a separate maemo directory and updated setup.py to switch to these in case the environment variable MAEMO is set. Should be further integrated with the build script.

I cleaned up the code in several places, but needs testing if I didn't break stuff since I have no maemo device to test on.

Most notably I changed the kludge to handle sensitivity switching for pageview accelerators - not sure if this now works with the maemo menu focus.

Remaining for me to do is work on the way the maemo specific UI elements are switched. Probably no time for that in the next wekk and a half or so.

[Jaap Karssenberg (jaap.karssenberg)]

Please sync from lp:~pardus-cpan/zim/pyzim-maemo and check if it still works. (Diff against lp:~maacruz/zim/maemo attached.) If all is OK I'll merge with trunk.

I added some questions in the comments. Please have a look at those.

Most of the patch is cleanup of the code. For future patches please pay more attention to coding style, especially whitespace was missing in many lines of code.

[maacruz (maacruz)]

El Lunes 17 Mayo 2010, Jaap Karssenberg escribió:
> Please sync from lp:~pardus-cpan/zim/pyzim-maemo and check if it still
> works. (Diff against lp:~maacruz/zim/maemo attached.) If all is OK I'll
> merge with trunk.
>
> I added some questions in the comments. Please have a look at those.
Ok, I'll have a look at it this week, starting today.
> Most of the patch is cleanup of the code. For future patches please pay
> more attention to coding style, especially whitespace was missing in
> many lines of code.
Sorry about the style. Most of the changes were done in the device itself, and
one of the editors destroyed whitespaces. I tryed a cleanup by hand, but
obviously a lot slipped through.
>
> ** Branch linked: lp:~maacruz/zim/maemo
>
> ** Patch added: "merge-maemo.patch"
> http://launchpadlibrarian.net/48622549/merge-maemo.patch
>
> ** Changed in: zim
> Status: Confirmed => In Progress

--
Don't see the world through a window, be open{source}minded, and be free :-)

[maacruz (maacruz)]

Many things are broken. It'll take me a few days to review the patch and fix it.

[Jaap Karssenberg (jaap.karssenberg)]

On Thu, May 20, 2010 at 9:52 PM, maacruz <email address hidden> wrote:
> Many things are broken. It'll take me a few days to review the patch and
> fix it.

Hmm, that's bad. Can we come up with some test cases to ensure things
work OK on maemo? Problem is that such tests should run without the
maemo environment, otherwise they won't run often enough during
development.

-- Jaap

[Jaap Karssenberg (jaap.karssenberg)]

Just noticed I forgot to check in one file, see attached maemo/README-BUILD-Maemo.txt with some notes about building for maemo.

Without this parameter the maemo .desktop files will not be included - which is probably one of the things that broke for you. Just realized that this also means the maemo .desktop files are not used when running from source only (unless they were installed before).

[maacruz (maacruz)]

I didn't even noticed the .desktop issue, I was running from sources :)
Ok, I have updated my branch, and here is the patch against your pyzim-maemo branch.

About the build system, it doesn't work at all.
First, it breaks complaining about non existing directories ('maemo/applications').
Ok, I fix (it should be data/maemo/....) and create such directories and put my desktop files and shell scripts there.
Still doesn't work, it fails at the copy stage with:
.....
copying data/pixmaps/xchecked-box.png -> /var/tmp/pyzim/usr/local/share/zim/pixmaps
creating /var/tmp/pyzim/usr/local/share/zim/maemo
copying data/maemo/modest-mailto.sh -> /var/tmp/pyzim/usr/local/share/zim/maemo
creating /var/tmp/pyzim/usr/local/share/zim/maemo/applications
copying data/maemo/applications/fennec.desktop -> /var/tmp/pyzim/usr/local/share/zim/maemo/applications
copying data/maemo/applications/modest.desktop -> /var/tmp/pyzim/usr/local/share/zim/maemo/applications
copying data/maemo/applications/hildon-mime-summon.desktop -> /var/tmp/pyzim/usr/local/share/zim/maemo/applications
copying data/maemo/applications/tear.desktop -> /var/tmp/pyzim/usr/local/share/zim/maemo/applications
copying data/maemo/applications/microb.desktop -> /var/tmp/pyzim/usr/local/share/zim/maemo/applications
copying data/maemo/applications/opera.desktop -> /var/tmp/pyzim/usr/local/share/zim/maemo/applications
creating /var/tmp/pyzim/usr/local/share/zim/applications
error: can't copy 'fennec.desktop': doesn't exist or not a regular file

[maacruz (maacruz)]

Updated the patch with a fix for the calendar plugin autoclose feature

[maacruz (maacruz)]

Updated patch for 0.47

[Jaap Karssenberg (jaap.karssenberg)]

On Thu, Jun 10, 2010 at 6:09 PM, maacruz <email address hidden> wrote:
> Updated patch for 0.47
>
> ** Patch added: "Patch against 0.47"
>   http://launchpadlibrarian.net/50080137/zim-0.47-maemo.patch

I see this is still the patch without my changes. Did you have a look at those?

Regards,

Jaap

[maacruz (maacruz)]

El Viernes 11 Junio 2010, Jaap Karssenberg escribió:
> On Thu, Jun 10, 2010 at 6:09 PM, maacruz <email address hidden> wrote:
> > Updated patch for 0.47
> >
> > ** Patch added: "Patch against 0.47"
> >   http://launchpadlibrarian.net/50080137/zim-0.47-maemo.patch
>
> I see this is still the patch without my changes. Did you have a look at
> those?
>
No, Jaap, you are wrong :)
This is patch has all your changes (as in merge-maemo.patch)
with all my fixes upon them to make it work again (so a couple of changes may
seem reverted but they really aren't),
and all comments "FIXME: Why do you do this?" answered,
and then a few new platform enhancements and bugfixes (the main one being
better N900 support), as in mergev2-maemo.patch which is against your
pyzim-maemo branch (to make clear what my changes upon yours are),
and then applied to 0.47 and all the collisions that happened fixed, so it can
be used to directly merge with 0.47
Nothing less, nothing more.

Sorry if this sounds confusing.

So, to make it clear where each patch belongs to:
- mergev2-maemo.patch is against your pyzim-maemo branch, which is still 0.46
and deprecated by the 0.47 release
- zim-0.47-maemo.patch is against 0.47 release
Both hold the same changes.

--
Don't see the world through a window, be open{source}minded, and be free :-)

[Jaap Karssenberg (jaap.karssenberg)]

OK, I see now what went wrong. In my branch I moved a number of files. E.g. maemo specific desktop files went into a separate folder so they only got installed on maemo, not on other platforms. But in the diff I attached these file renames drop out.

What is the easiest way for me to rebase the fixes and post them in a way you can commit them to your tree - it there a svn command for that ?

[maacruz (maacruz)]

Ok, I have moved those files and redone the 0.47 patch to refect it.
You can apply this patch on 0.47. If you need to make any additional change, just do it and tell me when you are finished. I'll take care from there.

setup.py builds but the installation still fails in my box:

miguel@linux:~/zim/zim-0.47-maemo> ZIM_BUILD_TARGET=maemo make DESTDIR=/var/tmp/zim install
`which python` setup.py install --root /var/tmp/zim
Building for Maemo...
...
copying xdg/hicolor/application-x-zim-notebook.png -> /var/tmp/zim/usr/local/share/icons/hicolor/64x64/mimetypes
error: can't copy 'fennec.desktop': doesn't exist or not a regular file
make: *** [install] Error 1

Furthermore, it ignores $PREFIX and insists in installing things under /usr/local while I want to install in /usr
Unfortunately, I've never have used distutils and don't know what can be wrong here.

[Jaap Karssenberg (jaap.karssenberg)]

OK, will double check patch and try to merge it.

In setup.py I changed the line:
    files = [f for f in os.listdir('maemo/applications') if f.endswith('.desktop')]

to:
    files = ['maemo/applications/%s' % f
   for f in os.listdir('maemo/applications') if f.endswith('.desktop')]

This will solve the error during install.

To use a prefix you need to call setup.py directly instead of using make. Probably for building a package you want to do something like:

   $ ./setup.py install --root /my/package/dir --prefix /usr --skip-xdg-cmd

[Jaap Karssenberg (jaap.karssenberg)]

Trying to sort out a clean way to merge this. Unfortunately the bazaar import of your svn tree on launchpad is not correct, a checkout gives lot of ghost directories that are not in the svn checkout. So what I'm doing now is I synced my own bazaar maemo branch up to release 0.47 and compare it to a checkout of your svn tree. So probably you could flag your bazaar import as no longer needed so it gets removed from the list of active branches.

Looking at the diff I see various new changes in your branch. Busy checking those out before merging in trunk.

One glitch I see from the svn tree is that you still have "zim/plugins/scrot.py". This became "zim/plugins/screenshot.py" and had quite some changes in my branch. This is probably to the same issue with renamed files being dropped from the patch.

Also I see a few files missing in "data/manual/Plugins/GNU_R_Plot_Editor" - probably you missed these in your 0.47 sync. And missing "MANIFEST.in" which is needed for packaging.

Files in the svn branch that can probably be removed: "data/preferences.conf" and "PKG-INFO"

Regards,

Jaap

[maacruz (maacruz)]

Hi Jaap,
Don't get lost with the tools; for 0.47 I also tryed to use bazaar to diff with my svn and local trees and it was a mess, so I reverted back to doing things by hand.
I suggest that, for this patch, you forget about svn and use the patch directly. I do it by hand and take great care it is right and works as expected.
By the way, I've updated the patch with your screenshot.py changes and the setup.py fix.

IMHO, the easyest way to merge this, is to take a local branch from 0.47 and apply the patch directly (by hand). Then you'll have your bazaar branch synced to my local/svn trees. We will take care of small details like any remaining absent, moved or deleted file then.
Then I'll try to find some way of making svn and bazaar play well together in my local tree, and will delete the bazaar svn import (it seems useless for both of us) and will create here a new branch from the merged one for future development, so we can use bazaar to merge future changes while I keep svn in sync.

About scrot.py, it is still scrot.py in 0.47 tarball, so that explains I didn't noticed anything.
About GNU_R_Plot_Editor, you are right, I missed a few files. Already solved.
About MANIFEST.in, it doesn't exists in the 0.47 tarball, and I didn't consider any file absent from the tarballs.

[Jaap Karssenberg (jaap.karssenberg)]

What I'm doing is indeed using manual diff to sync the trees, but
doing it in incremental steps so I can distinguish my changes and your
subsequent changes. Doing it this way because this is a large patch
touching many modules in zim, so I want to make sure I understand what
is going on everywhere and nothing else breaks. Will take some time
but this is the only way to get a clean history of all the changes.

Files like MANIFEST.in are needed if you want to build a source
package from your tree. PKG-INFO on the other hand is a file that is
generated when building a source distribution, but should not be in
the development tree. Better to sync based on the bazaar tree instead
of the released package.

Also missing in your tree are the "website", "windows" and "debian"
sub directories. The first two you can do without, but I would assume
you need the debian control files to build a .deb for maemo, or do you
use another package system ?

Btw. still missing data/manual/Plugins/GNU_R_Plot_Editor.txt in your tree.

[maacruz (maacruz)]

El Domingo 20 Junio 2010, Jaap Karssenberg escribió:
> What I'm doing is indeed using manual diff to sync the trees, but
> doing it in incremental steps so I can distinguish my changes and your
> subsequent changes. Doing it this way because this is a large patch
> touching many modules in zim, so I want to make sure I understand what
> is going on everywhere and nothing else breaks. Will take some time
> but this is the only way to get a clean history of all the changes.
Ok.

> Files like MANIFEST.in are needed if you want to build a source
> package from your tree. PKG-INFO on the other hand is a file that is
> generated when building a source distribution, but should not be in
> the development tree. Better to sync based on the bazaar tree instead
> of the released package.
Thanks. Updated svn with this.

> Also missing in your tree are the "website", "windows" and "debian"
> sub directories. The first two you can do without, but I would assume
> you need the debian control files to build a .deb for maemo, or do you
> use another package system ?
I'm using a custom system with a GUI to build deb packages, but you are right,
I'll need the debian directory to do this The Right Way
Added debian/ to svn with a customized (and still untested) control file.

> Btw. still missing data/manual/Plugins/GNU_R_Plot_Editor.txt in your
> tree.
Thanks, fixed.

--
Don't see the world through a window, be open{source}minded, and be free :-)

[Jaap Karssenberg (jaap.karssenberg)]

Manual synced svn branch to bzr (see lp:~pardus-cpan/zim/pyzim-maemo) and did some cleanups (see changes in revision 230 and 231)

3 remaining questions:

1) Should we force dialogs on maemo to always use 800x480 ? This would reduce the maemo specific code per dialog. Or does it make sense to have specific dialogs on a different size ?

2) The following comment in pageview.py is internally contradicting:

"""
Maemo hildon input method keyboard doesn't emit keypress events except for TAB, ENTER and BACKSPACE
so we provide TAB as an alternative END_OF_WORD key that works with the current keypress event driven implementation
"""

If no keypress event is generated for TAB adding to current keypress handler will also not work - so probably something else is going on here

3) What is the function of the tap_and_hold_setup() call for the fullscreen toolbar item - why do we need a object property "fsbutton" that is not used anywhere else?

[Jaap Karssenberg (jaap.karssenberg)]

@maacruz: planning new release for next week and would like to merge this patch. Could you confirm whether current revision works on maemo and answer question in comment #27 when you have the time? Thanks.

[maacruz (maacruz)]

El Lunes 05 Julio 2010, Jaap Karssenberg escribió:
> Manual synced svn branch to bzr (see lp:~pardus-cpan/zim/pyzim-maemo)
> and did some cleanups (see changes in revision 230 and 231)
You removed the accelerator key combination for hiding/showing the toolbar
(<ctrl>M). Actually that's not an option for maemo5 and the N900 device, so I
wrapped it with a "if" sentence (see attached patch).
Everything else is fine.
> 3 remaining questions:
>
> 1) Should we force dialogs on maemo to always use 800x480 ? This would
> reduce the maemo specific code per dialog. Or does it make sense to have
> specific dialogs on a different size ?
Big or complex dialogs, yes. Some, like the calendar dialog, no, they would
look ugly. We can decide on this later, when I have adapted more dialogs.
> 2) The following comment in pageview.py is internally contradicting:
>
> """
> Maemo hildon input method keyboard doesn't emit keypress events except for
> TAB, ENTER and BACKSPACE so we provide TAB as an alternative END_OF_WORD
> key that works with the current keypress event driven implementation """
>
> If no keypress event is generated for TAB adding to current keypress
> handler will also not work - so probably something else is going on here
The key word there is "except"
Let me say it in other words: Maemo hildon input method keyboard (aka stylus
keyboard) emits keypress events only for TAB, ENTER and BACKSPACE

> 3) What is the function of the tap_and_hold_setup() call for the
> fullscreen toolbar item - why do we need a object property "fsbutton"
> that is not used anywhere else?
It is a function to attach a menu to a widget, that will be brought by
simulating a right click by keeping the finger/stylus pressing on the widget
for a while.
I used the fsbutton property to be able to reference the fullscreen widget
later, if needed.

--
Don't see the world through a window, be open{source}minded, and be free :-)

[Jaap Karssenberg (jaap.karssenberg)]

Merged into trunk in rev285

[Jaap Karssenberg (jaap.karssenberg)]

Release version 0.48