On 7/6/18, Thierry Rascle <thier...@free.fr> wrote: > On Fri, 6 Jul 2018 07:33:16 +0100 > Joe <j...@jretrading.com> wrote: > >> On Fri, 6 Jul 2018 07:58:41 +0200 >> Thierry Rascle <thier...@free.fr> wrote: >> >> > Hi, >> > >> > I'm using Debian Sid. Gimp does not seem to work any more (the user >> > interface does not show up). I've tried in Xmonad and in Openbox. >> > >> > I have no idea what causes this. I don't see any error message. >> > >> > Does anyone else have the same problem ? >> > >> > Thanks! >> > >> > Thierry >> > >> >> No. 2.10 behaves differently, and I find the toolbox much harder to >> use, as I only use GIMP occasionally, but it's working. My sid is up >> to date, but of course will be very different from your sid. >> > > Yes, I noticed that the toolbox has changed with 2.10 two months ago. > There was also a new issue with the gimp-ufraw plugin, forcing the user > to use the standalone ufraw application instead. But Gimp was usable. > > Now it is totally unusable for me. A 'ps -ef' shows a gimp process > running but I don't see any windows in any workspace. A 'xwininfo -tree > -root' does not list any Gimp windows. Launching Gimp from a terminal > does not give any error message.
A half-baked memory is coming back about Thunar giving me ghost instances in unstable or Sid, I don't remember which.. I can't quite remember, but it was something about Thunar wasn't being properly shut down when I rebooted. Yeah, I know, I don't know if Thunar was still open when I rebooted or if it wasn't completely shutting down and then the reboot still didn't finish the shut down process on top of that. I think I learned that because Thunar wasn't coming coming up for me in a similar way as is being described here about GIMP. However it was happening is why there was a "ghost" lingering in the background *for me*. I never got around to reporting a bug, and it eventually resolved itself via some one or another upgrades back then (maybe a couple years ago?). With respect to dealing with that ghost, I have two things I do in these kinds of instances. The first one I do is kill that ghost instance then relaunch the problem program from within a terminal window. Sometimes you get lucky and see a bunch of error messages that can possibly help solve the problem. The second thing I do... out of exasperation... is purge the problem program THEN secondarily ALSO PURGE all the various dependency packages. Apt-get is very neighborly about presenting that dependency list when a user is trying to upgrade or install just after having purged a primary package. There's also a remove option instead of purge that may be more appropriate. I just like the sound of *PURGE IT!* and have never had any problems going that route. :) The reason I purge instead of "install --reinstall" is because "install --reinstall" *ONLY* reinstalls the specifically named package, i.e. *no dependencies*. There may be an option that triggers the reinstallation of dependencies, too, but I've never encountered it (yet). I just went into "man apt-get" for a second. That reminded me that users sometimes have good luck simply deleting existing config files and NOT the whole program. Those config files are the kind found in our /home directories unless we've defined them to set up some place else. They're sometimes (often?) only visible if we toggle CTRL+H on and off in our favorite file managers. If that seems like a friendly option, I'd make a backup copy of the files I intend to delete just in case that doesn't work/turns out to be a wasted effort. Moving those out of the way while simultaneously making a backup is as simple as renaming the file or entire folder. We can call them anything we want, but I tend to like to rename mine with the date last used as a point of reference. One of the things I've learned while deliberately pushing my copies to the limit here is that there can be upgrade/downgrade(/crossgrade) incompatibility problems with those config files. I learned that while working through problems with the Opera-Beta browser. Once the config file(s) became "contaminated" with new features while older features started falling by the wayside, that's when I first started seeing the problems AND then tied OTHER problems to how config files MIGHT cause our programs' success and failures over a very extended period of time... Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with duct tape *
