fpGUI v0.7-rc1 is available
---------------------------

An archived source download can be found at the following URL, or the source code could be pulled directly from the source code repository.

http://sourceforge.net/projects/fpgui/files/

For more details, please visit the fpGUI home page:

http://opensoft.homeip.net/fpgui/

The v0.7 release contains a lot of added features compared to the previous release. Below is just a small list of things that changed or was added. A more detailed change-log will be made available when I create the final v0.7 release. The final release will also include updated Class Documentation (in HTML and INF format) and application help for DocView and UI Designer. The FPC Language Reference document will also be made available in INF format.

Some changes in v0.7-rc1
-------------------------
* FPC 2.4.0 compatible.
* Fully tested on 32-bit and 64-bit platforms. Tested on Linux, Windows and the *BSD family.
* Mobile device support is back. Tested on ARM Linux and Windows Mobile devices.
* fpGUI UI Designer has improved a lot and extended it's component palette and Object Inspector.
* Various bug fixes, memory leaks and other enhancements have been applied.
* Units have a more uniform naming style.
* Classes have a more uniform structure/hierarchy with base classes.
* Help support has been added to the core framework
* fpGUI now has it's own help file viewer called DocView. Docview includes the following features:
- document annotation
- bookmarks
- browse history
- exporting articles to plain text or IPF format.
- full text search (including weighting of results to see how relevant the results are)
- Font and Color customization
- Concatenation of help files at run-time so a library of help files can be viewed simultaneously.
- Easy integration via the "external tools" feature of IDE's like Lazarus or MSEide. This allows for context sensitive help.
- History of most recently viewed help files.
- Help file format used is the INF format (IBM's format used it OS/2), which is very compact, incredibly fast and supports full text search.
* A lot of new components have been added, including enhancements to existing components.
* Various new dialogs have been added, which include Color Wheel, Character Map, Database Login etc.
* Improved integration with tiOPF project via the Model-GUI-Mediator design pattern.
* Graphical FPCUnit unit test runner.
* Lots of new language translations for the core fpGUI library.
* A lot of new example projects demoing various GUI components.

Regards,
- Graeme -

Graeme,

Amazing update, can't wait to get time to have my hands on this!

whats the status of its integration with directfb ?

im working on a INIT replacement for linux (based on xml files) and i was thinking about a DirectFB/fpGUI user shell (Something quite simple and light, for use on routers and other kind of network stuff where X is overkill)

2010/3/9 Joseph Montanez :

see this : http://www.calmira.net/

thats my goal (coincidentally, calmira was made using delphi...)

Jorge Aldo G. de F. Junior het geskryf:

whats the status of its integration with directfb ?

Two new backends are planned (AggPas and DirectFb), but none are started yet. There is currently no timeframe set yet.

Regards,
- Graeme -

Nice work, Graeme. I've been waiting sooo... long for 0.7 to come. I'll try rebuilding Lazarus with this version, hope it doesn't break anything :)

leledumbo wrote

Nice work, Graeme. I've been waiting sooo... long for 0.7 to come. I'll try rebuilding Lazarus with this version, hope it doesn't break anything :)

Sorry to disappoint you, but the fpGUI v0.7-rc1 release has nothing to do with the Lazarus lcl-fpgui widgetset. They are totally separate projects. And as recently stated in the Lazarus mailing list, I will not be working on the lcl-fpgui
Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Sorry to disappoint you, but the fpGUI v0.7-rc1 release has nothing to do with the Lazarus lcl-fpgui widgetset. They are totally separate projects. And as recently stated in the Lazarus mailing list, I will not be working on the lcl-fpgui know, but as long as there's no BIG API changes in fpgui, the current

lcl-fpgui implementation should still work, right?

leledumbo het geskryf:

I know, but as long as there's no BIG API changes in fpgui, the current lcl-fpgui implementation should still work, right?

The lcl-fpgui has never worked. The current lcl-fpgui implementation is far from complete. Last time I checked, only about 5 basic components could be dropped on a form and displayed, but much of the implementation still needs to be done before it is near usable.

If you want to use fpGUI today, then use fpGUI directly, without the LCL. That is the only way you will get the full benefit of fpGUI.

The fpGUI release also includes an add-on package that registers a new project type with Lazarus IDE (File > New... > fpGUI app). You can also integrate the fpGUI DocView (INF help viewer) and fpGUI UI Designer (visual forms designer) with Lazarus IDE, via the "external tools" menu option. This allows you to press Shift+F1 and get context sensitive help (FCL, RTL, LCL and Language Reference) without the need for internet access. You can also edit a unit and press Ctrl+Shift+F12 and load the UI Designer with the current unit you were editing. When you return to Lazarus IDE, the ide will prompt to reload the file (if it changed). We [our company] have been using Lazarus IDE like this for the last 4 years with great success.

The same integration can be done with MSEide as well. If you want I can add a web page describing in detail how to setup the IDE integration with Lazarus IDE and MSEide. I think I should do this in any event before the final v0.7 release.

Regards,
- Graeme -

Last time I checked, only about 5 basic components could be dropped on a

form and displayed

That's what I mean by "still work" actually :p

If you want I can add a web page describing in detail how to setup the IDE integration with Lazarus IDE and MSEide.

Please do, that would help fpgui new comers.

found some code to work with framebuffer on linux (/dev/fb)

but im stuck at changing video modes and etc... its not as easy as i thought (you cant just say "i want 800x600")

and pixel manipulating is similar to the old DOS/Vesa1.2 ways...

im checking your code for the low level core routines, if you are interested i found code about linuxfb here :
http://bugs.freepascal.org/view.php?id=12288

(im not the author)

if you manage to make fpGUI usable for framebuffer devices you will win a nice niche (Small console applications or even hand held like devices where X server is overkill)

i want to enhace my current programs (they use text menus, with readln and similar ugly things) without having to resort to XOrg (its hard to place a xserver on a routerboard).

i will keep investigating...

Jorge Aldo G. de F. Junior wrote

if you manage to make fpGUI usable for framebuffer devices you will win a nice niche (Small console applications or even hand held like devices where X server is overkill)

This would be very nice, indeed.

You may want to look at directfb instead of working with the framebuffer directly.

Henry

Well, that is the plan for fpGUI. I have some use cases for fpGUI on linux framebuffer too.

You may want to look at directfb instead of working with the framebuffer directly.

That is actually what I was going to far as I
understand DirectFB is bit higher level than /dev/fb directly, so should make implementation a bit easier.

It's not only on a much higher level, but it also provides hardware-acceleration where drivers are available. On low-end embedded devices this can be crucial for acceptable performance. As for the level, I'd say using DFB is sort of on a par with using Xlib, only easier to handle. Besides the init procedures it acatually feels more like using SDL, but with richer functionality. You even get native support for windowing, multi-application support, etc. It's definitely much more comfortable than /dev/fb!

I'm maintaining FPC-bindings for DFB. Right now, they work with the 1.4 line of DFB binaries only. If anyone has a need for 1.2 bindings (which is the version that ships with most GNU/Linux distributions these days), I'd actually provide such bindings. So, if anyone is seriously interested, please come forward.

Cheers
Roland

Roland Schaefer het geskryf:

level, I'd say using DFB is sort of on a par with using Xlib, only easier to handle. Besides the init procedures it acatually feels more

This is what I understood about directfb too [the little that I read about directfb].

I'm maintaining FPC-bindings for DFB. Right now, they work with the 1.4 line of DFB binaries only. If anyone has a need for 1.2 bindings (which

Umm, I'm running Ubuntu 8.04.2 LTS (long term support) release and it comes with libdirectfb 1.0.1. I'll be upgrading to the next LTS release due end of April - hopefully that will include a more up to date version of directfb, otherwise I'll be in contact with you. ;-)

Regards,
- Graeme -

Graeme Geldenhuys wrote

fpGUI v0.7-rc1 is available ---------------------------

Hi, this is the first time I nice work !

I tried to cross compile some examples for WinCE and it worked so far - looks like my search is over and I found a nice little GUI framework for that platform. I was not satisfied with LCL (much too big), KOL (too weird) and I even thought of switching to c++ and QT, but QT apps take ages to load on a phone.

One thing I found is, that when a fpGUI application is running on my WinCE phone (even when it is in the background), the phone will slow down dramatically. I guess there is an event loop which is too busy - any idea ?

cheers, Adrian.

Graeme Geldenhuys wrote

fpGUI v0.7-rc1 is available

when compiling uidesigner with actual fpc from svn it fails with duplicate identifier "unitname" in vfdfile.pas. It seems to be a name clash with the new class procedure unitname in TObject. I don't know why fpc raises an error - is there a rule, that a local identifier cannot have the same name as a class procedure ? (makes no real sense, because a class procedure can be accessed via a full qualified name). Anyway if you change "unitname" in NewFileSkeleton to "aunitname" it compiles.

Adrian.

Adrian Veith het geskryf:

WinCE is experimental, so expect some issue. But that is no excuse. ;-) I can duplicate the slow down on my Garmin iQue M5, so will try and resolve the issue before the final v0.7 release. Thanks for bringing this to my attention.

