Re: duplicate definition of fast_reload
* Andrew Borodin aboro...@vmail.ru schrieb: On Wed, 28 Oct 2009 20:14:17 +0100 Enrico Weigelt wrote: just seen that the variable fast_reload is defined twice (once in main.c, once in screen.c), I cannot find that in main.c. fast_reload variable is declared as extern in panel.h and defined in screen.c only. Forget it, I fragged up my own code and just got confused ;-o sorry for the noise ... 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: building 4.6.2 with glib1
* Slava Zanko slavaza...@gmail.com schrieb: Hi, Enrico, 'been driven out of the team' is an incorrect words. At present time you have write access on git in m-c.o: I didnt talk about git/trac access, but the social climate in the dev-team, which - to me - wasnt a real team anymore. You know that it wasn't the glib issue, but was just the ignition spark. But I don't want to cook up those old silly stories - I'm just interested in technical advance, even if it requires maintaining my own fork. If you absolutely don't like glib - please, propose FULLY-replace library. That's just the start of the mess: one fat library for all. I'm currently in process of replacing glib stuff step by step, first things that can be done more efficiently and then those where other - specific and small - libs existing. The rule is _NOT_ kick off glib by any means (as opposite to the use glib by any means-doctrine), but carefully refactoring step by step. Not library with young age and/or poor-featured - need stable and fully-functional library. You want to support own library code? You want a stable library ? Then glib is not the right thing to look for. In my daily job (dev as well as operating), glib is one of the bigges troublemakers, especially incompatibe API changes within minor release - it really makes fun loosing important apps (like mc) on a production system just due an glib update. Glib may be smallest. For this, need to tuning glib (via glib bugzilla's feature request etc). Glib API is too big. It would require a complete refactoring, it had to be split into lots of smaller libs, ending up in an very different API. My experciences on glib-dev showed up that there's absolutely no interest in that there. MC just use convenient and 'soft' library. Yes, but with the inconvenience of loosing mc on several platforms. Many current features and thinks will impossible or will much harder to realize without glib. Isn't it? Which ones exactly ? 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: Lots of breaks on -Werror
* Stan. S. Krupoderov pashel...@mail.ru schrieb: Feel free to create ticket and provide branch to review. See #1774 :) 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: [PATCH] do not abort on broken .cpio file
On Thursday 15 October 2009 16:21, Denys Vlasenko wrote: For some reason, mc aborts if .cpio magic as wrong. This trivial patch makes mc handle it gracefully. Please apply. This is now fixed, thanks! I am a bit surprised that for such a trivial fix, you guys went to the trouble of creating a bug: http://www.midnight-commander.org/ticket/1725 and went through 7 changes in that bug. This wastes your time. Maybe it makes sense to allow trivial fixes to be applied without going through this process? Just a sugeestion, feel free to disregard. -- vda ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
Home / End in viewer does not work in recent git
Hi, I built mc from recent git. Today I noticed that Home / End key in the viewer do not jump to the beginning / end of the viewed file. They work in other places, so it does not seem to be a problem with interpreting keycodes. My git-fu is weak, I don't know how to identify when exactly I did last git pull. git log shows this: commit ae3a0a85f7d3ae36d3beab75743e9ec7c3a3 Merge: c96af78 f3f975e Author: Denys Vlasenko vda.li...@googlemail.com Date: Mon Oct 26 01:01:25 2009 +0100 Merge branch 'master' of git://midnight-commander.org/git/mc commit f3f975ec16af8f702f5b3e0697cb87e806249018 Merge: 20cd37d acd0ed0 Author: Ilia Maslakov il.sm...@gmail.com Date: Sat Oct 24 15:24:47 2009 + Merge branch '1627_widechar_in_viewer' * 1627_widechar_in_viewer: fixed drawing zerowidth characters * Added g_unichar_iszerowidth() and g_file_set_contents() functions for Ticket #1627 commit acd0ed038db194f60423e7f1b0c5869086b31e22 Author: Ilia Maslakov il.sm...@gmail.com Date: Sat Oct 24 13:32:33 2009 + fixed drawing zerowidth characters Signed-off-by: Ilia Maslakov il.sm...@gmail.com ... ... -- vda ___ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel
