pan-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Pan-devel] Re: Regex Filters


From: Jack Cuyler
Subject: [Pan-devel] Re: Regex Filters
Date: Fri, 23 May 2008 23:00:32 +0000 (UTC)

On Fri, 23 May 2008 16:36:51 +0000, Duncan wrote:

> Jack Cuyler <address@hidden> posted
> address@hidden, excerpted below, on  Fri, 23 May 2008
> 03:16:37 +0000:
> 
>> I've attached an updated patch to Bug 351196 – "Wildcard support in the
>> group search box".  This patch allows regex searches/filters in the
>> header pane as well as the group pane.  It also adds an option to the
>> preferences menu to enable regex filtering by default.
>> 
>> As this is my first real patch submitted anywhere, so I'd love
>> feedback.
>> 
>> http://bugzilla.gnome.org/show_bug.cgi?id=351196
> 
> I like the idea.  The only doubt I have is that both GNOME in general
> and Charles in particular, prefer to minimize the number of config
> options in ordered to not confuse the newbie user.  (Fortunately for
> this power user, Charles isn't quite as extreme about it as GNOME often
> is, likely the reason this normally KDE user is still using pan.  IMO,
> of course.) For the same reason Charles expressed doubts about regex by
> default for the newbie user, I think he may be hesitant about this.
> 
> The solution he has used for a number of such more "power user" options
> is to have a setting for them in the config file (preferences.xml, for
> global prefs like this), but NOT put them in the GUI.  Make the config
> file variable name self-documenting, so people editing it know its type
> and what it does, make sure it saves and restores the file setting
> correctly (and gracefully deals with botched configs, tho I've not
> tested that so I have no idea if pan does so in general), and leave it
> at that. Actually, I'd suggest that you supply a patch with the GUI
> setting and without it, making it easy for Charles to choose which he
> wants.  I'd expect that to increase the likelihood of the patch getting
> applied, when he focuses on pan development again.

The idea came from Charles' suggestion that regex use be an option rather 
than just replacing the default filter behavior.  The patch submitted by 
Benjamin did just that, but only for the header pane.  The first patch I 
submitted extended this functionality to the group pane (and it was a 
pain, as the existing filter box didn't have a drop down menu).

Now I know /I/ like using the regex filter, so it was frustrating to /me/ 
to have to select the feature each time I started pan.  But I also 
realized that others may not, and it would be better to leave it off by 
default.

Which is where the option came in.  I honestly thought it would be harder 
than it was.  I found where the preferences menu was generated in prefs-
ui.cc and added my bit in there, just to get that part out of the way.  I 
had (and still have) no idea how the preferences file is written, and 
thought I would have to hunt that down. 

But first I compiled and ran, just to test that the new selection was 
added to the menu.  I didn't think it would do anything other than set an 
unused variable.  Quite by accident, I discovered that by selecting the 
option, the key was written to the file.  Magic!  So I really didn't go 
any deeper.  If you or Charles or others think having the option in the 
preferences menu clutters the gui, I can dig deeper and figure out how to 
add the line to preferences.xml, and set it to false, without using the 
gui.  Or Charles could do it in seconds :)

> Talking about saving and restoring the option from the config file...
> I'm not really a coder and therefore not particularly familiar with pan
> or indeed C++ code, tho I can usually make some sense of it if I have to
> or from a sysadmin perspective, but nothing in the patch leapt out at me
> as dealing with saving the preference and restoring it.  If it's dealt
> with, mention which lines (and in particular which lines deal with the
> name it'll use in the config file, since that's what I was really
> looking for), and you'll help me understand pan better too. =8^)


I'm not much of a programmer myself.  Like you, I'm much more a 
scripter.  This really is my first attempt at any programming.  That 
being said...

The name of the key in preferences.xml is "use-regex".  Like I said 
above, it is magically created by prefs-ui.cc when the option is 
selected.  That is, it's Boolean, and defaults to false and will be 
created when the option is selected.  The line is:

w = new_check_button (_("Use regex searches by default"), "use-regex", 
false, prefs);

As for reading the preferences from the file, there's a for loop that 
creates each entry in the drop down menu. It loops through the various 
search "modes".  In the original code, the first is automatically 
selected, with the line:

mode = 0;

I changed that to check the preferences and see if we want to use regex 
instead, defaulting (if it's missing) to false:

bool regex = _prefs.get_flag ("use-regex", false);
if (regex == true )
  mode = 1;
else
  mode = 0;

"i" is a variable that increases by one in each pass of the loop, 
starting at 0.  When "i" and "mode" are equal, the option is set to 
active:

if (mode == i)
  gtk_check_menu_item_set_active (GTK_CHECK_MENU_ITEM(w), TRUE);


If you want to use the preference without modifying the gui, that is, 
have the regex search selected by default according to preferences in the 
file but not set by the gui, simply eliminate the changes to prefs-ui.cc 
from the patch.  That would be the last 14 lines.  Then add the line to 
preferences.xml yourself:  

<flag name='use-regex' value='true'/>

Remove that line or set the value to false to go back to standard 
behaviour.


To further assist you in reading in the preferences, the functions(1) are:

prefs.get_int
prefs.get_color_str
prefs.get_string
prefs.get_flag

for getting integers, color strings, strings and booleans, respectively.  
Each is followed by two comma separated values in parenthesis, the name 
of the key, usually quoted, and the default value, also quoted if not an 
integer or boolean, for when the key is missing or unset.

ex:
prefs.get_int ("get-latest-n-headers", 300)
prefs.get_color_str ("score-color-watched-fg", "black")
prefs.get_string ("header-pane-columns", 
"state,action,subject,score,author,lines,date")
prefs.get_flag ("size-pictures-to-fit", true)

I /believe/ an underscore before the function(1) tells it to look for the 
function (in this case "prefs") to be defined outside of the current 
function.  Someone with more experience with C++ and/or programming in 
general can probably correct me or explain it a lot better.

Hope this helps.

(1) I'm not sure "function" is the correct term here.  As I said, I'm not 
really a programmer.  It's /similar/ to a shell function.

-- 
Cheers,
Jack

I WILL NOT CARVE GODS
I WILL NOT CARVE GODS
I WILL NOT CARVE GODS
I WILL NOT CARVE GODS

        Bart Simpson on chalkboard in episode 8F11





reply via email to

[Prev in Thread] Current Thread [Next in Thread]