from:"Johannes Brakensiek"


Hi Sergii,

thank you for your response!

On 2 Nov 2019, at 23:48, cobjective wrote:


Could you please share some details on what exactly do you plan to do?
The paragraph above sounds the same as what NEXTSPACE project is 
developed for.


I know NEXTSPACE and really like your project! My goals are somewhat 
lower currently: I’d be glad if I had some packages for GNU/Linux 
systems providing the new runtime/clang based libraries. Default Debian 
packages use gcc and I cannot ship a new app on this basis. I don’t 
like to be limited to one distribution type though, so I thought about 
using something like https://openbuildservice.org/ and/or 
https://launchpad.net/


If you would build your work for NEXTSPACE in a way like this, a big 
hurdle regarding the basic libraries would be already achieved of 
course. Providing an app would be easy and installing an app would be as 
simple as „apt install my.app“ then.


Once this is done I would like to build a package applying some nice 
icons and styling like Bertrand has created and bundled in his 
repositories.


(To test the libraries I have built I’m trying to make GWorkspace 
work. I’m doing this to get known to the environment and to check out 
whether there are bugs within GWorkspace, the libraries or my setup. 
When you have a new Workspace working once I’d like to test it as 
well.)


Johannes

Re: GWorkspace and new ABI


Hi Riccardo,

On 4 Nov 2019, at 0:45, Riccardo Mottola wrote:


Johannes Brakensiek wrote:


LIB_FREETYPE_LDFLAGS := $(shell pkg-config --libs freetype2)
LIB_FREETYPE_CFLAGS := $(shell pkg-config --cflags freetype2)


thank for the hint. I commited this fix to the repository. I hope that 
helps.


it does - thank you!


Forcing a specific linker however, is not something I will for now put 
in the official makefile. I don't know if this "ld.gold" thing is a 
fix needed generically by clang, only on OpenBSD and why it is needed.


I understand that. The linker will be provided through the environment 
vars so this is not needed at all, I think. I think the crucial fix was 
adding -lobjc for the clang flags. Maybe you could add that one to the 
repo?


Johannes

Re: GWorkspace and new ABI





On 4 Nov 2019, at 1:18, Ivan Vučica wrote:

I checked the directory instead and there's files 
there: 


Looks like there's versioning on top of versioning in that repo?


yep it is. Some forks of the same script for different distributions in 
the same repo and fork. It’s the way we do it currently. What would be 
your preferred way to do it?

Re: GWorkspace and new ABI


Hi Svetlana,

On 4 Nov 2019, at 2:30, Svetlana Tkachenko wrote:


Not sure why llvm is from external repository and not debian directly.


afaik Debian Buster provides clang 7 which is known to have bugs that 
make the build process fail (when using the new 2.0 ABI/ng). So I needed 
to get clang 8 from somewhere.



Is this script linked from the gnustep official web site?


Yep. You will find it here:
- 
http://wiki.gnustep.org/index.php/Building_GNUstep_under_Debian_FreeBSD

- http://wiki.gnustep.org/index.php/GNUstep_under_Ubuntu_Linux
- http://wiki.gnustep.org/index.php/Platform:Linux#Debian_.2F_Ubuntu


I can test it this week but not today (most likely on the weekend).


Thank you. I’m happy to read from you. It worked last time I used it. 
But as it uses sources from the dev repositories in most cases it tends 
to break sometimes.


Good luck
Johannes

Re: GWorkspace and new ABI


On 4 Nov 2019, at 6:28, Johannes Brakensiek wrote:

Thank you. I’m happy to read from you. It worked last time I used 
it. But as it uses sources from the dev repositories in most cases it 
tends to break sometimes.


Uh, forgot to mention: The latest fixes regarding PDFKit (see the other 
thread) are not included yet. You will have to change the makefile 
yourself or remove PDFKit to make it work.

Re: GWorkspace and new ABI


On 4 Nov 2019, at 7:07, Svetlana Tkachenko wrote:


I think clang-8 is in backports.
Is that better than the external repository, or it does not matter?


Thank you for that hint. Wasn’t aware of that. Yes, I think that’s 
better, because we do not have to add a repo key and it’s probably 
integrated better. I’ll change that when I have some spare time.


Is it a good idea to add a link to the script from the official 
download page?

http://www.gnustep.org/resources/sources.html


Well, I would not link it on a top level page as that script does not 
use stable releases for building. It can break any time and I do not 
have time to keep it up to date and support it for whatever period.


If we’d manage to build some stable and up to date packages (built 
with clang/runtime 2.0) for distribution package managers, it would be 
nice if those were linked, imho.


Regards,
Johannes

Re: Package building

2019-11-15 Thread Johannes Brakensiek


Hi Sergii,

On 5 Nov 2019, at 1:48, Sergii Stoian wrote:

I know NEXTSPACE and really like your project! My goals are somewhat 
lower currently: I’d be glad if I had some packages for GNU/Linux 
systems providing the new runtime/clang based libraries. Default 
Debian packages use gcc and I cannot ship a new app on this basis. I 
don’t like to be limited to one distribution type though, so I 
thought about using something like https://openbuildservice.org/ 
and/or https://launchpad.net/


Oh, now I understand what you’re talking about. I have plan to setup 
CI environment (Jenkins? Travis?).


yeah, that would be great. Maybe you would like to risk a look into 
openbuildservice? Having some installable packages built automatically 
would be great.


If you would build your work for NEXTSPACE in a way like this, a big 
hurdle regarding the basic libraries would be already achieved of 
course. Providing an app would be easy and installing an app would be 
as simple as „apt install my.app“ then.
Current state of the NEXTSPACE is somewhat special… I use particular 
(not cutting edge) versions of GNUstep libraries (gui and back) with 
custom patches. So build (or CI) process - along the NEXTSPACE part - 
should build custom GNUstep libraries. Is it fit to your goals?


Well, currently not. But as soon as you are able to use the upstream 
libs it would be of great use of course.


Once this is done I would like to build a package applying some nice 
icons and styling like Bertrand has created and bundled in his 
repositories.
NEXTSPACE contains its own fonts, icons and mouse cursors with true 
NeXTSTEP look and feel. I’m afraid it is not what you want to do.


Yeah, it’s not as well. But did you obtain the ability of GNUstep for 
using themes? That way one could use the software you wrote and create a 
friendly fork providing a different look and feel. That would allow some 
merges with the development of the Etoile project f.e. and would be a 
very nice thing, in my opinion. It seems to me this community is too 
small for having multiple desktop approaches, considering the aim one 
should be useful for everyday tasks once.



(To test the libraries I have built I’m trying to make GWorkspace 
work. I’m doing this to get known to the environment and to check 
out whether there are bugs within GWorkspace, the libraries or my 
setup. When you have a new Workspace working once I’d like to test 
it as well.)
NEXTSPACE has it’s own genuine Workspace, Window Manager, 
Preferences, Terminal and so on. It’s already working and functional 
- give it a try. :)


Sounds great. Regarding upstream compatibility see my question/thoughts 
above.


Johannes

Re: Added MISSING file to libs-gui

2019-11-15 Thread Johannes Brakensiek

Hey Greg,

On 15 Nov 2019, at 4:39, Gregory Casamento wrote:

I have done a little work to figure out which headers/classes are
missing
in libs-gui as compared to macOS10.15. Just a heads up. If anyone
would
like to take some of these on please DO. :) There are a large number
of

classes currently missing. I admit I didn't know there was such a gap
until I did the analysis.

The files are listed in the MISSING file under libs-gui.

thank you for your work and your approach to even get this work done! :)

And yes, currently you have almost no chance to port a current interface
to GNUstep. I installed three virtual macOS machines to be able to use
Xcode/IB to backport a current xib to a GNUstep compatible nib/Xcode
4-xib (which works quite well), but you have to delete many items of the
interface to be able to use it with Gorm/GNUstep.

That said if would be great of course to even have the xib support of
Gorm updated for making porting and cross platform development easier.

Maybe some sort of dev survey would be nice? Just to get an idea wich
classes are considered most needed so you know there is good cause to
start with specific ones?

That said highest priority for me would be to have tested API
compatibility concerning the existing classes (same for base). Writing a
new app or porting from GNUstep to Cocoa is much easier if we’d have a
solid base there, I think.

As a first project I just updated DictionaryReader.app to make it work
on Cocoa. It does, but the implementation/use of NSUInteger is probably
be different for Cocoa and GNUstep as my changes on this class do not
work using GNUstep:
https://github.com/Letterus/DictionaryReader/commit/368b39fa1bd81bf7482860d6b85a537d235533d8#diff-3dc9afee5b822cb486003ac0d8405667

I’m currently missing the knowledge to figure out what/where the cause
for the issue exactly lays, though.

Keep up your great work
Johannes

Re: Package building

2019-11-19 Thread Johannes Brakensiek


Hi Sergii,

thank you for your reply!

On 19 Nov 2019, at 0:39, Sergii Stoian wrote:

Frankly speaking I don’t like themes idea almost totally. It’s 
hard to achieve desired look and feel with themes without coding 
(overriding some class methods). Plus themes support bloats the 
GNUstep codebase.


I’m not into the details of the theming implementation, but to me it 
looks a GNUstep based DE would be far from being bloated compared to 
other current DEs. ;)


I understand that the initial idea was to attract more 
users/developers, but… It’s not working.


Hm, yes. I think developers don’t need a nice UI at first place (and I 
think most of what developers need luckily is already provided by Apple 
as of today). But developers need happy users (if you’re not 
developing only for yourself) and I think happy users need a stable, 
solid and consistent UX. That would be provided by a NextStep based UI 
guideline. But they also need a pretty UI (which is not what you’d 
call that NextStep look nowadays, imho).


So, I want to make ideal NEXTSTEP interface first. Who knows maybe 
some day I’ll want to change it to macOS-like… ;)


I think: Do it (some days earlier). From a users perspective my heart 
was filled with joy and happiness when I saw what Bertrand had compiled 
here: 
https://github.com/BertrandDekoninck/rik.theme/blob/master/newscreen.png 
;)


