Re: the gnustep wreckage. Part 1: windowmaker and user apps

[Enrico Sersale]

On 2004-11-20 21:48:48 +0200 Nicolas Roard <nicolas@roard.com> wrote:

> 
> Le 19 nov. 04, à 18:27, Enrico Sersale a écrit :
>>>> 
>>>> both the apps needs file operations.
>>>> both the apps needs an Inspector.
>>>> both the apps needs a Finder and will use its File Annotations and Live
>>>> Search Folders.
>>>> both the apps use fswatcher, thumbnailer, etc...
>>> 
>>> Yes, but why having multiple graphical applications ?
>>> Wouldn't it be better to use frameworks for that ? and optionally some
>>> servers (tools) if you really want for things like copy operations ?
>> 
>> Not sure if I understand correctly or I'm missing something...
>> But let we take Inspector as example: its window is *the place* where the 
>> information is shown. And it must be only one place where this happens, 
>> that is, a common window for all the applications. How can I get this with 
>> a framework? I'd have an inspector for each app...
> 
> hm, ok, I understand more why you split out the Inspector now. I still 
> disagree, but at least it make sense.
> I find this separation quite odd, as "Operations" and "Inspector" aren't 
> applications by themselves (why having a tile for them for example..) and I 
> think there
> were other possibilites (put operations/inspector in workspace and have the 
> desktop requesting things using DO for example.. and/or have 
> operations/inspector in framework for more clarity perhaps...). If "Desktop" 
> and "Workspace" depends so much on common things, it's perhaps an indice that 
> they belong in the same place:
> I'm not sure why the "desktop" needs to be separated to the "workspace" 
> anyway, as you can just flag the desktop window as omnipresent on all 
> (virtual) desktops -- that's how nautilus works for example.

Besides the Desktop and Workspace separation, there are also other reasons for 
this split. 
You should consider that, many times, the solution that seems the most logical 
one in theory, is not the same pratically :-)

Take Operation as example: in the last four years I think that I've tested all 
the possible solutions for this problem; tools, threads in the main app, a 
daemon launching subtasks, etc... At the end, I've had to understand that the 
harder part of the process was not the file operation itself but the DO 
communication between the process working on the files and the process updating 
the process indicator. Having this window in the main app (in the file viewer), 
even if the operation on the files runs in a other process/thread, slows down 
all the application. Delegating all this stuff to an other app, leaves the file 
viewer responsive. This is the main reason for which I want to have a separate 
application.

In the Inspector there are a similar problem. The Contents Inspector runs all 
the time-consuming tasks as, for example, showing the contents of a image file, 
in other threads; when you select a new file, Inspector detach a thread that 
creates a resized image and pass it back as NSData to the view that must show 
it and then exits. 
But think now at this example: a browser column showing a directoty full of 
images; select the first row and then keep pushed your DownArrow key. 
If the Inspector view is in the same app of the browser, *a lot* of processing 
is generated because, for each row, a new thread is detached. On the other 
hand, with the solution I'm using, for each row only a oneway void method of 
the remote object is used. In this method the thread is detached "only if the 
previous image is done"; else, the new selection is assigned to a ivar that 
will be used when the current thread will exit. (Well, here the problem is a 
bit more complex but it outruns my English).

Finder: in this case you are right. When the live search folder will be done 
I'll blend it back in the main app.

Regarding Desktop: there is not, for the moment, a real reason to keep it 
separate. But I want to leave the way open for a integration with a future 
GNUstep window manager (It is even possible that I'll start to write it if I'll 
have time for this). 
It is true that it would be enough to flag its window as omnipresent but this 
already implies some X stuff and I don't want this in GWorkspace.

> Of course I'm really not a friend of a "desktop" place, I think it's not a 
> really good thing, but hey ;-) I know that lots of people disagree.
> 
> So, well, I'm not really convainced by this separation, but I'm not the one 
> who code and I understand now why you did it that way. Thanks a lot for the 
> explanation.
> 
> If you keep things that way though, it would probably be nice to quit 
> Inspector.app and Operations.app when the desktop and the workspace are gone; 
> and perhaps remove their tile possibly as well as their menu (but well, then 
> it will also trigger some problems... yuck).

I'll do this (but not sure about the menues).

> Another nice addition would be to have the inspector *resizible* -- 
> particularly when used in "view content" mode.
>
>
> thanks,
>