Nabble - kfm-devel

Re: Actions extensions in File Manager

2009-12-17T14:30:31Z

Hi David,

I've rewritten most of the first version of draft to take into account
your (welcome) remarks. So the v 0.2 is ready at [1].

Though I've not really tried to mimic the KDE Services Menus, I've yet
tried to put all required functionalities, possibly extending some of
them, taking advantage of writing a new specification.

And, humm.. there is always one action per .desktop file ;-)
But no more XML.

All comments are more than welcome.
Regards
Pierre

[1] http://www.nautilus-actions.org/?q=node/377

Re: Patch for bug #200795

2009-12-11T10:32:28Z

Hi,
I revisited the patch sent previously because probably I had not fully
understood what was suggested by the KHTML developers... i hope now it's the
case :-)
Function shouldDisableNativeBorders() now really handles the case where native
borders have not to be painted (either because we have to paint css borders
or we have not to paint borders at all because border:none)
I added a partial fix (or workaround?) for bug #216795: force setting of
qlineedit native frame (just in case previously disabled); may be the
real/better fix here is to handle qlineedit widget borders through proxy
style (if yes, i have not been able to achieve this :-( )

Is that waht's expected?

(I'm sorry if I'm only causing noise but I am new to khtml and qt4)

Best Regards,
Andrea.

[attachment removed]

Several patches for Solaris builds

2009-12-11T07:13:31Z

Hi,

the kde-solaris project uses several patches to be able to build KDE4
with Sun Studio on OpenSolaris. They are needed since the compiler is
stricter about the C++ standards than gcc.

The below bug reports have the patches attached.
The patches are being used for several months already, they're very
simple, but they weren't tested on other platform.

https://bugs.kde.org/show_bug.cgi?id=191750
https://bugs.kde.org/show_bug.cgi?id=191763
https://bugs.kde.org/show_bug.cgi?id=191764
https://bugs.kde.org/show_bug.cgi?id=191789
https://bugs.kde.org/show_bug.cgi?id=191799
https://bugs.kde.org/show_bug.cgi?id=191810

best regards

Pavel Heimlich

Re: Tab moving in Konqueror

2009-12-11T04:55:19Z

Hi David, hi everyone,

2009/12/9 David Faure:

> On Wednesday 25 November 2009, Frank Reininghaus wrote:
>>
>> it seems that tab moving in Konqueror (and any other app that uses the
>> traditional middle-click tab moving) is broken at the moment:
>>
>> https://bugs.kde.org/show_bug.cgi?id=214646
>>
>> Regardless of this bug (which should of course be fixed before 4.4.0)
>> I'm wondering if it makes sense to use Qt's tab moving with the left
>> mouse button in Konqueror instead.
>> [...]
>> The disadvantage would be that drag&drop of the tab url would not work
>> any more, but I would guess that this feature is used a lot less than
>> tab moving?
>
> I guess that makes sense, yes. More "behaviour compatible" with other
> browsers, and indeed one can use "duplicate tab" instead of DND (which also
> duplicates the current url into another tab, but without back/forward
> history).

OK, how shall we proceed? I can see 3 options:

1. Make the change now (it's actually a bug fix because tab moving is
broken at the moment).

2. Make the change in KDE 4.5.

3. Get further feedback (maybe from usability people) before a decision is made.

David, what do you think? If we go for 1., we should maybe do it
before Beta 2 is tagged.

Best regards,
Frank

Re: Actions extensions in File Manager

2009-12-10T14:51:34Z

----- "PCMan" <pcman.tw@...> wrote:

> How do you handle menu items which have submenus?

I agree that, for now, actions are just an unordered flat list of
items. IMHO, a menu item which handle a submenu is just a menu:
a label, an icon, and an ordered list of items (actions or menus).
So I think this should be handle by the menu spec.

> Besides, some kind of caching is needed. Otherwise having to read
> many files can hurt performance.

Do you are just afraid of such a possibility, or do you have any
measures ? Disks have cache, filesystem drivers have cache, and the
code ran to just display a context menu may already be considered
as heavy (evaluate the selection, build mimetype-depending options,
and so on...).
We also may suppose that file manager only loads these actions once,
and install a monitoring to reload them when the underlying storage
space is changed.

> > - menu definition is left to the already existing spec [5] ; I find
> > it very complicated, and it may also need an extension, but it
> > exists and cannot just be thrown away
>
> This one is apparently too complicated for what we need in file
> managers. The current menu spec almost has nothing in common with
> file manager actions. A new spec specifically designed for this
> work should be better.

Better, I don't know, but surely simpler ;-)
Essentially, the spec says (see [7]) :
a) you define a menu in a .directory file, with a label and an icon
b) you define the order of the items, in a .menu xml file.
This may not even need an extension of the spec, but rather a
simplification to better suit our needs.

We would just have to carefully place our own files to no risk
a collision with the global Applications menu.

But, eventually, yes, I agree that any spec is not complete while
the menus are not described and properly managed. I'll work on
this point.

> >
> > [1] http://www.nautilus-actions.org/?q=node/377
> > [2]
> http://lists.freedesktop.org/archives/xdg/2006-February/006094.html
> > [3] http://lists.freedesktop.org/archives/xdg/2006-June/006612.html
> > [4]
> http://lists.freedesktop.org/archives/xdg/2009-August/010914.html
> > [5] http://standards.freedesktop.org/menu-spec/latest/
> > [6] http://standards.freedesktop.org/desktop-entry-spec/latest/
[7] http://standards.freedesktop.org/menu-spec/latest/apcs03.html

