It would appear that on Mar 19, Carsten Haitzler did say:
> On Sun, 18 Mar 2012 15:56:54 -0400 "Joe(theWordy)Philbrook" <[email protected]>
> said:
> > The only time the name property fails to get the correct value is when more
> > then one konsole window is launched with differing --name options before X
> > actually starts... if I wait till after X {and therefore E17} starts, I can
> > feed this comma separated command pair to the everything launcher:
> >
> > konsole --workdir /home/jtwdyp/STUFF/ShuttleStuff --name F12crap --profile
> > BlackYellow -e medosumc ; konsole --workdir ~/mail --name F2alpine
> > --profile BlackGray -e alpine
> >
> > And each window winds up with the correct unique value...
> >
> > Hmmnnn I'm still not sure why the ~/.xinirc command strings fail. But If
> > I could remember how to tell E17 to start an application upon startup,
> > (that is "Settings Panel->Apps->Startup Applications" right? And if it's
> > possible to specify a user bash script as an application, then maybe I
> > could comment out the init strings in the .xintrc file and just use an
> > startup application bash script containing the command strings, and go back
> > to basing my windows remembers on name/class like I used to use...
>
> well from what you say above (summary):
>
> 1. if run manually later it works. if started on login it fails.
> 2. on login each konsole window has the SAME name(/class), which is the crux
> of
> the problem.
Exactly so.
> 3. WM_COMMAND (xprop and the command in the icccm dialog) i still don't know
> if
> it has the correct command listed (you didn't cover that).
Opps sorry. Thing is I don't know if WH_COMMAND is supposed to include all
the arguments to the command or just the command itself... If the latter
then:
WM_COMMAND(STRING) = { "konsole" }
would be correct. But if it's supposed to include the entire command
including all command line options, then not so much...
None of the command line option tags {IE "--name"} appear anywhere in the
xprop output. Though with the exception of the --profile option, the values
assigned to them appear scattered across:
"WM_CLASS(STRING)", "WM_NAME(STRING)", & "_NET_WM_NAME(UTF8_STRING)"
> 4. equo probably upgraded konsole and *IT* broke - no break in e here. of
> course i'm assuming that e READ the command property correctly as the windows
> start up with different content (medosumc vs alpine) right? you just dont get
> them in the right size/desktop/location/position etc. due to name/class being
> non-unique, and that is thanks to your konsole bug :)
Likely so. Though I doubt the kde devs would consider it much of a bug
since it only happens if X isn't running yet when the Konsole commands are
issued. AND I think they might say it wouldn't be a problem if E17 restored
saved desktop sessions like kde does...
However I did find that once I "created a personal launcher" for the
bash script, the launcher showed up in the "StartUp Applications" dialog
Which does successfully start both konsole windows with ALL their correct
values {including unique window names} Allowing the "Window Remembers to
work with the more stable name/class recognition values.
So for me it's no longer an issue.
Thanks!
--
| --- ___
| <0> <-> Joe (theWordy) Philbrook
| ^ J(tWdy)P
| ~\___/~ <<[email protected]>>
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
enlightenment-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
