gnue
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Forms definition again - high-resolution capability requirements


From: Jason Cater
Subject: Re: Forms definition again - high-resolution capability requirements
Date: Sat, 19 Oct 2002 11:37:58 -0500

Robert,

I certainly understand having to do whatever to get a client up. I wish
you luck. 

However, a comment or two: 

We have currently tied ourselves to a character-based positioning system.
This may not be ideal, and like I mentioned before, we are working towards
pluggable positioning. 

However, character-based does *not* imply an 80x24 grid. I have forms
running closer to the equivalent of 200x60. Character-based simply implies
the positioning granularity, not screen resolutions. Have you looked at
some of our screenshots on the website? They are certainly not 80x24. 

Also, regarding authentication from a database table... part of the 0.4.0
release was the ability to have custom authenticators. It's quite easy to
do.  In common/doc/technotes, there are instructions. You basically create
a python file with two methods. 

I certainly don't blame you for having to make whatever decision you need
to in order to get paid.. that's perfectly understandable.  However, I
wonder if you misjudge GNUe Form's completeness. I have it in use in quite
a few production environments now. Sure, it's not perfect.  But also
consider the amount of effort required to do a custom job. 

Either way, thanks for the feedback. 

-- Jason 

On Sat, 19 Oct 2002 17:17:14 +0100
"Robert Jenkins" <address@hidden> wrote:

> Hi Jason,
> 
> Thanks for the reply.
> It is a lot at one go, but it's absolutely everything I could come up
> with for complete 'useability'.
> 
> 
> 
> My #1 main problem with the current GNUe 'Standards' is the restriction
> on _functional_ screen resolution - you are forcing people to use what
> is in effect an emulation of a text-resolution screen on graphics
> systems. 
> 
> If the forms system was capable of handling up to graphics resolutions,
> users could define the resolution they want to use for their system,
> whether it is 1280 x 1024 graphics or 80 x 24 text. Note that I'm not
> saying graphic-only, just definable resolution.
> 
> 
> >From my experience of business & database apps., 80 x 24 text is simply
> not enough to be useable for serious applications. It's not whether the
> screen is graphical or text, it's about quantity of information
> displayed per screen.
> 
> (I've just looked at a couple of forms in the Sage Line50 accounts
> package - these are diplayed on my PC at a resolution equivalent to
> about 240 characters x 60 lines.)
> 
> I strongly suggest that you talk to some independent accountants and
> business managers, describe the 'Enterprise' project to them & ask what
> they think the minimum amount of information per page would be on the
> more complex forms. 
> 
> 
> 
> In the meantime; pending GNUe reaching a suitably functional level, I've
> started writing my own Forms client / designer, as I will lose my
> customer if I don't get their new system up and running fairly soon.
> 
> It happily takes existing GNUe forms definitions (as I hope to still use
> GNUe and get them changed over to 'Enterprise' once it's done), but it
> has the screen resolution and security extensions I need.
> 
> So far it handles form display, paging, etc., with login at startup
> reading user security level from a table on the database. I'm currently
> working on the rest of the database integration, then I have to start on
> the designer side...
> 
> 
> 
> 
> I don't like to keep going on about it, BUT if you insist on restricting
> GNUe to 80 x 24 then you are creating a dinosaur. All current serious
> applications have high resolution capability.
> 
> The current minimum screen resolution requirement for many apps is 800 x
> 600 - and this applies equally to a lot of the present Linux XWindows
> ones, not only MS windows stuff.
> 
> 
> 
> What does everyone else think??
> 
> 
> 
> Regards,
> 
> Robert Jenkins,
> JRW Developments.
> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]