From kde-devel  Fri Sep 03 01:23:23 2004
From: Frans Englich <frans.englich () telia ! com>
Date: Fri, 03 Sep 2004 01:23:23 +0000
To: kde-devel
Subject: Re: KPDF and search... "fork" xpdf?
Message-Id: <200409030123.23253.frans.englich () telia ! com>
X-MARC-Message: https://marc.info/?l=kde-devel&m=109418992225690

On Thursday 02 September 2004 16:36, Albert Astals Cid wrote:
> Hi, i have implemented simple search in kpdf based on the capabilities xpdf
> provides. The "problem" is that kde standard find text dialog lets the user
> select more things than xpdf supports (whole words, case sensitive, etc.)
>
> To make that things work i would have to "fork" the xpdf that is inside the
> kpdf directory to support them.
>
> So the dilema is, "fork" xpdf that is inside kpdf to try to support more
> features or replace fancy search dialog with a simple KInputDialog::getText
> and stay only with simple search.
>
> What do you think?

How about extending the file dialog API to allow the API-user to toggle what 
features should be available? This could be achieved by an overloaded 
constructor and a set/getters for an enum property(OR'ed flags), which lists 
the various search functionalities. They would be disabled, not hidden, when 
told they are not relevant.

This would have these advantages:

* A standard KDE widget is used; code saved, and consistent interface

* It's not impossible this situation appears again; then the widget is ready

* You are free from stressing with implementing features in xpdf/whatever :) 
(and what if it's not even possible..)

Just a suggestion.


Cheers,

		Frans


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