BGRAbitmap and MSEgui? about bgrabitmap HOT 192 CLOSED

Hmmm I suppose this could be tried.

from bgrabitmap.

Well I feel I am not listened to. What do you think of my initial suggestion: to implicitely add -dMSEgui to projects?

OK, I vote for that.

And what would be wonderful would be to see BGRAbitmap and MSEgui as best friends.

from bgrabitmap.

Yep I am talking about the IDE. I had a look at your IDE but can't seem to change the font of the interface either.

Hello! You can change the font by a command line parameter:

MSEgui command line parameters
******************************
--FONTALIAS=<alias>,<fontname>[,<fontheight>[,<fontwidth>[,<options>[,<xscale>]
                              [,<ancestor>]]]]
 Change the used fonts. Example for a 16 pixel height default font:
 --FONTALIAS=stf_default,,16

from bgrabitmap.

By right-clicking the Exe file and going into compatibility properties.

from bgrabitmap.

I think that without changing the DPI, a height of 16 is ok. I suggest if you do an installation to put that by default.

The spacing between texts is not increased when increasing font size, so 24 is kind of ok but with a bigger size you get the impression that texts are stuck together without spaces.

from bgrabitmap.

Hello, about settings the font name + size in the GUI in Settings, it was done in last commit of ideU:

But, like explained to mse-org, of course it can be done for MSEide too, but for that it is more tricky because MSE dont have a "extra-config" form, not easy to link with actual global option, etc,...

from bgrabitmap.

Hi there

I have started to delve into MSEgui framework. In theory, it is doable to make BGRABitmap compatible with it.

I would like to know if there is a compiler directive to detect that we are compiling for MSEgui.

For example, to detect LCL:
{$IFDEF LCL}

from bgrabitmap.

Indeed. I've added in Project options > Make in the Make option tab the follwing:
-dMSEgui

Now I can customize BGRABitmap. Though such directive could be added implicitely.

from bgrabitmap.

It seems that MSEgui presuppose a little endian processor as the color is accessed by value as a LongWord have its 3 lower bytes for RGB value and also accessed as a record where the first 3 bytes are for RGB values.

As I don't access TColor as a record in BGRABitmap, I will assume that the 3 lower bytes always contains the RGB value.

Note: the equivalent type in MSEgui colorty has red and blue swaped compared to TColor. I will check what I can in BGRABitmap to prevent such swap.

from bgrabitmap.

@circular17
Maybe you will be interested in these examples:
https://gitlab.com/mseide-msegui/mseuniverse/-/tree/master/testcase/graphics

from bgrabitmap.

That would be necessary, unless there is a package system?

No, as far as I know, there is no package system.

I tried to put a {$define msegui} in top of msegui.pas, but it doesn't seem to be visible in my project.

I suggest that you use your own definition, and it will be the responsability of the main program to use the appropriate option. What do you think of that?

Hello.

It was suggested to add a fpc global macro {$IFDEF msegui} few year ago.

The answer was NO, we do it only for LCL.

from bgrabitmap.

Well I feel I am not listened to. What do you think of my initial suggestion: to implicitely add -dMSEgui to projects?

Using an inc file does not seem simpler to me than adding manually -dMSEgui, so that feels like a diversion.

We could put it in default project options, like -Mobjfpc?

from bgrabitmap.

And I maintain that a global FPC macro BGRABitmap in FPC compiler source would not be indecent.

And yes, je re-file dans ma chambre.

from bgrabitmap.

Is there an option somewhere to indicate a project is for fpGUI or for mseGUI?

The most easy is to create a BGRAbitmap template and when the user create a new project, choose that template that is in /template/BGRAbitmap.prj.

from bgrabitmap.

I suppose you intended to say "available" instead of "disposable"?

I intended to say "disponible"

;)

from bgrabitmap.

can we be sure of which file is compiled?

In theory the search order of fpc for units are the first for declared with -Fu command line or if they are in same directory as sources.

