Two CUI issues

Roy Klein Gebbinck

I am planning to 'port' some of my Lisp utilities to BricsCAD on Linux and I am running into several issues. Two of which concern (partial) CUIs.
BricsCAD 13.1.19
Ubuntu 12.4 LTS

1.
On Windows I use a resource file (.dll) as a container for bitmaps. This is not recognized a resource file on Linux. I am aware that .dll files belong to the Windows platform although it appears that Linux employs a similar concept using .so files. Is the use of a resource file possible for a CUI on Linux? And if so, what is the correct file format and extension?

2.
When a CUI with multiple floating toolbars is added to BricsCAD, all toolbars end up bunched together in the lower right corner of the screen. If you move the top one to a new location all the other bunched up toolbars become invisible and you have to restart BricsCAD for every toolbar you want to move. Using the CUSTOMIZE dialog box to change the position does not work. In fact after hitting APPLY and OK all floating toolbars are bunched up again. How can I create a partial CUI so that toolbars end up in the right place?

Torsten Moses

Dear Roy,

for problem #1 - resource DLLs :
indeed, those .so files are also "shared libararies" which work with a very similar concept as Windows .dll files - so far so good.

But the logic to embed resources into a DLL (or shared library) are Windows specific, those resources are always MFC-based only,
as MFC is a native part of Windows OS.

Under Linux, there is
a) no similar GUI component present across all unix/linux systems, so it is simply undefined, which kind of resources should be embedded
b) and even more, the .so shared libraries are (as logical consequence of a) point) not providing similar file structure to embed wharever
    kind of resources, unfortunately

So there seems no other option than to use plain bmp/jpg/png files ... CUI file can specify i.e. "subfolder/Icon1.jpg" to have all icons
in a central place below a defined support path (CUI supports relative pathes)

for problem #2 - toolbar position
if I'm not completely wrong, the initial toolbar position can be defined in a CUI file ... please have a look at standard CUI files installed
with BricsCAD, you will notice the positions for toolbar entry
-> so you can define your own initial positions then, solving that "position clashes" :-)

Many greetings & a nice week !

Jason Bourhill

Perhaps resources could be placed in a ISO, zip, .tar? Mount this as a folder/drive on startup of BricsCAD, unmount on exit.

regards,

Jason Bourhill

CAD Concepts

Roy Klein Gebbinck

@ Torsten:
I should clarify problem #2:
My CUIs have correct X- and Y-coordinates for all toolbars. On Windows these coordinates are used to position the toolbars. On linux the coords are disregarded.

Roy Klein Gebbinck

@ Jason:
Your idea is something that you see in quite a few modern file formats. The file may have a unique extension but is in fact a zip-container. Open Office uses this principle. And I believe a .cuix file is also such a file.

Torsten Moses

Dear Roy, Dear Jason,

for #1 - it will not help, to put a Windows .dll file into a container :-)
the problem is, that the resources placed in DLL are WIndows specific - MFC allows code to specify resources by their ID values,
and MFC is able to locate them in .resource section of  .dll file
-> nothing similar on Linux - BricsCAD would (in theory) need to read the .dll file in binary format into memory (which is possible),
     and to extract resources from .resource section "manually" by code, and to create valid GUI objects (bmp, jpg) from the embedded
     data ... tons of work;

for #2 :
aaah, ok, I see :-)
in this case, it is clearly a bug under Linux version then ... as usually, best to provide a small sample CUI,
and to open a support request, should be fixed indeed
(there seems no reason that x/y positions defined in .cui file are ignored under Linux)

Many greetings to all !

Roy Klein Gebbinck

@ Torsten:
I assume that Jason means putting the image files in a zip-container. Since the zip-format is already used By BricsCAD this would seem achievable. Although maybe the focus is already on .cuix compatibility...

Torsten Moses

Dear Roy,

aaah, yes, likely :-)
Then the point would be that BricsCAD Linux (+ Windows) need to use a logic, to check for a parallel
"container" file to load the images from ... currently, there si no such logic yet implemented;
but a good idea indeed !

Many greetings to all !

Roy Klein Gebbinck

BTW: I can't get "subfolder/Icon1.bmp" to work. This type of reference only works if the CUI folder is part of the serarch path.

Torsten Moses

Yes, indeed - the searches with relative pathes "subfolder/Icon1.bmp" are also based on declared support pathes;
meaning, the "parent" of "subfolder" must be in search path list ...
I think, this is as designed ?

But I will propose to also search in from home folder of the CUI itself ... would simplify many thanks :-)

Many greetings !

Jason Bourhill

Hi Torsten & Roy,

Just to clarify BricsCAD doesn't generate an MNR resource file when loading a CUI? This is why Roy is looking for other means to package images up tidily? I wonder whether your DEScoder could be turned to this type of purpose? It can package multiple file types, applies compression to text based, and provides encryption.  I assume Roy only needs for particular cases:

• Images for CUI toolbar. Perhaps if you had an MNL -> DES, which included the images? BricsCAD knows to look there by default.
• Images for LISP. images are included when compiling to DES. Function looks there first
  

i.e. doesn't need a general solution, just a few key cases. Leverage off something that already exists for BricsCAD.

Note compatibility chart says encryption has not been implemented for Linux yet.

regards,

Jason Bourhill

CAD Concepts

Roy Klein Gebbinck

@Jason Bourhill:

Note compatibility chart says encryption has not been implemented for Linux yet.

The compatibility chart should then be updated: encrypted Lisp files can be loaded on Linux.

Roy Klein Gebbinck

... Ah, I guess it is a matter of 'can use but cannot create'.

Torsten Moses

Yes, DEScoder encrypted Lisp files can be loaded - but not generated :-)

Regarding packaging : Jason's suggestions do not help, unfortunately :-(
Because icon usage is at BricsCAD core side, and that part of code does not know about Lisp -
meaning, if Lisp would support to embed icons/bitmaps into DES file, then only Lisp knows about,
nt accessible outside Lisp.

Besides, DEScoder can only embed ASCII resources (txt, dcl), not binary files as bmp/ico.

So in my opinion, the only safe solution is to put all bmp/ico in a dedicated folder - this works always and across platforms
(though there seems to be a bug with ToolPalettes yet - this dies not find images from support pathes, as a client reported;
that needs to be fixed then either).

Many greetings to all !

Roy Klein Gebbinck

An update regarding issue #2:
Yesterday I have received word from Bricsys that this issue has been fixed (SR39309). Very nice!
In the mean time I have stumbled on a way to 'unbunch' the toolbars in the current version without having to close BricsCAD:
1. Close all toolbars that are bunched together.
2. Switch on each toolbar in turn and move it to the desired location.