We use a program called vspace created by ncomputing. This allows for example 4 stations on a single host machine. So, each time this is installed we have to fill out the registration form which pops up when finalizing the installation. It only takes roughly 20 seconds or so to fill out, but that's 20 seconds for a couple hundred computers, so I am trying to find something that will take the information and fill it in.
I have no idea how to accomplish this. One thing it could do, is when I fill it out manually, I "tab" to the next block. If it could say, fill, tab, fill, tab and so forth with the pre-programmed data starting at whatever the currently selected field was, I think that might be easiest.
Here's a photo of the registration screen. It defaults the cursor to the first block "name" and none of the drop boxes have to be edited.
Related
I'm plotting two Line Graphs using the Oxyplot Library in a WPF application, which works pretty well. There are a maximum of 8 lines, but for the sake of the test, I'm only using 2.
The program allows the user to choose the refresh rate of the data, which is also used to refresh both Plots. All works as it should, unless when the user choose a Refresh rate under 1 second.
Some seconds after the refresh has been set to under 1 sec, the Plot just vanishes and its area turns blank. A weird fact tho, the Tracker still works if I can find the right spot in the line, i.e. the points of the graph are still there, but it's not been shown anymore. It happens first with one Graph, than some time later the second Graph also turns into a deep white area.
I wonder, is there any limitation for the refresh rate for Line Graphs of the Oxyplot library? I mean, does it use some buffer or cache memory that is probably been blown by the high refresh rate? And yes, I would need it to refresh this fast in some cases.
My program currently allows the user to draw the $ character on the screen with ncurses initialized when a key is pressed.
mvaddch(y,x,'$');
I also have a box drawn and I want to say that after the user presses a specific key, I want the $ to be erased and placed in the new position the user puts it without erasing the entire screen. I tried using erase(), but after that it would erase the entire screen and I don't want that. I want it to keep the box that was drawn. So how would I do this?
The usual way to approach this is to create windows on the screen, e.g., with newwin or subwin, and create the box and '$' in different windows while using clear/wclear to clear the appropriate places on the screen.
Keep in mind that getch/wgetch does a refresh on the window with which it is associated, so that may overwrite updates from overlapping windows.
I am envisioning a Google Glass knitting app to help my sister. Many knitters, including her, like to work from knitting charts, which are big grids with special symbols to indicate the type of stitch. You work your way down the chart, one row at a time, knitting the indicated stitches, and voila! you have a fancy sweater or whatever. She often knits while sitting on the bus, or even while walking, and having the chart on Glass would leave her hands free to do what's important.
Let me describe the ideal, but apparently unsupported, interface, and then you can tell me if there's any good substitute. Ideally, there would be a bundle containing 100 numbered rows of knitting symbols (or however long the chart is). The user sees the current row across the middle of the screen, with the rows above and below displayed more dimly. Swiping back and forward would move up and down the chart, vertically scrolling by one row and highlighting the current row. Because there are so many rows, the user needs a way to skip to a particular row, if they are picking up where they left off. I imagine them tapping to bring up a menu that allows them to speak the desired row number.
It appears that this is completely impossible at the moment. Vertical scrolling is not supported; instead, I would need to create a bundle of horizontally scrolling images of sets of three rows, with the one in the middle highlighted to be the "current" one. OK, that's an acceptable substitute. But then how does the user select a particular row? Do I need to give each card a menu allowing them to somehow request a particular row, which then gets sent over the network to the server, which then sends back a new version of the bundle with the desired row toward the beginning? That sounds wasteful, slow and fragile. Does the Glass UI provide any way to handle this kind of data? If not, is it possible that it will handle it in the future?
I can imagine plenty of applications (teleprompter, karaoke, etc.) that involve vertically scrolling through significant numbers of rows, so I'm sure I'm not the only requester of this, which makes me think that maybe, if it's not currently supported, it might be in the future. Thanks.
It sounds like you are interested in filing a feature request with the Glass team. You can do so here by clicking the New Issue button in the top left. In your request, it will be helpful to the Glass team to summarize the use case that you have described in this question.
I'm creating a bundle using timeline.html as my cover page and providing other sub-pages using the timeline.htmlPages attribute. I want to have different menu items for the cover page as well as for each of the sub-pages. Currently I dont' see any way to have a menuItem for each htmlPage and/or the cover page. Am I missing something ?
I have a work around for this which I did during Glass Foundry : I created a random bundle id, then i looped over all my html pages and using the same bundle id inserted a timeline item, with the same cover page and a single htmlPages with whatever menuItems i want for that index. This works as I want, however since this results in N insert() calls, it takes a lot of time for the glass to receive the bundle [also eats into my api quota as a side effect]
You can only have one menu for a given timeline card, even if it has many pages.
timelineItem.html and timelineItem.htmlPages are intended to be used for a single logical piece of content that just happens to exceed the space available on the screen. For this reason, they all share the same menu and the same timelineItem.id.
If you require a different menu for each page, you probably have content that's logically separate. This warrants a distinct timeline card for each piece of content, and this allows you to specify a different menu. Bundling by timelineItem.bundleId allows you to group similar distinct cards, just as you describe.
The total amount of data transmitted is roughly the same, so total latency shouldn't be too much of an issue. If the gradual insert is noticeable, consider only setting timelineItem.notification on the last item to be inserted.
I'm designing some dialog boxes, and I'm having a hard time to fit everything. (and it has to fit on a single dialog box by design, so please don't tell me I should make two dialogs instead of one:))
I'm wondering what's the max size a dialog can have before being annoying for the end user. Of course it should't be bigger than his resolution, but are there any other boundaries to consider?
I'm trying to limit at 800x580 (so that it can display fine on a 800x600 screen without hiding the taskbar), but I expect my users to be on 1024x768 or better screen resolutions.
Is a 800x580 dialog box ok, or is it too big?
Have you considered using a tabbed layout?
Also, I believe the smallest main-stream screen resolution is 1024x600.
I'd say anything over that is too big. I try to stick below 1000x500.
I'm writing this on a netbook (ASUS) with resolution 1024 x 600. I've also noticed this is a defacto standard for most other netbooks too.
Another option: you could create a dialog that resizes itself automatically to fill the current desktop (except for the task bar).
It could also enforce a "flow" style layout for it's child controls. This would ensure the best use of the available space is made.
To get "flowing" in Windows forms you can use either the flow layout control or (for a richer interface) the WebBrowser control.
By the way, modal dialogs seem to be less popular as a way of user interaction these days. Especially large dialogs containing a lot of information/controls. This article has some good alternatives.
I think that if the user NEEDS to see all data on screen at the same time... and you can fit everything in 800x580... I think that it's a fine size.
If you know all users have bigger resolutions so don't struggle... that size is OK.
However... a way of showing lots of information and being able to edit it... could be a PropertyGrid control (an example here)... may be that could shrink a bit the form if you don't feel confortable with it being so big. Don't know if it a possibility given the needs of your client/user.
Just hope that no-one ever tries using your app on a media center running through a standard definition display. That's 640x480 for NTSC. I've suffered this problem with quite a few apps.
Whatever your pixel by pixel size, if it takes more than a few seconds for skilled users to complete the use of your window, then it shouldn’t be a dialog. Anything longer is annoying. You’d be asking your users to do too much work that is too easy to lose (e.g., by hitting Cancel accidentally) and too hard to re-entered (e.g., between sessions). If you have so many controls that the dialog needs to be 800 by anything, then it’s too many controls. 200,000 square pixels and 40 controls is the very most you should consider for a dialog. And tabs are nature’s way of saying your dialog is too complex.
Dialogs are for entering parameters to execute a single command on one or more data objects visible in the primary window for the dialog, which is why dialogs need to be small and simple. I suspect that’s not what you’re doing. Instead, you’re using a “dialog” to represent the main data objects and carry out a major task, not a single command.
What you want is a primary window, not a dialog, with all the support necessary for the complicated task you’ve set up for the user. That includes providing a means for users to save, retrieve, and copy their work. That means a menu bar and toolbar with all the standard commands, including help. The window should absolutely be modeless, and be resizable, maximizable, and minimizable.
Primary windows should be designed to work best at the size of most (over half) of your users’ screens. 1024x768 is generally fine for today’s laptop/desktop screens, not that you should use that much space if you don’t have to. If the user’s screen is smaller, or the user for any reason resizes your window below the design size, then scrollbars should appear to allow full access to all controls and content in the form –just like any primary window. The experience on the web indicates that scrolling is not a showstopper for forms.
Beyond that, tabs may be used in a primary window to increase the number of controls on it. You said you don’t want to hear about multiple windows, but multiple windows should be used instead of tabs if the user will be comparing data across tabs/windows. You can also fit more in a given primary window size by using a compact presentation (I describe this at http://www.zuschlogin.com/?p=42), but test such an approach on your users before committing to it.