I must be missing something in Xojo - new user here: Working on an industrial app conversion from VB to Linux, and I’ve got a whole folder full of .ICO icon files that go on various control buttons. So I add a bevel button (or whatever image friendly control) to my form, go to inspector and under "icon"property I browse to my icon folder (all permissions set for full access for everyone) and all the .ICO files are filtered out. The file selection filter is set to All Picture Files or All Files. Xojo Linux pretends those icon files aren’t there. I can’t import .ICO files, or drag them in from desktop file manager. These are single size, single image icons. PNG, JPGs etc work.
Is there a way to get ICO files to work inside Linux IDE? Is there some setting that needs adjustment before Xojo can recognize .ICO files?
When I do get a PNG file to work, it is always brought in full size - no scaling is done larger or smaller. Is there a way to get the image files scaled - or even cropped to fit inside a control? We’d like to keep the GUI at least somewhat responsive to monitor layout, so we need a way to use larger or smaller icon images as needed.
.ICO files are mainly a Microsoft Windows thing, for a more cross platform format stick with PNGs. You’ll have to manage all the scaling when you assign these to a BevelButton for example, since there’s no telling how big/small you really want this from our end.
I have to stick to design guidelines and use existing ICO files.
Xojo Windows IDE will let me import ICO icon files all day long and assign them to controls…then I have to save the project on Windows side and then re-open the project in Linux, and the icon files show up on the controls.
The Linux IDE is NOT showing “All Files” when I go to import various image files. It does work fine in Windows IDE.
So far, Xojo doesn’t seem well-tested in Linux, or at least it doesn’t seem to do what it -should- do.
In this case it’s more about what’s natively available. Windows has built-in support for ICO files in its picture reading libraries, Linux doesn’t.
FWIW, when you load an ICO file into the IDE on Windows, they’re converted to PNG just as William suggested, which is why you can do what you did. PNGs are pretty ubiquitous.
OK. I thought it was another Qt or Gtk widget, which do take ICO file (and resize / crop) as well - in Linux. See how Qt5 & Gambas3 handle the same situation.
The question remains: If I open the “Import” file browser in Linux Xojo, and I have it set to show “All Files”… then why is it not showing me “all” the files in the folder. That behavior doesn’t seem correct.
Oh well.
You still need to create file types for the things you do accept and apply them to the Filter. All Files means “all files that I can accept” not “all files on the machine”.
Now you can create a File Type that represents “all files” and I suspect that would do what you’re expecting.
Thanks Greg!
I see - It’s just a surprise that I can select .ico files in other IDE apps in Linux, and they are handled just fine. Converting image files can be done of course, just looking at what Xojo thinks it can digest - and what happens when it can’t.
It’s also a surprise than on image files that Xojo can accept (png etc.) they aren’t resized or cropped to the control boundaries - and other systems handle that task fine in Linux (with Qt / GTk support).
I’m just testing to see what Xojo Linux IDE can and can’t handle on its own, and comparing to what other IDE’s do for design and layout.
You have two choices:
a. provide the images at the correct size;
b. resize the files using g.DrawPicture.
I suggest using a:
place the images at the correct size in a folder with “btn_” as prefix (to know they are for buttons) and drop that folder in the Navigation pane (IDE left part).
Then, you can apply them to each button backdrop in the IDE.
There is no need to store a large image into an applcation when a smaller can be used instead.
Yes, that’s what we used to do when we had one monitor size / resolution to work with. When the application has to resize for different monitors you’ll want both the control and icon image to resize as required. Generally we use an icon of the largest size we’d need on the button backdrop, and let the control widget resize the image as required. It takes zero additional steps that way and you don’t need the same image of multiple sizes. For example: like how Qt / Gambas does it on Linux.
This reference is meaningless (for me); but I like the idea. I hope some other reading person will chime in with advice.
For instance…Here is the result of a simple way we do it in Gambas or Qt, etc - Send an image to a control’s background, & let the control widget resize the image to fit. Even at runtime if the control is resized, we don’t care…the image will always resize with the control. In other words: let the system handle the image housekeeping. No messing around manually adjusting the image size, no extra files to maintain, no extra draw commands - it just works. This screenshot is from Gambas but Qt’s IDE will produce the exact same result - without extra coding. Of course Qt and Gambas serve different needs than Xojo, I’m just showing what can be accomplished in the IDE before writing one line of code.
I know Xojo could have code added to re-dimension an Icon image to fit a control…but that’s extra steps. Time is money, and if I have to spend more on employee labor time, that’s kind of a drag.
The problem is for this industrial application, there will be different controls presented to the operator depending on what features are in use - so a touch screen area might be setup for a 3 X 2 tool button array, but that will need to change to a 3 X 3 or 3 X 4 area depending on what’s happening. Then you’ve got several different monitor resolutions to worry about for various HMI displays depending on age of equipment. And so on.
So we need to build a quasi-responsive type of GUI that can fill out a monitor display as required - without having a bunch of image icons stored for each layout size.
I was just curious if Xojo could handle that out of the box, but it looks like extra steps are needed for control background image resizing.
Imagine you have a Canvas who can enlarge/shrink like its Window.
In the Paint Event, you place the code to display the ison using th Canvas Width and height.
Each time a resize is done to the window, the Canvas will be resized too, and so the icon too.
Logic, not verified with code.
Remember: AFAIK, .ico files max size is 256 x 256.
Better: make a custom sub-class of that Canvas,
place the code in that sub-class,
Set every Canvas Super to that sub-class.
Et voilà: one code written, used in all of your Canvas.
Is it OK for you ?
Thanks Emile,
Yes we’ve tried those techniques before, but not on Xojo. In theory that technique can work on simple layouts. What can happen is if you explicitly force an image resize, and the system doesn’t realize it’s the same image it just resized on the previous paint event (and it still has a clean cached image already resized) - you can see some performance issues when you’ve got 50 or 80 controls being updated on the GUI… Maybe Xojo is smart enough to manage that situation better - we’d have to test. A lot depends on display hardware, and we have to allow for some slower hardware in the field.
We have to try to let the underlying graphics system handle as much resizing as possible on its own since these controls are being used on & around a machine vision video display window, running at perhaps 60 to 70fps. If we’re not careful, we get either the video window or the controls flickering at certain points during forced explicit resize / paint events, and those problems can be tricky to track down and cure.
By the way, we use a mix of .ico, .png and svg files, all the time. It’s interesting that Xojo Linux only knows about our PNG files (even when import file browser is set to “all pictures” the .ico and .svg files are not shown). All other Linux IDE’s we use natively handle all common image formats, and several not-so-common ones.
Xojo Windows can handle .ico and png files OK. It will show svg files in an import file browser, but apparently won’t let you use it anywhere - at least not when I was trying to add an svg image to a bevel button. PNG and Jpg worked OK.
Maybe a plugin is required or feature turned on, not sure.
