Refacor of our GUI Keyboard for allowing native onscreen keyboards #1194

Merged
merged 5 commits into from Aug 1, 2012

Conversation

Projects
None yet
3 participants
@Memphiz
Member

Memphiz commented Jul 21, 2012

This splits our GUIDialogKeyboard.cpp approach into some classes for allowing the implementation of native onscreen keyboards (mostly interesting for touch devices).

Therefore:

  • add guilib/GUIKeyboard.cpp/.h - this is the baseclass each onscreen keyboard has to implement
  • move the GUIDialog/Keyboard out of dialogs/GUIDialogKeyboard.cpp/.h to dialogs/GUIDialogKeyboardGeneric.cpp/.h
  • move the rest (all the static ShowAndGetInput methods) to guilib/GUIKeyboardFactory.cpp/.h
  • make all keyboard users use the CGUIKeyboardFactory class for accessing keyboard functions
  • add implementation for native onscreen keyboard for ios

Well i know its not bisectable - but i tried hard and didn't come up with a solution because of the trickyness :).

I have tested it on osx, linux, windows, ios and atv2. Behaviour is same like before (except ios which now has a fancy native on screen keyboard :D).

@jmarshallnz its you again i guess (sounds familiar ha? ;) ). If you remember you proposed something like this some months ago. I hope i've hit your taste...

@Memphiz

This comment has been minimized.

Show comment
Hide comment
@Memphiz

Memphiz Jul 28, 2012

Member

Ok - i have done your comments and also moved the object creation of the GUIKeyboard implementations into the factory where it belongs to (getting rid of the GUIKeyboard.cpp - only have the GUIKeyboard.h in there now).

Member

Memphiz commented Jul 28, 2012

Ok - i have done your comments and also moved the object creation of the GUIKeyboard implementations into the factory where it belongs to (getting rid of the GUIKeyboard.cpp - only have the GUIKeyboard.h in there now).

@Memphiz

This comment has been minimized.

Show comment
Hide comment
@Memphiz

Memphiz Jul 31, 2012

Member

@jmarshallnz do we want this for august merge window?

Member

Memphiz commented Jul 31, 2012

@jmarshallnz do we want this for august merge window?

@jmarshallnz

This comment has been minimized.

Show comment
Hide comment
@jmarshallnz

jmarshallnz Aug 1, 2012

Member

I don't see why not - android will mean that anything else that needs altering to make it work there can then happen in master.

Member

jmarshallnz commented Aug 1, 2012

I don't see why not - android will mean that anything else that needs altering to make it work there can then happen in master.

@ghost ghost assigned Memphiz Aug 1, 2012

Memphiz added some commits Jul 21, 2012

[ios] - add methods to XBMCController for allowing to attach an UIVie…
…w to the controller view (in our case this will be the native ios keyboard) - and for fetching the screenScale
[keyboard] - add the GUIKeyboard baseclass which needs to be implemen…
…ted for each native keyboard

        - add ios keyboard implementation
        - add generic keyboard implementation (moved code from GUIDialogKeyboard.cpp)
[keyboard] - moved the rest of the GUIDialogKeyboard (which is no dia…
…log anymore but only he bunch of ShowAndGetInput methods) to guilib/GUIKeyboardFactory
[keyboard] - change all occurences of GUIDialogKeyboard to the new ap…
…proach and removed unneeded keyboard includes

Memphiz added a commit that referenced this pull request Aug 1, 2012

Merge pull request #1194 from Memphiz/keyboardrefactor
Refactor of our GUI Keyboard for allowing native onscreen keyboards

@Memphiz Memphiz merged commit 63c8b72 into xbmc:master Aug 1, 2012

@natethomas

This comment has been minimized.

Show comment
Hide comment
@natethomas

natethomas Sep 5, 2012

Member

In messing around with the keyboard, I have a small suggestion. It seems to me that "Enter value" is somewhat dry and unnecessary in the text entry box. I would think if the box was simply left empty altogether, users would still pretty much get the point of what it's there for, particularly as they start typing.

Member

natethomas commented Sep 5, 2012

In messing around with the keyboard, I have a small suggestion. It seems to me that "Enter value" is somewhat dry and unnecessary in the text entry box. I would think if the box was simply left empty altogether, users would still pretty much get the point of what it's there for, particularly as they start typing.

@Memphiz

This comment has been minimized.

Show comment
Hide comment
@Memphiz

Memphiz Sep 5, 2012

Member

Hey nate - basically the text which is shown there differs (depends if you hit search or filter). I have pinged JoeTheFox on making the Editbox for the native keyboard a bit more fancy some month ago. (because i don't like the gap between editbox and keyboard). Maybe i can ping him about it again and see if he can make it even more native ;)

Member

Memphiz commented Sep 5, 2012

Hey nate - basically the text which is shown there differs (depends if you hit search or filter). I have pinged JoeTheFox on making the Editbox for the native keyboard a bit more fancy some month ago. (because i don't like the gap between editbox and keyboard). Maybe i can ping him about it again and see if he can make it even more native ;)

tru added a commit to plexinc/plex-home-theater-public that referenced this pull request May 19, 2014

Merge pull request #1194 from RasPlex/PR-Lowercase
Boost Set/Get/Has Properties using a better lowercasing function

tru added a commit to RasPlex/plex-home-theatre that referenced this pull request Aug 21, 2014

Merge pull request #1194 from RasPlex/PR-Lowercase
Boost Set/Get/Has Properties using a better lowercasing function
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment