Re: Small wish for the XML dialogs

[David via Scripting]

Thanks Chip,
I am following your prctice - at least partially, when constructing my 
XMLs. I just wish there would be a way for me to control the dialogs to 
the higher extent.

My guess is that this is one of the cases, where either people have 
never tried constructing anything more than a very simple XML dialog - 
and hence won't realize what we are talking. Or, they have at least 
enough sight to do their dialogs and check to see they are the way they 
intended them to be. Or, they simply don't care, long as things come out 
the right way for a speech-user. I don't know. But it is nice to hear, 
that at least one other blind person, finds himself struggling the same 
that I do.

Your ideas, Chip, in their basic, are very helpful. The idea of nesting 
groups is what I am doing as well. A couple of your suggestions I have 
never tried, so will have to do some playing around here one of the 
days. And the idea of the mousing around, I have done for a long time. 
Only thing with the mousing is, that it takes quite a bit of time and 
efforts. Specially when things did not get totally where you wanted it. 
And you will all the time have to remember where on the screen your 
mouse is. That is why, for one reason, I thought it would be easier if I 
could simply tell the system exactly where I want things placed, and 
have that done.

Just, for all of you, imagine if we were to save our files on our disks, 
the way we construct XMLs. OK, a bit out of scope that comparison, I  
know, but just for the samplification. You tell the computer to store 
your file under documents, and it does, but you don't know exactly which 
subfolder, or if it got the filename you hoped for. How much would you 
care, long as the computer was able to refind and load your file. But 
the day you want to know where the file actually is stored, or in any 
other way control it a bit more, you are bewildered. It is a 
seek-an-hide job, ain't it? Same with your XML elements. You tell the 
system to place them somewhere in a dialog, and don't really care, if 
all you want is to have the speech read out some controls in a given 
order, and let the user act upon them. But the day you, as a blind 
person, wants a professional and controlled layout of your app, you may 
hope for a way of controlling it somehow more down to the details. And 
you wish you could do so, without having to hunt around the screen, to 
check if any tiny change you make, really got correct.

Well, I am not up for a prolonged arguing here, just aired a small wish. 
For those of you who - for whatever reason - don't care about the actual 
lookout of your dialogs, or who have never dealt with more complex 
dialogs with a number of controls; I guess you wonder what all of this 
hazzle ever is all about. And for those who have dealt with complex 
dialogs, and who happen to have a bit of sight, my suggestion could be 
for you to blindfold yourself for an hour, and sit down and construct 
just one dialog, holding say ten controls. Do all your posistioning, 
controlling and modification. Then get back to your result, when you 
again can see them with your eyes. Did you really get what you wanted? I 
am honestly eager to know. Because, IF you really got what you intended, 
then the XML system is really that reliable that i don't have to worry, 
and you could put me at ease. Or, maybe your blindfolded experience 
could lead you to some enhanced suggestions as to how a blind best can 
ensure his dialogs the best layout; and then you could enlighten both me 
and Chip. To be open-hearted with you, that would be of real value to 
us. Instead of just sweeping it all off the board, with some 
misunderstood comments, or sarcastic questions.

Aaron, it is nice to hear that things were constructed with blind people 
in mind. I am sure you and the staff around you, have put loads of 
efforts into making this the best for us developers. Still, my question 
is, have you ever tried my above mentioned idea of doing the job 
blindfolded? Don't mean to be harsh, just wondered if you have. I have 
suggested similarly in other cases, when sighted people have "ideas" of 
how easy things have been made for blind people. In many cases, people 
may get a slightly different idea of what would be good and workable 
solutions. Or, they could at least more specifically relate to what the 
blind user find troublesome. Sometimes, you've just gotta experience 
things, before you can realize. :) All said in a friendly and smiley way.

Had I been a newbie here, and simply just found things a bit confusing, 
I would maybe have been more at ease by the feedback in this thread. 
Yet, I have based my dialogs on some of the automated calculating 
built-in, and I have done extensive mousing. Through this mousing, I 
also have realized several times, that things did not really get 
positioned what I wanted them to. And, it is based on a few years 
experience - with a bit more than two controls in my dialogs - that I 
come back with this idea for improvement. Maybe the idea is not good in 
itself, the way it stands right now, but at least my hope was that it 
could be the foundation for some future way of enhancing the 
blind-friendly environment in which we already do our dialog-building.

With a smile, at least now you know what a couple of us feel could be 
helpful. :) And thanks to all, for whatever constructive feedback you 
may have to give. I am still learning... :D

o

David

On 4/1/2016 7:43 PM, Chip Orange wrote:
Hi David,

Yes, I absolutely agree, this feature of WE (which is an absolutely great feature (the XML 
dialogs)) does need a little more attention for exactly the reasons you mention.  To get around 
this, I use a lot of nested groups, specify only the width of the outter most group using actual 
dialog units, and use width and heights of either "group" or "fill".  I have 
found this gives the automatic dialog positioning algorithms the best chance of generating postions 
and widths and heights that I'm the happiest with.

I've found it's not actually the positions that are sometimes the most 
problematic, but the widths and heights which the positions are then generated 
from.

So, to give you a rough idea of what I mean,I may want a column of buttons down 
the left, next to an editbox, which I would like to fill all the space 
remaining in my dialog.
   I also add the window sizing option to the dialog, so that a user with a bigger screen 
can "maximize" my dialog and see even more if he's sighted.

