Re: [anjuta-devel] Search Dialog in Anjuta 3.2?

[Sébastien Granjoux <seb sfo free fr>]

Hi,


Le 13/02/2012 14:30, Johannes Schmid a écrit :
> Yes, I have been quite busy working and it
> sometimes hard to motivate yourself for coding when you have been working
> for 8-10 hours.

Yes, I'm doing it from quite some time now but, I'm not programming all 
the time at work so it is something different at least for me.


> But we could possibly save the state with gsettings so that you
> at least don't have to always set it.

Yes, I think it would be better.


> Even as I proposed it I don't like the current UI with the menu. But
> checkbuttons don't scale very good either. In english that *might* work
> but in Germany you would have two check boxes
> [x] Groß/Kleinschreibung beachten [x] Regulärer Ausdruck
> which will of course work on my 24' desktop screen but not really on my
> 13' notebook anymore.

Well, firefox has "previous", "next", "highlight" and "case sensitive". 
The window is a bit a wider but not that much. But we could perhaps have 
just an icon with a tooltip, like we already have for next and previous.


> What I was thinking about is an extra button with an [Options] symbol that
> pops up the menu. The current state should then be shown either in the
> remaining space (can be ellipsized if needed) or in the statusbar.

I think an option button will be fine as an user will know that it can 
click here. Then I'm not sure it is important enough to worth a place in 
the status bar.


> > 3. Some editors do case sensitive search if the user type upper case
> > characters in the search string, this can be another option if you prefer.
> Looks like a rather random choice to me.

I think it's quite natural when you use it but perhaps for not for new 
users.


> > 4. It will be nice to be able to search in the selected text only.
> If you have some selection the search should start inside it AFAIK already.

Well, it starts from the beginning of the selection. But my idea was to 
be able to select a column of text and search only in this column by 
example. But as I'm writing, I see that it needs too much changes.


> The "Find in files" button has it's origin in regexxer which is one of the
> best search tools IMHO. But I like the idea of combining "Search" and
> "Find files" into one button so I will try to implement it. It's not a big
> deal.

Ok. I wasn't aware of this program, I understand better your design now.


> > 9. For checking and unchecking files in the list, it should be possible
> > to select a range of files.
> What UI would you propose here? Popup-menu?

I don't know. It's possible with a popup-menu but it's difficult to find 
for a new user. Perhaps we can just discard this ideas and display the 
file in a tree view (like regexxer) where it should be possible to 
remove a complete directory.


> In general I agree with this points but I won't have time for it this
> cycle.

That's fine. I think it's already really nice to have this function 
back. We can spend more time in the next cycle to improve these details.

> The latter is a bit tricky because there is no easy way to find the
> line of a match as you only get the string position.
> Of course we could break up a file in lines but that would break multiline
> search with regular expressions. And counting the newlines between the
> matches also seems like a slow solution though we might try that.

The line number perhaps is not that important, if we can at least 
display the line and be able to open the editor at the right position 
when we double click on it.

Else, I think breaking the file in lines is not right solution, so 
counting the newlines looks better, the data should be in memory so it 
shouldn't take so much time.


Regards,

Sébastien