Re: [Nautilus-list] continued redhat merge
- From: Darin Adler <darin bentspoon com>
- To: Alex Larsson <alexl redhat com>
- Cc: Nautilus <nautilus-list lists eazel com>
- Subject: Re: [Nautilus-list] continued redhat merge
- Date: Mon, 17 Sep 2001 09:55:16 -0700
on 9/17/01 9:48 AM, Alex Larsson at alexl redhat com wrote:
> Using eel_read_entire_file sounds like a good idea.
We probably also want to add a maximum size parameter to
eel_read_entire_file because it's probably never a good idea to read a whole
file into a buffer in memory without any bound on how much data you are
going to read. Or rather, we want to add a newly named function to avoid
incompatibility with older nautilus and newer eel. On HEAD we can have only
the single function with the maximum file size. Also, we can change it so
that it always puts a '\0' after the file at the same time, since that hurts
nothing and helps in this case.
>> The code in nautilus-directory-async.c looks very good overall, but it's
>> very hard for me to spot problems just be reading it (especially in diff
>> form). I think we should put the changes into nautilus HEAD, but then we
>> need some testing before we can do a 1.0.5 release. And I'll probably have
>> to read it over again and think about possible simplifications. I don't
>> think that we need both "add_file_to_work_queue" and a separate
>> "async_state_changed". To fully deploy the new model, I'd like to see more
>> of the code to support the old model deleted.
>
> I don't really know this code that well. Is it possible to move it to HEAD
> withouth the other changes without much work?
Possible, but not easy, to disentangle this change from the others. There's
no big hurry, I guess, so lets do it all together.
>> Since nautilus_file_is_nautilus_link is changing function, I'd ideally like
>> to see it change its name too, but then again that would also mean changing
>> the names of everything in nautilus-link* files so I guess we can leave it
>> alone as long as we make a nice comment to explain that "Nautilus link"
>> means ".desktop file or historical Nautilus link file". I don't see such a
>> comment anywhere in the diff.
>
> I will add such a comment.
I have since realized that "historical" Nautilus link files are still needed
for things like the trash file on the desktop. It would be great if someone
changed it so that wasn't true, or made the trash use a .desktop file
instead (with a suitable additional key in the .desktop file, I guess). But
anyway, calling it "historical" might be premature if we still need it for
more than just compatibility.
>> What's the status on the code inside "#if ADDITIONAL_TEXT_DISABLED"? Lets
>> remove this feature completely, or turn it back on.
>
> It was disabled, because the text stored in the .desktop files was often
> really bad.
>
> Stuff like:
> Name=Emacs
> Comment=Emacs
> just made it look really bad.
But this also disables the additional text from the old Nautilus link files.
If .directory files Content are not suitable for additional text, that
should be changed in the desktop back end for the link code, rather than
disabling display of additional text here in the directory view.
-- Darin
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]