ubuntu-terminal-dev team mailing list archive
-
ubuntu-terminal-dev team
-
Mailing list archive
-
Message #00001
Re: Initial Discussions
Hi Evan,
Thanks for starting the thread!
2016-02-18 1:18 GMT+01:00 Evan McIntire <mcintire.evan@xxxxxxxxx>:
> First off, pot files. [...]
That's the idea.
Otherwise, we could try to "bzr revert po/" or "bzr revert
po/com.ubuntu.terminal.pot" before committing: that's what I currently
do for DocViewer, but I still forget sometimes to remove translations
from my proposals.
> Next off, we've also discussed redoing the copy/paste functionality. I think
> Stefano mentioned looking at the textbox dialog and taking inspiration from
> that. I'm not 100% sure what that looks like, but I figure it'll be similar
> to how it is on Android. Either way, we could make some mockups and the
> like. I'm not that experienced with launchpad, so correct me if Im wrong or
> there's a better way, but we could maybe consider using a blueprint to track
> progress on this? There are a few open bugs about this issue, and we could
> attach all that to the blueprint, attach the mockups, etc., but as I said,
> I'm not 100% sure.
https://imgur.com/EME6Ak0
I had a look at the Ubuntu UI Toolkit sources, and the dialog itself
is very easy to reproduce:
Popover { Row { AbstractButton { styleName: "ToolbarButtonStyle" } } })
[1], but we may want to re-think the toggle for the selection mode
(i.e. automatically activate it when a long-press on a touch device is
detected).
Anyway, I think a normal bug report is okay. They aren't complex tasks
that require a full specification, IMHO.
> I'd also like to mention Autopilot tests. We haven't had them in a long
> time, and they're a good idea to have. At the very least we should work
> towards getting all the setup logic done so the rest of the tests could be
> written.
I've heard of manual testing too and I'd like to know from Alan
further information on this.
I guess manual tests are a sort of "human-readable" translation of
Autopilot tests.
Could we decide to use Pilot app?
> I've also noticed a lot of old bugs. As part of GCI (and a bit on my own), I
> triaged some of the bugs, setting some as incomplete. I think we should take
> time to look over all bugs and make sure their status is still correct.
> It'll take a bit of work and organization, but I think we'll be able to get
> it done :)
I tried to have a look some week ago, and I guess some of the
not-triaged bugs have been fixed now.
We'd need to build an old version of terminal-app and check all the
pre-2015 reports... :)
> Last thing - when are we going to do the next release of the app? We've
> fixed and added a lot, so it'd be awesome to get a fresh new version out.
> Maybe once I finish the window sizing I've been working on, and Stefano's
> branch with gesture tutorials could be cool to have in it, but Im not sure
> how long it is until that happens.
I don't think this is really a problem. Terminal-app is just 1.5MiB,
we could release even every week.
Having a reasonable deadline (e.g. every 3-4 weeks) would help us a
lot, since we would be able to set a milestone on Launchpad and
properly track any issue we'd like to fix.
It would be great to get your window sizing work in the next release :)
Sadly, my gesture tutorial branch should wait a bit, since I'm still
waiting for the design team to update the specifications. I'll try to
ping James at the DocViewer meeting if he's around.
Other two things we'd like to do:
1) Improve the detection of the OSK. i.e. show the keyboard button and
keyboard layouts only when an OSK is active ( = device has a
touchscreen and no psysical keyboard is connected)
2) Update QmlTermWidget, and backport some of the fixes done on
Konsole and/or QTermWidget.
As I said earlier, I'm not sure we should start doing heavy changes to
its source code yet, but we have to discuss in a near future about the
possibility of forking from the parent project.
The original QmlTermWidget seems not to updated, and I saw a few forks
coming up (e.g. Papyros project [2] ).
Sooner or later, we'd like to do the same in order to complete the
transition from QWidgets to QtQuick, I guess.
Cheers,
Stefano
[1] http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/staging/view/head:/src/Ubuntu/Components/1.3/TextInputPopover.qml
[2] https://github.com/papyros/qmltermwidget
Follow ups
References