Regards
Pierre

Re: Actions extensions in File Manager

2009-12-10T09:30:03Z

On Thu, Dec 10, 2009 at 11:25 PM, Pierre Wieser <pwieser@...> wrote:

> Hi all,
>
> I've eventually written my own draft of a desktop entry specification
> extension ; it is available at [1].
>
> I don't have found a real consensus in the discussions which have
> already taken place here (see e.g. [2], [3], [4]).
> I have so preferred to go with a different approach which could be
> summarized in two points :
>
> - there is only one action per .desktop file, maybe with several profiles
> which may apply to different environments ; only the first profile
> whose conditions are met will be candidate to be displayed in the
> context menu for this action

How do you handle menu items which have submenus?
Besides, some kind of caching is needed. Otherwise having to read many
files can hurt performance.
> - menu definition is left to the already existing spec [5] ; I find
> it very complicated, and it may also need an extension, but it
> exists and cannot just be thrown away
This one is apparently too complicated for what we need in file
managers. The current menu spec almost has nothing in common with file
manager actions. A new spec specifically designed for this work should
be better.

> I'm conscious that this proposal is probably not what you could
> have wished. Do you are willing to comment this draft ?
>
> Thanks in advance
> Regards
> Pierre
>
> [1] http://www.nautilus-actions.org/?q=node/377
> [2] http://lists.freedesktop.org/archives/xdg/2006-February/006094.html
> [3] http://lists.freedesktop.org/archives/xdg/2006-June/006612.html
> [4] http://lists.freedesktop.org/archives/xdg/2009-August/010914.html
> [5] http://standards.freedesktop.org/menu-spec/latest/
> [6] http://standards.freedesktop.org/desktop-entry-spec/latest/
> _______________________________________________
> xdg mailing list
> xdg@...
> http://lists.freedesktop.org/mailman/listinfo/xdg
>

Re: Actions extensions in File Manager

2009-12-10T07:25:54Z

Hi all,

I've eventually written my own draft of a desktop entry specification
extension ; it is available at [1].

I don't have found a real consensus in the discussions which have
already taken place here (see e.g. [2], [3], [4]).
I have so preferred to go with a different approach which could be
summarized in two points :

- there is only one action per .desktop file, maybe with several profiles
which may apply to different environments ; only the first profile
whose conditions are met will be candidate to be displayed in the
context menu for this action

- menu definition is left to the already existing spec [5] ; I find
it very complicated, and it may also need an extension, but it
exists and cannot just be thrown away

I'm conscious that this proposal is probably not what you could
have wished. Do you are willing to comment this draft ?

Thanks in advance
Regards
Pierre

[1] http://www.nautilus-actions.org/?q=node/377
[2] http://lists.freedesktop.org/archives/xdg/2006-February/006094.html
[3] http://lists.freedesktop.org/archives/xdg/2006-June/006612.html
[4] http://lists.freedesktop.org/archives/xdg/2009-August/010914.html
[5] http://standards.freedesktop.org/menu-spec/latest/
[6] http://standards.freedesktop.org/desktop-entry-spec/latest/

Re: Tab moving in Konqueror

2009-12-09T01:41:09Z

On Wednesday 25 November 2009, Frank Reininghaus wrote:

> Hi everyone,
>
> it seems that tab moving in Konqueror (and any other app that uses the
> traditional middle-click tab moving) is broken at the moment:
>
> https://bugs.kde.org/show_bug.cgi?id=214646
>
> Regardless of this bug (which should of course be fixed before 4.4.0)
> I'm wondering if it makes sense to use Qt's tab moving with the left
> mouse button in Konqueror instead.
>
> The advantage would be that it's probably more intuitive (it's been
> requested a couple of times on bugs.kde.org, and other browsers like
> Firefox and Arora also use the left button for moving tabs) and that
> the moving is animated nicely by QTabBar. Moving tabs with the middle
> mouse button would still work.
>
> The disadvantage would be that drag&drop of the tab url would not work
> any more, but I would guess that this feature is used a lot less than
> tab moving?

I guess that makes sense, yes. More "behaviour compatible" with other
browsers, and indeed one can use "duplicate tab" instead of DND (which also
duplicates the current url into another tab, but without back/forward
history).

--
David Faure, faure@..., http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

Re: PATCH: Entering the same url in Konqueror's location bar...

2009-12-07T11:11:09Z

On Monday 30 November 2009 19:15:45 David Faure wrote:
> On Thursday 05 November 2009, Dawit A. wrote:
> > + // If the current url in the view is the same as the one being
> > displayed + // simply do a reload instead of calling openUrl...
>
> I'm against this.
> It's a very convenient feature that Enter in the location bar doesn't do
> a reload. Think of pages which you can "post" to, and which you can
> also just open directly. If you reload, it will (offer to) re-post the
> data. If you press Enter, it will load the page without using post data.

I had already abondened this patch since it does not completely fix the problem
at all. As far as how pressing enter again and again should behave, I have no
preference. I just do not want the backward history navigation not to be
screwed up ;)

> Admittedly I don't know what other browsers do, but I really like the
> current behavior.

Not sure about this either since you cannot tell from the behavior of the
applications.

> If the bug is duplication in the history list, I think it should be fixed
> at the level of the history list (I assume this is about the back/forward
> history, not the 500-last-visited-pages history).

