Re: Bugs in gui/back

[Riccardo Mottola]

Hi,

Andreas Höschler wrote:
this looks pretty much like the bug I am encountering with Unity 
window manager on Ubuntu 16.04. Any news regarding this? Now that I 
have figured out the fragile/non-fragile issue that caused seg fault 
crashes I am motivated to move forward with the project. Luckily 
Window Maker does not seems to suffer from the bug. But it would be 
great to see this fixed anyway. :-)


just for your "info" i have seen this happening in the past 
intermittently also on WindowMaker, but then it goes away at another 
rebuild or X11 restart and then seems to stay "stable".
I have seen this happen again and again in the past, only in certain 
windows, most notably those with a tab view. GWorkspace seems to suffer 
from it and also Gorm's palette. but not all apps.


However (crossing fingers) currently I am not encountering it anywhere.

Riccardo

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Andreas Höschler]

Hi all,

this looks pretty much like the bug I am encountering with Unity window manager 
on Ubuntu 16.04. Any news regarding this? Now that I have figured out the 
fragile/non-fragile issue that caused seg fault crashes I am motivated to move 
forward with the project. Luckily Window Maker does not seems to suffer from 
the bug. But it would be great to see this fixed anyway. :-)

Best wishes,

 Andreas


> On 20 May 2018, at 13:06, Ivan Vučica  wrote:
> 
> To add to this:
> 
> Stjepan ran into something that reminds me of this bug when running 
> SystemPreferences:




> 
> 
> This is on stock Ubuntu 16.04 under stock Unity window manager, which should 
> make it easy to test for this bug.
> 
> On Wed, May 2, 2018 at 11:09 AM Andreas Höschler  > wrote:
> Hi Fred and all,
> 
>> Here comes my tiny test application. It is about the minimal code that
>> is needed to test this behaviour. A minimal GNUmakefile for this would
>> look something like this:
> 
> After successfully setting up Ubuntu 16 with Window Maker I was able to 
> recheck your test app. It behaves correctly under Window Maker:
> 
>   openapp ./resize.app &> A.out.
> 
> 2018-05-02 12:05:04.413 resize[3378:3378] styleoffsets ... guessing offsets
> 2018-05-02 12:05:04.414 resize[3378:3378] styleoffsets ... guessing offsets
> 2018-05-02 12:05:04.529 resize[3378:3378] Content view set frame to {x = 1; y 
> = 9; width = 140; height = 140}
> 
> Now resizing the window ...
> 
> 2018-05-02 12:05:08.426 resize[3378:3378] Content view set frame to {x = 1; y 
> = 9; width = 149; height = 140}
> 2018-05-02 12:05:08.426 resize[3378:3378] Content view set frame to {x = 1; y 
> = 9; width = 149; height = 140}
> 
> Looks good!
> 
> So the issue is somehow related to this Ubuntu ubity stuff. No problem for me 
> as we want to and can run Window Maker anyway.
> 
> Thanks a lot,
> 
>  Andreas
> 
> ___
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep 
> 


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Ivan Vučica]

To add to this:

Stjepan ran into something that reminds me of this bug when running
SystemPreferences:
[image: cef8e878-85b2-4672--636cc90c792f.png]
×


This is on stock Ubuntu 16.04 under stock Unity window manager, which
should make it easy to test for this bug.

On Wed, May 2, 2018 at 11:09 AM Andreas Höschler 
wrote:

> Hi Fred and all,
>
> Here comes my tiny test application. It is about the minimal code that
> is needed to test this behaviour. A minimal GNUmakefile for this would
> look something like this:
>
>
> After successfully setting up Ubuntu 16 with Window Maker I was able to
> recheck your test app. It behaves correctly under Window Maker:
>
> openapp ./resize.app &> A.out.
>
> 2018-05-02 12:05:04.413 resize[3378:3378] styleoffsets ... guessing offsets
> 2018-05-02 12:05:04.414 resize[3378:3378] styleoffsets ... guessing offsets
> 2018-05-02 12:05:04.529 resize[3378:3378] Content view set frame to {x =
> 1; y = 9; width = 140; height = 140}
>
> Now resizing the window ...
>
> 2018-05-02 12:05:08.426 resize[3378:3378] Content view set frame to {x =
> 1; y = 9; width = 149; height = 140}
> 2018-05-02 12:05:08.426 resize[3378:3378] Content view set frame to {x =
> 1; y = 9; width = 149; height = 140}
>
> Looks good!
>
> So the issue is somehow related to this Ubuntu ubity stuff. No problem for
> me as we want to and can run Window Maker anyway.
>
> Thanks a lot,
>
>  Andreas
>
> ___
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
>
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Andreas Höschler]

Hi Fred and all,

> Here comes my tiny test application. It is about the minimal code that
> is needed to test this behaviour. A minimal GNUmakefile for this would
> look something like this:

After successfully setting up Ubuntu 16 with Window Maker I was able to recheck 
your test app. It behaves correctly under Window Maker:

openapp ./resize.app &> A.out.

2018-05-02 12:05:04.413 resize[3378:3378] styleoffsets ... guessing offsets
2018-05-02 12:05:04.414 resize[3378:3378] styleoffsets ... guessing offsets
2018-05-02 12:05:04.529 resize[3378:3378] Content view set frame to {x = 1; y = 
9; width = 140; height = 140}

Now resizing the window ...

2018-05-02 12:05:08.426 resize[3378:3378] Content view set frame to {x = 1; y = 
9; width = 149; height = 140}
2018-05-02 12:05:08.426 resize[3378:3378] Content view set frame to {x = 1; y = 
9; width = 149; height = 140}

Looks good!

So the issue is somehow related to this Ubuntu ubity stuff. No problem for me 
as we want to and can run Window Maker anyway.

Thanks a lot,

 Andreas

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Andreas Höschler]

Hi all,

it seems my encountered problems were due to choosing the wrong ubuntu image 
(AMD instead of i386). I just tried it one again with Ubuntu 16.04 (i386 ISO) 
and am now after doing

apt-get install ntp
apt-get install openssh-server
apt-get install build-essential
apt-get install wmaker

 logged in into a WIndow Maker session. I can not continue to check out the 
gui/back issue now ...

Thanks a lot (so far),

 Andreas



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Andreas Höschler]

Hi Liam,

thanks for all your responses and tips:

> If you are running a beta of 18.04, the forthcoming LTS version, then
> again, it's GNOME 3 and Clutter under Wayland.


I - in the meanwhile - installed the newest version of VirtualBox on a Mac and 
into that as a guest OS the newest version of Ubuntu 18.04 TLS. I could do

apt install wmaker

but am not offerered window maker as an option on the login page!? :-(

They again changed everything. /etc/network/interfaces no longer works. They 
have invented just another theme to configure network interfaces.

pico /etc/netplan/01-network-manager-all.yaml

"networkd" does not work for me

network:
  version: 2
  renderer: networkd
 ethernets:
   enp0s3:
 dhcp4: no
 dhcp6: no
 addresses: [192.168.2.198/24]
 gateway4: 192.168.2.1
 nameservers:
   addresses: [8.8.8.8,8.8.4.4]


root@RetinaUbuntu18:~# netplan apply
Invalid YAML at //etc/netplan/01-network-manager-all.yaml line 4 column 1: did 
not find expected key

I also tried

network:
  version: 2
  renderer: NetworkManager

but wasn't able to start NetworkManager to setup a static network interface and 
dns-severs.

sudo NetworkManager

No error message but it happens nothing. If I simply say

NetworkManager

in a terminal session I get "You must be root to run NetworkManager". I tried 
to login as root into a gui session (root passwd is set and working) but not 
even that works "Sorry, that didn't work. Please try again".

In the meanwhile I spent days on getting Ububntu 16 ... 18 to work under 
VirtualBox (and possibly Window Maker) to test out the gui/back issue but am 
failing badly. :-( I will probably try my luck with other Linux distros now  ...

I am still looking for (or trying to assemble) a step by step tutorial to setup 
a GNUstep system from scratch on current hardware and current Linux releases. 
No luck at all. I am at zereo. This should be easier in 2018!? 

Best wishes,

 Andreas



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Riccardo Mottola]

Hi,

On 2018-04-30 16:27:07 + Andreas Höschler  wrote:


> How can this be enabled? Never heard of that and don't know if this is 
> relevant for me (my problem)!?

The two options to play with are:

For  window maker, in its preferences, Window Handling Preferences "Opaque 
Resize"

For GNUstep, GSUseGhostResize (with split views only though). You can set it 
with SystemPreferences.
I think to remember there was a second setting, but I don't find it, maybe it 
was removed.

Riccardo


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Andreas Höschler]

Hi Riccardo,

> On 30 Apr 2018, at 18:16, Riccardo Mottola  wrote:
> 
> Actually I forgot to check if I have live window resizing enabled or not... 
> because you have to enable it in windowmaker and GNUstep IIRC. correctly.

How can this be enabled? Never heard of that and don't know if this is relevant 
for me (my problem)!? 

Thanks,

 Andreas


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Riccardo Mottola]

Hi Andreas,

Andreas Höschler wrote:

Thus... there must be something specific on your side.


On the specific machine preinstalled with Ubuntu 16 I always got 
"System program problem detected" panels after logging in. When I 
click on "Reprot problem" it says "Please enter your password to 
access problem reports of systems programs". I thought that was due to 
a smashed installation. But I installed Ubuntu 16.04 from scratch on a 
VirtualBox virtual machine in the meanwhile to sort out the reported 
GNUstep problems and got the same error panels there as well. So this 
really seems to be a generic Ubuntu 16 problem (not machine or 
installation related). Do you get those as well?




No I get no such error!

How did you install Window Maker on your Ubuntu 16? I would like to 
give Freds test program a try under Window Maker to see whether it 
also shows the wrong behaviour.


I just installed it from the repositories, offical package, with 
apt-get! I don't remember if I had to tweak the sesion myself or not: 
but I get to the standard ubuntu login panel and then after logging in I 
get into windowmaker.


Actually I forgot to check if I have live window resizing enabled or 
not... because you have to enable it in windowmaker and GNUstep IIRC. 
correctly.







That's cool. Thanks a lot. I will give them a try soon. But for this 
special project I currently have on the table I need to get window 
resizing (auto relayouting) running on the special hardware with 
Ubuntu 16 installed. As you can see in my last few mails the current 
GNUstep missives here a bit. :-(


Yes, I read about the pain, that'ìs what I thought tot est if general 
stuff still worked for me on ubuntu or not and it does.

I use th standard gcc runtime, as additional info.

Riccardo

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Andreas Höschler]

Hi Riccardo,

>> What's the quickest and cleanest way to set up a Linux/GNUstep machine on 
>> current hardware? Which distro do you recommend? Is there a todo-list 
>> somewhere to get from naked hardware to a working GNUstep desktop somewhere?
> 
> That opens a can of worms!
> 
> However, I have a ThinkPad running Ubuntu 16 with WindowMaker, I took the 
> time this weekend to update everythin, recompile all GNUstep and confirm it 
> works perfectly.
> Thus... there must be something specific on your side.

On the specific machine preinstalled with Ubuntu 16 I always got "System 
program problem detected" panels after logging in. When I click on "Reprot 
problem" it says "Please enter your password to access problem reports of 
systems programs". I thought that was due to a smashed installation. But I 
installed Ubuntu 16.04 from scratch on a VirtualBox virtual machine in the 
meanwhile to sort out the reported GNUstep problems and got the same error 
panels there as well. So this really seems to be a generic Ubuntu 16 problem 
(not machine or installation related). Do you get those as well?

How did you install Window Maker on your Ubuntu 16? I would like to give Freds 
test program a try under Window Maker to see whether it also shows the wrong 
behaviour.

> Solaris is now just a niche server OS, since there are no more workstations.
> 
> If you still have it somewhere though, I created and try to maintain several 
> gnustep packages for it! I never announced it because I still miss some 
> packages, howver, check on https://www.opencsw.org/ 
>  All the "core" stuff is there, I am in the process 
> of upgrading the rest.
> 
> gnustep_back    
> 0.26.0,REV=2018.04.29   GNUstep-core back
> gnustep_base    
> 1.25.1,REV=2018.03.26   GNUstep-core base
> gnustep_gui  
> 0.26.2,REV=2018.04.28   GNUstep-core gui
> gnustep_make    
> 2.7.0,REV=2018.01.30GNUstep-core make
> 
> 
> 
> 
> 

That's cool. Thanks a lot. I will give them a try soon. But for this special 
project I currently have on the table I need to get window resizing (auto 
relayouting) running on the special hardware with Ubuntu 16 installed. As you 
can see in my last few mails the current GNUstep missives here a bit. :-(

Best wishes,

 Andreas

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Riccardo Mottola]

Hi Andreas,

Andreas Höschler wrote:
What's the quickest and cleanest way to set up a Linux/GNUstep machine 
on current hardware? Which distro do you recommend? Is there a 
todo-list somewhere to get from naked hardware to a working GNUstep 
desktop somewhere?


That opens a can of worms!

However, I have a ThinkPad running Ubuntu 16 with WindowMaker, I took 
the time this weekend to update everythin, recompile all GNUstep and 
confirm it works perfectly.

Thus... there must be something specific on your side.



These kind of problems made me stick to Solaris and MacOSX for so 
long. Both just worked. This Linux crap gives me a hard time .. :-(


I understand and share the feeling. There is some sort of hurdle which 
Linux continues to have even if a great deal of complication got added.


Solaris is now just a niche server OS, since there are no more workstations.

If you still have it somewhere thouhg, I created and try to maintain 
several gnustep packages for it! I never announced it because I still 
miss some packages, howver, check on https://www.opencsw.org/ All the 
"core" stuff is there, I am in the process of upgrading the rest.


gnustep_back  
0.26.0,REV=2018.04.29 	GNUstep-core back
gnustep_base  
1.25.1,REV=2018.03.26 	GNUstep-core base
gnustep_gui  
0.26.2,REV=2018.04.28 	GNUstep-core gui
gnustep_make  
2.7.0,REV=2018.01.30 	GNUstep-core make










Riccardo
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Andreas Höschler]

Hi Fred,

> The  important line  is this one: 
> 
>> Am 28.04.2018 um 17:49 schrieb Andreas Höschler > >:
>> 
>> gcc  -rdynamic -shared-libgcc  -pthread  -fexceptions -fgnu-runtime -o 
>> /Build/TabTest/TabTest.app/./TabTest \
>> /Build/TabTest/obj/TabTest.obj/Controller.m.o 
>> /Build/TabTest/obj/TabTest.obj/DocumentController.m.o 
>> /Build/TabTest/obj/TabTest.obj/main.m.o   
>> -L/root/GNUstep/Library/Libraries -L/usr/local/lib   -lESMFoundation 
>> -lSRAppKit -lSRDesign -lSREnterprise -lSRFoundation -lSRInterface -lSRMapKit 
>> -lSRObjects -lSRQuery  -lgnustep-gui-lgnustep-base-lobjc   -lm
> 
> The question now is, which of your libraries didn’t it link to? And where is 
> that library located?

None made it into the binary, so it seems.

ldd /Build/TabTest/TabTest.app/TabTest

