Re: [lazarus] Introduction
On Tuesday 29 January 2008 10.59:57 Michael Van Canneyt wrote: > > ... but it is i386 only. No 64-bit, meaning it is unusable for me, since > I work on 64-bit only... > > All projects have their advantages and disadvantages... > I have no need for 64 bit so I didn't port it to 64 bit up to now. What did you gain from switch to 64 bit? Can't you run 32 bit applications on your Systems? Martin _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Tuesday 29 January 2008 10.45:47 A.J. Venter wrote: > > MSEide+MSEgui is designed with the goal to provide identical look and > > feel on Linux and win32: > > http://sourceforge.net/projects/mseide-msegui/ > > > > Another main focus of MSEide+MSEgui are database components. > > Does it support lazarus components however ? I wouldn't even THINK of > using it if I couldn't use the custom components I developed for lazarus > - the ones included in lazarus now as well as the ones I just use myself. > No, MSEgui is a fresh approach of GUI toolkit design which does not aim to be VCL compatible. Martin _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Tuesday 29 January 2008 04.13:31 Alexsander Rosa wrote: > The OPF is ported to Lazarus (with IFDEF's). We removed most of the > 3rd-party components, the only remaining are Colrcal (TMonthCalendar does > not work under Wine), AlignEdit (a simple TEdit with Alignment property) > and Rave Reports. We still plan to migrate to a binary-native solution and > Lazarus is a top candidate -- however, the current LCL approach of using > multiple widget sets may bring us back the same visual differences. > MSEide+MSEgui is designed with the goal to provide identical look and feel on Linux and win32: http://sourceforge.net/projects/mseide-msegui/ Another main focus of MSEide+MSEgui are database components. Martin _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Saturday 19 January 2008 19.39:32 Damien Gerard wrote: > > Sorry for my ignorance, but I really don't see the interest of fpGui. > Under Windows, I prefer Win32 due to it is the native gui. Under Linux > GTK2 make all the work I need. QT may be too I don't really know I > have not enough tested it. Under OS X I would prefer Cocoa but Carbon > is fine too(additionally this widgetset begins to be really usable). > > Projects work on these 3 platform without any defines, and they are > quite complex. And the current LCL solves those issues too. > So what fpGUI brings to me ? > With the Lazarus approach to use OS-native or external widgets it is difficult to achieve consistent behaviour over all platforms. To write your own widget base library in pascal is more work at the beginning but much easier to achieve high quality and productive cross platform development once the kernel is written. A big plus is the ability to add needed base functionality for the higher levels into the kernel, it allows a maximum of flexibility and platform independence. The architecture of MSEgui: There is a twindow object which represents the top level window of the operating system. twindow holds the handle to the OS window object. The top level widget (for example a tmseform) is responsible for creating and destroying the twindow object. Every widget holds a reference to the assigned twindow of the top level widget. That is twidget.window of a child widget maps to twindow of the top level twidget. twindow has a canvas which is used for painting all widgets of the form. The canvas is a parameter of the paint method: " twidget = class(tactcomponent,iscrollframe,iface) [...] procedure paint(const canvas: tcanvas); virtual; " The paint canvas works on a server side pixmap with the size of the update area in order to implement platform independent double buffering. The pixmap is copied to the screen after the widgets of the window are painted. If the update area is small, the pixmap is small too which results in good performace. twidget.font is normally a nil pointer which means that the widget uses the font of the parent widget or a default font if there is no parent. In object inspector of MSEide or in code you can create a local tfont instance if needed. The same principle applies for twidget.frame, twidget.face and other not always used class properties, they are a nil pointer only if the widget doesn't need them. Because of this and the fact that there is only one window handle per form, there is no need for a stripped-down "TGraphicControl". Every MSEgui twidget has all possibilities, every twidget can serve as top level window-widget. MSEgui is completely Unicode based, all text strings are widestrings. MSEgui has a Unicode capable tpostscriptprinter and an own report generator and designer, the MSEgui database components convert from/to utf8 or the system encoding while reading/writing from/to the database, text fields are stored as widestrings in the dataset . Worth to mention is tmsebufdataset with "TClientDataset"-like functionality. Another innovative component is twidgetgrid. Every inserted edit widget builds a data colum in the grid. All properties and events of the column widgets are working, the result is a very flexible and powerful compound widget. tdbwidgetgrid is the DB-aware version of the twidgetgrid. MSEide+MSEgui is at version 1.6 and used in production. Invested development time about 14'000 hours up to now. MSEide is GPL, MSEgui modified LGPL like the FPC-RTL. For questions and bug reports please use NNTP: news://news.grid-sky.com/public.mseide-msegui.talk Martin _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Introduction
On Friday 18 January 2008 21.53:27 Graeme Geldenhuys wrote: > On 18/01/2008, Jon Foster <[EMAIL PROTECTED]> wrote: > > On the other hand I have yet to be able to accomplish any serious > > project with it. I've run into a series of issues with just about every > > component I've tried to use. > > I had the same experience. Good news is that you have a few choices. > 1. Start cranking out LCL patches to fix the issues. ;-) 2. Ditch > the LCL, but continue using Lazarus with a different GUI toolkit. > I've had great success with option 2. > 3. MSEide+MSEgui ;-) http://sourceforge.net/projects/mseide-msegui/ Martin _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making GTK Thread Safe
On Sunday 30 December 2007 07.39:25 Micha Nelissen wrote: > Martin Schreiber wrote: > > You are right, there seems to be no race condition if one uses > > WakeMainThread correct. There can be a deadlock if the main thread tries > > to destroy a thread which is waiting for Synchronize. > > Hmm I think this is a very stupid idea to do. The thread will continue > to execute something so I don't think this is supported. Like destroying > a component in an event handler. > TThread.Destroy calls Waitfor. What is the supported method to terminate an application which has threads waiting for Synchronize? Martin _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] DBGrid - what do you use?
On Sunday 16 December 2007 10.14, Lukas Gradl wrote: > I know TDBGrid on Data Controls Tab. > As you can read in my posting, I'm looking for an enhanced version, an > alternative, and not for the standard-TDBGrid... > tdbwidgetgrid from MSEide+MSEgui, an enhanced alternative but not Lazarus compatible: http://sourceforge.net/projects/mseide-msegui/ The mode of operation of t*widgetgrid: Every edit or DB edit widget (tstringedit, tintegeredit, trealedit, lookup edits..., tdataicon, tdataimage, tdatabutton...) which is placed in the data area builds a data column. The grid positions the widgets in the active row. All properties and events of the edit widgets are accessible and working. Any widget can be placed into cells of the fixed rows, this is useful in order to switch sorting order, to edit filter values or to show sums. There can be fixed rows above and/or below the data area and there can be fixed columns left and/or right of the data area, adjacent fixed row cells can be merged. Martin _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making GTK Thread Safe
On Thursday 13 December 2007 18.16, Micha Nelissen wrote: > Martin Schreiber wrote: > > Fourthly there is FPC synchronize with the problem that checksynchronize > > is called once in onidle of then main event loop. One can call > > application.wakeupguithread to enable processing but there is a race > > condition. > > AFAICS, these are all variants on the TThread.Synchronize "hack". There > is no race condition in TThread.Synchronize, so why not use this then? > You are right, there seems to be no race condition if one uses WakeMainThread correct. There can be a deadlock if the main thread tries to destroy a thread which is waiting for Synchronize. Martin _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making GTK Thread Safe
On Friday 14 December 2007 11.43, Al Boldi wrote: > > TFrame, visual form > > inheritance and datamodules with cross form/datamodule design time > > component linking are implemented for example, > > Wow, I didn't get that far. I had to disable db-support, because I > compiled the MSEide with FPC2.0.2. MSEide+MSEgui 1.6 needs FPC 2.2. > BTW, why isn't there a makefile or lpr > file to compile the MSEide directly with FPC/laz without the MSEide bin? > In MSEide+MSEgui source directory: ppc386 apps/ide/mseide.pas -Fulib/common/* -B -Fulib/common/kernel/i386-linux -Fi/lib/common/kernel (Linux) or ppc386.exe apps\ide\mseide.pas -Fulib\common\* -B -Fulib\common\kernel\i386-win32 -Fi\lib\common\kernel (win32) There are scripts in SVN trunk to do a checkout and compiling MSEide, "updatefromsvn" on Linux and "udatefromsvn.bat" for win32. You can get them with viewvc: http://mseide-msegui.svn.sourceforge.net/viewvc/mseide-msegui/trunk/ The script files are at the bottom of the list. > > Lazarus can not be used to design MSEgui forms. > > That's sad. MSEgui looks rather professional, but forcing a developer to > change the ide is rather drastic. > > > There is a NNTP newsgroup for questions about MSEide+MSEgui: > > news://news.grid-sky.com/public.mseide-msegui.talk > > Is there web gateway for this? > No, use a news client, Mozilla Thunderbird for win32/Linux or KNode for Linux for example. You will probably like the conversation by NNTP, much more convenient than mailing lists or web forums IMHO. Martin _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making GTK Thread Safe
On Friday 14 December 2007 10.52, Al Boldi wrote: > Martin Schreiber wrote: > > Don't forget MSEide+MSEgui: > > http://sourceforge.net/projects/mseide-msegui > > MSEgui has several possibilities to synchronize worker threads with the > > main GUI thread. > > Sounds interesting. Is it possible to use MSEgui via the laz-ide? > MSEgui has its own sophisticated IDE (MSEide). TFrame, visual form inheritance and datamodules with cross form/datamodule design time component linking are implemented for example, the integrated debug facilities of MSEide are better than the Lazarus ones IMO. Lazarus can not be used to design MSEgui forms. There is a NNTP newsgroup for questions about MSEide+MSEgui: news://news.grid-sky.com/public.mseide-msegui.talk Martin _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Making GTK Thread Safe
On Thursday 13 December 2007 01.28, Giuliano Colla wrote: [...] > The screen is a shared resource, so it must be granted exclusive > access. If one thinks of one main thread which besides doing its job > receives messages from all the worker threads, creates a clean queue of > what needs to be done (sorting out what's visible and what not, what > must be drawn and what not, etc.), and passes that to a graphic thread > which is the only one which has access to the display, then you have a > real multithread GUI, which could fill a void in what's currently > available. It could be a challenging project, don't you think? > It just requires a not too large GUI system already existing (such as > fpGui, not Lazarus which is too big to play with) and some enthusiasm > (and also a lot of time, but for my company it could be important, so > some resources could be found). > Don't forget MSEide+MSEgui: http://sourceforge.net/projects/mseide-msegui MSEgui has several possibilities to synchronize worker threads with the main GUI thread. First there is application.lock/unlok which works on a mutex. The main eventloop acquires the mutex on start of a new round of the main eventloop and releases it after it gets idle. Secondly there is application.synchronize which runs a callback in a try/finally block with application.lock/unlock. Thirdly there is application.postevent in order to send messages to MSEgui components. The posted events are feed into the main event queue and are delivered to the component in context of the main thread. application.postevent is thread safe and does not block. tmsecomponent.postcomponentevent and asyncevent can be used for convenience, tmseform tmsedatamodule have onevent and onasyncevent where the messages can be handled in context of the main thread. Fourthly there is FPC synchronize with the problem that checksynchronize is called once in onidle of then main event loop. One can call application.wakeupguithread to enable processing but there is a race condition. Worth to mention is teventthread with its own message queue. The graphic subsystem has its own locking mechanism so it is possible to draw onto off screen canvas (pixmap or printer) from worker threads. Martin _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Really bad bug in IDE.
On Monday 12 November 2007 09.44, Michael Van Canneyt wrote: > > Did you upgrade xlib/Xorg? There are some new "sanity checks" in xcb > > which break many applications. In MSEgui I had a problem with XFlushGC, > > it was necessary to remove the XFlushGC call because it triggered an > > assertion error. > > As far as I know, I have the latest X which comes with SuSE 10.3. > Me too. :-) Flamerobin crashes, Postgres admin tool crashes, FlightGear crashes... Martin _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] Really bad bug in IDE.
On Sunday 11 November 2007 11.43, Michael Van Canneyt wrote: > Hi, > > Quite the showstopper: The action editor no longer works in the Lazarus IDE > :/ > > Steps to reproduce: > > - Create new application > - Drop action list on form > - Edit action list > - Click 'Add action' button. > > lazarus.pp - unhandled exception > [TMainIDE.Destroy] A > Gdk-ERROR **: BadCursor (invalid Cursor parameter) > serial 175337 error_code 6 request_code 2 minor_code 0 > lazarus: xcb_xlib.c:42: xcb_xlib_lock: Assertion `!c->xlib.lock' failed. Did you upgrade xlib/Xorg? There are some new "sanity checks" in xcb which break many applications. In MSEgui I had a problem with XFlushGC, it was necessary to remove the XFlushGC call because it triggered an assertion error. Martin _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] App Localization
On Saturday 22 September 2007 03.59, Luis Rodrigues wrote: > Hi, > > Is there any good translation tool? > > When i say good I mean that it finds all the strings on my project (in > code and forms) and creates a list for me to translate. > > If there is only resourcestring i'm willing to make a better tool, any > info on how to do this? > You could look into MSEi18n, the internationalization tool of MSEide+MSEgui. http://sourceforge.net/projects/mseide-msegui located in tools/i18n. It works with string constants, resource strings and *.mfm files (the MSEgui equivalent of *.lfm files) and creates resource dll's which can be loaded by the application dynamically. Most published properties of the components can be modified language specific. MSEi18n can export/import to spreadsheet programs for translation by non IT people. Eventually it could be adapted for Lazarus? Martin _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] detecting the Linux window manager used
On Saturday 21 April 2007 11.38, Graeme Geldenhuys wrote: > Hi, > > Anybody know how to detect what Window Manager is being used under > Linux so I can try and query information about the current theme?. > For example, I have Ubuntu 7.04 installed and am running Mozilla > Firefox. I change the Gnome's theme window text color to blue. > Mozilla Firefox doesn't change, but if I restart Mozilla Firefox, it > uses the blue color for it's fonts (same goes for Window background > colors). Not sure what it does under KDE. > > In Windows it is easy to find the System Window background color or > System Window Text color via Win32 API's (well for Win9x and Win2000), > but how do you do something like this under Linux with Gnome or KDE? > Miha has done it for MSEgui and KDE (QT): http://wiki.freepascal.org/index.php/User:Miha Martin _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] listview example cannot be loaded in the IDE on win64
On Monday 16 April 2007 22.24, Vincent Snijders wrote: > If events are not executed when componentstate is csDesigning, then we > don't have this problem. > > But the LCL does raise events when component state is csDesigning, and > then this problem occurs. If we were to guard each OnXXX(Self) call with > CanEvent, then we don't need to change anything in the IDE. > While designing in MSEide 1.2 the "code" field of published event properties is nil, the "data" field is used to hold an index number into an event list where the info about the events in the project is stored. The event list is filled while loading the forms and modified due to user settings in the object inspector." assigned" returns false for all published event properties while designing because "code" is nil. In order to let TWriter write the events while streaming "code" and "data" fields of the published event properties must be swapped and an artificial methodtable must be added to the form. While streaming in designmode the streamed component must not fire published events because "code" does not point to real code. Is there any component which fires such events? TDataset for example doesn't AFAIK. It is problematic to fire published event properties while streaming anyway because the loading state of the form is undefined while reading. Martin _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] listview example cannot be loaded in the IDE on win64
On Monday 16 April 2007 19.17, Mattias Gaertner wrote: > On Mon, 16 Apr 2007 14:56:01 +0200 > > > > Does this mean during streaming Assigned(OnClick) is true? > > > > Yes. > > But then you need "if [csReading,csWriting]*ComponentState=[] then ", > don't you? > For events which are triggered while streaming only. I use "if not (csdesigning in componentstate) then". The MSEgui events are all protected by tmsecomponent.canevent anyway: " function tmsecomponent.canevent(const event: tmethod): boolean; begin result:= (event.code <> nil) and (event.data <> nil) and (componentstate * [csloading,csdesigning,csdestroying] = []); end; " Martin _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] listview example cannot be loaded in the IDE on win64
On Monday 16 April 2007 10.32, Mattias Gaertner wrote: > > It is no more necessary in MSEide version 1.2. In 1.0 I used "code" > > to hold the method lookup number. In 1.2 "code" and "data" are > > swapped before/after streaming. > > Does this mean during streaming Assigned(OnClick) is true? > Yes. BTW: Feel free to use any code from MSEide+MSEgui for Lazarus if you find it useful, I am happy to help the Lazarus team. Martin _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] listview example cannot be loaded in the IDE on win64
Mattias Gaertner wrote: > Of course this trick works only for methods, not procedures. > > There are two alternatives: > 1. set all events to nil and extend TReader and friends to use some > highly sophisticated method lookup. > 2. Do it like msegui and add a > not (csdesigning in componentstate) > to every method check in every component. (not Delphi compatible) It is no more necessary in MSEide version 1.2. In 1.0 I used "code" to hold the method lookup number. In 1.2 "code" and "data" are swapped before/after streaming. Martin _ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
