Re: starting an app bundle natively - NSWorkspace launchApplication

> Am 04.07.2024 um 00:06 schrieb Riccardo Mottola : > > > Fred Kiefer wrote: >>> is NSWorkspace's launchApplication the best answer? >> Yes, to me this sounds like the right way to go. > > indeed, it works for running. It didn't yesterday because

Re: starting an app bundle natively - NSWorkspace launchApplication

> Am 02.07.2024 um 22:15 schrieb Riccardo Mottola : > > Hi, > > is there a way to start an application - as in GNUstep or mac app bundle - > natively from? > Something that would be the equivalent of gopen/openapp essentially. > > To start a normal executable I can use NSTask. > I see two

GUI and Back release

I generated the files that are needed for a GUI and back release. I don’t have the means to generate the release itself. It would be creat if somebody (Richard or Ivan) could do that right after the base release. I ran into an issue with generating the NEWS and ANNOUNCE files for GUI (on back

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

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.

Re: issues generating icon - NSImageRep immutable ?

Sorry, I am completely lost here. Are you referring to line 301 or 351? I think that you expect the code starting in line 351 will be able to update the appIcon. This won’t work in GNUstep. When locking focus on an image we try to draw a representation of the image on an NSCachedImageRep. Your

Re: GNUstep devs on FOSDEM 2023?

I am sorry, I won’t make it to FOSDEM this year. Seeing you would be great but the German railway (DB) has all connections flagged as being unreliable und during the last year we learned what that means. I ope you have a great time there. Cheers, Fred > Am 10.01.2023 um 14:30 schrieb Ivan

Re: Releases

get this fixed within the next few hours, I will just mail you the changes to the news files. Sorry for the delay, Fred > Am 28.12.2022 um 14:35 schrieb Fred Kiefer : > > Merry Christmas to you too Richard! > > Great that you started to build releases of make and base. If it is

Re: Releases

Merry Christmas to you too Richard! Great that you started to build releases of make and base. If it isn’t too much trouble for you, could you please release guidance and back as well? The last release there was almost two years ago. I am willing to update the news.texi file for these two

Re: Invitation: Discussion of GCC v. Clang -- redux of quarterly meeting ... @ Sat Feb 12, 2022 12pm - 2pm (EST) (gnustep-dev@gnu.org)

I will only be able to attend for an hour or so, as we have booked a table at a restaurant at 19:30 that evening. Cheers, Fred > Am 09.02.2022 um 16:38 schrieb greg.casame...@gmail.com: > > You have been invited to the following event. > Discussion of GCC v. Clang -- redux of quarterly meeting

Re: Automated Reference Counting (Was: Disappointed by GNUstep)

> Am 07.02.2022 um 18:47 schrieb Wolfgang Lux : > >> Am 06.02.2022 um 19:50 schrieb Fred Kiefer : >> >>> Am 06.02.2022 um 16:30 schrieb Wolfgang Lux : >>> >>>> There are bugs in GNUstep and probably there always will be. We don’t get >>

Re: Disappointed by GNUstep

Hi Wolfgang, > Am 06.02.2022 um 16:30 schrieb Wolfgang Lux : > >> There are bugs in GNUstep and probably there always will be. We don’t get >> enough testing, usage, for GNUstep gun applications, so many bugs may go >> unnoticed for a long time. At least the first bug you mention below is >>

Re: Disappointed by GNUstep

HI Wolfgang, it is sad to read about you being disappointed by GNUstep. Especially on the one day where I was looking forward to join the GNUstep quarterly online meeting. There are bugs in GNUstep and probably there always will be. We don’t get enough testing, usage, for GNUstep gun

Re: wayland PR

For me merging that PR is fine. I did approve it some time ago. If nobody objects I would merge it next week. Fred > Am 28.11.2021 um 10:27 schrieb Riccardo Canalicchio > : > > hello, > I'd like to follow up on this PR: > https://github.com/gnustep/libs-back/pull/33 > > I was thinking that

Re: GNUstep releases this month?

HI Ivan, still waiting for the thumbs up? You definitely got one from me :-) Riccardo and Richard fixed a few bugs in the meantime and there are surely a few more to fix, but there always will be. We really should try to get a new release out to the world. At the moment I am faced with a few

