tuxpaint-devel Mailing List for Tux Paint (Page 14)
An award-winning drawing program for children of all ages
Brought to you by:
wkendrick
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
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Bill K. <nb...@so...> - 2022-03-09 08:21:40
|
On Wed, Mar 09, 2022 at 01:13:23AM +0100, Pere Pujal i Carabantes wrote: > El dg. 06 de 03 de 2022 a les 22:40 +0900, en/na Shin-ichi TOYAMA va escriure: > > Hi! > > > > I have been thinking it is strange that there are some amount of specific code to convert wide charcter strings to utf-8 strings in render_text_w() from line 1665 to 1740. > > > > ----------------------------------------------------------------- > > /* Convert from 16-bit UNICODE to UTF-8 encoded for SDL_Pango: */ > > > > utfstr_max = (sizeof(char) * 4 * (wcslen(str) + 1)); > > utfstr = (char *)malloc(utfstr_max); > > memset(utfstr, 0, utfstr_max); > > > > < ... many lines ... > > > > > utfstr[j] = '\0'; > > ----------------------------------------------------------------- > > > > Here, we need to use '#ifdef WIN32' to cope with the difference in length of wchar_t between windows and other platforms. > > > > I looked here again, then I have become confident that we can replace all this block with wcstombs() which became safe also on windows by defining it as a native conversion function WideCharToMultiByte(). > > > > ----------------------------------------------------------------- > > /* Convert from 16-bit UNICODE to UTF-8 encoded for SDL_Pango: */ > > > > utfstr_max = (sizeof(char) * 4 * (wcslen(str) + 1)); > > utfstr = (char *)malloc(utfstr_max); > > > > wcstombs(utfstr, str, utfstr_max); > > ----------------------------------------------------------------- > > > > How do you think of it? > > > > Looks much more clear, I don't know why that code was needed but seems wcstombs() currently does the same thing > Note that I've just tested your approach in Linux. > > My 2 cents > Pere Thanks, you two! This stuff is a bit outside my expertise (and I'm also very busy with some big changes at my day job, so my brain is pretty fried by the evening, when I can spend any time on Tux Paint :-D )... so I appreciate your efforts. It would be good, of course, to make sure changes work as expected. Alas, we don't have any kind of unit testing in Tux Paint, so it would have to be manual. So perhaps we can put together a list of things to test, and the process to test each. For example, say: Test 1 * Create 1 label using basic ASCII * Save image * Load image * Confirm label is correct Test 2 * Create 1 label using multibyte characters * Save image * Load image * Confirm label is correct Test 3 * Create 1 label using ASCII * Edit label using ASCII * Save image * Load image * Confirm label is correct ...and so on. I suppose if it were to be put into a big matrix, the things I'm concerned about are: * does it work properly in ASCII? with multibyte? mixed? * does it work properly with one label? multiple labels? * does it work properly after editing a label? And we'd want to ensure it works on our currently-supported platforms: * Linux * Windows * macoS * Android * Haiku Of course, I welcome any other ideas (or alternatives) here! Thanks! -- -bill! Sent from my computer |
From: Pere P. i C. <per...@gm...> - 2022-03-09 00:13:37
|
El dg. 06 de 03 de 2022 a les 22:40 +0900, en/na Shin-ichi TOYAMA va escriure: > Hi! > > I have been thinking it is strange that there are some amount of specific code to convert wide charcter strings to utf-8 strings in render_text_w() from line 1665 to 1740. > > ----------------------------------------------------------------- > /* Convert from 16-bit UNICODE to UTF-8 encoded for SDL_Pango: */ > > utfstr_max = (sizeof(char) * 4 * (wcslen(str) + 1)); > utfstr = (char *)malloc(utfstr_max); > memset(utfstr, 0, utfstr_max); > > < ... many lines ... > > > utfstr[j] = '\0'; > ----------------------------------------------------------------- > > Here, we need to use '#ifdef WIN32' to cope with the difference in length of wchar_t between windows and other platforms. > > I looked here again, then I have become confident that we can replace all this block with wcstombs() which became safe also on windows by defining it as a native conversion function WideCharToMultiByte(). > > ----------------------------------------------------------------- > /* Convert from 16-bit UNICODE to UTF-8 encoded for SDL_Pango: */ > > utfstr_max = (sizeof(char) * 4 * (wcslen(str) + 1)); > utfstr = (char *)malloc(utfstr_max); > > wcstombs(utfstr, str, utfstr_max); > ----------------------------------------------------------------- > > How do you think of it? > Looks much more clear, I don't know why that code was needed but seems wcstombs() currently does the same thing Note that I've just tested your approach in Linux. My 2 cents Pere |
From: Shin-ichi T. <sh...@wm...> - 2022-03-06 13:40:26
|
Hi! I have been thinking it is strange that there are some amount of specific code to convert wide charcter strings to utf-8 strings in render_text_w() from line 1665 to 1740. ----------------------------------------------------------------- /* Convert from 16-bit UNICODE to UTF-8 encoded for SDL_Pango: */ utfstr_max = (sizeof(char) * 4 * (wcslen(str) + 1)); utfstr = (char *)malloc(utfstr_max); memset(utfstr, 0, utfstr_max); < ... many lines ... > utfstr[j] = '\0'; ----------------------------------------------------------------- Here, we need to use '#ifdef WIN32' to cope with the difference in length of wchar_t between windows and other platforms. I looked here again, then I have become confident that we can replace all this block with wcstombs() which became safe also on windows by defining it as a native conversion function WideCharToMultiByte(). ----------------------------------------------------------------- /* Convert from 16-bit UNICODE to UTF-8 encoded for SDL_Pango: */ utfstr_max = (sizeof(char) * 4 * (wcslen(str) + 1)); utfstr = (char *)malloc(utfstr_max); wcstombs(utfstr, str, utfstr_max); ----------------------------------------------------------------- How do you think of it? -- Shin-ichi TOYAMA <sh...@wm...> |
From: Pere P. i C. <per...@gm...> - 2022-03-04 23:49:12
|
Hi, El dj. 03 de 03 de 2022 a les 00:09 -0800, en/na Bill Kendrick va escriure: > > Please pull from the Git repo and try it out and > let me know what you think and (especially) if > you notice any issues with it! Just tested in the sdl2.0 branch, looks nice :) Found some things: When you start it with the default values there are a couple of ghost markers at the top left of colors and top of the value box. When the mouse is over the value box maybe it should have a different cursor, a cross, a hand? When you click and drag in the value box the color doesn't updates until you release, this is different from clicking and dragging in the colored square. HTH Pere |
From: Bill K. <nb...@so...> - 2022-03-03 08:09:58
|
The color picker we had before was simply an image containing ~65,000 colors. It was a very simple solution to letting you pick from many colors, but it wasn't as flexible as a true color chooser. So last night I updated it to be a true HSV-style color picker. The rainbow-colored square represents the hues and saturations, and a separate vertical bar allows you to choose the value. This affects the colors appearing in the rainbow box. The way the interface works has, of course, had to change. (It's no longer simply a matter of clicking a color from the box, because maybe you want to adjust the value first!) So it now includes a green checkmark button, like the new color mixer, along with the "Back" button it had before (which leaves the color for that entry in the palette unchanged). Please pull from the Git repo and try it out and let me know what you think and (especially) if you notice any issues with it! Thanks! -- -bill! Sent from my computer |
From: Bill K. <nb...@so...> - 2022-02-22 07:23:27
|
On Tue, Feb 22, 2022 at 02:24:46AM +0100, Pere Pujal i Carabantes wrote: <snip> > > Correct -- it is still a work-in-progress. I've had to take a > > break from it for a while, > > > > You already had it, just need to blit the label node surface > and disable the edit node Wow, thanks! :) I notice one unwanted effect, which I'll try to sort out this evening, if I can. (If you click the final label, which is highlighted in red, it is applied, but remains outlined until another screen update occurs.) Thanks again! -bill! |
From: Pere P. i C. <per...@gm...> - 2022-02-22 01:24:59
|
El dj. 17 de 02 de 2022 a les 21:19 -0800, en/na Bill Kendrick va escriure: > On Fri, Feb 18, 2022 at 01:00:28AM +0100, Pere Pujal i Carabantes wrote: > > Hi all, > > > > This last month has been a lot of work in master, congrats :) > > Thanks /slash/ apologies! :^D (Glad it wasn't just me, though!) > > > > Today I've just reached to keep sdl2.0 in sync, > > but at the cost of having to solve really big merge conflicts > > and potentially making mistakes, so I would be very grateful if > > you could test the sdl2.0 branch and catch any of them. > > > > Right now, in Linux, I see the onscreen keyboard not sizing > > the same as in master.(tuxpaint --800x600 --onscreen-keyboard) > > > > I also see the apply label not working, it doesn't apply the label, > > but this happens too in master, > > so not sure if this is a bug or is just work in progress. > > Correct -- it is still a work-in-progress. I've had to take a > break from it for a while, > You already had it, just need to blit the label node surface and disable the edit node diff --git a/src/tuxpaint.c b/src/tuxpaint.c index 0ab9e2cf..1b2b5a6c 100644 --- a/src/tuxpaint.c +++ b/src/tuxpaint.c @@ -28441,6 +28441,7 @@ static void apply_label_node(int old_x, int old_y) { cursor_x = old_x; cursor_y = old_y; cursor_left = old_x; + SDL_Rect rect; rec_undo_buffer(); do_render_cur_text(1); @@ -28453,6 +28454,14 @@ static void apply_label_node(int old_x, int old_y) { draw_fonts(); have_to_rec_label_node = TRUE; + + rect.x = label_node_to_edit->save_x; + rect.y = label_node_to_edit->save_y; + rect.w = label_node_to_edit->save_width; + rect.w = label_node_to_edit->save_height; + + SDL_BlitSurface( label_node_to_edit->label_node_surface, NULL, canvas, &rect); + label_node_to_edit->is_enabled = FALSE; add_label_node(0, 0, 0, 0, NULL); derender_node(&label_node_to_edit); label_node_to_edit = NULL; HTH Pere |
From: Mark K. K. <mar...@gm...> - 2022-02-19 17:07:15
|
On Thu, Feb 17, 2022 at 7:00 PM Pere Pujal i Carabantes <per...@gm...> wrote: > test the sdl2.0 branch and catch any of [merge conflicts] > The recent macOS changes have been tested. The merge itself looks good. A couple small issues were found related to differences in the API -- fixed and committed. Thank you for keeping the sdl2 branch in sync. It works great! Mark |
From: Pere P. i C. <per...@gm...> - 2022-02-18 23:15:00
|
El dj. 17 de 02 de 2022 a les 22:06 -0800, en/na Bill Kendrick va escriure: > On Fri, Feb 18, 2022 at 01:00:28AM +0100, Pere Pujal i Carabantes wrote: > > Hi all, > > > > This last month has been a lot of work in master, congrats :) > > Today I've just reached to keep sdl2.0 in sync, > > but at the cost of having to solve really big merge conflicts > > and potentially making mistakes, so I would be very grateful if > > you could test the sdl2.0 branch and catch any of them. > > > > Right now, in Linux, I see the onscreen keyboard not sizing > > the same as in master.(tuxpaint --800x600 --onscreen-keyboard) > > Ah, I see the difference. You're sending "screen", no "canvas" > to "osk_create()" calls in tuxpaint.c. This causes it to try and > take up an amount of space relative to the _window_ (including > the toolbars on the left/right), rather than the canvas. > > I've corrected it in the sdl2.0 branch. > > While I'm at it, I think I've found a bug to fix related > to the OSK! I'll do that in master branch. > > HTH! Indeed, thanks, the Android build broke and now I am trying to fix it but Linux build looks fine :) Thanks Pere |
From: Bill K. <nb...@so...> - 2022-02-18 06:06:31
|
On Fri, Feb 18, 2022 at 01:00:28AM +0100, Pere Pujal i Carabantes wrote: > Hi all, > > This last month has been a lot of work in master, congrats :) > Today I've just reached to keep sdl2.0 in sync, > but at the cost of having to solve really big merge conflicts > and potentially making mistakes, so I would be very grateful if > you could test the sdl2.0 branch and catch any of them. > > Right now, in Linux, I see the onscreen keyboard not sizing > the same as in master.(tuxpaint --800x600 --onscreen-keyboard) Ah, I see the difference. You're sending "screen", no "canvas" to "osk_create()" calls in tuxpaint.c. This causes it to try and take up an amount of space relative to the _window_ (including the toolbars on the left/right), rather than the canvas. I've corrected it in the sdl2.0 branch. While I'm at it, I think I've found a bug to fix related to the OSK! I'll do that in master branch. HTH! -bill! > > I also see the apply label not working, it doesn't apply the label, > but this happens too in master, > so not sure if this is a bug or is just work in progress. > > Thanks > Pere > > > _______________________________________________ > Tuxpaint-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel -- -bill! Sent from my computer |
From: Bill K. <nb...@so...> - 2022-02-18 05:20:06
|
On Fri, Feb 18, 2022 at 01:00:28AM +0100, Pere Pujal i Carabantes wrote: > Hi all, > > This last month has been a lot of work in master, congrats :) Thanks /slash/ apologies! :^D (Glad it wasn't just me, though!) > Today I've just reached to keep sdl2.0 in sync, > but at the cost of having to solve really big merge conflicts > and potentially making mistakes, so I would be very grateful if > you could test the sdl2.0 branch and catch any of them. > > Right now, in Linux, I see the onscreen keyboard not sizing > the same as in master.(tuxpaint --800x600 --onscreen-keyboard) > > I also see the apply label not working, it doesn't apply the label, > but this happens too in master, > so not sure if this is a bug or is just work in progress. Correct -- it is still a work-in-progress. I've had to take a break from it for a while, because it was bending my mind too much, and I kept stumbling across other issues in there. (Thanks to Shin-ichi for helping sort some of it out.) More recently, it came to my attention that the tuxpaint.org website was taking a LOT of bandwidth at the organization that has been hosting it for me. I'm currently simply paying for the extra usage, but spent a lot of time recently compressing content on the site (optimizing images, for example). Eventually I may migrate the virtual server to a different colocation facility, which is cheaper. They've also suggested utilizing a CDN. So I've got all sorts of web tech stuff to think about lately, too. :-D Thanks as always, Pere! -- -bill! Sent from my computer |
From: Shin-ichi T. <sh...@wm...> - 2022-02-18 02:32:19
|
Hi! Thank you for your enormous effort to keep up with the main branch. I gave it a try on windows and confirmed it compile with no problem. One thing I see is that OSK scaling is not working. See screen shot image https://z1.plala.jp/tuxpaint/testing/ss/sdl2osk.png Thanks! On Fri, 18 Feb 2022 01:00:28 +0100, Pere Pujal i Carabantes wrote: >Hi all, > >This last month has been a lot of work in master, congrats :) >Today I've just reached to keep sdl2.0 in sync, >but at the cost of having to solve really big merge conflicts >and potentially making mistakes, so I would be very grateful if >you could test the sdl2.0 branch and catch any of them. > >Right now, in Linux, I see the onscreen keyboard not sizing >the same as in master.(tuxpaint --800x600 --onscreen-keyboard) > >I also see the apply label not working, it doesn't apply the label, >but this happens too in master, >so not sure if this is a bug or is just work in progress. > >Thanks >Pere > > >_______________________________________________ >Tuxpaint-devel mailing list >Tux...@li... >https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel -- Shin-ichi TOYAMA <sh...@wm...> |
From: Pere P. i C. <per...@gm...> - 2022-02-18 00:00:36
|
Hi all, This last month has been a lot of work in master, congrats :) Today I've just reached to keep sdl2.0 in sync, but at the cost of having to solve really big merge conflicts and potentially making mistakes, so I would be very grateful if you could test the sdl2.0 branch and catch any of them. Right now, in Linux, I see the onscreen keyboard not sizing the same as in master.(tuxpaint --800x600 --onscreen-keyboard) I also see the apply label not working, it doesn't apply the label, but this happens too in master, so not sure if this is a bug or is just work in progress. Thanks Pere |
From: Shin-ichi T. <sh...@wm...> - 2022-02-11 23:50:02
|
On Sat, 12 Feb 2022 00:13:40 +0200, ΑΡΕΤΗ ΤΣΟΛΑΚΙΔΟΥ wrote: >Hello again, >Did you bother with the bug that I sent you these days? Do you think that >this bug needs to be a new ticket in the buglist? >Thanks! Thank you for investigating to quite a detail. My personal view is that the text tool does not need to be that sophisticated, because Tux Paint is not a word processer. I think it is better to open a ticket in "Feature Requests" if you want that function to be employed. Thanks! -- Shin-ichi TOYAMA <sh...@wm...> |
From: ΑΡΕΤΗ Τ. <tso...@gm...> - 2022-02-11 22:14:00
|
Hello again, Did you bother with the bug that I sent you these days? Do you think that this bug needs to be a new ticket in the buglist? Thanks! |
From: ΑΡΕΤΗ Τ. <tso...@gm...> - 2022-02-07 18:36:38
|
Hello again, I figured out that in the 'text' tool you can write an endless text that can't be read. That's because the letters are added at the end of the raw which is out of the window. What should be done is that the text must continue in a new raw when the text comes to the end of rhe canvas. Also, in the fonts (on the right of the window) I meet some little boxes and spaces. I'm not sure what's the use of them. Is it a translation problem again? I am sending a screenshot to clarify what I mean. Tell me what you think. Thank you! |
From: Bill K. <nb...@so...> - 2022-02-07 06:08:52
|
On Mon, Feb 07, 2022 at 02:46:54AM +0200, ΑΡΕΤΗ ΤΣΟΛΑΚΙΔΟΥ wrote: > Hello there, > I was working on tux paint this days and I was testing especially on the > 'text' and 'label' tools. What I recognized is that these 2 tools have very > similar uses. Also, I figured that the 'label' tool is more useful than the > 'text'. I think that these things that can be done with 'text' can easily > be done with 'label' too. > I would be glad if you tell me what your opinions are and if you think that > the 'text' tool should be replaced by 'label'. > Thank you! >From a historical perspective, the Text tool came first. It is simpler to use -- once you are done adding text to your drawing, there are no extra UI elements, which could potentially cause confusion in younger users. (This is why the Label tool can be explicitly disabled, as a simplification option.) Many requests came in over the years to add a way to edit and manipulate text after the fact (move it, correct a typo, etc.), beyond simply using the Undo feature, and typing it again. Based on these requests, we added the Label tool. >From a practical perspective, the Label tool provides something different from the Text tool, beyond simply the ability to edit the text after the fact. With the original Text tool, the text becomes "blitted" into the drawing. You may paint over it, manipulate it with various Magic tool effects (blur, blocks, perspective, etc.), just as you can with most everything else that ends up on the canvas. Imagine the Text tool as though you were literally painting words onto your canvas. You can smear or paint over them later. The Label tool is like a clear sheet of glass hovering just in front of your painting, where you can place little stickers containing text. You can move them around after the fact, without changing your painting. However, you cannot paint _over_ them. >From a technical perspective, Label is like a text layer in GIMP. The Text tool is as if you the took your text layer and issue a "Layer -> Discard Text Information" command, followed by a "Layer -> Merge Down" command. So there's definitely no reason to get rid of the Text tool. I do see how it could be useful to provide an option, that caused the same effect as those two GIMP commands above. In other words, a way to take a piece of text written with the Label tool and "apply" it to the canvas, as if it were originally entered using the Text tool ("painted onto the canvas"), once you are happy with it. (Also, I see that the Label tool's interactions lack very many hints (text at the bottom, next to Tux the penguin) on how to use it, which I think should be addressed!) Thanks for your thoughts on this! -- -bill! Sent from my computer |
From: ΑΡΕΤΗ Τ. <tso...@gm...> - 2022-02-07 00:47:15
|
Hello there, I was working on tux paint this days and I was testing especially on the 'text' and 'label' tools. What I recognized is that these 2 tools have very similar uses. Also, I figured that the 'label' tool is more useful than the 'text'. I think that these things that can be done with 'text' can easily be done with 'label' too. I would be glad if you tell me what your opinions are and if you think that the 'text' tool should be replaced by 'label'. Thank you! |
From: Bill K. <nb...@so...> - 2022-02-04 06:39:06
|
On Fri, Feb 04, 2022 at 11:36:52AM +0900, Shin-ichi TOYAMA wrote: > Hi! > > On Fri, 28 Jan 2022 02:40:42 -0800, Bill Kendrick wrote: > >Finally, the color proportions shown at the bottom > >(e.g., "Your color is 1/3 red, 1/3 yellow, and 1/3 blue") > >will now show simplified fractions as alternatives, when possible. > >For example: > > > > Your color is 5/10 (1/2) red, 4/10 (2/5) yellow, and 1/5 black. > > I translated ja.po hoping > > "5/10 (1/2) $B$,(B $B$"$+(B $B$G(B 4/10 (2/5) $B$,(B $B$-$$$m(B $B$G(B 1/10 $B$,(B $B$/$m(B $B$N(B $B$$$m$G$9(B" > > for > > "Your color is 5/10 (1/2) red, 4/10 (2/5) yellow, and 1/10 black." > > but, it appears like > > "Your color is 5/10 (1/2) $B$"$+(B, 4/10 (2/5) $B$-$$$m(B, and 1/10 $B$/$m(B." Hrm, very odd, I see it too! I'll investigate. Thanks, -bill! |
From: Shin-ichi T. <sh...@wm...> - 2022-02-04 02:37:11
|
Hi! On Fri, 28 Jan 2022 02:40:42 -0800, Bill Kendrick wrote: >Finally, the color proportions shown at the bottom >(e.g., "Your color is 1/3 red, 1/3 yellow, and 1/3 blue") >will now show simplified fractions as alternatives, when possible. >For example: > > Your color is 5/10 (1/2) red, 4/10 (2/5) yellow, and 1/5 black. I translated ja.po hoping "5/10 (1/2) が あか で 4/10 (2/5) が きいろ で 1/10 が くろ の いろです" for "Your color is 5/10 (1/2) red, 4/10 (2/5) yellow, and 1/10 black." but, it appears like "Your color is 5/10 (1/2) あか, 4/10 (2/5) きいろ, and 1/10 くろ." |
From: Shin-ichi T. <sh...@wm...> - 2022-02-02 13:43:51
|
Hi! On Sun, 30 Jan 2022 20:28:10 +0100, Pere Pujal i Carabantes wrote: >After some more tests with bindtextdomain, I couldn't make it working >with any of the combinations of the locale string I tested, >maybe you could have more luck. > >What works for me is to use the full path, >copying/adapting some code from chdir_to_binary from tuxpaint.c >and get_fname from fname.c: > > > char curdir[256]; > char f[512]; > > getcwd(curdir, sizeof(curdir)); > #ifdef DEBUG > printf("Current directory at launchtime: %s\n", curdir); > #endif > > snprintf(f, sizeof(f), > "%s%s", > curdir, "\\\\locale\\\\"); > > > bindtextdomain("tuxpaint", f); Committed it to the master branch as follows. +#ifdef WIN32 + // FIXME: After the update of MinGW/MSYS2 in January 2022, gettext() no longer find + // translation (.mo) files unless dirname is specified by full path. + // + // -- 2022/02/02: Shin-ichi TOYAMA & Pere Pujal i Carabantes + char curdir[256]; + char f[512]; + getcwd(curdir, sizeof(curdir)); + snprintf(f, sizeof(f), "%s%s", curdir, "\\locale"); +#ifdef DEBUG + printf("Current directory at launchtime: %s\n", curdir); + printf("Localedir is set to: %s\n", f); +#endif + bindtextdomain("tuxpaint", f); +#else bindtextdomain("tuxpaint", LOCALEDIR); +#endif Thanks!! |
From: Shin-ichi T. <sh...@wm...> - 2022-01-30 23:27:41
|
On Sun, 30 Jan 2022 20:28:10 +0100, Pere Pujal i Carabantes wrote: >> Some progress, when in i18n.c in the bindtextdomain function I set the full path in the windows way,E:\\home\\tuxpaint-sdl2\\win32\\bdist\\locale\\ then it works with the updated mingw >> >> maybe LOCALEDIR that now is locale/ should be changed to locale\\ or maybe just to locale as you say it works in your test > >After some more tests with bindtextdomain, I couldn't make it working >with any of the combinations of the locale string I tested, >maybe you could have more luck. > >What works for me is to use the full path, >copying/adapting some code from chdir_to_binary from tuxpaint.c >and get_fname from fname.c: > > > char curdir[256]; > char f[512]; > > getcwd(curdir, sizeof(curdir)); > #ifdef DEBUG > printf("Current directory at launchtime: %s\n", curdir); > #endif > > snprintf(f, sizeof(f), > "%s%s", > curdir, "\\\\locale\\\\"); > > > bindtextdomain("tuxpaint", f); It worked also for me, thanks!! However, considering the fact that the translation works fine in tuxpaint-config without these efforts, there might be some hidden problem in tuxpaint. Anyway, I will commit your's if we really could not find any other fundamental solution. Thanks!! |
From: Pere P. i C. <per...@gm...> - 2022-01-30 19:28:22
|
El dg. 30 de 01 de 2022 a les 17:23 +0100, en/na Pere Pujal i Carabantes va escriure: > El dg. 30 de 01 de 2022 a les 22:18 +0900, en/na Shin-ichi TOYAMA va escriure: > > Hi! > > > > I tried a test code as follows. > > > > $ cat test.c > > #include <stdio.h> > > #include <libintl.h> > > > > int main(void) > > { > > setlocale(LC_ALL, ""); > > bindtextdomain("tuxpaint", "locale"); > > bind_textdomain_codeset("tuxpaint", "UTF-8"); > > textdomain("tuxpaint"); > > puts(gettext("Yes, I'm done!")); > > return 0; > > } > > > > $ gcc test.c -o test.exe -lintl > > > > I copied this .exe file to the bdist directory and executed it from > > windows command prompt. > > > > Then, it DOES translate. > > > > I am quite at a loss what is happening.... > > Some progress, when in i18n.c in the bindtextdomain function I set the full path in the windows way,E:\\home\\tuxpaint-sdl2\\win32\\bdist\\locale\\ then it works with the updated mingw > > maybe LOCALEDIR that now is locale/ should be changed to locale\\ or maybe just to locale as you say it works in your test After some more tests with bindtextdomain, I couldn't make it working with any of the combinations of the locale string I tested, maybe you could have more luck. What works for me is to use the full path, copying/adapting some code from chdir_to_binary from tuxpaint.c and get_fname from fname.c: char curdir[256]; char f[512]; getcwd(curdir, sizeof(curdir)); #ifdef DEBUG printf("Current directory at launchtime: %s\n", curdir); #endif snprintf(f, sizeof(f), "%s%s", curdir, "\\\\locale\\\\"); bindtextdomain("tuxpaint", f); > > HTH > Pere > > > > > > On Sun, 30 Jan 2022 00:31:53 +0100, Pere Pujal i Carabantes wrote: > > > El ds. 29 de 01 de 2022 a les 10:31 +0900, en/na Shin-ichi TOYAMA va escriure: > > > > Hi! > > > > > > > > I noticed an interesting thing about this issue. > > > > > > > > You can install tuxpaint in /usr/local/bin on MSYS2 environment > > > > as follows. > > > > > > > > $ make && make install > > > > > > I get permission denied, strange > > > /usr/local/bin/tuxpaint.exe --help > > > bash: /usr/local/bin/tuxpaint.exe: Permission denied > > > > > > > > > > > Then it has NO problem with translation!! > > > > > > > > Next, I tried deleting all the .dll files in /mingw64/bin/ except > > > > for those are copied to the win32/bdist directory, suspecting that > > > > there might be some dll(s) newly required by gettext. > > > > > > > > As a result, it still worked fine! > > > > > > > > Considering above, it may not be a library loading issue. > > > > > > I did a different test that seems to lead also to this conclusion: > > > compile a bdist dir with the old mingw, make a backup of it > > > compile another bdist with the new mingw, also backup it > > > create an empty dir and copy there the backup of the non working bdist, > > > then one by one copy the dlls of the working bdist into it > > > until the translations works. > > > > > > the least dlls that I had to copy from the old, working bdist dir are > > > libintl and harfbuzz(wich depends on libintl) > > > > > > > > > > > Could it be that tuxpaint fails to find the translation (.mo) files ? > > > > > > Maybe, but even putting the full locale path in i18n.c I could not get it working > > > > > > Replacing bindtextdomain("tuxpaint", LOCALEDIR); with > > > bindtextdomain("tuxpaint", "/e/home/tuxpaint-sdl2/win32/bdist/locale/"); > > > did not solve things for me. > > > > > > _______________________________________________ > > Tuxpaint-devel mailing list > > Tux...@li... > > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel > |
From: Pere P. i C. <per...@gm...> - 2022-01-30 16:23:53
|
El dg. 30 de 01 de 2022 a les 22:18 +0900, en/na Shin-ichi TOYAMA va escriure: > Hi! > > I tried a test code as follows. > > $ cat test.c > #include <stdio.h> > #include <libintl.h> > > int main(void) > { > setlocale(LC_ALL, ""); > bindtextdomain("tuxpaint", "locale"); > bind_textdomain_codeset("tuxpaint", "UTF-8"); > textdomain("tuxpaint"); > puts(gettext("Yes, I'm done!")); > return 0; > } > > $ gcc test.c -o test.exe -lintl > > I copied this .exe file to the bdist directory and executed it from > windows command prompt. > > Then, it DOES translate. > > I am quite at a loss what is happening.... Some progress, when in i18n.c in the bindtextdomain function I set the full path in the windows way,E:\\home\\tuxpaint-sdl2\\win32\\bdist\\locale\\ then it works with the updated mingw maybe LOCALEDIR that now is locale/ should be changed to locale\\ or maybe just to locale as you say it works in your test HTH Pere > > > On Sun, 30 Jan 2022 00:31:53 +0100, Pere Pujal i Carabantes wrote: > > El ds. 29 de 01 de 2022 a les 10:31 +0900, en/na Shin-ichi TOYAMA va escriure: > > > Hi! > > > > > > I noticed an interesting thing about this issue. > > > > > > You can install tuxpaint in /usr/local/bin on MSYS2 environment > > > as follows. > > > > > > $ make && make install > > > > I get permission denied, strange > > /usr/local/bin/tuxpaint.exe --help > > bash: /usr/local/bin/tuxpaint.exe: Permission denied > > > > > > > > Then it has NO problem with translation!! > > > > > > Next, I tried deleting all the .dll files in /mingw64/bin/ except > > > for those are copied to the win32/bdist directory, suspecting that > > > there might be some dll(s) newly required by gettext. > > > > > > As a result, it still worked fine! > > > > > > Considering above, it may not be a library loading issue. > > > > I did a different test that seems to lead also to this conclusion: > > compile a bdist dir with the old mingw, make a backup of it > > compile another bdist with the new mingw, also backup it > > create an empty dir and copy there the backup of the non working bdist, > > then one by one copy the dlls of the working bdist into it > > until the translations works. > > > > the least dlls that I had to copy from the old, working bdist dir are > > libintl and harfbuzz(wich depends on libintl) > > > > > > > > Could it be that tuxpaint fails to find the translation (.mo) files ? > > > > Maybe, but even putting the full locale path in i18n.c I could not get it working > > > > Replacing bindtextdomain("tuxpaint", LOCALEDIR); with > > bindtextdomain("tuxpaint", "/e/home/tuxpaint-sdl2/win32/bdist/locale/"); > > did not solve things for me. > > > _______________________________________________ > Tuxpaint-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel |