From kde-core-devel Wed Feb 03 05:47:43 2010 From: "Aaron J. Seigo" Date: Wed, 03 Feb 2010 05:47:43 +0000 To: kde-core-devel Subject: Re: Review Request: Add "Open With" actions to KFileDialog context Message-Id: <201002022147.44768.aseigo () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=126517610620319 On February 2, 2010, marcel partap wrote: > This always has been the biggest strength of KDE3: provide all possible > functionality everywhere plausible. it was also a major blocker for many. there is ballance to be struck, kde3 got it wrong too often. > With KDE4, the opposite direction has been taken - simplicity is now > considered the sane default you've misinterpreted what's going on. where there have been lots of lacking features it's almost always been because things were being rewritten. example: the file views in konqueror/dolphin/file manager. they were rewritten because of Qt4's model/view. during that process there were fewer features. the goal wasn't fewer features, however, and as development has continued that can be quite obviously seen. usually where it _seems_ there are fewer features there are actually the same or more because those features are actually presented more ergonomically. the recent "oh no, gwenview has fewer configuration widgets in the config dialog means it has fewer features" stupidity was a great example of failing to grasp this. gwenview in kde4 has more features than in kde3. sometimes features have indeed been dropped. often this is to make way for features deemed (wrongly or rightly) as more desirable, sometimes it is because those features are simply not considered valuable enough to warrant keeping. the latter is the overwhelming *minority* situation. unfortunately, because people are attempting to analyze the situation without knowing what is the causal factors in each case they are ending up with incorrect generalizations that lead to incorrect arguments being made and people such as yourself getting annoyed without reason and then sharing that annoyance with us, the people writing the software. which SUCKS!, imho ;) > - which SUCKS!, imho. > It is always easier to > take features out than to cram everything in and still make it work > efficiently (while looking good). ime, it's easy to remove features and it's easy to cram features in. ime, it's hard to add features without making the whole thing an unmaintainable, unusable mess. and that's what we are trying to achieve. i hope you're providing patches to that end to some of the software. what SUCKS!(tm) is that when we achieve "features while still making it work efficiently" people then complain that we've removed features. when you do a feature comparison, we find that isn't the case. yet people still complain. and by "people" i mean "people who used KDE1/2/3 and now are reacting in a knee-jerk fashion" > To me, this adaption of the Win/Mac/GNOME attitude is a great loss to > KDE. you're mistaken as to what we've adopted. > Screwing the die-hard power users in favor of 'joe user' might not > hurt the market share, but it surely raises averse emotions in some. we aren't screwing the die-hard power users. you are doing yourself far too much of a kindness to say that all, or even most, die-hard power users like the kind of interfaces that were found throughout KDE3 software. i, btw, am a "die hard power user" (as are many of my close friends, some of whom use a Free O/S, many of whom do not (sadly :)) and do not count myself in your broad generalization. as for raising emotions, i agree that it does. that some people choose to dump this on us is really an unfortunate choice (it results in nothing good) and is rather uncalled for: this is a technical project, not a pottery class. > Alas, we seem to be in the minority so not much hope this direction will > change. but in the meantime, you can make everyone else's lives annoying and you can also ensure that we waste time and lose marketshare through such moaning and gnashing of teeth. how does that make any sense to you? > > it at least doesn't match the stated purpose of these dialogs. > > Well who cares about the intended purpose of the dialog indeed, why shouldn't my bicycle also be an ice cream maker? how useful, as i often bike on hot sunny days. > - if i see files > anywhere, i *expect* to have the *freedom* of applying any file > operation i might deem fit. you have expectations that are unlikely to be fulfilled. we could put every possible operation someone might deem fit in there and then it would be an awesome tool to do anything ... except what it's actually meant for. i invite you to eat your dinner for the next month with a swiss army knife. they sure are useful tools, but they make shitty day-to-day knives when the point of the tool is to actually cut your food. of course, a dinner knife that doesn't have a handle or lacks a cutting edge is similarly useless. and a dinner knife makes for a pretty survival tool. it's about finding the right mix for the context. > Not being able to do that always is a great > cause of annoyance. See GTK file dialogs, for really bad example... ^^ we offer a lot more functionality, and more importantly sane arrangement of navigational systems, than gtk+ file dialogs do or have. nobody is interested in copying that approach. btw, in kde3 could the file dialog change the size of the icons in the view? ("humorously" the option is buried in the context menu in kde3, but it doesn't actually work!) why did the kde3 file dialog have only two view types instead of the four we have now? why didn't it show automatically in the sidebar very well (if at all)? where were the file preview thumbnails? why were the bookmarks in the sidebar not available from konqueror or the kmenu? why couldn't you decide where the file name should be relative to the icon? why wasn't there an 'Add new.." ability? where was the option to have (the rather more efficient) breadcrumb widget? why isn't "show hidden files" in the context menu? why do the icons in the sidebar only have "small" or "large" as options instead of filling whatever space i give them? why, when i view properties of a directory, don't i get a nice bar graph showing me the usage? these are all things the kde 4 file dialog does that the kde 3 one doesn't or does much more poorly. why does a kde3 app always use the kde file dialog even when it's running on a completely different platform (preventing it from blending in with the rest of the environment)? you know what i *can't* do in the kde4 one? i can't always use F10 as a shortcut (this is a bug, not an intention feature; it's also a bug that came up a few times in kde3 and which i personally fixed once or twice; it's back :/) i can't set folders to not be first in the sort order. (debatable; dolphin has it, but the file dialog doesn't; probably should be added back to the kde4 fie dialog, just haven't gotten to it) i can't have a separate tree of folders to the side of the file list. this is intentional and perhaps the only feature i can see where there could be disagreement based on difference in tastes. i can tell you that not having it makes the code much more sane to maintain and when we asked around the users it wasn't a commonly used feature. so, sum up the things the kde3 file dialog doesn't do (12). sum up what the kde4 one doesn't do (3, of which 1 is a bug, 1 is a feature not added yet but which almost certainly will and one that won't). compare. for a final score we could add in "which one looks less jumbled". but let's assume that we're talking only functionality and don't care about elegance. winner is quite obviously the kde4 file dialog. to make this all the more ironic, this discussion is about a feature that kde3 didn't have either. as such, i humbly submit that your measurements of the two file dialogs do not reflect reality nor do they match what our true goals are, namely: powerful software that is still maintainable and doesn't look like crap. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks