Re: using XDPS backend to display NextOpenStep apps remotely

[Ondrej Florian]

I managed to find out what an app is actually sending out to the display server.
There is NXShowPS argument you can pass to any application which will print out 
any data coming back and forth. 
It is basically streaming postscript (as expected ;-). ...very cool to see in 
real-time.
The problem is that it includes a lot of extensions like "set active window" or 
"change window status" which is not part of "standard" DPS. All of that would 
all have to be reverse engineered and Incorporated into DPS server  + 
windowmanager.
...a lot of work and non of it is documented...

What I am thinking about doing is capturing actual bitmap of a window.
Kind of like VNC would do but capture it per window instead of entire screen.

I know it can be done. Grab.app does capture window even if it covered by other 
window, but I didn't find the right API yet ;-)

On 2024-04-29 00:37:34 +0200 Gregory Casamento  wrote:

> Sweet!!!   Please share your progress.  I would love to learn more.
> 
> Gregory Casamento
> GNUstep Lead Developer / Black Lotus, Principal Consultant
> http://www.gnustep.org - http://heronsperch.blogspot.com
> https://www.patreon.com/bePatron?u=352392 - Become a Patron
> https://www.openhub.net/languages/objective_c
> https://www.gofundme.com/f/cacao-linux-a-gnustep-reference-implementation
> 
> 
> On Sun, Apr 28, 2024 at 17:27 Ondrej Florian  wrote:
> 
>> Thanks Gregory.
> 
>> Communicating between GNUstep and Next is actually not that bad.
>> I managed to sync pasteboard by using simple TCP client/server and
>> transferring strings, RTF or TIFF data as appropriate.
> 
>> The Previous has NFS server built-in, so working with files is just matter
>> of transforming local paths to network paths and then executing appropriate
>> app (using the simple TCP client/server) in Next.
> 
>> I mapped Previous into its own windowmaker workspace.
>> That works reasonably well but it is somewhat limiting for day to day
>> usage.
> 
>> I'll take a look at DSP server as you've suggested and see where it leads
>> me ;-).
> 
>> On 2024-04-28 22:41:53 +0200 Gregory Casamento 
>> wrote:
> 
>>> Hey,
>>> 
>>> I had given this some thought some years ago.   Let's go over what you
>> said
>>> you need...
>>> 
>>> 1) running the next emulator headless...
>>> 
>>> I think this could be accomplished, no problem.   You could either use
>>> Previous or qemu (running the intel version of OPENSTEP).
>>> 
>>> 2) Communication via DPS...
>>> 
>>> You don't need XDPS for this.  The XDPS backend for GNUstep was an
>> attempt
>>> to use the Display Postscript that was going to be integrated into X11,
>> but
>>> this never happened because the people on the project determined that
>>> postscript was better done as a client/app side thing rather than in the
>> X
>>> server itself.   Here is the discussion...
>>> 
>>> 
>> https://www.x.org/releases/X11R7.5/doc/graphics/dps.html#:~:text=Display%20Postscript%20
>>> (or%20DPS%20for,code%20from%20client%20to%20server.
>>> 
>>> One place you can get information is from the following website, he has
>>> done a fair bit of hacking on PS and DPS...
>>> 
>>> https://www.wizards.de/~frank/franksprojects.html
>>> 
>>> Of particular interest is project Akira.   It may be possible to connect
>> to
>>> the DPS server over a port and communicate with it, but no one has done
>>> that and I am not sure the remote capability is present either in the
>>> DGS/DPS backend that X was planning.
>>> 
>>> 3) Pasteboard bridging...
>>> 
>>> The pasteboard on the NeXT likely uses the typedstream style of encoding
>>> that was common on the NeXT machine.   This encoding has never been
>> reverse
>>> engineered... one possible resource for this is a python program I found
>>> recently that discovers, in part, the structure of typedstream
>> archives...
>>> 
>>> https://github.com/dgelessus/python-typedstream.git
>>> 
>>> The tool doesn't get the data it just breaks down what data is there
>> which
>>> could be instrumental in reverse engineering it.
>>> 
>>> CONCLUSION...
>>> 
>>> As you can see there is a fair amount of work here.   This is all of the
>>> information I have discovered over the years on this.  If I find anything
>>> else or dig up any other information that might be useful I will let you
>>> know.
>>> 
>>> Yours, GC
>

Re: using XDPS backend to display NextOpenStep apps remotely

[Ondrej Florian]

Thanks Gregory.

Communicating between GNUstep and Next is actually not that bad.
I managed to sync pasteboard by using simple TCP client/server and transferring 
strings, RTF or TIFF data as appropriate.

The Previous has NFS server built-in, so working with files is just matter of 
transforming local paths to network paths and then executing appropriate app 
(using the simple TCP client/server) in Next.

I mapped Previous into its own windowmaker workspace.
That works reasonably well but it is somewhat limiting for day to day usage.

I'll take a look at DSP server as you've suggested and see where it leads me 
;-).

On 2024-04-28 22:41:53 +0200 Gregory Casamento  wrote:

