SunRay Update 4

The inevitable question is how.

Essentially creating two text fields is no huge task, however when one considers all the minor trends and habits users acquire, several considerations needed to be made – these will be considered later.

I will cover several aspects of the menu code; this post is written with the intension to be used as a reference guide rather than a walkthrough for an implementation. You are welcome to use any of the code and I will be happy to provide any assistance or explain further although using the code (or my advice) is at your own risk.

The sunray menu at the Solaris side is basically comprised of two main parts; a Tcl menu and a shell script.

The menu itself is created using Tcl.

In order to run the windows connector, we have a procedure which imports the entered username, password, kiosk username and applicable host IP address.

proc log {username password KIOUSER HOST} {set EN1 [string trim $username]; set EN2 $password; \ delete 0 end; delete 0 end; focus; \
        exec echo $EN2 | /opt/SUNWuttsc/bin/uttsc \
        -k en_GB -l en_GB -m -b -O -r sound:high \
        -r disk:USB=/tmp/SUNWut/mnt/$KIOUSER \
        -u $EN1 -i $HOST }

button -text "Login" -font defaultFont -command { log $username $password $KIOUSER $HOST}

This procedure also clears both of the text fields and sets the focus to the entry text box. This clearing is done before the windows connector to ensure regardless of whatever event, the details are not saved and will always be removed.

With a single frame positioned in the middle of the screen, the focus of textboxes required users to move their mouse over the frame. To resolve this issue I created a frame within another frame on the page. The background frame being set to the maximum screen size and the menu frame will auto size itself depending on the internal widgets contained.

set width [expr {([winfo screenwidth .]-[winfo width .])+1}]
set height [expr {([winfo screenheight .]-[winfo height .])+1}]

frame .sub -background black -width $width -height $height
frame -background grey -borderwidth $BORDER_WIDTH -relief raised

This does present another issue, as the menu frame is dynamically generated, how would one centralise it on the screen? Essentially there are two potential resolutions, you could hard-code the dimensions (not ideal if the menu ever changes) or calculate the size after it has been rendered.

I decided to proceed with the latter option and in fact what my script does is place the whole menu frame outside the viewable screen, measure the dimensions and then with these figures reposition it exactly in the middle of the screen.

This image conveys the calculations which are essential to dynamically centralise the menu.

In pseudo code:
The menu frame is created (actually outside of the BIX by BIY boundary, but represented inside for simplicity) as GrX by GrY = Grey position.
The centre of the screen: BY/2 by BX/2 = Dark Blue Grid.
Moving the menu frame GrX by GrY + BY/2 by BX/2 = Light Blue position.
Calculate the value half length of menu frame LbX/2 by LbY/2 = GX by GY.
Move menu to the centre of the screen LbY – GY by LbX – GX = RY by RX.

And now no matter how big or small our menu frame is made, it will always be set in the middle if the screen.

set c [winfo width .menuframe]
set d [winfo height . menuframe]
set e [expr {($a)-(($c)/2)}]
set f [expr {($b)-(($d)/2)}]
place .menuframe -x $e -y $f

In an aim to be openly usable, we make every effort to make our systems viable to people who might be visually impaired. Luckily, Sun really made this easy with the sunray system, allowing us to set a sunray to a particular resolution.
The command in the sunray software is called using utxconfig – in the following format: /opt/SUNWut/bin/utxconfig -t $TOKEN -r “1024×768”.
We decided three main resolutions would provide our users with a good scope: 1280×1024, 1024×768. 800×600.

The user is able to change their resolution from the same menu screen and no extra script is required. Based on a dropdown menu, the user can choose their desired option, then the sunray will reboot itself and apply the changes.

menubutton .menuframe.resol -text "Preferences" -font defaultFont -relief raised \
        -menu . menuframe.resol.options
menubutton .menuframe.resol -text "Preferences" -font defaultFont -relief raised \
        -menu . menuframe.resol.options

menu . menuframe.resol.options
        . menuframe.resol.options add command -label "High 1280x1024" -command \
                { exec /opt/SUNWut/bin/utxconfig -t $TOKEN -r "auto" >/dev/null 2>&1 ; exit }
        . menuframe.resol.options add command -label "Medium 1024x768" -command \
                { exec /opt/SUNWut/bin/utxconfig -t $TOKEN -r "1024x768" >/dev/null 2>&1 ; exit }
        . menuframe.resol.options add command -label "Low 800x600" -command \
                { exec /opt/SUNWut/bin/utxconfig -t $TOKEN -r "800x600" >/dev/null 2>&1 ; exit }

Where &gt should display “>” and &amp should show “&1”. >/dev/null 2>&1

Our menus widgets are placed in a grid format within the menu frame (which is within the screen frame).

Finally to allow the ‘return’ or ‘enter’ key can be used to login, it needs to be bound to a procedure – much like the login button. In this case the return key can be used to login when and only when the focus is on the password field.

bind .menuframe.entry2  { log $username $password $KIOUSER $HOST }

Please note, I have trimmed, rearranged and edited some of the working code to simplify it for this post. You should be able to copy chunks of code, but please make sure you understand what it is doing, else you will likely fall prey to a simple syntax error.

This entry was posted in Cool Stuff, General, Sunray and tagged , , , , , , , . Bookmark the permalink.

2 Responses to SunRay Update 4

  1. “several considerations needed to be made – these will be considered later.”

    Haha! A true developer at work here. Decide what you want to give the user, then once completed, consider the effects and decide the user will just have to live with it 😉

  2. Adam says:

    “These will be considered later” was referring to the structure of the blog post, rather than the development of the project.

    The system is designed specifically with the user requirement as a priority. Functionality which might not currently exist is likely due to the fact it is no longer required. Much like not having a floppy drive is rarely an issue anymore, yet the first PC’s without one seemed lacking! With the use of USB pen drives and session mobility, there is rarely a requirement for a CD drive – and in the case there is, a single shared PC per team or department would be reasonable.
    If someone truely needs that kind of functionality on a daily basis, maybe a sunray isn’t the solution for the situation.

Leave a Reply

Your email address will not be published. Required fields are marked *