from bgrabitmap.

The problem though seems related to the FPImage unit.

Same idea for FPImage. I have just checked. It is nowhere used.

from bgrabitmap.

It would be fantastic!

XXL thanks.

from bgrabitmap.

Hi

As I have a bit of time I have downloaded MSEgui. That's cool, though the fonts are too small I am struggling to see. Is there a way to adjust it?

from bgrabitmap.

What are you talking, about MSEide application or MSEgui widget-set?

If it is about the font used by MSEide and his look, Martin opted for the "hyper-compact" look.
About the font used in the code editor, it is configurable in menu Project-Options-Editor-Font.

For the ide himself, there is also ideU, that is a fork of MSEide but with some more feature and other look:
https://github.com/fredvs/ideU

from bgrabitmap.

Yep I am talking about the IDE. I had a look at your IDE but can't seem to change the font of the interface either.

I suppose I could do with a magnifier for Linux.

Otherwise can I do something without the IDE? Like edit within Lazarus?

from bgrabitmap.

Hi, there's a ready to use installer for Windows?

from bgrabitmap.

MSE does not need installer, MSE is wob (works out of the box).

Just download the last release for Windows:
https://github.com/mse-org/mseide-msegui/releases

Unzip it somewhere.
Then in /mseide_win32/ run mseide.exe.
No more!

If you want to compile application using the msegui widget package, you should download the source.

The source are here:
https://github.com/mse-org/mseide-msegui

Download it somewhere and use that directory in the config menu of MSEide.

from bgrabitmap.

I followed the readme.txt file, installed FPC, downloaded the repository, placed the binary in the same folder. Created a new mainform, saved all.

I tried to compile and I get this:

Free Pascal Compiler version 3.0.4 [2017/10/06] for i386
Copyright (c) 1993-2017 by Florian Klaempfl and others
Fatal: No source file name in command line
Fatal: Compilation aborted

from bgrabitmap.

I followed the readme.txt file, installed FPC, downloaded the repository, placed the binary in the same folder. Created a new mainform, saved all.

I tried to compile and I get this:

Free Pascal Compiler version 3.0.4 [2017/10/06] for i386
Copyright (c) 1993-2017 by Florian Klaempfl and others
Fatal: No source file name in command line
Fatal: Compilation aborted

Can you compile the demo project (in msegui\apps\demo)?

from bgrabitmap.

Created a new mainform, saved all.

Did you create a project before to create the form?

In menu Project-New-From Template-Default.prj

from bgrabitmap.

@rchastain

Maybe we could add some directories in the release.
/syntaxdefs/ and /templates/

Because only the executable and readme.txt is not totally out of the box, people needs to download the source, go inside mseide-msegui/apps/ide to find those directories.

from bgrabitmap.

Can you compile the demo project (in msegui\apps\demo)?

Yes I can compile the app.

Did you create a project before to create the form?

In menu Project-New-From Template-Default.prj

Cool, that is working.

from bgrabitmap.

For Windows you can create an installer, with Inno Setup, if the folder of the application needs to write something, you can install it by default on app data or public documents folder.

The user gets a shortcut in the desktop like with Lazarus.

from bgrabitmap.

Yep I am talking about the IDE. I had a look at your IDE but can't seem to change the font of the interface either.

Hello! You can change the font by a command line parameter:

MSEgui command line parameters
******************************
--FONTALIAS=<alias>,<fontname>[,<fontheight>[,<fontwidth>[,<options>[,<xscale>]
                              [,<ancestor>]]]]
 Change the used fonts. Example for a 16 pixel height default font:
 --FONTALIAS=stf_default,,16

Excellent, I did not know that!
Thanks for the tip.
And maybe good to do this too via the gui config, hum....

from bgrabitmap.

@lainz , yep, welcome.

from bgrabitmap.

@rchastain

Maybe we could add some directories in the release.
/syntaxdefs/ and /templates/

