Hi,
Actually I've now managed to made it so that the screen rect stays the
same and it's now scrollable in the split view. I also disabled the
gestures and toolbar move but not the toolbar buttons.
now it works like this:
- tap it opens virtuakeyboard in split view mode.
- close keyboard the terminal returns as it was. (windowd / full screen
mode)
It still needs the scrolling since now it scrolls down to the bottom of
the terminal screen. I'll make it to follow the cursor. Most of the
implementation is in the container but I had to add couple messages that
come to appui to go through view to the container.
Br,
Risto
On 15.12.2010 6:10, Petteri Kangaslampi wrote:
Hi Risto,
That sounds great, although as a QWERTY user again not something I'd
need myself. :)
For scrolling it would probably be better to add viewport support to
the terminal control itself, so that the physical terminal size
doesn't have to mathc the control. This would also be useful for
locking the terminal size to say 80x24 even when the display is
different, something that people have asked for before -- some
programs don't really like odd and/or changing terminal sizes...
You'd probably want to support per-pixel rather than per-character
viewport positioning though to make scrolling smoother.
A reasonable logic might be something like:
- Full terminal view by default
- Tap terminal to enable split view. Position terminal viewport
initially to the half/quadrant of the terminal where the cursor is.
- Drag terminal to move viewport
- Maybe automatically move the viewport if the cursor leaves it?
- Tap to leave split view
I'm not sure what's the best functionality split between the container
and the terminal control, and whether you'd want to keep other
gestures active while in split view?
Cheers,
Petteri
On 2010-12-11 04:13, Risto Avila wrote:
Hello all,
I've managed to get the split view working. It still needs a little
work tough.
The problem with the split view is that I dont want to resize the
actual terminal to so small window so I decided to move the container
up and keep it as same size. Now where the problem comes is that when
you have just connected to ssh you might not have the cursor in
bottom of the terminal. If that's the case the screen is just blank
not showing anything. So some kind of inteligence is needed to scroll
the container up & down. I'm going to make swipes to do this in the
first round but I think in the end it needs something smoother.
todo:
1. change the container move just to y axel now its x and y and
its one pixel off
2. Disable swipes from the split view and assign up & down swipes
scrolling
3. Disable long tap, short tap, double tap, toolbar move from
split view
BR,
Risto
PS: Actually this is a quite killer feature. At least when combined
with irssi! :) irc.freenode.org #s2putty
On 1.11.2010 4:51, Petteri Kangaslampi wrote:
Hi Risto, all,
I have also had QWERTY phones as the main target for PuTTY. There is
some attempt in helping people with non-qwerty devices in the
earlier versions too, such as the send grid for quick access to some
functions, but that's a bit of an afterthought. I don't even have a
single non-qwerty phone myself. :)
Having said that, (clean) patches are always welcome, and the split
view could potentially work at least to some extent if you just kept
the terminal size as before but moved the part with the cursor in it
to the other half of the display. There is still a possible problem
with complex input from the FEP as Risto wrote -- most FEPs seem to
assume all controls are effectively editors where you can go back
and change already entered content, and that really doesn't work
with a terminal...
The best bet might be to create a better "Send line" feature for
non-qwerty devices and make it easily accessible. I generally find
it better to use "Send line" instead of writing directly to the
terminal: Network lag doesn't affect editing, it's easier to review
text and fix typos, and it results in fewer packets which reduces
network traffic.
After fighting with Avkon again for a couple of hours today I'd
fully support anybody who wishes to write a new Qt-based UI. Just
don't expect me to contribute much, PuTTY pretty much does what I
need it to do already. :)
Cheers,
Petteri
On 2010-10-27 16:30, Risto Avila wrote:
Hi,
It would be much nicer to have a transparent input layout for vkb.
Also at least I consider putty unusable with touch only device. It
needs lots of workaround to even work at as much as it works now.
E.G. the hacks in the feb buffer to "remember" what is writen until
enter is pressed == BAD FEP code. I've tried to analyze the depths
of FEP how it works and how it should work but there seems to be 0
examples 0 documentations so it's quite hard. Also space in the vkb
is quite limited to show up even a small fraction of the terminal
screen (in a readable format). I've like much much more about hw
qwerty solution in a phone where I'll be using putty but I've still
tried to make a quite simple UI for also non hw qwerty phones.
What happens when QT comes? since it seems QT is right around a
corner. Do we need a complete rewrite? at least for the UI? Should
we do it now? Is it worth our time to spend developing old FEP.
Since QT is supported by 5.0 and s^3 and will be in the future
mostlikely our only platform to support.
-Risto
On 26.10.2010 10:13, Jari Airaksinen wrote:
Hi,
Is there plans to update putty touch text input to support split
view input introduced in S^3:
http://wiki.forum.nokia.com/index.php/Split_view_input_in_Symbian_C%2B%2B_applications
Would be usefull to be able to see the lower part of terminal
window while inputting text. For example in irssi use and I quess
in many other shell usecases also.
br
Jari
------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
s2putty-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/s2putty-developers
