From: PCMan <pcm...@gm...> - 2013-03-26 02:42:13
|
Hello world, I just released PCManFM Qt file manager 0.1.0. The tarball is available for download here. http://sourceforge.net/projects/pcmanfm/files/PCManFM%20%2B%20Libfm%20%28tarball%20release%29/ You'll need libfm to build it (which is included in many distros). This release contains no thumbnail support. However a fully working thumbnail support is already in the git. Because this requires some changes to the upstream libfm library, it's scheduled for the next release and not make public at the moment. To turn on the desktop icon management feature, run with the command: > pcmanfm-qt --desktop Generally it's a good idea to add this command to your session startup script. To turn the desktop icon manager off again, do this: > pcmanfm-qt --desktop-off If you don't want to use the desktop icons, you can still add the command to your session startup script: > pcmanfm-qt --daemon In this way, it will becomes a background daemon. Every time you need to open a folder with pcmanfm-qt, it can be shown "immediately". Thank you. |
From: Jerome L. <ad...@gm...> - 2013-03-26 13:26:13
|
Thanks, this is brilliant. Some early feedback; I'm guessing you're aware of most of it: - UX for when going to a directory that doesn't exist is pretty bad; I would suggest graying out the background and either an infobar or a chrome-style error message with a button to create the directory. - "Operation is not supported" on the gvfs stuff: the icons should be hidden or grayed out if they are unusable. - My cursor gets stuck to the "Waiting..." cursor after clicking about in the left panel. - Please implement zooming in/out with ctrl mousewheel and ctrl+/- :) - Applications in Open With / Properties have no icons - There's no way to permanently delete a file without moving it to the trash (shift-del) - "Open with pcmanfm-qt" on directories makes no sense :-) - Should be able to open directories in new tabs (ctrl+dblclick / rightclick->open in new tab) - Compress menu item doesn't do anything - Any way to filter current directory? (ctrl+f foo and only the matching items stay) Very cool stuff otherwise. I love that we have quite a few solid qt file managers now :) J. Leclanche On Tue, Mar 26, 2013 at 2:42 AM, PCMan <pcm...@gm...> wrote: > Hello world, > I just released PCManFM Qt file manager 0.1.0. > The tarball is available for download here. > > > http://sourceforge.net/projects/pcmanfm/files/PCManFM%20%2B%20Libfm%20%28tarball%20release%29/ > > You'll need libfm to build it (which is included in many distros). > > This release contains no thumbnail support. > However a fully working thumbnail support is already in the git. > Because this requires some changes to the upstream libfm library, > it's scheduled for the next release and not make public at the moment. > > To turn on the desktop icon management feature, run with the command: > > pcmanfm-qt --desktop > > Generally it's a good idea to add this command to your session startup > script. > > To turn the desktop icon manager off again, do this: > > pcmanfm-qt --desktop-off > > If you don't want to use the desktop icons, you can still add the > command to your session startup script: > > pcmanfm-qt --daemon > > In this way, it will becomes a background daemon. Every time you need > to open a folder with pcmanfm-qt, it can be shown "immediately". > > Thank you. > > -- > -- > You received this message because you are subscribed to the Google > Groups "Razor-qt" group. > For more options, visit this group at > http://groups.google.com/group/razor-qt?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "Razor-qt" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to raz...@go.... > For more options, visit https://groups.google.com/groups/opt_out. > > > |
From: PICCORO M. L. <mck...@gm...> - 2013-03-26 14:41:56
|
We have a rock solid DECENT file manager.. i have only one question: > pcmanfm-qt --desktop can work with pcmanfm GTK vesion? great work, take in consideration jerome, that the developer pcman are not a programer, its a dmedician.. honor! On Tue, Mar 26, 2013 at 8:55 AM, Jerome Leclanche <ad...@gm...> wrote: > Thanks, this is brilliant. > > Some early feedback; I'm guessing you're aware of most of it: > > - UX for when going to a directory that doesn't exist is pretty bad; I > would suggest graying out the background and either an infobar or a > chrome-style error message with a button to create the directory. > - "Operation is not supported" on the gvfs stuff: the icons should be > hidden or grayed out if they are unusable. > - My cursor gets stuck to the "Waiting..." cursor after clicking about in > the left panel. > - Please implement zooming in/out with ctrl mousewheel and ctrl+/- :) > - Applications in Open With / Properties have no icons > - There's no way to permanently delete a file without moving it to the > trash (shift-del) > - "Open with pcmanfm-qt" on directories makes no sense :-) > - Should be able to open directories in new tabs (ctrl+dblclick / > rightclick->open in new tab) > - Compress menu item doesn't do anything > - Any way to filter current directory? (ctrl+f foo and only the matching > items stay) > > Very cool stuff otherwise. I love that we have quite a few solid qt file > managers now :) > > J. Leclanche > > > On Tue, Mar 26, 2013 at 2:42 AM, PCMan <pcm...@gm...> wrote: > >> Hello world, >> I just released PCManFM Qt file manager 0.1.0. >> The tarball is available for download here. >> >> >> http://sourceforge.net/projects/pcmanfm/files/PCManFM%20%2B%20Libfm%20%28tarball%20release%29/ >> >> You'll need libfm to build it (which is included in many distros). >> >> This release contains no thumbnail support. >> However a fully working thumbnail support is already in the git. >> Because this requires some changes to the upstream libfm library, >> it's scheduled for the next release and not make public at the moment. >> >> To turn on the desktop icon management feature, run with the command: >> > pcmanfm-qt --desktop >> >> Generally it's a good idea to add this command to your session startup >> script. >> >> To turn the desktop icon manager off again, do this: >> > pcmanfm-qt --desktop-off >> >> If you don't want to use the desktop icons, you can still add the >> command to your session startup script: >> > pcmanfm-qt --daemon >> >> In this way, it will becomes a background daemon. Every time you need >> to open a folder with pcmanfm-qt, it can be shown "immediately". >> >> Thank you. >> >> -- >> -- >> You received this message because you are subscribed to the Google >> Groups "Razor-qt" group. >> For more options, visit this group at >> http://groups.google.com/group/razor-qt?hl=en >> >> --- >> You received this message because you are subscribed to the Google Groups >> "Razor-qt" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to raz...@go.... >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > -- > -- > You received this message because you are subscribed to the Google > Groups "Razor-qt" group. > For more options, visit this group at > http://groups.google.com/group/razor-qt?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "Razor-qt" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to raz...@go.... > For more options, visit https://groups.google.com/groups/opt_out. > > > -- Lenz McKAY Gerardo (PICCORO) http://qglochekone.blogspot.com |
From: Andrej N. G. <an...@re...> - 2013-04-22 20:30:28
|
Hello! PCMan have written on Tuesday, 26 March, at 10:42: >Hello world, >I just released PCManFM Qt file manager 0.1.0. >The tarball is available for download here. I never looked into razor-qt before and I wasn't aware such DE even exists but now that I looked into its site I've found out some conceptual similarities with LXDE. And I've got some crazy idea. Since libfm/pcmanfm has Qt port already and LXDE as whole has too few active developers, it might be reasonable to join projects (razor-qt and LXDE), i.e. port to Qt rest of LXDE components so LXDE will be based on Qt instead of GTK and razor-qt will get few missing applications as well. It's a crazy idea, I know, and may be even silly one, I just got that thought and decided to write it out loud. :) I never did comparizon on resourses consumption between pcmanfm GTK and Qt versions though, it should be done somehow sometime. And if Qt is more lightweight than GTK then... you know. :) The only problem is that GTK is C but Qt is C++... Cheers! Andriy. |
From: Julien L. <gi...@ub...> - 2013-04-22 21:00:46
|
2013/4/22 Andrej N. Gritsenko <an...@re...>: > Hello! > > PCMan have written on Tuesday, 26 March, at 10:42: >>Hello world, >>I just released PCManFM Qt file manager 0.1.0. >>The tarball is available for download here. > > I never looked into razor-qt before and I wasn't aware such DE even > exists but now that I looked into its site I've found out some conceptual > similarities with LXDE. And I've got some crazy idea. Since libfm/pcmanfm > has Qt port already and LXDE as whole has too few active developers, it > might be reasonable to join projects (razor-qt and LXDE), i.e. port to Qt > rest of LXDE components so LXDE will be based on Qt instead of GTK and > razor-qt will get few missing applications as well. It's a crazy idea, I > know, and may be even silly one, I just got that thought and decided to > write it out loud. :) > I never did comparizon on resourses consumption between pcmanfm GTK > and Qt versions though, it should be done somehow sometime. And if Qt is > more lightweight than GTK then... you know. :) > The only problem is that GTK is C but Qt is C++... It's not a so crazy idea. I'm seriously looking at razor-qt and Qt in general for a possible future of Lubuntu. Ubuntu will use more and more Qt applications in the future, so it makes sense for us to investigate this way. Regards, Julien Lavergne |
From: PCMan <pcm...@gm...> - 2013-04-23 05:04:11
|
On Tue, Apr 23, 2013 at 4:30 AM, Andrej N. Gritsenko <an...@re...> wrote: > Hello! > > PCMan have written on Tuesday, 26 March, at 10:42: >>Hello world, >>I just released PCManFM Qt file manager 0.1.0. >>The tarball is available for download here. > > I never looked into razor-qt before and I wasn't aware such DE even > exists but now that I looked into its site I've found out some conceptual > similarities with LXDE. And I've got some crazy idea. Since libfm/pcmanfm > has Qt port already and LXDE as whole has too few active developers, it > might be reasonable to join projects (razor-qt and LXDE), i.e. port to Qt > rest of LXDE components so LXDE will be based on Qt instead of GTK and > razor-qt will get few missing applications as well. It's a crazy idea, I > know, and may be even silly one, I just got that thought and decided to > write it out loud. :) > I never did comparizon on resourses consumption between pcmanfm GTK > and Qt versions though, it should be done somehow sometime. And if Qt is > more lightweight than GTK then... you know. :) > The only problem is that GTK is C but Qt is C++... > > Cheers! > Andriy. Thank you guys very much for the proposal. It's not crazy at all. The proposal is very practical. Actually, it's also what I'm thinking about now. As the lead developer and founder of a some what famous DE, it's really hard for me to say this. Even I personally found that using Qt is much more productive and I already tested razor-qt for a while, I felt that we should not abandon our LXDE users/supporters. Politically, we belongs to the Gtk+ camp and moving toward Qt will make some supporters disappointed. Technically, porting to Qt is much easier than it looks like. It only took me 1 - 2 months to port 90% of the functionality of pcmanfm to Qt. So porting all other LXDE components to Qt is applicable and practical. I've been evaluating razor-qt for months. I followed up the project regularly and joined their mailing list. It has very similar goals with us and its development is really rapid. After months it's nearly complete now and contains even much more stuff than us. The infrastructure and library APIs are also well designed. So personally I like razor-qt very much and admire their work. Resource usage is a little more than ours, but that's understandable because it has more features. Free software is all about choice, but too many choices is not always good. Diversity is nice, but having duplicated work with the only differences in GUI toolkits is non-sense. This only creates unnecessary divergence and waste precious man power. Since we have the same goals, merging the effort is reasonable. Though the future of Qt is uncertain (will Digia sell it someday?), it still has many supporters and ubuntu is moving toward Qt. Currently, Gnome 3 seems to be the only user of gtk+3. XFCE2 is using gtk2 and they're also suffering from the painful porting. Gtk2 seems to be lighter than Qt in some cases, but it's no longer true for gtk3. Besides, it's KDE that's bloat, not Qt. Compared with gtk+, Qt contains much more than just GUI widgets. It also offers xml parsers, database supports, network stuff, and even webkit support. With gtk+, you need to install many other libraries for these but with Qt they're built-in. That explains the bigger library size. So it's not really bloat. To sum up, if our developers and users are willing to joint the effort and help razor-qt instead of mirrors what they have with gtk+, I'm not against the idea. Instead of having two incomplete DEs, at least we can have a really good one. For those who get used to gtk+, learning C++ and Qt is much easier than learning GObject. I started porting pcmanfm to Qt immediately after reading the Qt tutorial and "hello world". Maybe a vote is needed for this issue? Comments are wanted, please. |
From: Andrej N. G. <an...@re...> - 2013-04-23 10:45:04
|
Hello! PCMan has written on Tuesday, 23 April, at 13:04: >On Tue, Apr 23, 2013 at 4:30 AM, Andrej N. Gritsenko <an...@re...> wrote: >> I never looked into razor-qt before and I wasn't aware such DE even >> exists but now that I looked into its site I've found out some conceptual >> similarities with LXDE. And I've got some crazy idea. Since libfm/pcmanfm >> has Qt port already and LXDE as whole has too few active developers, it >> might be reasonable to join projects (razor-qt and LXDE), i.e. port to Qt >> rest of LXDE components so LXDE will be based on Qt instead of GTK and >> razor-qt will get few missing applications as well. It's a crazy idea, I >> know, and may be even silly one, I just got that thought and decided to >> write it out loud. :) >> I never did comparizon on resourses consumption between pcmanfm GTK >> and Qt versions though, it should be done somehow sometime. And if Qt is >> more lightweight than GTK then... you know. :) >> The only problem is that GTK is C but Qt is C++... >Thank you guys very much for the proposal. It's not crazy at all. >The proposal is very practical. Actually, it's also what I'm thinking about now. >As the lead developer and founder of a some what famous DE, it's >really hard for me to say this. Even I personally found that using Qt >is much more productive and I already tested razor-qt for a while, I >felt that we should not abandon our LXDE users/supporters. >Politically, we belongs to the Gtk+ camp and moving toward Qt will >make some supporters disappointed. Technically, porting to Qt is much >easier than it looks like. Well, that shouldn't be too big problem. I believe it shouldn't take too much efforts to support both GTK2 and Qt versions to honor GTK2 users. Why I don't talk about GTK3? Many of you know GTK3 is a lot more buggy and resourse consuming. And less of you know about another GTK3 problem: they tend to change APIs too much and too fast. For example, last night I did researches to implement some new plugin into libfm-gtk. And what I see? Let's say, class GtkVBox. In GTK 3.0 they've marked it deprecated and suggested to use newly created GtkBox. In GTK 3.2 they've created new GtkGrid class and in 3.4 they've deprecated GtkBox as well telling to use GtkGrid. What will be next? They deprecate GtkGrid in a year or too? So who knows if applications designed for GTK 3.0 can be even compiled in mere year or two without lots of workarounds and conditionals? I wouldn't be so sure. But what about Qt, BTW, is its API somewhat stable? At least I strongly want libfm to be compatible with libraries of year 2010 - it's glib 2.22 for example. The Qt was 4.5.4 at that time. Is it possible or hard to have things compatible with both Qt 4.5.4 and with latest one? >To sum up, if our developers and users are willing to joint the effort >and help razor-qt instead of mirrors what they have with gtk+, I'm not >against the idea. At least I appreciate your work on libfm/pcmanfm Qt port, it is great thing. And as soon I finish my work on libfm/pcmanfm 1.2 (there are a lot of features to implement in my TODO list, there are few bugreports in the tracker and a lot of (currently 101) tickets in FR tracker that I want to close by implementations in 1.2, at least 80% of them), I think we can do comparizon together and add all missing things into Qt port. >Instead of having two incomplete DEs, at least we can have a really good one. Exactly my thoughts. :) >For those who get used to gtk+, learning C++ and Qt is much easier >than learning GObject. I started porting pcmanfm to Qt immediately >after reading the Qt tutorial and "hello world". >Maybe a vote is needed for this issue? >Comments are wanted, please. With the best wishes. Andriy. |
From: Andrej N. G. <an...@re...> - 2013-04-24 13:55:40
|
Hello! Abdurrahman AVCI has written on Tuesday, 23 April, at 13:39: >23 Nisan 2013 Salı 10:44:52 UTC tarihinde Andriy G yazdı: >> Well, that shouldn't be too big problem. I believe it shouldn't take >> too much efforts to support both GTK2 and Qt versions to honor GTK2 users. >> Why I don't talk about GTK3? Many of you know GTK3 is a lot more buggy >> and resourse consuming. And less of you know about another GTK3 problem: >> they tend to change APIs too much and too fast. For example, last night I >> did researches to implement some new plugin into libfm-gtk. And what I >> see? Let's say, class GtkVBox. In GTK 3.0 they've marked it deprecated >> and suggested to use newly created GtkBox. In GTK 3.2 they've created new >> GtkGrid class and in 3.4 they've deprecated GtkBox as well telling to use >> GtkGrid. What will be next? They deprecate GtkGrid in a year or too? So >> who knows if applications designed for GTK 3.0 can be even compiled in >> mere year or two without lots of workarounds and conditionals? I wouldn't >> be so sure. But what about Qt, BTW, is its API somewhat stable? At least >> I strongly want libfm to be compatible with libraries of year 2010 - it's >> glib 2.22 for example. The Qt was 4.5.4 at that time. Is it possible or >> hard to have things compatible with both Qt 4.5.4 and with latest one? >Qt doesn't break API or ABI compatility within the lifetime of a major >release. >So, conceptually if you have a program that compiled with Qt 4.0 (circa >2005), >it should compile fine with Qt 4.8.4, the latest Qt4 release. Only new >stuff >added during minor releases, nothing removed or broken. >In fact Qt5 doesn't break the API much either, so you can have an >application >that compiles with Qt4 and Qt5 with minimal ifdefs. Thank you very much for clarification. That's great thing for the development and application life. >> >Instead of having two incomplete DEs, at least we can have a really good >> one. >> Exactly my thoughts. :) So what do we have now? I would like to hear from razor-qt guys what they think about the idea to merge our efforts and teams to make LXDE and razor-qt camps the one. I mean LXDE and razor-qt to be similar things but just based on different toolkits - GTK2 for LXDE and Qt for razor-qt. This way the razor guys will affect quality of GTK2 versions and lxde guys will give Qt versions of missing parts (file manager for example). As I said a bit earlier, two teams together is definitely more than just sum of two and you all know that. With the best wishes. Andriy. |
From: Alexis L. Z. <azu...@es...> - 2013-04-24 19:34:29
|
Hello everyone: I'm a student of informatics sciences in the University of Informatics Sciences of Cuba. I belong to a free software project that aims to provide to the cuban user a stable, functional and lightweight operative system. We have been working on it for a while and recently we made our 4th release. We use as desktop environment a fork of LXDE that we call "Guano" but as we are a reduced team (6 members only) the balance between productivity and time is crucial to us. In this aspect the combination of C and Gtk don't show the best numbers, so we where studding the possibility of creating our on lightweight desktop environment in order to improve the architecture of LXDE and make it more scalable, functional and integrated. But is not wise to start another project and duplicate efforts, instead of that we want to join forces with you to create a fully functional and lightweight desktop environment. We have done some research and we have some ideas and workforce that could be useful to the cause. In my opinion we must gather and plan the next step in order to make this transition quick and clean. I propose to start a new thread in both mailing lists and coordinate a live chat meeting. Waiting for your opinion -- ------------------------------------------------------------------------ University of Informatic Sciences (UCI)http://www.uci.cu Nova Light Development Team http://www.nova.cu Alexis López Zubieta azu...@es... http://www.uci.cu |
From: nomnex <no...@gm...> - 2013-04-25 05:31:18
|
> On Wed, 24 Apr 2013 15:31:56 -0400 > Alexis López Zubieta <azu...@es...> wrote: > > We use as desktop environment a fork of LXDE that we call > "Guano" I don't intend to be offending, but I you might be interested to know that that "guano" means "bird shit" in French http://fr.wikipedia.org/wiki/Guano Sorry about that :( -- nomnex <no...@gm...> Freenode: nomnex Registered Linux user #505281. Be counted at: http://linuxcounter.net |
From: Alexis L. Z. <azu...@es...> - 2013-04-25 13:37:06
|
Jajajajaja, It realy means bird shit but also is the name of a material used by cuban people in the 19 century to make the roof of their houses, it is a sort of tree palm leaf. Take a look at http://en.wikipedia.org/wiki/Coccothrinax. Nice one ----- Mensaje original ----- De: "nomnex" <no...@gm...> Para: lxd...@li... Enviados: Jueves, 25 de Abril 2013 1:31:05 Asunto: Re: [Lxde-list] PCManFM Qt 0.1.0 released. > On Wed, 24 Apr 2013 15:31:56 -0400 > Alexis López Zubieta <azu...@es...> wrote: > > We use as desktop environment a fork of LXDE that we call > "Guano" I don't intend to be offending, but I you might be interested to know that that "guano" means "bird shit" in French http://fr.wikipedia.org/wiki/Guano Sorry about that :( -- nomnex <no...@gm...> Freenode: nomnex Registered Linux user #505281. Be counted at: http://linuxcounter.net ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ Lxde-list mailing list Lxd...@li... https://lists.sourceforge.net/lists/listinfo/lxde-list http://www.uci.cu -- ... no se ve bien sino con el corazón, lo esencial es invisible a los ojos ... http://www.uci.cu |
From: John S. <mai...@ba...> - 2013-04-25 13:32:09
|
On 04/24/2013 09:31 PM, Alexis López Zubieta wrote: > Hello everyone: > > I'm a student of informatics sciences in the University of Informatics > Sciences of Cuba. I belong to a free software project that aims to > provide to the cuban user a stable, functional and lightweight operative > system. We have been working on it for a while and recently we made our > 4th release. We use as desktop environment a fork of LXDE that we call > "Guano" nice ! do you have a project page set up somewhere ? for sabotage linux, i pretty much also ended up forking lxde, however it's only a handful of bugfixes to this day. https://github.com/rofl0r/sabotage > but as we are a reduced team (6 members only) the balance > between productivity and time is crucial to us. In this aspect the > combination of C and Gtk don't show the best numbers, so we where depends on which numbers you look. when you look at memory consumption and speed, you won't get lower numbers than with C. however *GTK* is pretty bloated and depends on the horrible glib framework which inhibits robust programs: https://bugzilla.gnome.org/show_bug.cgi?id=674446 OTOH what the LXDE leaders currently have in mind is even worse: now they want to use C++ (!) and Qt (!). Qt is over 100 MB of compressed sources and takes hours to build, it's full of templates (yay duplicated code in binaries! yay debug builds which consume gigabytes of RAM to link!), OOP (dynamic allocation everywhere) and thus the next gen LXDE will turn into a giant hairball, basically the next KDE. btw, according to the wikipedia entry about razor-qt, that one already consumes more than 100MB of RAM to simply show the panel and a wallpaper... on sabotage linux i do the same with lxpanel, and mem consumption is 20MB for the entire system: http://i.imgur.com/Lz7Ov.png (early screenshot, here's a newer one: http://i.imgur.com/2k4Hvzh.png which doesnt show ram consumption tho) > studding the possibility of creating our on lightweight desktop > environment in order to improve the architecture of LXDE and make it > more scalable, functional and integrated. But is not wise to start > another project and duplicate efforts, instead of that we want to join > forces with you to create a fully functional and lightweight desktop > environment. unfortunately you won't achieve this with mainline LXDE, they're heading down the road of bloat nowadays. > > We have done some research and we have some ideas and workforce that > could be useful to the cause. In my opinion we must gather and plan the > next step in order to make this transition quick and clean. I propose to > start a new thread in both mailing lists and coordinate a live chat > meeting. if you want to chat join #sabotage @ irc.freenode.net |
From: Fernando B. <fer...@f1...> - 2013-04-25 13:21:34
|
What comes to mind is that there is no free lunch in life. If you save coding time, you pay for it with compute cycles and vice-versa. But there should be an objective way of measuring this. Since this is a very technically sophisticated group, wouldn't it make sense to have a table comparing memory usage, disk usage, and speed for a few standard setups before making a decision to switch to any other library? Fernando On 04/25/2013 09:59 AM, John Spencer wrote: > On 04/24/2013 09:31 PM, Alexis López Zubieta wrote: >> Hello everyone: >> >> I'm a student of informatics sciences in the University of Informatics >> Sciences of Cuba. I belong to a free software project that aims to >> provide to the cuban user a stable, functional and lightweight operative >> system. We have been working on it for a while and recently we made our >> 4th release. We use as desktop environment a fork of LXDE that we call >> "Guano" > > nice ! do you have a project page set up somewhere ? > for sabotage linux, i pretty much also ended up forking lxde, however > it's only a handful of bugfixes to this day. > > https://github.com/rofl0r/sabotage > >> but as we are a reduced team (6 members only) the balance >> between productivity and time is crucial to us. In this aspect the >> combination of C and Gtk don't show the best numbers, so we where > > depends on which numbers you look. when you look at memory consumption > and speed, you won't get lower numbers than with C. > > however *GTK* is pretty bloated and depends on the horrible glib > framework which inhibits robust programs: > https://bugzilla.gnome.org/show_bug.cgi?id=674446 > > OTOH what the LXDE leaders currently have in mind is even worse: > > now they want to use C++ (!) and Qt (!). > > Qt is over 100 MB of compressed sources and takes hours to build, it's > full of templates (yay duplicated code in binaries! yay debug builds > which consume gigabytes of RAM to link!), OOP (dynamic allocation > everywhere) and thus the next gen LXDE will turn into a giant hairball, > basically the next KDE. > > btw, according to the wikipedia entry about razor-qt, that one already > consumes more than 100MB of RAM to simply show the panel and a wallpaper... > on sabotage linux i do the same with lxpanel, and mem consumption is > 20MB for the entire system: http://i.imgur.com/Lz7Ov.png (early > screenshot, here's a newer one: http://i.imgur.com/2k4Hvzh.png which > doesnt show ram consumption tho) > >> studding the possibility of creating our on lightweight desktop >> environment in order to improve the architecture of LXDE and make it >> more scalable, functional and integrated. But is not wise to start >> another project and duplicate efforts, instead of that we want to join >> forces with you to create a fully functional and lightweight desktop >> environment. > > unfortunately you won't achieve this with mainline LXDE, they're heading > down the road of bloat nowadays. > >> >> We have done some research and we have some ideas and workforce that >> could be useful to the cause. In my opinion we must gather and plan the >> next step in order to make this transition quick and clean. I propose to >> start a new thread in both mailing lists and coordinate a live chat >> meeting. > > if you want to chat join #sabotage @ irc.freenode.net > > > |
From: Alexis L. Z. <azu...@es...> - 2013-04-25 15:05:33
|
----- Mensaje original ----- >> What comes to mind is that there is no free lunch in life. If you save >> coding time, you pay for it with compute cycles and vice-versa. >> But there should be an objective way of measuring this. Since this is a >> very technically sophisticated group, wouldn't it make sense to have a >> table comparing memory usage, disk usage, and speed for a few standard >> setups before making a decision to switch to any other library? >> Fernando In software projects the tools, the programing languages and the rest of the stuff are selected attending to the goals of the software. So we must start by there. What are we going to build ? A desktop enviroment, but what functionalities should have it? In order to start this i have created a small list of which functionalities that in my opinion, it should have. Please take a look at: https://github.com/azubieta/LDE/wiki/Requirements---What-the-desktop-should-provide When were agree on it we can continue to the design of the system. Best regards -- University of Informatic Sciences (UCI) http://www.uci.cu Nova Light Development Team http://www.nova.cu Alexis López Zubieta azu...@es... http://www.uci.cu |
From: Alexis L. Z. <azu...@es...> - 2013-04-25 14:53:02
|
Hello: John, we do have a web page for our project but right now its down due to some troubles with the hosting, if you want to know more about our work take a look at http://es.wikipedia.org/wiki/Nova_%28linux%29. About C++, I have to say that it support in a native form the object oriented programing what enable to have the data and the functions related to it together and also encourage the code reusage. And over all it enables to put more of the business logic into the code, (less comments are needed). Comparing C and C++ in runtime the second is just a bit (very small bit) more resource hunger wich is the cost of the metadata asociciated to C++ objects. I have done a more detailed comparison but it is in spanish, if you are interested I can translate it to english. In order to avoid that the next LXDE become a giant air ball I propose a monolithic architecture extensible through modules and use lightweight threading instead of FORK. If we do a efficient memory sharing the size of the overall system will be drastically reduced. Best regards -- University of Informatic Sciences (UCI) http://www.uci.cu Nova Light Development Team http://www.nova.cu Alexis López Zubieta azu...@es... http://www.uci.cu |
From: John S. <mai...@ba...> - 2013-04-25 15:17:52
|
On 04/25/2013 04:52 PM, Alexis Lopez Zubieta wrote: > Hello: > > John, we do have a web page for our project but right now its down due to some troubles with the hosting, > if you want to know more about our work take a look at http://es.wikipedia.org/wiki/Nova_%28linux%29. can you also share the link to the currently offline page ? i will look if its reachable in a few days. > > About C++, I have to say that it support in a native form the object oriented programing > what enable to have the data and the functions related to it together and also encourage the code reusage. 1) putting data and functions together is considered harmful http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf but it's perfectably doable in C so i don't see your point 2) that C++ encourages code reusage and C doesn't, is a propaganda lie. the reality looks quite different, C++ adds a lot of hidden dependencies that make code reusage *harder*. think about inherited classes. in order to know how to use them, i have to know all about the involved classes. when some code i'm trying to debug passes around a base class object, i can not be sure which descendant of the class was originally instatiated. this makes debugging C++ code that was written by other people very hard. > And over all it enables to put more of the business logic into the code, (less comments are needed). huh ? citation needed. > Comparing C and C++ in runtime the second is just a bit (very small bit) > more resource hunger wich is the cost of the metadata asociciated to C++ objects. there's much more than that, as soon as you use templates you get a ton of specialised functions (it is sufficient to use STL). in the end, even a dynamically linked binary that uses some form of templates will end much bigger than it's C counterpart. and bigger binary also means bigger RAM consumption since the binary has to be mapped into RAM. > I have done a more detailed comparison but it is in spanish, if you are interested I can translate it to english. sure, would be interesting to read about that. > > In order to avoid that the next LXDE become a giant air ball I propose a monolithic architecture extensible > through modules and use lightweight threading instead of FORK. now you're talking about fork(), i was refering to forking lxde (the last release that works with gtk+2). when you talk about modules, do you think about dlopen() ? P.S. next time you come to IRC, stay a bit longer please :) i am not always in front of the PC... |
From: Andrej N. G. <an...@re...> - 2013-04-25 15:49:35
|
Hello! John Spencer has written on Thursday, 25 April, at 17:17: >1) putting data and functions together is considered harmful >http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf >but it's perfectably doable in C so i don't see your point >2) that C++ encourages code reusage and C doesn't, is a propaganda lie. >the reality looks quite different, C++ adds a lot of hidden dependencies >that make code reusage *harder*. think about inherited classes. in order >to know how to use them, i have to know all about the involved classes. >when some code i'm trying to debug passes around a base class object, i >can not be sure which descendant of the class was originally >instatiated. this makes debugging C++ code that was written by other >people very hard. [.......] >in the end, even a dynamically linked binary that uses some form of >templates will end much bigger than it's C counterpart. >and bigger binary also means bigger RAM consumption since the binary has >to be mapped into RAM. [.......] >> In order to avoid that the next LXDE become a giant air ball I propose a monolithic architecture extensible > > through modules and use lightweight threading instead of FORK. >now you're talking about fork(), i was refering to forking lxde (the >last release that works with gtk+2). You should fork GTK2 itself first. Just because GTK2 will not stay forever. Its development was ended long time ago. It's why LXDE require another toolkit along with it. GTK3? Nobody has any intentions to work with that bloated, unstable, and buggy toolkit. And talking about all of problems above, they are raised a lot much more in GTK (especially GTK3) than in Qt - GTK is really built around templates and code is duplicated tens and hundreds times everywhere. So GTK3 is a way to nowhere. You may fork LXDE as much as you want. And if nobody will make any development on your fork, your system will be your personal fork and nobody else will want it. And I believe nobody will join you. The LXDE community is built around people who wants fast and light decent system and we are the community, not bunch of developers for own development, all LXDE users are the same as I am, as PCMan, as anyone else. Sure, I understand, you may be too much ambitious and you want your own system. Not a problem, just make it instead of telling that others doing that bad way. A lot of people can just talk and offend others. Only few really are doing something. dixi Andriy. |
From: Stephan S. <gma...@sp...> - 2013-04-26 06:41:38
|
On 13-04-25 11:17 AM, John Spencer wrote: >> >> About C++, I have to say that it support in a native form the object oriented programing > > what enable to have the data and the functions related to it together > and also encourage the code reusage. > > 1) putting data and functions together is considered harmful > http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf > > but it's perfectably doable in C so i don't see your point > I'm no expert, but if I understand correctly, C++ is actually BETTER for the kinds of optimizations recommended in that presentation because: 1. The compiler is more aware of what optimizations can be applied to C++ classes as opposed to the ones GObject jerry-rigs on top of C. 2. Having the class syntax as part of the language itself allows the system to grant you more power to reliably fine-tune the in-memory layout the compiler will produce. 3. Very few people are obsessive enough to spend all day finding ways to use as little GObject as possible, so "C optimizes better than C++" is irrelevant. The question is "Does C++ optimize better than GObject... and that's much more debatable." 4. MOST IMPORTANT: GTK2 has been end-of-life'd. Unless you can scrape together enough willing people to maintain it (we don't have time), the choice is between porting to Qt and porting to GTK3... and GTK3 loses hands-down for being slower, more bloated, buggier, and having developers who can't pick one API and stick with it. If you're fine with a dying GUI toolkit, why not write your apps against GTK+ 1.2.x? I remember GTK+ 2.x causing uproar for being heavier too. (But, unlike 3.x, GTK 2.x had a stable API so people got used to it) ...or heck, go even lighter. Use Motif. That's been LGPLed and lots of developers still have it installed so they can run DDD. > 2) that C++ encourages code reusage and C doesn't, is a propaganda lie. > the reality looks quite different, C++ adds a lot of hidden dependencies > that make code reusage *harder*. think about inherited classes. in order > to know how to use them, i have to know all about the involved classes. > when some code i'm trying to debug passes around a base class object, i > can not be sure which descendant of the class was originally > instatiated. this makes debugging C++ code that was written by other > people very hard. > I don't have the experience to know whether that's a correct comparison for GObject-instrumented C but my first impression is that a language which does OOP natively would produce more meaningful output in its debugging tools than a system which jerry-rigs it on top like GObject. Again, this isn't a question of whether or not we're doing object-oriented stuff. GTK+ and Qt are both object-oriented and, at the language level, it's a choice between staying with a jerry-rigged hack or moving to a language which promotes OOP to a core language feature that a respect-worthy debugging tool must support without confusion. (Plus, there's the Qt Creator IDE which goes a step further and extends the underlying debugging to make things like QString as easy to work with as native language types like int and float.) Also, keep in mind that, back before a move to Qt was contemplated, Vala was being increasingly used as a way to get the speed of C but a more comfortable syntax and more automatic compile-time checks. Vala is a whole other language which compiles into C+GObject (If you have web programming experience, think CoffeeScript.) and I've yet to hear of a debugger which can do any kind of reverse-translation. Even without Qt Creator, C++ is often a lot easier to debug than Vala programs since the compiler knows how to reference back to the source you were actually writing rather than C files generated from it. |
From: Infodomestic <inf...@gm...> - 2013-05-02 16:56:35
|
On Thu, May 2, 2013 at 5:47 PM, JM <me...@gm...> wrote: > On Thu, 2 May 2013 17:26:59 +0200 > Infodomestic <inf...@gm...> wrote: > > > I'm running #! into a 700 Mhz CPU with 512 MB of RAM and it takes only > 80MB > > of RAM footprint. > > It runs OpenBox, Tint2, Conky, NetworkManager and no deskto icon manager > > (PCManFM takes a little bit more but it's ok) > > > > So as you can see the problem it's not the DE... > > > > The 512MB will be saturated when you start Firefox and use it with 10 > tabs > > open with HTML5 multimedia objects running on it...that's it > > > > At the moment we need a decent and modern replacement for iDesk (very > > specific and light to do one think done well...let users click on an icon > > and trigger an action on it) from this point of view...PCManFM it's > > bloatware... > > > > If you think in terms of pure C (i.e: fltk) you can sleep relaxed because > > Enlightenment it's here at our disposal and is programmed with the > embedded > > world inside. > > > > So we need only a release of PCManFM specific to draw icons on desktop > and > > manage a little of animations like you can do in an iPhone/Android Home > > screen...the rest is out there (windows managers, panels, icon trayers, > > players, ....) > > > > cheers, > > > > Luca > > > Hi Luca, > > I don't want to say it in a bad way, but talk for yourself. I don't want > any other file > manager than PCManFM. I like it very much, it is handy and light. I don't > use it to > manage desktop icons and background because I just use feh to display a > background and > no icons on the desktop. > I agree with you I use only PCManFM as file manager and I like it But browsing for files is a specific works that it's best suited by a file browser/manager and PCManFM works like I expect... I'm speaking about a specific fork of PCManFM that only compete with iDesk in terms of pure desktop icon drawer/user interaction. Like you I love and promote PCManFM as file browser but at the moment I use iDesk when I need a very light desktop icon drawer (I don't use so much a file manager because I work with files using LxTerminal...mv cp touch and rm fits very well into my daily working process) To return in topic...the problem remains...LXDE already fit well into low resource systems, the rest it's up to the applications that tends to weight too much thanks for you response, regards, Luca |
From: Andrej N. G. <an...@re...> - 2013-05-02 19:13:07
|
Hello! Infodomestic has written on Thursday, 2 May, at 18:55: >Like you I love and promote PCManFM as file browser but at the moment I use >iDesk when I need a very light desktop icon drawer (I don't use so much a >file manager because I work with files using LxTerminal...mv cp touch and >rm fits very well into my daily working process) On 32-bit system PCManFM running as pure desktop manager takes less than 12 MB of memory. At least I use it in that role and I even have 8 different wallpapers for each workspace and it uses 11052 kB of RSS (and 8896 kB of shared) memory right now. Is it too much? >To return in topic...the problem remains...LXDE already fit well into low >resource systems, the rest it's up to the applications that tends to weight >too much Exactly what happens, yes. To be exact, on my system right now the most memory eager processes of my desktop are: 1) Firefox (browser, 16 tabs opened) - 385 MB; 2) Chromium (browser, single tab) - 158 MB; 3) mutt (mail client) - 25 MB; 4) deluged (bittorrent client) - 17 MB; 5) konsole (KDE3 version terminal emulator) - 16 MB each; 6) kmix (KDE3 version tray volume/mixer applet) - 13 MB; 7) lxpanel - 13 MB; 8) pcmanfm - 11 MB; 9) clipit (clipboard manager tray applet) - 10 MB; 10) openbox - 9.5 MB. As you can see, DE parts are not on the very top and take not so much. :) With best wishes. Andriy. |
From: gary s. <rh...@gm...> - 2013-04-23 06:13:11
|
I have to admit, this sounds very good. On Mon, Apr 22, 2013 at 10:04 PM, PCMan <pcm...@gm...> wrote: > On Tue, Apr 23, 2013 at 4:30 AM, Andrej N. Gritsenko <an...@re...> > wrote: > > Hello! > > > > PCMan have written on Tuesday, 26 March, at 10:42: > >>Hello world, > >>I just released PCManFM Qt file manager 0.1.0. > >>The tarball is available for download here. > > > > I never looked into razor-qt before and I wasn't aware such DE even > > exists but now that I looked into its site I've found out some conceptual > > similarities with LXDE. And I've got some crazy idea. Since libfm/pcmanfm > > has Qt port already and LXDE as whole has too few active developers, it > > might be reasonable to join projects (razor-qt and LXDE), i.e. port to Qt > > rest of LXDE components so LXDE will be based on Qt instead of GTK and > > razor-qt will get few missing applications as well. It's a crazy idea, I > > know, and may be even silly one, I just got that thought and decided to > > write it out loud. :) > > I never did comparizon on resourses consumption between pcmanfm GTK > > and Qt versions though, it should be done somehow sometime. And if Qt is > > more lightweight than GTK then... you know. :) > > The only problem is that GTK is C but Qt is C++... > > > > Cheers! > > Andriy. > > Thank you guys very much for the proposal. It's not crazy at all. > The proposal is very practical. Actually, it's also what I'm thinking > about now. > As the lead developer and founder of a some what famous DE, it's > really hard for me to say this. Even I personally found that using Qt > is much more productive and I already tested razor-qt for a while, I > felt that we should not abandon our LXDE users/supporters. > Politically, we belongs to the Gtk+ camp and moving toward Qt will > make some supporters disappointed. Technically, porting to Qt is much > easier than it looks like. > It only took me 1 - 2 months to port 90% of the functionality of pcmanfm > to Qt. > So porting all other LXDE components to Qt is applicable and practical. > I've been evaluating razor-qt for months. I followed up the project > regularly and joined their mailing list. It has very similar goals > with us and its development is really rapid. > After months it's nearly complete now and contains even much more stuff > than us. > The infrastructure and library APIs are also well designed. > So personally I like razor-qt very much and admire their work. > Resource usage is a little more than ours, but that's understandable > because it has more features. > Free software is all about choice, but too many choices is not always good. > Diversity is nice, but having duplicated work with the only > differences in GUI toolkits is non-sense. This only creates > unnecessary divergence and waste precious man power. > Since we have the same goals, merging the effort is reasonable. > Though the future of Qt is uncertain (will Digia sell it someday?), it > still has many supporters and ubuntu is moving toward Qt. Currently, > Gnome 3 seems to be the only user of gtk+3. XFCE2 is using gtk2 and > they're also suffering from the painful porting. > Gtk2 seems to be lighter than Qt in some cases, but it's no longer > true for gtk3. > Besides, it's KDE that's bloat, not Qt. Compared with gtk+, Qt > contains much more than just GUI widgets. It also offers xml parsers, > database supports, network stuff, and even webkit support. With gtk+, > you need to install many other libraries for these but with Qt they're > built-in. That explains the bigger library size. So it's not really > bloat. > > To sum up, if our developers and users are willing to joint the effort > and help razor-qt instead of mirrors what they have with gtk+, I'm not > against the idea. > Instead of having two incomplete DEs, at least we can have a really good > one. > For those who get used to gtk+, learning C++ and Qt is much easier > than learning GObject. I started porting pcmanfm to Qt immediately > after reading the Qt tutorial and "hello world". > Maybe a vote is needed for this issue? > Comments are wanted, please. > > -- > -- > You received this message because you are subscribed to the Google > Groups "Razor-qt" group. > For more options, visit this group at > http://groups.google.com/group/razor-qt?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "Razor-qt" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to raz...@go.... > For more options, visit https://groups.google.com/groups/opt_out. > > > |
From: PCMan <pcm...@gm...> - 2013-04-23 05:14:50
|
On Tue, Apr 23, 2013 at 10:49 AM, Stephan Sokolow <gma...@sp...> wrote: > My main problem with the idea is that the vast majority of apps I use > are GTK+ ones with no acceptable Qt alternatives and I worry that a move > to Qt would jeopardize the ready availability of a less GNOME3-ish GTK+ > theme for most of the apps on my Lubuntu desktop. > > (Nothing matches Audacious for a compact chiptune-playing GUI, nothing > matches Geeqie for a responsive image viewer, The default (GTK+) Firefox > theme is the only one that is reliably compatible with the Aurora > channel, etc.) Audacious is really perfect. However, it's core library is tight with Gtk+, so porting to Qt is quite difficult. I studied this earlier and had the conclusion. Fortunately, there are several nice Qt music players. Qmmp if you like WinAmp UI. Clementine is also a nice one. If you prefer xmms2, there exists some Qt UI frontends for it which are lightweight. > QGtkStyle is an officially-supported part of Qt, so I can effortlessly > mix Qt apps into my primarily GTK+ desktop and force GNOME/OSX > "Cancel/OK" button order on them. (It's not just taste. It's superior > and I've got a link I can share to explain why.) > gtk-engines-qt has been bitrotting for years and native Qt themes tend > to force Windows/KDE-style "OK/Cancel" button order with no option to > change that. If we decided to move toward Qt/razor-qt, we need to devoted some time to fix this part. That engine is developed by KDE guys. As we have much experience with gtk+ and its internal, I think we can help fix this part after learning more Qt stuff. Removing KDE dependency and making it Qt only is possible. I'm quite confident. > On the plus side, at least the native Qt file dialogs have "Rename" and > "Delete" in the context menu, unlike the GTK+ ones. (but I can't > remember whether it was Qt4 or just the DolphinPart and the KDE 4 file > dialogs that play badly with my high-resolution mouse compared to Qt 3.) The Qt file dialogs are replaced by KDE if you're running KDE. Qt is extensible via plugins and it allowed overriding the file dialogs with your own plugins. If you want, we can even provide a file dialog with PCManFM. (Of course, someone needs to spend the time for it since it's not a trivial task) > (And I do already have a fair few Qt apps. KRename, Filelight since > Baobab's radial view is a lazy afterthought, K3b since others are too > crash-happy or too spartan, Okular since Lubuntu's Evince doesn't do CHM > or offer bitmap/screenshot select-to-clipboard for PDF, GoldenDict, LyX, > and Skype, for example.) There exists many nice independent Qt applications. What they need is polishing, advertising, and grouped together. Just like what we did with LXDE, we can group some nice independent Qt apps as well. As the founder of the project, emotionally I'm a little bit reluctant to replace our work with others'. However, from the perspective of the whole free software community, merging the effort rather than divergence brings much more benefit to the world. So I support the change. :-) > On 13-04-22 05:00 PM, Julien Lavergne wrote: >> 2013/4/22 Andrej N. Gritsenko <an...@re...>: >>> Hello! >>> >>> PCMan have written on Tuesday, 26 March, at 10:42: >>>> Hello world, >>>> I just released PCManFM Qt file manager 0.1.0. >>>> The tarball is available for download here. >>> >>> I never looked into razor-qt before and I wasn't aware such DE even >>> exists but now that I looked into its site I've found out some conceptual >>> similarities with LXDE. And I've got some crazy idea. Since libfm/pcmanfm >>> has Qt port already and LXDE as whole has too few active developers, it >>> might be reasonable to join projects (razor-qt and LXDE), i.e. port to Qt >>> rest of LXDE components so LXDE will be based on Qt instead of GTK and >>> razor-qt will get few missing applications as well. It's a crazy idea, I >>> know, and may be even silly one, I just got that thought and decided to >>> write it out loud. :) >>> I never did comparizon on resourses consumption between pcmanfm GTK >>> and Qt versions though, it should be done somehow sometime. And if Qt is >>> more lightweight than GTK then... you know. :) >>> The only problem is that GTK is C but Qt is C++... >> >> It's not a so crazy idea. I'm seriously looking at razor-qt and Qt in >> general for a possible future of Lubuntu. Ubuntu will use more and >> more Qt applications in the future, so it makes sense for us to >> investigate this way. >> >> Regards, >> Julien Lavergne >> >> ------------------------------------------------------------------------------ >> Precog is a next-generation analytics platform capable of advanced >> analytics on semi-structured data. The platform includes APIs for building >> apps and a phenomenal toolset for data science. Developers can use >> our toolset for easy data analysis & visualization. Get a free account! >> http://www2.precog.com/precogplatform/slashdotnewsletter >> > > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > Pcmanfm-develop mailing list > Pcm...@li... > https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop |
From: Stephan S. <gma...@sp...> - 2013-04-23 06:25:12
|
I have one question in the role of a developer. As someone who's used Qt in C++ recently (as opposed to via PyQt back before PySide was even proposed) and used it for more than the big brother of a Hello World app, how would you say the current offerings (C++ API, Qt Quick, etc.) compare to Vala (which I've actually used) for writing something reasonably memory-safe using native widgets? ...because, if I can ever spare the time, whether I contribute something suitable for inclusion will depend on how much more painful it is to work with Qt than with Vala, PyGTK, or PyQt/PySide. (And KDE has shown all too well that Qt applications written in C++ can crash readily and frequently) Also, any tips you'd be willing to write up on how to port C-based GTK+ applications to Qt would be welcome. I'm always up for learning new things but I have time to learn them through trial and error far less often than I'd like. On 13-04-23 01:04 AM, PCMan wrote: > > To sum up, if our developers and users are willing to joint the effort > and help razor-qt instead of mirrors what they have with gtk+, I'm not > against the idea. > Instead of having two incomplete DEs, at least we can have a really good one. > For those who get used to gtk+, learning C++ and Qt is much easier > than learning GObject. I started porting pcmanfm to Qt immediately > after reading the Qt tutorial and "hello world". > Maybe a vote is needed for this issue? > Comments are wanted, please. > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr > |
From: Fernando B. <fer...@f1...> - 2013-04-23 11:31:52
|
My own two cents would be to please consider the accessibility for use by the blind of these new libraries, in addition to resource utilization. Currently LXDE is fairly accessible, and this opens up the possibility of a lot of use among the blind in developing countries. Fernando On 04/23/2013 03:21 AM, Stephan Sokolow wrote: > I have one question in the role of a developer. > > As someone who's used Qt in C++ recently (as opposed to via PyQt back > before PySide was even proposed) and used it for more than the big > brother of a Hello World app, how would you say the current offerings > (C++ API, Qt Quick, etc.) compare to Vala (which I've actually used) for > writing something reasonably memory-safe using native widgets? > > ...because, if I can ever spare the time, whether I contribute something > suitable for inclusion will depend on how much more painful it is to > work with Qt than with Vala, PyGTK, or PyQt/PySide. (And KDE has shown > all too well that Qt applications written in C++ can crash readily and > frequently) > > Also, any tips you'd be willing to write up on how to port C-based GTK+ > applications to Qt would be welcome. I'm always up for learning new > things but I have time to learn them through trial and error far less > often than I'd like. > > On 13-04-23 01:04 AM, PCMan wrote: >> >> To sum up, if our developers and users are willing to joint the effort >> and help razor-qt instead of mirrors what they have with gtk+, I'm not >> against the idea. >> Instead of having two incomplete DEs, at least we can have a really good one. >> For those who get used to gtk+, learning C++ and Qt is much easier >> than learning GObject. I started porting pcmanfm to Qt immediately >> after reading the Qt tutorial and "hello world". >> Maybe a vote is needed for this issue? >> Comments are wanted, please. >> >> ------------------------------------------------------------------------------ >> Try New Relic Now & We'll Send You this Cool Shirt >> New Relic is the only SaaS-based application performance monitoring service >> that delivers powerful full stack analytics. Optimize and monitor your >> browser, app, & servers with just a few lines of code. Try New Relic >> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr >> > > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > > |
From: Andrej N. G. <an...@re...> - 2013-04-24 20:56:24
|
Hello! Stephan Sokolow has written on Tuesday, 23 April, at 2:21: >I have one question in the role of a developer. >As someone who's used Qt in C++ recently (as opposed to via PyQt back >before PySide was even proposed) and used it for more than the big >brother of a Hello World app, how would you say the current offerings >(C++ API, Qt Quick, etc.) compare to Vala (which I've actually used) for >writing something reasonably memory-safe using native widgets? >...because, if I can ever spare the time, whether I contribute something >suitable for inclusion will depend on how much more painful it is to >work with Qt than with Vala, PyGTK, or PyQt/PySide. (And KDE has shown >all too well that Qt applications written in C++ can crash readily and >frequently) I hope PCMan will answer this shortly. But what I heard from him is Qt is a lot better in both API stability and variability. And in regard of debugging - C++ isn't syntetic language but Vala is therefore should be a much easier to debug C++ applications than Vala (Vala is just a hell to debug). But I have almost zero experience with C++ and Qt so cannot tell you much. >Also, any tips you'd be willing to write up on how to port C-based GTK+ >applications to Qt would be welcome. I'm always up for learning new >things but I have time to learn them through trial and error far less >often than I'd like. Porting GTK+ applications to Qt shouldn't be too much hard but it will require at least two things: 1) if the application has own GTK classes those API interface should be completely rewritten because in C++ classes have public and private methods but in GTK each method is just a separate API (because it's C after all); 2) all calls to GTK APIs should be replaced with appropriate Qt calls, also every GTK object should be replaced with appropriate Qt object. I don't know yet if some list of appropriations ever exists. There may be some problems with the transition in case if Qt object has no method appropriate to some method for similar GTK object. But also opposite is right - some GTK parts may be simplified in transition if Qt object has convenient method which is absent in GTK. You're not the one who will need to learn it. But it seems we have no other choice because GTK3 is a way to nowhere and we decided to not try to support it because it require too big efforts without any benefits. Qt seems to be a lot better alternative due to much more stable API. With best regards. Andriy. |