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