Re: tab behaviour, was [gedit-list] gedit 2.15.2 released

[John Pye <john pye student unsw edu au>]

Hi Paolo

Paolo Maggi wrote:
> Hi,
>
>   
>> I do think that the keystroke for changing between tabs needs to be
>> shown in the menus.
>>     
>
> You are right, please file a bug in bugzilla (better if containing a
> patch).
>   
Doing that now.
>   
>> (and it should be ctrl-TAB or ctrl-PgUp, not
>> ctrl-alt-PgUp, which is a pain).
>>     
>
> As we already explained several times, this choice is not up to us.
> We are following gtk+ default.
>   
Drip-drip... :-)
>   
>> I also think that it shouldn't default to opening multiple copies of
>> documents -- it should default to raising the already-open document's
>> tab. I think that opening multiple copies of the same document is a very
>> rare use-case compared to someone opening something that they forgot
>> they had already opened.
>>     
>
> Have you tried gedit 2.14? We have changed the behavior a bit but as we
> already discussed on the mailing list and/or on bugzilla, we still need
> to tune the new behavior a bit. I think we have found a nice solution...
> wait and see :)
>   
Yes I have tried it. I'm still not really happy with it, although it's
definitely better. I would just rather disable this multiple-copies
thing altogether. I think it's an usual use-case.

Is there any way you could do a survey of what most users would like in
this regard?

My preference is for it to silently (no dialogs or warnings) focus the
already-open document. You could add a preference that said "allow
multiple copies of documents to be opened". If set true, you could have
a dialog "You have already opened filexxxx.txt. Do you want to open
another copy of the file?". Then, rather than switching to read-only
mode, a more useful general-purpose technique would be to open the file
read-write, but to check the file mtime whenever a document is brought
into focus or saved. If it's changed, there would be a dialog asking if
the file should be reverted to the (newly) saved version, or the remote
changes ignored.

As I mentioned before, this has implications when launching gedit as the
external editor or viewer for another application, eg a ctags-style
program or a find-in-files or syntax checking program, for example.


>> Regarding the 'common user': the common user for something like gedit
>> *is* a programmer. 
>>     
>
> In our opinion, the common users for gedit are:
> a. system administrators
> b. programmers
> c. people opening random README files
>   
I agree... so these are more-or-less technical people, and they'll be
comfortable with an MDI and all that.
> If you are using gedit for other reasons... well, you are on your own :)
> Actually, let us know what you are using gedit for.
>
> I think we are working well for users a, quite well for users b but we
> still fail to offer a good solution for users c.
>
> You may argue users c are very important. We agree :)
>   
How exactly do you feel you are letting down users 'c'?

Cheers
JP

-- 
John Pye
School of Mechanical and Manufacturing Engineering
The University of New South Wales
Sydney  NSW 2052  Australia
t +61 2 9385 5127
f +61 2 9663 1222
mailto:john.pye_AT_student_DOT_unsw.edu.au
http://pye.dyndns.org/