linux-vdso.so.1 =>  (0x7ffe45bcb000)
libgnustep-gui.so.0.26 => /usr/local/lib/libgnustep-gui.so.0.26 
(0x7fe23fdcd000)
libgnustep-base.so.1.25 => /usr/local/lib/libgnustep-base.so.1.25 
(0x7fe23f5d2000)
libobjc.so.4 => /usr/lib/x86_64-linux-gnu/libobjc.so.4 
(0x7fe23f3b4000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fe23efea000)
libicuuc.so.55 => /usr/lib/x86_64-linux-gnu/libicuuc.so.55 
(0x7fe23ec56000)
libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 
(0x7fe23ea31000)
libtiff.so.5 => /usr/lib/x86_64-linux-gnu/libtiff.so.5 
(0x7fe23e7bd000)
libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 
(0x7fe23e564000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fe23e25b000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fe23e045000)
libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 
(0x7fe23dd15000)
libxslt.so.1 => /usr/lib/x86_64-linux-gnu/libxslt.so.1 
(0x7fe23dad8000)
libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 
(0x7fe23d71d000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 
(0x7fe23d515000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fe23d311000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fe23d0f4000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fe23ceda000)
libicui18n.so.55 => /usr/lib/x86_64-linux-gnu/libicui18n.so.55 
(0x7fe23ca78000)
/lib64/ld-linux-x86-64.so.2 (0x7fe240626000)
libicudata.so.55 => /usr/lib/x86_64-linux-gnu/libicudata.so.55 
(0x7fe23afc1000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fe23ac3f000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fe23aa1d000)
libjbig.so.0 => /usr/lib/x86_64-linux-gnu/libjbig.so.0 
(0x7fe23a80f000)
libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 
(0x7fe23a5ab000)
libidn.so.11 => /usr/lib/x86_64-linux-gnu/libidn.so.11 
(0x7fe23a378000)
libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 
(0x7fe23a165000)
libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 
(0x7fe239f2f000)
libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 
(0x7fe239cfc000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 
(0x7fe239a7c000)

I looked for one of the frameworks and it was found here:

root@RetinaUbuntu16:/usr/src/FileHub/TabTest# find /usr/local -name 
ESMFoundation
/usr/local/include/ESMFoundation
/usr/local/lib/GNUstep/Frameworks/ESMFoundation.framework/Versions/1/ESMFoundation
/usr/local/lib/GNUstep/Frameworks/ESMFoundation.framework/ESMFoundation

and another one

root@RetinaUbuntu16:/usr/src/FileHub/TabTest# find /usr/local -name SRFoundation
/usr/local/include/SRFoundation
/usr/local/lib/GNUstep/Frameworks/SRFoundation.framework/Versions/1/SRFoundation
/usr/local/lib/GNUstep/Frameworks/SRFoundation.framework/SRFoundation

May be my GNUmakefile needs a path setting but exactly this GNUmakefile worked 
for years, even still works with

gnustep-make-2.7.0.tar.gz

from www.gnustep.org !?

Thanks,

 Andreas

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Andreas Höschler]

Hi Fred,	your GNUmakefile looks like it was scrambled by your mail client. A few lines end in $ and the rest is missing. It would be best to attach the file to give others a chance to investigate it.Sorry! Here it is (the attached file):

GNUmakefile
Description: Binary data
 What you should do yourself is run the build process with „make messages=yes“ and report back the actual link command.root@RetinaUbuntu16:/usr/src/FileHub/TabTest# make messages=yesThis is gnustep-make 2.7.0. Type 'make print-gnustep-make-help' for help.Running in gnustep-make version 2 strict mode.cd /Build/TabTest; \/usr/local/share/GNUstep/Makefiles/mkinstalldirs ./objMaking all for app TabTest...cd /Build/TabTest; \/usr/local/share/GNUstep/Makefiles/mkinstalldirs ./obj/TabTest.obj//usr/local/share/GNUstep/Makefiles/mkinstalldirs /Build/TabTest/TabTest.app/.gcc Controller.m -c \      -MMD -MP -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing -fexceptions -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS -pthread -fPIC -Wall -DGSWARN -DGSDIAGNOSE -Wno-import -g -O2 -fgnu-runtime -Wno-parentheses -Wno-import -fconstant-string-class=NSConstantString -I. -I/root/GNUstep/Library/Headers -I/usr/local/include \       -o /Build/TabTest/obj/TabTest.obj/Controller.m.ogcc DocumentController.m -c \      -MMD -MP -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing -fexceptions -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS -pthread -fPIC -Wall -DGSWARN -DGSDIAGNOSE -Wno-import -g -O2 -fgnu-runtime -Wno-parentheses -Wno-import -fconstant-string-class=NSConstantString -I. -I/root/GNUstep/Library/Headers -I/usr/local/include \       -o /Build/TabTest/obj/TabTest.obj/DocumentController.m.ogcc main.m -c \      -MMD -MP -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing -fexceptions -fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS -pthread -fPIC -Wall -DGSWARN -DGSDIAGNOSE -Wno-import -g -O2 -fgnu-runtime -Wno-parentheses -Wno-import -fconstant-string-class=NSConstantString -I. -I/root/GNUstep/Library/Headers -I/usr/local/include \       -o /Build/TabTest/obj/TabTest.obj/main.m.ogcc  -rdynamic     -shared-libgcc  -pthread  -fexceptions -fgnu-runtime -o /Build/TabTest/TabTest.app/./TabTest \/Build/TabTest/obj/TabTest.obj/Controller.m.o /Build/TabTest/obj/TabTest.obj/DocumentController.m.o /Build/TabTest/obj/TabTest.obj/main.m.o       -L/root/GNUstep/Library/Libraries -L/usr/local/lib   -lESMFoundation -lSRAppKit -lSRDesign -lSREnterprise -lSRFoundation -lSRInterface -lSRMapKit -lSRObjects -lSRQuery  -lgnustep-gui    -lgnustep-base    -lobjc   -lm/usr/local/share/GNUstep/Makefiles/mkinstalldirs /Build/TabTest/TabTest.app/Resourcesecho "OLD_GNUSTEP_STAMP_ASTRING = _NSApplication-TabTest.icns--" > /Build/TabTest/TabTest.app/stamp.make(echo "{"; echo '  NOTE = "Automatically generated, do not edit!";'; \  echo "  NSExecutable = \"TabTest\";"; \  echo "  NSMainNibFile = \"\";"; \  echo "  GSMainMarkupFile = \"\";"; \  if [ "TabTest.icns" != "" ]; then \    echo "  NSIcon = \"TabTest.icns\";"; \  fi; \  echo "  NSPrincipalClass = \"NSApplication\";"; \  echo "}") >/Build/TabTest/TabTest.app/Resources/Info-gnustep.plistif [ -r "" ]; then \   plmerge /Build/TabTest/TabTest.app/Resources/Info-gnustep.plist ""; \  fipl2link /Build/TabTest/TabTest.app/Resources/Info-gnustep.plist /Build/TabTest/TabTest.app/Resources/TabTest.desktop; \                 chmod a+x /Build/TabTest/TabTest.app/Resources/TabTest.desktopfor f in MainMenu-GNUstep.gsmarkup MainMenu-OSX.gsmarkup SmartClient.tiff Document.smib TabTest.tiff Info-gnustep.plist; do \  if [ -f .//$f -o -d .//$f ]; then \    cp -fr .//$f /Build/TabTest/TabTest.app/Resources/; \  else \    echo "Warning: .//$f not found - ignoring"; \  fi; \doneWarning: .//TabTest.tiff not found - ignoringWarning: .//Info-gnustep.plist not found - ignoringWarning! You have specified Info-gnustep.plist in TabTest_RESOURCE_FILES  Unfortunately, it will not work because Info-gnustep.plist is automatically generated.  To customize Info-gnustep.plist, please create a TabTestInfo.plist file with your custom entries.  TabTestInfo.plist will be automatically merged into Info-gnustep.plist.Thanks, Andreas___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Andreas Höschler]

Hi Fred,

> Here comes my tiny test application. It is about the minimal code that
> is needed to test this behaviour. A minimal GNUmakefile for this would
> look something like this:
> 
> 
> 
> include $(GNUSTEP_MAKEFILES)/common.make
> 
> NEEDS_GUI = yes
> 
> # The application to be compiled
> TEST_APP_NAME = resize
> resize_OBJC_FILES = resize.m
> 
> include $(GNUSTEP_MAKEFILES)/test-application.make
> 
> 
> 
> For me this give the expected values when trying to resize the window.
> But on the other hand, the GNUstep fallback window border sizes are
> tailored to my KWin window manager. I promise to have a look at the
> window manager specific code that Josh has put into PikoPixel to provide
> a better user experience on more environments.

Thanks a lot for providing a test app. I checked it out on my newly installed 

Ubuntu 16.04 system

and get 

Starting the app:

2018-04-27 19:55:33.498 resize[19948:19948] Content view set frame to {x = 0; y 
= 0; width = 140; height = 140}

Grabbing the lower corner of the window (not yet significantly resized):

2018-04-27 19:55:37.613 resize[19948:19948] Content view set frame to {x = 0; y 
= 0; width = 140; height = 171}
2018-04-27 19:55:37.613 resize[19948:19948] Content view set frame to {x = 0; y 
= 0; width = 140; height = 171}

So it shows the exact same error my app exhibits. :-(

Thanks,

 Andreas

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Fred Kiefer]

Am 24.04.2018 um 18:28 schrieb Andreas Höschler:
>> All of these values look correct, I really don’t understand why it is
>> going wrong here. I see two ways to proceed from here. Either you
>> could move on to a more current GNUstep version just to see whether
>> the error is resolved there. Or I could write a tiny test application,
>> check it locally with current GNustep and send you the test code to
>> confirm the behaviour on your side.
>>
>> I hope to find the time for the later, but am promising nothing for
>> this week.
> 
> I assume I would find the more recent version on 
> 
> https://github.com/gnustep
> 
> I will try the most recent gui and back ...
> 
> I am also looking forward to your little test app!

Here comes my tiny test application. It is about the minimal code that
is needed to test this behaviour. A minimal GNUmakefile for this would
look something like this:



include $(GNUSTEP_MAKEFILES)/common.make

NEEDS_GUI = yes

# The application to be compiled
TEST_APP_NAME = resize
resize_OBJC_FILES = resize.m

include $(GNUSTEP_MAKEFILES)/test-application.make



For me this give the expected values when trying to resize the window.
But on the other hand, the GNUstep fallback window border sizes are
tailored to my KWin window manager. I promise to have a look at the
window manager specific code that Josh has put into PikoPixel to provide
a better user experience on more environments.

Fred
#import 
#import 
#import 
#import 
#import 
#import "AppKit/NSGraphics.h"
#import 
#import 
#import 

#include 
@interface MyContentView: NSView
{
}
@end

@implementation MyContentView

- (void) setFrame: (NSRect)frameRect
{
  NSLog(@"Content view set frame to %@", NSStringFromRect(frameRect));
  [super setFrame: frameRect];
}
- (void) drawRect: (NSRect)rect
{
  [[NSColor redColor] set];
  NSRectFill(rect);
}

@end

@interface AppController: NSObject
{
}
@end


@implementation AppController

- (void)applicationDidFinishLaunching:(NSNotification *)notification
{
  NSWindow *aWin;
  NSMenu *menu = [NSMenu new];

  [menu addItemWithTitle: @"Quit"
	action: @selector(terminate:)
	keyEquivalent: @"q"];
  [NSApp setMainMenu: menu];
  RELEASE(menu);

  aWin = [[NSWindow alloc] initWithContentRect: NSMakeRect(200,200,140,140)
 styleMask: NSTitledWindowMask | NSResizableWindowMask
   backing: NSBackingStoreBuffered
 defer: NO];
  [aWin setMaxSize: NSMakeSize(200, 200)];
  [aWin setBackgroundColor: [NSColor blueColor]];
  NSView *contentView = [[MyContentView alloc] initWithFrame: NSMakeRect(200,200,140,140)];
  [aWin setContentView: contentView];
  [contentView release];
  [aWin makeKeyAndOrderFront: nil];
}

@end

int main (int argc, const char *argv[])
{
  CREATE_AUTORELEASE_POOL(pool);
  id app;

  app = [NSApplication sharedApplication];
  [app setDelegate: [AppController new]];
  [app run];
  RELEASE(pool);
  return 0;
}
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Josh Freeman]

On Apr 25, 2018, at 6:30 PM, Josh Freeman wrote:

  For GNUstep GUI-app development, I'd suggest MATE as the desktop  
environment, and the easiest way to get it is a distro where MATE's  
the built-in default: Ubuntu MATE (17.10 or 18.04), or Linux MATE.


   Linux MATE -> Linux Mint MATE


  Most desktop environments have at least some minor UI issues with  
GNUstep GUI apps (avoid Unity/Compiz), but MATE seems to be the most  
compatible - no issues as far as I've seen [1].


   For clarification: The UI issues are due to the window manager,  
not the desktop environment. Most DEs are tied to a specific WM, and  
since DE names are more widely-known than WM names, it was simpler to  
refer to the former.


   However, MATE is one of the DEs that allows you to switch to a  
different WM. For GNUstep-GUI compatibility, this is not recommended -  
what works well with GNUstep is MATE's built-in WM: Marco.


Cheers,

Josh

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Josh Freeman]

On Apr 25, 2018, at 11:26 AM, Andreas Höschler wrote:

I tried to install a different window manager on this Ubuntu 16.04  
box to check out whether the problem is window manager related. I  
tried Window Maker


add-apt-repository ppa:profzoom/wmaker
apt-get update
apt-get install wmaker

and was even able to select that on the login screen. But logging in  
got me immediately rerouted to the login screen. So it simply did  
not work. I tried a bunch of other window managers from


https://www.ubuntupit.com/install-various-desktop-environment-ubuntu/

without success. Not one wanted to work. Pretty annoying and  
discouraging experience so far. The machine is now completely messed  
up. I not even get back into the original Unity 8 desktop. After a  
reboot I end up on some kind of xfce login screen with no option to  
choose a different window manager. :-(



   This won't help your broken setup, but once you get a working OS  
again, I'd suggest two things:


1) Install some virtualization software, so you can test out  
potentially-breaking installs on a virtual machine first. (Take a VM  
snapshot right before doing something risky, so you can easily revert  
the changes if it breaks). Virtualization can also save time when  
doing cross-platform Mac/GNUstep development: Installing a Linux VM on  
your Mac allows you to use both development environments from a single  
computer.


2) Before adding an external PPA for a desktop environment, first try  
installing the distro's own packaged version. I've installed a bunch  
of different DEs (including wmaker) in Ubuntu from its repository  
packages, and fortunately, they've mostly worked (never had a machine  
become unusable).



It might be the time for a complete reinstall of the OS. Since the  
Linux was preinstalled on this machine I do not even have an install  
CD and would have to create one first. This brings me to the  
question which distro to use.


What's the quickest and cleanest way to set up a Linux/GNUstep  
machine on current hardware? Which distro do you recommend?


   For GNUstep GUI-app development, I'd suggest MATE as the desktop  
environment, and the easiest way to get it is a distro where MATE's  
the built-in default: Ubuntu MATE (17.10 or 18.04), or Linux MATE.


   Most desktop environments have at least some minor UI issues with  
GNUstep GUI apps (avoid Unity/Compiz), but MATE seems to be the most  
compatible - no issues as far as I've seen [1].


   As for the quickest way to set up GNUstep (on Ubuntu/Mint):

   If you need clang or Objective-C 2.0 features, you can use the  
install script (GNUstep/libobjc2 runtime) at: http://wiki.gnustep.org/index.php/GNUstep_under_Ubuntu_Linux 
 [2].


   Otherwise, you can install GNUstep from distro packages (gcc  
compiler/runtime) - if you use this option, Ubuntu would be preferable  
to Mint, because its GNUstep packages are more recent:


sudo apt-get update && sudo apt-get install build-essential libgnustep- 
gui-dev gnustep-examples

echo ". /usr/lib/GNUstep/Makefiles/GNUstep.sh" >> ~/.bashrc
. /usr/lib/GNUstep/Makefiles/GNUstep.sh


Cheers,

Josh


[1] PikoPixel has workarounds for DE-specific GNUstep UI issues in:  
Budgie, Cinnamon, GNOME, KDE, LXDE, Pantheon, Unity, Xfce, &  
WindowMaker. Most of the issues are due to incorrect window-style- 
offsets values. You can browse PikoPixel's workaround code in the  
Debian GNUstep team's online mirror:

https://salsa.debian.org/search?utf8=%E2%9C%93=kPPGSWindowManagerTypeMask__id=_id=18300_code=true_ref=master

[2] The "GNUstep under Ubuntu Linux" script will install a working  
GNUstep environment, but it uses the fragile ABI. If you want the  
nonfragile ABI, you currently need to use the script & patch attached  
to this list message:

http://lists.gnu.org/archive/html/discuss-gnustep/2017-12/msg00129.html


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Liam Proven]

On 25 April 2018 at 17:26, Andreas Höschler  wrote:

> It might be the time for a complete reinstall of the OS. Since the Linux was
> preinstalled on this machine I do not even have an install CD and would have
> to create one first. This brings me to the question which distro to use.

There is no right answer. There are  many strong factions in Linux
land and a lot of advocacy.

> What's the quickest and cleanest way to set up a Linux/GNUstep machine on
> current hardware? Which distro do you recommend? Is there a todo-list
> somewhere to get from naked hardware to a working GNUstep desktop somewhere?

I use Ubuntu at home and SUSE at work. I formerly worked for Red Hat.

For a desktop distro, at present, Ubuntu is as good as it gets. It is
simple, clean, polished and as easy as Linux gets, IMHO.

> These kind of problems made me stick to Solaris and MacOSX for so long. Both
> just worked. This Linux crap gives me a hard time .. :-(

Well, Solaris is dead now, sadly. Mac OS X is a fine OS and I also use
a Mac desktop at home, but it doesn't run well on cheap commodity
hardware. Personally, I hate the keyboards and trackpads on modern
Macs, so I don't use the laptops -- I use Thinkpads. Cheap used ones.
On them Ubuntu with Unity gives a very Mac-like experience.

What hardware do you have that came pre-installed?  I ask because it
may need drivers.

When it comes to generic hardware, as for re-installing it, download
16.04-04 from here:

https://www.ubuntu.com/download/desktop

You can make a bootable USB key on Windows, Mac or another Linux box.

-- 
Liam Proven • Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk • Google Mail/Hangouts/Plus: lpro...@gmail.com
Twitter/Facebook/Flickr: lproven • Skype/LinkedIn: liamproven
UK: +44 7939-087884 • ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Liam Proven]

On 24 April 2018 at 19:06, Andreas Höschler  wrote:

>
> I tried to get Window Maker to run to figure out whether the problem is
> window manager related. I did
> add-apt-repository ppa:profzoom/wmaker
> apt-get update
> apt-get install wmaker

Oh dear. Why do it this way?

Did you not look at the date on that article? It was from *six years
ago*, an extremely long time in FOSS terms. It was designed for a
version of Ubuntu *eighte versions* older than yours.

I'm afraid I'm not surprised it broke it.

Window Maker is in the Ubuntu repositories. You didn't need to add 3rd
party sources which are by nature far less well-tested.

> Any experiences with Window Maker and its installation on an Ubuntu 16.04
> system?

Yes, I installed it from the repos and it worked fine for me.

Do a clean install of 16.04. Then add the Synaptic graphical package manager.

Add in the latest hardware enablement update. (If you download a new
copy this should be built in.)

Install the build essentials.

Then install Window Maker from the repos. Google for how. *Include the
Ubuntu version numbers.* For more guidance, ask on the Ubuntu mailing
list -- there are some skilled folk there.

Then follow the GNUstep build instructions.

-- 
Liam Proven • Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk • Google Mail/Hangouts/Plus: lpro...@gmail.com
Twitter/Facebook/Flickr: lproven • Skype/LinkedIn: liamproven
UK: +44 7939-087884 • ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Liam Proven]

On 24 April 2018 at 18:53, Andreas Höschler  wrote:
> Hi Liam,
>
> I run 16.04, so I guess that will be it. Any idea how to be sure (command to
> test this)?

The Settings menu at the top right corner of the screen is the
simplest way to find out what version of the OS you are running.

> May be I should try to get WindowMaker to run on this box and see whether
> this makes a difference!?

Oh dear. I would have said "no" to that, but it seems it is too late.

> Woahhj!!

The Linux desktop world is in a period of some flux at the moment,
with major infrastructure changes that should substantially modernise
the OS. These include:
* systemd -- a new init daemon that subsumes a lot of traditional Unix
underpinnings
* Wayland -- a new display server that replaces the decades-old X
Window System, used on all other Unixes (except Mac OS X and Android).

These changes will also distance it considerably from more traditional
FOSS Unix OSes such as the BSDs (e.g. FreeBSD). However many of them
are controversial and widely disliked.

It does mean stuff is changing quite fast at present.

-- 
Liam Proven • Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk • Google Mail/Hangouts/Plus: lpro...@gmail.com
Twitter/Facebook/Flickr: lproven • Skype/LinkedIn: liamproven
UK: +44 7939-087884 • ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Andreas Höschler]

Hi all,