> Hey,
> 
> I had given this some thought some years ago.   Let's go over what you said
> you need...
> 
> 1) running the next emulator headless...
> 
> I think this could be accomplished, no problem.   You could either use
> Previous or qemu (running the intel version of OPENSTEP).
> 
> 2) Communication via DPS...
> 
> You don't need XDPS for this.  The XDPS backend for GNUstep was an attempt
> to use the Display Postscript that was going to be integrated into X11, but
> this never happened because the people on the project determined that
> postscript was better done as a client/app side thing rather than in the X
> server itself.   Here is the discussion...
> 
> https://www.x.org/releases/X11R7.5/doc/graphics/dps.html#:~:text=Display%20Postscript%20
> (or%20DPS%20for,code%20from%20client%20to%20server.
> 
> One place you can get information is from the following website, he has
> done a fair bit of hacking on PS and DPS...
> 
> https://www.wizards.de/~frank/franksprojects.html
> 
> Of particular interest is project Akira.   It may be possible to connect to
> the DPS server over a port and communicate with it, but no one has done
> that and I am not sure the remote capability is present either in the
> DGS/DPS backend that X was planning.
> 
> 3) Pasteboard bridging...
> 
> The pasteboard on the NeXT likely uses the typedstream style of encoding
> that was common on the NeXT machine.   This encoding has never been reverse
> engineered... one possible resource for this is a python program I found
> recently that discovers, in part, the structure of typedstream archives...
> 
> https://github.com/dgelessus/python-typedstream.git
> 
> The tool doesn't get the data it just breaks down what data is there which
> could be instrumental in reverse engineering it.
> 
> CONCLUSION...
> 
> As you can see there is a fair amount of work here.   This is all of the
> information I have discovered over the years on this.  If I find anything
> else or dig up any other information that might be useful I will let you
> know.
> 
> Yours, GC
> 
> 
> 
> 
> On Sun, Apr 28, 2024 at 2:32 PM Ondrej Florian  wrote:
> 
>> Hi everyone,
> 
>> I am working on integrating the Next emulator
>> (http://previous.alternative-system.com/)
>> into the GSDE  (https://github.com/onflapp/gs-desktop).
> 
>> I understand the original Next/OpenStep could display apps remotely (I
>> guess that's where NXHost arg comes from).
>> Does anyone know how this actually worked?
>> Could it be possible to use XDPS backed for for that?
> 
>> My hope is that I could run the Next emulator "headless" and display
>> the original apps along side GNUstep apps in the same desktop (plus
>> bridging pasteboard etc. ;-).
>> Kind of like how the classic mode worked on OS X.
> 
>> Any ideas?
> 
>> Many thanks,
>> Ondrej
> 
> 
> 
> 
>

using XDPS backend to display NextOpenStep apps remotely

[Ondrej Florian]

Hi everyone,

I am working on integrating the Next emulator 
(http://previous.alternative-system.com/)

into the GSDE  (https://github.com/onflapp/gs-desktop).

I understand the original Next/OpenStep could display apps remotely (I 
guess that's where NXHost arg comes from).

Does anyone know how this actually worked?
Could it be possible to use XDPS backed for for that?

My hope is that I could run the Next emulator "headless" and display 
the original apps along side GNUstep apps in the same desktop (plus 
bridging pasteboard etc. ;-).

Kind of like how the classic mode worked on OS X.

Any ideas?

Many thanks,
Ondrej

Re: General Design Guidelines for GNUstep and apps

[Ondrej Florian]

On 2024-04-04 09:07:36 +0200 Thomas  wrote:



As Ricardo mentioned could you test wether this strange menu behavior 
is 
caused by GDSE please or is there another reason?




The reason why this doesn't work is missing support from the window 
manager (windowmaker).


1. GNUstep will send out custom X11 event (root window I believe)
2. wmaker will interpret the signal and hide/show windows as requested
3. wmaker will also need to send signals back to all GNUstep windows 
to inform them what has just happened (careful, there might be a race 
issue here)


This does not work correctly and as it breaks existing focus 
behaviour, I decided to disable it.


Thanks,
Ondrej

Re: General Design Guidelines for GNUstep and apps

[Ondrej Florian]

Hi Thomas,

I am afraid creating modern, OSX-like desktop would require very different 
approach than GSDE is taking. 
Using Wayland, process separation and something like D-bus for IPC for example. 

What makes GSDE cool is its simplicity. All of its consistency and power comes 
from the GNUstep foundation (e.g. services, NSNotifications, global key 
shortcuts, steptalk, etc.). 

However, this is only possible because all apps are GNUstep apps (or wrappers).
I did experiment with bridging GTK with GNUstep to make "porting" apps to GSDE 
easier,
but considering one has to remap all keys, menus, dialog boxes to make it all 
work and look the same as GSDE,
it is really not worth the effort.

"Normal" world is much, much more complex.
There is a reason why GNOME, KDE or even XFSE are such beasts.
There are many edge cases that these desktop environments must take into 
cosideration.
Linux Desktop is not easy problem to solve.

Thanks,
Ondrej

On 2024-04-03 10:57:00 +0200 Thomas  wrote:

> Hi Ondrej,
> 
> I would very very appriciate if these menus "hide others", "show all" or 
> "quit“ and so on would stay and work GSDE wide in a uniform way :-).
> 
> In my opinion you addressing one main reason for the tiny userbase GNUstep 
> has. There is noch easy to use, comfortable home (a fine Desktop 
> environment).
> You remember what Jobs said about OS X Aqua? „You want to lick it…“ ;-).
> As an old OS X user who want to leave Apples hardware and has to use M$ at 
> work (including swearing) I would like to have things that work on OS X 
> (menus) similar on GNUstep (GSDE)…
> as also NEXTstep has some changes on the way to OS X ;-).
> Why not adapt the good things?
> Currently I often change to one of the not so bad LINUX Desktops for instance 
> XFSE or so to do things easier as GSDE is not yet complete …..
> 
> But I don’t understand why GWorkspace menu calls do not work. I thought 
> that GWorkspace only interact with wmaker and these calls are specified?
> 
> Best regards
> 
> Thomas
> 
>> Am 02.04.2024 um 23:25 schrieb Ondrej Florian :
> 
>> Hi Thomas,
> 
>> As GNUstep is platform independent, there is no specific design guideline.
>> Many applications will use menu items, shortcut keys etc. that fit 
>> particular platform (Windows / OS X or Linux)
>> GNUmail or PikoPixel is good example of that.
> 
>> GSDE and Nextspace follow Next/OpenStep design guideline.
>> However, this means an application needs to be tweaked for each 
>> platform/environment either by creating dedicate gorm files or 
>> programmatically.
>> Integration and consistency is one of the reasons why GSDE forked many 
>> common GNUstep applications.
>> GWorkspace.app has not been forked (yet) that's why it still has menus like 
>> "hide other", "show all" or "quit" which do not really do anything useful 
>> in GSDE.
> 
>> I am experimenting with using StepTalk scripts to modify UI to fit GSDE to 
>> avoid forking the code itself but it has its limits.
> 
>> ---
>> As for using ProjectCenter to build source code.
>> I would like to end up with *all* applications in GSDE being directly 
>> build-able from ProjectCenter but that will require a lot of additional 
>> work as many makefiles will have to be rewritten.
> 
>> ...one step at a time ;-)
> 
>> Ondrej
> 
>> On 2024-03-28 10:02:22 +0100 Thomas  wrote:
> 
>>> Hello,
> 
>>> as I play around with GSDE I noticed that there are some differences 
>>> between the usage of the apps.
> 
>>> Does a Design Guideline for GNUstep exists (as Apple has(d))?
> 
>>> So at macos every app from the Finder to the smallest app has the 
>>> (standard) menue points:  hide, hide others, show all.
>>> Here with GNUstep only GWorkspace has this menue entries and by the way on 
>>> my HP prodesk 400 G3 mini with GSDE on Debian hide others doesn´t work, 
>>> it hides GWorkspace itself, the opposite behavior I awaited.
> 
>>> Other (maybe stupid) Question from a newbe: I copied for instance from 
>>> github the zip files from Textedit to my computer to find out wether I can 
>>> open and learn to program the source with Projectcenter and Gorm but I 
>>> can´t find a projectfile like in Xcode.
>>> Do I have to use git how to begin programming existing projects?  Hints 
>>> welcome. :-)
> 
> 
>>> Best regards and Happy Easter!
> 
>>> Thomas
> 
> 
>

Re: General Design Guidelines for GNUstep and apps

[Ondrej Florian]

Hi Thomas,

As GNUstep is platform independent, there is no specific design guideline.
Many applications will use menu items, shortcut keys etc. that fit particular 
platform (Windows / OS X or Linux)
GNUmail or PikoPixel is good example of that.

GSDE and Nextspace follow Next/OpenStep design guideline.
However, this means an application needs to be tweaked for each 
platform/environment either by creating dedicate gorm files or programmatically.
Integration and consistency is one of the reasons why GSDE forked many common 
GNUstep applications.
GWorkspace.app has not been forked (yet) that's why it still has menus like 
"hide other", "show all" or "quit" which do not really do anything useful in 
GSDE.

I am experimenting with using StepTalk scripts to modify UI to fit GSDE to 
avoid forking the code itself but it has its limits.

---
As for using ProjectCenter to build source code.
I would like to end up with *all* applications in GSDE being directly 
build-able from ProjectCenter but that will require a lot of additional work as 
many makefiles will have to be rewritten.

...one step at a time ;-)

Ondrej

On 2024-03-28 10:02:22 +0100 Thomas  wrote:

> Hello,
> 
> as I play around with GSDE I noticed that there are some differences between 
> the usage of the apps.
> 
> Does a Design Guideline for GNUstep exists (as Apple has(d))?
> 
> So at macos every app from the Finder to the smallest app has the (standard) 
> menue points:  hide, hide others, show all.
> Here with GNUstep only GWorkspace has this menue entries and by the way on my 
> HP prodesk 400 G3 mini with GSDE on Debian hide others doesn´t work, it 
> hides GWorkspace itself, the opposite behavior I awaited.
> 
> Other (maybe stupid) Question from a newbe: I copied for instance from github 
> the zip files from Textedit to my computer to find out wether I can open and 
> learn to program the source with Projectcenter and Gorm but I can´t find a 
> projectfile like in Xcode.
> Do I have to use git how to begin programming existing projects?  Hints 
> welcome. :-)
> 
> 
> Best regards and Happy Easter!
> 
> Thomas
>

Re: Installation script

[Ondrej Florian]

Hi Thomas,

