User-Agent: Opera/9.02 (X11; Linux i686; U; en) Build Identifier: Move the file from one window to other in any way (CTRL + X, cut-paste or right mouse move). After this action, the content of the first window should automatically refresh, but it does not. Reproducible: Always Steps to Reproduce: 1. Open two windows 2. Move a file from one window to other 3. You must press F5 at first window, too see the change
I guess you did not build Thunar with FAM/Gamin support.
One more dependence?.. No, I didn't. But I don't see a necessity in this concrete case, while this action is direct. It is enought to simply call an update of icon view after the operation (for eg., like in file deletion case), isn't it? Thanks.
Do these two windows run in the same Thunar process (i.e. did you open the second window from the first one, or build Thunar with D-BUS support)?
Any news?
> Do these two windows run in the same Thunar process No, it is two separate processes. If the second window is open from the first - it works fine. > <...> build Thunar with D-BUS support? No, without D-Bus support. Hence, Thunar uses only D-Bus for IPC?
Sure Thunar uses D-BUS for IPC, what else could Thunar use an "IPC mechanism" for? ;-) But there's the explanation then, and so this bug is INVALID. Because the other Thunar process has no way to get noticed of the file move. Neither does the kernel report it (i.e. via Gamin), nor does the other Thunar window has a chance to report it.
> Sure Thunar uses D-BUS for IPC, what else could Thunar use an "IPC mechanism" > for? ;-) I really don't know about the needs of Thunar, but isn't enough a simple POSIX defined SysV IPC? > But there's the explanation then, and so this bug is INVALID. Well, if this is noted in documentation, let's close it.
(In reply to comment #7) > > Sure Thunar uses D-BUS for IPC, what else could Thunar use an "IPC mechanism" > > for? ;-) > I really don't know about the needs of Thunar, but isn't enough a simple POSIX > defined SysV IPC? That'd be unnecessary overhead.
> That'd be unnecessary overhead. But it would be portable, save up one more dependence and even resources (when DBus is used only by Thunar).
If Thunar would be the only one to use D-Bus, and everything else would use SysV IPC, then yes. But it's the exact opposite, everything in today's desktop world, except for some legacy apps, uses D-Bus, and the (unportable!) SysV IPC mechanism wasn't meant for desktop IPC anyway. Even worse, Thunar requires D-Bus to talk to HAL. And so it'd be a waste of time and resources to use both D-Bus and another IPC mechanism if everything else already uses D-Bus. And as said, and as you can learn from the papers/documentation on SysV IPC, if you will ever be forced to dig into that, it's really not meant for general purpose IPC of different applications. And you will still need marshalling/unmarshalling, etc. So, to conclude, it won't save any dependencies or resources, that's one of the myths that won't die in today's Linux desktop communities.
> If Thunar would be the only one to use D-Bus Well, Slackware doesn't provides native D-Bus package (yet). Thunar is the only application using it. > and the (unportable!) SysV IPC mechanism Why? It is defined in POSIX, SUSv3 and other standards and it is supported by all modern UNIX-Like systems. Did you mean something else? > Even worse, Thunar requires D-Bus to talk to HAL. And so it'd be a waste of time and resources to use both D-Bus and another IPC mechanism <...> SysV IPC, if you will ever be forced to dig into that, it's really not meant for general purpose IPC of different applications. Not both. If D-Bus is not compiled - use SysV IPC for some actions. As said, I don't know Thunar needs, but is it so complex to use, for example, message queues to make a notify for window refresh? I think it's not. > that's one of the myths that won't die in today's Linux desktop communities. I cannot dispute, when I am mostly POSIX level developer, not familiar with desktop ideologies. But as user, I don't want to see a huge list in ldd <application>, when the most part of those libraries are used by only one single application. IMHO, this goal would separate such bloated environments like KDE/Gnome from XFce, Fluxbox, etc and user can choice. But it's only my opinion in our discussion :)
(In reply to comment #11) > > If Thunar would be the only one to use D-Bus > Well, Slackware doesn't provides native D-Bus package (yet). > Thunar is the only application using it. I dunno if you are using a pretty outdated Slackware, but atleast the people I know that use Slackware, have D-BUS, HAL, etc. > > and the (unportable!) SysV IPC mechanism > Why? It is defined in POSIX, SUSv3 and other standards and it is supported by > all modern UNIX-Like systems. Did you mean something else? Well, that basicly means nothing. There's a reason why it's (mostly) unused. > > Even worse, Thunar requires D-Bus to talk to HAL. And so it'd be a waste of time and resources to use both D-Bus and another IPC mechanism <...> SysV IPC, if you will ever be forced to dig into that, it's really not meant for general purpose IPC of different applications. > Not both. If D-Bus is not compiled - use SysV IPC for some actions. > As said, I don't know Thunar needs, but is it so complex to use, for example, > message queues to make a notify for window refresh? I think it's not. As said, that'd be overhead (-> maintaince). D-Bus is there as standard lightweight desktop IPC framework. There's no need to support different IPC mechanisms. If your distribution doesn't offer D-BUS, HAL, etc. yet, it's somewhat out of date, and will either be updated or dropped soon. > > that's one of the myths that won't die in today's Linux desktop communities. > I cannot dispute, when I am mostly POSIX level developer, not familiar with > desktop ideologies. > But as user, I don't want to see a huge list in ldd <application>, when the > most part of those libraries are used by only one single application. > IMHO, this goal would separate such bloated environments like KDE/Gnome from > XFce, Fluxbox, etc and user can choice. But it's only my opinion in our > discussion :) Dependencies = less overhead in most cases. Imagine, you'd link all applications statically. That means no dependencies. Juhu. So, it's lightweight, right?... Well, of course not. It has nothing to do with desktop apps, but it's a general fact: If you duplicate functionality, you'll have overhead. So, what's easier on resources: (a) every application implements it's own IPC or (b) all applications use D-Bus? As said, this is something that most people don't get, and as such it's stated very often and so people joining the Linux/Unix communities raise up with the belief that less dependencies mean less wasted resources. But it's nearly exactly the opposite in several cases. BTW: Bugzilla is not meant for such discussion. If you want to continue, please use the thunar-dev mailinglist.