Thread: [Tuxpaint-devel] hello, and hildon
An award-winning drawing program for children of all ages
Brought to you by:
wkendrick
Menu
▾
▴
tuxpaint-devel
|
From: Alessandro P. <apa...@gm...> - 2007-02-22 17:41:19
|
Hello everybody, This is my first post. I've just downloaded the sources from CVS. I'm the one who ported tp to OS2006 (Nokia 770 and Nokia 800 inetrnet tablets), not so much work indeed. Since Bill Kendrick told me that some hildonizations work has been done before (for OS2005 version of Nokia firmware) I've looked at the code. Well, I discovered that some makefile flags exists for Nokia 770 but no hildonizazion was done, it's just a few configuration change, exactly the same I did (in a very quick and dirty way) for OS2006. BTW having those flags is fine. Just a question: where can I find the DEBIAN control files in order to make a debian package? Do I have to extract them for another tuxpaint debian package? Thanks in advance. -- Alessandro Pasotti w3: www.itopen.it |
|
From: Caroline F. <car...@go...> - 2007-02-22 22:34:46
|
Alessandro Pasotti wrote: > Just a question: where can I find the DEBIAN control files in order to > make a debian package? Do I have to extract them for another tuxpaint > debian package? > They are done by Debian afaik - try packages.debian.org or packages.ubuntu.com (Ubuntu is 'downstream' of Debian and generally uses their packages unaltered. If it is altered it will have ubuntu in the package name) Debian files are in the debian directory which is generally a patch to the upstream tarball. You download the diff, the original tarball and a dsc file which gives checksums etc. In Debian land tuxpaint is in 4 binary packages - tuxpaint, tuxpaint-data, tuxpaint-stamps-default and tuxpaint-config. Currently tuxpaint-data depends on tuxpaint-stamps and vice versa. In Ubuntu we are looking at changing it so that tuxpaint-data only recommends the stamps package as it is possible to run tuxpaint without the stamps installed (and circular dependencies are horrible and break with gdebi) (my bug - https://launchpad.net/bugs/82510) tuxpaint-stamps is a virtual package which is currently only provided by tuxpaint-stamps-data but can be provided by other packages once the stamps collection is split by theme. http://packages.debian.org/unstable/graphics/tuxpaint is the main binary http://packages.debian.org/unstable/graphics/tuxpaint-data is the architecture independent data http://packages.debian.org/unstable/graphics/tuxpaint-stamps-default stamps http://packages.debian.org/unstable/graphics/tuxpaint-config config Debian unstable currently has version 0.9.16 and 2006.10.21 for stamps. Ubuntu Feisty will get 0.9.16, currently Ubuntu Edgy and Dapper have 0.9.15. Caroline |
|
From: Kees J. <kee...@gm...> - 2007-02-22 23:05:25
|
Hello I am very happy to get a chance to contribute to this great piece of software! My involement in tuxpaint started because I wanted a tuxpaint for the N800. I did this by putting a mud file in the mud builder https://garage.maemo.org/plugins/scmsvn/viewcvs.php/trunk/packages/tuxpaint.xml?root=mud-builder&view=markup The mud builder generates the debian /control and rules for us. http://mud-builder.garage.maemo.org/index.php The N700 is a pretty small (in terms of memory/cpu speed device) I think we have different considerations when it comes to the possibilities and I don't even thing there is a download stamps package. The maemo platform is debian based and we can use most of the other debian source archives (we just need a good reson). I think the current port works pretty well , it just needs a bit of love. I propose to build the packages /debian things for the different maemo platforms. I don't think this all is very interesting for tuxpaint developers. but.. I would like to have a virtual keyboard so my kids can also type letters. are there people willing to create some graphics for that? greetings On 2/22/07, Caroline Ford <car...@go...> wrote: > Alessandro Pasotti wrote: > > Just a question: where can I find the DEBIAN control files in order to > > make a debian package? Do I have to extract them for another tuxpaint > > debian package? > > > They are done by Debian afaik - try packages.debian.org or > packages.ubuntu.com (Ubuntu is 'downstream' of Debian and generally > uses their packages unaltered. If it is altered it will have ubuntu in > the package name) > > Debian files are in the debian directory which is generally a patch to > the upstream tarball. You download the diff, the original tarball and a > dsc file which gives checksums etc. > > In Debian land tuxpaint is in 4 binary packages - tuxpaint, > tuxpaint-data, tuxpaint-stamps-default and tuxpaint-config. Currently > tuxpaint-data depends on tuxpaint-stamps and vice versa. In Ubuntu we > are looking at changing it so that tuxpaint-data only recommends the > stamps package as it is possible to run tuxpaint without the stamps > installed (and circular dependencies are horrible and break with gdebi) > (my bug - https://launchpad.net/bugs/82510) > > tuxpaint-stamps is a virtual package which is currently only provided by > tuxpaint-stamps-data but can be provided by other packages once the > stamps collection is split by theme. > > http://packages.debian.org/unstable/graphics/tuxpaint is the main binary > http://packages.debian.org/unstable/graphics/tuxpaint-data is the > architecture independent data > http://packages.debian.org/unstable/graphics/tuxpaint-stamps-default stamps > http://packages.debian.org/unstable/graphics/tuxpaint-config config > > Debian unstable currently has version 0.9.16 and 2006.10.21 for stamps. > Ubuntu Feisty will get 0.9.16, currently Ubuntu Edgy and Dapper have 0.9.15. > > Caroline > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Tuxpaint-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel > |
|
From: Caroline F. <car...@go...> - 2007-02-22 23:47:13
|
Kees Jongenburger wrote: > I don't think this all is very interesting for tuxpaint developers. but.. > I would like to have a virtual keyboard so my kids can also type letters. > are there people willing to create some graphics for that? > > greetings > I'm working on sets of alphabet stamps currently which could be used. One question would be on keyboard layout as it would need to be localised - EN has qwerty, DE has qwertz etc Caroline > On 2/22/07, Caroline Ford <car...@go...> wrote: > >> Alessandro Pasotti wrote: >> >>> Just a question: where can I find the DEBIAN control files in order to >>> make a debian package? Do I have to extract them for another tuxpaint >>> debian package? >>> >>> >> They are done by Debian afaik - try packages.debian.org or >> packages.ubuntu.com (Ubuntu is 'downstream' of Debian and generally >> uses their packages unaltered. If it is altered it will have ubuntu in >> the package name) >> >> Debian files are in the debian directory which is generally a patch to >> the upstream tarball. You download the diff, the original tarball and a >> dsc file which gives checksums etc. >> >> In Debian land tuxpaint is in 4 binary packages - tuxpaint, >> tuxpaint-data, tuxpaint-stamps-default and tuxpaint-config. Currently >> tuxpaint-data depends on tuxpaint-stamps and vice versa. In Ubuntu we >> are looking at changing it so that tuxpaint-data only recommends the >> stamps package as it is possible to run tuxpaint without the stamps >> installed (and circular dependencies are horrible and break with gdebi) >> (my bug - https://launchpad.net/bugs/82510) >> >> tuxpaint-stamps is a virtual package which is currently only provided by >> tuxpaint-stamps-data but can be provided by other packages once the >> stamps collection is split by theme. >> >> http://packages.debian.org/unstable/graphics/tuxpaint is the main binary >> http://packages.debian.org/unstable/graphics/tuxpaint-data is the >> architecture independent data >> http://packages.debian.org/unstable/graphics/tuxpaint-stamps-default stamps >> http://packages.debian.org/unstable/graphics/tuxpaint-config config >> >> Debian unstable currently has version 0.9.16 and 2006.10.21 for stamps. >> Ubuntu Feisty will get 0.9.16, currently Ubuntu Edgy and Dapper have 0.9.15. >> >> >> > > |
|
From: Terje <ter...@ko...> - 2007-02-24 06:16:23
|
Hi,
My first post, too. I tried to send this already from GMail, but it didn't
seem to appear in the list.
> I've just downloaded the sources from CVS.
> I'm the one who ported tp to OS2006 (Nokia 770 and Nokia 800 inetrnet
tablets), not so much work indeed.
> Since Bill Kendrick told me that some hildonizations work has been done
before (for OS2005 version of Nokia firmware) I've looked at the code.
> Well, I discovered that some makefile flags exists for Nokia 770 but no
hildonizazion was done, it's just a few configuration change, exactly the
same I did (in a very quick and dirty way) for OS2006.
> BTW having those flags is fine.
I downloaded the sources and noticed, that they actually don't build. I made
small changes to Makefile and got it to build and run in Maemo SDK fine. If
there are no objections, I will commit my changes to Makefile to cvs
tomorrow.
My biggest change was not to overwrite stock CFLAGS, but just to
append "-DNOKIA_770" to it by introducing similar flag set as with "NOSVG".
I think the biggest challange with the already-packaged OS2006 version is the
cursor. The cursor should be removed, as there is no mouse in OS2006. With
touchscreen the cursor just gets in the way.
Just a question: where can I find the DEBIAN control files in order to
make a debian package? Do I have to extract them for another tuxpaint debian
package?
I think the best bet would be to start with the Debian's tuxpaint package and
work from there.
Best regards,
Terje
|
|
From: Alessandro P. <apa...@gm...> - 2007-02-25 10:56:31
|
Yes, the cursor could be removed, I left it because I liked it, but it is really unuseful. 2007/2/24, Terje Bergstr=F6m <ter...@ko...>: > > Hi, > > My first post, too. I tried to send this already from GMail, but it didn'= t > seem to appear in the list. > > > I've just downloaded the sources from CVS. > > I'm the one who ported tp to OS2006 (Nokia 770 and Nokia 800 inetrnet > tablets), not so much work indeed. > > Since Bill Kendrick told me that some hildonizations work has been > done > before (for OS2005 version of Nokia firmware) I've looked at the code. > > Well, I discovered that some makefile flags exists for Nokia 770 but > no > hildonizazion was done, it's just a few configuration change, exactly the > same I did (in a very quick and dirty way) for OS2006. > > BTW having those flags is fine. > > > I downloaded the sources and noticed, that they actually don't build. I > made > small changes to Makefile and got it to build and run in Maemo SDK fine. > If > there are no objections, I will commit my changes to Makefile to cvs > tomorrow. > > My biggest change was not to overwrite stock CFLAGS, but just to > append "-DNOKIA_770" to it by introducing similar flag set as with > "NOSVG". > > I think the biggest challange with the already-packaged OS2006 version is > the > cursor. The cursor should be removed, as there is no mouse in OS2006. Wit= h > touchscreen the cursor just gets in the way. > > Just a question: where can I find the DEBIAN control files in order t= o > make a debian package? Do I have to extract them for another tuxpaint > debian > package? > > > I think the best bet would be to start with the Debian's tuxpaint package > and > work from there. > > Best regards, > Terje > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > Tuxpaint-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel > --=20 Alessandro Pasotti w3: www.itopen.it |
|
From: Kees J. <kee...@gm...> - 2007-02-24 07:06:05
|
Hello Terje It looks like we are enough people who have a good interest in this project the mud builder builds tuxpaint from the tar.gz archieve. I just tried to build tuxpaint from the debian repo and it required hevea and such for building how did you build it? I am quite sure the source debian will need to changes , the question is where to put these changes :p. I am off to fosdem are there tuxpaint developer going there? greetings On 2/24/07, Terje Bergstr=F6m <ter...@ko...> wrote: > Hi, > > My first post, too. I tried to send this already from GMail, but it didn'= t > seem to appear in the list. > > > I've just downloaded the sources from CVS. > > I'm the one who ported tp to OS2006 (Nokia 770 and Nokia 800 inetrne= t > tablets), not so much work indeed. > > Since Bill Kendrick told me that some hildonizations work has been d= one > before (for OS2005 version of Nokia firmware) I've looked at the code. > > Well, I discovered that some makefile flags exists for Nokia 770 but= no > hildonizazion was done, it's just a few configuration change, exactly the > same I did (in a very quick and dirty way) for OS2006. > > BTW having those flags is fine. > > > I downloaded the sources and noticed, that they actually don't build. I m= ade > small changes to Makefile and got it to build and run in Maemo SDK fine. = If > there are no objections, I will commit my changes to Makefile to cvs > tomorrow. > > My biggest change was not to overwrite stock CFLAGS, but just to > append "-DNOKIA_770" to it by introducing similar flag set as with "NOSVG= ". > > I think the biggest challenge with the already-packaged OS2006 version is= the > cursor. The cursor should be removed, as there is no mouse in OS2006. Wit= h > touchscreen the cursor just gets in the way. |
|
From: Caroline F. <car...@go...> - 2007-02-24 22:14:18
|
Kees Jongenburger wrote: > Hello Terje > > It looks like we are enough people who have a good interest in this project > the mud builder builds tuxpaint from the tar.gz archieve. > > I just tried to build tuxpaint from the debian repo and it required > hevea and such for building > how did you build it? I am quite sure the source debian will need to > changes , the question is where to put these changes :p. I am off to > fosdem are there tuxpaint developer going there? > > Hi guys What is the connection between yourselves and Debian? I'm trying to understand so I can best answer your question. Are you running Debian on your tablets? Is there a Debian port for your tablets? The person you need to contact about the tuxpaint debian package is Ben Armstrong - sy...@sa... He's the Debian developer responsible for tuxpaint. (I've copied him into this email) To submit patches to the Debian packae I'd use their bug tracker. Ben will be able to help you better than I can. Caroline |
|
From: Alessandro P. <apa...@gm...> - 2007-02-25 10:54:17
|
The NOKIA Internet Tablets run a debian-like system, but the packages do not come from debian repositories. The debian packages need some changes to adapt in the hildon framework (menus, icons) and the sources need changes too. The architecture is armel. Regards. 2007/2/24, Caroline Ford <car...@go...>: > > Kees Jongenburger wrote: > > Hello Terje > > > > It looks like we are enough people who have a good interest in this > project > > the mud builder builds tuxpaint from the tar.gz archieve. > > > > I just tried to build tuxpaint from the debian repo and it required > > hevea and such for building > > how did you build it? I am quite sure the source debian will need to > > changes , the question is where to put these changes :p. I am off to > > fosdem are there tuxpaint developer going there? > > > > > Hi guys > > What is the connection between yourselves and Debian? I'm trying to > understand so I can best answer your question. > > Are you running Debian on your tablets? Is there a Debian port for your > tablets? The person you need to contact about the tuxpaint debian > package is Ben Armstrong - sy...@sa... He's the Debian > developer responsible for tuxpaint. (I've copied him into this email) > > To submit patches to the Debian packae I'd use their bug tracker. Ben > will be able to help you better than I can. > > Caroline > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Tuxpaint-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel > -- Alessandro Pasotti w3: www.itopen.it |
|
From: <ter...@ko...> - 2007-02-25 12:06:51
|
On 2/24/07, Kees Jongenburger <kee...@gm...> wrote: > > Hello Terje > > It looks like we are enough people who have a good interest in this > project > the mud builder builds tuxpaint from the tar.gz archieve. What are the advantages of using mud-builder instead of own packaging? As far as I've understood, mud-builder is great at building simple stuff with no Maemo specific changes. When the building has to be done in a customized way to make tuxpaint even run on Maemo, mud-builder is maybe not the optimal solution. I just tried to build tuxpaint from the debian repo and it required > hevea and such for building > how did you build it? I am quite sure the source debian will need to > changes , the question is where to put these changes :p. I am off to > fosdem are there tuxpaint developer going there? I suggest we use the garage project Alessandro started to make the Maemo specific changes. Any changes that need to touch the tuxpaint code, should be committed to tuxpaint's CVS. Stuff like Debian control files, which are Maemo specific, could be hosted in the garage project's svn. There are at least two different types of tasks to do: = Packaging = It's probably easier to start the packaging based on a stable version, so we could start with tuxpaint 0.9.16's source tar.gz package, make the needed changes to get it running well on 770 or N800, and then see how the changes could be merged to tuxpaint CVS. Probably the changes done on 0.9.16 are pretty easy to port to tuxpaint CVS. Maemo requires some special dependencies for packaging, so as an answer to Caroline, we cannot push that to Debian's tuxpaint package. In addition, Maemo is using older debhelper and some other tools. = Hildonizing = I'm mostly worried about the mouse cursor. Otherwise I guess hildonizing will not be a big task. Mostly replacing some gtk calls with hildon calls. I'm not sure how file system differences etc. are going to affect. Hopefully most of the stuff can be done without touching the generic tuxpaint code. Compile time flags are not an optimal solution, but I guess they will do for now. How does that sound? I'm sending Alessandro a please-let-me-in email to get this started. I guess it's still best to keep the discussion in this mailing list. |
|
From: Kees J. <kee...@gm...> - 2007-02-26 11:21:15
|
> What are the advantages of using mud-builder instead of own packaging? As > far as I've understood, mud-builder is great at building simple stuff with > no Maemo specific changes. When the building has to be done in a customized > way to make tuxpaint even run on Maemo, mud-builder is maybe not the optimal > solution. There is no immediate gain here if you know how to build for on different maemo sdk's. Also if you know how to signs the package and upload them to the maemo reposiroty I guess. Also once we have the patches into the official tuxpaint there will be no gain in the mud paching system. I don't really mind I think you are right in wanting to use the garage tuxpaint project. > = Packaging = > It's probably easier to start the packaging based on a stable version, so we > could start with tuxpaint 0.9.16's source tar.gz package, make the needed > changes to get it running well on 770 or N800, and then see how the changes > could be merged to tuxpaint CVS. Probably the changes done on 0.9.16 are > pretty easy to port to tuxpaint CVS. > > Maemo requires some special dependencies for packaging, so as an answer to > Caroline, we cannot push that to Debian's tuxpaint package. In addition, > Maemo is using older debhelper and some other tools. correct > > = Hildonizing = > I'm mostly worried about the mouse cursor. Otherwise I guess hildonizing > will not be a big task. Mostly replacing some gtk calls with hildon calls. > I'm not sure how file system differences etc. are going to affect. > > Hopefully most of the stuff can be done without touching the generic > tuxpaint code. Compile time flags are not an optimal solution, but I guess > they will do for now. > > How does that sound? I'm sending Alessandro a please-let-me-in email to get > this started. I guess it's still best to keep the discussion in this mailing > list. Good thinking[tm] I will try to looks if the freedesktop project keyboard layouts could be used to display an onscreen keyboard greetings |
|
From: Alessandro P. <apa...@gm...> - 2007-02-25 14:14:23
|
Jus a few comments 2007/2/25, Terje Bergstr=F6m <ter...@ko...>: > > > There are at least two different types of tasks to do: > > =3D Packaging =3D > It's probably easier to start the packaging based on a stable version, so > we could start with tuxpaint 0.9.16's source tar.gz package, make the > needed changes to get it running well on 770 or N800, and then see how th= e > changes could be merged to tuxpaint CVS. Probably the changes done on > 0.9.16 are pretty easy to port to tuxpaint CVS. > > Maemo requires some special dependencies for packaging, so as an answer t= o > Caroline, we cannot push that to Debian's tuxpaint package. In addition, > Maemo is using older debhelper and some other tools. > > =3D Hildonizing =3D > I'm mostly worried about the mouse cursor. Otherwise I guess hildonizing > will not be a big task. Mostly replacing some gtk calls with hildon calls= . > I'm not sure how file system differences etc. are going to affect. > Mouse cursor can be easily avoided, it's just a matter of commenting a line in the sources (or in the configuration file, cannot exactly remember where= ) Hopefully most of the stuff can be done without touching the generic > tuxpaint code. Compile time flags are not an optimal solution, but I gues= s > they will do for now. > > How does that sound? I'm sending Alessandro a please-let-me-in email to > get this started. I guess it's still best to keep the discussion in this > mailing list. > > Other changes to the source are related to the screen size and disabling text tools. Since AFAIK there is no GTK code in tuxpaint, there is no need to change to hildon, the only good reason could be to implement text tools with the hildon keyboard (and other hildon input methods). Other changes for maemo packaging are done in the /etc/tuxp* file: * store images in the mmc (and not in a hidden dir, otherwise users will never find them anymore) * disable printing * hildon menu and icons * disable cursor? ToDo: * text tool input * fix the bug that don't show the application in the application bar (I think is now fixed by kees in N800) * change some tools to use integer math (no FPU on N770) * implement the possibility to hide (via config file) the lower information bar (so we have more space for drawings), this is a feature request from a user, and I think it's a good idea * package stamps * package languages separately Concerning mud yes or mud no, I'm agnostic but just a little bit lazy to learn something new: I tried mud a week ago (trying to compile gdal) and ended up compiling the entire world (CTRL+C after one hour or so). If someone could help me/us start with mud, it could be an option, but I'm not sure it is the best way to go. Those are just a few ideas. Comments are welcome. BTW right now tuxpaint is already packaged and woks (with the a.m. bugs) on both N800 and N770. Regards. --=20 Alessandro Pasotti w3: www.itopen.it |
|
From: <te...@ik...> - 2007-02-23 13:42:56
|
Hi, My first post, too. I've just downloaded the sources from CVS. > I'm the one who ported tp to OS2006 (Nokia 770 and Nokia 800 inetrnet > tablets), not so much work indeed. > Since Bill Kendrick told me that some hildonizations work has been done > before (for OS2005 version of Nokia firmware) I've looked at the code. > Well, I discovered that some makefile flags exists for Nokia 770 but no > hildonizazion was done, it's just a few configuration change, exactly the > same I did (in a very quick and dirty way) for OS2006. > BTW having those flags is fine. I downloaded the sources and noticed, that they actually don't build. I made small changes to Makefile and got it to build and run in Maemo SDK fine. If there are no objections, I will commit my changes to Makefile to cvs tomorrow. My biggest change was not to overwrite stock CFLAGS, but just to append "-DNOKIA_770" to it by introducing similar flag set as with "NOSVG". I think the biggest challange with the already-packaged OS2006 version is the cursor. The cursor should be removed, as there is no mouse in OS2006. With touchscreen the cursor just gets in the way. Just a question: where can I find the DEBIAN control files in order to make > a debian package? Do I have to extract them for another tuxpaint debian > package? I think the best bet would be to start with the Debian's tuxpaint package and work from there. Thanks in advance. > -- > Alessandro Pasotti > w3: www.itopen.it > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Tuxpaint-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel > > |
|
From: <te...@ik...> - 2007-02-25 12:05:45
|
On 2/24/07, Kees Jongenburger <kee...@gm...> wrote: > > Hello Terje > > It looks like we are enough people who have a good interest in this > project > the mud builder builds tuxpaint from the tar.gz archieve. What are the advantages of using mud-builder instead of own packaging? As far as I've understood, mud-builder is great at building simple stuff with no Maemo specific changes. When the building has to be done in a customized way to make tuxpaint even run on Maemo, mud-builder is maybe not the optimal solution. I just tried to build tuxpaint from the debian repo and it required > hevea and such for building > how did you build it? I am quite sure the source debian will need to > changes , the question is where to put these changes :p. I am off to > fosdem are there tuxpaint developer going there? I suggest we use the garage project Alessandro started to make the Maemo specific changes. Any changes that need to touch the tuxpaint code, should be committed to tuxpaint's CVS. Stuff like Debian control files, which are Maemo specific, could be hosted in the garage project's svn. There are at least two different types of tasks to do: = Packaging = It's probably easier to start the packaging based on a stable version, so we could start with tuxpaint 0.9.16's source tar.gz package, make the needed changes to get it running well on 770 or N800, and then see how the changes could be merged to tuxpaint CVS. Probably the changes done on 0.9.16 are pretty easy to port to tuxpaint CVS. Maemo requires some special dependencies for packaging, so as an answer to Caroline, we cannot push that to Debian's tuxpaint package. In addition, Maemo is using older debhelper and some other tools. = Hildonizing = I'm mostly worried about the mouse cursor. Otherwise I guess hildonizing will not be a big task. Mostly replacing some gtk calls with hildon calls. I'm not sure how file system differences etc. are going to affect. Hopefully most of the stuff can be done without touching the generic tuxpaint code. Compile time flags are not an optimal solution, but I guess they will do for now. How does that sound? I'm sending Alessandro a please-let-me-in email to get this started. I guess it's still best to keep the discussion in this mailing list. |
|
From: Bill K. <nb...@so...> - 2007-03-04 07:35:03
|
On Sun, Feb 25, 2007 at 02:05:44PM +0200, Terje Bergström wrote: > I suggest we use the garage project Alessandro started to make the Maemo > specific changes. Any changes that need to touch the tuxpaint code, should > be committed to tuxpaint's CVS. Stuff like Debian control files, which are > Maemo specific, could be hosted in the garage project's svn. I'm happy having them in CVS as well. We already have, for example, an RPM .spec file. -bill! |
|
From: Bill K. <nb...@so...> - 2007-03-04 07:41:37
|
On Sun, Feb 25, 2007 at 03:14:20PM +0100, Alessandro Pasotti wrote: > Mouse cursor can be easily avoided, it's just a matter of commenting a line > in the sources (or in the configuration file, cannot exactly remember where) I'll make a note to add a "--nomouse" option, which would be useful on other touchscreen devices. <snip> > Other changes to the source are related to the screen size and disabling > text tools. The current version of Tux Paint supports pretty much any arbitrary screen size from 640-wide and up, and 480-tall and up. So on a 770, having a default config that sets it to 800x480 should be sufficient, wouldn't it? > Since AFAIK there is no GTK code in tuxpaint, there is no need to change to > hildon, the only good reason could be to implement text tools with the > hildon keyboard (and other hildon input methods). That'd be nice, down the road, if we can figure it out. I also heard that there's a physical "Home" button on the device that the current (OS2006-compatible) release of TP does NOT recognize, so you have to go in and manually kill the app if you hit that button. (This was not an issue in the build for OS2005.) Thanks! -bill! bi...@ne... http://www.newbreedsoftware.com/ |
|
From: Alessandro P. <apa...@gm...> - 2007-03-05 07:12:10
|
2007/3/4, Bill Kendrick <nb...@so...>: > > On Sun, Feb 25, 2007 at 03:14:20PM +0100, Alessandro Pasotti wrote: > > Mouse cursor can be easily avoided, it's just a matter of commenting a > line > > in the sources (or in the configuration file, cannot exactly remember > where) > > I'll make a note to add a "--nomouse" option, which would be useful on > other touchscreen devices. Good! <snip> > > Other changes to the source are related to the screen size and disabling > > text tools. > > The current version of Tux Paint supports pretty much any arbitrary > screen size from 640-wide and up, and 480-tall and up. > > So on a 770, having a default config that sets it to 800x480 should be > sufficient, wouldn't it? Yes. > Since AFAIK there is no GTK code in tuxpaint, there is no need to change > to > > hildon, the only good reason could be to implement text tools with the > > hildon keyboard (and other hildon input methods). > > That'd be nice, down the road, if we can figure it out. > I also heard that there's a physical "Home" button on the device that > the current (OS2006-compatible) release of TP does NOT recognize, so you > have > to go in and manually kill the app if you hit that button. (This was not > an > issue in the build for OS2005.) The problem is somewhat more complex: it's ok that the home button drives the user to the desktop, it's wrong that the tuxpaint icon doesn't appear in the toolbar and the user cannot go back to tuxpaint. I tried several times to solve this issue (that happens also to other applications ported to the tablets) without success. -- Alessandro Pasotti w3: www.itopen.it |
|
From: Bill K. <nb...@so...> - 2007-03-05 23:45:16
|
On Mon, Mar 05, 2007 at 08:12:05AM +0100, Alessandro Pasotti wrote: > The problem is somewhat more complex: it's ok that the home button drives > the user to the desktop, it's wrong that the tuxpaint icon doesn't appear in > the toolbar and the user cannot go back to tuxpaint. Ok, thanks for clarifying. > I tried several times to solve this issue (that happens also to other > applications ported to the tablets) without success. I thought Christian Hammond got that working in the OS2005 port...? -bill! |
|
From: Alessandro P. <apa...@gm...> - 2007-03-06 08:38:50
|
Sorry, I don't remember if the problem existed in 2005 edition, but since
they changed a lot of things in the 2006 release it's also possible the
problem arised in the 2006 edition.
BTW I've seen no code modifications that I've not (independently)
implemented in my port, in other words my OS2006 port and the OS2005 port
are almost completely equivalent in terms of code modifications (very few
lines indeed).
It's certainly more a problem of how the menu for hildon desktop is built
than a tuxpaint problem (many other ports are affected by the same issue),
see this post (the reply is form Eero Tamminem @ nokia . com):
> When the user press the hardware Home button, TuxPaint continues to run
> in the background and the user must kill it through a terminal with
> killall -9 tuxpaint
> or reset the device.
> I've tried unsuccessfully differente approachs (libosso), if you know
> how to solve this, please let me know.
Below is copy of my earlier mail to the devel list.
(I think the info is also in Maemo wiki somewere)
It tells how to get back to the application.
- Eero
I spent a while debugging why I cannot switch back to SDL window
from which I've switched away, and noticed that it's actually
easy to fix.
Application switcher needs to know which window matches to which
.desktop file. This is done using the standard WM_CLASS X property.
So, e.g. to be able to switch back to the Bomberman game, you
need to...
Add following line to Bomberman .desktop file for application switcher:
StartupWMClass=Bomberman
And ask SDL to use that WM_CLASS definition for the Bomberman game
window through an environment variable by adding following line
to the "launch-bomberman" script:
export SDL_VIDEO_X11_WMCLASS=Bomberman
I.e. only two lines need to be added and no actual code needs to
be changed!
---
Of course I tried this approach but it doesn't solve the problem.
--
Alessandro Pasotti
w3: www.itopen.it
|
Thanks for helping keep SourceForge clean.
X