Making sure different applications and frameworks play well together was/is my 
main motivation for GSDE.
If you want to see how services / scripting can (or should) all work together, 
GSDE is probably the only place right now.
Support for NSDataLink across all applications is the next ;-)

...there is a lot of cool stuff you can do with it, like using GORM to create 
simple UIs for shell scripts 
Great for creating app wrappers with GNUstep menus and all that stuff.
Or display man pages or gsdoc in the HelpViewer using GNUstep filters.  :-) 

However, in order to make it all work, GSDE has to make a lot of assumptions 
and not everyone is going to be happy with the choices made. Therefore, it is 
not substitute for more generic build/installation script as I explained 
earlier.

The upside is that it makes finding and fixing bugs easier. You have all the 
sources available, everything is configured in the same way, etc.


Thanks,
Ondrej

On 2024-03-11 12:13:58 +0100 Thomas  wrote:

> Hi Ondrej,
> 
> ok, sounds logical.
> One point: Couldn´t it be useful for the normal unexperienced LINUX user to 
> include his „normal“ application menue path from Debian so that his 
> experience wouldn´t be so strange as he find all standard apps he know 
> (LibreOffice etc.)? By the way I have some Questions ;-). The Service parts 
> from the main menue (GWorkspace) don´t work at all, right (for instance 
> starting a new task in Simple Agenda)? Is it a task for Smalltalk (Steptalk)? 
> How can it be fixed?  In Gorm there is the effect that Gorm completely shuts 
> down when you test an unsafed project and try to end this test with shortcut 
> #q…. don´t know the reason. Also the Icons a a little misplaced in the 
> windows…..
> Some glitches are in the presentation in GWorkspace, Gorm etc.  for instance 
> if you have switched to other languages than English the Spaces in the 
> textfields often don´t fit.
> How can I help? ;-).
> 
> Best regards
> 
> Thomas
> 
> 
>> Am 06.03.2024 um 16:33 schrieb Ondrej Florian :
> 
>> Hi Thomas,
> 
>> I'll try to merge some of those changes back into GSDE fork but as both 
>> forks are starting to diverge in significant way, this will become hard to 
>> do down the road.
> 
>> There already few areas that make plain-vanilla WindowMaker not compatible 
>> with GSDE desktop.
>> For example: focus and menu management code, dock and scripting 
>> functionality.
> 
>> Thanks,
>> Ondrej
> 
>> On 2024-03-04 09:04:30 +0100 Thomas  wrote:
> 
>>> Hi Ondrej,
>>> referring to your WM. Your fork is from WindowMaker 0.95.9  How can  I 
>>> update to 0.96 as there are some enhancements in the original?
>>> Best regards
>>> Thomas
>>>> Am 02.03.2024 um 08:37 schrieb Ondrej Florian :
>>>> Hi Nikolaus,
>>>> GSDE install scripts go far beyond just installing GNUstep libraries and 
>>>> build environment.
>>>> Its purpose is to provide complete desktop environment so those scripts 
>>>> pull in a lot of dependencies, etc.
>>>> In addition, these scripts are very "opinionated" as to how everything 
>>>> should be setup and come together.
>>>> For example:
>>>> - hard requirement for X11
>>>> - it comes with its fork of WindowMaker as WM
>>>> - /Application, /Libraries type of directory layout
>>>> - patches for GNUstep libraries
>>>> Considering all of this, dedicated build scripts for GNUstep is still 
>>>> very much needed, especially if you want to do cross-platform 
>>>> development.
>>>> Thanks,
>>>> Ondrej
>>>> On 2024-02-25 00:47:28 + H. Nikolaus Schaller  
>>>> wrote:
>>>>> Nice. Will try asap on different architectures (arm64, armel, armhf, 
>>>>> i386, mipsel) and different Debian flavours.
>>>>> How is it related to https://onflapp.github.io/gs-desktop/index.html 
>>>>> resp. https://github.com/onflapp/gs-desktop which is also a set of 
>>>>> scripts to install GNUstep on Debian systems? Does it also provide some 
>>>>> "Desktop" experience?
>>>>> BR,
>>>>> Nikolaus
>>>>>> Am 24.02.2024 um 23:36 schrieb Ethan Charoenpitaks 
>>>>>> :
>>>>>> Hi everyone,
>>>>>> I've written an installation script for GNUstep, which has been 
>>>>>> tested so far on recent Debian and Ubuntu derivatives. It should be 
>>>>>> easily portable to any distribution, so long as you can determine the 
>>>>

Re: Installation script

[Ondrej Florian]

Hi Nikolaus,

GSDE install scripts go far beyond just installing GNUstep libraries 
and build environment.
Its purpose is to provide complete desktop environment so those 
scripts pull in a lot of dependencies, etc.


In addition, these scripts are very "opinionated" as to how everything 
should be setup and come together.

For example:

- hard requirement for X11
- it comes with its fork of WindowMaker as WM
- /Application, /Libraries type of directory layout
- patches for GNUstep libraries

Considering all of this, dedicated build scripts for GNUstep is still 
very much needed, especially if you want to do cross-platform 
development.


Thanks,
Ondrej

On 2024-02-25 00:47:28 + H. Nikolaus Schaller  
wrote:


Nice. Will try asap on different architectures (arm64, armel, armhf, 
i386, 
mipsel) and different Debian flavours.


How is it related to https://onflapp.github.io/gs-desktop/index.html 
resp. 
https://github.com/onflapp/gs-desktop which is also a set of scripts 
to 
install GNUstep on Debian systems? Does it also provide some 
"Desktop" 
experience?


BR,
Nikolaus

Am 24.02.2024 um 23:36 schrieb Ethan Charoenpitaks 
:



Hi everyone,


I've written an installation script for GNUstep, which has 
been 
tested so far on recent Debian and Ubuntu derivatives. It should be 
easily 
portable to any distribution, so long as you can determine the 
correct 
commands to install all the dependencies and clang-14. It will just 
install 
from source, installing all the files into /usr/GNUstep/System and 
/usr/GNUstep/Local. It's based on @plaurent's gnustep-build scripts 
, but has been heavily 
modified 
to only have one script that applies to all distributions. I would 
appreciate it if anyone would be willing to try it out, or to port 
it to 
other distributions. It is probably also portable to other Unixes, 
but 
might not be applicable to Windows, iOS, or Android.


To install GNUstep from source, please cd to the directory in which 
you 
want to store GNUstep's source code, and run the following script:


wget -qO- 
https://raw.githubusercontent.com/ethanc8/gnustep-build/master/generic/build.sh 
| bash
If you want to customize the installation paramaters (for example, 
to 
install an older version of the libraries, to install from git 
master, or 
to disable the applications), please do the following:



git clone https://github.com/ethanc8/gnustep-build
nano generic/build.sh # Or your favorite text editor
./generic/build.sh
Thanks!



Ethan

Re: Images disappear after Display Resolution Change

[Ondrej Florian]

Hmm, I did some more testing.
Although it does help in some situations, the problem still persists in other 
cases (e.g. NSButton + image)

Anyone has an idea where to look next?

On 2023-12-30 18:21:16 +0100 Tom Sheffler  wrote:

> That looks like a good approach.  FWIW - I have found that the 
> NSApplicationDidChangeScreenParametersNotification
> is also listened for in NSWindow which gets the window’s new NSScreen and 
> (i think) redraws the window.  But I
> couldn’t find anything in NSWindow.m that might trigger image caches being 
> emptied or recalculated.
> 
>> On Dec 30, 2023, at 8:23 AM, Ondrej Florian  wrote:
> 
>> I think I managed to fix the problem by clearing NSImage cache after 
>> receiving NSApplicationDidChangeScreenParametersNotification
> 
>> Please see:
>> https://github.com/onflapp/libs-gui/commit/2b6a26b2f013d79971165abf7b10a56b5e42c619
>> There is still problem with GWorkspace though.
>> Non-scaled icons works fine but scaled icons (e.g. list / browser view) do 
>> not.
> 
> 
>> On 2023-12-29 22:23:45 +0100 Gregory Casamento  
>> wrote:
> 
>>> Would it be possible for you to file a bug for this on GitHub?  The proper
>>> place is https://github.org/gnustep/libs-gui under the “Issues” tab.
> 
>>> Gregory Casamento
>>> GNUstep Lead Developer / OLC, Principal Consultant
>>> http://www.gnustep.org - http://heronsperch.blogspot.com
>>> https://www.patreon.com/bePatron?u=352392 - Become a Patron
>>> https://www.openhub.net/languages/objective_c - OpenHub standings
> 
> 
>>> On Fri, Dec 29, 2023 at 15:58 Paulo Delgado  wrote:
> 
>>>> I noticed something similar happened to me on a clean Debian installation
>>>> whenever the computer came back from sleep. Images and icons were all 
>>>> gone,
>>>> also wallpaper (which gworkspace manages in my installation).
> 
> 
>>>> PD
> 
>>>>> On Dec 29, 2023, at 1:52 PM, Ondrej Florian  wrote:
> 
>>>>> This also happens (sometimes) when you attach external display..
>>>>> It is certainly related to change of display resolution and easily
>>>> reproducible by invoking xrandr.
> 
>>>>> I guess that GNUstep is caching some kind of data that needs to be
>>>> invalidated.
> 
> 
>>>>>> On 2023-12-28 14:25:21 +0100 Sebastian Reitenbach <
>>>> sebas...@l00-bugdead-prods.de> wrote:
> 
>>>>>> Hi,
> 
>>>>>> On Tuesday, December 26, 2023 19:52 CET, Tom Sheffler
>>>>>>  wrote:
> 
>>>>>>> I’ve recently installed gs-desktop (from
>>>> github.com/onflapp/gs-desktop/
>>>>>>> <http://github.com/onflapp/gs-desktop/>) on Debian 12 into a clean
>>>>>>> partition in a System76 laptop.  It all works very nicely as a desktop
>>>>>>> environment.
> 
>>>>>>> I have noticed an annoying problem when I change resolutions - I seem
>>>> to do
>>>>>>> this often: when I plug in an external monitor I size things one way,
>>>> and
>>>>>>> when not connected I size the display another way.  I’ve investigated
>>>> the
>>>>>>> problem, and do not have a good fix. I’m hoping that by sharing my
>>>>>>> experience here someone might be able to shed some light on the
>>>> subject.
> 
> 
>>>>>>> Upon resizing the main screen, icons and images disappear.  The
>>>> commands I
>>>>>>> use are
> 
>>>>>>>- xrandr —output eDP-1 —mode 1400x1050
>>>>>>>- xrandr —output eDP-1 —mode 1600x900
> 
>>>>>>> After changing resolutions, images and icons in the following apps have
>>>>>>> been seen to dissappear
>>>>>>>   - GWorkspace
>>>>>>>   - Gorm
>>>>>>>   - nextspace/Preferences
>>>>>>>   - gs-desktop/Applications/VolMon
>>>>>>>   - gs-desktop/Applications/MountUp
> 
>>>>>>> The picture below shows two versions of GWorkspace FileViewer.  The
>>>> one on
>>>>>>> top is GWorkspace installed “as-is” and shown after changing the
>>>>>>> resolution of the display.  The large icons and the small icons are all
>>>>>>> gone.  They do not reappear after any amount of fiddling with controls
>>>> or
>>>>>>> themes I attempt.
> 
>

Re: Images disappear after Display Resolution Change

[Ondrej Florian]

I think I managed to fix the problem by clearing NSImage cache after receiving 
NSApplicationDidChangeScreenParametersNotification

Please see:
https://github.com/onflapp/libs-gui/commit/2b6a26b2f013d79971165abf7b10a56b5e42c619
 

There is still problem with GWorkspace though.
Non-scaled icons works fine but scaled icons (e.g. list / browser view) do not.


On 2023-12-29 22:23:45 +0100 Gregory Casamento  wrote:

> Would it be possible for you to file a bug for this on GitHub?  The proper
> place is https://github.org/gnustep/libs-gui under the “Issues” tab.
> 
> Gregory Casamento
> GNUstep Lead Developer / OLC, Principal Consultant
> http://www.gnustep.org - http://heronsperch.blogspot.com
> https://www.patreon.com/bePatron?u=352392 - Become a Patron
> https://www.openhub.net/languages/objective_c - OpenHub standings
> 
> 
> On Fri, Dec 29, 2023 at 15:58 Paulo Delgado  wrote:
> 
>> I noticed something similar happened to me on a clean Debian installation
>> whenever the computer came back from sleep. Images and icons were all gone,
>> also wallpaper (which gworkspace manages in my installation).
> 
> 
>> PD
> 
>>> On Dec 29, 2023, at 1:52 PM, Ondrej Florian  wrote:
>>> 
>>> This also happens (sometimes) when you attach external display..
>>> It is certainly related to change of display resolution and easily
>> reproducible by invoking xrandr.
>>> 
>>> I guess that GNUstep is caching some kind of data that needs to be
>> invalidated.
>>> 
>>> 
>>>> On 2023-12-28 14:25:21 +0100 Sebastian Reitenbach <
>> sebas...@l00-bugdead-prods.de> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> On Tuesday, December 26, 2023 19:52 CET, Tom Sheffler
>>>>  wrote:
>>>> 
>>>>> I’ve recently installed gs-desktop (from
>> github.com/onflapp/gs-desktop/
>>>>> <http://github.com/onflapp/gs-desktop/>) on Debian 12 into a clean
>>>>> partition in a System76 laptop.  It all works very nicely as a desktop
>>>>> environment.
>>>> 
>>>>> I have noticed an annoying problem when I change resolutions - I seem
>> to do
>>>>> this often: when I plug in an external monitor I size things one way,
>> and
>>>>> when not connected I size the display another way.  I’ve investigated
>> the
>>>>> problem, and do not have a good fix. I’m hoping that by sharing my
>>>>> experience here someone might be able to shed some light on the
>> subject.
>>>> 
>>>> 
>>>>> Upon resizing the main screen, icons and images disappear.  The
>> commands I
>>>>> use are
>>>> 
>>>>>- xrandr —output eDP-1 —mode 1400x1050
>>>>>- xrandr —output eDP-1 —mode 1600x900
>>>> 
>>>>> After changing resolutions, images and icons in the following apps have
>>>>> been seen to dissappear
>>>>>   - GWorkspace
>>>>>   - Gorm
>>>>>   - nextspace/Preferences
>>>>>   - gs-desktop/Applications/VolMon
>>>>>   - gs-desktop/Applications/MountUp
>>>> 
>>>>> The picture below shows two versions of GWorkspace FileViewer.  The
>> one on
>>>>> top is GWorkspace installed “as-is” and shown after changing the
>>>>> resolution of the display.  The large icons and the small icons are all
>>>>> gone.  They do not reappear after any amount of fiddling with controls
>> or
>>>>> themes I attempt.
>>>> 
>>>>> The bottom FileViewer is a modified copy of GWorkspace that has been
>>>>> changed to add a new menu item called “Redraw” that does a couple of
>>>>> things.  It deletes image caches in various places and then calls
>> [NSApp
>>>>> updateWindows].  This does not immediately fix the images, but after
>>>>> scolling around the images get refreshed as the caches are rebuilt.
>>>>> The two “DIFF” files attached in this message show what code
>>>>> modifications I made to support the “Redraw” menu item.
>>>> 
>>>>> While clearing the caches helps fix the problem, I don’t really believe
>>>>> I’m on totally the right track for a permanent fix across applications.
>>>>> So I’m looking for suggestions or other insights.  Or at least that
>> this
>>>>> info helps someone else one day.
>>>> 
>>>>> ===
>>>> 
>>>>> I”ve also investigated an entirely different track, changing the
>>>>> following line in NSImage.m
>>>>> _cacheMode = NSImageCacheDefault;
>>>>> to
>>>>> _cacheMode = NSImageCacheNever;
>>>> 
>>>>> and rebuilding.  In GWorkspace, this fixes the Large icons, but breaks
>> the
>>>>> Small icons.  It does, however, also fix the module images in the
>>>>> Nextspace/Preferences app so that they do not disappear upon resolution
>>>>> changes.
>>>> 
>>>>> Thanks,
>>>>> T
>>>> 
>>>> just recently, a few weeks ago, I exchanged my desktops Nvidia card,
>> with 2
>>>> monitors (2xHD), with a AMD based graphics car, and a single monitor
>> UWQHD.
>>>> I'm on OpenBSD, using latest gnustep releases, and after suspend/resume
>>>> cycle, I see the same.
>>>> Haven't had time to dig into it, thought might be because of graphics
>> GPU
>>>> driver change, or resolution change etc.
>>>> But it's only GNUstep applications that loose the images, most notably
>>>> GWorkspace.
>>>> 
>>>> Sebastian
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
> 
> 
>

Re: Images disappear after Display Resolution Change

[Ondrej Florian]

This also happens (sometimes) when you attach external display.
It is certainly related to change of display resolution and easily reproducible 
by invoking xrandr.

I guess that GNUstep is caching some kind of data that needs to be invalidated.


On 2023-12-28 14:25:21 +0100 Sebastian Reitenbach 
 wrote:

> Hi,
> 
> On Tuesday, December 26, 2023 19:52 CET, Tom Sheffler 
>  wrote:
> 
>> I’ve recently installed gs-desktop (from github.com/onflapp/gs-desktop/ 
>> ) on Debian 12 into a clean 
>> partition in a System76 laptop.  It all works very nicely as a desktop 
>> environment.
> 
>> I have noticed an annoying problem when I change resolutions - I seem to do 
>> this often: when I plug in an external monitor I size things one way, and 
>> when not connected I size the display another way.  I’ve investigated the 
>> problem, and do not have a good fix. I’m hoping that by sharing my 
>> experience here someone might be able to shed some light on the subject.
> 
> 
>> Upon resizing the main screen, icons and images disappear.  The commands I 
>> use are
> 
>> - xrandr —output eDP-1 —mode 1400x1050
>> - xrandr —output eDP-1 —mode 1600x900
> 
>> After changing resolutions, images and icons in the following apps have 
>> been seen to dissappear
>>- GWorkspace
>>- Gorm
>>- nextspace/Preferences
>>- gs-desktop/Applications/VolMon
>>- gs-desktop/Applications/MountUp
> 
>> The picture below shows two versions of GWorkspace FileViewer.  The one on 
>> top is GWorkspace installed “as-is” and shown after changing the 
>> resolution of the display.  The large icons and the small icons are all 
>> gone.  They do not reappear after any amount of fiddling with controls or 
>> themes I attempt.
> 
>> The bottom FileViewer is a modified copy of GWorkspace that has been 
>> changed to add a new menu item called “Redraw” that does a couple of 
>> things.  It deletes image caches in various places and then calls [NSApp 
>> updateWindows].  This does not immediately fix the images, but after 
>> scolling around the images get refreshed as the caches are rebuilt.
>> The two “DIFF” files attached in this message show what code 
>> modifications I made to support the “Redraw” menu item.
> 
>> While clearing the caches helps fix the problem, I don’t really believe 
>> I’m on totally the right track for a permanent fix across applications. 
>> So I’m looking for suggestions or other insights.  Or at least that this 
>> info helps someone else one day.
> 
>> ===
> 
>> I”ve also investigated an entirely different track, changing the 
>> following line in NSImage.m
>>  _cacheMode = NSImageCacheDefault;
>> to
>>  _cacheMode = NSImageCacheNever;
> 
>> and rebuilding.  In GWorkspace, this fixes the Large icons, but breaks the 
>> Small icons.  It does, however, also fix the module images in the 
>> Nextspace/Preferences app so that they do not disappear upon resolution 
>> changes.
> 
>> Thanks,
>> T
> 
> just recently, a few weeks ago, I exchanged my desktops Nvidia card, with 2 
> monitors (2xHD), with a AMD based graphics car, and a single monitor UWQHD. 
> I'm on OpenBSD, using latest gnustep releases, and after suspend/resume 
> cycle, I see the same.
> Haven't had time to dig into it, thought might be because of graphics GPU 
> driver change, or resolution change etc.
> But it's only GNUstep applications that loose the images, most notably 
> GWorkspace.
> 
> Sebastian
> 
> 
> 
>

Re: Swift calling into GNUStep Progress

[Ondrej Florian]

I am just wondering, would it make sense to make this part of 
https://github.com/onflapp/libs-steptalk ?
I was able to get quite far with it. 
It is even possible to create GUI app now (see 
https://github.com/onflapp/libs-steptalk/blob/master/Examples/AppKit/app.st)

On 2023-08-11 03:35:22 +0200 dr_c...@me.com wrote:

> Hello Friends,
> I just wanted to give you a little update regarding my progress. All of this 
> can also be viewed on my GitHub at 
> 
> NSObjects and Subclassing
> I have two classes that help bridge Swift classes to Objective-C (1) 
> GNUStepNSObjectWrapper and (2) GNUStepNSObjectSubclassConstructor. The former 
> is used to simply wrap Objective-C NSObjects and the latter is used to 
> register subclasses with the GNUStep Objective-C runtime. All classes crated 
> with GNUStepNSObjectSubclassConstructor get a special Ivar '___swiftPtr ' 
> intended to hold a reference back the Swift. Once you use 
> GNUStepNSObjectSubclassConstructor to create a new subclass, you can then 
> wrap  it using GNUStepNSObjectWrapper.
> I've actually had to do this already, within the Swift AppKit API, I've 
> subclassed NSButton as "NSButtonForSwift" but expose it as NSButton to the 
> Swift API. This allows me to use closures instead of target/selectors.
> I don not currently like how I am using ___swiftPtr to hold a reference to 
> the Swift object created with any class registered with 
> GNUStepNSObjectSubclassConstructor, but it is the best solution I could come 
> up keep track of who owns the Objective-C object.
> I understand that on Apple platforms, Swift actually emits Objective-C 
> compatible Swift objects when @objc or inheriting from NSObject occurs, which 
> allows them casted on either side correctly.
> NSString, NSArray and NSDictionary are all going to be problematic types 
> because there is currently no way to share storage like in Apple's Swift 
> implementation. I think that some work needs to be done here to figure this 
> out. That is beyond my abilities. For now, I am just going to be copying data 
> between them.
> 
> Currently, variables for like NSButton 'var title: String' take a String type 
> and I just convert between NSString when getting and setting (I wish we could 
> offer both, but Swift doesn't allow that) ; but when we have functions like 
> "func setTitle(string: String)" I plan to also offer "func setTitle(string: 
> NSString)" so we do not have to do any copying.
> Additionally, NSArray and NSDictionary are only going to be able to store 
> Objective-C types. On Apple Platforms,
> 
> Regarding Sending Messages / Calling Method: I've to figure out how to use 
> objc_msgSend and objc_msgSend_stret from Swift, so instead I am now using 
> class_getMethodImplementation. Which has been incredibly successful. I 
> created some helper swift functions called objc_smart_getIMP to aid in 
> setting these up better.
> API Bridging Update:
> I've gotten some of the the GUI objects going: NSWindow, NSButton, NSImage, 
> NSImageView, NSFont, NSColor. You can get and set frames. It's pretty cool.
> 
> 
> 
> 
> 
>> On Aug 8, 2023, at 8:56 PM, dr_c...@me.com wrote:
> 
>> UPDATE: SUCCESS!
> 
>> Since I sent that last email. I had a little break through.
>> Then GNUStep ObjC function class_getMethodImplementation (Apple also has 
>> function class_getMethodImplementation_stret that is evidently not used in 
>> GNUStep and is just a stub) and allows one to look up the C function that 
>> is precisely used with the function.
>> So I created a nice Swift version of this lookup. public func 
>> objc_smart_getIMP(object: GNUStepNSObjectWrapper, selector: String) -> 
>> T? {
>>  let c = object_getClass(_nsobjptr!.pointee)
>>  let v = class_getMethodImplementation(c, sel_getUid(selector))
>>  let rt: T? = unsafeBitCast(v, to: T.self)
>>  return rt
>> }
> 
>> And then in the the var frame property of my NSView wrapper the following 
>> public var frame: CGRect {
>>  get {
>>  var imp:  (@convention(c) (id, SEL) -> (CGRect))? = 
>> objc_smart_getIMP(object: self, selector: "frame")
>>  if let rtn = imp?(_nsobjptr!.pointee, 
>> sel_getUid("frame")) {
>>  return rtn
>>  }
>>  return .init(x: 0, y: 0, width: 0, height: 0)
>>  }
>>  set {
>>  guard let selfPtr = self._nsobjptr else {return}
>>  let _: Any? = objc_smart_sendMessage(object: self, 
>> selector: 
>> "setFrame:", value1: newValue)
>>  }
>> }
> 
>> RESULT: It worked!
> 
>> When Swift Macros are working on Linux, this could be a Macro that 
>> generates everything we need. Maybe @GNUStepPropertyWrapper("frame", 
>> "getFrame") We could also have @GNUStepMethodWrapper that automatically 
>> wraps the method callers.
> 
> 
>>> On Aug 8, 2023, at 7:48 PM, dr_c...@me.com 

Re: GNUstep Desktop

[Ondrej Florian]

Hi Svetlana,

GNUstep Desktop requires a lot of system dependecies and specific 
system configuration.

It will not run properly unless you install it as root.
Furthermore, be aware it might conflict with existing objc runtime / 
GNUstep or other libraries on your sytem.
It has always been intended to be installed as the main desktop 
environment with specific set of dependencies.


The best way to try it is to install it in its own VM (e.g. using 
virtualbox).


Ondrej

On 2023-05-26 01:23:32 +0200 Svetlana Tkachenko 
 wrote:


I would like to try this on my debian laptop, but without interfering 
with 
the rest of the OS. I could do that in a new OS user called 'gsde', 
for 
example. Could you please guide me how this could be done? I've read 
README.md and it says "sudo -E ./build_world.sh", and I would like to 
avoid 
installing things as root. (I see no problem with installing 
additional 
debian packages as root if needed.)

Re: GNUstep Desktop

[Ondrej Florian]

Done! :-)

Thank you Philippe.

On 2023-05-24 09:14:24 + p.o.rous...@free.fr wrote:

> Hi Ondrej,
> 
> This is great work, congratulations !
> 
> May I suggest including SimpleAgenda 
> (https://github.com/poroussel/simpleagenda) ? I'm far from being an active 
> maintainer but the application should be useful as is and if modifications 
> are needed I'll be happy to merge them..
> 
> Thanks,
> Philippe
> 
> ----- Mail original -
>> De: "Ondrej Florian" 
>> À: "discuss-gnustep" , info-gnus...@gnu.org
>> Envoyé: Dimanche 21 Mai 2023 02:38:21
>> Objet: GNUstep Desktop
> 
>> Hi everyone,
> 
>> I'd like to announce GNUstep Desktop.
>> https://onflapp.github.io/gs-desktop/index.html
> 
>> I have been working on it for more than a year now and it is finally
>> complete enough to be my main desktop environment.
>> It is perfect for my Raspberry PI! :-)
> 
>> GSDE contains many GNUstep apps and frameworks in one place.
>> Enhanced, fixed, configured and integrated so that everything works
>> together seamlessly.
> 
>> Notable enhancements:
>> - StepTalk   - used for system scripting, fixes and
>> enhancements to the API
>> - TextEdit- scriptable + enhancements for attachment
>> and link panels
>> - HelpViewer - uses filters to display man, info and gsdoc
>> pages
>> - WrapperFactory - greatly enhanced, support for filters and services
>> - Terminal   - a lot of improvements, refactored into Kit,
>> scriptable
>> - Preferences- taken from NEXTSPACE + additional settings for
>> timezone, keys, themes
>> - WindowMaker- make tweaks and fixes to fit with GNUstep
> 
>> New applications:
>> - WebBrowser   - Google Chrome with GNUstep UI, scriptable
>> - VimGS - Vim with GNUstep UI (using TerminalKit),
>> scriptable
>> - Player  - VLC with GNUstep UI, scriptable
>> - DocViewer - PDF and HTML document viewer, filters for
>> additional formats (e.g. markdown), scriptable
>> - ImageViewer  - filter for additional formats, scriptable
>> - RemoteView   - VNCViewer
>> - Librarian - document indexing - similar to NeXT's
>> Digital Librarian
>> - ScreenShot- screenshot service
> 
>> Other apps:
>> Gorm and ProjectCenter, GWorkspace, GNUMail
> 
>> Other utilities:
>> Dictionary, Affiche, FTP, TalkSoup, EdenMath, Addresses
>> ForManager, DefaultsManager, Console, HtopGS, OpenUp,
>> Process monitor, Volume and Battery controls.
> 
>> ...and more
> 
>> WebPage: https://onflapp.github.io/gs-desktop/index.html
>> github: https://github.com/onflapp/gs-desktop
> 
>> ---
> 
>> Spending weeks and months deep in GNUstep and all those apps created
>> with it,
>> made me really appreciate all the amazing work that went into it.
> 
>> I hope that GNUstep Desktop will help to renew the interest in GNUstep
>> as desktop.
> 
>> Ondrej
> 
>

Re: GNUstep Desktop

[Ondrej Florian]

Absolutely.
I don't consider GNUstep Desktop to be the final place of maintenance.

GSDE is an experiment. It allows you to test and see how complete 
desktop system *could* work like.
That's why everything is in one place and it is easy to build from 
scratch.


I do not follow strict release process.
It moves fast but it also breaks fast!

Once an app or framework reaches maturity, it should be cleaned up and 
moved over to GAP or other appropriate place.


I hope this makes sense,
Ondrej

On 2023-05-21 11:10:10 + Fred Kiefer  wrote:

One question though: Would it be possible to merge back the forked 
applications (Addresses and BatMon) to GAP? If you two need a tie 
breaker to 
decide on which version to use, I am willing to volunteer.


Cheers
Fred
Am 21.05.2023 um 02:38 schrieb Ondrej Florian via Info-gnustep 
:



Hi everyone,



I'd like to announce GNUstep Desktop.
https://onflapp.github.io/gs-desktop/index.html


I have been working on it for more than a year now and it is finally 
complete enough to be my main desktop environment.

It is perfect for my Raspberry PI! :-)



GSDE contains many GNUstep apps and frameworks in one place.
Enhanced, fixed, configured and integrated so that everything works 
together seamlessly.



Notable enhancements:
- StepTalk   - used for system scripting, fixes and 
enhancements to the API
- TextEdit- scriptable + enhancements for attachment 
and 
link panels
- HelpViewer - uses filters to display man, info and gsdoc 
pages

- WrapperFactory - greatly enhanced, support for filters and services
- Terminal   - a lot of improvements, refactored into 
Kit, 
scriptable
- Preferences- taken from NEXTSPACE + additional settings 
for 
timezone, keys, themes

- WindowMaker- make tweaks and fixes to fit with GNUstep



New applications:
- WebBrowser   - Google Chrome with GNUstep UI, scriptable
- VimGS - Vim with GNUstep UI (using TerminalKit), 
scriptable

- Player  - VLC with GNUstep UI, scriptable
- DocViewer - PDF and HTML document viewer, filters for 
additional 
formats (e.g. markdown), scriptable

- ImageViewer  - filter for additional formats, scriptable
- RemoteView   - VNCViewer
- Librarian - document indexing - similar to NeXT's 
Digital 
Librarian

- ScreenShot- screenshot service



Other apps:
Gorm and ProjectCenter, GWorkspace, GNUMail



Other utilities:
Dictionary, Affiche, FTP, TalkSoup, EdenMath, Addresses
ForManager, DefaultsManager, Console, HtopGS, OpenUp,
Process monitor, Volume and Battery controls.



...and more



WebPage: https://onflapp.github.io/gs-desktop/index.html
github: https://github.com/onflapp/gs-desktop



---


Spending weeks and months deep in GNUstep and all those apps created 
with 
it,

made me really appreciate all the amazing work that went into it.


I hope that GNUstep Desktop will help to renew the interest in 
GNUstep as 
desktop.



Ondrej





___
Info-gnustep mailing list
info-gnus...@gnu.org
https://lists.gnu.org/mailman/listinfo/info-gnustep

Re: GNUstep Desktop

[Ondrej Florian]

My vision is for GSstep Desktop to be available as source.
Something you can easily tinker and experiment with.

Imagine browsing all the code in ProjectCenter.
GORM to edit UI.
Documentation fully indexed and available in the HelpViewer.
(it's never going to be Smalltalk system, but why not try to replicate 
the experience ;-)


GNUstep + all supporting code is incredibly compact.
This makes is unique when compared to other desktop environments today.

-

Having said that, anyone is free to create deb packages and distribute 
it that way.

Live CD would certainly be nice.

Ondrej

On 2023-05-21 09:04:31 + Svetlana Tkachenko 
 wrote:



There is also TalkSoup, an IRC client.

Would be nice to have a gsde task  package for debian, then it will 
be 
available for download as a live cd?

Re: GNUstep Desktop

[Ondrej Florian]

Yes, GNUstep Desktop would not be possible without XEmbed! :-)

