Greetings everybody;
Everytime I have to reboot, but often, or more recently because of tdm updates, restart tdm, I have had to find a shell and execute "alsactl restore" before I have sound.
Is there a file that runs after my login, far enough after it, that I could add that command to instead of figureing out "hey its awful quiet in here" some time after the restart and reminds me to go and execute it?
If I could figure out where in the restart the sound gets muted, I'd fix it there. This has been a nearly 2 year long problem for me.
Thanks everybody.
Cheers, Gene Heskett
Am Dienstag, 9. Februar 2016 schrieb Gene Heskett:
Greetings everybody;
Everytime I have to reboot, but often, or more recently because of tdm updates, restart tdm, I have had to find a shell and execute "alsactl restore" before I have sound.
Is there a file that runs after my login, far enough after it, that I could add that command to instead of figureing out "hey its awful quiet in here" some time after the restart and reminds me to go and execute it?
If I could figure out where in the restart the sound gets muted, I'd fix it there. This has been a nearly 2 year long problem for me.
Thanks everybody.
Cheers, Gene Heskett
Hi Gene!
Add in your .xinitrc:
( sleep 10; alsactl restore) &
You might change 10 to any number of seconds you like :-)
Nik
On Tuesday 09 February 2016 11:05:30 Dr. Nikolaus Klepp wrote:
Am Dienstag, 9. Februar 2016 schrieb Gene Heskett:
Greetings everybody;
Everytime I have to reboot, but often, or more recently because of tdm updates, restart tdm, I have had to find a shell and execute "alsactl restore" before I have sound.
Is there a file that runs after my login, far enough after it, that I could add that command to instead of figureing out "hey its awful quiet in here" some time after the restart and reminds me to go and execute it?
If I could figure out where in the restart the sound gets muted, I'd fix it there. This has been a nearly 2 year long problem for me.
Thanks everybody.
Cheers, Gene Heskett
Hi Gene!
Add in your .xinitrc:
( sleep 10; alsactl restore) &
You might change 10 to any number of seconds you like :-)
Nik
Thats probably better than my idea was, which was to add a bash script to ~/.trinity/Autostart, named sound that did the same thing.
But since I already have the xrdb line in there, I terminated it with a && so this would be exec'd after that bit of sed magic you supplied.
Since theres quite a bit of stuff being restored when tdm restarts, which takes a good 30+ seconds to do, I wish I could find where to get it to restart each of the numerous term's I use on its correct workspace screen. They always restore with the correct number of tabs, but they all pile up on the same screen & have to be moved to the screen I am used to using for that particular workflow. I think the only exception to that is probably trinity-kcalc, which always seems to be on the workspace #3 it was running on prior to the restart. So someplace, there is that info. Also, the tde version of kcalc does this, the kde version does not restart.
Yeah, I know, beggars and horses...
Thanks Nik.
Cheers, Gene Heskett
Am Dienstag, 9. Februar 2016 schrieb Gene Heskett:
On Tuesday 09 February 2016 11:05:30 Dr. Nikolaus Klepp wrote:
Am Dienstag, 9. Februar 2016 schrieb Gene Heskett:
Greetings everybody;
Everytime I have to reboot, but often, or more recently because of tdm updates, restart tdm, I have had to find a shell and execute "alsactl restore" before I have sound.
Is there a file that runs after my login, far enough after it, that I could add that command to instead of figureing out "hey its awful quiet in here" some time after the restart and reminds me to go and execute it?
If I could figure out where in the restart the sound gets muted, I'd fix it there. This has been a nearly 2 year long problem for me.
Thanks everybody.
Cheers, Gene Heskett
Hi Gene!
Add in your .xinitrc:
( sleep 10; alsactl restore) &
You might change 10 to any number of seconds you like :-)
Nik
Thats probably better than my idea was, which was to add a bash script to ~/.trinity/Autostart, named sound that did the same thing.
But since I already have the xrdb line in there, I terminated it with a && so this would be exec'd after that bit of sed magic you supplied.
Since theres quite a bit of stuff being restored when tdm restarts, which takes a good 30+ seconds to do, I wish I could find where to get it to restart each of the numerous term's I use on its correct workspace screen. They always restore with the correct number of tabs, but they all pile up on the same screen & have to be moved to the screen I am used to using for that particular workflow. I think the only exception to that is probably trinity-kcalc, which always seems to be on the workspace #3 it was running on prior to the restart. So someplace, there is that info. Also, the tde version of kcalc does this, the kde version does not restart.
Yeah, I know, beggars and horses...
Thanks Nik.
Cheers, Gene Heskett
Hi Gene!
Last time I used saved sessions to restore my workspace after login, it worked flawless - but that's been more than a year ago. But I also rember, I had to use "start with empty session" temporarily (for one or two reboots) to get rid of some hikups.
Nik
On Tuesday 09 February 2016 13:54:21 Dr. Nikolaus Klepp wrote: [...]
Hi Gene!
Last time I used saved sessions to restore my workspace after login, it worked flawless - but that's been more than a year ago. But I also rember, I had to use "start with empty session" temporarily (for one or two reboots) to get rid of some hikups.
Nik
And where is that option? I don't recall seeing it when I walked thru it earler today. Are my cataracts getting that bad? :(
Cheers, Gene Heskett
In article 201602091426.58790.gheskett@shentel.net, Gene Heskett trinity-users@lists.pearsoncomputing.net wrote:
On Tuesday 09 February 2016 13:54:21 Dr. Nikolaus Klepp wrote: [...]
Hi Gene!
Last time I used saved sessions to restore my workspace after login, it worked flawless - but that's been more than a year ago. But I also rember, I had to use "start with empty session" temporarily (for one or two reboots) to get rid of some hikups.
Nik
And where is that option? I don't recall seeing it when I walked thru it earler today. Are my cataracts getting that bad? :(
In Control centre, it's in TDE Components / Session Manager.
Nick
On Tuesday 09 February 2016 14:36:21 Nick Leverton wrote:
In article 201602091426.58790.gheskett@shentel.net,
Gene Heskett trinity-users@lists.pearsoncomputing.net wrote:
On Tuesday 09 February 2016 13:54:21 Dr. Nikolaus Klepp wrote: [...]
Hi Gene!
Last time I used saved sessions to restore my workspace after login, it worked flawless - but that's been more than a year ago. But I also rember, I had to use "start with empty session" temporarily (for one or two reboots) to get rid of some hikups.
Nik
And where is that option? I don't recall seeing it when I walked thru it earler today. Are my cataracts getting that bad? :(
In Control centre, it's in TDE Components / Session Manager.
Nick
Found it, was set for restore. Which is good but doesn't remember the workspace the restored stuff was running on.
I note that most of the time, the restored term prompts do show the directory it was sitting in when I restarted it, causing that term & shell to be killed. So its remembering that, but not the workspace.
Is that a bug? Or just hasn't been coded to do yet?
Thanks Nick.
Cheers, Gene Heskett
On Tuesday 09 February 2016 23:10:08 Gene Heskett wrote:
On Tuesday 09 February 2016 14:36:21 Nick Leverton wrote:
In article 201602091426.58790.gheskett@shentel.net,
Gene Heskett trinity-users@lists.pearsoncomputing.net wrote:
On Tuesday 09 February 2016 13:54:21 Dr. Nikolaus Klepp wrote: [...]
Hi Gene!
Last time I used saved sessions to restore my workspace after login, it worked flawless - but that's been more than a year ago. But I also rember, I had to use "start with empty session" temporarily (for one or two reboots) to get rid of some hikups.
Nik
And where is that option? I don't recall seeing it when I walked thru it earler today. Are my cataracts getting that bad? :(
In Control centre, it's in TDE Components / Session Manager.
Nick
Found it, was set for restore. Which is good but doesn't remember the workspace the restored stuff was running on.
I note that most of the time, the restored term prompts do show the directory it was sitting in when I restarted it, causing that term & shell to be killed. So its remembering that, but not the workspace.
Is that a bug? Or just hasn't been coded to do yet?
Have you tried Nik's suggestion and turned the restore off for a couple of reboots?
Lisi
On Tuesday 09 February 2016 18:34:28 Lisi Reisz wrote:
On Tuesday 09 February 2016 23:10:08 Gene Heskett wrote:
On Tuesday 09 February 2016 14:36:21 Nick Leverton wrote:
In article 201602091426.58790.gheskett@shentel.net,
Gene Heskett trinity-users@lists.pearsoncomputing.net wrote:
On Tuesday 09 February 2016 13:54:21 Dr. Nikolaus Klepp wrote: [...]
Hi Gene!
Last time I used saved sessions to restore my workspace after login, it worked flawless - but that's been more than a year ago. But I also rember, I had to use "start with empty session" temporarily (for one or two reboots) to get rid of some hikups.
Nik
And where is that option? I don't recall seeing it when I walked thru it earler today. Are my cataracts getting that bad? :(
In Control centre, it's in TDE Components / Session Manager.
Nick
Found it, was set for restore. Which is good but doesn't remember the workspace the restored stuff was running on.
I note that most of the time, the restored term prompts do show the directory it was sitting in when I restarted it, causing that term & shell to be killed. So its remembering that, but not the workspace.
Is that a bug? Or just hasn't been coded to do yet?
Have you tried Nik's suggestion and turned the restore off for a couple of reboots?
Lisi
No I haven't Lisi. Does it not store a new list of stuff each time as it shuts down when that is checked?
IDK.
Thanks Lisi.
Cheers, Gene Heskett
Am Mittwoch, 10. Februar 2016 schrieb Gene Heskett:
On Tuesday 09 February 2016 18:34:28 Lisi Reisz wrote:
On Tuesday 09 February 2016 23:10:08 Gene Heskett wrote:
On Tuesday 09 February 2016 14:36:21 Nick Leverton wrote:
In article 201602091426.58790.gheskett@shentel.net,
Gene Heskett trinity-users@lists.pearsoncomputing.net wrote:
On Tuesday 09 February 2016 13:54:21 Dr. Nikolaus Klepp wrote: [...]
Hi Gene!
Last time I used saved sessions to restore my workspace after login, it worked flawless - but that's been more than a year ago. But I also rember, I had to use "start with empty session" temporarily (for one or two reboots) to get rid of some hikups.
Nik
And where is that option? I don't recall seeing it when I walked thru it earler today. Are my cataracts getting that bad? :(
In Control centre, it's in TDE Components / Session Manager.
Nick
Found it, was set for restore. Which is good but doesn't remember the workspace the restored stuff was running on.
I note that most of the time, the restored term prompts do show the directory it was sitting in when I restarted it, causing that term & shell to be killed. So its remembering that, but not the workspace.
Is that a bug? Or just hasn't been coded to do yet?
Have you tried Nik's suggestion and turned the restore off for a couple of reboots?
Lisi
No I haven't Lisi. Does it not store a new list of stuff each time as it shuts down when that is checked?
IDK.
Thanks Lisi.
Cheers, Gene Heskett
Hi Gene!
The terminal should be restored on the correct workspace, but sessions are not overwritten, just saved anew. If I recall correctly, the sessions are stored in ~/ .trinity/share/config/session, so you might clean that directory, too. But first start with a clean session.
Nik
On Wednesday 10 February 2016 02:54:50 Dr. Nikolaus Klepp wrote:
Am Mittwoch, 10. Februar 2016 schrieb Gene Heskett:
On Tuesday 09 February 2016 18:34:28 Lisi Reisz wrote:
On Tuesday 09 February 2016 23:10:08 Gene Heskett wrote:
On Tuesday 09 February 2016 14:36:21 Nick Leverton wrote:
In article 201602091426.58790.gheskett@shentel.net,
Gene Heskett trinity-users@lists.pearsoncomputing.net wrote:
On Tuesday 09 February 2016 13:54:21 Dr. Nikolaus Klepp wrote: [...]
> Hi Gene! > > Last time I used saved sessions to restore my workspace > after login, it worked flawless - but that's been more than > a year ago. But I also rember, I had to use "start with > empty session" temporarily (for one or two reboots) to get > rid of some hikups. > > Nik
And where is that option? I don't recall seeing it when I walked thru it earler today. Are my cataracts getting that bad? :(
In Control centre, it's in TDE Components / Session Manager.
Nick
Found it, was set for restore. Which is good but doesn't remember the workspace the restored stuff was running on.
I note that most of the time, the restored term prompts do show the directory it was sitting in when I restarted it, causing that term & shell to be killed. So its remembering that, but not the workspace.
Is that a bug? Or just hasn't been coded to do yet?
Have you tried Nik's suggestion and turned the restore off for a couple of reboots?
Lisi
No I haven't Lisi. Does it not store a new list of stuff each time as it shuts down when that is checked?
IDK.
Thanks Lisi.
Cheers, Gene Heskett
Hi Gene!
The terminal should be restored on the correct workspace, but sessions are not overwritten, just saved anew. If I recall correctly, the sessions are stored in ~/ .trinity/share/config/session, so you might clean that directory, too. But first start with a clean session.
AKA turn it off, nuke those files in the session directory, restart and reconfigure, turn it back on and restart again.
Nik
looking at those files, I can't see a thing that looks like a workspace # specifier. And they all carry a time stamp from the last restart, and a long hashed from the *nix epoche time" extension to the name. Is there documentation on this someplace the "unwashed" can read it?
And yet, kcalc alone is the only one that always re-opens on the same workspace it was on so I think its possible. I may play with it once I have an eye open simultaneously again.
Cheers, Gene Heskett
On Wednesday 10 February 2016 09:24:41 Gene Heskett wrote:
On Wednesday 10 February 2016 02:54:50 Dr. Nikolaus Klepp wrote:
Am Mittwoch, 10. Februar 2016 schrieb Gene Heskett:
On Tuesday 09 February 2016 18:34:28 Lisi Reisz wrote:
On Tuesday 09 February 2016 23:10:08 Gene Heskett wrote:
On Tuesday 09 February 2016 14:36:21 Nick Leverton wrote:
In article 201602091426.58790.gheskett@shentel.net,
Gene Heskett trinity-users@lists.pearsoncomputing.net wrote: >On Tuesday 09 February 2016 13:54:21 Dr. Nikolaus Klepp > wrote: [...] > >> Hi Gene! >> >> Last time I used saved sessions to restore my workspace >> after login, it worked flawless - but that's been more than >> a year ago. But I also rember, I had to use "start with >> empty session" temporarily (for one or two reboots) to get >> rid of some hikups. >> >> Nik > >And where is that option? I don't recall seeing it when I > walked thru it earler today. Are my cataracts getting that > bad? :(
In Control centre, it's in TDE Components / Session Manager.
Nick
Found it, was set for restore. Which is good but doesn't remember the workspace the restored stuff was running on.
I note that most of the time, the restored term prompts do show the directory it was sitting in when I restarted it, causing that term & shell to be killed. So its remembering that, but not the workspace.
Is that a bug? Or just hasn't been coded to do yet?
Have you tried Nik's suggestion and turned the restore off for a couple of reboots?
Lisi
No I haven't Lisi. Does it not store a new list of stuff each time as it shuts down when that is checked?
IDK.
Thanks Lisi.
Cheers, Gene Heskett
Hi Gene!
The terminal should be restored on the correct workspace, but sessions are not overwritten, just saved anew. If I recall correctly, the sessions are stored in ~/ .trinity/share/config/session, so you might clean that directory, too. But first start with a clean session.
AKA turn it off, nuke those files in the session directory, restart and reconfigure, turn it back on and restart again.
Nik
looking at those files, I can't see a thing that looks like a workspace # specifier. And they all carry a time stamp from the last restart, and a long hashed from the *nix epoche time" extension to the name. Is there documentation on this someplace the "unwashed" can read it?
And yet, kcalc alone is the only one that always re-opens on the same workspace it was on so I think its possible. I may play with it once I have an eye open simultaneously again.
Why not just _try_, just for - I don't know - for heck's sake - doing *exactly* what Nik suggested? You never know, it might work.
<quote> I had to use "start with empty session" temporarily (for one or two reboots) to get rid of some hikups. </quote>
Lisi
Am Mittwoch, 10. Februar 2016 schrieb Lisi Reisz:
Why not just _try_, just for - I don't know - for heck's sake - doing *exactly* what Nik suggested? You never know, it might work.
<quote> I had to use "start with empty session" temporarily (for one or two reboots) to get rid of some hikups. </quote>
Lisi
I'm couriouse: Gene, could you solve the problem?
Nik
On Tuesday 16 February 2016 10:10:54 Dr. Nikolaus Klepp wrote:
Am Mittwoch, 10. Februar 2016 schrieb Lisi Reisz:
Why not just _try_, just for - I don't know - for heck's sake - doing *exactly* what Nik suggested? You never know, it might work.
<quote> I had to use "start with empty session" temporarily (for one or two reboots) to get rid of some hikups. </quote>
Lisi
I'm couriouse: Gene, could you solve the problem?
Nik
Sorry Nik, I haven't tried, been up to my tail in other projects. But I will at some point do exactly that. And let everyone know.
Cheers, Gene Heskett
On Tuesday 16 February 2016 16:53:24 Gene Heskett wrote:
On Tuesday 16 February 2016 10:10:54 Dr. Nikolaus Klepp wrote:
Am Mittwoch, 10. Februar 2016 schrieb Lisi Reisz:
Why not just _try_, just for - I don't know - for heck's sake - doing *exactly* what Nik suggested? You never know, it might work.
<quote> I had to use "start with empty session" temporarily (for one or two reboots) to get rid of some hikups. </quote>
Lisi
I'm couriouse: Gene, could you solve the problem?
Nik
Sorry Nik, I haven't tried, been up to my tail in other projects. But I will at some point do exactly that. And let everyone know.
Cheers, Gene Heskett
Dr Nik;
I had a huge update tonight, 165 packages. So I set it to start with an empty config, and alternately rebooted and edited grub.cfg to get it to use the latest kernel automatically since it has been built with enough stuff I can run the uspace sim version of lcnc with it. That took 4 reboots to get it right, each one a blank screen except for the icons & tde menu's.
Getting that right, I reset it to use a saved config, and sure as God made little green apples, on the next reboot nothing had changed, it was all back, and all piled up on workspace 2, with the 4 tab terminal that lives on workspace 2 in my usual workflow, sitting on top of everything else.
So it appears that accomplished zero effect other than kmail wasn't restarted, everything else was after 4 reboots to an empty config, including kcalc on its correct workspace 3..
Is the a subdir in ~/.trinity or ~/.kde ( those file dates were all old) that I can nuke, to make it resave the config as it exists at logout/reboot?
IOW, What did I do wrong? Should I have been just logging out as opposed to a hot reboot?
And how does one go about "saving" the manually saved session that this menu gives you the option of using. I haven't run across a menu entry to do that. That seems like it should be the real answer, saving the currently running stuff, including the workspace # its running on.
But what do I know?
In the FWIW category, big story about a Glibc vulnerability, released by both Red Hat and Google, a dns exploit that gives the attacker root with one query. Supposedly a year old, but I don't recall seeing anything but an update to the docs for glibc in recent history.
Does anyone know if the wheezy glibc has actually been quietly patched for that exploit or not in the last year?
Thanks.
Cheers, Gene Heskett
Am Mittwoch, 17. Februar 2016 schrieb Gene Heskett:
On Tuesday 16 February 2016 16:53:24 Gene Heskett wrote:
On Tuesday 16 February 2016 10:10:54 Dr. Nikolaus Klepp wrote:
Am Mittwoch, 10. Februar 2016 schrieb Lisi Reisz:
Why not just _try_, just for - I don't know - for heck's sake - doing *exactly* what Nik suggested? You never know, it might work.
<quote> I had to use "start with empty session" temporarily (for one or two reboots) to get rid of some hikups. </quote>
Lisi
I'm couriouse: Gene, could you solve the problem?
Nik
Sorry Nik, I haven't tried, been up to my tail in other projects. But I will at some point do exactly that. And let everyone know.
Cheers, Gene Heskett
Dr Nik;
I had a huge update tonight, 165 packages. So I set it to start with an empty config, and alternately rebooted and edited grub.cfg to get it to use the latest kernel automatically since it has been built with enough stuff I can run the uspace sim version of lcnc with it. That took 4 reboots to get it right, each one a blank screen except for the icons & tde menu's.
Getting that right, I reset it to use a saved config, and sure as God made little green apples, on the next reboot nothing had changed, it was all back, and all piled up on workspace 2, with the 4 tab terminal that lives on workspace 2 in my usual workflow, sitting on top of everything else.
So it appears that accomplished zero effect other than kmail wasn't restarted, everything else was after 4 reboots to an empty config, including kcalc on its correct workspace 3..
Is the a subdir in ~/.trinity or ~/.kde ( those file dates were all old) that I can nuke, to make it resave the config as it exists at logout/reboot?
IOW, What did I do wrong? Should I have been just logging out as opposed to a hot reboot?
And how does one go about "saving" the manually saved session that this menu gives you the option of using. I haven't run across a menu entry to do that. That seems like it should be the real answer, saving the currently running stuff, including the workspace # its running on.
But what do I know?
In the FWIW category, big story about a Glibc vulnerability, released by both Red Hat and Google, a dns exploit that gives the attacker root with one query. Supposedly a year old, but I don't recall seeing anything but an update to the docs for glibc in recent history.
Does anyone know if the wheezy glibc has actually been quietly patched for that exploit or not in the last year?
Thanks.
Cheers, Gene Heskett
Hi Gene!
Ok, then there is something wrong in your ~/.trinity - and I expect it's not that easy to correct by hand.
The easiest fix is probably this:
- log out of TDE - go to a console <ctrl>+<alt>+<f1> - log in as "gene" or what ever user you use - $ mv .trinity .trinity-old - back to X11 - log in - wizard comes up, just walk through it - test session, which I expect to work. - no copy the configs you need from the .trinity-old to .trinity, at least mails.
I know, that's anoying, but it sometimes happens. Maybe silent bitrotting, who knows?
Nik
On Wednesday 17 February 2016 03:43:56 Dr. Nikolaus Klepp wrote:
Am Mittwoch, 17. Februar 2016 schrieb Gene Heskett:
On Tuesday 16 February 2016 16:53:24 Gene Heskett wrote:
On Tuesday 16 February 2016 10:10:54 Dr. Nikolaus Klepp wrote:
Am Mittwoch, 10. Februar 2016 schrieb Lisi Reisz:
Why not just _try_, just for - I don't know - for heck's sake
- doing *exactly* what Nik suggested? You never know, it
might work.
<quote> I had to use "start with empty session" temporarily (for one or two reboots) to get rid of some hikups. </quote>
Lisi
I'm couriouse: Gene, could you solve the problem?
Nik
Sorry Nik, I haven't tried, been up to my tail in other projects. But I will at some point do exactly that. And let everyone know.
Cheers, Gene Heskett
Dr Nik;
I had a huge update tonight, 165 packages. So I set it to start with an empty config, and alternately rebooted and edited grub.cfg to get it to use the latest kernel automatically since it has been built with enough stuff I can run the uspace sim version of lcnc with it. That took 4 reboots to get it right, each one a blank screen except for the icons & tde menu's.
Getting that right, I reset it to use a saved config, and sure as God made little green apples, on the next reboot nothing had changed, it was all back, and all piled up on workspace 2, with the 4 tab terminal that lives on workspace 2 in my usual workflow, sitting on top of everything else.
So it appears that accomplished zero effect other than kmail wasn't restarted, everything else was after 4 reboots to an empty config, including kcalc on its correct workspace 3..
Is the a subdir in ~/.trinity or ~/.kde ( those file dates were all old) that I can nuke, to make it resave the config as it exists at logout/reboot?
IOW, What did I do wrong? Should I have been just logging out as opposed to a hot reboot?
And how does one go about "saving" the manually saved session that this menu gives you the option of using. I haven't run across a menu entry to do that. That seems like it should be the real answer, saving the currently running stuff, including the workspace # its running on.
But what do I know?
In the FWIW category, big story about a Glibc vulnerability, released by both Red Hat and Google, a dns exploit that gives the attacker root with one query. Supposedly a year old, but I don't recall seeing anything but an update to the docs for glibc in recent history.
Does anyone know if the wheezy glibc has actually been quietly patched for that exploit or not in the last year?
Thanks.
Cheers, Gene Heskett
Hi Gene!
Ok, then there is something wrong in your ~/.trinity - and I expect it's not that easy to correct by hand.
The easiest fix is probably this:
- log out of TDE
- go to a console <ctrl>+<alt>+<f1>
- log in as "gene" or what ever user you use
- $ mv .trinity .trinity-old
- back to X11
- log in
- wizard comes up, just walk through it
- test session, which I expect to work.
- no copy the configs you need from the .trinity-old to .trinity, at
least mails.
I know, that's anoying, but it sometimes happens. Maybe silent bitrotting, who knows?
Nik
I did an ls -lR in ~./.trinity, and saw that I own everything, and that several files were updated last night, but nothing that looks like a usual suspect. Only 4 files in the session directory
So next time I am in need of a reboot, I'll do that. Thanks Nik.
Cheers, Gene Heskett
In article 201602162114.58407.gheskett@shentel.net, Gene Heskett trinity-users@lists.pearsoncomputing.net wrote:
And how does one go about "saving" the manually saved session that this menu gives you the option of using. I haven't run across a menu entry to do that. That seems like it should be the real answer, saving the currently running stuff, including the workspace # its running on.
I can answer this bit at least. On the K menu (I suppose I should call it the "T" menu :-)) there will be a "save session" entry, when the "use manually saved session" option is chosen in Control Panel.
Nick
On Thursday 18 February 2016 02:50:13 Nick Leverton wrote:
In article 201602162114.58407.gheskett@shentel.net,
Gene Heskett trinity-users@lists.pearsoncomputing.net wrote:
And how does one go about "saving" the manually saved session that this menu gives you the option of using. I haven't run across a menu entry to do that. That seems like it should be the real answer, saving the currently running stuff, including the workspace # its running on.
I can answer this bit at least. On the K menu (I suppose I should call it the "T" menu :-)) there will be a "save session" entry, when the "use manually saved session" option is chosen in Control Panel.
Nope, Nick, selection of the "use manually saved session", does not generate a "save session" option to select. Thats why I asked where it was in the first place. I have now checked that option and will note if that choice is presented when I next logout.
Here, the session manager's help screen shows:
Jost Schenck Revision 3.2 (2003-10-13)
Which sure seems to indicate a rather profound lack of interest in fixing such "problems" if it hasn't been updated in 13 years... WTH? Does that not predate the tde fork by a decade at least?
Somebody elses turn. :)
Nick
Thanks Nick.
Cheers, Gene Heskett
In article 201602100424.41617.gheskett@shentel.net, Gene Heskett trinity-users@lists.pearsoncomputing.net wrote:
On Wednesday 10 February 2016 02:54:50 Dr. Nikolaus Klepp wrote:
The terminal should be restored on the correct workspace, but sessions are not overwritten, just saved anew. If I recall correctly, the sessions are stored in ~/ .trinity/share/config/session, so you might clean that directory, too. But first start with a clean session.
looking at those files, I can't see a thing that looks like a workspace # specifier. And they all carry a time stamp from the last restart, and a long hashed from the *nix epoche time" extension to the name. Is there documentation on this someplace the "unwashed" can read it?
And yet, kcalc alone is the only one that always re-opens on the same workspace it was on so I think its possible. I may play with it once I have an eye open simultaneously again.
Please excuse me asking: by Workspace, do you mean the numbered desktops on Ctrl-1 Ctrl-2 etc, or is there some other TDE feature that I've missed ? Assuming the former, the desktop number for each window seems to be stored in the session entry for twin, not that for the program itself.
I don't know of any documentation for the feature, but I use "manually saved" session option and things always restart on the right desktop.
In the distant past, relying on logout to save session didn't always work for me, or else would restore session once but then not again. But that was way back in KDE3 days, and I've just stuck with the easy option.
Nick
On Wednesday 10 February 2016 18:18:33 Nick Leverton wrote:
In article 201602100424.41617.gheskett@shentel.net,
Gene Heskett trinity-users@lists.pearsoncomputing.net wrote:
On Wednesday 10 February 2016 02:54:50 Dr. Nikolaus Klepp wrote:
The terminal should be restored on the correct workspace, but sessions are not overwritten, just saved anew. If I recall correctly, the sessions are stored in ~/ .trinity/share/config/session, so you might clean that directory, too. But first start with a clean session.
looking at those files, I can't see a thing that looks like a workspace # specifier. And they all carry a time stamp from the last restart, and a long hashed from the *nix epoche time" extension to the name. Is there documentation on this someplace the "unwashed" can read it?
And yet, kcalc alone is the only one that always re-opens on the same workspace it was on so I think its possible. I may play with it once I have an eye open simultaneously again.
Please excuse me asking: by Workspace, do you mean the numbered desktops on Ctrl-1 Ctrl-2 etc, or is there some other TDE feature that I've missed ? Assuming the former, the desktop number for each window seems to be stored in the session entry for twin, not that for the program itself.
I don't know of any documentation for the feature, but I use "manually saved" session option and things always restart on the right desktop.
In the distant past, relying on logout to save session didn't always work for me, or else would restore session once but then not again. But that was way back in KDE3 days, and I've just stuck with the easy option.
Nick
Well, unless froggy's magic twanger has been plucked, most of the r14.0.0.3 code base is still kde3.5. So unless someone has addressed it since the fork, that particular speed bump is probably still there.
As for workspace 3 that I referred to, I have 10 such 'screens', and I usually have at least 4 of them with open terminals with multiple tabs on them. On workspace1 for instance, a 5 tab terminal runs, with tab 0 being used for a root copy of htop, with which I can find and destroy a runaway process. Tab 1 has a root tail -fn300 on /var/log/messages. Tab 2 is running in my home dir, and has a tail -fn50 log/fetchmail.log so I can sorta keep track of my network connection etc. Tab 3 ATM, has a tail -fn50 log/procmail.log but as long as procmail behaves itself, that can be shut down. I played with some of the procmail recipe's last evening, so I've been tracking how that is working.
Next workspace has a 4 tab terminal running on it, with ssh -Y sessions live to each of my CNC machines scattered about the Ranchette. Theres 2 more workspaces with terminals running on them, for whatever. I normally run iceweasel on workspace 9, and kmail on workspace 10.
The whatever category might be gaf, or pcb, or even qucs depending on what I'm attempting to do ATM.
Boring isn't it. :(
Cheers, Gene Heskett
In article 201602102119.32759.gheskett@shentel.net, Gene Heskett trinity-users@lists.pearsoncomputing.net wrote:
On Wednesday 10 February 2016 18:18:33 Nick Leverton wrote:
In the distant past, relying on logout to save session didn't always work for me, or else would restore session once but then not again. But that was way back in KDE3 days, and I've just stuck with the easy option.
Nick
Well, unless froggy's magic twanger has been plucked, most of the r14.0.0.3 code base is still kde3.5. So unless someone has addressed it since the fork, that particular speed bump is probably still there.
I should apologise, I didn't mean to suggest that there is a bug there nowadays. Like many of us I just established a way of working many years ago and have been reluctant to change something that works !
Nick
On Friday 12 February 2016 13:24:25 Nick Leverton wrote:
I should apologise, I didn't mean to suggest that there is a bug there nowadays. Like many of us I just established a way of working many years ago and have been reluctant to change something that works !
That was how I read you, Nick. :-)
Some years ago when I was helping my granddaughter do her homework, she asked me how to do something. I didn't actually know. But I looked at it, worked out how I would achieve what she wanted, and showed her. She completed her homework. The next day, I looked up how to do whatever it was. There was a MUCH better way of doing it - both quicker and easier than the (admittedly successful) bodge I had showed her. So I said to her: "Look , there is this much better way of doing it." She refused to change. "No, this is how I do it."
And you have been doing it your way for years!!
Lisi
On Friday 12 February 2016 08:24:25 Nick Leverton wrote:
In article 201602102119.32759.gheskett@shentel.net,
Gene Heskett trinity-users@lists.pearsoncomputing.net wrote:
On Wednesday 10 February 2016 18:18:33 Nick Leverton wrote:
In the distant past, relying on logout to save session didn't always work for me, or else would restore session once but then not again. But that was way back in KDE3 days, and I've just stuck with the easy option.
Nick
Well, unless froggy's magic twanger has been plucked, most of the r14.0.0.3 code base is still kde3.5. So unless someone has addressed it since the fork, that particular speed bump is probably still there.
I should apologise, I didn't mean to suggest that there is a bug there nowadays. Like many of us I just established a way of working many years ago and have been reluctant to change something that works !
Nick
We are ALL creatures of habit. And at 81, I've had about as long as anyone on the 'net to "develop" them. :) But we now have 3 generations that have no clue what "froggies magic twanger" even was. That tv program for kids dates back to about '48 or '49, and I was already fixing those first tv's for smoke money by then. Its been quite a ride.
In '50, seeing what we do today reminds of an Art Clark saying, That any sufficiently advanced technology is indestinguishable from magic.
But now we write bash scripts and make our own magic spells. They do the repetitive, boring stuff in the background here, so all I have left to is tap the + key to read the next message, reply if I can help, and hit the + key till there are no more messages to read. ALL the time killers that freeze up kmail while one is in the middle of typing a reply have been offloaded to background utilities, some of which I wrote. Fetchmail/procmail/clamd/spamd take care of pulling the mail and filtering it, but they don't have a mechanism to tell kmail there is new mail in /var/spool/mail when they are done, so I wrote a bash thing that uses inotifywait to detect that, and it sends kmail the "get the mail" command when a new messsage has arrived, tying it all together.
Such convenience is making me lazy in my dotage. ;-)
Cheers, Gene Heskett
-
Dr. Nikolaus Klepp -
Gene Heskett -
Lisi Reisz -
Nick Leverton