You can subscribe to this list here.
2008 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
(29) |
Jun
(24) |
Jul
(17) |
Aug
(39) |
Sep
(6) |
Oct
(11) |
Nov
(14) |
Dec
(21) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2009 |
Jan
(28) |
Feb
(21) |
Mar
(30) |
Apr
(53) |
May
(90) |
Jun
(49) |
Jul
(181) |
Aug
(35) |
Sep
(18) |
Oct
(30) |
Nov
(34) |
Dec
(106) |
2010 |
Jan
(69) |
Feb
(107) |
Mar
(248) |
Apr
(189) |
May
(62) |
Jun
(109) |
Jul
(53) |
Aug
(108) |
Sep
(61) |
Oct
(44) |
Nov
(16) |
Dec
(22) |
2011 |
Jan
(50) |
Feb
(41) |
Mar
(30) |
Apr
(48) |
May
(24) |
Jun
|
Jul
|
Aug
(45) |
Sep
(43) |
Oct
(59) |
Nov
(60) |
Dec
(43) |
2012 |
Jan
(59) |
Feb
(30) |
Mar
(82) |
Apr
(53) |
May
(93) |
Jun
(101) |
Jul
(79) |
Aug
(87) |
Sep
(51) |
Oct
(66) |
Nov
(120) |
Dec
(30) |
2013 |
Jan
(20) |
Feb
(53) |
Mar
(19) |
Apr
(111) |
May
(63) |
Jun
(20) |
Jul
(156) |
Aug
(177) |
Sep
(68) |
Oct
(162) |
Nov
(300) |
Dec
(96) |
2014 |
Jan
(58) |
Feb
(44) |
Mar
(68) |
Apr
(138) |
May
(270) |
Jun
(63) |
Jul
(126) |
Aug
(78) |
Sep
(85) |
Oct
(182) |
Nov
(69) |
Dec
(54) |
2015 |
Jan
(77) |
Feb
(97) |
Mar
(44) |
Apr
(31) |
May
(20) |
Jun
(72) |
Jul
(31) |
Aug
(9) |
Sep
(19) |
Oct
(22) |
Nov
(53) |
Dec
(16) |
2016 |
Jan
(20) |
Feb
(26) |
Mar
(34) |
Apr
(22) |
May
(14) |
Jun
(27) |
Jul
(17) |
Aug
(9) |
Sep
(65) |
Oct
(20) |
Nov
(25) |
Dec
(36) |
2017 |
Jan
(18) |
Feb
(1) |
Mar
(20) |
Apr
(3) |
May
(23) |
Jun
(4) |
Jul
(18) |
Aug
(1) |
Sep
(15) |
Oct
(4) |
Nov
(3) |
Dec
(2) |
2018 |
Jan
(6) |
Feb
(5) |
Mar
(4) |
Apr
|
May
(3) |
Jun
|
Jul
(1) |
Aug
(2) |
Sep
(32) |
Oct
(2) |
Nov
|
Dec
|
2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(5) |
Jun
|
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
(6) |
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
(7) |
Jul
(9) |
Aug
(5) |
Sep
(2) |
Oct
(6) |
Nov
(9) |
Dec
|
2021 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
(6) |
Feb
(1) |
Mar
|
Apr
(1) |
May
(6) |
Jun
|
Jul
(25) |
Aug
|
Sep
(3) |
Oct
(14) |
Nov
|
Dec
|
2023 |
Jan
|
Feb
(12) |
Mar
(6) |
Apr
|
May
(5) |
Jun
(1) |
Jul
(23) |
Aug
(10) |
Sep
(12) |
Oct
|
Nov
(3) |
Dec
(11) |
2024 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Enrique D. <enr...@ya...> - 2019-07-18 12:02:23
|
<div dir='auto'>Hi, I'd like to start user session without shell permissions. So I'm trying to start a openbox user session setting lxdm.conf,<div dir="auto"><div dir="auto">session=/usr/bin/pcmanfm -d --desktop</div><div dir="auto">But it worked only if user has bash execution permission. It's not possible to start a session without a shell?</div><div dir="auto">I would like keep the shell only for root.</div><div dir="auto">Thanks a lot for your time.</div></div></div> |
From: Pixel_Lime <jo...@gm...> - 2019-07-18 05:41:57
|
We would like you to be part of KDE community. If you are interested, go to KDE Incubator, i hope LXQt team join us. https://community.kde.org/Incubator |
From: Влад С. <fla...@gm...> - 2019-05-31 16:38:48
|
Hello, Here is my patch for bug #150. diff --git a/src/gpicview.c b/src/gpicview.c index 00d6a47..5e8671e 100644 --- a/src/gpicview.c +++ b/src/gpicview.c @@ -90,6 +90,13 @@ int main(int argc, char *argv[]) if( G_UNLIKELY( *files[0] != '/' && strstr( files[0], "://" )) ) // This is an URI { char* path = g_filename_from_uri( files[0], NULL, NULL ); + + if(!path) + { + main_win_show_error(win, _("Cannot open file")); + return 1; + } + main_win_open( win, path, ZOOM_NONE ); g_free( path ); } diff --git a/src/main-win.c b/src/main-win.c index 32f6433..2d3c515 100644 --- a/src/main-win.c +++ b/src/main-win.c @@ -372,6 +372,9 @@ static void update_btns(MainWin* mw) gboolean main_win_open( MainWin* mw, const char* file_path, ZoomMode zoom ) { + if(!file_path) + return FALSE; + if (g_file_test(file_path, G_FILE_TEST_IS_DIR)) { image_list_open_dir( mw->img_list, file_path, NULL ); Best regards, Vladyslav Stovmanenko |
From: Piotr S. <pio...@gm...> - 2019-05-30 12:22:34
|
pon., 27 maj 2019 o 08:25 Влад Стовманенко <fla...@gm...> napisał(a): > Hi all. > I have fix for defect #150 "gpicview handles some malformed filenames in > wrong way". > Which way for reviewing my changes should I choose? > Hi Vlad, Send the patch to the list. The group will review and someone with push privileges should be able to get it upstream. Thanks! Piotr |
From: Влад С. <fla...@gm...> - 2019-05-27 12:24:38
|
Hi all. I have fix for defect #150 "gpicview handles some malformed filenames in wrong way". Which way for reviewing my changes should I choose? |
From: Matteo B. <mat...@gm...> - 2019-05-22 16:40:32
|
Il giorno mer 22 mag 2019 alle ore 18:14 Germano Massullo <ger...@gm...> ha scritto: > > Hello, I am writing to you to propose the following reasoning, hoping > that it can help making easier (just a bit) third parties development > work on Linux. > I am currently developing BOINC client user idle time detection on > Linux systems (both graphical or tty sessions) > After some studies I started writing a little piece of code that that > is able to print on standard output the user idle time by retrieving > it from systemd-logind IdleSinceHint property (that is exposed on > DBus). By the way I found out that this value was always 0 [1], so I > asked why [2]. I have been told that logind relies on the desktop > environment to pass this information. > Many d.e. expose user idle time to their own DBus path, (i.e. > org.gnome.Mutter.IdleMonitor), so I will be forced to write code that > depends on the specific desktop environment. Since: > 1) systemd-logind is just ready for exposing user idle time; > 2) for a developer writing code for Linux it would be much easier to > retrieve user idle time from a unique place rather than having to deal > with all various desktop environments; > I would like to ask you what do you think about passing the user idle > time to logind [3] [4] ? > > Best regards > > [1]: you can try with system console command > $ sleep 2 && gdbus introspect --system --dest org.freedesktop.login1 > --object-path /org/freedesktop/login1 | grep IdleSinceHint > [2]: https://lists.freedesktop.org/archives/systemd-devel/2019-May/042726.html > [3]: https://www.freedesktop.org/wiki/Software/systemd/writing-desktop-environments/ > [4]: https://www.freedesktop.org/wiki/Software/systemd/writing-display-managers/ I just hope, in the eventuality of new code in LXDE/LXQt that takes in account of this, that the case in which there's no systemd-logind on a {,non-}Linux system is considered as a possibility too :-) thanks in advance! Matteo |
From: Germano M. <ger...@gm...> - 2019-05-22 16:13:35
|
Hello, I am writing to you to propose the following reasoning, hoping that it can help making easier (just a bit) third parties development work on Linux. I am currently developing BOINC client user idle time detection on Linux systems (both graphical or tty sessions) After some studies I started writing a little piece of code that that is able to print on standard output the user idle time by retrieving it from systemd-logind IdleSinceHint property (that is exposed on DBus). By the way I found out that this value was always 0 [1], so I asked why [2]. I have been told that logind relies on the desktop environment to pass this information. Many d.e. expose user idle time to their own DBus path, (i.e. org.gnome.Mutter.IdleMonitor), so I will be forced to write code that depends on the specific desktop environment. Since: 1) systemd-logind is just ready for exposing user idle time; 2) for a developer writing code for Linux it would be much easier to retrieve user idle time from a unique place rather than having to deal with all various desktop environments; I would like to ask you what do you think about passing the user idle time to logind [3] [4] ? Best regards [1]: you can try with system console command $ sleep 2 && gdbus introspect --system --dest org.freedesktop.login1 --object-path /org/freedesktop/login1 | grep IdleSinceHint [2]: https://lists.freedesktop.org/archives/systemd-devel/2019-May/042726.html [3]: https://www.freedesktop.org/wiki/Software/systemd/writing-desktop-environments/ [4]: https://www.freedesktop.org/wiki/Software/systemd/writing-display-managers/ |
From: Donald H. <b4...@gm...> - 2019-02-21 15:48:27
|
From: Einar M. <ei...@mo...> - 2018-10-24 16:42:06
|
Hi again, sorry for bothering the mailing list! I figured it out myself in weblate. I just needed to go to the individual component to be able to add another language to it. Sorry! Kind regards, Einar Mostad -------- Videresendt melding -------- Emne: Norwegian Bokmål translation Dato: Sun, 21 Oct 2018 13:02:41 +0200 Fra: Einar Mostad <ei...@mo...> Til: lxd...@li... Hi! I would like to translate LXQt to Norwegian Bokmål and has made a profile on weblate.lxqt.org, but Norwegian Bokmål (nb_NO) is not listed as a language there. Can I add the language myself or does someone have to add it for me? Kind regards, Einar Mostad -- Einar Mostad (+47) 40 09 52 84 ei...@mo... |
From: Einar M. <ei...@mo...> - 2018-10-21 11:18:56
|
Hi! I would like to translate LXQt to Norwegian Bokmål and has made a profile on weblate.lxqt.org, but Norwegian Bokmål (nb_NO) is not listed as a language there. Can I add the language myself or does someone have to add it for me? Kind regards, Einar Mostad -- Einar Mostad (+47) 40 09 52 84 ei...@mo... |
From: Mgr. J. C. <jan...@vo...> - 2018-09-28 20:56:35
|
Dear core developers of LXDE, Thanks to MR professor Klaus Knopper, I have made The chance to try The LXDE desktop environment 7 years before or more. I have found it very light and stable environment. And because I want to try new exciting development trends, I have started to test and use Userland Android application. It enable Android operating system users to run ARM 64 bit Linux distribution in its userspace mode. It uses chroot method and it even enable users to execute ARM64 bit instructions on ARM32 bit CPUS. Because it is developing project and because it is not standard Linux operating system it run in userspace mode, it is required some research to get desktop environments working. LXDE currently work for sighted users, but I Am experiencing issues with hod keys support. When I type lxdestart & In console window, I do not get crash info inside this window. My sighted mother has informed Me, that there is Thunar and there is trash desktop item. But build in hodkeys detection algorithm, such as: ALT+F1 Do not recall main menu. ALT+F2 do not recall run dialog. I AM running Debian stable ARM64 bit.Or did you removed hodkeys support from LXDE at all? And all other keys on external keyboard do not work. I Am aware, that userland this environment is not standard Linux. But I believe, that somebody of engaged developer would have some time to give ME some advices how to find The cause of this problem. I have successfully run Caja file manager and several other GTK apps with orca but I must use The procedure. In console window by using SSH. For example. marco & orca & caja & Sure, I can even use Openbox window manager without problems. I can not simply root my Android device and boot Linux directly from SD cart, because ARM devices are not IBM/PC compatible machines with support for Udev, there is no PCI bus and so there is no something like ARM live bootable operating system which auto detect sound chip and others. And I have also read some article, that xorg can severely corrupt Android device display thanks to monitor calibration algorithm used. May be, that it is non sense, but I AM afraid because of it. So I rather do not try to run Linux from rooted Android device. In this case, when I always patiently wait till every process have been executed, I Am able to use individual app. I think, that sighted users of Userland have big profit, since they are using VNC. But I must use XserverXSDL for Android which have been made by MR Pelia in year 2016, since it is The only one safe solution for non rooted Android devices to run Xserver including XKB protocol, so keyboard can be used inside X session without issues. Xserver XSDL also contain very clever and strange algorithm, which emulates Pulseaudio. In userland, I even do not have to have Pulseaudio installed. I only need to type export PULSE_SERVER=tcp:127.0.0.1:4712 export display=:0 And I can even use Pulseaudio players from console window. Because I do not see at all, I do not have problems with graphical apps, that Xserver XSDL do not support 3D instructions set. Smart window managers autodetect this fact and there are no crashes. Thank you very much for some advices if it would be possible. With warmest regards. Janusz Chmiel |
From: aitor_czr <ait...@gn...> - 2018-09-21 18:47:37
|
Hi Andriy, El 21/09/18 a las 17:02, Andriy Grytsenko escribió: > Hello! > > aitor_czr has written on Friday, 21 September, at 15:09: > >> I'm a newbie here, and a PCManFM fanboy. English is not my native >> language, but i'm learning a lot with the Veteran Unix Admins (Devuan). >> I live in the basque country, north of Spain. I have some experience >> developing in C/C++ and Gtk/Gtkmm, and I would like to help the project. > You're pretty welcome! You can start with working on issues from the bug > trackers: > > https://sourceforge.net/p/pcmanfm/bugs/ > https://sourceforge.net/p/lxde/bugs/ > > Anything done will be appreciated a lot. > > With best regards, > Andriy. I've been working recently on a network manager for Lxde, Openbox... You can find the sources in gitlab: https://git.devuan.org/aitor_czr/simple-netaid-gtk and the .deb packages here: http://gnuinos.org/simple-netaid/ Here you are some screenshots: http://gnuinos.org/simple-netaid/screenshots/ The project has a lot of issues pending to be fixed: warnings during the compilation, a segmentation fault closing the application, to improve the wired connection (it takes a few seconds), etc... But the packages are operative. The backen of simple-netaid uses come code taken from the netstat plugin of the LXPanel. Have a look at this file: https://git.devuan.org/aitor_czr/simple-netaid-gtk/blob/master/backend_src/netstat.c This project was started by another person (Edward Bartolo), a member of the Devuan Mailing list, written in C and freepascal, but I rewrote it a couple of years later in C/C++ and Gtkmm. It's buildable in both Gtk2 and Gtk3. On the other hand, I'm the author of a non-popular distribution: gnuinos. The website is obsolete and the isos are also obsolete. If you give a try to the newest live image: http://gnuinos.org/gnuinos%20jessie/ you will be able to test a new dinamic menu developed in Gtk2: https://git.devuan.org/aitor_czr/popupmenu/blob/master/screenshot.png Here you are the sources: https://git.devuan.org/aitor_czr/popupmenu/tree/master/ The popupmenu uses the libmenu-cache developed for Lxde. I also have some experience on packaging stuff: http://packages.gnuinos.org/ Thanks to all of you :) Aitor. |
From: Andriy G. <an...@re...> - 2018-09-21 15:02:18
|
Hello! aitor_czr has written on Friday, 21 September, at 15:09: >I'm a newbie here, and a PCManFM fanboy. English is not my native >language, but i'm learning a lot with the Veteran Unix Admins (Devuan). >I live in the basque country, north of Spain. I have some experience >developing in C/C++ and Gtk/Gtkmm, and I would like to help the project. You're pretty welcome! You can start with working on issues from the bug trackers: https://sourceforge.net/p/pcmanfm/bugs/ https://sourceforge.net/p/lxde/bugs/ Anything done will be appreciated a lot. With best regards, Andriy. |
From: aitor_czr <ait...@gn...> - 2018-09-21 14:27:33
|
Hi all, I'm a newbie here, and a PCManFM fanboy. English is not my native language, but i'm learning a lot with the Veteran Unix Admins (Devuan). I live in the basque country, north of Spain. I have some experience developing in C/C++ and Gtk/Gtkmm, and I would like to help the project. Cheers, Aitor. |
From: Mario R. <mru...@gm...> - 2018-09-17 22:37:09
|
El lun., 17 sept. 2018 a las 15:13, Andriy Grytsenko (<an...@re...>) escribió: > > Hello! > > Mario Rugiero has written on Sunday, 16 September, at 17:59: > > >While running some routine checks (the likes that motivated my > >patches), I found libfm's source includes a few files coming from exo, > >nicely dated to ease comparison to upstream. > >However, they are also /dated/ (2009-08-30), and it's likely some of > >the bugs detected by the tools are already fixed upstream, and also > >many more the tools didn't catch. > > Actually they were initially taken from libexo but rewritten a lot (GTK3 > compatibility, accessibility, bugs, etc.). Some time (few years I think) > ago I checked XFCE sources and imported relevant fixes into our code. As > a matter of fact, I planned to further rework it, at least ExoTreeView > class requires a massive rewrite. Unfortunately I constantly run out of > free time so never started that rework. I see. Then, on the short term I think we should at the very least update the misleading comment at the top of the source files. That's where I got the date from. > > [.......] > >Number 3 also comes with a lot of breakage, and not only means aiming > >at a moving target, but it can cause harm to distributions, as they > >may need to update the library and we may not fully support it for a > >variety of reasons, one being we don't have yet complete support for > >GTK3. > > That is not true. Complete GTK3 support was aimed yet for 1.2.0 version, > and few discovered bugs were fixed since then. And, BTW, while libfm had > GTK3 full support, libexo didn't, they added partial support on it much > later. Another problem is that GTK3 is still buggy, it's why I avoid it > personally. But LXDE as a whole should be working with GTK3 for a while, > and there are distros that use GTK3-only builds for all LXDE components. I'm sorry I didn't clarify, but I meant LXDE would need GTK3, but now that I think about it, even if LXDE doesn't support GTK3, there's nothing impeding using GTK2 for the components that don't support GTK3. > > >I think the most reasonable route would be to fix the immediate bugs > >(as in option 1), then migrate to near-upstream and later move to use > >it as a library. > >Of course, I'm thinking of a span of at least several months. > > Depend on libexo is bad move, we'd get retro-bugs fixed long time ago, we > will depend on XFCE intsallation, we will depend on XFCE developers, we > will lose few our features and much more. And since actually libexo is a > modified version of GTK+ classes (GtkIconView and GtkTreeView), following > your logic we should abandon all our extra features and go stright to GTK > classes as GTK gets even more attention than XFCE, right? :) The retro-bugs are a real drawback, as is not importing the fixes for the alternative. Now, on installing XFCE, I don't think that's the case. Such an assertion is equivalent to stating writing a FM based con libfm requires installing LXDE. Also, keep in mind I thought the file was mostly borrowed at the time of writing my original e-mail. This means I never proposed dropping any features. > PS: if you can give me an idea of the changes you had in store, I might see if I can lend a hand :) > With best regards, > Andriy. > Regards, Mario. > > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list |
From: Andriy G. <an...@re...> - 2018-09-17 18:12:25
|
Hello! Mario Rugiero has written on Sunday, 16 September, at 17:59: >While running some routine checks (the likes that motivated my >patches), I found libfm's source includes a few files coming from exo, >nicely dated to ease comparison to upstream. >However, they are also /dated/ (2009-08-30), and it's likely some of >the bugs detected by the tools are already fixed upstream, and also >many more the tools didn't catch. Actually they were initially taken from libexo but rewritten a lot (GTK3 compatibility, accessibility, bugs, etc.). Some time (few years I think) ago I checked XFCE sources and imported relevant fixes into our code. As a matter of fact, I planned to further rework it, at least ExoTreeView class requires a massive rewrite. Unfortunately I constantly run out of free time so never started that rework. [.......] >Number 3 also comes with a lot of breakage, and not only means aiming >at a moving target, but it can cause harm to distributions, as they >may need to update the library and we may not fully support it for a >variety of reasons, one being we don't have yet complete support for >GTK3. That is not true. Complete GTK3 support was aimed yet for 1.2.0 version, and few discovered bugs were fixed since then. And, BTW, while libfm had GTK3 full support, libexo didn't, they added partial support on it much later. Another problem is that GTK3 is still buggy, it's why I avoid it personally. But LXDE as a whole should be working with GTK3 for a while, and there are distros that use GTK3-only builds for all LXDE components. >I think the most reasonable route would be to fix the immediate bugs >(as in option 1), then migrate to near-upstream and later move to use >it as a library. >Of course, I'm thinking of a span of at least several months. Depend on libexo is bad move, we'd get retro-bugs fixed long time ago, we will depend on XFCE intsallation, we will depend on XFCE developers, we will lose few our features and much more. And since actually libexo is a modified version of GTK+ classes (GtkIconView and GtkTreeView), following your logic we should abandon all our extra features and go stright to GTK classes as GTK gets even more attention than XFCE, right? :) With best regards, Andriy. |
From: Mario R. <mru...@gm...> - 2018-09-16 22:59:57
|
Regarding this patch, there's a missing case that isn't (and wasn't) handled, which is an 'empty' param, e.g. 'search:///tmp?min_size=' still crashes. El dom., 16 sept. 2018 a las 19:57, Mario J. Rugiero (<mru...@gm...>) escribió: > > From: Mario Rugiero <mru...@gm...> > > In cases where a parameter is passed to an URI search but > the corresponding value is missing, libfm users (PCManFM) > would crash or worse due to assuming value to be valid. > Since all of the params depend on this value, the reasonable > fix seems to be an early break or continue. > --- > src/modules/vfs-search.c | 36 +++++++++++++++++++++++++----------- > 1 file changed, 25 insertions(+), 11 deletions(-) > > diff --git a/src/modules/vfs-search.c b/src/modules/vfs-search.c > index 57a375c..64344f2 100644 > --- a/src/modules/vfs-search.c > +++ b/src/modules/vfs-search.c > @@ -464,21 +464,35 @@ static void parse_search_uri(FmVfsSearchEnumerator* priv, const char* uri_str) > char* value = strchr(params, '='); > char* sep = strchr(params, '&'); > > - if (value && (sep == NULL || value < sep)) > + /* If there's no value, the whole param is crippled. > + * At the very least, that's the case for how currently > + * supported params work. > + */ > + if (value == NULL && sep == NULL) > { > - name = g_strndup(params, value - params); > - if (sep) > - value = g_uri_unescape_segment(value+1, sep, NULL); > - else > - value = g_uri_unescape_string(value+1, NULL); > + /* sep == NULL means this is the last parameter. */ > + break; > } > - else if (sep) > + else if (value == NULL) > { > - name = g_strndup(params, sep - params); > - value = NULL; > + /* No value, but still more params later. */ > + params = sep + 1; > + continue; > + } > + else if (value >= sep) > + { > + /* We found a value, but it's for a later param, as it's > + * after the next sep. > + */ > + params = sep + 1; > + continue; > } > - else /* value == NULL && sep == NULL */ > - name = g_strdup(params); > + > + name = g_strndup(params, value - params); > + if (sep) > + value = g_uri_unescape_segment(value+1, sep, NULL); > + else > + value = g_uri_unescape_string(value+1, NULL); > > /* g_printf("parameter name/value: %s = %s\n", name, value); */ > > -- > 2.17.1 > |
From: Mario J. R. <mru...@gm...> - 2018-09-16 22:57:20
|
From: Mario Rugiero <mru...@gm...> In cases where a parameter is passed to an URI search but the corresponding value is missing, libfm users (PCManFM) would crash or worse due to assuming value to be valid. Since all of the params depend on this value, the reasonable fix seems to be an early break or continue. --- src/modules/vfs-search.c | 36 +++++++++++++++++++++++++----------- 1 file changed, 25 insertions(+), 11 deletions(-) diff --git a/src/modules/vfs-search.c b/src/modules/vfs-search.c index 57a375c..64344f2 100644 --- a/src/modules/vfs-search.c +++ b/src/modules/vfs-search.c @@ -464,21 +464,35 @@ static void parse_search_uri(FmVfsSearchEnumerator* priv, const char* uri_str) char* value = strchr(params, '='); char* sep = strchr(params, '&'); - if (value && (sep == NULL || value < sep)) + /* If there's no value, the whole param is crippled. + * At the very least, that's the case for how currently + * supported params work. + */ + if (value == NULL && sep == NULL) { - name = g_strndup(params, value - params); - if (sep) - value = g_uri_unescape_segment(value+1, sep, NULL); - else - value = g_uri_unescape_string(value+1, NULL); + /* sep == NULL means this is the last parameter. */ + break; } - else if (sep) + else if (value == NULL) { - name = g_strndup(params, sep - params); - value = NULL; + /* No value, but still more params later. */ + params = sep + 1; + continue; + } + else if (value >= sep) + { + /* We found a value, but it's for a later param, as it's + * after the next sep. + */ + params = sep + 1; + continue; } - else /* value == NULL && sep == NULL */ - name = g_strdup(params); + + name = g_strndup(params, value - params); + if (sep) + value = g_uri_unescape_segment(value+1, sep, NULL); + else + value = g_uri_unescape_string(value+1, NULL); /* g_printf("parameter name/value: %s = %s\n", name, value); */ -- 2.17.1 |
From: Mario R. <mru...@gm...> - 2018-09-16 20:59:55
|
Hi, list, While running some routine checks (the likes that motivated my patches), I found libfm's source includes a few files coming from exo, nicely dated to ease comparison to upstream. However, they are also /dated/ (2009-08-30), and it's likely some of the bugs detected by the tools are already fixed upstream, and also many more the tools didn't catch. I thought of three possibilities going forward: 1_ We keep working as if exo's code was our own, fixing the bugs independently of them being fixed or not upstream. 2_ We sync periodically, bringing the fixes made to the respective version of the file. In that case, tagging the files with the hash of the correspondent commit would be a good idea. 3_ We remove the copy-pasted code and just depend on exo as a third-party library. As I see it, 1 is the easiest path in the short term: it doesn't require us to update calls to deprecated functions, issues due to mixed dependencies with GTK2 and GTK3, and that sort of breakage. However, it is the least robuts. We are unlikely to catch as many bugs as upstream, for several reasons, including, but not limited to, the number of users, the man-power, and pure randomness. Number 2 has the partial advantage of a reduced amount of breakage due to library update on the target system, as we are still shipping our own files with the interfaces WE need. However, in the immediate term this comes with breakage because we lagged behind too much. It has the advantage of getting upstream's fixes, but lagging behind a bit. It also requires periodically checking, which I'm not sure we can guarantee right now. Number 3 also comes with a lot of breakage, and not only means aiming at a moving target, but it can cause harm to distributions, as they may need to update the library and we may not fully support it for a variety of reasons, one being we don't have yet complete support for GTK3. I think the most reasonable route would be to fix the immediate bugs (as in option 1), then migrate to near-upstream and later move to use it as a library. Of course, I'm thinking of a span of at least several months. I may or may not be able/willing to do that job. I'm not sure it's desired, really, since the move to Qt may render this obsolete, AFAIK. Opinions welcomed. Mario. |
From: Mario J. R. <mru...@gm...> - 2018-09-15 04:31:23
|
From: Mario Rugiero <mru...@gm...> This one is actually rather easy to trigger: 1_ In section [ui] of the config, set the field saved_search so it matches: [0-9a-fA-f]\&[^\&]$ 2_ Launch file search on PCManFM. 3_ Watch it crash. For quick validation, I used the string "405&a" to test it. --- src/gtk/fm-gtk-file-launcher.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gtk/fm-gtk-file-launcher.c b/src/gtk/fm-gtk-file-launcher.c index 5e7cde9..3eb08a4 100644 --- a/src/gtk/fm-gtk-file-launcher.c +++ b/src/gtk/fm-gtk-file-launcher.c @@ -960,7 +960,7 @@ gboolean fm_launch_search_simple(GtkWindow* parent, GAppLaunchContext* ctx, } else mask = expr = g_strdup(c); - if (*mask == '/') /* else corrupted */ + if (mask && *mask == '/') /* else corrupted */ { mask++; c = strchr(mask, '/'); -- 2.17.1 |
From: Mario J. R. <mru...@gm...> - 2018-09-15 04:31:19
|
From: Mario Rugiero <mru...@gm...> --- src/base/fm-file-launcher.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/base/fm-file-launcher.c b/src/base/fm-file-launcher.c index 41c7857..6245b51 100644 --- a/src/base/fm-file-launcher.c +++ b/src/base/fm-file-launcher.c @@ -457,7 +457,8 @@ _launch_desktop_entry: type); if (err) { - launcher->error(ctx, err, NULL, user_data); + if (launcher->error) + launcher->error(ctx, err, NULL, user_data); g_clear_error(&err); } g_list_free(fis); -- 2.17.1 |
From: Mario J. R. <mru...@gm...> - 2018-09-15 04:31:13
|
From: Mario Rugiero <mru...@gm...> A break was missing between cases G_FILE_TYPE_SHORTCUT and F_GILE_TYPE_MOUNTABLE. In this case, there's no logical reason why a shortcut should be treated as a mountable, so it was concluded this was actually a mistake. --- src/base/fm-file-info.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/base/fm-file-info.c b/src/base/fm-file-info.c index a2775d5..7d1b2d8 100644 --- a/src/base/fm-file-info.c +++ b/src/base/fm-file-info.c @@ -632,6 +632,7 @@ void fm_file_info_set_from_g_file_data(FmFileInfo *fi, GFile *gf, GFileInfo *inf { case G_FILE_TYPE_SHORTCUT: fi->shortcut = TRUE; + break; case G_FILE_TYPE_MOUNTABLE: uri = g_file_info_get_attribute_string(inf, G_FILE_ATTRIBUTE_STANDARD_TARGET_URI); if(uri) -- 2.17.1 |
From: Mario J. R. <mru...@gm...> - 2018-09-15 04:31:09
|
From: Mario Rugiero <mru...@gm...> --- src/gtk/fm-dir-tree-model.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gtk/fm-dir-tree-model.c b/src/gtk/fm-dir-tree-model.c index a2b9a87..f896d78 100644 --- a/src/gtk/fm-dir-tree-model.c +++ b/src/gtk/fm-dir-tree-model.c @@ -339,8 +339,8 @@ static GtkTreePath *fm_dir_tree_model_get_path(GtkTreeModel *tree_model, g_return_val_if_fail (FM_IS_DIR_TREE_MODEL(tree_model), NULL); model = (FmDirTreeModel*)tree_model; - g_return_val_if_fail (iter->stamp == model->stamp, NULL); g_return_val_if_fail (iter != NULL, NULL); + g_return_val_if_fail (iter->stamp == model->stamp, NULL); g_return_val_if_fail (iter->user_data != NULL, NULL); item_l = (GList*)iter->user_data; -- 2.17.1 |
From: Mario J. R. <mru...@gm...> - 2018-09-14 02:28:30
|
From: Mario Rugiero <mru...@gm...> --- src/utils.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/utils.c b/src/utils.c index 11633bc..6845459 100644 --- a/src/utils.c +++ b/src/utils.c @@ -144,6 +144,8 @@ _failed: argv[1] = "--gzip"; else if(g_str_has_suffix(package_path, ".tar.bz2")) argv[1] = "--bzip2"; + else if(g_str_has_suffix(package_path, ".tar.xz")) + argv[1] = "--xz"; else /* the file format is not supported */ goto _out; @@ -248,7 +250,8 @@ gboolean install_icon_theme(GtkWindow* parent) gtk_window_set_transient_for(GTK_WINDOW(fc), GTK_WINDOW(app.dlg)); gtk_file_filter_add_pattern( filter, "*.tar.gz" ); gtk_file_filter_add_pattern( filter, "*.tar.bz2" ); - gtk_file_filter_set_name( filter, _("*.tar.gz, *.tar.bz2 (Icon Theme)") ); + gtk_file_filter_add_pattern( filter, "*.tar.xz" ); + gtk_file_filter_set_name( filter, _("*.tar.gz, *.tar.bz2, *.tar.xz (Icon Theme)") ); gtk_file_chooser_add_filter( GTK_FILE_CHOOSER(fc), filter ); gtk_file_chooser_set_filter( GTK_FILE_CHOOSER(fc), filter ); -- 2.17.1 |
From: Mario J. R. <mru...@gm...> - 2018-09-14 02:28:27
|
From: Mario Rugiero <mru...@gm...> The case where a single package comes with both cursor and icon themes is evaluated before the theme structure is actually loaded. Because of how the rest of the code handles it, there are five possible scenarios caused because of this: 1_ The program crashes. This is most likely when theme ends up pointing to a protected address. 2_ A true positive. Everything works as intended. 3_ A false positive. Nothing bad happens, because it iterates and looks for the corresponding theme, failing gracefully if it doesn't exist. 4_ A true negative. Everything works as intended. 5_ A false negative. Since it won't look for the corresponding theme, we end up leaving trash behind us. I didn't actually certify that all of this happens as described, mostly because I couldn't find a theme containing both icons and cursors. I did try erasing a few themes to make sure I didn't break anything, Plus, the change is rather trivial, so it's unlikely I made any mistakes here. --- src/icon-theme.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/icon-theme.c b/src/icon-theme.c index 7fba616..5416351 100644 --- a/src/icon-theme.c +++ b/src/icon-theme.c @@ -171,7 +171,6 @@ static void on_remove_theme_clicked(GtkButton* btn, gpointer user_data) if(gtk_tree_selection_get_selected(sel, &model, &it)) { IconTheme* theme; - gboolean both = theme->has_icon && theme->has_cursor; if(gtk_tree_model_iter_n_children(model, NULL) < 2) { @@ -190,6 +189,7 @@ static void on_remove_theme_clicked(GtkButton* btn, gpointer user_data) gtk_tree_selection_select_iter(sel, &it); /* FIXME: in rare case, a theme can contain both icons and cursors */ + gboolean both = theme->has_icon && theme->has_cursor; if(both) /* we need to remove item in another list store, too */ { model = GTK_TREE_MODEL(model == (GtkTreeModel*)app.icon_theme_store ? app.cursor_theme_store : app.icon_theme_store); -- 2.17.1 |