IceDesign GUI designer

[Clanzer]

I found that everything works very well for resizing (Forms, Buttons, etc)
except the font sizes on the buttons, etc. which remain the same.

I don't know if it's suitable for everyone, but maybe there's something I could add.
I'm saving the idea for after the summer vacation which is closer for me.

If you use the same font for all Gadgets, you can probably do it with something like this

Purchased IceDesign and well worth the money.

The auto gadget re-size works great in IceDesign and adding the font re-size routine would be great.

Cheers

Sean

[ChrisR]

Hi Sean,
About the font re-size routine, I still have the same doubts about its usefulness and common practice.
I asked ChatGPT what is generally done in practice to resize fonts relative to window size.
Here is his answer (translated with DeepL), more complete than I could provide:

In desktop UI development (including in PureBasic), resizing the window does not usually involve automatically resizing fonts.
And it is not common practice to resize text proportionally to the window.

Here are the usual practices and reasons:

Common practice in most applications

Fonts remain fixed even if the window is enlarged.
Controls can be enlarged (gadgets, text boxes, lists, etc.).

This allows you to:
- display more text content (string gadgets, editor gadgets, etc.),
- avoid a “cartoon” effect where everything is unnecessarily enlarged,
- maintain visual consistency (the typography does not change with each resize).

This is what the following do:
- Windows Explorer
- Browsers
- Most office applications
- File managers, text editors, etc.

When do we resize the font?

Rarely, but it can be done in two cases:

1. Highly graphical or presentation-oriented interfaces

E.g.: drawing software, control panels, touch screens, dashboards.
Objective: to maintain consistent readability on a large screen.

2. Accessibility feature / User zoom

Some software offers:
- interface zoom (an option in the preferences),
- or a customizable font.

But this is never automatically linked to simply resizing the window.
...

I don't have much time right now, but maybe it could be considered as an option if there is a real need !

[Clanzer]

Hi Sean,
About the font re-size routine, I still have the same doubts about its usefulness and common practice.
I don't have much time right now, but maybe it could be considered as an option if there is a real need !

Hi Chris

Thanks for the info, but I do not really understand why it is not useful.

The code example you pasted in a earlier post worked great and re-sized the fonts.
If the fonts are not re-sized I get the following where in the normal start size the screen looks like this


Then after re-sizing you can see in picture below that the fonts cannot be read


With the Titles like Enter Bobbin Width I created images that re-size okay to get around the fonts not re-sizing.

Or am I missing something here that I am not setting somewhere?

Thanks

Sean

[ChrisR]

Thanks for the pictures, Sean
I understand better the usefulness of having proportional fonts here, less for strings or editor gadgets allowing more text to be displayed.
It could be an additional option in the settings associated with "Proportional size for all gadget"
I can't promise anything for timing, as I'm quite busy at the moment, but I'll look into it.

Another option to consider, to avoid being below the minimum required size for gadgets would be to design for the minimum window size and specify the minimum window bounds in its properties.

[ChrisR]

IceDesign has been updated in version 2.3.8

• Add the option: Font size scaled
  It is a sub-option of "Proportional Size for All Gadgets"
  
  Note: By default, most applications and classic interfaces do not use this font scaling but only scaling based on DPI

[Clanzer]

Brilliant !

Works like a charm, thank you so much Chris

IceDesign has been updated in version 2.3.8

[BarryG]

Just downloaded the demo for another look. Wow, this is fantastic! I may want to use this for future projects.

One thing is stopping me buying at the moment: I put a ButtonGadget on the form, but I can't see any way to tell it a procedure to call when clicked, or when right-clicked, etc? Because when I create the code for it and run it, clicking the button shows a message box with some text. Is that meant to be in the editor somewhere?

I'd love the properties box to have a section called "Procedures" and entry boxes for left, middle, and right clicks; and keypress, where we can name our own procedures in each box for mouse clicks and keypresses to be called for that gadget. I could then have my own standalone "Procedures.pbi" file that wouldn't be affected by editing the gadgets on the form. This would be the nail in the coffin that makes me buy.

[ChrisR]

Thanks Clanzer, glad it responded to your request