It allowed me to add a lot of functionality quickly and do some "impossible" 
things.
For example: RemoveView.app uses SDL2 + vnc client library to do the actual 
remove viewing part.
Trying to combine it in one process with GNUstep proved impossible. You've got 
competing event loops, SDL uses a lot of globals, etc. etc. 
With XEmbed - easy. AND you can add basic support for RDP in a day using the 
same approach ;-)

Obviously this makes it all very, very XWindow dependent.
It is not "pure" solution, it is very utilitarian.

But that was the chance I was willing to take and the result is surprising.

Thanks,
Ondrej

On 2023-05-21 03:33:24 + Gregory Casamento  wrote:

> Hey,  I want to be the first to say that this is pretty cool.  I like the
> use of XEmbed to give apps the look of GNUstep.   This is great work!
> 
> 
> On Sat, May 20, 2023 at 8:39 PM Ondrej Florian  wrote:
> 
>> Hi everyone,
> 
>> I'd like to announce GNUstep Desktop.
>> https://onflapp.github.io/gs-desktop/index.html
> 
>> I have been working on it for more than a year now and it is finally
>> complete enough to be my main desktop environment.
>> It is perfect for my Raspberry PI! :-)
> 
>> GSDE contains many GNUstep apps and frameworks in one place.
>> Enhanced, fixed, configured and integrated so that everything works
>> together seamlessly.
> 
>> Notable enhancements:
>> - StepTalk   - used for system scripting, fixes and
>> enhancements to the API
>> - TextEdit- scriptable + enhancements for attachment
>> and link panels
>> - HelpViewer - uses filters to display man, info and gsdoc
>> pages
>> - WrapperFactory - greatly enhanced, support for filters and services
>> - Terminal   - a lot of improvements, refactored into Kit,
>> scriptable
>> - Preferences- taken from NEXTSPACE + additional settings for
>> timezone, keys, themes
>> - WindowMaker- make tweaks and fixes to fit with GNUstep
> 
>> New applications:
>> - WebBrowser   - Google Chrome with GNUstep UI, scriptable
>> - VimGS - Vim with GNUstep UI (using TerminalKit),
>> scriptable
>> - Player  - VLC with GNUstep UI, scriptable
>> - DocViewer - PDF and HTML document viewer, filters for
>> additional formats (e.g. markdown), scriptable
>> - ImageViewer  - filter for additional formats, scriptable
>> - RemoteView   - VNCViewer
>> - Librarian - document indexing - similar to NeXT's
>> Digital Librarian
>> - ScreenShot- screenshot service
> 
>> Other apps:
>> Gorm and ProjectCenter, GWorkspace, GNUMail
> 
>> Other utilities:
>> Dictionary, Affiche, FTP, TalkSoup, EdenMath, Addresses
>> ForManager, DefaultsManager, Console, HtopGS, OpenUp,
>> Process monitor, Volume and Battery controls.
> 
>> ...and more
> 
>> WebPage: https://onflapp.github.io/gs-desktop/index.html
>> github: https://github.com/onflapp/gs-desktop
> 
>> ---
> 
>> Spending weeks and months deep in GNUstep and all those apps created
>> with it,
>> made me really appreciate all the amazing work that went into it.
> 
>> I hope that GNUstep Desktop will help to renew the interest in GNUstep
>> as desktop.
> 
>> Ondrej
> 
> 
> 
> 
>