If we’d have some more screenshots of well crafted software looking 
like this, it would be a huge benefit regarding the public impression of 
GNUstep. It doesn’t need to be macOS, but to have a free DE that’s 
getting close regarding UX/UI would be a thing I’d really like to see 
and work with. (Especially since Apple is currently driving the 
development of macOS to a state where I won’t want to use it 
anymore…)


Etoile is great effort to create macOS-like DE with great fundamental 
frameworks inside. I wish to borrow some  of them someday… But its 
development stopped AFAIK.


Yes, sadly. Merge it, use it. Once I come to start writing a serious app 
I’ll give CoreObject a try and see how it works. ;)


Keep up your good work
Johannes

Re: Package building

2019-11-19 Thread Johannes Brakensiek


Hey everyone,

thank you, reads very well. :)

To sum it up, some whishful thinking:

1. Integrate apps on a short-term basis. (Updated) themes for Gtk, Qt, 
keyboard shortcuts, support for drag ’n drop per default (!). (It 
works, look at Josh’s PikoPixel.)
2. Release early, release often. Have package repos that are 
continuously updated and are installable.
3. Continue making a decent looking DE work for everyday tasks (I think 
it’s for the long run, but I’d still highly appreciate one).


I hope I’ll be able to have a try on 2 for Ubuntu/Debian, but not 
before the end of the year.


Johannes

Re: Package building

2019-11-20 Thread Johannes Brakensiek


Hey Ivan,

thank you for your work and your explanations!

On 20 Nov 2019, at 3:10, Ivan Vučica wrote:

Now... developers may need updated versions when developing their 
apps. I remember Debian not shipping with NSViewController or 
NSWindowController when I first came around -- but on the other hand, 
when I would cut a release, an updated .deb would follow. (Not to 
mention our source code became much more discoverable, so seeing if a 
class is missing is much easier too.)


So when a developer needs a newer version so they can prepare a source 
tarball for Debian to integrate... they can talk to us. We cut our 
release, a Debian maintainer (e.g. Yavor) picks it up, the app gets 
picked up too, everyone happy.


Yes, I would say developers are very welcome to advocate with 
maintainers for a release if not cutting one blocks their app's 
release. :-)


And at this time, I am still here to help component maintainers with a 
release. I may not do it on a tight schedule, but eventually I’ll 
find an evening or two to tackle this kind of request.


Do you have a specific anecdote about something you wanted up to date, 
as a binary, which wasn’t in your favorite distro?


The problem simply is that f.e. Debian ships libs that are build with 
GCC and thus are missing any of the new language features. I understand 
you are doing this for compatibility with other processor platforms. But 
this leads to the problem that any app developer who wants to build a 
new app based upon the clang ABI has to build and ship everything on his 
own. I really think this is a show blocker for attracting new developers 
(or even users). Or did I miss anything here?


Johannes

Re: Package building

2019-11-20 Thread Johannes Brakensiek





On 20 Nov 2019, at 11:56, Ivan Vučica wrote:

I think that, when you say “you are doing this”, you also miss the 
part where I am not a Debian developer and do not build the Debian 
source+binary packages that are shipped in Debian :-)


Yes, I’m sorry. I’ve been in contact about this issue with Yavor 
Doganov, not with you. :) He was the one who told me about sticking to 
GCC because of the architectures Debian supports/wants to support.

Re: Package building

2019-11-20 Thread Johannes Brakensiek





On 19 Nov 2019, at 13:16, James Carthew wrote:

I've been toying with NextSpace in a VM. From my experience, if this 
gains a web browser and network settings panel (mostly for Wifi 
config), (and gets Debian packages) it could easily replace Mate on my 
machines. Linux desktop application development is terrible at the 
moment.


+1

GNUstep may not be the right answer for me, but I'm open to at least 
exploring it. NSMacintoshMenuStyle works in NextSpace, and I had 
Rik.theme built/working properly.


That’s promising to hear. I’m very interested in trying this out on 
Debian/Ubuntu!


I was hoping to get Etoile WildMenus running as well but ran out of 
time.


Would be very interesting.

NextSpace is definitely moving in the right direction. I think the 
focus on System settings is definitely the way to go. As someone who 
would like to get a mac-like desktop out of this eventually I'd like 
to see some of the options ported into SystemPreferences.app just 
because it's a more mac-like application.


Full ack.

But I like how NextSpace has the look/feel of NextStep, definitely 
keep it up. I know the ideal would be to port webkit to gnustep but at 
this point I'd be happy to just throw firefox into a gnustep window 
with an application menu.


+1

So I’m very much supporting Sergii in his approach. If his 
developments are going to be compatible with GNUstep upstream, I’d 
love to have/get this packaged and installable for my distribution of 
choice (Debian/Ubuntu) to recommend it to regular users.


Johannes

Re: Which ObjC2.0 features are missing in the latest GCC?

2019-11-23 Thread Johannes Brakensiek




On 24 Nov 2019, at 2:24, Yavor Doganov wrote:


Ivan Vučica wrote:

On Fri, Nov 22, 2019 at 8:02 PM Yavor Doganov  wrote:

The answer is simple: because there's a lot to lose and nothing to
gain.



This is unfortunately wrong. There is a lot to gain.


Right or wrong depends on the point of view, which ultimtately boils
down to one's values and beliefs.  What is gain for some may be loss
for others.  It appears we have different values, hence the
discrepancy.


Developers who want to start using Debian-built GNUstep libraries
can start using tons and tons of features that GCC and GCC runtime
do not support.


Developers who want to start using these new (not so new -- 10 years
old!) features have the option to build the environment they need on
top of Debian (if that is their distro of choice) or switch to another
distro that provides prebuilt packages.

But that is the wrong answer.

You, developers, tend to forget that free software is for users.
Developers are users too in a broad sense but they are a very small
part of the whole mass of people using a particular piece of software.
If these fancy features existed for 10 years, why they have not
inclined developers to write more free software that is relying on
them?  Surely that's not because Debian stopped them?  Or because the
GNUstep project is stopping them?

My task as a free software contributor (with the extremely limited
skills I have) is to help achieve the goals of the Free Software
Movement.  Providing "tons and tons of features" to developers who
don't care at all about free software (at least the majority of them)
and who won't write a single line of code for the cause I'm aligned to
doesn't strike me as the "right" thing to do.

I don't mind helping them as a side effect of helping free software.
In this case, however, it is all about them.


- ARC is one.
- Blocks is another.
- @123 syntax for NSNumber (and similar stuff for arrays and dicts 
and

more) is another.
- Improved @property support is yet another.


This is like offering rocket fuel to someone who has a car with a
diesel engine.  None of the packages in Debian is using these
features, which is why I said there's nothing to win.  There's a queue
of software packages we intend to package in Debian but neither of
them depends on these things -- except probably the Rik theme and
NEXTSPACE (which are not suitable for packaging for other reasons).

Right now I'm working on a new upstream release of a package which
uses NSNotificationCener-addObserverForName:object:queue:usingBlock:.
This is a method which is declared and supposed to be supported even
with GCC, I just don't know the (GCC) syntax I'm supposed to use so
I'm experimenting with GCC nested functions as replacement.  If that
fails, I guess I'll solve it somehow, using a different approach.
That's the first case I face ever -- I've seen methods using blocks in
upstream code before but they were no-op anyway as there was no
GNUstep implementation.  On the contrary, there are tons of
block-unrelated things which are not implemented, especially in GUI.

The biggest hurdle with porting apps IMVHO is missing functionality
and dependency on Core* stuff and other libraries with no free
implementation.  The switch to Clang is not going to solve these
problems.  The only thing it solves is making the life of developers
of properiatary software easy.  That is not my goal.


But I'd say that Debian's packaging of GNUstep is very important and
even if the core doesn't start depending on these features, they
should be made available.


I don't know why Debian is important, but they cannot be made
available as an option.  It would mean duplicate packages with
different names -- the release team will not allow it and the
ftpmasters will not allow it.

You probably weren't around when we (GNUstep people in Debian) had to
scrap and fight to prevent it from being removed.  GNUstep in Debian
back then was undermaintained and violated the FHS, it was also full
of bugs (that is, obvious bugs such as frequent failures to build from
source) and blatant bugs solely due to packaging.  Hubert wrote a tool
to FHS-ify most of the packages, we fixed most bugs and we had a
helping hand from the Debian GCC maintainers who said it would be very
worthwile to keep GNUstep in Debian, at least as a testing ground for
GCC.

And that's what it's been, more or less; GNUstep had a rapid decline
in the user base some years ago and it appears it is not going to
recover.  All the Clangs in the world are not going to help you with
that.  But in your quest for popularity you may lose some of the solid
foundations that are still keeping this project afloat.

What's lost is builds on some architectures. Can't those 
architectures

keep using GCC-targeting libraries or be actively disabled?


