Re: [hpoj-devel] xojpanel

[<pa...@rc...>]

Hi, Joe.

Joe Piolunek wrote:
> Lately the line number reported in the error message has been 263, but that 
> doesn't matter very much now. I'm reasonably certain I found what was causing 
> the problem. In /var/log/messages the OfficeJet is reported as being on an 
> EPP port rather than an ECP, which I thought it was. After I removed the 
> ieee12844pp module and reinserted it with the usenibble=1 option, xojpanel 
> starts every time. I wrote a shell script that would repeatedly start and 
> then kill xojpanel 6 seconds later. It's been through 1000 startups so far 
> without any failures. Previously, one try in 15 starts would fail (rough 
> average).
> I'll see what happens after I change the port type to ECP on the IO card the 
> OfficeJet is connected to. 
That would be interesting to try.  The bidirectional ECP patch causes the
parallel port to be used in different ways compared to before (or when using
usenibble=1).  Is your second parallel port software-configurable, or do you
have to change jumpers?  If you can't get it working on that port, then
perhaps you could try swapping ports.

> The patch installed ok, but it gave two error messages:
> patch unexpectedly ends in middle of line
> patch unexpectedly ends in middle of line
> 
> xojpanel compiles runs fine with the patch.
That's strange.  Did you tell your mail client to save the attachment to a
file, or did you copy and paste (which could cause a problem)?  I just
looked at a hex dump of the patch file as I sent it out, and there is a
newline at the end of the file, which is what it could be complaining about.
Did you double-check the code to make sure it applied the patch correctly?

> Early in development, the printer poll timer controlled scroll speed as well, 
> so to cut down on unnecessary console output during testing, I set it as high 
> as 3000ms (if I remember correctly). Now that the timers are separate, that 
> reason is gone. The poll timer can be set lower than 1000ms. Are there any 
> network delay issues to consider in setting the timer? For instance, if an 
> lcd message is changing in the printer, but it's being polled too often, the 
> wrong message might get to xojpanel first. Could this happen?
Occasionally when I was scrolling through the menus, it looked like it
updated the two lines in separate polls, which might indicate a race
condition with the peripheral where it was in the middle of updating the LCD
as you suggest.  However, it doesn't seem to be a big problem.  My concern
would be more about what happens if the timer pops again before it's done
servicing the previous poll.  I think the most optimal behavior would be
that it ignores timer pops when it's still servicing a previous timer pop.
A less optimal option would be for it to just queue up poll requests.  I
think it would be pretty undesirable for it to initiate another set of PML
transactions before it was done with the last set.

> Overhead doesn't seem to be a big problem with xojpanel. It seems to use a 
> lot of memory, but little processor time.
I guess one should expect a fair amount of memory overhead from a GUI
toolkit such as QT, but it's surprising that it uses more RAM than kwm.
I would suggest checking all the places where you use "new" to make sure
that either there's a corresponding "delete" or there doesn't need to be
one.  I grepped for those strings (with a space after them) and there was
at least one more new than delete of QString.  Of course I doubt this would
add a significant amount of overhead, and at least the memory usage doesn't
appear to grow over time (at least not in the last 15 minutes or so).

> top -p says that most of the time 
> its CPU usage is 0.0%. The timer is set at 500ms for now, though.
OK, that sounds reasonable.

> I'll put a copyright notice in, with credit for anyone who contributed to the 
> remaining parts of the original xojpanel, if the contributors can be 
> identified. If not, I'll give generic credit. It might be important to know 
> the origin of the name 'xojpanel'. Andreas' response should be helpful. 
>
> Hopefully, the copyright issue will be solved soon, so waiting a day or so 
> before committing the new xojpanel code to CVS will probably make one patch 
> unnecessary. 
> 
> Handle the changelog whichever way you think is best.
> 
> You won't need .directory for anything. I probably should have deleted that. 
> lcd.bmp is no longer used or even very usable, due to a size difference. You 
> can leave both of them out.
> 
> A KDE user could copy xojpanel.kdelnk to his/her desktop for a quick way to 
> start the app. Many users may prefer to create their own launchers, but some 
> don't know how, or don't want to go to the trouble. The addition of a GNOME 
> launcher might be nice later on. I have only an older version of GNOME and 
> haven't used it in a while, so I wasn't that interested in making one right 
> away.

OK, so I will go ahead and start making the changes to support the
compile-time pixmap path, but I'll wait for your go-ahead to commit it all
into CVS.  I will take out the changelog file (but reflect it in the checkin
comments) and remove .directory.  I will include xojpanel.kdelnk in the
package but probably won't install it anywhere.

David