Bug 714482 - Xcleints don't get started when using fvwm
Summary: Xcleints don't get started when using fvwm
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: switchdesk
Version: 21
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Than Ngo
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-06-19 15:04 UTC by Wolfgang Denk
Modified: 2015-12-02 16:02 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-02 02:35:34 UTC
Type: ---


Attachments (Terms of Use)
Patch to /usr/share/switchdesk/Xclients.fvwm (554 bytes, patch)
2011-06-19 15:04 UTC, Wolfgang Denk
no flags Details | Diff
Shortened version of ~/.Xclients-default (662 bytes, text/plain)
2015-10-22 10:32 UTC, Wolfgang Denk
no flags Details

Description Wolfgang Denk 2011-06-19 15:04:55 UTC
Created attachment 505475 [details]
Patch to /usr/share/switchdesk/Xclients.fvwm

Description of problem:

When using switchdesk to start a fvwm session, the user defined Xclients don;t get started.

Version-Release number of selected component (if applicable):

switchdesk-4.0.9-8.fc15.2.noarch

How reproducible:

always (and has been so for several releases; sorry, I was too lazy to report it earlier)

Steps to Reproduce:
1. Define some actions in your $HOME/.Xclients-default file
2. Start a new fvwm session
  
Actual results:

None of the defined Xclients gets started.

Expected results:

Actions defined in exec $HOME/.Xclients-$HOSTNAME$DISPLAY resp. in $HOME/.Xclients-default should be executed.

Additional info:

It seems that neither /usr/share/switchdesk/Xclients.fvwm nor any other file check for the existence of any .Xclients* files.

The attached patch fixes the problem for me.

Comment 1 Wolfgang Denk 2012-06-08 08:35:48 UTC
The problem is still present in FC17.

Comment 2 Wolfgang Denk 2013-01-28 07:41:02 UTC
The problem is still present in FC18.

Comment 3 Wolfgang Denk 2013-04-20 13:47:36 UTC
This bug is present since F15, even though I submitted a patch that fixes it.

What exactly is necessary that anybody picks that up and applies it?

The quality of Fedora is degrading from release to release - with F18 it has reached the limit of being unusable.  The fact that nobody cares at all about bug reports is extremely frustrating.

Comment 4 Wolfgang Denk 2013-10-15 10:45:16 UTC
Still present in F19.

Comment 5 Wolfgang Denk 2014-06-16 12:25:31 UTC
OK, so this bug is not TWO YEARS and FIVE RELEASES old,
and I even provided a patch that fixes it.

HELLO?  IS ANYBODY LISTENING?!?!?!?!?!

Comment 6 Wolfgang Denk 2015-01-29 09:16:03 UTC
We are approaching 4 years lifetime of a bug where a patch has been submitted.

Shame on Fedora QA!

Comment 7 Than Ngo 2015-02-27 13:41:28 UTC
Hi Wolfgang, sorry for delay! i'm now working on it.

i have tried to reproduce this issue on my local machine with following steps:

1. switchdesk fvwm
2. start X server with startx from text console.

FVWM session starts fine for me. I cannot reproduce your problem.


Could you please provide more infos? how did you start Xserver?

Thanks

Comment 8 Wolfgang Denk 2015-02-27 14:22:13 UTC
(In reply to Ngo Than from comment #7)
> Hi Wolfgang, sorry for delay! i'm now working on it.

Wonderful.

> i have tried to reproduce this issue on my local machine with following
> steps:
> 
> 1. switchdesk fvwm
> 2. start X server with startx from text console.

Well, this is definitely not the standard way to start a
graphical login under Fedora...

> FVWM session starts fine for me. I cannot reproduce your problem.
> 
> 
> Could you please provide more infos? how did you start Xserver?

Log out completely from the system.  At the GDM login screen, select FVWM session instead of the standard Gnome session, then provide your login credentials.

Comment 9 Than Ngo 2015-02-27 16:13:58 UTC
i will test it next week if i can reproduce this issue. thanks for your infos again.

Comment 10 Hans de Goede 2015-10-21 09:53:31 UTC
Hi Wolfgang,

I've tried to reproduce your problem, but things work fine for me. Can you provide some more details please.

What I've done is:

1) install fvwm
2) restart gdm (which graphical login manager are you using ?)
3) Select fvwm session, login, get fvwm