Hi BarryG,thank you for trying it out and glad that you like it.
For now, there is no section titled “Procedures” with input fields for left, middle, and right clicks or key presses in the properties but it's a good idea
However, there is the “Bind Event” property but the procedure name cannot be changed,
it is automatically generated based on the Gadget name (#Button_Yes --> Procedure Event_Button_Yes()).
It is also possible to do the same for All Gadgets, in the settings with the option "Bind All Gadgets Events" and with the optional sub-option “Bind Events in an IncludeFile”

[BarryG]

Oh, I see. I tried ticking "Bind Event" and I see what you mean, but "Bind Events in an IncludeFile" still gets overwritten when I click "Create Code" (F7), so I can't use it. I need a way for my gadget event codes that I add to always be kept safe, no matter what I do for the GUI gadgets in the form editor.

If I could just name a procedure for a left/middle/right click, and for a keypress, then I can just use my own IncludeFile for my gadgets (nothing to do with IceDesign) and therefore all is safe and not overwritten with F7.

[Joe]

Hi Chris,
regarding the "Bind Event" in above Picture:
"Create Code" still puts the Procedures into the form code, even if "Bind Events in an IncludeFile" is checked.

"Create Code" also puts a
;- Main Program
If Open_frmMain()

Repeat : Until WaitWindowEvent() = #PB_Event_CloseWindow
EndIf
into the form code, even if "Add Compiler isMainFile" is unchecked.

So, after creating the form code, both sections has to be deleted by hand ...

And while I'm just writing ..-Can you pls but a "#SS_Notify" to to TextGadget constants?

Cheers, Joe

[ChrisR]

@BarryG
I also understand your request, but I don't really see how I could do it!

The code is generated to be always functional right out of the box, with also the preview and I think that's an important point for a designer.
I have no problem with the automatically generated procedure names, they are always in sync between BindGadgetEvent() and the procedure names written.

But I don't know how I could get a 100% functional code with specific procedure names BindGadgetEvent(), but without these procedures in the generated code, defined by the user elsewhere in an included file.
Also, I don't see an easy solution to avoid overwriting and preserve the changes made by a user in the Bind Event procedures, and create them if they do not already exist.

[ChrisR]

@Joe
I'll look into “Bind Events in an IncludeFile”, currently it is used only as a sub-option of “Bind All Gadgets Event” in the settings.
But, indeed, it should also work with the Bind Event property if defined for 1 or more Gadgets.

There is a misunderstanding, I believe about “Add Compiler isMainFile”
This option only adds "CompilerIf #PB_Compiler_IsMainFile" to the source code before the Open window and the event loop.

Code: Select all

;- Main Program
If Open_frmMain()

Repeat : Until WaitWindowEvent() = #PB_Event_CloseWindow
EndIf

Is always written but inside "CompilerIf #PB_Compiler_IsMainFile and CompilerEndIf" if the option is enabled
It means that Open_frmMain() and the event loop are included in the compilation and operational if you execute this source code directly, to test this window individually for example.
But it is not included in the compilation if this code is included and called from another main source code (MainFile).

I don't know in which case you use #SS_Notify with a TextGadget, but no problem, I can add it.

[Joe]

Might be a mistunderstandig!?

I want to create the form with IceDesigner and include the generated code in the main program.

How can I get rid of these Open_frmMain()

It will be called from the Main program.

THX Joe

[ChrisR]

I want to create the form with IceDesigner and include the generated code in the main program.

You mean, include with: XIncludeFile "YourForm.pb" in the main program not by copy/paste
If yes and it's the right way to do it, then enable the option “Add Compiler isMainFile” for your form
When you compile your main program, your form included will not be the Main File and therefore all the code between CompilerIf #PB_Compiler_IsMainFile and CompilerEndIf will not be included in the compilation.

Example:
YourForm.pb

Code: Select all

Procedure Event_Button()
EndProcedure

Procedure Open_Window(X = 0, Y = 0, Width = 240, Height = 90)
  If OpenWindow(0, X, Y, Width, Height, "Title", #PB_Window_SystemMenu | #PB_Window_SizeGadget | #PB_Window_ScreenCentered)
    ButtonGadget(0, 20, 20, 200, 50, "Button")
    BindGadgetEvent(0, @Event_Button())
    ProcedureReturn #True
  EndIf
EndProcedure

CompilerIf #PB_Compiler_IsMainFile
; Not included if compiling from a main file
If Open_Window()
  Repeat : Until WaitWindowEvent() = #PB_Event_CloseWindow
EndIf
CompilerEndIf

MainFile.pb

Code: Select all

XIncludeFile "YourForm.pb"
; Main code:
If Open_Window()
  Repeat : Until WaitWindowEvent() = #PB_Event_CloseWindow
EndIf

When compiling MainFile.pb, the code seen by the compiler will be:

Code: Select all

Procedure Event_Button()
EndProcedure

Procedure Open_Window(X = 0, Y = 0, Width = 240, Height = 90)
  If OpenWindow(0, X, Y, Width, Height, "Title", #PB_Window_SystemMenu | #PB_Window_SizeGadget | #PB_Window_ScreenCentered)
    ButtonGadget(0, 20, 20, 200, 50, "Button")
    BindGadgetEvent(0, @Event_Button())
    ProcedureReturn #True
  EndIf
EndProcedure

; Main code:
If Open_Window()
  Repeat : Until WaitWindowEvent() = #PB_Event_CloseWindow
EndIf

So you can test YourForm.pb on its own or test MainFile.pb, without the Open_Window() and event loop from YourForm

[Joe]

Ahh, I've to include to get rid off
My fault

THX Chris