Because only the executable and readme.txt is not totally out of the box, people needs to download the source, go inside mseide-msegui/apps/ide to find those directories.

I cannot answer at once. I have to think about the question. I suggest we start a discussion about that in our forum.

from bgrabitmap.

For Windows you can create an installer, with Inno Setup, if the folder of the application needs to write something, you can install it by default on app data or public documents folder.

The user gets a shortcut in the desktop like with Lazarus.

Yes, good idea. We are currently studying the idea of Windows and Linux installers. A tutorial about installation could be also useful, because nobody reads README files. :)

from bgrabitmap.

Hello! You can change the font by a command line parameter:

MSEgui command line parameters
******************************
--FONTALIAS=<alias>,<fontname>[,<fontheight>[,<fontwidth>[,<options>[,<xscale>]
                              [,<ancestor>]]]]
 Change the used fonts. Example for a 16 pixel height default font:
 --FONTALIAS=stf_default,,16

That works well. I have made a batch file with:

@echo off
start mseide --FONTALIAS=stf_default,,24

and also deactivating DPI scaling and I get the follwing

from bgrabitmap.

@circular17

Nice! I keep your screenshot for a future tutorial. :)

Where do you deactivate DPI scaling?

from bgrabitmap.

I am trying to explore the code now to get insights on how it works. I ctrl-click on tmseform but nothing happens.

from bgrabitmap.

Hi there

I have started to delve into MSEgui framework. In theory, it is doable to make BGRABitmap compatible with it.

Good news!

I would like to know if there is a compiler directive to detect that we are compiling for MSEgui.

For example, to detect LCL:
{$IFDEF LCL}

I have just made a search. No, I didn't find something like that. We could add it.

from bgrabitmap.

That would be necessary, unless there is a package system?

from bgrabitmap.

That would be necessary, unless there is a package system?

No, as far as I know, there is no package system.

I tried to put a {$define msegui} in top of msegui.pas, but it doesn't seem to be visible in my project.

I suggest that you use your own definition, and it will be the responsability of the main program to use the appropriate option. What do you think of that?

from bgrabitmap.

The thing is that the package adds a compiler directive for all files. Otherwise one would need to modify bgrabitmap.inc when using it for MSEgui. That would then require to make a whole copy of BGRABitmap if one want to use MSEgui on one side and LCL on the other.

If I understand correctly, what is needed is that a compiler directive be passed to the compiler. Make this can be done in the MSEgui project?

from bgrabitmap.

If I understand correctly, what is needed is that a compiler directive be passed to the compiler. > > Make this can be done in the MSEgui project?

Yes, this is what I was thinking. Something like BGRABITMAP_USE_MSEGUI?

from bgrabitmap.

Who said NO?

from bgrabitmap.

I dont remember who, I will check (asap) in fpc mailing list.

Please, please, please and re-please, I dont want more problem with fpc team.
If you use, like explained in previous post, -dMSEgui it will do the trick.

from bgrabitmap.

@circular17 : there is a fork of fpc here:
https://github.com/fredvs/freepascal
And all positive propositions, like your ";" can be done.
Same to add global macros.

from bgrabitmap.

That would be necessary, unless there is a package system?

No, as far as I know, there is no package system.
I tried to put a {$define msegui} in top of msegui.pas, but it doesn't seem to be visible in my project.
I suggest that you use your own definition, and it will be the responsability of the main program to use the appropriate option. What do you think of that?

Hello.

It was suggested to add a fpc global macro {$IFDEF msegui} few year ago.

The answer was NO, we do it only for LCL.

I did ask the same for {$IFDEF fpgui}, with same answer.
By the way, I dont really understand why, adding a global macro in fpc source is the most easy thing that exist and dont break any compatibility.

But re-please let it flow.

from bgrabitmap.

Hmmm I am surprised you would like such global define to be included in FPC.

It can be added in MSEide or ideU.

from bgrabitmap.

