Working on layout designs, problems with fontawesome, margins, etc.

[aykaramba]

Hi!

For a challenge, I want to try and re-create the W3C templates just to see how far we can get. I have a few questions:

1. I am trying to recreate the following template in CLOG: https://www.w3schools.com/w3css/tryit.asp?filename=tryw3css_templates_dark_portfolio&stacked=h

It's very simple and we should be able to easily recreate this.

2. I have uploaded my code for reference to my repo here: https://github.com/aykaramba/website-project

3. What is the proper way to set the background colour of a panel? The default is white, this template is black, it would be nice to not have to use a div as the background for the body.

4. The template uses the following code to generate 4 of the icons in the left menu:

<a href="#about" class="w3-bar-item w3-button w3-padding-large w3-hover-black"> <i class="fa fa-user w3-xxlarge"></i> <p>ABOUT</p> </a>

The control palette has the link widget, but what widget can we use for fontawesome fa fa-user classes? I tried paragraph span but putting fa fa-home w3-xxlarge in the class field doesn't work (well w3-xxlarge class is rendered).

4. The first menu item uses an image. The left bar is a div (relative), that contains a link (static) which contains an image (static). The link has padding of 12px 24px and I cannot change it manually in any way. How can the padding be changed because it inserts unnecessary spacing relative to the main vertical menu div?

Screenshot of builder attached for reference, link-18 is highlighted so you can see the padding in the control properties panel.

Thanks for any help

.

[aykaramba]

Well, sometimes you just have to get some sleep before you can figure it out. Updates:

1. I am trying to keep as close as possible to the W3css classes as possible to try and minimize hacks and test just how well OUT OF THE BOX CLOG builder capability can take us.

2. It turns out the following class was defining the margins: w3-padding-large. This is interesting because CLOG (being built on W3css by default) is respecting the classes which is good because that will keep devs from shooting them selves in the foot and it keeps the separation between presentation and content VERY clear.

3. Also, you see how the left hand black bar renders BEYOND panel-1 boundries? That is caused by the following css class: w3-sidebar. I don't have any suggestions or thoughts on this just yet, however, it is rendering as if it would in a rendered window so ... yeah. It's fine I can work with this.

4. This also probably means that font awesome is not rendering because I did not include that in the headers. Updates in a bit.

[aykaramba]

5. With regard to body colour, it is set with: (setf (background-color body) :red). This is interesting conceptually. The builder only deals with the visual widgets and everything outside of that is handled by code in the correct application file. Not complicated but it takes a bit to visualize the distinction.

[rabbibotton]

BTW you do know that you can do the complete layout in plain html and just load it in and then resave after?

[aykaramba]

Hi! Yup. I really want to test how far I can get with builder though.

[aykaramba]

Okay, styling wise, I don't have any further questions, everything seems fairly straight forward.

Next, I am wanting to build an application with pull down menus just like in tutorial 22. I want to re-create a bunch of templates and let users select them from the menu so they can see what is possible in terms of design and how to hook it all up to the main menu provided by clog builder website template. However, I have run into a problem that I don't understand:

QUESTION: How do you load panel contents into a window:

1. Let's say this is my .asd:

(asdf:defsystem #:clos-contact
:description "New CLOG System"
:author "[email protected]"
:license "BSD"
:version "0.0.0"
:serial t
:depends-on (#:clog)
:components ((:file "clos-contact")
(:file "config-event-types")
(:file "manage-contacts")
(:file "contact-event")
))

2. Let's say that all three of my *.clog panels from above just have an html label in them and I just want to display the content of the panel.

3. Let's say my clos-contact.lisp has this menu:

(defun on-new-window (body)
(let ((app (make-instance 'app-data)))
(setf (connection-data-item body "app-data") app)
(setf (title (html-document body)) "CLOS-CONTACT")
(clog-gui-initialize body)
(add-class body "w3-indigo")
(let* ((menu-bar (create-gui-menu-bar body))
(icon-item (create-gui-menu-icon menu-bar :on-click 'on-help-about))
(cntct-item (create-gui-menu-drop-down menu-bar :content "Contacts"))
(contacts (create-gui-menu-item cntct-item :content "ManageContacts" :on-click 'on-manage-contacts))
(events (create-gui-menu-item cntct-item :content "New ContactEvent" :on-click 'on-new-event))
(config-item (create-gui-menu-drop-down menu-bar :content "Config"))
(event-types (create-gui-menu-item config-item :content "Manage EventTypes" :on-click 'on-config-event-types))
(report-item (create-gui-menu-drop-down menu-bar :content "Reports"))
(contact-rep (create-gui-menu-item report-item :content "Contact List" :on-click 'on-report-contacts))
(events-rep (create-gui-menu-item report-item :content "Contact Event List" :on-click 'on-report-events))
(help-item (create-gui-menu-drop-down menu-bar :content "Help"))
(help-about (create-gui-menu-item help-item :content "About" :on-click 'on-help-about))
(full-screen (create-gui-menu-full-screen menu-bar)))
(declare (ignore icon-item help-about full-screen)))))

4. Let's say that we have this example handler:

(defun on-manage-contacts (obj)
(let* ((app (connection-data-item obj "app-data"))
(win (create-gui-window obj :title "Manage Contacts")))
(declare (ignore app))
(create-manage-contacts (window-content win))))

QUESTION: Why does sly/slime say that create-manage-contacts is unbound? I could have sworn the clos-contacts create-manage-contacts handler worked as long as I had manage-contacts listed in the above .asd file. I don't see anything in the clos-contacts (Tutorial 4) instructions that is really different from what I have here. All I did was strip out the logic and the panel layouts to get the simplest possible version of the tutorial in order to explore the loading panels mechanism.

Can someone provide some guidance on what I am not understanding here?

Thank you kindly.

[aykaramba]

Oooohhkay. Figured this out. All of the above is correct, the problem was that the panels that I created had the default IN-PACKAGE property set. For any noobs reading this, the standard CLOG GUI PROJECT has the simplest defaults to work with. Create a new panel first and make sure you set the IN-PACKAGE property to the correct package, add the panel to the .asd file, edit the menu portion of your apps .lisp file and then the handler from above will work.

Note that if your panel name is MYPANEL then the handler would be something like this:

(defun on-manage-contacts (obj)
(let* ((app (connection-data-item obj "app-data"))
(win (create-gui-window obj :title "Manage Contacts")))
(declare (ignore app))
(create-mypanel (window-content win))))

I am not sure why the function is create-"NAME OF YOUR PANEL HERE" instead of something like panel-open :panel-name but I am sure there is a very good reason for it.

[aykaramba]

So, working through Tutorial 30, that uses the clog-web templating and it provides slightly different approach as each menu link refers to a route and "refreshes" the page (updates the dom I guess).

So we have:

1. The menu global:
   (defparameter *menu* (("Content" (("Home" "/" on-main)
   ("Content from Lambda" "/lambda" on-lambda)
   ("Content from File" "/readme" on-readme)
   ("panel" "/panel" on-panel) ))
   ("Help" (("About" "/about" on-about)))))`

2. The routes are created by the clog-web-routes-from-menu menu function in the start-tutorial () form.

3. The standard page handler looks something like this:
   (defun on-about (body) (init-site body) (create-web-page body :main (:menu ,menu
   :content "About Me")))`

So, all of that is straight forward and doing templating directly in the .lisp file is fine. However, I have looked at the clog-gui templating approach and I understand how to render panels into modal windows, this is straight forward but I am not able to visualize how to load the content of the panel into a clog-web based template that updates the actual body of the document.

A couple of questions:

QUESTION 1) Can we load panels saved in .clog files into the page it self?

QUESTION 2) Can we mix and match the display of panels we create in builder so that some handlers update body while other handlers render out into modal windows?

NOTE: I have tried mixing clog-web and clog-gui templating packages and there are symbol conflicts so I am assuming that we cannot mix and match, which is fair enough, that would make sense from a design perspective.

Thanks.

[aykaramba]

For any noobs that want to know what a handler would look like if you have the above menu from tutorial 30 lisp file, here it is:

(defun on-panel (body) (init-site body) (create-template01 body))

You also need to make sure:

• You have a panel created and saved as a .clog file named template02
• The panel MUST belong to the package it is in, you have to put the package name into the in-package field in the control properties window.
• You must RNDR the file to a .lisp file.
• The template02 file needs to be added to your .asd file:

(asdf:defsystem #:my-project-file-here :description "New CLOG System" :author "[email protected]" :license "BSD" :version "0.0.0" :serial t :depends-on (#:clog) :components ((:file "my-project-file-here") (:file "template01") ))

That will load up a link directly into the /panel route.

I hope that helps.

[rabbibotton]

QUESTION 1) Can we load panels saved in .clog files into the page it self?

yes as the .clog files are just html. but they won't function as any source code in the markup will just be sent to the user's browser. What you should do is render the clog file, and then use the create-xx function instead to place the content on the web page.

QUESTION 2) Can we mix and match the display of panels we create in builder so that some handlers update body while other handlers render out into modal windows?

The rendered panels work with CLOG-GUI and CLOG-WEB.

NOTE: I have tried mixing clog-web and clog-gui templating packages and there are symbol conflicts so I am assuming that we cannot mix and match, which is fair enough, that would make sense from a design perspective.

For the most part you can mix and match, just not a good idea and you would have to know a bit about CLOG-GUIs internals.

…

Message ID: ***@***.*** .com>

[aykaramba]

Aha! Perfect, thanks.

[rabbibotton]

I hope in the next months (I need to finish the api for adding controls and better layout of controls first) to redo the entire collection of learning materials with companion videos your input is very helpful. As I have stated my goal is to make using Lisp + CLOG something any one can do at any level. Of course the master can do more and do it more elegantly, but everyone should be able to enjoy creating software.

[aykaramba]

I am trying to learn enough to help with at least the tutorials stuff. Your enthusiasm comes through your writing but, then again, so does your yiddish. We need to spiff that up a bit + run the tutorials through a few iterations to see what needs to be explained better because you are a tad too close to your own project.

[aykaramba]

Two more points:

1. Not sure where my last edit went. Weird. Anyway, I was referring to your google docs tutorials, the tutorials in the CLOG folder are exceptional.

2. As a side point, one of my goals is to learn enough so that I can create my own control sets the way Elementor allows authors to package up controls into a package that can be just drag/dropped on to a page to cut down on the layout time. Builder is really kind of amazing already, I think you are very much on the right track with CLOG in quite a number of dimensions.

[rabbibotton]

Appreciated :)

[aykaramba]

Rabi Botton, since you mentioned "revamping" some aspects of build / layout capability, I have a request:

REQUEST: When you are considering the api for adding controls AND layout, can you take into account the use case of creating custom controls?

Yes, that is re-stating what you posted. However, what I mean by custom controls / layouts is this:

1. The core tools already exist in Builder.

I can use Panels to create custom controls and custom layouts. For example, I can already create libraries of custom forms, custom counters, custom sliders and so forth. It is all pretty straight forward and more powerful because CLOG is a synchronous framework which allows me to not just design the controls but build into them integration directly into my apps.

I can also use Panels to create entire libraries of layouts. I can create everything from entire page layouts to header, footer and custom content layouts with stand-in content.

This is already EXTREMELY powerful because replicates all of the core functionality of Elementor.

2. What doesn't exist (yet!) is a way to hook the library controls / layouts into the control palette. My thoughts here would be to create 3 palettes:

a) Control Palette - Standard application primitives as they exist already. This should almost never change as they are the basic building blocks of all applications.

b) Extended Palette - Custom widgets that all users can add to. As time goes on CLOG may acrete known good defaults and ship with a standard Extended Palette + allow devs to create their own custom Extended Palettes customized to their and their dev teams needs.

c) Layout Palette - This would be basically the same as the Extended Palette just re-named to Layout Palette where the community and individual dev teams can contribute their own layout libraries that specifically provide ideas and templates for doing modern web layouts. All of the builders these days offer libraries split into two categories: full page layouts and component layouts where the component layout would be something like a header or a hero section but a full page layout would be a whole template for a page (obviously).

The key idea that I am trying to communicate here is this:

• Virtually nothing new needs to be created.
• All of the core functionality already exists in the Palette + Panel technology. It is almost perfect already.
• All of the ideas above can be accomplished through the re-purposing of the Palette + Panel technology and adding the api interfaces to allow for the creation of libraries of widgets and templating components.

I hope that falls in line with what you have already envisioned for CLOG.

[rabbibotton]

Most of what needs to be done just needs documentation, you just need to add to the data structures in clog-builder-settings after loading clog/tools and then run the builder. My plan is just to simplify that process in the next few weeks.

…

On Tue, Jun 7, 2022 at 8:34 PM aykaramba ***@***.***> wrote: Rabi Botton, since you mentioned "revamping" some aspects of build / layout capability, I have a request: REQUEST: When you are considering the api for adding controls AND layout, can you take into account the use case of creating custom controls? Yes, that is re-stating what you posted. However, what I mean by custom controls / layouts is this: 1. The core tools already exist in Builder. I can use Panels to create custom controls and custom layouts. For example, I can already create libraries of custom forms, custom counters, custom sliders and so forth. It is all pretty straight forward and more powerful because CLOG is a synchronous framework which allows me to not just design the controls but build into them integration directly into my apps. I can also use Panels to create entire libraries of layouts. I can create everything from entire page layouts to header, footer and custom content layouts with stand-in content. This is already EXTREMELY powerful because replicates all of the core functionality of Elementor. 1. What doesn't exist (yet!) is a way to hook the library controls / layouts into the control palette. My thoughts here would be to create 3 palettes: a) Control Palette - Standard application primitives. This should almost never change as they are the basic building blocks of all applications. b) Extended Palette - Custom widgets that all users can add to. As time goes on CLOG may acrete known good defaults and ship with a standard Extended Palette + allow devs to create their own custom Extended Palettes customized to their and their dev teams needs. c) Layout Palette - This would be basically the same as the Extended Palette just re-named to Layout Palette where the community and individual dev teams can contribute their own layout libraries that specifically provide ideas and templates for doing modern web layouts. All of the builders these days offer libraries split into two categories: full page layouts and component layouts where the component layout would be something like a header or a hero section but a full page layout would be a whole template for a page (obviously). The key idea that I am trying to communicate here is this: - Virtually nothing new needs to be created. - All of the core functionality already exists in the Palette + Panel technology. It is almost perfect already. - All of the ideas above can be accomplished through the re-purposing of the Palette + Panel technology and adding the api interfaces to allow for the creation of libraries of widgets and templating components. I hope that falls in line with what you have already envisioned for CLOG. — Reply to this email directly, view it on GitHub <#141 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACYUEFLQ4V2HJZJLWNCOMOLVN7TBTANCNFSM5XUMHFJQ> . You are receiving this because you commented.Message ID: ***@***.***>

[aykaramba]

Sweet. Will look into that next, thanks for the heads up.

[aykaramba]

I have a new question: How do you change the color of the body of the page on click?

1. Using the application template above, I have the following menu item: (template09 (create-gui-menu-item templates :content "Template 09" :on-click 'on-template09))

2. I tried re-purposing the on-new-window function as follows:

(defun on-template09 (body)
(let ((app (make-instance 'app-data)))
(setf (connection-data-item body "app-data") app)
(add-class body "w3-red")))

This sets the background colour for the menu item. How is the document body it self accessed so I can control page colour, document name, etc?

Thanks.

[rabbibotton]

The issue is that in your defun the parameter "body" is not set to the body object of the page but to the result of create-gui-menu-item which is your menu item. You probably should change body in your snippet to obj to not be confused.

As far as getting the body object, you could store it in your app-data object in your on-new-window handler that is called with the body object or you can use the function - connection-body

So you could write

(defun on-template09 (obj)
(add-class (connection-body obj) "w3-red"))

[aykaramba]

As part of testing, the connection-body function is a lot of fun. For example, it is easy to create a function that adds objects to the DOM:

(defun on-template09 (obj)
(create-div (connection-body obj) :content "w3-red")
(create-button (connection-body obj) :content "button")
(create-img (connection-body obj) :url-src "https://common-lisp.net/static/imgs/lisplogo_flag2_128.png")
(create-video (connection-body obj) :source "https://www.w3schools.com/html/mov_bbb.mp4")
(create-text-area (connection-body obj))
(create-meter (connection-body obj) :high 100 :low 0 :value 35)
(create-description (connection-body obj) :content "alsdkjfj alsdkf jasdlf d")
(create-hr (connection-body obj)))

I realize that in order to properly interact with DOM objects that we create they need to be bound to variables and data structures. I was curious, is there a way to evaluate the state of the existing DOM in CLOG? If yes, are there ways to manipulate the DOM objects without them being bound to variables?

Not an important use case, just trying to visualize how everything is tied together.

Thanks.

[rabbibotton]

"CLOG-Obj - Internals for Extensions and Plugins"
(html-id generic-function)
(execute generic-function)
(query generic-function)
(js-execute generic-function)
(js-query generic-function)
(set-on-event generic-function)
(set-on-event-with-data generic-function)

"CLOG-jQuery methods"
(jquery generic-function)
(jquery-execute generic-function)
(jquery-query generic-function)

With those you have total access to JavaScript and jQuery to do as you will with the DOM as if you were on the user's local browser. CLOG is basically built on these.

All of clog sits on top of clog-connection that is the actually mechanics of communication and for the most part js-execute and js-query are the only to functions using clog-connection. So for example to run CLOG on iOS or Android, or native on Mac,Linux or Windows you just pipe those to functions directly to a WebKit control on one of those platforms.

There you go CLOG internals in a nutshell.

[aykaramba]

Whoa. Thank you very kindly! What a wonderful toolkit.

[rabbibotton]

Well that is CLOG :)

[aykaramba]

Good afternoon Rabbi.

I am really enjoying the updates, your dev cycle is so fast it is hard to keep up!

Absolutely everything is better, faster and more magical. I did have a couple of comments and thoughts on the new UI layout ideas:

• I agree with maximizing the Control Palette and Properties Palette windows. I have been maximizing them my self as well anyway.

• I am not sure about sticking the Control List chooser in the bottom left hand corner, even on a 4k monitor it is annoyingly unusable.

I have attached a screenshot for reference.

I am not sure what the correct way to handle this is. A generalized way might be to allow for users to float each of those 4 Palettes as windows just as they were before and add a vertical maximize icon that allows users to either stick the windows to one of the other side of their display and arrange them side by side. This might give users the flexibility to organize their tools as they wish while giving them also the ability to maximize vertically those Palettes they may need lined up. I don't think having palettes vertically aligned by default, unless a user really wants to setup their ui that way is going to be too useful just because of number of items each Palette needs to list. With floating windows that could be vertically maximized or organized how the user wants, it would allow for a SAVE WORKSPACE LAYOUT feature where we can provide users the ability to define their own layouts and save them for whatever project they working on.

It has not been unusual for me to vertically maximize 3 or even 4 of the Palette windows SIDE by SIDE and then have my layout window in the middle, for example. Sometimes I would just have 1 vertically maximized window, sometimes two with Control Events Palette opened up 3/4rs, and so forth.

Note: I realize that I am ostensibly describing a tiling window manager already here, I apologize for the scope creep. For a half a second I had the image of me making StumpWM a dependency of CLOG and writing a module to make it aware of CLOG windows ... Hehe! Anyway ...

In my screen shot, I have imported a W3CSS template. This templates has a HUGE number of divs and the Control List Palette is simply way way way too small to be useful.

For me, I would want each one of those 4 Palette windows to be vertically maximizable as all of them can be (and will be on sophisticated layouts) taller than even the maximum resolution on a 4k monitor. I will be moving to an 8k monitor in the next year or so, but for users on regular monitors, the usability of tiny windows that cannot be resized is going to be a substantial issue.

Thoughts? Questions?

[rabbibotton]

So let's say we start with 50/50 split and make the split resizable for the control palette and the control list?
Also thinking about moving the event list to also be a docked style of window?

[aykaramba]

First: Okay, did not expect a response in 5 minutes!

Second: I don't want to distract you with UI stuff too much. I can live with this, maybe others should comment as well. There may be more useful things to work on.

Third: I have a 4k tv as my monitor and for me, I really want all 4 Palettes vertically maximized side by side, squeezing Palettes into the edges is not use of good realestate. On an 8k tv it will get even more silly.

Fourth: I think you are fighting with this issue because you are trying to provide users with regular monitors maximum utility of screen realestate and you are being forced into providing menu folding to accomodate.

I think I can describe the interface generalization here into three categories:

a) WINDOWED LAYOUT - Float all Palettes like before, add a vertical maximize feature so users can vertically maximize their Palettes and stack them side by side or even vertically into 1/2, 1/3, 1/4 layouts so that they get the ui folding idea that you are working with.

b) STACKED LAYOUT - A subset of the above, just allow for users to stack Palettes into left and right columns and by default offer a 50/50 split with ability to resize.

c) DOCKER - Whenever I use a Mac I make docker hide but that is because I use Linux + StumpWM tiling window manager and for me everything is maximized or split into 1/2, 1/3 or 1/4. This would be something Mac users should comment on, I am not sure what to think of it. I guess it might be interesting idea from the old CDE desktop metaphor, I don't know.

My preferences is for a) above, but, again I don't want to bog you down on UI minutia. Anyone else have any input?

Thank you kindly for the feedback Rabbi!

[rabbibotton]

I moved it to 50/50 and added a divider (no resize yet) for now so can see how it looks. After this iteration (almost done) I'll work more on UI and in particular allowing configurability in more diverse ways.

[aykaramba]

Neat!

1. When CLOG Builder loads up, the 50/50 split is awesome.

2. I just git cloned the repo. When I load up the W3CSS template with tons of divs, the Tools Palette gets squished, screenshot attached.

Please note that I did not want to distract you with UI issue for this very reason. Getting UIs to work is usually a lot more work than it seems and this might be an example of how even a small tweak turns edge case scenarios into tons of wheel spinning.

In general, 50/50 split is excellent, looks a lot better and the scrolling capability is perfect. I would say go with that for now, that should work on all monitor resolutions.

As a side point, the maximize window feature is fantastic, I love having the window maximized between the panels for large layouts

.

[aykaramba]

Follow up:

1. Linux / Brave - 50/50 split works great.

2. Linux / Firefox - Tools Palette gets squished to the top. Refresh does not fix it.

3. Linux / Chromium - Tools Palette gets squished to the top. Refresh does not fix it.

[aykaramba]

Follow up:

1. Windows / Brave - Tools Palette gets squished to the top. Refresh does not fix it.

2. Windows / Firefox - Tools Palette gets squished to the top. Refresh does not fix it.

3. Windows / Chromium - Tools Palette gets squished to the top. Refresh does not fix it.

[rabbibotton]

pull again should work now (lmk)

[aykaramba]

Thank you kindly.

SUMMARY: It works on all platforms, but you need to resize the browser in a way that affects its size in the Y axis to get the 50% split to resize and render.

For me this is good enough.

TESTING METHODOLOGY:

• Clear all browsing cache from all browsers on all platforms.
• Linux - reboot to start fresh
• Windows - reboot to start fresh
• OSX - reboot to start fresh

TESTING RESULTS:

Linux + Tiling WM (StumpWM)

• Brave - Works on-load, 50% is rendered properly
• Firefox - Works after window size changed manually or via full screen mode
• Chrome - Works after window size changed manually or via full screen mode

Linux + XFCE

• Brave - Works after window size changed manually or via manual window (mouse drag) resize.
• Firefox - Works after window size changed manually or via manual window (mouse drag) resize.
• Chrome - Works on-load, 50% is rendered properly

Windows 10

• Brave - Works after window size changed manually or via manual window (mouse drag) resize.
• Firefox - Works after window size changed manually or via manual window (mouse drag) resize.
• Chrome - Works after window size changed manually or via manual window (mouse drag) resize.

OSX

• Brave - Works after window size changed manually or via manual window (mouse drag) resize.
• Firefox - Works after window size changed manually or via manual window (mouse drag) resize.
• Chrome - Works after window size changed manually or via manual window (mouse drag) resize.

I can perform more detailed tests if you like. For me, this is good enough. Resize is really nice btw, love that.

[rabbibotton]

If you can just run all your tests again, let me know. It should all be working well now.

[rabbibotton]

Ok, done, resizing now works on window change, window full screen and changing orientation of monitor

[aykaramba]

Confirmed as working on-load. Test results:

Linux + Tiling WM (StumpWM)

• Brave - Works on-load
• Firefox - Works on-load
• Chrome - Works on-load

Linux + XFCE

• Brave - Works on-load
• Firefox - Works on-load
• Chrome - Works on-load

Windows 10

• Brave - Works on-load
• Firefox - Works on-load
• Chrome - Works on-load

OSX

• Brave - Works on-load
• Firefox - Works on-load
• Chrome - Works on-load

Thank you Rabbi. Best support ever.

[rabbibotton]

Would you mind testing out the load, save and render dialogs cross platform? Appreciated either way!

…

On Sun, Jul 3, 2022 at 5:55 PM aykaramba ***@***.***> wrote: Confirmed as working on-load. Test results: Linux + Tiling WM (StumpWM) - Brave - Works on-load - Firefox - Works on-load - Chrome - Works on-load Linux + XFCE - Brave - Works on-load - Firefox - Works on-load - Chrome - Works on-load Windows 10 - Brave - Works on-load - Firefox - Works on-load - Chrome - Works on-load OSX - Brave - Works on-load - Firefox - Works on-load - Chrome - Works on-load Thank you Rabbi. Best support ever. — Reply to this email directly, view it on GitHub <#141 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACYUEFKLWIJ6QYOLUQFFRP3VSID6ZANCNFSM5XUMHFJQ> . You are receiving this because you commented.Message ID: ***@***.***>

[aykaramba]

No problem at all. If you need any testing done, just ask. Give me a bit, I have to take care of something first. Otherwise, just let me know what you need tested.

[aykaramba]

I have completed testing on Linux / OSX / Windows.

SUMMARY:

Everything works okay except that there is something going on with how CLOG enumerates threads maybe? The first browser that opens up a session with /builder ends up being the TARGET into which CLOG pushes a new tab (window) when you select the TEST dialog. This doesn't matter if it is on the same computer or a different computer. I have a few laptops from which I was able to select TEST and have the Panel rendered into the original computers browser.

At some point in time, you should separate out this issue into a separate security module / process and deal with this issue in a separate / itemized way because on complicated applications this sort of thing might become a serious security issue.

Let me know if you have any questions or any of the results need to be explained. I would be happy to continue to do QC / testing if you like.

TEST RESULTS:

Between each browser re-load:

• Delete any *.clog, *.lisp and *.back files

Test #1 - In each browser:

• Load HTML template file originally sourced from W3CSS here: https://www.w3schools.com/w3css/w3css_templates.asp
• Save Dialog - Save to template.clog file
• Render Dialog - Save to template.lisp file
• Test Dialog - Run the test dialog

Test #2 - In each browser:

• Delete - Blank CLOG-GUI Panel, create image, delete image
• Undo / Redo - Blank CLOG-GUI Panel, create image, move image to each of 4 corners of window, undo to beginning, redo to end
• Cut / Paste - Blank CLOG-GUI Panel, create image, cut image, paste image.
• Copy / Paste - Blank CLOG-GUI Panel, copy image, paste image.

Linux + Tiling WM (StumpWM)

• Brave - 1 fail - Test Dialog failed to open up a new tab, all others ok
• Firefox - All tests passed.
• Chrome - 1 fail - Test Dialog failed to open up a new tab, all others ok

Linux + XFCE

• Brave - All tests passed.
• Firefox - 1 fail, Firefox opened up Test Dialog in Brave browser in this session, all others ok
• Chrome - 1 fail, Chrome opened up Test Dialog in Brave browser in this session, all others ok

Windows 10

• Brave - 1 fail - Test Dialog sent the new tab TO THE WRONG COMPUTER. The Windows 10 Brave opened up a new tab on my Linux FF browser connected to Clog Builder. All other tests ok.
• Firefox - 1 fail - Test Dialog sent the new tab TO THE WRONG COMPUTER. The Windows 10 FF opened up a new tab on my Linux FF browser connected to Clog Builder. All other tests ok.
• Chrome - 1 fail - Test Dialog sent the new tab TO THE WRONG COMPUTER. The Windows 10 Chrome opened up a new tab on my Linux FF browser connected to Clog Builder. All other tests ok.

OSX

• Brave - 1 fail - Test Dialog sent the new tab TO THE WRONG COMPUTER. The Windows 10 Brave opened up a new tab on my Linux FF browser connected to Clog Builder. All other tests ok.
• Firefox - 1 fail - Test Dialog sent the new tab TO THE WRONG COMPUTER. The Windows 10 Firefox opened up a new tab on my Linux FF browser connected to Clog Builder. All other tests ok.
• Chrome - 1 fail - Test Dialog sent the new tab TO THE WRONG COMPUTER. The Windows 10 Chrome opened up a new tab on my Linux FF browser connected to Clog Builder. All other tests ok.

[rabbibotton]

Thanks!

[rabbibotton]

My last push should fix the issue of open browsers in random places. OPEN-BROWSER is a helper that really exists just for start up. OPEN-WINDOW should have been used that launches a new window/tab

Let me know how tests work out now. Thanks!

[aykaramba]

TEST RESULTS:

Between each browser re-load:

Delete any *.clog, *.lisp and *.back files

Test #1 - In each browser:

Load HTML template file originally sourced from W3CSS here: https://www.w3schools.com/w3css/w3css_templates.asp
Save Dialog - Save to template.clog file
Render Dialog - Save to template.lisp file
Test Dialog - Run the test dialog

Linux + Tiling WM (StumpWM)

Brave - ok
Firefox - ok
Chrome - ok

Linux + XFCE

Brave - ok
Firefox - ok
Chrome - ok

Windows 10

Brave - ok
Firefox - ok
Chrome - ok

OSX

Brave - ok
Firefox - ok
Chrome - ok

SPECIAL NOTES AND OBSERVATIONS:

1. CLOG is run and loaded on the main workstation.

2. Main workstation tests are done via: http://localhost:8080/builder

3. LAN tests are done via ip: http://x.x.x.x:8080/builder

4. All tests open up as tabs in the browser that is being used for /builder testing. No more opening up the TEST render in other browsers. This is fixed.

5. IP ADDRESS - Local machine - Whenever the test button is rendered on the local workstation where CLOG is running, it opens up properly in a new tab via http://localhost:8080/test

... however ...

6. IP ADDRESS - Other computers on the LAN - Whenever the network laptops click the TEST button to render a page, the test pages open up correctly in a new tab but they try to open up the link as follows: http://localhost:8080/test and they "should (maybe?)" be aware of their local ip and open up as http://x.x.x.x:8080/test.

I am not sure how important this is, just an interesting artifact.

7. SPEED - So, between loading up /builder in each browser I did the following:

a) Delete the test-template.clog and test-template.lisp files.

b) Loaded up /builder in a new browser then loaded up the .html template file in a new panel.

c) Once the html file was loaded an panel and palettes populated I would first hit SAVE to save a .clog file. Then I would wait and watch my file manager for the .clog file to appear.

d) Once the .clog file appeared, I would hit RENDER and render out the .lisp file. The I would wait and watch my file manager for the .lisp file to appear.

e) Only once the .lisp file appeared did I click TEST to render out a test in a new tab.

What I wanted to share here was that saving out .clog and .lisp files seemed to be fast on the local workstation but the laptops on the lan would take between 10 second and 40 seconds to either render out a file AND/OR render out a TEST. After clicking TEST on a laptop on the lan, it too would either take 3 to 40 seconds to open up a new tab. I did not do extensive testing on this, just noticed the pattern.

I am not sure how important this performance metric is, I thought you might be interested in these data points.

Test #2 - In each browser:

Delete - Blank CLOG-GUI Panel, create image, delete image
Cut / Paste - Blank CLOG-GUI Panel, create image, cut image, paste image.
Copy / Paste - Blank CLOG-GUI Panel, copy image, paste image.
Undo / Redo - Blank CLOG-GUI Panel, create image, move image to each of 4 corners of window, undo to beginning, redo to end

Linux + Tiling WM (StumpWM)

Brave - ok
Firefox - ok
Chrome - ok

Linux + XFCE

Brave - ok
Firefox - ok
Chrome - ok

Windows 10

Brave - ok
Firefox - ok
Chrome - ok

OSX

Brave - ok
Firefox - ok
Chrome - ok

NOTE: No issues here, everything works great.

Let me know if you need any other testing done.

[rabbibotton]

Really invaluable help. Thanks so much!!

[aykaramba]

Happy to help.

[rabbibotton]

1. As a side point, one of my goals is to learn enough so that I can create my own control sets the way Elementor allows authors to package up controls into a package that can be just drag/dropped on to a page to cut down on the layout time. Build is really kind of amazing already, I think you are very much on the right track with CLOG in quite a number of dimensions. The code for that is practically already there, as long as the other

controls are all children of a control that control can be cut and pasted even between panels. You can create a panel that has a collection of such layouts to use at will. As part of the code of allowing new controls that wrap JS etc, that is sort of how custom controls that are all lisp will be implemented.

…

Message ID: ***@***.*** .com>