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