From: PCMan <pcm...@gm...> - 2011-10-18 05:01:06
|
Hi everyone on this list, I just passed my license exam yesterday. So that means I will have a little more free time from now on. I, however, still have an important presentation this week and I have to prepare for it. Since next week, I guess I'll have some time for LXDE development. It's time to fix some old bugs and adopt some patches. I'm now thinking about future development. Since dbus support is now part of glib and nowadays dbus is widely adopted, maybe it's time to replace our own hand-made IPC with dbus and make use of dbus more in LXDE. It's possible to use dbus inside menu-cache and in the session manager. PCManFM might also use it for IPC and to provide some interfaces to other applications. The second issue is the use of C++ in LXDE. Currently we mainly use C and in the future there might be vala. Doing programming in pure C is quite inefficient and error-prone on memory management sometimes. In C++, things can be better encapsulated if it's used carefully. There also exists some very high quality libraries, such as boost and some tools provided by google. Using C++ inside LXDE only introduces one additional runtime lib, libstdc++6.so. So actually I'm considering the possibility of using C++ in PCManFM. Implement some new features with C++ will be much easier than doing it with pure C. With C++, the development can be more rapid and we can utilize many nice existing libs. Later, I'll try to use C++ inside PCManFM is feasible and will do some experiments in git branches. Of course, the program should be kept as fast as old versions and memory usage cannot significantly increase. Otherwise, I won't use it. Cheers! |
From: Christoph W. <chr...@go...> - 2011-10-18 05:13:41
|
Am Dienstag, den 18.10.2011, 13:00 +0800 schrieb PCMan: > > So actually I'm considering the possibility of using C++ in PCManFM. > Implement some new features with C++ will be much easier than doing it > with pure C. > With C++, the development can be more rapid Hi, frankly speaking I think one of the things that LXDE needs most for rapid development is consistency. We cannot rewrite everything all time, we need to finish and release it at some point. This being said I'd like to strongly encourage you to not change anything but finish PCManFM 1.0 first. It is a great program and deserves a release. > and we can utilize many nice existing libs. Such as? Regards, Christoph |
From: Christoph W. <chr...@go...> - 2011-10-18 09:30:04
|
Am Dienstag, den 18.10.2011, 07:13 +0200 schrieb Christoph Wickert: > I think one of the things that LXDE needs most for > rapid development is consistency. s/consistency/continuity Regards, Christoph |
From: PCMan <pcm...@gm...> - 2011-10-18 11:22:22
|
On Tue, Oct 18, 2011 at 1:13 PM, Christoph Wickert < chr...@go...> wrote: > Am Dienstag, den 18.10.2011, 13:00 +0800 schrieb PCMan: > > > > So actually I'm considering the possibility of using C++ in PCManFM. > > Implement some new features with C++ will be much easier than doing it > > with pure C. > > With C++, the development can be more rapid > > Hi, > > frankly speaking I think one of the things that LXDE needs most for > rapid development is consistency. We cannot rewrite everything all time, > we need to finish and release it at some point. This being said I'd like > to strongly encourage you to not change anything but finish PCManFM 1.0 > first. It is a great program and deserves a release. > When developing smaller applications, the problems of C/GObject is not that apparent. However, when the scale of the whole program becomes larger and larger, it soon becomes very painful for developers to work with. For long-term development, "more productive development tools"are absolutely needed. Doing something in C/GObject may take hours, but it could be finished in minutes with C++ or others. C/GObject thing is hard to write, hard to read, hard to maintain, and hard to debug. It requires the programmers do the job of C++ compilers manually in C language. Developing with it is quite slow, time-consuming, and error-prone. It's just a pain to work with. For limited man power, a more productive development tool, if used correctly, can help a lot. I'll do some experiment with Vala first since it's totally compatible with GObject. If it works well, I'll consider using C++ since it can do things in a real OO way, and handles very low level things as well. > > > and we can utilize many nice existing libs. > Such as? > Boost, google-url, ... and all other C libs are still available as well. Besides, some code in KDE code base can be used if not bound to Qt. > > Regards, > Christoph > > > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > |
From: Robert A. <rob...@gm...> - 2011-10-20 21:36:21
|
On 18 October 2011 22:22, PCMan <pcm...@gm...> wrote: > On Tue, Oct 18, 2011 at 1:13 PM, Christoph Wickert > I'll do some experiment with Vala first since it's totally compatible with > GObject. > If it works well, I'll consider using C++ since it can do things in a real > OO way, and handles very low level things as well. Hi PCMan, Feel free to ping me on IRC if you have any questions about using Vala. I've switched most of my development over and the productivity gain has been massive. There's a few gotchas to Vala that can be frustrating (mostly due to the age of the project / bindings), but if you navigate around them it's really nice to work work. IMHO much nicer than C++... |
From: Shane K. <sh...@ti...> - 2011-10-18 12:11:25
|
PCMan, On Tue, 2011-10-18 at 13:00 +0800, PCMan wrote: > I just passed my license exam yesterday. So that means I will have a > little more free time from now on. Congratulations! > I'm now thinking about future development. > Since dbus support is now part of glib and nowadays dbus is widely > adopted, > maybe it's time to replace our own hand-made IPC with dbus and make > use of dbus more in LXDE. > It's possible to use dbus inside menu-cache and in the session > manager. > PCManFM might also use it for IPC and to provide some interfaces to > other applications. On the BIND 10 project, we also decided to switch to D-Bus after looking at a few alternatives to replace our own custom communication system. We haven't made the switch yet, so I can't say how much trouble it is. ;) http://bind10.isc.org/wiki/msgqReplacements > The second issue is the use of C++ in LXDE. Currently we mainly use C > and in the future there might be vala. > Doing programming in pure C is quite inefficient and error-prone on > memory management sometimes. > In C++, things can be better encapsulated if it's used carefully. > There also exists some very high quality libraries, such as boost and > some tools provided by google. > Using C++ inside LXDE only introduces one additional runtime lib, > libstdc++6.so. > So actually I'm considering the possibility of using C++ in PCManFM. > Implement some new features with C++ will be much easier than doing it > with pure C. > With C++, the development can be more rapid and we can utilize many > nice existing libs. > Later, I'll try to use C++ inside PCManFM is feasible and will do some > experiments in git branches. > Of course, the program should be kept as fast as old versions and > memory usage cannot significantly increase. > Otherwise, I won't use it. We also chose to use C++ when starting BIND 10, and I've been mostly pleased with the results. Performance is excellent, and the code is generally safer (smart pointers eliminate most memory or other leaks, basic data structures are already present in STL or Boost, exceptions let you handle faults at the appropriate place). The main problem with C++ is that it is very easy to go a bit crazy with all of the language. We crossed the line at one point when we had a bit of template code that only 2 people on the team could understand. So... manage your complexity carefully if you use C++! We use Boost, and have not had any real concerns at all. (We are limited to using the header-only version of Boost, due to licensing issues... our company is strictly BSD License, but we can still use almost all of Boost.) It's high-quality, very portable code. One recommendation is to also compile code with clang. The error messages are much more readable than g++, and you find a different set of problems. (Microsoft Visual Studio and Sunstudio both find different errors, but one runs only on Windows and the other only on Solaris, and neither is free.) One final advice is that we use Google Test along with lcov to do unit tests and also get code coverage reports. Any code without tests is probably wrong (and most of the code with tests too). :) -- Shane |
From: David S. <dy...@gn...> - 2011-10-18 17:11:37
|
On 10/18/2011 07:55 AM, Shane Kerr wrote: > One recommendation is to also compile code with clang. The error > messages are much more readable than g++, and you find a different set > of problems. (Microsoft Visual Studio and Sunstudio both find different > errors, but one runs only on Windows and the other only on Solaris, and > neither is free.) I believe sunstudio is actually free, as in cost. Or at least used to be available that way. But overall yes, it can be very useful to compile on different compilers, each of which may indeed find rather different and useful issues. In respect to gcc, my only issue is that it is never clear for certain warnings what the pragma might be to disable those that are actually irrelevant. |
From: Julien L. <gi...@ub...> - 2011-10-18 21:00:50
|
Le 10/18/2011 07:00 AM, PCMan a écrit : > > I'm now thinking about future development. > Since dbus support is now part of glib and nowadays dbus is widely > adopted, > maybe it's time to replace our own hand-made IPC with dbus and make > use of dbus more in LXDE. > It's possible to use dbus inside menu-cache and in the session manager. > PCManFM might also use it for IPC and to provide some interfaces to > other applications. It's IMO a must have, at least on lxsession. D-Bus is now a standard accros all desktop environment. > The second issue is the use of C++ in LXDE. Currently we mainly use C > and in the future there might be vala. > Doing programming in pure C is quite inefficient and error-prone on > memory management sometimes. > In C++, things can be better encapsulated if it's used carefully. > There also exists some very high quality libraries, such as boost and > some tools provided by google. > Using C++ inside LXDE only introduces one additional runtime lib, > libstdc++6.so. > So actually I'm considering the possibility of using C++ in PCManFM. > Implement some new features with C++ will be much easier than doing it > with pure C. > With C++, the development can be more rapid and we can utilize many > nice existing libs. > Later, I'll try to use C++ inside PCManFM is feasible and will do some > experiments in git branches. > Of course, the program should be kept as fast as old versions and > memory usage cannot significantly increase. > Otherwise, I won't use it. As Christoph said, let's finish pcmanfm first, before trying such move. Personally, I don't see many advantages to move to C++. I fear there will be more disadvantages than real gains. One rewrite (C to C++) I have in mind is compiz, and the result was not very pretty (lose of devs, not more stable, not so many new features ...). Regards, Julien Lavergne |
From: <u-l...@ae...> - 2011-10-24 07:54:28
|
Hello PCMan, On Tue, Oct 18, 2011 at 01:00:59PM +0800, PCMan wrote: > The second issue is the use of C++ in LXDE. Currently we mainly use C and in > the future there might be vala. Sorry I'm late to comment but want to name another possibility (possibly useful in the future if not now). Did you take a look at Go? I feel it addresses many of your concerns about the efficiency of both the development and of the code. It looks like it can interface with C libraries (even though not all compilers allow this yet). > Doing programming in pure C is quite inefficient and error-prone on memory > management sometimes. Agreed. > In C++, things can be better encapsulated if it's used carefully. I am not fond of C++ myself but it can be a matter of taste. > So actually I'm considering the possibility of using C++ in PCManFM. Having a dependency on C++ runtime may make use of FLTK attractive, what do you think? Thanks for your work! Regards, Rune |
From: Martin B. / b. <br...@bs...> - 2011-10-24 08:05:03
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2011-10-18 07:00, PCMan wrote: > Hi everyone on this list, I just passed my license exam yesterday. So > that means I will have a little more free time from now on. \o/ > I'm now thinking about future development. Yes. Future. Is good. > something something dbus something somehting something C++ something > vala something something using branches something I can not comment on the technology choices at all. I will not do the actual code in any case. The major parts for me is the following. 1. Use branches to test things. 2. Release often 3. Release early 4. Fix bugs 5. Try to stick to a plan We are short on man power I know and there are a very broad interest in what we do. Having plans and having development cycle that make us more interesting is in my mind important now. With releases that fixes bugs in a timely manner we draw attention and by that developers and patches. Yes it will be more geared towards reviewing patches in some cases but that is not a bad thing. As we are now with everything depending one man and his schedule the project is not very agile. - -- brother http://sis.bthstudent.se -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJOpRwjAAoJEJbdSEaj0jV7u00H/15pHKGND7TdFmFbwyWck5ww +9mPnSNpoFqyMx1V8PIo32/3NaPTrDXeGpkyH60a6sm2AcDrXQoPCzkAzDwLiWDB s+K1BlhIXDqId6YTDm4CB5Sf5RDiGaRteZTj7qzExPUr6tvMQhv8NWc3lvG1Z8Zw cy15q5s1zvwAYksKlSWOBv7081r20qdsInd+hHgwXoE4QnwhtNZccvXx2EKDzf1u GO5x71+pmf3fky/xfU2tBlE0Bm3T038ps2EhHskwUXFiXto/x7rJ16XQJZKRn+rH TlwO4xpToRJXc7VXIBgmqm8QgYb3VGQCCs9MQDvHMUExnRKS/JQjnaFBPFzA+4Q= =m2dX -----END PGP SIGNATURE----- |
From: <u-l...@ae...> - 2011-10-25 10:19:01
|
Hello Ikem, I guess you meant to post to the list, answering here. On Mon, Oct 24, 2011 at 10:30:36PM +0000, Ikem Krueger wrote: > The whole desktop is using GTk 2. > > And there's a lot of good programs using GTk 2. > > Programs using FLTK doesn't look like the rest of the system. It should be possible to at least somewhat synchronize the look (?). I am no expert in programming with different toolkits but my experience as a user and a packager suggests that FLTK and programs using it are "less bloated" that with gtk. Here are "du .../lib" for the instances of fltk and gtk i happen to have at hand: (of ~ the same age, I guess the ratio did not change radically since then) fltk 1.1.7: 1708 Kb gtk 2.12.1: 5312 Kb 5312/1708 => 3.11 I'd definitely not mind relying on FLTK applications as part of LXDE, even if it leads to some differences in theming (theming is harmful if it really enforces the use of a single toolkit for everything). I am happily running applications which are using different toolkits and it never felt like an issue, certainly not worse than restraining one's application choice to a "single toolkit environment". So even if, say, a file manager would have a different look compared to, say, a picture viewer, I'd not percieve this as a problem - rather like an eye candy which helps to distinguish between different windows on the screen. This is a matter of taste but I am probably not the only user who feels that way. Sometimes I can hate that "unified" look of windows and dialogs which belong to unrelated applications. So the differences in the appearance can be even an actual advantage, for free :) I have been under the impression that the only important hinder for a wider deployment of FLTK has been internationalization, i.e. Unicode support. Now it seems to have been implemented to a reasonable (?) degree. That's why I took this up. Note that even if FLTK comes as an added dependency/bloat _along_ with gtk, the difference is not that big. Then, as soon as there would be a useful subset of FLTK-based programs for basic needs, the footprint of such an installation would be drastically reduced. There exist for instance both a window manager, a wysiwyg text editor and a web browser using fltk, all made with a small footprint in mind. The smallest "full-featured" web browser I know of happens though to use Qt (http://www.qtweb.net/), again not gtk. (Well, may be Qt is a viable alternative to gtk, given C++?) Regards, Rune |