Regards,
- Graeme -

Adrian Veith wrote

when compiling uidesigner with actual fpc from svn it fails with duplicate identifier "unitname" in vfdfile.pas. It seems to be a name clash with the new class procedure unitname in TObject.

http://wiki.freepascal.org/User_Changes_Trunk#TObject_class_declaration

It makes sense because that way you can accidentally hide an identifier, which can result in all sorts of hard to debug behaviour. It's one of the core differences between objfpc and Delphi mode.

Jonas

Adrian Veith het geskryf:

when compiling uidesigner with actual fpc from svn it fails with duplicate identifier "unitname" in vfdfile.pas. It seems to be a name clash with the new class procedure unitname in TObject. I don't know why

As rule of thumb, I never test with unstable FPC (trunk) because things change to often and nothing is cast in stone. I only test with latest release and latest "fixes" revision. eg: FPC 2.4.1

Either way, I'll update my FPC tomorrow and take a look. It should be no problem renaming the property in UI Designer, as it is a stand-alone application and the issue is not in the actual fpGUI library code.

Regards,
- Graeme -

If it makes sense or not - I get the same error in delphi mode.

Adrian.

Adrian Veith wrote

If it makes sense or not - I get the same error in delphi mode.

my error - forget it

Adrian

Hi Adrian,

I'm also using fpGUI for WinCE (and Linux) and I'm excited to see fpGUI continue moving forward.

You probably don't need it but I would like to point out for the benefit of others reading this message thread that I have posted a minimal FreePasacal and fpGUI distribution for cross-compiling WinCE applications near the bottom of this page:
http://www.turbocontrol.com/helloworld.htm

"I'm maintaining FPC-bindings for DFB. Right now, they work with the 1.4 line of DFB binaries only. If anyone has a need for 1.2 bindings (which is the version that ships with most GNU/Linux distributions these days), I'd actually provide such bindings. So, if anyone is seriously interested, please come forward."

Where can i find those bindings ?

And Graeme, where should i look for (Units/Classes) to port fpGUI to directfb ?

Im feeling motivated to do the work...

Jorge Aldo G. de F. Junior het geskryf:

And Graeme, where should i look for (Units/Classes) to port fpGUI to directfb ?

It's relatively simple.

* You'll create a new folder for the new backend code. eg: src/corelib/directfb/

* You'll create a new fpg_interface.pas unit. See gdi or x11 directories. These are just alias types to prevent IFDEF's in fpg_main.pas unit.

* You will have to implement all abstract methods/classes found in fpg_base.pas in a new unit called for example fpg_directfb.pas. Again, see the GDI (fpg_gdi.pas) or X11 (fpg_x11.pas) directories for examples.

* Lastly, you'll need to create a fpgui_toolkit.lpk package for use with Lazarus IDE - though this step is not required, as fpGUI can be used by other IDE's as well. The command line build scripts would need to be edited as well. The scripts are located in the 'src' directory (build.sh or build.bat)

Im feeling motivated to do the work...

I really appreciate that. If you have any more questions, please post them in the fpGUI newsgroup. Patches can be posted there as well.

http://opensoft.homeip.net/fpgui/#Newsgroups

Regards,
- Graeme -

Ok - I got another issue with reading and painting bitmaps. The original code throws an error when reading a bitmap file in ReadImage_BMP for 32 bit depths images.

I change the code in the loop:

    while (p) < (pdata) do
    begin
      //pcol^ := Plongword(p)^; -- changed
      pcol^ := (LongWord(p[3]) shl 24) + (LongWord(p[2]) shl 16) +
