hpoj-devel

Re: [hpoj-devel] xojpanel replacement

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

Joe Piolunek wrote:
> I've started working again on an 'xojpanel replacement' that should be much 
> more functional. 
> 
> An earlier version that I had put together just got too big and complicated, 
> so I started over from scratch. The newer version looks a lot better, I think.
> It may still be too early to decide exactly how the application should look 
> or what it should contain, but the more thought put into it in the beginning, 
> the better, IMHO.
> 
> I have the application building into a new directory under hpoj-0.7/apps/. 
> It's a little too early to make the code available. There isn't much of it 
> yet.
> 
> On my site are screenshots of the two windows created so far. These are 
> 'previews' created by the Qt designer.
> 
> The web server has been a little messed up, so if you don't see a page with 
> OfficeJet GUI screenshots, try again later.
> 
> http://pages.cthome.net/jsp/hpoj-linux-gui/index.html
> 
> Is it worth continuing in this direction? Let me know what you think.

Hi, Joe.  Thanks for revising this.  Sorry I didn't respond until now.
I started back at work at the end of last week after being on vacation for
two weeks and have been trying to catch up a lot there.  :-)

Although I applaud your efforts to simplify the application and make it
easier to use, I'm not sure that the new version will totally accomplish
that.  It appears that the user would have to do too much clicking to go
through the list of devices and check the status on each one, if there
happened to be multiple devices available.  Even if you put the LCD panel
on the printer selection dialog box, that wouldn't help me if I wanted to
check the ink/toner levels on each device, for example, and if you kept
adding more "shortcuts" like this to the printer selection dialog box,
then it would end up getting quite cluttered as well.

Looking back at your earlier screenshots based on my original idea, I'll
admit they do seem a bit cluttered and overwhelming.  I still think a
somewhat simplified version of this idea would be quite effective,
however:

- On the left, have a flat (non-hierarchical) list of all known PTAL
device names (perhaps from a file such as /etc/xhpcontrol.conf).  One
could argue that it's not user-friendly to let the PTAL device names all
hang out like this, but I want to avoid falling into the trap of over-
obfuscation that Windows-based applications tend to fall into, which
ultimately only makes things more difficult when one really needs to know
what's going on behind the scenes.  You could always allow a user-defined
comment (possibly indication location or ownership of the device) to be
displayed either in this list or in one of the tabs...

- On the right, have the (infamous?) tabs, but it might be better not to
have nested tabs as in your earlier example.  This way, one could click
on the first device and the desired tab (LCD or ink levels, for example),
then click on each successive device and the same tab would stay selected
and would update itself for each successive device.

- As an alternative to tabs, we could use the KDE control panel as an
example, with its (possibly hierarchical) list of categories of options
in the middle, and once a category is selected, the actual dialog box for
it on the right.

- I envision that this application could be made useful for most HP
peripherals, not just the all-in-ones.  Therefore, I think it would be
better to have some sort of plugin architecture, where each plugin would
define and register one or a small number of option categories (tabs or
whatever), and the application would handle the device list and would
notify plugins when a different device or category was selected so the
plugin could redraw its share of the dialog box and handle user event
such as clicking on buttons or whatever.

Besides making it easy to support a larger variety of HP peripherals,
using plugins would allow a much cleaner and modular design for the
application, and would give much more flexibility in defining the actual
categories of control/status options and their contents, rather than if
they were all hard-coded in a monolithic design.

Plugins could be loaded at runtime as shared libraries, or they could be
statically compiled into the application while still being cleanly separated
from the main part of the application.

Of course, I'm not a user-interface expert, which explains why my job is
firmware development, not GUI design.  :-)

David

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

Re: [hpoj-devel] xojpanel replacement

[Joe P. <joe...@sn...>]

On Saturday 20 January 2001 09:06, David Paschal wrote:

<..>
> 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 listview widget may still be useful in some fashon for this. In the 
'new design' that I put on my page, the listview showed several nested layers 
in the printer column, but the 'tree' was there only for illustrative 
purposes. If the listview is used, and the user is responsible for adding 
devices to the list, he/she can create either a totally flat list or a nested 
one if desired. Another property of the listview is its built-in ability to 
sort by column, which could be useful for sorting the printer list by 
ink/toner level, for example.

The listview could also be informational only, with no ability for the user 
to change entries directly.

> > 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 . 
<...>
> 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.

I was in error regarding the designer's compatibilty with earlier versions. 
There probably would be few if any compatibility problems with ver. 2.1.x+, 
but 2.0.x versions will cause a problem. Possibly, it may not be a big one. 
When I compiled the big, complex version of the interface under qt-2.0.1, gcc 
complained about several lines, but simply commenting them out allowed it to 
build and execute without trouble. 

It seems that if the designer is to be used, a lot of time would be saved in 
creating the interfaces, but some would be lost later trying to maintain 
compatibility with earlier qt versions. If it remains easy to do, It would be 
worth the trouble, I think.

The directory structure I'm using prevents the generated files from 
overwriting hand-modified versions. The generated files are in a separate 
directory of their own. 'make' will look for them in a different directory, 
where it will find either symlinks to the generated files, or local 
hand-modified versions.