Yes, and I did attempt to fix it at that level but my changes caused other
problems. I will probably revisit the issue once I have the time for it.
Unlike the previous attempt to fix the problem, this is actually the only level
where the problem can be solved without side effects...

Re: Tab moving in Konqueror

2009-12-06T13:04:46Z

Hi,

On Sunday 06 December 2009 15:23:25 Jos Poortvliet wrote:

> On Wednesday 25 November 2009 14:18:40 Marcus Harrison wrote:
> > On Wednesday 25 Nov 2009 10:26:32 Frank Reininghaus wrote:
> > > Hi everyone,
> > >
> > > it seems that tab moving in Konqueror (and any other app that uses the
> > > traditional middle-click tab moving) is broken at the moment:
> > >
> > > https://bugs.kde.org/show_bug.cgi?id=214646
> > >
> > > Regardless of this bug (which should of course be fixed before 4.4.0)
> > > I'm wondering if it makes sense to use Qt's tab moving with the left
> > > mouse button in Konqueror instead.

[...]
> > Therefore, I consider this a net-gain, not a net-loss action. I would
> > move over to Qt's tab-bar implementation and make contributions directly
> > upstream when most appropriate.
>
> I don't see many responses from developers here, it might be nice if either
> of you can come up with a patch. If the konqi devs don't respond - well,
> maybe it should be considered unmantained and you guys can take over ;-)

The patch would be quite trivial, see below.

Cheers,
Frank

Index: src/konqtabs.cpp
===================================================================
--- src/konqtabs.cpp (revision 1059378)
+++ src/konqtabs.cpp (working copy)
@@ -113,7 +113,7 @@
}

setAutomaticResizeTabs( true );
- setTabReorderingEnabled( true );
+ setMovable( true );
connect( this, SIGNAL( movedTab( int, int ) ),
SLOT( slotMovedTab( int, int ) ) );
connect( this, SIGNAL( mouseMiddleClick() ),

Re: Tab moving in Konqueror

2009-12-06T05:58:18Z

On Wednesday 25 November 2009 14:18:40 Marcus Harrison wrote:

> On Wednesday 25 Nov 2009 10:26:32 Frank Reininghaus wrote:
> > Hi everyone,
> >
> > it seems that tab moving in Konqueror (and any other app that uses the
> > traditional middle-click tab moving) is broken at the moment:
> >
> > https://bugs.kde.org/show_bug.cgi?id=214646
> >
> > Regardless of this bug (which should of course be fixed before 4.4.0)
> > I'm wondering if it makes sense to use Qt's tab moving with the left
> > mouse button in Konqueror instead.
> >
> > The advantage would be that it's probably more intuitive (it's been
> > requested a couple of times on bugs.kde.org, and other browsers like
> > Firefox and Arora also use the left button for moving tabs) and that
> > the moving is animated nicely by QTabBar. Moving tabs with the middle
> > mouse button would still work.
> >
> > The disadvantage would be that drag&drop of the tab url would not work
> > any more, but I would guess that this feature is used a lot less than
> > tab moving?
> >
> > Any thoughts on this? I'm sorry about starting this discussion just
> > before the beta tagging, but I've been a bit busy with other things
> > recently.
> >
> > Best regards,
> > Frank
>
> Though it's probably unsafe to make that assumption without any feedback, I
> also happen to know that the current tab-URL-dragging effect is also
> implemented in the address-bar icon: they both behave, as far as I can
> tell, exactly the same. Additionally, with Qt's tab-bar moving, it is
> possible to detach and re-attach tabs to windows in the context menu and,
> in the future I presume, by simply tearing the tab away. Using Qt's
> tab-bar moving function in Konqueror would allow it to inherit these
> benefits directly, without needing to re-implement them.
>
> Therefore, I consider this a net-gain, not a net-loss action. I would move
> over to Qt's tab-bar implementation and make contributions directly
> upstream when most appropriate.

I don't see many responses from developers here, it might be nice if either of
you can come up with a patch. If the konqi devs don't respond - well, maybe it
should be considered unmantained and you guys can take over ;-)

signature.asc (205 bytes) Download Attachment

Re: konqueror hash history

2009-12-05T15:18:12Z

On Sunday 19 Jul 2009 02:21:15 Vicente Couce Díaz wrote:

> Hi
> 3.5.9
> Try to implement ajax history/bookmarks thru the url hash :
>
> 1- Manualy typing in the address bar blocks further automatic actions
> on the hash (js or links).
> 2- Back button 1st time, changes the url but js doesnt detect the
> change, 2nd time woks as it was the 1st time and so on : back and
> forward stay always 1 step wrong for js and further script
> manipulations are also blocked.
>
> So... a very limitating bug, I would say easy to correct... (I have no
> idea if it is) that makes one of the best browsers useless for many
> purposes.
>
> Didnt tested the 4 series but the 3 ones are very good and come with
> many distros yet.
>

KDE 3 isn't supported any more by KDE. There is currently no effort to
backport patches to the 3.x series.

> Mmm... what do you think? Some work arounds?
>
> ... and what about -khtml-opacity or simply opacity? Also very annoying.
>
> Thanks for one of the best apps Ive ever seen and that I must often
> ignore for such behaviors when I write js.
>
Recent versions of KHTML have support for opacity. That is, KHTML in the
4.X series.

--
Marcus Harrison

Re: Fwd: sidebar history in konqueror

2009-12-05T15:14:59Z

On Sunday 30 Aug 2009 21:14:36 Darío Andrés wrote:

> ---------- Forwarded message ----------
> From: Martin Koller <kollix@...>
> Date: Sat, Aug 29, 2009 at 5:49 AM
> Subject: sidebar history in konqueror
> To: kde-core-devel@...
>
>
> Hi all,
>
> as I could not find anything in the ML archives, can someone please shed
> some light onto the current situation and plans regarding the konqueror
> history functionality ?
>
> - Why was the sidebar history removed (or being declared no longer

wanted)
> ?

I believe this was because of the migration of history to an Akonadi back-
end. The sidebar will be coming back in 4.4, if memory serves.

>
> - What is the status and plan with the new history window ?
>
> References:
> https://bugs.kde.org/show_bug.cgi?id=193966
> https://bugs.kde.org/show_bug.cgi?id=205521
>
> David Faure commented the latter with:
>
> "It's not supposed to show up there anymore
> The new way to see the history is Go / Show History."
>
> I wonder: why ?
>
> --
> Best regards/Schöne Grüße
>
> Martin () ascii ribbon campaign - against html mail
> /\ - against microsoft attachments
>
> Geschenkideen, Accessoires, Seifen, Kulinarisches: www.bibibest.at
>

--
Marcus Harrison

Re: about kde browser !!

2009-12-05T06:31:48Z

On Sunday, 2009-12-06, Jos Poortvliet wrote:

> On Friday 20 November 2009 11:35:07 DR. DARK wrote:
> > good morning !!
> > I like use konqueror as default browser but I want improve it to support
> > hotmail mail-messages and..... like restart tabs and pages after close
> > it ==> like firefox
> >
> > thank you so much
>
> Guys? there has to be a KHTML developer on this list, and if not, a Konqi
> developer?

I am pretty sure there are.
But since we (as in KDE) don't forbid anyone working on improvements, thus not
requiring approval from anyone, it was most likely just seen as an
informational posting, i.e. a "heads up" on what the poster is about to
attempt.

Cheers,
Kevin

--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

signature.asc (197 bytes) Download Attachment

Re: about kde browser !!

2009-12-05T06:19:54Z

On Friday 20 November 2009 11:35:07 DR. DARK wrote:
> good morning !!
> I like use konqueror as default browser but I want improve it to support
> hotmail mail-messages and..... like restart tabs and pages after close it
> ==> like firefox
>
> thank you so much

Guys? there has to be a KHTML developer on this list, and if not, a Konqi
developer?

Even so, mr Dark, you are free to start working on this... IRC might be a
better place to ask for help if you run into trouble, but in FOSS generally
speaking just getting started works best. Don't try to create something
perfect, but come up with a simple patch which improves something, and send it
to the developers. If none respond, contact me, I'll try to help you find the
right person.

signature.asc (205 bytes) Download Attachment

Re: Presentation of a new Khtml project (and Problems with mapToGlobal in LineEditWidget)

2009-12-05T00:31:34Z

On Fri, Dec 4, 2009 at 7:50 PM, Rigo Wenning <rigo@...> wrote:

> Hi all,
>
> I did GPG security for HTML pages in 1999 for the german federal
> constitutional court and it was a hack.
>
> The correct way to do it is to use the xhtml serialization and to use XML
> Signature. This is of interest to me. If we get sufficient support, I can see
> how we can help with it from W3C's perspective.
>
> Best,
>
> Rigo Wenning

Hello Rigo,

I didn't know about XML Signature [1]: it seems to be a good way to
create encrypted/signed documents. XML Signature is the envelope for
encrypted/signed data, but that part I think should be up to the
developer of the website. To continue with the envelope analogy, what
I feel is important here is not the envelope itself nor the data it
contains, but how securely it was generated.

It should have been written in a secure room with no windows whose
sole purpose is writing text with a secure "enigma" machine. The user
of that room knows that the room is secure and thus is confident that
no one but his recipient will be able to read what he is writing. When
he gets out of the room, he handles the written cyphered text to the
mailman and that's it.

The secure room would be the encrypted input element, which the user
knows is secure because of the visual hints of the browser which lets
the user know that it's actually secure. The enigma machine would be
the cypher method you would be using, GPG for example. Both things
would be provided by the user's web browser and thus if the user
trusts his web browser he then trust the secure room and the enigma
machine.

Also, the room is room is secure because it's imposible to access to
the input element value unencrypted or to change it: if you try to
access to it's value it will be encrypted. If you try to modify the
value, it won't work (only the user can do it, and even if it worked
you could only change the encrypted value, not the plain text). The
recipient of the text can only be set once, and the user can see it
clicking in the padlock (probably I should also put in the status bar
on mouse over and when the input/textarea has the focus to make it
perfectly clear).

By the way did you know about WebPKI [2]? It's similar to XML
Signature. It's not a W3C draft but a researcher propossal, but it
provides something closer to what I want: a means to generate signed
html code. So it differs from XML Signature in that it provides a
workflow for generating the signed document: the user is shown a
signature request for a document, then the user can sign it, and then
the signed document is generated and sent, all done by the web browser
too.

The problem I see with WebPKI is that it doesn't provide a way to
generate encrypted data and even if it did, it's not designed to do
so. It's more like a way to ask the user for his signature for
something generated by the server than anything else. So it doesn't
provide a secure room where the user can write anything he wants
without anyone else spying him, but instead it's a secure room in
which he is given a written text which he can securely stamp his
signature in.

