p.s. Could you maybe add password mode in TEdit it involves only calling

It's done for a long time already ... See TEdit.EchoMode.

Michal

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 ().

[...] Wouldn't it be simpler to retain names. Probably just some of my strange thoughts. Almoust any gcc software that respects changes can be compiled with--enable-gtk20?

FYI: For applications you just set the widget type from gtk to gtk2. And the gtk2-interface is always compiled via the IDE or the Makefiles. So, we don't need to make the hidden compilation very comfortable.

Wouldn't it be easyer to take same logic and have gtk1 or gtk2 compile destination, (qt, win, gtk, gtk2). Overloading objects would demand overloaded and corrected components, while retaining would demand only to respect old definitions with adding or correcting new ones.

What do you mean with "Overloading objects would demand overloaded and corrected components"? Can you give an example?

Many differences will simply be made with compiler directives. But some gtk2 features allows to replace whole functions. And these functions can be overloaded.

I hope the fpc-team reads this thread.

Mattias

Last question on this topic! Otherwise everything is crystal clear.

Quoting Mattias Gaertner :

Wouldn't it be simpler to retain names. Probably just some of my strange thoughts. Almoust any gcc software that respects changes can be compiled with --enable-gtk20?

Wouldn't it be easyer to take same logic and have gtk1 or gtk2 compile destination, (qt, win, gtk, gtk2). Overloading objects would demand overloaded and corrected components, while retaining would demand only to respect old definitions with adding or correcting new ones.

I probably missed there as much as possible.

ok, if fpc branch needs it, I have it :-)

by the way, is CVS server down?
Logging in to
CVS password:
cvs [server aborted]: can't chdir(/home/cvs): No such file or directory

m.

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

Howdy

I just be curious.. is there a particular reason for using gtk for window management and not glut in
Lazarus?

Thanks!
-Rob

__________________________________________________ Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

Quoting Michal Bukovjan :

Not even 15 minutes after sending this question, I was trying grids demo and saw that one. thanX anyway

But gtk2 question is still valid (and maybe stupid :-$ ). When I use glade2 and gcc (but,... to keep using them is not what I wish) to make some simple gtk software, I have no trouble with slo chars. gtk2 solved that nicely. Slo chars in gtk1 were never really solved. And I suspect many other share the same problem with their special country characters.
Question has occured when I saw gtk2 headers for pascal somewhere on the net. (at least if I remember correctly)

m.

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

overload

TGtk2Object = class(TGtkObject)

Sorry, it was gnome.org:

http://developer.gnome.org/doc/API/2.0/gtk/gtk-changes-2-0.html

Normally, visual components go into lazarus and non visual components go into fpc.

Mattias

... as I said earlyer I was absent for almost a year and wasn't really following lazarus, I just couldn't allow my self the time to test anything (I think everyone know how testing while working ends).

Is there maybe a chance to compile it with gtk2? (explanation: gtk1 has many flaws in international usage aka. special regional characters, while gtk2 eliminates this problems by using system wide solutions built in controls)

Hope it's wasn't too stupid.

p.s. Could you maybe add password mode in TEdit
it involves only calling

gtk_entry_set_visibility(GTK_ENTRY(someedit), TRUE or FALSE)

so that shouldn't be a problem if I think correctly, I used that on my app and it worked fine, except it would be nicer to have password: boolean property than that, especially looking at portability of app.

m.

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

first off window management usually refers to the handling of windows etc.. aka nothing to do with lazarus..

second GTK+ is a native widget toolkit, whereas glut is not. so for instance gtk+ apps blend nicely within a GTK+ or GNOME desktop, glut apps would not.

third lazarus is not intended to be any toolkit specific, so if anyone wants to make a glut based interface.. they could go right ahead!

fourth programming wise I would say that the bulk of the lcl can be implemented a lot easier with gtk+ then glut, so it is easiest to get the lcl and lazarus working using gtk+ as a base, and then as it becomes more stable(as it has begun too already) add more interfaces such as QT, win32, GNOME, KDE, XForms, etc..

Andrew

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.

Mattias

Yes, the machine running the cvs has been upgraded. It's back now...

The gtk2 interface has not yet been started. The idea is, to inherit from the gtk1 interface and just overload any procedure that needs some adaptions. So, I think, a basic gtk2 interface can be created very fast. After that all the changes listed on www.gtk.org must be checked. And I estimate, that this will take at least a full week of work.

testing is no problem, as for finishing, well maybe but I can't promise full dedication.

Any help is appreciated.

Mattias

Probably you mean gtk2forpascal on sourceforge. I'm one of the developers and I did it for lazarus. But I didn't find the time, to create a gtk2 interface for the lcl. If someone wants to try it, just mail.

Mattias

Quoting Mattias Gaertner :

The gtk2 interface has not yet been started. The idea is, to inherit from the gtk1 interface and just overload

overload or correct?

any procedure that needs some adaptions. So, I think, a basic gtk2 interface can be created very fast. After that all the changes listed on www.gtk.org

I downloaded all documents, but there's no changes specified just complete API specification, is there maybe some document of changes to ease the job. It wouldn't be easy to search every function and check it. So for start it would be much nicer if some such document would exists. www.gtk.org doesn't contain anything like that.

must be checked. And I estimate, that this will take at least a full week of work.

A bit too much to acomplish in one peace. but I think I can help at least a bit

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

m.

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

Quoting Mattias Gaertner :

are there some interfaces to unfinished or is it just not tested?

testing is no problem, as for finishing, well maybe but I can't promise full dedication.

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

D-Day is not soon.

Quoting Florian Klaempfl :

fam -> file alteration monitor
SGI has implemented this function in kernel >2.4, it is used to be informed about changes of file or folder. It is widely used in linux (nautilus and all other file managers)

it could be used for monitoring of files in editor as lazarus does but the code is much simpler and less intrusive, because hook gets registred in kernel and fs driver uses it to inform when changes occur

In case it should go into the fcl, contact

if you need any kind of file monitoring then it should go. Windows part could be simply made with shell functions

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

<snip>

Why don't you use dispatch and messages. See:
http://www.freepascal.org/docs-html/ref/node8.html#SECTION03533000000000000000

But what about the other unices, and older Linux?

Just fix the int64/longint overloading bug #2056. ;)

Mattias

Quoting Mattias Gaertner :

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

It depends, maybe lazarus can switch soon to 1.1