No.  Packages which no longer build for a particular architecture must
be removed manually by the ftpmasters, after a request is filed.  If
the architecture is official (meaning

Re: Which ObjC2.0 features are missing in the latest GCC?

2019-11-24 Thread Johannes Brakensiek




On 24 Nov 2019, at 10:11, Max Chan wrote:

I would like to add another plus for dropping GCC: if we want any hope 
for Swift interworking, we have to use clang as the compiler.


Apple have no plan to provide any GUI support on Linux version of 
Swift. If we have Swift interworking, even though we may have to drop 
our own libobjc, Foundation and CoreFoundation in favor of Apple’s 
release, the GNUStep GUI package can provide the replacement AppKit 
that Apple’s Swift release lacked.


I don’t know anything about Swift and it’s not AppKit, but maybe you 
already recognized there now is:


- https://github.com/Cosmo/OpenSwiftUI
- https://github.com/SwiftWebUI/SwiftWebUI

Re: Which ObjC2.0 features are missing in the latest GCC?

2019-11-24 Thread Johannes Brakensiek


On 24 Nov 2019, at 14:16, Yavor Doganov wrote:


Packaging libraries and development tools just because they are cool
and it is expected that hordes of developers will write useful
programs that utilize them is not a useful activity -- you have to
justify their inclusion in the distro and a hypothetical future
benefit is not a good argument.


Well, I think different about this (otherwise Apple f.e. would never 
have shipped any new software I think), but we can agree to disagree 
here.



If you don’t provide new tools for developers they are not going to
build new software for their users. It’s this way around not the
other and it’s no dilemma at all.



So you are basically saying that just because Debian does not provide
the right tools there is no software written yet?  Sorry to say that
but it's a ridiculous statement.


Well, I’m ok with that. They call me Mr. Ridiculous at times. And of 
course it is not because of Debian. It is a GNUstep and 
distribution/packaging thing.


Let me just tell you some things I did and let’s see what sounds that 
ridiculous to you:


Under Debian I typed apt-get install kdevelop and was provided a nice 
IDE and quite up-to-date tools to write and compile KDE/Qt software.


Somewhat later I typed apt-get install gnome-builder and I was provided 
a quite nice IDE and quite up-to-date tools to write and compile 
Gnome/GTK+ software.


I also typed apt-get install gnustep-devel and I was provided an IDE 
that looked like it jumped out of the 90s. I thought: Oh, not that bad, 
I can use Xcode and compile then. But I could not because the tools 
installed were not able to compile f.e. Rik.theme or .m files using 
recent language features.


I still liked the idea of GNUstep and luckily there were some nice 
people like Andreas Fink and Patryk Laurent who provided me their build 
instructions and scripts to help me building the new runtime. As a 
newbie it took me several weeks of my spare time and some mails to get a 
working build environment before I could start with developing at all. 
There were no public available build instructions or build scripts for 
Debian that worked at that time (I changed that).


Later this year I recognized that a working build environment is of no 
use at all if nobody is distributing that environment to my users. That 
was when I decided to leave Debian und use Ubuntu, because for users it 
would be way easier to install a PPA (that I could create) than to add 
an extra deb repository. Luckily some work was already done on 
https://launchpad.net/gnustep by Thomas Karl Pietrowski.


So, please tell me which part of this story sounds most ridiculous to 
you?




For me this cause is indeed a decision whether you are most
comfortable with the state in which GNUstep currently is or if you
would be more comfortable when it would develop to a further state,
maybe one where most ObjC currently is. If you want it to develop the
decision should be simple.



This is a bogus argument, GNUstep supports these new features and
developers who want to use them can do so.  Debian cannot stop them.


That’s true. It takes some efforts though. I think that’s a pity.




- https://github.com/64characters/Telephone
- https://github.com/subethaedit/SubEthaEdit
- http://colloquy.info/
- https://github.com/rburgst/time-tracker-mac



Are these projects directly buildable/runnable with GNUstep configured
for Clang and the modern runtime?  I doubt it.


No, of course they are not. But they could some day if the GNUstep 
project would decide and be able to develop some way further. That’s 
my point.


Johannes

Re: Which ObjC2.0 features are missing in the latest GCC?

2019-11-24 Thread Johannes Brakensiek

Am 24.11.19 um 20:08 schrieb Bertrand Dekoninck:

> Just my two pence here : I’ve got a gcc compatible branch of rik (which I 
> maintain for my ppc computers) at 
> https://github.com/BertrandDekoninck/rik.theme/tree/no_objc2
> The only thing I had to do was to remove the button animation code which uses 
> objc_setAssociatedObject.

Thank you, that's good to know. To be true: Rik.theme won't compile
using the 2.0 runtime as well. I think it accesses private ivars which
is not allowed using the new ABI. But I don't know how to work around
this yet.

Johannes

Re: Which ObjC2.0 features are missing in the latest GCC?

2019-11-25 Thread Johannes Brakensiek


Hi Yavor,

On 25 Nov 2019, at 14:34, Yavor Doganov wrote:


Off the top of my head, Rik theme is about the single piece of
software that can't be built on stock Debian because of us sticking to
GCC.  NEXTSPACE relies on custom patches to GNUstep core, which means
that you'll have to build your own GNUstep environment anyway so you
may as well configure it for Clang and the new runtime.


thank you for making clear your point. I understood GNUstep would have 
to provide an updated runtime for all supported architectures and 
upstream software/applications that rely on clang and its features to 
make the Debian maintainers distribute it.


It’s good to know what to do now. ;)

Johannes

Re: Which ObjC2.0 features are missing in the latest GCC?

2019-11-25 Thread Johannes Brakensiek

Am 25.11.2019 um 16:31 schrieb Yavor Doganov :
> 
> Johannes Brakensiek wrote:
>>> On 25 Nov 2019, at 14:34, Yavor Doganov wrote:
>>> Off the top of my head, Rik theme is about the single piece of
>>> software that can't be built on stock Debian because of us
>>> sticking to GCC.
>> 
>> thank you for making clear your point. I understood GNUstep would
>> have to provide an updated runtime for all supported architectures
>> and upstream software/applications that rely on clang and its
>> features to make the Debian maintainers distribute it.
> 
> No, that was not my point and nowhere near to what I said.  Debian
> will consider moving to Clang and the new runtime when:
> 
> 1. The pool of new software is large and worthy enough to justify the
>   major regression that is dropping support for about half of the
>   architectures.  It means there has to be much more than Rik that we
>   can't build and package now.  And it appears Rik is buildable with
>   GCC, albeit a less capable version.  So it's not even a proper
>   example.
> 
> 2. The release team approves building an entire software stack with a
>   non-default compiler and as a direct consequence dropping
>   architecure support.
> 
> 3. There is someone willing to do the actual work and carry out such
>   transition.  That's always the case in Debian for any kind of work.
> 
> If GNUstep upstream drops GCC support, 1) will become pointless but 2)
> and 3) remain.
> 
> If GNUstep upstream continues GCC support and the condition outlined
> in 1) does not change, we'll stick to GCC.  We will not move just
> because of some blurry promise for great new software.  I've seen this
> before and it's nothing more than a wet dream.

That‘s what I meant.
+ if clang/the gnustep runtime would support all major architectures there 
would be no regression at all. So that‘s what should be worked on.

Johannes

Re: libobjc2 build issue

2019-11-26 Thread Johannes Brakensiek




On 26 Nov 2019, at 20:36, Andreas Fink wrote:

Today I tried to build libobjc2 again as I  did many time before and I 
get this missing file:



gnustep/libobjc2/arc.mm:6:10: fatal error: 
'third_party/robin-map/include/tsl/robin_map.h' file not found



anyone having a clue what dependency this is?


It seems libobjc2 now has git modules which you need to get. The needed 
lines are included here:


https://github.com/plaurent/gnustep-build/blob/039478042e725a98662a4e60d9fb60c200e8fc53/ubuntu-19.04-clang-8.0-runtime-2.0/GNUstep-buildon-ubuntu1904.sh#L59

Re: libobjc2 build issue





On 27 Nov 2019, at 9:37, Fred Kiefer wrote:

Thank you for updating this instruction file. Is there a link to this 
in the GNUstep wiki? I understand that we should make it as easy as 
possible for new (and experienced) programmers to grab the correct 
instructions the first time.
For me this reoccurring build issues are one of the reasons why I do 
not use clang and the new runtime. They both develop too fast for me. 
It is quite normal that things change and from time to time they are 
even broken. If I remember correctly most of the questions on the 
development mailing list in recent years where caused by this. I 
prefer to spend my little time on GNUstep itself and not on fixing the 
build infrastructure. (Resulting in a less than optimal GNUstep 
environment for me.) What we need to do is minimise the pain for 
people who choose the other way.


Yep, I agree. That’s why we are working on these scripts and on CI 
tools to make sure they work (at least as long as we are able to 
maintain these scripts). On midterm we’d like to have continuously 
updated (Ubuntu) packages to make it even easier. Patryk already worked 
closer to that goal as he managed to build a big install .deb.


The textual instructions from Andreas Fink are published here:
http://wiki.gnustep.org/index.php/Building_GNUstep_under_Debian_FreeBSD

The script repo is linked multiple times, f.e. here:
http://wiki.gnustep.org/index.php/Platform:Linux#Install_from_source

Johannes

Re: Which ObjC2.0 features are missing in the latest GCC?



On 26 Nov 2019, at 23:43, Fred Kiefer wrote:

That could be said about all backward-compatibility. A follow up 
question
is, does it hold us back enough to justify breaking compatibility? 
It seems
some people think yes, and others think no. We're at a stalemate, 
where no
progress can be expected to take place. For things to move forward, 
either
one side has to give in, or both sides can compromise and agree to a 
middle

ground.




You described the dilemma very well. (And I also want to thank David 
and Ivan to their excellent contributions to this thread.) Some people 
are very conservative in this group. But others have a bit too much 
wishful thinking. I myself would not mind too much loosing gcc but 
loosing active developers and packagers. Sadly for some this doesn’t 
seem to be an argument.


I think for those who have to do the decision (who’s that anyways, the 
active contributors?) this probably will be good reason („argument“ 
;)) as this is a community of people working non-profit who seem to have 
strong feelings regarding some options.


What I want to tell (being quite new to this community and not having 
these strong bindings) is there are some reasons that are mainly 
considered outside of this mailing list which should be important here 
as well, imho.


To name a few (just referring to what I’ve read, not meant as a 
personal insult at all):


- the GNUstep project is largely considered dead
- the only bigger free software project relying on GNUstep which seems 
to be of greater relevance and extension is SOGo, which relies on 
Foundation and GNUstep web, but not on AppKit (any of the devs active 
here?)
- German companies that used GNUstep told me they already switched to 
using Foundation and GNUsteb web only as users did not accept the AppKit 
interface anymore


So, if people like the SOGo devs would say they need GCC because they 
are relying on it and Foundation/GNUstep web, I’d say it would be a 
very reasonable decision to keep Foundation and GNUstep web compatible 
to GCC.


