Re: [BUG] ? mc hangs when $DISPLAY set
On Tue, May 02, 2006 at 11:25:41PM +0200, Enrico Weigelt wrote: > What exactly is this X connection for ? > for tracking keyboard modifiers ... fun, isn't it? i think mc should only connect to $DISPLAY if $WINDOWID is also set, meaning it was started from within an xterm (many, if not all term emulators set this env var). -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
[BUG] ? mc hangs when $DISPLAY set
Hi folks, I've got some strange problem with mc, I already hat a long time ago, but disappeared magically and now is back: mc keyboard input is broken - seems like it has Alt-Gr is pressed continously ... completely unusable. It happened only on one machine, which is accessed only via ssh. Doesn't matter from which machine I tried. The other machines do not have such problems, even when connecting through sevel ssh's from one to another. Also ssh'in from an xterm (on another machine) worked without problems. So I strace'd mc on several machines to compare mc's actions between working and non working. I found out that on working machines it gets in clean keystrokes via fd 3. On the broken one, the keystrokes come at fd 4, but fd 3 brings in a lot of bytes I could't interpretate. lsof showed by this fd 3 as an socket connected to the (remote) X-server. Unsetting $DISPLAY helped. Obviously we've got a problem, when mc sees an X display (and connects to it), but doesn't run in an xterm. What exactly is this X connection for ? cu -- - Enrico Weigelt== metux IT service - http://www.metux.de/ - Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: rsync://sources.metux.de/metux-patches - ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: midnight commander reloaded (?)
Hello all, I would also like to first thank all you developers for your work! Jozef Riha wrote: Dear mc devs, please let me thank you for your work at the first place. Midnight commander is still my number one file-manager (Linux). Except the utility I welcome there are however things I see in other file-managers (total commander) which I would be happy to see ported. Specifically: * user defined key bindings This is a feature that I would like very very much, or if it is cumbersome to incorporate, at least an enhanced set of keybindings. Today I mainly miss how to swiftly change sort order and enable/disable view of hidden files/directories. If I might, as a user, add one more request, it would be support for diffing of directories as in the windows application Total Commander. There you can decide on recursiveness, "on content", "ignore date" and after the diff is performed you can easily view equal files, unequal files, files unique to one directory, etc. I admit I am a little bit hesitant to write here, because of reverence of the developers skills and fear of myself posing stupid questions, but now that I have decided to post, I would be very grateful to know whether these two things are reasonable to exepct to ultimately arrive in mc? -- Best Regards, Caj Zell ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: midnight commander reloaded (?)
Hello! Just a few comments. On Tue, 2006-05-02 at 19:48 +0200, Jozef Riha wrote: > Dear mc devs, > > please let me thank you for your work at the first place. Midnight > commander is still my number one file-manager (Linux). Except the > utility I welcome there are however things I see in other > file-managers (total commander) which I would be happy to see ported. > Specifically: > * user defined key bindings > * better bookmarks system w/ hotkeys > * more options for searching (Esc ?) Potential killer feature - exclude versioning data (CVS, RCS, SCCS, .git, .svn directories and *,v files) with one checkbox. Although I should probably just find a night for it and add it to mc. > * tabs (like in firefox/opera/you name it) I think backgrounding the viewer and the editor would be fine. I don't think backgrounding extra panels would be helpful. > * plugin support > * better archive support (zip archive inside zip archive inside rar This is working for me already. On the other hand, associations don't work well on the archive files (think pdf in zip). > and sidenote: look how tc opens/reads huge zip files) > * ability to send copy/move process to background and back, manager of > background processes Yes, that's another useful thing to background. Another high-priority requirement - proper Unicode support. And better keyboard support in Linux console. > -- Lower priority ones -- > * drag&drop support > * option to use a GUI (--enable-gui like option) That has the potential to make the new commander another mc. Unless both the text and the GUI frontends use the same library for drawing, and the differences are transparent to the bulk of the code. > * clock (remember volkov commander?) > * multiplatormness (a win32 port) Same comment applies. If it's not transparent to most of the code, it will damage the project very badly. > As from what I have read about the history of mc, the current > development is somewhat cumberome. Namely since version 4.x.x the > patches are becoming less transparent and it is still harder for a new > feature to make it into the sources. To be fair, many features that were added in the "good old times" required significant clean-ups afterward. So it's not like that it suddenly became harder to add features because the of the code changes. The requirements were changed to allow only complete patches that would not require subsequent cleanups. > I do not know if or how much is > this true, if the real problem is the active developer number or > something else, but I somehow feel that in order to make mc going > somewhere the sources must be rewritten from scratch. I agree. Lots of time was spent on figuring out why some code was written in a certain way. The sources are full of irrelevant workarounds for libraries that are no longer used. > Midnight commander is still the only widely accepted filemanager for > console but I see it becoming too old these days. And I am not the > only one seeing this. Therefore I was thinking of the following: > collect a decent sum of money from the linux users who share the same > ideas as > me, make a competition of tenders based on the demo of the new > manager, set detailed specifications (GPL license mandatory) on > software after those are met the money will be paid. Simil > ar to SoC except for that anyone (including companies) will be able to > take part on it. I'm afraid the best code is written by those who are going to maintain it in the long term, not by those who want just to meet certain requirements before the deadline. In the case of "summer of code", the ideas were suggested by maintainers of actively developed projects. The criteria for success was integrating the changes to the codebase. And what would happen to the mc-reloaded once the "summer of code" is over? Who is going to maintain it? > What I would like to know is your opinion on the whole matter as I > admit I may be all wrong here. I agree that mc should be rewritten, but I don't think your approach is workable. You can end up with something that does what the specs say and nothing else, and the code may be even harder to improve. -- Regards, Pavel Roskin ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
midnight commander reloaded (?)
Dear mc devs, please let me thank you for your work at the first place. Midnight commander is still my number one file-manager (Linux). Except the utility I welcome there are however things I see in other file-managers (total commander) which I would be happy to see ported. Specifically: * user defined key bindings * better bookmarks system w/ hotkeys * more options for searching (Esc ?) * tabs (like in firefox/opera/you name it) * plugin support * better archive support (zip archive inside zip archive inside rar and sidenote: look how tc opens/reads huge zip files) * ability to send copy/move process to background and back, manager of background processes -- Lower priority ones -- * drag&drop support * option to use a GUI (--enable-gui like option) * clock (remember volkov commander?) * multiplatormness (a win32 port) As from what I have read about the history of mc, the current development is somewhat cumberome. Namely since version 4.x.x the patches are becoming less transparent and it is still harder for a new feature to make it into the sources. I do not know if or how much is this true, if the real problem is the active developer number or something else, but I somehow feel that in order to make mc going somewhere the sources must be rewritten from scratch. Midnight commander is still the only widely accepted filemanager for console but I see it becoming too old these days. And I am not the only one seeing this. Therefore I was thinking of the following: collect a decent sum of money from the linux users who share the same ideas as me, make a competition of tenders based on the demo of the new manager, set detailed specifications (GPL license mandatory) on software after those are met the money will be paid. Simil ar to SoC except for that anyone (including companies) will be able to take part on it. What I would like to know is your opinion on the whole matter as I admit I may be all wrong here. Thank you. Best regards, -- Jozef Riha ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
