[lazarus] Maybe.... gtk2

[matooo at email.si]

Quoting Mattias Gaertner <nc-gaertnma at netcologne.de>:

> On Sat, 14 Dec 2002 00:10:34 +0100
> Florian Klaempfl <Florian.Klaempfl at gmx.de> wrote:
> 
> > Mattias Gaertner wrote:
> > >>>>Also I just finished fam implementation and basic object.
> Component
> > >>>
> > >>>will
> > >>>
> > >>>>be finished today. If that one is planned for lazarus I can upload
> it
> > >>>>somewhere otherwise it will appear on my server after I find a
> time to
> > >>>
> > >>>set
> > >>>
> > >>>>him up again
> > >>>
> > >>>Normally, visual components go into lazarus and non visual
> components
> > >>>go
> > >>>into fpc.
> > >>>
> > >>
> > >>ok, if fpc branch needs it, I have it :-)
> > > 
> > > 
> > > I hope the fpc-team reads this thread.
> > 
> > I read it but I don't know exactly what I should do :) Besides this I
> 
> > don't know what fam is :) In case it should go into the fcl, contact 
> > Michael (michael at freepascal.org).
> 
> I guess his fam is file access monitoring. I think, this is a very
> useful
> feature. Probably it is not OS independent, but I hope it can be
> extended
> like TProcess.
> 

yes it is.
it's not os independent but windows have shell functions that do same job.

as far as gtk2.
tonight I'll be correcting the last file gtkcallbacks.inc and I hope it will
workout OK. that's only the first part of three

Work process I've choosen
/lcl/interfaces/gtk has three new small .inc files and gtk version is choosen
simly with {$define GTK2} and all differences are made in
{$ifdef GTK2}
{$else}
{$endif GTK2}

this way /lcl/interfaces/gtk is able to be compiled with gtk1 or gtk2

as I said I have taken three steps
{GTK2} just making possible to compile with GTK2 and try to make use of gtk2
lazarus to compile gtk2 software

{DISABLE_DEPPRECIATED} this one will be tricky because many of the functions
(and they aren't only a few of them) that are still supported but deppreciated
in 2.x will vanish in 3.x, so this step currently not really urgently needed (I
will acomplish this job after the time will allow me)

{OPTIMIZATIONS} as you said some new functions allow us to get rid of some parts
of implementation with calling them directly, but this part will be the last and
probably never ended as I doubt that any of us will be able to take him self so
much time to apply them all at once

I'm worried about one part that will probably need some help from the one who
implemented it originaly (accelgroups are something I never used so I don't know
much about them), three function for accelerators that had some major changes,
so when first part will end help in this three funcs would be appreciated.




One more thing or two for fpc part of the group. I needed interfaces for many
times 'till now. Especialy for my non-visual components that are controlling
different types of components some of them are already implemented by fpc and
some are mine, but they don't share other same ancestor than TComponent so
passing them as a parameter to some function is a real pain (typeis, typeis,
typeis).
1.1 should have interfaces, when is D-Day???
if D-Day is not sometimes soon, I would like to propose a little (stupid one,
but it would ease the job) solution (if there maybe exists something like that I
would be really glad if you'd let me know). because function is originaly empty
I don't think it would harm anything or anybody

// this way all components have some blank and usable common point, 
// it remains only one part a little function that assigns registred 
// messages so they don't duplicate and can be applied and registred 
// from everywhere, but all of the registration can be applied in some 
// completely different unit so nothing would interfer with current 
// state of lcl or fcl
function TComponent.CommonInterfaceMsg(Sender: TComponent; Msg: longInt; Data:
pointer): longInt;
begin
end;

// some completely different unit
function RegisterMsg(Msg: string): longInt;
function GetMsgID(aMsg: string): longInt;

Something like that would really shorten my sources (pros and contras are
appreciated).

m.

> 
> Mattias


-------------------
http://www.email.si