8:16 p.m.
I'd like to get a release out soon. That raises the question
of what to do with the new tabbed windows.
I think the best thing at this point would be to disable
tabbed windows altogether for the release, then resume testing
and development in CVS. With the tabbed model window I don't
feel I can guarantee that it works right in all respects; and
with the tabbed script editor the issue is that the design
isn't finalized -- in particular, in respect of what happens
when you "undock" a tab.
To expand a little on the last point: right now, what happens
if you drag a script out of the tabbed editor is that you get
a window that is functionally identical to the original
single-script editor. That's a defensible choice, but it's
just one out of (at least) three possibilities. The other two
I have in mind are:
1) What gedit does: when you drag a tab out, you get a second
tabbed editor, with one tab. This means you can use the file's
tab to drag it back into the first tabbed window if you want.
2) What Talha was suggesting (I think), namely, when you drag
a file out you get a "subsidiary" window that doesn't have all
the controls of the orginal single-file window (e.g. no "Open"
or "New" buttons). And this subsidiary window should have some
sort of control that allows you to re-dock it.
Anyway, the bottom line is that I don't want to put half-baked
stuff into a release.
Allin
8:25 p.m.
On 19-03-2012, at 21:16, Allin Cottrell wrote:
I'd like to get a release out soon. That raises the question
of what to do with the new tabbed windows.
I think the best thing at this point would be to disable
tabbed windows altogether for the release, then resume testing
and development in CVS. With the tabbed model window I don't
feel I can guarantee that it works right in all respects; and
with the tabbed script editor the issue is that the design
isn't finalized -- in particular, in respect of what happens
when you "undock" a tab.
To expand a little on the last point: right now, what happens
if you drag a script out of the tabbed editor is that you get
a window that is functionally identical to the original
single-script editor. That's a defensible choice, but it's
just one out of (at least) three possibilities. The other two
I have in mind are:
1) What gedit does: when you drag a tab out, you get a second
tabbed editor, with one tab. This means you can use the file's
tab to drag it back into the first tabbed window if you want.
2) What Talha was suggesting (I think), namely, when you drag
a file out you get a "subsidiary" window that doesn't have all
the controls of the orginal single-file window (e.g. no "Open"
or "New" buttons). And this subsidiary window should have some
sort of control that allows you to re-dock it.
Anyway, the bottom line is that I don't want to put half-baked
stuff into a release.
Seems a good idea to not release the tabbed stuff right now.
Berend
8:32 p.m.
Em 19 de março de 2012, Berend escreveu:
On 19-03-2012, at 21:16, Allin Cottrell wrote:
> I'd like to get a release out soon. That raises the question
> of what to do with the new tabbed windows.
>
> I think the best thing at this point would be to disable
> tabbed windows altogether for the release, then resume testing
> and development in CVS. With the tabbed model window I don't
> feel I can guarantee that it works right in all respects; and
> with the tabbed script editor the issue is that the design
> isn't finalized -- in particular, in respect of what happens
> when you "undock" a tab.
(...)
Seems a good idea to not release the tabbed stuff right now.
I agree with Berend.
Best,
Henrique
8:58 p.m.
I also think that disabling this stuff for the next release is the best way to go.
I haven't played around with the tabbed windows yet, but I do have a couple thoughts
on the possible behavior of undocked tabs:
If I undock a tab from the main script editor and then try to open another tab in that new
window, what happens? It sounds like currently nothing does, because my new window is just
like the original (ie, untabbed) window. Would that also be the case with a second tabbed
editor with one tab?
What I'm getting at here is that I think we should avoid the potential for
proliferation of tabbed windows. In other words it seems like Allin's option 2
(Talha's suggestion) might be best. Undocked windows can't have more than one tab,
and should maybe have an obviously different look (lack of options, etc).
I hope that makes sense...
PS
-----Original Message-----
From: gretl-devel-bounces(a)lists.wfu.edu [mailto:gretl-devel-bounces@lists.wfu.edu] On
Behalf Of Allin Cottrell
Sent: Monday, March 19, 2012 4:17 PM
To: Gretl development
Subject: [Gretl-devel] grep 1.9.8, once again
I'd like to get a release out soon. That raises the question of what to do with the
new tabbed windows.
I think the best thing at this point would be to disable tabbed windows altogether for the
release, then resume testing and development in CVS. With the tabbed model window I
don't feel I can guarantee that it works right in all respects; and with the tabbed
script editor the issue is that the design isn't finalized -- in particular, in
respect of what happens when you "undock" a tab.
To expand a little on the last point: right now, what happens if you drag a script out of
the tabbed editor is that you get a window that is functionally identical to the original
single-script editor. That's a defensible choice, but it's just one out of (at
least) three possibilities. The other two I have in mind are:
1) What gedit does: when you drag a tab out, you get a second tabbed editor, with one tab.
This means you can use the file's tab to drag it back into the first tabbed window if
you want.
2) What Talha was suggesting (I think), namely, when you drag a file out you get a
"subsidiary" window that doesn't have all the controls of the orginal
single-file window (e.g. no "Open"
or "New" buttons). And this subsidiary window should have some sort of control
that allows you to re-dock it.
Anyway, the bottom line is that I don't want to put half-baked stuff into a release.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
11:25 p.m.
On Mon, 19 Mar 2012, Summers, Peter wrote:
I also think that disabling this stuff for the next release is the
best way to go.
Thanks, Peter (and Berend). BTW, "grep"?? That shows what I was
thinking about when I made my last post.
When development resumes after the next release, I think that one
question is: what do people generally expect of the behavior of a
tabbed editor? What are the dominant examples? Obviously, we're free
to depart from the norm (assuming there is one) if we reckon we have
a compelling reason to do so. But we shouldn't just reinvent the
wheel arbitrarily.
On the multi-tabbed design I'm more than usually willing to listen
to what seems right to others, since -- as I've said already -- I'm
not a great fan of tabbed windows myself. I sometimes find tabs
useful in Firefox, but that's about it.
Allin
11:54 p.m.
I use frequently the Open Source Notepad++ in Windows, and I can
detach and attach Tabbed windows easily.
I almost intrigued if you people does not know about that amazing software!
I believe that having a single "class" of windows is the condition to
have the tabbed windows attach and detach functions. Surely it will be
the easiest to code.
Hélio
On Mon, Mar 19, 2012 at 11:25 PM, Allin Cottrell <cottrell(a)wfu.edu> wrote:
On Mon, 19 Mar 2012, Summers, Peter wrote:
> I also think that disabling this stuff for the next release is the
> best way to go.
Thanks, Peter (and Berend). BTW, "grep"?? That shows what I was
thinking about when I made my last post.
When development resumes after the next release, I think that one
question is: what do people generally expect of the behavior of a
tabbed editor? What are the dominant examples? Obviously, we're free
to depart from the norm (assuming there is one) if we reckon we have
a compelling reason to do so. But we shouldn't just reinvent the
wheel arbitrarily.
On the multi-tabbed design I'm more than usually willing to listen
to what seems right to others, since -- as I've said already -- I'm
not a great fan of tabbed windows myself. I sometimes find tabs
useful in Firefox, but that's about it.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
6:37 a.m.
On Mon, 19 Mar 2012, Allin Cottrell wrote:
I'd like to get a release out soon. That raises the question
of what to do with the new tabbed windows.
I think the best thing at this point would be to disable
tabbed windows altogether for the release, then resume testing
and development in CVS. With the tabbed model window I don't
feel I can guarantee that it works right in all respects; and
with the tabbed script editor the issue is that the design
isn't finalized -- in particular, in respect of what happens
when you "undock" a tab.
I've been playing with tabs intermittently and my house hasn't caught
fire, nor my dog has been eaten by aliens. OTOH, I never set to work with
the specific intent of stress-testing tabbed windows by trying crazy
things. For these things, you need the wisdom of crowds. How about leaving
the situation as is now (that is, no tabs by default, but you can enable
them if you want) but addin, somehow, a big flashing "WARNING!
EXPERIMENTAL! USE AT YOUR OWN RISK!" sign?
Anyway, the bottom line is that I don't want to put half-baked
stuff into a release.
I hear you, but my point is that it's almost impossible for a group of
50-100 people to debug a thing like tabs to the end; you need the mass of
users to find the weird guy who tries something totally unexpected and
triggers the corner case.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
9:22 p.m.
On Tue, 20 Mar 2012, Riccardo (Jack) Lucchetti wrote:
On Mon, 19 Mar 2012, Allin Cottrell wrote:
> I think the best thing at this point would be to disable
> tabbed windows altogether for the release [...]
I've been playing with tabs intermittently and my house hasn't caught fire,
nor my dog has been eaten by aliens. OTOH, I never set to work with the
specific intent of stress-testing tabbed windows by trying crazy things. For
these things, you need the wisdom of crowds. How about leaving the situation
as is now (that is, no tabs by default, but you can enable them if you want)
but addin, somehow, a big flashing "WARNING! EXPERIMENTAL! USE AT YOUR OWN
RISK!" sign?
> Anyway, the bottom line is that I don't want to put half-baked
> stuff into a release.
I hear you, but my point is that it's almost impossible for a group of 50-100
people to debug a thing like tabs to the end; you need the mass of users to
find the weird guy who tries something totally unexpected and triggers the
corner case.
Agreed, we'll get more bugs shaken out the more people are
trying out the new code. But I don't much like the idea of
making users of an official release into guinea pigs. I think
that given some more testing time, those who use CVS/snapshots
should be able to help us get the new code into more
presentable shape.
Anyway, for now I've done two things in CVS:
* Made it so that an "undocked" editor tab doesn't have the
New and Open controls.
* Added a right-click menu item to let you "re-dock" a script
or model that has been dragged out of a tabbed context.
Allin
4414
days inactive
4415
days old
7 comments
6 participants
participants (6)
-
Allin Cottrell -
Berend Hasselman -
Henrique Andrade -
Hélio Guilherme -
Riccardo (Jack) Lucchetti -
Summers, Peter