(LongWord(p[1]) shl 8) + LongWord(p[0]);
      //Writeln('color: ',HexStr(pcol^,8));
      Inc(pcol);
      //Inc(Plongword(p)); -- changed
      inc(p, 4);
      Inc(pixelcnt);
    end;

this reads the bitmap so far, but there is still a problem with painting bitmaps in WinCE. It seems, that memory layout is different or something like that, because the bitmaps look scrambled and have different colors. I haven't found the solution for this yet.

BTW. is there another place to discuss fpGUI related problems ?

cheers,

Adrian.

Adrian Veith wrote

//pcol^ := Plongword(p)^; -- changed pcol^ := (LongWord(p[3]) shl 24) + (LongWord(p[2]) shl 16) + (LongWord(p[1]) shl 8) + LongWord(p[0]);

This looks like an endian issue. Aren't Bitmaps in Little Endian format (as per the usual endianess of the Intel x86 processor) and ARM can be either in big or little endian? This could explain the scrambling of this image too. Are there any routines in the RTL that could be used to get round this?

M

Adrian Veith wrote

..the bitmaps look scrambled and have different colors. I haven't found the solution for this yet.

Ignore that last message. It seems WinCE is only ever little endian. So it is probably more to do with DIB vs general device dependent Bitmaps. Have you tried converting the bitmap in question to a DIB?

M

I am so far that I found that the procedure SetDIBits is not supported on WinCE (that's why it is commented out in the WinCE build). So the Bitmap is not initialized with the data loaded from the file and shows random crap.

I have to find way how to initialize the bitmap without SetDIBits (and in a efficient way).

Adrian.

A freshly baked tar ball is here:

http://sourceforge.net/projects/wiseslap/files/external/directfb/fpc-directfb-1.4.tar.gz/download

You need DFB 1.4, which is usually not available in most distros (as I said, I'm going to provide 1.2 compatibility if there is serious interest in it (current Ubuntu has 1.2.7)). However, we have a link to a Zenwalk 6.2 VMWare machine which has DFB 1.4 in our wiki. That machine is due for a major overhaul. It has quirks (don't update Cairo under any circumstances!), but can be used to play around with DFB at once:

https://sourceforge.net/apps/trac/wiseslap/wiki

There is no demo app included in the bindings, so please use: http://www.directfb.org/docs/DirectFB_Reference_1_4/index.html

And there are some 1.2 demo apps in C found here:
http://www.directfb.org/index.php?path=Main%2FDownloads&page=1

They should mostly be translatable 1:1 to Pascal. Notice that on unprepared desktop distros you need to run your app with root privileges. The DFB wiki explains about that, and what you can do to avoid that (wiki server seems to be down again at the moment):

http://www.directfb.org/wiki/

Cheers
Roland

My solution for the moment is:

{$IFDEF wince}
procedure WinCESetInitBMP(BMP: HBITMAP; awidth, aheight, depth: Integer;
aimgdata: Pointer);
var
  hdcSrc, hdcDest: HDC;
  hbmSrc: HBITMAP;
  bm: BITMAP;
  data, p, pend: pByte;
begin
  hdcSrc:= CreateCompatibleDC(0);
  hdcDest:= CreateCompatibleDC(0);
  hbmSrc:= CreateBitmap(awidth, aheight, 1, depth, nil);
  if depth = 32 then
    SetBitmapBits(hbmSrc, (awidth * aheight) *4, aimgdata)
  else
    SetBitmapBits(hbmSrc, (awidth * aheight) div 8, aimgdata);
  SelectObject(hdcSrc, hbmSrc);
  SelectObject(hdcDest, BMP);
  BitBlt(hdcDest, 0, 0, awidth, aheight, hdcSrc, 0, 0, SRCCOPY);
  DeleteDC(hdcSrc);
  DeleteDC(hdcDest);
  DeleteObject(hbmSrc);
end;
{$ENDIF}

and change the code in TfpgGDIImage.DoInitImage to

  {$IFNDEF wince}
  SetDIBits(wapplication.display, FBMPHandle, 0, aheight, aimgdata, bi,
DIB_RGB_COLORS);
  {$else}
  WinCESetInitBMP(FBMPHandle, awidth, aheight, bi.bmiHeader.biBitCount,
aimgdata);
  {$ENDIF}

and in TfpgGDIImage.DoInitImageMask to:

  {$IFNDEF wince}
  SetDIBits(wapplication.display, FMaskHandle, 0, aheight, aimgdata,
pbi^, DIB_RGB_COLORS);
  {$ELSE}
  WinCESetInitBMP(FMaskHandle, awidth, aheight, bi.bmiHeader.biBitCount,
aimgdata);
  {$ENDIF}

now bitmaps are loaded an painted correctly, but still the stdimg.xxx (e.g. stdimg.close) are not painted correctly
- I guess there is a problem with the masking.

Adrian.

Now my second solution works:

{$IFDEF wince}
procedure WinCESetDibBits(BMP: HBITMAP; awidth, aheight: Integer;
aimgdata: Pointer; var bi: TBitmapInfo);
var
  hdcSrc, hdcDest: HDC;
  hbmSrc: HBITMAP;
  bm: BITMAP;
begin
  hdcDest:= CreateCompatibleDC(0);
  SelectObject(hdcDest, BMP);
  if bi.bmiHeader.biBitCount = 1 then begin
    SetDIBitsToDevice(hdcDest, 0, 0, awidth, aheight, 0, 0, 0, aheight,
aimgdata, bi, DIB_RGB_COLORS);
  end else begin
    hdcSrc:= CreateCompatibleDC(0);
    hbmSrc:= CreateBitmap(awidth, aheight, 1, bi.bmiHeader.biBitCount,
aimgdata);
    SelectObject(hdcSrc, hbmSrc);
    BitBlt(hdcDest, 0, 0, awidth, aheight, hdcSrc, 0, 0, SRCCOPY);
    DeleteDC(hdcSrc);
    DeleteObject(hbmSrc);
  end;
  DeleteDC(hdcDest);
end;
{$ENDIF}

and the change for TfpgGDIImage.DoInitImage:

  {$IFNDEF wince}
  SetDIBits(wapplication.display, FBMPHandle, 0, aheight, aimgdata, bi,
DIB_RGB_COLORS);
  {$else}
  WinCESetDibBits(FBMPHandle, awidth, aheight, aimgdata, bi);
  {$ENDIF}

and for TfpgGDIImage.DoInitImageMask

  {$IFNDEF wince}
  SetDIBits(wapplication.display, FMaskHandle, 0, aheight, aimgdata,
pbi^, DIB_RGB_COLORS);
  {$ELSE}
  WinCESetDibBits(FMaskHandle, awidth, aheight, aimgdata, pbi^);
  {$ENDIF}

with the patch for loading 32bit bitmaps posted before you can call fpgCreateStandardImages; in fpg_main:

  {--$IFNDEF wince}
  fpgCreateStandardImages;
  (*  causes EBusError on Symbol MC1000 WinCE 4.2
  see: http://wiki.freepascal.org/Windows_CE_Development_Notes
  "Using ARM processors, some times you may get a EBusError exception with
  a message about misaligned data access.  The following section explains
  what this is and how to fix it." - fixed
  *)
  {--$ENDIF}

cheers Adrian.

Adrian Veith wrote

Ok - I got another issue with reading and painting bitmaps. The original code throws an error when reading a bitmap file in ReadImage_BMP for 32 bit depths images.

A known problem. I suspect a endian issue. I am currently working on changing the existing BMP read unit with the units included in FPImage (part of FCL). This will improve BMP image loading and support other file formats too. The existing BMP unit in fpGUI is a bit limited and only reads 24bit R8 G8 B8 images.

BTW. is there another place to discuss fpGUI related problems ?

Yes, please direct future conversations regarding fpGUI to the fpGUI newsgroups. There is a web interface for the newsgroups too, if you don't have a news client available.

http://opensoft.homeip.net/fpgui/#Newsgroups

Adrian Veith wrote

>> Now my second solution works:

Thank you very much. I'll take a look at the code and test on my Garmin in the next day or two.

Adrian,

Thank you *very* much for getting fpGUI working better on WinCE. A few months ago I spent quite a bit of time doing the initial work but as you've seen in the comments I only had a Motorola Symbol MC1000 barcode scanner to work with and that just has a 240x240 monochrome display.

I hope to get a better WinCE system like this to use with fpGUI: http://www.cubloc.com/product/06_02.php

I've been using fpGUI on this 7" Linux touchscreen: http://www.embeddedarm.com/products/board-detail.php?product=TS-TPC-7390

If fpGUI gets DirectFB support that should help on the low-powered Linux systems.

When I did all my work a few months ago I hoped someone else would come along to take it further so I am *very* pleased to see your messages today. It appears it is going to get even easier to show how FreePascal and fpGUI provide simple entry to embedded GUI systems. :)

