Thanks again Jeremiah for reporting, > Le 4 mai 2018 à 01:35, Jeremiah Breeden <jeremiah.bree...@gmail.com> a écrit : > > Unrelated thing to the previous bugs: > > In Gnoga.Gui.Elements.Form, there is a function for turning Autocomplete off > and on. When I tried to disable autocomplete on a Text input type, it didn't > work. Inspecting the DOM showed that it set: > > autocomplete="false" > > when (at least for that input type) it should be > > autocomplete="off" > > I used the Property procedure in Gnoga.Gui.Base to work around it (setting > the field manually).
Well done, confirmed with https://www.w3schools.com/tags/att_input_autocomplete.asp. Here is a fix: diff --git a/src/gnoga-gui-element-form.adb b/src/gnoga-gui-element-form.adb index 80e9bb57..207529ae 100644 --- a/src/gnoga-gui-element-form.adb +++ b/src/gnoga-gui-element-form.adb @@ -142,7 +142,11 @@ package body Gnoga.Gui.Element.Form is Value : in Boolean := True) is begin - Form.Property ("autocomplete", Value); + if Value then + Form.Property ("autocomplete", "on"); + else + Form.Property ("autocomplete", "off"); + end if; end Autocomplete; ------------------ @@ -151,7 +155,7 @@ package body Gnoga.Gui.Element.Form is function Autocomplete (Form : Form_Type) return Boolean is begin - return Form.Property ("autocomplete"); + return Form.Property ("autocomplete") = "on"; end Autocomplete; ------------------------ @@ -258,7 +262,11 @@ package body Gnoga.Gui.Element.Form is Value : in Boolean := True) is begin - Element.Property ("autocomplete", Value); + if Value then + Element.Property ("autocomplete", "on"); + else + Element.Property ("autocomplete", "off"); + end if; end Autocomplete; ------------------- @@ -267,7 +275,7 @@ package body Gnoga.Gui.Element.Form is function Autocomplete (Element : Form_Element_Type) return Boolean is begin - return Element.Property ("autocomplete"); + return Element.Property ("autocomplete") = "on"; end Autocomplete; ---------------- > > The rest of my responses are below: > > On Thu, May 3, 2018 at 5:03 PM, Pascal via Gnoga-list > <gnoga-list@lists.sourceforge.net> wrote: > Hello Jeremiah, > > > > Le 3 mai 2018 à 02:35, Jeremiah Breeden <jeremiah.bree...@gmail.com> a > > écrit : > > > > Thanks, that got the build process going. Ran into the following problems: > > > > 1. building Zanyblue places random "build" folders in my directory > > structure outside of my gnoga envrionment. I originally thought this was a > > windows only issue, but today I was building it for a variant of Ubuntu > > 16.04 and it did the same there if my gnoga directory was far enough away > > from root locked folders. To be clear if I have: > > > > /d/Program_Files/mingw64/home/Jere/gnoga-code/ > > > > and I build zany blue, I get phantom "build" directories in the following > > locations: > > > > /d/build > > /d/Program_Files/build > > /d/Program_Files/mingw64/home/build > > > > I get the same results in my Ubuntu 16.04 variant OS. I noticed in the > > main Makefile that the path ../../../build is passed to the zanyblue > > makefile. I wonder if it is using it incorrectly in places? > > Here is what I got (macOS): > cd deps/zanyblue/src && > "/Applications/Xcode.app/Contents/Developer/usr/bin/make" > INSTALL_DIR=../../../build APPDIRS="zbmcompile zbinfo" install > gprinstall -f -p --prefix=../../../build -p -XOS=unix -XTYPE=static > -XBUILD=Debug -aP../src zanyblue.gpr > Install project ZanyBlue > gprinstall -f -p --prefix=../../../build -p -XOS=unix -XTYPE=static > -XBUILD=Debug -aP../src --mode=usage zbmcompile/zbmcompile.gpr > Install project zbmcompile > gprinstall -f -p --prefix=../../../build -p -XOS=unix -XTYPE=static > -XBUILD=Debug -aP../src --mode=usage zbinfo/zbinfo.gpr > Install project zbinfo > > What do you get on your side? > > I suspect an issue with gprbuild which some versions don't handle relative > path correctly. > Here is a patch: > > diff --git a/Makefile b/Makefile > index bf6a37c7..5e166458 100644 > --- a/Makefile > +++ b/Makefile > @@ -145,7 +145,7 @@ sqlite3: lib/libsqlite3.a > # Zanyblue with DEBUG on > zanyblue: > - cd deps/zanyblue/src && "$(MAKE)" BUILD=Debug APPDIRS="zbmcompile > zbinfo" > - - cd deps/zanyblue/src && "$(MAKE)" INSTALL_DIR=../../../build > APPDIRS="zbmcompile zbinfo" install > + - cd deps/zanyblue/src && "$(MAKE)" INSTALL_DIR="$(CWD)/build" > APPDIRS="zbmcompile zbinfo" install > > pragmarc: > $(BUILDER) -P deps/PragmARC/lib_pragmarc.gpr > > > Does it work better? > > The patch stops the phantom "build" directories. Thank you! > > I did notice it was failing to build zbcompile on my side (while your side > compiled it correctly. > > My new output is: > > $ make zanyblue > cd deps/zanyblue/src && "make" BUILD=Debug APPDIRS="zbmcompile zbinfo" > make[1]: Entering directory > '/home/Jere/gnoga-code-2018_05_01/deps/zanyblue/src' > gprbuild -p -XOS=Windows_NT -XTYPE=static -XBUILD=Debug -aP../src -P > zanyblue.gpr > "libzanyblue.a" up to date > make -C zbmcompile > make[2]: Entering directory > '/home/Jere/gnoga-code-2018_05_01/deps/zanyblue/src/zbmcompile' > gprbuild -p -p -XOS=Windows_NT -XTYPE=static -XBUILD=Debug -aP../../src -P > zbmcompile > gprbuild: "zbmcompile.exe" up to date Seems to be good. > make[2]: Leaving directory > '/home/Jere/gnoga-code-2018_05_01/deps/zanyblue/src/zbmcompile' > make -C zbinfo > make[2]: Entering directory > '/home/Jere/gnoga-code-2018_05_01/deps/zanyblue/src/zbinfo' > gprbuild -p -p -XOS=Windows_NT -XTYPE=static -XBUILD=Debug -aP../../src -P > zbinfo > gprbuild: "zbinfo.exe" up to date > make[2]: Leaving directory > '/home/Jere/gnoga-code-2018_05_01/deps/zanyblue/src/zbinfo' > make[1]: Leaving directory > '/home/Jere/gnoga-code-2018_05_01/deps/zanyblue/src' > cd deps/zanyblue/src && "make" > INSTALL_DIR=/home/Jere/gnoga-code-2018_05_01/build APPDIRS="zbmcompile > zbinfo" install > make[1]: Entering directory > '/home/Jere/gnoga-code-2018_05_01/deps/zanyblue/src' > gprinstall -f -p --prefix=/home/Jere/gnoga-code-2018_05_01/build -p > -XOS=Windows_NT -XTYPE=static -XBUILD=Debug -aP../src zanyblue.gpr > Install project ZanyBlue > gprinstall -f -p --prefix=/home/Jere/gnoga-code-2018_05_01/build -p > -XOS=Windows_NT -XTYPE=static -XBUILD=Debug -aP../src --mode=usage > zbmcompile/zbmcompile.gpr > Install project zbmcompile > file > D:\Program_Files\msys64\home\Jere\gnoga-code-2018_05_01\deps\zanyblue\bin\zbmcompile > does not exist, build may not be complete No exe extension! > make[1]: *** [../src/mkfile/install.mk:69: install-zb] Error 1 > make[1]: Leaving directory > '/home/Jere/gnoga-code-2018_05_01/deps/zanyblue/src' > make: [Makefile:148: zanyblue] Error 2 (ignored) > > I looked and zbmcompile.exe is the correct location, so I don't know why it > says it doesn't exist unless it can't tell due to the lack of ".exe" in the > build setup somewhere? I agree with your analysis, maybe an issue with grpinstall. It's ok on my side with gprinstall from GNAT GPL 2017, where does your gprinstall come from? > > > > 2. Some potential bugs: > > components/pixi/src/gnoga-gui-plugin-pixi-sprite.adb > > lines 86 and 876 call Sprite.Loop_Times() but in Ada you cannot use the > > object.operation notation unless operation is a primitive operation. Since > > both the declaration and the definition are in the body file (.adb) it > > cannot be a primitive operation and thus the call is illegal. Ironically, > > recent versions of GNAT compile it fine, but when I use 5.4 on my Ubuntu > > box, it flags it as illegal. Moving the declaration to the spec file > > (.ads) fixes the problem. > > Is it thus legal? Ada 2012? > Since Loop_Times is a private method of Sprite package, I prefer then to call > it in traditional manner: > Loop_Times (Sprite, 0, TFin); > > I don't think object.operation is legal on non primitive operations in any > version of Ada. Using package.operation(object) is a good fix. However, > don't forget you can put it in the private section of the spec and still get > both a private method and a primitive one for object.operation if you so > desire. I'm good either way. Thanks for the idea, here is the patch: diff --git a/components/pixi/src/gnoga-gui-plugin-pixi-sprite.adb b/components/pixi/src/gnoga-gui-plugin-pixi-sprite.adb index ef65c0a3..5d013923 100644 --- a/components/pixi/src/gnoga-gui-plugin-pixi-sprite.adb +++ b/components/pixi/src/gnoga-gui-plugin-pixi-sprite.adb @@ -51,11 +51,6 @@ package body Gnoga.Gui.Plugin.Pixi.Sprite is (Integer (Angle * 180.0 / Ada.Numerics.Pi)); -- Converts integer angle in degree to radian. - procedure Loop_Times - (Sprite : in out Sprite_Type; - Current, Final : Natural); - -- Sets both times current and final for move loop - ------------ -- Create -- ------------ diff --git a/components/pixi/src/gnoga-gui-plugin-pixi-sprite.ads b/components/pixi/src/gnoga-gui-plugin-pixi-sprite.ads index bb43cc56..4e812239 100644 --- a/components/pixi/src/gnoga-gui-plugin-pixi-sprite.ads +++ b/components/pixi/src/gnoga-gui-plugin-pixi-sprite.ads @@ -389,4 +389,10 @@ private On_Frame_Event : Sprite_Event := null; On_Angle_Event : Sprite_Event := null; end record; + + procedure Loop_Times + (Sprite : in out Sprite_Type; + Current, Final : Natural); + -- Sets both times current and final for move loop + end Gnoga.Gui.Plugin.Pixi.Sprite; > > > > 3. For some reason on Ubuntu, it looks for gnoga-application-Linux and > > gnoga.application-Unix in the build process but the files are all lower > > case named. It builds fine on windows which is case insensitive but fails > > on Ubuntu which is strict on case. Renaming the files fixes the issue. > > Yes, it's a awful trick in gnoga.gpr which works on macOS (case insensitive > file names with standard file system): > for Body ("Gnoga.Application.Open_command") use "gnoga-application." & > Settings.Build_Target; > > Here is a patch: > > diff --git a/src/gnoga.gpr b/src/gnoga.gpr > index e480793b..198494ea 100644 > --- a/src/gnoga.gpr > +++ b/src/gnoga.gpr > @@ -11,7 +11,14 @@ project Gnoga is > for Library_Kind use "static"; > > package Naming is > - for Body ("Gnoga.Application.Open_command") use "gnoga-application." & > Settings.Build_Target; > + case Settings.Build_Target is > + when "Windows" => > + for Body ("Gnoga.Application.Open_command") use > "gnoga-application.windows"; > + when "OSX" => > + for Body ("Gnoga.Application.Open_command") use > "gnoga-application.osx"; > + when others => > + for Body ("Gnoga.Application.Open_command") use > "gnoga-application.linux"; > + end case; > end Naming; > > package Compiler renames Settings.Compiler; > > > Does it work better? > > I'll have to try it out next week to be sure. I'm at home tomorrow and my > ubuntu box is at work. Thanks. Let us informed. > > > > > > Thanks again. > > > > Side note: On the ubuntu box, I had to fix one of the zanyblue files in > > the text subdirectory becauase it was using Object'Image, which 5.4 doesn't > > support. However, when I search the copy I have on my windows machine, I > > don't find it. In both cases I used "git clone -b dev_1.4 > > source/forge/path/to/gnoga gnoga-code" (both on today). Since I cant > > replicate it here, I don't have much to give. My ubuntu box is essentially > > standalone, so it is hard to get data off of it to here. > > With your following post: > > > Right after I sent the email I found it. Not in zany blue, but in > > > > components/ace_editor/src/gnoga-gui-plugin-ace_editor.adb:985: > > Row'Img & ',' & Column'Image & ");"); > > > > It compiles fine in GNAT FSF 7.3 but not in 5.4. I don't know if > > Object'Image is legal Ada or not. It might be, but in my Ubuntu box with > > version 5.4, I changed it to Column'Img which is a GNAT extension. > > > You're right, it's a mistake. > As current Gnoga uses 'Img largely, I will correct it. > As Jean-Pierre said I thought too it was for Ada 2020. > But as Jeff noticed it is Ada 2012 so why don't use 'Image instead specific > 'Img from GNAT? > One more item in Gnoga todo list. > > Since it is part of Ada2012 TC1, then yeah, it is ok to use. I wasn't sure > when I posted it. > > I'm stuck with my old version of GNAT so I'll just manually patch the files > for this. > > I'm currently building a Gnoga app on an Nvidia TX2 running Linux for Tegra > (L4T), an Ubuntu 16.04 variant. Unfortunately, the most recent version of > GNAT is 5.4 from 2015, but it is better than no Ada! > > Thanks again! > HTH, Pascal. http://blady.pagesperso-orange.fr ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Gnoga-list mailing list Gnoga-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gnoga-list