My prediction (which could be way off) is with the major improvements in kde2 
and qt, in a few months kde '1' will have nearly disappeared. The older Qt 
versions will probably disappear with it. Redhat already has  qt-2.2.3 RPMS 
available for newer systems. 

Several different Qt versions can happily coexist on the same system, making 
an upgrade easy. I have three versions installed on my box.

 
> > 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.

I don't have a better one.

> > 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.

Makes sense.


> > 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.

I agree that an arbitrary limit should not be used. I was trying to get a 
better idea of how the application would be used. The more details I can get 
about that, the more confident I'll be that what I'm making will be usable.


> > 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.

I'm only going to get it started for now. I haven't been able to do very much 
on it lately anyway, due to other projects needing work.


>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.

I won't add anything kde-specific.

>
> 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).

That might be a good idea, especially if there aren't many graphics in the 
application. In a small app like xojpanel, it may make more sense to compile 
them in.

When I opened an *.xpm with a text editor, I could see the format is simply 
an array declared like this:
static char * hpoj_mini_xpm[] = { ... }

If a pixmap is chosen inside the qt designer, a similar array is added to the 
generated *.cpp file, but it's declared like this:
static const char* const image0_data[] = { ... } 

Loading graphics at runtime isn't necessarily a bad idea though. 'kdevelop' 
does it. Loading at runtime lets the user substitute his/her own graphics 
without recompiling. It also decreases the size of the binary, which in some 
cases may improve performance.

-- 
Joe

Re: [hpoj-devel] xojpanel replacement

[Joe P. <joe...@sn...>]

On Wednesday 10 January 2001 08:55, David Paschal wrote:

> Joe Piolunek wrote:
> > I've started working again on an 'xojpanel replacement' that should be
> > much more functional.

<...>
> I'm not sure that the new version will totally accomplish
> that.  It appears that the user would have to do too much clicking to go
> through the list of devices and check the status on each one, if there
> happened to be multiple devices available.  Even if you put the LCD panel
> on the printer selection dialog box, that wouldn't help me if I wanted to
> check the ink/toner levels on each device, for example, and if you kept
> adding more "shortcuts" like this to the printer selection dialog box,
> then it would end up getting quite cluttered as well.

I went back to the old design and have it building under hpoj-0.7/apps/. It 
will be easy to modify the windows' appearance to fit whatever you want it to 
look like, especially if done early in the process.

When I have the window looking more acceptable, I'll update my web page, 
adding current screenshots.

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.

About modifying the appearance of the windows -

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.

Qt-2.2.3 works extremely well. It's worth installing, but it needs a lot of 
disk space if building from source. You can now get Qt under the GPL if you 
are developing free software or simply using qt applications.


> Looking back at your earlier screenshots based on my original idea, I'll
> admit they do seem a bit cluttered and overwhelming.  I still think a
> somewhat simplified version of this idea would be quite effective,
> however:
>
> - On the left, have a flat (non-hierarchical) list of all known PTAL
> device names (perhaps from a file such as /etc/xhpcontrol.conf).  

I'll make the windows look more or less the way you want them to.
 
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'.

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::"

What would you like for the main window's title?

>One could argue that it's not user-friendly to let the PTAL device names all
> hang out like this, but I want to avoid falling into the trap of over-
> obfuscation that Windows-based applications tend to fall into, which
> ultimately only makes things more difficult when one really needs to know
> what's going on behind the scenes.  You could always allow a user-defined
> comment (possibly indication location or ownership of the device) to be
> displayed either in this list or in one of the tabs...

What user are you primarily aiming at (developer, printer admin, etc.), and 
how many device names would normally be in that user's list? What might the 
maximum number be? What would the device names look like?

>
> - On the right, have the (infamous?) tabs, but it might be better not to
> have nested tabs as in your earlier example.  This way, one could click
> on the first device and the desired tab (LCD or ink levels, for example),
> then click on each successive device and the same tab would stay selected
> and would update itself for each successive device.
>

More than one row of tabs is generally to be avoided. It occurred with the 
'fax' tab because there is so much information in that category. I'll remove 
the nested row soon and perhaps show it in a different 'popup' window later.

> - As an alternative to tabs, we could use the KDE control panel as an
> example, with its (possibly hierarchical) list of categories of options
> in the middle, and once a category is selected, the actual dialog box for
> it on the right.

Sounds like a good alternative.

>
> - I envision that this application could be made useful for most HP
> peripherals, not just the all-in-ones.  Therefore, I think it would be
> better to have some sort of plugin architecture, where each plugin would
> define and register one or a small number of option categories (tabs or
> whatever), and the application would handle the device list and would
> notify plugins when a different device or category was selected so the
> plugin could redraw its share of the dialog box and handle user event
> such as clicking on buttons or whatever.
>
> Besides making it easy to support a larger variety of HP peripherals,
> using plugins would allow a much cleaner and modular design for the
> application, and would give much more flexibility in defining the actual
> categories of control/status options and their contents, rather than if
> they were all hard-coded in a monolithic design.
>
> Plugins could be loaded at runtime as shared libraries, or they could be
> statically compiled into the application while still being cleanly
> separated from the main part of the application.
>

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?

> Of course, I'm not a user-interface expert, which explains why my job is
> firmware development, not GUI design.  :-)

Me neither.

-- 
Joe