But if there are no bigger projects depending on a GCC AppKit it should 
be a first class aim of the project to develop it to a state that others 
would consider picking it up and using it for their projects - imo. Yes, 
that’s investing into future and it comes at the cost and risk of not 
being successful, of course. But please bear in mind that probably there 
are a lot more devs (here just being a few of them trying to give them a 
voice) that evaluate which platform to use for their apps and probably 
pass by and choose Qt or a web based platform.


I think that’s a pity as GNUstep AppKit could be highly attractive for 
Cocoa ObjC devs wanting to port their apps to Linux and a free 
environment (and maybe don’t want switch to Swift yet). If you don’t 
want that target audience it’s your decision, but I’d be interested 
to know who’s your target audience then? Of course you can do it just 
for yourself, but I think it’s unlikely others will join then.


Johannes

Re: Which ObjC2.0 features are missing in the latest GCC?


Gregory,

I’m leaving out your replies as it seems you did not get me right. 
First I was trying to strengthen your approach by reflecting the public 
opinion about GNUstep as far as I recognized it. Of course it is not 
fully true and of course I did not write and speak with everyone or did 
scientific research.


Second I was proposing a compromise of keeping base compatible to GCC 
and only update AppKit to the new runtime. But as you already wrote this 
does not seem to be sufficient.


If there are bigger free software projects using AppKit I’d be 
interested to know, btw.


The proposal of forking GNUstep and running two forks seems too much 
work to me and probably you won’t be able to port back what you’ve 
achieved using clang. So to me it seems you just have to decide if you 
start doing GNUstep 2.0 (breaking compatibility for new features, but 
keeping compatibility for older features of course - using clang you can 
compile everything you can with gcc, don’t you?). I don’t see a way 
of a compromise or middle ground.


Johannes

Re: libobjc2 build issue




On 27 Nov 2019, at 12:29, David Chisnall wrote:

I am no longer actively working on Foundation or AppKit, so I 
shouldn't get much of a say in what those projects do, but if GNUstep 
is going to be tested with only GCC then my advice would be:


 - Actively market GNUstep as only an OpenStep implementation, drop 
all Cocoa references.


 - Drop support for Clang.

Currently, the project is setting itself up to fail by advertising 
features that no one tests.


Ok, this is the third thread on this topic but I can only support it 
from a user’s and newbie’s perspective. It was quite disappointing 
when I discovered that this Cocoa compatibility thing is very limited 
taking into account the current feature set of Cocoa.


Thinking about it a while and seeing Sergii’s Nextspace project one 
could consider you can build a fully functional desktop experience using 
the OpenStep API.


So it might be a less overambitious goal to polish the existing API, 
keeping GCC compatibility and thus preventing a fork of the community. 
(The clang people might distribute their ARC enabled apps as they are 
trying currently and thus testing and improving clang runtime quality. 
I’d like to do that.)


Even using a GCC compatible API/libs there are many things that could be 
improved to target a wider user audience:


1. Polish the look and feel of AppKit and make it integrate well with 
current GTK themes (same for Gorm).

2. Work on the integration of ObjC with f.e. gnome-builder.
3. Upgrade xib integration to work with interfaces created with recent 
Xcode releases.
4. Provide a plugin for Xcode that warns the user when he uses classes 
or API calls that are not part of the OpenStep API or implemented 
GNUstep API so that cross platform developing and porting apps becomes 
more easy.


Some unfinished thoughts…

The clang/ng runtime environment distribution keeps important to me, 
though.


Johannes

Re: Improving GNUstep tooling with Clang

2019-11-29 Thread Johannes Brakensiek




On 29 Nov 2019, at 11:43, Frederik Seiffert wrote:

Am 28.11.2019 um 22:06 schrieb Niels Grewe 
:


On 28.11.19 17:15, Frederik Seiffert wrote:
- Set up CI testing for the 2.0 runtime version, which currently 
doesn’t seem to be tested with libs-base.
I have submitted a pull request for this 
(https://github.com/gnustep/libs-base/pull/88).


Thanks to the work of Patryk we have a working build setup with CI here 
now: https://github.com/plaurent/gnustep-build/


Would it be helpful to you if we’d run the tests on the runtime as 
well?


Unfortunately, when I tried to integrate that into my libdispatch 
stuff,

I discovered that this doesn't actually test the 2.0 runtime. The CI
script is still using a Ubuntu 14.04 builder, which ships with a 
clang

version that is too old to know about the 2.0 runtime version
(defaulting to something else, presumably). Once run under 18.04 
(baby
steps…), with clang 7, we're getting failures in the configure 
script
because the new objc_init struct references non-existent sections in 
the

binary (those conftest things don't declare any classes and such).


Oh, good catch! How did you find out that the Clang version didn’t 
support the 2.0 runtime? Is there a warning or similar that I can 
watch out for in the future?



Upgrading to clang 9 fixes that, but now I'm seeing a load of test
failures that I haven't had the time to investigate further:

https://travis-ci.org/gnustep/libs-base/builds/618352009


The output there looks as if you are still using clang 7?

Ok wow – to be honest, based on our experience with the 2.0 runtime, 
I was kind of surprised when all the tests were previously passing. It 
sounds like something fundamental is broken here though and you’re 
onto it (https://github.com/gnustep/libobjc2/issues/136). Let me know 
if I can give a hand with this in any way.


I don’t know if there is anything fundamental broken, but clang 7 is 
known to not work with the 2.0 runtime as well as the lld linker (you 
have to use ld.gold). Did you notice Andreas’ paper describing this?


http://wiki.gnustep.org/index.php/Building_GNUstep_under_Debian_FreeBSD

His (and our) build experiences have been collected at the scripts 
mentioned at the repository above.


Johannes

Re: Improving GNUstep tooling with Clang

2019-11-30 Thread Johannes Brakensiek


Hi Frederik,

On 30 Nov 2019, at 16:06, Frederik Seiffert wrote:

I think ideally these things should be "figured out" by GNUstep make 
configure, something like:


If Clang version is at least 9 (?) and libobjc2 is detected:


afaik you need clang at least at version 8 to make the 2.0 runtime work 
and any other version (down to 3.x?) to work using the 1.x runtime and 
in order to enable the new ABI supporting ARC, blocks and libdispatch.



=> select ng-gnu-gnu library combo

=> select gnustep-2.0 runtime

=> enable ARC
=> enable native ObjC exceptions

=> add -fuse-ld=gold to linker flags

Would that make sense? 


Hm, maybe anybody having some insights into the internals of GNUstep 
make and these build processes is able to answer this?


Currently I just know it seems necessary to install gnustep make before 
the start of any building (f.e. of the runtime), at least that’s what 
we are doing. As long as this is necessary you cannot do any auto 
detection. But I think it would already be very helpful if the right 
settings and env variables would be chosen and set for you, f.e. by just 
providing a single config parameter.


Johannes

Re: Added MISSING file to libs-gui

2019-12-01 Thread Johannes Brakensiek

Hi Greg,

thank you for your kind reply and your plans on development! Sounds
great to me.

On 1 Dec 2019, at 14:03, Gregory Casamento wrote:

And yes, currently you have almost no chance to port a current
interface

to GNUstep.

Not true. There are a few current apps which are on GNUstep by
companies

which reach thousands of users.

But how do they do it? I meant the user interface (xib/nib files) where
I only see the way of either develop .gorm and .xib files in parallel or
to use an old version of Interface Builder (<= Xcode 4) to be able to
load it using Gorm/GNUstep. Did I miss anything?

As a first project I just updated DictionaryReader.app to make it
work
on Cocoa. It does, but the implementation/use of NSUInteger is
probably

be different for Cocoa and GNUstep as my changes on this class do not
work using GNUstep:

https://github.com/Letterus/DictionaryReader/commit/368b39fa1bd81bf7482860d6b85a537d235533d8#diff-3dc9afee5b822cb486003ac0d8405667

I'll take a look at it.

I’m currently missing the knowledge to figure out what/where the
cause

for the issue exactly lays, though.

I'll provide some feedback and or see if I can't fix what's blocking
you.

Thank you. Fred already helped me with it and it seemed the first issue
was that I didn’t change all declarations of int to NSInteger so I did
not have full 64 bit compatibility (which Xcode/Cocoa somehow tweaked to
make it work, but GNUstep did not).

The second apparently was that one of the .gorm files was broken
regarding the colors which are to be set by the themes. I refreshed the
.gorm file from the .nib file and it works now. I just seems that I have
to redo it a bit because the .nib file seemed to contain selectors of
Cocoa AppKit methods which slightly differ compared to the
implementation of GNUstep (I already mentioned these difficulties in my
mail before).

Sorry for being so busy... I would have gotten back to you sooner.

Don’t mind, thank you for your reply nonetheless
Johannes

Re: ProjectCenter running or building

2019-12-30 Thread Johannes Brakensiek


Hello everyone,

On 30 Dec 2019, at 9:23, Fred Kiefer wrote:


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.


I can confirm this issue using the 2.0 runtime. LogPanel is not loaded. 
I don’t know if it is the same issue, but the inspectors of GWorkspace 
(being bundles as well I think) do not work using 2.0 runtime as well.


Johannes

Re: ProjectCenter running or building

2020-01-05 Thread Johannes Brakensiek




On 5 Jan 2020, at 12:50, David Chisnall wrote:

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.



There is a bug in BFD LD.  Things that use ld -r in some situations (I 
have not been able to find a minimal test case, but base additions is 
one) have things stripped too early and so all of the Objective-C 
classes are removed.


I’m quite sure that I linked everything using ld.gold. Same issue.

Johannes

Re: ProjectCenter running or building

2020-01-06 Thread Johannes Brakensiek

Hi Riccardo,

On 6 Jan 2020, at 10:26, Riccaro Mottola wrote:

I can confirm this issue using the 2.0 runtime. LogPanel is not
loaded. I
don’t know if it is the same issue, but the inspectors of
GWorkspace (being

bundles as well I think) do not work using 2.0 runtime as well.

Just for information. On my OpenBSD setup I am running now clang +
liobjc2 (latest git) and of course ng-gnu-gnu.

I do not have issues with ProjectCenter, it loads the log panel fine.
Also GWorkspace loads inspector bundles correctly and I can view PDF
files fine (which is the most critical of the content inspector,
PDFKit having a C++ Bridge).

PDFKit is latest SVN head and currently in "test".

thank you for getting into this. It might be Patryk already asked the
right questions. Because if you use the standard setup of GNUstep make
and/or the libobjc2 v1.8 release tarball it is quite likey that you set
up the older „ng“ GNUstep runtime versioned 1.x.

So regarding your list of possible setups it should look be a little bit
extended regarding options 4a and 4b afaik:

4a) clang + libobjc2 and make configured ng-gnu-gnu and set
RUNTIME_VERSION=gnustep-1.9 (or 1.x). This one will build using older
version of clang and is known to work with various linkers.

You’ll find a reference setup here:
https://github.com/plaurent/gnustep-build/blob/master/ubuntu-16.04-clang-6.0-runtime-1.9/GNUstep-buildon-ubuntu1604.sh
(note clang 6 and RUNTIME_VERSION. We even did a checkout of the 1.9 tag
even though I don’t know if this is necessary.)

4b) clang + libobjc and make configured ng-gnu-gnu, using master from
GitHub and RUNTIME_VERSION=gnustep-2.0. This one is the new and cleaner
version of the ng runtime David wrote at the end of 2018. Afaik it will
only build and run using clang >= 8 and it will not run when linked
using bdf or lld.

You’ll find a reference setup here:
https://github.com/plaurent/gnustep-build/blob/master/ubuntu-19.04-clang-8.0-runtime-2.0/GNUstep-buildon-ubuntu1904.sh
(note clang 8, RUNTIME_VERSION and the use of ld.gold).

If I use setup 4a everything works without issues. The issues Patryk and
I were talking about appear using setup 4b.

Maybe you can check your setup against these instruction and see if you
can reproduce our setup/issues?

Thank you and good luck
Johannes

Re: rdynamic? Re: ProjectCenter running or building

2020-01-19 Thread Johannes Brakensiek


Hi Patryk, hi everyone,

I don't know if this is of any use for anyone, but let's try:

Am 18.01.20 um 02:08 schrieb Patryk Laurent:


On Jan 13, 2020, at 01:24, David Chisnall  wrote:

-rdynamic is fine.  This means put all symbols on the dynamic symbol table.  
The problem is -r, which means do a partial link.  Some linkers do too much of 
one and prevent the final link from correctly placing everything in the correct 
sections.


In the below compile likes there is no -r while ProjectCenter is being built... 
so can anyone think of any other reason for the ProjectCenter failures and how 
to fix them?


I set a breakpoint at [NSBundle loadNibNamed:owner:].

This is what I get when when I start ProjectCenter when it comes to the 
LogPanel gorm file:


Breakpoint 1, +[NSBundle(NSBundleAdditions) loadNibNamed:owner:] (
self=0x77a02700 <._OBJC_CLASS_NSBundle>,
_cmd=0x77fc2ee8 <.objc_selector_loadNibNamed:owner:_C320:81624>,
aNibName=0x99bf3d0c3bb2ec44, owner=0xd21068) at NSBundleAdditions.m:65
65if (owner == nil || aNibName == nil)
(gdb) po owner

(gdb) s
69table = [NSDictionary dictionaryWithObject: owner forKey: NSNibOwner];
(gdb) s
83bundle = [self bundleForClass: [owner class]];
(gdb) s
84if (bundle != nil && [bundle loadNibFile: aNibName
(gdb) po aNibName
Cannot access memory at address 0x99bf3d0c3bb2ec44
(gdb) s
86withZone: [owner zone]] == YES)
(gdb) s
84if (bundle != nil && [bundle loadNibFile: aNibName
(gdb) s
86withZone: [owner zone]] == YES)
(gdb) s
84if (bundle != nil && [bundle loadNibFile: aNibName
(gdb) s
92bundle = [self mainBundle];
(gdb) s
96  withZone: [owner zone]];
(gdb) s
94return [bundle loadNibFile: aNibName
(gdb) s
0x774e3c0c in objc_msgSend_fpret ()
   from /usr/GNUstep/Local/Library/Libraries/libobjc.so.4.6
(gdb) bt
#0  0x774e3c0c in objc_msgSend_fpret ()
   from /usr/GNUstep/Local/Library/Libraries/libobjc.so.4.6
#1  0x77fa5f9b in -[PCLogController init] (self=0xd21068,
_cmd=) at PCLogController.m:105
#2  0x77fa5f24 in +[PCLogController sharedLogController] (
self=, _cmd=) at PCLogController.m:86
#3  0x77fa5bdc in PCLog (sender=0xf4a0b8, tag=0,
format=0x77fc5a58, args=) at PCLogController.m:28
#4  PCLogInfo (sender=0xf4a0b8, format=0x77fc5a58) at 
PCLogController.m:40

#5  0x77f8802f in -[PCBundleManager loadBundleWithFullPath:] (
self=0xf4a0b8, _cmd=, path=0x98eab8)
at PCBundleManager.m:403
#6  0x77f87cca in -[PCBundleManager bundleOfType:withClassName:] (
self=0xf4a0b8, _cmd=,
type=0x40c910 , className=)
at PCBundleManager.m:324
#7  0x77f87a82 in -[PCBundleManager 
objectForClassName:bundleType:protocol:] (self=0x441a78, _cmd=out>, className=0xd14e48,

bundleExtension=,
proto=0x40cab0 <._OBJC_PROTOCOL_PCPrefsSection>) at 
PCBundleManager.m:244

#8  0x0040505a in -[PCPrefController loadPrefsSections] (
self=0xf42888, _cmd=) at PCPrefController.m:313
#9  0x00404711 in -[PCPrefController init] (self=0xf42888,
--Type  for more, q to quit, c to continue without paging--
_cmd=) at PCPrefController.m:57
#10 0x004046b4 in +[PCPrefController sharedPCPreferences] (
self=, _cmd=) at PCPrefController.m:43
#11 0x00402138 in -[PCAppController init] (self=0xde48d8,
_cmd=) at PCAppController.m:52
#12 0x77da3782 in -[GSNibItem initWithCoder:] (self=0xdb7da8,
_cmd=, aCoder=0x8067b8) at GSGormLoading.m:551
#13 0x777f9d00 in -[NSUnarchiver decodeValueOfObjCType:at:] (
self=0x8067b8,
_cmd=0x77a76158 <.objc_selector_decodeValueOfObjCType:at:_>,
type=, address=0x7fffcb30) at NSUnarchiver.m:929
#14 0x776c9690 in -[GSSet initWithCoder:] (self=0xf4aee8,
_cmd=, aCoder=0x8067b8) at GSSet.m:249
#15 0x777f9d00 in -[NSUnarchiver decodeValueOfObjCType:at:] (
self=0x8067b8,
_cmd=0x77f20550 
<.objc_selector_decodeValueOfObjCType:at:_v320:8r*16^v24>, 
type=, address=0xb17e50) at NSUnarchiver.m:929

#16 0x77da2d69 in -[GSNibContainer initWithCoder:] (self=0xb17e28,
_cmd=, aCoder=0x8067b8) at GSGormLoading.m:384
#17 0x777f9d00 in -[NSUnarchiver decodeValueOfObjCType:at:] (
self=0x8067b8,
_cmd=0x77a75ba8 
<.objc_selector_decodeValueOfObjCType:at:_v320:8r*16^v24>, 
type=, address=0x7fffcce0) at NSUnarchiver.m:929

--Type  for more, q to quit, c to continue without paging--
#18 0x77717edf in -[NSCoder decodeObject] (self=0x441a78,
_cmd=) at NSCoder.m:249
#19 0x77dc926f in -[GSGormLoader 
loadModelData:externalNameTable:withZone:] (self=, 
_cmd=, data=0xea5718,

context=0x7545b8, zone=0x77a4c080 )
at GSGormLoader.m:114
#20 0x77c786dd in +[NSBundle(NSBundleAdditions) 
loadNibFile:externalNameTable:withZone:] (self=, 
_cmd=,

Re: ProjectCenter running or building

2020-01-30 Thread Johannes Brakensiek


Hi Patryk,

On 31 Jan 2020, at 6:44, Patryk Laurent wrote:

Manually looking for LogPanel.nib, I don’t see it anywhere on my 
system.


I do see LogPanel.gorm, however.

Could the problem just be that the .nib file isn’t being created 
anymore for some reason?


What code/makefile creates the .nib?


gorm files are preferred by GNUstep given the same name as the 
corresponding nib file. This is ok.


I tried to track this down a little for GWorkspace. The InspectorWin 
nibs/gorm files are located within the Inspector.framework. The 
framework is loaded, but when it comes to loading the nib files, the 
name/path of the bundle is set to the values of the main bundle not 
those of the framework. Due to the wrong path nib loading failes.


I’ve not yet come to the point to figure out why the bundle path might 
be set incorrect.


This is the point where I’m currently stuck:

```
Breakpoint 1, +[NSBundle(NSBundleAdditions) loadNibNamed:owner:] (
self=0x779b4700 <._OBJC_CLASS_NSBundle>,
_cmd=0x77f4be10 
<.objc_selector_loadNibNamed:owner:_C320:81624>,

aNibName=0x77f4d740 <.objc_str_InspectorWin>, owner=0x3f18cf8)
at NSBundleAdditions.m:65
65if (owner == nil || aNibName == nil)
(gdb) po owner

(gdb) po aNibName
InspectorWin
(gdb) s
69	  table = [NSDictionary dictionaryWithObject: owner forKey: 
NSNibOwner];

(gdb) s
83bundle = [self bundleForClass: [owner class]];
(gdb) s
84if (bundle != nil && [bundle loadNibFile: aNibName
(gdb) s
86withZone: [owner zone]] == YES)
(gdb) po bundle
 
```

That last value is wrong, afaik.

I’ve currently got problems debugging + (NSBundle *) bundleForClass: 
(Class)aClass using gdb because this method gets called too often. 
I’ll try to insert logging of some debugging output and recompile 
maybe.


Thanks for helping here - maybe anyone has a good idea regarding the 
cause of the issue?

Johannes

Re: Loading bundle resources using GNUstep runtime 2.0, was: Hint towards solution? Re: ProjectCenter running or building

2020-02-01 Thread Johannes Brakensiek


Hi Patryk,

On 1 Feb 2020, at 19:18, Patryk Laurent wrote:

Ok, armed with this knowledge, I was able to get ProjectCenter to 
"work" by doing 2 things:


thank you for proving we’re on the right track. ;)

What does this all mean, and why does this help things work?  I don't 
know, but I would like to know, as well as the "right" way to fix it.


Well, I think it works, because you have moved the framework to the main 
bundle (the app bundle). The main bundle path is known and loading from 
the main bundle works.


Why does it not work otherwise? Here I can just guess. There is much 
magic going on within NSBundle it seems. This comment beginning in line 
638 seems as it is giving some hints:


```
/* Nicola & Mirko:

   Frameworks can be used in an application in two different ways:

   […]

   (2) the framework was linked into the application.  This is much
   more difficult, because without using tricks, we have no way of
   knowing where the framework bundle (needed eg for resources) is on
   disk, and we have no way of knowing what the class list is, or the
   version.  So the trick we use in this case to work around those
   problems is that gnustep-make generates a 'NSFramework_xxx' class
   and compiles it into each framework.  By asking to the class, we
   can get the version information and the list of classes which were
   compiled into the framework.  To get the location of the framework
   on disk, we try using advanced dynamic linker features to get the
   shared object file on disk from which the NSFramework_xxx class was
   loaded.  If that doesn't work, because the dynamic linker can't
   provide this information on this platform (or maybe because the
   framework was statically linked into the application), we have a
   fallback trick :-) We look for the framework in the standard
   locations and in the main bundle.  This might fail if the framework
   is not in a standard location or there is more than one installed
   framework of the same name (and different versions?).
```

Using the debugger I did not see that „the standard locations“ (like 
…/Library/Frameworks) were tested. So currently it seems to me the 
fallback case is never reached. It might well be that the default way of 
looking up the bundle path using GSPrivateSymbolPath() returns something 
that seems valid but does not work or just is the path of the main 
bundle. We’d need to further investigate here.


So there might be two issues:

1. I suspect using the GNUstep runtime version 2.0 there are problems 
using these „advanced dynamic linker features“. This way of looking 
up the bundle path relies on using ```GSPrivateSymbolPath()```. Already 
the code comments of NSBundle make clear that this is a very fragile 
solution („But in real life GSPrivateSymbolPath() is risky“). So I 
don’t know if there is a proper way to fix this for the newest 
runtime. Any help from experienced people is appreciated here. If this 
fails in the way that it returns a valid but wrong value I won’t be 
able to fix it.


2. If the fallback way of looking up the bundle path fails, this is 
something I might be able to at least debug to some extend. The 
responsible code seems to begin at line 838, the most important function 
called here seems to be ```_find_framework()``` beginning in line 547. 
The constant which should be set correctly is 
```GSFrameworksDirectory```. First hint: If this fails ```NSWarnMLog``` 
(to be activated by which debug flag?) should output an error message 
(see line 869).


So this is the current result of my research late in the night. ;)

Regards
Johannes

Re: plmerge core dumps...

2020-02-13 Thread Johannes Brakensiek


Hey guys,

On 13 Feb 2020, at 15:31, Gregory Casamento wrote:


Another question.  How do i switch to ld.gold?


as I’ve written multiple times, these links describe how to get a 
working setup (and how to use ld.gold):


http://wiki.gnustep.org/index.php/Building_GNUstep_under_Debian_FreeBSD
https://github.com/plaurent/gnustep-build/

It works, but using libobjc2 runtime version 2.0 has the issues 
described in other mails about loading bundles/frameworks (no problems 
when using runtime version 1.9). Where these issues derive from we are 
still examining.


Regards
Johannes

#ilovefs - Thank you

2020-02-15 Thread Johannes Brakensiek


Hello everyone,

in my time zone Valentine’s day has already passed, but as I did not 
have time do it yesterday I’d like to pick up the campaign of the 
FSFE[1] today and use this day to thank you.


Thank you for your long and lasting commitment into developing GNUstep 
and providing this great API for the free world! I really liked to get 
into it and enjoyed writing with several people to understand how 
GNUstep works, fix some issues and make some pieces of software work.


I want to thank Bertrand Dekoninck, Riccardo Mottola, Patryk Laurent, 
Andreas Fink, Yavor Doganov, H. Nikolaus Schaller and David Chisnall for 
answering my questions, providing helpful hints and script and beautiful 
graphics to make my GNUstep environment work.


I’d like to especially thank Fred Kiefer who put an enormous amount of 
time and efforts to explain things to me, improve GNUstep-gui and thus 
make my first attempts to port a Cocoa app to GNUstep quite successful, 
which I’m very happy about.


So, thank you everyone. Keep up the good work!

```#ilovefs 💖```

Best
Johannes

[1] https://fsfe.org/campaigns/ilovefs/

Re: Loading bundle resources using GNUstep runtime 2.0

2020-02-16 Thread Johannes Brakensiek


Hello everyone,

Am 02.02.20 um 00:22 schrieb Johannes Brakensiek:
Using the debugger I did not see that „the standard locations“ (like 
…/Library/Frameworks) were tested. So currently it seems to me the 
fallback case is never reached. It might well be that the default way of 
looking up the bundle path using GSPrivateSymbolPath() returns something 
that seems valid but does not work or just is the path of the main 
bundle. We’d need to further investigate here.


after some hours of debugging I found out the following:

GSPrivateSymbolPath() works, but it always returns a path like 
/usr/GNUstep/Local/Library/Libraries/libOperation.so.1


So the subdir is Libraries and even +(NSBundle 
*)bundleForLibrary(NSString *)libraryName version:(NSString 
*)interfaceVersion (NSBundle.m) only looks within "Libraries" so the 
bundle at Library/Frameworks cannot be found this way. But as testing of 
the paths of LD_LIBRARY_PATH follows after this, the bundle is usually 
found.


The cause that looking up a bundle/framework by a linked class name 
fails is that [framework frameworkClasses] returns null as well as 
frameworkVersion returns 0.


Framework classes should be set by the code at lines 888 until 900 but 
this does not work the way it should it seems.


This interface for this is defined in NSBundle.m:

@interface NSObject (PrivateFrameworks)
+ (NSString*) frameworkVersion;
+ (NSString**) frameworkClasses;
@end

I don't know if this way of defining the interface might lead to 
problems using the new runtime?


Apparently the implementation is defined when building the framework as 
you can see at 
https://github.com/gnustep/tools-make/blob/master/Instance/framework.make, 
lines 488 until 499.


Help is appreciated once more. ;)

Thanks in advance
Johannes

Re: md5 hashing on GNUstep

2020-04-01 Thread Johannes Brakensiek





On 1 Apr 2020, at 20:36, Andreas Fink wrote:

Your approach might not give you the intended result if you have 
NSStrings containing Unicode characters which contains zero bytes. 
Your strlen() call would stop at that character and not go to the full 
length of a NSString. So a conversion to NSData and use its length 
would be better. For ASCII and Laltin1 it wouldnt make a difference 
though.


so this would be better appraoch:

   NSData *d = [self dataUsingEncoding:NSUTF8StringEncoding];
   unsigned char result[CC_MD5_DIGEST_LENGTH];
   CC_MD5( d.bytes, (int)d.length, result );


One might add (you probably know) that MD5 is broken regarding 
cryptographic purposes.[1]
For many use cases you should use something like SHA-2[2] or - if 
targeting passwords - hashing and salting[3] instead.


Johannes

[1] https://en.wikipedia.org/wiki/MD5
[2] https://en.wikipedia.org/wiki/SHA-2
[3] https://download.libsodium.org/doc/password_hashing

Re: GNUstep app fails on Ubuntu 16

2020-05-06 Thread Johannes Brakensiek

Hi Andreas,

On 6 May 2020, at 13:35, Andreas Höschler via Discussion list for the
GNUstep programming environment wrote:

I have done

apt-get install wdm
apt-get install wmaker
reboot

on a fresh Ubuntu (server) install but did not get any graphical
login!? :-(

it might be that wdm is a little too old to have a good configuration
packaged. Trying to add xorg is a good idea of course. I had good
results using lightdm under Debian. Installing GNUstep should be as easy
as

```
sudo apt install wmaker lightdm gnustep gnustep-devel
sudo dpkg-reconfigure lightdm
```

https://wiki.debian.org/LightDM (same should apply for Ubuntu)

This should pull in all of the required dependencies. But as of 16.04
the gnustep packages are quite old probably.

If you want to try a recent GNUstep build on top of Ubuntu 16.04 using
the GNUstep runtime you might want to try this one using the default
clang (using GNUstep runtime version 1.9):

https://github.com/plaurent/gnustep-build/blob/master/ubuntu-16.04-clang-6.0-runtime-1.9/GNUstep-buildon-ubuntu1604.sh

Or this one, which installs clang 9 before and installs runtime version
2.0:

https://github.com/plaurent/gnustep-build/blob/master/ubuntu-16.04-clang-9.0-runtime-2.0-ARM/GNUstep-buildon-ubuntu1604_arm.sh

You might have to adopt the latter one a little because it is meant for
the aarch64 version of Ubuntu 16.04 and installs the corresponding
clang/llvm (in cause you are using a different platform).

Before using the scripts X11 and a window manager should be up and
running.

Good luck
Johannes

Re: GNUstep - look and feel

2020-05-09 Thread Johannes Brakensiek


Hi Andreas,

On 9 May 2020, at 2:17, Bertrand Dekoninck wrote:

Rik :  This one 
needs the gnustep runtime and clang.





I’m using Rik (GNUstep runtime 1.9) or NesedahRik (gcc, GNUstep 
runtime 2.0) with most of my installations. I’m using 
SystemPreferences.app to set the menu style to Mac style (horizontal 
menu bar). You may also use:


```
defaults write NSInterfaceStyleDefault NSMacintoshInterfaceStyle
defaults write NSMenuInterfaceStyle NSMacintoshInterfaceStyle
```

Look and feel of default apps already seems pretty decent to me then.

Bertrand is also a little bit humble regarding his work to prettify the 
GNUstep appearance:


If you want some nice icons, 3D and shadow effects I suggest to follow 
Betrand’s setup using Compton, Icons and a WindowMaker theme which he 
has documented here: 
https://github.com/BertrandDekoninck/WindowMaker-session


If you turn off the dock of wmaker and use GWorkspace and its dock you 
will get pretty decent looks similar to these:


- NesedahRik: 
https://github.com/BertrandDekoninck/NesedahRik/blob/master/README.md
- Rik: 
https://github.com/AlessandroSangiuliano/rik.theme/blob/master/newscreen.png


I’m using this setup with clang (GNUstep runtime 1.9, libobjc 1.9) and 
a Raspberry Pi 3B+ (armhf, 32bit system). It looks pretty familiar for 
Mac users, runs faster than Mate Desktop and has very low memory 
footprint (about 200MB of RAM).


Johannes

Re: ctrl-mouse drag does not work - solved

2020-05-12 Thread Johannes Brakensiek


Hi Andreas,

On 12 May 2020, at 0:11, Andreas Höschler via Discussion list for the 
GNUstep programming environment wrote:


I have not yet managed to get Command - ... (e.g. Command - q to quit 
an application, Command - w to close a window,...) working though.I 
have 




defaults write NSGlobalDomain GSFirstCommandKey  **Meta_L**

**
**

on GNUstep so the instance should be ready to go. But it seems Jump 
Desktop is not forwarding Command - ...  shortcuts through to the 
remote instance. I have tried out all possible settings in the Jump 
Desktop preferences. Is anyone using Jump Desktop to access a remote 
GNUstep/Linux instance?


this seems to be a little OT here, but maybe others are interested as 
well. ;)


I’m using Jump! on my iPad and it works very well. The default alt-Key 
as well as „Left Super“ after using SystemPreferences to change it 
to that value. If „Left Super“ is selected it behaves like the 
Cmd-Key on MacOS.


This might depend on the RDP server you use. Do you use the RDP feature 
of the supervisor? I’m using xrdp (on the guest, bare metal in my 
case). After setting ```new_cursors=false``` in ```/etc/xrdp/xrdp.ini``` 
this works like a charm.


Regarding the other topic: Did you manage to change the GNUstep theme?

Johannes

Re: cross platform question

2020-05-14 Thread Johannes Brakensiek


Hi Andreas,

On 14 May 2020, at 10:56, Andreas Fink wrote:

If you want to write new apps running on MacOS X & GNUstep, what would 
you use to create the nib/xib/storyboard stuff which Xcode manages 
normally for you?

Handcoded source files? or is there an easier way.


I was investigating this for some time. For now two approaches seem 
reasonable to me.


The first one is creating xib files using Xcode and use these files with 
GNUstep. This works (somewhat well) since the latest GNUstep release.


I did some basic documentation here: 
http://wiki.gnustep.org/index.php/XIB
I have an experimental port of an app which uses this and kind of runs 
(thanks to the help of Fred): 
https://github.com/Letterus/app-time-tracker


This approach would be even nicer if xib 5 support would be added to 
Gorm.


The other approach is to use lib Renaissance[^1] which requires writing 
xml files and f.e. is used by FisicaLab[^2] or EOModelEditor[^3].


Let me know what you think.

Johannes

[^1]: http://www.gnustep.it/Renaissance/index.html | 
https://github.com/gnustep/libs-renaissance


[^2]: https://www.gnu.org/software/fisicalab/

[^3]: 
https://github.com/gnustep/libs-gdl2/tree/master/Apps/EOModelEditor

Re: [gnustep/libs-gui] * Source/NSWindow.m (-makeFirstResponder, -sendEvent:): Correct (be12d7b)

2020-05-15 Thread Johannes Brakensiek

Hi Fred,

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?

Johannes


smime.p7s
Description: S/MIME digital signature

Re: Graphos.app : error whith make

2020-05-18 Thread Johannes Brakensiek

On 18 May 2020, at 20:32, Fred Kiefer wrote:

> /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.

This might be because of some old settings somewhere. Make sure you did not mix 
different installation sources of GNUstep. This may lead to problems very 
quickly.

There are two scripts to unset (the wrong) and set the required env variables. 
You will usually find them as 
```/System/Library/Makefiles/GNUstep-reset.sh``` and 
```/System/Library/Makefiles/GNUstep.sh```. These scripts 
have to be ‚sourced‘, *not* executed. Use ```source ``` or ```. 
```. If you’re building GNUstep apps often it might be good 
idea to put such a line into your .bash_profile f.e.

Good luck
Johannes

signature.asc
Description: OpenPGP digital signature

Re: Gemas.app needs HighlighterKit

2020-05-21 Thread Johannes Brakensiek




On 22 May 2020, at 2:21, Ivan Vučica wrote:

Well spotted, but the correct approach is actually to use "sudo -E" 
instead of just "sudo" to inherit the current environment.




Otherwise you'd have to source the environment script within the new 
shell; sudo bash -c "source $path_to_gnustepsh && make install", 
perhaps? 




And, are .profile and .bashrc even used in sudo's subshell out of the 
box?


And it’s quite good practice to not build as root. So do ```make``` as 
a regular user followed by ```make install``` with ```sudo -E```. If you 
do have a machine with multiple cores/hyperthreading use -j to speed up 
to the build process like so: ```make -j```, fe ```make 
-j8```.

Re: Trying to build GNUstep from git repo and clang-9 on Raspbian Buster (10.4)

2020-06-15 Thread Johannes Brakensiek

Hi Patrick,

On 14 Jun 2020, at 23:15, Patrick Cardona via Discussion list for the
GNUstep programming environment wrote:

I tried to make GNUstep from git according to the wiki :
http://wiki.gnustep.org/index.php/Building_GNUstep_under_Debian_FreeBSD

I am stuck at this step : building libobjc2.

These are the steps and things done :

Building GNUstep under Raspbian (Buster 10.4) :

Target: armv6k-unknown-linux-gnueabihf

I don’t know the exact cause of your failure, so David might want to
add valuable information here.

But afaik some parts of libobjc2 2.0 are built from assembler code. The
needed code for the armhf architecture does not exist yet. That
architecture is 32bit. If you try the 64bit variant (aarch64) it should
work afaik.

If you want to build libobjc2 on armhf you will have to use the older
version 1.9 of libobjc (which does not require clang >= 8, but works
with older versions of clang as well).

We have a script prepared for this which should install GNUstep by just
running it:
https://github.com/plaurent/gnustep-build/blob/master/raspbian-10-clang-7.0-runtime-1.9-ARM/GNUstep-buildon-raspbian10.sh

If you are going to use aarch64 this one should work as well:
https://github.com/plaurent/gnustep-build/blob/master/debian-10-clang-8.0/GNUstep-20-buildon-debian10.sh

I’d be glad if David could approve this is correct.

Also, it would be very nice if anybody would like to do the missing
libobjc2 assembler implementation for armhf. I think this is a common
use case as long as the default arch for Raspbian is 32 bit. Even though
this arch will be running out of support at some time in the future, of
course.

For anybody building libobjc2 on a Debian based platform: Please note
there are also some very recent Debian source packages. I have not yet
tried to build them, but I think that approach sounds very promising:
https://github.com/trunkmaster/nextspace/tree/master/Packaging/Debian
(this will only work if you try it on the supported platforms of
course).

Cheers
Johannes

Re: Segmentation Fault while compiling PikoPixel : 1.0-b9d

2020-06-17 Thread Johannes Brakensiek


Hi Patrick,

On 17 Jun 2020, at 13:51, Patrick Cardona via Discussion list for the 
GNUstep programming environment wrote:


obj/PikoPixel.obj/PrecompiledHeaders/ObjC/PikoPixel_Prefix.pch.gch] 
Error 254


the precompiled header file is not compatible with clang/the libobjc2 
runtime. Just remove the .pch file from the GNUmakefile and will compile 
nicely.


Good luck
Johannes

Re: Trying to build GNUstep from git repo and clang-9 on Raspbian Buster (10.4)

2020-06-18 Thread Johannes Brakensiek


Thank you for your reply, David.

On 18 Jun 2020, at 10:46, David Chisnall wrote:

If you want to build libobjc2 on armhf you will have to use the older 
version 1.9 of libobjc (which does not require clang >= 8, but works 
with older versions of clang as well).



The v2 and v1 ABIs do not use different assembly fast paths.


This is always a little bit confusing to me. Version 2.0 of libobjc2 
supports v2 and v1 ABI, ok. But compiling only worked using the version 
1.9 of libobjc2 (meaning the git tag/version, not the ABI version). Does 
that sound correct to you?


Also, it would be very nice if anybody would like to do the missing 
libobjc2 assembler implementation for armhf. I think this is a common 
use case as long as the default arch for Raspbian is 32 bit. Even 
though this arch will be running out of support at some time in the 
future, of course.



I did.  Five years ago.  Note that there was a bug until 15 months ago 
where the unwind info was not correctly set, so throwing an exception 
out of +initialize would potentially corrupt some floating point 
state.


That’s very good to read, thank you! Probably I read some outdated 
documentation or was just using the 1.9 tag because Raspbian only had 
clang 7 available then. I will try again with 2.0 and clang 8 and report 
if I ran into the same issue as Patrick.


Johannes