I was thinking that if they do it for LCL, why not for fpGUI and MSEgui too?
Anyway, like you explained, it can be done with -dmsegui, it is less "out-of-the-box" but it works perfectly.

from bgrabitmap.

Oh I see. Well I don't see the point either to add an LCL define in FPC. Maybe I am missing something. But it doesn't matter.

Relax, take a deep breath in.

So let me rephrase what I was saying as it seems there was a misunderstanding. This -dMSEgui could be added implicitely by ideU. So that you can use some code that is not specific to MSEgui but that can adapt to it.

from bgrabitmap.

For example in uos project:
https://github.com/fredvs/uos/

Because MSEgui gives some very efficient way to deal with thread, there is in define.inc some definitions you may enable/disable.

Like this one:

{.$DEFINE mse} // uncomment when using a mse project, use mse mseThread in place of fpc TThread.

You may choose to compile using MSE thread or fpc thread.

from bgrabitmap.

Sorry I don't see how it is related?

from bgrabitmap.

Huh, maybe I go too fast.
;)
I was thinking that if you are in mood to do BGRAbitmap compatible with MSEgui, we may use also a define.inc and use it in msegui source.

from bgrabitmap.

Anyway, using "-dbgrabitmap" adding it to "Make Option" in MSEide or IdeU is the most simple.

Yes, I am obsessed by OOTB feature and what could be the most easy for end-users.

from bgrabitmap.

Well I was also thinking about OOTB. As a user of mseGUI or ideU, it would be convenient just to add the path to BGRABitmap and add it to the uses clause.

I just don't see how it is related to threads.

from bgrabitmap.

Oh I see. Well I don't see the point either to add an LCL define in FPC. Maybe I am missing something. But it doesn't matter.

If I create a FPC unit, I may use the global variable

{$ifdef LCL} // the unit will be use LCL widgetset
dosomething
{$endif}

But this will work, only if you manually add -dfpGUI at compilation

 {$ifdef fpGUI} // the unit will be use fpGUI widget set
 dosomething
 {$endif}

from bgrabitmap.

I just don't see how it is related to threads.

Mama mia, it was only a example to show that using a define.inc can solve the problem.

But yes I agree, maybe it could be more complicated at the end.

[EDIT] Huh, I re-read my post, I agree it was more propaganda, I have to take care of that.
;)

from bgrabitmap.

Well I feel I am not listened to. What do you think of my initial suggestion: to implicitely add -dMSEgui to projects?

Using an inc file does not seem simpler to me than adding manually -dMSEgui, so that feels like a diversion.

from bgrabitmap.

Well I feel I am not listened to. What do you think of my initial suggestion: to implicitely add -dMSEgui to projects?

Using an inc file does not seem simpler to me than adding manually -dMSEgui, so that feels like a diversion.

Indeed, I didn't really pay attention, at the beginning of the discussion, to your suggestion of adding implicitely the definition to MSEide project.
I am not sure to see what you mean. How would you do that?
Anyway the most important is that we agree on the usage of a definition.

from bgrabitmap.

Do you think of something like an environment variable?

from bgrabitmap.

Well I don't see the point either to add an LCL define in FPC.

Yes, exactly, why add LCL as global macro in FPC for unique widget?
IMHO, or nobody or all that has contributed for a while for FPC.

OK, ok, ok, je file dans ma chambre.

Fre;D

from bgrabitmap.

We could do something like this:

program mseide;
{$define MSEgui}

But I wonder if it would be a good idea, because MSEide can be used to develop a project that doesn't use MSEgui, for example a fpGUI project.

from bgrabitmap.

We could do something like this:

program mseide;
{$define MSEgui}

But I wonder if it would be a good idea, because MSEide can be used to develop a project that doesn't use MSEgui, for example a fpGUI project.

I would adore!

Sadly it will not work because MSEgui is not declared as global macro in FPC compiler source.

from bgrabitmap.

It will work only if you add {$define MSEgui} in each unit, as global it will work only if you add -dMSEgui

from bgrabitmap.

to implicitely add -dMSEgui to projects??

Sorry, I am lost, I was talking about adding -dBGRA in a project that uses MSEgui.
Maybe I am completely wrong, you are talking about adding -dMSEgui to what kind of project?

[EDIT] Oooops, ok, we are in the BGRAbimap side here, yes, understood.

from bgrabitmap.

to implicitely add -dMSEgui to projects??

Sorry, I am lost, I was talking about adding -dBGRA in a project that uses MSEgui.
Maybe I am completely wrong, you are talking about adding -dMSEgui to what kind of project?

To a MSEide project using MSEgui and BGRABitmap. :)

from bgrabitmap.

To a MSEide project using MSEgui and BGRABitmap. :)

Ha, then, it is about adding -dBGRAbitmap in a MSEide project (because MSEide project knows when MSEgui is used, no need to define it).

from bgrabitmap.

@rchastain : I fear that we are thinking from MSEgui side and Circular from BGRABitmap side.

Anyway, the problem is similar.

from bgrabitmap.

But I wonder if it would be a good idea, because MSEide can be used to develop a project that doesn't use MSEgui, for example a fpGUI project.

MSEide can deal with any kind of project, even LCL.
There is a utility to translate LCL lpi project into prj project.
There is not yet a LCL designer disposable but for compile-debug-run it works perfectly.

from bgrabitmap.

To a MSEide project using MSEgui and BGRABitmap. :)

Ha, then, it is about adding -dBGRAbitmap in a MSEide project (because MSEide project knows when MSEgui is used, no need to define it).

No that's not it.

We could put it in default project options, like -Mobjfpc?

Yes, for example.

But I wonder if it would be a good idea, because MSEide can be used to develop a project that doesn't use MSEgui, for example a fpGUI project.

Is there an option somewhere to indicate a project is for fpGUI or for mseGUI?

from bgrabitmap.

There is not yet a LCL designer disposable but for compile-debug-run it works perfectly.

I suppose you intended to say "available" instead of "disposable"?

from bgrabitmap.

Ok I am progressing a bit. I encounter errors that I don't undersand:

fpreadxwd.pas(54,17) Error: There is no method in an ancestor class to be overridden: "InternalRead(TStream;TFPCustomImage);"
unibitmap.inc(169,15) Error: There is no method in an ancestor class to be overridden: "Assign(TPersistent);"

from bgrabitmap.

What compiler version are you using?

from bgrabitmap.

It is used by TFPCustomImageReader from fpc.

from bgrabitmap.

I have FPC 3.0.4.

I don't get those errors when compiling from Lazarus with the same FPC version.

What's surprising is that those functions are defined as virtual so I don't understand how I could get this error.

from bgrabitmap.

Those functions are defined in fpc/packages/fcl-image/src/fpimage.pp

Hum, do you have problems when compiling MSE bitmap demos?
Or a little test program?

from bgrabitmap.

Yes as soon as I add fpreadxwd to the uses clause it won't compile anymore.

from bgrabitmap.

Yes as soon as I add fpreadxwd to the uses clause it won't compile anymore.

OK, I will see what appends.
See you later.

from bgrabitmap.

Aaargh.

Yes, indeed:

Compiling /home/fred/mseide-msegui/lib/common/fpccompatibility/fpreadxwd.pas
fpreadxwd.pas(54,17) Error: There is no method in an ancestor class to be overridden: "InternalRead(TStream;TFPCustomImage);"
fpreadxwd.pas(55,17) Error: There is no method in an ancestor class to be overridden: "InternalCheck(TStream):Boolean;"
fpreadxwd.pas(61,1) Fatal: There were 2 errors compiling module, stopping
Fatal: Compilation aborted

Mama mia.
OK, one new battle, I hope not too hard this time.
See you later (hope not too later).

from bgrabitmap.

Ok good luck my friend

from bgrabitmap.

Re-aaargh.

I just recompiled using the official last release of Martin from
https://gitlab.com/mseide-msegui/mseide-msegui

and get the same error:

OK, I will jump into it tonight.
See you much later, I fear.

Fre;D

from bgrabitmap.

There's no rush as always

from bgrabitmap.

If it does not stop in your development...

;)

from bgrabitmap.

Maybe a stupid idea, but why not do this?

// msegui/lib/common/fpccompatibility//fpreadxwd.pas
      procedure InternalRead  (Stream:TStream; Img:TFPCustomImage);// override;
      function  InternalCheck (Stream:TStream) : boolean;// override;

from bgrabitmap.

Hello.

Roland.

I just come with the same idea.

// required by TFPCustomImageReader
      procedure InternalRead  (Stream:TStream; Img:TFPCustomImage); 
      function  InternalCheck (Stream:TStream) : boolean; 

Tested and it compiles perfectly.

from bgrabitmap.

It compile perfectly adding:

uses
fpreadxwd, ...

But not tested, I dont have any idea what fpreadxwd is.

from bgrabitmap.

Another idea. There is a fpimage.pas in FPC, and another one in MSEgui. Isn't it a problem? How can we be sure of which file is compiled?
I wonder why Martin didn't change the name of the modified files.

from bgrabitmap.

But not tested, I dont have any idea what fpreadxwd is.

The same for me.

from bgrabitmap.

If I trust my search program, fpreadxwd unit is used nowhere, neither in MSEgui, nor in any MSEgui-based project that I have on my disk. Maybe this is why the error wasn't visible until now.

@circular17
How did you come to the idea of using that unit?

from bgrabitmap.

If I trust my search program, fpreadxwd unit is used nowhere, neither in MSEgui, nor in any MSEgui-based project that I have on my disk.
Maybe this is why the error wasn't visible until now.

Yep, well seen, very strange indeed.

from bgrabitmap.

That said, I dont really understand the reason of override; in preadxwd.pas.

Override what?

from bgrabitmap.

nor in any MSEgui-based project that I have on my disk.

Did you try also for MSE-universe project?
[EDIT] No, tested here, nothing found for preadxwd

from bgrabitmap.

I wonder why Martin didn't change the name of the modified files.

Maybe Martin did not change anything but provide those files for convenience.

from bgrabitmap.

FPReadXWD is a unit to load images in the XWD format. And BGRABitmap being a library for images makes use of it.

The override keyword is necessary because image readers derive from a common class, and once instantiated the virtual functions are used. For example you can supply a reader for any format to a LoadFromStream function.

from bgrabitmap.

FPReadXWD is a unit to load images in the XWD format. And BGRABitmap being a library for images makes use of it.

Thank you for the explanation. So, another idea (but you probably have already thought of it) would be to delete the MSEgui unit and use the one from FPC.

@fredvs
If ever that solves the problem, we could rename fpreadxwd.pas to fpreadxwd.txt (for example).

from bgrabitmap.

The problem though seems related to the FPImage unit.

from bgrabitmap.

If ever that solves the problem, we could rename fpreadxwd.pas to fpreadxwd.txt (for example).

I fear that the 2 files are indentical (or I did not see the difference).

from bgrabitmap.

Or maybe, I dont know, Martin did try with FPImage and then created his own image handler.
MSEgui can deal with jpg, bmp, gif, png.

I have to confess that I did not jump deep in mse image code.
I use MSEimage widget and it works out of the bloc.

from bgrabitmap.

Well you can try what Roland suggests: remove completely FPImage package from MSEgui and see if it still compiles.

from bgrabitmap.

OK, I will try this.

from bgrabitmap.

Oups, I made another search and now I see that FPImage is used in many places. There must be something wrong with my tool. Sorry.
But we still can try to use the unit from FPC.

from bgrabitmap.

Yes fpreadxwd is not used but FPImage is everywhere.

But maybe delete all the fp***.pas that are in /fpccompatibility ?

from bgrabitmap.