It would appear that on Mar 14, Carsten Haitzler did say:
> On Wed, 14 Mar 2012 18:37:04 -0400 Joe Philbrook <[email protected]> said:
>
> >
> > Something changed:
> >
> > I wasn't sure if this was an E17 issue or something specific to Sabayon
> > Linux. {So far the only Distribution where I've encountered this problem}
> > where the behavior changed after a recent system update.
<snipped stuff>
> > Since Enlightenment doesn't "restore" a saved DE session like I used to do
> > with kde3, I learned to use it's "Window Remembers" function to recreate the
> > parts of the session I care about. And pre-Launch the ones that
> > Enlightenment
> > doesn't "Start on Login" correctly. Like for example It would start two
> > Konsole sessions, But I couldn't get it to use the assorted options needed
> > to
> > load the correct executables within them, nor to use the specific konsole
> > profile and {window}name definitions...
>
> on the konsole window if u launch manually click the icon (and in the window
> menu) look at window->icccm/netwm
Thanks: the 1cccm/netwm pop-up is a nice tool to peek at those properties
with.
> this pops up a dialog with the window properties. specifically you want the
> Command property to be the same command used to launch the app. it is up to
> the
> app to set this correctly as the wm has no idea what the command is otherwise.
> if this is set right then it should work in running with the right command +
> options (the options should be there too). additionally app should set
> name/class/role (or whatever is used to match the window - u can tweak what is
> used) BEFORE it shows the window. title is unreliable to match here as it
> changes so much, but name+class+role etc. should be reliable. if app changes
> these after showing the window e will have trouble matching it up.
Yeah, that's about what I thought. I always used to use Name+Class and wish
that my copy of Sabayon Linux still succeeded in consistently passing the
command assigned "Name" from the initialization string in my ~/.xinitrc to
each of the two separate Konsole windows So that E17 can use my carefully
composed Unique "Name(s)" to put them in their intended desktop areas...
> > Currently my ~/.xinitrc contains:
> >
> > xdaliclock -12 -noseconds -builtin1 &
> > konsole --workdir /home/jtwdyp/STUFF/ShuttleStuff --name F12crap --profile
> > BlackYellow -e medosumc &
> > yakuake &
> > konsole --workdir ~/mail --name F2alpine --profile BlackGray -e alpine &
> > /usr/bin/enlightenment_start
> > Today however, after I ran "equo upgrade" The "name" value stopped working
> > properly with the ~/.xinitrc invoked instances of konsole. Sometimes they
> > both wind up named "F2alpine", and sometimes they both wind up named
> > "F12crap"
>
> what does equo upgrade do?
>
equo is the CLI tool for Sabayon Linux package management. It will
install/remove binaries from their "Entropy" repository system.
(Note: it's still possible to use instead, Gentoo's Portage tree and have
emerge custom build all your packages. But mixing the two package management
systems is NOT for beginners...)
Run AFTER a recent "equo update" the "equo upgrade" command will upgrade
all installed packages to the latest versions in the repo.
> title is less reliable due to it being able to change - name/class should not.
> if konsole changes name/class AFTEr showing - thats a konsole bug. if e doesnt
> get the right name then its e's bug. try "xprop" and click on your console to
> see all the properties after they get shown - name/class should be there eg:
>
> WM_CLASS(STRING) = "xterm", "XTerm"
>
> check this is correct and matches the name/class in the icccm/netwm dialog in
> e.
>
the medosumc window:
WM_CLASS(STRING) = "F12crap", "Konsole"
the alpine window:
WM_CLASS(STRING) = "F12crap", "Konsole"
In both cases the two quoted strings match the corresponding icccm/netwm
field values for Name, Class...
I note that the init string in my ~/.xinitrc for the alpine session
specified a different name:
> > konsole --workdir ~/mail --name F2alpine --profile BlackGray -e alpine &
And which command is identical {excepting only the "&"} to the command
assigned in e17's keyboard shortcuts to <ctrl>+<win>+<alt>+a which upon
closing the .xintrc spawned alpine konsole session, I recreated it with the
shortcut and got:
WM_CLASS(STRING) = "F2alpine", "Konsole"
Which in turn did match the Name, Class values in the new session's icccm/netwm
properties...
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...
--
| ~^~ ~^~
| <?> <?> 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