Hi

has there been already been work on a carbon backend of fpGUI?

Michael

The best place to ask about this is on the fpgui newsgroups, which are hosted by opensoft.homeip.net

Discussions took place in the fpgui.support group in 2008 (June and December) and you can probably still access those messages from the news server.

To summarize what was said there:
- carbon was started but abandoned in favor of cocoa
- cocoa was reported as "mostly working" but "very incomplete" in 2008, however there hasn't been any mention of it since

~David.

Schindler Karl-Michael het geskryf:

has there been already been work on a carbon backend of fpGUI?

Felipe started a Carbon backend for the old v0.4 fpgGUI (years ago), but there was hardy any real code, just basic class declarations. Then Apple reported that Carbon will not be 64-bit. Carbon support was then discontinued and work on Cocoa bindings for FPC was started instead.

I don't know Mac's at all, so I have no idea how far FPC bindings support to any Mac API (Carbon or Cocoa) is progressed.

I do know fpGUI with the X11 backend does run under Mac OS X with the X11 support. Obviously it doesn't look anything like a Mac OS program, but at least the programs run. :)

Regards,
- Graeme -

David Emerson het geskryf:

Discussions took place in the fpgui.support group in 2008 (June and December) and you can probably still access those messages from the news server.

Correct. Messages in the newsgroup never expire so everything is accessible. I am also working on a Forum gateway to the NNTP server so web based searching can be done. This already runs correctly on my system, I just need to make the forum public as some point in time.

Regards,
- Graeme -

Paul,

yes I agree with you, that fpGUI is very nice for embedded GUI systems - and I think it has potential for more. The next thing I will look at, is why it draws a frame around labels etc. in WinCE - do you have the same issue ? Should be a minor problem.

Adrian.

yes please, and if it works please fix the code on git. I will also look at the issue with frames around labels etc

I have read, that you mentioned to think about AggPas as a target for fpGUI. For me it would be very interesting to combine both (I fixed already the code of AggPas to compile for ARM, but there is a problem, that the demo applications don't start - I guess its a missing system call).

I would like to have a small widget set (pure pascal, so that it can be easy ported to all the platforms fpc can target) with very mighty drawing capabilities, which can be styled like HTML and CSS.

For example: why do we need widgets like Panel and Button and Bitmap Button (if I look at my Delphi installation, which is still my main developing environment - I have about 50 different Button widgets and about 20 Panels). In fact all are rectangular areas which are drawn with different styles and borders, some are transparent, some contain images, some are for toolbars, some can contain styled text. If I look at HTML you have a <div> with different styles and depending if you have events attached to it or not, it behaves like a button or a panel. That kind of simplicity and flexibility is what I want - separate code from layout and design, but with mighty design possibilities.

That's why I has very straight forward design and is easy to change and runs on all platforms. If we bring the amazing drawing capabilities of AggPas to fpGUI and have a (to be written) style engine a la CSS - et voila we could have a little gemstone, which is far beyond existing frameworks - ok. I am dreaming now ;-).

Adrian.

Hi,

yes please, and if it works please fix the code on git. I will also > look at the issue with frames around labels etc >

Good news, the fixes seem to work well on my Garmin. I fixed some memory leaks and drawing improvements for the "examples/corelib/helloworld/" demo too. I'll commit the code tomorrow - I ran out of time today.

@Paul
Thanks again for your FPC+fpGUI starter compiler setup - it makes testing WinCE so much easier! :-)

> I have read, that you mentioned to think about AggPas as a target for > fpGUI. For me it would be very interesting to combine both (I fixed >

Yes, AggPas has some amazing graphics features. I hope the fpGUI+AggPas integration works well, then maybe I can replace all painting in all backends to rather use AggPas, and let each backend simply handle windowing and system events. This will greatly reduce the effort to support even more backends/platforms.

> ks - ok. I am dreaming now ;-) . >

That's how every programming project starts. :-)

Graeme,

Thanks for the feedback. I'll try to update that distribution in the next couple of days with the latest code.

For the benefit of others reading this message thread I would like to mention that I have posted a minimal FreePascal and fpGUI distribution for cross-compiling WinCE applications near the bottom of this page: http://www.turbocontrol.com/helloworld.htm
That is the starter compiler setup that Graeme is referring to.

As has been suggested a couple times already, it's probably a good idea to continue this discussion on the fpGUI newsgroup/forum (http://opensoft.homeip.net/fpgui/#Newsgroups ).

Thanks,

Jonas
FPC mailing lists admin

Yes, sure. But there are 3 other minimal FreePascal distributions on that page that are just FreePascal and have nothing to do with fpGUI. :)

thank you all, im working on understanding directfb first, so i have nothing to show about fbGUI (i was looking at fpg gdi and fpg x11 and it looked quite alien to me... i think i will need more help).

now i am going to join the fpgui mailgroup.

thank you all.

Jorge Aldo G. de F. Junior wrote

now i am going to join the fpgui mailgroup.

The opensoft.homeip.net server is down until Tuesday morning 08:00 (GMT+2). We have builders working at our office over the weekend so for safety, had to shutdown all power.

Sorry for the inconvenience.

Hi

I tried a bit more using colorlistbox. But what would be as simple as possible X11 examples? working with gdb is quite tedious.

Michael

nothing in it. A lot still happens in the background, and that is where the Mac+X11 problems are.

If you wanted a Object Pascal example of talking directly to Xlib to create a GUI X11 application, I can do that. I have a few test apps like 'll post one on Monday when I am back in the
office.

It's pretty hard trying to implement a platform I don't have hardware or software for. I'll try and see if it is possible to install Mac OS in a VirtualBox session - not sure if this is possible. I'll Google for more information. Is one allowed to buy Mac OS-X without actually owning a Mac? Will the iStore or general computer shop actually ask for proof of Mac hardware?

2010/4/11 Graeme Geldenhuys :

for the virtualization, the problem is the absence of the drivers for most of the pc hardware.... unless you happen to have a pc with the very few types of devices used in macs.
You don't need to proof anything to buy it, but consider that:
- it is expressly forbidden by the license to install on a non-Apple assembled hardware
- you can't buy a cheap upgrade, but you need a full os install 10.5 + the snow leopard upgrade (i.e. i think there is no full 10.6 on the market)
- you can easily find used mac mini's, if the 500€ new one are out of budget

R.

Roberto Padovani wrote

for the virtualization, the problem is the absence of the drivers for most of the pc hardware.... unless you happen to have a pc with the very few types of devices used in macs.

Well, virtualization software like VirtualBox "fakes" it's own hardware - I'm hoping the faked hardware is similar to a real Mac. My real PC is Intel based (Quad Core), graphics card is a average ATI or Nvidia card. I believe real Mac's use similar hardware.

You don't need to proof anything to buy it, but consider that:

Good.

- it is expressly forbidden by the license to install on a non-Apple assembled hardware

I do not care about such rubbish license restrictions, and I don't believe such a license is valid in my country either (South Africa).

- you can easily find used mac mini's, if the 500€ new one are out of budget

This might also be a good path to follow. Thanks for pointing it out.

The MacOS 10.6 you can buy is a full installation DVD. As far as I know Apple has no distinction on full / upgrade at least on the newer OS versions.

Have a look at -> http://prasys.co.cc/tag/empire-efi/ -> they claim that it is legal in some circumstances, but you have to decide self.
This is about installation on a intel hardware that is near to a mac.

It is also possible to install OSX on a VMWare (at least), there are images, and walkthroughs
existing on the net - i don't think that it iss legal, maybe depending on your country law ...

helmut

2010/4/11 Graeme Geldenhuys :

I didn't intend to be a moralist, I was just pointing it out. With this very same purpouse, I'll point out another one. Even though I own a Mac, so I was only moved by curiosity, I also thought that such a restriction might not be valid in my country (Italy).
However, after researching a while, I made up the idea that there are no specific national limits about these kinds of agreements in the license and that only international anti-trust and trade regulations apply. I'm no lawyer, but for what I read those regulations forbid a hardware manufacturer to force you to use only his software (i.e. you are allowed to install win XP on the mac you have bought), but not the contrary (i.e. I give you my software but it is only for XYZ hardware).

R.

Can this discussion please be taken off-list?

Thanks,

Jonas
FPC mailing list admin