I tried to install a different window manager on this Ubuntu 16.04 box to check 
out whether the problem is window manager related. I tried Window Maker 

add-apt-repository ppa:profzoom/wmaker
apt-get update
apt-get install wmaker

and was even able to select that on the login screen. But logging in got me 
immediately rerouted to the login screen. So it simply did not work. I tried a 
bunch of other window managers from 

https://www.ubuntupit.com/install-various-desktop-environment-ubuntu/

without success. Not one wanted to work. Pretty annoying and discouraging 
experience so far. The machine is now completely messed up. I not even get back 
into the original Unity 8 desktop. After a reboot I end up on some kind of xfce 
login screen with no option to choose a different window manager. :-(

It might be the time for a complete reinstall of the OS. Since the Linux was 
preinstalled on this machine I do not even have an install CD and would have to 
create one first. This brings me to the question which distro to use.

What's the quickest and cleanest way to set up a Linux/GNUstep machine on 
current hardware? Which distro do you recommend? Is there a todo-list somewhere 
to get from naked hardware to a working GNUstep desktop somewhere?

These kind of problems made me stick to Solaris and MacOSX for so long. Both 
just worked. This Linux crap gives me a hard time .. :-(

Hints greatly appreciated!!

Thanks,

 Andreas


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Andreas Höschler]

On Apr 24, 2018, at 6:53 PM, Andreas Höschler wrote:

>> E.g. if the version is 16.04 (the current long-term support version),
>> then the default desktop is Unity and the WM is Compiz.
> 
> I run 16.04, so I guess that will be it. Any idea how to be sure (command to 
> test this)?
> 
> May be I should try to get WindowMaker to run on this box and see whether 
> this makes a difference!?

I tried to get Window Maker to run to figure out whether the problem is window 
manager related. I did

add-apt-repository ppa:profzoom/wmaker
apt-get update
apt-get install wmaker


Source: 
https://www.howtogeek.com/109686/how-to-install-use-the-window-maker-desktop-environment-on-ubuntu/

logged out and tried to login after selecting Window Maker in the login panel. 
This does not work. I am not logged in but routed back to the login screen! :-(

Any experiences with Window Maker and its installation on an Ubuntu 16.04 
system?

Thanks a lot,

 Andreas

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Andreas Höschler]

Hi Fred,

> All of these values look correct, I really don’t understand why it is going 
> wrong here. I see two ways to proceed from here. Either you could move on to 
> a more current GNUstep version just to see whether the error is resolved 
> there. Or I could write a tiny test application, check it locally with 
> current GNustep and send you the test code to confirm the behaviour on your 
> side.
> 
> I hope to find the time for the later, but am promising nothing for this week.

I assume I would find the more recent version on 

https://github.com/gnustep

I will try the most recent gui and back ...

I am also looking forward to your little test app!

Thanks a lot,

 Andreas

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Fred Kiefer]

All of these values look correct, I really don’t understand why it is going 
wrong here. I see two ways to proceed from here. Either you could move on to a 
more current GNUstep version just to see whether the error is resolved there. 
Or I could write a tiny test application, check it locally with current GNustep 
and send you the test code to confirm the behaviour on your side.

I hope to find the time for the later, but am promising nothing for this week.

Fred

> Am 24.04.2018 um 17:20 schrieb Andreas Höschler :
> 
> Hi Ivan,
> 
>> Just staring at those logs...
>> 
>> (1) Which window manager is this?
> 
> I actually don't know. This is a preinstalled Ubuntu system. It has a 
> vertical doc on the left side of the screen. How do I figure this out?
> 
>> (2) What does "xprop _NET_FRAME_EXTENTS" tell you when you click on
>> the offending window?
> 
> It says
> 
>   _NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 32, 0
> 
>> (I think "xwininfo -wm"'s line "Frame extents"
>> should also be querying the same property.)
> 
> Yes, it returns the same info!
> 
> What does that mean for/in my case? 
> 
> Thanks,
> 
>  Andreas
> 
> 
> ___
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Andreas Höschler]

Hi Liam,

>> I actually don't know. This is a preinstalled Ubuntu system. It has a
>> vertical doc on the left side of the screen. How do I figure this out?
> 
> If you can tell me what exact version of Ubuntu you are running, and
> what desktop, I can tell you what the WM is.
> 
> E.g. if the version is 16.04 (the current long-term support version),
> then the default desktop is Unity and the WM is Compiz.

I run 16.04, so I guess that will be it. Any idea how to be sure (command to 
test this)?

May be I should try to get WindowMaker to run on this box and see whether this 
makes a difference!?

> If it is the latest released version, 17.10, then the default desktop
> is GNOME 3 (with Ubuntu customisations) and the window manager is
> Clutter, but this is inexact as it is not running X.11 but Wayland and
> there is no traditional WM.
> 
> If you are running a beta of 18.04, the forthcoming LTS version, then
> again, it's GNOME 3 and Clutter under Wayland.

Woahhj!!

Thanks,

 Andreas

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Liam Proven]

On 24 April 2018 at 17:20, Andreas Höschler  wrote:
>
> I actually don't know. This is a preinstalled Ubuntu system. It has a
> vertical doc on the left side of the screen. How do I figure this out?

If you can tell me what exact version of Ubuntu you are running, and
what desktop, I can tell you what the WM is.

E.g. if the version is 16.04 (the current long-term support version),
then the default desktop is Unity and the WM is Compiz.

If it is the latest released version, 17.10, then the default desktop
is GNOME 3 (with Ubuntu customisations) and the window manager is
Clutter, but this is inexact as it is not running X.11 but Wayland and
there is no traditional WM.

If you are running a beta of 18.04, the forthcoming LTS version, then
again, it's GNOME 3 and Clutter under Wayland.

-- 
Liam Proven • Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk • Google Mail/Hangouts/Plus: lpro...@gmail.com
Twitter/Facebook/Flickr: lproven • Skype/LinkedIn: liamproven
UK: +44 7939-087884 • ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Andreas Höschler]

Hi Ivan,

> Just staring at those logs...
> 
> (1) Which window manager is this?

I actually don't know. This is a preinstalled Ubuntu system. It has a vertical 
doc on the left side of the screen. How do I figure this out?

> (2) What does "xprop _NET_FRAME_EXTENTS" tell you when you click on
> the offending window?

It says

_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 32, 0

> (I think "xwininfo -wm"'s line "Frame extents"
> should also be querying the same property.)

Yes, it returns the same info!

What does that mean for/in my case? 

Thanks,

 Andreas


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Ivan Vučica]

Just staring at those logs...

(1) Which window manager is this?
(2) What does "xprop _NET_FRAME_EXTENTS" tell you when you click on
the offending window? (I think "xwininfo -wm"'s line "Frame extents"
should also be querying the same property.)

Docs on the EWMH-defined window property:
https://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472552416

On Tue, Apr 24, 2018 at 9:38 AM, Andreas Höschler  wrote:
> Hi Fred,
>
> No, I forgot to add „-remove“ in the middle of the command. But the result
> that you have above are enough for now.
> Could you please either restart your computer again or execute this remove
> command
> xprop -root -remove _GNUSTEP_FRAME_OFFSETS
>
> And then start you application with the parameter "—GNU-Debug=Offset“ and
> mail back the output. Newer versions of GNUstep would have a bit more
> diagnostic here, but I hope the old version will print something as well.
>
>
> Starting the app:
>
> 2018-04-24 10:36:11.292 TabTest[30979:30979] Setting contentView  0x28bffa8>
> 2018-04-24 10:36:11.293 TabTest[30979:30979] setFrame {x = 0; y = 0; width =
> 85; height = 53} - 
> 2018-04-24 10:36:11.303 TabTest[30979:30979] setFrame {x = 140; y = 345;
> width = 85; height = 247} display 0
> 2018-04-24 10:36:11.306 TabTest[30979:30979] setFrame {x = 0; y = 0; width =
> 85; height = 247} - 
> 2018-04-24 10:36:11.309 TabTest[30979:30979] setFrame {x = 0; y = 0; width =
> 85; height = 247} - 
> 2018-04-24 10:36:11.310 TabTest[30979:30979] setFrame {x = 140; y = 345;
> width = 85; height = 247} display 0
> 2018-04-24 10:36:11.318 TabTest[30979:30979] setFrame {x = 140; y = 345;
> width = 85; height = 247} display 0
> 2018-04-24 10:36:11.362 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.367 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.372 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.374 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.377 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.379 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.380 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.380 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.395 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.397 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.397 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.397 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.398 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.399 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.426 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.431 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.433 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:11.472 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
>
> Grabbing the bottom right corner of the window with the mouse in order to
> resize:
>
> 2018-04-24 10:36:19.155 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.170 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.178 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.186 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.202 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.210 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.226 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.234 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.242 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.258 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.266 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.274 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.282 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.306 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.538 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.706 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.778 TabTest[30979:30979] Offsets retrieved from
> _NET_FRAME_EXTENTS
> 2018-04-24 10:36:19.826 

Re: Bugs in gui/back

[Andreas Höschler]

Hi Fred,

