Re: strange bug in RH9 qt lyx1.3.3
On Monday 27 October 2003 18:47, Jerome Schretter wrote: I don't have any solution to your specific problem. All I can say is that I had a similar problem with klipper on a RH7.3 system distribution and with lyx1.3.1 running under KDE. Me too. That is one of the reasons why I have klipper disabled most of the time, sometime it tries to do some fancy stuff with the selection and it consumes lots of cpu. [...] cheers, JS -- José Abílio LyX and docbook, a perfect match. :-)
Re: strange bug in RH9 qt lyx1.3.3
On Monday 27 October 2003 18:47, Jerome Schretter wrote: I don't have any solution to your specific problem. All I can say is that I had a similar problem with klipper on a RH7.3 system distribution and with lyx1.3.1 running under KDE. Me too. That is one of the reasons why I have klipper disabled most of the time, sometime it tries to do some fancy stuff with the selection and it consumes lots of cpu. [...] cheers, JS -- José Abílio LyX and docbook, a perfect match. :-)
Re: strange bug in RH9 qt lyx1.3.3
On Monday 27 October 2003 18:47, Jerome Schretter wrote: > I don't have any solution to your specific problem. All I can say is > that I had a similar problem with klipper on a RH7.3 system distribution > and with lyx1.3.1 running under KDE. Me too. That is one of the reasons why I have klipper disabled most of the time, sometime it tries to do some fancy stuff with the selection and it consumes lots of cpu. [...] > cheers, > JS -- José Abílio LyX and docbook, a perfect match. :-)
strange bug in RH9 qt lyx1.3.3
Hello list, Here is a behavior that I have seen ever since I installed lyx for the first time a few months ago, version 1.3.2 but it did not really bother me. But now it's starting to get on my nerves so here it is. I am working in version 1.3.3 RH9 qt. Sometimes, when I select text in lyx, like for example I select a couple of lines to make them bold or italic or something, something strange happens and I seem to lose contact with the red hat task bar at the bottom of the screen. For example if I am running xmms but it's minimized then there is a little xmms button at the bottom. Problem is that if I click on that button to maximize xmms it takes like 5 minutes for that to happen. It eventually happens, but after quite a while. Then, after it opens (which it does all of a sudden), I can do anything INSIDE the window, like change the volume, add songs, whatever, and it responds just fine. No delay. Then I minimize it again, and it does it right away. If I try to remaximize it it takes 5 minutes again. Same with like a konsole or any other program, like kmail or mozilla or gftp. If it's minimized it takes 5 minutes to maximize it, then, I can work inside of it without a problem, and minimize it without a problem. During the dead time it seems to access the hard disk every couple of seconds or so, so it's not like it's busy working on something like updating the rpm database or something. If I want to open the start menu, again it takes 5 minutes. But if I move the mouse over the desktop it does turn into a little pointing hand when I hover over files or folders. So it seems that this bug is very specific to a certain part of the graphical interface, the task bar. This does not happen EVERY time I select text in lyx, but it ONLY happens when I have selected some text, and done like copy paste, or just changed the font type or something. Before, this used to happen for like a couple of minutes and then all the stuff I had clicked on would happen all at once. But this time I lost an hour and a half a cause de ces conneries. Oh, also, during the time it's quasi-frozen the clock on the task bar is not updated at all, so I can see exactly when it froze, and how much time I wasted. If anybody has ever seen this kind of behavior before, or if anybody has any clue what this is all about, I would appreciate a helping hand. This is exactly the kind of stuff I do not expect to see happening in Linux. Alex.
Re: strange bug in RH9 qt lyx1.3.3
I don't have any solution to your specific problem. All I can say is that I had a similar problem with klipper on a RH7.3 system distribution and with lyx1.3.1 running under KDE. After selecting text in lyx and clicking on the klipper icon in the taskbar, it took a while for klipper to pop-up the menu. Depending on the amount of text selected: the more text I selected, the longer it took klipper to display the menu. Some other persons reported no problem under similar conditions on an updated system (i.e. rh7.3 + some patches). I thought it was klipper's fault which may have been lost because of lyx's treatment of text. That's only a very wild guess as I don't know much of lyx's internal text handling. A bug in the taskbar or another part of your desktop can't be ruled out. May be you could try to find a way to reproduce the bug. From your description, one doesn't know what desktop you're using. Maybe you can provide more detailed information. cheers, JS Am Mon, 2003-10-27 um 14.19 schrieb Cabuz Alexandru: Hello list, Here is a behavior that I have seen ever since I installed lyx for the first time a few months ago, version 1.3.2 but it did not really bother me. But now it's starting to get on my nerves so here it is. I am working in version 1.3.3 RH9 qt. Sometimes, when I select text in lyx, like for example I select a couple of lines to make them bold or italic or something, something strange happens and I seem to lose contact with the red hat task bar at the bottom of the screen. For example if I am running xmms but it's minimized then there is a little xmms button at the bottom. Problem is that if I click on that button to maximize xmms it takes like 5 minutes for that to happen. It eventually happens, but after quite a while. Then, after it opens (which it does all of a sudden), I can do anything INSIDE the window, like change the volume, add songs, whatever, and it responds just fine. No delay. Then I minimize it again, and it does it right away. If I try to remaximize it it takes 5 minutes again. Same with like a konsole or any other program, like kmail or mozilla or gftp. If it's minimized it takes 5 minutes to maximize it, then, I can work inside of it without a problem, and minimize it without a problem. During the dead time it seems to access the hard disk every couple of seconds or so, so it's not like it's busy working on something like updating the rpm database or something. If I want to open the start menu, again it takes 5 minutes. But if I move the mouse over the desktop it does turn into a little pointing hand when I hover over files or folders. So it seems that this bug is very specific to a certain part of the graphical interface, the task bar. This does not happen EVERY time I select text in lyx, but it ONLY happens when I have selected some text, and done like copy paste, or just changed the font type or something. Before, this used to happen for like a couple of minutes and then all the stuff I had clicked on would happen all at once. But this time I lost an hour and a half a cause de ces conneries. Oh, also, during the time it's quasi-frozen the clock on the task bar is not updated at all, so I can see exactly when it froze, and how much time I wasted. If anybody has ever seen this kind of behavior before, or if anybody has any clue what this is all about, I would appreciate a helping hand. This is exactly the kind of stuff I do not expect to see happening in Linux. Alex.
strange bug in RH9 qt lyx1.3.3
Hello list, Here is a behavior that I have seen ever since I installed lyx for the first time a few months ago, version 1.3.2 but it did not really bother me. But now it's starting to get on my nerves so here it is. I am working in version 1.3.3 RH9 qt. Sometimes, when I select text in lyx, like for example I select a couple of lines to make them bold or italic or something, something strange happens and I seem to lose contact with the red hat task bar at the bottom of the screen. For example if I am running xmms but it's minimized then there is a little xmms button at the bottom. Problem is that if I click on that button to maximize xmms it takes like 5 minutes for that to happen. It eventually happens, but after quite a while. Then, after it opens (which it does all of a sudden), I can do anything INSIDE the window, like change the volume, add songs, whatever, and it responds just fine. No delay. Then I minimize it again, and it does it right away. If I try to remaximize it it takes 5 minutes again. Same with like a konsole or any other program, like kmail or mozilla or gftp. If it's minimized it takes 5 minutes to maximize it, then, I can work inside of it without a problem, and minimize it without a problem. During the dead time it seems to access the hard disk every couple of seconds or so, so it's not like it's busy working on something like updating the rpm database or something. If I want to open the start menu, again it takes 5 minutes. But if I move the mouse over the desktop it does turn into a little pointing hand when I hover over files or folders. So it seems that this bug is very specific to a certain part of the graphical interface, the task bar. This does not happen EVERY time I select text in lyx, but it ONLY happens when I have selected some text, and done like copy paste, or just changed the font type or something. Before, this used to happen for like a couple of minutes and then all the stuff I had clicked on would happen all at once. But this time I lost an hour and a half a cause de ces conneries. Oh, also, during the time it's quasi-frozen the clock on the task bar is not updated at all, so I can see exactly when it froze, and how much time I wasted. If anybody has ever seen this kind of behavior before, or if anybody has any clue what this is all about, I would appreciate a helping hand. This is exactly the kind of stuff I do not expect to see happening in Linux. Alex.
Re: strange bug in RH9 qt lyx1.3.3
I don't have any solution to your specific problem. All I can say is that I had a similar problem with klipper on a RH7.3 system distribution and with lyx1.3.1 running under KDE. After selecting text in lyx and clicking on the klipper icon in the taskbar, it took a while for klipper to pop-up the menu. Depending on the amount of text selected: the more text I selected, the longer it took klipper to display the menu. Some other persons reported no problem under similar conditions on an updated system (i.e. rh7.3 + some patches). I thought it was klipper's fault which may have been lost because of lyx's treatment of text. That's only a very wild guess as I don't know much of lyx's internal text handling. A bug in the taskbar or another part of your desktop can't be ruled out. May be you could try to find a way to reproduce the bug. From your description, one doesn't know what desktop you're using. Maybe you can provide more detailed information. cheers, JS Am Mon, 2003-10-27 um 14.19 schrieb Cabuz Alexandru: Hello list, Here is a behavior that I have seen ever since I installed lyx for the first time a few months ago, version 1.3.2 but it did not really bother me. But now it's starting to get on my nerves so here it is. I am working in version 1.3.3 RH9 qt. Sometimes, when I select text in lyx, like for example I select a couple of lines to make them bold or italic or something, something strange happens and I seem to lose contact with the red hat task bar at the bottom of the screen. For example if I am running xmms but it's minimized then there is a little xmms button at the bottom. Problem is that if I click on that button to maximize xmms it takes like 5 minutes for that to happen. It eventually happens, but after quite a while. Then, after it opens (which it does all of a sudden), I can do anything INSIDE the window, like change the volume, add songs, whatever, and it responds just fine. No delay. Then I minimize it again, and it does it right away. If I try to remaximize it it takes 5 minutes again. Same with like a konsole or any other program, like kmail or mozilla or gftp. If it's minimized it takes 5 minutes to maximize it, then, I can work inside of it without a problem, and minimize it without a problem. During the dead time it seems to access the hard disk every couple of seconds or so, so it's not like it's busy working on something like updating the rpm database or something. If I want to open the start menu, again it takes 5 minutes. But if I move the mouse over the desktop it does turn into a little pointing hand when I hover over files or folders. So it seems that this bug is very specific to a certain part of the graphical interface, the task bar. This does not happen EVERY time I select text in lyx, but it ONLY happens when I have selected some text, and done like copy paste, or just changed the font type or something. Before, this used to happen for like a couple of minutes and then all the stuff I had clicked on would happen all at once. But this time I lost an hour and a half a cause de ces conneries. Oh, also, during the time it's quasi-frozen the clock on the task bar is not updated at all, so I can see exactly when it froze, and how much time I wasted. If anybody has ever seen this kind of behavior before, or if anybody has any clue what this is all about, I would appreciate a helping hand. This is exactly the kind of stuff I do not expect to see happening in Linux. Alex.
strange bug in RH9 qt lyx1.3.3
Hello list, Here is a behavior that I have seen ever since I installed lyx for the first time a few months ago, version 1.3.2 but it did not really bother me. But now it's starting to get on my nerves so here it is. I am working in version 1.3.3 RH9 qt. Sometimes, when I select text in lyx, like for example I select a couple of lines to make them bold or italic or something, something strange happens and I seem to lose contact with the red hat task bar at the bottom of the screen. For example if I am running xmms but it's minimized then there is a little xmms button at the bottom. Problem is that if I click on that button to maximize xmms it takes like 5 minutes for that to happen. It eventually happens, but after quite a while. Then, after it opens (which it does all of a sudden), I can do anything INSIDE the window, like change the volume, add songs, whatever, and it responds just fine. No delay. Then I minimize it again, and it does it right away. If I try to remaximize it it takes 5 minutes again. Same with like a konsole or any other program, like kmail or mozilla or gftp. If it's minimized it takes 5 minutes to maximize it, then, I can work inside of it without a problem, and minimize it without a problem. During the dead time it seems to access the hard disk every couple of seconds or so, so it's not like it's busy working on something like updating the rpm database or something. If I want to open the start menu, again it takes 5 minutes. But if I move the mouse over the desktop it does turn into a little pointing hand when I hover over files or folders. So it seems that this bug is very specific to a certain part of the graphical interface, the task bar. This does not happen EVERY time I select text in lyx, but it ONLY happens when I have selected some text, and done like copy paste, or just changed the font type or something. Before, this used to happen for like a couple of minutes and then all the stuff I had clicked on would happen all at once. But this time I lost an hour and a half a cause de ces conneries. Oh, also, during the time it's "quasi-frozen" the clock on the task bar is not updated at all, so I can see exactly when it froze, and how much time I wasted. If anybody has ever seen this kind of behavior before, or if anybody has any clue what this is all about, I would appreciate a helping hand. This is exactly the kind of stuff I do not expect to see happening in Linux. Alex.
Re: strange bug in RH9 qt lyx1.3.3
I don't have any solution to your specific problem. All I can say is that I had a similar problem with klipper on a RH7.3 system distribution and with lyx1.3.1 running under KDE. After selecting text in lyx and clicking on the klipper icon in the taskbar, it took a while for klipper to pop-up the menu. Depending on the amount of text selected: the more text I selected, the longer it took klipper to display the menu. Some other persons reported no problem under similar conditions on an updated system (i.e. rh7.3 + "some" patches). I thought it was klipper's fault which may have been lost because of lyx's treatment of text. That's only a very wild guess as I don't know much of lyx's internal text handling. A bug in the taskbar or another part of your desktop can't be ruled out. May be you could try to find a way to reproduce the bug. >From your description, one doesn't know what desktop you're using. Maybe you can provide more detailed information. cheers, JS Am Mon, 2003-10-27 um 14.19 schrieb Cabuz Alexandru: > Hello list, > > Here is a behavior that I have seen ever since I installed lyx for the first > time a few months ago, version 1.3.2 but it did not really bother me. But now > it's starting to get on my nerves so here it is. > > I am working in version 1.3.3 RH9 qt. > > Sometimes, when I select text in lyx, like for example I select a couple of > lines to make them bold or italic or something, something strange happens and > I seem to lose contact with the red hat task bar at the bottom of the screen. > For example if I am running xmms but it's minimized then there is a little > xmms button at the bottom. Problem is that if I click on that button to > maximize xmms it takes like 5 minutes for that to happen. It eventually > happens, but after quite a while. Then, after it opens (which it does all of > a sudden), I can do anything INSIDE the window, like change the volume, add > songs, whatever, and it responds just fine. No delay. Then I minimize it > again, and it does it right away. If I try to remaximize it it takes 5 > minutes again. > Same with like a konsole or any other program, like kmail or mozilla or gftp. > If it's minimized it takes 5 minutes to maximize it, then, I can work inside > of it without a problem, and minimize it without a problem. During the dead > time it seems to access the hard disk every couple of seconds or so, so it's > not like it's busy working on something like updating the rpm database or > something. > > If I want to open the start menu, again it takes 5 minutes. > > But if I move the mouse over the desktop it does turn into a little pointing > hand when I hover over files or folders. > > So it seems that this bug is very specific to a certain part of the graphical > interface, the task bar. > > This does not happen EVERY time I select text in lyx, but it ONLY happens when > I have selected some text, and done like copy paste, or just changed the font > type or something. > > Before, this used to happen for like a couple of minutes and then all the > stuff I had clicked on would happen all at once. But this time I lost an hour > and a half a cause de ces conneries. > > Oh, also, during the time it's "quasi-frozen" the clock on the task bar is not > updated at all, so I can see exactly when it froze, and how much time I > wasted. > > If anybody has ever seen this kind of behavior before, or if anybody has any > clue what this is all about, I would appreciate a helping hand. This is > exactly the kind of stuff I do not expect to see happening in Linux. > > Alex.
