Re: 4.7pre4
* Slava Zanko slavaza...@gmail.com schrieb: Hi, 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? I never ever considered KDE1 for embedded systems, always had been far too fat for that. But MC once was well suited for them. And what percentage of running mc greater: on end-user desktop (or on servers via ssh-connect) or in poor embedded devices? Actually, I know a lot of people using mc on small memory systems (from routers or controlling devices to VZs). Do you really want to piss off that userbase ? 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. What do you maintain on long approved code ? 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. Plugins are a great way for making applications unreliable. Gratulations! 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. Why not just as a build-time flag ? 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: 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
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: 4.7pre4
Enrico Weigelt wrote: * SZABÓ Gergely s...@subogero.com schrieb: Actually mc implements a lot of CUA standards, but you seem to forget about the Norton/Total/Far traditions. I think it's equally (or more) important to conform to those traditions. Anybody who ever used a two-pane file-manager knows by heart what the keys F1 to F10 mean. And they all expect to be able to edit the command line without any further complications. ACK. These keybindings should not change (at least not in the default installation). We could distribute multiple keybinding files aside of the default one - one in which MC will mimick Total commander keyboard shortcuts as close as possible, one mimicking FAR manager as close as possible, perhaps some other if someone will send us something reasonable :) Currently we have only the default and emacs keymap. Martin Petricek ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: 4.7pre4
* MP t...@centrum.cz schrieb: We could distribute multiple keybinding files aside of the default one -one in which MC will mimick Total commander keyboard shortcuts as close aspossible, one mimicking FAR manager as close as possible, perhaps someother if someone will send us something reasonable :) ACK. But we also should have the traditional one built-in as a compile-time option (for small systems). 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
4.7pre4
Hello Russian Team, Please make sure you call your init/config files in a different way from 4.6.1 or put them in a different directory. Right now your are modifying 'ini' without considering that users may want to leave the old 4.6.1 install intact. Further, it seems to me that you are playing around with effects (skins) and wasting time. You have no chance in hell to get agreement from the (still) official maintainers and from the distros maintainers on such visual aspects. Forget it. You want to innovate? Here are two suggestions: - A set of keybindings in the CUA tradition. Why is F8 used rather than Delete? If the reason is the (displayed) command line, the solution is that keypresses only reach the command line *after* a switch key (assume F8) is pressed. So Delete does delete and if you want to type on the command line you press the switch key first. This would also help with Backspace and others. - Tree view. I do not know what the original authors of mc's tree view were thinking but that was mid-90s. Currently, the tree view is fairly standardized. You need a command to expand the tree one level (e.g. Right) or to expand it all levels (e.g. *) and to collapse it (e.g. Left). And yes, first admit unreservedly that the tree view is not just useful, it is indispensable. Regards frank ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: 4.7pre4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 02.11.2009 19:23, y199mp1...@gmail.com wrote: Hello Russian Team, This is not right: Russian team was transform into international devel-team. Please make sure you call your init/config files in a different way from 4.6.1 or put them in a different directory. Is you mean moving mc.wrapper.csh|sh from /usr/share/mc into /usr/libexec/mc ? Right now your are modifying 'ini' without considering that users may want to leave the old 4.6.1 install intact. MC reads old configs as well (as possible) and transforms into new format. If this not right: create new ticket, please. Further, it seems to me that you are playing around with effects (skins) and wasting time. You have no chance in hell to get agreement from the (still) official maintainers and from the distros maintainers on such visual aspects. Forget it. Well... someone have profit at this point, someone annoying by visual effects... Skins (and filehighlight) was very easy for implement. Much harder(and much important) for implement was 'keymaps' technology - it's an 'invisible' work for end user (like iceberg) and at present time this technology incomplete. You want to innovate? Here are two suggestions: We have lot of new ideas about mc (such as config dialog like 'about:config' from Firefox/Seamonkey). But we don't have time to realize all ideas :(. In any case, patches always welcome. ;) - A set of keybindings in the CUA tradition. Why is F8 used rather than Delete? If the reason is the (displayed) command line, the solution is that keypresses only reach the command line *after* a switch key (assume F8) is pressed. So Delete does delete and if you want to type on the command line you press the switch key first. This would also help with Backspace and others. Now implemented user-side keybinds. If something don't work - create ticket, please. - Tree view. I do not know what the original authors of mc's tree view were thinking but that was mid-90s. Currently, the tree view is fairly standardized. You need a command to expand the tree one level (e.g. Right) or to expand it all levels (e.g. *) and to collapse it (e.g. Left). And yes, first admit unreservedly that the tree view is not just useful, it is indispensable. I think, implement these keybinds not hard... but this task not for 4.7.0 milestone. WBR, Slavaz. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkrvLawACgkQb3oGR6aVLpqzpgCfUJBnqa48fVltSa8WAZV4zteo fcAAn3SuEQwunqJ02H8zCBKFW6k5NQaO =dHx7 -END PGP SIGNATURE- ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: 4.7pre4
On Mon, 2009-11-02 at 21:06 +0200, Slava Zanko wrote: Please make sure you call your init/config files in a different way from 4.6.1 or put them in a different directory. Is you mean moving mc.wrapper.csh|sh from /usr/share/mc into /usr/libexec/mc ? I think that he wants us to pick another directory for configuration files like .mc-new, but even in this case I can't really follow his logic. Why wouldn't you ask Firefox developers to use something else instead of just .firefox every new version, because you MIGHT be interested in running Firefox 2 and Firefox 3 at the same time? -- Sincerely yours, Yury V. Zaytsev ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: 4.7pre4
y199mp1...@gmail.com wrote: Hello Russian Team, Please make sure you call your init/config files in a different way from 4.6.1 or put them in a different directory. Right now your are modifying 'ini' without considering that users may want to leave the old 4.6.1 install intact. Further, it seems to me that you are playing around with effects (skins) and wasting time. You have no chance in hell to get agreement from the (still) official maintainers and from the distros maintainers on such visual aspects. Forget it. You want to innovate? Here are two suggestions: - A set of keybindings in the CUA tradition. Why is F8 used rather than Delete? If the reason is the (displayed) command line, the solution is that keypresses only reach the command line *after* a switch key (assume F8) is pressed. So Delete does delete and if you want to type on the command line you press the switch key first. This would also help with Backspace and others. - Tree view. I do not know what the original authors of mc's tree view were thinking but that was mid-90s. Currently, the tree view is fairly standardized. You need a command to expand the tree one level (e.g. Right) or to expand it all levels (e.g. *) and to collapse it (e.g. Left). And yes, first admit unreservedly that the tree view is not just useful, it is indispensable. Regards frank ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel Frank, I think the name 4.7 pre4 suggests it's a beta version. Backing up ini files before starting to use it may be a good idea. Skins may be wasting time, but editing the ini file manually in the 4.6 way to give mc a better appearance is an even bigger waste of time. Actually mc implements a lot of CUA standards, but you seem to forget about the Norton/Total/Far traditions. I think it's equally (or more) important to conform to those traditions. Anybody who ever used a two-pane file-manager knows by heart what the keys F1 to F10 mean. And they all expect to be able to edit the command line without any further complications. Best regards Gergely ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Re: 4.7pre4
* Yury V. Zaytsev y...@shurup.com schrieb: I think that he wants us to pick another directory for configuration files like .mc-new, but even in this case I can't really follow his logic. ./configure --help ;-P 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
* SZABÓ Gergely s...@subogero.com schrieb: Actually mc implements a lot of CUA standards, but you seem to forget about the Norton/Total/Far traditions. I think it's equally (or more) important to conform to those traditions. Anybody who ever used a two-pane file-manager knows by heart what the keys F1 to F10 mean. And they all expect to be able to edit the command line without any further complications. ACK. These keybindings should not change (at least not in the default installation). 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
