Re: [hpoj-devel] xojpanel replacement

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

Hi, Joe.

Joe Piolunek wrote:
> I was trying to create a compromise between an app for the home user and one 
> for an enterprise printer administrator, but since I don't have a very good 
> understanding of what the administrator would need, I think I compromised too 
> much in the wrong direction.
One important thing to keep in mind for the "enterprise printer administrator"
is to make sure it's easy to keep track of a possibly large number of
different devices.  Of course, this principle would also apply for the sake
of users who happened to have access to multiple devices, particularly when
they are connected to a LAN with HP JetDirect print servers, rather than to
a single PC, as would be typical for most "home" users.  (I can certainly
appreciate the concerns of the multi-device user, since I've managed to
gather up quite a collection of HP all-in-ones over the last year or so
that I've been working on this project.:-)

> The Qt designer can be used to create/modify windows very quickly, but since 
> it's designed to work with qt-2.xx , we will have to work around that if we 
> want to continue supporting qt-1.xx . What the designer does is output *.xml 
> files which have *.cpp and *.h files generated from them by the uic utility. 
> If that code contains lines that are incompatible with earlier qt versions, 
> they usually can be commented out or wrapped in '#ifdef HAVE_QT_2' or some 
> such. Hand-modifying generated code only works if you don't plan to 
> regenerate it, of course. After the generated files have been hand-modified, 
> they will always need to be hand-modified. My plan is to keep the generated 
> classes simple and add functionality by hand to an implementation class which 
> is 'cloned' from its uic-generated base class. Subclassing is the system 
> recommended by Trolltech when using the designer.
Sounds good to me.  I would agree that it's a good idea to avoid hand
modifications.  Although it would be nice to support as wide a range of QT
versions as possible, I think it will be acceptable to discontinue support
for 1.x as long as all 2.x versions work.

> To avoid unnecessary name/title changes in the code, filenames, etc., I'd 
> like to have them set as soon as they are decided upon -  
> 
> What would you like the binary to be called? It looks like you may be 
> considering 'xhpcontrol'.
I think I came up with that name on-the-fly while I was writing that message.
It's more generic than "xojpanel", but it still conveys the notion that it's
an X-Windows control-panel application for HP peripherals (not necessarily
just all-in-ones).  I discarded my first idea "xhppanel", where I just
replaced "oj" with "hp", because I didn't think it looked good to have the
two "p"s right next to each other.  Of course, other suggestions would be
welcome also.

> Class names for an entire project often have a prefix to distinguish them 
> from classes taken from another project. If one is used, would 'HPC' be 
> acceptable as a prefix for the project's classes? An example would be 
> "HPCMainWindow_Impl::"
I think that would be OK.  On the other hand, all those capital letters
together might seem a bit overwhelming and cause the first letter of the
next word ("Main" in your example) to get lost in the noise.  "Hpc" as a
class name prefix ("HpcMainWindow...") might be a little more readable.

> What would you like for the main window's title?
Either "xhpcontrol" or "HP Control Panel" would be fine for now.  It shouldn't
be too hard to change a window title later, should it?

> What user are you primarily aiming at (developer, printer admin, etc.),
(D) All of the above.  :-)

But seriously, the idea is to give the user access to all of the
PML-accessible device status and control features that are provided by the
bundled Windows software, which is especially important for the OfficeJet
500/600 series, which don't have device-based menus that let you change the
settings without PC assistance.  Even for models that do work standalone, it
would be nice to have this ability, if for no other reason than because we
can.

So to answer your question, I think it would best be targeted to both a user
as well as an administrator.  I suppose there wouldn't actually be much in it
for developers such as ourselves, other than possibly a tab or whatever at
the end to play around with raw PML, but that could just as easily be done
in a separate command-line utility.

> and 
> how many device names would normally be in that user's list? What might the 
> maximum number be?
If possible I would prefer to avoid setting an arbitrary maximum count for
things like this (think linked lists, not arrays), but if it absolutely has
to be done this way, then it should be a large number (say, 100) that is
#defined in one place so it can be changed easily if necessary.

> What would the device names look like?
Currently the PTAL device names are in the form "mlc:mlcpp0", "mlc:mlcpp1",
etc. for devices connected to a PC's parallel port, and they're in the form
"hpjd:my-jdex.my-domain.com", "hpjd:my-500x.my-domain.com:3",
"hpjd:192.54.79.33", etc. for devices connected to a JetDirect.  For the
future user-space I/O driver I'm currently working on, I'm leaning towards
names in the form "mlc:par:whatever" or "mlc:usb:whatever", where "whatever"
would be a string set by the user when starting the daemon.  It could be as
simple as "0", "1", "2", etc., or for parallel it could be an I/O port base,
such as "378", "278", "3BC", or it could be any pet name, like "ol_betsy".

(regarding my plugin proposal)
> Unfortunately, I am missing a lot of the expertise needed for this. I'm 
> reasonably sure I can set up the windows, classes, etc. for the beginning of 
> this kind of app, but almost certainly, someone else will need to assist in 
> various areas, which would probably include the plugin system. 
> 
> What timeline do you expect for development of this app?
I don't think there's any hurry.  For the time being I'm focusing on
improving I/O support and adding PML support to PTAL, which is a necessary
dependency for something as complicated as xhpcontrol, particularly since I
haven't yet finalized the PTAL PML API.

Initially I am thinking about writing some quick-and-dirty commmand-line
utilities that would provide similar functionality to xhpcontrol.  (I might
also do something similar for PML scanning and faxing before I embark on
the task of writing a proper SANE backend or whatever for this.)  Besides
helping me test PTAL, this would give me a chance to experiment and figure
out the "content" that should go into xhpcontrol.  That's one reason I
suggested the plugin idea to have maximum content flexibility.

That said, it still wouldn't hurt to at least start developing the
infrastructure: overall layout, multi-device support, and one or two simple
plugins, such as the current xojpanel functionality, just to get started.
I'll certainly be glad to help wherever you need it, and I think there are
plenty of examples to draw from as well.

PTAL is an example of a static (compile-time) plugin architecture, although
I called them "providers" rather than "plugins".  ptal.c provides the general
API, and there are two providers (ptal-hpjd.c and ptal-mlc.c) which are
registered in a table in ptal-providers.c.

A dynamic plugin architecture would use shared libraries dynamically loaded
using the "dl" functions: dlopen, dlerror, dlsym, and dlclose.  See the man
page for those functions.  Since I'm not familiar with QT programming I don't
know offhand how one would go about dynamically binding modules into a QT
class hierarchy, but I know it's possible, since it turns out that this is
exactly what KDE2 (not KDE1) control center does, as I just discovered by
reading kdebase-2.0/kcontrol/HOWTO (in the source package).  It sounds pretty
interesting, and there might be an opportunity to leverage some of their
code, since it's also licensed under the GPL.  However, I don't think it
would be appropriate to just write kcontrol plugins instead of a standalone
application, because that would shut out many users who don't use KDE.

BTW, it occurred to me recently that you don't actually have to go to the
trouble of loading .xpm files at runtime.  They're actually in the format of
a .h file that you can just #include into a C/C++ application.  I learned a
long time ago that .xbm files have this property, and I didn't realize that
.xpm files were the same way.  I added an entry on the TODO list on the web
to change this when I get a chance (unless you happen to get to it before I
do, but don't worry about it if you don't want to, and it's not urgent in
any case).

David