discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

My suggestions for GNUstep.


From: Kevin Ingwersen
Subject: My suggestions for GNUstep.
Date: Sun, 9 Feb 2014 22:30:18 +0100

Hello there.

In the past few months, I spend almost all my free time to learn everything, 
from C, to C++; from polling to threading; from static to dynamic libraries and 
differences between linking on different platforms…basically, i jumped 
head-first into the moshpit of low-level developing.
In that time, I learned and started to understand a lot of things that have 
been going thru my head. Things like „Why is there no PS3 compiler for Mac?“ 
Well, there actually is. But porting it from the first os - Windows - to 
something that is not-standart - OS X - is hard. And so on, and so forth.

So, I also learned ObjectiveC and came across GNUstep, when I tried to toy 
aorund with it. I really enjoyed the syntax, and have been pondering to suggest 
a giant RFC to php.net for „Objective-PHP“, to bring Objective-C++ to PHP…it 
was a fun idea, but the more I think about it, the more its shaping up. And PHP 
always reminds me of portability: I code it on my mac, and run it on my Linux 
box, and can run a test at school on Windows. And after I realized that, I did 
another course on static libraries. 

That brought me to my first possible improvement for GNUstep: Static libs.
If GNUstep had static libs, it wouldnt be neccessary to link against various of 
libraries, package them all together, just to build one app. Imagine, that you 
have a great idea, and wrote it out in ObjC on GNUstep. But when you try to 
redistribute on Windows, you realize that its anything but pleasant. On linux, 
this is okay - because you can use PKMs. So, packaging it all up, is not easy. 
But meanwhile, static libraries allow you to put all the objects that you need 
into one binary…which in return means, your executable becomes portable.
On my various tries of building GNUstep on my OS X, i tried to build it as 
staticaly as possible. Mainly to avoid linking against OS X’ native libs. 
Imagine what happens if the dynamic linker on a non-dev oS linked an executable 
to Apple’s libobjc2, although it was intended for libobjc2-gnustep? It…could 
turn out quite weird. *chuckles.* Therefore, I tried to be as static as 
possible. But since libobjc2 didnt want to compile with clang, I have given up 
the idea for now, while I was working on other projects.

But - hey. If GNUstep learned to be more static, it woudl be more portable - 
which in return, would make it much easier, to redistribute an OBJC app. And 
that in return, would be so cool =).

But redistribution is not the only problem. I saw, somewhere in the manuals 
about upgrading, that in order to upgrade you needed to kill a process, that 
helped the GUI. Oi, not cool. Having to depend on an external .exe that keeps 
the backend running is kinda un-portable. That requires any user to install the 
runtime, in order to run an app.
I also saw that there are many backends. For what are they, and what exactly 
are they based on? I amc urrently having a lot of fun with FLTK. Its a great 
GUI toolkit - and thus, very tiny. It only adds 2mb to my app, and thats the 
maximum, to get me going with a GUI.
So my suggestion here, make clear which is the „probably best“ backend to use. 
In conjunction with the point above, possibly one that wouldnt require an 
always-running process :p

Now, while I travel around mainly with my MacBook, I dont have to worry for a 
toolchain. And if I have my Vaio duo 11 with me, i also get Windows and Ubuntu 
on hand if I need them (and actually a „hackintosh“ x3). But often enough, I am 
spending a lot of time in coding class - and in which, i have basically nothing 
to do. SQL is something I taught myself years ago. So, explaining relational 
database structures is pretty basic for me. So, I try to spend my time with 
coding. The only set of compilers is Dev-C++ - which, in my school - is an 
outdated version of MinGW. So outdated, that I honestly didnt try to run Bash 
yet - i fear that its something like 3.1 xD. But, what if I had a portable 
GNUstep build?
If GNUstep was optimized to be ran off a thumbdrive, it could be utilized in a 
ton of ways.

To build my current project Deskshell, its recommended to use a uNIX style 
build system. I am trying to port it to use Microsoft’s VS too - the project 
itself uses GYP, so I need to adjust settings - but it would be much easier to 
run it in a UNIX environment. Now, if I was able to download a fully prepared 
GNUstep bundle, and would be able to launch a .bat file to kick off a UNIX 
environment, that would be so very useful. :) That way, I could make building 
easier, and rely less on the wobbly info that I am reading off other projects 
o-o.
In short, this suggestion would be to make GNUstep even easier to be used from 
anywhere, like from a thumbdrive. I am actually waiting to finish my current 
project to finalize my package manager, that has developed so far, that it 
could build from source too. For that, I would really liek to use a standarized 
toolchain. I first thought about using plain MinGW - but i would be happier to 
actually advertise, that drag0n (the name of the PKM) offers a toolchain that 
can also do Objective-C. It would make it all complete - a PKM that can not 
install just from a lot of places, but also a lot of sources in different 
languages.



For now, I just wanted to express my thoughts and ideas for GNUstep. I hope to 
find a way to utilize it more in the future towards an end-user - and not just 
devs. But as long as it is a humble task to build up a good bundle, it will be 
impossible for me to redistribute GNUstep for now.

And, if i get GNUstep to compile properly on OS X, I will see and try if i can 
get an old project that I saw in the trunk working again; GNUstep.framework, 
which makes it possible to really have one api, across all platforms that use 
GNUstep. :)

For now, i wish you a great day :)

Kind regards, Ingwie! ^^


reply via email to

[Prev in Thread] Current Thread [Next in Thread]