[e-users] Window remembers: konsole window name assigned in ~/.xinitrc
Joe Philbrook
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.
But I've had no response to my Sabayon forum post, so I thought I'd find
out if anybody here knows what changed...
I have a strong preference for booting to console. And then, when and if
I'm ready for GUI, I run startx as a normal user... At which point, my
~/.xinitrc feeds a few applications to X that I expect to find running on
certain specific desktop areas when E17 {Enlightenment} starts. I've used
Enlightenment almost exclusively ever since I ran away from kde4. But one
of the places my kde roots show is a strong preference to use Konsole as my
"xterm" of choice.
I have two bash scripts that I expect to find running in their on Konsole
windows with specific --profile settings. One which runs my console based
email client {alpine} I expect to find on desktop area "1,0". The other is
a script that runs mc via a call to "su -c" so that it sits there waiting
on desktop area "3,2" for my root password to start the root mc session.
I also have two E17 keyboard shortcuts defined to recreate these windows on
demand, in the event I close them or {in the case of the 2nd script} If I
might need more than one root mc session open.
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...
Thus I use my ~/.xinitrc to initialize them with the desired options.
This has worked well for years. I use the same method on all the Linux
distributions that I run. (I have 5 of them installed on this PC)
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
A key component of which is the "Unique" strings assigned to the "--name"
flag that has for years reliably identified these two very different
konsole instances from any other Konsole instances.
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"
But after logging out and rerunning startx about 20 times (half of which
were full reboots) Not once did the each wind up with their own discretely
unique "names" within my Sabayon installation since my last:
equo update && equo upgrade
(which I do about once a month.) I note however that any instances of them
that I fire up with the keyboard shortcuts still consistently wind up with the
correct command defined name value. It is only the two instances that
Enlightenment inherits from the ~/.xinitrc that this value fails to get
correctly assigned. And It might be worth mentioning that ALL the other option
flags do work correctly. Even the ~/.xinitrc initialized konsole instances do
wind up with the correct working directories, as well as the correct konsole
profiles, and with the correct executable running within them.
Now however, in order to get E17 to place them in the correct desktop
areas, I need to uncheck the "Window name" option in the "Remember using"
dialog box, and rely instead on the "Title" option, and just hope that it's
value continues to use the current format of "${A}: ${B}" where A equals
the value assigned via the --workdir option, and B equals the value assigned to
the -e option. (I note that A is not the same as $PWD because "~/mail" is not
rendered as "/home/jtwdyp/mail")
Does anyone know what changed? Or whether this is more correctly an
Sabayon Linux issue, or perhaps even an kde thing???
Or if you happen to know how to make sure that the window Title will always
be rendered as "${A}: ${B}" {see above} I'd appreciate a clue.
--
| ~^~ ~^~
| <?> <?> Joe (theWordy) Philbrook
| ^ J(tWdy)P
| \___/ <<jtw...@ttlc.net>>
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
enlightenment-users mailing list
enlighten...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Carsten Haitzler
on the konsole window if u launch manually click the icon (and in the window
menu) look at window->icccm/netwm
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.
> Thus I use my ~/.xinitrc to initialize them with the desired options.
>
> This has worked well for years. I use the same method on all the Linux
> distributions that I run. (I have 5 of them installed on this PC)
>
> 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
>
>
> A key component of which is the "Unique" strings assigned to the "--name"
> flag that has for years reliably identified these two very different
> konsole instances from any other Konsole instances.
>
> 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?
> But after logging out and rerunning startx about 20 times (half of which
> were full reboots) Not once did the each wind up with their own discretely
> unique "names" within my Sabayon installation since my last:
>
> equo update && equo upgrade
>
> (which I do about once a month.) I note however that any instances of them
> that I fire up with the keyboard shortcuts still consistently wind up with the
> correct command defined name value. It is only the two instances that
> Enlightenment inherits from the ~/.xinitrc that this value fails to get
> correctly assigned. And It might be worth mentioning that ALL the other option
> flags do work correctly. Even the ~/.xinitrc initialized konsole instances do
> wind up with the correct working directories, as well as the correct konsole
> profiles, and with the correct executable running within them.
>
> Now however, in order to get E17 to place them in the correct desktop
> areas, I need to uncheck the "Window name" option in the "Remember using"
> dialog box, and rely instead on the "Title" option, and just hope that it's
> value continues to use the current format of "${A}: ${B}" where A equals
> the value assigned via the --workdir option, and B equals the value assigned
> to the -e option. (I note that A is not the same as $PWD because "~/mail" is
> not rendered as "/home/jtwdyp/mail")
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.
> Does anyone know what changed? Or whether this is more correctly an
> Sabayon Linux issue, or perhaps even an kde thing???
>
> Or if you happen to know how to make sure that the window Title will always
> be rendered as "${A}: ${B}" {see above} I'd appreciate a clue.
>
> --
> | ~^~ ~^~
> | <?> <?> Joe (theWordy) Philbrook
> | ^ J(tWdy)P
> | \___/ <<jtw...@ttlc.net>>
>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> enlightenment-users mailing list
> enlighten...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
Joe(theWordy)Philbrook
It would appear that on Mar 14, Carsten Haitzler did say:
> On Wed, 14 Mar 2012 18:37:04 -0400 Joe Philbrook <jtw...@ttlc.net> 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
| \___/ <<jtw...@ttlc.net>>
------------------------------------------------------------------------------
Carsten Haitzler
said:
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.
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).
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 :)
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
Joe(theWordy)Philbrook
It would appear that on Mar 19, Carsten Haitzler did say:
> On Sun, 18 Mar 2012 15:56:54 -0400 "Joe(theWordy)Philbrook" <jtw...@ttlc.net>
> 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
| ~\___/~ <<jtw...@ttlc.net>>
Carsten Haitzler
said:
it should include the full command - arguments too. otherwise e has no ability
to read it AND the arguments and remember to run the command PLUS arguments. :)
e runs what the wm_command says to run. :) app sets this.
> 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:
i smell an equo upgrade breaking konsole. :)
> "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.
cool. well at this point the only other thing i'd say is.. "don't use konsole
if its broken". xterm i know works correctly (with some .Xdefaults it looks
just fine color and font-wise).
> Thanks!
>
> --
> | --- ___
> | <0> <-> Joe (theWordy) Philbrook
> | ^ J(tWdy)P
> | ~\___/~ <<jtw...@ttlc.net>>
>
>
> ------------------------------------------------------------------------------
> 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
> enlighten...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
Joe(theWordy)Philbrook
It would appear that on Mar 20, Carsten Haitzler did say:
> On Mon, 19 Mar 2012 14:33:04 -0400 "Joe(theWordy)Philbrook" <jtw...@ttlc.net>
> said:
>
> >
> > It would appear that on Mar 19, Carsten Haitzler did say:
> > > 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...
>
> it should include the full command - arguments too. otherwise e has no ability
> to read it AND the arguments and remember to run the command PLUS arguments. :)
> e runs what the wm_command says to run. :) app sets this.
>
> > 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)"
>
> i smell an equo upgrade breaking konsole. :)
>
Perhaps Konsole *_IS_* broken. Though I think it's more like KDE4 has the
foul smell of much broken{wind}. And I suspect that this aspect of whatever
Konsole is doing wrong so that xprop doesn't get the full command string
has been happening for some time now. I didn't start using E17 till kde4
ticked me off. But I've never been able to use windows remembers to
start one of these konsoles "on login" complete with the path, profile, or
executable... Also the WM_COMMAND(STRING) doesn't include the argument list
even when I start it from within E Like with the keyboard shortcut. Nor
does it when I run xprop when running any of the other 4 installed Linux
distros {with all of which, the window "name" is still correctly assigned
even when initialized via ~/.xinitrc...} It's like Konsole uses the CLI
options, but doesn't see any reason to share the info.
> > 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.
>
> cool. well at this point the only other thing i'd say is.. "don't use konsole
> if its broken". xterm i know works correctly (with some .Xdefaults it looks
> just fine color and font-wise).
Well xterm may work better with xprop. But I have enough difficulty with
manipulating the mouse well enough to mark a selection of text, that it
matters to me that with Konsole I can then right click "c" {copy} And then use
^V to paste to *_CURSOR_* position in most gui apps {most commonly pasting a URL
into a Firefox's location field} without having to carefully position the
uncooperative mouse cursor to exactly the right spot while I emulate middle
click on my two button trackball. And/or {better yet} mark text with the
keyboard in some gui app such as LibreOffice, copy it with ^C and then I only
have to keep that durned mouse pointer anywhere within the konsole screen
While I right-click then type "p" to paste it to the cursor position of
konsole. With xterm I don't get the right click menu. And I detest the HOLD
THE BUTTON DOWN WHILE SELECTING method used by xterms <ctrl>+<LeftButton> and
<ctrl>+<RightButton> menus (for on the fly adjustments) Nor have I figured out
how to alter the color settings on the fly for those times when my tired eyes
NEED a change and I'm already many screenfuls deep into a LONG file...
I'm just glad that so far them KDE devs haven't messed up Konsole so far
that I can't use it. As while there are a few alternatives, There isn't any
such thing as a good replacement. But give them enough time, and it's bound
to happen. and then I'll likely make more use of xterm...
Be that as it may, I thank you for the help and suggestions. It has
certainly improved my understanding of how a some things work.
Carsten Haitzler
said:
thats what it smells like. i use xterm and it behaves like a good little boy:
WM_COMMAND(STRING) = { "xterm", "-e", "htop" }
> > > 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.
> >
> > cool. well at this point the only other thing i'd say is.. "don't use
> > konsole if its broken". xterm i know works correctly (with some .Xdefaults
> > it looks just fine color and font-wise).
>
> Well xterm may work better with xprop. But I have enough difficulty with
> manipulating the mouse well enough to mark a selection of text, that it
> matters to me that with Konsole I can then right click "c" {copy} And then use
> ^V to paste to *_CURSOR_* position in most gui apps {most commonly pasting a
> URL into a Firefox's location field} without having to carefully position the
> uncooperative mouse cursor to exactly the right spot while I emulate middle
> click on my two button trackball. And/or {better yet} mark text with the
thats how xterm works.. but not ctrl+c/v - middle mouse click to paste. just
hilight to copy. old school x style. :) you can skip the ctrl+c bit :)
> keyboard in some gui app such as LibreOffice, copy it with ^C and then I only
> have to keep that durned mouse pointer anywhere within the konsole screen
> While I right-click then type "p" to paste it to the cursor position of
> konsole. With xterm I don't get the right click menu. And I detest the HOLD
> THE BUTTON DOWN WHILE SELECTING method used by xterms <ctrl>+<LeftButton> and
> <ctrl>+<RightButton> menus (for on the fly adjustments) Nor have I figured out
gee. i barely ever touch those :) so it doesnt bother me :)
> how to alter the color settings on the fly for those times when my tired eyes
> NEED a change and I'm already many screenfuls deep into a LONG file...
aaah i've never needed to :)
> I'm just glad that so far them KDE devs haven't messed up Konsole so far
> that I can't use it. As while there are a few alternatives, There isn't any
> such thing as a good replacement. But give them enough time, and it's bound
> to happen. and then I'll likely make more use of xterm...
one of these days we have to modernize eterm (or start afresh) and make an e
terminal that fits in with modern efl (uses evas, edje, ecore etc.)... one of
these days.
> Be that as it may, I thank you for the help and suggestions. It has
> certainly improved my understanding of how a some things work.
>
> --
> | --- ___
> | <0> <-> Joe (theWordy) Philbrook
> | ^ J(tWdy)P
> | ~\___/~ <<jtw...@ttlc.net>>
>
>
> ------------------------------------------------------------------------------
> 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
> enlighten...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
Joe(theWordy)Philbrook
It would appear that on Mar 22, Carsten Haitzler did say:
> On Thu, 22 Mar 2012 00:56:21 -0400 "Joe(theWordy)Philbrook" <jtw...@ttlc.net>
> said:
> > > thats how xterm works.. but not ctrl+c/v - middle mouse click to paste. just
> > > hilight to copy. old school x style. :) you can skip the ctrl+c bit :)
> >
> > That part works in a Konsole to, Provided I want to paste via middle click.
> > Which presents two difficulties for me. Both related to having poor mouse
> > coordination.
> > (1)When I paste to any gui application via the middle click.
> > invariably the text cursor is first moved to the mouse pointer position.
>
> THAT behavior in apps/toolkits, i find INCREDIBLY annoying. :(
>
> > Since I have difficulty correctly positioning anything with the mouse I
> > find it much easier to position the text cursor with the keyboard and then
> > use a keyboard shortcut to paste to it. Hence the right click menu
> > followed by the "c" to copy the marked text to the correct buffer for
> > pasting with ^V...
>
> sure, but in xterm it'll go where the text cursor is.. YAY! :)
>
Likewise when pasting *_to_* Konsole, whether via a successful middle click
or a right click menu->"p"
> > (2)I sometimes need to make several attempts, just to mark the
> > correct text string with the mouse. Once I finally get the right text
> > segment marked, I'm not willing to trust my poor mouse coordination to
> > attempt emulating the middle click by cording the left and right buttons,
> > because I'm just as likely to accidentally mark something new as to actually
> > paste the contents that used to be in the gpm clipboard. {sigh}
>
> have u tried double/triple click and customising the "cut chars" (the chars
> where the term decides a word begins/ends). i use:
>
> XTerm*.charClass:
> 37-38:48,43:48,45-57:48,60:48,62:48,64-90:48,95:48,97-122:48,124:48,126:48
>
> very much more usable for me :)
Yes I use both double and triple clicking as often as I can avoid having to
hold a mouse button down and drag the pointer to mark something.
I'm guessing this "XTerm*.charClass:" definition goes in ~/.Xresources?
Or alternatively could it somehow be added to a cli string like: This 80+
column easy eye string from one of my keyboard shortcuts???
xterm -bg gray75 -fg DarkBlue -fn 12x24 -geometry 82x25
> > > one of these days we have to modernize eterm (or start afresh) and make an e
> > > terminal that fits in with modern efl (uses evas, edje, ecore etc.)... one
> > > of these days.
> >
> > Speaking of Eterm, how about a trip down memory lane? I have an old memory
> > backed up by an old screenshot of a surreal landscape image with a command
> > prompt printed on the upper lefthand corner and a boarder that referred to the
> > terminal window as being something called "Eterm-0.8.10". At the time I was a
> > kde user. And I hadn't even heard of Enlightenment yet. But somehow I found
> > this Eterm terminal that displayed a different surreal landscape as a
> > background image every time I initialized it. Though if memory serves, I found
>
> yup. random background feature. picks 1 from a list. :)
>
> > it hard to actually use because the background image often interfered with the
> > legibility of the text. S0 what I did was to open a full screen session of it
>
> yeah. poor choice in backgrounds to make sure they contrast from the text
> colors. that's all. you could change the wallpaper set yourself if u wanted to.
>
Yeah, but at the time I didn't know where to find such kool graphic
images... So of course whenever I noticed one I liked, a snapshot of it was
added to the folder I keep my personal background images in...
Of course, that means that every now and then, when I'm too tired to
realize it's just a background image I get a little frustrated trying to
type a command into what looks like my bash prompt in the upper left hand
corner... ;-)
What would have had me actually "*_using_*" that version of Eterm a lot would
have been a good opaque contrasting "character" background for all printable
text characters So that you only saw those portions of the background that
wasn't currently printed on...
Thanks again.
--
| ~^~ ~^~
| <*> <*> Joe (theWordy) Philbrook
| ^ J(tWdy)P
| \___/ <<jtw...@ttlc.net>>
Joe(theWordy)Philbrook
It would appear that on Mar 23, Carsten Haitzler did say:
> On Thu, 22 Mar 2012 13:31:16 -0400 "Joe(theWordy)Philbrook" <jtw...@ttlc.net>
> said:
> > I'm guessing this "XTerm*.charClass:" definition goes in ~/.Xresources?
> > Or alternatively could it somehow be added to a cli string like: This 80+
> > column easy eye string from one of my keyboard shortcuts???
>
> yeah. ~/.Xdefaults (or .Xresources - same thing). xrdb -load .Xdefaults on
> login or whenever u update. e17 has an option to do this for u.
Well I put the "XTerm*.charClass:" def there and added the
"xrdb -load .Xdefaults" command to my ~/.xintrc files...
> > xterm -bg gray75 -fg DarkBlue -fn 12x24 -geometry 82x25
>
> you can convert all these to lines in your .Xdefaults and save fat cmdlines :)
>
Yeah I suppose I could put that in the ~/.Xdefaults in case something
automatically starts an xterm. But I normally use a keybinding for that
anyway. ( win+F2 ) Plus I don't think ~/.Xdefaults method would also handle
my alternative keybindings:
( shift+win+F2 ) For those times when it don't fit in 80 columns neatly:
xterm -bg gray75 -fg DarkBlue -fn 10x20 -geometry 100x20
& ( ctrl+win+F2 ) For those times when I need a light on dark terminal:
xterm -bg black -fg green -fn 12x24 -geometry 82x25
And of course, if I ever give up on konsole I'll need to convert my konsole
based keybindings to use xterm instead.
Carsten Haitzler
said:
>
> It would appear that on Mar 23, Carsten Haitzler did say:
>
> > On Thu, 22 Mar 2012 13:31:16 -0400 "Joe(theWordy)Philbrook"
> > <jtw...@ttlc.net> said:
> > > I'm guessing this "XTerm*.charClass:" definition goes in ~/.Xresources?
> > > Or alternatively could it somehow be added to a cli string like: This 80+
> > > column easy eye string from one of my keyboard shortcuts???
> >
> > yeah. ~/.Xdefaults (or .Xresources - same thing). xrdb -load .Xdefaults on
> > login or whenever u update. e17 has an option to do this for u.
>
> Well I put the "XTerm*.charClass:" def there and added the
> "xrdb -load .Xdefaults" command to my ~/.xintrc files...
>
> > > xterm -bg gray75 -fg DarkBlue -fn 12x24 -geometry 82x25
> >
> > you can convert all these to lines in your .Xdefaults and save fat
> > cmdlines :)
> >
>
> Yeah I suppose I could put that in the ~/.Xdefaults in case something
> automatically starts an xterm. But I normally use a keybinding for that
> anyway. ( win+F2 ) Plus I don't think ~/.Xdefaults method would also handle
> my alternative keybindings:
>
> ( shift+win+F2 ) For those times when it don't fit in 80 columns neatly:
>
> xterm -bg gray75 -fg DarkBlue -fn 10x20 -geometry 100x20
>
> & ( ctrl+win+F2 ) For those times when I need a light on dark terminal:
>
> xterm -bg black -fg green -fn 12x24 -geometry 82x25
>
> And of course, if I ever give up on konsole I'll need to convert my konsole
> based keybindings to use xterm instead.
you'd be amazed at what the xdefaults/resources can actually set up. quite a
lot. :)
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com