Re: Review Request 114933: KF5 Port of kdeui/kmessagewidgetdemo

[Sune Vuorela]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/114933/#review47428
---



kdeui/kmessagewidgetdemo/CMakeLists.txt


Would it be hard to get rid of XmlGui here? I don't see what it really buy 
us for this example?

Replacing it with kwidgetaddons - and maybe switch from kmainwindow to 
qmainwindow will make the example simpler.


- Sune Vuorela


On Jan. 10, 2014, 8:49 p.m., Laurent Navet wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/114933/
> ---
> 
> (Updated Jan. 10, 2014, 8:49 p.m.)
> 
> 
> Review request for KDE Examples and Sune Vuorela.
> 
> 
> Repository: kdeexamples
> 
> 
> Description
> ---
> 
> This is part of Google Code-IN Contest.
> As I'm no more student, I've waited for the end of the contest to work on it.
> 
> Comments appreciated,
> 
> 
> Diffs
> -
> 
>   kdeui/kmessagewidgetdemo/CMakeLists.txt 12ef4ac 
>   kdeui/kmessagewidgetdemo/main.cpp d3a5bf0 
>   kdeui/kmessagewidgetdemo/window.h d3a67c8 
>   kdeui/kmessagewidgetdemo/window.cpp 9786da6 
> 
> Diff: https://git.reviewboard.kde.org/r/114933/diff/
> 
> 
> Testing
> ---
> 
> Regression on KTextedit::setClickMessage(), as it don't exist in QTextEdit 
> I've commented the line.
> 
> 
> Thanks,
> 
> Laurent Navet
> 
>


>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[no subject]

[GAURAV Agrawal]

Hi

I am learning Qt and I wanted to start building okular on qt and solve some
bugs.
I have downloaded the repository but it contains a huge amount of files
which I am finding very hard to understand .

If anyone could guide me to understand the structure of the code so that I
could start building Okular on Qt framework and also how to build an
application on Qt,that would  be of great help.

Thanks

Gaurav

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[no subject]

[GAURAV Agrawal]

Hi

I wanted to ask that how should I use the Okular repository code to start
building the application ie. understanding the code structure of Okular

Gaurav

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re:

[Shantanu Tushar Jha]

You should find build instructions at the bottom of the page
http://okular.kde.org/download.php . Instead of this -

cmake -DCMAKE_INSTALL_PREFIX=/path/to/your/kde4/install/dir ..

use this-

cmake -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` ..


If this complains about missing dependencies, you need to install the
dependencies listed on that page. On Ubuntu/Debian you can just say sudo
apt-get build-dep okular


On Wed, Jan 15, 2014 at 8:50 PM, GAURAV Agrawal <
gauravagrawal03...@gmail.com> wrote:

> Hi
>
> I wanted to ask that how should I use the Okular repository code to start
> building the application ie. understanding the code structure of Okular
>
> Gaurav
>
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> unsubscribe <<
>
>


-- 
Shantanu Tushar(UTC +0530)
http://www.shantanutushar.com

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Review Request 114632: Improve pdf title extraction

[Luis Silva]

> On Dec. 26, 2013, 1:57 a.m., Christoph Feck wrote:
> > Hm, you broke the comment :)
> 
> Luis Silva wrote:
> What do you mean? It all works fine here.
> 
> Christoph Feck wrote:
> Yes, because the compiler does not read comments.
> 
> Thomas Lübking wrote:
> Aside this, the approach seems too naive?
> DOIs have a defined structure, leading "doi: 10" (ignoring the case and 
> making colon and whitespace optional) and in general the "problematic" tokens 
> will have a massive digit overhead - so this could be used as additional test 
> ( < 25 && looksLikeIndex())
> 
> Luis Silva wrote:
> @Christoph: Just (finally) understood what you meant with "breaking the 
> comment". I uploaded a new patch that (hopefully) fixes the issue in the 
> correct way.
> @Thomas: The approach was meant to be naive. In this simple form, this 
> patch takes care of all index-like cases as well as most other short garbage 
> titles without further parsing. What would be the point of actually knowing 
> if a very short title was actually a doi or an index?
> 
> Thomas Lübking wrote:
> echo "The Lord of the Rings" | wc -m
> 22
> 
> And that's not a short title - not to mention the typical Stephen King 
> ("It") or other languages that use hanzi, kanji or hanja and will never met 
> your arbitrary 25 glyph requirement.
> Though many academic papers (in western cultures at least) in fact have 
> clumsy long titles, that doesn't hold for other document types.
> 
> OTOH, if the "title" (=index) is some (md5, sha*) hash of the text, that 
> will easily outnumber 25 glyphs.
> 
> So the more honest solution seems to just omit the title field altogether.
> 
> The alternative (don't know how expensive the document scan is) would be 
> to check whether the title field seems like reasonable text, what could 
> invoke the digit ratio, the longest non-digit sequence ("0x12a21f56ea5") and 
> maybe whether there's any digitless word at all.
> 
> Albert Astals Cid wrote:
> Honestly I don't even know why there is the rule for needing a space, 
> looking at my shelf of books i can see "Cryptonomicon", "Azogue", "Portico", 
> "Hyperion", "Endymion", "1984", and then I have stopped. Please, don't try to 
> be that much clever, i can understand if you want to rule out stuff like 
> "Microsoft Word - something.doc", but imho you're being already too broad 
> with the rule of "it includes microsoft". What about if i have a manual about 
> "Microsoft Visual Basic"?
> 
> Honestly omiting or mangling the title is a very bad thing to do. If you 
> have a sensible thing to run over the 1500 test pdf files i have here i'm 
> happy to help.
> 
> Christoph Feck wrote:
> Would it make sense to refactor the code to use the (PDF supplied) 
> document title, and, if for whatever reason it is believed to be wrong, 
> append the extracted text that is believed to be a better title?
> 
> Luis Silva wrote:
> I can see the point Albert is making that when a pdf has a short (but 
> valid) pdftitle and an unparseable first page the resulting extracted title 
> will be gibberish. I also agree that mangling the title just because it 
> seemed to be small is unacceptable. I must admit that I did not think about 
> the cases of hanzi, kanji or hanja for which this patch would systematically 
> force the parsing of the first page of the document. 
> The issue here is when the pdftitle does not match the real document 
> title. In my database of academic papers (700+) this happens a lot. Most of 
> my other documents are either prints to pdf, documents generated from their 
> latex source or Word documents converted to pdf most (90%) of which lack a 
> pdftitle and so have to be parsed anyway. From my experience this is a 
> typical situation, at least amongst academics.  Of course, the best operating 
> solution must cater for the most common personas, not just academics, but in 
> your experience, what would that be?
> 
> Albert Astals Cid wrote:
> I'm with Christoph here, not sure what he use case for this is, but would 
> it be possible to add the extra information instead of replacing it? Maybe 
> even in a second field? Like "title" and "thingwethinkmaybethetitle"?
> 
> Vishesh Handa wrote:
> The more I think about this, the more I realize how this is really not 
> required.
> 
> Use Cases -
> 
> 1. Viewing the title - The title can currently only be seen via the 
> Dolphin sidebar
> 2. Searching - It currently makes no difference if the text is in the 
> title or in the plain text. Both are currently given the same priority. In 
> the future we could give the title/any other field a higher priority, but 
> that has not been done.
> 
> Given that the only real use case is (1), and it is debatable if Dolphin 
> users will actually care, perhaps we could remove this all together. This 
> could be implemented in a specialized application like Conqu

Re:

[Kevin Krammer]

On Wednesday, 2014-01-15, 20:54:47, Shantanu Tushar Jha wrote:
> You should find build instructions at the bottom of the page
> http://okular.kde.org/download.php . Instead of this -
> 
> cmake -DCMAKE_INSTALL_PREFIX=/path/to/your/kde4/install/dir ..
> 
> use this-
> 
> cmake -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` ..

I am not sure if this is a good idea, that will result in an install path that 
is the system's install path. Nothing other than the package manager should 
install into that.

Cheers,
Kevin

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


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

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re:compiling okular

[GAURAV Agrawal]

Hello

On executing the steps of compiling Okular,it gives the following error
even after installing all the dependencies by the command

   * sudo apt-get build-dep okular*
as I am having ubuntu.





















*gaurav@gaurav-Inspiron-5520:~/okular/build$ cmake
-DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` ..-- Found Qt-Version 5.0.2
(using /usr/bin/qmake)CMake Error: The following variables are used in this
project, but they are set to NOTFOUND. Please set them or make sure they
are set and tested correctly in the CMake files:QT_QT_INCLUDE_DIR   used as
include directory in directory
/home/gaurav/okular/build/CMakeFiles/CMakeTmpCMake Error: Internal CMake
error, TryCompile configure of cmake failed CMake Error at
/usr/share/kde4/apps/cmake/modules/FindKDE4Internal.cmake:1311 (message):
Unable to compile a basic Qt application.  Qt has not been found
correctly.Call Stack (most recent call first):
/usr/share/cmake-2.8/Modules/FindKDE4.cmake:95 (find_package)
CMakeLists.txt:3 (find_package)-- Configuring incomplete, errors
occurred!gaurav@gaurav-Inspiron-5520:~/okular/build$ qmake -versionQMake
version 3.0Using Qt version 5.0.2 in /usr/lib/i386-linux-gnu *



I have installed Qt Creator 2.4.1 based on Qt 4.7.4 on my system but still
it says



*QMake version 3.0  Using Qt
version 5.0.2 in /usr/lib/i386-linux-gnu *
please help me fix it.

Thanks
Gaurav

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: compiling okular

[arjun]

On Wednesday 15 Jan 2014 9:41:55 PM GAURAV Agrawal wrote:
> Hello
> 
> On executing the steps of compiling Okular,it gives the following error
> even after installing all the dependencies by the command
> 
>* sudo apt-get build-dep okular*
> as I am having ubuntu.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> *gaurav@gaurav-Inspiron-5520:~/okular/build$ cmake
> -DCMAKE_INSTALL_PREFIX=`kde4-config --prefix` ..-- Found Qt-Version 5.0.2
> (using /usr/bin/qmake)CMake Error: The following variables are used in this
> project, but they are set to NOTFOUND. Please set them or make sure they
> are set and tested correctly in the CMake files:QT_QT_INCLUDE_DIR   used as
> include directory in directory
> /home/gaurav/okular/build/CMakeFiles/CMakeTmpCMake Error: Internal CMake
> error, TryCompile configure of cmake failed CMake Error at
> /usr/share/kde4/apps/cmake/modules/FindKDE4Internal.cmake:1311 (message):
> Unable to compile a basic Qt application.  Qt has not been found
> correctly.Call Stack (most recent call first):
> /usr/share/cmake-2.8/Modules/FindKDE4.cmake:95 (find_package)
> CMakeLists.txt:3 (find_package)-- Configuring incomplete, errors
> occurred!gaurav@gaurav-Inspiron-5520:~/okular/build$ qmake -versionQMake
> version 3.0Using Qt version 5.0.2 in /usr/lib/i386-linux-gnu *
> 
> 
> 
> I have installed Qt Creator 2.4.1 based on Qt 4.7.4 on my system but still
> it says
> 
> 
> 
> *QMake version 3.0  Using Qt
> version 5.0.2 in /usr/lib/i386-linux-gnu *
> please help me fix it.
> 
> Thanks
> Gaurav
Try  "cmake -DQT_QMAKE_EXECUTABLE=/usr/bin/qmake-qt4"

Remove the CMakeCache.txt file first

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Fwd: [kde] Bug#688801: kde-window-manager: Incorrect Build-conflict against libgles2-mesa-dev

[Held Bier]

2014/1/13 Thomas Lübking :
> On Montag, 13. Januar 2014 12:58:55 CEST, Myriam Schweingruber wrote:
>
>> This way i've got a kwin_gles also, thought ldd'ing on it showed that
>> besides libEGL dependency (which is good), it also relied on libGL
>> (which is not good! this means some/most of GL functions were still
>> used).
>
>
> kwin/_gles links libplasma which links libGL - you'd have to build plasma
> against GLES (while i'm not sure whether that's possible) or strip libplasma
> deps from kwin - this should be the case for "plasma workspaces 2"("KDE
> notfive"), but libplasma might still be dlopened through qml (eventually
> including libGL)
> It's not trivial, but possible, for KDE SC4 (it's mostly used for
> effectframe styling - forcing them to be unstyled will get you > half the
> way) - but since workspace is frozen, this could only be applied downstream
> (and on top of that, current QML usage might still kick in libplasma->libGL)
>
> However, GLES is a subset of GL and kwin_gles only uses this subset, so if
> GLES is accelerated for you, LD_PRELOADing libGLES *might* do the job - but
> i've really no idea.
>
> Cheers,
> Thomas
>
> ps: despite "compiz", it's "compoSiting"

Thomas, thanks for the detailed answer! If kwin_gles only uses a GLES subset,
then i'm golden :) I'll try LD_PRELOAD trick.

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Review Request 114933: KF5 Port of kdeui/kmessagewidgetdemo

[Laurent Navet]

> On Jan. 15, 2014, 10:17 a.m., Sune Vuorela wrote:
> > kdeui/kmessagewidgetdemo/CMakeLists.txt, line 23
> > 
> >
> > Would it be hard to get rid of XmlGui here? I don't see what it really 
> > buy us for this example?
> > 
> > Replacing it with kwidgetaddons - and maybe switch from kmainwindow to 
> > qmainwindow will make the example simpler.

XmlGui replaced with KWidgetAddons and KConfigWidgets.
switched from KMainWindow to QMainWindow.


- Laurent


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/114933/#review47428
---


On Jan. 10, 2014, 9:49 p.m., Laurent Navet wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/114933/
> ---
> 
> (Updated Jan. 10, 2014, 9:49 p.m.)
> 
> 
> Review request for KDE Examples and Sune Vuorela.
> 
> 
> Repository: kdeexamples
> 
> 
> Description
> ---
> 
> This is part of Google Code-IN Contest.
> As I'm no more student, I've waited for the end of the contest to work on it.
> 
> Comments appreciated,
> 
> 
> Diffs
> -
> 
>   kdeui/kmessagewidgetdemo/CMakeLists.txt 12ef4ac 
>   kdeui/kmessagewidgetdemo/main.cpp d3a5bf0 
>   kdeui/kmessagewidgetdemo/window.h d3a67c8 
>   kdeui/kmessagewidgetdemo/window.cpp 9786da6 
> 
> Diff: https://git.reviewboard.kde.org/r/114933/diff/
> 
> 
> Testing
> ---
> 
> Regression on KTextedit::setClickMessage(), as it don't exist in QTextEdit 
> I've commented the line.
> 
> 
> Thanks,
> 
> Laurent Navet
> 
>


>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<