I have a program written for Windows being converted to Linux, and have hit a few win api calls I need to replace.
Mostly they are to do with window control
eg ShowWindow, SetWindowPos, MoveWindow etc etc
These are used to control windows outside of the program itself, not internal forms.

Would anybody know where I could find a listing / source that I could track equivalents to suit Linux ?

Really appreciated - Thanks

This is actually quite a bit trickier than you think - the reason being that under Linux there is no single way that windows are controlled nor a single API for doing it with. Various window managers and widgetsets behave in different ways.
All of them are implemented (somewhere along the line at least) using xlib and I think if you use xlib you could do the things you are trying to do - though this is a very low-level way to code (fpc can use xlib though just put xlib in your uses clause). You could also check the gtk docs (and add gtk itself to your uses clause) and see if it has an equivalent (I don't THINK so but it's worth looking) - if you can do it with GTK it will be easier and simpler code than with xlib because gtk is much more high level.

What all the above do is to send hints to the window manager ASKING it to please do an action (the window manager won't always honour it especially as some may not even be ABLE to honour the request) but usually programs ask this on their OWN behalf. It is definitely possible to send window manager hints for OTHER windows, but it isn't straight-forward to do - you'll need to read up a bit about wm_hints to figure out the details.
Xlib is probably your most guaranteed way to make this work, of course if you wanted to be nice you could write wrapper functions that are compatible in their calls to the win32 API calls you were using but use xlib instead (advantage it isn't tied to any particular linux widgetset - GTK calls won't play nice for people with QT apps) to implement them, and then put them all in a unit which other people could add on to and which people porting from delphi could use to replace win32 calls with minimum fuss ?

Either way, I hope I at least helped you know how to find the right FM to R. :)

Ciao
A.J.

A.J. Venter wrote

This is actually quite a bit trickier than you think - the reason being that under Linux there is no single way that windows are controlled nor a single API for doing it with. Various window managers and widgetsets behave in different ways.

A.J. is correct. It is a bit trickier than under Windows, but should be impossible. Window Manager sometimes behave very different from another, so your mileage my vary.

Using Xlib directly will probably be your best bet. Xlib functions you will probably be using are...

XMoveResizeWindow(FDisplay, FWinHandle, left, top, w, h);
XMoveWindow(FDisplay, FWinHandle, x, y);

The FDisplay you can query (X Window supports multiple display surfaces on the same server [this has nothing to do with multiple monitors]). Read up on XOpenDisplay() and XDefaultScreen().

I'm not sure where you are going to get the FWinHandle from. I'm pretty sure you can query the X Server for a list of child windows from XRootWindow().

The rest is easy... But do remember, like A.J. said. When you call xlib functions they tend to create hints and you ask the Window Manager to fullfill that hint (request), but it isn't garaunteed. You are simply asking, not telling it what to do.

Regards,
- Graeme -

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

Graeme Geldenhuys wrote

A.J. is correct. It is a bit trickier than under Windows, but should be impossible.

Oops, a minor typo. that should read: '..., but should not be impossible."

Regards,
- Graeme -

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

Graeme Geldenhuys wrote

A.J. is correct. It is a bit trickier than under Windows, but should not be impossible. Window Manager sometimes behave very different from another, so your mileage my vary.

I just tried this. I created an application that takes a window ID and calls XMoveWindow() to a set coordinates.

I launched Gnome Calculater, used xwininfo to find out it's Window ID, typing it in, in my test application and clicked the button. The Gnome Calculater window moved to my specified coordinates. :-)

Regards,
- Graeme -

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

I'm not sure where you are going to get the FWinHandle from. I'm pretty sure you can query the X Server for a list of child windows from XRootWindow().

Apps can get their own window handle and there is a program included in the X utils that can query the winhandle (and some other things) of any particular open window - check the manpage for xwininfo. There is even a utility (xlsclients) which will list all running clients on the X server giving you the process that owns them and the winhandle they are using - you could contact xlsclients over a tprocess but most distro's no longer install the x utils by default so I would rather suggest you install the source package for x-utils (whatever your distro calls it) and look at the source code for xlsclients then see which functions it uses to do that query and write a small function that can query winhandles by processname or something (of course a process can open many windows).

How were you thinking of having your app identify the target window ? With a click ? If so you could possibly call xwininfo in a tprocess, and get the ID from the output, or you could check the source for Xwininfo to see how it finds out the ID from the click and adapt it to whatever input method you had in mind.

The rest is easy... But do remember, like A.J. said. When you call xlib functions they tend to create hints and you ask the Window Manager to fullfill that hint (request), but it isn't garaunteed. You are simply asking, not telling it what to do.

Aye, some of the more obscure ones don't even HAVE windows as we think of them... quite a few cannot minimize or iconify, probably the MAJORITY don't have taskbars built in (but icewm does, while KDE and Gnome puts the taskbars in entirely sepperate programs to the window managers), and I know of at least one that HAS no mouse interaction with windows. Apps can use the mouse, but you cannot use it to switch windows or maximise them or anything.
That said, KDE and gnome are between them about 80% of all Linux desktops, about 5% will be stuff like E17 and the last 15 is the various others combined, and KDE/Gnome handles probably almost every thing you can ask for, at least, if the user hasn't disabled it or overwritten it (both can tune their handling of window manager hints to deliberately ignore some or do something DIFFERENT when they receive them, mostly on a per-application basis, usually to get apps to work nicer in the specific environment)

Ciao
A.J.

A.J / Graeme
Thanks for the input on this - (and for doing some of my homework for me :)

I will study xlib and see if I can put a library together - will post whatever I come up with as soon as its usable

SteveG

That said, KDE and gnome are between them about 80% of all Linux desktops, about 5% will be stuff like E17 and the last 15 is the various others combined

I think XFCE has a good percentage, more than E17, maybe mostly due to Xubuntu and similar distributions/setups.

Kostas

Well nobody has full figures on any of them, E17 got a massive boost for being the (base of) native deskop on the very popular eeePC and the GPC as well. But you are right I forgot about XFCE but it is a very popular one, quite possibly more than E17.

Either way, this thread is drifting off topic now, the important point was just that the greater majority of the desktops out in the world should at least honour MOST of the things you ask it to do.

Ciao
A.J.

Well nobody has full figures on any of them, E17 got a massive boost for being the (base of) native deskop on the very popular eeePC and the GPC as well. But you are right I forgot about XFCE but it is a very popular one, quite possibly more than E17.

My eeePC had a custom Asus launcher, not E17 (which wouldn't be a good idea to use in eeePC, since it uses a lot of CPU and eeePC has a weak CPU). Some programs were GTK programs and some (most) were Qt programs. In the eeeuser wiki there is mentioned a "full desktop mode" which basically installs the full KDE (since eeePC uses a lot of KDE programs it makes more sense than installing some other desktop). However personally i just removed the Qt/KDE programs and installed XFCE :-P.

I don't know about GPC though.

Kostas