GNUstep Desktop

[Ondrej Florian]

Hi everyone,

I'd like to announce GNUstep Desktop.
https://onflapp.github.io/gs-desktop/index.html

I have been working on it for more than a year now and it is finally 
complete enough to be my main desktop environment.

It is perfect for my Raspberry PI! :-)

GSDE contains many GNUstep apps and frameworks in one place.
Enhanced, fixed, configured and integrated so that everything works 
together seamlessly.


Notable enhancements:
- StepTalk   - used for system scripting, fixes and 
enhancements to the API
- TextEdit- scriptable + enhancements for attachment 
and link panels
- HelpViewer - uses filters to display man, info and gsdoc 
pages

- WrapperFactory - greatly enhanced, support for filters and services
- Terminal   - a lot of improvements, refactored into Kit, 
scriptable
- Preferences- taken from NEXTSPACE + additional settings for 
timezone, keys, themes

- WindowMaker- make tweaks and fixes to fit with GNUstep

New applications:
- WebBrowser   - Google Chrome with GNUstep UI, scriptable
- VimGS - Vim with GNUstep UI (using TerminalKit), 
scriptable

- Player  - VLC with GNUstep UI, scriptable
- DocViewer - PDF and HTML document viewer, filters for 
additional formats (e.g. markdown), scriptable