So has anything similar to this been done? Certainly. Yourself seem to
have done it ten years ago, but even now there's a Firefox extension
(damn it there's always a Firefox extension doesn't it? :P) called
FireGPG [3] whose aim is very similar to mine. By using right click ->
Encrypt/Decrypt you can encrypt or decrypt any text in a textarea. It
has also support for its own type of plugins for modifying existing
websites for adding better integration of this in them (mainly,
gmail). It has even its own Javascript API for doing all this, and
that part is quite interesting. But it doesn't seem provide a HTML tag
or attribute to mark as "encrypted" a textarea or input element. On
the other hand, FireGPG already exists and works, and it's a good
start point for implementing support for what I'm working on in
Firefox too. I will probably drop an email to them to let them know
about my project =).

Regards,
Eduardo Robles Elvira.
--
[1] http://www.w3.org/TR/xmldsig-core/#sec-PGPData
[2] http://webpki.org
[3] http://getfiregpg.org/

Re: Dolphin folders - question

2009-12-04T18:10:17Z

Right-click anywhere in the Folders panel (the "left bar" you're referring to) and uncheck "Show hidden folders".

For the future, this might not be the best mailing list to ask such question, as this is a development list. User support lists would be kde@... or kde-user@....

Hope that helps

--
Regards,

Juan Carlos Torres
Jucato

Re: Actions extensions in File Manager

2009-12-04T15:19:18Z

On Thursday 19 November 2009 08:02:35 Pierre Wieser wrote:

> Hi guys,
>
> I'm the Nautilus-Actions (N-A) maintainer.
> N-A is an extension to Nautilus, the Gnome file manager,
> which allows (advanced) users to add their own actions
> in the context menu.
>
> This is so very similar to Konqueror Service Menus.
>
> While our actions used to be stored in GConf system, which
> is the general Gnome system for configuration storage, I'm
> currently working on making use of desktop entry files.

I'd like to note that he's also posted this to the xdg mailing list at
freedesktop.org on my recommendation, so there's already been a bit of
discussion. It would be nice to get feedback from the relevant developers
though. I suggested kfm-devel, would kde-core-devel be better?

Regards,
- Michael Pyne

signature.asc (853 bytes) Download Attachment

Re: Presentation of a new Khtml project (and Problems with mapToGlobal in LineEditWidget)

2009-12-04T10:50:59Z

Hi all,

I did GPG security for HTML pages in 1999 for the german federal
constitutional court and it was a hack.

The correct way to do it is to use the xhtml serialization and to use XML
Signature. This is of interest to me. If we get sufficient support, I can see
how we can help with it from W3C's perspective.

Best,

Rigo Wenning

On Friday 20 November 2009 01:51:02 Eduardo Robles Elvira wrote:

> On Thu, Nov 19, 2009 at 6:49 PM, Germain Garand
>
> <germain@...> wrote:
> > Le jeudi 19 novembre 2009, Eduardo Robles Elvira a écrit :
> >> Hello everyone,
> >>
> >> I know I've been silent for a while but that doesn't mean I haven't
> >> been busy working in konqi/khtml. As my final project I'm writing a
> >> patch for khtml for adding support of GPG encryption in forms, so that
> >> something like a GPG web client or a GPG web chat can be done (I'll
> >> prepare a django chat demo too as part of that project). This project
> >> is not intended to be merged in trunk (though I would love to do so
> >> hehe). This is project is just a test of what can be done for
> >> improving the security and functionality of web applications, allowing
> >> end-to-end encryption so that you don't need to trust the server
> >> meanwhile using it, so that the user can reclaim the control of the
> >> data he lost when giving way to web services like Gmail o Gmail chat.
> >> I'm using Libkleo for dealing with GPG stuff.
> >
> > that's a neat idea... nice and simple way of building back a polder of
> > privacy.
> >
> > IIUC, you are using just a couple new attributes for this...
> > do you intend to submit those as a proposal to w3c, once you have worked
> > out things?
>
> I've thought about that, and think I will do it =). It would be great
> if something like this was included in HTML5, and I'm already
> subscribed to w3c html5 public mailing list with that intention.
> However I don't know that much about HTML5 yet and if those attributes
> are compatible with HTML5 forms, although with a quick Google search
> it seems that they could be.
>
> What I'm envisioning is an easy and simple way to handle encryption
> but OTOH it might be too simple for more complex things. Anyway it's
> perfect for my purpose: as it is simple it's easy to implement, and it
> can also be secure. My original idea was a bit more complex, see
> http://edulix.wordpress.com/2009/01/22/web-encryption-framework/ .
>
> > anyway, down to your practical problem:
> >
> > [...]
> >
> >> "drop-down widget". I'm trying to use mapToGlobal(QPoint(0, height()))
> >> inside khtml::LineEditWidget (rendering/render_form.cpp) as a start
> >> point to deal with this, but I'm getting (14, 24392), when as you can
> >> see in [3] it should be more like.. ~ (15, 50). What can be happening
> >> that is making mapToGlobal go crazy?
> >
> > most KHTML widgets are positioned off screen, they are painted at their
> > visible position but they are not really there. This is how we control
> > their stacking order among other rendering objects (cf. z-index CSS
> > property).
> >
> > I'd love to be able to just overload mapToGlobal and friends, but those
> > aren't virtual, so what you need to do instead is some variation of:
> >
> > QPoint dest;
> > KHTMLView* v = m_kwp->rootViewPos(dest);
> >
> > within a KHTMLWidget.
> >
> > |dest| will then contain the widget position, on the canvas of the root
> >
> > KHTMLView |v|.
> >
> > Greetings,
> > Germain
>
> Thanks it worked! And you can even see the result in a screenshot ;-)
> http://img17.imageshack.us/img17/2766/konqi7.png
>
> Regards,
> Eduardo Robles Elvira.
>

