tuxpaint-devel Mailing List for Tux Paint (Page 110)
An award-winning drawing program for children of all ages
Brought to you by:
wkendrick
Menu
▾
▴
tuxpaint-devel — General discussion list for Tux Paint developers
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
(15) |
Apr
(5) |
May
(12) |
Jun
(15) |
Jul
(21) |
Aug
(2) |
Sep
(14) |
Oct
(32) |
Nov
(47) |
Dec
(39) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(33) |
Feb
(59) |
Mar
(17) |
Apr
(5) |
May
|
Jun
(6) |
Jul
(7) |
Aug
(19) |
Sep
(64) |
Oct
(161) |
Nov
(9) |
Dec
(23) |
| 2007 |
Jan
(6) |
Feb
(46) |
Mar
(55) |
Apr
(41) |
May
(43) |
Jun
(44) |
Jul
(46) |
Aug
(25) |
Sep
(16) |
Oct
(29) |
Nov
(50) |
Dec
(64) |
| 2008 |
Jan
(11) |
Feb
(18) |
Mar
(52) |
Apr
(37) |
May
(40) |
Jun
(78) |
Jul
(85) |
Aug
(31) |
Sep
(23) |
Oct
(13) |
Nov
(19) |
Dec
(37) |
| 2009 |
Jan
(36) |
Feb
(24) |
Mar
(86) |
Apr
(43) |
May
(36) |
Jun
(151) |
Jul
(23) |
Aug
(40) |
Sep
(11) |
Oct
(91) |
Nov
(68) |
Dec
(27) |
| 2010 |
Jan
|
Feb
(11) |
Mar
(79) |
Apr
(50) |
May
(26) |
Jun
(44) |
Jul
(31) |
Aug
(6) |
Sep
(2) |
Oct
(16) |
Nov
(11) |
Dec
(4) |
| 2011 |
Jan
(14) |
Feb
(5) |
Mar
(22) |
Apr
(1) |
May
(5) |
Jun
(5) |
Jul
(13) |
Aug
(1) |
Sep
(3) |
Oct
(18) |
Nov
(15) |
Dec
(25) |
| 2012 |
Jan
(1) |
Feb
(9) |
Mar
(41) |
Apr
(32) |
May
|
Jun
(2) |
Jul
(5) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2013 |
Jan
|
Feb
(5) |
Mar
(16) |
Apr
(21) |
May
(3) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
(13) |
Nov
(1) |
Dec
(3) |
| 2014 |
Jan
|
Feb
(12) |
Mar
(6) |
Apr
(35) |
May
|
Jun
(12) |
Jul
(35) |
Aug
(98) |
Sep
(3) |
Oct
(8) |
Nov
(4) |
Dec
(1) |
| 2015 |
Jan
(4) |
Feb
(9) |
Mar
(58) |
Apr
(9) |
May
(15) |
Jun
(23) |
Jul
|
Aug
(32) |
Sep
(12) |
Oct
(21) |
Nov
(5) |
Dec
(14) |
| 2016 |
Jan
(6) |
Feb
(3) |
Mar
(37) |
Apr
(18) |
May
(5) |
Jun
(8) |
Jul
|
Aug
(21) |
Sep
(5) |
Oct
(20) |
Nov
(4) |
Dec
(6) |
| 2017 |
Jan
(2) |
Feb
|
Mar
|
Apr
(19) |
May
(8) |
Jun
(3) |
Jul
(3) |
Aug
(5) |
Sep
|
Oct
(4) |
Nov
(4) |
Dec
(6) |
| 2018 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(4) |
Sep
(4) |
Oct
|
Nov
|
Dec
(3) |
| 2019 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
(2) |
Jul
(1) |
Aug
(3) |
Sep
(14) |
Oct
(2) |
Nov
(1) |
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
(2) |
Jun
|
Jul
|
Aug
(3) |
Sep
(15) |
Oct
(9) |
Nov
(11) |
Dec
(7) |
| 2021 |
Jan
(12) |
Feb
(2) |
Mar
(16) |
Apr
|
May
|
Jun
(11) |
Jul
|
Aug
(4) |
Sep
(24) |
Oct
(68) |
Nov
(61) |
Dec
|
| 2022 |
Jan
(42) |
Feb
(17) |
Mar
(20) |
Apr
(2) |
May
(23) |
Jun
(4) |
Jul
(6) |
Aug
|
Sep
(27) |
Oct
(4) |
Nov
(10) |
Dec
(31) |
| 2023 |
Jan
(4) |
Feb
(18) |
Mar
(8) |
Apr
(11) |
May
(18) |
Jun
(47) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(2) |
| 2024 |
Jan
(10) |
Feb
|
Mar
|
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(6) |
Aug
|
Sep
(2) |
Oct
(1) |
Nov
|
Dec
(3) |
| 2025 |
Jan
(2) |
Feb
(11) |
Mar
(3) |
Apr
(1) |
May
(22) |
Jun
(5) |
Jul
(15) |
Aug
(5) |
Sep
|
Oct
(3) |
Nov
|
Dec
|
|
From: Bill K. <nb...@so...> - 2008-06-15 17:47:13
|
On Sun, Jun 15, 2008 at 05:40:27PM +0100, John Popplewell wrote: > CVS Tuxpaint now builds here flawlessly using just 'make' and > 'make install'. Thanks John & everyone! Can you make sure the Win32-related docs in INSTALL.txt are up-to-date, too? Thanks! -- -bill! "Tux Paint" - free children's drawing software for Windows / Mac OS X / Linux! Download it today! http://www.tuxpaint.org/ |
|
From: Bill K. <nb...@so...> - 2008-06-15 17:44:52
|
On Sun, Jun 15, 2008 at 01:18:40PM -0300, Ben Armstrong wrote: > Aha! I *knew* it. Please update ka_docs/COPYING.txt accordingly: Done. :) -bill! |
|
From: Bill K. <nb...@so...> - 2008-06-15 17:39:50
|
On Sun, Jun 15, 2008 at 12:42:18PM -0300, Ben Armstrong wrote: > Hi, > > Please remove the vi.ttf font from the Tux Paint source > distribution until the author licenses it correctly. Done -bill! |
|
From: John P. <jo...@jo...> - 2008-06-15 16:40:31
|
On Sun, Jun 15, 2008 at 11:48:46PM +0800, lee york wrote: > Thanks john > you are right > "RUN_QUERY_MODULES_TEST=false" is the key, > the pango work right now! > thank you! Thanks for getting back to me. I'll update the instructions. I've also added feedback from TOYAMA Shin-ichi related to building libgsf which requires a configure switch --without-python if Python isn't installed (I have Python installed). Regarding the new Tuxpaint Makefile structure (a great improvement!) I've checked in a few Win32 related fixes and updated the build instructions. CVS Tuxpaint now builds here flawlessly using just 'make' and 'make install'. To build the standalone, re-distributable version (as opposed to the development version that only works inside MSYS) just use 'make bdist-win32' as before. I've not thoroughly tested this version but it looks good so far, cheers, John. |
|
From: Ben A. <sy...@sa...> - 2008-06-15 16:18:41
|
Aha! I *knew* it. Please update ka_docs/COPYING.txt accordingly: Begin forwarded message: Date: Thu, 12 Jan 2006 03:46:50 +0300 From: Gia Shervashidze <gi...@te...> To: Ben Armstrong <sy...@sa...> Cc: Bill Kendrick <nb...@so...> Subject: Re: Please update your Tux Paint translations! Ben Armstrong იწერება: >Gia, > >On Thu, 2006-01-12 at 00:42 +0300, Gia Shervashidze wrote: > > >>Sure, my fonts (all of them and their clones used by approx. 4/5 of >>Georgians) since1989 are free, You can do everything with it. >>For me is little bit unclear what's needed from my side? Some special >>procedures? >> >> > >Decide what license they are to be released under. We need to be >assured that users of these fonts have all of the rights that are >described here in the Debian Free Software Guidelines: > >http://www.debian.org/social_contract#guidelines > >The reason I said it might be easier just to release under the GPL is >because Tuxpaint itself is already released under that license. But >really, any license meeting the requirements of the DFSG will do. > >Up until now, what rights the user have has only been stated in vague >terms. For instance, I am told that these fonts can be redistributed >freely, but free redistribution is only one point of the guidelines. >The others need to be addressed too, or else we need to assume users >don't have permission. So please read the guidelines and let us know >more particuarly what we are permitted to do with these fonts. > >Thanks, >Ben Armstrong > > > GPL sounds good for me. By the way, can You recommend me some actual project on [unicode] fonts (Serif, SSerif, Mono) with the same (GPL) license [to try] to include my Georgian fonts? BR, g.\ -- -- ,-. nSLUG http://www.nslug.ns.ca sy...@sa... \`' Debian http://www.debian.org sy...@de... ` [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ] [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ] |
|
From: Ben A. <sy...@sa...> - 2008-06-15 16:03:40
|
I thought we discussed this with Gia before and got more out of him than this, which is not a valid DFSG-free license. Anything that isn't stated is implicitly prohibited. So modification would be prohibited under these terms: COPYING.txt for "tuxpaint-ttf-georgian" Georgian TrueType Font (TTF) for Tux Paint Copyright 2005 Gia Shervashidze (gi...@te...) "all my fonts are (and will be) redistributable." I am pretty sure from talking to Gia that this is not what he intended, but we need something on record from him to include in COPYING.txt that makes this clear. -- ,-. nSLUG http://www.nslug.ns.ca sy...@sa... \`' Debian http://www.debian.org sy...@de... ` [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ] [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ] |
|
From: lee y. <yor...@gm...> - 2008-06-15 15:48:42
|
Thanks john you are right "RUN_QUERY_MODULES_TEST=false" is the key, the pango work right now! thank you! |
|
From: Ben A. <sy...@sa...> - 2008-06-15 15:42:32
|
Hi, Please remove the vi.ttf font from the Tux Paint source distribution until the author licenses it correctly. The web site from which the font is distributed says in the FAQ: 1. Are these fonts copyright? Yes. Although they are free, they are subject to copyright under the GNU License. You may modify the fonts, include glyphs in your own fonts, and even sell your modified versions, but if you do they must also be released under the same GNU License terms. Modified versions must be renamed. Please do not redistribute my fonts, but post a link to this page to ensure that everyone can get the latest versions and other new fonts. However, Bitstream Vera, on which the font is based according to vi_docs/COPYING.txt is not under any GNU license! So the license of this font is invalid (not to mention the fact that the web site links to the FSF's license page without mentioning which one is supposed to apply to the font). I cannot upload the new tuxpaint to Debian until this is resolved (see rejection of my upload below). In fact, I have my work cut out for me today to update the copyright file in the Debian package to include *all* license texts (even ones that I don't distribute in the .debs, as we distribute the source, so the licenses of the others must be included too). So far I have only looked at the ones for which I make debs. There may be problems with others too, and if there are I'll send a separate note. Thanks, Ben Begin forwarded message: Date: Sun, 15 Jun 2008 13:48:19 +0000 From: Joerg Jaspert <ftp...@de...> To: Ben Armstrong <sy...@sa...> Cc: Debian Installer <ins...@ft...> Subject: tuxpaint_0.9.19-1_i386.changes REJECTED Hi Maintainer, rejected, please enhance your copyright file. You may want to read http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html for a bit more information. You also miss some licenses, like for ttf files (use less on default_font.ttf for an example, but thats not the only one.) -- bye Joerg === If you don't understand why your files were rejected, or if the override file requires editing, reply to this email. -- ,-. nSLUG http://www.nslug.ns.ca sy...@sa... \`' Debian http://www.debian.org sy...@de... ` [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ] [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ] |
|
From: John P. <jo...@jo...> - 2008-06-15 14:28:54
|
Hi Lee, I checked my archives and TOYAMA Shin-ichi reported a problem building pango which may be related to your difficulties: > b) Installing Pango > > At the stage of building GTK+, I found that .pc file for Pango > had not been installed. So, I had to turn back to the installation > stage of Pango and edit modules/Makefile to disable some processes > which causes error related to the 'pango-querymodules' before > doing "make install". Did you do something like this? Reviewing my build instructions, I notice that I claim: "A couple of spurious error dialog boxes appear related to the 'pango-querymodules' wrapper script, but it seems that they can be safely ignored." So I may just have been 'lucky' or forgot to document that I copied the .pc file manually, I can't remember. By the time I got to trying to build GTK+ I was tearing my hair out and may have missed a couple of the steps required :-) Unfortunately, I didn't ask TOYAMA Shin-ichi what changes he made to the 'modules/Makefile' to get it to work for him. When I run make to build a clean pango, I get an error dialog: "sh.exe has generated errors and will be closed by Windows. You will need to restart the program. An error log is being created." I just waited for the build to complete, and then closed the dialog. Changing the RUN_QUERY_MODULES_TEST from true to false in modules/Makefile prevented this error. It would appear that running 'pango-querymodules' after make install is then required, and I notice that the instructions include that step before running the GTK+ tests. Hope that helps, good luck, regards, John. PS I build on a Win2K system which may explain this difference in behaviour. On Sun, Jun 15, 2008 at 07:14:20PM +0800, lee york wrote: > thanks! > my platform :windows-xp ,mingw+msys > yes,i forgot to install the freetype2 :P > After install the freetype->SDL_ttf->libxml->fontconfig,it's right now > except the building "pango" package :( > ./configure > make > error : > *Writing a pango.modules file to use with tests/examples. > make[3]: *** [pango.modules] Error 127 > make[3]: Leaving directory `/f/dev/pango-1.17.5/modules' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/f/dev/pango-1.17.5/modules' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/f/dev/pango-1.17.5' > make: *** [all] Error 2 > *I entered the /f/dev/pango-1.17.5/modules and make the directory's files > separately, > then i got the same errors! > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Tuxpaint-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel |
|
From: lee y. <yor...@gm...> - 2008-06-15 11:14:14
|
thanks! my platform :windows-xp ,mingw+msys yes,i forgot to install the freetype2 :P After install the freetype->SDL_ttf->libxml->fontconfig,it's right now except the building "pango" package :( ./configure make error : *Writing a pango.modules file to use with tests/examples. make[3]: *** [pango.modules] Error 127 make[3]: Leaving directory `/f/dev/pango-1.17.5/modules' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/f/dev/pango-1.17.5/modules' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/f/dev/pango-1.17.5' make: *** [all] Error 2 *I entered the /f/dev/pango-1.17.5/modules and make the directory's files separately, then i got the same errors! |
|
From: Bill K. <nb...@so...> - 2008-06-15 04:33:03
|
What platform/version are you building on? (Windows? which? Linux? what distro and which release? etc.) Probably more importantly, what version of FreeType do you have? Google came up a bunch of people have ft2build.h-related issues back in 2004. -bill! On Sun, Jun 15, 2008 at 12:07:11PM +0800, lee york wrote: > hi everyone > when i make the "pango-1.17.5"package > > $ ./configure > $ make > //there are some errors: > In file included from pangofc-font.c:24: > pangofc-font.h:25:22: ft2build.h: No such file or directory > pangofc-font.h:26:10: #include expects "FILENAME" or <FILENAME> > pangofc-font.h:27:35: fontconfig/fontconfig.h: No such file or directory > In file included from pangofc-font.c:24: > pangofc-font.h:72: error: syntax error before "FcPattern" > pangofc-font.h:72: warning: no semicolon at end of struct or union > pangofc-font.h:80: error: syntax error before ':' token > pangofc-font.h:81: error: syntax error before ':' token > ??? > what's the "ft2build.h"???? > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Tuxpaint-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel -- -bill! "Tux Paint" - free children's drawing software for Windows / Mac OS X / Linux! Download it today! http://www.tuxpaint.org/ |
|
From: lee y. <yor...@gm...> - 2008-06-15 04:07:06
|
hi everyone when i make the "pango-1.17.5"package $ ./configure $ make //there are some errors: In file included from pangofc-font.c:24: pangofc-font.h:25:22: ft2build.h: No such file or directory pangofc-font.h:26:10: #include expects "FILENAME" or <FILENAME> pangofc-font.h:27:35: fontconfig/fontconfig.h: No such file or directory In file included from pangofc-font.c:24: pangofc-font.h:72: error: syntax error before "FcPattern" pangofc-font.h:72: warning: no semicolon at end of struct or union pangofc-font.h:80: error: syntax error before ':' token pangofc-font.h:81: error: syntax error before ':' token ??? what's the "ft2build.h"???? |
|
From: Ciaran M. <gen...@go...> - 2008-06-08 11:38:44
|
Hi, The following is from Launchpad Bug Tracker (https://bugs.launchpad.net/ubuntu/+source/tuxpaint/+bug/238279). It is a suggestion from a user. I am afraid I am no developer but thought it best that you guys see this. ---------------------------- Binary package hint: tuxpaint Please add user-friendly way to edit wanted pictures with tuxpaint - currently majority of tuxpaint users can't find a way to edit wanted pictures :( There is command line tool tuxpaint-import , but who from actual tuxpaint users uses command-line nowadays? I'm suggesting simple solution - we can include "Import" command in /usr/share/applications/tuxpaint.desktop file - then users can import wanted pictures into tuxpaint by simple right clicking on picture(s) and Choosing "Import to TuxPaint" from context menu. I can add needed changes to tuxpaint.desktop file and to postinst script (update-desktop-database is needed to regenerate file associations) - just tell me if you like my idea. ---------------------------- Regards, |
|
From: Bill K. <nb...@so...> - 2008-06-04 14:08:58
|
On Wed, Jun 04, 2008 at 03:48:59PM +0800, Shih-Chin Yang wrote: > > Y.S.C.> For now, it appears as a mouse but with absolute (X,Y) > positioning. And it is connected using USB. Ok, then it should probably work with Linux out of the box, I would think. (You can test it yourself -- if you don't have Linux, just get a LiveCD like Knoppix, and boot into Linux temporarily :) ) > Y.S.C. > I saw DACs on Amazon, but I didn't own one. Does it work like a > Wacom tablet? Does it have any pressure sensor? To save cost, I probably > won't put those coloring buttons on the board to keep the tablet simple > and smaller. It does not register as a Wacom tablet -- not one that X-Window on Linux recognizes, at least. The buttons appear as joystick inputs. If I recall, it seemed to appear as an XBox controller...? A friend has mine now, and has spent some occasional time trying to get it to work under Linux. I should get it back from him. :) > Y.S.C. > I would see if I could arrange it. Wow, cool, thank you so much! :) -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |
|
From: Shih-Chin Y. <sya...@gm...> - 2008-06-04 07:48:56
|
Hi, Bill: Thanks for your comments! Please see my comments below ... On Wed, Jun 4, 2008 at 1:14 AM, Bill Kendrick <nb...@so...> wrote: > (Responding to both -devel and -users.) > > On Tue, Jun 03, 2008 at 02:30:26PM +0800, Shih-Chin Yang wrote: > > Hi, Bill: > > Many thanks for your comments. > > > > As a matter of fact, I would like to make the tablet as simple as > > possible, but with features like large drawing area, transparent. The > > tablet would still require a tethered stylus, but not pressure > sensitive. > > Ok, so it's technology closer to a Wacom tablet than a Koala Pad drawing > tablet or a touchscreen (e.g., a CRT at an Automated Teller Machine) > > Y.S.C> Yes, it is closer to a Wacom tablet. > > > Even though the prototype work for windows only for now, but with > proper > > drivers, it could also support Linux, Mac OS etc. And it could work > with > > any software other than TuxPaint. > > How does Windows see the device? I would imagine it would not need to act > much different from a plain pointer input device (like a mouse or > trackball). > Is it (going to) connect(ed) by USB? Y.S.C.> For now, it appears as a mouse but with absolute (X,Y) positioning. And it is connected using USB. > > > The Koala Pad on the Atari 8-bit acted as two Paddle controllers > (potentiometers), one representing X, the other Y. The two buttons on > the Koala Pad acted as Paddle fire buttons (digital on/off). > > Once upon a time I had a little device a friend and I made which allowed me > to connect Atari Paddle controllers to a PC's joystick port (the kind you > used to find on sound cards like the SoundBlaster). I imagine I could have > used the X/Y/Fire of the joystick input on the PC (say, under Linux) to > utilize the Koala Pad. > > Unfortunately, at the time, I had no Koala Pad. And these days, PCs don't > have the old-style analog joystick input. I've got a StellAdapter > (Atari video game/computer system controller to USB converter), but I don't > recall if it supports Paddle inputs... it may only do joystick > (which were 4 digital values on the Atari). > > > > What hardware features(buttons) do you think might help to put on the > > tablet? Other than a plain transparent board? > > Honestly, I don't know! I think keeping it simple would be the best and > most flexible route. > Perhaps I should keep it very simple, a plain board but a ON/OFF button to solve the conflict between mouse and the tablet. Or maybe a Tux Paint quick launch button? > > > Have you looked at the Digital Arts and Crafts Studio's drawing tablet? > It includes an assortment of buttons for choosing colors, tools, etc. > I can map most of those to controls within Tux Paint, but really, Tux Paint > can do so much more than the DACS software can (in some ways, at least), > so those buttons are more of a burden. :) Y.S.C. > I saw DACs on Amazon, but I didn't own one. Does it work like a Wacom tablet? Does it have any pressure sensor? To save cost, I probably won't put those coloring buttons on the board to keep the tablet simple and smaller. > > > What do others out here think of Shin-Chin's device? > > PS - I'd happily accept a prototype to play with. :^D > Y.S.C. > I would see if I could arrange it. > > -bill! > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Tuxpaint-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel > |
|
From: Mark K. K. <mkk...@gm...> - 2008-06-03 20:41:43
|
On Tue, Jun 03, 2008 at 02:30:37PM -0400, Albert Cahalan wrote:
> On Tue, Jun 3, 2008 at 1:06 PM, Bill Kendrick <*************> wrote:
>
> > I think that text entered using this new tool (where text can be edited
> > later, moved around on the fly, etc.) should NOT be affected by Magic tools,
> > or painted over. (Well, ok, if the Move tool or Mirror/Flip tools are used,
> > the X/Y coordinates of the text would change, but that's it!)
>
> Finally we have a layer-like idea that is at least theoretically
> usable by kids and, more importantly, possible to implement.
It sounds reasonable to me, also. Unless others have concerns,
perhaps we can discuss the implementation details (below.)
To summarize, this is going to be a new tool, separate from the text
tool. I believe bill referred to this tool as a "label tool" so that's
the term I'll be using below.
> I'm fairly sure that is still has unusable performance on many
> machines, maybe including the OLPC XO. Crazy optimization
> (use of MMX and 3DNow! assembly) may save the day.
If there are performance concerns, at least for the initial
implementation, we can just "turn it off" at compliation time. For most
desktops I doubt it'll be a problem with some careful design. Handhelds
may be an issue but we won't know how much impact it will have until we
try it out.
> For usability, I think you need to have fixed lines for the text.
> Consider the problem of selecting a small letter with a big
> letter on top of it.
In a private email, Bill had an idea of "repelling labels." At least
for the initial implementation, I think preventing labels from being
written into the same box-area of other labels will be good enough.
Moving labels can also prevent itself from overlapping with other
existing labels. With this mechanism, we don't have to worry about
multiple layers, selecting the correct label when attempting to edit it
when multiple labels overlap, figuring out which label should be on top
of which other label, etc., but it still allows free-placement of
labels (no snapping to predetermined lines.)
HOW THE DATA SHOULD BE SAVED
============================
There are several options here. For simplicity, I think it's best to
have two files:
1a. One PNG file without labels.
1b. Label data embedded into the PNG file as comments. The data
includes the actual string, the coordinate of the string, the font
name of the string, the font size, and the font color.
... with all label data redrawn at open-time.
There are some consequences of saving data this way. One consequence is
that the image file, when opened with another image application, won't
show the labels. We would have to remedy this by having some sort of
"export" option. Another consequence is that the image won't always
look exactly right when opened by Tux Paint on a different computer
because the other computer may not have the right fonts, and depending
on the display size the image and the fonts will need scaling which may
displace the label location.
We could store the image *with* the labels to partially take care of the
latter issue, but that does not entirely solve the issue. For example,
storing the labels with the image allows the image to be viewable from
another computer as the image was originally drawn, but it does not
allow the label to be edited with the same font, and cause the label to
get "mangled" as soon as it is edited.
I think we simply cannot expect everything to work correctly when the
image is opened on a different computer. Given this limitation, I think
the above option (1a + 1b) is the simplest storage mechanism.
Thoughts?
-Mark
|
|
From: Albert C. <aca...@gm...> - 2008-06-03 18:42:19
|
On Tue, Jun 3, 2008 at 1:01 PM, Bill Kendrick <nb...@so...> wrote: > On Tue, Jun 03, 2008 at 03:40:16AM -0400, Albert Cahalan wrote: >> A fine point in time is when another tool gets used. >> Magic tools should have a callback to tell them that >> they should dump any saved state. This gets called as >> soon as some other tool is used. > > Understand that the #1 reason people want an 'editable' text tool is > because merely hitting Undo isn't sufficient. Kids make mistakes, and > want to go back and change or move their text way after the fact. > (i.e., they finish making their drawing, then their teacher comes and > tells them they made a typo or misspelling) They can paint over it. Kids do make mistakes. Facing the consequences is a learning experience. >> I could have used such a callback when I wrote the >> bricks tools. The bricks tools keep track of brick >> relationships so that they can join bricks together, >> but this info must be forgotten when another tool >> modifies the canvas. Currently the bricks tools get >> rid of their state when the mouse button is released, >> which is not ideal. > > In considering how a strokes-to-font tool could work (what I imagine > as a 'stage 1' to Namrata's Big Idea of a writing training tool), > I realize we'd need some means of telling the tool "I'm done with a letter", > after multiple strokes. (We're not doing "one click-and-drag for an entire > letter" like PalmOS Graffiti...) I hope that isn't going in to Tux Paint. It doesn't have even the slightest reason to be part of a paint program. As a stand-alone program, it is somewhat sensible. (subject to the problem of learning without paper) > It occured to me we could put a little 'checkboxs' button next to their > strokes, or at the bottom of the canvas, or somewhere. The Magic Tools > can easily do this (see the crosshairs that appear over the entire canvas > when you use the Move magic tool). However, for this tool to not splat > checkmarks on the drawing when the user happens to switch tools, or hit > Save, or ..., I think we _do_ need a "this tool is finished" clean-up call. That too. "this tool is finished" is distinct from "some other tool has mucked with the canvas". The "some other tool has mucked with the canvas" case might best be attached to the history mechanism. The history gets a pair of pointers for each undo level. One pointer is tool-private data. The other pointer is a clean-up function. |
|
From: Albert C. <aca...@gm...> - 2008-06-03 18:30:32
|
On Tue, Jun 3, 2008 at 1:06 PM, Bill Kendrick <nb...@so...> wrote: > I think that text entered using this new tool (where text can be edited > later, moved around on the fly, etc.) should NOT be affected by Magic tools, > or painted over. (Well, ok, if the Move tool or Mirror/Flip tools are used, > the X/Y coordinates of the text would change, but that's it!) Finally we have a layer-like idea that is at least theoretically usable by kids and, more importantly, possible to implement. I'm fairly sure that is still has unusable performance on many machines, maybe including the OLPC XO. Crazy optimization (use of MMX and 3DNow! assembly) may save the day. For usability, I think you need to have fixed lines for the text. Consider the problem of selecting a small letter with a big letter on top of it. |
|
From: Bill K. <nb...@so...> - 2008-06-03 17:14:06
|
(Responding to both -devel and -users.) On Tue, Jun 03, 2008 at 02:30:26PM +0800, Shih-Chin Yang wrote: > Hi, Bill: > Many thanks for your comments. > > As a matter of fact, I would like to make the tablet as simple as > possible, but with features like large drawing area, transparent. The > tablet would still require a tethered stylus, but not pressure sensitive. Ok, so it's technology closer to a Wacom tablet than a Koala Pad drawing tablet or a touchscreen (e.g., a CRT at an Automated Teller Machine) > Even though the prototype work for windows only for now, but with proper > drivers, it could also support Linux, Mac OS etc. And it could work with > any software other than TuxPaint. How does Windows see the device? I would imagine it would not need to act much different from a plain pointer input device (like a mouse or trackball). Is it (going to) connect(ed) by USB? The Koala Pad on the Atari 8-bit acted as two Paddle controllers (potentiometers), one representing X, the other Y. The two buttons on the Koala Pad acted as Paddle fire buttons (digital on/off). Once upon a time I had a little device a friend and I made which allowed me to connect Atari Paddle controllers to a PC's joystick port (the kind you used to find on sound cards like the SoundBlaster). I imagine I could have used the X/Y/Fire of the joystick input on the PC (say, under Linux) to utilize the Koala Pad. Unfortunately, at the time, I had no Koala Pad. And these days, PCs don't have the old-style analog joystick input. I've got a StellAdapter (Atari video game/computer system controller to USB converter), but I don't recall if it supports Paddle inputs... it may only do joystick (which were 4 digital values on the Atari). > What hardware features(buttons) do you think might help to put on the > tablet? Other than a plain transparent board? Honestly, I don't know! I think keeping it simple would be the best and most flexible route. Have you looked at the Digital Arts and Crafts Studio's drawing tablet? It includes an assortment of buttons for choosing colors, tools, etc. I can map most of those to controls within Tux Paint, but really, Tux Paint can do so much more than the DACS software can (in some ways, at least), so those buttons are more of a burden. :) What do others out here think of Shin-Chin's device? PS - I'd happily accept a prototype to play with. :^D -bill! |
|
From: Bill K. <nb...@so...> - 2008-06-03 17:06:25
|
On Sat, May 31, 2008 at 11:47:47AM +0530, vudem arun wrote: > I am also thinking of ways in which we change the background image > when text is selected. The problem that we face here is as follows: > Suppose the text is entered, and smudge is applied in the area of the > text. I think that text entered using this new tool (where text can be edited later, moved around on the fly, etc.) should NOT be affected by Magic tools, or painted over. (Well, ok, if the Move tool or Mirror/Flip tools are used, the X/Y coordinates of the text would change, but that's it!) My thought is that we could call this the "Label" tool. The text acts like it's on a separate layer, similar to the coloring-book-style starter images. (Except those literally get applied to the final drawing canvas after every other draw event. The Label text would NEVER get applied to the drawing canvas, except during Save -- either as an arbitary "ok, you can never edit that text again", which I don't love, but would be ok with for the time being, or as a kind of 'export'... i.e., you'd end up with three files: canvas, text data, canvas with text blitted on it (suitable for use in other applications, web, email, etc.)) -bill! |
|
From: Bill K. <nb...@so...> - 2008-06-03 17:01:52
|
On Tue, Jun 03, 2008 at 03:40:16AM -0400, Albert Cahalan wrote: > > A fine point in time is when another tool gets used. > Magic tools should have a callback to tell them that > they should dump any saved state. This gets called as > soon as some other tool is used. Understand that the #1 reason people want an 'editable' text tool is because merely hitting Undo isn't sufficient. Kids make mistakes, and want to go back and change or move their text way after the fact. (i.e., they finish making their drawing, then their teacher comes and tells them they made a typo or misspelling) > I could have used such a callback when I wrote the > bricks tools. The bricks tools keep track of brick > relationships so that they can join bricks together, > but this info must be forgotten when another tool > modifies the canvas. Currently the bricks tools get > rid of their state when the mouse button is released, > which is not ideal. In considering how a strokes-to-font tool could work (what I imagine as a 'stage 1' to Namrata's Big Idea of a writing training tool), I realize we'd need some means of telling the tool "I'm done with a letter", after multiple strokes. (We're not doing "one click-and-drag for an entire letter" like PalmOS Graffiti...) It occured to me we could put a little 'checkboxs' button next to their strokes, or at the bottom of the canvas, or somewhere. The Magic Tools can easily do this (see the crosshairs that appear over the entire canvas when you use the Move magic tool). However, for this tool to not splat checkmarks on the drawing when the user happens to switch tools, or hit Save, or ..., I think we _do_ need a "this tool is finished" clean-up call. -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |
|
From: Pere P. i C. <pe...@fo...> - 2008-06-03 11:37:08
|
Hi! El ds 31 de 05 de 2008 a les 11:47 +0530, en/na vudem arun va escriure: > I am also thinking of ways in which we change the background image > when text is selected. The problem that we face here is as follows: > Suppose the text is entered, and smudge is applied in the area of the > text. What about editing in "correction mode"? Say draw just the changed letter(s) in a contrasted background. No layers needed, no need to go backwards to know if some tool has covered any part of the text, just keep the information of it and draw the changed portion. My two cents. Pere |
|
From: Albert C. <aca...@gm...> - 2008-06-03 07:40:14
|
On Mon, Jun 2, 2008 at 4:12 PM, Mark K. Kim <mkk...@gm...> wrote: > On Sat, May 31, 2008 at 04:52:42AM -0400, Albert Cahalan wrote: >> On Sat, May 31, 2008 at 2:17 AM, vudem arun wrote: >>> About being able to select the text long long time after the >>> text has been entered. We could save the data in the list >>> where information about the text is present. Now when open >>> is used and the corresponding drawing along with the list >>> informations gets loaded. Thus it can be edited. but with >>> support for system dialogs coming up and renaming of files >>> being a possibility this will not be good enough. Is there >>> someway in which we ca handle this problem. >> >> There is no "undo" support for freshly loaded files. >> The history is not saved with the image. > > Albert's statement is technically correct, but I think he > may have misunderstood Arunodai's email. Arunodai is specifically > referring to the mechanism of storing the text data, > so the text data can be edited later, not for undo operations. I understood. I consider the problem to be one and the same. A saved+loaded file does not have all the history with it. >>> The file naming convention could be kept simple like all >>> the files related to xxx.png could be xxx-lyyy.png where >>> yyy would be the layer number. Can we work around this so >>> that the same filename cannot be used in a different directory. >>> All the other files could b e saved in the current tuxpaint >>> saving directory except the whole drawing. >> >> Don't go there. (big mess) > > I agree creating several files for each drawing will be messy, but I > think the alternatives aren't much better. The text data, if we want > the text to be editable across saving, will need to be saved. This "editable across saving" idea is extremely bad. > Arunodai's proposal is to create one file per layer, where multiple > layers are required to store all the texts at different layers. The > alternatives are: > > 1. Choose a file format that can support layers so that only a single > file is created. MNG, XCF, etc. > > 2. Save all non-text data into a single file in a proprietary format, > so only two files are created. > > 3. Don't do layers. When the image is saved, it's saved in a single > layer, with no further editing of text upon re-opening of the file. > > 4. Save all extra data into PNG's meta-data area. > > I would like #3, but Bill wants the text editable a long time after it > is entered. Barring #3, other options will take long time to implement > correctly. I only see multi-file format as the only other option. > Please suggest other options if there are other viable options. "don't" is best by far, followed by custom PNG tags, followed by "tell people to use Kid Pix instead of Tux Paint". > All these are valid concerns. Perhaps the thing to do here, given the > complications, is to allow text to be edited until a specific point > (e.g., until the text tool is de-selected) for the initial > implementation. A fine point in time is when another tool gets used. Magic tools should have a callback to tell them that they should dump any saved state. This gets called as soon as some other tool is used. I could have used such a callback when I wrote the bricks tools. The bricks tools keep track of brick relationships so that they can join bricks together, but this info must be forgotten when another tool modifies the canvas. Currently the bricks tools get rid of their state when the mouse button is released, which is not ideal. > That way we can defer the file storage and magic-tool > interaction issues for another time. Right. Let's plan to implement that on April 1, 2099. > My biggest concern, as the mentor for this project, is that I think the > file storage and magic-tool interaction issues are difficult problems > that we won't have time to work out thoroughly during the GSoC period. > Bill/Arunodai - would you guys be okay with this for now? The other > features can be implemented as time allows, whether it be during GSoC or > following it. Google says "Changes to milestones and your original project plan are expected as part of the program." I don't think that excludes picking something else to do. |
|
From: Shih-Chin Y. <sya...@gm...> - 2008-06-03 06:34:36
|
Hi, Bill: Many thanks for your comments. As a matter of fact, I would like to make the tablet as simple as possible, but with features like large drawing area, transparent. The tablet would still require a tethered stylus, but not pressure sensitive. Even though the prototype work for windows only for now, but with proper drivers, it could also support Linux, Mac OS etc. And it could work with any software other than TuxPaint. What hardware features(buttons) do you think might help to put on the tablet? Other than a plain transparent board? Best regards, Shih-Chin On Tue, Jun 3, 2008 at 1:25 PM, Bill Kendrick <nb...@so...> wrote: > On Tue, Jun 03, 2008 at 10:27:36AM +0800, Shih-Chin Yang wrote: > > Dear all: > > I found Tuxpaint to be a very good software for kids, but it might be > a > > bit difficult for kids to use mouse to draw on TuxPaint, > > > > I have been working on a technology to offer an economic tablet for > kids. > > For the prototype, you could see the video demo at > > > > http://www.imareader.com/coopaint.html > > WOW! So I've thought about this a bit, lately. I'm not sure if you're > familiar with the Koala Pad touchpad for 8-bit computers back in the early > 1980s, but after looking at: > > * Wacom drawing tablets > * Digital Arts & Crafts Studio drawing tablet [a recent product, for > Windows] > * My son's Manga-Doodle magnetic drawing toy > > ... I started thinking that a much simpler, much cheaper drawing pad should > exist for kids. > > It would not need pressure sensitivity, tilt, or multiple inputs. I > figured > that the technology behind the Koala pad (a pressure-sensitive pad that > provided X/Y coordinates -- which you could use with your fingers, and not > just with a stylus -- and a button for 'clicking') would be sufficient. > > I'm very curious to learn more about your tablet's features. > Does it do pressure? Is a stylus required, or can you use your fingers? > What platforms does it (or will it / can it) support? (Linux? OS X?) > > $39 is a little steep, compared to the $50 or 55 we paid for the > Digital Arts & Crafts Studio (that included software). But on the > other hand, it looks like you've got an enormous surface area for > drawing compared to the lowest-end Wacom tablets (and your device is > not 'kid-oriented' and goofy, and sounds like it would work with any > software -- the DACS device is meant only for DACS software, though I > hope to change that, some day :^) ) > > > <snip> > > I plan to make a product using the technology, but think I had better > to > > do some market research before doing. Do you think if parents would > buy a > > $39.99 tablet for kids to explore their creativity using TuxPaint? > > Feel free to pose this same question to our 'tuxpaint-users' mailing list. > Also, I assume you don't mind if I share the link to your site, since > you've > already posted it here, to a public forum. :) > > Thanks, and good luck, and keep in touch! > > PS - Have you tested using your device on top of an LCD screen or laptop? > (Since it's transparent, I can see it acting as an alternative to > tablet PCs or 'touchscreens'.) > > -- > -bill! > bi...@ne... > http://www.newbreedsoftware.com/ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Tuxpaint-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel > |
|
From: Bill K. <nb...@so...> - 2008-06-03 05:25:36
|
On Tue, Jun 03, 2008 at 10:27:36AM +0800, Shih-Chin Yang wrote: > Dear all: > I found Tuxpaint to be a very good software for kids, but it might be a > bit difficult for kids to use mouse to draw on TuxPaint, > > I have been working on a technology to offer an economic tablet for kids. > For the prototype, you could see the video demo at > > http://www.imareader.com/coopaint.html WOW! So I've thought about this a bit, lately. I'm not sure if you're familiar with the Koala Pad touchpad for 8-bit computers back in the early 1980s, but after looking at: * Wacom drawing tablets * Digital Arts & Crafts Studio drawing tablet [a recent product, for Windows] * My son's Manga-Doodle magnetic drawing toy ... I started thinking that a much simpler, much cheaper drawing pad should exist for kids. It would not need pressure sensitivity, tilt, or multiple inputs. I figured that the technology behind the Koala pad (a pressure-sensitive pad that provided X/Y coordinates -- which you could use with your fingers, and not just with a stylus -- and a button for 'clicking') would be sufficient. I'm very curious to learn more about your tablet's features. Does it do pressure? Is a stylus required, or can you use your fingers? What platforms does it (or will it / can it) support? (Linux? OS X?) $39 is a little steep, compared to the $50 or 55 we paid for the Digital Arts & Crafts Studio (that included software). But on the other hand, it looks like you've got an enormous surface area for drawing compared to the lowest-end Wacom tablets (and your device is not 'kid-oriented' and goofy, and sounds like it would work with any software -- the DACS device is meant only for DACS software, though I hope to change that, some day :^) ) <snip> > I plan to make a product using the technology, but think I had better to > do some market research before doing. Do you think if parents would buy a > $39.99 tablet for kids to explore their creativity using TuxPaint? Feel free to pose this same question to our 'tuxpaint-users' mailing list. Also, I assume you don't mind if I share the link to your site, since you've already posted it here, to a public forum. :) Thanks, and good luck, and keep in touch! PS - Have you tested using your device on top of an LCD screen or laptop? (Since it's transparent, I can see it acting as an alternative to tablet PCs or 'touchscreens'.) -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |
49 messages has been excluded from this view by a project administrator.