Re: Windows mingw64 - loading of certain Gorms broken - NSSearchField ?

Thank you for finding this. I made a mistake when I changed the encoding to use our new helper functions. For strange reasons an unsigned int had been used for the maximum. Should be fixed now. Hopefully no Gorm file was created in the meantime. Cheers, Fred > Am 12.02.2021 um 14:08 schrieb

Re: gnustep gui localization - UTF8 issues

Great you did find this. This was my fault. I regenerated that fie and all other language files just as I always do before a release. I was not aware that this file (and the one for Esperanto) had been converted to UTF8 and the tool we use to generate these files seems to ignore the old format.

Re: Base - color pparsing bug - Was: [Re: GNUstep releases this month?]

> Am 20.01.2021 um 20:13 schrieb Riccardo Mottola : > > Hi, > > Fred Kiefer wrote: >>> I will try to bisect - but I'd liek to track this down before a release, >>> especially knowing it is something done these last months. >> If this is really a recent

Re: GNUstep releases this month?

> Am 20.01.2021 um 17:08 schrieb Riccardo Mottola : > > Hi, > > Richard Frith-Macdonald wrote: >> I think the base library is functionally OK, but I need to get ChangeLog >> updated from the git logs, and it turns out there is no tool that does a >> good job of this so it may take me a day

Re: GNUstep releases this month?

> Am 18.01.2021 um 16:46 schrieb Ivan Vučica : > > On Mon, Jan 18, 2021 at 10:55 AM Richard Frith-Macdonald > wrote: >>> On 16 Jan 2021, at 19:50, Fred Kiefer wrote: >>> >>> I updated the required files and also increased the version number in both &

Re: GNUstep releases this month?

can cut releases next > week. > > If a maintainer wishes me to release and upload anything that is not > included in the usual batch of releases on ftp.gnu.org, let me know > and I can try pushing that out as well. > > On Thu, Jan 14, 2021 at 6:27 PM Fred Kiefer wrote: >> >> Hi I

Re: GNUstep releases this month?

Hi Ivan, great that you remind us! The problem at the moment is that there is a know problem for 64bit big endian systems in gui (actually a rather long standing issue) and even two suitable solutions for it. But we haven’t decided which solution to prefer. Either we reach a consensus quickly

Re: NSControls failing to set status/label on BigEndian/64bit

> Am 08.01.2021 um 01:23 schrieb Riccardo Mottola : > > Richard Frith-Macdonald wrote: >> Changing the type of the masks from NSInteger to uint32_t would also fix the >> encoding/decoding of course. Maybe that has other issues though. > > perhaps we should try a mixed approach: encode/decode

Re: NSControls failing to set status/label on BigEndian/64bit

> Am 07.01.2021 um 14:33 schrieb Riccardo Mottola : > > Wolfgang Lux wrote: >> Yes. Changing the type you pass to the {en,de}codeValueOfObjCType methods is >> a, errm, not so bright idea. The types are included in the binary archives. >> So, trying to decode a value with a different type

Re: NSControls failing to set status/label on BigEndian/64bit

> Am 06.01.2021 um 22:57 schrieb Wolfgang Lux : > >> good catch. We have two differences here 32bit vs 64bit, but also signed vs >> unsigned! > > the difference between signed and unsigned is irrelevant for encoding and > decoding, as you pass a pointer to the memory being encoded or

Re: NSControls failing to set status/label on BigEndian/64bit

> Am 06.01.2021 um 17:20 schrieb Wolfgang Lux : > > > >> Am 06.01.2021 um 17:15 schrieb Wolfgang Lux : >> >>  >> >>> Am 06.01.2021 um 15:41 schrieb Fred Kiefer : >>> >>>  >>> The next step would be to compare thes

Re: NSControls failing to set status/label on BigEndian/64bit

> Am 06.01.2021 um 15:32 schrieb Riccardo Mottola : > > Fred Kiefer wrote: >> >> You should concentrate on the _highlightByMask which gets decoded in line >> 1905 (_showAltStateMask is handled just below). > > I put a log statement "after" and I al

Re: NSControls failing to set status/label on BigEndian/64bit

> Am 06.01.2021 um 01:06 schrieb Riccardo Mottola : > > On 2021-01-05 08:07:59 +0000 Fred Kiefer wrote: > >>> line 1094, after the mask is calculated, do you expect it to be always 0, >>> both for on and off state? It is always 0 for me. >> As you can see

Re: NSControls failing to set status/label on BigEndian/64bit

> Am 05.01.2021 um 01:28 schrieb Riccardo Mottola : > > > Fred Kiefer wrote: >> thank you for pointing out this issue. As I don’t have a Bigendian 64 bit >> system you will have to do the testing to pin this down. First I would >> propose that

Re: NSControls failing to set status/label on BigEndian/64bit

Hi Riccardo, thank you for pointing out this issue. As I don’t have a Bigendian 64 bit system you will have to do the testing to pin this down. First I would propose that you add a few NSLog statements in NSButtonCell.m after line 1773. Most likely the data is not aligned in the unsigned int

Re: Thematic Crash - hard to debug

The lines that the debugger reports look like this: if ([[img image] size].width > 64 || [[img image] size].height > 64) The most likely reason for a crash here is [img image] being nil. Just add a check for this condition a few lines above and see what happens. Hope this helps, Fred

Re: Crashes in GUI when applying a theme (Thematic)

> Am 23.11.2020 um 17:50 schrieb Richard Frith-Macdonald > : > >> On 22 Nov 2020, at 22:09, Riccardo Mottola >> wrote: >> >> Riccardo Mottola wrote: >>> #0 0x772103ab in objc_msg_lookup () from >>> /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/libobjc.so.4 >>> #1 0x77bf976c in

Away for two weeks

Dear GNUsteppers, I will be away for two weeks of holidays with very limited internet access. This may delay any pull request for gui and back for a few days. That shouldn’t cause too much inconvenience. Cheers, Fred

Re: [PATCH resend] Remove hack to fake OBJCXX checks

I commited your patch to GNustep make. Thank you, Fred Am 26.08.20 um 21:28 schrieb Ladislav Michl: > Remove hack to fake OBJCXX checks as autoconf-2.65 (first one > supporting Objective-C++) is over ten years old already. > --- > Hi, > > this is resend of a patch patch sent more than half a

Re: Missing text in gui apps on Kubuntu

t; > Cheers, > > Josh > > > > > [1] Earlier install problems were due to running the KDE Neon installer under > BIOS; KDE Neon requires UEFI. > > > On May 30, 2020, at 5:27 PM, Fred Kiefer wrote: > >> Thank you Josh for this excellent analysis. M

Issue with gcc 10