--
Open Standards are great. Please use mine! [Peter Brown]

Re: No statusbar in the default konqueror tab ??

2009-12-04T10:47:54Z

On Tuesday 01 December 2009 01:19:04 David Faure wrote:

> On Friday 25 September 2009, Friedrich W. H. Kossebau wrote:
> > Vendredi, le 25 septembre 2009, à 20:36, Dawit A. a écrit:
> > > Whenever I launch Konqueror, does not matter how (command link, menu),
> > > the default tab, regardless what my default start page is set to, does
> > > not show the status bar. However, if I create new tabs, then those new
> > > tabs do show the status bar. Does anyone else experience this issue ?
> >
> > I remember to have seen this ever since KDE 4.0, too. Just checked, and a
> > Konqueror from trunk a week or so ago now always shows a statusbar for me
> > on start. No idea if this is related to the fact that I meanwhile
> > compiled and installed the Konqueror extensions from extragear, but you
> > working on the searchbar plugin should have them also installed I guess,
> > which might rule that out as reason.
>
> I think I fixed this bug recently (see bug 193072). Can you confirm?
>

I still have it. But I wonder when this will arrive downstream (kubuntu)

Rigo
--
Open Standards are great. Please use mine! [Peter Brown]

Re: No statusbar in the default konqueror tab ??

2009-12-01T09:29:08Z

On Monday 30 November 2009 19:19:04 David Faure wrote:

Well I personally cannot confirm this because right after I asked this question
and messed around with my config files, the bug disappeared as mysteriously as
it appeared and I have not encountered it since.

Re: No statusbar in the default konqueror tab ??

2009-11-30T16:19:04Z

On Friday 25 September 2009, Friedrich W. H. Kossebau wrote:

> Vendredi, le 25 septembre 2009, à 20:36, Dawit A. a écrit:
> > Whenever I launch Konqueror, does not matter how (command link, menu),
> > the default tab, regardless what my default start page is set to, does
> > not show the status bar. However, if I create new tabs, then those new
> > tabs do show the status bar. Does anyone else experience this issue ?
>
> I remember to have seen this ever since KDE 4.0, too. Just checked, and a
> Konqueror from trunk a week or so ago now always shows a statusbar for me
> on start. No idea if this is related to the fact that I meanwhile compiled
> and installed the Konqueror extensions from extragear, but you working on
> the searchbar plugin should have them also installed I guess, which might
> rule that out as reason.

I think I fixed this bug recently (see bug 193072). Can you confirm?

--
David Faure, faure@..., http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

Re: Problem with saving the "ServiceName" in Konqueror profile files...

2009-11-30T16:18:01Z

On Friday 30 October 2009, Dawit A. wrote:
> Never mind this question. I see why "ServiceName" is saved in the
profile
> files. It is still confusing specially if you had saved the profile a long
> time ago and forgot about doing so. Anyhow disregard this
question... It
> was user error ;)

Well, I guess we could write out "default" instead of the actual
service name, when it matches the default. This would also solve
some migration issues (e.g. if a part is being removed in kde5, like
konq_iconview was removed in kde4), though not all of them (part is
not default -> still hardcoded, but no other choice there).

--
David Faure, faure@..., http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror
(http://www.konqueror.org).

Re: PATCH: Entering the same url in Konqueror's location bar...

2009-11-30T16:15:45Z

On Thursday 05 November 2009, Dawit A. wrote:
> + // If the current url in the view is the same as the one being
> displayed + // simply do a reload instead of calling openUrl...

I'm against this.
It's a very convenient feature that Enter in the location bar doesn't do
a reload. Think of pages which you can "post" to, and which you can
also just open directly. If you reload, it will (offer to) re-post the data.
If you press Enter, it will load the page without using post data.

Admittedly I don't know what other browsers do, but I really like the
current behavior.

If the bug is duplication in the history list, I think it should be fixed at
the level of the history list (I assume this is about the back/forward
history, not the 500-last-visited-pages history).

--
David Faure, faure@..., http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).

Re: Patch for bug #200795

2009-11-30T04:14:59Z

Il giovedì 26 novembre 2009 18:50:18 Andrea Iacovitti ha scritto:

> Il mercoledì 25 novembre 2009 19:59:08 Germain Garand ha scritto:
> > Le mercredi 18 novembre 2009, Andrea Iacovitti a écrit :
> > > Hi,
> > > revision 1046447 fixes half of bug, there are some cases where
> > > *buttons* does not respect border:none , like in comment #4 and #5:
> > >
> > > http://bugs.kde.org/show_bug.cgi?id=200795#c4
> > > http://bugs.kde.org/show_bug.cgi?id=200795#c5
> > >
> > > (another test case would be:
> > > http://sol.cib.unibo.it/SebinaOpac/Opac?sysb=UBOSB , here some buttons
> > > must not have borders)
> > >
> > > Attached a proposed (tested) patch (same logic as in revision 1046447).
> >
> > Hi Andrea,
>
> Hi Germain
>
> > your patch makes plain sense indeed...
> >
> > but then we'd better factor this code in some more readable
> > method I guess (e.g. shouldDisableNativeBorders() ?)
>
> Yes, i agree. That's the same Allan suggested to do first time i sent the
> patch, unfortunately i haven't had enough time to work on a patch in that
> direction and, sorry, i can't promise i will, but i will try...
>
> > if only because one day some usability option could want to have the
> > native borders still painted in the 'border:none' case (bringing much
> > better discoverability of form widgets ... I thought about adding such an
> > option already when making form widgets more obedient to CSS styling...
> > some people with slight disabilities might prefer a lot to have widgets
> > that stand out, even against the web designer's will.)
> >
> > Maybe also renaming shouldPaintBorder() to shouldPaintCSSBorders() would
> > be clearer, what do you think?
>
> Yes, as a newbie to khtml code i had some difficult to understand the sense
> of shouldPaintBorder, for sure shouldPaintCSSBorders is more appropriate.
> What about to also rename setShouldPaintBackgroundOrBorder() to
> setShouldPaintCSSBackgroundOrBorders(), am i wrong?
>
> Thanks a lot,
> Andrea

Hi all,
please would you verify the attached patch, that:
Introduce shouldDisableNativeBorders() function (at the moment, simply =
(!shouldPaintBackgroundOrBorder() && canHaveBorder()) ).
Rename shouldPaintBorder() to shouldPaintCSSBorders().
Fix condition under which we have to disable native borders on button.
Fix condition under which to show clear button for lineedit (don't show it if
we don't have native borders).

It is worth to mention here that while doing tests I found two new bugs (not
regressed by the patch).
They are related to widged style changes via javascript.
I opened for those bug report #216795

thanks for your attention

Best Rgeards,
Andrea.

[attachment removed]

Howto logout from basic HTTP Authentication

2009-11-29T10:15:10Z

Hi,

I really now, logout from a basic HTTP authentication is not possible (many
people said).
But that is not true. It is possible. I found a solution which will work for
IE as well as Firefox/Iceweasel (http://www.nanodocumet.com).

How the solution work for Mozilla/Firefox?
I have a html page which contains Javascript:

if (agt.indexOf("mozilla") != -1) {
var xmlhttp = createXMLObject();
xmlhttp.open("GET",".logout_mozilla",true,"logout","");
xmlhttp.send("");
xmlhttp.abort();

and a .htaccess which contains:

<Files .logout_mozilla>
AuthType Basic
AuthName "Backup4U"
AuthUserFile /etc/backuppc/htpasswd
Require valid-user
</Files>

The User "logout" is not within my /etc/backuppc/htpasswd. Therefore Mozilla
will get a 401 and the browser will ask for username/password if the page
will be accessed again.

Unfortunately that do not work for Mozilla/Konqueror.
Any hint how to get Konqueror to forgot his credentials?

Thanks in advance
Matthias
--
Don't Panic

Re: Patch for bug #200795

2009-11-26T09:50:18Z

Il mercoledì 25 novembre 2009 19:59:08 Germain Garand ha scritto:

> Le mercredi 18 novembre 2009, Andrea Iacovitti a écrit :
> > Hi,
> > revision 1046447 fixes half of bug, there are some cases where *buttons*
> > does not respect border:none , like in comment #4 and #5:
> >
> > http://bugs.kde.org/show_bug.cgi?id=200795#c4
> > http://bugs.kde.org/show_bug.cgi?id=200795#c5
> >
> > (another test case would be:
> > http://sol.cib.unibo.it/SebinaOpac/Opac?sysb=UBOSB , here some buttons
> > must not have borders)
> >
> > Attached a proposed (tested) patch (same logic as in revision 1046447).
>
> Hi Andrea,

Hi Germain

> your patch makes plain sense indeed...
>
> but then we'd better factor this code in some more readable
> method I guess (e.g. shouldDisableNativeBorders() ?)

Yes, i agree. That's the same Allan suggested to do first time i sent the
patch, unfortunately i haven't had enough time to work on a patch in that
direction and, sorry, i can't promise i will, but i will try...

> if only because one day some usability option could want to have the native
> borders still painted in the 'border:none' case (bringing much better
> discoverability of form widgets ... I thought about adding such an option
> already when making form widgets more obedient to CSS styling... some
> people with slight disabilities might prefer a lot to have widgets that
> stand out, even against the web designer's will.)
>
> Maybe also renaming shouldPaintBorder() to shouldPaintCSSBorders() would be
> clearer, what do you think?

Yes, as a newbie to khtml code i had some difficult to understand the sense of
shouldPaintBorder, for sure shouldPaintCSSBorders is more appropriate.
What about to also rename setShouldPaintBackgroundOrBorder() to
setShouldPaintCSSBackgroundOrBorders(), am i wrong?

Thanks a lot,
Andrea

Re: Actions extensions in File Manager

2009-11-26T03:06:31Z

----- "Michael Pyne" <mpyne@...> a écrit :
>
> But it would be better discussed on the freedesktop.org XDG list I
> think, that
> way other DE developers could chime in on their requirements as well.
>
> Regards,
> - Michael Pyne

Thanks for the advise, Michael.
I'll ping the list.

Regards
Pierre

Re: Actions extensions in File Manager

2009-11-25T15:41:56Z

On Wednesday 25 November 2009 06:16:34 Pierre Wieser wrote:
> Do you think it would be possible, and profitable for our
> users, to be able to share actions between Xfce-KDE-Gnome ?
> (this would probably imply having common path, common
> interpretation of desktop file keys, and so on...)

Sounds like a good idea.

> If this list is not the good one, could you be kind enough
> to forward this message to the ad-hoc list ?

But it would be better discussed on the freedesktop.org XDG list I think, that
way other DE developers could chime in on their requirements as well.

Regards,
- Michael Pyne

signature.asc (853 bytes) Download Attachment

Re: Patch for bug #200795

2009-11-25T10:56:08Z

Le mercredi 18 novembre 2009, Andrea Iacovitti a écrit :

> Hi,
> revision 1046447 fixes half of bug, there are some cases where *buttons*
> does not respect border:none , like in comment #4 and #5:
>
> http://bugs.kde.org/show_bug.cgi?id=200795#c4
> http://bugs.kde.org/show_bug.cgi?id=200795#c5
>
> (another test case would be:
> http://sol.cib.unibo.it/SebinaOpac/Opac?sysb=UBOSB , here some buttons must
> not have borders)
>
> Attached a proposed (tested) patch (same logic as in revision 1046447).

Hi Andrea,
your patch makes plain sense indeed...

but then we'd better factor this code in some more readable
method I guess (e.g. shouldDisableNativeBorders() ?)

if only because one day some usability option could want to have the native
borders still painted in the 'border:none' case (bringing much better
discoverability of form widgets ... I thought about adding such an option
already when making form widgets more obedient to CSS styling... some people
with slight disabilities might prefer a lot to have widgets that stand out,
even against the web designer's will.)

Maybe also renaming shouldPaintBorder() to shouldPaintCSSBorders() would be
clearer, what do you think?

Greetings,
Germain

Re: Tab moving in Konqueror

2009-11-25T05:18:40Z

On Wednesday 25 Nov 2009 10:26:32 Frank Reininghaus wrote:

Though it's probably unsafe to make that assumption without any feedback, I
also happen to know that the current tab-URL-dragging effect is also
implemented in the address-bar icon: they both behave, as far as I can tell,
exactly the same. Additionally, with Qt's tab-bar moving, it is possible to
detach and re-attach tabs to windows in the context menu and, in the future I
presume, by simply tearing the tab away. Using Qt's tab-bar moving function
in Konqueror would allow it to inherit these benefits directly, without needing
to re-implement them.

Therefore, I consider this a net-gain, not a net-loss action. I would move
over to Qt's tab-bar implementation and make contributions directly
upstream when most appropriate.

--
Marcus Harrison

Actions extensions in File Manager

2009-11-25T03:16:34Z

Hi guys,

I'm the Nautilus-Actions (N-A) maintainer.
N-A is an extension to Nautilus, the Gnome file manager,
which allows (advanced) users to add their own actions
in the context menu.

This is so very similar to Konqueror Service Menus and
thunar-actions-plugin.

While N-A actions used to be stored in GConf system, which
is the general Gnome system for configuration storage, I'm
currently working on making use of desktop entry files.

I know Konqueror Service Menus makes use of desktop files,
as Thunar does in Xfce.

Do you think it would be possible, and profitable for our
users, to be able to share actions between Xfce-KDE-Gnome ?
(this would probably imply having common path, common
interpretation of desktop file keys, and so on...)

If this list is not the good one, could you be kind enough
to forward this message to the ad-hoc list ?

Thanks in advance for your opinions
Regards
Pierre

Tab moving in Konqueror

2009-11-25T02:26:32Z

Hi everyone,

it seems that tab moving in Konqueror (and any other app that uses the
traditional middle-click tab moving) is broken at the moment:

https://bugs.kde.org/show_bug.cgi?id=214646

Regardless of this bug (which should of course be fixed before 4.4.0)
I'm wondering if it makes sense to use Qt's tab moving with the left
mouse button in Konqueror instead.

The advantage would be that it's probably more intuitive (it's been
requested a couple of times on bugs.kde.org, and other browsers like
Firefox and Arora also use the left button for moving tabs) and that
the moving is animated nicely by QTabBar. Moving tabs with the middle
mouse button would still work.

The disadvantage would be that drag&drop of the tab url would not work
any more, but I would guess that this feature is used a lot less than
tab moving?

Any thoughts on this? I'm sorry about starting this discussion just
before the beta tagging, but I've been a bit busy with other things
recently.

Best regards,
Frank

The KHTML Vision

2009-11-22T07:18:51Z

Hello mailing list!
I've been wanting to enter development of KHTML/KJS for a long while, and
am working hard to acquire the skills to do that, but I also want to ask:
what is the vision of the KHTML project? What are you (the developers)
aiming towards?

--
Marcus Harrison

Re: File Associations Settings Module outdated?

2009-11-21T14:10:35Z

On Friday, 20. November 2009 17:30:34 Burkhard Lück wrote:
[...]
> > These options should be enabled/disabled dependeing on the selected
> > default component 'filemanager'.
> >
> > Attached a patch with changed wording of all relevant gui strings to make
> > it clear which option is relevant for /konqueror/dolphin.
> >
> > Improvements or objections to commit that?
>
> Meesage freeze is coming soon...

Sorry for the late reply - from my point of view the gui strings are fine,
please commit.

Thanks!
Peter