- ImageViewer  - filter for additional formats, scriptable
- RemoteView   - VNCViewer
- Librarian - document indexing - similar to NeXT's 
Digital Librarian

- ScreenShot- screenshot service

Other apps:
Gorm and ProjectCenter, GWorkspace, GNUMail

Other utilities:
Dictionary, Affiche, FTP, TalkSoup, EdenMath, Addresses
ForManager, DefaultsManager, Console, HtopGS, OpenUp,
Process monitor, Volume and Battery controls.

...and more

WebPage: https://onflapp.github.io/gs-desktop/index.html
github: https://github.com/onflapp/gs-desktop

---

Spending weeks and months deep in GNUstep and all those apps created 
with it,

made me really appreciate all the amazing work that went into it.

I hope that GNUstep Desktop will help to renew the interest in GNUstep 
as desktop.


Ondrej

Re: GNUMail running on macOS 12.6 (Apple Silicon)

[Ondrej Florian]

Hi Riccardo,

I tried out the version from the svn.
It still doesn't work right.
No errors in the console (BTW: the console is next to useless for 
debugging, I had to add my own logs to see what's really happening ;-)


However, I am getting different behaviour now.
The cache file grows up to 90G! in very short time.
Maybe an overflow somewhere?

I have less then 100 messags in my imap, all from this newsgroup.

I am testing on x86 64bit.

---
As for the attachment "bug", this is not GNUmail related.

I forked and added attachment capability to the TextEdit + some more 
fixes and enhacements

(https://github.com/onflapp/gs-textedit)

It is impossible to open attachment by double-clicking.
The double-click just selects text and that's it.

Thanks,
Ondrej

On 2022-10-15 01:31:26 +0200 Riccardo Mottola 
 wrote:



Hi Ondrej,

Ondrej Florian wrote:



The result is the same.
IMAP seems to get only half of all messages in a folder.
fetch never finishes because it seems like the messages IDs do not 
correspond to the request IDs (?)


That is very strange. Any error in the console?



I am using yahoo.com IMAP server.
Body/content of the message doesn't seem to make a difference.


Oh, I just asked, I have some messages that do not load on Mac, but 
do load 
on GNUstep. I tried to have a look, but without success.


On GNUstep I think you experience issues with saving attachments, I 
noticed 
you supplied a PR for multiple clicks. However, a single click should 
be 
sufficient.


Please test my new PR:
https://github.com/gnustep/libs-gui/tree/AttachmentIndexFix

It does wonders for me and fixes a nuisance that bugged me for years.


I can send you log of all requests and responses, if this helps.



BTW: what source do you use? Maybe I am using the wrong one.


Current development is "unofficially" forked and happens here:
http://svn.savannah.gnu.org/viewvc/gnustep-nonfsf/

|svn co svn://svn.savannah.nongnu.org/gnustep-nonfsf
|
As you happen, update, since I committed a fix on GNUMail about store 
memory 
management which needs to be tested.


||


(Florian is my last name ;-)


Oh, sorry. Florian is also a perfect surname, a full-fledged Saint 
protecting 
from fires. So hard to tell.


Riccardo

Re: GNUMail running on macOS 12.6 (Apple Silicon)

[Ondrej Florian]

Hi Riccardo,

Many thanks for following this up.
I tried on different setups myself, x86 both 32 and 64bit, ARM 32 and 
64bit.


The result is the same.
IMAP seems to get only half of all messages in a folder.
fetch never finishes because it seems like the messages IDs do not 
correspond to the request IDs (?)


I am using yahoo.com IMAP server.
Body/content of the message doesn't seem to make a difference.

I can send you log of all requests and responses, if this helps.

BTW: what source do you use? Maybe I am using the wrong one.

Many thanks,
Ondrej
(Florian is my last name ;-)

On 2022-10-09 16:10:19 + Riccardo Mottola 
 wrote:



Hi Florian

I test GNUMail on Intel 32 & 64 and PPC 32 quite extensively in a 
rainy 
sunday, I recompiled current on ARM to test.


On 2022-09-26 15:24:01 +0100 Ondrej Florian  wrote:


I had problems with both POP and IMAP (yahoo and google)
The POP3 problem was related to working with large emails (e.g. more 
than 
5M)
I solved it by rewriting the code which splits the lines using 
memcpy.



POP3 works fine for me.


I admit I don't test POP3 since quite some time, I case I'd need to 
setup an 
account somehow.
However both local as IMAP maiboxes for me handle also very big 
messages, 
like 20MB or 25MB complete of attachments, the message loads and the 
attachment is saved. Also I can copy the message from one to the 
other 
mailbox. So I doubt it is a size issue?

Or is the code you rewrote specific to POP3, please point me to it.




IMAP gets confused while fetching email body.
I am still trying to track this down.


I use IMAP extensively and have no big issues, perhaps it is a 
specific 
message that confuses GNUMail? In the past I tracked down many issues 
down to 
specific content. If the problem is replicable on certain specific 
emails and 
maybe not with the one before or after in your mailbox, let's try to 
investigate.



BTW: I am sending this from GNUMail


me too, this time from ARM, just to test.

Riccardo

Re: WindowMaker fork made for GNUstep

[Ondrej Florian]

Hi Gregory,

Done! :-)

You can drag app icons from GWorkspace to create dock buttons.

It is limited to .app extensions only now, but it could be enhanced to handle 
files and folders in the future.
WMaker expects dock icon to be an executable in order to track its status (e.g. 
running) or to handle drag With files & folders this would have to be 
handled differently.

Anyway, hopefully you'll find this useful.

Ondrej 

On 2022-06-06 01:43:59 +0200 Gregory Casamento  wrote:

> Sweet!!   One suggestion I have had for a while is to implement the ability
> to add apps from gsworkspace.  That is to be able to drag an app into the
> doc from the file system when it is NOT running.
> 
> There are a number of other “misses” when it comes to WindowMaker but that
> is a major one.
> 
> On Sun, Jun 5, 2022 at 11:36 Ondrej Florian  wrote:
> 
>> Hi everyone,
> 
>> I forked WindowMaker to make it make it more GNUstep friendly. My goal
>> is to end up with a window manager that provides the best user
>> experience for GNUstep applications. I "ported" some fixes from
>> Nextspace project and added some of my own.
> 
>> Noteble changes include:
> 
>> - fixing GNUstep menus (make sure only one menu is visible at a time)
>> - fixing "hide" application command (as implemented in Nextspace)
>> - launch on startup (as implemented in Nextspace)
>> - use the same look and feel as GNUstep
>> - implement/fix dock drop functionality
> 
>> If you are interested, please feel free to take a look or even
>> contribute ;-)
> 
>> https://github.com/onflapp/gs-wmaker
> 
>> Thanks
> 
> 
>> --
> Gregory Casamento
> GNUstep Lead Developer / OLC, Principal Consultant
> http://www.gnustep.org - http://heronsperch.blogspot.com
> https://www.patreon.com/bePatron?u=352392 - Become a Patron
> https://gf.me/u/x8m3sx - My GNUstep GoFundMe
> https://teespring.com/stores/gnustep - Store
>

