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