Re: Trying to build GNUstep from git repo and clang-9 on Raspbian Buster (10.4)

2020-06-19 Thread Johannes Brakensiek


On 18 Jun 2020, at 10:46, David Chisnall wrote:

I did.  Five years ago.  Note that there was a bug until 15 months ago 
where the unwind info was not correctly set, so throwing an exception 
out of +initialize would potentially corrupt some floating point 
state.


This runtime stuff really is higher arts for me, so I won’t be of much 
help debugging. But I ran into an issue that seems to be connected to 
something called „unwind“. ;)


Looking into the git history it seems to be connected to lastest 
commit/PR.


https://github.com/gnustep/libobjc2/issues/164

It’s different to what Patrick reported, though. Running cmake with 
clang-8 worked without issues.


Johannes

Re: XCode project to GNUstep GNUmakefile within ProjectCenter

2020-07-07 Thread Johannes Brakensiek


On 7 Jul 2020, at 20:39, Gregory Casamento wrote:

The two TARGETED apps you mentioned are also both UIKit apps which we 
currently don't support. 


The corresponding AppKit app is MacPass, which surely would be worth a 
try to port it. I’d not expect it to compile using GNUstep without 
changes though.


https://github.com/MacPass/MacPass

Johannes

Re: Segfault while building PikoPixel

2020-07-07 Thread Johannes Brakensiek


Patrick,

On 7 Jul 2020, at 19:55, Patrick Cardona via Discussion list for the 
GNUstep programming environment wrote:



 Precompiling header file PikoPixel_Prefix.pch ...


didn’t you already run into this problem which I responded to on 17th 
June and didn’t that solve the problem for you?


Johannes

Re: Help building GNUstep from scratch

2020-07-15 Thread Johannes Brakensiek


On 15 Jul 2020, at 5:29, Patryk Laurent wrote:

What OS/distribution are you building under, and what version of 
clang?  A few of us have put together build scripts that use the 
latest GNUstep source using all the modern Objective-C features 
at  — perhaps one of 
those would help you? 


One might add that this is the more detailed tutorial from which the 
Debian scripts above derive: 
http://wiki.gnustep.org/index.php/Building_GNUstep_under_Debian_FreeBSD


Please also note that you usually have to remove all GNUstep 
dependencies from apt/aptitude to make the manual installation work.


In case you want to build apt based packages on your own you might try 
these sources for Debian source packages which will build the 
GNUstep/clang runtime as well:


https://github.com/trunkmaster/nextspace/tree/master/Packaging/Debian

Johannes

Re: Debian Package Repository...

2020-07-29 Thread Johannes Brakensiek


Hey Gregory,

On 29 Jul 2020, at 16:52, Gregory Casamento wrote:

One of the things we have struggled with in the past is the fact that 
the
Debian packages are, necessarily, way behind.   I would like to set up 
a
repo that contains the needed packages (at first for deb, but then for 
rpm
based repositories as well) for users to get their packages directly 
from
us IF they choose to do so.  I am in no way saying we should not 
create
packages for Debian, but this would allow us to have more control and 
also
would allow us to create packages that use clang instead of GCC for 
Linux.


I am going to set this up on an AWS server.  I will let you guys know 
about
my progress.  If anyone would like to help or has any advice, let me 
know.


thank you for putting new efforts into this, I think this is a great 
idea. ;)


But I’d beg you to not start afresh again. The work of preparing the 
source packages already has been done for the Nextspace project: 
https://github.com/trunkmaster/nextspace/tree/master/Packaging/Debian


These are the GNUstep packages plus those needed for Nextspace and they 
are all based on the Debian ones, just renamed.


It would be of great use you could provide the binary packages for this. 
I’d prefer them to not be hosted on AWS, but that’s a minor issue to 
me.


I also tried to set up a PPA for GNUstep 
(https://launchpad.net/~gnustep), but I did not achieve much progress 
regarding CI/CD, because some of the automatic imports of GNUstep 
repositories are failing due to a bug of LaunchPad itself. So I’d 
rather prefer a CD approach based on the source packages mentioned 
above, provided by a custom Debian repository.


Thank you
Johannes

Re: A window manager written in objective-c: uroswm and gnustep support problems

2020-09-15 Thread Johannes Brakensiek


Hi Alex,

On 15 Sep 2020, at 16:38, Alessandro Sangiuliano wrote:

Any help is appreciated, also just opinions, discussions and exchange 
of ideas.


to keep it short: You work is highly appreciated. Your work on rik.theme 
and graphics from Bertrand make using GWorkspace a joy.


If you plan to further improve that experience and are having fun on the 
technical part I highly encourage you to keep the good work up. It’s a 
pity we do not yet have packages to ship that experience (also due to 
the fact that rik won’t work with libobjc2 v2). But as part of the 
Nextspace project there is some packaging work done which could be 
reused.


That said to the technical point of view I’d also like to add that I 
could a imagine a way of integration of GNUstep apps that works the 
other way around: If there were a theme and maybe some implementation of 
desktop frameworks that would neatly integrate GNUstep apps into a Mac 
like experience like elementary OS I could imagine a great benefit for 
both GNUstep and fans of that sort of user experience.


So, if you look at screenshots like this: 
https://elementary.io/images/screenshots/mail.png That could be 
GNUMail.app as well. One would just have to make it look like this. ;) 
Same applies to many Cocoa apps which could be ported.


These are just some dreams in a more strategic pattern. I’m able to 
imagine stuff like that since I saw Rik.theme. So thanks to you. :)


Best
Johannes

Re: NeXTstep interface

2020-09-29 Thread Johannes Brakensiek


Hi Simon,

On 28 Sep 2020, at 0:43, Simon Gornall wrote:

So I came across this 
(https://www.ninamakes.co.uk/builds/next-computer-replica-raspberry-pi-case/ 
) 
and it’d be pretty cool to have a NeXT-like interface running on the 
Pi in that enclosure, and I assume running GNUstep is the best way to 
do something like that.


Any hints on what’s the best way to go about this, starting from 
scratch ?


Is it even possible to get the NeXT window manager experience ? Etoile 
looks to have a different ‘look-and-feel’ from the screenshots 
I’ve seen, although Nextspace 
(https://github.com/trunkmaster/nextspace 
) looks pretty realistic to 
my untutored eye, and also runs with Centos 8, although it may not 
work with the PI (it looks pretty focussed on x86).


you can get the basic GNUstep experience on any Debian based system by 
just installing WindowMaker (wmaker) and GNUstep with GWorkspace via 
apt. This works well using Raspbian f.e., see 
http://wiki.gnustep.org/index.php/Platform:Linux#Debian


You can install Nextspace as well (libobjc2 works on ARM since its last 
release). But you will need to compile and install it yourself. 
Packaging for Debian is still work in progress and does not lead to a 
fully working environment yet. rpm packaging for other platforms seems 
to be implemented currently as well. See 
https://github.com/trunkmaster/nextspace/tree/master/Packaging for that 
progress.


Good luck
Johannes

LIVEstep - FreeBSD based live CD

2020-10-01 Thread Johannes Brakensiek


Hello folks,

there is a FreeBSD based live CD using GNUstep and the more modern 
looking adjustments by Alessandro and Bertrand. It’s created utilizing 
the FuryBSD live CD efforts.


https://github.com/probonopd/LIVEstep

Just to let you know.

Johannes

Re: Debian Package Repository...

2020-12-15 Thread Johannes Brakensiek

Hello everyone,

>> On 15 Dec 2020, at 03:23, Patryk Laurent  wrote:

>> I’d be interested to know if there are any updates on this. One of the 
>> most popular distributions on Pine64’s PinePhone is Mobian which is 
>> Debian with mobile UI added on top.
> 
>> I have a build script working for Mobian[1] but up-to-date packages would 
>> be great as they’d be easier to specify as dependencies.

as part of the Nextspace project/repo Patrick Georgi and me have been working 
on Debian packaging a bit. But for me it's still unfinished as you will have to 
get clang 8 from backports, which makes packaging for Buster a little bit 
complicated (and is much easier for sid).

This pull request contains some efforts, that work. I won't be too hard to port 
them back for GNUstep packages:
https://github.com/trunkmaster/nextspace/pull/353

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 additionall distributions and architectures in case 
anybody would like to provide these.

So far. Stay sound and healthy
Johannes

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.

GNUstep.app, was: Debian Package Repository...


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: GNUstep.app, was: Debian Package Repository...


Thank you, Greg.

On 18 Jan 2021, at 17:14, Gregory Casamento wrote:

  * Aaron Hillegass/Adam Preble: Cocoa Programming for Mac OS X. 4th 
ed. Addison-Wesly, 2012.


He gets the project COMPLETELY wrong in this book.  His misconception 
about us needing the "absolute latest" of gcc and other assumptions he 
made without really checking with us are damaging.


Yes, I know. But that was 2nd edition (maybe still 3rd?). So I’ve 
referenced 4th. He dropped the (wrong) part about GNUstep, but added 
information about ARC, properties and so on. So, 4th ed., best choice 
for my taste. ;)

Re: GNUstep.app, was: Debian Package Repository...


Hi Patryk,

On 18 Jan 2021, at 17:35, Patryk Laurent wrote:


This is great!  Are you accepting pull requests on this?

One suggestion is to increase the compression level on the PNGs, 
they’re loading very slowly from over here in California.


I’d be happy to re-compress all the images if it would help, I think 
it could be automated using ImageMagick.


thank you. You’re welcome: 
https://github.com/Letterus/gnustep.app-website


Johannes

Re: GNUstep.app, was: Debian Package Repository...





On 18 Jan 2021, at 18:45, Fred Kiefer wrote:

Great website! There is one typo on the IDE page ("Different 
approaches für building cross platform GUI“) :-)


Nice catch. Almost did not see it even after your hint. :)


And you should add PikoPixel to your list of apps.


Definitely. As soon as I can. ;)

Thank you
Johannes

Re: GNUstep.app, was: Debian Package Repository...