Re: Reminder!!! GNUstep meeting 12:30-1:30est
I cannot make it on Saturday. We have an invitation from friends and I won’t be back in time. My point for the discussion would be the same as last time, to prepare a shared release of all core libraries. My contribution could be to write up the news sections for gui and back but somebody else would have to cut the releases. The first step should be to step a release date let#s say in a months time. Cheers, Fred > Am 11.04.2024 um 09:36 schrieb Gregory Casamento : > > Jitsi Meeting - > https://meet.jit.si/TheatricalNecessitiesFormulateNotably > > Anybody is welcome. Please come!!! > > Gregory Casamento > GNUstep Lead Developer / Black Lotus, Principal Consultant > http://www.gnustep.org - http://heronsperch.blogspot.com > https://www.patreon.com/bePatron?u=352392 - Become a Patron > https://www.openhub.net/languages/objective_c - OpenHub standings
Re: Gorm build error
Looks like Gorm is using the instance variable directly while it should be using the corresponding method. No idea why this is the case but it should be easy to fix. > Am 25.03.2024 um 04:07 schrieb Boris D. : > > Hello, > Trying to build the latest release of Gorm (gorm-1.3.1.tar.gz) on Ubuntu > 22.04 results in the following error: > > Making all for app Gorm... > Creating Gorm.app/ > Compiling file Gorm.m ... > Compiling file main.m ... > Linking app Gorm ... > GormCore/./obj/libGormCore.so: error: undefined reference to > '__objc_ivar_offset_NSMatrix._selectedCells.^^C' > > Any suggestions? > >
Re: NSString subclass responsibility
I was hoping for somebody else to answer this. There are different subclasses
that provide the implementation for NSString, most importantly GSString. Within
an Obj-C application NSString in itself is never instantiated. The problem you
are facing is that your non Obj-C code may try to instantiate an NSString
object. Just stick to the [[NSString alloc] init] pattern or get your
strings from one of the factory methods.
Hope this helps,
Fred
> Am 23.03.2024 um 20:03 schrieb Boris D. :
>
> Hello,
> In NSString.m, -length is defined as follows:
>
> - (NSUInteger) length
> {
> [self subclassResponsibility: _cmd];
> return 0;
> }
>
> My code links with the gnustep-base library but is not compiled from
> Objective-C source. Am I supposed to use a subclass of NSString instead
> of NSString directly? Which class provides this implementation?
>
>
Re: WebSite: navigation to bug reporting
I like the way you put it in the menu. The name „External“ is really a bit confusing, but at the moment I don’t have a better idea. Cheers, Fred > Am 16.02.2024 um 15:38 schrieb Riccardo Mottola : > > Hi, > > I want to uniform the bug reporting on our website. > Originally, we had a single page on savannah for all projects. I found this > better than the current situation of github, were every sub-project has its > own issue tracker. This makes reclassifying a bug impossible and also confuse > newcomers. > > But is what it is, I created a single page which should help as a collector > and points to te trackers of the most common projects. > See it here: https://home.gnustep.org/bugs.html > > We also had a wiki page: https://mediawiki.gnustep.org/index.php/Report_Bugs > But the wiki was not available for a long time and also, now it needs to be > promoted. > > It would be best if bugs.gnuste.org could point to > https://home.gnustep.org/bugs.html eventually. > > But question: where to put the navigation? > Under a "menu" like you can see here: https://home.gnustep.org/index.html > (name of menu and structure are another topic, current name is "External") > > Or on a separate item, maybe even in a prominent place like at right, as > here: https://home.gnustep.org/jigs/index.html > > Both have pro, say yours. > > Riccardo >
Re: GNUstep bi-monthly Meeting Reminder...
Not that I know of. I don’t want to be the moderator as I have to leave soon. i wait for five more minutes and give up then. Cheers, Fred > Am 10.02.2024 um 18:47 schrieb lars.sonchocky-helld...@hamburg.de: > > Has the meeting be canceled again? > > Kind regards, > > Lars > >> Am 08.02.2024 um 00:11 schrieb Gregory Casamento : >> >> The meeting is on the 10th which is this saturday. Here is the link: >> >> https://meet.jit.si/TheatricalNecessitiesFormulateNotably >> The meeting is open to everyone. Please feel free to attend. It starts at >> 12:30EST and goes to 2:30PM EST. This is an informal meeting, though we >> may discuss some important topics. >> >> Yours, GC >> -- >> Gregory Casamento >> GNUstep Lead Developer / OLC, Principal Consultant >> http://www.gnustep.org - http://heronsperch.blogspot.com >> https://www.patreon.com/bePatron?u=352392 - Become a Patron >> https://www.openhub.net/languages/objective_c - OpenHub standings >
Re: Bi-monthly GNUstep Meeting this Saturday?
I am currently trying to join this meeting. Looks like there is no moderator present. Has this meeting been cancelled or postponed? I will only be able to attend for another half hour so if we don#t start soon, I will have to drop out. Cheers, Fred > Am 08.02.2024 um 01:28 schrieb Gregory Casamento : > > Lars, > > We should have the meeting. I've spoken to Riccardo and he may not be able > to make it due to other commitments, but I would still like to have it. > > Yours, GC > > On Wed, Feb 7, 2024 at 5:38 PM lars.sonchocky-helld...@hamburg.de > wrote: > Hi everybody, > > my calendar says that our bi-monthly GNUstep Video Call is up this Saturday > (10.02.2024) at 18:30 MET / 17:30 GMT / 12:30 ET / 9:30 PT: > > https://meet.jit.si/TheatricalNecessitiesFormulateNotably > > Will we hold the meeting this time or will we skip it again? > > > Kind regards, > > Lars > > > -- > Gregory Casamento > GNUstep Lead Developer / OLC, Principal Consultant > http://www.gnustep.org - http://heronsperch.blogspot.com > https://www.patreon.com/bePatron?u=352392 - Become a Patron > https://www.openhub.net/languages/objective_c - OpenHub standings
Re: Images disappear after Display Resolution Change
Let me try to explain roughly what happens when an image gets displayed. First we try to find the best representation for this image. We may already have different representations when loading an image from a file and we also regard the created cached versions as representations (This might be wrong!). After that we get the cached version for this representation (creating one if there isn’t one). Now this cached version might be generated for a different resolution or even for e different colour order. So we should compare the device description for the cached versions with the current device description. There is at the moment no code in place to store that. And if I remember correctly things are even worse. The cached representations is just drawn into a hidden window for the current display. That way a cached representation is only suitable for the display it was created for. Decoupling this should be the first step. > Am 06.01.2024 um 11:02 schrieb Riccardo Mottola : > > Fred Kiefer wrote: >> This looks like a nice way to work around this issue. At the moment I am not >> sure, whether it is such a good idea to have every image in an application >> to watch out for a screen change notification. But from my side it would be >> OK to enable this and see if we get negative results. >> With the code itself I have a few minor white space issues. Feel free to >> open a pull request and we can try to get it through before the year ends. > > if you like that approach for libs-gui, I wonder if something needs to be > done in GWorkspace and what.. and furthermore if then potentially *any* > application needs to be resolution-change aware. > > We could try to look at this in a next hacking session. > > Is there an easy way to cause a resolution change without things like putting > a laptop to sleep or switching monitors? I'm thinking if perhaps issuing > xrandr commands would be enough. We need this to be able to reproduce as well > as test all applications that handle images. > > Riccardo >
Re: Images disappear after Display Resolution Change
This looks like a nice way to work around this issue. At the moment I am not sure, whether it is such a good idea to have every image in an application to watch out for a screen change notification. But from my side it would be OK to enable this and see if we get negative results. With the code itself I have a few minor white space issues. Feel free to open a pull request and we can try to get it through before the year ends. Cheers, Fred > Am 30.12.2023 um 17:23 schrieb Ondrej Florian : > > I think I managed to fix the problem by clearing NSImage cache after > receiving NSApplicationDidChangeScreenParametersNotification > > Please see: > https://github.com/onflapp/libs-gui/commit/2b6a26b2f013d79971165abf7b10a56b5e42c619 > > > There is still problem with GWorkspace though. > Non-scaled icons works fine but scaled icons (e.g. list / browser view) do > not.
Re: Christmas wishes and a failing installation of gnustep-gui on FreeBSD.
Looks like we need to switch line 101 and 102 in the file AppKit.texi. I will
try this change tomorrow and hope this changes the issue for you. What I am not
sure is, when this change will reach you as you don’t seem to compile from the
git source code.
Cheers,
Fred
> Am 27.12.2023 um 09:31 schrieb Edwin Ancaer :
>
>
> Hello all,
>
> I must admit my Christmas Wishes for you all are not entirely without
> self-interest
> I recently had to reinstall GNUStep on my FreeBSD laptop. As I'm on FreeBSD,
> I used the ports system. When installing the gnustem-gui port, I had an
> error. The installation displayed a list of missing html documents, and
> ended with error code 1.
>
> gmake[3]: Leaving directory
> '/usr/ports/x11-toolkits/gnustep-gui/work/libs-gui-gui-0_28_0/Documentation'
> gmake[2]: Leaving directory
> '/usr/ports/x11-toolkits/gnustep-gui/work/libs-gui-gui-0_28_0'
> > Compressing man pages (compress-man)
> ===> Installing ldconfig configuration file
> ===> Installing for gnustep-gui-0.28.0_1
> ===> Checking if gnustep-gui is already installed
> ===> Registering installation for gnustep-gui-0.28.0_1
> pkg-static: Unable to access file
> /usr/ports/x11-toolkits/gnustep-gui/work/stage/usr/local/GNUstep/System/Library/Documentation/Developer/Gui/ProgrammingManual/AppKit/Affine-Transformations.html:No
> such file or directory
> pkg-static: Unable to access file
> /usr/ports/x11-toolkits/gnustep-gui/work/stage/usr/local/GNUstep/System/Library/Documentation/Developer/Gui/ProgrammingManual/AppKit/Application-Makefiles.html:No
> such file or directory
> ...
> ...
> ...
> pkg-static: Unable to access file
> /usr/ports/x11-toolkits/gnustep-gui/work/stage/usr/local/GNUstep/System/Library/Documentation/Developer/Gui/ProgrammingManual/AppKit/theviewconcept.html:No
> such file or directory
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/ports/x11-toolkits/gnustep-gui
> *** Error code 1
>
> Stop.
>
> The only error I found until now was with a call to texi2pdf for AppKit.texi
> . I suppose my version of texi2pdf is too old or too new, but before I
> start messing with versions, could someone tell me if the error above can be
> caused by texi2pdf failing. After all, it is complaining about missing HTML
> documents, not PDFs. I tried the texi2pdf with the AppKit.texi file from the
> command line, and I got the same error as the one from the installation:
>
> gmake[4]: Entering directory
> '/usr/ports/x11-toolkits/gnustep-gui/work/libs-gui-gui-0_28_0/Documentation/manual'
> Making all for doc AppKit...
> texi2pdf \
> AppKit.texi -o AppKit.pdf
> This is pdfTeX, Version 3.14159265-2.6-1.40.16 (Web2C 2015) (preloaded
> format=pdfetex)
> restricted \write18 enabled.
> entering extended mode
> (./AppKit.texi (/usr/local/share/texmf-dist/tex/texinfo/texinfo.tex
> Loading texinfo [version 2015-05-06.11]: pdf, fonts, markup, glyphs,
> page headings, tables, conditionals, indexing, sectioning, toc, environments,
> defuns, macros, cross references, insertions,
> (/usr/local/share/texmf-dist/tex/generic/epsf/epsf.tex
> This is `epsf.tex' v2.7.4 <14 February 2011>
> ) localization, formatting, and turning on texinfo input format.)
> (/usr/ports/x11-toolkits/gnustep-gui/work/libs-gui-gui-0_28_0/Documentation/man
> ual/AppKit.aux)
> [1{/usr/local/share/texmf-dist/fonts/map/pdftex/updmap/pdftex.m
> ap}] [2]
> ./AppKit.texi:101: This command can appear only outside of any environment,
> not
> in environment @titlepage.
> @badenverr ...temp , not @inenvironment @thisenv }
>
> @checkenv ...@ifx @thisenv @temp @else @badenverr
> @fi
> @chapmacro #1#2#3->@checkenv {}
>@let @prevchapterdefs =@lastchapterdefs @let
> ...
>
> @startcontents ... @chapmacro {#1}{Yomitfromtoc}{}
> @savepageno = @pageno
> @beg...
>
> @contents ->@startcontents {@putwordTOC }
> @openin 1 @tocreadfilename @space
> @...
> l.101 @contents
>
> ?
> ./AppKit.texi:101: Emergency stop.
> @badenverr ...temp , not @inenvironment @thisenv }
>
> @checkenv ...@ifx @thisenv @temp @else @badenverr
> @fi
> @chapmacro #1#2#3->@checkenv {}
>@let @prevchapterdefs =@lastchapterdefs @let
> ...
>
> @startcontents ... @chapmacro {#1}{Yomitfromtoc}{}
> @savepageno = @pageno
> @beg...
>
> @contents ->@startcontents {@putwordTOC }
> @openin 1 @tocreadfilename @space
> @...
> l.101 @contents
>
> ./AppKit.texi:101: ==> Fatal error occurred, no output PDF file produced!
> Transcript written on AppKit.log.
> makeinfo --html \
>
Re: BUG App Name in GNOME
Not sure what is happening here, it could be that GNOME is only looking at the window class hint name and if I remember correctly, we set that to GNUStep (Must be somewhere in XGServerWindow.m). Do all applications get gathered up under the same menu entry? Cheers, Fred On the road > Am 09.09.2023 um 21:07 schrieb dr_c...@me.com: > > I noticed that when I open a GNUStep app in GNOME, the app title says > "GNUStep" instead of "TextEdit" or "GWorkspace". Is there a way to ensure > that it says the name, or is this something related to how I have setup my > desktop? > > Thanks! > > > >
Re: Improved and Fixed Screen Math For Parity With Mac OS and Squashing Bugs
It is gone now, maybe I was looking at an old version of the code? In the git history you can still see it on line 546. On the road > Am 07.09.2023 um 01:38 schrieb dr_c...@me.com: > > So I read the code again, and I just wasn't able to find where I was > dividing twice. I set a rule that I only preformed division at the NSEvent > construction site (to ensure that all the math that happens up until that > point was surly in pixels. Would you mind showing me the line. I assume it > it's in XGServerEvent.m. I might just be tired, or I confused myself. Thanks! > >> On Sep 6, 2023, at 3:37 AM, Fred Kiefer wrote: >> >> This looks a lot better, though I only looked at the back part. There are a >> few typos and at one place (mouse events) you are doing the division twice. >> >> Cheers, >> Fred >> >> On the road >> >>>> Am 06.09.2023 um 04:31 schrieb dr_c...@me.com: >>>> >>> Hello All, >>> >>> I just finished rebasing my code on the current libs-gui and libs-back and >>> cleaning it up so it follows the current indentation conventions for >>> GNUStep. I compiled it, and it all works (except for one bug that I am >>> trying to track down that may be unrelated). The links below should work >>> with the better re-based code. >>> >>> (1) libs-back >>> https://github.com/austintatiousness/libs-back/tree/improved-screen-maths >>> (2) libs-gui >>> https://github.com/austintatiousness/libs-gui/tree/improved-screen-maths >>> >>> Bug: >>> There is one bug that I am still trying to track down that I believe is >>> from GORM files or deferred windows. In a 2x scale factor, they display >>> still at half the height. No idea why. It might have to do with the order >>> the the screen gets attached to the window? Maybe they are deferred? >>> Something I notice was that when the affected windows are allocated and >>> first set up, the correct sizes are reported to libs-gui and libs-base (i >>> tracked this with a bunch of NSLogs), but at some points libs-base sends >>> another NSEvent with it half the size causing the window to resize to half >>> the size. Maybe there is a rect cached somewhere that it is using and math >>> is preformed on it to cut it in half. I just can't figure where the event >>> is originating form. >>> >>> Thanks for reading! >>> >>> >>> >>>> On Sep 5, 2023, at 9:17 AM, dr_c...@me.com wrote: >>>> >>>> You're not wrong it is currently messy code. I had tried so many different >>>> things before I fully understood the drawing system and the Back->GUI >>>> interactions. Though, I thought I did pull out all of the code that I used >>>> to mitigate the issue before as with my adjustments, they were no longer >>>> needed. It was a LOT of learning. I started on a copy that was a few weeks >>>> old, but I thought that I re-synced those changes in before I moved the >>>> code back in. May I didn't. >>>> >>>> So, what I will do is clone it again and add back each change so the code >>>> matches better and you can see the changes more clearly and try not to >>>> adjust any of the indentation. It might look like more changes were made >>>> when you do a code comparison because I had modified and changed back so >>>> many things and then back when I realized it wasn't needed. To be honest, >>>> in the end, it really ended up just being som minor changes in Back and >>>> changing how NSWindow adjusted the base decoration view and adding a new >>>> method to scale drawing. >>>> >>>> I will post an update soon to clean up some of the code to make the code >>>> comparison cleaner in both back and base. >>>> >>>> Thanks! >>>> >>>>> On Sep 5, 2023, at 3:37 AM, Fred Kiefer wrote: >>>>> >>>>> I had a short look at your changes and sadly these don’t resemble the >>>>> clear idea you expressed in your mail. There are many leftovers from your >>>>> previous attempts to tackle the issue. You also missed out on the changes >>>>> that happened to GNUstep since you forked off your branch. A simple >>>>> rebase would help here. On the other hand, you are using an unmatched >>>>> indentation pattern and added plenty of empty newlines. Maybe it would be >>>>> best if
Re: Improved and Fixed Screen Math For Parity With Mac OS and Squashing Bugs
This looks a lot better, though I only looked at the back part. There are a few typos and at one place (mouse events) you are doing the division twice. Cheers, Fred On the road > Am 06.09.2023 um 04:31 schrieb dr_c...@me.com: > > Hello All, > > I just finished rebasing my code on the current libs-gui and libs-back and > cleaning it up so it follows the current indentation conventions for GNUStep. > I compiled it, and it all works (except for one bug that I am trying to track > down that may be unrelated). The links below should work with the better > re-based code. > > (1) libs-back > https://github.com/austintatiousness/libs-back/tree/improved-screen-maths > (2) libs-gui > https://github.com/austintatiousness/libs-gui/tree/improved-screen-maths > > Bug: > There is one bug that I am still trying to track down that I believe is from > GORM files or deferred windows. In a 2x scale factor, they display still at > half the height. No idea why. It might have to do with the order the the > screen gets attached to the window? Maybe they are deferred? Something I > notice was that when the affected windows are allocated and first set up, the > correct sizes are reported to libs-gui and libs-base (i tracked this with a > bunch of NSLogs), but at some points libs-base sends another NSEvent with it > half the size causing the window to resize to half the size. Maybe there is a > rect cached somewhere that it is using and math is preformed on it to cut it > in half. I just can't figure where the event is originating form. > > Thanks for reading! > > > >> On Sep 5, 2023, at 9:17 AM, dr_c...@me.com wrote: >> >> You're not wrong it is currently messy code. I had tried so many different >> things before I fully understood the drawing system and the Back->GUI >> interactions. Though, I thought I did pull out all of the code that I used >> to mitigate the issue before as with my adjustments, they were no longer >> needed. It was a LOT of learning. I started on a copy that was a few weeks >> old, but I thought that I re-synced those changes in before I moved the code >> back in. May I didn't. >> >> So, what I will do is clone it again and add back each change so the code >> matches better and you can see the changes more clearly and try not to >> adjust any of the indentation. It might look like more changes were made >> when you do a code comparison because I had modified and changed back so >> many things and then back when I realized it wasn't needed. To be honest, in >> the end, it really ended up just being som minor changes in Back and >> changing how NSWindow adjusted the base decoration view and adding a new >> method to scale drawing. >> >> I will post an update soon to clean up some of the code to make the code >> comparison cleaner in both back and base. >> >> Thanks! >> >>> On Sep 5, 2023, at 3:37 AM, Fred Kiefer wrote: >>> >>> I had a short look at your changes and sadly these don’t resemble the clear >>> idea you expressed in your mail. There are many leftovers from your >>> previous attempts to tackle the issue. You also missed out on the changes >>> that happened to GNUstep since you forked off your branch. A simple rebase >>> would help here. On the other hand, you are using an unmatched indentation >>> pattern and added plenty of empty newlines. Maybe it would be best if you >>> start anew from the current GNUstep code and just implement your idea? >>> >>> Hope this helps, >>> Fred >>> >>> On the road >>> >>>>> Am 05.09.2023 um 09:17 schrieb Fred Kiefer : >>>>> >>>> >>>> Hi, >>>> >>>> This approach sounds sensible to me. But as you said, it will take some >>>> more effort to spread it through the whole library, especially all the >>>> different backends. And there is also the case where GNUstep does the >>>> window decoration drawing. >>>> I am currently travelling and wont be able to review your code in detail >>>> before I am back home. But I will try to have a quick look to maybe point >>>> out some further difficulties. >>>> >>>> Cheers, >>>> Fred >>>> >>>> >>>> On the road >>>> >>>>> Am 05.09.2023 um 01:29 schrieb dr_c...@me.com: >>>>> >>>>> Hello Friends, >>>>> >>>>> As you may have read I have been working on getting some of the >>>>&
Re: Improved and Fixed Screen Math For Parity With Mac OS and Squashing Bugs
I had a short look at your changes and sadly these don’t resemble the clear idea you expressed in your mail. There are many leftovers from your previous attempts to tackle the issue. You also missed out on the changes that happened to GNUstep since you forked off your branch. A simple rebase would help here. On the other hand, you are using an unmatched indentation pattern and added plenty of empty newlines. Maybe it would be best if you start anew from the current GNUstep code and just implement your idea? Hope this helps, Fred On the road > Am 05.09.2023 um 09:17 schrieb Fred Kiefer : > > > Hi, > > This approach sounds sensible to me. But as you said, it will take some more > effort to spread it through the whole library, especially all the different > backends. And there is also the case where GNUstep does the window decoration > drawing. > I am currently travelling and wont be able to review your code in detail > before I am back home. But I will try to have a quick look to maybe point out > some further difficulties. > > Cheers, > Fred > > > On the road > >>> Am 05.09.2023 um 01:29 schrieb dr_c...@me.com: >>> >> Hello Friends, >> >> As you may have read I have been working on getting some of the ScreenFactor >> bugs squashed. One of my theories is that a lot of GNUStep developers are >> assuming screen scaling of 1. This creates a problem where the values coming >> in from NSEvent, NSScreen are in pixels and not points. I noticed that apps >> like GWorkspace used the screen resolution (in pixels) to generate its >> desktop and center its dock which cause the dock and desktop items to >> disappear. Originally, I fixed this by going in my version and dividing by >> the correct scale. I then noticed that these little bugs were everywhere. I >> also noticed that sometimes the NSString value of a NSRect saved to Plists >> were in pixels as well, creating a problem when screen scaling would change. >> Suffices to say, I wanted a fix that would allow all these other projects to >> display correctly with out having to go to each one and divide by scale >> factor for the offending views. >> >> There are two libraries that this affects (my version of the projects are >> here) >> (1) libs-back >> https://github.com/austintatiousness/libs-back/tree/improved-screen-maths >> (2) libs-gui >> https://github.com/austintatiousness/libs-gui/tree/improved-screen-maths >> >> To fix this, I proposed that we allow AppKit to assume that all geometry is >> in points instead of pixels according to the screen the window is on. This >> required only some minor changes actually. >> >> 1) When libs-back constructs NSEvents that pertain to an NSWindow, it needs >> to ensure that all the math is scaled by the screen factor of that window. >> 2) When libs-gui sends data to back, back knows that it will be in points >> and fixes it. >> 3) NSWindow needed some minor changes to its drawing routines because the >> assumption is no longer that that decoration view (_wv) is scaled, but >> instead a theoretical layer just below it is. So no longer do we to a >> transform on the view, but instead just do a transform right before drawing. >> You will see a method added to NSView - (NSAffineTransform*) >> _baseMatrixForDrawing , that handles the math for each view so they draw at >> the correct scale. >> >> When I finished fixing all of this, some of the other changes that I had >> previously proposed were no longer needed. >> >> Some caveats: In my tests, I only changed the X11 code, I am only using >> frames drawn by GNUSteap instead of the window manager. >> >> I have compiled and tested the code against GNUStep Desktop, and it all is >> working great. There are still a few bug fixes (I cannot figure out why >> items loaded from gorm sometimes are divided by the screen factor), but some >> of the issues I encountered in other apps are now fixed when I change my >> screen resolution. >> >> I would really love it if my code could be reviewed and possibly taken into >> consideration to being added to the official reposatory. >> >> As it is right now, I'm not going to be using an old monitor for my work, >> and I am working on a Swift bridge so I can port some of my software. I will >> be using my version of the frameworks for this project because >> unfortunately, as the bugs currently are, my ports wouldn't work correctly. >> >> Lastly, I am hoping that I copied all the code back into my repository, >> please let me know know if something doesn't build. >> >> Thanks!
Re: Improved and Fixed Screen Math For Parity With Mac OS and Squashing Bugs
Hi, This approach sounds sensible to me. But as you said, it will take some more effort to spread it through the whole library, especially all the different backends. And there is also the case where GNUstep does the window decoration drawing. I am currently travelling and wont be able to review your code in detail before I am back home. But I will try to have a quick look to maybe point out some further difficulties. Cheers, Fred On the road > Am 05.09.2023 um 01:29 schrieb dr_c...@me.com: > > Hello Friends, > > As you may have read I have been working on getting some of the ScreenFactor > bugs squashed. One of my theories is that a lot of GNUStep developers are > assuming screen scaling of 1. This creates a problem where the values coming > in from NSEvent, NSScreen are in pixels and not points. I noticed that apps > like GWorkspace used the screen resolution (in pixels) to generate its > desktop and center its dock which cause the dock and desktop items to > disappear. Originally, I fixed this by going in my version and dividing by > the correct scale. I then noticed that these little bugs were everywhere. I > also noticed that sometimes the NSString value of a NSRect saved to Plists > were in pixels as well, creating a problem when screen scaling would change. > Suffices to say, I wanted a fix that would allow all these other projects to > display correctly with out having to go to each one and divide by scale > factor for the offending views. > > There are two libraries that this affects (my version of the projects are > here) > (1) libs-back > https://github.com/austintatiousness/libs-back/tree/improved-screen-maths > (2) libs-gui > https://github.com/austintatiousness/libs-gui/tree/improved-screen-maths > > To fix this, I proposed that we allow AppKit to assume that all geometry is > in points instead of pixels according to the screen the window is on. This > required only some minor changes actually. > > 1) When libs-back constructs NSEvents that pertain to an NSWindow, it needs > to ensure that all the math is scaled by the screen factor of that window. > 2) When libs-gui sends data to back, back knows that it will be in points and > fixes it. > 3) NSWindow needed some minor changes to its drawing routines because the > assumption is no longer that that decoration view (_wv) is scaled, but > instead a theoretical layer just below it is. So no longer do we to a > transform on the view, but instead just do a transform right before drawing. > You will see a method added to NSView - (NSAffineTransform*) > _baseMatrixForDrawing , that handles the math for each view so they draw at > the correct scale. > > When I finished fixing all of this, some of the other changes that I had > previously proposed were no longer needed. > > Some caveats: In my tests, I only changed the X11 code, I am only using > frames drawn by GNUSteap instead of the window manager. > > I have compiled and tested the code against GNUStep Desktop, and it all is > working great. There are still a few bug fixes (I cannot figure out why items > loaded from gorm sometimes are divided by the screen factor), but some of the > issues I encountered in other apps are now fixed when I change my screen > resolution. > > I would really love it if my code could be reviewed and possibly taken into > consideration to being added to the official reposatory. > > As it is right now, I'm not going to be using an old monitor for my work, and > I am working on a Swift bridge so I can port some of my software. I will be > using my version of the frameworks for this project because unfortunately, as > the bugs currently are, my ports wouldn't work correctly. > > Lastly, I am hoping that I copied all the code back into my repository, > please let me know know if something doesn't build. > > Thanks!
Re: Drawing in NSWindows and NSViews in GNUStep
> Am 20.08.2023 um 16:42 schrieb Austin Clow : > > I have been investigating how drawing works and am having a hard time > understanding where drawing begins in the object hierarchy. For example, > where does an NSWindow tell its decorations view to begin drawing its content > into the window? Thanks! Window and view drawing start of in the static method +_handleAutodisplay: that gets triggered by the runloop. This informs all the registered windows to -_handleAutodisplay: themselves. There we check if the window actually needs to redraw and if this is the case call -displayIfNeeded which passes on this method to the window view. The window view is the decorations view you are interested in. From here on down the normal NSView drawing code gets used. Hope this helps, Fred
Re: programmatic layout of controls
I would expect that you need to provide a frame rectangle at least for the top level view but most likely very view will require one as otherwise it does not even know its start size. > Am 18.08.2023 um 17:57 schrieb Tom Sheffler : > > Thanks Fred. > > Indeed, that was a missing line! > Compiles now. Do not see any views. > Updated screenshot and description in repo. Still not sure how to use this > correctly for layout. > > Thanks, > Tom > > > On Fri, Aug 18, 2023 at 8:38 AM Fred Kiefer wrote: > Hi Tom, > > I had a very short look at your stack view test code and could not see where > you create the object `hbox`. This might be completely unrelated to the issue > you are having with that code but maybe it points you in the right direction. > > Cheers, > Fred > > > Am 18.08.2023 um 15:32 schrieb Tom Sheffler : > > > > I wanted to create a tiny app with just a few controls and create a layout > > programmatically. I began by testing NSGridView and NSStackView, but did > > not succeed with those. In an older "tests-examples" project, I found some > > older programs that looked reasonable, so that took me down a path of using > > some older GNUstepGUI views. > > > > FYI - my target environment is Linux, GCD, ARC, clang. > > > > What I believe I found is the following: > > - NSStackView is not ready for a completely programmatic layout. > > Constraint based layout is in the works but is not quite ready. > > - GNUstepGUI GSHbox and GSVbox are sufficient, but introduce a compiler > > error when their headers are included in a file compiled with ARC. There > > is a workaround. > > - setting the positions of frames explicitly works and is actually pretty > > simple > > > > What I found is that it's difficult to find some straightforward examples > > of layout that does not involve an Interface Builder of one form or another. > > > > I put together some examples illustrating these successes and issues. If > > you're interested in this topic, perhaps you can help create some simple > > examples of layout that work in a modern ObjC environment. > > > > https://github.com/sheffler/gnustep-rowcol-layout-examples > > > > Thanks, > > Tom > > >
Re: programmatic layout of controls
Hi Tom, I had a very short look at your stack view test code and could not see where you create the object `hbox`. This might be completely unrelated to the issue you are having with that code but maybe it points you in the right direction. Cheers, Fred > Am 18.08.2023 um 15:32 schrieb Tom Sheffler : > > I wanted to create a tiny app with just a few controls and create a layout > programmatically. I began by testing NSGridView and NSStackView, but did not > succeed with those. In an older "tests-examples" project, I found some older > programs that looked reasonable, so that took me down a path of using some > older GNUstepGUI views. > > FYI - my target environment is Linux, GCD, ARC, clang. > > What I believe I found is the following: > - NSStackView is not ready for a completely programmatic layout. Constraint > based layout is in the works but is not quite ready. > - GNUstepGUI GSHbox and GSVbox are sufficient, but introduce a compiler error > when their headers are included in a file compiled with ARC. There is a > workaround. > - setting the positions of frames explicitly works and is actually pretty > simple > > What I found is that it's difficult to find some straightforward examples of > layout that does not involve an Interface Builder of one form or another. > > I put together some examples illustrating these successes and issues. If > you're interested in this topic, perhaps you can help create some simple > examples of layout that work in a modern ObjC environment. > > https://github.com/sheffler/gnustep-rowcol-layout-examples > > Thanks, > Tom >
Re: Questions about WindowMaker's Alpha and Shadow
Hi Austin, what happens here is that we delegate this functionality to the window manager. That may either implement it or not. The standard for this interaction can be found here: https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.html If it does not work on your machine it might either be that you window manager does not adhere to this standard or that the interpretation differs from the one in GNUstep. Hope this helps, Fred > Am 16.08.2023 um 02:39 schrieb dr_c...@mac.com: > > I have been following some of the code back form NSWindow to see what it > ultimately calls. I see that setAlphaValue and setHasShadow: all call back to > similar methods in x11/XGServerWindow.m . I noticed they were non-functional, > but the methods there are not simply stubs, they have code in them. The > setShadow refer to _NET_WM_WINDOW_SHADOW_ATOM , so I assume these were > intended to work, but a shadow doesn't appear on the window. > > I would love some more context if possible! Thanks! > > - Austin
Re: NSSwitch drawRect bug
> Am 14.08.2023 um 08:36 schrieb H. Nikolaus Schaller :
>
>> Am 13.08.2023 um 22:40 schrieb dr_c...@me.com:
>>
>> Nice! Maybe even just drawSwitchInRect:dirtyRect:forState:enabled: Though,
>> with your way, you could get more information from the control without
>> having to enlarge method arguments every time we wanted to add something
>> else.
>>
>> So maybe -(void) drawSwitch:(NSSwitch*)switch inRect:(CGRect)rect
>> dirtyRect:(CGRect)dirtyRect {}
>
> I am not sure if passing the dirtyRect is necessary and useful.
> The idea is that -drawRect: is usually called after setting a clipping rect
> within -display so that drawing with bounds size is correct but will be
> clipped away.
This is not about correctness, as you wrote the NSView clipping will take care
of that, this idea is about performance. When we pass on the dirty rectangle
the drawing will be able to decide which parts actually require a redraw. This
isn’t important for a small component like an NSSwitch but for something like
NSMatrix or NSTableView it allows us to speed up drawing a lot. We only redraw
and compute bits that will be visible.
In general we should always draw a view within the assigned bounds and use the
dirty rectangle to speed things up, where this is useful. Somebody should go
through the NSView subclasses to see where corrections in the code are required.
Hope this clears things up,
Fred
Re: NSSwitch drawRect bug
This is a common problem in our drawing code, especially in GSTheme. In the
better cases we hand on the view/controller to be drawn along with the
requested rectangle. That way the drawing code could still optimise the
process, by only drawing components that are actually visible.
I will change the code as suggested by you.
Cheers,
Fred
> Am 11.08.2023 um 21:23 schrieb Austin Clow :
>
> In NSSwitch.m, the method for drawRect is as follows:
>
> - (void) drawRect: (NSRect)rect
> {
> [[GSTheme theme] drawSwitchInRect: rect
>forState: _state
> enabled: [self isEnabled]];
> }
>
> I believe it should be
>
> - (void) drawRect: (NSRect)rect
> {
> [[GSTheme theme] drawSwitchInRect: [self bounds]
>forState: _state
> enabled: [self isEnabled]];
> }
>
> As it is right now, when it redrawing a rect, it will redraw it within rect
> causing it to draw bigger and smaller depending not he redraw area. I'm not
> comfortable yet doing pull requests for a library I am largely unfamiliar
> with.
>
> I know the drawing method is kinda ugly right now. I am thinking about
> rewriting it.
Re: GNUstep Testsuite
You can always fallback to the inplace documentation in GNUstep make: https://github.com/gnustep/tools-make/tree/master/TestFramework Hope this helps, Fred > Am 05.08.2023 um 01:47 schrieb Tito Mari Francis Escaño > : > > Hi, > Can somebody please point me to the GNUstep Testsuite resources? > I clicked the link in https://gnustep.github.io/developers/documentation.html > and it went error 404, supposedly pointing to something in Github but it > seems it's no longer there. > I was hoping to learn how test-driven development is done in GNUstep and > Objective-C. > Please advise. > Thank you.
Re: tools-windows-msvc runtime error
I am no Windows expert but I remember that for some compilers we needed special symbol handling there. We use the macro GS_EXPORT_CLASS there which boils down to some __declspec(dllexport) declarations on classes. Not sure whether this would also be needed for a class that is only locally used. Overall it would really be helpful if you provided more information about the versions of the different components you are using. That is, which version of Windows, version of clang and libobjc2. Where did you get the GNUstep libraries and how did you install these? Cheers, Fred > Am 18.07.2023 um 03:00 schrieb loserist : > > Sure! The following is it: > > * thread #1, stop reason = Exception 0xc005 encountered at address > 0x7ffcec4e1048: Access violation reading locatio > n 0x > * frame #0: 0x7ffcec4e1048 objc.dll`objc_msgSend + 40 > frame #1: 0x7ff645cc1154 abc.exe > frame #2: 0x7ff645cc142c abc.exe > frame #3: 0x7ffcfb967614 kernel32.dll`BaseThreadInitThunk + 20 > frame #4: 0x7ffcfc1826b1 ntdll.dll`RtlUserThreadStart + 33 > Thanks!
Re: GNUstep Desktop
Wow, looks great and seems like a really impressive work! I admire how you base it on services one of the most undervalued features in GNUstep. One question though: Would it be possible to merge back the forked applications (Addresses and BatMon) to GAP? If you two need a tie breaker to decide on which version to use, I am willing to volunteer. Cheers Fred > Am 21.05.2023 um 02:38 schrieb Ondrej Florian via Info-gnustep > : > > Hi everyone, > > I'd like to announce GNUstep Desktop. > https://onflapp.github.io/gs-desktop/index.html > > I have been working on it for more than a year now and it is finally complete > enough to be my main desktop environment. > It is perfect for my Raspberry PI! :-) > > GSDE contains many GNUstep apps and frameworks in one place. > Enhanced, fixed, configured and integrated so that everything works together > seamlessly. > > Notable enhancements: > - StepTalk - used for system scripting, fixes and enhancements > to the API > - TextEdit- scriptable + enhancements for attachment and link > panels > - HelpViewer - uses filters to display man, info and gsdoc pages > - WrapperFactory - greatly enhanced, support for filters and services > - Terminal - a lot of improvements, refactored into Kit, > scriptable > - Preferences- taken from NEXTSPACE + additional settings for > timezone, keys, themes > - WindowMaker- make tweaks and fixes to fit with GNUstep > > New applications: > - WebBrowser - Google Chrome with GNUstep UI, scriptable > - VimGS - Vim with GNUstep UI (using TerminalKit), scriptable > - Player - VLC with GNUstep UI, scriptable > - DocViewer - PDF and HTML document viewer, filters for additional > formats (e.g. markdown), scriptable > - ImageViewer - filter for additional formats, scriptable > - RemoteView - VNCViewer > - Librarian - document indexing - similar to NeXT's Digital > Librarian > - ScreenShot- screenshot service > > Other apps: > Gorm and ProjectCenter, GWorkspace, GNUMail > > Other utilities: > Dictionary, Affiche, FTP, TalkSoup, EdenMath, Addresses > ForManager, DefaultsManager, Console, HtopGS, OpenUp, > Process monitor, Volume and Battery controls. > > ...and more > > WebPage: https://onflapp.github.io/gs-desktop/index.html > github: https://github.com/onflapp/gs-desktop > > --- > > Spending weeks and months deep in GNUstep and all those apps created with it, > made me really appreciate all the amazing work that went into it. > > I hope that GNUstep Desktop will help to renew the interest in GNUstep as > desktop. > > Ondrej > > > > ___ > Info-gnustep mailing list > info-gnus...@gnu.org > https://lists.gnu.org/mailman/listinfo/info-gnustep
Re: Base 1.28.1 API/ABI break?
> Am 09.01.2023 um 07:58 schrieb Andreas Fink : > > I usually build packages for Debian 10 & 11 for amd64 and arm64 > > I have encountered make check returning an error on Debian11 arm64 but not on > Debian 11 amd64 > > Built on Debian 11 intel: All OK! > Built on Debian 11 on arm64: 2 Failed tests > Failed test: (2023-01-09 07:39:12.574 +0100) general.m:37 ... > -classNamed returns the correct class > Failed test: (2023-01-09 07:39:12.576 +0100) general.m:61 ... > -principalClass returns TestClass for +bundleForClass:[TestClass class] > > I'm surprised as this stuff is not really architecture specific usually. > Which version of libobjc are you building against and is it the same for both architectures?
Re: Base 1.28.1 API/ABI break?
> Am 07.01.2023 um 19:42 schrieb Yavor Doganov :
>
> But when build-testing packages with GUI 0.30.0 I came upon this build
> failure of GDL2:
>
> gcc EOAdaptor.m -c \
> -MMD -MP -Wdate-time -D_FORTIFY_SOURCE=2 -DGNUSTEP_BASE_LIBRARY=1
> -DGNU_RUNTIME=1 -g -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1
> -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing -fexceptions
> -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS -pthread -fPIC -Wall -DGSWARN
> -DGSDIAGNOSE -Wno-import -g -O2 -g -O2
> -ffile-prefix-map=/build/gnustep-dl2-0.12.0=. -fstack-protector-strong
> -Wformat -Werror=format-security -DDEBUG
> -fconstant-string-class=NSConstantString -I../EOControl/. -I.. -I.
> -I/usr/local/include/GNUstep -I/usr/include/GNUstep \
> -o obj/EOAccess.obj/EOAdaptor.m.o
> EOAdaptor.m:132:39: error: 'NSGB2312StringEncoding' undeclared here (not in a
> function); did you mean 'NSHZ_GB_2312StringEncoding'?
> 132 | { @"NSGB2312StringEncoding",NSGB2312StringEncoding },
> | ^~
> | NSHZ_GB_2312StringEncoding
> EOAdaptor.m:135:39: error: 'NSBIG5StringEncoding' undeclared here (not in a
> function); did you mean 'NSBig5StringEncoding'?
> 135 | { @"NSBIG5StringEncoding", NSBIG5StringEncoding },
> | ^~~~
> | NSBig5StringEncoding
> make[6]: *** [/usr/share/GNUstep/Makefiles/rules.make:521:
> obj/EOAccess.obj/EOAdaptor.m.o] Error 1
>
> These encodings were renamed which (IMVHO) should not happen in a
> point release that should be fully compatible. There's a similar
> error when building SOPE (not maintained by us, Debian GNUstep team).
Which version of GDL2 are you getting this warnings from? I think the code in
question was removed more than ten years ago. But then the last release of GDL2
was 2009. Maybe a new release is required here?
Fred
Re: airyxOS has a new name: ravynOS
> Am 31.08.2022 um 21:23 schrieb Liam Proven : > > On Tue, 30 Aug 2022 at 17:50, Marco Cawthorne wrote: >> >> >> He compliments how much further along they are in adopting modern >> technologies than GNUstep. >> Pushing for Wayland is definitely 'ambitious' to say the least because >> it seems everyone else is somewhat struggling with it. Also GNUstep >> already relies on some of their work (libobjc2) it seems. Not exactly, libobjc2 was developed by David Chisnall and is actually part of GNUstep. As for Wayland, GNUstep has an experimental backend for that, feel free to test and improve it. Cheers, Fred
Re: Greg, are you o.k.?
Greg, I hope you get better soon. Lars, what did you discuss today and were there any agreements reached? I just came home a few minutes ago and tried to join the meeting but you already split up. I hope you had a nice meeting. Cheers, Fred > Am 06.08.2022 um 22:53 schrieb lars.sonchocky-helld...@hamburg.de: > > Greg, you don’t need to apologize. If you’re sick, you’re sick. We had a > meeting nevertheless, but I think nobody recorded it. I convey your apologies > by crossposting to discuss-gnustep. > > Kind regards, > > Lars > >> Am 06.08.2022 um 21:15 schrieb Gregory Casamento : >> >> Hey Lars. >> >> I have been very sick this morning. I apologize for not making it. Please >> convey my apologies. >> >> GC >> >> On Sat, Aug 6, 2022 at 14:10 lars.sonchocky-helld...@hamburg.de >> wrote: >> Greg, you didn’t make it to the quarterly GNUstep meeting today — I hope, >> nothing bad happened and you are o.k. >> >> Kind regards, >> >> Lars >> -- >> Gregory Casamento >> GNUstep Lead Developer / OLC, Principal Consultant >> http://www.gnustep.org - http://heronsperch.blogspot.com >> https://www.patreon.com/bePatron?u=352392 - Become a Patron >> https://gf.me/u/x8m3sx - My GNUstep GoFundMe >> https://teespring.com/stores/gnustep - Store >
Re: GNUstep Quarterly Meeting #2
I won’t be able to attend the GNUstep meeting on Saturday. I have just been invited on a short trip over to Strasbourg and have no idea at what time we will be back. I might be able to join you later, as I did the last time but don’t wait for me. Cheers Fred PS: The only news from my side is that I updated the GNUstep packages on the Open Suse Buildsystem. And it would be great to agree on a release date for the core packages. > Am 03.08.2022 um 05:26 schrieb greg.casame...@gmail.com: > > > Hey guys just a reminder. The meeting is this weekend. Please come. All > are welcome. > > GC > > GNUstep Quarterly Meeting #2 > Saturday Aug 6, 2022 ⋅ 12:30pm – 2:30pm (Eastern Time - New York) > I am planning on having these in the middle of every quarter. I realize most > people are in Europe, so I am going to make this at a time that I believe is > convenient for most people. We have two months to go for this so, if you > would like to suggest a time please do so here on google calendar. > Ultimately I would like to move to an open-source/free software solution for > scheduling as well, but for right now Google Calendar will need to do. > > Please note, I would very much like this meeting to be recorded so that we > can learn the most from the experience. > > Yours always, GC > > > Click the following link to join the meeting from your computer: > https://meet.jit.si/TheatricalNecessitiesFormulateNotably > > = > > Just want to dial in on your phone? > > Call one of the following numbers: > Australia: +61.8.7150.1136 > Brazil: +55.21.3500.0112 > Canada: +1.437.538.3987 > France: +33.1.87.21.0005 > Japan: +81.3.4510.2372 > Netherlands: +31.85.208.1541 > Spain: +34.932.205.409 > Switzerland: +41.61.588.0496 > UK: +44.203.885.2179 > US: +1.512.647.1431 > > Dial your meeting ID: '4036948717' and you will be connected! > > Location > Jitsi Meeting - https://meet.jit.si/TheatricalNecessitiesFormulateNotably > View map > Guests > greg.casame...@gmail.com - organizer > fredkie...@gmx.de > h...@goldelico.com > discuss-gnustep@gnu.org > frede...@algoriddim.com > riccardo.mott...@libero.it > mul...@gmail.com > ape...@alexperez.com > ste...@stevenrbaker.com > h...@computer.org > nicola.p...@brainstorm.co.uk > fe...@gnu.org > r...@gnu.org > r...@gnu.org > iaml...@gmail.com
Re: Porting GNUstep to the RISC-V architecture
I committed both changes together to a tools-make branch. Somebody now has to check whether this still works with MSVC as config.guess seem to have dropped support for that platform. As far as I can tell we currently don’t have any CI pipeline set up for make. This is probably tested when building base. Frederik, could you please have a look? Cheers, Fred > Am 08.05.2022 um 22:49 schrieb lars.sonchocky-helld...@hamburg.de: > > Hi Fred, > > I did this change only in tools-make but then again I’ve built the whole > GNUstep hierarchy at once using that compile-all script from tools-scripts. > So I guess it might be different if you’re building those modules separately. > I think it wouldn’t hurt to update the config.guess and the config.sub > everywhere just to be safe. > > kind regards, > > Lars > >> Am 08.05.2022 um 22:24 schrieb Fred Kiefer : >> >> OK, so I will undo my local change and instead update these two files. Was >> that change needed for all GNUstep modules? >> >> Fred >> >>> Am 08.05.2022 um 05:15 schrieb lars.sonchocky-helld...@hamburg.de: >>> >>> From sheer excitement I forgot to answer your question: configure works >>> fine so far even when not updating configure and configure.ac, e.g. >>> replacing config.guess and config.sub with recent versions is just enough. >>> >>> regards, >>> >>> Lars >>> >>>> Am 08.05.2022 um 01:11 schrieb Fred Kiefer : >>>> >>>> Lars, >>>> >>>> could you please try whether it would be sufficient to just replace these >>>> two file without updating configure and configure.ac? >>>> That update is fine for me, but it would stop people with an old autoconf >>>> to regenerate the configure file. >>>> >>>> Cheers, >>>> Fred >> >
Re: Porting GNUstep to the RISC-V architecture
OK, so I will undo my local change and instead update these two files. Was that change needed for all GNUstep modules? Fred > Am 08.05.2022 um 05:15 schrieb lars.sonchocky-helld...@hamburg.de: > > From sheer excitement I forgot to answer your question: configure works fine > so far even when not updating configure and configure.ac, e.g. replacing > config.guess and config.sub with recent versions is just enough. > > regards, > > Lars > >> Am 08.05.2022 um 01:11 schrieb Fred Kiefer : >> >> Lars, >> >> could you please try whether it would be sufficient to just replace these >> two file without updating configure and configure.ac? >> That update is fine for me, but it would stop people with an old autoconf to >> regenerate the configure file. >> >> Cheers, >> Fred
Re: Porting GNUstep to the RISC-V architecture
Lars, could you please try whether it would be sufficient to just replace these two file without updating configure and configure.ac? That update is fine for me, but it would stop people with an old autoconf to regenerate the configure file. Cheers, Fred > Am 08.05.2022 um 00:32 schrieb lars.sonchocky-helld...@hamburg.de: > > Hi Fred, Hi Greg, > > > That Autoconf was too old, was already the right idea, however differently > than assumed. I'll get to that in a moment. First the good news: I have made > significant progress in porting GNUstep to RISC-V by making changes to > Autoconf. Configure is basically working now, although many dependencies for > a real compilation of GNUstep are still missing. However, I had not installed > these dependencies before either. > > What did I do? > > First a checkout of all major GNUstep subprojects: > > $ mkdir Sources > $ cd Sources > $ git clone http://github.com/gnustep/tools-make > $ git clone http://github.com/gnustep/libs-base > $ git clone http://github.com/gnustep/libs-back > $ git clone http://github.com/gnustep/libs-gui > $ git clone http://github.com/gnustep/tools-scripts > > Then I ran the build script in tools-scripts: > > $ ./tools-scripts/compile-all &> compile-all-out.txt > > (see attachment) > > compile-all-out.txt now revealed that already configure did not run correctly. > > > ---8<--- > > BUILDING WITH GCC > Build command: CCFLAGS= CC=gcc ./configure --prefix=/usr/GNUstep > --with-layout=gnustep > > checking build system type... ./config.guess: unable to guess system type > > This script, last modified 2016-04-02, has failed to recognize > the operating system you are using. It is advised that you > download the most up to date version of the config scripts from > > http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess > and > http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub > > If the version you run (./config.guess) is already up to date, please > send the following data and any information you think might be > pertinent to in order to provide the needed > information to handle your system. > > config.guess timestamp = 2016-04-02 > > ---8<--- > > > Fred then made changes to configure and configure.ac and sent them to me. > > I applied those changes and then ran this command: > > $ ./tools-scripts/compile-all &> compile-all-out.1.txt > > (see attachment) > > It turned out that Fred's changes did not include everything necessary, > configure failed again (analogous to before). > > A closer look at the error messages of configure suggested that especially > the files config.guess and config.sub had to be replaced: > > ---8<--- > > It is advised that you > download the most up to date version of the config scripts from > > http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess > and > http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub > > ---8<--- > > I downloaded both files (and added them to the archive in the attachment) and > of course replaced these two files with the new variants in tools-make. A > comparison of the new and old variants brought to light that in the previous > version of config.guess from 2016-04-02 the term "riscv" does not appear, > this architecture was at that time at least unknown to Autoconf. > > After replacing the config.guess and config.sub files with their more recent > variants, I ran the following command: > > $ ./tools-scripts/compile-all &> compile-all-out.2.txt > > (see attachment) > > Now configure ran through, however nothing has been built yet, since an ObjC > compiler is missing on the system. > > > Kind regards, > > Lars > >
Re: Reminder of quarterly meetup... Sat, May 7th 2022...
I am sorry, I won’t make it for tomorrows quarterly meeting. The most important subject for me would have been a release for the core libraries and as Ivan will be busy with other stuff, this seems out of reach for the near future. Looking forward to see you again in the next quarter. Fred > Am 07.03.2022 um 10:04 schrieb Gregory Casamento : > > Here are the meeting details in plain text... > > It is at 12:30-2:30pm Eastern Standard Time on the day mentioned... > > I am planning on having these in the middle of every quarter. I realize most > people are in Europe, so I am going to make this at a time that I believe is > convenient for most people. We have two months to go for this so, if you > would like to suggest a time please do so here on google calendar. > > Ultimately I would like to move to an open-source/free software solution for > scheduling as well, but for right now Google Calendar will need to do. > > Please note, I would very much like this meeting to be recorded so that we > can learn the most from the experience. > > Yours always, GC > > > Click the following link to join the meeting from your computer: > https://meet.jit.si/TheatricalNecessitiesFormulateNotably > > = > > Just want to dial in on your phone? > > Call one of the following numbers: > Australia: +61.8.7150.1136 > Brazil: +55.21.3500.0112 > Canada: +1.437.538.3987 > France: +33.1.87.21.0005 > Japan: +81.3.4510.2372 > Netherlands: +31.85.208.1541 > Spain: +34.932.205.409 > Switzerland: +41.61.588.0496 > UK: +44.203.885.2179 > US: +1.512.647.1431 > > Dial your meeting ID: '4036948717' and you will be connected! > > > On Mon, Mar 7, 2022 at 3:54 AM Gregory Casamento > wrote: > All, > > The next meeting is on May 7th... please see the link below. > > https://calendar.google.com/event?action=TEMPLATE=Mzg2MHBlMzBnbG9yNjhtZGM1OHBjNHJyYzlfMjAyMjA1MDdUMTYzMDAwWiBncmVnLmNhc2FtZW50b0Bt=greg.casamento%40gmail.com > > If you are interested in attending, please RSVP or just show up. :) > > For members of the GNUstep team... please remember. These meetings, while > not a "steering committee", are not just social events. They are also used > to discuss things and, possibly, make decisions about things that are > relevant to the project. > > Yours, GC > -- > Gregory Casamento > GNUstep Lead Developer / OLC, Principal Consultant > http://www.gnustep.org - http://heronsperch.blogspot.com > https://www.patreon.com/bePatron?u=352392 - Become a Patron > https://gf.me/u/x8m3sx - My GNUstep GoFundMe > https://teespring.com/stores/gnustep - Store > > > > -- > Gregory Casamento > GNUstep Lead Developer / OLC, Principal Consultant > http://www.gnustep.org - http://heronsperch.blogspot.com > https://www.patreon.com/bePatron?u=352392 - Become a Patron > https://gf.me/u/x8m3sx - My GNUstep GoFundMe > https://teespring.com/stores/gnustep - Store
Re: Clang/LLVM migration roadmap
> Am 06.02.2022 um 01:14 schrieb Gregory Casamento :
>
> There are a number of factors that are driving this:
> --
> 1) GCC lacks support for many memory management features that are commonly
> used today
> 2) GCC's objective-c support is lagging behind and doesn't include support
> for @[], @{}, @autorelease, etc etc etc
> 3) Lack of bug fixes in GCC's implementation of ObjC
> 4) GCC team does not consider ObjC release critical and will and HAS released
> with broken support for building ObjC targets.
> All of these things are UNACCEPTABLE
Again I beg to differ. Of course the first two point are true and need to be
addressed. But I am not aware of any critical bug in gcc that is currently
hindering us. There are many missing features and this is really bad for
GNUstep and ObjC as a whole. As for the position of the gcc team on ObjC, none
of knows and we only may guess here. The one time where a gcc release knowingly
broke ObjC was ages ago. Maybe it could happen again, we just don’t know.
Stating something as a fact that is just a possibility is a rather annoying
habit of our times. Please don’t do so on the GNUstep mailing list.
As is typing words in all capital letters. It really doesn’t help in polite
conversations.
Fred
Re: Notes from meeting Q1 2022
> Am 06.02.2022 um 15:42 schrieb Gregory Casamento : > > Here are the "raw" notes from yesterday's meeting... > • Wolfgang email > • libobjc2 > • PR for windows > • exceptions not working. > • fragility on other platforms. > • linker dependencies > • Xcode-lib > • Put solution files into instructions. — Frederick Seiffert > • Commit hook for @gnustep twitter account > • GITHUB Action > • build with clang > • build .deb files. > • build .rpm files. > • NIGHTLY BUILD > • RMS > • Write about participation — pointless given the > decision to move more toward LLVM/clang I disagree here. Most likely the sentence after the hyphen is you personal opinion after the meeting. At lease during the two hours I attended nobody stated this. The idea here was to get in touch with the gcc developers over better support for libobjc2 from gcc (not stated in the protocol). And as you didn’t know who the current gcc maintainers are I suggested to last RMS on that point as he wrote he already spoke to them last year on that subject. It really would help to keep personal opinions outside of the notes. Everybody who attended or didn’t attend may have differing views but the notes should somehow represent what was discussed during the meeting. Otherwise they are pointless. > • Phase ARC into core libraries — RFM > • ROADMAP to move to clang if GCC is not up to spec > • Reference implementation > • VOID LINUX — Hugo > • FRED TOPICS > • Spring release — Mention on list > • Updated Fred UBS
Re: ANN: GWorkspace 1.0
Thank you Riccardo for your great work on this release and for the kind words you found fro remember Bertrand. Merry Christmas to you, Fred > Am 25.12.2021 um 01:37 schrieb Riccardo Mottola : > > GWORKSPACE 1.0 > -- > > Christmas, in Anno Domini 2021. > > This is a different announcemement than usual, since it is a special release: > it is tagged 1.0 after many years of work. It is different, because it is a > personal writing. The last release has been long ago, but many refinements > and improvements came in; there has been a person who spurred me improving > and working on GWorkspace: Bertrand Dekoninck. > > Hard times were the past two years and they have not been easy and the > pandemic is not yet over, so in the Christmas Eve, a new release of > GWorkspace has been done and it is dedicated to Bertrand: so shall he be > remembered from us GNUsteppers, he, who had not the privilege to live till > Christmas with his family. > > A reserved user who really gave the sensation to be interested in GNUstep and > its applications, thus, especially GWorkspace. Continuously he proposed > contributions, tested, always gentle, collaborative: a friend. I will miss > him, we will miss him. > Betrand, as me, worked also on PowerPC - so it was inspiring to know that > supporting that Big Endian platform was useful! After the pandemic, I wanted > to meet hi8mfor a hacking session, but it will no longer happen on earth. > > Merry Christmas and a Happy New Year! > > > Riccardo > > > What is new? > > * "Modern mode" enables now clearer icon lables on the desktop > * Single click launch is now an option and affects the Dock and the Tabbed > shelf > * cleaned up code in Shelf and Dock Icons > * Fixed display of available tools for documents in the inspector > * Improved display of handled extensions for an applications > * Improve image scaling for image content inspector and image thumbnailer > * Better handling of removable volumes > * Improved French, Italian and Spanish localizations, as well as new Japanese > and Polish ones > * The build system was improved and cleaned up, allowing easier packaging and > building on different platforms > * Fix crash in Metadata extractor > * Fix build failure on GNU/HURD > > Links for info and downloads: > > http://www.gnustep.org/experience/GWorkspace.html > http://www.gnustep.org/resources/downloads.php > https://github.com/gnustep/apps-gworkspace > > -- > Sent with GNUMail on GNUstep on Gentoo running on a ThinkPad T510i-i5. > >
Re: Wayland backend
Great improvement! Thank you for that. > Am 06.11.2021 um 13:33 schrieb Riccardo Canalicchio > : > > Hello, > following up on this, I moved forward with the implementation and I have got > to a working state. (with still some bugs but usable) > Windows are shown properly, dropdown menus as well, resize and move work. > The implementation is tested on Weston, GnomeShell and some other compositors > based on wlroots. It uses the protocol xdgshell widely adopted in all the > compositors as well the layer shell protocol which is currently adopted by > the wlroots compositors and ubuntu shell. > Here a PR: https://github.com/gnustep/libs-back/pull/33 > > note: To be able to associate submenus to the parent windows i had to make a > change to libs-gui: > https://github.com/nongio/libs-back/blob/wayland/Source/wayland/WaylandServer.m#L894 > maybe there are better ways to do it, in case you think it's ok i would > proceed to make a PR for libs-gui too Could you please explain this a bit? What is the issue here and what is your workaround? And what could be a better workaround in gui? Cheers, Fred
Re: Changing control font size
> Am 23.09.2021 um 13:19 schrieb Andreas Höschler :
>
>
>> Ignore that list. The only defined font sizes in the defaults are
>> @„NSFontSize“, @„NSLabelFontSize“ and @„NSSmallFontSize“. You have to use
>> these strings if you want to set this programmatically
>
> I have done
>
> - (void)applicationDidFinishLaunching
> {
>#ifndef __APPLE__
>[[NSUserDefaults standardUserDefaults] setObject:[NSNumber
> numberWithFloat:20.0] forKey:@"NSFontSize"];
>[[NSUserDefaults standardUserDefaults] setObject:[NSNumber
> numberWithFloat:20.0] forKey:@"NSLabelFontSize"];
>#endif
>
> }
>
> but this does not seem to have changed anything. The font used by TableViews,
> ComboBoxes, TextFields and Buttons is still the same!?
Thinking about this a bit gave me a hint. Do the elements with the wrong font
size come from a Gorm or NIB file? When encoding a font object we store its
actual size and when regenerating the font we use that size. This is of course
wrong. We should store the standard size as 0, so that the current standard
size gets used when recreating the object. This is easy to change in the code,
still all old NIB and Gorm files will behave wrong. We could try to treat 12
the same as 0 when decoding. But this both won’t work for label and small
system font size.
Anybody with a better idea out there?
>> but most likely it is easier to set them via the defaults file once.
>
> You mean
>
> defaults write ScaleMaster NSFontSize 20
> defaults write ScaleMaster NSLabelFontSize 20
Yes, that is what I was suggesting.
Fred
Re: Changing control font size
Ignore that list. The only defined font sizes in the defaults are @„NSFontSize“, @„NSLabelFontSize“ and @„NSSmallFontSize“. You have to use these strings if you want to set this programmatically but most likely it is easier to set them via the defaults file once. Hope this helps, Fred > Am 22.09.2021 um 15:40 schrieb Andreas Höschler : > > Hi all, > > I am building a GNUstep app on Ubuntu 20.04 and would like the font used by > NSButtons, NSTableView, NSComboBox etc. to be larger as normal for industrial > usage of the app (better readability from further away from the screen). > > I found this list > > NSBoldFontSize > > > > NSControlContentFontSize > > > > NSFontSize > > > > NSLabelFontSize > > > > NSMenuFontSize > > > > NSMiniFontSize > > > > NSMessageFontSize > > > > NSPaletteFontSize > > > > NSSmallFontSize > > > > NSTitleBarFontSize > > > > NSToolTipsFontSize > > > > NSUserFixedPitchFontSize > > > > NSUserFontSize > and greped through the GNUstep sources for NSControlContentFontSize but only > found > > grep -r "NSControlContentFontSize" /usr/src/GNUstep/ > > /usr/src/GNUstep/libs-gui/Source/NSFont.m:NSControlContentFontSize > (none) > /usr/src/GNUstep/libs-gui/Source/NSToolbarItem.m: // [NSFont > smallSystemFontSize] or better should be NSControlContentFontSize > > Is this default used at all? How would I programmatically change the font > size for all the controls in the user interface. I intuitively tried > >[[NSUserDefaults standardUserDefaults] setObject:[NSNumber > numberWithFloat:20.0] forKey:NSControlContentFontSize]; >[[NSUserDefaults standardUserDefaults] setObject:[NSNumber > numberWithFloat:20.0] forKey:NSLabelFontSize]; > > but this of course does not build since NSControlContentFontSize is > undefined. > > I am obviously missing the point!? :-( > > Any idea? > > Thanks a lot, > > Andreas > > >
Re: NSInvalidArgumentException building GSspell.service
The program make_services is in the unlucky situation of being the first Objective-C program that is executed on your system. If you run the tests of base (make check) you would be getting similar errors a bit earlier. I still would prefer to better understand your setup before going into detailed analysis here. An as this involves a non standard architecture it would be great to get David and Riccardo involved as they know a lot more about GNUstep and clang on PowerPC. Cheers, Fred > Am 10.09.2021 um 01:00 schrieb Mick Bert : > > > > Again, after installing gnustep-make 2.9.0, and gnustep-base 1.28.0, > compiling gnustep-gui 0.29.0 on a debian powerpc port with clang 9.0.1-16.1, > I got the error: > > Creating GSspell.service/Resources/Info-gnustep.plist... > ././obj/make_services: Uncaught exception NSInvalidArgumentException, reason: > Tried to init dictionary with nil key > > and I have no idea about how to proceed. > > -- > > Mick >
Re: CPPFLAGS ignored compiling gui
Hi Mick, this sounds a bit strange. You are building GNUstep with clang but point it to use the gcc libobjc? This might work but surely it isn’t a recommended setup. Why would you want to do that? When using clang you should be using the GNUstep libobjc2. Confused, Fred > Am 10.09.2021 um 00:16 schrieb Mick Bert : > > Hello > > I am trying to compile gnustep (latest release, downloaded a couple of days > ago) on a Debian 5.10.46-powerpc, with clang. > > Configured gnustep-gui with > CPPFLAGS=-I/usr/lib/gcc/powerpc-linux-gnu/9/include and > CFLAGS=-I/usr/lib/gcc/powerpc-linux-gnu/9/include (which is the directory > containing objc/objc.h), when I run make,it fails on source > Model/IMCustomObject.m with error: > > In file included from IMCustomObject.m:28: > In file included from > /opt/Local/Library/Headers/Foundation/NSObjCRuntime.h:222: > /opt/Local/Library/Headers/GNUstepBase/GSObjCRuntime.h:58:11: fatal error: > 'objc/objc.h' file not found > #include > > If I run make -n, I get: > > clang-9 IMCustomObject.m -c -MMD -MP -DGNU_RUNTIME=1 -DGNU_GUI_LIBRARY=1 > -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 > -DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing -pthread -fPIC -Wall -DGSWARN > -DGSDIAGNOSE -Wno-import -g -O2 -fobjc-runtime=gcc -Wall > -fconstant-string-class=NSConstantString -I../Headers/Additions -I../Headers > -I. -I/home/mick/GNUstep/Library/Headers -I/opt/Local/Library/Headers > -I/opt/System/Library/Headers -o obj/libgmodel.obj/IMCustomObject.m.o > > which is clearly missing the directory containing objc.h > > Where should I have to specify that directory, in order it to be added to > that compiling command? > > -- > > Mick >
Re: related websites and links
> Am 14.08.2021 um 18:38 schrieb Riccardo Mottola : > > > checking some of our pages, I found some "cruft" and I'd like your opinions > on it and "actions". > > 1) http://www.gnustep.it/ > > A top-level domain which is stuck in the past - I wonder if it is of Nicola > and who maintains it?It is not in Italian at all! What a great page! It is like a time machine back to the good old GNUstep from early 2000. > It contains obsolete information (e.g.Workspace pages > http://www.gnustep.it/enrico/gworkspace/ which are totally old and which I > completely replaced with http://www.gnustep.org/experience/GWorkspace.html ) > > Obsolete tutorial http://www.gnustep.it/pierre-yves/index.html which I > completely updated and redid here: > > > JIGS - does it still exist? works? should i become part of the main > development pages? As far as I know still still exists and gets used at Brainstorm, or what ever they are called now. It should be documented on our main web page. > Renaissance: it is part of GNUstep and has its repository on GIT, shouldn't > we integrate it in the main website ? Yes, this too, please. > Main website: > > We should agree on where to report bugs (savannah or GIT) and choose what to > do with "bugs.gnustep.org" and then update accordingly. I know Greg's > position on it, but I'd like to raise the discussion on this again. > > > Related projects: are these still alive? does it make sense to link and > sponsor them? I just checked on gnustep.org as well as on gap.nongnu.org > > * www.etoile-project.org we still sponsor it high, but it is almost a dead > collection? At least the website is so; should we still sponsor it so > prominently? We should still link to it, but maybe not that prominently. > * http://www.nongnu.org/backbone/ - latest commit I see is 4 years old That is not that long ago :-) > > * http://interfacewm.sourceforge.net/ seems total retrocomputing :) > > * ImageApps still points to https://home.gna.org/gsimageapps/ what happened > to them ? > > * http://www.collaboration-world.com/cgi-bin/error.cgi?id=1 goes on error, > but the domain is half there, should we hide it in favour of gnustep-nonfsf ? > > * Advogato - it is dead now... so we should kill links to it > > * http://fortytwo.sourceforge.net/ didn't even know we had this project, tell > me about it!!! Never heard about that either. (Or at least I don’t remember)
Re: Notes from GNUstep quarterly meet up...
Hi Steven, great that you volunteer! Greg already replied with information on the webpage part. For gcc things are a bit more complicated. The notes that Greg took leave out a bit of the discussion there. The problem is not whether gcc maintainers would accept our patches. It is rather that to come up with a solution here we all agreed that help from some gcc developers would be required. We don’t know whether anybody there is willing to support us. Previous attempts were not very promising. What I could do is get you in contact with RMS who offered to help to get the necessary people together. I also have some preliminary ideas on how to address the issues. Contact me directly if you are interested. Cheers, Fred > Am 13.08.2021 um 01:57 schrieb Steven R. Baker : > > I would like to volunteer to have website tasks assigned to me. You can be > vague and open ended with these. > > I’m also happy to work on the gcc bits but I’ll need a pair or a sherpa on > that because though I’d like to work on that, I have very little experience > working on compilers. > >> 12 aug. 2021 kl. 20:38 skrev Gregory Casamento : >> >> >> Hey guys... I would like to see if we can break out this list into action >> items and make some issues and assign them to certain individuals. This >> way we make some progress based on our discussion. >> >> I will take a stab at making a list of action items and post them here. If >> anyone has any feedback, let me know. >> >> Thx, GC >> >> On Sat, Aug 7, 2021 at 12:00 AM Gregory Casamento >> wrote: >> Hey all, >> >> The meet up went well. I REALLY enjoyed meeting everyone and I found the >> discussion very interesting and productive. I took notes during the >> meeting. We did not have an agenda so these points came up naturally. I >> have noted who brought them up. Riccardo joined later, so I took down his >> thoughts. I am glad we did this and am very much looking forward to the >> next time. >> >> So, for your comment and review here are the notes: >> >> * Website (David Wetzel - DW) >> * Need to have the website present a solution for installing GNUstep >> quickly. Make a script… >> * tutorials to get from to hello world quickly >> * (Riccardo M. - RM) Discuss with Riccardo what changes are needed. >> * Usability (DW) >> * More command line interfaces >> * Terminal based environment >> * Terminal only based tutorial >> * GCC vs. LLVM/Clang (DW) >> * Clang has an advantage because ObjC is more of a focus >> * Fred: Is it possible to get gcc up to spec? >> * Require time from GS developers? >> * Who should do it? >> * Will GCC accept our patches? >> * RMS asked, and GCC said they would review our patches with >> “kinder” eye. >> * Issues with libobjc2 - (RM) - This is a consistent issue on a lot of >> platforms. LLVM/Clang Doesn’t work on ALL platforms. >> * Doesn’t work NetBSD >> * uses CMAKE, but would be better using STRAIGHT make as CMAKE is >> not available or not easy to configure >> * Cairo - Problems (Fred Kiefer - FK) >> * unmaintained — should we move to another library?? >> * Can we replace the current Cairo with a hw accelerated library? Or any >> other commonly used library that is maintained!? >> * Cocotron (FK) >> * Can we use any Cocotron code? >> * MIT based. So we may be able to reuse some of their code or take >> ideas from their code. >> >> I will be posting these to the wiki or to the website soon. >> >> Yours, GC >> -- >> Gregory Casamento >> GNUstep Lead Developer / OLC, Principal Consultant >> http://www.gnustep.org - http://heronsperch.blogspot.com >> https://www.patreon.com/bePatron?u=352392 - Become a Patron >> https://gf.me/u/x8m3sx - My GNUstep GoFundMe >> https://teespring.com/stores/gnustep - Store >> >> >> >> -- >> Gregory Casamento >> GNUstep Lead Developer / OLC, Principal Consultant >> http://www.gnustep.org - http://heronsperch.blogspot.com >> https://www.patreon.com/bePatron?u=352392 - Become a Patron >> https://gf.me/u/x8m3sx - My GNUstep GoFundMe >> https://teespring.com/stores/gnustep - Store
Re: GNUstep Quarterly Meeting
Does this mean the meeting is basically already over? In my calendar it should only start in ten minutes. Fred > Am 06.08.2021 um 16:46 schrieb lars.sonchocky-helld...@hamburg.de: > > The link worked fine, there were three of us in the conference at 10:00 am > EST. > >> Am 06.08.2021 um 16:22 schrieb Gregory Casamento : >> >> It is the link jitsi gave me. If it isnt then i can use zoom. But i wanted >> to keep it on free software. ;) >> >> On Fri, Aug 6, 2021, 9:58 AM lars.sonchocky-helld...@hamburg.de >> wrote: >> Hi Greg, >> >> is this surely the correct link? It looks a bit to generic to me … >> >> regards, >> >> Lars >> >>> Am 22.07.2021 um 13:46 schrieb Gregory Casamento : >>> >>> The meeting link is here... >>> >>> Jitsi Meeting - https://meet.jit.si/LiveAttendancesConfrontInitially >>> >>> It is on August 6th from 10AM to 12PM (2 hours) EST. >>> >>> A few people have been explicitly invited, but anyone may attend. You are >>> all hereby invited to join on that date. >>> >>> Thanks for being part of this project. >>> >>> Yours, GC
Re: GNUstep Quarterly Meeting
I expected the meeting to start in an hour. After your mail I joined with the link below, but there is nobody else there. Fred > Am 06.08.2021 um 16:06 schrieb Gustavo Tavares : > > 3 of us are here inside the link. Bob, Lars and me :) > > On Fri, Aug 6, 2021, at 10:00 AM, Gustavo Tavares wrote: >> I'm inside the meeting. Don't see anybody Lars. Are you there? >> >> On Fri, Aug 6, 2021, at 9:58 AM, lars.sonchocky-helld...@hamburg.de wrote: >>> Hi Greg, >>> >>> is this surely the correct link? It looks a bit to generic to me … >>> >>> regards, >>> >>> Lars >>> Am 22.07.2021 um 13:46 schrieb Gregory Casamento : The meeting link is here... Jitsi Meeting - https://meet.jit.si/LiveAttendancesConfrontInitially It is on August 6th from 10AM to 12PM (2 hours) EST. A few people have been explicitly invited, but anyone may attend. You are all hereby invited to join on that date. Thanks for being part of this project. Yours, GC -- Gregory Casamento GNUstep Lead Developer / OLC, Principal Consultant http://www.gnustep.org - http://heronsperch.blogspot.com https://www.patreon.com/bePatron?u=352392 - Become a Patron https://gf.me/u/x8m3sx - My GNUstep GoFundMe https://teespring.com/stores/gnustep - Store
Re: GNUstep - Documentation
Bob, you should not give up too soon. Just ignore the corebase error and go ahead and compile GNUstep gui and core. You will need some extra libraries for these. Not having done a Windows compile in years, I don't remember which ones. But after that you should be able to compile and run your own code. Cheers, Fred On the road Am 25.07.2021 um 11:23 schrieb Bob Plymale : > It seems all of the documentation for install configuration is dated and no > longer works as described, such as the Windows installer, It didn't play > well, so I dropoped it. Then it was recommended to follow the tutorial > gnustep/tools-windows-msvc at https://github.com/gnustep/tools-windows-msvc. > This one had potiential but alas running the build.bat script bombed with the > following errors: > > 1 warning generated. > Linking library libgnustep-corebase ... > lld-link: error: undefined symbol: __declspec(dllimport) pthread_once > >>> referenced by > >>> C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:436 > >>> > >>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(CFRunLoopGetCurrent) > >>> referenced by > >>> C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:462 > >>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(CFRunLoopGetMain) > > lld-link: error: undefined symbol: __declspec(dllimport) pthread_getspecific > >>> referenced by > >>> C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:438 > >>> > >>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(CFRunLoopGetCurrent) > > lld-link: error: undefined symbol: __declspec(dllimport) pthread_setspecific > >>> referenced by > >>> C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:442 > >>> > >>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(CFRunLoopGetCurrent) > > lld-link: error: undefined symbol: __declspec(dllimport) pthread_key_create > >>> referenced by > >>> C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:424 > >>> > >>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(_CFRunLoopCreateThreadKey) > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > make[4]: *** > [/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Instance/library.make:307: > obj/gnustep-corebase.lib] Error 1 > make[3]: *** > [/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Instance/library.make:292: > internal-library-all_] Error 2 > make[2]: *** > [/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Master/rules.make:297: > libgnustep-corebase.all.library.variables] Error 2 > make[1]: *** > [/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Master/library.make:37: > internal-all] Error 2 > make: *** > [/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Master/serial-subdirectories.make:53: > internal-all] Error 2 > Failed > > > > I have some macOS code that I want to make multiplatform so I was leaning > towards rewrite in wxWidgets so my code portable. Basically if I could get > objective-c to work on windows and linux that would be my portable code, and > to say I really enjoy coding in objective-c regardless of what Apple does > with thee version. > > > > Bob
Re: GNUstep Windows MSVC Toolchain Error
If you do not need corebase, then you should be good to go. Just ignore this failure. I am sure Frederik will update his scripts soon. Fred On the road Am 24.07.2021 um 13:03 schrieb Bob Plymale : > Thanks for the reply Fred, > > I am not trying to build codebase by itself, I am following the steps in the > following link: > > > > GNUstep Windows MSVC Toolchain > https://github.com/gnustep/tools-windows-msvc > I did the prerequisites steps, and them executed the build.bat file and the > script did everything. > > Bob > >> On 7/24/2021 6:47 AM, Fred Kiefer wrote: >> It looks like you are trying to build corebase. This has not been ported >> over to the new MSVC toolchain. Has base now no longer requires the pthread >> library, this seems to be missing in the link statement. Do you really need >> corebase? If so, you will have to add pthread as a dependency there. >> >> Hope this helps, >> Fred >> >> On the road >> >> Am 24.07.2021 um 11:13 schrieb Bob Plymale : >> >>> I can get this far with the build, but errors out. >>> >>> I guess, has anyone been able to get this to work on Windows? >>> >>> >>> >>> I sure could use some assistance on getting this to work if possible. >>> 1 warning generated. >>> Linking library libgnustep-corebase ... >>> lld-link: error: undefined symbol: __declspec(dllimport) pthread_once >>> >>> referenced by >>> >>> C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:436 >>> >>> >>> >>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(CFRunLoopGetCurrent) >>> >>> referenced by >>> >>> C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:462 >>> >>> >>> >>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(CFRunLoopGetMain) >>> >>> lld-link: error: undefined symbol: __declspec(dllimport) pthread_getspecific >>> >>> referenced by >>> >>> C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:438 >>> >>> >>> >>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(CFRunLoopGetCurrent) >>> >>> lld-link: error: undefined symbol: __declspec(dllimport) pthread_setspecific >>> >>> referenced by >>> >>> C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:442 >>> >>> >>> >>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(CFRunLoopGetCurrent) >>> >>> lld-link: error: undefined symbol: __declspec(dllimport) pthread_key_create >>> >>> referenced by >>> >>> C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:424 >>> >>> >>> >>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(_CFRunLoopCreateThreadKey) >>> clang: error: linker command failed with exit code 1 (use -v to see >>> invocation) >>> make[4]: *** >>> [/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Instance/library.make:307: >>> obj/gnustep-corebase.lib] Error 1 >>> make[3]: *** >>> [/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Instance/library.make:292: >>> internal-library-all_] Error 2 >>> make[2]: *** >>> [/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Master/rules.make:297: >>> libgnustep-corebase.all.library.variables] Error 2 >>> make[1]: *** >>> [/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Master/library.make:37: >>> internal-all] Error 2 >>> make: *** >>> [/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Master/serial-subdirectories.make:53: >>> internal-all] Error 2 >>> Failed >>> >>> c:\Users\bplym\Desktop\tools-windows-msvc>
Re: GNUstep Windows MSVC Toolchain Error
It looks like you are trying to build corebase. This has not been ported over to the new MSVC toolchain. Has base now no longer requires the pthread library, this seems to be missing in the link statement. Do you really need corebase? If so, you will have to add pthread as a dependency there. Hope this helps, Fred On the road Am 24.07.2021 um 11:13 schrieb Bob Plymale : > I can get this far with the build, but errors out. > > I guess, has anyone been able to get this to work on Windows? > > > > I sure could use some assistance on getting this to work if possible. > 1 warning generated. > Linking library libgnustep-corebase ... > lld-link: error: undefined symbol: __declspec(dllimport) pthread_once > >>> referenced by > >>> C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:436 > >>> > >>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(CFRunLoopGetCurrent) > >>> referenced by > >>> C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:462 > >>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(CFRunLoopGetMain) > > lld-link: error: undefined symbol: __declspec(dllimport) pthread_getspecific > >>> referenced by > >>> C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:438 > >>> > >>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(CFRunLoopGetCurrent) > > lld-link: error: undefined symbol: __declspec(dllimport) pthread_setspecific > >>> referenced by > >>> C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:442 > >>> > >>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(CFRunLoopGetCurrent) > > lld-link: error: undefined symbol: __declspec(dllimport) pthread_key_create > >>> referenced by > >>> C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:424 > >>> > >>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(_CFRunLoopCreateThreadKey) > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > make[4]: *** > [/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Instance/library.make:307: > obj/gnustep-corebase.lib] Error 1 > make[3]: *** > [/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Instance/library.make:292: > internal-library-all_] Error 2 > make[2]: *** > [/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Master/rules.make:297: > libgnustep-corebase.all.library.variables] Error 2 > make[1]: *** > [/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Master/library.make:37: > internal-all] Error 2 > make: *** > [/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Master/serial-subdirectories.make:53: > internal-all] Error 2 > Failed > > c:\Users\bplym\Desktop\tools-windows-msvc>
My future GNUstep contribution
Dear GNUsteppers, as some of you may have noticed I was on a break from the project for some time. This hiatus was caused by the way Greg reacted on the mail from Johannes on RMS. Just to state the obvious, I think that Johannes was wrong here, still he deserved a friendlier reply. I was not surprised that Johannes choose to quit the project. The tone on the GNUstep mailing lists, and sadly on many free software projects, is often very unfriendly. After this I needed some time to think about what my role in such a project should be. Why would I subject myself to treatments in my spare time that I would not accept in a payed position? The result of all this thinking is that I still want to contribute to this project, for which I have worked more than twenty years. But I will scale down my involvement. I would like to give up on chores that I never enjoyed and work on fun stuff like problem analysis and bug fixing. There are three main jobs that I would like to pass on: - Maintainership of GNUstep gui and back. Here it would be great if somebody could at least take over the review of Greg's pull requests. Somehow we are not able to sort out our communication and this results in a rather frustrating experience for me. - Package building on OSB (https://build.opensuse.org/project/show/X11:GNUstep). Here an update to the latest GNUstep release would be needed and there is a lot room for further improvements. - Coverity Scan for GNUstep base (https://scan.coverity.com/projects/gnustep-base?tab=overview). I use a docker image to create these metrics and at the beginning of the year I wanted to improve on that script and even extend it to cover gui as well. Now I would rather pass this on to somebody else. If you are interested to take over one of these jobs, please contact me directly. I will stay out of further mailing list discussion but will still be around to help developers and users with their issues. Cheers, Fred
Re: wm compatibility
Yes, GNUstep has a known issue with tiling window managers. At the moment I cannot remember the exact cause. It must be something about window sizing and placing. GNUstep expects to have full control of these and this is not the case for for tiling window managers. As tiling window managers haven’t been that popular the demand to look into this and finding a workaround hasn’t been huge. If you really need this feature I could explain to you how to get more debug information about what is going on and maybe you could suggest a solution or workaround based on that. Hope this helps, Fred > Am 11.07.2021 um 23:11 schrieb Alan Third : > > Hi, > > Does GNUstep have compatibility issues with tiling window managers > like i3? I'm seeing some odd behaviour and I'm trying to trace it's > origin without much success. > > I'm trying to tidy up some Emacs code and I'm seeing very odd > behaviour that I can't begin to explain. When I resize a window using > the mouse it's frame struct doesn't seem to have the correct size. The > window (usually) displays fine, it just causes problems when I later > try to get the height of the window and use it. > > Directly setting the frame fails too, usually complaining that a size > of ~400x400 pixels has a negative width... > -- > Alan Third >
Re: Swizzling Alloc
Hi Gustavo,
if what you want to achieve is finding leaked objects then there is abetter way
to do so. GNUstep already has a build in leak detection: GSDebugAllocationAdd.
This registers all allocated objects per class in a table and with the function
GSDebugAllocationListAll you get an NSString ready to print out, showing the
current state of this table. Doing so multiple times in you application should
show you which classes are leaking objects.
And if you actually have a gui application, things are even more simple. Just
one the about dialog, clock on the displayed icon and you will get a window
displaying the content of that table. Keep on refreshing and you will see which
classes move up to the top.
Hope this helps,
Fred
> Am 30.05.2021 um 18:59 schrieb Gustavo Tavares :
>
> Hi All,
>
> So—I am trying to use swizzling for my first ever and my goal is to swizzle
> `alloc`. Why? I want to run a unqiued counter of where my objects are
> allocated by analyzing the call stack symbols. Sort of like Valgrind so that
> I can see where my program is leaking data—but I figured since I don't know
> how to parse Valgrind Objective-C might be an easier way to get something
> very similar.
>
> Unfortunately when I follow this guide to swizzle the methods—I am getting a
> segmentation fault.
> https://newrelic.com/blog/best-practices/right-way-to-swizzle
>
> He basically tell me to do:
>>
>> id gtkDebugAlloc(id self, SEL cmd) { }
>>
>> {
>> Method nsObjectAllocMethod = class_getClassMethod([NSObject
>> class], @selector(alloc));
>> IMP orginalAlloc =
>> method_setImplementation(nsObjectAllocMethod,(IMP)gtkDebugAlloc);
>> }
>
> Instead of:
>
>> @interface GTKDebugObject
>> @end
>> @implementation GTKDebugObject
>> +(id)alloc { id toReturn = [self
>> allocWithZone:NSDefaultMallocZone()]; if (toReturn { ... } return toReturn;
>> }
>> @end
>>
>> {
>>
>> Method nsObjectAllocMethod = class_getClassMethod([NSObject
>> class], @selector(alloc));
>> Method gtkObjectAllocMethod =
>> class_getClassMethod([GTKDebugObject class], @selector(alloc));
>> method_exchangeImplementations(nsObjectAllocMethod,
>> gtkObjectAllocMethod);
>>
>> }
>
>
> Both methods immediatley give me a segmentation fault when I run this.
>
> Not really sure where to begin debugging this given it's my first time ever
> swizzling something.
>
> Another approaoch would be to have my own build of `Foundation`. I am
> probably going to do that next—but this would be a much handier tool if I
> didn't have to rebuild my system everytime I wanted to debug my mistakes. So
> far, I don't really know how to tell GNUmake to use another version of
> Foundation.
>
> It seems like I can change my Foundation library for cross-compiling but not
> the location of Foundation lookup.
>
> . /usr/GNUstep/System/Library/Makefiles/GNUstep-reset.sh
> export LIBRARY_COMBO=ng-gnu-gnu
> . /usr/GNUstep/System/Library/Makefiles/GNUstep.sh
>
> Ref: http://manpages.ubuntu.com/manpages/impish/man7/library-combo.7.html
>
> Seeing also: http://www.gnustep.org/resources/documentation/make_1.html#SEC33
>
> Would appreciate the help as I go off and bang my head on this. Might have a
> very easy solution.
>
> Thank for any help in advance,
>
> G
Re: Call to stop contributing
According to Godwni's law (https://en.wikipedia.org/wiki/Godwin%27s_law) you have won. Could we stop this flamewar now? And just to make this also public: I did reply in private to you on the original subject (GCC support for OBJC) long before any of the discussion started. I was stating the actual problems and even my original offer to help here. But I never did get any reply on that mail. You do not seem to be interested in supporting GNUstep or helping with our GCC issues. My impression here is that you just mailed on the GNUstep mailing list to start such a flamewar. Now that you won it, could you please just vanish again? Fred > Am 27.03.2021 um 19:35 schrieb Richard Stallman : > > [[[ To any NSA and FBI agents reading my email: please consider]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > Most of the accusations in that letter are false. > A few are true, but they are not very important. > > Meanwhile, that message demonstrates the true nature > of the cancellationist movement: an attempt to bully people > into obeying its party line. > > In a world in which Nazis, violent nationalists and violent > bigots grow in power, it is bizarre that people focus on crushing > someone like me. > > In fact, I do not support abuse of women or children, but that issue > has nothing to do with the FSF, GNU or GNUstep. > > The FSF does, however, support basic human rights including freedom of > thought and speech. We who hold views on political issues should not > try to censor views that we disagree with. > > -- > Dr Richard Stallman > Chief GNUisance of the GNU Project (https://gnu.org) > Founder, Free Software Foundation (https://fsf.org) > Internet Hall-of-Famer (https://internethalloffame.org)
Re: Problem with the GNUStep packages in FreebSD?
Hi Edwin, > Am 20.03.2021 um 10:01 schrieb Edwin Ancaer : > > Sorry to keep bothering you for what is probably a mistake I made during the > upgrade of FreeBSD. But I upgraded every installed port on the system, > causing endless hours and hours of recompilations and installations. and > reduced the linker errors in GNUMail and ProjectCenter (maybe other gnustep > ports are involved, but I did not try them allyet) to 1. > > Can you give any indication where to look for a solution? > Linking ProjectCenter gives: > > cc -L/usr/local/lib -fstack-protector-strong -rdynamic -rdynamic -rdynamic > -rdynamic -fuse-ld= -pthread -fexceptions -fobjc-runtime=gnustep-2.0 > -fblocks -o ProjectCenter.app/./ProjectCenter \ > ./obj/ProjectCenter.obj/PCAppController.m.o > ./obj/ProjectCenter.obj/PCInfoController.m.o > ./obj/ProjectCenter.obj/PCMenuController.m.o > ./obj/ProjectCenter.obj/PCPrefController.m.o > ./obj/ProjectCenter.obj/ProjectCenter_main.m.o > -L./Framework/ProjectCenter.framework/. > -L./Framework/ProjectCenter.framework/. > -L./Framework/ProjectCenter.framework/. > -L./Framework/ProjectCenter.framework/. > -L/usr/ports/devel/projectcenter/work/GNUstep/Library/Libraries > -L/usr/local/GNUstep/Local/Library/Libraries > -L/usr/local/GNUstep/System/Library/Libraries -L/usr/local/lib > -lProjectCenter -lgnustep-gui-lgnustep-base -pthread -lobjc -lm > ld: error: ./Framework/ProjectCenter.framework/./libProjectCenter.so: > undefined reference to __objc_ivar_offset_NSView._tracking_rects. > cc: error: linker command failed with exit code 1 (use -v to see invocation) > > libProjectCenter.so seems to depend on the latest gnustep libraries: > l > $ ldd > /usr/ports/devel/projectcenter/work/ProjectCenter-0.6.2/Framework/ProjectCenter.framework/libProjectCenter.so > /usr/ports/devel/projectcenter/work/ProjectCenter-0.6.2/Framework/ProjectCenter.framework/libProjectCenter.so: > /usr/ports/devel/projectcenter/work/ProjectCenter-0.6.2/Framework/ProjectCenter.framework/libProjectCenter.so: > libobjc.so.4.6 => /usr/local/lib/libobjc.so.4.6 (0x8006f) > libgnustep-base.so.1.27 => > /usr/local/GNUstep/System/Library/Libraries/libgnustep-base.so.1.27 > (0x800e0) > libgnustep-gui.so.0.28 => > /usr/local/GNUstep/System/Library/Libraries/libgnustep-gui.so.0.28 > (0x80140) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800725000) > > The strange thing is, that symbol seems to be in the libgnustep-gui library: > > $ nm /usr/local/GNUstep/System/Library/Libraries/libgnustep-gui.so.0.28 | > grep __objc_ivar_offset_NSView._tracking_rects > 0049f61c d __objc_ivar_offset_NSView._tracking_rects.Wolfgang Lux > > $ for clang _tracking_rect is package private, so it should not be visible in ProjectCenter. This shouldn’t be an issue as the code using it was removed from ProjectCenter two years ago. But somehow the package you are using still seems to include that old code. Looks like we need a new release of ProjectCenter. Until that happens you are best off by using the code from git. Hope this helps, Fred
Re: Problem with icns file
> Am 27.02.2021 um 00:04 schrieb Bertrand Dekoninck > : > Le 26/02/2021 à 23:18, Fred Kiefer a écrit : >> Just to understand the issue a bit better. Are you using libicns to read the >> icns file or is the fallback to the GNUstep implementation used? The later >> implementation is rather limited and won’t be able to handle your added >> formats. >> >> And why didn’t you add a 48x48 version? > > To be clearer : I add for each app a resource folder in > Sombre.theme/Resources. Here, I add Sombre.theme/Resources/org.gap.InnerSpace. > > And I place the custom icon inside. It must be named as is named the appicon > in InnerSpace plist file : InnerSpace_Icon.icns. > > I tried to replace it with a 48x48 InnerSpace_Icon.tiff but it didn't work. > Should it work ? If so, I must have missed something and should retry. I > remember to have replaced tiff files with png files in rik.theme long ago. Using a different type should be possible but only one file (with the same base name) at the time would be allowed. But I was asking why you didn’t use 48x48 inside of the icns file. > So to answer your question, I don't think I use libicns, unless GWorkspace > uses it to read icns files. But I don't see this library in its dependancies. The libicns would be used directly by GWorkspace. It gets used by GNUstep gun, if present and if not we fall back to the local implementation in GNUstep gui. In the meantime I checked the libicns source code and they do support more formats than our code, but not the @2 and also not the PNG subtype you are using. > I would like to be able to reproduce the same sizes as Greg in my icns file, > but I don't know how. If I don't generate the missing @2x files with my > conversion script, iconutil complains about them and fail on osX ElCapitan. I > tried my conversion script on osX Leopard, but it misses the iconutil tool. Having more formats in the file won’t do any harm. All the supported formats will get ignored.
Re: Problem with icns file
Just to understand the issue a bit better. Are you using libicns to read the icns file or is the fallback to the GNUstep implementation used? The later implementation is rather limited and won’t be able to handle your added formats. And why didn’t you add a 48x48 version? Cheers, Fred > Am 26.02.2021 um 20:21 schrieb Bertrand Dekoninck : > > Hi everyone ! > > I'm working on theming icons again and ma facing a problem with InnerSpace > icns icon. This is the first icns ifle I've encountered in gnustep > applications resources folder. > > I've created a custom SVG icon for it, which I've converted to 1024x1024 png. > > I don't now how Gregory did generate its original InnerSpace_Icon.icns file. > > I didn't find any linux tool to convert it to icns file and only found a > little script on the web using apple's sips and iconutil tools. > > The problem is that the resulting icon doesn't display properly at 48x48 size > in GWorkspace. At this size, the icon displayed is in fact the 32x32 one and > is smaller than all the others. I think GNUstep and/or GWorkspace don't > display correctly high res icns file at this size. > > I can see on Macos Preview differences between my icns and Greg's one : > > Greg's contains 16x16, 32x32, 128x128, 256x256, 512x512 at 72 ppm sizes, plus > a 512x512@2x (1024x1024 at 144 bpm). > > Mine contains the same plus 16x16@2x, 32x32@2x, 128x128@2x, 256x256@2x. > > I attach the script used to generate the icon and the icon itself to this > mail. > > Can someone help me figure out how to override this problem ? > > > Last question : Gworkspace seems to display icons better at 64x64 if it's an > icns file than a 48x48 tiff file. Should I increase the size of my icons ? > Would it be possible to implement bigger sizes in GWorkspace (128 ? 256 ?) > using bigger tiff files or this format containing multiple files? GWorkspace > is a little poor looking compared to other filemanagers and desktop in this > area. > > Cheers, > > Bertrand > > >
Re: Dr. Brad Cox, co-creator of Objective-C
Thank you Josh for sharing this. I remember fondly reading Brad Cox's book while i was still at University. The concept of Soft-ICs, reusable software components, won me over for Objective-C. So even a long time before starting to contributing to GNUstep I learned and liked the language. Thank you Brad for giving it to us! Fred > Am 23.01.2021 um 21:38 schrieb Josh Freeman : > > Dr. Brad Cox, who co-created the Objective-C language with business partner > Tom Love, has passed: > https://www.legacy.com/us/obituaries/scnow/name/brad-cox-obituary?pid=197454225 > > If you'd like to read about Objective-C's early history, Dr. Cox co-wrote > an article last year, titled, "The origins of Objective-C at PPI/Stepstone > and its evolution at NeXT": > https://dl.acm.org/doi/10.1145/3386332 (Free online eReader, PDF download) > >
Re: GNUstep.app, was: Debian Package Repository...
Great website! There is one typo on the IDE page ("Different approaches für
building cross platform GUI“) :-)
And you should add PikoPixel to your list of apps.
Cheers,
Fred
> Am 18.01.2021 um 16:56 schrieb Johannes Brakensiek :
>
> Hello everyone,
>
> On 15 Dec 2020, at 21:28, Johannes Brakensiek wrote:
>
>> In the meantime I installed Arch/Manjaro on my development laptop as you are
>> provided with much more recent packages when using a rolling release. And
>> the Arch PKGBUILD system is quite easy to set up, so I've created some Arch
>> packages using clang and libobjc2. These are compiled from git sources and
>> thus provide some sort of continous delivery for development purposes:
>>
>> https://build.opensuse.org/project/show/home:letterus:gnustep-ngr
>>
>> That said I'd happily provide information on how to retrigger builds for the
>> app/project you maintain to deliver a fresh build if you wish.
>>
>> One would have to add, that openSUSE's Open Build Service currently only
>> provides x86_64 packages for Arch PKGBUILD files.
>>
>> This is not the case for Debian and RPM spec files. So I would of course add
>> packaging instructions for additional distributions and architectures in
>> case anybody would like to provide these.
>
>> P.S.: For Manjaro users (I really like it); Add a panel to the top of the
>> screen, add a global menu there and set GNUstep to use the Sombre.theme from
>> Bertrand Dekoninck. From a optical point of view it integrates nicely, I
>> think.
>
> just to let you know. I used the time after Christmas to prepare a little
> showcase on how to develop GNUstep apps when coming from macOS/Cocoa (these
> apps using AppKit) and how to integrate these into a popular desktop
> environment (because I think that’s what new devs would be interested in):
>
> https://gnustep.app/
>
> It was a nice experience to put together some bits and pieces I learned and
> explored the last year.
>
> Hope you enjoy as well
> Johannes
>
Re: Bug in [NSScanner scanDouble:]
Looks like the code of GSScanDouble and [NSScanner scanDouble:] differ a lot. Both are in the file NSScanner.m and it looks like the function has been corrected over the years to handle different cases a lot better. The NSScanner code is just a straight forward number scanning as you would expect. The easiest solution would be to reuse GSScanDouble by scanning in a buffer all the characters for the double value and calling the function on that value (handling _decimal by replacing it with a dot). But somehow this feels like the wrong way around. The code in NSScanner should have the correct implementation and GSScanDouble should just call that. This solution would require to allocate and free an NSScanner object, and I am pretty sure that Richard wouldn’t like the extra time spend on that. I rather leave it to him to decide which way to go. Fred > Am 28.12.2020 um 23:27 schrieb Douglas Simons > : > > Hi, sorry for posting a bug report here, but I seem to have lost my > credentials for accessing the bug tracker. > > The scanDouble: method of NSScanner is adding a tiny fraction to the value > scanned (at least on Windows). > > NSScanner *scanner = [NSScanner scannerWithString:@“197319600.00”]; > double val = 0.0; > [scanner scanDouble:]; > NSLog(@"scanDouble got: %.9f", val); > // results in val having the value 197319600.0012 > > Note that NSString’s doubleValue method doesn’t have this problem, so I’m > using that to work around this problem for now. > > Thanks! > > Doug
Re: What function sets up the GNUstep environment?
Not sure, whether we are all looking for the same thing here. The question is which of the gui functionality would your server application use? Greg is asking for Postscript output. We already have a very primitive way for that in the gsc classes so something would be there already. But for a better quality and for example PDF output we should rather use cairo. So if there is the need for real functionality from the backend we could use cairo just with the image surface drawing, that is without any X11 references. But for that you would have to build your own version of that library. Similar things for fonts, if you want to use fonts in a meaningful way you will have to rely on a library. The no-op backed that I was talking about would be simple to implement, but also quite useless. The more functionality you expect here, the more complex it will get. Fred > Am 03.11.2020 um 21:52 schrieb Gustavo Tavares : > > > This is exactly what I need and was looking at doing just that. I did some > no-op classes but I have very little experience with there system to do so > immediately. > > It doesn’t look like a lot of files but I might be wrong. There are a lot of > subtle interactions that I have already bumped into. > > For example, right now, I’m still working through the call to +[NSProcessInfo > initalizeWithArguments:count:environment:] (I think I have the name right but > I didn’t look it up on my phone. > > Calling this didn’t solve my problem immediately. > > As for testing it’s pretty wonderful. I already have some tests running by > enclosing them in a framework (Marcel WeiHer does this in MPWTest) > > The use case as a server backend is compelling too because you can save and > interact with User preferences for Font, Color, Theme, etc on the backend > just as you would on a frontend. > > > On Tue, Nov 3, 2020, at 4:19 PM, Gregory Casamento wrote: >> This is a really interesting notion. Would the no-op backend (I think we >> need a better name) be able to print, or output postscript? Would it be >> possible to use it for testing GUI in some way? >> >> GC >> >> >> On Tue, Nov 3, 2020 at 12:06 PM Fred Kiefer wrote: >> Your problem got me thinking. Would it help you if we offered a „no-op“ >> backend for GNUstep? That is a backend where both the window and the drawing >> system would be implemented as no-operations. >> >> We could try to get this done as a special GNUstep back configuration. Most >> likely we could cheat here by reusing the gsc classes as a real drawing >> backend, which of course would not draw but raise subclassResponsibility:. >> That means we only need code for the window/event part and a lot of >> configuration to switch all the extra libraries off. >> >> Cheers, >> Fred >>
Re: What function sets up the GNUstep environment?
Your problem got me thinking. Would it help you if we offered a „no-op“ backend
for GNUstep? That is a backend where both the window and the drawing system
would be implemented as no-operations.
We could try to get this done as a special GNUstep back configuration. Most
likely we could cheat here by reusing the gsc classes as a real drawing
backend, which of course would not draw but raise subclassResponsibility:. That
means we only need code for the window/event part and a lot of configuration to
switch all the extra libraries off.
Cheers,
Fred
> Am 03.11.2020 um 16:02 schrieb Gustavo Tavares :
>
> Thank you! This is great.
>
> I think I'm going to make some sort of subclass—NSCommandLineApplication.
>
> I did implement some of the backend classes in a -doNothingMethod { ; }
> style: GSFontInfo / GSFontEnumerator.
>
> Previously I just tried running X11 and calling it a day—but that didn't
> work. So goes the rabbit hole...
>
> Looks like it will be fun though. Just gotta love Objective-C :)
>
> Gustabo
>
>
> On Mon, Nov 2, 2020, at 11:20 PM, Ivan Vučica wrote:
>> Based on
>> https://github.com/gnustep/libs-base/blob/3752016/Source/NSProcessInfo.m#L140-L154,
>> this comes from
>> https://github.com/gnustep/libs-base/blob/3752016/Source/NSProcessInfo.m#L919
>> or
>> https://github.com/gnustep/libs-base/blob/3752016/Source/NSProcessInfo.m#L1021.
>>
>> If these were GUI apps, I’d recommend calling NSApplicationMain which takes
>> argc and argv and sorts this out for you – in fact, that’s ideally exactly
>> what you should do if you’re using any GUI methods. You’re saying you’re
>> using certain GUI classes on the server; if you believe they will actually
>> behave correctly in a server environment without gnustep-back (not a given;
>> hypothetically, NSColor could heavily depend on Opal’s CGColorRef), you may
>> be able to call NSProcessInfo +initializeWithArguments:..., too.
>>
>> Otherwise study
>> https://github.com/gnustep/libs-gui/blob/0ccdb278d4cc8ad60f033892a5105e0532261838/Source/Functions.m#L63
>> carefully, but don’t be surprised if lack of x11 breaks GUI classes. You
>> break it (into pieces), you get to pick up those pieces and glue them
>> together :)
>>
>> (Yes, I noticed you said you went ahead and removed some backend-dependent
>> code. This sounds like it’ll be a lot of fun…)
>>
>> Ivan Vučica
>>
>> From: Gustavo Tavares
>> Sent: Tuesday 3 November 2020 02:13
>> To: GNUstep Discuss
>> Subject: What function sets up the GNUstep environment?
>>
>>
>> Hi!
>>
>> Was wondering what function sets up a GNUstep environemtnt?
>>
>> Getting this error:
>>
>> GNUSTEP Internal Error:
>> The private GNUstep function to establish the argv and environment
>> variables was not called.
>>
>> Mismatched library versions between GNUstep Foundation (base) and AppKit
>> (gui) is most often the cause of this message. Please be sure you
>> are using known compatible versions and not a mismatched set. Generally,
>> we recommend you use versions of base and gui which were released together.
>>
>> For more detailed assistance, please report the error to bug-gnus...@gnu.org.
>>
>> ---
>>
>> For context—I built a seperate framework that extracts some "GUI" classes
>> with the intention to use them semantically on a server. (Such as NSImage,
>> NSColor, NSFont...)
>> I already went through the business of overriding / deleting some of the
>> backend functions so that the classes would be "initalized" and wouldn't
>> need to be rendered to screen.
>>
>> Stuck here.
>>
>> Where should I look?
>>
>>
>> Thank you,
>> G
Re: NSMenuItem setAttributedTitle
Am 19.10.20 um 20:21 schrieb Aaron Carr:
> Hi
>
> Ive been trying to change the font of an NSMenuItem, looking at the source,
> setAttributedTitle is:
>
> -(void) setAttributedTitle: (NSAttributedString *)title
> {
> // FIXME
> [self setTitle: [title string]];
> }
>
> Am i reading this right, is it essentially bypassed ? if so, what is the best
> way to say bold/italic/underline an NSMenuItem ?
Currently there is no proper way of doing so. You would need to grap
hold of the corresponding NSMenuItemCell and set the font there
directly. But you really shouldn't go down that way. Instead it would
not be to hard to implement attributed string support in NSMenuItem and
NSMenuItemCell, at least for the standard theme. Ivan already explained
the limits of doing this for other setups.
The main obstacle here is that the current code here needs a cleanup, or
rather a proper rewrite. There are many duplications and
inconsistencies. For example the alternate text of the menu item cell
would never be displayed.
Patches are highly welcome,
Fred
Re: NSTableView bug fix
Hi Andreas,
thank you for this patch. I already committed it, this was well spotted.
There is another issue though. As I already wrote you, I never get the mails
that you send to this mailing list. And this was also the case for these two
mails, without Gregory replying, the whole issue would have passed unnoticed by
me. I checked all the spam folders that I am aware of and none contained your
mails. I really don’t have an idea where they get filtered. Please add me
directly as recipient to your mails to the mailing list when you think that a
mail should be addressed by me.
Cheers,
Fred
> Am 17.10.2020 um 13:18 schrieb Gregory Casamento :
>
>
> Andreas,
>
> For future reference, it is usually best to clone the repository and create a
> branch, then create a PR for consideration by the maintainer of that repo, in
> this case, Fred Kiefer. This is not a hard and fast rule, but it allows us
> to keep all contributions tracked in one place.
>
> Your change looks okay to me, but Fred has primary responsibility for
> libs-gui, so I defer to his judgment.
>
> Yours, GC
>
> On Sat, Oct 17, 2020 at 5:22 AM Andreas Höschler via Discussion list for the
> GNUstep programming environment wrote:
> Hi all,
>
> I sent the below fix to the group a while ago. Has this already been
> integrated into the repository (by someone with write privileges)? I haven't
> seen any feedback on this and just want to make sure it does not get lost.
>
> Thanks,
>
> Andreas
>
> ***
>
>
> > On 11 Oct 2020, at 19:54, Andreas Höschler via Discussion list for the
> > GNUstep programming environment wrote:
> >
> > Hi Fred,
> >
> > I just hunted down a bug in NSTableView. A test app would be an application
> > with a tableview with a couple of columns with formatters. Entering data
> > stops working once a cell with a formatter was hit. This is due to
> >
> > NSTableView.m - (void) validateEditing
> >
> > existing without setting _isValidating back to NO.
> >
> > The following fix (see the line marked with // <---) does the trick.
> > Could anyone please integrate this fix into the repository? :-)
> >
> > Thanks a lot,
> >
> > Andreas
> >
> > ***
> >
> > - (void) validateEditing
> > {
> > if (_textObject && (_isValidating == NO))
> > {
> > NSFormatter *formatter;
> > NSString *string;
> > id newObjectValue = nil;
> > BOOL validatedOK = YES;
> >
> > // Avoid potential recursive sequences...
> > _isValidating = YES;
> >
> > formatter = [_editedCell formatter];
> > string = AUTORELEASE([[_textObject text] copy]);
> >
> > if (formatter != nil)
> >{
> > NSString *error;
> >
> > if ([formatter getObjectValue: forString: string
> > errorDescription: ] == YES)
> > {
> >[_editedCell setObjectValue: newObjectValue];
> >
> >if (_dataSource_editable)
> > {
> > NSTableColumn *tb;
> >
> > tb = [_tableColumns objectAtIndex: _editedColumn];
> >
> > [self _setObjectValue: newObjectValue
> > forTableColumn: tb
> > row: _editedRow];
> > }
> >_isValidating = NO; return; // <---
> > }
> > else
> > {
> >SEL sel =
> > @selector(control:didFailToFormatString:errorDescription:);
> >
> >if ([_delegate respondsToSelector: sel])
> > {
> > validatedOK = [_delegate control: self
> > didFailToFormatString: string
> > errorDescription: error];
> > }
> >// Allow an empty string to fall through
> >else if (![string isEqualToString: @""])
> > {
> > validatedOK = NO;
> > }
> > }
> >}
> >
> > if (validatedOK)
> >{
> > [_editedCell setStringValue: string];
> >
> > if (_dataSource_editable)
> > {
> >NSTableColumn *tb;
> >
> >tb = [_tableColumns objectAtIndex: _editedColumn];
> >
> >[self _setObjectValue: string forTableColumn: tb row:
> > _editedRow];
> > }
> >}
> >
> > // Avoid potential recursive sequences...
> > _isValidating = NO;
> > }
> > }
> >
> >
>
>
>
>
>
> --
> Gregory Casamento
> GNUstep Lead Developer / OLC, Principal Consultant
> http://www.gnustep.org - http://heronsperch.blogspot.com
> https://www.patreon.com/bePatron?u=352392 - Become a Patron
> https://gf.me/u/x8m3sx - My GNUstep GoFundMe
> https://teespring.com/stores/gnustep - Store
>
Re: A window manager written in objective-c: uroswm and gnustep support problems
HI Alex,
even after reading your Github column, I still don’t quite understand the issue.
It might help you to know that all other window managers I am aware of don’t
support the EWMH feature _NET_REQUEST_FRAME_EXTENTS, or at least none did when
we implemented this feature. So this code path is lesser used in GNustep and
there might be undetected issues with it. Maybe it would be best wo disable
this feature in your window manager for now and to try to get the rest working
first?
As for the configure event you should run the GNUstep application with the
option „—GNU-Debug=NSEvent“ to see more information about event handling.
And did you see this comment in the GNUstep code:
/*
According to the ICCCM, coordinates in synthetic events
(ie. non-zero send_event) are in root space, while coordinates
in real events are in the parent window's space. The parent
window might be some window manager window, so we can't
directly use those coordinates.
Thus, if the event is real, we use XTranslateCoordinates to
get the root space coordinates.
*/
This might be the reason why your events get handled incorrectly by the GNUstep
code? But this is only guessing and won’t help. Without more data I won’t be
able to help you.
Cheers,
Fred
> Am 14.09.2020 um 19:37 schrieb Alessandro Sangiuliano :
>
> Hello guys, I'm still here with this problem. It is going to be tricky.
>
> This time I have more informations;
>
> I started to use the github projects and columns feature so I can clean ideas
> in my mind and put all toghether.
>
> At this column called GNUstep support
>
> https://github.com/AlessandroSangiuliano/XcbKit/projects/2#column-10827552
>
> i wrote in a better way the problem, but with some additional informations
> about is going to happen after a debbugging session.
>
> I noticed that the map just works, the client window of a GNUStep is mapped
> where I want to be apped inside the frame window at coordinates (0, 21).
>
> The problem happens after the map request event, in the configure window
> request event. In the coulmn is well described.
>
> Do you think that resetting the W;_NORMAL_HINTS of the client window will fix
> the problem?
>
> I don't see how to fix the offset calculation that GNUStep does.
>
> I tried to run GNUStep Apps with window managers that are going to be really
> poor in ICCCM and EWMH support; I tried with twm and echinus ( a dwm fork);
> With these GNUstep Apps are positioned inside the frame in the correct way
> (echinus is a reparenting wm).
>
> The source code of echinus is really few lines of code, I give it a flash
> lookm it doesn't seem that play so much with offset or whethever. I'm just
> failing something.
>
> GNUStep Apps are working quite well also with awesome wm, I wm that i studied
> to get some knowledge about xcb. The have totally no support for
> _NET_REQUEST_FRAME_EXTENTS, while they update the _NET_FRAME_EXTENTS to the
> window.
>
> I do that too, putting the array as {3,3,21,3}. These values actually are my
> borders + the title bar window (21 in height).
>
> I also tried to use xprop on SystemPreferences running on my desktopn
> environment, XFCE on Manjaro, the _NET_FRAME_EXTENTS are set to {2,2,28,2}.
> 28 is the height of the title bar window, indeed is slighty heghter than mine.
>
> Thank you.
>
>
> Cheers,
> Alex.
Re: A window manager written in objective-c: uroswm and gnustep support problems
Hi Alessandor, from looking at your image I would expect that the GNUstep application, in this case System preferences, is expecting the wrong offset from the window manager. Here it would help to see which values get displayed when the first GNUstep application for your window manager starts up. At that time we try to determine how big the window borders are going to be and these values will be used later on to compute the internal offset for all GNUstep windows. Hope this helps, Fred > Am 18.08.2020 um 18:21 schrieb Alessandro Sangiuliano : > > Hello everyone, is a lot I'm not writing here due of the work i was doing I > had no time to code with gnustep, however now I'm back and some months ago I > took again my project, the window manager. > > To be honest, I'm writing a kit to code window managers, XCBKit and as the > name says it is on top of xcb. I was insipred by the étolié XCBKit for some > things, but it works in a different way. However my XCBKit will have some > usefull code from the étoilé one escpecially the composite support, but is > actually really soon talking about compositing. > > Actually the status of the kit + the window manager uroswm, is good but a lot > of work is needed. Indeed the version is 0.0.10. > > Fred helped me privately when something was not clear, the code was too young > and really bad to start to talk here. Actually is a bit better but still bad > (well not really bad, is a progress!). > > The wm is able to handle gtk application in a good way, I can frame them > iconify them, moving resizing, closing via WM_DELETE_WINDOW etc etc. > > The wm is going to be, slowly, EWMH compliant and ICCCM too where needed. > > I started to write it on my old mac laptop with 10.9.5 and XCode 5, as Fred > saw time ago in a video I shared with him. When I reached some goals I had to > complete, I started the linux port on gnustep and this was really great > because I HAD TO CHANGE NO LINES OF CODE! > > I literally had just to write the GNUmakefile start the build and all was > built and working, in less than 1 hour I had the port complete, so > CONGRATULATIONS to all GNUstep developers and contribs. I remeber some year > ago when I started with GNUstep porting simple apps form OSX to GNUstep > needed some code changes and I was expecting te same for uroswm. > > So, it's time to talk about some problems I'm having to get a god support for > gnustep apps. > > Actually when I reparent a gnustep app in my frame the position is not what > I'm expecting, in the zip archive I attached you can see what I mean. > As you can see I have no problems with the calculator and google chrome, > while for SystemPreferences (and other gnustep apps) I ever get the app on > the shifted on the right or right-bottom. > > I'm pretty sure I'm not supporting some EWMH/ICCCM standard that gnustep is > using or asking to the window manager. For what I saw gnustep is strongly > supporting these stadards. > > Do you have some ideas about this? > > > > The branch you should look and where the developing is going is: > > https://github.com/AlessandroSangiuliano/XcbKit/tree/feature/gnustep_support > > Where map requests are handled: > > https://github.com/AlessandroSangiuliano/XcbKit/blob/feature/gnustep_support/XCBKit/XCBConnection.m#L444 > > > Where client messages are handled: > > https://github.com/AlessandroSangiuliano/XcbKit/blob/feature/gnustep_support/XCBKit/XCBConnection.m#L895 > > > Where the support for EWMH is going to be implemented: > > https://github.com/AlessandroSangiuliano/XcbKit/blob/master/XCBKit/services/EWMHService.m > > Same for ICCCM: > > https://github.com/AlessandroSangiuliano/XcbKit/blob/master/XCBKit/services/ICCCMService.m > > >
Re: Buildtool : other attempt to build a ported app : the Bean.app example
Hi Patrick, all the three test that fail for you seem to be internet related. Is it possible that form the machine where these tests are run no external network connection is possible? If this is that case please ignore the failing tests. Fred > Am 10.07.2020 um 16:31 schrieb Patrick Cardona : > On 2020-07-10 15:59:20 +0200 Fred Kiefer wrote: > >>> Am 10.07.2020 um 15:25 schrieb Patrick Cardona via Discussion list for the >>> GNUstep programming environment : >>> Just a thing I noted : if you run 'make test' with the new gnustep-base, >>> some tests are failing. It might be something RFM could look at too. >> Patrick, if you have failing tests for GNUstep base you should report these. >> Nobody else knows which tests are failing for you nor why this is the case. >> We are using Travis on GitHub and there all tests for base seem to pass. >> Please report back the failing test and be sure to include the test.log file >> with the details for these test. > > Here is a brief : > (...) > base/GSXML/basci.m:184 > > Failed test: basic.m:184 ... empty plist is not valid > 2020-07-10 10:54:58.406 basic[10942:10942] unable to find GNUstep DTD - > 'plist-$at line: 1 column: 95 ... failed to load HTTP resource > (...) > base/NSException/basic:404 > We expect a single FAIL without any explanation as > the test is terminated by an uncaught exception ... > /usr/GNUstep/System/Tools/gnustep-tests : ligne 404 : 18483 Abandon > $RUN_CMD > Completed file: basic.m > > I join the log and the sum files too.
Re: Buildtool : other attempt to build a ported app : the Bean.app example
> Am 10.07.2020 um 15:25 schrieb Patrick Cardona via Discussion list for the > GNUstep programming environment : > > Just a thing I noted : if you run 'make test' with the new gnustep-base, some > tests are failing. It might be something RFM could look at too. Patrick, if you have failing tests for GNUstep base you should report these. Nobody else knows which tests are failing for you nor why this is the case. We are using Travis on GitHub and there all tests for base seem to pass. Please report back the failing test and be sure to include the test.log file with the details for these test. Fred
Re: FYI: Advancements in the Objective-C runtime
Thank you Lars, that was a very interesting presentation. And Ben is a lot more pleasant than Chris was. > Am 28.06.2020 um 03:15 schrieb lars.sonchocky-helld...@hamburg.de: > > Some pretty neat things in here: > > https://developer.apple.com/videos/play/wwdc2020/10163/ > > this is the WWDC 2020 Talk "Advancements in the Objective-C runtime“, Ben > Cohen, who also works on the Swift Project, talks about some new things > inside the ObjC runtime of Apple. Some of those „tricks“ I consider pretty > nifty > > This might be especially interesting for David, as an inspiration for the > GNUstep ObjC runtime. > > > regards, > > Lars >
Re: HelpViewer 0.3 : error while linking
> Am 17.06.2020 um 19:36 schrieb Patrick Cardona via Discussion list for the > GNUstep programming environment : > > Hi All, > > I am trying to compile HelpViewer (version : 0.3). > > First, I had to change some header calls, because GSXML.h vas presumed to be > in 'Foundation' while it was in GNUstepBase. > I modified accordingly to the right path TextFormatterXLP.h, line 35 > and HandlerStructureXLP.h to set the correct path I guessed : > #include "GNUstepBase/GSXML.h" > > But finally, I got an error with the linker : > > Linking app HelpViewer ... > mainWindowController.m:0 : erreur : référence à « ASSIGN » non définie > mainWindowController.m:0 : erreur : référence à « RELEASE » non définie > mainWindowController.m:0 : erreur : référence à « RELEASE » non définie > mainWindowController.m:0 : erreur : référence à « RELEASE » non définie > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > make[3]: *** > [/usr/GNUstep/System/Library/Makefiles/Instance/application.make:133: > HelpViewer.app/./HelpViewer] Error 1 > make[2]: *** > [/usr/GNUstep/System/Library/Makefiles/Instance/application.make:147: > internal-app-run-compile-submake] Error 2 > make[1]: *** [/usr/GNUstep/System/Library/Makefiles/Master/rules.make:297: > HelpViewer.all.app.variables] Error 2 > make: *** [/usr/GNUstep/System/Library/Makefiles/Master/application.make:38: > internal-all] Error 2 This just means that the file is missing an import for GNUstep.h
Re: fallback fonts? remote display - xlib
> Am 16.06.2020 um 18:54 schrieb Riccardo Mottola : > > I launch an app on my Raspberry with xlib and remote display. > > 2020-06-16 10:40:33.831 ProjectCenter[29598:29598] No font cache available - > building new one - this may take several seconds (or minutes on a slow > machine with lots of fonts) > 2020-06-16 10:40:33.834 ProjectCenter[29598:29598] Running > /GNUstep/System/Tools/font_cacher > 2020-06-16 10:42:03.487 ProjectCenter[29598:29598] XGFont: selected font: > Helvetica at 12.00 ((null)) is not available. > 2020-06-16 10:42:03.488 ProjectCenter[29598:29598] The font specified for > NSFont, Helvetica, can't be found. > 2020-06-16 10:42:03.488 ProjectCenter[29598:29598] XGFont: selected font: > Helvetica at 12.00 ((null)) is not available. > 2020-06-16 10:42:03.489 ProjectCenter[29598:29598] XGFont: selected font: > Helvetica at 12.00 ((null)) is not available. > 2020-06-16 10:42:03.489 ProjectCenter[29598:29598] XGFont: selected font: > Helvetica at 12.00 ((null)) is not available. > 2020-06-16 10:42:03.490 ProjectCenter[29598:29598] XGFont: selected font: > Courier at 12.00 ((null)) is not available. > 2020-06-16 10:42:03.491 ProjectCenter[29598:29598] XGFont: selected font: > Fixed at 12.00 ((null)) is not available. > > <<...>> > > 2020-06-16 10:42:04.267 ProjectCenter[29598:29598] NSFont.m:1513 Assertion > failed in GSCInlineString(instance), method initWithCoder:. Couldn't find a > valid font when decoding. > 2020-06-16 10:42:04.270 ProjectCenter[29598:29598] Exception occurred while > loading model: NSFont.m:1513 Assertion failed in GSCInlineString(instance), > method initWithCoder:. Couldn't find a valid font when decoding. > 2020-06-16 10:42:04.272 ProjectCenter[29598:29598] Failed to load Gorm > > <<...>> > > 2020-06-16 10:42:04.342 ProjectCenter[29598:29598] XGFont: selected font: > Fixed at 12.00 ((null)) is not available. > Segmentation fault > > now.. I wonder why? I launched "xfontsel" on the raspberry. > Am I right to assume that the fonts seen there are the one availbale to the > backend too? > > I see Helvetica, e.g.: > > -*-helvetica-*-r-*-*-12-*-*-*-*-*-*-* > > -*-courier-*-r-*-*-12-*-*-*-*-*-*-* > > what am I missing? Have a look into the font cache file to see which fonts are detected. maybe you should delete that file and have it recreated. As you know the xlib backend is no longer supported especially not the XGFont class. You should check, why no better font support is found.
Re: Fresh install - issues with missing GNUstep/Library
> Am 16.06.2020 um 12:44 schrieb Riccardo Mottola :
>
> Hi,
>
> I did a total fresh install of GNUstep (had to reinstall everything on my
> Raspberry).
> For simplicity I used xlib, I only need a minimal GUI.
>
> I get this trace when starting ProjectCenter:
>
> pi@RaspberryPI1 ~/code/apps-projectcenter $ ProjectCenter
> 2020-06-16 09:00:46.810 ProjectCenter[28356:28356] styleoffsets ... guessing
> offsets
> 2020-06-16 09:00:46.829 ProjectCenter[28356:28356] styleoffsets ... guessing
> offsets
> 2020-06-16 09:00:46.974 ProjectCenter[28356:28356] Unsupported context depth
> 24
> 2020-06-16 09:00:47.413 ProjectCenter[28356:28356] Library directory
> '/home/pi/GNUstep/Library' not available!
> 2020-06-16 09:00:47.416 ProjectCenter[28356:28356] File NSData.m: 287. In
> readContentsOfFile Open ((null)) attempt failed - bad path
> 2020-06-16 09:00:47.418 ProjectCenter[28356:28356] No font cache available -
> building new one - this may take several seconds (or minutes on a slow
> machine with lots of fonts)
> 2020-06-16 09:00:47.422 ProjectCenter[28356:28356] Running
> /GNUstep/System/Tools/font_cacher
> ProjectCenter: Uncaught exception NSInvalidArgumentException, reason: Tried
> to init array with nil object
>
>
> I think the depth24 context is not relevant (although, Fred... nothing
> strange in this setup, the display is exported)
>
> I think the whole failure is that the user has no gnustep preference
> directory.
> usually no font_cacher is run either, xlib only and perhaps only on remote
> display?
>
> Maybe it fails because *both* GNUstep and GNUstep/Library have to be created
> (whole path).
>
> I suppose it should be created automatically?
> I created manually GNUstep/Library and font cacher started withoutissuesl.
>
> Riccardo
>
In font_cache we have this code:
paths = NSSearchPathForDirectoriesInDomains(NSLibraryDirectory,
NSUserDomainMask, YES);
if ((paths != nil) && ([paths count] > 0))
{
path = [paths objectAtIndex: 0];
}
else
{
NSLog(@" No valid path for cached information exists. You ");
NSLog(@" should create ~/GNUstep/Library by hand");
return nil;
}
This makes it unlikely that the failure was in font_cache. More likely other
code in the library tried to access this directory. A stacktrace of the
exception would have helped.
Fred
Re: cairo drawing problem
Hi Andreas,
I did not get your original mail and it isn’t even in my spam folder where your
previous mails.
> Am 11.06.2020 um 00:05 schrieb Josh Freeman :
>
> Try initializing your window as NSBackingStoreBuffered?
> (NSBackingStoreNonretained tells the window to draw directly to the screen
> without buffering, so the pixel data is probably unavailable for reading
> back).
This might help but I really would like to understand where the issue comes
from in the first place.
Looking at the code and the output below the first thing I notice is that the X
error happens after the extraction of the view data into the bitmap image was
finished. The most likely scenario is that the data we extracted is somehow
invalid. That would fit in wit your suggested work around.
But all of this is just blind guessing, what we need here is example code that
allows to reproduce this issue with GNUstep classes only.
Andreas, could you please strip down your application to pure GNUstep and if
that still displays the error send out that code?
Cheers,
Fred
> On Jun 8, 2020, at 1:52 PM, Andreas Höschler via Discussion list for the
> GNUstep programming environment wrote:
>
>>
>> Hi all,
>>
>> I have just found some time to continue testing my app(s) on GNUstep and
>> realised that drawing OSM maps fails under GNUstep when using the cairo
>> backend while it works if using libart.
>>
>> My code draws something in a NSView subclass and then uses
>>
>> [mapView display];
>> [mapView lockFocus];
>> NSBitmapImageRep *rep = [[NSBitmapImageRep alloc]
>> initWithFocusedViewRect:[mapView bounds]];
>> data = [[[rep representationUsingType:NSPNGFileType
>> properties:[NSDictionary dictionaryWithObject:[NSNumber numberWithInt:1]
>> forKey:@"NSImageInterlaced"]] retain] autorelease];
>> if ([data length] == 0) // try TIFF instead
>> {
>>data = [[[rep representationUsingType:NSTIFFFileType
>> properties:[NSDictionary dictionaryWithObject:[NSNumber numberWithInt:1]
>> forKey:@"NSImageInterlaced"]] retain] autorelease];
>>if ([data length] == 0) NSLog(@"Damn! TIFF failed as well!");
>> }
>> [mapView unlockFocus];
>>
>> to produce a PNG from the view content. This works great with libart
>>
>> art:
>>
>>
>> 2020-06-08 19:37:18.526 ESMMapServer[10165:10165] draw way inlays... 359
>> _drawPrimaryInLays 1 _drawOtherInLays 1
>> 2020-06-08 19:37:18.527 ESMMapServer[10165:10165] BUMM
>> 2020-06-08 19:37:18.545 ESMMapServer[10165:10165] Draw 7 mapShields ...
>> 2020-06-08 19:37:18.548 ESMMapServer[10165:10165] Draw 1 mapLocs ...
>> 2020-06-08 19:37:18.549 ESMMapServer[10165:10165] Draw 2 mapLines ...
>> 2020-06-08 19:37:18.549 ESMMapServer[10165:10165]
>> drawLine _colorName (null) _color 0 0 1
>> 2020-06-08 19:37:18.549 ESMMapServer[10165:10165]
>> drawLine _colorName (null) _color 0 1 0
>> 2020-06-08 19:37:18.557 ESMMapServer[10165:10165] h=--- v=--- > 0x2302ca0> f={x = 0; y = 0; width = 542; height = 620} b={x = 0; y = 0;
>> width = 542; height = 620} locking Focus ...
>> 2020-06-08 19:37:18.557 ESMMapServer[10165:10165] getting rep ...
>> 2020-06-08 19:37:18.563 ESMMapServer[10165:10165] rep > 0x2f15450 size: {width = 542; height = 620} pixelsWide: 542 pixelsHigh: 620
>> colorSpaceName: NSDeviceRGBColorSpace bps: 8>
>> 2020-06-08 19:37:18.665 ESMMapServer[10165:10165] h=--- v=--- > 0x2302ca0> f={x = 0; y = 0; width = 542; height = 620} b={x = 0; y = 0;
>> width = 542; height = 620} unocked Focus!
>> 2020-06-08 19:37:18.665 ESMMapServer[10165:10165] data 248529
>>
>> but fails with cairo
>>
>> cairo:
>> ===
>> 2020-06-08 19:31:52.783 ESMMapServer[9982:9982] draw way inlays... 359
>> _drawPrimaryInLays 1 _drawOtherInLays 1
>> 2020-06-08 19:31:52.783 ESMMapServer[9982:9982] BUMM
>> 2020-06-08 19:31:52.798 ESMMapServer[9982:9982] Draw 8 mapShields ...
>> 2020-06-08 19:31:52.801 ESMMapServer[9982:9982] Draw 1 mapLocs ...
>> 2020-06-08 19:31:52.802 ESMMapServer[9982:9982] Draw 2 mapLines ...
>> 2020-06-08 19:31:52.802 ESMMapServer[9982:9982]
>> drawLine _colorName (null) _color 0 0 1
>> 2020-06-08 19:31:52.802 ESMMapServer[9982:9982]
>> drawLine _colorName (null) _color 0 1 0
>> 2020-06-08 19:31:52.811 ESMMapServer[9982:9982] h=--- v=--- > 0x28e0fe0> f={x = 0; y = 0; width = 542; height = 620} b={x = 0; y = 0;
>> width = 542; height = 620} locking Focus ...
>> 2020-06-08 19:31:52.812 ESMMapServer[9982:9982] getting rep ...
>> 2020-06-08 19:31:52.815 ESMMapServer[9982:9982] rep > 0x3698ef0 size: {width = 542; height = 620} pixelsWide: 542 pixelsHigh: 620
>> colorSpaceName: NSDeviceRGBColorSpace bps: 8>
>> 2020-06-08 19:31:52.882 ESMMapServer[9982:9982] h=--- v=--- > 0x28e0fe0> f={x = 0; y = 0; width = 542; height = 620} b={x = 0; y = 0;
>> width =
Re: Bad icons on the GWorkspace dock
> Am 11.06.2020 um 00:31 schrieb Patrick Cardona via Discussion list for the > GNUstep programming environment : > > Also I found some kind of EasterEgg : then You click on the running clock in > the Info Panel, it shows a new window, which has this title : > "Memory Panel" and which shows this table : ClassName, Current, Total, Peak... This is a standard feature of all GNUstep gui applications. Nicola Pero build that in to allow the inspection of memory consumption over time. This makes it easier to detect memory leakage.
Re: Graphos.app : error whith make
Could it be that you are using a GNUstep.sh file that does not come from the GNUstep make you are currently using? Your GNUstep make reports its version as 2.7.0 and at that time this variable was long gone. So either you’re GNUstep.sh should not contain this value or it is not related to your make installation. Please try to find out which GNUstep.sh gets source and where this is coming from. Hope this helps, Fred > Am 19.05.2020 um 23:39 schrieb Patrick Cardona : > > The unset method succeeded : I was able to make Graphos and StepSync. > But the GNUSTEP_USER_ROOT was initialy made available bu GNUstep.sh : so I > don't understand why the GNUstep.sh define a wrong or obsolete environment > var. > > Le 18/05/20 à 20:32, Fred Kiefer a écrit : >> >> >>> Am 18.05.2020 um 20:17 schrieb Patrick Cardona via Discussion list for the >>> GNUstep programming environment : >>> >>> Hi All GNUstep Masters, >>> >>> Because I did not find this app from raspbian repository, I tried to make >>> it myself. >>> But I encountered this error : >>> >>> pi@raspberrypi:~/Fabrique/Graphos-0.7 $ make >>> This is gnustep-make 2.7.0. Type 'make print-gnustep-make-help' for help. >>> Running in gnustep-make version 2 strict mode. >>> /usr/share/GNUstep/Makefiles/config-noarch.make:121: *** GNUSTEP_USER_ROOT >>> is obsolete. Arrêt. >>> >>> So, first, it seems that arm achitecture is not recognised. >>> And what does mean : GNUSTEP_USER_ROOT is obsolete ? >>> Because in my env, I got such a variable : >>> >>> pi@raspberrypi:~/Fabrique/Graphos-0.7 $ echo $GNUSTEP_USER_ROOT >>> /home/pi/GNUstep >> >> Just unset that variable and try again.
Re: Graphos.app : error whith make
> Am 18.05.2020 um 20:17 schrieb Patrick Cardona via Discussion list for the > GNUstep programming environment : > > Hi All GNUstep Masters, > > Because I did not find this app from raspbian repository, I tried to make it > myself. > But I encountered this error : > > pi@raspberrypi:~/Fabrique/Graphos-0.7 $ make > This is gnustep-make 2.7.0. Type 'make print-gnustep-make-help' for help. > Running in gnustep-make version 2 strict mode. > /usr/share/GNUstep/Makefiles/config-noarch.make:121: *** GNUSTEP_USER_ROOT is > obsolete. Arrêt. > > So, first, it seems that arm achitecture is not recognised. > And what does mean : GNUSTEP_USER_ROOT is obsolete ? > Because in my env, I got such a variable : > > pi@raspberrypi:~/Fabrique/Graphos-0.7 $ echo $GNUSTEP_USER_ROOT > /home/pi/GNUstep Just unset that variable and try again.
Re: [gnustep/libs-gui] * Source/NSWindow.m (-makeFirstResponder, -sendEvent:): Correct (be12d7b)
> Am 15.05.2020 um 13:33 schrieb Johannes Brakensiek : > > On 15 May 2020, at 9:30, Fred Kiefer wrote: > > Here we don’t follow this principle and this is dangerous as a view we call > this method on may not be as clean as the GNUstep code itself. Patches are > welcome :-) > > And why did I write that I „mostly“ agree? I would not follow this advice > when the value is completely in our control. > > thank you for your explanation! Just a further question: Would it be safe to > just do if([v acceptsFirstMouse: theEvent]) or would that make things worse? Yes, that would be the right thing to do in that place. Fred PS: You signature has expired again.
Re: [gnustep/libs-gui] * Source/NSWindow.m (-makeFirstResponder, -sendEvent:): Correct (be12d7b)
> Am 15.05.2020 um 08:28 schrieb Johannes Brakensiek : > > I'm new to Objective C, so this is just a question: > > In the NY Times Objective C style guide I am reading: > > Values MUST NOT be compared directly to YES, because YES is defined as 1, and > a BOOL in Objective-C is a CHAR type that is 8 bits long (so a value of > 1110 will return NO if compared to YES). > https://github.com/nytimes/objective-c-style-guide > > What do you think of this? Johannes, I am replying to the discussion mailing list, as your mail most likely should have gone there, replying to a GitHub mail directly makes little sense. I mostly agree with the style guide you are citing. And I really didn’t know that the NY Times was using Objective C, looks like they are even hiring :-) It is a shame that there are so few ObjC programmer offerings in Germany. But back to the topic. This is what is common in all C based programming languages and I think Richard is following this principle very strictly in GNUstep base. The idea is to be open in what you accept, but strict in what you return. As far as I am aware he even makes sure to convert values he gets from calls to other methods to YES or NO before returning them. GNUstep qui is not that clean in this respect. The one line I just moved in the commit you are replying to is an example: [v acceptsFirstMouse: theEvent] == YES Here we don’t follow this principle and this is dangerous as a view we call this method on may not be as clean as the GNUstep code itself. Patches are welcome :-) And why did I write that I „mostly“ agree? I would not follow this advice when the value is completely in our control. Cheers, Fred
Re: GUI incompatibility
> Am 14.05.2020 um 13:14 schrieb Fred Kiefer :
>
>> Am 14.05.2020 um 12:22 schrieb Josh Freeman :
>>
>> On May 13, 2020, at 5:52 PM, Andreas Höschler via Discussion list for the
>> GNUstep programming environment wrote:
>>
>>> I could fix the problem under GNUstep by simply commenting out
>>>
>>>
>>> /* if (_firstResponder != v && ![v isKindOfClass: [NSButton
>>> class]])
>>> {
>>> // Only try to set first responder, when the view wants it.
>>> if ([v acceptsFirstResponder] && ![self makeFirstResponder:
>>> v])
>>> {
>>> return;
>>> }
>>> }
>>> */
>>>
>>> Does anything speak against submitting this change into the public tree?
>>
>> That logic should remain - it's useful for when the clicked responder wants
>> first responder status but the current first responder refuses to yield it;
>> In that case, it's probably better to return without passing along the
>> mouseDown event, otherwise the clicked responder will assume it's active &
>> receiving key events, while the current first responder is preventing its
>> own deactivation.
>>
>> That doesn't seem to be the cause of the issue anyway; The different
>> behavior between GNUstep & OS X appears to be due to mismatched return
>> values of -[NSWindow makeFirstResponder:] - if the passed responder refuses
>> first responder status, GNUstep's version returns NO, but OS X's version
>> returns YES:
>> https://developer.apple.com/documentation/appkit/nswindow/1419366-makefirstresponder?language=objc
>
> Thank you Josh for pointing this out. This looks like the correct way to go.
I just committed a change in the line of Josh’s reasoning. Andreas, please give
it a try.
Fred
Re: GUI incompatibility
> Am 14.05.2020 um 12:22 schrieb Josh Freeman :
>
> On May 13, 2020, at 5:52 PM, Andreas Höschler via Discussion list for the
> GNUstep programming environment wrote:
>
>> I could fix the problem under GNUstep by simply commenting out
>>
>>
>> /* if (_firstResponder != v && ![v isKindOfClass: [NSButton
>> class]])
>>{
>> // Only try to set first responder, when the view wants it.
>> if ([v acceptsFirstResponder] && ![self makeFirstResponder:
>> v])
>>{
>> return;
>>}
>>}
>> */
>>
>> Does anything speak against submitting this change into the public tree?
>
> That logic should remain - it's useful for when the clicked responder wants
> first responder status but the current first responder refuses to yield it;
> In that case, it's probably better to return without passing along the
> mouseDown event, otherwise the clicked responder will assume it's active &
> receiving key events, while the current first responder is preventing its own
> deactivation.
>
> That doesn't seem to be the cause of the issue anyway; The different
> behavior between GNUstep & OS X appears to be due to mismatched return values
> of -[NSWindow makeFirstResponder:] - if the passed responder refuses first
> responder status, GNUstep's version returns NO, but OS X's version returns
> YES:
> https://developer.apple.com/documentation/appkit/nswindow/1419366-makefirstresponder?language=objc
Thank you Josh for pointing this out. This looks like the correct way to go.
Fred
Re: GUI incompatibility
> Am 14.05.2020 um 00:53 schrieb Andreas Höschler via Discussion list for the
> GNUstep programming environment :
>>> I could fix the problem under GNUstep by simply commenting out
>>>
>>>
>>> /* if (_firstResponder != v && ![v isKindOfClass: [NSButton
>>> class]])
>>> {
>>> // Only try to set first responder, when the view wants it.
>>> if ([v acceptsFirstResponder] && ![self makeFirstResponder:
>>> v])
>>> {
>>> return;
>>> }
>>> }
>>> */
>>>
>>> Does anything speak against submitting this change into the public tree?
>>
>> Just commenting out parts of the code won’t do. As you could probably see
>> with your own code by adding a log statement in acceptsFirstResponder that
>> method needs to be called. Other changes to this logic here are welcome, but
>> they need to address more than one specific issue. Maybe you could provide
>> more details on what happens on Cocoa?
>
> On Cocoa this happens.
>
>> 13/05/20 17:23:40,783 InterfaceBuilder[93679]:
>> acceptsFirstMouse 1
>> 13/05/20 17:23:40,783 InterfaceBuilder[93679]:
>> becomeFirstResponder 0
>> 13/05/20 17:23:40,784 InterfaceBuilder[93679]:
>> mouseDown ..
>
> So we might want to call acceptsFirstResponder: but not drop out if the
> answer is NO but call mouseDown: anyway!? This would probably mimic the Cocoa
> behaviour!
In your Cocoa output acceptsFirstMouse comes before becomeFirstResponder so
maybe we need to move line 3972 "if (wasKey == YES || [v acceptsFirstMouse:
theEvent] == YES)“ further up. But what should we do with the result of
makeFirstResponder just ignore it?And what should we do with
_lastLeftMouseDownView? At what point should that be cleared? This variable
gets used for drag or mouse up events later on to make sure these go to the
same view as the mouse down event. The current way of setting this value just
before we send the mouse down event to the view seems correct. But why do we
destroy it?
I hope to find time for a few tests on Cocoa later today or on the weekend.
Fred
Re: GUI incompatibility
> Am 13.05.2020 um 23:52 schrieb Andreas Höschler :
>
> I understand the idea behind this part
>
> if (_firstResponder != v && ![v isKindOfClass: [NSButton class]])
> {
> // Only try to set first responder, when the view wants it.
> if ([v acceptsFirstResponder] && ![self makeFirstResponder:
> v])
> {
> NSLog(@"Leaving early");
> return;
> }
>}
>
> but would suggest that this is not entirely correct. My FormTextField refuses
> to become first responder on purpose but nevertheless relies on seeing a
> mouseDown: call. I use that to activate an inspector. At another place in the
> code this mouseDown: is needed to initiate a drag operation to drag the gui
> element around. Cocoa does this correctly IMHO (sends the mouseDown:).
>
> I could fix the problem under GNUstep by simply commenting out
>
>
> /* if (_firstResponder != v && ![v isKindOfClass: [NSButton
> class]])
> {
> // Only try to set first responder, when the view wants it.
> if ([v acceptsFirstResponder] && ![self makeFirstResponder:
> v])
> {
> return;
> }
> }
> */
>
> Does anything speak against submitting this change into the public tree?
Just commenting out parts of the code won’t do. As you could probably see with
your own code by adding a log statement in acceptsFirstResponder that method
needs to be called. Other changes to this logic here are welcome, but they need
to address more than one specific issue. Maybe you could provide more details
on what happens on Cocoa? Maybe the order of things is wrong?
Fred
Re: GUI incompatibility
The relevant section in the sendEvent: method of NSWindow looks like this:
if (wasKey == YES || [v acceptsFirstMouse: theEvent] == YES)
{
if ([NSHelpManager isContextHelpModeActive])
{
[v helpRequested: theEvent];
}
else
{
ASSIGN(_lastLeftMouseDownView, v);
if (toolTipVisible != nil)
{
/* Inform the tooltips system that we have had
* a mouse down so it should stop displaying.
*/
[toolTipVisible mouseDown: theEvent];
}
[v mouseDown: theEvent];
}
}
Looks like we only call acceptsFirstMouse when the window was not already key.
If this isn’t what Cocoa does, you need to explain the expected behaviour.
This code looks like it is there on purpose but Apple may have changed their
implementation or documentation in the meantime.
Cheers,
Fred
> Am 13.05.2020 um 17:37 schrieb Andreas Höschler via Discussion list for the
> GNUstep programming environment :
>
> Hi Fred,
>
> I am still trying to get my apps to work under GNUstep. I have already worked
> around a couple of incompatibilities between Cocoa and GNUstep that caused
> trouble.
>
> I now ended up at the following problem:
>
> I have some NSView subclass on a window
>
> ValueElementCarrier : ElementCarrier : ComponentCarrier :
> ControlCarrier : NSView
>
> ValueElementCarrier has a subview
>
> FormTextField : NSTextField
>
> over its complete rect.
>
> @implementation FormTextField
>
> - (void)mouseDown:(NSEvent *)theEvent
> {
>NSLog(@"%@ mouseDown ..", self);
> ...
> [super mouseDown:theEvent];
> }
>
> - (BOOL)becomeFirstResponder
> {
>BOOL result = ([(FBFormWindow *)[self window] designMode] ? NO : [super
> becomeFirstResponder]);
>NSLog(@"%@ becomeFirstResponder %d", self, result);
>return result;
> }
>
> - (BOOL)acceptsFirstMouse: (NSEvent*)theEvent
> {
>BOOL result = [super acceptsFirstMouse:theEvent];
>NSLog(@"%@ acceptsFirstMouse %d", self, result);
>return result;
> }
>
> @end
>
>
> When I click on this FormTextField on MacOSX I get
>
> 13/05/20 17:23:40,783 InterfaceBuilder[93679]:
> acceptsFirstMouse 1
> 13/05/20 17:23:40,783 InterfaceBuilder[93679]:
> becomeFirstResponder 0
> 13/05/20 17:23:40,784 InterfaceBuilder[93679]:
> mouseDown ..
>
> When I do the same on GNUstep I get
>
> 13/05/20 17:23:40,783 InterfaceBuilder[93679]:
> becomeFirstResponder 0
>
> but no call of acceptsFirstMouse and no call of mouseDown!? This renders my
> up inoperable! :-(
>
> Any idea? Should this behaviour be fixed in GNUstep (handled equally)?
>
> Thanks,
>
> Andreas
>
>
>
>
>
>
>
Re: ctrl-mouse drag does not work
> Am 11.05.2020 um 20:42 schrieb Andreas Höschler via Discussion list for the > GNUstep programming environment : > > > I usually start a drag operation with ctrl-drag in my apps. I just realised > that this (no longer) works under GNUstep. Instead a context menu is raised!? > I first thought this was due to a WindowMaker setting. But I see the same > behaviour under xfce. Has this changed in GNUstep over the years? On MacSOX > and with the old GNUstep tree (we were using years ago) we could happily use > Ctrl-left-mouse-down and then drag to initiate a drag operation. Can this be > reenabled somehow (may be with a global default) in the current GNUstep > release? I am not using Drag that much in GNUstep. This might be because I implemented it and still feel bad about it. But the basic principles haven’t changed since your version of GNUstep. For GNUstep itself no modifier key is required to start a drag operation pressing the left mouse button (which may of course be redefined to the right or any other one) of the mouse and moving the mouse a bit should start this. Of course specific views may require additional keys to be press to start specific operations. Gorm uses this when creating connections between elements. Gorm is really the best place to start testing D with GNUstep as this gets used a lot there. And there it is also easy to see when a Window Manager steals a specific key combination. In that case you will have to either reconfigure your WM or define different modifiers in GNUstep. For GNUstep the simplest way to redefine modifiers keys is in SystemPreferences. If you have further questions please feel free to give me a direct call (telephone or Skype). Just send me a private email if you lost my contact numbers. Cheers, Fred
Re: GNUstep app fails on Ubuntu 16 - found workaround
> Am 11.05.2020 um 13:16 schrieb Andreas Höschler via Discussion list for the
> GNUstep programming environment :
>
>> Thank you Andreas for this huge amount of data. It seems to show that my
>> guess was wrong. The problem is not happening in the GSHorizontalTypesetter
>> and all the extra rects that are shown look correct. But when ever a wrong
>> height shows up it looks like these lines:
>>
>>> 2020-05-09 20:19:40.720 SOObjectBrowser[4163:4163] cache_lookup hit 1
>>> 2020-05-09 20:19:40.720 SOObjectBrowser[4163:4163] In attributed string and
>>> got result from c->usedRect {x = 0; y = 0; width = 1; height = 1e+07}
>>
>> First a cache hit in the string drawing code and then the wrong height, but
>> that height never seems to get produced by the NSLayoutManager. This must
>> point to an error in the cache itself. I found that we do not clean the
>> „used“ flag for the cache when setting it up. Could it be that you are just
>> picking up a random cache entry? I am not sure about that but hacked
>> together a fix hat initialises the cache entries as unused explicitly. Could
>> you please pull the current code from the GNUstep repository and try again
>> with that? This will also include my other attempts in fixing this issue.
>> They should at least not do any harm.
>
> I have repulled libs-gui from git and the problem is gone. My
>
> 2020-05-09 20:19:40.765 SOObjectBrowser[4163:4163] Got height
> 1004.00. We correct this ...
>
> workaround is no longer triggered.
>
> Thanks a lot for your effort!!
Thank you Andreas for confirming that finally I found the correct spot to fix
the issue.
>
>> On 10 May 2020, at 23:57, Riccardo Mottola
>> wrote:
>>
>> I remember this, I have a déjà-vu here! Don't remember the App, but chasing
>> down exactly this issue, I remember that it should be at least "one line"
>> height and that there were issue.
>
> According to my google search result forwarded a couple of days ago this
> issue indeed popped up for others as well. One app that apparently triggered
> it was ProjectCenter. I have never looked into the ProjectCenter code. But
> the problem must have occurred in all apps that do auto resizing of the
> interface using [NSControl sizeToFit] and have image only buttons (obviously
> a rather seldom combination). :-)
I think Riccardo was referring to the issues that your work around (returning
zero size for an empty string) would be causing. We worked on that one together
a few years ago that is why we both remembered the issues with that solution.
Luckily it is no longer needed.
Cheers,
Fred
Re: GNUstep app fails on Ubuntu 16 - found workaround
> Am 09.05.2020 um 20:28 schrieb Andreas Höschler :
>
>
>> Thank you Andreas for pinning this down. Sadly your solution cannot be used
>> directly. That way all text views or text cell would result in a height of
>> zero. The returned size here has to include at least the height of a new
>> line. This gets handled in the class GSLayoutManager (around line 2600) by
>> adding the extra used rectangle to the returned rectangle.
>>
>> If you still got time to look further it would help to know, how big the
>> extra_used_rect is in your case and where these values come from. Maybe we
>> fail to initialise the value correctly? That value should get set by the
>> class GSHorizontalTypesetter (line 555). If the wrong value comes from there
>> then the current font is to blame. Could you please inspect that?
>>
>> Again thank you very much!
>
>
> I inserted a bunch of log statements. See below for the modified code:
>
>
> And here is the output that is logged when opening the form with the image
> button. Search for "Got height 1004.00. We correct this ..." and
> examine the lines above. Does this give us a clue? I unfortunately get lost
> in the usedRectForTextContainer: method. :-)
Thank you Andreas for this huge amount of data. It seems to show that my guess
was wrong. The problem is not happening in the GSHorizontalTypesetter and all
the extra rects that are shown look correct. But when ever a wrong height shows
up it looks like these lines:
> 2020-05-09 20:19:40.720 SOObjectBrowser[4163:4163] cache_lookup hit 1
> 2020-05-09 20:19:40.720 SOObjectBrowser[4163:4163] In attributed string and
> got result from c->usedRect {x = 0; y = 0; width = 1; height = 1e+07}
First a cache hit in the string drawing code and then the wrong height, but
that height never seems to get produced by the NSLayoutManager. This must point
to an error in the cache itself. I found that we do not clean the „used“ flag
for the cache when setting it up. Could it be that you are just picking up a
random cache entry? I am not sure about that but hacked together a fix hat
initialises the cache entries as unused explicitly. Could you please pull the
current code from the GNUstep repository and try again with that? This will
also include my other attempts in fixing this issue. They should at least not
do any harm.
Cheers,
Fred
Re: GNUstep app fails on Ubuntu 16 - found workaround
Thank you Andreas for pinning this down. Sadly your solution cannot be used
directly. That way all text views or text cell would result in a height of
zero. The returned size here has to include at least the height of a new line.
This gets handled in the class GSLayoutManager (around line 2600) by adding the
extra used rectangle to the returned rectangle.
If you still got time to look further it would help to know, how big the
extra_used_rect is in your case and where these values come from. Maybe we fail
to initialise the value correctly? That value should get set by the class
GSHorizontalTypesetter (line 555). If the wrong value comes from there then the
current font is to blame. Could you please inspect that?
Again thank you very much!
Fred
> Am 08.05.2020 um 22:53 schrieb Andreas Höschler via Discussion list for the
> GNUstep programming environment :
>
> It seems [NSAttributedString size] has a problem!?
>
>
> I did the following:
>
> - (NSSize) size
> {
> if ([self length] == 0) return NSZeroSize; // <-- inserted this
>
> NSRect usedRect = [self boundingRectWithSize: NSZeroSize
>options:
> NSStringDrawingUsesLineFragmentOrigin];
> return usedRect.size;
> }
>
> - (NSSize) sizeWithAttributes: (NSDictionary *)attrs
> {
> if ([self length] == 0) return NSZeroSize; // <-- inserted this
>
> NSRect usedRect = [self boundingRectWithSize: NSZeroSize
>options:
> NSStringDrawingUsesLineFragmentOrigin
> attributes: attrs];
> return usedRect.size;
> }
>
> Problem gone!! :-)
>
> Regards,
>
> Andreas
Re: GNUstep app fails on Ubuntu 16 - found workaround
> Am 08.05.2020 um 20:00 schrieb Andreas Höschler :
>
> NSButtonCell.m
> ==
> - (NSSize) cellSize
> {
> ...
> if (imageToDisplay)
> {
> imageSize = [imageToDisplay size];
> NSLog(@"cellSize imageSize %@", NSStringFromSize(imageSize));
> }
> ...
> case NSImageLeft:
> case NSImageRight:
> s.width = imageSize.width + titleSize.width + GSCellTextImageXDist;
> NSLog(@"imageSize.height %f titleSize.height %f", imageSize.height,
> titleSize.height);
> s.height = MAX(imageSize.height, titleSize.height);
> break;
> ...
>
> // Add border size
> s.width += border.left + border.right;
> NSLog(@"border.top %f border.bottom %f", border.top, border.bottom);
> s.height += border.top + border.bottom;
> NSLog(@"returning s %@", NSStringFromSize(s));
> ...
> }
>
>
> 2020-05-08 19:58:14.729 SOObjectBrowser[14224:14224] cellSize imageSize
> {width = 15; height = 15}
> 2020-05-08 19:58:14.730 SOObjectBrowser[14224:14224] imageSize.height
> 15.00 titleSize.height 1000.00
> 2020-05-08 19:58:14.730 SOObjectBrowser[14224:14224] border.top 0.00
> border.bottom 0.00
> 2020-05-08 19:58:14.730 SOObjectBrowser[14224:14224] returning s {width = 18;
> height = 1e+07}
> 2020-05-08 19:58:14.730 SOObjectBrowser[14224:14224] Reporting
> button::imagePosition 2
> 2020-05-08 19:58:14.730 SOObjectBrowser[14224:14224] Reporting
> _cell::imagePosition 2
> 2020-05-08 19:58:14.730 SOObjectBrowser[14224:14224] Got height
> 1004.00. We correct this ...
>
> The mess is caused by the titleSize!? :-( I haven't set a title since this is
> an image only button!
Now we are getting closer. But this is weird, The variable titleSize gets
initialised with NSZeroSize and later only changed here
if (titleToDisplay != nil)
{
titleSize = [titleToDisplay size];
}
Could you add another NSLog line there and report the value of titleToDisplay?
This looks like either a bug in our NSString drawing code or the compiler
itself. We really need to get to the bottom of this. Fixing NSWindow is just a
work around that won’t help you much.
Fred
Re: GNUstep app fails on Ubuntu 16 - found workaround
> Am 08.05.2020 um 17:48 schrieb Andreas Höschler :
>
>> that is a very interesting analysis you provided. Could you tell us a bit
>> more about the images you are using? Or to be concrete, what is the size of
>> one of these images? If these images report such huge values for their
>> height this would explain the behaviour you are seeing.
>
> The images are rather tiny. Here is the one that caused the problem in one of
> the forms:
>
>
Yes, this looks rather small.
>> In NSButtonCell the computation of cellSize relies directly on the value
>> reported by the image. It would also be interesting to know, which value
>> gets used for the image position of the button cell.
>
> I don't set that. So I guess it's a default position!? Let's see ...
>
> @implementation NSButton (sizeToContent)
>
> - (void)sizeToFit
> {
>NSSize size = [_cell cellSize];
>if (size.height > 1.0)
> {
> NSLog(@"Reporting button::imagePosition %d", [self imagePosition]);
> NSLog(@"Reporting _cell::imagePosition %d", [_cell imagePosition]);
> }
>[self setFrameSize: size];
> }
>
> @end
Could you please move the logging code one level down into the NSButtonCell and
report from there how this is calculated? Also report the image size as seen by
the cell. You could check the value of s.height at the end of the method and if
it is huge report textSize, imageSize and border
An image position of 2 should be NSImageLeft, which is fine.
Cheers,
Fred
Re: GNUstep app fails on Ubuntu 16 - found workaround
It turns out that we do not limit the frame of a window on creation. The lines
of code in NSWindow look like this:
_frame = [NSWindow frameRectForContentRect: contentRect styleMask: aStyle];
_minimumSize = NSMakeSize(_frame.size.width - contentRect.size.width + 1,
_frame.size.height - contentRect.size.height + 1);
_maximumSize = NSMakeSize (10e4, 10e4);
Every attempt to set the size too big later on will be blocked, but doing so on
creation is passed through. I will have to come up with a solution for this.
Maybe just call setFrame: in the next line?
Fred
> Am 08.05.2020 um 17:29 schrieb Fred Kiefer :
>
> HI Andreas,
>
> that is a very interesting analysis you provided. Could you tell us a bit
> more about the images you are using? Or to be concrete, what is the size of
> one of these images? If these images report such huge values for their height
> this would explain the behaviour you are seeing.
>
> In NSButtonCell the computation of cellSize relies directly on the value
> reported by the image. It would also be interesting to know, which value gets
> used for the image position of the button cell. I don’t see a sensible way
> we could fix this problem directly in GNUstep gui. The only way would be to
> enforce some arbitrary limit for views and this is not possible as we may
> have some coordinate transformation in place and seemingly huge values would
> be converted to usable ones. As for the window enforcing limits there makes
> sense but I vaguely remember that we already have code for that in place.
> Although I am still looking for that limit.
>
> Cheers,
> Fred
>
>
>> Am 08.05.2020 um 16:31 schrieb Andreas Höschler via Discussion list for the
>> GNUstep programming environment :
>>
>> In the meanwhile I have inserted an [NSException raise:...] into
>> /libs-back/Source/x11/XWindowBuffer.m
>>
>> if (!wi->ximage)
>>{
>> NSLog(@"Warning: XShmCreateImage failed!");
>> NSLog(@"Falling back to normal XImage (will be slower).");
>> goto no_xshm;
>>}
>> wi->shminfo.shmid = shmget(IPC_PRIVATE,
>>wi->ximage->bytes_per_line * wi->ximage->height,
>>IPC_CREAT | 0700);
>>
>> if (wi->shminfo.shmid == -1)
>>{
>> NSLog(@"Warning: shmget() failed: %m.");
>> NSLog(@"Falling back to normal XImage (will be slower).");
>>
>> [NSException raise:NSInternalInconsistencyException
>> format:@"asas"]; // <-- remove this
>>
>> XDestroyImage(wi->ximage);
>> goto no_xshm;
>>}
>>
>> to get a backtrace of what triggers the shmget() problem and got this
>>
>> #0 -[NSException raise] (self=0x46c75c0, _cmd=0x76ac64e0
>> <_OBJC_SELECTOR_TABLE+480>) at NSException.m:1574
>> #1 0x76565bba in +[NSException raise:format:arguments:]
>> (self=0x76ac6020 <_OBJC_Class_NSException>,
>>_cmd=0x76ac64b0 <_OBJC_SELECTOR_TABLE+432>, name=0x76ac59e0
>> <_OBJC_INSTANCE_4>, format=0x7fffee2ccd50 <_OBJC_INSTANCE_12>,
>>argList=0x7fffca10) at NSException.m:1465
>> #2 0x76565b01 in +[NSException raise:format:] (self=0x76ac6020
>> <_OBJC_Class_NSException>, _cmd=0x7fffee2cd3b0 <_OBJC_SELECTOR_TABLE+176>,
>>name=0x76ac59e0 <_OBJC_INSTANCE_4>, format=0x7fffee2ccd50
>> <_OBJC_INSTANCE_12>) at NSException.m:1450
>> #3 0x7fffee05d046 in +[XWindowBuffer windowBufferForWindow:depthInfo:]
>> (self=0x7fffee2cd280 <_OBJC_Class_XWindowBuffer>,
>>_cmd=0x7fffee2d2320 <_OBJC_SELECTOR_TABLE+320>, awindow=0x1072ce0,
>> aDI=0x7fffcba0) at XWindowBuffer.m:322
>> #4 0x7fffee0620d7 in -[ARTGState(internal) stuff:GSSetDevice:::]
>> (self=0x1087990, _cmd=0x7fffee2d1840 <_OBJC_SELECTOR_TABLE+352>,
>> window=0x1072ce0,
>>x=1, y=1547) at ARTGState.m:644
>> #5 0x7fffee05e933 in -[ARTContext(ops) GSSetDevice:::] (self=0x3f7f2f0,
>> _cmd=0x7fffee2ca860 <_OBJC_SELECTOR_TABLE+1472>, device=0x1072ce0, x=1,
>>y=1547) at ARTContext.m:164
>> #6 0x7fffee04a30f in GSSetDevice (ctxt=0x3f7f2f0, device=0x1072ce0,
>> x=1, y=1547) at
>> /usr/GNUstep/Local/Library/Headers/AppKit/DPSOperators.h:1153
>> #7 0x7fffee052111 in -[XGServer(WindowOps) setWindowdevice:forContext:]
>> (self=0xa53760, _cmd=0x7fffee2ba080 <_OBJC_SELECTOR_TABLE+448>, win=164,
>>ctxt=0x3f7f2f0) at XGServerWindow.m:2683
>>
Re: GNUstep app fails on Ubuntu 16 - found workaround
HI Andreas,
that is a very interesting analysis you provided. Could you tell us a bit more
about the images you are using? Or to be concrete, what is the size of one of
these images? If these images report such huge values for their height this
would explain the behaviour you are seeing.
In NSButtonCell the computation of cellSize relies directly on the value
reported by the image. It would also be interesting to know, which value gets
used for the image position of the button cell. I don’t see a sensible way we
could fix this problem directly in GNUstep gui. The only way would be to
enforce some arbitrary limit for views and this is not possible as we may have
some coordinate transformation in place and seemingly huge values would be
converted to usable ones. As for the window enforcing limits there makes sense
but I vaguely remember that we already have code for that in place. Although I
am still looking for that limit.
Cheers,
Fred
> Am 08.05.2020 um 16:31 schrieb Andreas Höschler via Discussion list for the
> GNUstep programming environment :
>
> In the meanwhile I have inserted an [NSException raise:...] into
> /libs-back/Source/x11/XWindowBuffer.m
>
> if (!wi->ximage)
> {
> NSLog(@"Warning: XShmCreateImage failed!");
> NSLog(@"Falling back to normal XImage (will be slower).");
> goto no_xshm;
> }
> wi->shminfo.shmid = shmget(IPC_PRIVATE,
> wi->ximage->bytes_per_line * wi->ximage->height,
> IPC_CREAT | 0700);
>
> if (wi->shminfo.shmid == -1)
> {
> NSLog(@"Warning: shmget() failed: %m.");
> NSLog(@"Falling back to normal XImage (will be slower).");
>
>[NSException raise:NSInternalInconsistencyException
> format:@"asas"]; // <-- remove this
>
> XDestroyImage(wi->ximage);
> goto no_xshm;
> }
>
> to get a backtrace of what triggers the shmget() problem and got this
>
> #0 -[NSException raise] (self=0x46c75c0, _cmd=0x76ac64e0
> <_OBJC_SELECTOR_TABLE+480>) at NSException.m:1574
> #1 0x76565bba in +[NSException raise:format:arguments:]
> (self=0x76ac6020 <_OBJC_Class_NSException>,
> _cmd=0x76ac64b0 <_OBJC_SELECTOR_TABLE+432>, name=0x76ac59e0
> <_OBJC_INSTANCE_4>, format=0x7fffee2ccd50 <_OBJC_INSTANCE_12>,
> argList=0x7fffca10) at NSException.m:1465
> #2 0x76565b01 in +[NSException raise:format:] (self=0x76ac6020
> <_OBJC_Class_NSException>, _cmd=0x7fffee2cd3b0 <_OBJC_SELECTOR_TABLE+176>,
> name=0x76ac59e0 <_OBJC_INSTANCE_4>, format=0x7fffee2ccd50
> <_OBJC_INSTANCE_12>) at NSException.m:1450
> #3 0x7fffee05d046 in +[XWindowBuffer windowBufferForWindow:depthInfo:]
> (self=0x7fffee2cd280 <_OBJC_Class_XWindowBuffer>,
> _cmd=0x7fffee2d2320 <_OBJC_SELECTOR_TABLE+320>, awindow=0x1072ce0,
> aDI=0x7fffcba0) at XWindowBuffer.m:322
> #4 0x7fffee0620d7 in -[ARTGState(internal) stuff:GSSetDevice:::]
> (self=0x1087990, _cmd=0x7fffee2d1840 <_OBJC_SELECTOR_TABLE+352>,
> window=0x1072ce0,
> x=1, y=1547) at ARTGState.m:644
> #5 0x7fffee05e933 in -[ARTContext(ops) GSSetDevice:::] (self=0x3f7f2f0,
> _cmd=0x7fffee2ca860 <_OBJC_SELECTOR_TABLE+1472>, device=0x1072ce0, x=1,
> y=1547) at ARTContext.m:164
> #6 0x7fffee04a30f in GSSetDevice (ctxt=0x3f7f2f0, device=0x1072ce0, x=1,
> y=1547) at /usr/GNUstep/Local/Library/Headers/AppKit/DPSOperators.h:1153
> #7 0x7fffee052111 in -[XGServer(WindowOps) setWindowdevice:forContext:]
> (self=0xa53760, _cmd=0x7fffee2ba080 <_OBJC_SELECTOR_TABLE+448>, win=164,
> ctxt=0x3f7f2f0) at XGServerWindow.m:2683
> #8 0x7fffee022ed5 in -[GSContext initWithContextInfo:] (self=0x3f7f2f0,
> _cmd=0x77d676e0 <_OBJC_SELECTOR_TABLE+3520>, info=0x46cad70)
> at GSContext.m:226
> #9 0x778b598d in -[NSWindow _startBackendWindow] (self=0x108b160,
> _cmd=0x77d67770 <_OBJC_SELECTOR_TABLE+3664>) at NSWindow.m:915
> #10 0x778b5d69 in -[NSWindow _initBackendWindow] (self=0x108b160,
> _cmd=0x77d67890 <_OBJC_SELECTOR_TABLE+3952>) at NSWindow.m:967
> #11 0x778b66f7 in -[NSWindow
> initWithContentRect:styleMask:backing:defer:] (self=0x108b160,
> _cmd=0x73970980 <_OBJC_SELECTOR_TABLE+1888>,
> contentRect=..., aStyle=15, bufferingType=2, flag=0 '\000') at
> NSWindow.m:1100
> #12 0x7370ed00 in -[GSMarkupTagWindow platformObjectInit]
> (self=0x21f6c20, _cmd=0x73952c80 <_OBJC_SELECTOR_TABLE+2272>)
> at GSMarkupTagWindow.m:180
>
> The corresponding code is
>
>
> GSMarkupTagWindow:
> ==
> - (void)platformObjectInit
> {
> ...
>NSLog(@"contentRect %@ style %d backingType %d",
> NSStringFromRect(contentRect), style, backingType);
>[self setPlatformObject:[_platformObject initWithContentRect:contentRect
> styleMask:style backing:backingType defer:NO]];
>
> }
>
> and the output of the log line is
>
> 2020-05-08
Re: cannot locate symbol "utext_setup_67"
i am no expert in this area, but my first idea would be that GNUstep base was build with ICU 67 installed and so this function got used (in the code we just reference text_setup) and now this version cannot be found during linking. On a normal Linux system I would suggest to use ldd on gnustep-base.so to see where the references point to. On Android I don’t know whether this command is available. The easiest way out would be to rebuild GNUstep from scratch and see if the error persists. Hope this helps, Fred > Am 01.05.2020 um 23:34 schrieb Stefan Pauwels : > > I rebuilt the Android Toolchain with the current state of master today and > updated the cmake arguments with "-DANDROID_STL=c++_shared“ according to the > examples, but now I’m getting a crash with > >java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol > "utext_setup_67" referenced by „(…)==/lib/x86/libgnustep-base.so"… > > Any ideas? > Thanks! > > Stefan
Re: How to ensure methods are set in my GNUstep build
HI Gustavo, that method on NSDateComponents is something that I just did add to the GNUstep base source last week. If you really need that code you would have to switch to use GNUstep directly from the up to date git repository. Basically you would need to update base and start the recompilation from there. Maybe it is easier to just start over from scratch again? Hope this helps, Fred PS: As that code is pretty new, expect some glitches in the beginning. > Am 30.04.2020 um 00:49 schrieb Gustavo Tavares : > >> >> I've installed GNUstep using this script from Plaurent: >> https://github.com/plaurent/gnustep-build/blob/master/ubuntu-19.10-clang-9.0-runtime-2.0/GNUstep-buildon-ubuntu1910.sh >> and have been successfully building some projects with it. >> >> For my current project, I'm encountering a build error. I was thinking it >> was a config on the GNU install—and later I thought it was something I could >> define in a Makefile—but I can't seem to work out how to solve it. >> >> The error is this: >> >> MyFile.m:130:50: error: no visible @interface for 'NSDateComponents' >> declares the selector 'valueForComponent:' >> >> I can see that the MAC_OS_VERSION and GS_API_VERSION are somehow determined >> in GSVersionMacros.h and that this determines whether to inlcude this >> NSDateComponents functionality—but I also don't know where the headers are >> in my system. Looking in /usr/GNUstep/System/ and ~/GNUstep/Library/Headers >> and I can't echo it out either. >> >> https://github.com/gnustep/libs-base/blob/fc0c0da188eb4ee2800ab9643394aa16660ef6bd/Headers/GNUstepBase/GSVersionMacros.h >> >> Would really appreciate it if someone could help me get this built :) What >> do I need to do / invoke? >> >> Thank you! >> >> Gustavo
Re: NSCalendar bug (mktime related)
I changed a few things in NSCalendar:
First I completed NSDateComponents up to the recent Cocoa specification. That
part should be fairly complete and correct.
Next I tried to support more of these components in the existing NSCalendar
methods. While doing so I noticed some oddities in that class and tried to
clean those. And while doing that I did get even more confused about the
interaction with NSLocale.
Finally I tried to make NSCalendar respect the timezone of NSDateComponents. As
Stefan already pointed out you have to be careful here not to change the state
of the calendar itself, but the state currently also includes one ucal object,
which means that NSCalendar is not multithread safe and that some operations
may influence later ones. To work around this I am now using a local ucal
object for -dateFromComponents:.
As I wrote, I am no expert in this area and my changes may have broken some
stuff. At least the tests (plus my new one) still work. Please give this
classes some more real testing and feel free to provide test code.
If these changes work out I am willing to implement some of the missing methods
on NSCalendar.
@Richard:
In the header file NSCalendar.h there are some left over instance variables
that according to the comments there could be removed in a binary compatibility
breaking release of base. Are you planing to have the next release to be binary
compatible or not?
Cheers,
Fred
> Am 25.04.2020 um 16:36 schrieb Stefan Bidigaray :
>
> Hi Fred/Andreas,
> I wrote all that code, so I'm fairly familiar with it. The code is entirely
> dependent on ICU's implementation of ucal, so the solution is to simply set
> the Time Zone value in the ucal. The function to do this is:
> ucal_setTimeZone()
> (https://unicode-org.github.io/icu-docs/apidoc/released/icu4c/ucal_8h.html#ae5612988cb9dc282ccda82fda38602b2).
>
> I no longer have a development machine with GNUstep installed, so I cannot
> make the changes and test it. There are two methods where this needs to be
> fixed:
> -dateByAddingComponents:toDate: and -dateFromComponents:.
>
> The part I'm not totally sure of is if the fix should be done by calling
> -setTimeZone: or ucal_setTimeZone(). Based on the method descriptions, I
> believe a call to ucal_setTimeZone should be added to lines NSCalendar.m:546
> and NSCalendar.m:611 (first a UChar timezone name must be retrieved from the
> NSTimeZone object) since -setTimeZone: will permanently modify the NSCalendar
> object.
>
> Regards
> Stefan
>
> On Sat, Apr 25, 2020 at 9:58 AM Fred Kiefer wrote:
> Hi Andreas,
>
> I checked the code of NSCalendar, which you could have done yourself, this is
> free software, and we are not using mtkime there. The problem is a lot worse.
> We just ignore the handed in time zone of the NSDateComponents. This could be
> repaired but I am no expert on NSCalendar so if anybody else wants to look
> into this feel free. It would be great to have a few more tests for
> NSCalendar. Anybody willing to provide a few test cases?
>
> Fred
>
> > Am 23.04.2020 um 10:51 schrieb Andreas Fink :
> >
> > Hello all,
> >
> > I have run into a very weird thing in conversion from NSStrings to NSDate.
> > The result is we are always off by 1h under LInux.
> > Under MacOS X I have the same problem but only with mktime() not with
> > NSCalendar.
> > I am suspecting Gnustep implementation probably uses mktime() in the back
> > and thus inherits this issue also for NSCalendar.
> >
> > What I try to do is to convert aNSString with a timestamp which is always
> > in UTC into a date.
> > So the timestamp I supply has timezone GMT+0 and no daylight savings time.
> > If the current system currently experiences daylight savings time, the
> > result by mktime is off by 1h even if I specify timezone to be UTC in
> > struct tm.
> >
> > Here is a test programm for this:
> >
> >
> > #define _BSD_SOURCE
> > #include
> > #include
> > #include
> > time_t test(void)
> > {
> >struct tm tm;
> > memset(,0, sizeof(tm));
> >
> > int year = 1970;
> > int month = 1;
> > int day = 1;
> > int hour = 0;
> > int minute = 0;
> > int second = 0;
> >
> > tm.tm_year = year -1900;
> > tm.tm_mon = month -1,
> > tm.tm_mday = day;
> > tm.tm_hour = hour;
> > tm.tm_min = minute;
> > tm.tm_sec = second;
> > tm.tm_zone = "UTC";
> > tm.tm_isdst = -1;
> > tm.tm_gmtoff = 0;
> >
> > time_t t = mktime();
> > return t;
> > }
> >
> >
> > int main(in
Re: NSCalendar bug (mktime related)
Hi Andreas,
I checked the code of NSCalendar, which you could have done yourself, this is
free software, and we are not using mtkime there. The problem is a lot worse.
We just ignore the handed in time zone of the NSDateComponents. This could be
repaired but I am no expert on NSCalendar so if anybody else wants to look into
this feel free. It would be great to have a few more tests for NSCalendar.
Anybody willing to provide a few test cases?
Fred
> Am 23.04.2020 um 10:51 schrieb Andreas Fink :
>
> Hello all,
>
> I have run into a very weird thing in conversion from NSStrings to NSDate.
> The result is we are always off by 1h under LInux.
> Under MacOS X I have the same problem but only with mktime() not with
> NSCalendar.
> I am suspecting Gnustep implementation probably uses mktime() in the back and
> thus inherits this issue also for NSCalendar.
>
> What I try to do is to convert aNSString with a timestamp which is always in
> UTC into a date.
> So the timestamp I supply has timezone GMT+0 and no daylight savings time.
> If the current system currently experiences daylight savings time, the result
> by mktime is off by 1h even if I specify timezone to be UTC in struct tm.
>
> Here is a test programm for this:
>
>
> #define _BSD_SOURCE
> #include
> #include
> #include
> time_t test(void)
> {
>struct tm tm;
> memset(,0, sizeof(tm));
>
> int year = 1970;
> int month = 1;
> int day = 1;
> int hour = 0;
> int minute = 0;
> int second = 0;
>
> tm.tm_year = year -1900;
> tm.tm_mon = month -1,
> tm.tm_mday = day;
> tm.tm_hour = hour;
> tm.tm_min = minute;
> tm.tm_sec = second;
> tm.tm_zone = "UTC";
> tm.tm_isdst = -1;
> tm.tm_gmtoff = 0;
>
> time_t t = mktime();
> return t;
> }
>
>
> int main(int argc, const char * argv[])
> {
> time_t t;
>
> setenv("TZ","UTC",1);
> t = test();
> printf("TZ=UTC: t=%d\n",t);
>
> setenv("TZ","CET",1);
> t = test();
> printf("TZ=CET: t=%d\n",t);
>
> setenv("TZ","CEST",1);
> t = test();
> printf("TZ=CEST: t=%d\n",t);
>
> setenv("TZ","Europe/Zurich",1);
> t = test();
> printf("TZ=Europe/Zurich: t=%d\n",t);
>
> }
>
>
> So the timestamp I supply has timezone GMT+0 and no daylight savings time.
> So the time_t value returned should always be 0 but its off by -1h if the
> envirnment has the timezone set to Europe/Zurich or CET. Interestingly CEST
> is correct (which is the current timezone in Zurich CET + Daylight savings
> time)
>
> TZ=UTC: t=0
> TZ=CET: t=-3600
> TZ=CEST: t=0
> TZ=Europe/Zurich: t=-3600
>
> The output of this is indicating that the daylight savings yes/no from the
> supplied timezone is ignore as well as the timezone. It always bases the date
> on the current environmental variable even though the current timezone might
> not be the one in effect at that date.
> So it assumes that on 1.11970 we had daylight savings time (because TZ says
> we have now) despite being in January and despite it wasn't in use in that
> year even.
>
> Now lets say this is a bug of mktime or maybe a wanted feature. Be is at it
> is.
>
> The problem is NSCalendar fails for the same issue.
>
>
> This piece of code works under MacOS X but fails under Linux.
> Under NSCalendar I specify the timezone explicitly and TZ environment
> variable should not be relevant. But if NSCalendar implementation uses
> mktime, it inherits above strange behaviour.
>
> NSDate *dateFromStringNSCalendar(NSString *str, const char *ctimezone_str) /*
> expects -MM-DD hh.mm.ss.SS TZ timestamps */
> {
> int year;
> int month;
> int day;
> int hour;
> int minute;
> int seconds;
> double subsecond = 0;
> const char *cdate_str;
> const char *ctime_str;
>
> NSArray *components = [str componentsSeparatedByString:@" "];
> if(components.count >0)
> {
> NSString *s = components[0];
> cdate_str = s.UTF8String;
> }
> if(components.count > 1)
> {
> NSString *s = components[1];
> ctime_str = s.UTF8String;
> }
> if(components.count > 2)
> {
> NSMutableArray *arr = [components mutableCopy];
> [arr removeObjectsInRange:NSMakeRange(0,2)];
> NSString *s = [arr componentsJoinedByString:@" "];
> ctimezone_str = s.UTF8String;
> }
>
> /* parsing date */
> sscanf(cdate_str,"%04d-%02d-%02d",
>,
>,
>);
> if(strlen(ctime_str) ==8 ) /* HH:mm:ss.SS */
> {
> sscanf(ctime_str,"%02d:%02d:%02d",
>,
>,
>);
> }
> else if(strlen(ctime_str) >=9 ) /* HH:mm:ss.SS */
> {
> sscanf(ctime_str,"%02d:%02d:%lf",
>,
>,
>);
> seconds = (int)subsecond;
> subsecond = subsecond -
Re: md5 hashing on GNUstep
Have a look at libs-base/Source/Additions/NSData+GNUstepBase.m
> Am 01.04.2020 um 19:46 schrieb H. Nikolaus Schaller :
>
>>
>> Am 01.04.2020 um 19:43 schrieb Andreas Höschler :
>>
>> Hi all,
>>
>> I have the following NSString category
>>
>> @implementation NSString (NSStringJsonExtension)
>>
>> - (NSString *)md5
>>{
>> #ifdef __APPLE__
>> const char *cStr = [self UTF8String];
>> unsigned char result[CC_MD5_DIGEST_LENGTH];
>> CC_MD5( cStr, (int)strlen(cStr), result ); // This is the md5 call
>> return [NSString stringWithFormat:
>> @"%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x",
>> result[0], result[1], result[2], result[3],
>> result[4], result[5], result[6], result[7],
>> result[8], result[9], result[10], result[11],
>> result[12], result[13], result[14], result[15]
>> ];
>> #else
>> NSLog(@"md5 not yet supported on GNUstep. Please implement");
>
> https://linux.die.net/man/3/md5_init
>
> maybe
> unsigned char *MD5(cStr, strlen(cStr), result);
>
> You need to install openssl devel packages.
>
>
>> return nil;
>> #endif
>>}
>>
>> @end
>>
>> working on MacOSX (neede to access HkVision cameras).
>>
>> I would like to port this app to GNUstep and therefore need code that builds
>> on Ubuntu (current GNUstep tree). The above code gives
>>
>> SRHTTPRequest.m:93:27: error: 'CC_MD5_DIGEST_LENGTH' undeclared (first use
>> in this function)
>> unsigned char result[CC_MD5_DIGEST_LENGTH];
>> ^
>> SRHTTPRequest.m:93:27: note: each undeclared identifier is reported only
>> once for each function it appears in
>> SRHTTPRequest.m:94:6: warning: implicit declaration of function 'CC_MD5'
>> [-Wimplicit-function-declaration]
>> CC_MD5( cStr, (int)strlen(cStr), result ); // This is the md5 call
>> ^
>> Any idea how to do md5 hashing on Linux/GNUstep?
>>
>> Thanks a lot in advance!
>>
>> Andreas
Re: Touch panel keyboard in GNUstep app
The actual transfer happens in NSWindow makeFirstResponder. You should be able
to log the current and the future first responder in that method to see who is
requesting this. And if you run in a debugger and put a break point in this
method you might be even able to see where this call comes from. But beware,
this gets called quite a lot and debugging Guidebook applications may be
difficult. The most likely caller is sendEvent: on NSWindow, but as Wolfgang
noted this should ignore NSButton.
Fred
> Am 31.03.2020 um 13:30 schrieb Andreas Höschler :
>
> Hi Fred,
>
> in the meanwhile I was able to test the
>
> - (void)mouseDown:(NSEvent *)theEvent
> {
> NSLog(@"mouseDown ...");
> [NSApp preventWindowOrdering];
>
> [self highlight:YES];
>
> NSEvent *mouseUpEvent = [[self window]
> nextEventMatchingMask:NSLeftMouseUpMask untilDate:[NSDate distantFuture]
> inMode:NSEventTrackingRunLoopMode dequeue:YES];
> NSPoint mouseLocation = [self convertPoint:[mouseUpEvent locationInWindow]
> fromView:nil];
> BOOL mouseUpInside = [self mouse:mouseLocation inRect:[self bounds]];
>
> if (mouseUpInside)
>{
> if ([self target]) [[self target] performSelector:[self action]
> withObject:self];
>}
> [self highlight:NO];
> }
>
> code fragment (NSButton subclass) on GNUstep. And as expected it does not
> work there. So I am still looking for a solution ...
>
> Do you know which part in the GNustep source tree resigns fist responder from
> a currently active control and transfers it to a clicked button? I got
> somehow lost in the event handling code.
>
> Thanks a lot,
>
>Andreas
>
>
>
>> The method preventWindowOrdering is a NOOP on GNUstep, so it won’t help you.
>> Put if this is what helps you on MacOS then most likely your touch panel is
>> stealing the focus. You should try to override canBecomeKeyWindow for that
>> panel.
>>
>> Hope this help,
>> Fred
>>
>>> Am 30.03.2020 um 19:13 schrieb Andreas Höschler :
>>>
> Am 30.03.2020 um 15:19 schrieb Andreas Höschler :
>
> Hi Fred,
>
>> in NSButton you find this code:
>>
>>
>> - (BOOL) acceptsFirstMouse: (NSEvent *)theEvent
>> {
>> return YES;
>> }
>>
>>
>> You will need to write a subclass to handle this different.
>
> Thanks a lot for your response. I created a subclass KbButton and
> overwrote this method like so
>
> - (BOOL)acceptsFirstMouse:(NSEvent *)theEvent
> {
> NSLog(@"%@ returns acceptsFirstMouse NO", self);
> return NO;
> }
>
> When I click on the button the currently active NSTextField looses first
> responder and the action of the button is called
>
> 30/03/20 14:42:16,912 ScaleMaster[59798]: strike sender 0x7b82ae50> stringValue A
>
> The method acceptsFirstMouse: of KbButton is never called. So this
> unfortunately does not work, at least not on MacOSX (dev machine for the
> project). :-( I will port the code to GNUstep and see whether GNUstep
> behaves differently. Will let you know ...
Well, yes. I'm afraid Fred's advice is wrong (even though . While the code
in -[NSWindow sendEvent:] indeed requires The method acceptsFirstMouse is
supposed to serve a different purpose. When you activate window by
clicking onto it, acceptsFirstMouse governs whether this click is passed
to the control under the mouse (acceptsFirstMouse returns YES) or whether
it is only for activating the window (acceptsFirstMouse returns NO). Your
original approach calling setAcceptsFirstResponder: with NO looks right to
me. It is just that the code in -[NSEvent sendEvent:] gets the logic
wrong. Where it currently says
if ([v acceptsFirstResponder] && ![self makeFirstResponder: v])
{
return;
}
it should really say
if (![v acceptsFirstResponder] || ![self makeFirstResponder: v])
{
return;
}
>>>
>>> I got this working on MacOSX by subclassing NSButton and doing
>>>
>>> - (void)mouseDown:(NSEvent *)theEvent
>>> {
>>> NSLog(@"mouseDown ...");
>>> [NSApp preventWindowOrdering];
>>>
>>> [self highlight:YES];
>>>
>>> NSEvent *mouseUpEvent = [[self window]
>>> nextEventMatchingMask:NSLeftMouseUpMask
>>> untilDate:[NSDate distantFuture] inMode:NSEventTrackingRunLoopMode
>>> dequeue:YES];
>>> NSPoint mouseLocation = [self convertPoint:[mouseUpEvent locationInWindow]
>>> fromView:nil];
>>> BOOL mouseUpInside = [self mouse:mouseLocation inRect:[self bounds]];
>>>
>>> if (mouseUpInside)
>>>{
>>> if ([self target])
>>> [[self target] performSelector:[self action] withObject:self];
>>>}
>>> [self highlight:NO];
>>> }
>>>
>>> I haven't tested that on the GNUstep machine yet. But if it worked there as
>>> well this would make my day.
>>>
>>> Best wishes,
>>>
>>> Andrea
>>>
>>
Re: Touch panel keyboard in GNUstep app
The method preventWindowOrdering is a NOOP on GNUstep, so it won’t help you.
Put if this is what helps you on MacOS then most likely your touch panel is
stealing the focus. You should try to override canBecomeKeyWindow for that
panel.
Hope this help,
Fred
> Am 30.03.2020 um 19:13 schrieb Andreas Höschler :
>
>>
>>> Am 30.03.2020 um 15:19 schrieb Andreas Höschler :
>>>
>>> Hi Fred,
>>>
in NSButton you find this code:
- (BOOL) acceptsFirstMouse: (NSEvent *)theEvent
{
return YES;
}
You will need to write a subclass to handle this different.
>>>
>>> Thanks a lot for your response. I created a subclass KbButton and overwrote
>>> this method like so
>>>
>>> - (BOOL)acceptsFirstMouse:(NSEvent *)theEvent
>>> {
>>> NSLog(@"%@ returns acceptsFirstMouse NO", self);
>>> return NO;
>>> }
>>>
>>> When I click on the button the currently active NSTextField looses first
>>> responder and the action of the button is called
>>>
>>> 30/03/20 14:42:16,912 ScaleMaster[59798]: strike sender >> 0x7b82ae50> stringValue A
>>>
>>> The method acceptsFirstMouse: of KbButton is never called. So this
>>> unfortunately does not work, at least not on MacOSX (dev machine for the
>>> project). :-( I will port the code to GNUstep and see whether GNUstep
>>> behaves differently. Will let you know ...
>>
>> Well, yes. I'm afraid Fred's advice is wrong (even though . While the code
>> in -[NSWindow sendEvent:] indeed requires The method acceptsFirstMouse is
>> supposed to serve a different purpose. When you activate window by clicking
>> onto it, acceptsFirstMouse governs whether this click is passed to the
>> control under the mouse (acceptsFirstMouse returns YES) or whether it is
>> only for activating the window (acceptsFirstMouse returns NO). Your original
>> approach calling setAcceptsFirstResponder: with NO looks right to me. It is
>> just that the code in -[NSEvent sendEvent:] gets the logic wrong. Where it
>> currently says
>> if ([v acceptsFirstResponder] && ![self makeFirstResponder: v])
>> {
>> return;
>> }
>> it should really say
>> if (![v acceptsFirstResponder] || ![self makeFirstResponder: v])
>> {
>> return;
>> }
>
> I got this working on MacOSX by subclassing NSButton and doing
>
> - (void)mouseDown:(NSEvent *)theEvent
> {
> NSLog(@"mouseDown ...");
> [NSApp preventWindowOrdering];
>
> [self highlight:YES];
>
> NSEvent *mouseUpEvent = [[self window]
> nextEventMatchingMask:NSLeftMouseUpMask
> untilDate:[NSDate distantFuture] inMode:NSEventTrackingRunLoopMode
> dequeue:YES];
> NSPoint mouseLocation = [self convertPoint:[mouseUpEvent locationInWindow]
> fromView:nil];
> BOOL mouseUpInside = [self mouse:mouseLocation inRect:[self bounds]];
>
> if (mouseUpInside)
> {
> if ([self target])
> [[self target] performSelector:[self action] withObject:self];
> }
> [self highlight:NO];
> }
>
> I haven't tested that on the GNUstep machine yet. But if it worked there as
> well this would make my day.
>
> Best wishes,
>
> Andrea
>
Re: Touch panel keyboard in GNUstep app
Hi Andreas,
in NSButton you find this code:
- (BOOL) acceptsFirstMouse: (NSEvent *)theEvent
{
return YES;
}
You will need to write a subclass to handle this different.
Cheers,
Fred
> Am 25.03.2020 um 18:56 schrieb Andreas Höschler :
>
> Hi all,
>
> I am just trying to add a touch panel keyboard feature to some GNUstep app,
> meaning that I have added a bunch of NSButtons with titles "A", "B", "C",...
> to the GUI of my app. My plan is to generate and send some key-event whenever
> a user clicks (actually presses with his finger on a touch screen) on one of
> the on-screen keyboard buttons.
>
> However, for this to work I need to make sure that the keyboard buttons never
> get first responder but that e.g. an NSTextField in the GUI (first responder
> before clicking on a key button) stays first responder and receives the
> programmatically generated key-event.
>
> I have run
>
> [button setRefusesFirstResponder:YES];
>
> on the keyboard buttons but this did not do the trick. The NSTextField that
> is first responder before clicking on one of the key board buttons resigns
> first responder before the action of the button is executed. :-(
>
> Any idea how to correctly set this up?
>
> Thanks a lot in advance!!
>
> Best,
>
> Andreas
>
>
Re: Wayland backend update
I looked through your patch files and this seems to be great. It would be excellent to have a git repository where we could merge this from. You will need to assign the copyright for your changes to the FSF of course. Merging this would make me happy and I am sure Ivan feels the same :-) Fred > Am 03.01.2020 um 22:50 schrieb Fred Kiefer : > > Wow, I am impressed that somebody is working on this. I will be away for the > long weekend, but I promise to look into your work as soon as I am back. > > Thank you and happy New Year! > Fred > >> Am 03.01.2020 um 22:36 schrieb Ladislav Michl : >> >> Hi there, >> >> this is quick wayland backend update based on >> https://github.com/ivucica/libs-back/tree/ivucica-wayland >> >> Note that original Sergio's patch is rebased to current master, >> the rest is just to make things work somehow again. You can find >> current work in progress here: >> https://paste.debian.net/1124403 >> https://paste.debian.net/1124404 >> https://paste.debian.net/1124405 >> https://paste.debian.net/1124406 >> https://paste.debian.net/1124407 >> >> ..and a picture: https://ibb.co/DRFmH2T (so you can see there's work left) >> >> This is just to have something to play with again. As I've never touched >> Wayland nor GNUstep before and another winter holidays are about a year >> in the future do not expect miracles. I can make some more cleanups >> and perhaps prepare it for merge, but let's see how many people are >> actually interested - Debian paste expires in 90 days ;-) >> >> Happy New Year, >> ladis >> > >
Re: Wayland backend update
Wow, I am impressed that somebody is working on this. I will be away for the long weekend, but I promise to look into your work as soon as I am back. Thank you and happy New Year! Fred > Am 03.01.2020 um 22:36 schrieb Ladislav Michl : > > Hi there, > > this is quick wayland backend update based on > https://github.com/ivucica/libs-back/tree/ivucica-wayland > > Note that original Sergio's patch is rebased to current master, > the rest is just to make things work somehow again. You can find > current work in progress here: > https://paste.debian.net/1124403 > https://paste.debian.net/1124404 > https://paste.debian.net/1124405 > https://paste.debian.net/1124406 > https://paste.debian.net/1124407 > > ..and a picture: https://ibb.co/DRFmH2T (so you can see there's work left) > > This is just to have something to play with again. As I've never touched > Wayland nor GNUstep before and another winter holidays are about a year > in the future do not expect miracles. I can make some more cleanups > and perhaps prepare it for merge, but let's see how many people are > actually interested - Debian paste expires in 90 days ;-) > > Happy New Year, > ladis >
Re: ProjectCenter running or building
> Am 02.01.2020 um 19:06 schrieb Patryk Laurent : > > > It looks like the “name” in LLDB was referring to the binary’s name. So I > placed an NSLog right before NSBundle.m:2280 to print out the local variable > name and _frameworkVersion — which is null for all the classes being loaded, > including “LogPanel”. Please see below. Sorry Patryk, from now on this is a clang issue and I am no longer of any help here. Maybe David has an idea what is going on? It would help to know which version of clang used to work and on which version it is failing. The next thing would be to write a minimal framework and an application using this to reproduce the issue. Fred
Re: ProjectCenter running or building
In your examples the name was „ProjectCenter“ not „LogPanel“. You need to continue your debugging until you get to that name. Only this resource seems to get loaded from a framework. For the other resources having a framework version of nil is correct. Fred > Am 30.12.2019 um 01:17 schrieb Patryk Laurent : > > On December 29, 2019 at 12:31 PM, Fred Kiefer wrote: > >> Thank you for your tests. I had a look into the NSBundle code in base and >> from that I think that we have an issue with frameworks here. Is clang >> supporting frameworks? >> The code in base doesn’t have any log statements that we could use. So this >> means you will have to switch to a debugger and run ProjectCenter with a >> breakpoint on NSBundle.m:2280 and wait until we get around with the name >> „LogPanel“ and see whether the framework version gets added correctly. >> > > From within the debugger I am seeing that _frameworkVersion tends to be nil. > And I'm having trouble seeing the values of NSStrings... so maybe there's > something up. > > Patryk > > > (base) > patryk@wax:~/gnustep-build/ubuntu-19.04-clang-8.0-runtime-2.0/GNUstep-build/apps-projectcenter/ProjectCenter.app$ > lldb ./ProjectCenter > (lldb) target create "./ProjectCenter" > Current executable set to './ProjectCenter' (x86_64). > > (lldb) breakpoint set --file NSBundle.m --line 2280 > Breakpoint 1: no locations (pending). > WARNING: Unable to resolve breakpoint to any actual locations. > > (lldb) run > Process 3951 launched: > '/home/patryk/gnustep-build/ubuntu-19.04-clang-8.0-runtime-2.0/GNUstep-build/apps-projectcenter/ProjectCenter.app/ProjectCenter' > (x86_64) > 1 location added to breakpoint 1 > Process 3951 stopped > * thread #1, name = 'ProjectCenter', stop reason = breakpoint 1.1 > frame #0: 0x77731997 libgnustep-base.so.1.27`-[NSBundle > pathForResource:ofType:inDirectory:](self=0x00683768, _cmd="-", > name=0x77a8c978, extension=0xe1b34f3e802c, > subPath=0x) at NSBundle.m:2283:7 >2280 NSString *rootPath; >2281 >2282 #if !defined(_WIN32) > -> 2283 if (_frameworkVersion) >2284 rootPath = [NSString stringWithFormat: @"%@/Versions/%@", [self > bundlePath], >2285 _frameworkVersion]; >2286 else > > (lldb) fr va _frameworkVersion > (NSString *) _frameworkVersion = nil > (lldb) n > Process 3951 stopped > * thread #1, name = 'ProjectCenter', stop reason = step over > frame #0: 0x777319e5 libgnustep-base.so.1.27`-[NSBundle > pathForResource:ofType:inDirectory:](self=0x00683768, _cmd="-", > name=0x77a8c978, extension=0xe1b34f3e802c, > subPath=0x) at NSBundle.m:2288:16 >2285 _frameworkVersion]; >2286 else >2287 #endif > -> 2288 rootPath = [self bundlePath]; >2289 >2290 return [NSBundle _pathForResource: name >2291 ofType: extension > > (lldb) n > Process 3951 stopped > * thread #1, name = 'ProjectCenter', stop reason = step over > frame #0: 0x777319f4 libgnustep-base.so.1.27`-[NSBundle > pathForResource:ofType:inDirectory:](self=0x00683768, > _cmd=, name=0x77a8c978, extension=0xe1b34f3e802c, > subPath=0x) at NSBundle.m:2290:10 >2287 #endif >2288 rootPath = [self bundlePath]; >2289 > -> 2290 return [NSBundle _pathForResource: name >2291 ofType: extension >2292 inRootPath: rootPath >2293 inDirectory: subPath]; > > (lldb) fr va rootPath > (NSString *) rootPath = 0x006838a8 > (lldb)
