| Summary: | setting 'home page' is unintuitive | ||
|---|---|---|---|
| Product: | [Applications] konqueror | Reporter: | Unknown <null> |
| Component: | general | Assignee: | David Faure <faure> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | CC: | aben, alpeterson, bismail2, corey_s, EmilJacobs, esigra, faure, fd0man, ismail, kemarken, mail, nicolas.girard, peter.penz19, siegbert.baude, sven.burmeister, talhayalta, tyrerj, wishie |
| Priority: | NOR | ||
| Version: | 1.9.3b | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Other | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Patch to for two HOME locations | ||
|
Description
dgwatson
2000-08-14 04:32:10 UTC
On Mon 14 Aug 2000 David Grill Watson wrote : >Package: konqueror >Version: 1.9.3b (KDE 1.93 Beta >= 20000807) >Severity: wishlist > >When you load up Konqy with the Web Browsing profile it just loads up a > blank window. It would be nice if (like any other browser) it would at > least load up SOMETHING. This is a 'necessary' feature. Simply go to the page you want the profile to open by default and "save profile webbrowsing". Hmm I thought this was intuitive... -- David FAURE david@mandrakesoft.com faure@kde.org http://home.clara.net/faure/ http://www.konqueror.org/ KDE Making The Future of Computing Available Today See http://www.kde.org/kde1-and-kde2.html for how to set up KDE 2 Just about to add a new bug when I saw this one. I was going to say "how come I can't have a home page AND a home directory" (Konqueror only lets you have one home URL (right?)). But I've now discovered that I can choose my page to load on starting by choosing save view profile. Conclusion: No it's _not_ intuitive. To me "save view profile" means you save your view settings like how many windows are open what size of icons you display - the stuff that's in your view menu and in the Window menu. I was completely surprised that it also means you save the current URL as a page to open. In fact for ages my Konqueror has been opening on an inappropriate page. Now I know why. I have some more ramblings which I will post as a new bug. -- davidhj@mail.com Hope it is ok to post to this address (actually this is a wishlist) the currently opened url should really be included in the "web=20 profile" so that clicking on the Home button takes you to your home=20 page when you're in "web mode" and to your homedir when you're in=20 "filemanager mode". Thanks for kde2 Yves --- The irony is that Bill Gates claims to be making a stable operating=20 system and Linus Torvalds claims to be trying to take over the world In a profile of the konqueror should not only contained the start page but also the home page. When I press the home page button while web browsing I don't want a directory listing of my local home. It would be nice to have such a feature. Matthias *** Bug 22068 has been marked as a duplicate of this bug. *** *** Bug 13410 has been marked as a duplicate of this bug. *** *** Bug 42270 has been marked as a duplicate of this bug. *** Well anyone thinking about fxing the bug or resolving as worksforme ? thinking about fixing :) Alex Don't just change it to ASSIGNED. :-) I think the intuitiveness of setting the startpage won't be there until you can fill in a URL in the konqueror's settings dialog called 'start page'. This is the way it is done in all other browsers, and it is the way users expect it to be. This start page should be profile dependent, so it can be "/home/joe" in file browsing mode and "http://www.google.com" in web browsing mode. Is anything improving for this bug in 3.2? Just curious... I think it's quite clear how to change your homepage. Problem is, I use konqueror for browsing and file-managing. Both in the same konqueror, either after each other or with tabs. So I would rather have 2 homepages. One internet homepage and ~. Or more generally I would like to put bookmarks in my toolbar. I think this is a real UI problem that needs to be addressed in 3.2. I was about to fill in a bug about this issue. Indeed, I spent a lot of time trying to set my home page (=the page that displays when I launch konqueror). As I don't use "profiles", I was unable to set it. I even wondered what was the point of this "Home URL" in konqueror's settings... Is it just to set the URL that's loaded when I click on the "home" button ? Reading what has already been said before. I found quite relevant to have 2 different "home page" given our profile : file or web browsing. Then, the question is : Should we have 2 different buttons or should the same button have a different behavior given the running profile ? Hard to decide but I'd rather choose for 1 button that adapt to the context. 2 different buttons might overload the toolbar and may not be extremely relevant : When I browse the web, I usually don't want to access my personnal folder. I think this bug is definitely a "usability" bug which should be closed before 3.2 but again, it's just my humble opinion :) I elaborated a bit more how things could be in the bug report http://bugs.kde.org/show_bug.cgi?id=42270 which is marked as a duplicate above. Boy this is an old bug. I agree that the home button should behave differently depending on whether you are in file management mode or not. I also think that file management and web browser profiles should be more obviously separated. The mixing of the two makes konqueror more confusing and bloated. I think the two profiles shouldn't share the same main toolbar, that way we can get rid of the UP button in Web browsing mode, but still have it in file management mode. It would also be nice if a lot of the irrelevant menu items/right click items, dissapeared in web browsing mode. It's just extra clutter that makes navigating konqueror slower and more frustrating. What we really need is a more editable interface, with *very* simple defaults. Look at opera web browers interface, it is so easy to add and remove buttons and arrange toolbars. No "Toolbar editor", just right click->remove to remove a button you don't want. Separation of file manager and web browser is a good thing, even if they are technically the same application, it shouldn't feel that way. Perhaps konqueror file manager should behave like it does now, able to view html and all that, with all the file management options available. But make Konqueror Web browser "appear" to be totally separate, and only have options relating to web browsing in it, so there is no confusion. I almost thought about making a khtml web browser based on the khtml part, just as proof of concept (actually I did start making it...).. Call it "KDE Web Browser" instead, and leave Konqueror to identify the file manager > that way we can get rid of the UP button in Web browsing mode, but still have
> it in file management mode.
What a stupid idea! The Up button is very useful and I miss it in web browsers that do not have it. You do know that web servers also have hierarchical filesystems, right?
> ------- Additional Comments From sigra home se 2004-04-19 18:35 -------
> > that way we can get rid of the UP button in Web browsing mode, but still have
> > it in file management mode.
>
> What a stupid idea! The Up button is very useful and I miss it in web
> browsers that do not have it. You do know that web servers also have
> hierarchical filesystems, right?
As a professional web site developer and user, I think it's a very
reasonable idea to remove the "Up" button from the browser default
toolbar. I rarely think to use it. This might be because it's not there
in Mozilla, Firefox, Galeon, Safari and IE.
I think it's a good idea for the feature to /exist/-- I know some find
it useful. Let those people add it to their own toolbars.
I think it can be confusing, which is a reason not to include it by
default. While websites do have a hierachical structure, going up a
directory provides no assurance that you'll land a place that makes
sense relative to where you were.
Mark
I'm a professional web site developer and user as well, and I use the "Up" button often. I think it should be kept in the default toolbar, since it has to be there for file management. Changing the toolbar too much between file management and web browsing can be confusing. And the two are pretty much the same in most cases -- going from file to file, up and down in a folder hierarchy. The "Up" button is a navigation tool, and can be very useful no matter how you see the files (as files or as rendered html). On 19 Apr 2004 16:07:02 -0000, aZaZeL <morpheus_2606@yahoo.com.au> wrote: > Boy this is an old bug. I agree that the home button should behave > differently depending on whether you are in file management mode or not. > I also think that file management and web browser profiles should be > more obviously separated. The mixing of the two makes konqueror more > confusing and bloated. I think the two profiles shouldn't share the same > main toolbar, that way we can get rid of the UP button in Web browsing > mode, but still have it in file management mode. nod wrt removal of up in web browse mode. > It would also be nice if a lot of the irrelevant menu items/right click > items, dissapeared in web browsing mode. It's just extra clutter that > makes navigating konqueror slower and more frustrating. agreed. > What we really need is a more editable interface, with *very* simple > defaults. Look at opera web browers interface, it is so easy to add and > remove buttons and arrange toolbars. No "Toolbar editor", just right > click->remove to remove a button you don't want. Separation of file > manager and web browser is a good thing, even if they are technically > the same application, it shouldn't feel that way. couldn't agree more. and yeah ur right, operas drag and drop editing awesome. > Perhaps konqueror file manager should behave like it does now, able to > view html and all that, with all the file management options available. > But make Konqueror Web browser "appear" to be totally separate, and only > have options relating to web browsing in it, so there is no confusion. I > almost thought about making a khtml web browser based on the khtml part, > just as proof of concept (actually I did start making it...).. Call it > "KDE Web Browser" instead, and leave Konqueror to identify the file > manager i think having some visual aid to the user to tell him what the current mode is would probably do. and having the profile change when u switch to browsing dirs is an absolute must. Alex (who's a user rather than a devel for the moment) > What a stupid idea! The Up button is very useful and I miss it in web browsers that do not have it. You do know that web servers also have hierarchical filesystems, right?
You can add it back if you wanted to. And no, most web servers are not hierarchial in nature. Not since 1998 or so. The advent of dynamic content mostly killed that off. The up button in today's web is something only a handful of people will use.
> And no, most web servers are not hierarchial in nature. > Not since 1998 or so. Nearly every website on the Internet is at least 1-level hierarchical, in that http://hostname/ will be the home page, and http://hostname/some/path/ will be a subpage of that page. Even naive users understand this convention. I often use this to go directly to the home page of a site: it's easier than hunting around the page for a "home" link, or hand-editing the URL. But my particular habits are not that important. The following seem clear: 1. In practice, naive users will not use the "up" button on web pages, simply because most other web browsers do not have it. 2. Expert users will be able to add the "up" button to their toolbar by using "Settings" -> "Configure Toolbars...". The question then becomes: which is the more usable default setting for naive users? Is it more confusing for a naive user to have the "Up" button disappear and reappear when moving between file management and web browsing, or is it more confusing to have it there all the time? Keep in mind that having the "up" button disappear/reappear will shift the spatial position of *all* the other buttons on the toolbar. A user who is accustomed to clicking "back" and "forward" based on muscle memory --- which even naive users do --- will curse the Konqueror designers every time they click "forward" when they meant to click "back". For this principal reason, I think the "up" button should be left as is. Changing gears a bit, w.r.t. "home directory" vs. "home page", I think the right thing is to add a separate "start" button. The home button would always take you to your home directory. The start button would always take you to your start URL. This is better than the "modal home button" suggestion because modal interfaces are usually confusing. How exactly should a modal home button behave? It is possible to browse remote URLs in file views, and local URLs in HTML views. It is not clear what the behavior of the "home" button should be in such cases. Should the home button take its URL from the most recently loaded view profile? That's still more hidden modality. I'd love to hear a suggestion as to how to make that setting intuitive in the Control Center. Furthermore, it seems safe to say, based on comments on this BR, that only expert users grok view profiles. Separate, global "home" and "start" URLs would be completely orthogonal to view profiles. Once the concept of "start URL" exists, a way to make it interact "properly" with view profiles is as follows: 1. Currently, view profiles have a boolean option: "Save URLs in profile". This should be changed to a 4-state option, with the following states (settable per-profile): When activating this view profile: o Go to my home directory o Go to my start URL o Go to a custom URL: [xxxxx] o Do not change the URL. where [xxxxx] is an input field whose initial value is taken from the current URL at the time the user brings up the dialog box. 2. Obviously, the default setting for the filemanagement view profile should be "Go to my home directory", and the default setting for the webbrowsing view profile should be "Go to my start URL". 3. Some GUI should be added to configure the "start URL". (To avoid confusion, perhaps the "home URL" should not be configurable, or should be hidden in an "Advanced" sub-dialog box?) The above solution has the following good points: + It gives naive users an easily settable start page for web browsing. + It minimizes the modality of the interface. + It interacts naturally with the existing framework for view profiles, without forcing naive users to deal with view profiles at all. It has the following bad points: - Users may be confused by the distinction between "home URL" and "start URL". To ameliorate this problem, I suggest that 1. the terminology "home directory" be used for the home URL, 2. the terminology "start URL" be used for the start URL, and 3. since few users have cause to customize their home directory, this setting should be less accessible than the "start page" setting. p.s. Maybe I'm just strange, but I use the "home" button to go to my home *directory* from the web browser profile all the time, to look at downloaded files etc. > 1. Currently, view profiles have a boolean option: "Save URLs in profile". This should be changed to a 4-state option, with the following states (settable per-profile):
>
> When activating this view profile:
> o Go to my home directory
> o Go to my start URL
> o Go to a custom URL:
> [xxxxx]
> o Do not change the URL.
>
> where [xxxxx] is an input field whose initial value is taken from the current URL at the time the user brings up the dialog box.
>
> 2. Obviously, the default setting for the filemanagement view profile should be "Go to my home directory", and the default setting for the webbrowsing view profile should be "Go to my start URL".
>
> 3. Some GUI should be added to configure the "start URL". (To avoid
> confusion, perhaps the "home URL" should not be configurable, or
> should be hidden in an "Advanced" sub-dialog box?)
Sounds like a winner to me.
Mark
>The up button in today's web is something only a handful of people will use. HOW do you know that? Kde needs some way of tracking user behavior before statements like these should be made. Hopefully comment #22 might actually start to get this 'bug' somewhere, as it was reported in ... the year 2000 - KDE 1.93 Beta ... >A user who is accustomed to clicking "back" and "forward" based on muscle >memory --- which even naive users do --- will curse the Konqueror designers >every time they click "forward" when they meant to click "back". Yes it could indeed mess with heads! I actually believe that if someone has no clue about the up button, it might be pressed out of curiosity to have it's effect observed, one might actually learn to appreciate it's presence, or perhaps that believe itself is naive? Konqueror revolves around two major parts which will always define it's ultimate strength: 1 - It's a filemanager 2 - It's a browser All the rest is more or less great extra bonus stuff which always revolve around one or both of these 2. Therefor I agree with comment #22 especially the last p.s. point: >p.s. Maybe I'm just strange, but I use the "home" button to go to my home >*directory* from the web browser profile all the time, to look at downloaded >files etc. This goes visa versa actually. If your file browsing anywhere, sometimes you would want to click the home button to go to your start URL. This would suggest having two 'home' buttons always present. Somehow something is illogical about the GUI. It is there to browse for files AND the web, yet one can only go to a home or start point of either one at any time. The question I want to bring up is: if Konqueror is both a file manager and browser, how come that if I am file managing, there is NO SINGLE OBVIOUS way, no single option or button which makes this great application go to my start URL? It seems such essential functionality, yet it is not possible. A strange thought when actually file managing and browsing are supposed to be so blended in Konqueror. One could argue for two home buttons, or if the home button is hold down (like the back and forward buttons) pop up a menu which holds: home directory, start URL or something like that? Frankly, the reason WHY other browsers do not have an up button in their toolbar, is also likely because there is no other browser who has AS MUCH file management functionality connected to it as Konqueror has. In other browsers it feels just unnatural to think of file browsing at all, where in Konqueror it's completely normal. Therefor to compare these things seems unfair, since Konqueror IS not just a browser but actually much more and therefor it HAS to have at least some difference in GUI compared to 'general' browsers, unless it chooses to completely separate Gui's which in my oppionion would in turn weaken the interoperability and strength of file and web management accessible trough one the same application. Just as much a challenge developing Konqueror as both a file manager AND web browser is, just as much is the challenge for GUI designers. The challenge is to come up with a good GUI where the two Konqueror modes can blend really well. GUI designers can talk allot about bad GUI, but it seems to me this Konqueror is actually a great challenge for GUI designers. Any failure in good GUI design is also their failure at suggestion or correction, it's not always just the developers to complain about. To summarize and challenge this 'bug'; in what holes are the big mouth GUI experts hiding? Personally I never use file management and web browsing at the same time in konqueror. I use it as a web browser when I'm web browsing, and if I want to manage files, I load it up in file management mode. These two things *are* separate cognitively, and I think should remain separate (at least by default). I think we should somehow work out and define: a) what expert/power users desire out of konqueror b) what average "normal" users desire out of konqueror, and set this behaviour as the default. It should then be easy and quick to alter konqueror's behaviour/toolbars so that expert/power users can have it how they like it. Perhaps if you open Konqueror in file management mode, it stays in file management mode, even if you view html. This is okay, because HTML viewing can be thought of as embedding the web browser into the file management view, just like embedding a pdf file, a kword file, or a text file. Then, if you open konqueror in Web Browser mode, it opens up in a "Pure" Web Browsing mode, where all the options in the menu's, toolbars, and right click menu's, relate to Browsing the Web. Even going to "Settings->Configure Konqueror", should be changed to "Settings->Configure Konqueror Web Browser" (for example, could also be "Settings->Configure Web Browsing" or whatever), and that brings up the konqueror config dialog with ONLY web browsing options available. The "throbber" (thingy in the right hand corner that animates when konqueror is doing something) in pure web browsing mode should be different to reflect the fact that it is in web browsing mode. The "Home" button in web browsing mode, should have a different icon; perhaps a house but with a globe overlaid onto it somehow. In the caption in the title bar, it should say "- Konqueror Web Browser" and "- Konqueror File Manager", not just "- Konqueror". On my quick launch I have an icon for konqueror web browser (a globe with gears around it), and an icon for Konqueror file manager (a house). This is by default in mandrake, and shows the cognitive separation of tasks. I predict (at least from my own experience), that most people will not think of browsing the web when they click the house, and vice versa when clicking the globe. The merging of these tasks (at least in the UI) is confusing and clutters the interface. >The merging of these tasks (at least in the UI) is confusing and clutters the interface
However, one can stubbornly argue to what extend simply current present weak GUI design simply presents this as a fictional 'fact' in the first place.
But nevertheless, Konqueror allows tabs for both file management and web browsing (to name just 2) within the same window. Thus complete separation can be desired, but always boils down to: apparently hiding some real core strengths of the application where the argument can always remain that ineffective GUI design in the first place 'forces' this separation.
If I lookup 'browse' using KDict, WordNet (r) 2.0 says:
3: look around casually and randomly, without seeking anything in particular; "browse a computer directory"; "surf the internet or the world wide web" [syn: surf]
And there is the definition of Konqueror, it can browse almost anything. A true browser as in, not just HTML. Some applications browse the web, others browse file systems and others browse both and many more. The GUI, ideally, should be able to mirror that strength, lest it weakons it's true powers. Can one argue that the REAL challenge here lies in having a (to some extend) cross purpose GUI and that separating GUI is the weakest way out?
To keep this BR on-topic, I have filed the following bug: Bug #80018: stronger distinction between file management and web browsing modes (wishlist) http://bugs.kde.org/show_bug.cgi?id=80018 Please take the "separate Konqueror into two apps" discussion to this BR, where it can be discussed and voted on separately. As for the "Up" button issue, please take this discussion to the following BR: Bug #70506: In web-browsing mode, the up button should be removed (wishlist) http://bugs.kde.org/show_bug.cgi?id=70506 My comment #22 is a fairly conservative extension that builds on previous ideas on this BR, and will (I believe) solve this particular BR. I suggest that further talk on this BR be limited to *specific suggestions* that address *only* the home page problem. »I think the right thing is to add a separate "start" button. The home button would always take you to your home directory. The start button would always take you to your start URL. « I agree. I would like to have this too. I have a selfmade start-page for webbrowsing that has all the links on it I commonly use. It's annoying not to be able to get back to this page easily. I too believe that changing the meaning of the "house-button" with changing profile is confusing to most users, including me:). Remeber: konqueror usually make "the right thing" for a user that is not aware of the actuall profile. heh.. I'd call this a bug Interesting comment about Konqueror web browser in a review of SUSE Linux 9.1:
"Further issues relate to the browser software included with SUSE LINUX 9.1. The Personal edition includes only Konqueror, which, although it is maturing rapidly, may not be ready for heavy personal use. In particular, its file manager heritage makes it hard to adapt to as a complete browsing solution. Clicking the "Home" button takes the user to their home folder, not a favourite website, and although this setting can be reconfigured, it also, naturally, -affects the file manager as well. Similarly, clicking on the Konqueror icon on the toolbar, or launching the application from within the menu system ("Web Browser") opens a blank window, with a helpful message in the status bar at the bottom of the screen that there are "0 Items - 0 Files (and) 0 Folders". Even the address bar has an icon of a folder visible, adding to the impression that Konqueror is really just a file manager. New users looking for a web browser may well give up in confusion. On the positive side, Konqueror renders most web pages perfectly, integrates tightly with KDE, including its password manager and download manager, and has plug-ins like Flash and Java pre-configured and ready for use."
http://www.desktopos.com/sections.php?op=viewarticle&artid=19
I guess the question is, do we want Konqueror to be able to be a fully fledged stand-alone browser able to compete with Mozilla, firefox etc? or is it a File Manager that can also render web pages?
As I said earlier here and as I believe to be true: using KDict, WordNet (r) 2.0 says for the word "browser": look around casually and randomly, without seeking anything in particular; "browse a computer directory"; "surf the internet or the world wide web" Konqueror is designed technically to be capable of browsing pretty much anything. The only "failure" and the only REAL challenge here is it's own "GUI Design". MS Explorer is a browser and a file browser also, but Konqueror is even more. Yet from a GUI design point of view, Konqueror GUI Design is behind it's technical design, there is in-balance. So in my oppinion the question is not: "do we want Konqueror to be able to be a fully fledged stand-alone browser able to compete with Mozilla, firefox etc? or is it a File Manager that can also render web pages" No, I believe the question is: "why do http://accessibility.kde.org/ and http://usability.kde.org/ fail to connect/relate to end users more effectively?" Visiting those sites makes me want leave them again quickly, they are appalling in their own purpose of design. Konqueror is a universal browser designed just for that and it's GUI design challenge should naturally align to this approach by being designed from a universal design point of view. A challenge for GUI design. These sites lack vision, or at least the presentation of vision trough the collective power of it's users community. This 'bug' will never be solved here. This bug should not be discussed in some 'obscure' bug reporting system or only on 'un-ordered' mailing lists. GUI is something very visible to which many users can contribute ideas. These sites fail miserably at their own accessibility and usability. That's the real problem from preventing solution to this issue in a more wide and public way. I believe that the fix of assigning different URLs for HOME based on the Profile which is loaded is a reasonable solution. I won't use this, but it appears that it won't cause me any problems since I can still configure it as though there weren't different profiles for Web and File. I also note that the KCM modules do need some work since they arbitrarily separate Konqueror into Web and File when this isn't the way that it actually works. There should actually be four classes. General, File, KHTML & Web. -- JRT I beleive that the fix of assiginig different URLs for HOME based on the Profile which is loaded is a reasonable solution. I won't use this, but it appears that it won't cause me any problems since I can still configure it as though there weren't different profiles for Web and File. I also note that the KCM modules do need some work since they arbitratly seperate Konqueror into Web and File when this isn't the way that it actually works. There should actually be four classes. General, File, KHTML & Web. -- JRT In reply comment #33; the ability of assigning different URLs for the HOME button for each profile seems like a good solution to me. In addition to this solution, it might then also be nice to add a menu for the home button (just like with the forward and back buttons) which would simply show the home URLs of all profiles present at the time. This way when your in filebrowsing mode, simply clicking on the home button would always go to the home URL of the filebrowsing profile. But if you would hold the home button down, you could pick the home URL of your web browsing profile (or any ex-histing profile for that matter). The same would work when in web browsing mode, showing all home URLs for the other view profiles. It would work in any profile for that matter. This would increase the ability and usability of hopping quickly between view profiles (home URLs). Just wanted to explain why I'd be strongly against a solution as explained in comments #33 and #34; Konqueror has the unfortunate habit of launching in web-browser mode when called upon via "konqueror" in the command line or via ALT-F2. The problem with that is that people (like me or any new user who knows that the file manager is called konqueror) will be starting konqui this way to browse their files. Where I'm working there's mostly no Icon for a root Konqueror linked somewhere that opens the file management profile. So I run it via ALT-F2 or from a root shell - with "konqueror" like most people would. Since it opens the web browsing profile by default (a very unfortunate decision since it should be seen as a file-browser first) I have to either - switch to file management mode via Settings -> Load Profile -> File Management - enter a path in the address field - press the home button Guess what's the fastest (yeah some will say entering the path, but remember the user has the hand on the mouse since Konqueror is used with that ;)). Changing to a behavior as described in comment #33 will only further underline the I'm-a-webbrowser-damnit feel of Konqueror and make file management unnecessarily hard. Hmm.. I thought that everybody would agree with comment #34 but comment #35 proves me wrong :) I personnally think that the solution given by comment #34 is just perfect ! "Simply clicking on the home button would always go to the home URL of the filebrowsing profile. But if you would hold the home button down, you could pick the home URL of your web browsing profile (or any ex-histing profile for that matter)." Indeed, this way everybody's happy ! The ones who are used to konqueror's current behavior can still use it their way, and the same goes for konqueror's users that are unhappy with its current behavior : they can now configure home urls to fit their needs. I think it brings better usability and better flexibility for both kinds of users. I think the issue raised by comment #35 doesn't stand in my opinion. Indeed : 1) It's seems weird to me that on a KDE system, the desktop don't have a preset icon that loads konqueror filemanagement profile. But I agree with that it could happen. 2) If the user has no problem with using the mouse, why doesn't he just create an icon that would fireup konqui's filemanagement profile ("kfmclient openProfile filemanagement") ? It would save him lots of time each time he wants to browse his files because, as of now, he must first hit the keyboard to type ALT-F2 and enter "konqueror", then take his mouse. By adding an icon, he would just take the mouse and make one click. 3) If he really wants to use ALT-F2, why doesn't he just type "konqueror ~/" instead of "konqueror"? It doesn't take more time (except the first time) because it is saved in the commands history. 4) And even if the 3 points above were impossible, comment #34 would just require him approximately 1/2 second more with the way described by comment #35 to enable konqueror's filemanagement profile. Hopefully, he won't lose this amount of time because of points 1 to 3 :) So, from my personal point of view, I strongly support the proposition made in comment #34 ! I carefully considered my proposal (#33) -- I considered if it would interfere with the way that I use Konqueror. I do not have it configured differently for Web and File and wish that it was possible to choose some option somewhere to unify those two profiles. My thought was that if I configured both the profiles to have $HOME as the HOME URL and didn't save a URL in the profile then it would work just the same as I have it now, but people that wanted a different URL for their WebBrowsing profile could do so. Re: comment #34. This appears to be a very good idea. One question about this. Should clicking the HOME URL for a profile with the HOME button's menu also load that profile. It appears to me that this would be the way to do it (and it would possibly be easier to implement). Another note: I am assuming that to have a different HOME URL for a profile that you would have to save it with the profile as you do now. Therefore, the default HOME URL would be the one that you save in the File Manager (Behavior) KCM. -- JRT Following up on the small 'home button' momentum here, I do believe 'view profile' should be banned. Not the concept or it's functionality, but it's naming scheme. It should be called 'browsing mode' or 'browsing modes' something like that. I mean '(load) view profile' can mean so many things and can be interpreted in so many unrelated and different ways. Konqueror is a universal browser, it browsing pretty much anything, it is not a 'view profile loader', if it has 'browsing modes' things begin to make much more sense! Konqueror has browsing modes because that's what it is very good at and not every thing is or can be browsed in the same way. In a browsing mode called 'web browsing' I would set www.kde.org as my home. In a 'file browsing' mode I would set ~/ as my home. Depending on what browsing mode Konqueror is, pressing the home button goes to the home URL of the particular active browsing mode at the time. As described earlier, holding down home should ideally allow quick access to the home's of any other home of all other available browsing modes. I can't think of a cleaner way out of all this 'home' mess then this way currently. And to get this all doable from the user interface, I believe a couple of other things should be changed with this. Open up Konqueror and view the Settings menu. There are 3(!) entries related to 'view profiles'. Again, this is confusing, do I want to view a profile? Do I want to load it? Huh, what is it?? In stead I just want to configure Konqueror. There doesn't need to be any entry here related to view profiles or browsing modes for that matter, because with the proposed new home button functionality, this would automatically be available trough the home button. As for where to manage browsing modes, this should be in the 'Configure Konqueror' dialog. Just add another button group called 'browsing modes'. clicking that entry should show a simple 'browsing mode' editor. Here user's can set things one would associate with 'browsing modes'. Here you save/edit/add/delete 'browsing modes'. Note that this would still make the method of HOW/WHERE the user SETS the home URL kind of illusive. I mean this would boil down to, where do I set the home URL? Settings->Configure Konqueror->Browsing Modes->do it here somewhere (and that seems really awkward). So this problem remains, but at least we can get new ideas going for this. Aside from all this, the person who opened this bug called for easier setting of the home URL. And with all suggestions here and also made by myself, none toughed on the actual issue I believe. Just an interesting observation. Let's make sure that whatever this happens when this bug is 'FIXED', it also means that it has become easier to actually set the 'bloody' home URL ;) In reply to comment #37: >>Should clicking the HOME URL for a profile with the HOME button's menu also load that profile. That was the intention, just like it is now basically, you are web browsing mode, you click home and you are in file browsing mode. It should simply be the ability to set a home URL per view profile (browsing mode) and always show the home's of each single profile, that way it has no choice but to load the view profile else things would really really get confusing I think! >>Another note: I am assuming that to have a different HOME URL for a profile that you would have to save it with the profile as you do now. Therefore, the default HOME URL would be the one that you save in the File Manager (Behavior) KCM. Here is the reason of the bug report in the first place hehe! Setting 'home page' is unintuitive! So naturally we should all loudly cheer NOOO!!! All we have done so far, really, is change the problem. Now it has become: how do we set the home URL for each profile? If we keep the current way of setting the home URL, how does the user know for which view profile it is setting the home URL? I think the only problem left (idea wise) is how to most effectively manage the profiles and where to set home URLs all while 'the how' of setting the home URL be 'obvious'. To make it clear and short about the 'home button', it would essentially become a home URL from profile loader, whereas now it can only go to 1 set location. If there are 4 profiles, each has 1 home URL connected to it. The home button always has to go to the home URL of the current active viewing profile unless the user keeps the home button down and wants to load the home URL which is part of another viewing profile. The home button essentially shows a menu (just like the forward back buttons) which shows the home URLs of each ex-histing viewing profile. Arguably this could be an option, it could actually not load the profile but only the location. But the default should be to load the view profile associated with the selected home URL. This would make it even more flexible/customizable. Sorry to be flooding this with messages here, but I believe I was too fast with my reasoning on actually loading the profile together with the home URL of a profile. Actually the home button should NOT load the associated profile, but only the location set as home URL from the chosen profile. Else you would click a home menu entry and loose all your current tabs and whatnot else. You don't want to load profiles, you only want to GO PLACES with the home button. But it still remains valid that home URLs should be connected with viewing profiles. Sorry to be going to fast with this, I should better step back now ;) To condense ideas, and interject my opinion: 1. "Load View profile" should be renamed to "Browsing Mode" 2. Home Folder and Home Page buttons should look different, to avoid confusion (home page should probably be the icon for the website) 3. Konqueror should load in web browser mode. and FileManager (or something) should load in file manager mode. (konqueror is doing stuff the way that we feared MS was going to do stuff with IE, IE and explorer are loaded distinctly) 4. Finemanager mode and web mode should have distinct icons. (for desktop or taskbar) 5. Home Folder and Home Page could have a drop down menu (like back, forward, up directory have) to select other "important pages", and could also serve as a quick and clear browsing mode switcher) #40 outlines a very good solution to this problem which would further establish Konqy's position as the premier file manager and browser. Let me repeat that having one home button that does different things depending on the view profile (i.e., a modal home button) is a bad idea, particularly because the view profile is a *hidden* modality that most users do not understand or even realize exists. As evidence that this is a bad idea, consider the following use cases: 1. Suppose a user starts up Konqueror in file management mode, then types a web URL into the location bar, or accesses a bookmark for a remote web page. Now the user presses home. What does the browser do? 2. Suppose a user starts up Konqueror in file management mode, then browses to a local HTML file. It now appears to the user that (s)he is browsing a web page. The user presses home. What does the browser do? 3. Suppose a user starts up Konqueror in web browsing mode, then browses to a remote FTP URL, which loads a part that looks like it does file management. The user presses home. What does the browser do? Aaron's comment #41 consolidates the best ideas in this thread and IMO is a good roadmap. I think we're now at the stage where it's just a matter of implementation. I think comment #41 is good as well. IE 6/Windows Explorer XP is very clever about making sure that file browsing and web browsing act in distincitive natures-- something IE 4/Windows Explorer 98 didn't do at all, and IE 5/Windows Explorer 2k only did somewhat. We're currently stuck in IE 4.x era ideas. Re: #40. Yes, your are probably correct. Having it load the profile would be redundant since with 3.3.0 you can already have a toolbar button with a menu to load profiles -- Load View Profile -- (which would include the URL if saved with the profile). This doesn't have an icon yet, but you can choose any icon with 3.3.0. -- JRT To comment on comment #43 >>>Let me repeat that having one home button that does different things depending on the view profile (i.e., a modal home button) is a bad idea, particularly because the view profile is a *hidden* modality that most users do not understand or even realize exists. >>>2. Suppose a user starts up Konqueror in file management mode, then browses to a local HTML file. It now appears to the user that (s)he is browsing a web page. The user presses home. What does the browser do? I do get your point. But at the same time don't see the light at the end of any tunnel being suggested. Yes, you can end up in a 'confusing' situation where you are web brosing but not actually in the web browsing mode, so pressing the home button at that time would not open the web URL you might expect from being in what the user believes to be web browsing mode. I do believe this is a valid confusing problem. If I am right, you suggest the home button to ALWAYS go to one main home URL. But on top of that, different profiles can still set separate home URLs, but these would only ever show up and open using the a drop down menu. If there is one main home URL you would limit confusion. Am I right?? Perhaps then and I hope you agree here, it could yet still be an extra option where you say 'home button should go to home URL of active profile' or something like that. It seems like a fairly easy option to implement and would please both worlds, right? This would thus be solved by having always one main or 'root' home URL and also one for each viewing profile. It's either that, either not that or no separate home URLs for viewing profiles at all. Anyway, we cannot (should not) loose 'view profiles' or 'browsing modes' unless web browsing and file browsing should become separate applications. Someway or another, the home button is going to have to go to different homeplaces, else Konqueror would not be taking enough advantage of it's (amazingly powerfull) viewing profiles. That is the difference with explorer where there are no 'infinite' viewing profiles at all. I don't think the problem can be described as being the same as in explorer, the problem is somewhat the same, but because of technical differences, Konqueror should seek another solution. At least that's what I think. On comment #41 >>2. Home Folder and Home Page buttons should look different, to avoid confusion (home page should probably be the icon for the website) Personally I would be satisfied with just one home related image, since basically it always goes to a home or start related location, but having 2 distinctive icons might result in the user automatically understanding that they are browsing something completely different (files, web). On top of that, might it be nice to use that top-right KDE gear logo as an indicator of what you are browsing? I mean it could show a rotating world or whatever if you web browse, or something else when you file browse, perhaps this would eliminate the need for 2 different looking home buttons, or it could be addition and actually increase the visability of being in different browsing modes. For the record, I'd just like to pipe in and say I agree with comment #34. I also agree with comment #46 in that the "throbber" or whatever you call it should have a different icon depending on what browsing mode you are in (let's get used to calling it a browsing mode, I also agree with that :). Now, when it comes to setting the home url for each browsing mode, that is a tricky one. They way IE does it, is that the menu's actually change depending on what browsing mode it is in. In IE mode, you can go to tools->Internet Options. In Explorer mode, it has tools->Folder Options (I think). I don't see how that can work in Konqueror because it has lots of browsing modes. We *could* see that file management and web browsing are the two major browsing modes and have a Settings->Configure Web Browsing, and Settings->Configure File Browsing, options depending on what browsing profile you are in. Imagine you are a typical user, familiar with other web browsers, and you were using Konqueror to browse the web. You want to change your home page, where would you go? In firefox: edit->preferences, in IE tools->Internet Options, in Opera Tools->Preferences. In all these cases, the home page setting is on the first tab/page. This is true in konqueror too, for file management anyway. When going to Settings->Configure Konqueror, it could only display options for the current browsing mode, with an extra Tab/Page for "Other Browsing Modes" - which would be a reasonably advanced Browsing Mode Editor. So when browsing the web, joe user can go Settings->Konqueror, and change the *web* homepage on the first tab/page. In file management mode, Settings->Konqueror shows file management stuff (including home URL for file management). Would this be confusing? As long as it is _obvious_ you are in a different mode, I don't think there is anything wrong with toolbars/menu's looking different in each mode (tabs become an issue though). Refactored: 1. "Load View profile" should be renamed to "Browsing Mode" 2. Home Folder and Home Page buttons should look different, to avoid confusion (home page should probably be the icon for the website) 3. Konqueror should load in web browser mode. and shell script with the options to manage files, should be called something else (fkonqueror) 4. tabs of different types should not be allowed, or (grudgingly) toolbar should change obviously when switching between browsing mode type. 5. file managing is an editing type part, so is kwrite, or kate, editor type modes could have a file home button show, and browsing type modes, could have a web page.. (this is a crock) 5. Home Folder and Home Page could have a drop down menu (like back, forward, up directory have) to select other "important pages", and could also serve as a quick and clear browsing mode switcher) Re: #48 2. I have no problem with having the Home URL button icon change to indicate which profile is currently being used. Unfortunately, 'favicons' are only 16x16 so if you want to use your ISP's icon, you are going to have to set this up by hand. 3. There is already such a command: "kfmclient" but it needs to have a default command. Currently you must use the command: kfmclient openURL . This could be fixed with just a script. 4. This is simply wrong. Konqueror is a universal browser. Why do people want the artificial dichotomy like Windows? The profiles and the tabbed browsing have a conflict. This is a bug. Should you be able to have different profiles in different tabs? You would have to load them (see below), but currently the profile also contains a tab configuration -- so the answer is NO! This won't work. Clearly profiles are problematic here. The profiles now are able to save different toolbar configurations (3.3.0) this is probably necessary, but it doesn't solve the problems (actually if the problem were solved, this feature wouldn't be used much). Currently the toolbar configuration changes based on the content displayed, and this is now (3.3.0) configurable but it is awkward to do. Perhaps having them change based on the protocol (e.g. file:/ or http:/) being used is also needed and this would need to be configurable. Changing the toolbar configuration based on the protocol COULD work with different tabs having different protocols. Second 5. You can already have a toolbar button with a menu for: "Load View Profile". 3.2.x couldn't use this because it didn't have an icon. It still lacks an icon but you will be able to assign one In 3.3.0. But, only one URL per profile please. -- JRT I'm voicing my vote of "yeah!" for this bug/feature-request.
The current behavior is _obviously_ very flawed for a variety of reasons, as explained through the many, many, many posts in this bug. As further indication that this behavior must be changed, just look at all the duplicates - and how far back they go! In fact, I was brought to this bug while creating one of my own. It's good to see a large number people still discussing this - lets fix it!
The current use case and terminology is unintuitive and restrictive: "view profiles" would better be named "browse mode" ("browsing mode") or something similar. Additionaly, there needs to be some intuitive and logical, simple method for setting a "home" for each "view profile"/"browse mode" that the user creates - _including_ the default 'File Management' and 'Web Browsing' modes/views.
Those are the primary issues.
Additionaly, I'd like to put my votes in for two other suggestions already put forth:
1 - The comment 34 idea of having a modal "home" button that, as was stated: "added a menu for the home button(just like with the forward and back buttons) which would simply show the home URLs of all profiles present at the time."
2 - As a visual queue so that the user can quickly tell at a glance what "view"/"mode" he is in, and thus an indicator of which context the current "home" button is in, implement the ability to configure the animated throbber thingy to intuitively reflect the current view/mode; with two default animations for 'Web Browsing' and 'File Management'.
So:
1 - Better nomenclature for the "View Profile" concept. Proposal: "Browse Mode"
( note: this is not imperative, but it would arguably ease problems for new/naive users )
2 - Ability to configure/assign a separate "Home" for each "Browse Mode".
( note: not _just_ the ability to have separate homes for 'Web Browsing' and 'File Management' - but the ability to assign a custom/separate home for each "Browse Mode" that the user defines. )
3 - A modal "Home" button that,as a convenience mechanism,additionaly serves as a menu for selecting the other available/configured "Browse Mode" homes.
4 - A configurable "throbber" animation for each defined "Browse Mode", with at least two defaults provided by KDE - one suitable for Web Browsing, and one suitable for File Browsing.
( note: this is for the purpose of displaying to the user at a glance which "Browse Mode" he is in, and thus indicates which context the modal "Home" button is currently in. Such that if he should browse a local file while in 'Web Browsing' mode he will know that he is still operating under the 'Web Browsing' mode, and has not suddenly switched to his 'File Management' mode or somesuch. )
To implement:
1 - Modify all verbage where appropriate, i.e. where it appears in code, and where it appears in the UI and documentation.
2 - Modify behavior of the "Home" button as per #3 above.
3 - Under the "Profile Management" dialog, in _addition_ to the current two options ( i.e. "Save URLs in profile" & "Save window size in profile" ) - include the following two options:
"Set 'Home URL'"
"Set 'throbber'"
Done deal - everyone should be happy. Those currently satisfied with the current behavior need not change their work habits if they don't wish - and those who desire the use of these features can do so with ease.
i think there should be an "auto-load home URL" checkbox in the behavior applet. *** Bug 56414 has been marked as a duplicate of this bug. *** ..so em ..are we getting any closer to where the "setting home page *is* intuitive" yet? *** Bug 93179 has been marked as a duplicate of this bug. *** I would like to invite all visitors of this bug who cared about the up button to comment on my proposal in http://bugs.kde.org/show_bug.cgi?id=93192 I agree completely with comment #34 and those that have similar suggestions. Those who say that the changing functionality is bad for usability have clearly not experienced the complete frustation of a newbie when the home button takes you somewhere completely unexpected -- and when you're browsing the web, your home folder is completely unexpected, and contrary to all their prior experience. But when you're doing file management, suddenly going to the web instead of your home directory is equally unexpected. The modal button not only fixes this, but in cases where you DO want to switch functions, the drop-down menu allows that easily. Perfect. #35 isn't a valid objection: just type "konqueror ~" or "konqueror .", one extra keystroke isn't bad -- and newbies will be launching it graphically anyway. Re #43: > 1. Suppose a user starts up Konqueror in file management mode, then types a web URL into the location bar, or accesses a bookmark for a remote web page. Now the user presses home. What does the browser do? Go to the home page of the web browsing profile. > 2. Suppose a user starts up Konqueror in file management mode, then browses to a local HTML file. It now appears to the user that (s)he is browsing a web page. The user presses home. What does the browser do? Go the the file browsing profile's home url (ie, ~). This is just viewing a local file, no different from an image or text file or what have you. > 3. Suppose a user starts up Konqueror in web browsing mode, then browses to a remote FTP URL, which loads a part that looks like it does file management. The user presses home. What does the browser do? This is the hairiest one. Since konqueror would be using the file browsing profile, it should go to that profile's home, ~. I think this would be the best usability solution in most cases; when users are dealing with files, they want quick access to their central file repository (to copy to, or whatever.) I think comment #56 misunderstands the definition of "view profile" in Konqueror. View profiles are not associated with the currently loaded URL; in fact, they are completely orthogonal to URLs. When you load a local file URL or remote FTP URL after starting up in the web browsing view profile, you are still in the web browsing view profile (you can verify this yourself --- look at the Window menu after doing the foregoing). So, what the poster is suggesting is that the behavior of the home button be modally dependent not on the view profile, but on the *protocol* used for the current URL (file:, http:, ftp:, etc.). This is a suggestion that has not been raised before. It may work, but I suspect there are still confusing corner cases. Here are two problems: 1. To the user, the most visible feature of a Konqueror window is the currently loaded KPart, not the protocol used for the currently loaded URL. Naive users will be confused about the behavior of the home button when the currently loaded KPart looks like something other than what the current protocol dictates. 2. Konqueror supports dozens of protocols. Shall users be permitted to change the home page for each protocol separately? Would this really make setting the home page *more* intuitive? I still suggest that there should be two buttons: one for the home folder, one for the start URL. These would never be confused. They would have entirely predictable behavior all the time. It should be easy to change the start URL, and hard to change the home folder. It seems to me that a lot of energy is being spent to address a case
that other Desktop interfaces already handle well. For examples, we have
Gnome, Windows, and KDE.
What happens is this:
1. When you click on a "Home" icon on the desktop , you get an interface
appropriate for browsing a file system. A "Home" icon in this toolbar
goes to /home/user
2. When you click a web browser icon, you get an interface appropriate
for the web. A "Home" icon in this toolbar goes to your favorite
website.
I think the whole thing would be clearer if the different "View
Profiles" actually appeared to be two different (simpler!) applications
to the user.
Konqueror's cluttered interface is one of the main reasons I don't
prefer as my primary browser. That it takes this look to figure out how
to make setting the home page intuitive is a sign something is rather
wrong.
Mark
Hooray! I absolutely 100% agree with comment #58. I don't use Konqueror as my main web browser either because its not a real web browser, it's some generic kitchen sync swiss army knife "browser" that attempts to be and do everything. I dont have any hope that Konqueror's UI will ever be totally useable and simplified; I don't think its in the philosophy of most KDE developers. They want software to be powerful and featureful, which KDE is, and so simplified and user friendly gets put on the back burner and might get hacked on as an afterthought. Recently I've been playing around with Mac OS X, and while there are some things I don't like about it, overall it is a very useable GUI for both novice and technical users. There are no "do everything" applications. The Finder is the file manager, Safari is the web browser, quicktime is the movie player, itunes is the music player, iphoto is the photo organiser, etc etc. So everything is tailored to do a specific task, and do it well. I don't forsee KDE ever changing its philosophy on this front. So the best we can do is make it appear to the user that KDE web browser and KDE file manager are two separate applications, and will behave differently. Re: comment #58: It appears that although a file is a file no matter where it is located, that many users appear to want some artificial distinction made. This distinction doesn't exist and making it leads to less usability. According to this theory, if you wish to view an HTML web page on the internet you would have to use the Web Browser, but if you save a copy of it to your hard drive, then you would have to use the File Manager to view it. This is ridiculous. The current idea of View Profile is not an answer because it is also ridiculous. You can display local files using the "WebBrowsing" profile and you can browse the web with the "FileManagment" profile. This is not a wise idea. Actually, the profile idea as implemented is somewhat broken since it cobbles together two concepts: save and setup which would be more useful if they were separated. It would be much better if there was only one setup for both web browsing and file management. However, what is needed is to have either two Home buttons, one for your local system and one for the web, or to have the home button display a list of Home locations that can be added to like a bookmark folder. Re: comment #59. This is even worse. What is a "real web browser". Don't you realize that FireFox will browse your local files on your hard disk? So, keeping that in mind, please explain exactly what you want. What Konqueror is is a browser that handles multiple protocols (just like FireFox). Konqueror does handle more protocols by using KIO Slaves. But, despite what you think, a browser is a browser. Konqueror uses a plugin to display everything so it is extensible, but that doesn't make any difference to the user. You open a file and it displays it. Does it matter if it uses a plugin to do that? If you don't like default configuration for Konqueror, all of the toolbars can be configured. You can even add more if you want. Is your complaint that Konqueror has too many menu entries because it has a lot of features? It sounds like you want a simpler browser that doesn't have all of the features. If that is what you want, that is probably a valid suggestion. But, you have confused this idea with the false idea of separate browsers for local files and the web. -- JRT >>I don't use Konqueror as my main web browser either because its not a real web browser This is one serious silly comment. Discussion here is splintering into: View profiles -> browsing modes (name change and or their use at all) How many home buttons do you want on a toolbar? OR, should there be one home button, but a modal one, a smarter one? Is Konqueror a real web browser (are you smocking crack?)? For the 'view profiles' which I rather call: 'browsing modes', I suggest the removal of all 3 entries in the 'Settings' menu. There needs only be 1 entry called browsing modes, from this menu entry you can manage 'browsing modes' in a browsing modes dialog? Browsing modes are very powerfull, sadly not yet obvious enough to the user. 2 home buttons, that is what I would really call clutter. In stead of pointing out how others have already solved this for their environments, some ignore the fact that Konqueror has more and different features it needs to deal with, it is not the same beast. >>It would be much better if there was only one setup for both web browsing and file management. The problem with this approach is that you ignore something this way. You ignore the problem of different 'view profiles', which _will_ ex-hist and which will always co-ex-hist in that you can browse everything from any 'viewing profile'. Two home buttons actually solve nothing in relation to the 'viewing profiles' (please call them browsing modes). A completely separate setup for 'file management', would still have the same problem of being able to go a web page and the home button would act 'strange'. That is the core of the problem, the home button. 2 home buttons ignore the fact that you create your own 'browsing mode' for FTP-ing or whatever, you would want a new home location for that 'browsing mode' as well. Anyway, this could take some time.. > For the 'view profiles' which I rather call: 'browsing modes', I suggest > the removal of all 3 entries in the 'Settings' menu. There needs only be 1 > entry called browsing modes, from this menu entry you can manage 'browsing > modes' in a browsing modes dialog? Browsing modes are very powerfull, sadly > not yet obvious enough to the user. Actually, the current profiles are really bad in terms of usability. They do not even switch automatically, but the user has to save in a profile, that when one is on the web, the sidebar should show the bookmarks, as an example. Maybe bug 87753, respectively http://wiki.kde.org/tiki-index.php?page=KDE+Context-Sidebar could solve this issue nicely, as it would allow konqueror to react to its context and thus be a lot more intuitive. However this is not really the point of this bugreport. The point is simply, whether one should be able to set up the home-page in some other way than one currently can. Everything else, i.e. a second button, or improving view-profiles, should be carried to new bugs, IMHO. Well I certainly agree with comment #62, discussion has splintering too much and should be carried to new bug reports. The title of this bug is about the home button not being easy to set a home page for it. Perhaps this bug should also be closed and renewed? 63 comments later, we are not even talking about this. Anyone else noticed, this bug was reported, ......in the year 2000? Re: Comment #63 Some of the comments have gotten a bit off topic, but I don't think that this needs to be closed since it is true that there are various possible ways to address this issue, and some of these ideas have other implications or require other changes to implement. This is getting down to two possibilities: 1. Have one singular Home button as we have now and have the URL selected by that button depend on the current view profile (or browsing setup or mode). I personally do not favor this because it would still require the user to manually switch the profile, setup or mode before they could click the Home button to load the desired URL. 2. Have either (a) multiple Home buttons, or (b) a single Home button that had a list of available Home locations which were configurable like a bookmark. I personally favor (b) since it would not clutter up the toolbar. There are various ways to implement such a Home button with a list. I believe that is necessary that a left (button 1) click would open the home URL for the current Browser Mode. Re: comment #61: It is suggested that we call "View Profile", "Browsing Mode". Yes, but this will also need a change in the code because the current "View Profile" also incorporated the ability to save URLs other than just Home as well as multiple tabs and until that is a separate function, some of the proposed solutions are not going to work. Re: comment #62: > Actually, the current profiles are really bad in terms of usability. They do > not even switch automatically,Actually, the current profiles are really bad > in terms of usability. They do not even switch automatically ... . Automatic switching is a good idea. But, for this we would need "Browsing Mode" which does not include the ability to save multiple tabs or URLs. If we had that, then the "Browsing Mode could switch automatically based on the protocol (i.e. File, HTTP, FTP, etc.) being used. Then this could still use the Home button with the list to switch modes since if you select a home URL with a different protocol, then the Browser Mode will also switch. Alternately (which I think still has issues), you could add a "Change Browser Mode" list box to the tool bar which would also change that mode's home URL. Re: Menus None of this addresses (and this issue *should* be started as a separate bug) a question which I believe *is* extraneous. Konqueror does have a lot of menu entries. According to the current KDE guidelines, all functions must appear in a menu so if users want a simplified Konqueror that doesn't have all of the features available, this would need to be a separate application (e.g. KWebBrowser) that would be "only" for web browsing like FireFox. But, like FireFox, if you enter "file:///" you can still browse your local files if you want -- it could be limited to HTTP, FILE (which can also browse a network if you enter a hostname), and FTP (perhaps others, but not all of the KIO Slave based functions) -- JRT >>2. ... (b) a single Home button that had a list of available Home locations which were configurable like a bookmark. I personally favor (b) since it would not clutter up the toolbar. Yes, but this still ignores something. It still misses the reason why comment #34 started more discussion. The point being that a browsing mode needs a home location which is browsing mode related (versus static). Why? Just a home button with multiple choices, is still the same old home button but now with more choices. If you would press it in the html browser it would STILL be going to the users home directory. So in that relation, just above point A will not truly solve anything. This is why 'somehow' the home button should have a relation to a browsing mode, on top of that, a list to choose from with the home being a modal button. Simply picking a choice from that list of homes would activate that browsing mode. It can't be simpler, at least I don't so at this moment. The most important thing and we seem to all agree on this, is make these modes more apparent, or seem more usefull and making sense, better configurable etc. > I personally favor (b) since it would not clutter up the toolbar. > > Yes, but this still ignores something. It still misses the reason why comment > #34 started more discussion. The point being that a browsing mode needs a > home location which is browsing mode related (versus static). Yes, I said that that you should be able to select different home URLs for each browsing mode. > Just a home button with multiple choices, is still the same old home button > but now with more choices. If you would press it in the html browser it would > STILL be going to the users home directory. So in that relation, just above > point A will not truly solve anything. No, as I said, if you didn't access the list, it would go to the URL for the current browsing mode, but if you access the list you could change browsing mode and it would then go to the home URL for that browsing mode. I suggest that as default we should have browsing modes: HTTP, FILE, and FTP since all users would need these. This could be all in the Home button, or there could be a separate button to change the browser mode. -- JRT Again, please take discussion of stronger browser modality to the following BR: Bug #80018: stronger distinction between file management and web browsing modes The current BR is about fixes for the home page issue specifically. In comment #22 and comment #43, my objections to a modal home button were based on the fact that view profiles are a hidden modality. If and when someone performs the highly nontrivial coding and UI design task necessary to make browser modes obvious (not just visible, but *obvious*) to the naive end user, then having a modal home button will be sensible. In other words, a modal home button would be sensible *only if* Bug #80018 gets implemented and closed. If that ever happens, then you should notify watchers of this BR, or file a new bug. Until that date, the best solution is to have two home buttons. Yes, it clutters up the toolbar. It's still better than the alternative. Comment #22 and comment #41 described how this could work. p.s. There have been not 2 but at least 7 distinct proposals floated in this thread:
1. Home button's URL depends on the current view profile.
2. Home button's URL depends on the currently loaded KPart.
3. Home button's URL depends on the current URL protocol.
4. Home button's default URL depends on the current view profile; other URLs available in a dropdown.
5. Home button's default URL depends on the currently loaded KPart; other URLs available in a dropdown.
6. Home button's default URL depends on the current URL protocol; other URLs available in a dropdown.
7. Two separate home buttons (home directory and home page).
Please make clear which one you are arguing for.
Note that all of these except 7 result in a modal home button.
Another point in favor of 7 is that it requires only 2 home URLs, one of which (the home directory) can be hidden in an obscure place because users only rarely need to change it. All the other proposals require a way to configure home URLs for each {view profile,KPart,protocol}, which is a potentially unbounded number. Out-of-the-box, a standard KDE distribution comes with 5 view profiles and dozens of KParts and protocols.
Please look at the title of this BR: do you seriously think that having a home URL for each profile/KPart/protocol is going to make it *easier* for end-users to set the home page?
Re: Comment #68 There are not really as many ideas as you list. Items 2 & 5 will not work because the KPart is determined by the file type being viewed, NOT by where it is located. Since they won't work, we forget them It is only the toolbars that can be configured based on the KPart being used. This is another issue if what we have in this regard is sufficent or not. The current system is that the basic toolbar configuration does not change but that additional toolbar buttons can be added depending on the KPart being used. Items 1 & 3 and items 4 & 6 are really the same idea. If we can switch over to Browser Modes and Browser Save then we might start out with a Mode for HTTP, FILE, & FTP (many other protocols do not need a Home URL). I presume that it would be as it is now that there could be additional named browser modes, so we are really talking about URLs being associated with a named browser mode and named browser modes being associated with a protocol so that there can be automatic selection of a browser mode based on the protocol of the URL (we would need a default Browser Mode for each protocol). I probably have this clearer in my mind than in my explaination. :-) So, that gets it down to the two I listed. 1. Action of the Home button determined by the current Browser Mode. 2. Browser Mode &/| Home URL controlable by toolbar buttons. With #2, the choices are not orthoginal, they are dependent: If you use the Home list button to select a URL, this is going to automatically select the default Browser mode for that protocol. If you use a Browser Mode list box to select a Browser Mode, this is going to load the Home URL for that Browser Mode. If you load a URL, that is going to switch to the default Browser Mode for that protocol. For option #2, there are various ways to implement the toolbar buttons but these are just minor details of implementation. Probably we should have all options in the toolbar configuration dialog so it is then a question of the choice of defaults. So, basicaly, you need to choose between these two first and if you choose #2 then you can state your preferences for the toolbar buttons to control this. -- JRT *** Bug 96110 has been marked as a duplicate of this bug. *** Guys, just a though : what if we could drag an url to konqi's home icon, as one of the possible ways of setting that home page ?? Re Comment #68: I am in favor of option 6. I don't think anyone's arguing for 1-3: having a drop-down does not impede the single-click functionality whatsoever, and in a situation where the home button can do multiple things, easy access to all of them is essential. I don't like 4 because view profiles are essentially meaningless, since users can go wherever afterwards. (However a solution involving automatic profile switching would probably solve this and other issues in a more general manner.) I don't like 5 because when a user follows a link to a tar.gz from a webpage and it opens in the ark kpart, he is browsing the web and expects Home to go to his homepage. However, if he clicks on a tar.gz in his file system and it opens in the ark kpart, he is browsing his filesystem and expects Home to go to his home directory. Having a second home button would be useless half the time, and I don't see the advantage when you can just list both options in the single button's drop-down list. All options would be easily available, just with a sensible default. As far as configuration problems: the only home page I can foresee the user wanting to change is the web browsing one. Perhaps local URL protocols stay going to $HOME, and the lan browsing protocols go to remote:/. If configuration is made a simple matter of right-clicking the home button, then choosing one of the listed URLs to then change, configuration shouldn't be a hassle at all. I absolutly agree with comment #72. I would like to make following suggestion as a solution. First there should be the possibility to set to kind of home's. One for the web and one for the local. It would even make sense to have to different icons for both. Then I would like to suggest to use the gear (on the right side of the browser) to switch between browsing modes (file/web-browser). there should be two different versions or colours which indicate web or filebrowsing. By klicking on it the browsing mode change and also the iconbar changes (may be other changes apart from the /home-icon useful). Futhermore I may make sense to have the option to automaticly call the /home-page (at least when switching to browsing mode) when clicking on the gear. So the gear would be indicator and switch at the same time. There may be also the possibility to have more than this two browsing-modes which could also be changed and indicated through different gears. The browsing mode should be set only by tab. Re: Comment #74 I believe that having two Home icons is the best solution. However, I suggest that the distinction between web-browsing and file-browsing as a matter of the *state* of the browser should be eliminated. This does not mean that there can't be different modes, but that they should be based on the protocol being used or the type of file being displayed. This is needed as the logical extension of tabbed browsing since you might have a "file" protocol in one tab and "http" in another. > This does not mean that there can't be different modes, but that they should be > based on the protocol being used or the type of file being displayed.
I think that is true, that the different modes should base on the mater of protocoll. But it also makes sense to introduce a switch, so that, there is also the possibility to prohibit the automatic switching without user-interaction (which could make for some users sense for security reasons).
On Wed, May 18, 2005 at 06:44:10AM -0000, Mark Wege wrote:
[bugs.kde.org quoted mail]
I'm interested to know what Alex, the owner of this bug, thinks, and am I'm
cc'ing him for that reason. I'm also copying David Faure to solicit the
opinion of a KDE administrator.
Alex,
This bug has been open for several /years/, has 735 votes, and 76 comments and
hasn't received a comment from you in over a year. It definitely seems worth
addressing considering this state.
Is there another developer or group that this bug could be assigned to that
would be more willing or able to discuss and resolve the issue with the
many interested KDE users?
Mark
So much discussion on a single bug makes it hard to address - it takes 20 minutes just to read the whole discussion :) What started as a discussion on the default *start page*, turned into "how to define where the Home button goes", which turned into a discussion about auto-switching profiles (something I'm still rather against in general, because it's almost impossible to get right, with tabs, splitted views and all, but which is not the topic of this BR, IMHO). So let's go back to the original issue; the start page for webbrowsing. We could add a separate config option for it... if people are fine with the Home button remaining unrelated to that. In other browsers it's not, but in KDE, the home symbol is your Home directory, not some webpage. On May 18, 2005, at 4:40 PM, Mark Stosberg wrote:
> Is there another developer or group that this bug could be assigned
> to that
> would be more willing or able to discuss and resolve the issue with
> the
> many interested KDE users?
i've made it more than clear on many occasions
that i'm no longer working on kde...
Alex
I personally really like the way view profiles work, and i think that the home button should stay the way it is, since only the startup page is important. after that the home-button acts more like a bookmark, and you can just create a bookmark. However, I do think that the startup-page setting style should be explained in the settings dialog, since it seems to be rather confusing to people new to konqi (my dad for example, he thought this was a bug). > ------- Additional Comments From sfh23 cornell edu 2005-06-21 01:52 -------
> I personally really like the way view profiles work, and i think that the home button should stay the way it is, since only the startup page is important. after that the home-button acts more like a bookmark, and you can just create a bookmark.
As a website developer, I disagree that the home button is like a
bookmark. Sometimes in website development, we have intentionally left
off a "home" button in the navigation scheme because it didn't go
anywhere useful. Or rather, it went to a splash page which only included
navigation options that were already on every page. We learned that the
"home" concept was important to help users feel comfortable and be able
to "start over".
I've found that few people use bookmarks, but many want to "start over".
The more fundamental issue is that it is confusing to combine the home
buttons for the web and local browsing. The common solution, which I
prefer, is to have two simpler applications specialized for each task.
Mark
Since http://bugs.kde.org/show_bug.cgi?id=56414 has been marked as a duplicate of this bug, I'm giving my vote for having a home button that you can define per profile. It just makes a lot of sense to have the home button pointing to your homepage when you are in the webbrowser profile and to you /home when you are in your filemanager profile. I think that this is such a fundamental feature that I still prefer firefox over konqueror, just because of this specific issue. Cheers Emil NICE SUMMARY OF PROBLEM: How do we set the home URL for each profile? I agree with others that once the user figures out the "save profile" feature it's hard to forget. I am guilty of hitting the home button in file browser mode and expecting to have my home folder appear. I give it 20 votes! I'll separate kfm from konqueror in kde4, or at least implement "filemanager / browser" modes in konqueror windows, and then the home button will do what one expects. What about making a "toggle" home button? For example: press once and get to your web home page. Press again and get to your home dir. And after all, why not pushing the idea further: Link the "home button" to a list where the user can list his home pages. And pressing the "homeButton" just browse the list in the order set up by the user. As a better UI feature, let's have the "home button" showing the name of the next item on the list. In this way, some user can choose to have a short list (2 items) for a quick browse-through as other will prefer an extensive abuse of the list. I suspect some will react: What's the difference with bookmmarks then? Well, in my opinion, bookmarks are for pages which are used regularly. It doesn't mean often. In fact it isn't really often used because I need to have the bookmark sorted per field (utils, news, IT, sport,...) to find out what the page is for. But the pages in the home button are the ones I always check through, everyday, and even before checking my mails. And this usage of the home button just sends the forever-existing "home button" back to the stone age. This usage of the "home button" is not incompatible with the profile-dependent "home button" as described above by some users. On Mon, Feb 27, 2006 at 03:27:39PM -0000, ChrisLau wrote:
>
> What about making a "toggle" home button?
> For example: press once and get to your web home page. Press again and get to your home dir.
While I feel the conversations in this ticket are often circular, I feel
compelled to jump back into it.
Every other browser I'm aware of has a simple "home" button that does
one thing. It's fine to be different, but do so carefully. I often
switch back and forth between Firefox and Konqueror. Having the home
button behave differently in Konqueror just makes the experience more
confusing.
I would much rather these functionality split into two simpler but related
applications, each with a simple "home button" implementation.
Personally, I've quit using the home button in any browser, and remove
it from the toolbar. I do set a "default start page", and then use
search bar when I want to restart my experience from a new point.
Mark
Re: comment #86 > I would much rather these functionality split into two simpler but related > applications The problem is that this split would be an artificial one. Actually, we already have such an artificial split and it isn't a good idea. Your "Browser" application can also browse your local files and what should the "Home" button do when you are browsing the local files. NOTE: In case you didn't know this, Firefox can also browse your local files. You could have the "Home" button file dependent on the current protocol, but this would have serious usability issues. I suggest that there is only one good solution which is to add a button that will take you to folder pointed to by the: "Documents" path. > Your "Browser" application can also browse your local files and what should
> the "Home" button do when you are browsing the local files.
Just because you can use the same word "browse" in English to search for your files (the main task of a file manager) and to read Internet content, doesn't mean, there is any relation. Go to a library and compare your actions, if you
a) scan an index to find a book in the shelf and
b) read this book
Do you see that those are two completely different tasks, that in the computer equivalent are both described as "browsing"?
So I fully support the remark of David Faure in #84, to separate kfm. If you can switch from both applications directly to the other within the same window, this would be o.k. for me, but the surface has to be different in both cases to be fully optimized for the specific task.
Re: Comment #88. To be blunt, you are wrong; Comment #84 From David Faure is a bad idea. On the computer, a browser does this: You enter a protocol and an location in the "Location" window and if it is a file it displays the content of the file, if it is a directory, it displays a list of files and subdirectories. This is the same no matter what protocol is used or where the location is. The only difference in Konqueror is that it can also display a directory in icon mode for some protocols and uses KFM to do this. When you are "displaying internet content" you are just displaying files. Yes, some web files are complex, but they are just files (the same as a Flash file is just a file) -- the fact that you are using HTTP to retrieve them does not change that. As I said, the distinction between browsing the web and browsing your local file system is artificial. While I have no objection to having KFM able to function as a stand alone application (currently it only exists as a K-Part) I do not see this as an improvement. You propose to have it possible to switch from one application ("browser" or KFM) to the other directly in the same window. I presume that you mean that it would be necessary to manually switch between them. How is this an improvement over what we have now? It works that way now except that it switches automatically. The only problem is the artificial distinction with two profiles. The profile needs to change automatically based on the protocol being displayed rather than having to change it manually. Currently, Konqueror does some of this automatically based on what is being viewed, but it could be improved. So, if we have manual switching and I am in "Browser" mode and I want to open my "KFM" mode home directory I first need to click on something to switch and then click on "Home" or does it automatically open "Home" when I switch? How is this better than two icons one for a web home and one for a local home? Also consider that local files can contain hyperlinks to web content. And, which application would you use for FTP (browser or KFM)? The universal browser can be improved. You could, for example, have it possible to have different profiles based on the protocol that you were using. A major complaint of the two browser advocates appears to be the fact that the base menus in Konqueror do not change with different profiles. This is a necessary part of the KDE interface guidelines -- options in the base menus must remain the same. I see no resolution of this issue except to make it configurable. I think that you want three icons while I only want two. Are there really any other differences? Please note, that the many computer users actually fear using a file browser beyond "my documents" because they think they will break something. Having the home button in file browser mode go back to /home/user1 offers a great deal of "peace of mind." I know this because I do desktop support for a living. As I understand the proposed resolution of the issue at comment #84 there will be the one home button when clicked in web-browser mode (http:// or ftp://) sends the user to their home URL. (ex. http://www.google.com) In file browser mode (/home or just /) it should take you back to your home folder.(/home/user1) In a protocol where "home" is not defined, there needs to be a way to ask the end-user where they want to go. (/home/user1 or http://www.google.com or define a new "home") This way the user can go to the home they expect. It is a great deal of peace of mind to an average user. > many computer users actually fear using a file browser beyond "my documents" > because they think they will break something. Probably true, and somewhat odd since on a properly installed Linux system, they can't break anything outside of their HOME directory. Actually, the one place where they can break something is in their HOME directory (and the so-called hidden subdirectories) which is why I suggest that the default setup have the local Home point to "~/Files" (which corresponds to "My Documents" -- people say it doesn't, but check a Windows installation). That is where my Home button points. I see some issues with what you propose. From a usability perspective, it isn't a good idea to have states because the user might forget which state their in (ambiguous states are worse). Our current setup lets you go to the web in the "file manager" and manage files in the "web browser" This is not good and I don't see anyway to change this. Even if we had profiles that would change based on the protocol (HTTP, FTP, FILE, etc.) it would still be best to have two HOME buttons (web home and "My Documents"), otherwise, you would need to have some way to change the mode of the browser in order to go to the HOME that you wanted. > web-browser mode (http:// or ftp://. I don't think so. Currently we use the file manager (the KFM part) for FTP, should we change this? This is a further confusion for users. I am also asserting that another source of confusion is that users seem to think that web browsing and local browsing are different things. This would be OK as long as it doesn't result in ambiguous states. My suggestion to avoid this issue is to have profiles based on the protocol in use. If this were the case then clicking on one of the two Home buttons would also select (indirectly) the profile to be used. Note that this needs to be setup so that users don't have to use different profiles if they don't want to. I suggest that there be a default "Browser" profile which would be used unless one were defined for the protocol being used. If profiles are used in this way, saving URLs would need to be a separate function. "Currently we use the file manager (the KFM part) for FTP" 1. It looks just like every other mode. This is a good thing. 2. Most users don't know AND don't care what's handling ftp on their PC. Myself included. What I like is it works as expected. Enter ftp.url.good.com and I can click away as if it were in file manager mode. Perfect! "Our current setup lets you go to the web in the "file manager" and manage files in the "web browser." It may not comply with KDE's standard, it may not be "right" in a technical sense, but it's very familiar from the user's perspective and it will work for most users. "users seem to think that web browsing and local browsing are different things" Not really. They don't really know and *really* don't care. They want to apply what they already know. If they aren't sure, they just quit. In this case, click on folder opens it is what they know. They don't want to learn new behavior, see new user interfaces they don't know. We all know there are some bad GUI practices built up over the years, but enforcing "good" behavior (gnome?) and adding more buttons when so few are actually used anyway won't help very many users. > it's very familiar from the user's perspective and it will work for most > users. You missed my point which is: why do we need the two profiles: "webbrowsing" and "filemanagement"? Wouldn't a single profile or profiles based on the protocol being used be simpler to understand? Either way, users don't have to figure out what state the Konqueror is in. And why then do uninformed users insist that we should have separate applications for the two functions (when they are essentially the same)? I find this artificial duality to be useless. I would think that many users would be confused by it. Perhaps they are, but not in the way we think they would be. > adding more buttons Either way, it takes more buttons. Two browser modes means two more. Adding a second HOME button only takes one more. Created attachment 14914 [details]
Patch to for two HOME locations
This is just the basic idea for two HOME buttons. One is the same and the
other is set with the Documents path.
There would still be usability issues such as which icons to use, what to call
them, etc. which I leave to the HCI group.
[the patch in Comment #94 seems the way to go - it was added while I was composing this...] http://bugs.kde.org/show_bug.cgi?id=8333#c2 (Comment #2) really summed this up right from the start - two buttons, "home page AND a home directory". Maybe the "home page" is to an ftp:// URL. Maybe the "home directory" is an smb:// share. Not what one might expect, but that's the point. Intuitively, I think two (as in more than one, but less than three) will "catch" the greatest percentage of what users want, without being overly intrusive. In other words, two buttons normalizes the locations they want, not just by the specific URL, but also the protocol. Any void can be filled in by the highly customizable profiles, which, once I adjusted to them, have become a greatest-thing-ever(tm) (to me, anyway). I just wanted to make a few important notes here. With the two 'home' buttons solution, I think we go for the most straight forward solution, sounds good. However, let's make sure to be reminded of the things this report has brought up; the actual unintuitive setting of the homepage itself being the most important. After all the posts in this report, from one point of view all that really has been accomplished is having multiplied the original problem. Now we have two home buttons which are unintuitive to set. Right now it's about saving a view profile, not setting any homepage or home location. Calling 'profiles' 'browse modes' seemed welcomed too. So that is: 1) Let's make sure it is straight forward to set the paths for each home button and that not in all we have done is multiplied the problem. 2) Let's make sure 'browse modes' become more accessable and not about setting home pages/locations from a usability point of view. 'save browse mode' does not translate into set home page! I was also thinking about an option which allows you to 'create browse mode shortcut' which would dump a shortcut accessing a 'browse mode' on the desktop for example. True use of 'browse modes' seems something regular users won't do that quickly, but it can be made more easy to manage or available perhaps. Short side note, 'browse state' or 'browsing state' might do well too. It's not about modes, it's more about states, isn't it? Re: Comment #97 I used the term 'state' in the technical sense to indicate something which should be avoided from the usability perspective. That is, if an application can be in two different states in the same situation and then taking what the user thinks is the same action has two different results depending on the state; this is not desirable from the usability perspective. Specifically: Having only one home button which when clicked goes to different places depending on the state the browser is in is not good from a usability perspective. Having two home buttons resolves that issue and although it does result in one more icon on the tool bar, it is more intuitive than one button that does different things depending on something else which the user would have to remember. The cure for too many buttons is not to install as many less commonly used ones as the default and perhaps have a tutorial on configuring the browser since the great reconfigurability of Konqueror is one of its more powerfull features. Being able to have the configuration change based on the protocol (or K-Part) being used would extend this power. Re: Comment #98 In any case still, we should want to make sure this bug report results in having it become easy to set the home button(s) and no more part of any 'save view profile xyz'. I mean someone may look at this bug report title and still ask the simple question; so how _do_ I change the homepage, right now it's: save a view profile. That's simply not good from a usability point of view I would expect. "I used the term 'state' in the technical sense to indicate something which should be avoided from the usability perspective." Then what about 'browse mode'? I recommend searching this report for 'browse mode' and reading the arguments made about them. "Having only one home button which when clicked goes to different places depending on the state the browser is in is not good from a usability perspective. Having two home buttons resolves that issue" My argument is that we have more or less simply elegantly multiplied the problem. I agree that states or profiles can obscure the consistency of the home button, and the same can apply to two home buttons. I agree with implementing 2 buttons, but I don't agree that it solves the issue as you explain it unless you would make the locations for the home buttons independent from 'browse modes' or 'profiles', global. That would eliminate all confusion or potential problems about 'profiles' and the expected behaviour of the two available home buttons in any active 'profile'. Basically I think we need to make a choice between 2 global home buttons or keeping them related to 'browse modes' or 'profiles'. In any case, we have to make sure they are obvious to set regardless, or else the title of this report remains true. There sure is a lot of debate in this report... I am interesting in seeing the setting of home pages become more intuitive, probably even following other browsers' models. I know that I at least start up Konq in the my default web browsing profile, unless I open a folder to open a Konq window. Would it be possible to have Konqueror actually make use of the "Home Page" option for starting up in the web profile, or just saved as a component of each individual browsing profile, and support tabs? For example, if I use my default web profile, and use the home page setting under Settings -> Configure Konqueror -> Behavior -> Home URL, that should be saved inside the profile that I am using. If I want two pages to display, I should be able to use the pipe (|) character to separate them. That way, I could bring up everything I use daily, just by opening one Konq window. Example: http://www.slashdot.org/|http://ecampus.wintu.edu/|http://username.livejournal.com/friends Which would bring up three tabs with these items in them when I started Konq. When the "Home" button is pressed, it would open tabs with these items in them, unless tabs are already open with them (then it would just refresh them). As a Firefox convert, this is really the only feature I am missing. +10 votes. *** Bug 129069 has been marked as a duplicate of this bug. *** Two Home buttons seems the best solution. Perhaps i'm viewing some local files, and i want to check something really quick on the internet home page, i simply clik the "internet home page" button. Or i'm on the net, and i want to delete something quickly on my home dir, a single button press ought to be enough to get me there. Perhaps a Home icon with a mouse rapped around it could serve for the "internet home" button. Also, has this patch made it into Kde 3.5.3 ?? because i can't seem to find 2 home buttons here. Two home buttons is NOT a solution, it's GUI bloat. Konqueror has enough toolbar buttons already - if not too many. A single button press on a kicker button that starts konqueror in webbrowsing or filemanagement mode gives you the same. On Wed, June 28 2006 07:15, David Faure wrote: > > Two home buttons is NOT a solution, it's GUI bloat. Konqueror has enough > toolbar buttons already - if not too many. A single button press on a > kicker button that starts konqueror in webbrowsing or filemanagement mode > gives you the same. > I agree. Perhaps it would be best if the "home" page settings, and the default startup page settings, were unified, Firefox style, and saved _per profile_. That way, you can have the file manager profile which allows you to quickly and easily browse your filesystem, and you have the web profile which comes up with the "home page" settings you have for the web. An example: I start up Konq in web mode, and have my home page set to: http://my.livejournal.com/|http://slashdot.org/|http://ecampus.wintu.edu That should bring up three tabs, in the order specified. When I click the "Home" button, it should give me those three tabs again, with the first tab replacing the contents of the tab that I am in, and the two extras opening up in new tabs. In the file browsing profile, I could set something up like: /home/fd0man|/home/fd0man/docs/WIU|system:/ And should be able to open a filemanager window and get the three tabs there, as well. Of course, you could put filesystem items in the web profile and web items in the filesystem profile; the user would have total control over that. In the end, this manner of doing things would resolve the unintuitiveness of the current way of setting the start page vs. home page, and make it so that there is a reasonable degree of flexibility in the system, as well. The home-button-per-profile idea has been suggested many times, and I also agree that this is the most logical course of action. Maybe go even one step further by letting it up to the user what he wants to do with the home button as Michael Trausch already suggested. But the point that I post this here is that this discussion is going in circles, this bug is already 6 years old and nothing has changed...! When will a dev pick it up and finally make a decission on this matter? Another year and the result is... :-( On Friday 06 July 2007, Marek Laane wrote:
> Another year and the result is... :-(
The result is here. KDE4 will have dolphin (home page = $HOME) and konqueror (home page = web page of your choice,
which we can make easier to configure).
Re: Comment #106 I have basically forgotten about this because I have changed Konqueror to do what I want on my system -- I don't use a web home so I didn't implement this but it would be about the same as $HOME vs documentPath. The changes to the code are very simple, this would be configurable so that the user can have both a web-home (as the user has configured) _and/or_ a local directory (either $HOME or documentPath). The problem is that the Konqueror developers are not interested in making any changes even if this is totally configurable so that it could be configured to be exactly as it is now and this would be the default. My idea is as follows: We have a "Home" icon and "Go -> Home" menu item which is hard coded. If KGlobalSettings::documentPath() is not set to $HOME, this icon becomes: "User Files" and the menu item becomes "Go -> User Files". In the Konqueror KCMs we have: "Home URL". If this is set to something other than $HOME we add an icon and a "Go" menu item for "Home URL". To be complete, this should be checked to see if it was: "http://" "ftp://", "file///:", or on the LAN and an appropriate icon and "Go" menu item should be added based on the protocol. An alternative would be to port the Dolphin Location window to Konqueror as an additional toolbar. If added to Konqueror, this might need to be a bit more configurable. The bookmark sidebar is nice too but needs to have subdivisions. Dolphin has a goHome button and menu entry, but these are redundant and I removed them. This is not an either/or decision. This could also be configurable. Re: Comment #107 This isn't a result. Konqueror has a configurable "Home URL" and Dolphin has a configurable "Home URL". The only difference is that with Dolphin, you can't use HTTP. You CAN select an FTP page as Home in Dolphin. This doesn't in any address this issue. The only difference between this and the false and artificial division of Konqueror into WebBrowsing and FileManagement profiles is that Dolphin actually won't display HTTP protocol pages. wrt Comment #107: And both Dolphin and Konqueror have possibility to assign different home page per profile? It'd be really great! Dolphin aims at less complexity: it doesn't have profiles. In Konqueror, well, I thought we could do without home-page-per-profile which *is* really unintuitive. If using dolphin for file management and konqueror for web surfing, why would you need home-page-per-profile? > If using dolphin for file management and konqueror for web surfing, why would you need home-page-per-profile?
Konqueror not being the _default_ file browser anymore doesn't mean it's not a file browser anymore.
One of the two solutions should be implemented :
- 2 different actions : "User Files" and "Home URL"
- a configurable home per profile
OR if that's not the case, it should be made clear that konqueror is not intended to be used as a file browser anymore. And that is not what I hear from the community actually...
Re: Comment #109 > And both Dolphin and Konqueror have possibility to assign different home page > per profile? It'd be really great! Did you know that you can manage files with the WebBrowsing profile and browse the web with the FileManagement profile? In short, since this is an artificial distinction, I can't see why users would want to have two instances of Konqueror open just to have two different functions for the same button. This is Konqueror's greatest strength, it is a universal browser -- why people are determined to screw this up is something which I can't even begin to understand. IAC, this would be very bad from classical GUI usability theory. According to theory, clicking the same button should always do the same thing -- you should avoid having things based on a state. Having two different profiles that result in things working differently means two states and this is always bad. Re. comment #112 That's exactly what I mean: Home button has to bring you home! It means if one has profile MyWebHome and clicks on the Home after a lot webbrowsing has to bring him/her to the site he/he has declared the home page in the profile; and if he/she decides to use MyWebHome2, then click on the Home has to bring him/her to the profile's home page but not to some generally declared home page. Same in filebrowsing mode where one can have MyHome profile with home folder as home and e.g. MyFTPhome with some ftp directory as home. Of course, you can always reload your profile and result is same but then, what is Home button for at all? I completely agree with the above (#112) #112 comments diverge quite a bit from how average people use a computer though. Home is different in their http browser because it's not their file browser. In their minds, they are totally exclusive of each other. Attempting to teach them that konqueror does both is a long, steep, up hill battle for which there is no benefit to anyone. Good gui theory be damned because it's just not how people *use* their computers. #104 is a good description of how konqueror should function. Perhaps we could have the 'home' button act like the back button where it shows an amount of locations when you press and hold the home button? You could make the 'web' home location the default one and be the same in any profile. This way you can access all your preferred home locations quickly via your home button, plus access other home locations still. So if in a web profile I hit home, I go to my homepage. If I am browsing files, I still go to my homepage, unless I press and hold the home button, which would then show (custom) (home) locations. Looking at what Dolphin displays in the left bar (home, network, root etc), perhaps those should show up when you press and hold home in Konqueror, but your homepage could be the default. As well, we might consider calling 'viewing profile' 'browsing mode', at least personally I believe that is more self explaining. Re: Comment #115 The embedded premise here is that there are two things: 1. HTTP (web or HTML) browser 2. file browser > In their minds, they are totally exclusive of each other. There is no basis for this belief in reality. I doubt that people make any logical distinction between the internet and the "web". That is, do they use a file manager to go to FTP sites? And which do they use to view HTML files on their local network or local system? Actually, there are two things: 1. Browser 2. File manager Browsers browse files. I have never seen a browser that won't browse both files on a network (including the internet) as well as the files on the local system. If people have somehow developed a superstition that there was a difference between a web browser and a file browser, it would be informative to determine how this developed. > Attempting to teach them that konqueror does both is a long, steep, up hill > battle for which there is no benefit to anyone. Actually, we are attempting to teach people that that this artificial distinction exists. I would suggest that we stop. Now that we have Dolphin, it should be simple to do so. We eliminate the KFM command from KDE by replacing it with a call to Dolphin and call Konqueror a Browser (NOT a Web Browser). This shouldn't be confusing to people since Firefox exists and it isn't a *web* browser, it is just a browser. I don't think that many people use Firefox to browse local files, but that doesn't change the fact that it is quite able to do this. File managers manage files. KDE has a file manager usually called KFM (actually two of them: list and icon views) that run as parts in Konqueror. These are totally integrated into Konqueror so that they also do part of the browsing function when browsing on the local system, local network, or FTP sites. This integration of the file manager with (or into) the browser is one of Konqueror's greatest strength -- this is the great benefit! the integration of the file management functions in to the browser, that is to be gained: greater usability by loosing the superstition that they need to use two separate apps. I think that most people already realize that the file management is integrated into the browser function. You can't, I think everyone knows, manage files with Firefox. It will browse anywhere but it will not manage files. So, there is little to learn. All that is left is the strange superstition that you need to use a separate application to browse files using HTTP. And, the false belief that KDE had taught people (KFM is not just a file manager, it is a file browser). IMHO, people that have demanded a separate "file manager" will be surprised to find out that Dolphin is not a "file browser" (it is only a file manager). From comment #117 >There is no basis for this belief in reality. Correct. Calling it a superstition is a good way to describe it. And yet it exists. As a desktop admin I see it every day. Integrating file management into konqueror was a good idea and still is. Build on the good idea some more by adding profile-based home values. Some well-intentioned ideals bite the dust. It will attract more users because it's simpler to use. So much talk about such a stupid thing! Who needs a home button at all? I don't. It is not in my toolbar. (All I have there is back, forward, up, search, bigger text, smaller text, padlock, location and animated logo. And I could even remove half of those buttons without missing them. I prefer shortcuts anyway.) I do not see why bookmarks are not enough for everyone. Just let users add any number of custom bookmark buttons to their toolbars, each with a configurable URL, icon and tooltip. Problem solved. I don't understand why the home button being related to the web-profile-management or not should confuse user : By default its ok user who agree with this behavior will not look further. Power users, who may want a more highly configurable interface as kde always provided should find it !! (hey its why we use kde, and not gnome dude!, because its higly configurable by the gui!!) Basic end user who wants konqueror home button to be a homepage button for web-env profile will open konqueror settings and see "FILE MANAGEMENT SETTINGS page", he will think ok... i should go to "WEB BROWSING SETTINGS tab" and there he should fine something like : - a check box saying "Override the default file-management url" - a textbox beeing activated when you check above checkbox where he will input his default url for WEB BROWSING PROFILE. I use Kde because it can be exactly what user want it to be. If im looking for some epurated UI with no options directly accessible i will use gnome. Don't start becoming what torvalds called "nazi of the UI" If so many people feels this option is lacking (since 2000!!) it should be present now (2007). Thats all. Re: Comment #120 First I want to say that I, greatly appreciate feedback. However, that doesn't mean that developers will directly act on it. Which is the case with this suggestion. I don't think that KDE will ever implement a "Home" button that depends on the "View Profile". There are two reasons for this. 1. This part of Konqueror is considered to be a kludge since it mixes configuration and URLs. These two features need to be separated into configuration profiles and multiple tab bookmarks. Note that if toolbar configurations were fully supported in View Profiles that it would then be possible to have different Home buttons for different profiles and this would be OK from a usability standpoint since they different buttons would have different icons. 2. What you suggest is considered to be evil by all classical usability theory. Your question is how this would confuse the user. To me this seems simple. There is nothing in Konqueror that indicates which View Profile you are using, so you have no way of knowing what the "Home" button is linked to. If I have support for the above two solutions, I will work on it. So, there are two possibilities that I see as workable: 1. Have two buttons. One for the URL set in the configuration KCM and a second one for what ever directory that you have set for "Documents" in the Control Center -- this defaults to $HOME. I have a patch for this and will post it if anyone wants to try it. 2. Have the "Home" button act like it does in Dolphin and when clicked on displays a short list of "Places". This (Places) would also be added to the sidebar where it could be configured. This can probably be done using Dolphin code. I should note that I do not use separate View Profiles for browsing and file management. So, for me your proposed solution would be of no use. Since Konqueror is very configurable, we could do both and the user could use whichever one they wanted to use. Yes, it is time that something was done about this. My patch was not accepted. Therefore, I think that this has become a political issue rather than a technical issue. here is a simple way to separate out the profiles, make the url sensitive. as in, if a http url is entered, the web profile is used and so on. basically, this will make the button behave depending on what the user is doing at the moment. if one is browsing the local file system, the button will bring one to the users home dir. if one is browsing a webpage, it will bring the user to his homepage. if one is browsing a smb share, it will bring him to his home smb group. browsing ftp? brought to the (virtual) root. and the list goes on. Re: Comment #122 Yes, this is a good idea with one small addition. The icon on the button and the tooltip need to change to indicate which "home". re: #123 is that really needed? if the user cant tell from the url, how is he supposed to tell from the icon? that there is a globe in the corner when surfing a website? btw, after some playing around i think i may have misunderstood the reason for the profile system in konqueror... Just about to add a new bug when I saw this one. Very unintuitive, I expect the setting to be under Settings -> Configure Konqueror -> Web Behavior. The home page is now configurable in Settings -> Configure Konqueror -> General. This applies to konqueror when started as a webbrowser. When starting konqueror as a file manager, the home button leads to $HOME, as one might expect. Showing this difference with a change of icon in the toolbar button is a good idea, I'd be fine with that if a KDE artist could draw the appropriate icon. really cool, David! Setting this bug to VERIFIED, it has been open long enough ;) I even like it without additional artwork. First, we don't mark bugs as VERIFIED. Re: Comment #126: This is not a valid solution since it is based on a _state_ which is a bad idea according to usability theory. To be a valid solution, additional work needs to be done. Re: Comment #128 Well ... this _is_ a solution to _this_ bug ! If you don't agree with this solution, then it's a different matter. It might be the worse idea usability wise. I don't know. But whatever, it still requires to open another wish/bug. Re: Comment #128 Obviously, I do not agree. The title states that setting the home page in unintuitive. It is still unintuitive since you have no way of knowing which "home" will open. I have modified my KDE3 installation and I won't consider this fixed till KDE-4.1 has something that is just as good (doesn't have to be exactly the same). Thanks JRT, I knew I could count on you for reopening this bug :) As I said, please draw a "web home" and a "$HOME home" icon, and the usability issue will be solved. After deleting "$HOME/.kde4/share/apps/konqueror", I opened a KDE TRUNK session. I opened Konqueror as "webbrowser", clicked the "Home" icon on the toolbar and the KDE home page opened. Then: "Settings -> Load View Profile -> File Management" and $HOME opens. OK so far. Then I clicked the "Home" icon on the toolbar and the KDE home page opened. What am I missing here. Exactly what did your change? Hold on, hold on - not so fast!! If we 'solve' this bug, at least say 'sorry' to bug 8333 for changing her sensitive status. Bug 8333 is the pre-alpha, alpha, beta and omega among KDE versions. She has a message for us and your children will call her 'grandmother'. Threat her gently. Popcorn anyone? Loading a profile only changes the arrangement of views, not the mode of this konqueror process. To get a filemanagement window, one would normally launch konqueror using the icon that launches "kfmclient openProfile filemanagement"... that's the start menu item called "Home", actually, it should probably be renamed to "Konqueror File Manager", to differenciate from dolphin. I guess we also need a config option for "make konqueror the default filemanager" so that when opening a directory from anywhere (file dialog, desktop folder, etc.) a konqueror window opens instead of dolphin (this is already doable in the filetypes editor, using inode/directory, but that's a bit too hidden, obviously). Anyway: the idea is: there are two applications, "konqueror as webbrowser" and "konqueror as filemanager", we just need to let users be able to start the second one more easily than "konqueror --profile filemanagement" or "kfmclient openProfile filemanagement". Maybe simply a "konqueror filemanager" The idea for making this per-process and not per-window is that it will simplify the whole logic of "not reusing filemanager processes when opening a webbrowsing window, in case the web page makes konqueror crash" -- this is done in a very complicated way currently, we should just split them per-process by treating konq-web and kfm as two different apps even though they are implemented by the same app. But this is off-topic for this bug. Setting the home page is now intuitive, for anything else please open a new bug (and assign it to me). My vote is for a solution ala comment 122 - or that solution can be put on top of yours even still. Namely, a direct url/protocol to home relation looks like a relatively simple concept and is flexible at the same time - plus it could grow 1:1 with however many protocols konqueror can handle in any environment. Konqueror's strong point is exactly that it can handle allot of protocols and having a home per protocol sounds sane to me, as all home now does is be 1 home loation. One could argue over a home location based on string patterns in the url, so if you are using for example fish, you could even apply different home locations, meaning when you are on server #1 you have one particular home and on server #2 you have another home. I will file a new feature request around this concept and see if it get's anywhere. A URL-based home isn't practical. What if you have tabs, with file://$HOME in one, http://www.kde.org in another, and some FTP site in another? OK you could use the visible tab, but if you split views then the problem is back. And talk about a constantly-changing behavior :( I think everyone should try the current (trunk, future 4.1) behavior (once it has a nice different icon) before suggesting more changes to the button's behavior. A URL-based home isn't practical? I would not support the idea myself if I thought it was not practical. But I think you confuse the idea I support as being 1 solution over yours. By now I think some more extended ability to set home(s) in relation to url/protocol is a valuable addition in the konqueror working environment - separate from the problem around view profiles and how they affect home button behavior. I agree about constantly changing behavior being a problem here - and it would have to be some none default ability I think. If you have tabs then home can be based on the active tab url/protocol. If you have 'one tab', that is the active tab as well, so the same applies there. If you split views, it still is the active view which counts. So...I think what I mean is active view, whatever the active view is, which automatically means which active tab. You would not have to give up a 'fixed' home for a viewing profile. If a new tab/view is opened without url, use the current active profile default home. If a new konq. is opened, use the home location for that active profile. If a view has an active url/protocol, there could be a home in relation to that, optionally. I think you would not have to give up your suggestion of 'mode of this konq. process'. Your kind of suggestion could solve one part of the problem. comment 122 would not need to be default behavior, but could make konq. more powerful. If I had the time, I would add a demo for this to konq., but I don't so I doubt it will get implemented. But this is getting all too confusing for me to deal with in this bug report. David: As I presume you know, I am a strong advocate of the ideas behind Comment #122. So, my first thought about your "fix" is that it is a bad idea -- that you are going in the wrong direction with further dividing Konqueror and creating 4 states. This small step should be simple to do correctly. IIUC, there are two files: konq-filemanagement.rc konq-webbrowsing.rc Wouldn't it be better to base the home selection on which one of these files was currently being used? Casper on comment #137 has done a very nice job of describing how the home button should work. My efforts to describe the home button function did not get the idea across the way his post does. JRT: there's also a konq-simplebrowser.rc -- does this mean there's a third home location just because some distros/profiles/people removed some toolbar buttons? There are no 4 states, there are two applications, kfm and konqueror (conceptually). There are most probably bugs in the separation of those two apps, let's just fix those. #122/#137 would confuse the hell out of most users for sure. You navigate into some ftp or smb link, then you're done and want to go back to your $HOME, you click on the home button, as you always did... The root folder of an FTP server is totally uninteresting, and so is the smb group, if you didn't come from there. Most users are NOT involved in this discussion, it should just work out of the box for them without having to realize that 1) profiles exist 2) there are different xmlgui files per profile and/or 3) that button will lead them somewhere else depending on where they currently are. IMHO #122 only confirms that yes, you want the homepage when browsing the web and the home dir when using the filemanager, that's exactly what I implemented, we just need to handle some corner cases right. For instance JRT's "loading the filemanagement profile" should replace the current window with a new one [in a new process] if the current window was a webbrowser window -- this is what is already happening when choosing a profile that specifies another .rc file, in fact. Should all be transparent to the user, but as a result, it becomes a filemanagement window. Another solution would be to split filemanagement profiles and webbrowsing profiles and only show those that match the running "app"... "You navigate into some ftp or smb link, then you're done and want to go back to your $HOME, you click on the home button, as you always did..." "The root folder of an FTP server is totally uninteresting, and so is the smb group, if you didn't come from there." Most FTP applications have some home location, as do my different ssh enabled servers. I go deeper into the file tree and sometimes a home on each of these would be very useful in stead of up-up-up-up.... Ah, yes, I should use profiles for that... right? Maybe stick to bookmarks. I guess. "Most users are NOT involved in this discussion, it should just work out of the box for them without having to realize that 1) profiles exist 2) there are different xmlgui files per profile and/or 3) that button will lead them somewhere else depending on where they currently are." Looking forward to KDE 4.1. Re: Comment #140 It is very unfortunate when what should be a discussion of how best to do things breaks down into a rhetorical argument. In rhetoric, you comment can be characterized as 'hit and run'. It accomplishes very little. The Strawmen that you offer make very little sense. They can mostly be disposed of with one fact. You can configure this does not mean that you must. Clearly, you start with defaults and these are changed ONLY if the user chooses to do so. > JRT: there's also a konq-simplebrowser.rc -- does this mean there's a third > home location just because some distros/profiles/people removed some toolbar > buttons? No, it actually means that there is a binary question: IF using konq-filemanagement.rc THEN home is $HOME ELSE home is web home This is not rocket science -- it is just another strawman. There are in fact 4 states. You can open Konqueror as "WebBrowser" or FileManager. And, you can do webbrowsing or filemanagement in either one. So, there are 4 states. You do the math. In my proposed solution. There is 2 states (either it is filemanagement or it isn't). Your attempt to split Konqueror into two applications will distroy one of KDE's best features. Konqueror is the universal browser. A browser that also has the ability to run a filemanager as a plugin. So, this is another possibility. If the Dolphin plugin is active, then home is $HOME, otherwise it is the web home. This has the advantage that there is NO state issue at all and it is simple to tell when the Dolphin plugin is active. Your additional ideas of further splitting Konqueror into two applications are even worse ideas. OK, after a long discussion on IRC with many other users and developers, I'm convinced. Unifying konqueror again as much as possible, but making as many things as possible view-dependent (which is something I've been doing a lot lately anyway). If done completely, I want to get rid of konq-filemanagement.rc altogether. The home button being view-dependent seems to be what everyone expects, so I'll implement that. For more discussion, I suggest the kfm-devel mailing-list; this bug is fixed for sure, and it's a bad replacement for a mailing-list :-) OK, further design discussion on KFM-Devel. See you all there. SVN commit 817618 by dfaure: *Finally* fix 8333: "setting the home page is unintuitive". It was both about the home button (which is fixed now) and about the startup page of konqueror (which I thought was fixed, so I closed 8333, but I then discovered that it was in fact not fixed yet, the only way to change the start page was still the unintuitive "save view profile webbrowsing"). Fixed now, the way all other browsers do it: FEATURE: added a combobox in the configuration page, which says "When Konqueror starts: Show the introduction page / Show my home page / Show a blank page" New strings approved by kde-i18n-doc. CCBUG: 8333 M +126 -3 settings/konqhtml/generalopts.cpp M +2 -0 settings/konqhtml/generalopts.h M +2 -2 src/konqviewmanager.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=817618 |