[Patch] Unified reload/stop actions

Hi,

some time ago I posted a patch on reviewboard about the unification of the
reload and stop action (similar to Opera and Safari). David Faure commented
quite a bit but we came to no conclusion, so I'd like to get some more
feedback.

patch URL: http://reviewboard.kde.org/r/593/

p.s.:
        please CC me, I'm not on this list
--
Sascha Peilicke
http://saschpe.wordpress.com

[Shaun Reich]

My personal opinion on merging the actions.. is that I don't like it :)

I have used applications that have done this before (memory serves me
not), but it's an annoyance for me at least. An aspect that really
annoys me, is when you are in the process of loading a big web page,
you hit the button (that is now set to the Stop action), but at that
very second, it finished, and you end up reloading the page.

Also, is it a good idea.. with respect to average users, to have
actions that change like that, into complete opposites. In the context
of e.g. a dialog, where it has the less/more thing, it makes sense to
change that button.. but this is only after the user actually does
something, whereas here it kind of does it out of it's own free will.

 But on the other hand, is the Stop action really used that much? On
additional thought, I'm not sure many use it, especially the "average
user". If this is true, then I suppose it would be beneficial to merge
them, avoiding clutter/confusion(?), etc.

In all honesty, I am quite skeptical on the first use-case I made
against it, wherein the action can quickly turn the other way, into
it's opposite action.....and reloading a bloaty page on a slow connect
is....unfun (although, I am blessed with a fast one :P ).

Hopefully others can offer some better opinions ;-)

--
--
Riverenter Vestri,
Shaun Reich


On Wed, Apr 29, 2009 at 3:29 PM, Sascha Peilicke <sasch.pe@...> wrote:

> Hi,
>
> some time ago I posted a patch on reviewboard about the unification of the
> reload and stop action (similar to Opera and Safari). David Faure commented
> quite a bit but we came to no conclusion, so I'd like to get some more
> feedback.
>
> patch URL: http://reviewboard.kde.org/r/593/
>
> p.s.:
>        please CC me, I'm not on this list
> --
> Sascha Peilicke
> http://saschpe.wordpress.com
>

Am Mittwoch, 29. April 2009 schrieb Sascha Peilicke:
> some time ago I posted a patch on reviewboard about the unification of the
> reload and stop action (similar to Opera and Safari). David Faure commented
> quite a bit but we came to no conclusion, so I'd like to get some more
> feedback.

We have had this discussion already years ago. The general issue with unified
reload/stop is, as long as the page loads, the button displays stop.

Say, loading takes you too long and you decide to abort. Then you click stop.
But ten milliseconds before, loading finishes and the stop button becomes the
reload button.

Your brains might recognise what happened, but it's too late to recall the
command to your index finger muscles.

Then you may wait again all the time.

Back then we decided to leave things in place, and we also should leave them
now.

mfg
        Leo

[Michael Pyne]

On Sunday 10 May 2009 15:24:58 Leo Savernik wrote:

> Am Mittwoch, 29. April 2009 schrieb Sascha Peilicke:
> > some time ago I posted a patch on reviewboard about the unification of
> > the reload and stop action (similar to Opera and Safari). David Faure
> > commented quite a bit but we came to no conclusion, so I'd like to get
> > some more feedback.
>
> We have had this discussion already years ago. The general issue with
> unified reload/stop is, as long as the page loads, the button displays
> stop.
>
> Back then we decided to leave things in place, and we also should leave
> them now.

The other option is to add a dedicated Stop/Reload action in addition to the
separate ones instead of instead of them.

Of course it's more annoying to implement, but not much more so IMO, it just
depends on how many people really want that extra customizable button for
their toolbar.

Regards,
 - Michael Pyne

Am Donnerstag, 14. Mai 2009 schrieb Michael Pyne:
> > Back then we decided to leave things in place, and we also should leave
> > them now.
>
> The other option is to add a dedicated Stop/Reload action in addition to
> the separate ones instead of instead of them.

Yes, that'd be way better. However, separated stop/reload should stay for the
default web-profile. A dedicated firefox/ie/opera/whatever-profile could make
use of the combined button.

mfg
        Leo

On Thursday 14 May 2009 22:23:12 you wrote:

> Am Donnerstag, 14. Mai 2009 schrieb Michael Pyne:
> > > Back then we decided to leave things in place, and we also should leave
> > > them now.
> >
> > The other option is to add a dedicated Stop/Reload action in addition to
> > the separate ones instead of instead of them.
>
> Yes, that'd be way better. However, separated stop/reload should stay for
> the default web-profile. A dedicated firefox/ie/opera/whatever-profile
> could make use of the combined button.

Hmm, wouldn't that add even more config options to konq? I would recommend a

decision either for or against it, there's already way to much options to
_tweak_ konq. I thought about that unification to help simplify the UI a bit.
IMHO in it's current state it is way to cluttered with buttons and toolbars
(even more true when another kpart is shown) which is a big contrast to all
the other browsers available.
--
Sascha Peilicke
http://saschpe.wordpress.com

Am Freitag, 15. Mai 2009 schrieb Sascha Peilicke:

> > Yes, that'd be way better. However, separated stop/reload should stay for
> > the default web-profile. A dedicated firefox/ie/opera/whatever-profile
> > could make use of the combined button.
>
> Hmm, wouldn't that add even more config options to konq? I would recommend
> a decision either for or against it, there's already way to much options to
> _tweak_ konq. I thought about that unification to help simplify the UI a
> bit. IMHO in it's current state it is way to cluttered with buttons and
> toolbars (even more true when another kpart is shown) which is a big
> contrast to all the other browsers available.

I think you misunderstand. The options are already there. They are called
toolbar customisation. The profiles are aleady there, they just have to be
prepared appropriately.

Konqueror is not just a browser. It's a swiss army knife, KDE's universal
viewer. Konqueror retains its followers *because* of the way it is, not
despite. For those wanting a simplified khtml-based browser, it suggest
looking at rekonq or arora.

And, as I mentioned above, we can still have a simplified browsing profile --
btw, I've just looked: In KDE 3.5 it already exists, it's called "Simple
Browser". That could be augmented with a single reload/stop-button.

mfg
        Leo

Leo Savernik wrote:
> For those wanting a simplified khtml-based browser, it suggest
> looking at rekonq or arora.
You mean webkit-based. There is, to my knowledge, no other khtml-based
browser than Konqueror.

Aurélien

[Jos Poortvliet-4]

2009/5/17 Aurélien Gâteau <agateau@...>:
> Leo Savernik wrote:
>> For those wanting a simplified khtml-based browser, it suggest
>> looking at rekonq or arora.
> You mean webkit-based. There is, to my knowledge, no other khtml-based
> browser than Konqueror.

True, small slip of the tongue I guess. Doesn't defeat his point - the
power of konqi is in the attraction to power users...

> Aurélien
>

Jos Poortvliet wrote:
> 2009/5/17 Aurélien Gâteau <agateau@...>:
>> Leo Savernik wrote:
>>> For those wanting a simplified khtml-based browser, it suggest
>>> looking at rekonq or arora.
>> You mean webkit-based. There is, to my knowledge, no other khtml-based
>> browser than Konqueror.
>
> True, small slip of the tongue I guess. Doesn't defeat his point - the
> power of konqi is in the attraction to power users...

What I meant is that there is no simple khtml-based alternative to
Konqueror. Konqueror is the only solution KDE provides to browse the
web, so it should not focus on power users only, unless the goal is to
ensure casual users/distributions switch to alternatives like Firefox
(or Arora or Rekonq when they are ready).

The simple-browser profile is probably a way to address this problem,
but Konqueror still needs to be de-cluttered quite a bit IMHO.

Aurélien

[Jos Poortvliet-4]

2009/5/18 Aurélien Gâteau <agateau@...>:

> Jos Poortvliet wrote:
>> 2009/5/17 Aurélien Gāteau <agateau@...>:
>>> Leo Savernik wrote:
>>>> For those wanting a simplified khtml-based browser, it suggest
>>>> looking at rekonq or arora.
>>> You mean webkit-based. There is, to my knowledge, no other khtml-based
>>> browser than Konqueror.
>>
>> True, small slip of the tongue I guess. Doesn't defeat his point - the
>> power of konqi is in the attraction to power users...
>
> What I meant is that there is no simple khtml-based alternative to
> Konqueror. Konqueror is the only solution KDE provides to browse the
> web, so it should not focus on power users only, unless the goal is to
> ensure casual users/distributions switch to alternatives like Firefox
> (or Arora or Rekonq when they are ready).

We don't have to ensure many casual users switch to alternatives like
Firefox, pretty much all of them already have. I know the problem
isn't in KHTML perse, but that doesn't change the situation it lacks
support for many modern sites like GMail and Google Docs. Konqi's
power is more in local & remote filemanagement & the powerful KParts
support, imho. KHTML is just one of it's KParts. Isn't this
mailinglist called KFM ;-)

> The simple-browser profile is probably a way to address this problem,
> but Konqueror still needs to be de-cluttered quite a bit IMHO.

Absolutely, but I would be careful alienating the powerusers. They are
an important part of the usergroup for Konqi.

> Aurélien



Like many, I'm eagerly awaiting the moment I can use a well-integrated
KDE browser with all websites I use. I'm completely satisfied with
KHTML in Akregator, as the sites I read news from mostly work (I load
the full website on viewing news items), but I always have to have
that loathsome firefox open for google docs, gmail etc. Unfortunately
Arora nor Rekonq are complety ready yet, and even if they were, I'd
rather have konqi with a good webkit KPart. The current one is barely
adequate.

Aaah well, I think this issue will solve itself in time, and it's good
that thought is spend on making konqi ready for the day the casual
endusers can enjoy it once again.

And more on-topic, I think the simple-browser profile should have the
combined stop/reload button... And I will personally configure the
other profiles to use it as well.

This doesn't add more options (only if you configure the toolbar there
is an additional entry on the left) so I don't see a reason not to add
it. Even if none of the default profiles have it.

grtz

[Luciano Montanaro-3]

On Mon, May 18, 2009 at 11:05 AM, Jos Poortvliet
<jospoortvliet@...> wrote:


>
>
> Like many, I'm eagerly awaiting the moment I can use a well-integrated
> KDE browser with all websites I use. I'm completely satisfied with
> KHTML in Akregator, as the sites I read news from mostly work (I load
> the full website on viewing news items),

Speaking of which... I think the current way full-page zoom is
implemented is a bit of a regression with regards to akregator and
kmail.

I'm used to use the Ctrl+wheel action quite often on html pages or
even in kmail reader to increase the font size, but currently the
wheel zoom zooms the whole page (images and all), which is not what I
want when zooming on the akregator article summary or the mail message
(because then the horizontal scrollbar appears, and I have to scroll
horizontally to read the mail text). I think this is one point where
the Firefox approach would work better in khtml also:

The zoom action is one only, and you can chose if it should affect
only text or also images with a checkbox in the menu.


If the default were "only text", this would make the default khtml
view work well for kmail and akregator, I think.

Maybe I should file a bug about this, but would anybody object to such
a patch? I'd like working on it, if this is considered useful.



--
Luciano Montanaro

Anyone who is capable of getting themselves made President should on
no account be allowed to do the job. -- Douglas Adams

[Jos Poortvliet-4]

On Mon, May 18, 2009 at 11:38 AM, Luciano Montanaro <mikelima@...> wrote:

> On Mon, May 18, 2009 at 11:05 AM, Jos Poortvliet
> <jospoortvliet@...> wrote:
>
>
>>
>>
>> Like many, I'm eagerly awaiting the moment I can use a well-integrated
>> KDE browser with all websites I use. I'm completely satisfied with
>> KHTML in Akregator, as the sites I read news from mostly work (I load
>> the full website on viewing news items),
>
> Speaking of which... I think the current way full-page zoom is
> implemented is a bit of a regression with regards to akregator and
> kmail.
>
> I'm used to use the Ctrl+wheel action quite often on html pages or
> even in kmail reader to increase the font size, but currently the
> wheel zoom zooms the whole page (images and all), which is not what I
> want when zooming on the akregator article summary or the mail message
> (because then the horizontal scrollbar appears, and I have to scroll
> horizontally to read the mail text). I think this is one point where
> the Firefox approach would work better in khtml also:
>
> The zoom action is one only, and you can chose if it should affect
> only text or also images with a checkbox in the menu.
>
>
> If the default were "only text", this would make the default khtml
> view work well for kmail and akregator, I think.
>
> Maybe I should file a bug about this, but would anybody object to such
> a patch? I'd like working on it, if this is considered useful.

Hmmm. I personally like the full page zoom. Maybe configurability is
indeed an option, but what about something like ctrl-shift-scroll, or
ctrl-+ and ctrl-shift-+?

>
>
> --
> Luciano Montanaro
>
> Anyone who is capable of getting themselves made President should on
> no account be allowed to do the job. -- Douglas Adams
>

[Luciano Montanaro-3]

On Mon, May 18, 2009 at 11:50 AM, Jos Poortvliet
<jospoortvliet@...> wrote:

>
> Hmmm. I personally like the full page zoom. Maybe configurability is
> indeed an option, but what about something like ctrl-shift-scroll, or
> ctrl-+ and ctrl-shift-+?
>

It's not that it's not useful; when I saw it implemented, I thought It
would be a useful addition.
The problem is that it often makes reading enlarged pages use
horizontal scrolling. Depending on the page at hand one method is
better than the other...

Yes, one solution would be to add extra menu items/shortcuts for the
text-only zoom...

But that would clutter the menu more than an extra checkbox.

Right now the menu only has the zoom character entries...
with a submenu each.

Firefox has only a zoom item, with "zoom in", "zoom out", "Reset" and
"Zoom text only" items.

I'd like to make konqueror use the same interface... This does not
preclude the use of either action. It only reorganize the menue, maybe
reducing "clutter". And it makes it clear that two different actions
are available (the Ctrl+wheel actions are not available as a menu
item).

Also, in general, I'd like to use the same menu structure in the
filemanager kpart.
Zooming is available there as well, but it's not visible in the user
interface at all, I see...
I think this also is a regression compared with KDE 3 Konqueror.

Uhm...  I thought this was due to Dolphin KParts, but in Dolphin the
Zoom in and Zoom out actions are available. So it's Konqueror that is
not offering the actions.
Maybe it would make sense to find some common ground?

I'm CC'ing this to the usability list too, maybe it would be a nice
guideline to add for programs that have the ability to show various
levels of zoom on a document. We have quite a few of them: Konqueror,
Dolphin, Okular, Gwenview... I'm sure there are more, or there could
be more. Wouldn't it make sense to define a basic set of features to
offer, and offer them consistently?

The firefox Zoom ->In/Out/Reset model could be a starting point...


--
Luciano Montanaro

Anyone who is capable of getting themselves made President should on
no account be allowed to do the job. -- Douglas Adams

[Jos Poortvliet-4]

On Mon, May 18, 2009 at 1:44 PM, Luciano Montanaro <mikelima@...> wrote:
<snip>

> I'm CC'ing this to the usability list too, maybe it would be a nice
> guideline to add for programs that have the ability to show various
> levels of zoom on a document. We have quite a few of them: Konqueror,
> Dolphin, Okular, Gwenview... I'm sure there are more, or there could
> be more. Wouldn't it make sense to define a basic set of features to
> offer, and offer them consistently?
>
> The firefox Zoom ->In/Out/Reset model could be a starting point...

For what it's worth, I think you should go ahead ;-)

>
> --
> Luciano Montanaro
>
> Anyone who is capable of getting themselves made President should on
> no account be allowed to do the job. -- Douglas Adams
>