GRIDPLUS: Also have a look at Examples 2, 3 and 4
Adrian Davis
visitors to the site only look at Example 5...
...However; Example 5 is only intended to show how a GRIDPLUS
application may be structured, and as such, uses very basic screen
layouts so as not to detract from the purpose of the example.
To get a *much* better idea of the GRIDPLUS screen layout/design
capabilities, please take a look at each of the following:-
http://www.satisoft.com/tcltk/gridplus/example2.html
http://www.satisoft.com/tcltk/gridplus/example3.html
http://www.satisoft.com/tcltk/gridplus/example4.html
...They are all different and (I hope) give a better insight to the
possibilities of GRIDPLUS.
========================================
PLEASE NOTE: There was an error in the "namespace import" commands in
the "example" TCL files originally uploaded. I typed it in wrong once,
then cut&paste it everywhere (silly boy!!). Corrected versions of the
examples are now available for download, or...
...you can edit the originals:-
The following command (in each example)...
namespace import gridplus *
...should be changed to...
namespace import -force gridplus::*
...This also applies to the "combobox" in Example 2.
(Thanks to Giovanni Cristelli for suggesting the "-force" option)
Best Regards,
=Adrian=
Ramon Rib?
I've tried gridplus and the examples. Very nice. The
examples from 1 to 4 raise an error when pressing any button.
Is it intended or is it some error in my installation?
Also, most of the windows do not have a perfect resize
behaviour. Is is for simplicity of the examples or is it
a limitation of the package?
Regards,
Ramon Ribó
adr...@satisoft.com (Adrian Davis) wrote in message news:<9085c859.04062...@posting.google.com>...
Adrian Davis
> examples from 1 to 4 raise an error when pressing any button.
> Is it intended or is it some error in my installation?
This is as intended. These are examples of screen design/layouts. No
functionality has been given to the buttons. Only Example 5 is a
functional application.
However...
The error message does show the name of the procedure that the button
will execute.
> Also, most of the windows do not have a perfect resize
> behaviour. Is is for simplicity of the examples or is it
> a limitation of the package?
>
Resizing the window does not resize the grids contained within the
window. This is as designed - The window sizes to fit the contents.
If you wish to prevent the user manually resizing the window you could
use something like:-
wm resizable . 0 0
...for the root/main window, or...
wm resizeable .mywindow 0 0
...for a toplevel called ".mywindow". I'm considering making this the
default behaviour for GRIDPLUS - Any comments?
Best Regards,
=Adrian=
Oscar
>> Also, most of the windows do not have a perfect resize
>> behaviour. Is is for simplicity of the examples or is it
>> a limitation of the package?
>>
>
> Resizing the window does not resize the grids contained within the
> window. This is as designed - The window sizes to fit the contents.
IMHO, forcing this is a poor choice. The toplevel should use their
childs' anchors and resize them or create scrollbars when the toplevel
is resized.
> If you wish to prevent the user manually resizing the window you could
> use something like:-
>
> wm resizable . 0 0
>
> ...for the root/main window, or...
>
> wm resizeable .mywindow 0 0
>
> ...for a toplevel called ".mywindow". I'm considering making this the
> default behaviour for GRIDPLUS - Any comments?
This would turn every GRIDPLUS-managed toplevel into a non-resizable
modeless dialog, in MSWindows parlance. Not good. When there are more
than one toplevel, the user can't arrange its sizes to fit its
preferences. More often than not, one toplevel will cover the others.
--
Oscar
Ramon Rib?
For many cases, non-resizable windows can be a good option.
However, in other cases, it is very handy a window that expands
and makes bigger, widgets like entries, combos, tablelists, and
so on. Would it be very difficult to provide this second
behavior in an automatic or semi-manual way?
Regards,
Ramon Ribó
adr...@satisoft.com (Adrian Davis) wrote in message news:<9085c859.04062...@posting.google.com>...
Adrian Davis
> > window. This is as designed - The window sizes to fit the contents.
>
> IMHO, forcing this is a poor choice. The toplevel should use their
> childs' anchors and resize them or create scrollbars when the toplevel
> is resized.
I'm not sure why you think this is bad. I designed GRIDPLUS mainly to
simplify the creation of "form" front ends for "database"
applications. For this purpose there isn't much (I can think of) to be
gained by resizing the window...
...However; I'll have a look at the "add scrollbars when shrinking the
window" idea to see what would be involved.
>
> > If you wish to prevent the user manually resizing the window you could
> > use something like:-
> >
> > wm resizable . 0 0
> >
> > ...for the root/main window, or...
> >
> > wm resizeable .mywindow 0 0
> >
> > ...for a toplevel called ".mywindow". I'm considering making this the
> > default behaviour for GRIDPLUS - Any comments?
>
> This would turn every GRIDPLUS-managed toplevel into a non-resizable
> modeless dialog, in MSWindows parlance. Not good. When there are more
> than one toplevel, the user can't arrange its sizes to fit its
> preferences. More often than not, one toplevel will cover the others.
The above example would simply prevent the user from manually resizing
the window. It won't have any other effect - though I do see your
point about the resizing...
...In fact, come to think of it, it would probably be best to have an
additional ("-resizable") option for the "gridplus window"
command/mode.
Best Regards,
=Adrian=
Adrian Davis
> However, in other cases, it is very handy a window that expands
> and makes bigger, widgets like entries, combos, tablelists, and
> so on. Would it be very difficult to provide this second
> behavior in an automatic or semi-manual way?
>
> Regards,
>
> Ramon Ribó
I'm Sorry Ramon, I currently have no plans to have resizable widgets.
This would be a lot of work and likely to impact on the current
simplicity of GRIDPLUS.
Best Regards,
=Adrian=
Andreas Leitgeb
> I'm Sorry Ramon, I currently have no plans to have resizable widgets.
> This would be a lot of work and likely to impact on the current
> simplicity of GRIDPLUS.
When I hear "non-resizeable windows", I come to think of
some dialogs like for example the one in outlook that shows
the properties of a mail-message and that has a small text-
field of about 4 lines and about 50 characters at the bottom
to display the "internet headers". Of course the whole dialog
is unresizeable (as many dialogs in windows-world are), so no
way to make this field larger. you have to scroll sideways and
back to read the full headers.
So, when someone announces a geometry-manager that doesn't
do resizing, I think to myself: nice for you, if you have
a use for it. I'll come back later, once it does support
resizing and forget about it for now.
Adrian Davis
> some dialogs like for example the one in outlook that shows
> the properties of a mail-message and that has a small text-
> field of about 4 lines and about 50 characters at the bottom
> to display the "internet headers". Of course the whole dialog
> is unresizeable (as many dialogs in windows-world are), so no
> way to make this field larger. you have to scroll sideways and
> back to read the full headers.
To be fair, I'm not really responsible for the bad design of "Outlook"
dialogs. If a field is likely to have more than 4 lines, then maybe
the field should be bigger in the first place!!
> So, when someone announces a geometry-manager that doesn't
> do resizing, I think to myself: nice for you, if you have
> a use for it. I'll come back later, once it does support
> resizing and forget about it for now.
GRIDPLUS was designed to create screens for a particular class of
application. A great number of "business" applications - (Things like,
payroll, stores, ordering, financial, transport management etc. etc.)
- are front-ends on a text based database. In general these mainly
require (possibly dozens of) "forms" to query/display/update the
contents database. This is what GRIDPLUS is good at. I've got more
than 20 years experience working in these environments, and resizeable
windows are very rarely a requirement, as, in the main, people working
with these types of applications spend most of their time using just
the one application. In this environment it is bad pratice to design
the application so that windows need to be resized in order to view
the data.
In summary, GRIDPLUS is not a replacement for other geometry managers,
but for the type of application for which it is intended, I believe it
will significantly simplify (and therefore speed up) the development
of "good looking" applications.
Best Regards,
=Adrian=
Oscar
[snip]
> GRIDPLUS was designed to create screens for a particular class of
> application. A great number of "business" applications - (Things like,
> payroll, stores, ordering, financial, transport management etc. etc.)
> - are front-ends on a text based database. In general these mainly
> require (possibly dozens of) "forms" to query/display/update the
> contents database. This is what GRIDPLUS is good at. I've got more
> than 20 years experience working in these environments, and resizeable
> windows are very rarely a requirement, as, in the main, people working
> with these types of applications spend most of their time using just
> the one application. In this environment it is bad pratice to design
> the application so that windows need to be resized in order to view
> the data.
The databases I work with have dynamic structure. Fields are created
and destroyed often. The user usually has several windows with
relations among them (master/detail, calculated fields, etc). The
user opens the windows he wants, rearranges its positions and sizes,
and start browsing or editing.
> In summary, GRIDPLUS is not a replacement for other geometry managers,
> but for the type of application for which it is intended, I believe it
> will significantly simplify (and therefore speed up) the development
> of "good looking" applications.
It is obvious that you achieved nice results for your
requirements. I'll see if GRIDPLUS works for me too.
Thanks for sharing.
Regards,
--
Oscar
Andreas Leitgeb
> To be fair, I'm not really responsible for the bad design of "Outlook"
> dialogs.
come across every once in a while that is unresizable, where
I wish very much it wasn't. In each particular case, of course
there may exist other solutions as well. (e.g. replace the
field with a button, which will popup a separate resizeable
window just for the contents of that field...)
> In this environment it is bad pratice to design
> the application so that windows need to be resized
> in order to view the data.
This is a tautology: In *every* environment it is bad practice
to *require* (need) the user to resize the window.
But it's also bad practise to *disable* him doing so.
Of course, dialogs should popup in a size that will, well just
be exactly the one you likely end up fixed-sizing your windows.
That is usually some compromise between the size of the data and
the size of the screen and the proportion of how much of the
screenspace a dialog may use up before it starts looking ugly.
Sometimes, a user wants to see more items of (e.g.) some embedded
listbox at once, or has entries unusually wide which get clipped.
then the first thing to try is to make the dialog larger, and if that
won't work then there is frustration left.
Often, such dialogs are clickety-clicked together with some
visual* guidesigner, with no concept of anchors and weights.
If your gridplus is built on top of the native grid, then you
already have the functionality of handling resizing right at
your hands, but you deliberately decide to disable it. Why?
Adrian Davis
Andreas,
Well, I guess we just have fundamental differences as to how we each
approach application design.
I originally created GRIDPLUS for my own purposes. I thought others
may find it useful, so in the "free and open" spirit of the TCL
community, I made the result of this work freely availble for anybody
who finds it useful...
...For those which don't find it useful, equally it is free *not* to
use it.
Best Regards,
=Adrian=
Andreas Leitgeb
> ...For those which don't find it useful, equally it is free *not* to
> use it.
I've got a tendency to give my comments even to things not my
business. I've seen various types of reactions to this
(mis?)behaviour of mine:
1) some just plain tell me to mind my own business,
2) some tell me, why they did it so, and depending on their
answer, I either see they were right anyway, or enter
a recursion if I think the answer was again flawed.
3) And finally sometimes it happens that my comments are actually
appreciated, implemented, whatever. (well, of course this also
depends on my comments in each particular case)
In this case, there was one recursion where I asked you
why you disable the geometry-management that you get for
free from grid, and now it ends with a type-1-answer.
Steve Landers
> I originally created GRIDPLUS for my own purposes. I thought others
> may find it useful, so in the "free and open" spirit of the TCL
> community, I made the result of this work freely availble for anybody
> who finds it useful...
>
> ...For those which don't find it useful, equally it is free *not* to
> use it.
And indeed it is useful - well done, and thanks for sharing it.
Steve
Jeff Godfrey
news:40db...@quokka.wn.com.au...
: Adrian Davis wrote:
: > ...For those which don't find it useful, equally it is free *not* to
: > use it.
:
: And indeed it is useful - well done, and thanks for sharing it.
I agree, totally - thanks Adrian. Your efforts are appreciated.