Hi ANdreas,

Andreas Fink wrote:
I think the answer lays in the area of who will use the website.

If a developer wants to use it, he will think of frameworks for his app
If a end user wants to use it, he will think of a full fledged desktop with a lot of apps already ready to deploy.

Exactly.. also there are different kind of developers. Some just want to port their app - they don't care much about project philosphy, GNU, whatever. Other choose to GNUstep core because they like it and take portability to Mac as a bonus.

Also, different kind of users, some users just look at some screenshots, others, who like to dive into details can look a bit in the technical side, this is why I like them to be "one menu distance" in navigation. Distinct, but near. Like the other side of the medal.


For me the developer is just someone using an SDK to use the frameworks to run on the desktop. So the developer is a special user case. If the desktop is not attractive, then the end users will not install it, hence developers will at some point waste their time developing for it (ignoring the fact temporarly that you can write single apps who don't care about the desktop environment and just run on any X.org <http://X.org> install or even without any GUI).

For me, marketing a fully fledged desktop is the much more attractive view. However it also means we must get a working reference implementation into the distros. Something where when one installs XYZ Linux, a question would appear saying "What Desktop do you want to run on: GNOME, KDE, Gnustep,...?"

Yes.. but think that GTK gives GNOME and XFCE and a lot of people like the latter (myself) and QT has KDE and Trinity... (ok, I hope we won't have stupid revision splits like these project has, pass the comparison).



Given GNUStep is kind of a  "clone" of MacOS at some point, I believe having a well working desktop would bring MacOS developers over to the platform to use GNUStep as the tool to port their Apps to supported GNUStep Platforms. Of course all the latest new AI and ML and Metal implementation stuff would be missing but there are LOTS and LOTS of applications out there who could be ported easily. But it all starts with a working environment a developer coming over from MacOS could use.


thank you for your thought, it is similar to mine.


I think having a split website is fine, it can be made clearer, we can have better working and better navigation. The only common part is the painpoint: the homepage. We used the catch-all approach for years, continuing to add everything so that at a glance everything is there. I tried to clean it up a little, but it can be done further without fear, being sure that you can read what you need.

However... we lack clear material in development, how things fit together, the structure, so that you can read. The "glue" between just raw  class reference and tutorials. They should be there and cross-linked.

Also some diagrams like our library structure. presentation of the different libraries beyond core.

we essentially have:
https://www.gnustep.org/developers/index.html

which contains really little. Points out some stuff to Wiki... but we should decide that if it is stable and complete, it should be "promoted" and integrated. E.g.

https://www.gnustep.org/developers/map.html

Sorry for not having upgraded the style of it yet - will do. But it should have a good "text" around the images.
Also... I find it a little bit confusing- gnustep make ?


The real useful it has is a link here:
https://www.gnustep.org/developers/documentation.html


Good evening,

Riccardo

          • ... Riccardo Mottola
            • ... Ethan C
              • ... Damianos Sidiropoulos
              • ... Riccardo Mottola
              • ... Gregory Casamento
              • ... Gregory Casamento
        • ... Riccardo Mottola
          • ... Daniel Boyd
            • ... Damianos Sidiropoulos
              • ... Andreas Fink via Discussion list for the GNUstep programming environment
              • ... Riccardo Mottola
              • ... Ethan C
              • ... Damianos Sidiropoulos
              • ... [email protected]
              • ... Damianos Sidiropoulos
              • ... Hugo Melder @ TUM
              • ... Ethan C
              • ... Riccardo Mottola
              • ... Riccardo Mottola
  • R... Riccardo Mottola
  • R... Riccardo Mottola

Reply via email to