--- On Tue, 2012/3/27, drago01 <drago01@xxxxxxxxx> wrote: > 2012/3/27 夜神 岩男 <supergiantpotato@xxxxxxxxxxx>: > > --- On Tue, 2012/3/27, drago01 <drago01@xxxxxxxxx> wrote: > >> 2012/3/27 夜神 岩男 <supergiantpotato@xxxxxxxxxxx>: > >> > --- On Tue, 2012/3/27, drago01 <drago01@xxxxxxxxx> wrote: > >> >> No. > >> > If you say so... but I'd like to point out that having a place where an application "might or might not" place some controls depending on a condition that is not obvious to the user makes me think this is some unneccessary and avoidable ambiguity in the interface, and I think that's what Tom was getting at. > >> > >> No that's not the purpose of the application menu. > >> It is about splitting application specific controls away from window > >> specific ones. Which makes a lot of sense to me. > > > > I can understand that, and leaving it up to the application is definitely the right thing to do -- but pushing it to a dock-ish location sometimes, but not always, is perhaps at least an awkward move, if not a wrong one. > > Well the "not always" is due to backwards compatibly apps have to make > use of the new API, the App menu only had a "quit" item before now we > added an API to allow apps to put application specific controls there. > > > But I can appreciate the train of thought. We'll see how it plays out. On the other hand, traditional applications have done this by presenting application-wide controls in whatever seemed the "main window" and left peripheral windows without menus or with really specific ones. GIMP is a good example of that, come to think of it. > > Sure some apps invented there own way to solve this. The application > menus are a way to standardize this so it is less "random" i.e to fix > the problem you actually complain about ;) Explained this way the situation is more clear; and thanks for taking the time to. This backwards compatibility problem is always a sticky thing and difficult to do anything about other than plan very firmly against, which is something open source projects in general have been very bad about doing lately -- particularly on glamorous projects like DEs. It seems like the higher profile, the worse this gets somehow (I'm sure there is a good, but probably unpleasantly real, explanation). What I'm really getting at is the idea of unifying architecture that is set generally in stone (or at least in hard taffy) by a principal architect, around which anything is free to happen. In the case of Gnome3 I saw some extreme inflexibility at the outset on relatively cosmetic issues (user modding was forbidden and designed against, until this policy was quietly abandoned), and on the other hand a few core usability concepts are sort of left up in the air based on backward compatibility. Granted, Gnome2 wasn't so different at the outset, but the paradigm shift from v1 to v2 was a lot less extreme (even in the plumbing), so leaving a lot of things unsaid was acceptable from a developer and user perspective. With Gnome3 there is really no connection to old Gnome at all -- and I sincerely believe this project would have found a more comfortable niche had it been named something different entirely. The name "Gnome Shell" seems to have been a compromise on this idea compared to calling it something more fitting like "Triangular Wheels" or "Hockey Cleats", but the use of the word "Gnome" promotes the Gnome3 moniker, and that promotes the idea that 3 is a transition from 2, despite that being totally wrong. We like to think that names don't mean things, but they certainly do -- consider the reason for reusing the name Gnome at all was to make it an easy shoe-in for Fedora (and later Red Hat) mainstream acceptance by promoting this very misconception, for example. The backward compatibility issue and the confusion about how interfaces are "supposed" to be designed by application developers for Gnome 3 trace back to an architectural vision that was perhaps either inadequately expressed at the outset (takes a lot of work, but then so does DE development), had its metals unsorted (as in, hard/soft decision bits were in the wrong places), or actually did not fit the market as well as was expected and is now reeling under the pressure of all the changes necessary to jam the peg into the hole it was just a little misshapen for (because turning back is not considered an option by some critical mass of stakeholders, i.e. the Microsoft/Lockheed boardroom or Government social management models). But I'm digressing. Good luck! -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
