From: PCMan <pcm...@gm...> - 2013-03-26 02:42:14
|
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: 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:47
|
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: Stephan S. <gma...@sp...> - 2013-04-23 02:50:18
|
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.) 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. 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.) (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.) 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 > |
From: PCMan <pcm...@gm...> - 2013-04-23 05:04:12
|
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:03
|
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: 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:19:24
|
On 13-04-23 01:14 AM, PCMan wrote: > > 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. Unfortunately, I've already looked and been unable to find anything else with the wide format and feature support I require. Even ignoring features, I use almost every format plugin available for Audacious AND I also use something (UADE) that should have been an Audacious plugin but the developers are jerks. (They promised to break the UADE API if the Audacious developers merged the plugin into Audacious and the Audacious developers, like the Linux kernel developers, weren't willing to hold up API improvements for external modules.) I know most things support AAC, AC3, FLAC, ModPlug, MP3, Ogg Vorbis, libsidplay, WavPack, AVI/FLV/MP4/WebM/mov/Real audio demuxing and playback via ffmpeg and I THINK there's a GStreamer plugin for libsndfile (.wav, .snd, .au, .voc). However, I have yet to find anything that also does AdPlug, MIDI through an external synthesizer, Game_Music_Emu (GBS, GYM, NSF/NSFE, and SPC at minimum), PSF, and PSF2. (And those are just the formats/libraries I'm using right now. I may decide to start also playing other types of console chiptune rips like HSF or VGM tomorrow.) ...not to mention, most of them accomplish the more esoteric stuff through plugins in the gst-plugins-bad/ugly bundles. If I could, I'd LOVE to be running something more versatile like XMMS2 or MPD which can separate the core from the GUI and support streaming more readily. > >> 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) I'm fine with the Qt file dialogs. Aside from a crash which I know is specific to my system, they seem to be better than the GTK+ ones in every way I care about. (I know the crash is on my end because, it causes them to crash in response to ANY click, right or left, in any Qt-based application) Yeah, sure, it is a little weird to not have / be the root of the virtual file system, but that's fine. My only complaints with the KDE 4 file dialogs is that they add unnecessary animations and extra widget clutter to the perfection that was the KDE 3 versions, interpret shaky-handed clicks on high-resolution mice as click-drags more readily than KDE 3 or GTK+, and don't let me lock the icons in the places sidebar at 16x16px. (Which means the icons change size and, therefore, throw off my muscle memory for row height, depending on the length of the volume labels of currently-available removable media.) > >> (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. For example, GoldenDict and LyX. The only major KDE applications I really need are K3b, Tellico, and KDiff3... though I do like Okular much more than ChmSee or xchm for reading CHM files. > > 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. :-) > I perfectly agree with the sentiment. One of my many "if I can ever find the time" projects is to investigate the "rarfile" Python module as a possible successor to my rar.py. (A partially-finished module for listing files in rar archives without depending on the rar/unrar binaries or linking against a GPL-incompatible library.) |
From: Stephan S. <gma...@sp...> - 2013-04-23 06:30:15
|
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: Andrej N. G. <an...@re...> - 2013-04-23 11:57:07
|
Hello! Stephan Sokolow has written on Tuesday, 23 April, at 2:19: >On 13-04-23 01:14 AM, PCMan wrote: >> 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. >Unfortunately, I've already looked and been unable to find anything else >with the wide format and feature support I require. I should agree with you and I still stick with Audacious and I will. >>> (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. >For example, GoldenDict and LyX. The only major KDE applications I >really need are K3b, Tellico, and KDiff3... though I do like Okular much >more than ChmSee or xchm for reading CHM files. Despite the fact Openbox is my favourite WM and I'm using PCManFM (it's why I've started to polish it in the first place) and Lxpanel (I found no alternative so far - all other are either incomplete or too bloated) I just cannot use my desktop without KDE/Qt applications: it's Konsole (which still is the best terminal program - full featured and bugless) and Kmix - the best tray mixer application with built-in keys support I ever seen. So I'm using Qt always anyway. Another application that I always use is Firefox. Other are used less often but some of them are GTK and some are Qt. So my desktop is always mixed and I don't think it's a bad thing as far they can coexist. >> 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. :-) >I perfectly agree with the sentiment. One of my many "if I can ever find >the time" projects is to investigate the "rarfile" Python module as a >possible successor to my rar.py. (A partially-finished module for >listing files in rar archives without depending on the rar/unrar >binaries or linking against a GPL-incompatible library.) It's why merging teams together means not just adding efforts but somehow multiply them and we could have much better desktop than if we just implement something in parallel. At least I think so. :) Cheers! Andriy. |
From: Stephan S. <gma...@sp...> - 2013-04-23 14:27:04
|
On 13-04-23 07:56 AM, Andrej N. Gritsenko wrote: > Despite the fact Openbox is my favourite WM and I'm using PCManFM > (it's why I've started to polish it in the first place) and Lxpanel (I > found no alternative so far - all other are either incomplete or too > bloated) I just cannot use my desktop without KDE/Qt applications: it's > Konsole (which still is the best terminal program - full featured and > bugless) and Kmix - the best tray mixer application with built-in keys > support I ever seen. So I'm using Qt always anyway. Another application > that I always use is Firefox. Other are used less often but some of them > are GTK and some are Qt. So my desktop is always mixed and I don't think > it's a bad thing as far they can coexist. Huh. I actually used to use Konsole too though more through Yakuake than on its own. I ended up switching to rxvt-unicode (featureful but a bit of a hassle to learn how to configure) with the provided kuake Perl script and GNU screen for the tabs when I got fed up with how much heavier the KDE 4 version was. (Among other reasons, I try to keep my desktop as comfortable as possible on my old 2Ghz Celeron with 1GiB of RAM as a way to control bloat on my Athlon II X2 270 with 16GiB.) Now all I need to do is to find time to optimize my .zshrc. (Currently, urxvt appears as quickly as Leafpad but then waits a couple of seconds before displaying a prompt while it does things like populating its Tab completion cache. One reason why my .zshrc displays the fortune command's output as early as possible.) |
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: 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. |
From: Stephan S. <gma...@sp...> - 2013-04-25 01:20:32
|
On 13-04-24 04:56 PM, Andrej N. Gritsenko wrote: > 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. I'm not concerned about the API stability. My time as an enthusiast KDE user has made it clear how much both Qt and KDE value API stability. New APIs can be added, but old ones can't be broken in Qt or kdelibs without incrementing the major version and, as has been mentioned, Qt5 isn't a gigantic break from Qt4. I can definitely agree that debugging will be better than in Vala (and it'll be nice to have an officially-supported IDE that's neither Eclipse nor MonoDevelop for a language where Vim just isn't quite enough) but, as someone who normally programs in Python, PHP, JavaScript, or shell script, I can't usually justify the time cost of dropping to a level lower than languages like Vala and C#. (I don't count Java. They botched it too much.) It also worries me that, while I haven't fully kept up with Qt news, it seems that using QML/Quick as a glue language for building native desktop UIs won't be an officially-supported option until at LEAST Qt 5.1 (See https://qt-project.org/wiki/QtDesktopComponents). > 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. > Naturally. It only makes sense that, if you're porting to another language, you should do your best to follow the conventions and idioms of that language. Every Python programmer can probably name at least one case where they've had to put up with a wrapper for a C library that didn't do much more than exposing the C functions and constants to Python. I can definitely see how a list of equivalent classes and methods would help though. Maybe six months ago, on a whim, I decided to see look up the Qt equivalent of using asynchronous callback to incrementally load an image into a GDKPixBuf and it took a lot longer than it should to figure out what keywords Google wanted of me. > 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. True. For example, I believe Qt does a better job than Vala+GObject Introspection at providing a reasonably high-level API for various things. On the other hand: 1. Last I heard, GTK+ had integrated GIO so the GNOME-specific GVFS plugins could Just Work™ if dropped in at runtime while I don't think QNetworkRequest and KIOSlaves share the same level of runtime hot-swappability. (I may be wrong) 2. If you're doing something where 3D isn't just a gimmick, Qt has had support for embedding widgets in an OpenGL scene, complete with Wayland-style input transformation, for years while the GTK+ community was all excited when they arrived late to the party with Compiz-esque display-only 3D widget compositing. (That's why you can't do a full knock-off of OSX's Exposé in Compiz. It's apparently huge job to retrofit X11 to figure out what your mouse is actually pointing to in a composited desktop where transformations have been applied) > 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. I'm a programmer, whether it's PySide, Qt Quick, or the bare C++ API, I'll have to learn it if I don't want to stick to writing PyGTK and Vala apps. (I'm part of that old/sane school of thought that web apps should be limited to things that inherently depend on the presence of a layout engine and/or network access. For example, TiddlyWiki.) ...though I'm currently in a bit of a "rock and a hard place" situation since there are plenty of GTK+-only desktops and PyGTK isn't too rare a thing to find already installed but few Qt-only ones and fewer with PySide installed, so I've been coding loosely-coupled GTK+ apps to minimize the potential for pulling in dependencies. |
From: Andrej N. G. <an...@re...> - 2013-04-24 20:59:13
|
Hello! Alexis López Zubieta has written on Wednesday, 24 April, at 15:31: >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 This would be just wonderful to have you joining forces. I've started the thread with idea to join forces with razor-qt team. In case someone doesn't know, I'm the main developer of libfm and pcmanfm at the time being, mainly because PCMan has a lot less time and I have much more and I have interest in making it. Yes, I'm working with GTK but last time we found out that making it compatible with such fast changing GTK3 doesn't worth all the efforts. Therefore Qt looks like as viable alternative for another toolkit instead of GTK3 and PCMan started his experiments with Qt and it is what libfm-qt / pcmanfm-qt are. Yes, I can handle all bugs and feature requests for libfm / pcmanfm alone, but what with another LXDE components? LXDE team has very few developers. But since razor-qt has not too many developers too and they have the same goals (not build monstrous integrated complex but rather a desktop toolkit) I think it would be beneficial for both teams to join forces. And since you want something alike, that sound very promicing. But we should get razor-qt voices first I believe. From LXDE side - I and PCMan support the idea, some other developers aren't sure yet. Andriy. |
From: Andrej N. G. <an...@re...> - 2013-04-26 12:55:45
|
Hello! Дмитрий Антонов has written on Friday, 26 April, at 2:12: >PCManFM is no longer a lightweight file manager. How can you tell that? Where you've got such conclusion? And if there is some problem with it as lightweight file manager then, please, report that problem and help find what may be wrong, please. >Besides, he's still in development. When it will finish, it will be even >slower and will consume more resources. PCManFM core is finished. Development on it is about few feature requests to extend its functionality when user require that, such as new content menu items for example. It will never be slower, I promise. Just because any feature requests that affect its responsiveness are being refused. All additional resourse consumption will be tiny bit of RAM to load extra code (which implements those features) and it's all. If you meant Qt version of PCManFM then yes, it's not finished yet but I believe core is already complete so no further slowness either. Best regards. Andriy. |
From: Andrej N. G. <an...@re...> - 2013-04-26 14:46:40
|
Hello! JM has written on Friday, 26 April, at 15:44: >I am trying pcmanfm-qt for the first time in Archlinux where a PKGBUILD has been done for >it. First I didn't see icons, then I chose icons in the preferences section and after I >restarted it the icons showed (pcmanfm does not look for a .gtkrc-2.0 file?). Then it >looks a bit strange compared to the GTK version, the left sidebar is not organized the >same way. It is in very early state really. But it's better to ask PCMan about details, I'm working on 1.2 GTK version now and never took a part in Qt version yet. I'm sorry. >I tested what interests me most : the USB stick is mounting alright, internal >partition too, and once I unmount a volume the pcmanfm-qt program does not close, which >is nice, because the pcmanfm gtk version "closes" (I'd rather call that crash) when >unmounting any partition... still a problem with the current Version: 1.1.0-1. I remember that issue and that is in feature list for 1.2 as well. >The qt version does not close and just states that the directory is invalid. (this is not >perfect but better than a crash). >I see it will indeed still need some enhancements, and probably translations too. >Qt ? Difficult to go without it anyway, many good programs rely on it, and if the next >gtk version is too heavy and too difficult to code with, lets use Qt ! \o/ >I have a wish for the wish list : it would be nice to be able to split the main window in >two independent panes at will (and make it again one only on the fly when two panes will >not be needed anymore). I personally don't mind using mc/midnight commander, which is very >good for that, but the two pane in a GUI light file manager is a feature which has been >longed for many times by the members of the LinuxVillage (http://beta.linuxvillage.net >forum). Of course, the twin-pane mode will be in pcmanfm 1.2, it is a long waited optional feature by many. With the best wishes. Andriy. |
From: PCMan <pcm...@gm...> - 2013-04-28 11:47:58
|
On Sat, Apr 27, 2013 at 9:20 AM, IgnorantGuru <ign...@gm...> wrote: > Great work PCMan! And thanks for the conversion wiki. I've been shopping > for a GUI toolkit myself - perhaps to take SpaceFM there eventually - though > I'm not sure I like qt. Is there a discussion somewhere of why LXDE and/or > you are choosing to migrate to qt? I understand the desire to move away > from Red Hat's poisoning of the GTK well, but why did you choose qt? And > what other toolkits did you review? I would like to see the discussion or > analysis. > > Also, what are the current thoughts on gvfs now that you're moving in a more > qt direction? Any plans for change there? > > I've dropped you a link > http://igurublog.wordpress.com/2013/04/26/lxde-and-calculate-snub-gnome-3/ About gvfs, I'll keep using it for now. Mixing GIO and Qt works perfectly and Qt has built-in glib integration. Gvfs has more and more backends and many of them has no FUSE-based equivalence. An alternative would be to use KDE's KIO slave, if you're OK with the KDE dependencies. In comparison, gvfs is "relatively" more desktop-independent. When the backends are carefully separated by packagers, it's actually desktop independent and only brings few gnome deps. If your gvfs installation depends on the whole gnome, blame the packager of your distro. Since people are curious about the GUI toolkit issue, I wrote down another wiki page (not completed). http://wiki.lxde.org/en/GUI_Toolkit_Comparison There is no perfect toolkit. So it's all about a balance between cost and benefit. What I considered important: 1. It should be fast and light: If you insist on this point, then Qt and Gtk+ are out. But when you also consider the following points, things become different. 2. It should have good i18n support, including unicode, RTL, and other complicated text layout. GTK+ and Qt have exellent support in this fields while FLTK and FOX toolkiit only have very basicones. Enligtenment, I'm not sure. If your program is going to be used in non-English speaking countries, this is a critical issue. 3. It should accept text input from an input method editor Again, it's an essential feature for people from countries like China, Japan, Korea, and Taiwan (where I come from). So, I think only Gtk+ and Qt have good enough support for this. 4. It'll be better if it has accessibility support. Undoubtedly, Gtk+ is the best one here, and Qt follows. The others are irrelevant. 5. It should be really easy to program with, making us more productive. I'll never call "writing C with GObject" easy and efficient. So GTK+ is out. (I know vala, but it has many issues, like generating "incorrect" C code that's hard to debug). If you're doing OOP, why not use a language with "native" OO support and compiler optimized for the task? 6. It should supports glib integration, so I can use all of the nice non-GUI libraries based on glib. Qt, GTK+, and E17 are the ones that support glib. Others cannot do this. 7. It should be well-maintained: Qt and Gtk+ win. E17 has slower development, and FLTK is now splitted into two incompatible branches and each of them have many supporters. The future is uncertain. 8. It should be themable and looks good. Then apparently FLTK and FOX are not the right choice. FLTK has some "so-called" themes, but it's very primitive and limited, not really of the same level as Gtk+/Qt. If you consider 2 - 8 required and also want it to stay ultra-lightwight, then there is no such toolkit. If you make some compromise, then Qt is probably a good one. Consider the rich feature set it provides, it's not that heavy. To get the same feature set, you need to install tons of other libraries in the G universe. Besides, Qt is modular. If you only need the core features, link with QtCore and other modules won't be loaded. The whole library of course is huge, but you only need to link with the module you really used. Hope this answer your questions. |
From: Andrej N. G. <an...@re...> - 2013-04-29 18:32:25
|
Hello! Дмитрий Антонов has written on Friday, 26 April, at 12:14: >PCManFM consumes too much memory (RAM). If you think ~15 MB on i386 or ~20 MB on x86_64 is too much then consider to use Midnight Commander isntead. Other file managers with functionality similar to PCManFM use more RAM. May be some very early version of PCManFM (1st generation - 0.1.7 or whatever) with very basic functionality consumed less but I doubt you want so basic functionality ever from GUI file manager. I'm sorry. With best wishes. Andriy. |