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

GNUstep as a framework has an extremely rich set of tools in addition to
the classes.
If web properties were separated between a developer web site and an end
user facing web site for a future desktop, there are a few benefits.

- Each website has a distinct target audience
- Each website will have it's own home page tailored to the needs of
their target audience
- It eliminates end users navigating to pages that are not relevant to them
- This opens the opportunity to actually have multiple implementations down
the road. NEXT style, Modern style, phone, tablet etc
- There is more than enough content to justify a dedicated GNUstep
developer focused site.

Apple themselves have multiple implementations/platforms. They also have
separate web sites for end users and developers. This is not by accident
and likely for the same reasons I stated above.



On Thu, Jul 11, 2024 at 1:48 PM Ethan C <echaroenpit...@gmail.com> wrote:

> I had an overview of the GNUstep system at
> https://ethanc8.github.io/Sphinx-Documentation/Reference/index.html. It's
> unfortunately a bit outdated, but do you think this kind of index would be
> good or do we want to organize oir docs some other way?
>
> On Thu, Jul 11, 2024, 12:35 Riccardo Mottola <riccardo.mott...@libero.it>
> wrote:
>
>> 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
>>
>>
              • ... 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
              • ... lars.sonchocky-helld...@hamburg.de
              • ... Damianos Sidiropoulos
              • ... Hugo Melder @ TUM
              • ... Ethan C
              • ... Riccardo Mottola
              • ... Riccardo Mottola
  • R... Riccardo Mottola
  • R... Riccardo Mottola
    • ... lars.sonchocky-helld...@hamburg.de
    • ... lars.sonchocky-helld...@hamburg.de

Reply via email to