This past week has been incredibly eye-opening. From fighting with signal passing one day to analyzing implementation the next, I've been plenty busy. At the beginning of the week Dan asked me to create a full-scale keyboard for people who want more options, but are limited to the virtual keyboard. I have added the Esc, Tab, and F1-12 buttons. In addition to that I implemented the all-too-tricky Ctrl/Alt keys.
The difference with these keys was that when the user presses the Ctrl key there is no immediate effect as in with the other keys. The user has to press a non-modifier (ie. 'a') in order for something to happen (same goes for Alt). So, when the user presses the key a signal is sent to the keyboard telling it that a modifier has been pressed and then putting it in the queue.
Here is the Ctrl key in action (as well as a preview to the full-scale layout).
I still need to do some more work figuring out the right spacing for this layout. As you can see some rows have many more keys than others making awkward gaps.
What I really want to start working on is the positioning code for the keyboard. This code will place the onscreen keyboard underneath any location where there is an input device, and will show the keyboard *only* when the user needs to type something, which will surely make for happy web surfing.
Until later,
Nohemi
Monday, June 27, 2011
Monday, June 20, 2011
Dragging ON
I didn't think I would post anything this week, since most of the changes I have made to the keyboard have been internal and thus there would be nothing fancy to show off. However, I have just (maybe 2 minutes ago?) finished the dragging option for the keyboard. This 'floating' layout allows the user to drag the smaller keyboard to whatever place on the screen they'd like. This is a precursor to the option we will eventually have for the keyboard.
Our future plan is to have the keyboard following the input changes of the user. For now the dragging keyboard is working properly, as far as I can tell :)
In addition to this functionality I have also added the option to have an iPod-like click-wait-drag-release option for subkeys and I have the message tray more or less working on top of the keyboard (GNOME users know that the message tray is usually at the bottom of the screen).
I am still having a bit of trouble getting the layout to look exactly as I wish, but I have figured that I'll first concentrate and ironing out the kinks in the keyboard functionality and then concentrate more on the "looks".
For next week, I'll hopefully have the 'combo' keys added and working on the keyboard (ie. CTRL + ALT + TAB, etc)
Until then,
Nohemi
Our future plan is to have the keyboard following the input changes of the user. For now the dragging keyboard is working properly, as far as I can tell :)
In addition to this functionality I have also added the option to have an iPod-like click-wait-drag-release option for subkeys and I have the message tray more or less working on top of the keyboard (GNOME users know that the message tray is usually at the bottom of the screen).
I am still having a bit of trouble getting the layout to look exactly as I wish, but I have figured that I'll first concentrate and ironing out the kinks in the keyboard functionality and then concentrate more on the "looks".
For next week, I'll hopefully have the 'combo' keys added and working on the keyboard (ie. CTRL + ALT + TAB, etc)
Until then,
Nohemi
Monday, June 13, 2011
A Big Success
I am typing from my onscreen keyboard!
Over the past week I have transformed the little black box on the corner of my screen into an improved keyboard. Some things I changed were the CSS style of the keys/keyboard, the ability to hide the keyboard in the message tray, and a formula that fits the keys to your screen no matter what the orientation of the screen.
Dan has suggested that I make the keys look more square, but I'm not sure if that will detract from the keyboard (there will need to be giant paddings horizontally or vertically depending on the screen orientation). Not sure what I'm going to do about that yet.
My favorite accomplishment of the week is the little keyboard button on the bottom right hand of the keyboard. Click it and whoosh!
The keyboard goes into the message tray and lets me work in full screen mode.
So, it seems that this week will be full of many little things TODO. I will be working on the "floating" layout, extending the subkey functionality (for iPhone users: click, wait, move, release on subkeys), and possibly merging some Caribou code. Today I've only had time to do a ton of little fixes to my code to make it look more like the rest of the GNOME shell, but I'm excited for tomorrow and that which will come.
Until then,
Nohemi
Over the past week I have transformed the little black box on the corner of my screen into an improved keyboard. Some things I changed were the CSS style of the keys/keyboard, the ability to hide the keyboard in the message tray, and a formula that fits the keys to your screen no matter what the orientation of the screen.
Dan has suggested that I make the keys look more square, but I'm not sure if that will detract from the keyboard (there will need to be giant paddings horizontally or vertically depending on the screen orientation). Not sure what I'm going to do about that yet.
My favorite accomplishment of the week is the little keyboard button on the bottom right hand of the keyboard. Click it and whoosh!
The keyboard goes into the message tray and lets me work in full screen mode.
So, it seems that this week will be full of many little things TODO. I will be working on the "floating" layout, extending the subkey functionality (for iPhone users: click, wait, move, release on subkeys), and possibly merging some Caribou code. Today I've only had time to do a ton of little fixes to my code to make it look more like the rest of the GNOME shell, but I'm excited for tomorrow and that which will come.
Until then,
Nohemi
Monday, June 6, 2011
A Keyboard, at last
After many struggles constructing ST entities and digging through pages of GNOME shell code, I am progressing with the keyboard. Just last week the keyboard was merely a shell, a pretty picture, but now I have the key and extended key presses mostly working as well as the sizing of the buttons.
Example of typing with keyboard
With the following piece of code we can take advantage of event signals in order to emit the key press:
button.connect('button-press-event', Lang.bind(this, function () { this._key.press(); }));
There were a ton of little details in this piece of code that challenged my understanding of signal passing, but when I realized that event signals become global events once they are created that made it much easier to concentrate on the procedures that needed to be done once the event was processed.
Example of using extended keys
Uses event.get_source() in order to figure out whether a click has been directed within the extended key box or outside of it. In order to do this, however, you must push the current modal into the global stage. This is a tricky procedure, since when the modal is on the stage the focus is removed from whatever is clicked at the moment. The reason this needs to be done is because there are "holes" on the stage that don't get processed as events.
For the next week I'm going to begin working on the focus and position of the keyboard, so that it matches the rest of GNOME's layout.
Also, I want to thank Marina for a great little piece of advice for the graphics crashes that I've been having recently on my Fedora 15 system with GNOME shell:
If your system crashes use CTRL+ALT+F2, type "DISPLAY=:0 gnome-shell", and then CTRL+ALT+F1.
Hopefully this issue is resolved soon, but until then this great little trick will save you a lot of trouble.
Nohemi
Example of typing with keyboard
With the following piece of code we can take advantage of event signals in order to emit the key press:
button.connect('button-press-event', Lang.bind(this, function () { this._key.press(); }));
There were a ton of little details in this piece of code that challenged my understanding of signal passing, but when I realized that event signals become global events once they are created that made it much easier to concentrate on the procedures that needed to be done once the event was processed.
Example of using extended keys
Uses event.get_source() in order to figure out whether a click has been directed within the extended key box or outside of it. In order to do this, however, you must push the current modal into the global stage. This is a tricky procedure, since when the modal is on the stage the focus is removed from whatever is clicked at the moment. The reason this needs to be done is because there are "holes" on the stage that don't get processed as events.
For the next week I'm going to begin working on the focus and position of the keyboard, so that it matches the rest of GNOME's layout.
Also, I want to thank Marina for a great little piece of advice for the graphics crashes that I've been having recently on my Fedora 15 system with GNOME shell:
If your system crashes use CTRL+ALT+F2, type "DISPLAY=:0 gnome-shell", and then CTRL+ALT+F1.
Hopefully this issue is resolved soon, but until then this great little trick will save you a lot of trouble.
Nohemi
Subscribe to:
Posts (Atom)