"Baeseman, Cliff" el d�a Tue, 18 May 1999
18:01:04 -0500, escribi�:

Cliff, in open source proyects centralizing things is a bad idea... Suppose that I want to add a component, why I must modify other code that is running smoothly.
Suppose that I want to develop a commercial component, the user must modify their source code ?
Suppose now that we have thousands of components, every time I create one, the code must flow an overloaded case struct ? If there is a problem in one component, just look at that component, not anything else.
I don't need syncronization with others developers when I'm creating components.

In a ideal situation of Open Source all must be a plug-in, this is what Gimp creators have done (because the authors couldn't mantain all the code) and why Gimp is so wonderfull.

Of course talking about plug-ins in this stage is useless, but, please, let's descentralize.

Two different approaches which is correct. The one we have specified here makes it easier to build compound objects based from many different widgets such as in the TMemo implementation without including units.

with my aproach we can do exactly the same without any problem, suppose that I want to do a OpenDialog that consist in a gtk_window and a gtk_file_selection inside, then you declare two components and map the calls to the corresponding one.
Even the gtk allow this, from what I understand you can even put a gtk_window inside a gtk_button

Ok sounds like a good plan of attack to me.

Cliff

Sergio A. Kessler wrote

Cliff, in open source proyects centralizing things is a bad idea...

I have to agree with Sergio on this one. At least as far as the future goes. To use Delphi as an example, I have created a host of new and useful components and controls but have never had to edit any of the Delphi VCL to do it. We want the same functionality in the FCL. That is one reason why I am working on moving the gtk OUT of the lower class structures. This allows users to not only create new components and controls without touching the basic FCL but it allows them to use a totally different GUI API to do so. Maybe QT has a built in widget that they want to create a FCL control of. It would mean compiling with the GUIAPI.pp designed for QT and create and new class without the need to edit any of the lower classes in the FCL.

Now we go back to the discussion of "Is it time to worry about this yet". I say no. It is something we want to keep in mind and plan on going back and doing but right now we need a working IDE. Once we have A BETTER environment to work in then I say we stop go back and smooth out all the rough edges in our hasty design and build of the IDE.

Just to show you what I am working on as far as moving the gtk callback out of the classes. This is how it will work, I'll use DoShow as an example.

You create a message procedure in your class.

procedure DoShow(var something, Self : TCustomForm);message 'show';

Then you write the procedure:

procedure DoShow(var something, Self : TCustomForm);
begin
   if Assigned(FOnShow) then FOnShow(Self);
end;

In the create for the class you write:

constructor TCustomForm.Create(AOwner : TComponent); begin
.
. Everything else you do need in create
.
.

{Then you do this for the callback attachment}

   GUIAPI_Set_Callback('show', Self);
end;

You will only need the procedure with message 'signal', the procedure itself and the GUIAPI call. This will allow you to use any GUIAPI to deal with the actual callback. It removes gtk dependence.

The only snag I have in this whole thing is that the DispatchStr method in TObject doesn't seem to be working correctly and I am just waiting and hoping one of the FPC gods/gurus/omnipotent beings can figure out what the problem is. :-)

Hey, what the heck is this ?

Procedure TControl.CreateComponent(AOwner : TComponent);
...
case fCompStyle of
csAlignment: Begin
		fComponent := gtk_alignment_new(0.5,0.5,0,0);
		gtk_widget_show(fComponent);
       	     end;
csButton: begin
   fComponent := gtk_button_new_with_label('Button');
   gtk_object_set_data(GTK_OBJECT (fComponent), PChar(Name), fComponent);
   end;
...

this should be managed by the components themselves, if not every time we add a widget, we need to modify this thingy.
And every time we create a widget, the code should traverse this code, slowing downs things without need.

it shouldn't be:

constructor TCustomForm.Create(AOwner : TComponent);
begin
inherited Create(AOwner);
+  fComponent := gtk_window_new( GTK_WINDOW_DIALOG);
+  // set the window policies
+  gtk_window_set_policy (GTK_WINDOW (fComponent), 1, 1, 0);
+  gtk_window_set_title(pGtkWindow(fComponent),'Caption');
  If AOwner = nil then
     fCompStyle := csMainForm
     else
     fCompStyle := csForm;
   Top := 1;
   Left := 1;
   Width := 120;
   Height := 120;
     	  Writeln('CreateComponent being called for TFORM');
	  CreateComponent(AOwner);
 { Assign  Signals }
   AssignOnDestroy;
   AssignOnShow;
   AssignOnFocus;
   AssignOnResize;
end;

the same with Destroy

TipNote: try to use // comments in one line comments, sometimes I want to comment a block and I found nested comments in the hard way :)

Sergio

�
Sergio....
�� So what you are asking about is the later of the two options I was speaking of.� A standard class implementation up to the TCustomObject level and then we each develop our components at this level and below. We would need some type of common class structure to implement the objects to keep the components on the same base at least for gtk as for qt the same would have to be done but qt would only have to be implemented at tcustom and below....
Just trying to understand your position ;)
Cliff

These are both good points. It's tough to get motivated to fix shoddy design when there's "new" stuff to program. It's also tough (for me, at least) to be real creative with the environment currently available on linux - even though I love rhide.

I have a suggestion. Since you're using gtk and the win32 dll's are available why not do this initial development under win32? FPIDE is pretty nice and I've even been using Delphi as an editor for fpc code generation. The end result should compile on either platform anyway (I'm able to compile and run lazarus on win32).

mz.

Then we'll have a broking environment and nobody will go back. It's the same case with gtk 1.0 ot gtk 1.2
Linus always said that half solutions always found a way to stay for a loooong time, if you will gonna to do it, do it rigth.

Is my solution rigth ? I don't know, but I think is better than the current one (to be honest the current one is just a hack, IMO)

Even it could be a _lot_ better to use gtk_widget_new along with gtk_widget_type, but again, I think that you cannot remove the gtk from the low level classes, but I have to see.

Maybe Michael H. can move the signals (I hope), but signal is just a little part of the gtk.

Sergio

A

I think you are using a bad distribution or that you don't find the editor that fit you.
I'm using gEdit of Gnome, and can do all the things that I can in an editor for win (Ctrl-C, Ctrl-V, etc)

I have a suggestion. Since you're using gtk and the win32 dll's are available why not do this initial development under win32? FPIDE is

pretty

nice and I've even been using Delphi as an editor for fpc code generation. The end result should compile on either platform anyway (I'm able to compile and run lazarus on win32).

use the tool that you like :)

Well we have two options for the create component thing. One is to use the construct that we are using and
the other is to pass the widget assignment up to fcomponent from the implementation level such as in TCustomMemo.Create. The one we are using allows us to add the widgets in one central location vs many units.

Two different approaches which is correct. The one we have specified here makes it easier to build compound objects based from many different widgets such as in the TMemo implementation without including units.

????

Cliff

Sergio tell me if you like it?

Cliff

(Nicolas Aragon) el d�a Thu, 20 May 1999 23:05:37 GMT, escribi�:

Hello, >For those of you yearning for a nice IDE under Linux, have a look a

CoolEdit

>(http://www.netins.net/showcase/Comput-IT/cooledit/). It has a bunch of Is it free?

yep, I found it in a redhat mirror contrib dir. (the .rpm)

btw, Alex Roberts has updated the pages http://gedit.pn.org and there is a new 0.5.2 .rpm

Sergio

Sergio A. Kessler wrote

btw, Alex Roberts (the author of gEdit) told me he will make a new rpm (exclusively for lazarus :)

I'd be very interested in seeing that.

Yep, free, distributed under the GPL. I wouldn't have suggested it otherwise !

Cheers

"Baeseman, Cliff" el d�a Thu, 20 May 1999
14:54:33 -0500, escribi�:

Sergio tell me if you like it?

I will tell you, but I'm in the work now
(updating cvs and downloading things)
btw, Alex Roberts (the author of gEdit) told me he will make a new rpm (exclusively for lazarus :)

For those of you yearning for a nice IDE under Linux, have a look a CoolEdit (http://www.netins.net/showcase/Comput-IT/cooledit/). It has a bunch of really nice features like built in scripting (so you can get it to compile your pascal programs directly, with command output to a scrolling text box), configurable automatic syntax highlighting (a pascal definition comes with it), multiple document interface paradigm, etc etc etc.

The author wrote his own widget set for it and it's a bit ugly, but it works very nicely.

Cheers
Michael A

Michael Anthon el d�a Thu, 20 May 1999 12:24:07 +1000, escribi�:

For those of you yearning for a nice IDE under Linux, have a look a

CoolEdit

(http://www.netins.net/showcase/Comput-IT/cooledit/). It has a bunch of

downloading rigth now :)

Sergio

Hello,

For those of you yearning for a nice IDE under Linux, have a look a CoolEdit (http://www.netins.net/showcase/Comput-IT/cooledit/). It has a bunch of

Is it free?

I use fte, not bad.

I can think of a better alternative: Delphi. Wine's page contains some reports on Delphi 4. I haven't been able to execute it... not even Notepad, only Win16 apps, but it surely depends on the version used.

greetings

Nico

RPM for lazarus?

Confused %)

Cliff