Re: 4.7pre4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Enrico Weigelt wrote: ACK. But we also should have the traditional one built-in as a compile-time option (for small systems). Small systems? In this case better way to use present libraries as possible for lesser size binary file and for less memory usage per one process. Code of libraries will shared in memory between processes rather than have same blob-code in any running process. And in reply to http://www.midnight-commander.org/ticket/1784#comment:12 It is *MUCH* smaller, similar in size like mc's internal vfs. And this all reasons? To me, it definitivly does. To me not. In really small systems better to use busybox without mc. Or just older versions of mc... I dont want the whole gnome blobs on dozens of small devices, VZs, etc just for mc. This is not a reason for drop external libraries from mc. Is you want big binary blobs of? In any case, for VZs you may use command: mount -obind /opt/VZ_environ/lib /home/some_user/vz/lib. About in-memory usage I'm already described. What about 'powerfull' What kind of power do you need from an VFS layer ? What's missing eg. in current mc's one ? WEBDAV; CURL; DeviceKit support; good realization of files/dirs change notification support etc. 'well supported', What kind of support do you need ? Good documentation for library, own bug tracking system, own devel-team. Glib (and gio) good candidate for this. No need to maintain any (builtin) libraries with mc (exclude in future libmc.so for better implementation of plugins). What kind of scalability do you need ? In which direction should a VFS API scale ? Partially yes. Own realization of ini-files parser was good realization too (was grabbed some time ago from wine project). But why we need to maintain this code? Glib have realization (desktop.org compatible): http://library.gnome.org/devel/glib/stable/glib-Key-value-file-parser.html We just was remove own ini-parser. Same case about own libpopt realization - glib have command line parser (standart for all glib-based applications) and we just use it instead of own _deprecated_ code. Why we need for own VFS layer? libgio is full of things we most likely won't ever need. How do you know this? P.S. About libmvfs: Is someone something known about this library (exclude Enrico :) )? WBR, Slavaz. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFK8T/cb3oGR6aVLpoRAvGKAJ4lXsSc/OpLBbu6YQydvxNERik4wACfUEUW BmIetDIwNcGVIwqY37Z6yCE= =o75f -END PGP SIGNATURE- ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
redefining keys
There are language issues in the section about redefining hotkeys in mc.hlp. Please find a suggested editing here below. The question marks in the last paragraph indicate that I did not understand the text. Further there is no indication in the help file that F1-F10 cannot be redefined, but I failed consistently when trying. Is this intended, is it a feature and not a bug? --- suggested editing -- Redefine hotkey bindings Hotkey bindings may be read from an external file (keymap-file) overriding the defaults. The keymap-file is determined using the following approach (with decreasing priority): 1) Command line option -K keymap or --keymap=keymap 2) Environment variable MC_KEYMAP 3) Config file parameter keymap in section [Midnight Commander] 4) File ~/.mc/mc.keymap 5) File /usr/local/etc/mc/mc.keymap 6) File /usr/local/share/mc/mc.keymap Command line option, environment variable and parameter in the config file may contain the absolute path to the keymap-file with or without the extension .keymap. Otherwise [???], the keymap-file will be looked for in (with decreasing priority): 1) ~/.mc/ 2) /usr/local/etc/mc/ 3) /usr/local/share/mc/ ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: 4.7pre4
* Slava Zanko slavaza...@gmail.com schrieb: Hi, Small systems? In this case better way to use present libraries as possible for lesser size binary file and for less memory usage per one process. Assuming they're present at all. For lots of my systems, mc is currently the *only* app requiring glib, adding 868k. If libgio will come in, this will even extend to 99% of all my systems, adding 690k. To me not. In really small systems better to use busybox without mc. Or just older versions of mc... What a great suggestion ;-o I dont want the whole gnome blobs on dozens of small devices, VZs, etc just for mc. This is not a reason for drop external libraries from mc. No, but it's a reason for not adding more fat ones including their dependencies. Is you want big binary blobs of? In any case, for VZs you may use command: mount -obind /opt/VZ_environ/lib /home/some_user/vz/lib. Assuming, that sharing is possible at all (host *and* vz nodes are all under the same administration). What kind of power do you need from an VFS layer ? What's missing eg. in current mc's one ? WEBDAV; CURL; DeviceKit A matter of proper fileservers. (plan9 folks already have ones for http, webdav, ftp, ...) support; good realization of files/dirs change notification support etc. Besides local linux (inotify), there's little chance to get it working w/o cyclic reloading. No need to maintain any (builtin) libraries with mc (exclude in future libmc.so for better implementation of plugins). Plugins ?! What kind of scalability do you need ? In which direction should a VFS API scale ? Partially yes. Own realization of ini-files parser was good realization too (was grabbed some time ago from wine project). Aehm, what does an ini parser have to do w/ a VFS API ? Why we need for own VFS layer? libgio is full of things we most likely won't ever need. How do you know this? Does MC need the streaming stuff (which is just yet another wrapper around standard filesystem operations) ? Does MC need desktop icon stuff (render them in ascii ? ;-o) Does MC need yet another socket API (besides OS/libc) ? Does MC need yet another DNS resolver ? etc, etc, etc Note: I'm talking about whats really needed for a good _console_ file manager, not what could be done if certain people have too much tedium and dont care about loosing large parts of the traditional user base ;-o 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: http://patches.metux.de/ - ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: 4.7pre4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Enrico Weigelt wrote: Small systems? In this case better way to use present libraries as possible for lesser size binary file and for less memory usage per one process. Assuming they're present at all. For lots of my systems, mc is currently the *only* app requiring glib, adding 868k. If libgio will come in, this will even extend to 99% of all my systems, adding 690k. To me not. In really small systems better to use busybox without mc. Or just older versions of mc... What a great suggestion ;-o Why not? For example: do you tried to run KDE4 under your embedded hardware? I'm sure, you never think about this :). Is KDE1 or more lightweight (and older) WM have chance to run? And what percentage of running mc greater: on end-user desktop (or on servers via ssh-connect) or in poor embedded devices? Partially yes. Own realization of ini-files parser was good realization too (was grabbed some time ago from wine project). Aehm, what does an ini parser have to do w/ a VFS API ? As example of dropped deprecated code. libgio is full of things we most likely won't ever need. How do you know this? Does MC need the streaming stuff (which is just yet another wrapper around standard filesystem operations) ? Does MC need desktop icon stuff (render them in ascii ? ;-o) Does MC need yet another socket API (besides OS/libc) ? Does MC need yet another DNS resolver ? etc, etc, etc Note: I'm talking about whats really needed for a good _console_ file manager, not what could be done if certain people have too much tedium and dont care about loosing large parts of the traditional user base ;-o I'm talking about console file manager too. But I'm talking about less codebase and as result easy to support (maintain); use all standart technology(libraries), with many opportunities for featurefull development. As example see on 'glib vs mhl' (sorry, nothing personal). A result, I want to see mc with minimal size of executable and hard dependencies to glib and s-lang(ncurses) only. All other dependencies will calculated in runtime via dlopen/dlsum. And mc will have plugins for extend basic functionality. For example, 'syntax coloring' plugin for editor. If some file is present (/usr/lib/mc/cooledit-syntaxhighlight.so) then editor have syntax highlight. Otherwise not. Same like for skins... or for filenames highlight... or for any other currently hardcoded visual effects. In this case size of main binary blob may be very small (and may be enought for placing libgio in your embedded hardware ;) ). WBR, Slavaz. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFK8YVCb3oGR6aVLpoRAsiyAJ4wZ6cS1GZuCqMLopypSRF7huiq+wCdHxv5 tEZ3DIGP9GBGLbYJvZEGKMU= =97H9 -END PGP SIGNATURE- ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: redefining keys
On Wed, 04 Nov 2009 10:05:53 + y199mp1...@gmail.com wrote: Further there is no indication in the help file that F1-F10 cannot be redefined, but I failed consistently when trying. Is this intended, is it a feature and not a bug? It's known bug. I'm currently fixing it. -- Andrew ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
