You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(16) |
Jul
(5) |
Aug
(9) |
Sep
(22) |
Oct
(14) |
Nov
(20) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(7) |
Feb
(2) |
Mar
(18) |
Apr
(15) |
May
(8) |
Jun
(2) |
Jul
(15) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(5) |
Dec
(5) |
2005 |
Jan
(8) |
Feb
(3) |
Mar
(1) |
Apr
(2) |
May
(1) |
Jun
(2) |
Jul
|
Aug
(14) |
Sep
(6) |
Oct
(42) |
Nov
(6) |
Dec
(1) |
2006 |
Jan
(12) |
Feb
(6) |
Mar
(1) |
Apr
(16) |
May
|
Jun
(4) |
Jul
(26) |
Aug
(4) |
Sep
(2) |
Oct
(9) |
Nov
(8) |
Dec
(10) |
2007 |
Jan
(4) |
Feb
(21) |
Mar
(12) |
Apr
(1) |
May
(13) |
Jun
(7) |
Jul
(1) |
Aug
(6) |
Sep
(10) |
Oct
(10) |
Nov
(8) |
Dec
|
2008 |
Jan
|
Feb
(8) |
Mar
(1) |
Apr
(7) |
May
(2) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
2009 |
Jan
|
Feb
(6) |
Mar
(14) |
Apr
(3) |
May
(18) |
Jun
(8) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(2) |
2010 |
Jan
(1) |
Feb
(9) |
Mar
(21) |
Apr
|
May
|
Jun
(4) |
Jul
(10) |
Aug
(6) |
Sep
|
Oct
(5) |
Nov
|
Dec
|
2011 |
Jan
(3) |
Feb
(1) |
Mar
|
Apr
|
May
(3) |
Jun
(2) |
Jul
(1) |
Aug
(10) |
Sep
(3) |
Oct
(1) |
Nov
|
Dec
(1) |
2012 |
Jan
(4) |
Feb
(2) |
Mar
(2) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
(5) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2015 |
Jan
(3) |
Feb
(3) |
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(2) |
Dec
(2) |
2016 |
Jan
(6) |
Feb
|
Mar
|
Apr
|
May
(5) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
|
2017 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(12) |
Dec
|
2021 |
Jan
(1) |
Feb
|
Mar
(12) |
Apr
|
May
|
Jun
(17) |
Jul
(17) |
Aug
(11) |
Sep
(1) |
Oct
(2) |
Nov
(4) |
Dec
(2) |
2022 |
Jan
(12) |
Feb
(12) |
Mar
(12) |
Apr
(5) |
May
(1) |
Jun
|
Jul
|
Aug
(29) |
Sep
(6) |
Oct
|
Nov
(4) |
Dec
|
2023 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
(16) |
Sep
|
Oct
(13) |
Nov
|
Dec
|
2024 |
Jan
(4) |
Feb
(21) |
Mar
(12) |
Apr
(22) |
May
|
Jun
(17) |
Jul
(16) |
Aug
(13) |
Sep
(5) |
Oct
(1) |
Nov
|
Dec
(15) |
2025 |
Jan
(3) |
Feb
(1) |
Mar
(11) |
Apr
(4) |
May
(1) |
Jun
(10) |
Jul
(8) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <and...@bl...> - 2025-03-25 08:37:14
|
Hi Dima Yes, Fl_Valuator cannot be used on its own and should be derived from. This is, for instance, what has been done with Fl_Adjuster, which is derived from Fl_Valuator. Of course, we could also derive from Fl_Valuator directly in Python, I can try to do that once in order to see what is happening. Best regards Andreas > Dima Kogan <di...@se...> hat am 25.03.2025 06:27 CET geschrieben: > > > and...@bl... writes: > > > Please have a look at test/adjuster.py, there is a simple example. > > Please let me know if I misunderstood something there. > > I think this is different Fl_Valuator::format() is a virtual function > that needs an override. So we need to subclass Fl_Valuator, and define > our own format(). And our format() needs to somehow write its output to > the char* in the argument. Can we do THAT? > > > _______________________________________________ > Pyfltk-user mailing list > Pyf...@li... > https://lists.sourceforge.net/lists/listinfo/pyfltk-user |
From: Dima K. <di...@se...> - 2025-03-25 05:27:34
|
and...@bl... writes: > Please have a look at test/adjuster.py, there is a simple example. > Please let me know if I misunderstood something there. I think this is different Fl_Valuator::format() is a virtual function that needs an override. So we need to subclass Fl_Valuator, and define our own format(). And our format() needs to somehow write its output to the char* in the argument. Can we do THAT? |
From: <and...@bl...> - 2025-03-25 01:06:10
|
Hi Dima Please have a look at test/adjuster.py, there is a simple example. Please let me know if I misunderstood something there. Best regards Andreas > Dima Kogan <di...@se...> hat am 24.03.2025 16:44 CET geschrieben: > > > Wait; successfully providing our own format() works in pyfltk now? Can > you point me to a Python demo that uses pyfltk, and shows this working? > I'm not 100% clear on the syntax. > > > > In my opinion, the best solution would be if fltk would start to use > > standard containers, like std::string, this would alleviate a lot of > > memory related problems and would bring fltk into more modern times. > > That's a comment for the fltk devs. My feeling is that the minimal c++ > usage in fltk is a feature, and is one of the things that differentiates > it from the other toolkits. But I'm just a user. > > Thanks. > > > _______________________________________________ > Pyfltk-user mailing list > Pyf...@li... > https://lists.sourceforge.net/lists/listinfo/pyfltk-user |
From: Robert A. <ro...@gm...> - 2025-03-24 17:22:02
|
On Mon, Mar 24, 2025 at 6:24 AM <and...@bl...> wrote: ... > In my opinion, the best solution would be if fltk would start to use standard containers, like std::string, this would alleviate a lot of memory related problems and would bring fltk into more modern times. This is happening in 1.5. There is a long thread here https://groups.google.com/g/fltkcoredev/c/7oADtBkmLGw The FLTK devs decided to include std::string and std::vector into the API and require C++11 in the next major version 1.5. |
From: Dima K. <di...@se...> - 2025-03-24 16:01:40
|
Wait; successfully providing our own format() works in pyfltk now? Can you point me to a Python demo that uses pyfltk, and shows this working? I'm not 100% clear on the syntax. > In my opinion, the best solution would be if fltk would start to use > standard containers, like std::string, this would alleviate a lot of > memory related problems and would bring fltk into more modern times. That's a comment for the fltk devs. My feeling is that the minimal c++ usage in fltk is a feature, and is one of the things that differentiates it from the other toolkits. But I'm just a user. Thanks. |
From: <and...@bl...> - 2025-03-24 13:42:09
|
Hi Robert Thank you very much for your diligent work. Best regards Andreas > Robert Arkiletian <ro...@gm...> hat am 23.03.2025 21:53 CET geschrieben: > > > pyfltk 1.4.2 is now released. We have wheel packages for 64 bit > Windows available for python 3.10-3.13 on pypi > (https://pypi.org/project/pyfltk/) and also on sourceforge > (https://sourceforge.net/projects/pyfltk/files/pyfltk/pyfltk-1.4.2/). > > MacOS wheel packages should be available within two weeks. > > note: wheel package names are now all lowercase, following pypi rules. > > > _______________________________________________ > Pyfltk-user mailing list > Pyf...@li... > https://lists.sourceforge.net/lists/listinfo/pyfltk-user |
From: <and...@bl...> - 2025-03-24 13:24:09
|
Hi Dima Actually in our latest release V1.4.2 I have changed the implementation slightly. The argument to Fl_Valuator::format is now strictly wrapped as an output parameter in Python. As length, I simply used the prescribed 128bytes. I think this works at the moment but of course it is not a nice solution. As has been correctly remarked in the code snippet for the format method, the length really needed to be provided. In my opinion, the best solution would be if fltk would start to use standard containers, like std::string, this would alleviate a lot of memory related problems and would bring fltk into more modern times. What do you think? Best regards Andreas > Dima Kogan <di...@se...> hat am 23.03.2025 20:32 CET geschrieben: > > > Hello. > > We talked about this earlier, but there was no conclusion, and I'd like > to actually find an answer. > > fltk provides a method to customize the formatting of any valuator > widget by overriding the virtual Fl_Valuator::format() function: > > https://www.fltk.org/doc-1.4/classFl__Valuator.html#aff16a315d6c85c08b01df98ff976f6f9 > > This would need an override. And its output string is returned in the > char* argument. I believe this is currently impossible to do with swig. > You can override the function using a swig director, but the result will > always treat the char* argument as an input, not an output. If that's > wrong, it actually is possible, please tell me. > > If it is impossible, let's suggest an alternative to the upstream fltk > people. Their current format() API needs a fix anyway, since any char* > buffer should also have a buffer size to go with it. Upstream knows > this; look at the comments: > > https://github.com/fltk/fltk/blob/80c73b508c9ac5f3fb2d8cafafffebbf466ea042/src/Fl_Valuator.cxx#L168 > > Would a callback work better with swig? Would WE be happy with that? > > > _______________________________________________ > Pyfltk-user mailing list > Pyf...@li... > https://lists.sourceforge.net/lists/listinfo/pyfltk-user |
From: Robert A. <ro...@gm...> - 2025-03-23 20:53:55
|
pyfltk 1.4.2 is now released. We have wheel packages for 64 bit Windows available for python 3.10-3.13 on pypi (https://pypi.org/project/pyfltk/) and also on sourceforge (https://sourceforge.net/projects/pyfltk/files/pyfltk/pyfltk-1.4.2/). MacOS wheel packages should be available within two weeks. note: wheel package names are now all lowercase, following pypi rules. |
From: Dima K. <di...@se...> - 2025-03-23 19:32:10
|
Hello. We talked about this earlier, but there was no conclusion, and I'd like to actually find an answer. fltk provides a method to customize the formatting of any valuator widget by overriding the virtual Fl_Valuator::format() function: https://www.fltk.org/doc-1.4/classFl__Valuator.html#aff16a315d6c85c08b01df98ff976f6f9 This would need an override. And its output string is returned in the char* argument. I believe this is currently impossible to do with swig. You can override the function using a swig director, but the result will always treat the char* argument as an input, not an output. If that's wrong, it actually is possible, please tell me. If it is impossible, let's suggest an alternative to the upstream fltk people. Their current format() API needs a fix anyway, since any char* buffer should also have a buffer size to go with it. Upstream knows this; look at the comments: https://github.com/fltk/fltk/blob/80c73b508c9ac5f3fb2d8cafafffebbf466ea042/src/Fl_Valuator.cxx#L168 Would a callback work better with swig? Would WE be happy with that? |
From: <pq...@fo...> - 2025-02-01 08:19:18
|
thank you. I tested on another computer and there was no issue. The difference is that one computer has a DPI of 100%, while the other has a DPI of 125%. This should be a problem with fltk. 老枪 pq...@fo... ------------------ 原始邮件 ------------------ 发件人: "pyFltk User Exchange" <and...@bl...>; 发送时间: 2025年1月26日(星期天) 下午5:04 收件人: "pyfltk-user"<pyf...@li...>; 主题: Re: [Pyfltk-user] pyfltk widget size problem Hi there I cannot reproduce that behaviour on my machine. It is also very likely not directly related to pyfltk but might rather be an fltk issue. Have you tried to run the examples that come with fltk and compared the results? Best regards Andreas On 1/26/25 02:44, 老枪 wrote: on my computer, running the same file results in different window sizes run pyFltk-1.4.1.0-cp311-cp311-win_amd64.whl\fltk\test\window.py left: with pyfltk1.3.7, 1.3.9 right: with pyfltk1.4.1 my os: python3.11, chinese windows10 ltsc2019, dpi=125 老枪 pq...@fo... _______________________________________________ Pyfltk-user mailing list Pyf...@li... https://lists.sourceforge.net/lists/listinfo/pyfltk-user |
From: Andreas H. <and...@bl...> - 2025-01-26 09:06:48
|
Hi there I cannot reproduce that behaviour on my machine. It is also very likely not directly related to pyfltk but might rather be an fltk issue. Have you tried to run the examples that come with fltk and compared the results? Best regards Andreas On 1/26/25 02:44, 老枪 wrote: >> on my computer, running the same file results in different window sizes >> run pyFltk-1.4.1.0-cp311-cp311-win_amd64.whl\fltk\test\window.py >> left: with pyfltk1.3.7, 1.3.9 >> right: with pyfltk1.4.1 >> >> my os: python3.11, chinese windows10 ltsc2019, dpi=125 > >> > > ------------------------------------------------------------------------ > > 老枪 > pq...@fo... > > <https://wx.mail.qq.com/home/index?t=readmail_businesscard_midpage&nocheck=true&name=%E8%80%81%E6%9E%AA&icon=https%3A%2F%2Fp.qlogo.cn%2Fqqmail_head%2FajNVdqHZLLAR9sfZ2DN5ToAzB57yLY6pfAXkvl438HZJUzbC8iciaI4ib8cqgqRQ7ba%2F160%2F&mail=pqwer99%40foxmail.com&code=QM0YbCQp_h91Trju_E1jIW-4n-zKn6KgkAyBn-LBLi2V4e7rE5Y7edle6szhQs1kSqNjCD_H3mt5fkj5vKNpmnon_ENFYvh2pPB-OAZ7oKQ> > > > _______________________________________________ > Pyfltk-user mailing list > Pyf...@li... > https://lists.sourceforge.net/lists/listinfo/pyfltk-user |
From: <pq...@fo...> - 2025-01-26 01:48:42
|
on my computer, running the same file results in different window sizes run pyFltk-1.4.1.0-cp311-cp311-win_amd64.whl\fltk\test\window.py left: with pyfltk1.3.7, 1.3.9 right: with pyfltk1.4.1 my os: python3.11, chinese windows10 ltsc2019, dpi=125 老枪 pq...@fo... |
From: Gonzalo G. <gga...@gm...> - 2025-01-03 01:43:22
|
I thought from the conversation with Matt that this issue was properly fixed. Or is it something we just have to live with? BTW… compiling from latest git. — Gonzalo Garramuno gga...@gm... |
From: Andreas H. <and...@bl...> - 2024-12-30 09:01:22
|
<div dir='auto'><div>Hi Gonzalo</div><div dir="auto"><br></div><div dir="auto">The idea was to migrate everything to git, including all the branches and the complete history. Afterwards, svn would be locked and eventually be deleted. However, if you still would need access to svn for some reason then we could discuss that. However, I see it as a problem if we have two systems in parallel, people might end up using the wrong one. </div><div dir="auto"><br></div><div dir="auto">Best regards</div><div dir="auto"><br></div><div dir="auto">Andreas</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 30 Dec 2024 09:38, Gonzalo Garramuño <gga...@gm...> wrote:<br type="attribution" /><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div> <p><br /> </p> <div>On 12/29/2024 10:43 AM, <a href="mailto:andreasheld@bluewin.ch">andreasheld@bluewin.ch</a> wrote:<br /> </div> <blockquote> <div>Dear colleagues </div> <div> </div> <div> Could you please make sure that you have committed everything you need to our SVN? As soon as I get your ok I will then lock the repo and start the migration to git. </div> <div> </div> <div> Best regards </div> <div> </div> <div> Andreas </div> </blockquote> <p>Will the SVN repo still be available for old projects? Or will I need to upgrade my build scripts?</p> <pre>-- Gonzalo Garramuño <a href="mailto:ggarrra13@gmail.com">ggarrra13@gmail.com</a></pre> </div> </blockquote></div><br></div> |
From: Gonzalo G. <gga...@gm...> - 2024-12-30 08:38:51
|
On 12/29/2024 10:43 AM, and...@bl... wrote: > Dear colleagues > Could you please make sure that you have committed everything you need > to our SVN? As soon as I get your ok I will then lock the repo and > start the migration to git. > Best regards > Andreas Will the SVN repo still be available for old projects? Or will I need to upgrade my build scripts? -- Gonzalo Garramuño gga...@gm... |
From: Robert A. <ro...@gm...> - 2024-12-18 07:11:15
|
Hi everyone, We have just released our first version of pyFltk. Version 1.4.1.0. We only have Windows amd64 wheel packages up on Sourceforge and Pypi right now. Hopefully, by next week we will have MacOS packages uploaded. We still have to update the website. Note: I released an incorrectly named version yesterday. It was called pyFltk1.4. I've deleted those files from SF and replaced them with the correctly named ones today. Note that RC releases in the past used "fltk14" as the import string. Current releases have been switched back to using "fltk" as the import string. |
From: Gonzalo G. <gga...@gm...> - 2024-12-18 00:11:31
|
+1 for git. svn (which I used to like) is atrocious compared to it. On 12/17/2024 5:32 PM, Robert Arkiletian wrote: > +1 for git > > On Tue, Dec 17, 2024 at 12:17 PM <and...@bl...> wrote: >> Dear colleagues >> >> Please be aware that I have now promoted the branch fltk1.4 as the new trunk. The previous trunk version is available as branches/fltk1.3.9. >> Development will now continue in trunk, covering fltk1.4. >> As SVN is now quite outdated, what do you think about moving to git slowly? I would still want to keep SourceForge as the hosting si >> >> Best regards >> >> Andreas >> >>> Robert Arkiletian <ro...@gm...> hat am 17.12.2024 08:03 CET geschrieben: >>> >>> >>> Hi Andreas, >>> >>> I had some problems with the release specifically on pypi >>> So funny I accidentally made a new project see this >>> https://pypi.org/project/pyFltk1.4/ >>> I will have to figure out how to delete this project. >>> I tried changing the wheels filename to the remove the 1.4 from >>> pyFltk1.4 but pypi refused the wheel file. >>> >>> So fo the time being the naming of the project is now (until I figure >>> out how to delete it) >>> pyFltk1.4 >>> instead of >>> pyFltk >>> I did not do this purposely. If you know the reason please let me >>> know. I think this may be because I'm working with the 1.4 branch >>> instead of trunk on svn. >>> I'm not that good with svn. Can you please create a 1.3 branch and >>> copy trunk to 1.3. Then merge 1.4 into trunk so that 1.4 becomes the >>> main branch. If you're not sure how to I can look into it. >>> >>> I created all the wheels in virtual environments and quickly tested >>> them but I hope they are ok. I will start building macos wheels >>> tomorrow. -- Gonzalo Garramuño gga...@gm... |
From: Robert A. <ro...@gm...> - 2024-12-17 20:33:06
|
+1 for git On Tue, Dec 17, 2024 at 12:17 PM <and...@bl...> wrote: > > Dear colleagues > > Please be aware that I have now promoted the branch fltk1.4 as the new trunk. The previous trunk version is available as branches/fltk1.3.9. > Development will now continue in trunk, covering fltk1.4. > As SVN is now quite outdated, what do you think about moving to git slowly? I would still want to keep SourceForge as the hosting si > > Best regards > > Andreas > > > Robert Arkiletian <ro...@gm...> hat am 17.12.2024 08:03 CET geschrieben: > > > > > > Hi Andreas, > > > > I had some problems with the release specifically on pypi > > So funny I accidentally made a new project see this > > https://pypi.org/project/pyFltk1.4/ > > I will have to figure out how to delete this project. > > I tried changing the wheels filename to the remove the 1.4 from > > pyFltk1.4 but pypi refused the wheel file. > > > > So fo the time being the naming of the project is now (until I figure > > out how to delete it) > > pyFltk1.4 > > instead of > > pyFltk > > I did not do this purposely. If you know the reason please let me > > know. I think this may be because I'm working with the 1.4 branch > > instead of trunk on svn. > > I'm not that good with svn. Can you please create a 1.3 branch and > > copy trunk to 1.3. Then merge 1.4 into trunk so that 1.4 becomes the > > main branch. If you're not sure how to I can look into it. > > > > I created all the wheels in virtual environments and quickly tested > > them but I hope they are ok. I will start building macos wheels > > tomorrow. |
From: <and...@bl...> - 2024-12-17 20:17:25
|
Dear colleagues Please be aware that I have now promoted the branch fltk1.4 as the new trunk. The previous trunk version is available as branches/fltk1.3.9. Development will now continue in trunk, covering fltk1.4. As SVN is now quite outdated, what do you think about moving to git slowly? I would still want to keep SourceForge as the hosting si Best regards Andreas > Robert Arkiletian <ro...@gm...> hat am 17.12.2024 08:03 CET geschrieben: > > > Hi Andreas, > > I had some problems with the release specifically on pypi > So funny I accidentally made a new project see this > https://pypi.org/project/pyFltk1.4/ > I will have to figure out how to delete this project. > I tried changing the wheels filename to the remove the 1.4 from > pyFltk1.4 but pypi refused the wheel file. > > So fo the time being the naming of the project is now (until I figure > out how to delete it) > pyFltk1.4 > instead of > pyFltk > I did not do this purposely. If you know the reason please let me > know. I think this may be because I'm working with the 1.4 branch > instead of trunk on svn. > I'm not that good with svn. Can you please create a 1.3 branch and > copy trunk to 1.3. Then merge 1.4 into trunk so that 1.4 becomes the > main branch. If you're not sure how to I can look into it. > > I created all the wheels in virtual environments and quickly tested > them but I hope they are ok. I will start building macos wheels > tomorrow. |
From: <and...@bl...> - 2024-12-16 19:42:27
|
Hi Gonzalo I have now removed the legacy code, including the weird renames, they should not be needed any more. Actually, swig generates getter and setter by default. However, we have switched this off in line 37 in fltk.i:e %rename("$ignore",%$isvariable) ""; So, I just made sure that the proper swig macros were applied again, but only for the variables that we needed. This you can find in lines 18-29 of Fl.i. Best regards Andreas > Gonzalo Garramuño <gga...@gm...> hat am 15.12.2024 23:24 CET geschrieben: > > > On 12/15/2024 6:35 PM, and...@bl... wrote: > > Still, it is possible to have the getters and setters auto-generated > > and use them through the fget and fset methods, this appears to work. > > You can see the adjusted example in the attachment. If you can live > > with this for the time being then I could commit my changes. > > Seems to work. However, I am curious, what's the swig command that > creates the fget/fset (ie. getters/setters)? > > Right now, I am looking at r653 and the Fl.i still has my code and a > weird rename for my methods. Is this legacy code? > > Either way, the widgets sample you provided should probably go into the > unit tests directory. > > -- > Gonzalo Garramuño > gga...@gm... > > > > _______________________________________________ > Pyfltk-user mailing list > Pyf...@li... > https://lists.sourceforge.net/lists/listinfo/pyfltk-user |
From: Gonzalo G. <gga...@gm...> - 2024-12-15 22:24:29
|
On 12/15/2024 6:35 PM, and...@bl... wrote: > Still, it is possible to have the getters and setters auto-generated > and use them through the fget and fset methods, this appears to work. > You can see the adjusted example in the attachment. If you can live > with this for the time being then I could commit my changes. Seems to work. However, I am curious, what's the swig command that creates the fget/fset (ie. getters/setters)? Right now, I am looking at r653 and the Fl.i still has my code and a weird rename for my methods. Is this legacy code? Either way, the widgets sample you provided should probably go into the unit tests directory. -- Gonzalo Garramuño gga...@gm... |
From: <and...@bl...> - 2024-12-15 21:45:21
|
Hi Matthias Thanks for your tip about the base classes. This was actually the reason for one of the warnings, we simply forgot to wrap the base class. The other warnings are really about interface classes, a concept that Python doesn't know about. I don't think there is much that can be done about that. We would definitely be interested in supporting the generation of Python code with fluid, provided it is geared towards pyFltk of course. Please let us know once you are starting so that we can see how we could help in your work. Best regards Andreas > Matthias Melcher <mm...@ma...> hat am 14.12.2024 18:54 CET geschrieben: > > > What exactly do you need in those classes? The destructurs are virtual in the base classes, so they implicitly exist. As long as we can keep binary compatibility, I can add empty prototypes if that helps. > > Also, we will start 1.5 early next year. Our internal promise is to release early and often in the future. If there are things that will make your life easier, let us know. > > Lastly, I will completely refactor Fluid so that we can add new code writers, including one for Python. Please let me know if there are things to pay attention to. > > Happy coding, > > - Matthias > > > > On 14. Dec 2024, at 16:42, and...@bl... wrote: > > > > Hi Robert > > > > At least the warning for Fl_Valuator we cannot fix, as we need to create a director class here in order to be able to inherit the format method in derived classes. I assume that we are facing a similar problem with Fl_Display_Device. For the last one we could probably ask the fltk team whether they would consider adding a virtual destructor, but this is probably not so important. In short I would suggest to ignore these warnings for the time being. > > By the way, it seems fltk-1.4.1 has now been released: https://www.fltk.org/articles.php?L1959 > > Shall we follow suit and also release what we have? I belive that our code base should be quite stable already and that we have been covering most features of fltk-1.4 > > > > Best regards > > > > Andreas > > > > Best regards > > > > Andreas > > > >> Robert Arkiletian <ro...@gm...> hat am 11.12.2024 00:18 CET geschrieben: > >> > >> > >> Building with latest FLTK 1.4.0-1 release and latest r648 pyFltk > >> > >> OS: Debian 12 x86_64 > >> > >> command: > >> python3 setup.py swig > >> > >> /usr/local/include/FL/Fl_Device.H:118: Warning 314: 'print' is a > >> python keyword, renaming to '_print' > >> ./swig/Fl_Valuator.i:25: Warning 517: Director class 'Fl_Valuator' > >> can't be constructed > >> /usr/local/include/FL/Fl_Device.H:95: Warning 517: Director class > >> 'Fl_Display_Device' can't be constructed > >> /usr/local/include/FL/Fl_Device.H:108: Warning 514: Director base > >> class Fl_Device_Plugin has no virtual destructor. > >> > >> Should we ignore these warnings? Or do they need to be addressed > >> before we release 1.4? > >> > >> > >> _______________________________________________ > >> Pyfltk-user mailing list > >> Pyf...@li... > >> https://lists.sourceforge.net/lists/listinfo/pyfltk-user > > > > > > _______________________________________________ > > Pyfltk-user mailing list > > Pyf...@li... > > https://lists.sourceforge.net/lists/listinfo/pyfltk-user > > Mit freundlichen Grüssen, > > Matthias Melcher > > --- > Geschäftsführer > > M.Melcher GmbH > Hohenbudberger Strasse 4-10 > 47829 Krefeld Uerdingen > > m.m...@go... > > Fon +49 2151 4832 26 > Fax +49 2151 4832 38 > > > > > _______________________________________________ > Pyfltk-user mailing list > Pyf...@li... > https://lists.sourceforge.net/lists/listinfo/pyfltk-user |
From: Robert A. <ro...@gm...> - 2024-12-15 00:19:19
|
On Sat, Dec 14, 2024 at 2:53 PM Gonzalo Garramuño <gga...@gm...> wrote: ... > Hi, Andreas. I verify the code DOES NOT work. I am attaching a simple > widgets sample program showing the issue. > > > I'm going to wait on building wheel packages until this is resolved. |
From: Gonzalo G. <gga...@gm...> - 2024-12-14 22:53:04
|
-------- Forwarded Message -------- Subject: Re: [Pyfltk-user] Getting commit permissions for pyFLTK Date: Sat, 14 Dec 2024 19:37:23 -0300 From: Gonzalo Garramuño <gga...@gm...> To: and...@bl... On 12/14/2024 2:01 PM, and...@bl... wrote: > Hi Gonzalo > > I have now tried to replace your getter and setter methods with proper Python attributes, please see my changes to Fl.i. Could you please try to see whether this works? In general, if you add new functionalities it would also be nice to add some test file in fltk/test. Like this we can always be sure not to have introduced anyregressions. > I have still left your code in Fl.i. If you can confirm that my chnanges are yielding the same result then you should be able to remove your code. > > Best regards > > Andreas Hi, Andreas. I verify the code DOES NOT work. I am attaching a simple widgets sample program showing the issue. -- Gonzalo Garramuño gga...@gm... |
From: Matthias M. <mm...@ma...> - 2024-12-14 18:08:22
|
What exactly do you need in those classes? The destructurs are virtual in the base classes, so they implicitly exist. As long as we can keep binary compatibility, I can add empty prototypes if that helps. Also, we will start 1.5 early next year. Our internal promise is to release early and often in the future. If there are things that will make your life easier, let us know. Lastly, I will completely refactor Fluid so that we can add new code writers, including one for Python. Please let me know if there are things to pay attention to. Happy coding, - Matthias > On 14. Dec 2024, at 16:42, and...@bl... wrote: > > Hi Robert > > At least the warning for Fl_Valuator we cannot fix, as we need to create a director class here in order to be able to inherit the format method in derived classes. I assume that we are facing a similar problem with Fl_Display_Device. For the last one we could probably ask the fltk team whether they would consider adding a virtual destructor, but this is probably not so important. In short I would suggest to ignore these warnings for the time being. > By the way, it seems fltk-1.4.1 has now been released: https://www.fltk.org/articles.php?L1959 > Shall we follow suit and also release what we have? I belive that our code base should be quite stable already and that we have been covering most features of fltk-1.4 > > Best regards > > Andreas > > Best regards > > Andreas > >> Robert Arkiletian <ro...@gm...> hat am 11.12.2024 00:18 CET geschrieben: >> >> >> Building with latest FLTK 1.4.0-1 release and latest r648 pyFltk >> >> OS: Debian 12 x86_64 >> >> command: >> python3 setup.py swig >> >> /usr/local/include/FL/Fl_Device.H:118: Warning 314: 'print' is a >> python keyword, renaming to '_print' >> ./swig/Fl_Valuator.i:25: Warning 517: Director class 'Fl_Valuator' >> can't be constructed >> /usr/local/include/FL/Fl_Device.H:95: Warning 517: Director class >> 'Fl_Display_Device' can't be constructed >> /usr/local/include/FL/Fl_Device.H:108: Warning 514: Director base >> class Fl_Device_Plugin has no virtual destructor. >> >> Should we ignore these warnings? Or do they need to be addressed >> before we release 1.4? >> >> >> _______________________________________________ >> Pyfltk-user mailing list >> Pyf...@li... >> https://lists.sourceforge.net/lists/listinfo/pyfltk-user > > > _______________________________________________ > Pyfltk-user mailing list > Pyf...@li... > https://lists.sourceforge.net/lists/listinfo/pyfltk-user Mit freundlichen Grüssen, Matthias Melcher --- Geschäftsführer M.Melcher GmbH Hohenbudberger Strasse 4-10 47829 Krefeld Uerdingen m.m...@go... Fon +49 2151 4832 26 Fax +49 2151 4832 38 |