OpenSuse did just switch to gcc 10 and now I have issues with GNUstep make. The gcc version gets detected as 1.0 which is obviously wrong. But this is only partly our fault gcc actually behaves strange: gcc --version gcc (SUSE Linux) 10.1.1 20200507 [revision

Re: Missing text in gui apps on Kubuntu

Thank you Josh for this excellent analysis. My impression is that this is somewhat of a Kubuntu bug, still it is better to fix it in our code especially if this results in a speed up. Such a speed up is really needed for slower machines. I will look through the details of the patch tomorrow

Re: GWorkspace startup - Setting unknown econding

> Am 29.05.2020 um 21:13 schrieb Riccardo Mottola : > > Hi Fred, > > > Fred Kiefer wrote: >> Turns out I was wrong here. Of course the bison grammar was wrong and needed >> correction, but this was not what caused this issue. Here 1 is a valid >> co

Re: GWorkspace startup - Setting unknown econding

. This specific one was important as it gets used a lot on the Mac. Please give the new code a try, Fred > Am 26.05.2020 um 15:44 schrieb Fred Kiefer : > > Most likely I made an error in the rtfGrammer.y file on line 212. The > statement "$$ = 3" should just re

Re: GWorkspace startup - Setting unknown econding

Most likely I made an error in the rtfGrammer.y file on line 212. The statement "$$ = 3" should just read "3". I will correct that and regenerate the dependent files as soon as I am back home, that is sometimes next weekend. You could check whether this is the case by looking at your RTF files,

Re: Lost information converting decoded value to in32_t

> Am 25.05.2020 um 09:28 schrieb RIccardo Mottola : > > I noticed that on a totally fresh installation on intel 32bit, I get many > warnings of the type "Lost information converting decoded value to in32_t" > when starting GWorkspace. > > Putting a breakpoint, I noticed that this issue is

Re: CMake 3.16

> Am 15.05.2020 um 12:02 schrieb David Chisnall : > > At some point, I'd like to move libobjc2 to requiring at least CMake 3.16. > 3.15 gained support for driving the GCC-flavoured clang on Windows with the > Visual Studio ABI (older versions have to use clang-cl, which takes Visual >

Re: Next GNUstep release

Thank you Ivan for the great work you are doing here. And I promise to try to lighten the work on the next release by making sure every pull request gets it proper ChangeLog entry. Fred > Am 05.04.2020 um 22:42 schrieb Ivan Vučica : > > I have cut new releases: > - gnustep-make 2.8.0 > -

Re: Next GNUstep release

: > On Tue, Feb 11, 2020 at 8:09 AM Fred Kiefer > wrote: >> And most importantly, Ivan will you have time to cut all these >> releases? Of course we could move that point around a week or two >> if that date fits better > > I've only now seen this. > > T

Re: Display issues (Was: Next GNUstep release)

> Am 28.02.2020 um 11:37 schrieb Riccardo Mottola : > Sergii Stoian wrote: >> >>> On Feb 27, 2020, at 23:09, Riccardo Mottola >>> wrote: >>> >>> before a release, I would like these issues to find a solution. >>> >>> - understand why we don't work properly on my ThinkPad T23 neither with

Re: crash when using local display but not remote

> Am 25.02.2020 um 17:25 schrieb Riccardo Mottola : > > Fred Kiefer wrote: >> I still don’t know for sure what is going on here. Most likely we are >> overriding some other data when copying the image. To prevent this I made >> the pre conditio

GNUstep Travis

Currently our build tests for GNUstep base and gut are broken. This render the automatic validation of pull requests useless. I am rather sure that the issue is again not in base but rather in changes build requirements of libobjc2, caused by a change in GNUstep make or that strange linker

Re: crash when using local display but not remote

> Am 19.02.2020 um 00:37 schrieb Riccardo Mottola : > > Fred Kiefer wrote: >> You won’t have to look up the WINGs documentation. In most cases we do not >> use a separate Wraster library but have copies of the files in this >> directory. The one you are looking for

Re: crash when using local display but not remote

> Am 18.02.2020 um 21:59 schrieb Riccardo Mottola : > > Fred Kiefer wrote: >> >> You may have to set these separately. I was hoping there was a way to >> specify and array here, but did not check. So the easiest was is >> >> Ink —GNU-Debug=Dflt —GNU

Re: crash when using local display but not remote

> Am 17.02.2020 um 23:53 schrieb Riccardo Mottola : > > Fred Kiefer wrote: >> >> >> With all the latest changes could you please try again and report the stack >> trace you are getting? It would also help if you could find out which code >> is crashi

Next GNUstep release

Dear GNUsteppers, I would like to schedule a shared new release for the core GNUstep packages (make, base, gui, back) around the end of March. We have a lot of excellent new features and it would be great to bring those out to more distributions and users. We are a bit later than in previous

Re: crash when using local display but not remote

> Am 08.02.2020 um 12:50 schrieb Riccardo Mottola : > > On 07/02/2020 10:20, Fred Kiefer wrote: >> I just committed a merge of the two approaches (plus a few compiler warning >> fixes). I hope this should fix Riccardo's issues. It might also be slightly >> faster a

Re: Multimonitor support

> Am 08.02.2020 um 15:20 schrieb Riccardo Mottola : > > On 03/02/2020 21:15, Fred Kiefer wrote: >> Sergii has written a great patch that will tremendously improve support for >> multiple monitors in GNUstep by using the XRandR extension. There is a >> downsi

Re: crash when using local display but not remote

> Am 04.02.2020 um 22:15 schrieb Sergii Stoian : > >> On Feb 4, 2020, at 20:43, Fred Kiefer wrote: >> In general it is safer as the new code expects that the image is fully >> packed. (You moved the comment with the conversion from unpacked to packed >

Multimonitor support

Dear GNUstepper, Sergii has written a great patch that will tremendously improve support for multiple monitors in GNUstep by using the XRandR extension. There is a downside to it though, this patch will also remove any multi screen support that was there before without XRandR. So if you have a

Re: crash when using local display but not remote

> Am 03.02.2020 um 00:53 schrieb Sergii Stoian : > > On Mon, Feb 3, 2020 at 1:05 AM Fred Kiefer wrote: > > I just ran a quick scan with valgrind and this did not detect any obvious > wrong memory access. Looking at the code once again I see that line 4276 may >

Re: crash when using local display but not remote

> Am 02.02.2020 um 21:38 schrieb Riccardo Mottola : > > On 1/28/20 11:28 AM, Sergii Stoian wrote: >> >> I'm not sure, just an idea: this problem may have relation to enabled >> multithreading in X11. Probably due to outdated X server. >> Could you please try to comment out line in

Re: [PATCH 0/3] gnustep-make: stage 1 of cross-compile awareness

Thank you for your patches. The first two are clear improvements. The third one also looks good to me, but I must admit it is really hard to read through in a patch mail (and I only read the configure.ac part. After the merge I would regenerate configure locally). As far as I can tell you

Re: Cross-compilation

First off, I tried to run GNUstep cross compilation ages ago and never succeeded and I didn’t hear that things improved in between. But for your specific problem it looks like you set „target“ when building make and later when building base you set both „host“ and „target“. And what is more

Re: Eggplant (formerly Testplant) Forks

Hi Adam, thank you very much for providing this. It will cost me quite some time to look through your changes but I am happy to do so. You could have saved me some effort by providing these changes a bit earlier :-( Just a few days ago I took over your XIB loading changes from a probably

Re: issue with mixed Objective-C ABI and SystemPreferences

From the error message I would suspect that you have an old plugin for SystemPreferences lying around that still gets loaded causing this issue. > Am 05.01.2020 um 23:01 schrieb RIccardo Mottola : > > I was able to compile most of GNUsteps apps with the options discussed in a > previous mail,

Re: Accidental merge into libs-gui

You really had me in a short state of shock when coming back from jogging and seeing this merge had happened. Thank you for cleaning up that quickly! Fred > Am 03.01.2020 um 13:50 schrieb Sergii Stoian : > > Fixed. > I've used `git rebase -i` and `git push origin master --force`. Everything

Re: [gnustep/libs-gui] NSPopUpButton's popup menu in pulldown mode displaying fix (#43)

ii > >> On 24 Dec 2019, at 17:32, Fred Kiefer wrote: >> >> Sorry for not being clear enough. Using rounded pull downs or different >> edges is nothing a theme would do. This is official functionality that the >> normal GNUstep drawing must support. We woul

Re: [gnustep/libs-gui] NSPopUpButton's popup menu in pulldown mode displaying fix (#43)

gii > >> On 24 Dec 2019, at 15:15, Fred Kiefer wrote: >> >> In your images the only difference I see is the focus ring and even that I >> see barely. But the real difference will be shown when using a rounded pull >> down or as Wolfgang pointed out one that u

Re: [gnustep/libs-gui] NSPopUpButton's popup menu in pulldown mode displaying fix (#43)

with current code, the second (PullDown-new.png) with my code. > I hope you'll notice the difference. > > > > > On Tue, Dec 24, 2019 at 12:06 PM Fred Kiefer wrote: > HI Sergii, > > here is what a pull down NSPopUpButton looks like on Cocoa: > > > > Th

Re: [gnustep/libs-gui] NSPopUpButton's popup menu in pulldown mode displaying fix (#43)

t 18:15, Wolfgang Lux wrote: > > > > > >> Am 20.12.2019 um 16:11 schrieb Fred Kiefer : > >> There you just describe that now the popup looks the same whether in pull > >> down or in popup state. But what is the reason for this change? As I wrote > >>

Re: [gnustep/libs-gui] NSPopUpButton's popup menu in pulldown mode displaying fix (#43)

> Am 20.12.2019 um 15:20 schrieb Sergii Stoian : > > On Fri, Dec 20, 2019 at 2:24 PM Fred Kiefer wrote: > > > > Am 20.12.2019 um 11:34 schrieb Sergii Stoian : > > > > I've moved discussion to mail list as Fred asked me. > > > > On Fri, Dec

Re: [gnustep/libs-gui] NSPopUpButton's popup menu in pulldown mode displaying fix (#43)

> Am 20.12.2019 um 11:34 schrieb Sergii Stoian : > > I've moved discussion to mail list as Fred asked me. > > On Fri, Dec 20, 2019 at 12:18 PM Fred Kiefer wrote: > Some of the changes of this pull request are obviously correct. What I doubt > is the overall chan

Re: Base NSScanner/GSFormat issues - segmentation fault

> Am 16.12.2019 um 11:44 schrieb Riccardo Mottola : > > on a very plain Linux i386 32bit setup, configured with clang, libobjc2 and > ng-gnu-gnu runtime I always had issues with almost everything crashing, this > is months old (years?). > > What happens is this: > Program received signal

Re: Working on XIB document support

find this useful, Fred > Am 09.12.2019 um 10:46 schrieb Fred Kiefer : > > I just want to let you know that I have started to integrate the > Eggplant code for XIB document loading, that is the newer XIB format, > into GNUstep gui. Over the weekend I managed to integrate a mi

Working on XIB document support

I just want to let you know that I have started to integrate the Eggplant code for XIB document loading, that is the newer XIB format, into GNUstep gui. Over the weekend I managed to integrate a minimal version of the code into a git branch and get it compile with gcc. The next step is to clean up

Gitflow proposal

First off before I explain why I am strongly against Gitflow let me restate that I advocate feature branches and pull requests. But I will come back to that in the end. A software workflow should match the organisation and purpose of a project and the people that defined Gitflow are well aware

Re: base fails to compile with gcc

I fixed these places. Bugs like this could easily be avoided by using branches and pull requests and having the travis CI test the build on different environments. But this did not happen. Looks like somebody wants to stop compilation of GNUstep with gcc. Fred > Am 14.11.2019 um 21:55

Re: GNUstep graphical elements missing text on Aarch64

> Am 24.08.2019 um 03:07 schrieb Patryk Laurent via Gnustep-dev > : > > On Aug 22, 2019, at 22:30, Fred Kiefer wrote: > >> Could you please provide some details about your system? >> >> Am 23.08.2019 um 01:20 schrieb Patryk Laurent via Gnustep-dev &

Re: GNUstep graphical elements missing text on Aarch64

Could you please provide some details about your system? Which version of GNUstep are you using, what graphic backend (Cairo is the default), which compiler, OS and so on. Even with those details I won’t be able to help you before next week as I am in the middle of the Italian alpes but maybe

Re: Commit access?

Hi Marcus, the simplest thing to do until you get commit access is to fork the GNUstep repository into yours and work with pull requests. I will be able to merge these but won’t be able to add you as a member. Fred > Am 16.08.2019 um 17:57 schrieb Marcus Müller : > > Hi Devs, > > I have

Re: About elementary Headers and Sources

Dear Madscientist, perhaps we should start off differently. You could try to explain a bit more in detail what you try to achieve and how you think that GNUstep could help you with that task. Next you might be able to give us some details about you background, which programming languages you

Re: gnustep-back font display broken on cairo

> Am 08.08.2019 um 21:39 schrieb Fred Kiefer : > > > >> Am 04.08.2019 um 23:48 schrieb Riccardo Mottola via Gnustep-dev >> : >> >> On 8/2/19 6:06 PM, Fred Kiefer wrote: >>> I would not like to revert this change even though I agree with

Re: gnustep-back font display broken on cairo

> Am 04.08.2019 um 23:48 schrieb Riccardo Mottola via Gnustep-dev > : > > On 8/2/19 6:06 PM, Fred Kiefer wrote: >> I would not like to revert this change even though I agree with you that >> pull requests this big are bad. The overall changes here are good and

Re: gnustep-back font display broken on cairo

I would not like to revert this change even though I agree with you that pull requests this big are bad. The overall changes here are good and in most cases we see no issues with them. As for your specific setting, did you try to run with the property "GSFontHinting" set to the value 17? This

Re: Gorm is broken for some reason...

events in an archive. Pleas give this workaround a try, Fred > Am 24.07.2019 um 12:44 schrieb Gregory Casamento : > > Thanks Fred. I also may do some investigation myself. I may not be > available for a couple of days. > > On Wed, Jul 24, 2019 at 02:38 Fred Kiefer w

Re: Gorm is broken for some reason...

> Am 23.07.2019 um 16:08 schrieb Gregory Casamento : > > I have tried editing classes and adding an NSSlider and connecting it with an > NSTextField and it is, for some reason, not working properly. Also when > selecting objects the classes do not appear correctly or at all. I am going >

Re: PCButton - tracking rect

> Am 22.05.2019 um 08:53 schrieb Riccardo Mottola : > > Sergii Stoian wrote: >> I've wrote tooltips for ProjectCenter PCButton's implementation. After that >> someone has copied this implementation into NSView. >> I looked into ProjectCenter sources long time ago. I was convinced that >>

Re: libobjc2 updates

Very impressive list of improvements. Thank you very much David! > Am 31.03.2019 um 13:58 schrieb David Chisnall : > > Hello the list, > > A kind volunteer gave me access to a BeagleBone Black running FreeBSD, so I > have now been able to test the runtime with ARM (AArch32) and fixed a few >

Re: Commit process to source tree on github

port of font packages (.nfont). > I want to polish UI: some elements draw lines as gray instead of black (I > know about half-pixel problem). > I'd like to test and enhance NSBrowser behavior. I want to implement display > resolution changes adoption at backend level. May high DPI some

Re: Commit process to source tree on github

Hi Sergii, having a pull request to review and approve is always the nicer way to work with patches. But if this is too much hassle for you feel free to do a direct commit or even to send a patch file to the mailing list. Which area are you planing to work on? Cheers, Fred On the road Am

Re: Cutting a release?

> Am 02.01.2019 um 17:48 schrieb Ivan Vučica : > > In the meantime, if maintainers could help me out by updating the > non-autogenerated news entries and such, that'd help a lot. Crawling > through the ChangeLogs and VCS logs takes a lot of the time when > cutting a release I could better spend

Re: Cutting a release?

> Am 01.01.2019 um 12:44 schrieb Ivan Vučica : > > Hi maintainers, > > If you want, I can spend some time cutting a release. It has been a while > since the last one. Do we need a one? Are there critical bugs we fixed? Are > there critical bugs blocking the release? There weren’t that many

Re: libs-base fails to compile on OpenBSD

> Am 18.12.2018 um 00:55 schrieb Riccardo Mottola : > Wolfgang Lux wrote: >> To be honest, no. The runtime.c file unconditionally includes objc-api.h, so >> it's obviously not supposed to compiled with a compiler that lacks the >> objc-api.h header file. So it doesn't really matter if the

Re: libs-quartzcore won't build

I think you are correct here. Could you please fix this yourself? I am still travelling and won’t be able to do it until next week. Fred Unterwegs > Am 09.06.2018 um 07:17 schrieb Stjepan Brkić : > > Hello all, > > Couple of days ago I started getting errors while running make in >

Away for a week

Starting today I will be away for a bit more than a week. I will have internet connection but no computer to do actual work. As Richard is also travelling others may have to stand in if urgent support tasks show up. Cheers Fred ___ Gnustep-dev mailing

Re: CA broken; how do I differentiate NSValues for size and point?

Sorry, you seem to be using an unusual mail format that my Apple Mail isn’t able to properly reply to. > Am 27.05.2018 um 21:17 schrieb Ivan Vučica <i...@vucica.net>: > On Sun, May 27, 2018 at 7:47 PM Fred Kiefer <fredkie...@gmx.de> wrote: > I was already fully aware of

Re: CA broken; how do I differentiate NSValues for size and point?

20: > > NSPoint point = {.x = 16.0, .y = 32.0}; > NSValue *pointV = [NSValue valueWithPoint: point]; > > result = !strcmp(@encode(NSPoint), [pointV objCType]); > PASS(result, "@encoding(NSPoint) == pointV objCType"); > > result = strcmp(@encode(NSSi

Re: CA broken; how do I differentiate NSValues for size and point?

um 16:02 schrieb Fred Kiefer <fredkie...@gmx.de>: > > I spend some time to understand this issue. But to be honest it took me more > time to understand why this ever worked :-) > > The problem here is that base uses two different ways to provide concrete > subclasses for

Re: CA broken; how do I differentiate NSValues for size and point?

I spend some time to understand this issue. But to be honest it took me more time to understand why this ever worked :-) The problem here is that base uses two different ways to provide concrete subclasses for NSValue. One being GSValue, which supports generic data and the other mechanism is

Re: New ABI NSConstantString

> Am 08.04.2018 um 16:11 schrieb David Chisnall : > > On 8 Apr 2018, at 12:41, David Chisnall wrote: >> >> On 8 Apr 2018, at 10:55, Richard Frith-Macdonald >> wrote: >>> >>> >>> On 6 Apr

Re: GSUnicodeString and NSString disagree on rangeOfComposedCharacterSequenceAtIndex:

> Am 07.04.2018 um 20:51 schrieb David Chisnall : > > I am testing out a new version of the compiler / runtime that is producing > NSConstantString instances with UTF-16 data. I have currently disabled a lot > of the NSConstantString optimisations, on the basis of

Re: New ABI NSConstantString

Am 01.04.2018 um 11:52 schrieb David Chisnall : > > Hello the list, > > I have nearly finished the ELF version of the new Objective-C ABI. It is > able to pass the same tests that the previous one did in -base, with a > smaller binary and better reflection metadata.

Re: Segmentation Faults - OpenBSD

I tried to reproduce this error but failed. Either it is a local problem on your machine or it was already fixed. Could you please try again? Fred > Am 30.03.2018 um 00:53 schrieb Riccardo Mottola : > > Hi All, > > After updating GNUstep on OpenBSD/i386 with gcc, I

Re: GSoC candidate introduction / ideas

> Am 26.03.2018 um 10:35 schrieb Stjepan Brkić : > >> >> welcome to the GNUstep mailing list. I am you possible co-mentor if you get >> accepted to the GSoC. As the time to apply is already running out I don’t >> want to convince you of any specific task just choose

  1   2   3   4   5   6   7   8   9   10   >