Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[XForms] application positioning

0 views
Skip to first unread message

alessandro basili

unread,
Dec 27, 2011, 8:40:37 PM12/27/11
to Development with and of XForms
Dear all,

I am trying to open my application in a given position on my Desktop and
I am aware of the fl_winposition. Unfortunately I am too lazy to modify
my application (indeed all of them...) to accept an additional command
line option to get the position - indeed is not only laziness, the
command-line interface is standardized and it does accept only specific
options.

Does anyone out there know how to locate the application somewhere in
the desktop without the need to use fl_winposition? I was thinking about
some environment variable or maybe just some other way to pass the
option to the window manager.

Thanks for any idea/comment.
Cheers,

Al

Jens Thoms Toerring

unread,
Dec 28, 2011, 3:30:37 PM12/28/11
to Development with and of XForms
Dear Al,
As far as I can see there unfortunately doesn't seem to be any
good way to achieve that. A "geometry" string passed to the pro-
gram isn't interpreted by XForms. Nor are any settings, e.g.
from the .Xresources file, taken into account. And using a
geonetry atring argument or setting a position/size via an
X resource are the two ways to do it I'm familiar with. And
within XForms when calling fl_show_form() only sizes and
positions are used that have been set via fl_set_form_size(),
fl_set_form_position() or fl_set_form_geometry() - in case
a 'place' value has been passed to fl_show_form() that
asks for evaluation of position or size information.

Personally, I always have used that when there was a need
for placing a form at a certain position. On the other
hand it indeed could be useful to set a position or size
via e.g. a geometry string. Although there would be a few
things to be considered first:

a) Which form is set according to the geomeptry string option?
It probably would be the "main form" (per default the first
one to be dispayed unless a different one is set explicitely
via fl_set_app_mainform())/
b) To facilitate this XForms would have to check for a
'-geometry' option on the commmand line. Since this
wasn't done before there can be a number of pplications
evaluation '-geometry' themselves which thus might break
when XForms would evaluate '-geometry' and not leave it
to the application (I got one myself where this would
be the case since it checks both for a '-geometry' option
as well as checking the .Xresource file).
c) I guess the form would need to be shown with fl_show_form()
with the 'place' argument set to 'FL_PLACE_POSITION' and/or
'FL_PLACE_GEOMETRY' etc. for the geometry string option to
be used.

I'm not sure yet that this would be a reasonable change,
especially given that it might break existing applications.
Does anyone has an opinion concerning this?

Best regards, Jens
--
\ Jens Thoms Toerring ________ j...@toerring.de
\_______________________________ http://toerring.de

alessandro basili

unread,
Dec 28, 2011, 8:34:01 PM12/28/11
to xforms-de...@nongnu.org
Hi Jens,

On 12/28/2011 9:30 PM, Jens Thoms Toerring wrote:
[...]
>>
>> Does anyone out there know how to locate the application somewhere in
>> the desktop without the need to use fl_winposition? I was thinking about
>> some environment variable or maybe just some other way to pass the
>> option to the window manager.
>
> As far as I can see there unfortunately doesn't seem to be any
> good way to achieve that. A "geometry" string passed to the pro-
> gram isn't interpreted by XForms. Nor are any settings, e.g.
> from the .Xresources file, taken into account. And using a
> geonetry atring argument or setting a position/size via an
> X resource are the two ways to do it I'm familiar with. And
> within XForms when calling fl_show_form() only sizes and
> positions are used that have been set via fl_set_form_size(),
> fl_set_form_position() or fl_set_form_geometry() - in case
> a 'place' value has been passed to fl_show_form() that
> asks for evaluation of position or size information.
>
> Personally, I always have used that when there was a need
> for placing a form at a certain position. On the other
> hand it indeed could be useful to set a position or size
> via e.g. a geometry string. Although there would be a few
> things to be considered first:
>
> a) Which form is set according to the geomeptry string option?
> It probably would be the "main form" (per default the first
> one to be dispayed unless a different one is set explicitely
> via fl_set_app_mainform())

I would assume the main form is drawn in the position specified.

> b) To facilitate this XForms would have to check for a
> '-geometry' option on the commmand line. Since this
> wasn't done before there can be a number of pplications
> evaluation '-geometry' themselves which thus might break
> when XForms would evaluate '-geometry' and not leave it
> to the application (I got one myself where this would
> be the case since it checks both for a '-geometry' option
> as well as checking the .Xresource file).

a '-geometry' option can actually be somehow annoying especially if the
command-line interface has to meet some specs. Checking the .Xresource
file might be more of a general solution, but then all the Forms will
open in the same position and this may not be what you want, unless
there's a mechanism to specify which application should be placed where
(but I have no idea how to do that).

> c) I guess the form would need to be shown with fl_show_form()
> with the 'place' argument set to 'FL_PLACE_POSITION' and/or
> 'FL_PLACE_GEOMETRY' etc. for the geometry string option to
> be used.
>
> I'm not sure yet that this would be a reasonable change,
> especially given that it might break existing applications.
> Does anyone has an opinion concerning this?
>

And I concur that no change request should be formulated prior to
understanding if this need is somehow shared in the community or it's
just my laziness in moving the window in the proper place.

Maybe there is a system level approach to that and does not need to be
addressed by XForms, but it's just an hypothesis.

> Best regards, Jens


0 new messages