b.n. schreef: > I'm just writing it for the sake of curiosity, so no flaming is here. > Just because some answer sound quite "sarcastic", but that's just a > style thing to get it short. :) > >> Yes, but you then have bloat (because Konqueror contains web >> browsing features that you are not using, therefore the code is >> unnecessary for you, but nonetheless present). > [...] >> Code, code, code. Bloat (for me). > [...] >> Fine, I can turn them off, but again, there is then a whole lot of >> backend code for a feature that I do not want in the first place >> and know I don't want. > > Ehm. Perhaps it's me being dense but: who cares about unused code? > Ok, you have unnecessary, unused code sitting on your HD: where's the > problem? You never see it.
If I wanted unused and unneccessary code sitting on my PC, I'd use a binary distribution. Why do I bother with disabling USE flags to not compile code that is unnecessary for me, if I didn't care about such things? On the rare occasions that I compile Mozilla (becoming less and less necessary, thank goodness), I compile it +moznomail, +mozcompose, +moznoirc, and -mozcalendar because I don't use those features in Mozilla, so why should I wait for them to be compiled? But I can't trim Konq down to be just a file manager (or browser, depending on which function I hypothetically like Konq to perform and which I prefer to use another application to perform). And of course, maybe I don't have so much HDD space that I want some portion of it to be used by applications that have extra functions that are unused, when that space could be used by applications that do things I *do* want. > >> I have to then spend time finding out how to disable it or avoid >> installing it. > > It's quite odd you obviously had spent the (worthwile but not > instantaneous) time to learn Linux, install Gentoo etc. but then you > can't type "emerge --unmerge kmix". Well I would if I liked KDE (and on the occasions that I have installed KDE, I've done that), but I've already objected to this idea that it's OK to install a whole complex and then have to go through it again with a fine-toothed comb to "edit it down" to something manageable. Fine if you don't mind working that way, but I do. > >>> I can't even understand what do you mean here. If you don't want >>> icons, don't put them on the desktop. It's that simple. You have >>> to do *nothing* to avoid icons on your desktop! >> >> The (presumably) default setting (since I've never touched it, and >> it is checked in kcontrol) is "Show icons on desktop". There are >> then two additional tabs for kinds of icons that you can enable or >> disable (for file types and drives). > > But if you don't actively link things on the desktop, *nothing* > appears on your desktop!! That's not the point, which is where we have a failure to communicate. Openbox and FVWM-crystal (and ICEwm, for that matter) are lighter, faster desktops than KDE partially because they do not contain the code to put icons on the desktop (whether I enable it in KDE or not). If I suddenly change my mind and want icons on my desktop, I have to install idesk or something. That's the way (unh-huh, unh-huh) I *like* it. If I want an application to perform a function that I want or need, then I install it. If I don't want or need the functionality, it *is not present*. > >>>> I have no interest in going through 6 tabs to specify Window >>>> Behaviour (I'm looking at the KDE Control Center right now). >>> >>> Ok, that's a good point. However that 6 tabs are more probably >>> than not a wrapper to a plain text config file, that you can >>> configure with your favourite editor all at once. >> >> Code for a gui function that I'm not using if I'm just editing the >> base text file anyway. > > ? Same as before. If I'm going to be editing the text file, all I need is nano (which I already have). So the code to create, manipulate and draw those tabs and their functions in the KDE control center is unnecessary. But developers have spent time to write it, and debug it, testers have spent time testing it, and I've spent time compiling it... and they've all wasted that time with respect to me, because I'm not using it, I'm just editing the text file in nano (which I already had). So for all of me, they could have done something else with that time (like make the code modular, so if I didn't want it, I could disable it with a USE flag or something, or of course, not include it at all, since I find Devilspie works just fine to control my windows if I need to do that for some reason, or just tell me where the text file is and how to edit it, like the FVWM man pages do, so I use the internal settings to control my windows if I want, but don't have a whole GUI that I find unnecessary to do so). > >> Yes they work fine, but they look like poop unless you jump through >> some hoops to "integrate" them with the look of your KDE desktop. >> This may involve installing additional applications (gtk-chtheme >> or gtk-engine-qt), or editing a text file (if you need to "fix" GTK >> 1 programs, which are generally not affected by the "theme >> consolidation" programs, which generally assume you're working with >> GTK2). Since one of KDE's big selling points is an integrated >> look-n-feel, "outside" apps that break the loveliness of the KDE >> desktop are very noticeable. > > This is one of the things I really have never understood. 1)On a, > let's say, fvwm or fluxbox desktop (the one I actually use at home, I > am a KDE user at work), no app is integrated with nothing. So the > situation should be worse. In some respects, it is (since there is no base consistency between applications demanded by the desktop in the first place). But because flux and fvwm don't have a whole "environment" to be consistent *to*, in some respects it's less noticeable, unlike running "nautilus --no desktop" under KDE, where its going to be very obvious that Nautilus looks and works much different from your KDE desktop and other KDE apps you might have open at the time. > 2)GTK apps look different from KDE apps. So what? gmplayer or xpdf > aren't similar to both. What's so bad in them being different? A lot of people care about this, both users and developers; It's a little issue known as User Interface Consistency, which people seem to find very important for new and/or inexperienced users (for experienced users it's more of an ongoing annoyance than a show-stopper, I think). Certainly programs exist to resolve that, both KDE and GNOME developers spend time migrating to the freedesktop.org standard to resolve that and users ask questions on this and other forums asking how to resolve at least the presenting visual issues. Myself, I generally try to solve the issue by sticking to one toolset, but that is not always possible. And it is annoying... if I use Krusader, and want to show hidden files in my home folder, the command or menu item to do that is in a different place than where it is in Nautilus or another GTK-toolset file manager or file browser for open/save dialogs. That means I have to *stop what I'm actually doing* (viewing my files) and think about which fm I'm using and remember that this one does it this way (as opposed to the one I usually use) and then go back to what I'm doing. It interrupts the seamless flow of your task, and people object to that to a greater or lesser degree, depending on how much interruption they can support before the task becomes unperformable, or more difficult to perform than the task is worth. > >> I don't even type things like that, I bookmark locations in my file >> manager (admittedly, Krusader, if installed with konqueror >> support-- which means I have to install Konq, though I don't use >> Konq-- does recognize kioslaves, so I can bookmark folders in >> media:/ or smb:/ ) and just go where I intend to go. without >> further ado. But I can bookmark locations (even Samba shares and >> HAL mounts) in most file managers I have available (Nautilus, >> Krusader, TuxCommander, emelFM2) > > Hmm. So you mean, for example, you can bookmark a location that shows > you all SMB-connected PCs on your local network? How do you do this? > Even for not-smbmounted shares? I am not a network admin with 500 PCs under my purview, nor am I an office worker sharing contacts or sensitive data with a team of co-workers who may often move or change. I am a home user with one Windows PC in my network-- my boyfriend's, whose desk is right behind mine. So I know exactly what is shared, I know what the hostname of the sharing PC is, and the shares are defined to places I might need to go to drop him a file I downloaded, rather than his entire PC. So I can of course bookmark these locations on my network because I'm not guessing where I'm going; I'm going to "Jord's desktop", or "Jord's music folder" or wherever. Certainly others in different situations have other needs, but a standard "family network" is not such a weird and outré thing that it should suprise you that the filemanagers for the two big "average user" DEs have internal support for the type of users that might do things like bookmark locations in a file manager (I suspect a network admin is less likely to operate that way than someone like me is). Both Nautilus and Krusader support remembering what computers are in my workgroup and connnecting me to their mounted shares, but they do this in different ways. > > Anyway (apart from the code thing, where I am very curious) I > understand your philosophy. Thanks, > > m. -- gentoo-user@gentoo.org mailing list
