You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
(195) |
Jun
(105) |
Jul
(146) |
Aug
(283) |
Sep
(151) |
Oct
(143) |
Nov
(204) |
Dec
(359) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(213) |
Feb
(366) |
Mar
(423) |
Apr
(226) |
May
(195) |
Jun
(270) |
Jul
(282) |
Aug
(255) |
Sep
(218) |
Oct
(328) |
Nov
(261) |
Dec
(358) |
2002 |
Jan
(366) |
Feb
(321) |
Mar
(360) |
Apr
(219) |
May
(284) |
Jun
(227) |
Jul
(592) |
Aug
(432) |
Sep
(530) |
Oct
(307) |
Nov
(320) |
Dec
(177) |
2003 |
Jan
(253) |
Feb
(164) |
Mar
(216) |
Apr
(295) |
May
(260) |
Jun
(297) |
Jul
(438) |
Aug
(339) |
Sep
(169) |
Oct
(174) |
Nov
(225) |
Dec
(221) |
2004 |
Jan
(517) |
Feb
(613) |
Mar
(320) |
Apr
(193) |
May
(165) |
Jun
(358) |
Jul
(502) |
Aug
(386) |
Sep
(474) |
Oct
(298) |
Nov
(305) |
Dec
(403) |
2005 |
Jan
(274) |
Feb
(409) |
Mar
(282) |
Apr
(430) |
May
(329) |
Jun
(309) |
Jul
(380) |
Aug
(363) |
Sep
(440) |
Oct
(271) |
Nov
(270) |
Dec
(173) |
2006 |
Jan
(185) |
Feb
(187) |
Mar
(213) |
Apr
(253) |
May
(204) |
Jun
(230) |
Jul
(155) |
Aug
(211) |
Sep
(159) |
Oct
(127) |
Nov
(162) |
Dec
(84) |
2007 |
Jan
(98) |
Feb
(105) |
Mar
(137) |
Apr
(88) |
May
(142) |
Jun
(174) |
Jul
(159) |
Aug
(107) |
Sep
(41) |
Oct
(84) |
Nov
(77) |
Dec
(43) |
2008 |
Jan
(106) |
Feb
(80) |
Mar
(78) |
Apr
(182) |
May
(79) |
Jun
(105) |
Jul
(51) |
Aug
(69) |
Sep
(79) |
Oct
(47) |
Nov
(42) |
Dec
(32) |
2009 |
Jan
(64) |
Feb
(41) |
Mar
(42) |
Apr
(40) |
May
(47) |
Jun
(86) |
Jul
(32) |
Aug
(57) |
Sep
(52) |
Oct
(38) |
Nov
(89) |
Dec
(32) |
2010 |
Jan
(30) |
Feb
(34) |
Mar
(23) |
Apr
(24) |
May
(17) |
Jun
(20) |
Jul
(49) |
Aug
(30) |
Sep
(77) |
Oct
(41) |
Nov
(66) |
Dec
(31) |
2011 |
Jan
(36) |
Feb
(34) |
Mar
(10) |
Apr
(55) |
May
(21) |
Jun
(21) |
Jul
(29) |
Aug
(55) |
Sep
(33) |
Oct
(8) |
Nov
(17) |
Dec
(17) |
2012 |
Jan
(7) |
Feb
(15) |
Mar
(23) |
Apr
(14) |
May
(20) |
Jun
(36) |
Jul
(35) |
Aug
(35) |
Sep
(9) |
Oct
(6) |
Nov
(29) |
Dec
(30) |
2013 |
Jan
(36) |
Feb
(19) |
Mar
(5) |
Apr
(15) |
May
(21) |
Jun
(12) |
Jul
(7) |
Aug
(18) |
Sep
(30) |
Oct
(5) |
Nov
(7) |
Dec
(9) |
2014 |
Jan
(11) |
Feb
(15) |
Mar
|
Apr
(1) |
May
(10) |
Jun
(16) |
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
(17) |
Dec
(21) |
2015 |
Jan
(15) |
Feb
(8) |
Mar
(1) |
Apr
(7) |
May
(3) |
Jun
(22) |
Jul
(10) |
Aug
(37) |
Sep
(8) |
Oct
(2) |
Nov
(18) |
Dec
(8) |
2016 |
Jan
(3) |
Feb
(1) |
Mar
(7) |
Apr
(14) |
May
(4) |
Jun
(13) |
Jul
(19) |
Aug
(21) |
Sep
(6) |
Oct
(1) |
Nov
(3) |
Dec
(9) |
2017 |
Jan
(17) |
Feb
(9) |
Mar
(30) |
Apr
(17) |
May
(7) |
Jun
(55) |
Jul
(1) |
Aug
(4) |
Sep
(1) |
Oct
|
Nov
(2) |
Dec
(4) |
2018 |
Jan
(21) |
Feb
(5) |
Mar
(9) |
Apr
(6) |
May
(4) |
Jun
(2) |
Jul
(2) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
(2) |
Dec
(3) |
2019 |
Jan
(2) |
Feb
(6) |
Mar
(9) |
Apr
|
May
(9) |
Jun
(3) |
Jul
(7) |
Aug
(2) |
Sep
(22) |
Oct
|
Nov
(10) |
Dec
(11) |
2020 |
Jan
(10) |
Feb
(6) |
Mar
(31) |
Apr
(27) |
May
(6) |
Jun
(4) |
Jul
(34) |
Aug
(3) |
Sep
|
Oct
(4) |
Nov
(51) |
Dec
(27) |
2021 |
Jan
(5) |
Feb
(3) |
Mar
(9) |
Apr
(18) |
May
(2) |
Jun
|
Jul
(12) |
Aug
(32) |
Sep
(16) |
Oct
(16) |
Nov
(1) |
Dec
(4) |
2022 |
Jan
(2) |
Feb
(12) |
Mar
(10) |
Apr
(17) |
May
|
Jun
(3) |
Jul
(4) |
Aug
|
Sep
(7) |
Oct
(23) |
Nov
(26) |
Dec
(1) |
2023 |
Jan
(7) |
Feb
(9) |
Mar
(4) |
Apr
(18) |
May
(17) |
Jun
(26) |
Jul
(24) |
Aug
(2) |
Sep
(10) |
Oct
(3) |
Nov
(11) |
Dec
(4) |
2024 |
Jan
(2) |
Feb
(13) |
Mar
(2) |
Apr
(14) |
May
(22) |
Jun
|
Jul
(16) |
Aug
(3) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
From: Pof <jd3...@gm...> - 2024-09-09 13:53:45
|
Dear Fox'ers, My app exists since 2005 and was from the start designed with the FoxToolkit for UI design and VTK (https://vtk.org/) for 3D visualization (VTK is a cutting edge visualization toolkit for scientific application). The bridge between FoxToolit and VTK uses *vtkfox*, originally written by Doug Henry, to which Pietro Cerutti applied some updates about 10 years ago (https://github.com/gahr/vtkfox) to make it compatible as VTK library evolved (I also applied some very minor modifications). Basically, *vtkfox* provides a canvas widget class (FXVTKCanvas) and an interactor class (vtkFXRenderWindowInteractor) that allows VTK to interact with FOX application. Keyboard and mouse events are translated to allow for "native" VTK functionality. *vtkfox* perfectly does its job for any FOX version (both in 1.6.x and 1.7.x branches), but currently only for VTK version up to VTK6.1 update (it uses OpenGL version 1.2 only, which leads to rather poor visualisation performance compared to nowadays' standard). So I want to update to a more recent VTK version that supports recent OpenGL versions. I successfully compile and link my app with the recent VTK8.2 version, but it fails at runtime with the following errors: - "failed to get valid pixel format." - "GLEW could not be initialized: Missing GL version" - "Shader object was not initialized, cannot attach it." After many tests, I came to the conclusion that these errors are related to *vtkfox*, which would probably need some update to be compatible with recent VTK versions (it evolved deeply since version 6.1). I have tried fixing these errors, but failed to do so (I am not a true software engineer, only a scientist with some coding skills ;-) ). Anybody would be interested in helping to bridge recent VTK versions to the FoxToolkit? Either updating vtkfox or aware of any another solution? That would really be great :-) I can easily provide a minimal example to anyone who would like to give it a try. Regards, Pof |
From: Pof <jd3...@gm...> - 2024-09-05 21:05:36
|
Thanks the gods;-)! This is a very good news indeed. Pof Le 05/09/2024 à 14:52, fox...@li... a écrit : > Send Foxgui-users mailing list submissions to > fox...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/foxgui-users > or, via email, send a message with subject or body 'help' to > fox...@li... > > You can reach the person managing the list at > fox...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Foxgui-users digest..." > > > Today's Topics: > > 1. Re: Fox Toolkit site down? (je...@fo...) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 04 Sep 2024 11:59:28 -0500 > From: je...@fo... > To: FOX Users <fox...@li...> > Subject: Re: [Foxgui-users] Fox Toolkit site down? > Message-ID: <dd4...@fo...> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > > Seems the gods have smiled upon us and reestablised the internet > connection to fox-toolkit.org. We're back! > > Decided to celebrate this by dropping a new snapshot. Some PNG > support improvements... > > One small issue that was found compiling on ancient Fedora version: > apparently, SSE2 has some new intrinsics that were not in the > original SSE2 intrinsics support. Thus my vectorized decoding/ > encoding didn't work. I've eliminated these intrinsics in favor > of older ways of doing business, and stuff compiles now on older > SSE2 header files. Generated code may actually be similar or > even a bit better. > > The message here is that just because SSE2 has been around forever, > it seems the compiler people may still be introducing new intrinsics > for them. This means your SSE2 code may break on older installations > even though SSE2 is fully supported. > > _mm_loadu_si64(), _mm_storey_si64() did not exist in older emmintrin.h > header files. This was in encodeGrayAlpha7BPP() and encodeGray8BPP(). > > Cheers, > > > -- JVZ > > > > ------------------------------ > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Foxgui-users mailing list > Fox...@li... > https://lists.sourceforge.net/lists/listinfo/foxgui-users > > > ------------------------------ > > End of Foxgui-users Digest, Vol 201, Issue 1 > ******************************************** |
From: <je...@fo...> - 2024-09-04 16:59:35
|
Seems the gods have smiled upon us and reestablised the internet connection to fox-toolkit.org. We're back! Decided to celebrate this by dropping a new snapshot. Some PNG support improvements... One small issue that was found compiling on ancient Fedora version: apparently, SSE2 has some new intrinsics that were not in the original SSE2 intrinsics support. Thus my vectorized decoding/ encoding didn't work. I've eliminated these intrinsics in favor of older ways of doing business, and stuff compiles now on older SSE2 header files. Generated code may actually be similar or even a bit better. The message here is that just because SSE2 has been around forever, it seems the compiler people may still be introducing new intrinsics for them. This means your SSE2 code may break on older installations even though SSE2 is fully supported. _mm_loadu_si64(), _mm_storey_si64() did not exist in older emmintrin.h header files. This was in encodeGrayAlpha7BPP() and encodeGray8BPP(). Cheers, -- JVZ |
From: Jeroen v. d. Z. <je...@fo...> - 2024-08-24 13:33:16
|
On Sat, 24 Aug 2024 04:52:22 -0400 "Jason E. Hale" <jh...@fr...> wrote: > When FXObject.h is simply included, builds fail in projects such as > gogglesmm [1]. In 1.7.85, the inclusion of FXMetaClass.h was removed > from FXObject.h, causing the compiler to no longer recognize > FXSelector as a type in the FX namespace. > > Example error from trying to build gogglesmm with LLVM 18.1.6 on > FreeBSD-CURRENT: > /usr/local/include/fox-1.7/FXObject.h:135:3: fatal error: no type > named 'FXSelector' in namespace 'FX' > 135 | FXDECLARE(FXObject) > | ^~~~~~~~~~~~~~~~~~~ > /usr/local/include/fox-1.7/FXObject.h:50:28: note: expanded from macro > 'FXDECLARE' > 50 | struct FXMapEntry { FX::FXSelector keylo; FX::FXSelector > keyhi; long (classname::* func)(FX::FXObject*,FX::FXSelector,void*); > }; \ > | ~~~~^ > > I've attached a patch to fix the issue and in case the ML scrubs > attachments, the patch can also be found here: > https://people.freebsd.org/~jhale/patches/fox-1.7.85-include-FXObject.h.diff > > [1] https://github.com/gogglesmm/gogglesmm Thanks, fixed that! -- JVZ |
From: Jason E. H. <jh...@fr...> - 2024-08-24 08:52:47
|
When FXObject.h is simply included, builds fail in projects such as gogglesmm [1]. In 1.7.85, the inclusion of FXMetaClass.h was removed from FXObject.h, causing the compiler to no longer recognize FXSelector as a type in the FX namespace. Example error from trying to build gogglesmm with LLVM 18.1.6 on FreeBSD-CURRENT: /usr/local/include/fox-1.7/FXObject.h:135:3: fatal error: no type named 'FXSelector' in namespace 'FX' 135 | FXDECLARE(FXObject) | ^~~~~~~~~~~~~~~~~~~ /usr/local/include/fox-1.7/FXObject.h:50:28: note: expanded from macro 'FXDECLARE' 50 | struct FXMapEntry { FX::FXSelector keylo; FX::FXSelector keyhi; long (classname::* func)(FX::FXObject*,FX::FXSelector,void*); }; \ | ~~~~^ I've attached a patch to fix the issue and in case the ML scrubs attachments, the patch can also be found here: https://people.freebsd.org/~jhale/patches/fox-1.7.85-include-FXObject.h.diff [1] https://github.com/gogglesmm/gogglesmm |
From: Jeroen v. d. Z. <je...@fo...> - 2024-08-16 04:43:22
|
FOX DEVELOPMENT 1.7.85 New PNG image support. First, its faster! Also, it no longer requires libpng; the PNG format support is now built-in, although the libz compression library is still required [for now...]. fxsavePNG() supports some fine-control via new save-flags. You can analyze the image, and shrink output by taking advantage of image features; for example, saving opaque image means alpha-channel may be dropped. If the image is gray-levels only, the RGB may be dropped to plain gray only. Also, shrinking further by emitting colormapped [indexed-color] image is possible if only a few colors are used. Finally, pre-compression filtering, as well as desired compression level can be selected. PNG I/O is optimized with when target ISA x86-64-v2 or higher are selected. FXStat::isSame() checks if two files are the same (same inode). FOX Desktop Calculator augmented with Unicode button labels (please select a font that has the math symbols!), also now supports additional functions, common physics constants, and other features. The fxCPUFeatures now can detect AVX512 presence. New FXPerformanceCounter and associated macros may be used to count clockcyles of critical code segments. FXAtomic.h APIs now mostly inlined for lower overhead. Read processor ticks on AARCH64. Adie text editor undo buffer size and undo buffer items can now be configured. New QOIF (Quite OK Image Format) now supported for either images (FXQOIFImage) or icons (FXQOIFIcon). FXColor to/from FXVec3d, FXVec3f, FXVec4d, FXVec4f now using SSE if compiled for x86-64-v2 or higher. Updated byte swap APIs in fxendian.h. New APIs in FXMat3f, FXMat3d, etc. classes to set up mirror-matrix. Moved new hash32() etc. functions into fxendian.h. Bug fix in FXIODevice reading > 1GB files in one readBlock(), writeBlock() call. Markdown syntax coloring in Adie. Per-syntax mode setting for removing trailing spaces in Adie saving a text file. Subtle change in operation of FXPath::relative(). Support for CRC32 calculations added. Additional conversion options in FXString::fromFloat() and FXString::fromDouble(): thousands groupings, force decimal point, and hexadecimal float output. FXJSON JSON loader now may report duplicate key warning reading json file. FXMappedFile improvements. FXString uncode escapes bug fix. Cheers, -- JVZ |
From: <je...@fo...> - 2024-07-29 12:39:27
|
On 2024-07-28 06:12, Jean Truc wrote: > Hi there, > > I recently upgraded from Ubuntu 22.04 to 24.04 and now some FOX > dialogs appear to have zero size (width and height set to 0). > > > Example: > > (with FOX 1.6.58 self compiled in Ubuntu 22.04) > > Launch adie and select the menu items Search / Search or Search / > Replace => the search or replace dialog have zero size > > Launch calculator => the entire calculator window has zero size > > Launch PathFinder => the Preferences dialog has zero sizer > > > Note that some other dialogs work as expected. > > I investigated a bit and found that the problem started to appear in > Gnome desktop with mutter window manager version 44. > > I tested with openbox or xfwm4 (from Xfce desktop) and I don't see such > issue. > > > Do you think it's a FOX issue? Should I fill a bug report to the > mutter team? Is there some workaround? Yes, you should file a bug report with the mutter WM team. It looks like there is something wrong with their WM. I'm not sure what; either the WM fails to observe the window size attributes, or maybe it fails to give us a configure event that FOX uses to layout the widgets after a WM-determined size. I'm using XFCE most times so have not ran into this issue, -- JVZ |
From: Jean T. <bib...@gm...> - 2024-07-28 11:12:57
|
Hi there, I recently upgraded from Ubuntu 22.04 to 24.04 and now some FOX dialogs appear to have zero size (width and height set to 0). Example: (with FOX 1.6.58 self compiled in Ubuntu 22.04) Launch adie and select the menu items Search / Search or Search / Replace => the search or replace dialog have zero size Launch calculator => the entire calculator window has zero size Launch PathFinder => the Preferences dialog has zero sizer Note that some other dialogs work as expected. I investigated a bit and found that the problem started to appear in Gnome desktop with mutter window manager version 44. I tested with openbox or xfwm4 (from Xfce desktop) and I don't see such issue. Do you think it's a FOX issue? Should I fill a bug report to the mutter team? Is there some workaround? Thanks, RB |
From: Roland H. <ro...@lo...> - 2024-07-26 13:56:16
|
It was a POSIX requirement. Best to put the things in: --start-group --end-group because by default the linker is still single pass. On 7/26/2024 7:18 AM, je...@fo... wrote: > On 2024-07-26 07:04, Roland Hughes via Foxgui-users wrote: >> Unknown if it ever impacted FOX, but many years ago, one had to. Gray >> cells are a bit fuzzy on it, had to do with video card flavored >> libraries and a few third party libraries that would not find one >> library if it was linked ahead of it. >> >> In what could only be an MBA lead "efficiency" move most linkers of >> the day were single pass. While you should never ever under any >> circumstances trust anything on StackOverflow, the answer from this 11 >> year old question with a green check mark and 123 up votes does a >> pretty good job of explaining it. >> >> https://stackoverflow.com/questions/11893996/why-does-the-order-of-l-option-in-gcc-matter >> >> >> Thanks to brain dead AI additions to search engines you can no longer >> search for "how many passes does GNU linker make" without getting >> inundated with links to command line passing. >> >> The comments below that answer tick some memories too. You have to >> remember the x86 has always been and will probably always be the home >> hobby platform. When Intel and Microsoft desperately wanted to get a >> to hold in Fortune 500 data centers they bribed marketing agencies >> like Gartner Group (masquerading as "industry analysts") telling >> companies that systems and libraries needed to conform to "Open >> Standards." Prior to that we had things that actually worked. Your >> OS/400 programs just worked on OS/400. MVS on MVS. VMS on VMS, etc. We >> had screen and other libraries all made by the hardware vendor for the >> hardware and OS we were running on. No, they weren't portable, but >> they "just worked." We used operating systems that were created to be >> robust multi-user platforms that could bill for every byte and clock >> cycle consumed by everyone. It wasn't until MAI, Wang, and a few >> others started going under that portable became something companies >> worried about. We had proprietary security until the vendor went >> under. We also had linkers that operated in one of the following >> manners: >> >> 1) Made N-passes through the libraries trying to resolve external >> linkage. You had a command line switch to limit the maximum number of >> passes. Something says the default for most was up to 4 passes. >> >> 2) Loaded _every_ external linkage item from every library on the >> command line into one big lookup table before linking object files. >> (Our libraries had header areas where all this info was so they were >> only reading a few disk blocks from each, not dynamically parsing >> something.) >> >> 3) Both 1 & 2. Towards the end this was what they all did because >> every time you linked another function from another library it could >> add new external dependencies. >> >> After the bust-up of AT&T, UNIX, originally created on a DEC PDP, >> which was never created to be a true multi-user OS, just to run phone >> switches and allow maintenance to log in to tweak/update things, got >> popped out into the world of "free software." There might have been as >> many as 60 commercial Unix versions that popped up in the weeks/months >> following. Most of them sucked. None of them were worthy of running a >> business on, though some companies tried. These vendors desperately >> wanted to get into the corporate data center as well. That's where the >> real money was. >> >> You may remember a name called SUN Microsystems. When you could cobble >> together a generic PC with 40MEG hard drive and two floppies for >> around $800, SUN was selling $20,000 "engineering workstations" to >> corporations that cost about the same to build. They had cash coming >> out their back side and got behind this "standard." There was no way >> they were ever going to get their >> not-really-multi-user-just-multiple-people-could-log-in system into >> the data center unless they could somehow make that sexy to the ones >> with the checkbooks. >> >> Enter POSIX. >> >> A standard that busted every proprietary OS trying to conform to it >> because the ones holding the checkbooks demanded compliance with it. >> With POSIX we got insecurities, data breaches, and a mandate for a >> single pass linker because that is all the >> not-really-multi-user-just-multiple-people-could-log-in systems could >> manage. >> >> Your latest macOS is not POSIX compliant. You should point it out to >> them since Apple was one of the companies behind POSIX back in the >> day. SUN, creators of Java with seemingly limitless financial >> resources, went bankrupt. >> >> As part of this POSIX world Microsoft wanted to make a standard for >> user interaction. They wanted it to be like their feeble DOS and GUI >> DOS (Windows) was capable of. After the initial POSIX debacle IBM >> flooded the standards committee with employees and customers. That is >> why CUA works exactly like a CICS application on a green screen. We >> tab between fields, have a special ENTER key different from the RETURN >> key, etc. >> >> Why do those of us who worked on real computers have such disdain for >> the x86 platforms despite all of the embedded, Linux, and desktop >> stuff we have written? >> >> On the PDP 11/70 we ran 255 interactive/batch users in 64K-words. The >> PC with DOS and 640K bytes could barely run one. >> >> The current IBM z/OS box, a little shorter and about the same width as >> 2 4-drawer file cabinets can run more users that 2 complete floors of >> machines at any cloud data center in the world. I don't think they >> worried about POSIX compliance. >> >> Sorry, the "why" behind your answer is tangled up in an ugly corrupt >> history of the PC world. It appears macOS has now learned the ugly >> truth. POSIX was meant to cripple, not enhance. >> >> When you are written for the least common denominator and all must >> comply, nobody can soar. >> >> Even GNU has figured this out and quietly hidden their nasty undies >> -- GNU is no longer POSIX compliant. Read up on: >> >> --whole-archive (links everything just like we did with DOS) >> >> --start-group --end-group (make N-passes through these libraries >> trying to resolve linkage) >> >> >> >> On 7/26/2024 2:02 AM, Michael Behrisch via Foxgui-users wrote: >>> Hi, >>> I have a question about the output of "fox-config --libs". >>> On my system it currently gives: "-L/usr/lib64 -lFOX-1.6 -lX11 >>> -lXext -lfreetype -lfontconfig -lXft -lXcursor -lXrender -lXrandr >>> -lXfixes -lXi -lGL -lGLU -ldl -lpthread -lrt -ljpeg -lpng -ltiff -lz >>> -lbz2 -lGLU -lGL" >>> which duplicates the GL and GLU libraries. >>> >>> The problem is that recent macOS builds complain if you link the >>> same library twice. >>> >>> I had a look at the source code in configure.ac and fox-config.in >>> and this seems to be intentional because indeed the GL libraries >>> (LIBGL) are being added to the LIBS variable and then both are >>> output in the end. >>> I removed the first addition of the GL libs and it is still working >>> fine here but before submitting a patch I wanted to ask whether >>> there is a known reason for this duplication because sometimes the >>> linker is tricky. >>> >>> Thank you and best regards, >>> Michael > > > W.r.t. search engines, Google, Bing are no longer search engines. You > won't find anything with these. > > I recommend xmol, presearch, and yandex. > > === > > Yes, it is indeed sometimes necessary to repeat same library, because > sometimes stuff was not possible to be arranged so all references were > forward. > > However, it is possible current linkers are no longer having this > problem; > maybe it was a a.out limitation, or maybe it only applies to .a linkage > and .so links [which are resolved at runtime] do not have this problem... > > > -- JVZ > > > > -- JVZ -- Roland Hughes, President Logikal Solutions (630)-205-1593 (cell) https://theminimumyouneedtoknow.com https://infiniteexposure.net https://johnsmith-book.com |
From: <je...@fo...> - 2024-07-26 12:32:01
|
On 2024-07-26 02:02, Michael Behrisch via Foxgui-users wrote: > Hi, > I have a question about the output of "fox-config --libs". > On my system it currently gives: "-L/usr/lib64 -lFOX-1.6 -lX11 -lXext > -lfreetype -lfontconfig -lXft -lXcursor -lXrender -lXrandr -lXfixes > -lXi -lGL -lGLU -ldl -lpthread -lrt -ljpeg -lpng -ltiff -lz -lbz2 > -lGLU -lGL" > which duplicates the GL and GLU libraries. > > The problem is that recent macOS builds complain if you link the same > library twice. > > I had a look at the source code in configure.ac and fox-config.in and > this seems to be intentional because indeed the GL libraries (LIBGL) > are being added to the LIBS variable and then both are output in the > end. > I removed the first addition of the GL libs and it is still working > fine here but before submitting a patch I wanted to ask whether there > is a known reason for this duplication because sometimes the linker is > tricky. > I think its OK to remove the duplicate. W.r.t. multiple repetitions of the same library, I remember occasionally having to do this for resolving forward referencing, i.e. linker not knowing how to handle 2 libraries mutually referring to each other. Not sure if this is still necessary, linkers have perhaps evolved... -- JVZ |
From: <je...@fo...> - 2024-07-26 12:26:56
|
On 2024-07-26 07:04, Roland Hughes via Foxgui-users wrote: > Unknown if it ever impacted FOX, but many years ago, one had to. Gray > cells are a bit fuzzy on it, had to do with video card flavored > libraries and a few third party libraries that would not find one > library if it was linked ahead of it. > > In what could only be an MBA lead "efficiency" move most linkers of > the day were single pass. While you should never ever under any > circumstances trust anything on StackOverflow, the answer from this 11 > year old question with a green check mark and 123 up votes does a > pretty good job of explaining it. > > https://stackoverflow.com/questions/11893996/why-does-the-order-of-l-option-in-gcc-matter > > Thanks to brain dead AI additions to search engines you can no longer > search for "how many passes does GNU linker make" without getting > inundated with links to command line passing. > > The comments below that answer tick some memories too. You have to > remember the x86 has always been and will probably always be the home > hobby platform. When Intel and Microsoft desperately wanted to get a > to hold in Fortune 500 data centers they bribed marketing agencies > like Gartner Group (masquerading as "industry analysts") telling > companies that systems and libraries needed to conform to "Open > Standards." Prior to that we had things that actually worked. Your > OS/400 programs just worked on OS/400. MVS on MVS. VMS on VMS, etc. We > had screen and other libraries all made by the hardware vendor for the > hardware and OS we were running on. No, they weren't portable, but > they "just worked." We used operating systems that were created to be > robust multi-user platforms that could bill for every byte and clock > cycle consumed by everyone. It wasn't until MAI, Wang, and a few > others started going under that portable became something companies > worried about. We had proprietary security until the vendor went > under. We also had linkers that operated in one of the following > manners: > > 1) Made N-passes through the libraries trying to resolve external > linkage. You had a command line switch to limit the maximum number of > passes. Something says the default for most was up to 4 passes. > > 2) Loaded _every_ external linkage item from every library on the > command line into one big lookup table before linking object files. > (Our libraries had header areas where all this info was so they were > only reading a few disk blocks from each, not dynamically parsing > something.) > > 3) Both 1 & 2. Towards the end this was what they all did because > every time you linked another function from another library it could > add new external dependencies. > > After the bust-up of AT&T, UNIX, originally created on a DEC PDP, > which was never created to be a true multi-user OS, just to run phone > switches and allow maintenance to log in to tweak/update things, got > popped out into the world of "free software." There might have been as > many as 60 commercial Unix versions that popped up in the weeks/months > following. Most of them sucked. None of them were worthy of running a > business on, though some companies tried. These vendors desperately > wanted to get into the corporate data center as well. That's where the > real money was. > > You may remember a name called SUN Microsystems. When you could cobble > together a generic PC with 40MEG hard drive and two floppies for > around $800, SUN was selling $20,000 "engineering workstations" to > corporations that cost about the same to build. They had cash coming > out their back side and got behind this "standard." There was no way > they were ever going to get their > not-really-multi-user-just-multiple-people-could-log-in system into > the data center unless they could somehow make that sexy to the ones > with the checkbooks. > > Enter POSIX. > > A standard that busted every proprietary OS trying to conform to it > because the ones holding the checkbooks demanded compliance with it. > With POSIX we got insecurities, data breaches, and a mandate for a > single pass linker because that is all the > not-really-multi-user-just-multiple-people-could-log-in systems could > manage. > > Your latest macOS is not POSIX compliant. You should point it out to > them since Apple was one of the companies behind POSIX back in the > day. SUN, creators of Java with seemingly limitless financial > resources, went bankrupt. > > As part of this POSIX world Microsoft wanted to make a standard for > user interaction. They wanted it to be like their feeble DOS and GUI > DOS (Windows) was capable of. After the initial POSIX debacle IBM > flooded the standards committee with employees and customers. That is > why CUA works exactly like a CICS application on a green screen. We > tab between fields, have a special ENTER key different from the RETURN > key, etc. > > Why do those of us who worked on real computers have such disdain for > the x86 platforms despite all of the embedded, Linux, and desktop > stuff we have written? > > On the PDP 11/70 we ran 255 interactive/batch users in 64K-words. The > PC with DOS and 640K bytes could barely run one. > > The current IBM z/OS box, a little shorter and about the same width as > 2 4-drawer file cabinets can run more users that 2 complete floors of > machines at any cloud data center in the world. I don't think they > worried about POSIX compliance. > > Sorry, the "why" behind your answer is tangled up in an ugly corrupt > history of the PC world. It appears macOS has now learned the ugly > truth. POSIX was meant to cripple, not enhance. > > When you are written for the least common denominator and all must > comply, nobody can soar. > > Even GNU has figured this out and quietly hidden their nasty undies > -- GNU is no longer POSIX compliant. Read up on: > > --whole-archive (links everything just like we did with DOS) > > --start-group --end-group (make N-passes through these libraries > trying to resolve linkage) > > > > On 7/26/2024 2:02 AM, Michael Behrisch via Foxgui-users wrote: >> Hi, >> I have a question about the output of "fox-config --libs". >> On my system it currently gives: "-L/usr/lib64 -lFOX-1.6 -lX11 -lXext >> -lfreetype -lfontconfig -lXft -lXcursor -lXrender -lXrandr -lXfixes >> -lXi -lGL -lGLU -ldl -lpthread -lrt -ljpeg -lpng -ltiff -lz -lbz2 >> -lGLU -lGL" >> which duplicates the GL and GLU libraries. >> >> The problem is that recent macOS builds complain if you link the same >> library twice. >> >> I had a look at the source code in configure.ac and fox-config.in and >> this seems to be intentional because indeed the GL libraries (LIBGL) >> are being added to the LIBS variable and then both are output in the >> end. >> I removed the first addition of the GL libs and it is still working >> fine here but before submitting a patch I wanted to ask whether there >> is a known reason for this duplication because sometimes the linker is >> tricky. >> >> Thank you and best regards, >> Michael W.r.t. search engines, Google, Bing are no longer search engines. You won't find anything with these. I recommend xmol, presearch, and yandex. === Yes, it is indeed sometimes necessary to repeat same library, because sometimes stuff was not possible to be arranged so all references were forward. However, it is possible current linkers are no longer having this problem; maybe it was a a.out limitation, or maybe it only applies to .a linkage and .so links [which are resolved at runtime] do not have this problem... -- JVZ -- JVZ |
From: Roland H. <ro...@lo...> - 2024-07-26 12:04:18
|
Unknown if it ever impacted FOX, but many years ago, one had to. Gray cells are a bit fuzzy on it, had to do with video card flavored libraries and a few third party libraries that would not find one library if it was linked ahead of it. In what could only be an MBA lead "efficiency" move most linkers of the day were single pass. While you should never ever under any circumstances trust anything on StackOverflow, the answer from this 11 year old question with a green check mark and 123 up votes does a pretty good job of explaining it. https://stackoverflow.com/questions/11893996/why-does-the-order-of-l-option-in-gcc-matter Thanks to brain dead AI additions to search engines you can no longer search for "how many passes does GNU linker make" without getting inundated with links to command line passing. The comments below that answer tick some memories too. You have to remember the x86 has always been and will probably always be the home hobby platform. When Intel and Microsoft desperately wanted to get a to hold in Fortune 500 data centers they bribed marketing agencies like Gartner Group (masquerading as "industry analysts") telling companies that systems and libraries needed to conform to "Open Standards." Prior to that we had things that actually worked. Your OS/400 programs just worked on OS/400. MVS on MVS. VMS on VMS, etc. We had screen and other libraries all made by the hardware vendor for the hardware and OS we were running on. No, they weren't portable, but they "just worked." We used operating systems that were created to be robust multi-user platforms that could bill for every byte and clock cycle consumed by everyone. It wasn't until MAI, Wang, and a few others started going under that portable became something companies worried about. We had proprietary security until the vendor went under. We also had linkers that operated in one of the following manners: 1) Made N-passes through the libraries trying to resolve external linkage. You had a command line switch to limit the maximum number of passes. Something says the default for most was up to 4 passes. 2) Loaded _every_ external linkage item from every library on the command line into one big lookup table before linking object files. (Our libraries had header areas where all this info was so they were only reading a few disk blocks from each, not dynamically parsing something.) 3) Both 1 & 2. Towards the end this was what they all did because every time you linked another function from another library it could add new external dependencies. After the bust-up of AT&T, UNIX, originally created on a DEC PDP, which was never created to be a true multi-user OS, just to run phone switches and allow maintenance to log in to tweak/update things, got popped out into the world of "free software." There might have been as many as 60 commercial Unix versions that popped up in the weeks/months following. Most of them sucked. None of them were worthy of running a business on, though some companies tried. These vendors desperately wanted to get into the corporate data center as well. That's where the real money was. You may remember a name called SUN Microsystems. When you could cobble together a generic PC with 40MEG hard drive and two floppies for around $800, SUN was selling $20,000 "engineering workstations" to corporations that cost about the same to build. They had cash coming out their back side and got behind this "standard." There was no way they were ever going to get their not-really-multi-user-just-multiple-people-could-log-in system into the data center unless they could somehow make that sexy to the ones with the checkbooks. Enter POSIX. A standard that busted every proprietary OS trying to conform to it because the ones holding the checkbooks demanded compliance with it. With POSIX we got insecurities, data breaches, and a mandate for a single pass linker because that is all the not-really-multi-user-just-multiple-people-could-log-in systems could manage. Your latest macOS is not POSIX compliant. You should point it out to them since Apple was one of the companies behind POSIX back in the day. SUN, creators of Java with seemingly limitless financial resources, went bankrupt. As part of this POSIX world Microsoft wanted to make a standard for user interaction. They wanted it to be like their feeble DOS and GUI DOS (Windows) was capable of. After the initial POSIX debacle IBM flooded the standards committee with employees and customers. That is why CUA works exactly like a CICS application on a green screen. We tab between fields, have a special ENTER key different from the RETURN key, etc. Why do those of us who worked on real computers have such disdain for the x86 platforms despite all of the embedded, Linux, and desktop stuff we have written? On the PDP 11/70 we ran 255 interactive/batch users in 64K-words. The PC with DOS and 640K bytes could barely run one. The current IBM z/OS box, a little shorter and about the same width as 2 4-drawer file cabinets can run more users that 2 complete floors of machines at any cloud data center in the world. I don't think they worried about POSIX compliance. Sorry, the "why" behind your answer is tangled up in an ugly corrupt history of the PC world. It appears macOS has now learned the ugly truth. POSIX was meant to cripple, not enhance. When you are written for the least common denominator and all must comply, nobody can soar. Even GNU has figured this out and quietly hidden their nasty undies -- GNU is no longer POSIX compliant. Read up on: --whole-archive (links everything just like we did with DOS) --start-group --end-group (make N-passes through these libraries trying to resolve linkage) On 7/26/2024 2:02 AM, Michael Behrisch via Foxgui-users wrote: > Hi, > I have a question about the output of "fox-config --libs". > On my system it currently gives: "-L/usr/lib64 -lFOX-1.6 -lX11 -lXext > -lfreetype -lfontconfig -lXft -lXcursor -lXrender -lXrandr -lXfixes > -lXi -lGL -lGLU -ldl -lpthread -lrt -ljpeg -lpng -ltiff -lz -lbz2 > -lGLU -lGL" > which duplicates the GL and GLU libraries. > > The problem is that recent macOS builds complain if you link the same > library twice. > > I had a look at the source code in configure.ac and fox-config.in and > this seems to be intentional because indeed the GL libraries (LIBGL) > are being added to the LIBS variable and then both are output in the end. > I removed the first addition of the GL libs and it is still working > fine here but before submitting a patch I wanted to ask whether there > is a known reason for this duplication because sometimes the linker is > tricky. > > Thank you and best regards, > Michael > > > _______________________________________________ > Foxgui-users mailing list > Fox...@li... > https://lists.sourceforge.net/lists/listinfo/foxgui-users -- Roland Hughes, President Logikal Solutions (630)-205-1593 (cell) https://theminimumyouneedtoknow.com https://infiniteexposure.net https://johnsmith-book.com |
From: Michael B. <os...@be...> - 2024-07-26 07:03:09
|
Hi, I have a question about the output of "fox-config --libs". On my system it currently gives: "-L/usr/lib64 -lFOX-1.6 -lX11 -lXext -lfreetype -lfontconfig -lXft -lXcursor -lXrender -lXrandr -lXfixes -lXi -lGL -lGLU -ldl -lpthread -lrt -ljpeg -lpng -ltiff -lz -lbz2 -lGLU -lGL" which duplicates the GL and GLU libraries. The problem is that recent macOS builds complain if you link the same library twice. I had a look at the source code in configure.ac and fox-config.in and this seems to be intentional because indeed the GL libraries (LIBGL) are being added to the LIBS variable and then both are output in the end. I removed the first addition of the GL libs and it is still working fine here but before submitting a patch I wanted to ask whether there is a known reason for this duplication because sometimes the linker is tricky. Thank you and best regards, Michael |
From: Roland H. <ro...@lo...> - 2024-07-24 23:28:56
|
The z820 discussed on here is available for anyone within driving distance, once we come to terms. I'm not shipping anything that heavy. Those "shipping" type places charge you $40 just for a box. You can see pictures and details in this pdf. https://www.dropbox.com/scl/fi/5jdhhgg8c2p0x64lcpaxz/machines-and-parts-for-sale.pdf?rlkey=lumw52etq21g0hbtf69br63l7&st=d0k2s75f&dl=0 WARNING: Beware PayMore -- it's a scam I emailed them that link. They told me to bring the stuff up and evaluate it. You will note that their Web page says they buy just about anything including broken tech and empty toner cartridges. Guy came out and looked at one machine, most everything else was in boxes, from the side from 12 feet away and said "I can't buy that. I can recycle it for you though." Therein lies the scam. I have taken stuff to recycling centers before over my nearly 40 year career. They are the ones you see selling "refurbished" systems and parts online. Usually they are tied to some kind of charity. I've even bought stuff from those places before. This place does a bait & switch. They appear to be a chain. Do not waste your time with them. The "gimick" here is promising to buy almost anything, then getting people to drive long distances and refuse to buy but offer to "recycle." They are banking on your frustration of "just wanting to get rid of it and avoid this hassle again." Sorry for off-topic post, but wanted to give you good warning. Why am I getting rid of that stuff? In not too many more weeks I turn 60. Time to clean the office, especially after I built this new toy. https://www.logikalsolutions.com/wordpress/experience/build-another-computer/ Can't wait to run some Yocto builds on it! Please contact off-list about equipment . . . or to bitch me out for posting this . . . <Grin> -- Roland Hughes, President Logikal Solutions (630)-205-1593 (cell) https://theminimumyouneedtoknow.com https://infiniteexposure.net https://johnsmith-book.com |
From: Michael B. <os...@be...> - 2024-07-21 15:44:17
|
Am 19.07.24 um 19:02 schrieb je...@fo...: > On 2024-07-19 10:54, Michael Behrisch via Foxgui-users wrote: >> Hi, >> I just wanted to check whether there might be any plans to add Vulkan >> support to Fox similar to the OpenGL context? It seems that OpenGL has >> been deprecated in the macOS world and also other projects like >> OpenSceneGraph move on. >> Is there any initiative in the same direction with Fox? > > There will not be a *replacement* of OpenGL by Vulkan, however, it > makes perfect sense to *add* an alternative set of APIs for Vulkan. > > For those who are interested in this issue, please forward all links and > resources about this to me so I can investigate what's involved. Thanks for picking this up! I think a good place to start is: https://vulkan-tutorial.com/ Best regards, Michael |
From: Roland P. <ro...@rp...> - 2024-07-19 17:57:23
|
Then Vulkan will be even a bigger pain. Vulkan is geared for high performance game development where you have to manage everything. You need like 100 lines of code in Vulkan for 1 line of code in OpenGL. Hence going from OpenGL to Vulkan is a huge time investment. There are helper libraries around to reduce the management overhead but it's no easy task. Am 19.07.24 um 19:02 schrieb je...@fo...: > On 2024-07-19 10:54, Michael Behrisch via Foxgui-users wrote: >> Hi, >> I just wanted to check whether there might be any plans to add Vulkan >> support to Fox similar to the OpenGL context? It seems that OpenGL has >> been deprecated in the macOS world and also other projects like >> OpenSceneGraph move on. >> Is there any initiative in the same direction with Fox? > > There will not be a *replacement* of OpenGL by Vulkan, however, it > makes perfect sense to *add* an alternative set of APIs for Vulkan. > > For those who are interested in this issue, please forward all links and > resources about this to me so I can investigate what's involved. > > The platform specifics, moreso that the core vulkan APIs themselves are > of particular interest. OpenGL platform issues w.r.t. 2D window > system have > always been huge pain points, particularly on Windows. > > > > -- JVZ > > > _______________________________________________ > Foxgui-users mailing list > Fox...@li... > https://lists.sourceforge.net/lists/listinfo/foxgui-users |
From: <je...@fo...> - 2024-07-19 17:21:59
|
On 2024-07-19 10:54, Michael Behrisch via Foxgui-users wrote: > Hi, > I just wanted to check whether there might be any plans to add Vulkan > support to Fox similar to the OpenGL context? It seems that OpenGL has > been deprecated in the macOS world and also other projects like > OpenSceneGraph move on. > Is there any initiative in the same direction with Fox? There will not be a *replacement* of OpenGL by Vulkan, however, it makes perfect sense to *add* an alternative set of APIs for Vulkan. For those who are interested in this issue, please forward all links and resources about this to me so I can investigate what's involved. The platform specifics, moreso that the core vulkan APIs themselves are of particular interest. OpenGL platform issues w.r.t. 2D window system have always been huge pain points, particularly on Windows. -- JVZ |
From: Michael B. <os...@be...> - 2024-07-19 15:54:18
|
Hi, I just wanted to check whether there might be any plans to add Vulkan support to Fox similar to the OpenGL context? It seems that OpenGL has been deprecated in the macOS world and also other projects like OpenSceneGraph move on. Is there any initiative in the same direction with Fox? Best regards, Michael |
From: Michael B. <os...@be...> - 2024-07-09 05:19:20
|
Hi, I have a problem using the FXGLVisual. If I enforce GPU rendering in my nvidia settings the creation of my GL window takes up to 7 seconds. If I disable it, the startup is much faster (0.15 seconds) but I get only half the frame rate in rendering. I checked with the debugger and the time seems to be spent in FXGLVisual::create. I am using Fox 1.6.58. It might be a driver problem because I don't remember this for earlier versions but it happens on several machines and unfortunately downgrading all of them is not a real option. Is this a known problem and can I do something about it? Thanks for your help Michael |
From: Devin S. <dev...@gm...> - 2024-07-04 00:45:51
|
Looking through the archives I found someone else that had a similar "issue" back in 2002. Turns out that I needed to pass SPLITTER_REVERSED as an option to the splitter during construction. Thanks for all the help. Happy 4th! On Wed, Jul 3, 2024 at 3:32 PM Roland Hughes <ro...@lo...> wrote: > > Hello Devin, > > I don't have a FOX Toolkit example for you and I haven't coded much in > this API for a while. It's the start of a long holiday weekend here in > America so odds are low many will look at your request until Tuesday. > > Having said that, the description of your problem sounds more > architectural than syntax. Believing that I'm pointing you towards code > have using CopperSpice which architecturally is what you have to do. > > Look at this source file and follow the m_splitter variable. > > https://sourceforge.net/p/reddiamond/code/ci/master/tree/src/edteditwidget.cpp > > CopperSpice has a QSplitter class and FOX has an FXSplitter. Syntax will > be different, but the flow should not be. If it turns out I'm talking > out my arse I sincerely apologize. > > Note how I create the splitter in the constructor and add the primary > edit widget to it. The splitter gets added to a layout along with other > widgets and the layout is basically assigned to the parent widget. > > Down around line 354 you will note that I add the widget which will > appear in the "split" to the existing splitter widget after defining the > direction of the split. > > In the GUI world, everything I've ever worked with operates in this > manner. You don't "split a window", you stick a splitter inside a widget > and add things to it. > > In the MS DOS, RS-232 terminal days of Unix/Linux/VMS/etc. yes, we > "split a window." We did not have graphical cards with memories. We had > a token few ASCII commands that could be sent to the terminal and then > you hoped the terminal did that. > > > -- > Roland Hughes, President > Logikal Solutions > (630)-205-1593 > > http://www.theminimumyouneedtoknow.com > http://www.infiniteexposure.net > http://www.johnsmith-book.com > http://www.logikalblog.com > http://www.interestingauthors.com/blog > > > -- > This email has been checked for viruses by Avast antivirus software. > www.avast.com |
From: Roland H. <ro...@lo...> - 2024-07-03 22:51:23
|
Hello Devin, I don't have a FOX Toolkit example for you and I haven't coded much in this API for a while. It's the start of a long holiday weekend here in America so odds are low many will look at your request until Tuesday. Having said that, the description of your problem sounds more architectural than syntax. Believing that I'm pointing you towards code have using CopperSpice which architecturally is what you have to do. Look at this source file and follow the m_splitter variable. https://sourceforge.net/p/reddiamond/code/ci/master/tree/src/edteditwidget.cpp CopperSpice has a QSplitter class and FOX has an FXSplitter. Syntax will be different, but the flow should not be. If it turns out I'm talking out my arse I sincerely apologize. Note how I create the splitter in the constructor and add the primary edit widget to it. The splitter gets added to a layout along with other widgets and the layout is basically assigned to the parent widget. Down around line 354 you will note that I add the widget which will appear in the "split" to the existing splitter widget after defining the direction of the split. In the GUI world, everything I've ever worked with operates in this manner. You don't "split a window", you stick a splitter inside a widget and add things to it. In the MS DOS, RS-232 terminal days of Unix/Linux/VMS/etc. yes, we "split a window." We did not have graphical cards with memories. We had a token few ASCII commands that could be sent to the terminal and then you hoped the terminal did that. -- Roland Hughes, President Logikal Solutions (630)-205-1593 http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com http://www.logikalblog.com http://www.interestingauthors.com/blog -- This email has been checked for viruses by Avast antivirus software. www.avast.com |
From: Devin S. <dev...@gm...> - 2024-07-03 21:30:19
|
Hi, I'm trying to build a program that splits a frame into two upon invocation of a command but I don't seem to be getting anywhere. I've attached a very minimal test program that hopefully demonstrates what I'm trying to accomplish. When you push the "Do Split" button, I'm hoping that two text boxes show up with the splitter in between them. However, I cannot seem to get the window to split. Any help would be appreciated! Thanks, Devin |
From: John S. <joh...@ja...> - 2024-05-21 21:42:39
|
I was planning of trapping the mousewheel event (SEL_MOUSEWHEEL) and toggle between SCROLLERS_DONT_TRACK and SCROLLERS_TRACK but it doesn't seem to be possible, the call to SEL_MOUSEWHEEL just gets ignored.. -----Original Message----- From: je...@fo... <je...@fo...> Sent: Tuesday, May 21, 2024 2:19 PM To: joh...@ja... Cc: je...@fo...; fox...@li... Subject: Re: [Foxgui-users] jumpy scrolling on the Mac On 2024-05-21 12:23, John Selverian wrote: > I passed SCROLLBAR_WHEELJUMP and it was the same and the vertical > scroll disappeared. > > I used SCROLLERS_DONT_TRACK and this works! It jumps by 1 line each > time and there is no blurring/smearing...I assume that is what you > meant. SCROLLERS_DONT_TRACK makes the scroll area (your scrollable list, in this case) ignore the SEL_CHANGED messages, and only handle the SEL_COMMAND one. So as you're dragging scrollbars, contents stay put until you stop moving and release the mouse button. SCROLLBAR_WHEELJUMP affects only mouse wheel movement. It skips the animation part and jump-scrolls straight to the scroll position the wheel would ultimately land on [e.g. a whole number of wheel lines further]. The animation serves no purpose other than user-feedback. But the SCROLLERS_DONT_TRACK might be too much in that you won't see interactive scrolling at all. One note, as you're dragging the scrollbar, keep in mind that modern mice may sometimes have very high report-rates. I think the logitech g300s I'm using right now can push up to 1000 updates/second. For scrolling this may be overkill as you're seeing only 60 changed images/second, or maybe slightly more on high-refresh-rate monitors. A few very high-end screens may go to 120, or even 240, but I have not seen anything beyond that. If you can control it [you can configure it with the g300s mouse] you can try dropping the report rate. Things may actually work better at lower rates... Note, report rates and dpi rates are not the same thing. dpi rates pertain to mouse accuracy, or pixels/inch movement. Report rate is position update transfers/second. I have an older logitech which has only like 120/second rate and it always felt very smooth; higher rates just cause more workload on CPU w/o a lot of benefit; as long as you're above screen refresh rate it works very well. -- JVZ |
From: <je...@fo...> - 2024-05-21 18:19:26
|
On 2024-05-21 12:23, John Selverian wrote: > I passed SCROLLBAR_WHEELJUMP and it was the same and the vertical > scroll disappeared. > > I used SCROLLERS_DONT_TRACK and this works! It jumps by 1 line each > time and there is no blurring/smearing...I assume that is what you > meant. SCROLLERS_DONT_TRACK makes the scroll area (your scrollable list, in this case) ignore the SEL_CHANGED messages, and only handle the SEL_COMMAND one. So as you're dragging scrollbars, contents stay put until you stop moving and release the mouse button. SCROLLBAR_WHEELJUMP affects only mouse wheel movement. It skips the animation part and jump-scrolls straight to the scroll position the wheel would ultimately land on [e.g. a whole number of wheel lines further]. The animation serves no purpose other than user-feedback. But the SCROLLERS_DONT_TRACK might be too much in that you won't see interactive scrolling at all. One note, as you're dragging the scrollbar, keep in mind that modern mice may sometimes have very high report-rates. I think the logitech g300s I'm using right now can push up to 1000 updates/second. For scrolling this may be overkill as you're seeing only 60 changed images/second, or maybe slightly more on high-refresh-rate monitors. A few very high-end screens may go to 120, or even 240, but I have not seen anything beyond that. If you can control it [you can configure it with the g300s mouse] you can try dropping the report rate. Things may actually work better at lower rates... Note, report rates and dpi rates are not the same thing. dpi rates pertain to mouse accuracy, or pixels/inch movement. Report rate is position update transfers/second. I have an older logitech which has only like 120/second rate and it always felt very smooth; higher rates just cause more workload on CPU w/o a lot of benefit; as long as you're above screen refresh rate it works very well. -- JVZ |
From: John S. <joh...@ja...> - 2024-05-21 17:23:49
|
I passed SCROLLBAR_WHEELJUMP and it was the same and the vertical scroll disappeared. I used SCROLLERS_DONT_TRACK and this works! It jumps by 1 line each time and there is no blurring/smearing...I assume that is what you meant. Thanks Js -----Original Message----- From: je...@fo... <je...@fo...> Sent: Tuesday, May 21, 2024 10:37 AM To: joh...@ja... Cc: 'Roland Hughes' <ro...@lo...>; 'Mathew Robertson' <mat...@gm...>; fox...@li... Subject: Re: [Foxgui-users] jumpy scrolling on the Mac On 2024-05-21 08:05, John Selverian wrote: > I added a repaint timer. It gets called but I don’t notice any > difference, it is still jumpy. > > I also tried Adie and see the same problem, i.e., jumpy text. > > I also see this problem in an FXTable not just FXList. That is important to know, because it would rule out issues specific to your program. Rather, it seems to have to do with the XQuartz interface then. > If I scroll using the ‘thumb’ in the scroll bar instead of the > mousewheel it looks fine. The wheel performs some animation, redrawing the widget at inter- mediate positions in order to provide visual clues of the direction of motion. All this is done via FXScrollBar [a wheel-rotation inside the widget is typically routed to either vertical scrollbar [default], or horizontal scrollbar [if vertical scrolling is disabled]. The wheel animation will be disabled if SCROLLBAR_WHEELJUMP is passed; this will skip the intermediate states and jump straight to the desired scroll position. You could try that. Current animated scrolling is "hardwired" to a time-interval of 1/60 (16,666,666 nanoseconds), and eight increments, i.e. you'll reach the desired scroll position in 8 frame times. Implicit in this assumption is that we can actually perform this act of drawing in one frame time. -- JVZ |