> No, I forgot to add „-remove“ in the middle of the command. But the result 
> that you have above are enough for now.
> Could you please either restart your computer again or execute this remove 
> command
> xprop -root -remove _GNUSTEP_FRAME_OFFSETS
> 
> And then start you application with the parameter "—GNU-Debug=Offset“ and 
> mail back the output. Newer versions of GNUstep would have a bit more 
> diagnostic here, but I hope the old version will print something as well.

Starting the app:

2018-04-24 10:36:11.292 TabTest[30979:30979] Setting contentView 
2018-04-24 10:36:11.293 TabTest[30979:30979] setFrame {x = 0; y = 0; width = 
85; height = 53} - 
2018-04-24 10:36:11.303 TabTest[30979:30979] setFrame {x = 140; y = 345; width 
= 85; height = 247} display 0
2018-04-24 10:36:11.306 TabTest[30979:30979] setFrame {x = 0; y = 0; width = 
85; height = 247} - 
2018-04-24 10:36:11.309 TabTest[30979:30979] setFrame {x = 0; y = 0; width = 
85; height = 247} - 
2018-04-24 10:36:11.310 TabTest[30979:30979] setFrame {x = 140; y = 345; width 
= 85; height = 247} display 0
2018-04-24 10:36:11.318 TabTest[30979:30979] setFrame {x = 140; y = 345; width 
= 85; height = 247} display 0
2018-04-24 10:36:11.362 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:11.367 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:11.372 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:11.374 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:11.377 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:11.379 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:11.380 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:11.380 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:11.395 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:11.397 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:11.397 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:11.397 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:11.398 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:11.399 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:11.426 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:11.431 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:11.433 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:11.472 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS

Grabbing the bottom right corner of the window with the mouse in order to 
resize:

2018-04-24 10:36:19.155 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:19.170 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:19.178 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:19.186 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:19.202 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:19.210 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:19.226 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:19.234 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:19.242 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:19.258 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:19.266 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:19.274 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:19.282 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:19.306 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:19.538 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:19.706 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:19.778 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:19.826 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:20.090 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:20.322 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:20.434 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:20.506 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:20.538 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 10:36:22.259 TabTest[30979:30979] Offsets retrieved from 
_NET_FRAME_EXTENTS
2018-04-24 

Re: Bugs in gui/back

[Fred Kiefer]

> Am 23.04.2018 um 15:21 schrieb Andreas Höschler :
> 
> 
>> It is easy to inspect these numbers as GNUstep stores them on the root
>> window as properties.
>>  xprop -root _GNUSTEP_FRAME_OFFSETS
> 
> I typed this command in the shell I use to start the app directly after a 
> reboot of the machine. It said
> 
> _GNUSTEP_FRAME_OFFESTS: no such atom on any window

This is to be expected, as GNUstep needs to fill these values first.

> I then started the app for the first time after a reboot and reexecuted the 
> above command. It then said
> 
> _GNUSTEP_FRAME_OFFSETS(CARDINAL) = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0

That looks bad. Most likely GNUstep couldn’t figure out any of these values 
which again would explain your problem.


>> Every group of four values belongs to a window style. If you see zeros
>> or negative values here this might point to invalid numbers. In that
>> case you should remove these values with the following command:
>> xprop -root _GNUSTEP_FRAME_OFFSETS
> 
> That's the exact same command as above? Is this correct

No, I forgot to add „-remove“ in the middle of the command. But the result that 
you have above are enough for now.
Could you please either restart your computer again or execute this remove 
command
xprop -root -remove _GNUSTEP_FRAME_OFFSETS

And then start you application with the parameter "—GNU-Debug=Offset“ and mail 
back the output. Newer versions of GNUstep would have a bit more diagnostic 
here, but I hope the old version will print something as well.

Fred



___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Andreas Höschler]

Hi Fred,

> It is easy to inspect these numbers as GNUstep stores them on the root
> window as properties.
>  xprop -root _GNUSTEP_FRAME_OFFSETS

I typed this command in the shell I use to start the app directly after a 
reboot of the machine. It said

_GNUSTEP_FRAME_OFFESTS: no such atom on any window

I then started the app for the first time after a reboot and reexecuted the 
above command. It then said

_GNUSTEP_FRAME_OFFSETS(CARDINAL) = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0

> Every group of four values belongs to a window style. If you see zeros
> or negative values here this might point to invalid numbers. In that
> case you should remove these values with the following command:
> xprop -root _GNUSTEP_FRAME_OFFSETS

That's the exact same command as above? Is this correct?
> 
> And start up a GNUstep applications, which will then try to recompute
> the values. If we are lucky this will already remove the issue. If it
> persists I will have to investigate a bit more what is going on.

Unfortunately this had no effect. The app still misbehaves. :-(

Starting the app gives

2018-04-23 15:19:39.762 TabTest[4137:4137] Setting contentView 
2018-04-23 15:19:39.763 TabTest[4137:4137] setFrame {x = 0; y = 0; width = 85; 
height = 53} - 
2018-04-23 15:19:39.770 TabTest[4137:4137] setFrame {x = 140; y = 439; width = 
85; height = 217} display 0
2018-04-23 15:19:39.772 TabTest[4137:4137] setFrame {x = 0; y = 0; width = 85; 
height = 217} - 
2018-04-23 15:19:39.774 TabTest[4137:4137] setFrame {x = 0; y = 0; width = 85; 
height = 217} - 
2018-04-23 15:19:39.775 TabTest[4137:4137] setFrame {x = 140; y = 439; width = 
85; height = 217} display 0
2018-04-23 15:19:39.782 TabTest[4137:4137] setFrame {x = 140; y = 439; width = 
85; height = 217} display 0

Grabbing the corner of the window (not yet significantly resized) produces

2018-04-23 15:19:44.815 TabTest[4137:4137] setFrame {x = 0; y = 0; width = 85; 
height = 248} - 
2018-04-23 15:19:44.815 TabTest[4137:4137] setFrame {x = 0; y = 0; width = 85; 
height = 248} - 
2018-04-23 15:19:44.863 TabTest[4137:4137] setFrame {x = 0; y = 0; width = 85; 
height = 247} - 
2018-04-23 15:19:44.863 TabTest[4137:4137] setFrame {x = 0; y = 0; width = 85; 
height = 247} - 

Thanks,

 Andreas

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Fred Kiefer]

Am 21.04.2018 um 16:43 schrieb Andreas Höschler:
>> And your observation is correct at the moment GNUstep gui isn’t calling 
>> setFrame:display: when resizing a window with operation system mechanisms. 
>> This is due to the fact that we could get a circular calling hierarchy that 
>> way and we tried hard to protect from that. If this really affects your 
>> application we could try to adjust the behaviour, but we need to be very 
>> careful here.
> 
> OK!
> 
> Both, MacOSX and the ancient GNUstep I had been using until now do call 
> NSWindow::drawRect:display: when the window is resized by the user. But I do 
> not depend on that. I actually subclass NSWindow in my apps but do not 
> overwrite NSWindow::drawRect:display: (just checked). 
> 
> I instead expect setFrame: and/or setFrameSize: to be called on the 
> contentView. The contentView is either a VBox or a HBox. These two classes do 
> the auto relayouting of the widgets in these methods.
> 
> Further analysis showed that I get setFrame: and setFrameSize: calls on the 
> contentView under MacOSX and calls to only setFrame: on the new GNUstep which 
> would be sufficient for my purposes if the passed NSRect were correct. But 
> that seems to be not the case under GNUstep. Please see the following log:
> 
> Starting the app gives
> 
> 2018-04-21 16:28:48.272 TabTest[4371:4371] Setting contentView  0x2c51068>
> 2018-04-21 16:28:48.272 TabTest[4371:4371] setFrame {x = 0; y = 0; width = 
> 85; height = 53} - 
> 
> 2018-04-21 16:28:48.276 TabTest[4371:4371] setFrame {x = 140; y = 574; width 
> = 85; height = 114} display 0
> 2018-04-21 16:28:48.277 TabTest[4371:4371] setFrame {x = 0; y = 0; width = 
> 85; height = 114} - 
> 2018-04-21 16:28:48.277 TabTest[4371:4371] setFrame {x = 0; y = 0; width = 
> 85; height = 114} - 
> 
> 2018-04-21 16:28:48.278 TabTest[4371:4371] setFrame {x = 140; y = 574; width 
> = 85; height = 114} display 0
> 2018-04-21 16:28:48.280 TabTest[4371:4371] setFrame {x = 140; y = 574; width 
> = 85; height = 114} display 0
> 
> and shows the button perfectly centered. I wonder why the first 
> NSWindow::drawRect:display: call is followed by GSVBox::setFrame: but the 
> other two calls aren't!? That is probably due to the mentioned optimization.
> 
> But see what happens if I touch the window corner with the mouse and start to 
> drag (not even yet a mm).
> 
> 2018-04-21 16:28:54.052 TabTest[4371:4371] setFrame {x = 0; y = 0; width = 
> 85; height = 147} - 
> 2018-04-21 16:28:54.053 TabTest[4371:4371] setFrame {x = 0; y = 0; width = 
> 85; height = 147} - 
> 2018-04-21 16:28:54.156 TabTest[4371:4371] setFrame {x = 0; y = 0; width = 
> 85; height = 148} - 
> 2018-04-21 16:28:54.156 TabTest[4371:4371] setFrame {x = 0; y = 0; width = 
> 85; height = 148} - 
> 
> I get setFrame:: calls on the GSVBox (contentView of the window) but with a 
> wrong height. The height should still be roughly 114 as I have not 
> significantly resized the window yet. But I get height = 148. Could these 
> additional 34 pixel be the height of the windows title bar? Something is 
> simply calculated wrong here for whatever reason (height of the window's 
> title omitted).
> 
> Does this ring any bells?