Looking at your patch the problem seems to be that you have a .Xclients-* file which you want to get executed instead of just executing the /usr/bin/fvwm binary, is that correct ?

And how does switchdesk fit into the whole picture ? Now a days most graphical login managers just look for available sessions in /usr/share/xsession/*.desktop and then execute the one chosen by the user during login.

Regards,

Hans

Comment 11 Hans de Goede 2015-10-21 10:01:38 UTC
Hi Again,

Looking a bit deeper it seems that the changes which you add to Xclients.fvwm are already part of Xclients.toplevel and that should get installed as ~/.Xclients, where as Xclients.fvwm should get installed as ~/.Xclients-default making Xclients.fvwm execute ~/.Xclients-default would lead to a loop where ~/.Xclients-default keeps excuting itself. So your patch does not seem to be correct.

Regards,

Hans

Comment 12 Wolfgang Denk 2015-10-21 19:43:17 UTC
(In reply to Hans de Goede from comment #10)

Dear Hans,

thanks for looking intot his...

> What I've done is:
> 
> 1) install fvwm
> 2) restart gdm (which graphical login manager are you using ?)
> 3) Select fvwm session, login, get fvwm

I'm running a standard installation, so yes, it's gdm.

> Looking at your patch the problem seems to be that you have a .Xclients-*
> file which you want to get executed instead of just executing the
> /usr/bin/fvwm binary, is that correct ?

Correct.  Just running fvwm is pretty boring, as it will start only
the empty desktop environment.  Traditionally I have all kinds of
applications preconfigured in .Xclients-*, so they get automagically
started when I log in.

> And how does switchdesk fit into the whole picture ? Now a days most
> graphical login managers just look for available sessions in
> /usr/share/xsession/*.desktop and then execute the one chosen by the user
> during login.

I don't know.  Yes, I do have a  /usr/share/xsessions/fvwm.desktop  on
my system, but I don't see how that would help to start a
user-configurable set of default applications on the FVWM desktop?

Best regards,

Wolfgang Denk

Comment 13 Wolfgang Denk 2015-10-21 19:50:33 UTC
(In reply to Hans de Goede from comment #11)

Dear Hans,

> Looking a bit deeper it seems that the changes which you add to
> Xclients.fvwm are already part of Xclients.toplevel and that should get

Obviously  /usr/share/switchdesk/Xclients.toplevel  does not come into
play for some reason.  Without my patch, only the commands in
/usr/share/switchdesk/Xclients.fvwm  are executed, no attempt is made
to execute any  ~/.Xclients-*  file


> installed as ~/.Xclients, where as Xclients.fvwm should get installed as
> ~/.Xclients-default making Xclients.fvwm execute ~/.Xclients-default would
> lead to a loop where ~/.Xclients-default keeps excuting itself. So your
> patch does not seem to be correct.

"Should get installed as ~/.Xclients" ... yes, this is the case:

	-> cmp /usr/share/switchdesk/Xclients.toplevel ~/.Xclients ; echo RC=$?
	RC=0

But this does not help anything.

If my patch is not correct - then what is the right way to have the
commands in ~/.Xclients-default (resp. ~/.Xclients-$HOSTNAME$DISPLAY)
executed automatically when I login?

Thanks in advance,

Wolfgang

Comment 14 Hans de Goede 2015-10-22 09:50:57 UTC
Hi Wolfgang,

How exactly are you starting fvwm. You are using a graphical login, correct ? Which display manager are you using ? And which session do you select inside the display manager ?

And what is the contents of your ~/.Xclients (identical to Xclients.toplevel, right ?)  and ~/.Xclients-default files ?

Regards,

Hans

Comment 15 Wolfgang Denk 2015-10-22 10:32:58 UTC
Created attachment 1085473 [details]
Shortened version of ~/.Xclients-default

Comment 16 Wolfgang Denk 2015-10-22 10:35:26 UTC
(In reply to Hans de Goede from comment #14)

Dear Hans,

> How exactly are you starting fvwm. You are using a graphical login, correct?

Correct.

> Which display manager are you using ?

I use gdm

> And which session do you select inside the display manager ?

I select "fvwm"

> And what is the contents of your ~/.Xclients (identical to
> Xclients.toplevel, right ?)

Yes, they are identical.

> and ~/.Xclients-default files ?

See attachment - this is a shortened version only, but for the test it
is sufficient to see xload and xclock starting.

Thanks for your help!

Wolfgang

Comment 17 Hans de Goede 2015-10-22 10:52:39 UTC
Hi,

(In reply to Wolfgang Denk from comment #16)
> (In reply to Hans de Goede from comment #14)
> 
> Dear Hans,
> 
> > How exactly are you starting fvwm. You are using a graphical login, correct?
> 
> Correct.
> 
> > Which display manager are you using ?
> 
> I use gdm
> 
> > And which session do you select inside the display manager ?
> 
> I select "fvwm"
> 
> > And what is the contents of your ~/.Xclients (identical to
> > Xclients.toplevel, right ?)
> 
> Yes, they are identical.
> 
> > and ~/.Xclients-default files ?
> 
> See attachment - this is a shortened version only, but for the test it
> is sufficient to see xload and xclock starting.

Ok, see this is different from the patched /usr/share/switchdesk/Xclients.fvwm you've attached to this bug, and switchdesk will install that as ~/.Xclients-default, so I think that this bug is no longer accurate.

I think that at point in time switchdesk may have installed /usr/share/switchdesk/Xclients.fvwm as ~/.Xclients, causing your problem, but since it now installs /usr/share/switchdesk/Xclients.toplevel, and
since that does exactly the thing you are adding in your patch I believe that everything works as it should now, and this bug can be closed.

Regards,

Hans

Comment 18 Wolfgang Denk 2015-10-22 12:20:33 UTC
(In reply to Hans de Goede from comment #17)

Dear Hans,

> Ok, see this is different from the patched
> /usr/share/switchdesk/Xclients.fvwm you've attached to this bug, and
> switchdesk will install that as ~/.Xclients-default, so I think that this
> bug is no longer accurate.

You write "switchdesk will install that as ~/.Xclients-default' - when
would it do that?  Do I have to manually run any special command for that?

> I think that at point in time switchdesk may have installed
> /usr/share/switchdesk/Xclients.fvwm as ~/.Xclients, causing your problem,
> but since it now installs /usr/share/switchdesk/Xclients.toplevel, and
> since that does exactly the thing you are adding in your patch I believe
> that everything works as it should now, and this bug can be closed.

Hm... I just installed fvwm and switchdesk on a virgin system, and
after logging into the fvwm sessin I get just the plain standard fvwm
menu, and there are no ~/.Xclients* files at all.

Best regards,

Wolfgang

Comment 19 Hans de Goede 2015-10-22 12:50:31 UTC
(In reply to Wolfgang Denk from comment #18)
> Hm... I just installed fvwm and switchdesk on a virgin system, and
> after logging into the fvwm sessin I get just the plain standard fvwm
> menu, and there are no ~/.Xclients* files at all.

Right, if you want to have ~/.Xclients files (instead of relying on the command defined in /usr/share/xsessions/fvwm.desktop) you need to run switchdesk once and select fvwm there.

Regards,

Hans

Comment 20 Fedora End Of Life 2015-11-04 15:19:10 UTC
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 21 Fedora End Of Life 2015-12-02 02:35:37 UTC
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.