I would then start out specifying the main dialog's width and height in units; 
I don't like doing this, but without doing it, the automatic positioning of WE 
is just far too often not usable.  So, I may specify 800 wide and 400 high.  I 
would then check the position and the size of my window using one of the 
developer tools which give you this information (TreeView from AI, or Vic 
Beckley has written an app named Focused Window Detective, which tells you 
about your currently focused window (such as the editbox) and the parent 
window, in an easy to use way).  I use these numbers and my resolution of the 
moment (which I don't set too high so I can hope what I generate will be 
something all users can run), to be sure the dialog I'm generating is not too 
large.  Later on as Tom said, I'll use the mouse to try and verify that info is 
showing up for all controls.  I'll adjust these number as needed, somes as the 
last thing I do for the dialog.

I'd make my main group horizontal, and I'd define two groups within it, both vertical.  
I'd set the ChildAlign property of the main group to "top", so my controls and 
any borders of my two vertical groups aligned at the top (don't know if this is the most 
attractive, just what I prefer).

I'll put my column of buttons in the left vertical group, and my editbox in the right one.  I won't 
define the width of the left vertical, because it's just buttons, and I've found WE will generate a 
group just wide enough to hold these buttons, which is just what I want.  I'll probably set it's 
height to be "group", so it will be the same height visually as the right vertical group 
holding the editbox which is also going to have a height of "group" (again, just a 
preference, but I do this when the buttons have some relation to what's in the editbox).

I usually give these groups a black frame (border), but again am not sure if this is the 
most attractive or not.  I use a lot of nested groups, and so when you get down to a low 
enough level, I do stop giving them frames, and instead set it to "none".  I do 
always give a group of radio buttons a visible frame.

For the vertical group on the right (here's the important part), I'll set the width to "fill", and the height to 
"group".  Since I made this right vertical group's parent be horizontal, then you can only use "fill" for the width of 
its children.  The height being "group" will have the same effect that I want as "fill"; that is, if the user exercises 
the "maximize" choice, the outer group will enlarge in both dimensions, and so the width of the right vertical group will expand 
to fill any extra space in the outer group, and the height of both vertical groups will expand to match the height of the outer group.

I don't set the height or width of the buttons in the left group, but for the editbox which I put in the right vertical 
group, I will set the height and width to be "group" when it's the only control in its group (as it is in 
this example), or I will set it's height to "fill" so it will take up as much of the right vertical group as 
it can after room as been calculated for the other controls in the group.  Note again that since the editbox parent is 
a vertical group, you can only use "fill" in the height of the editbox.  The rule is that you can only 
"fill" in the direction of the control placement axis of the parent group.

Later, I made decide that these buttons and their editbox are just one part of a more complex 
dialog, so I'll just insert them as a unit into a dialog which has other groups for the other 
controls I want to show.  I do end up with a lot of nested groups (take a look at the xml of the 
Remind Me Where app, especially the dlg_GetDirections1 dialog), but this works for me when I take a 
sort of modular approach in designing the dialog.  You do have to keep track of when you're using 
"fill" and "group" as widths or height, but it ends up giving me the most 
possible room for editboxes and listboxes which otherwise, can sometimes end up with a width or 
neight of 0 when WE calculates it.

Hth,

Chip



Chip Orange
Florida Public Service Commission
Computer Systems Analyst
850-413-6314


-----Original Message-----
From: Scripting 
[mailto:scripting-bounces+corange=psc.state.fl...@lists.window-eyes.com] On 
Behalf Of David via Scripting
Sent: Thursday, March 31, 2016 9:35 AM
To: GWScripting
Subject: Small wish for the XML dialogs

I have an idea, for an enhancement when constructing XML dialogs. That
is, if it is possible... :)

When defining an element, you can set the hight, width and the X and Y
positions. Yet, for a blind person, with no sighted assistance, this is
really quite a hit-and-miss job. OK, we got the AUTO feature for Hight
and Width, and to play safe as can be, that might be the one way to go.

But then we have the actual positioning of the element. Had all screens
looked the same, and all fonts been the same size, we could have gone by
screenpoints. But even that is a hit and miss. So, AISquared has
provided the chance to position our stuff on TOP, at BOTTOM, or align it
in the CENTER or near the LEFT and RIGHT edge.

I just wondered, if it would have been possible to implement a chance
for me, to define the size of the element percent-wise, in both the X
and Y direction. I could then have decided that my button should sit in
the upper left corner, and take up say 10 X-percent, and 5 Y-Percent. My
Next element, an edit box, I could have defined to sit 15 percent down
the X-line, and cover the next 3 X-percent. that is, it would start at
X15, and end at X17 percent. And it would stretch from Y20 to Y49 percent.

Hope the above gave a bit of meaning. The Dialog could then - all in the
background - do all the percent calculation, based on the actual size of
the dialog on the current computer, screen and under the currently
conditions that affects the dialog's physical size. It would have been a
bit easier, for me as a blind person to have things correctly positioned
and sized, did I have some tangible and reliable numbers to operate with.

In other words, could we have a feature to set the actual upper-left and
lower-right corners of an element, and also the starting position for
it, all based on percents of the total dialog size?

Anyone have some input on this?

Thanks,



_______________________________________________
Any views or opinions presented in this email are solely those of the author 
and do not necessarily represent those of Ai Squared.

For membership options, visit 
http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/archive%40mail-archive.com.
For subscription options, visit 
http://lists.window-eyes.com/listinfo.cgi/scripting-window-eyes.com
List archives can be found at 
http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com