Thank you for providing this additional information. I can now see what
is going wrong we just need to find out together why :-)

To give you a bit of background on what is going on here:
In Cocoa an NSWindow has a content rectangle and a frame rectangle. The
first is the area that the application draws into whereas the second is
the whole window including decorations. This difference gets handled by
a specific view, Apple calls it the borderview while GNUstep uses the
term windowview, which sits inside the window and has the content view
as its subview. In GNUstep this gets implemented by the two sub classes
of GSWindowDecorationView:
- GSBackendWindowDecorationView, here the window decoration gets handled
by the window system itself
- GSStandardWindowDecorationView, here GNUstep draws all the window
decoration.

You may switch between these two implementations by setting the default
value for the key GSBackHandlesWindowDecorations.

What happens in your case is that GNUstep and the window system disagree
about the size of the window that is being displayed. How could that
happen? When a window gets created we cannot ask the window system about
the amount of space it will be using for the window decoration. So
GNUstep pre-computes the decorations size for all possible window types
in advance and uses these values when ever a window gets created. Now in
your case these values seem to be wrong and when the window gets resized
we get a different number for the height then expected.

It is easy to inspect these numbers as GNUstep stores them on the root
window as properties.
  xprop -root _GNUSTEP_FRAME_OFFSETS

Every group of four values belongs to a window style. If you see zeros
or negative values here this might point to invalid numbers. In that
case you 

Re: Bugs in gui/back

[Andreas Höschler]

Hi Nikolaus,

> still alive? (same question goes to me :)

:-) Nice to hear/read from you. It seems we are all still there (somewhere)!

> NSWindow::drawRect:display:
> does this really exist?

Sorry, that was a typo! :-( I meant

NSWindow::setFrame:display:

> Anyways, what should a window draw? Only NSView and NSCell draw something.
> So it draws its contentView because that can be defined in a NIB.
> 
> Or this is a private method to draw the window decoration?

There actually is a 

NSWindow::drawRect:

method in the GNustep code. No idea when this is called (probably not related 
to my problem). My problem is rather anywhere here in the the sendEvent: method 
of NSWindow.m.

case GSAppKitWindowResized:
  {
NSRect newFrame;

newFrame.size.width = [theEvent data1];
newFrame.size.height = [theEvent data2];
/* Resize events always move the frame origin. The new origin
   is stored in the event location field. */
newFrame.origin = [theEvent locationInWindow];
 
/* FIXME: For a user resize we should call 
windowWillResize:toSize:
   on the delegate.
 */
_frame = newFrame;
newFrame.origin = NSZeroPoint;
[_wv setFrame: newFrame];
[_wv setNeedsDisplay: YES];

if (_autosaveName != nil)
  {
[self saveFrameUsingName: _autosaveName];
  }
 
[self _processResizeEvent];
[nc postNotificationName: NSWindowDidResizeNotification
  object: self];
break;
  }

I don't understand yet where this

newFrame.size.height = [theEvent data2];

comes from, but the height is wrong. And my guess is that the height of the 
window title bar is not subtracted!?

Best wishes,

 Andreas

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Andreas Höschler]

Hi Fred,

> Re-layouting would happen on level of the content view. If this doesn’t 
> happen for you something is really broken. Could you please provide the code 
> you are using?

The incorrect height is passed to the windows contentView from here:

#0  -[GSVBox setFrame:] (self=0x1ed2ed8, _cmd=0x7fcbe908aa10 
<.objc_selector_list+672>, rect=...)
at GSVBox.m:179
#1  0x7fcbe8c133e9 in -[NSView resizeWithOldSuperviewSize:] 
(self=0x1ed2ed8, 
_cmd=, oldSize=...) at NSView.m:2089
#2  0x7fcbe8c941a3 in -[GSWindowDecorationView setFrame:] (self=0x1ecd128, 
_cmd=, frameRect=...) at GSWindowDecorationView.m:411
#3  0x7fcbe8c29cb1 in -[NSWindow sendEvent:] (self=0x1ed2a48, 
_cmd=, 
theEvent=0x1f0c4a8) at NSWindow.m:4153
#4  0x7fcbe083aa75 in -[XGServer(EventOps) processEvent:] (self=, 
_cmd=, event=) at XGServerEvent.m:912
#5  0x7fcbe0838f53 in -[XGServer(EventOps) 
receivedEvent:type:extra:forMode:] (
self=, _cmd=, data=, 
type=ET_RDESC, extra=0x0, 
mode=0xd) at XGServerEvent.m:309
#6  0x7fcbe81d7f1f in -[GSRunLoopCtxt pollUntil:within:] (self=, 
_cmd=, milliseconds=0, contexts=) at 
GSRunLoopCtxt.m:600
#7  0x7fcbe8120cca in -[NSRunLoop acceptInputForMode:beforeDate:] 
(self=, 
_cmd=, mode=, limit_date=) at 
NSRunLoop.m:1224
#8  0x7fcbe81211bc in -[NSRunLoop runMode:beforeDate:] (self=0x18faa88, 
_cmd=, 
mode=0x7fcbe85da0a8 <.objc_str>, date=) at NSRunLoop.m:1304
#9  0x7fcbe8c3c9fa in -[GSDisplayServer(EventOps) 
getEventMatchingMask:beforeDate:inMode:dequeue:] (self=, 
_cmd=, mask=4294967295, limit=, 

Does this hit any bells? I will dive into the GNustep code and try to make 
sense out of this ...

Thanks,

 Andreas


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[H. Nikolaus Schaller]

Hi Andreas,
still alive? (same question goes to me :)

> Am 21.04.2018 um 16:43 schrieb Andreas Höschler :
> 
> NSWindow::drawRect:display:

does this really exist?

Apple is usually keeping deprecated methods in documentation for a long time:

https://developer.apple.com/documentation/appkit/nswindow?language=objc

but there are only display methods but no drawRect.

Anyways, what should a window draw? Only NSView and NSCell draw something.
So it draws its contentView because that can be defined in a NIB.

Or this is a private method to draw the window decoration?

-- hns
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Andreas Höschler]

Hi Fred,

> great to see that you are still using GNUstep and actually now willing to use 
> a more current version of it as well.

Yes, I still use GNUstep (and MacOSX) on a daily basis. Our software stack is 
supposed to run on both platforms and has done so for at least 15 years now, 
including all our in-house dev tools. 

> And your observation is correct at the moment GNUstep gui isn’t calling 
> setFrame:display: when resizing a window with operation system mechanisms. 
> This is due to the fact that we could get a circular calling hierarchy that 
> way and we tried hard to protect from that. If this really affects your 
> application we could try to adjust the behaviour, but we need to be very 
> careful here.

OK!

Both, MacOSX and the ancient GNUstep I had been using until now do call 
NSWindow::drawRect:display: when the window is resized by the user. But I do 
not depend on that. I actually subclass NSWindow in my apps but do not 
overwrite NSWindow::drawRect:display: (just checked). 

I instead expect setFrame: and/or setFrameSize: to be called on the 
contentView. The contentView is either a VBox or a HBox. These two classes do 
the auto relayouting of the widgets in these methods.

Further analysis showed that I get setFrame: and setFrameSize: calls on the 
contentView under MacOSX and calls to only setFrame: on the new GNUstep which 
would be sufficient for my purposes if the passed NSRect were correct. But that 
seems to be not the case under GNUstep. Please see the following log:

Starting the app gives

2018-04-21 16:28:48.272 TabTest[4371:4371] Setting contentView 
2018-04-21 16:28:48.272 TabTest[4371:4371] setFrame {x = 0; y = 0; width = 85; 
height = 53} - 

2018-04-21 16:28:48.276 TabTest[4371:4371] setFrame {x = 140; y = 574; width = 
85; height = 114} display 0
2018-04-21 16:28:48.277 TabTest[4371:4371] setFrame {x = 0; y = 0; width = 85; 
height = 114} - 
2018-04-21 16:28:48.277 TabTest[4371:4371] setFrame {x = 0; y = 0; width = 85; 
height = 114} - 

2018-04-21 16:28:48.278 TabTest[4371:4371] setFrame {x = 140; y = 574; width = 
85; height = 114} display 0
2018-04-21 16:28:48.280 TabTest[4371:4371] setFrame {x = 140; y = 574; width = 
85; height = 114} display 0

and shows the button perfectly centered. I wonder why the first 
NSWindow::drawRect:display: call is followed by GSVBox::setFrame: but the other 
two calls aren't!? That is probably due to the mentioned optimization.

But see what happens if I touch the window corner with the mouse and start to 
drag (not even yet a mm).

2018-04-21 16:28:54.052 TabTest[4371:4371] setFrame {x = 0; y = 0; width = 85; 
height = 147} - 
2018-04-21 16:28:54.053 TabTest[4371:4371] setFrame {x = 0; y = 0; width = 85; 
height = 147} - 
2018-04-21 16:28:54.156 TabTest[4371:4371] setFrame {x = 0; y = 0; width = 85; 
height = 148} - 
2018-04-21 16:28:54.156 TabTest[4371:4371] setFrame {x = 0; y = 0; width = 85; 
height = 148} - 

I get setFrame:: calls on the GSVBox (contentView of the window) but with a 
wrong height. The height should still be roughly 114 as I have not 
significantly resized the window yet. But I get height = 148. Could these 
additional 34 pixel be the height of the windows title bar? Something is simply 
calculated wrong here for whatever reason (height of the window's title 
omitted).

Does this ring any bells?

> What surprise me is that you actually noticed this implementation detail. 
> Normally you wouldn’t subclass NSWindow and only in this case the behaviour 
> is observable. Could you please explain what you are doing and why?

See above.

> Already for the content view the behaviour should be the same as on Cocoa. I 
> also wasn’t aware that there is an NSWindow drawRect: method. Are you really 
> sure about this? If so, this should just call the content view method.

This seems to be the case but with a falsely calculated height in the passed 
NSRect.

> So it would be very easy to implement.
> Re-layouting would happen on level of the content view.

That's how it is implemented.

Thanks a lot for looking into this!!

 Andreas


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Fred Kiefer]

Hi Andreas,

great to see that you are still using GNUstep and actually now willing to use a 
more current version of it as well. Although still not the latest from git :-(

And your observation is correct at the moment GNUstep gui isn’t calling 
setFrame:display: when resizing a window with operation system mechanisms. This 
is due to the fact that we could get a circular calling hierarchy that way and 
we tried hard to protect from that. If this really affects your application we 
could try to adjust the behaviour, but we need to be very careful here.

What surprise me is that you actually noticed this implementation detail. 
Normally you wouldn’t subclass NSWindow and only in this case the behaviour is 
observable. Could you please explain what you are doing and why? Already for 
the content view the behaviour should be the same as on Cocoa. I also wasn’t 
aware that there is an NSWindow drawRect: method. Are you really sure about 
this? If so, this should just call the content view method. So it would be very 
easy to implement.
Re-layouting would happen on level of the content view. If this doesn’t happen 
for you something is really broken. Could you please provide the code you are 
using?

As for the bug in NSTabView I am looking forward to hear about that in more 
detail.
 
Cheers,
Fred
 

> Am 20.04.2018 um 17:07 schrieb Andreas Höschler :
> 
> Hi all,
> 
> I just found ./gnustep-gui-0.25.1/Documentation/manual/theviewconcept.texi 
> and suppose that the problem is caused by the optimization mentioned in this 
> document. It seems critical calls (that MacOSX at least still performs) to 
> NSWindow::drawRect: are skipped now. 
> 
> Any hint where to look is greatly appreciated. I wold love to get the new 
> GNUstep tree working ...
> 
> Thanks in advance,
> 
>  Andreas
> 
> 
> 
> 
> On Apr 20, 2018, at 2:50 PM, Andreas Höschler wrote:
> 
>> I currently have a window with just one button and a spacer above and below 
>> it and am trying to resize the window vertically which works. However, 
>> 
>> NSWindow:
>> 
>>  - (void)setFrame:(NSRect)frameRect display:(BOOL)flag
>> 
>> is never called when I do this which is probably the reason why auto 
>> relayouting the content does not work. On MacOSX (same sources) I get a 
>> bunch of 
>> 
>> 2018-04-20 14:36:31.770 TabTest[8909:903] setFrame {{26, 282}, {97, 124}} 
>> display 1
>> 2018-04-20 14:36:31.780 TabTest[8909:903] setFrame {{26, 285}, {97, 121}} 
>> display 1
>> 2018-04-20 14:36:31.804 TabTest[8909:903] setFrame {{26, 287}, {97, 119}} 
>> display 1
>> 2018-04-20 14:36:31.831 TabTest[8909:903] setFrame {{26, 288}, {97, 118}} 
>> display 1
>> 2018-04-20 14:36:31.881 TabTest[8909:903] setFrame {{26, 289}, {97, 117}} 
>> display 1
>> 2018-04-20 14:36:31.931 TabTest[8909:903] setFrame {{26, 289}, {97, 117}} 
>> display 1
>> ...
>> 
>> calls when I vertically resize the window and the content is relayouted just 
>> fine!?
>> 
>> Any idea where to look from here? Which part in GNUstep is responsible for 
>> sending setFrame:display: to NSWindow when dragging the window larger and 
>> smaller?
> 


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Andreas Höschler]

Hi all,

I just found ./gnustep-gui-0.25.1/Documentation/manual/theviewconcept.texi and 
suppose that the problem is caused by the optimization mentioned in this 
document. It seems critical calls (that MacOSX at least still performs) to 
NSWindow::drawRect: are skipped now. 

Any hint where to look is greatly appreciated. I wold love to get the new 
GNUstep tree working ...

Thanks in advance,

 Andreas




On Apr 20, 2018, at 2:50 PM, Andreas Höschler wrote:

> I currently have a window with just one button and a spacer above and below 
> it and am trying to resize the window vertically which works. However, 
> 
> NSWindow:
> 
>   - (void)setFrame:(NSRect)frameRect display:(BOOL)flag
> 
> is never called when I do this which is probably the reason why auto 
> relayouting the content does not work. On MacOSX (same sources) I get a bunch 
> of 
> 
> 2018-04-20 14:36:31.770 TabTest[8909:903] setFrame {{26, 282}, {97, 124}} 
> display 1
> 2018-04-20 14:36:31.780 TabTest[8909:903] setFrame {{26, 285}, {97, 121}} 
> display 1
> 2018-04-20 14:36:31.804 TabTest[8909:903] setFrame {{26, 287}, {97, 119}} 
> display 1
> 2018-04-20 14:36:31.831 TabTest[8909:903] setFrame {{26, 288}, {97, 118}} 
> display 1
> 2018-04-20 14:36:31.881 TabTest[8909:903] setFrame {{26, 289}, {97, 117}} 
> display 1
> 2018-04-20 14:36:31.931 TabTest[8909:903] setFrame {{26, 289}, {97, 117}} 
> display 1
> ...
> 
> calls when I vertically resize the window and the content is relayouted just 
> fine!?
> 
> Any idea where to look from here? Which part in GNUstep is responsible for 
> sending setFrame:display: to NSWindow when dragging the window larger and 
> smaller?

Mit freundlichen Grüßen,

Andreas Höschler
Managing Director

Smartsoft GmbH
Birkenweg 11a
21483 Gülzow
Tel: 040 60889019
Web: http://www.smartsoft.de
EMail: ahoe...@smartsoft.de




___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: Bugs in gui/back

[Andreas Höschler]

Hi all,

I just installed back with xlib and get the same behaviour. So it's either in 
gui or back!?

Hints greatly appreciated!!

Thanks,
 
   Andreas



> after 10 years of successfully using an ancient GNUstep tree I have upgraded 
> to
> 
>   gnustep-back-0.25.1.tar.gz  
>   gnustep-gui-0.25.1.tar.gz
>   gnustep-base-1.25.0.tar.gz  
>   gnustep-make-2.7.0.tar.gz
> 
> and am testing it on Ubuntu 16.04. The sources built without issues. That's 
> good. 
> 
> However, I seem to be far away from getting anything from our software stack 
> to run on the current GNUstep sources. I have already fixed an issue with 
> NSTabView (will report/summarize later) but had to go back to zero with the 
> most simple test app to test out gui and back. 
> 
> I currently have a window with just one button and a spacer above and below 
> it and am trying to resize the window vertically which works. However, 
> 
> NSWindow:
> 
>   - (void)setFrame:(NSRect)frameRect display:(BOOL)flag
> 
> is never called when I do this which is probably the reason why auto 
> relayouting the content does not work. On MacOSX (same sources) I get a bunch 
> of 
> 
> 2018-04-20 14:36:31.770 TabTest[8909:903] setFrame {{26, 282}, {97, 124}} 
> display 1
> 2018-04-20 14:36:31.780 TabTest[8909:903] setFrame {{26, 285}, {97, 121}} 
> display 1
> 2018-04-20 14:36:31.804 TabTest[8909:903] setFrame {{26, 287}, {97, 119}} 
> display 1
> 2018-04-20 14:36:31.831 TabTest[8909:903] setFrame {{26, 288}, {97, 118}} 
> display 1
> 2018-04-20 14:36:31.881 TabTest[8909:903] setFrame {{26, 289}, {97, 117}} 
> display 1
> 2018-04-20 14:36:31.931 TabTest[8909:903] setFrame {{26, 289}, {97, 117}} 
> display 1
> ...
> 
> calls when I vertically resize the window and the content is relayouted just 
> fine!?
> 
> Any idea where to look from here? Which part in GNUstep is responsible for 
> sending setFrame:display: to NSWindow when dragging the window larger and 
> smaller? I guess this is more a back issue than gui!? If I remember correctly 
> 
>   tar xvfz gnustep-back-0.25.1.tar.gz
>   cd gnustep-back-0.25.1
>   ./configure
>   make
>   make install
>   cd ..
> 
> chose cairo on the current Ubuntu machine!? I used to have lib-art under 
> Solaris!?




___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep