From kde-devel Tue Jun 30 03:41:12 2009 From: "Aaron J. Seigo" Date: Tue, 30 Jun 2009 03:41:12 +0000 To: kde-devel Subject: Re: Techical Reason Why Konqueror File Management Engine Can't be Message-Id: <200906292141.12858.aseigo () kde ! org> X-MARC-Message: https://marc.info/?l=kde-devel&m=124633338601152 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0791001827==" --===============0791001827== Content-Type: multipart/signed; boundary="nextPart65616624.UTU9Zp4Ujv"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart65616624.UTU9Zp4Ujv Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Monday 29 June 2009, David C. Rankin wrote: > Is there some reason the konqueror file management engine ( "backend" or > whatever you want to call it) in kde4 cannot be restored to the kde3 > konqueror file manager engine instead of the dolphin backend? There are first, David, this is not a "my list of bugs" discussion list. you're going= to=20 end up frustrating people by treating it as such, and i don't blame them. i= t's=20 a misuse of the resource. now, as for "why is kong file manager engine replaced with the dolphin one"= ..=20 well, let's not rewrite history: konq's views were already being rewritten= =20 before dolphin came along to use the model/view architecture. this was goin= g=20 to happen regardless of dolphin being there or not. dolphin's views were also rewritten because, well, it shared this effort. when dolphin came along there was ~1 person working on the file management= =20 stuff. when dolphin came there were a few more people doing so. things woul= d=20 be _worse_, not better, without dolphin because the move to m/v was already= =20 underway. why? because it results in less code duplication, greater consistency, allows fo= r=20 greater speed in certain kinds of operations and is easier to maintain. tha= t=20 was a decision that the konqueror maintainer made before dolphin arrived on= =20 the scene. given that i can now delete huge numbers of files in a reasonable time fram= e=20 and have several rather nice features due to how painting is handled in m/v= ,=20 not to mention consistency between different views even in different areas = of=20 the UI (e.g. file dialog) the downside is that there was quite a few years of features added to the=20 konqueror views, many good and many not so good. some of these have made it= =20 back in, some will in the future and some simply won't depending on the mer= it=20 of the feature. > Restoring correct konqueror focus handling would also greatly improve the > ability for people with disabilities or an unsteady hand to use it as wel= l. > With the konqueror file management backend, you set focus on a file witho= ut > activating it by clicking "anywhere" in the blank space between the end of > the file name text and the "size" column. That was a big target and > sufficient real-estate for people to hit who had unsteady hands or impair= ed > vision. That's now broken and you have to be able to hit that tiny icon > just before the file name to accomplish the same thing. you actually don't have to hit the icon. you can right click on the icon, y= ou=20 can rubber band it. but yes, hover-to-select would be a nice feature to hav= e=20 back. > I'm doing my best to understand why all of this stuff is still broken on > the eve of the .3 release, and I am doing my best to help fix it (38 bug > reports in 30 days) filing reports is great. using those reports to needle developers isn't. an= d=20 in the end it takes patches to fix things. =20 > developers take the position that "yes, we know what you could do with > konqueror in kde3, we know you can't now, but that isn't a 'bug', that is= a > 'wishlist' item." Huh?? as Ivan and i both explained: "wishlist" is what bugzilla calls "feature=20 requests" and we keep feature that need implementing separate from features= =20 that need fixing. it's part of our development work flow. you are reading f= ar,=20 far too much into this and in the process wasting time and energy that coul= d=20 be spent on more productive things. > Is mediocrity the new gold standard for kde? that question is flame bait, insulting, and insinuating. do better than thi= s,=20 please. > With kde3 shut down, one > would think more emphasis would be placed on making sure its functionality > at least existed in kde4 as a priority and not simply an afterthought. you will find that every single release of kde4 has seen more of the good=20 features that were in kde3 but not in kde 4.0 emerge.=20 > functionality issues that seem to be completely overlooked, swept under t= he > rug, or basically ignored in a rush to get the glitz and glamor aspects of > kde4 ironed out.=20 the word is "seem". assigning motivation to people's actions you have littl= e=20 insight into is a perfect way to lose your message on them. your analysis i= s=20 pretty much wrong, but i don't think your analysis was needed in the first= =20 place. you have a list of bugs, great .. let's fix them! and the "let's" includes= =20 you. > I don't know what it will take to get the attention focused on these type > of problems,=20 writing code. > Now I know this post will piss 1/2 the readers off and garner agreement > from the other 1/2, you've neither pissed me off nor garnered my agreement. it is clear to me t= hat=20 you want various changes made, what isn't clear to me is that you have any= =20 personal commitment to making that happen. it's personal commitment that ma= kes=20 change happen in f/oss. we used to just call it "scratching an itch". many= =20 thing have changed since kde3, haven't they? ;) =2D-=20 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 Software --nextPart65616624.UTU9Zp4Ujv Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEABECAAYFAkpJiVgACgkQ1rcusafx20MNrwCgqFGXc7XkCLcyNNE6xpFGnNkY Yw0An2NCHZMDMVz9SEFlJsBjr1sYBlkn =HRVJ -----END PGP SIGNATURE----- --nextPart65616624.UTU9Zp4Ujv-- --===============0791001827== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << --===============0791001827==--