[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KPDF and search... "fork" xpdf?
From:       Frans Englich <frans.englich () telia ! com>
Date:       2004-09-03 1:23:23
Message-ID: 200409030123.23253.frans.englich () telia ! com
[Download RAW message or body]

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 <<
[prev in list] [next in list] [prev in thread] [next in thread]