Re: GNUMail running on macOS 12.6 (Apple Silicon)

[Ondrej Florian]

On 2022-09-26 16:04:09 +0200 Riccardo Mottola 
 wrote:


Hi Riccardo,

I had problems with both POP and IMAP (yahoo and google)
The POP3 problem was related to working with large emails (e.g. more 
than 5M)

I solved it by rewriting the code which splits the lines using memcpy.

POP3 works fine for me.

IMAP gets confused while fetching email body.
I am still trying to track this down.

BTW: I am sending this from GNUMail


Hi,


On 2022-09-26 12:05:41 + Ondrej Florian  wrote:


Hi Hugo,



I am working on GNUMail extensively myself.
Just currious, did you get IMAP working?



I got POP3 working after some patching but IMAP is still problematic.


that is strange, both work since a long time and I use IMAP with 
GNUmail 
since years, even for reading and composing this right mail.


Support for attachment is still hit and miss. For example your 
message only 
shows as text.


That is, I fear, easily explained. Florian's message was written with 
Apple's 
Mail and the the message is HTML, which GNUMail does not support and 
won't in 
the near possible future. GNUMail supports Text and RTF. So it 
switches to 
the Text mail part, but somehow misses to display the attachments, 
which are 
not inline anymore. Tricky thing I fear.

Mozilla SeaMonkey handles it correctly instead.


Riccardo

WindowMaker fork made for GNUstep

[Ondrej Florian]

Hi everyone,

I forked WindowMaker to make it make it more GNUstep friendly. My goal 
is to end up with a window manager that provides the best user 
experience for GNUstep applications. I "ported" some fixes from 
Nextspace project and added some of my own.


Noteble changes include:

- fixing GNUstep menus (make sure only one menu is visible at a time)
- fixing "hide" application command (as implemented in Nextspace)
- launch on startup (as implemented in Nextspace)
- use the same look and feel as GNUstep
- implement/fix dock drop functionality

If you are interested, please feel free to take a look or even 
contribute ;-)


https://github.com/onflapp/gs-wmaker

Thanks