Re: Fwd: looking for phonon gstreamer maintainer

2013-10-08 Thread Jean-Baptiste Kempf 
On 04 Oct, Daniel Vrátil wrote :
> in Fedora we have a big interest in keeping phonon-gstreamer alive, namely 
> because we can't ship phonon-vlc due to legal issues (you know, US company, 
> software patents and what not...) and our users would not probably be very 

This is a bit untrue, tbh and at the limit of FUD.

libVLC and libVLCcore are not more patent-encumbered than
gstreamer-core.

VLC, phonon-VLC and libVLC are based on modules loaded at runtime, like
gstreamer, QT, DShow and other multimedia frameworks (a contrario from
all-included players like mplayer)
Shipping a version without problematic modules is very doable and has
already been done.

Best regards,

-- 
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device

Re: Fwd: looking for phonon gstreamer maintainer

2013-10-08 Thread Harald Sitter 
On Fri, Oct 4, 2013 at 5:50 PM, Daniel Vrátil  wrote:
> On Wednesday 25 of September 2013 12:35:25 Harald Sitter wrote:
>> -- Forwarded message --
>> From: Harald Sitter 
>> Date: Mon, Sep 23, 2013 at 4:55 PM
>> Subject: looking for phonon gstreamer maintainer
>> To: "For discussion of multimedia (sound/video) issues under KDE"
>> 
>>
>>
>> Ahoy,
>>
>> since everyone who ever was/is/wanted to be Phonon GStreamer
>> maintainer is either busy or has no interest in it, the backend has as
>> of right now no actual maintenance.
>>
>> If anyone wishes to step up and move the backend forward now is the
>> time to do it. I'd like to note that this is not a one-man job though
>> and I am going to continue to be supporting developer.
>>
>> In the unfortunate case that no one is willing enough we will have to
>> look at the possibility of moving the backend out of the support
>> scope, leaving Phonon VLC as the only actively supported backend on
>> all platforms.
>>
>> As immediate result I will likely have to demote the backend's initial
>> preference for the upcoming 4.7.0 release below Phonon VLC's.
>
> Hi,
>
> in Fedora we have a big interest in keeping phonon-gstreamer alive, namely
> because we can't ship phonon-vlc due to legal issues (you know, US company,
> software patents and what not...) and our users would not probably be very
> happy if we had no phonon working backend in Fedora KDE.
>
> So far we are happy with gstreamer-0.10, but we realize that sooner or later
> we will have to start looking into supporting gstreamer-1.0. Even if we are
> able to keep phonon with gstreamer-0.10 alive by patching the hell out of it
> in downstream, at some point we will be forced to drop it, and then we would
> have nothing to switch to.
>
> So I'm willing to help keeping phonon-gstreamer alive in upstream (I'm not
> saying I'll be able to fix all the bugs) and slowly look into the gst-1.0 
> port.
> I'm not able to fully maintain yet another project (I already have more than
> enough :-)), but as said above, I can contribute to keep it alive and push it
> over the hill to gstreamer-1.0 (come on, how hard can it be? ;-))

That's great! Some progress is certainly better than no progress :D
If you could hop on #kde-multimedia we can coordinate development etc.

> Luckily for me, we have a GStreamer guy in the office, so I can get some help
> from him if necessary :)

Sebastian Dröge from GStreamer also offered to help, so we definitely
have some GStreamer backing. Yay.

HS

Re: Fwd: looking for phonon gstreamer maintainer

2013-10-08 Thread Harald Sitter 
On Mon, Oct 7, 2013 at 2:36 PM, Jean-Baptiste Kempf  wrote:
> On 04 Oct, Daniel Vrátil wrote :
>> in Fedora we have a big interest in keeping phonon-gstreamer alive, namely
>> because we can't ship phonon-vlc due to legal issues (you know, US company,
>> software patents and what not...) and our users would not probably be very
>
> This is a bit untrue, tbh and at the limit of FUD.
>
> libVLC and libVLCcore are not more patent-encumbered than
> gstreamer-core.
>
> VLC, phonon-VLC and libVLC are based on modules loaded at runtime, like
> gstreamer, QT, DShow and other multimedia frameworks (a contrario from
> all-included players like mplayer)
> Shipping a version without problematic modules is very doable and has
> already been done.

FWIW rdieter and j-b were able to clear up the confusion on IRC and
apparently there now are plans to get vlc-without-patent-plugins into
Fedora \o/

For anyone who is interested...
libvlc* use $LIB/vlc/plugins/*/*.so to actually get
demuxers/decoders/etc. a reasonable amount of containers and codecs
(certainly some of the most important ones from a free software
distribution's POV) are supported by vlc native implementations
without usage of libav/ffmpeg/whatever. Any of the plugins can be
dropped, which will naturally reduce feature or format support, but
not impair libvlc's functionality at large. So a simple ldd check will
tell you which plugins to exclude to get an ffmpeg-free package.

^ This is also how one can get smaller monolithic phonon-vlc binary
packages BTW. Tomahawk for example strips a lot of the unused vlc
plugins from their windows and osx binaries to reduce the size.

HS

Review Request 113175: Always use an external viewer application to view files

2013-10-08 Thread Sven Brauch 

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113175/
---

Review request for KDE Base Apps.


Repository: ark


Description
---

This patch makes ark always use an external viewer application instead of using 
the clunky internal preview thing. The internal viewer would just embed a plain 
kpart into a window, but without providing any of the XMLGUI or whatever from 
that part. Thus, when you for example clicked a PDF, you couldn't print it. The 
advantages of the internal viewer are imo overall quite questionable, and are 
far outweighted by its disadvantages.

Plus, it removes code ;)


Diffs
-

  part/arkviewer.cpp 053cd1c0502d3bb88895dc8d3653eaea9e6c3c83 

Diff: http://git.reviewboard.kde.org/r/113175/diff/


Testing
---

Clicking files opens them in the default application, as it should.


Thanks,

Sven Brauch

KF5 Update Meeting Minutes 2013-w41

2013-10-08 Thread Kevin Ottens 
Hello everyone,

This is the minutes of the Week 41 KF5 meeting. As usual it has been held on 
#kde-devel at 4pm Paris time.

Were present: afiestas, agateau, apol, jpwhiting, mck182, sebas, shadeslayer, 
teo, vHanda, wojtask9 and myself.

Announcement:
 * If you didn't read my email on stop the line events yet go read it now;
 * Don't ignore build.kde.org, fixing the build should always have top 
priority (kdelibs-frameworks and plasma-framework should always be green);
 * Try to not break the build in the first place, take measures like clean 
build before pushes;
 * Seriously...

Topics discussed:
 * afiestas finished moving some frameworks to tier 3;
 * he's working on kded at the moment;

 * agateau has finished the kf5 cmake template;
 * kconfigwidgets moved to tier 3;
 * fixed kcookiejartest (you get a cookie then);
 * working on improvements for KMessageBox code;

 * apol is splitting kinit;
 * he's also making sure all modules find their packages properly;
 * he'll also soon prepare kjsembed;

 * jpwhiting is working on knewstuff;

 * mck182 moved kprintutils and kdesu;
 * he's looking at ktimezoned;

 * sebas is removing kde4support uses in plasma-framework;
 * he's also porting away from kde4support in kde-workspace;
 * regularly build fixing;
 * systemtray work is in progress;
 * libdbusmenu-qt cmake work too;

 * shadeslayer is working on QErrorMessage;
 * he's also working on KDialogJobUiDelegate queueing;
 * he's also trying to remove KTextEditSpellInterface;

 * teo is waiting on dfaure's kfile changes to wrap up KEncodingFileDialog 
refactoring;
 * in the meantime he's porting kscmserver

 * vHanda is fixing up kross to get it in the frameworks regular form;
 * he's also removing the nepomuk dependencies from kde4support;

 * wojtask9 is still working on the dependency graph generator, should publish 
tomorrow;

 * ervin is just trying to have a green build.kde.org again... still some 
tests aren't run with "make test" for some reason...

If you got questions, feel free to ask.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

Sponsored by KDAB to work on KDE Frameworks
KDAB - proud supporter of KDE, http://www.kdab.com



signature.asc
Description: This is a digitally signed message part.

Re: Review Request 113175: Always use an external viewer application to view files

2013-10-08 Thread Sven Brauch 

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113175/
---

(Updated Oct. 8, 2013, 3:11 p.m.)


Review request for KDE Base Apps and Raphael Kubo da Costa.


Repository: ark


Description
---

This patch makes ark always use an external viewer application instead of using 
the clunky internal preview thing. The internal viewer would just embed a plain 
kpart into a window, but without providing any of the XMLGUI or whatever from 
that part. Thus, when you for example clicked a PDF, you couldn't print it. The 
advantages of the internal viewer are imo overall quite questionable, and are 
far outweighted by its disadvantages.

Plus, it removes code ;)


Diffs
-

  part/arkviewer.cpp 053cd1c0502d3bb88895dc8d3653eaea9e6c3c83 

Diff: http://git.reviewboard.kde.org/r/113175/diff/


Testing
---

Clicking files opens them in the default application, as it should.


Thanks,

Sven Brauch

Re: Review Request 113175: Always use an external viewer application to view files

2013-10-08 Thread Sven Brauch 

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113175/
---

(Updated Oct. 8, 2013, 3:13 p.m.)


Review request for KDE Base Apps.


Repository: ark


Description
---

This patch makes ark always use an external viewer application instead of using 
the clunky internal preview thing. The internal viewer would just embed a plain 
kpart into a window, but without providing any of the XMLGUI or whatever from 
that part. Thus, when you for example clicked a PDF, you couldn't print it. The 
advantages of the internal viewer are imo overall quite questionable, and are 
far outweighted by its disadvantages.

Plus, it removes code ;)


Diffs
-

  part/arkviewer.cpp 053cd1c0502d3bb88895dc8d3653eaea9e6c3c83 

Diff: http://git.reviewboard.kde.org/r/113175/diff/


Testing
---

Clicking files opens them in the default application, as it should.


Thanks,

Sven Brauch

Re: Review Request 113175: Always use an external viewer application to view files

2013-10-08 Thread Kai Uwe Broulik 

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113175/#review41398
---


You should remove the functions from the headerfile as well.

- Kai Uwe Broulik


On Oct. 8, 2013, 3:13 p.m., Sven Brauch wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113175/
> ---
> 
> (Updated Oct. 8, 2013, 3:13 p.m.)
> 
> 
> Review request for KDE Base Apps.
> 
> 
> Repository: ark
> 
> 
> Description
> ---
> 
> This patch makes ark always use an external viewer application instead of 
> using the clunky internal preview thing. The internal viewer would just embed 
> a plain kpart into a window, but without providing any of the XMLGUI or 
> whatever from that part. Thus, when you for example clicked a PDF, you 
> couldn't print it. The advantages of the internal viewer are imo overall 
> quite questionable, and are far outweighted by its disadvantages.
> 
> Plus, it removes code ;)
> 
> 
> Diffs
> -
> 
>   part/arkviewer.cpp 053cd1c0502d3bb88895dc8d3653eaea9e6c3c83 
> 
> Diff: http://git.reviewboard.kde.org/r/113175/diff/
> 
> 
> Testing
> ---
> 
> Clicking files opens them in the default application, as it should.
> 
> 
> Thanks,
> 
> Sven Brauch
> 
>

Re: Review Request 113175: Always use an external viewer application to view files

2013-10-08 Thread Sven Brauch 

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113175/
---

(Updated Oct. 8, 2013, 3:17 p.m.)


Review request for KDE Base Apps.


Repository: ark


Description
---

This patch makes ark always use an external viewer application instead of using 
the clunky internal preview thing. The internal viewer would just embed a plain 
kpart into a window, but without providing any of the XMLGUI or whatever from 
that part. Thus, when you for example clicked a PDF, you couldn't print it. The 
advantages of the internal viewer are imo overall quite questionable, and are 
far outweighted by its disadvantages.

Plus, it removes code ;)


Diffs (updated)
-

  part/arkviewer.h bb41472eaec985e2e1b3d9c2f7c257c949316bf4 
  part/arkviewer.cpp 053cd1c0502d3bb88895dc8d3653eaea9e6c3c83 

Diff: http://git.reviewboard.kde.org/r/113175/diff/


Testing
---

Clicking files opens them in the default application, as it should.


Thanks,

Sven Brauch

Re: Review Request 113175: Always use an external viewer application to view files

2013-10-08 Thread Sven Brauch 

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113175/
---

(Updated Oct. 8, 2013, 3:23 p.m.)


Review request for KDE Base Apps.


Changes
---

No, in fact we should do this, of course. The class is worthless now.


Repository: ark


Description
---

This patch makes ark always use an external viewer application instead of using 
the clunky internal preview thing. The internal viewer would just embed a plain 
kpart into a window, but without providing any of the XMLGUI or whatever from 
that part. Thus, when you for example clicked a PDF, you couldn't print it. The 
advantages of the internal viewer are imo overall quite questionable, and are 
far outweighted by its disadvantages.

Plus, it removes code ;)


Diffs (updated)
-

  part/CMakeLists.txt 9e384438b60322f1d51d31e40c556b2912970ceb 
  part/arkviewer.h bb41472eaec985e2e1b3d9c2f7c257c949316bf4 
  part/arkviewer.cpp 053cd1c0502d3bb88895dc8d3653eaea9e6c3c83 
  part/part.cpp b4ebcd27c462d2b8037b5ea40c56969eda71bdcb 

Diff: http://git.reviewboard.kde.org/r/113175/diff/


Testing
---

Clicking files opens them in the default application, as it should.


Thanks,

Sven Brauch

Re: Review Request 113175: Always use an external viewer application to view files

2013-10-08 Thread Jonathan Marten 

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113175/#review41400
---


I'm not totally happy with this change.  Yes, the internal viewer is limited in 
functionality, but it has advantages:  (1) it is fast to open and can be closed 
again with a single keystroke;  (2) it remembers its size and can be resized 
without affecting the default window size of, say, KWrite or whichever external 
application is used;  (3) it can be forced to display an archive component of 
any type as plain text.

There's nothing wrong with having the facility to open an archive component in 
its default application (or any other application), but it should be an option. 
 Either a configuration setting (Use internal viewer - Use external 
application), or a context menu with options View (in the internal viewer), 
Open (in the default application) or Open With... (any other application).

- Jonathan Marten


On Oct. 8, 2013, 3:23 p.m., Sven Brauch wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113175/
> ---
> 
> (Updated Oct. 8, 2013, 3:23 p.m.)
> 
> 
> Review request for KDE Base Apps.
> 
> 
> Repository: ark
> 
> 
> Description
> ---
> 
> This patch makes ark always use an external viewer application instead of 
> using the clunky internal preview thing. The internal viewer would just embed 
> a plain kpart into a window, but without providing any of the XMLGUI or 
> whatever from that part. Thus, when you for example clicked a PDF, you 
> couldn't print it. The advantages of the internal viewer are imo overall 
> quite questionable, and are far outweighted by its disadvantages.
> 
> Plus, it removes code ;)
> 
> 
> Diffs
> -
> 
>   part/CMakeLists.txt 9e384438b60322f1d51d31e40c556b2912970ceb 
>   part/arkviewer.h bb41472eaec985e2e1b3d9c2f7c257c949316bf4 
>   part/arkviewer.cpp 053cd1c0502d3bb88895dc8d3653eaea9e6c3c83 
>   part/part.cpp b4ebcd27c462d2b8037b5ea40c56969eda71bdcb 
> 
> Diff: http://git.reviewboard.kde.org/r/113175/diff/
> 
> 
> Testing
> ---
> 
> Clicking files opens them in the default application, as it should.
> 
> 
> Thanks,
> 
> Sven Brauch
> 
>

Re: Review Request 113175: Always use an external viewer application to view files

2013-10-08 Thread Sven Brauch 


> On Oct. 8, 2013, 4:47 p.m., Jonathan Marten wrote:
> > I'm not totally happy with this change.  Yes, the internal viewer is 
> > limited in functionality, but it has advantages:  (1) it is fast to open 
> > and can be closed again with a single keystroke;  (2) it remembers its size 
> > and can be resized without affecting the default window size of, say, 
> > KWrite or whichever external application is used;  (3) it can be forced to 
> > display an archive component of any type as plain text.
> > 
> > There's nothing wrong with having the facility to open an archive component 
> > in its default application (or any other application), but it should be an 
> > option.  Either a configuration setting (Use internal viewer - Use external 
> > application), or a context menu with options View (in the internal viewer), 
> > Open (in the default application) or Open With... (any other application).

I guessed some people would not be happy with it, but it was worth a try ;)

How about a context menu action? Or, since the context menu is currently empty, 
just opening the external viewer on right-click?


- Sven


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113175/#review41400
---


On Oct. 8, 2013, 3:23 p.m., Sven Brauch wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113175/
> ---
> 
> (Updated Oct. 8, 2013, 3:23 p.m.)
> 
> 
> Review request for KDE Base Apps.
> 
> 
> Repository: ark
> 
> 
> Description
> ---
> 
> This patch makes ark always use an external viewer application instead of 
> using the clunky internal preview thing. The internal viewer would just embed 
> a plain kpart into a window, but without providing any of the XMLGUI or 
> whatever from that part. Thus, when you for example clicked a PDF, you 
> couldn't print it. The advantages of the internal viewer are imo overall 
> quite questionable, and are far outweighted by its disadvantages.
> 
> Plus, it removes code ;)
> 
> 
> Diffs
> -
> 
>   part/CMakeLists.txt 9e384438b60322f1d51d31e40c556b2912970ceb 
>   part/arkviewer.h bb41472eaec985e2e1b3d9c2f7c257c949316bf4 
>   part/arkviewer.cpp 053cd1c0502d3bb88895dc8d3653eaea9e6c3c83 
>   part/part.cpp b4ebcd27c462d2b8037b5ea40c56969eda71bdcb 
> 
> Diff: http://git.reviewboard.kde.org/r/113175/diff/
> 
> 
> Testing
> ---
> 
> Clicking files opens them in the default application, as it should.
> 
> 
> Thanks,
> 
> Sven Brauch
> 
>

Re: Review Request 113175: Always use an external viewer application to view files

2013-10-08 Thread Jonathan Marten 


> On Oct. 8, 2013, 4:47 p.m., Jonathan Marten wrote:
> > I'm not totally happy with this change.  Yes, the internal viewer is 
> > limited in functionality, but it has advantages:  (1) it is fast to open 
> > and can be closed again with a single keystroke;  (2) it remembers its size 
> > and can be resized without affecting the default window size of, say, 
> > KWrite or whichever external application is used;  (3) it can be forced to 
> > display an archive component of any type as plain text.
> > 
> > There's nothing wrong with having the facility to open an archive component 
> > in its default application (or any other application), but it should be an 
> > option.  Either a configuration setting (Use internal viewer - Use external 
> > application), or a context menu with options View (in the internal viewer), 
> > Open (in the default application) or Open With... (any other application).
> 
> Sven Brauch wrote:
> I guessed some people would not be happy with it, but it was worth a try 
> ;)
> 
> How about a context menu action? Or, since the context menu is currently 
> empty, just opening the external viewer on right-click?

Not sure that changing the function of the right-click would be approved of 
(but then, I'm not the ark maintainer or authority, just an intensive user of 
it).  Maybe the middle button?

There has been some discussion about adding a context menu to Ark before now - 
e.g. bug #166203.


- Jonathan


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113175/#review41400
---


On Oct. 8, 2013, 3:23 p.m., Sven Brauch wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113175/
> ---
> 
> (Updated Oct. 8, 2013, 3:23 p.m.)
> 
> 
> Review request for KDE Base Apps.
> 
> 
> Repository: ark
> 
> 
> Description
> ---
> 
> This patch makes ark always use an external viewer application instead of 
> using the clunky internal preview thing. The internal viewer would just embed 
> a plain kpart into a window, but without providing any of the XMLGUI or 
> whatever from that part. Thus, when you for example clicked a PDF, you 
> couldn't print it. The advantages of the internal viewer are imo overall 
> quite questionable, and are far outweighted by its disadvantages.
> 
> Plus, it removes code ;)
> 
> 
> Diffs
> -
> 
>   part/CMakeLists.txt 9e384438b60322f1d51d31e40c556b2912970ceb 
>   part/arkviewer.h bb41472eaec985e2e1b3d9c2f7c257c949316bf4 
>   part/arkviewer.cpp 053cd1c0502d3bb88895dc8d3653eaea9e6c3c83 
>   part/part.cpp b4ebcd27c462d2b8037b5ea40c56969eda71bdcb 
> 
> Diff: http://git.reviewboard.kde.org/r/113175/diff/
> 
> 
> Testing
> ---
> 
> Clicking files opens them in the default application, as it should.
> 
> 
> Thanks,
> 
> Sven Brauch
> 
>

Re: Review Request 113175: Always use an external viewer application to view files

2013-10-08 Thread Sebastian Kügler 


> On Oct. 8, 2013, 4:47 p.m., Jonathan Marten wrote:
> > I'm not totally happy with this change.  Yes, the internal viewer is 
> > limited in functionality, but it has advantages:  (1) it is fast to open 
> > and can be closed again with a single keystroke;  (2) it remembers its size 
> > and can be resized without affecting the default window size of, say, 
> > KWrite or whichever external application is used;  (3) it can be forced to 
> > display an archive component of any type as plain text.
> > 
> > There's nothing wrong with having the facility to open an archive component 
> > in its default application (or any other application), but it should be an 
> > option.  Either a configuration setting (Use internal viewer - Use external 
> > application), or a context menu with options View (in the internal viewer), 
> > Open (in the default application) or Open With... (any other application).
> 
> Sven Brauch wrote:
> I guessed some people would not be happy with it, but it was worth a try 
> ;)
> 
> How about a context menu action? Or, since the context menu is currently 
> empty, just opening the external viewer on right-click?
> 
> Jonathan Marten wrote:
> Not sure that changing the function of the right-click would be approved 
> of (but then, I'm not the ark maintainer or authority, just an intensive user 
> of it).  Maybe the middle button?
> 
> There has been some discussion about adding a context menu to Ark before 
> now - e.g. bug #166203.
>

Honestly, to most people the internal viewer just looks broken, like an 
incomplete stepchild of the real viewer application.

Can we please at least make the default to open the application, not the 
crippled viewer?


- Sebastian


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113175/#review41400
---


On Oct. 8, 2013, 3:23 p.m., Sven Brauch wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113175/
> ---
> 
> (Updated Oct. 8, 2013, 3:23 p.m.)
> 
> 
> Review request for KDE Base Apps.
> 
> 
> Repository: ark
> 
> 
> Description
> ---
> 
> This patch makes ark always use an external viewer application instead of 
> using the clunky internal preview thing. The internal viewer would just embed 
> a plain kpart into a window, but without providing any of the XMLGUI or 
> whatever from that part. Thus, when you for example clicked a PDF, you 
> couldn't print it. The advantages of the internal viewer are imo overall 
> quite questionable, and are far outweighted by its disadvantages.
> 
> Plus, it removes code ;)
> 
> 
> Diffs
> -
> 
>   part/CMakeLists.txt 9e384438b60322f1d51d31e40c556b2912970ceb 
>   part/arkviewer.h bb41472eaec985e2e1b3d9c2f7c257c949316bf4 
>   part/arkviewer.cpp 053cd1c0502d3bb88895dc8d3653eaea9e6c3c83 
>   part/part.cpp b4ebcd27c462d2b8037b5ea40c56969eda71bdcb 
> 
> Diff: http://git.reviewboard.kde.org/r/113175/diff/
> 
> 
> Testing
> ---
> 
> Clicking files opens them in the default application, as it should.
> 
> 
> Thanks,
> 
> Sven Brauch
> 
>

Re: Review Request 113175: Always use an external viewer application to view files

2013-10-08 Thread Sven Brauch 


> On Oct. 8, 2013, 4:47 p.m., Jonathan Marten wrote:
> > I'm not totally happy with this change.  Yes, the internal viewer is 
> > limited in functionality, but it has advantages:  (1) it is fast to open 
> > and can be closed again with a single keystroke;  (2) it remembers its size 
> > and can be resized without affecting the default window size of, say, 
> > KWrite or whichever external application is used;  (3) it can be forced to 
> > display an archive component of any type as plain text.
> > 
> > There's nothing wrong with having the facility to open an archive component 
> > in its default application (or any other application), but it should be an 
> > option.  Either a configuration setting (Use internal viewer - Use external 
> > application), or a context menu with options View (in the internal viewer), 
> > Open (in the default application) or Open With... (any other application).
> 
> Sven Brauch wrote:
> I guessed some people would not be happy with it, but it was worth a try 
> ;)
> 
> How about a context menu action? Or, since the context menu is currently 
> empty, just opening the external viewer on right-click?
> 
> Jonathan Marten wrote:
> Not sure that changing the function of the right-click would be approved 
> of (but then, I'm not the ark maintainer or authority, just an intensive user 
> of it).  Maybe the middle button?
> 
> There has been some discussion about adding a context menu to Ark before 
> now - e.g. bug #166203.
>
> 
> Sebastian Kügler wrote:
> Honestly, to most people the internal viewer just looks broken, like an 
> incomplete stepchild of the real viewer application.
> 
> Can we please at least make the default to open the application, not the 
> crippled viewer?

I feel like Sebastian does and I have watched people use Ark before which 
obviously felt the same (i.e. which were confused because the PDF viewer was 
missing all the buttons). I do see the point of the viewer in some corner 
cases, but in almost all cases I don't want it.

Maybe we could do this: The side panel is currently quite useless (huge amount 
of space occupied + little information in there). We could embed the viewer 
there, and change the action on click to select the file and display it there. 
That would serve the (I guess?) common use case, which is looking through 
several images and deciding which one you want to extract even better than the 
current solution. Then there could be a button below the viewer widget to open 
the file in the actual application.
I'm not sure this is a good idea, what do you think?


- Sven


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113175/#review41400
---


On Oct. 8, 2013, 3:23 p.m., Sven Brauch wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113175/
> ---
> 
> (Updated Oct. 8, 2013, 3:23 p.m.)
> 
> 
> Review request for KDE Base Apps.
> 
> 
> Repository: ark
> 
> 
> Description
> ---
> 
> This patch makes ark always use an external viewer application instead of 
> using the clunky internal preview thing. The internal viewer would just embed 
> a plain kpart into a window, but without providing any of the XMLGUI or 
> whatever from that part. Thus, when you for example clicked a PDF, you 
> couldn't print it. The advantages of the internal viewer are imo overall 
> quite questionable, and are far outweighted by its disadvantages.
> 
> Plus, it removes code ;)
> 
> 
> Diffs
> -
> 
>   part/CMakeLists.txt 9e384438b60322f1d51d31e40c556b2912970ceb 
>   part/arkviewer.h bb41472eaec985e2e1b3d9c2f7c257c949316bf4 
>   part/arkviewer.cpp 053cd1c0502d3bb88895dc8d3653eaea9e6c3c83 
>   part/part.cpp b4ebcd27c462d2b8037b5ea40c56969eda71bdcb 
> 
> Diff: http://git.reviewboard.kde.org/r/113175/diff/
> 
> 
> Testing
> ---
> 
> Clicking files opens them in the default application, as it should.
> 
> 
> Thanks,
> 
> Sven Brauch
> 
>

Re: Review Request 112880: Added KColorSchemeToken class.

2013-10-08 Thread Denis Kuplyakov 


> On Sept. 29, 2013, 4:24 p.m., David Faure wrote:
> > The name "token" surprises me a bit. Is this a usual naming scheme for 
> > accessing C++ classes from QML?
> > Otherwise I would think the QML code would want to just write KColorScheme.
> > 
> > Maybe the registration could be done in a static method, rather than 
> > letting the apps do it on their own?
> > 
> > The "NEED TO FIX" in the description can be removed, right?
> > 
> > About the branch: I see that the request is correctly for 5.0 - which means 
> > less merging trouble, so it sounds good to me :)
> >
> 
> Denis Kuplyakov wrote:
> We can register it as KColorScheme for QML but in C++ it can't have such 
> name as KColorScheme already exists. Token was first that came to my mind, 
> maybe we can name it KColorSchemeQMLWrapper or smth like this?
> 
> As Kevin suggested maybe it should be placed at some other place, not 
> kdeui? I don't know all structure of kdelibs so I'm hope you will help me.
> 
> Also how can I implement static registration, or what class I can 
> investigate as example?
> 
> I have removed NEED TO FIX...

What is kdelibs/experimental/libkdeclarative ?? Maybe KColorSchemeToken should 
be put there. Does anybody know something about this?


- Denis


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112880/#review41002
---


On Oct. 6, 2013, 7:24 p.m., Denis Kuplyakov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112880/
> ---
> 
> (Updated Oct. 6, 2013, 7:24 p.m.)
> 
> 
> Review request for KDE Frameworks and kdelibs.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> It is wrapper to access KColorScheme's methods from QML code.
> Also added Q_GADGET to KColorScheme to enable Q_ENUMS using, to make them 
> accessible from QML code.
> 
> As it will be accepted, QML-clone of KgPopupItem will be posted for review to 
> libkdegames, as it uses it to access KDE's color theme.
> 
> More info:
> * search for "KDE theme colors API for QML" thread at kdelibs and kdegames 
> mailinglists *
> 
> 
> Diffs
> -
> 
>   kdeui/CMakeLists.txt b439e04 
>   includes/CMakeLists.txt cdf0143 
>   includes/KColorSchemeToken PRE-CREATION 
>   kdeui/colors/kcolorscheme.h 17570fd 
>   kdeui/colors/kcolorscheme.cpp a6650ac 
>   kdeui/colors/kcolorschemetoken.h PRE-CREATION 
>   kdeui/colors/kcolorschemetoken.cpp PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/112880/diff/
> 
> 
> Testing
> ---
> 
> I've tested it with KReversi's deniskup/gsoc2013/newdesign branch.
> 
> 
> Thanks,
> 
> Denis Kuplyakov
> 
>

Re: Review Request 113175: Always use an external viewer application to view files

2013-10-08 Thread Sven Brauch 


> On Oct. 8, 2013, 4:47 p.m., Jonathan Marten wrote:
> > I'm not totally happy with this change.  Yes, the internal viewer is 
> > limited in functionality, but it has advantages:  (1) it is fast to open 
> > and can be closed again with a single keystroke;  (2) it remembers its size 
> > and can be resized without affecting the default window size of, say, 
> > KWrite or whichever external application is used;  (3) it can be forced to 
> > display an archive component of any type as plain text.
> > 
> > There's nothing wrong with having the facility to open an archive component 
> > in its default application (or any other application), but it should be an 
> > option.  Either a configuration setting (Use internal viewer - Use external 
> > application), or a context menu with options View (in the internal viewer), 
> > Open (in the default application) or Open With... (any other application).
> 
> Sven Brauch wrote:
> I guessed some people would not be happy with it, but it was worth a try 
> ;)
> 
> How about a context menu action? Or, since the context menu is currently 
> empty, just opening the external viewer on right-click?
> 
> Jonathan Marten wrote:
> Not sure that changing the function of the right-click would be approved 
> of (but then, I'm not the ark maintainer or authority, just an intensive user 
> of it).  Maybe the middle button?
> 
> There has been some discussion about adding a context menu to Ark before 
> now - e.g. bug #166203.
>
> 
> Sebastian Kügler wrote:
> Honestly, to most people the internal viewer just looks broken, like an 
> incomplete stepchild of the real viewer application.
> 
> Can we please at least make the default to open the application, not the 
> crippled viewer?
> 
> Sven Brauch wrote:
> I feel like Sebastian does and I have watched people use Ark before which 
> obviously felt the same (i.e. which were confused because the PDF viewer was 
> missing all the buttons). I do see the point of the viewer in some corner 
> cases, but in almost all cases I don't want it.
> 
> Maybe we could do this: The side panel is currently quite useless (huge 
> amount of space occupied + little information in there). We could embed the 
> viewer there, and change the action on click to select the file and display 
> it there. That would serve the (I guess?) common use case, which is looking 
> through several images and deciding which one you want to extract even better 
> than the current solution. Then there could be a button below the viewer 
> widget to open the file in the actual application.
> I'm not sure this is a good idea, what do you think?

Ok, I see the problem with that approach -- it requires extracting files on 
selecting them, which is of course not optimal.


- Sven


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113175/#review41400
---


On Oct. 8, 2013, 3:23 p.m., Sven Brauch wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113175/
> ---
> 
> (Updated Oct. 8, 2013, 3:23 p.m.)
> 
> 
> Review request for KDE Base Apps.
> 
> 
> Repository: ark
> 
> 
> Description
> ---
> 
> This patch makes ark always use an external viewer application instead of 
> using the clunky internal preview thing. The internal viewer would just embed 
> a plain kpart into a window, but without providing any of the XMLGUI or 
> whatever from that part. Thus, when you for example clicked a PDF, you 
> couldn't print it. The advantages of the internal viewer are imo overall 
> quite questionable, and are far outweighted by its disadvantages.
> 
> Plus, it removes code ;)
> 
> 
> Diffs
> -
> 
>   part/CMakeLists.txt 9e384438b60322f1d51d31e40c556b2912970ceb 
>   part/arkviewer.h bb41472eaec985e2e1b3d9c2f7c257c949316bf4 
>   part/arkviewer.cpp 053cd1c0502d3bb88895dc8d3653eaea9e6c3c83 
>   part/part.cpp b4ebcd27c462d2b8037b5ea40c56969eda71bdcb 
> 
> Diff: http://git.reviewboard.kde.org/r/113175/diff/
> 
> 
> Testing
> ---
> 
> Clicking files opens them in the default application, as it should.
> 
> 
> Thanks,
> 
> Sven Brauch
> 
>

Re: Review Request 112880: Added KColorSchemeToken class.

2013-10-08 Thread Sebastian Kügler 


> On Oct. 1, 2013, 2:47 p.m., Sebastian Kügler wrote:
> > kdeui/colors/kcolorschemetoken.h, line 70
> > 
> >
> > using int here loses the type-safety. Why no use the corresponding 
> > enums? It would also make the code more readable.
> > 
> > (Same issue for all the other methods.)
> 
> Denis Kuplyakov wrote:
> I have tried it, but have such errors:
> Error: Unknown method parameter type: QPalette::ColorGroup
> 
> See this: http://qt-project.org/forums/viewthread/10308/ . It seems that 
> the int is only way to make it works correct.

Have you tried registering that enum using qmlRegisterType?


- Sebastian


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/112880/#review41068
---


On Oct. 6, 2013, 7:24 p.m., Denis Kuplyakov wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/112880/
> ---
> 
> (Updated Oct. 6, 2013, 7:24 p.m.)
> 
> 
> Review request for KDE Frameworks and kdelibs.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> It is wrapper to access KColorScheme's methods from QML code.
> Also added Q_GADGET to KColorScheme to enable Q_ENUMS using, to make them 
> accessible from QML code.
> 
> As it will be accepted, QML-clone of KgPopupItem will be posted for review to 
> libkdegames, as it uses it to access KDE's color theme.
> 
> More info:
> * search for "KDE theme colors API for QML" thread at kdelibs and kdegames 
> mailinglists *
> 
> 
> Diffs
> -
> 
>   kdeui/CMakeLists.txt b439e04 
>   includes/CMakeLists.txt cdf0143 
>   includes/KColorSchemeToken PRE-CREATION 
>   kdeui/colors/kcolorscheme.h 17570fd 
>   kdeui/colors/kcolorscheme.cpp a6650ac 
>   kdeui/colors/kcolorschemetoken.h PRE-CREATION 
>   kdeui/colors/kcolorschemetoken.cpp PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/112880/diff/
> 
> 
> Testing
> ---
> 
> I've tested it with KReversi's deniskup/gsoc2013/newdesign branch.
> 
> 
> Thanks,
> 
> Denis Kuplyakov
> 
>