After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 676858 - Remove extra panes
Remove extra panes
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-05-26 02:00 UTC by William Jon McCann
Modified: 2016-12-12 17:31 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Remove extra panes (114.19 KB, patch)
2012-05-26 02:00 UTC, William Jon McCann
committed Details | Review

Description William Jon McCann 2012-05-26 02:00:07 UTC
Extra Pane mode was somewhat useful before GNOME 3 had side by side window mode.
The combination of panes and tabs is just too much. It is inconsistent
with the file chooser and doesn't work well with touch.  We would like to
add a more explicit copy/move feature shortly.
Comment 1 William Jon McCann 2012-05-26 02:00:10 UTC
Created attachment 215023 [details] [review]
Remove extra panes
Comment 2 John Stowers 2012-05-26 14:00:46 UTC
> We would like to add a more explicit copy/move feature shortly.

When you remove the extra pane can you please replace the functionality it provided in the move/copy to menu?

Right click -> move/copy to -> list of open nautilus windows
Comment 3 André Klapper 2012-05-26 15:10:02 UTC
How discoverable is side by side window mode compared to opening an extra pane? Maybe this could be removed AFTER you "add a more explicit copy/move feature shortly". 
Don't see a reason to remove functionality before you have a proper replacement in place.
Comment 4 Cosimo Cecchi 2012-05-26 18:01:40 UTC
Review of attachment 215023 [details] [review]:

Thanks Jon, patch looks good and works fine in my testing.
Comment 5 Cosimo Cecchi 2012-05-26 18:09:10 UTC
(In reply to comment #2)
> > We would like to add a more explicit copy/move feature shortly.
> 
> When you remove the extra pane can you please replace the functionality it
> provided in the move/copy to menu?
> 
> Right click -> move/copy to -> list of open nautilus windows

I think this is a good idea, but what Jon hints to with a "more explicit copy/move feature" would be using a file chooser (and a content chooser in the future) upon choosing Copy To/Move To from the context menu.
While the content selection designs [1] allow this to be possible, I am not sure it can be easily implemented with a regular GTK file chooser.

[1] https://live.gnome.org/GnomeOS/Design/Whiteboards/ContentSelection
Comment 6 Cosimo Cecchi 2012-05-26 18:11:39 UTC
(In reply to comment #3)
> How discoverable is side by side window mode compared to opening an extra pane?
> Maybe this could be removed AFTER you "add a more explicit copy/move feature
> shortly". 
> Don't see a reason to remove functionality before you have a proper replacement
> in place.

I'd argue it is more discoverable, since it works transparently across all applications; with backdrop state theming, the final result is pretty much the same - Nautilus was acting as a sort of second-level window manager for those panes.
Comment 7 William Jon McCann 2012-05-26 19:33:35 UTC
Attachment 215023 [details] pushed as b8d5b4a - Remove extra panes
Comment 8 Luca Ferretti 2012-05-27 13:54:11 UTC
(In reply to comment #3)
> How discoverable is side by side window mode compared to opening an extra pane?
> Maybe this could be removed AFTER you "add a more explicit copy/move feature
> shortly". 
> Don't see a reason to remove functionality before you have a proper replacement
> in place.

I agree with André, it would be good to remove a feature when a replacement is ready, not before (see all other changes applied to nautilus in the latest 2~3 days too). Also, due to our feature-based approach, should we also consider the planned feature removals in our release planning? It seems that nautilus is going to have big changes between 3.4 and 3.6, none of them announced or proposed for review during feature announce period.

About this specific change, however, I feel that side windows mode and nautilus panes are "unrelated", just like file chooser and file manager, or, better, they could and should share some content/concept/behavior but they are different tools for different tasks. But I fear this could end in a design disagreement, and it seems that maintainer was yet fine with this change :|
Comment 9 Cosimo Cecchi 2012-05-27 14:38:03 UTC
(In reply to comment #8)

> I agree with André, it would be good to remove a feature when a replacement is
> ready, not before (see all other changes applied to nautilus in the latest 2~3
> days too). 

You have to remove old things in order to have space for new things, when the two conflict.

> Also, due to our feature-based approach, should we also consider the
> planned feature removals in our release planning? It seems that nautilus is
> going to have big changes between 3.4 and 3.6, none of them announced or
> proposed for review during feature announce period.

Are you really suggesting we should have discussions on d-d-l (before the development cycle starts...) for each feature added or removed to every GNOME application?

> About this specific change, however, I feel that side windows mode and nautilus
> panes are "unrelated", just like file chooser and file manager, or, better,
> they could and should share some content/concept/behavior but they are
> different tools for different tasks. But I fear this could end in a design
> disagreement, and it seems that maintainer was yet fine with this change :|

Jon and I discussed these changes extensively before he started writing patches. Not sure why you seem to think this sort of agreement is a bad thing.
Comment 10 André Klapper 2012-05-27 14:49:27 UTC
Thanks Cosimo for your elaboration in comment 6 and answering my doubts - I  understand the change now.

Re comment 7:
GNOME's feature-based approach (and discussion on d-d-l) is for cross-module stuff while this change is Nautilus only. Summarizing changes and making them (and the background for decisions) better known is always welcome but I guess that Cosimo will probably blog about them at some point... :)
Comment 11 Luca Ferretti 2012-05-30 13:59:58 UTC
(In reply to comment #9)

> > Also, due to our feature-based approach, should we also consider the
> > planned feature removals in our release planning? It seems that nautilus is
> > going to have big changes between 3.4 and 3.6, none of them announced or
> > proposed for review during feature announce period.
> 
> Are you really suggesting we should have discussions on d-d-l (before the
> development cycle starts...) for each feature added or removed to every GNOME
> application?

No, of course. It was just a remark about how we could or should gracefully handle _major_ changes that will _remove_ features (mockups I've seen about Files are really different from current and past Nautilus).
You know that probably people will claim about some missing stuff and you, as nautilus maintainer, have the final responsability of all applied changes, i.e. you will have to explain and/or close duplicate bugs asking for feature reintegration. So, abstracting from this specific bug, is it better to announce similar planned changes before (maybe during feature announce period, just a communication about what is planned to happen, in order to help other teams to work better, for instance the documentation team) or simply blog about them later? What's your point of view as maintainer?

 
> > About this specific change, however, I feel that side windows mode and nautilus
> > panes are "unrelated", just like file chooser and file manager, or, better,
> > they could and should share some content/concept/behavior but they are
> > different tools for different tasks. But I fear this could end in a design
> > disagreement, and it seems that maintainer was yet fine with this change :|
> 
> Jon and I discussed these changes extensively before he started writing
> patches. Not sure why you seem to think this sort of agreement is a bad thing.

Uh? Where did I said that you and jon have a disagreement? I was referring to me and my point of view, am I allowed to disagree? ;)
Comment 12 Cosimo Cecchi 2012-05-30 14:56:01 UTC
(In reply to comment #11)

> No, of course. It was just a remark about how we could or should gracefully
> handle _major_ changes that will _remove_ features (mockups I've seen about
> Files are really different from current and past Nautilus).
> You know that probably people will claim about some missing stuff and you, as
> nautilus maintainer, have the final responsability of all applied changes, i.e.
> you will have to explain and/or close duplicate bugs asking for feature
> reintegration. So, abstracting from this specific bug, is it better to announce
> similar planned changes before (maybe during feature announce period, just a
> communication about what is planned to happen, in order to help other teams to
> work better, for instance the documentation team) or simply blog about them
> later? What's your point of view as maintainer?

I see where you're coming from, but it's sometimes hard to predict beforehand exactly what changes will be carried out in a development cycle for each specific module; in an ideal world, we would have a development plan set in stone months before the next release, but we all know that's not how free software usually works, as it depends on the available manpower - mostly scarce in the case of Nautilus - and the will of individuals to write patches.

I think the direction Nautilus has gone starting with the 3.0 release, is quite clear and aligned with broader GNOME 3 goals of simplification/streamlining of existing interfaces and removal of duplicate/misplaced features.
In this specific case, Nautilus panes were an unique paradigm in the whole GNOME, and in my opinion a workaround of missing support for tiling windows and backdrop state in the window manager.

As for your last question: in my experience the documentation team gets into action later in the development cycle, when changes in modules are finalized. In other words, they build upon what has been done, not upon what was planned. In this regard, a blog post summarizing changes is probably more useful for them than a development roadmap at the beginning of the cycle; I never wrote documentation myself though, so this is just my gut feeling.
The vast majority of regular users will see these changes when they hit a stable release in a distribution; I think the GNOME release notes are a good place (even better than a blog post) to explain changes to a broader audience.

> Uh? Where did I said that you and jon have a disagreement? I was referring to
> me and my point of view, am I allowed to disagree? ;)

That's not what I said, and you're surely allowed to disagree :)
I was referring to the last part of your comment #8, where I understood you were disappointed that "the maintainer was yet fine with this change". If that's not what you meant, I'm sorry for the misunderstanding.
Comment 13 Holger Berndt 2012-07-02 20:32:46 UTC
Regarding comment #6:
>Nautilus was acting as a sort of second-level window manager
>for those panes.

Cosimo, that's been claimed multiple times (funnily enough, even now in the commit message) but it's just not true. And yes, this very issue has been discussed before the extra pane went in in the first place!

The extra pane is a _default target_ for file operations. That's fundamentally different to two random windows which happen to be arranged side-by-side.

That makes it possible to copy/move to that default target with a single menu item.

But it's more general. For example, it makes it possible for Nautilus Scripts to work on two related locations.

Just to name a practical example: I have a Nautilus Script that does a diff of "the right thing" (tm). If two files are selected, it diffs those files. Else, if extra pane is active and one file is selected in each, it diffs those. Else, if extra pane is active and no files are selected, it diffs the two displayed directories.

Scripts like that are trivial to write, have nothing to do with window arrangements, and help me to get actual work done.

Streamlining and making stuff look slick is nice and all, but at the end of the day, people use a file manager to get work done, not to enjoy its look.
Comment 14 James 2012-08-30 19:26:58 UTC
(In reply to comment #3)
> Don't see a reason to remove functionality before you have a proper replacement
> in place.

I agree with this. Could this F3 removal be delayed until a suitable replacement is ready such as: https://bugzilla.gnome.org/show_bug.cgi?id=683048

Thank you!
Comment 15 Federico Tramarin 2013-02-04 09:36:52 UTC
> The extra pane is a _default target_ for file operations. That's fundamentally
> different to two random windows which happen to be arranged side-by-side.
> 
> That makes it possible to copy/move to that default target with a single menu
> item.
> 
> But it's more general. For example, it makes it possible for Nautilus Scripts
> to work on two related locations.
> 
> Streamlining and making stuff look slick is nice and all, but at the end of the
> day, people use a file manager to get work done, not to enjoy its look.

AND

(In reply to comment #3)
> Don't see a reason to remove functionality before you have a proper replacement
> in place.

I also agree. Splitting the nautilus window in two "independent" panels was a very helpful feature. Removing it just made the work harder!!!

Dear Cosimo, I completely not agree with

In this specific case, Nautilus panes were an unique paradigm in the whole
GNOME, and in my opinion a workaround of missing support for tiling windows and
backdrop state in the window manager.

and other comments.

Let for a moment avoid touch screens (sometimes people have also to work with their PC ;) ). I understand that you can place two separate nautilus windows side by side. but it is not absolutely the same thing!

- First: I have to open a new nautilus then browse to the correct folder. Then probably I could start working, after just (maybe) 10 click?!

- Second: creating scripts that works on two separate nautilus occurrence is not as easy as with two panels!

-Third: let us suppose I want to switch between my opened programs (alt+tab). Then two nautilus windows have to be always reorganized, while a single windows is there, without trouble!

- Fourth: my workstations use (as usual) high resolution screens. My laptop for example has a 1920x1200 screen. Having two windows side-by-side will make my screen full of unwanted stuff (much of them are white unused space!!!) whereas a split pane nautilus could be used unmaximized! At least one should provide the ability to place win side-by-side,  but also in the corner, for example dragging a windows in the top-right corner will resize the window to use a quarter of the screen.

If the goal of nautilus on gnome is not be powerful, also for people that use a pc as a workstation, what is it? How do you think nautilus is? If one wants a replace for the mac finder, he/she could have bought a mac! And also in that case, if he/she has to work, he/she probably immediately switch to pathfinder&c.

Remember that the split panes are not a feature people are forced to use...I know a lot of colleagues that never used the F3 switch, and who neither know its existence!!!

Thank you!
Comment 16 Paddy Landau 2013-07-01 15:19:00 UTC
I have just found out that Nautilus has lost the split panels.

This is something I use very often, sometimes with more than two panes.

Please, please, please reinstate this function.

Two (or three or four) adjoining windows are just no replacement!
Comment 17 Steven Pemberton 2013-08-08 15:03:53 UTC
I agree that this is a terribly bad development, and seriously reduces the usability of Nautilus for me. Not everyone uses Gnome 3, not veryone uses touch screens. I thought this was one of the more useful parts of Nautilus, and I miss it terribly.
Comment 18 Martin Gerber 2013-08-14 15:00:14 UTC
I also ran into this issue, and argued in https://bugzilla.gnome.org/show_bug.cgi?id=683048#c18 why removing the extra pane from nautilus is a painful and annoying loss of usability for many users. It already raised displeasure in many forums, blogs and on launchpad.

Here, I want to state another point:

Consider any software where you connect outputs to inputs: the best way to visualize this is to show up the inputs on one side and the outputs on the other side. This is just the natural way how to do this. Most file-actions interact between two places. For that reason all famous file-managers provide a two-side-mode. Further, there is a strong logical and interactive coupling between both sides which can only be achieved if both sides are part of the same window. Indeed, the interaction between both sides could even be further improved - instead of removed.

Multiple nautilus-windows side-by-side bring their own bookmarks panel, location bars and menus with them, which is confusing and a waste of space. One cannot simply run 'copy to other side', but has to drag and drop between the windows, which requires a concentrated mouse operation, and it is not clear if 'copy' or 'move' will happen. Further, if one focuses a third window and then wants to go back to nautilus, one has to bring all the individual nautilus windows to the foreground again.

Please don't think of the extra-pane as something artificial, but as the most natural way to provide interactive functionality between two places.

Further, I want to comment the original post:

>> Extra Pane mode was somewhat useful before GNOME 3 had side by side window
mode.
...and remains useful for specific purposes, for example two-place-interaction in nautilus.

>> The combination of panes and tabs is just too much.
...on which scale? This decision should be left to the user. Nobody is forced to use tabs and/or panes in nautilus, but those who use it *need* it.

>> It is inconsistent with the file chooser
...many details are different in the file chooser, and when *choosing* file(s) there is no need to split the view.

>> ...and doesn't work well with touch
...there should be some solution for touch *without* limiting desktops. Of course it is challenging to deal with keyboard-users, mouse-users and touch-users at the same time, as it requires to provide the best of each in parallel, not to shrink down functionality to the greatest common divisor. For example, in order to copy, some users press STRG+C, others use the mouse context menu, and others use a touch gesture.

>> We would like to add a more explicit copy/move feature shortly.
...I cannot see how this should work better than re-introducing and enhancing the two-side-feature in nautilus.

Finally, note that in general side-by-side windows is a nice-to-have, but indeed this concept exists already since decades (already in Windows 3.1), and still is not used frequently. Reasons are that there is rarely a need for window-interaction, and multiple windows confuse very fast (GIMP for example). Every intuitive software provides a clear somewhat fixed subtiling of a single main window. Please think of nautilus as an elegant file-manager in a single window. Please do not solely externalize file-operations into some diffuse inter-window-zigzag.
Comment 19 Paddy Landau 2013-08-14 15:46:25 UTC
I had not previously seen bug #683048. The bug has been closed as NOTABUG. I suspect that this means that the developers are not looking at neither bug #683048 nor bug #676858.

If I am right, these comments are wasted.

Do people know how to contact the developers and let them know just how much we miss the panes? Perhaps to ask them to read the comments in these two bugs?
Comment 20 António Fernandes 2013-08-14 18:29:19 UTC
A number of people do get e-mail notifications of comments to this bug report and do read them, but explaining the same thing again and again on a closed bug report would only be an even bigger waste of everyone's time.

Bugzilla is not a regular forum. It's a tracker for technical/actionable issues. A tool to get things done. The issue here has been addressed over a year ago. Concerns have been raised and Cosimo has replied to them. Philosophical debate over the options made on design/development direction is out of scope for a bug tracker and usually happens on IRC[0] and mailing lists[1], or at hackfests and GUADEC[2].

I take the chance to remind that the best way to help shape the direction of the GNOME project is to get involved[3] and engage with the community.

[0] http://wiki.gnome.org/GnomeIrcChannels
[1] http://mail.gnome.org/
[2] http://www.guadec.org/
[3] http://www.gnome.org/get-involved/
Comment 21 John Crisp 2013-12-25 13:10:10 UTC
Another useful feature I find impossible to live without removed by devs who want to FORCE me to use what they think is best.

What happened to CHOICE ? I don't use tablets or touch screens and never will. I don't want multiple panes cluttering up my desktop thanks. That's what happens to M$ users. 

No wonder Gnome suffers so much. Developers who just won't listen and always think they know best. Programs dumbed down to the lowest level. What about educating users to a higher level ? You are just treating intelligent people the same as the rest and trying to force us down to their level.

So for the others out there who think the devs are idiots :

sudo apt-get remove nautilus && sudo apt-get install nemo

Works nicely, split screen. Two fingers to the devs.
Comment 22 André Klapper 2013-12-25 13:16:21 UTC
Another unhelpful comment that created bugmail. 
John, to answer your question, see http://www.islinuxaboutchoice.com/
Comment 23 John Crisp 2013-12-26 09:42:25 UTC
(In reply to comment #22)
> Another unhelpful comment that created bugmail.

Or just that you don't want to hear criticism ?

What do you want ? A NFR that you will ignore ? How else are users expected to communicate to devs in their impervious ivory white towers ?

As it transpires, for those like me who miss the feature and think it is a massive retrograde and illogical step, I pointed out an alternative solution.

> John, to answer your question, see http://www.islinuxaboutchoice.com/

Oh, it's egg sucking time then. Pesky users.

Like I said, devs who don't want to listen and always think they know best. Last place I chanced upon had a snapshot survey suggested 75% or so against the change.

Status : Resolved, Removed
Comment 24 André Klapper 2013-12-26 17:05:21 UTC
(In reply to comment #23)
> What do you want ?

On-topic technical comments that refer specifically to this bug report ("Remove extra panes") and its scope, instead of high-level interpretations which can go to your blog or some random mailing list. They are not welcome in Bugzilla.
Comment 25 AlexLikeRock 2014-02-28 16:43:39 UTC
im fuckin angry!!! 
who is the asshole think remove extra panes.?!?!?!?!??!?!?!?!?
i need  NAAAAMEEEEE !!!!!!!!!
its basic to desktop environment. !!!!!
now to compared diferents files  between size, names, characteristics,etc.

need:
1.- resize the current window to half the screen.
2.- open exta window and  resize, accommodate windows to half.
3.- then do my thing.
4.- then closed extra window, then maximice the lonely window

all this nonsense can be avoided with a simple F3 and DO IT!! 

you guys do stupid things...
 should consult and compatible with previous versions

now i understand , why isaac de icaza leaves Gnome.
Comment 26 AlexLikeRock 2014-02-28 16:46:53 UTC
ps:
have to solve in the next update of gnome
to mark like "RESOLVED FIXED "
Comment 27 Paddy Landau 2014-02-28 17:28:30 UTC
@AlexLikeRock, please remember that people of all ages use these forums, so you need to moderate your language. Thank you.
Comment 28 Max M 2016-12-12 14:08:19 UTC
Here the first issue of this thread:
<"Extra Pane mode was somewhat useful before GNOME 3 had side by side window mode.
The combination of panes and tabs is just too much. It is inconsistent
with the file chooser and doesn't work well with touch.  We would like to
add a more explicit copy/move feature shortly">.
The following sentence:
"the Combination of Panes and Tabs Is Just too Much" 
simply shows us an intolerant dictatorial personality.
Moreover, we can record no reconsideration after a two years lasting bad feedback lists received by a great amount of disappointed users. That means you don't care at all for those who suffer your arbitrary decision.
Your behaviour can't help me feeling you're absolutely as indifferent as your Microsoft windows developers colleagues. You are regressive.
Others and I reject you, still stay endured, as we users are the weak part of it.
I hope you be daily experimenting some similar logistical annoyance for the rest of your life, what would be called "random justice".
Comment 29 Carlos Soriano 2016-12-12 14:16:17 UTC
(In reply to Max M from comment #28)
> Here the first issue of this thread:
> <"Extra Pane mode was somewhat useful before GNOME 3 had side by side window
> mode.
> The combination of panes and tabs is just too much. It is inconsistent
> with the file chooser and doesn't work well with touch.  We would like to
> add a more explicit copy/move feature shortly">.
> The following sentence:
> "the Combination of Panes and Tabs Is Just too Much" 
> simply shows us an intolerant dictatorial personality.
> Moreover, we can record no reconsideration after a two years lasting bad
> feedback lists received by a great amount of disappointed users. That means
> you don't care at all for those who suffer your arbitrary decision.
> Your behaviour can't help me feeling you're absolutely as indifferent as
> your Microsoft windows developers colleagues. You are regressive.
> Others and I reject you, still stay endured, as we users are the weak part
> of it.
> I hope you be daily experimenting some similar logistical annoyance for the
> rest of your life, what would be called "random justice".

Please keep the comments just in the technical side, only referent to this bug report and without referencing any person, otherwise you will be banned.

Thanks for keep it civilized.
Comment 30 Carlos Soriano 2016-12-12 14:19:37 UTC
Andre, can we block adding more comments to this bug report? Seems this bug report is attracting lately only non-constructive comments.

If someone wants to focus on the use cases of this and do some personal research with objective and constructive comments you will be welcome to open a new bug, but this one seems is already too much in the wrong direction and I wouldn't like to spend time in such a way.
Comment 31 Max M 2016-12-12 14:37:40 UTC
If my comment contained offensive words I'm ready to apologize. Nevertheless having read it again and again I am still not aware of that. What many other people and I are expressing is a largely shared sense of helplessness, in this thread and elsewhere all over the web, wich is just unheard, not considered. 
How could we treat the matter from a technical point of view if the decision is out of that field of possibilities?
Can you suggest me the right place where to discuss such an "ethical" matter? Does it exist really?
Comment 32 Carlos Soriano 2016-12-12 15:02:39 UTC
Max, you can use IRC (always in a constructive manner) or the social medias like G+ or mailing lists.

You have all the info on how to get in touch with us in https://wiki.gnome.org/Community/GettingInTouch/

Please, always remember to be respectful and constructive. Since you pointed you don't know what you did wrong:
"I hope you be daily experimenting some similar logistical annoyance for the rest of your life, what would be called "random justice"."

We really doesn't want bad things to anyone, desiring this is not nice to any person you direct this in the discussion.

"intolerant dictatorial personality"

Here you are pointing out personal properties, this is the opposite of what respectful means for us.

"That means you don't care at all"

You are assuming too much of our work, that is not nice neither constructive in any way.

"who suffer your arbitrary decision"

Again, is our work,nothing is arbitrary, please be respectful for the time and effort we invest.

To make it clearer, either you want to change something, and you perfectly know being constructive is the way to achieve it, or you just want to vent, which you perfectly know is counterproductive to achieve a change, and the latter is not welcome.
Comment 33 André Klapper 2016-12-12 15:07:33 UTC
https://wiki.gnome.org/Foundation/CodeOfConduct applies .
xmor@teletu.it seems to have only registered here to comment on this ticket.

(In reply to Carlos Soriano from comment #30)
> Andre, can we block adding more comments to this bug report?

How? Making it inaccessible? :)
Comment 34 Carlos Soriano 2016-12-12 15:12:12 UTC
> 
> (In reply to Carlos Soriano from comment #30)
> > Andre, can we block adding more comments to this bug report?
> 
> How? Making it inaccessible? :)

I don't know, you are the admin :D
I though it was possible to block comments, GitHub alike.
Meh anyway, I guess it's enough saying that if someone wants further constructive feedback I think is better to start from scratch in a new one instead of here.
Comment 35 Max M 2016-12-12 15:55:16 UTC
Read your comment 32.
I presume I must conform my entries to your rules and I'm going to do so.
I'm maybe going to use the link you indicated there.

Just a word to tell you I could argue on every point you spotted but I think it would take too much time and be not useful as well.
The word "attitude" was certainly more fit than "personality" to the adjectives "Dictatorial" and "intolerant".
Wishing a logistical annoyance does not mean wishing a whatever damage and, whether you did not realize it, a lot of people is really suffering annoyances for an imposed, not shared important decision. IT IS your work and IT HAS an impact on many people. Didn't you know it?

Regarding the sentences "you don't care" and "who suffer your decisions...", I can't help feeling your objection slightly oversensitive.
Don't worry any longer, I'm leaving this thread, thanks for your politeness and hospitality.
Comment 36 Carlos Soriano 2016-12-12 17:31:15 UTC
If you have any further question or disagreement with the behavior standard we expect on the community, feel free to contact me on irc.

But Bugzilla is not the appropriate place for this discussion, let's not continue here please.