From: Lucas H. <lu...@di...> - 2008-04-25 13:33:53
|
I just upgraded to compiz-fusion 0.7.4, and the panels come off the screen. ------------------------------- Panel ------------------------------- GAP ------------------------------- Edge of screen My immediate reaction was to think that the panel struts aren't playing nicely with compiz, and sure enough if I prevent panel_setup_struts in panel.c from doing anything the panel are positioned correctly, however the panels now get covered when maximising. Not sure if this a bug with ROX or compiz though. -- Lucas Hazel <lu...@di...> |
From: Lucas H. <lu...@di...> - 2008-04-25 14:42:47
|
On Fri, 25 Apr 2008 23:24:52 +1000 Lucas Hazel <lu...@di...> wrote: > > I just upgraded to compiz-fusion 0.7.4, and the panels come off the > screen. > > ------------------------------- > Panel > ------------------------------- > GAP > ------------------------------- > Edge of screen > > My immediate reaction was to think that the panel struts aren't > playing nicely with compiz, and sure enough if I prevent > panel_setup_struts in panel.c from doing anything the panel are > positioned correctly, however the panels now get covered when > maximising. > > Not sure if this a bug with ROX or compiz though. > After some further investigation, and a brief discussion with the compiz devs. I have discovered that the panel's aren't being correctly set to _NET_WM_WINDOW_TYPE_DOCK with compiz: _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL with openbox: _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK -- Lucas Hazel <lu...@di...> Digit Illogic Enterises [http://die.net.au] [phone: +61401313870] [ABN: 52841332786] AMAC Fast Track Computers Technician 209 Beardy Street, Armidale NSW [phone: +61267711287] School of Maths and Computer Science University of New England Armidale, Australia [http://cs.une.edu.au] ================================================= "Clothes make the man. Naked men are rarely taken seriously, or given employment." ================================================= |
From: Lucas H. <lu...@di...> - 2008-04-26 00:12:35
|
On Sat, 26 Apr 2008 00:39:17 +1000 Lucas Hazel <lu...@di...> wrote: > On Fri, 25 Apr 2008 23:24:52 +1000 > Lucas Hazel <lu...@di...> wrote: > > > > > I just upgraded to compiz-fusion 0.7.4, and the panels come off the > > screen. > > > > After some further investigation, and a brief discussion with the > compiz devs. I have discovered that the panel's aren't being correctly > set to _NET_WM_WINDOW_TYPE_DOCK > > with compiz: _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL > with openbox: _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK > Strange I just checked again and now the panels are have the dock type hint set. But still not on the screen edge. -- Lucas Hazel <lu...@di...> |
From: Stephen W. <st...@ke...> - 2008-04-25 15:22:06
|
Lucas Hazel <lu...@di...> wrote: > On Fri, 25 Apr 2008 23:24:52 +1000 > Lucas Hazel <lu...@di...> wrote: > > > > > I just upgraded to compiz-fusion 0.7.4, and the panels come off the > > screen. > > > > ------------------------------- > > Panel > > ------------------------------- > > GAP > > ------------------------------- > > Edge of screen > > > > My immediate reaction was to think that the panel struts aren't > > playing nicely with compiz, and sure enough if I prevent > > panel_setup_struts in panel.c from doing anything the panel are > > positioned correctly, however the panels now get covered when > > maximising. > > > > Not sure if this a bug with ROX or compiz though. > > > > After some further investigation, and a brief discussion with the > compiz devs. I have discovered that the panel's aren't being correctly > set to _NET_WM_WINDOW_TYPE_DOCK > > with compiz: _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL > with openbox: _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK Options=>Compatibility=>Panel is a 'dock' -- Stephen Watson http://www.kerofin.demon.co.uk/ If you read this on a mailing list, send any reply back to the list and not to me. Not even CC. "Bad dog!" "Affirmative!" |
From: Lucas H. <lu...@di...> - 2008-04-25 23:37:26
|
On Fri, 25 Apr 2008 16:21:47 +0100 Stephen Watson <st...@ke...> wrote: > Lucas Hazel <lu...@di...> wrote: > > > On Fri, 25 Apr 2008 23:24:52 +1000 > > Lucas Hazel <lu...@di...> wrote: > > > > > > > > I just upgraded to compiz-fusion 0.7.4, and the panels come off > > > the screen. > > > > > > ------------------------------- > > > Panel > > > ------------------------------- > > > GAP > > > ------------------------------- > > > Edge of screen > > > > > > My immediate reaction was to think that the panel struts aren't > > > playing nicely with compiz, and sure enough if I prevent > > > panel_setup_struts in panel.c from doing anything the panel are > > > positioned correctly, however the panels now get covered when > > > maximising. > > > > > > Not sure if this a bug with ROX or compiz though. > > > > > > > After some further investigation, and a brief discussion with the > > compiz devs. I have discovered that the panel's aren't being > > correctly set to _NET_WM_WINDOW_TYPE_DOCK > > > > with compiz: _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL > > with openbox: _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK > > Options=>Compatibility=>Panel is a 'dock' > $ grep dock ~/.config/rox.sourceforge.net/ROX-Filer/Options <Option name="panel_is_dock">1</Option> -- Lucas Hazel <lu...@di...> |
From: Lucas H. <lu...@di...> - 2008-04-27 13:13:27
|
On Fri, 25 Apr 2008 23:24:52 +1000 Lucas Hazel <lu...@di...> wrote: > > I just upgraded to compiz-fusion 0.7.4, and the panels come off the > screen. > > > Not sure if this a bug with ROX or compiz though. > Here is a screenshot of the problem, http://i27.tinypic.com/so1stu.jpg I'm almost certain this is a ROX related bug now. I did a quick test to see how compiz handles dock type windows: #include <gtk/gtk.h> int main(int argc, char **argv) { GtkWidget *panel; gtk_init(&argc, &argv); panel = gtk_window_new(GTK_WINDOW_TOPLEVEL); gtk_window_set_type_hint(GTK_WINDOW(panel), GDK_WINDOW_TYPE_HINT_DOCK); gtk_widget_show(panel); gtk_main(); return 0; } Under compiz this immediately put the window onto the edge of the screen, made it sticky and ignored by pagers and tasklists. So the only requirement under compiz to create a panel is to set the dock type window hint. I've been playing with the X11 magic in gui_support.c and panel.c but can't seem to pinpoint the cause. Is there anywhere else I should be looking? Or any ideas what might cause this effect? -- Lucas Hazel <lu...@di...> |
From: Thomas L. <ta...@gm...> - 2008-04-27 14:06:26
|
2008/4/27 Lucas Hazel <lu...@di...>: > On Fri, 25 Apr 2008 23:24:52 +1000 > > Lucas Hazel <lu...@di...> wrote: > > > > > I just upgraded to compiz-fusion 0.7.4, and the panels come off the > > screen. > > Not sure if this a bug with ROX or compiz though. > > > > Here is a screenshot of the problem, http://i27.tinypic.com/so1stu.jpg > > I'm almost certain this is a ROX related bug now. I did a quick test to > see how compiz handles dock type windows: > > #include <gtk/gtk.h> > > int main(int argc, char **argv) { > GtkWidget *panel; > gtk_init(&argc, &argv); > panel = gtk_window_new(GTK_WINDOW_TOPLEVEL); > gtk_window_set_type_hint(GTK_WINDOW(panel), > GDK_WINDOW_TYPE_HINT_DOCK); > gtk_widget_show(panel); > gtk_main(); > return 0; > } > > Under compiz this immediately put the window onto the edge of the > screen, made it sticky and ignored by pagers and tasklists. So the only > requirement under compiz to create a panel is to set the dock type > window hint. > > I've been playing with the X11 magic in gui_support.c and panel.c but > can't seem to pinpoint the cause. Is there anywhere else I should be > looking? Or any ideas what might cause this effect? Is panel_setup_struts() causing the problem? -- Dr Thomas Leonard http://rox.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Lucas H. <lu...@di...> - 2008-04-27 23:06:36
|
On Sun, 27 Apr 2008 15:06:24 +0100 "Thomas Leonard" <ta...@gm...> wrote: > 2008/4/27 Lucas Hazel <lu...@di...>: > > On Fri, 25 Apr 2008 23:24:52 +1000 > > > > Lucas Hazel <lu...@di...> wrote: > > > > > > > > I just upgraded to compiz-fusion 0.7.4, and the panels come off > > > the screen. > > > Not sure if this a bug with ROX or compiz though. > > > > > > > Here is a screenshot of the problem, > > http://i27.tinypic.com/so1stu.jpg > > > > I'm almost certain this is a ROX related bug now. I did a quick > > test to see how compiz handles dock type windows: > > > > #include <gtk/gtk.h> > > > > int main(int argc, char **argv) { > > GtkWidget *panel; > > gtk_init(&argc, &argv); > > panel = gtk_window_new(GTK_WINDOW_TOPLEVEL); > > gtk_window_set_type_hint(GTK_WINDOW(panel), > > GDK_WINDOW_TYPE_HINT_DOCK); > > gtk_widget_show(panel); > > gtk_main(); > > return 0; > > } > > > > Under compiz this immediately put the window onto the edge of the > > screen, made it sticky and ignored by pagers and tasklists. So the > > only requirement under compiz to create a panel is to set the dock > > type window hint. > > > > I've been playing with the X11 magic in gui_support.c and panel.c > > but can't seem to pinpoint the cause. Is there anywhere else I > > should be looking? Or any ideas what might cause this effect? > > Is panel_setup_struts() causing the problem? > > That was my immediate reaction because it looks like the panels are being place outside of the struts. I turned off struts in the code and sure enough the panels go to the edge, but this breaks the "do not cover panel" option. I've installed fbpanel to see if there is anything noticably different, which there isn't. fbpabel uses struts and it a dock type window, yet manages to sit on the screen edge. -- Lucas Hazel <lu...@di...> |
From: Lucas H. <lu...@di...> - 2008-04-29 10:53:23
Attachments:
test.c
|
On Mon, 28 Apr 2008 09:02:43 +1000 Lucas Hazel <lu...@di...> wrote: > On Sun, 27 Apr 2008 15:06:24 +0100 > "Thomas Leonard" <ta...@gm...> wrote: > > > 2008/4/27 Lucas Hazel <lu...@di...>: > > > On Fri, 25 Apr 2008 23:24:52 +1000 > > > > > > Lucas Hazel <lu...@di...> wrote: > > > > > > > > > > > I just upgraded to compiz-fusion 0.7.4, and the panels come off > > > > the screen. > > > > Not sure if this a bug with ROX or compiz though. > > > > > > > > > > Here is a screenshot of the problem, > > > http://i27.tinypic.com/so1stu.jpg > > > > > > I'm almost certain this is a ROX related bug now. I did a quick > > > test to see how compiz handles dock type windows: > > > > > > #include <gtk/gtk.h> > > > > > > int main(int argc, char **argv) { > > > GtkWidget *panel; > > > gtk_init(&argc, &argv); > > > panel = gtk_window_new(GTK_WINDOW_TOPLEVEL); > > > gtk_window_set_type_hint(GTK_WINDOW(panel), > > > GDK_WINDOW_TYPE_HINT_DOCK); > > > gtk_widget_show(panel); > > > gtk_main(); > > > return 0; > > > } > > > > > > Under compiz this immediately put the window onto the edge of the > > > screen, made it sticky and ignored by pagers and tasklists. So > > > the only requirement under compiz to create a panel is to set the > > > dock type window hint. > > > > > > I've been playing with the X11 magic in gui_support.c and panel.c > > > but can't seem to pinpoint the cause. Is there anywhere else I > > > should be looking? Or any ideas what might cause this effect? > > > > Is panel_setup_struts() causing the problem? > > > > > > That was my immediate reaction because it looks like the panels are > being place outside of the struts. I turned off struts in the code and > sure enough the panels go to the edge, but this breaks the "do not > cover panel" option. I've installed fbpanel to see if there is > anything noticably different, which there isn't. fbpabel uses struts > and it a dock type window, yet manages to sit on the screen edge. I'm trying to come up with a minimal example of a dock type window with struts, but I can't get it to set the strut hints. I've attached the example, just wondering if there was something obvious I was missing? -- Lucas Hazel <lu...@di...> |
From: Lucas H. <lu...@di...> - 2008-05-08 05:26:57
|
On Tue, 29 Apr 2008 20:49:13 +1000 Lucas Hazel <lu...@di...> wrote: > On Mon, 28 Apr 2008 09:02:43 +1000 > Lucas Hazel <lu...@di...> wrote: > > > On Sun, 27 Apr 2008 15:06:24 +0100 > > "Thomas Leonard" <ta...@gm...> wrote: > > > > > 2008/4/27 Lucas Hazel <lu...@di...>: > > > > On Fri, 25 Apr 2008 23:24:52 +1000 > > > > > > > > Lucas Hazel <lu...@di...> wrote: > > > > > > > > > > > > > > I just upgraded to compiz-fusion 0.7.4, and the panels come > > > > > off the screen. > > > > > Not sure if this a bug with ROX or compiz though. > > > > > > > > > > > > > Here is a screenshot of the problem, > > > > http://i27.tinypic.com/so1stu.jpg > > > > > > > > I'm almost certain this is a ROX related bug now. I did a quick > > > > test to see how compiz handles dock type windows: > > > > > > > > #include <gtk/gtk.h> > > > > > > > > int main(int argc, char **argv) { > > > > GtkWidget *panel; > > > > gtk_init(&argc, &argv); > > > > panel = gtk_window_new(GTK_WINDOW_TOPLEVEL); > > > > gtk_window_set_type_hint(GTK_WINDOW(panel), > > > > GDK_WINDOW_TYPE_HINT_DOCK); > > > > gtk_widget_show(panel); > > > > gtk_main(); > > > > return 0; > > > > } > > > > > > > > Under compiz this immediately put the window onto the edge of > > > > the screen, made it sticky and ignored by pagers and tasklists. > > > > So the only requirement under compiz to create a panel is to > > > > set the dock type window hint. > > > > > > > > I've been playing with the X11 magic in gui_support.c and > > > > panel.c but can't seem to pinpoint the cause. Is there anywhere > > > > else I should be looking? Or any ideas what might cause this > > > > effect? > > > > > > Is panel_setup_struts() causing the problem? > > > > > > > > > > That was my immediate reaction because it looks like the panels are > > being place outside of the struts. I turned off struts in the code > > and sure enough the panels go to the edge, but this breaks the "do > > not cover panel" option. I've installed fbpanel to see if there is > > anything noticably different, which there isn't. fbpabel uses struts > > and it a dock type window, yet manages to sit on the screen edge. > > I'm trying to come up with a minimal example of a dock type window > with struts, but I can't get it to set the strut hints. I've attached > the example, just wondering if there was something obvious I was > missing? > I managed to get my minimal demo to work by setting the strut properties after the window is displayed, this has me thinking that the bug might have something to do with the order in which properties are set. I'm guessing some form of profiling is required for me to investigate this theory, something I've not really done before (rather than munging the code with debug statements). Is there a tool or technique that will make this task a bit easier for me that anyone can recommend? -- Lucas Hazel <lu...@am...> AMAC Digital Products Technician 209 Beardy Street, Armidale NSW [phone: +61267711287] |
From: Lucas H. <lu...@di...> - 2008-05-08 07:18:12
|
On Fri, 25 Apr 2008 23:24:52 +1000 Lucas Hazel <lu...@di...> wrote: > > I just upgraded to compiz-fusion 0.7.4, and the panels come off the > screen. > > ------------------------------- > Panel > ------------------------------- > GAP > ------------------------------- > Edge of screen > > My immediate reaction was to think that the panel struts aren't > playing nicely with compiz, and sure enough if I prevent > panel_setup_struts in panel.c from doing anything the panel are > positioned correctly, however the panels now get covered when > maximising. > > Not sure if this a bug with ROX or compiz though. > I just uploaded a video to youtube, top and left panels don't display the behaviour until a mouse over event. http://www.youtube.com/watch?v=V5UBkLCO5Gg -- Lucas Hazel <lu...@am...> AMAC Digital Products Technician 209 Beardy Street, Armidale NSW [phone: +61267711287] |
From: Tony H. <h...@re...> - 2008-05-12 18:13:55
|
In <20080427230938.3abf9f99@akira.digitilocal> Lucas Hazel <lu...@di...> wrote: > On Fri, 25 Apr 2008 23:24:52 +1000 > Lucas Hazel <lu...@di...> wrote: > > > I just upgraded to compiz-fusion 0.7.4, and the panels come off the > > screen. > > > > > > > Not sure if this a bug with ROX or compiz though. > > > > Here is a screenshot of the problem, http://i27.tinypic.com/so1stu.jpg > > I'm almost certain this is a ROX related bug now. I did a quick test > to see how compiz handles dock type windows: [Snip] > I've been playing with the X11 magic in gui_support.c and panel.c but > can't seem to pinpoint the cause. Is there anywhere else I should be > looking? Or any ideas what might cause this effect? I think it's compiz's fault. recalcWindowType() in window.c contains this: if (type == CompWindowTypeDockMask && (w->state & CompWindowStateBelowMask)) type = CompWindowTypeNormalMask; I disabled the bit of ROX that sets _NET_WM_STATE_BELOW (but I still think compiz is in the wrong, not ROX) and my panel stayed on the edge. I'm attaching a little patch. I'll report it on the compiz forums and/or bug tracker, but it could be a while before a fix is generally available so perhaps we should have an extra Compatibility option in ROX? -- TH * http://www.realh.co.uk |
From: Tony H. <h...@re...> - 2008-05-12 18:17:14
Attachments:
rox-disable-panel-below.diff
|
In <200...@ti...n> Tony Houghton <h...@re...> wrote: > I'm attaching a little patch. Which I promptly forgot. I'd also forgotten to reinstall claws-mail-attach-warner. -- TH * http://www.realh.co.uk |
From: Lucas H. <lu...@di...> - 2008-05-12 22:46:16
|
On Mon, 12 May 2008 19:16:38 +0100 Tony Houghton <h...@re...> wrote: > In <200...@ti...n> > Tony Houghton <h...@re...> wrote: > > > I'm attaching a little patch. > > Which I promptly forgot. I'd also forgotten to reinstall > claws-mail-attach-warner. > Fantastic. Looking at that compiz code makes me think it's their bug as well. A window is not allowed to be a dock if it's below state is set, seems silly to me. -- Lucas Hazel <lu...@di...> |
From: Thomas L. <ta...@gm...> - 2008-05-12 18:19:57
|
2008/5/12 Tony Houghton <h...@re...>: > In <20080427230938.3abf9f99@akira.digitilocal> > > Lucas Hazel <lu...@di...> wrote: > > > On Fri, 25 Apr 2008 23:24:52 +1000 > > Lucas Hazel <lu...@di...> wrote: > > > > > I just upgraded to compiz-fusion 0.7.4, and the panels come off the > > > screen. [...] > I think it's compiz's fault. recalcWindowType() in window.c contains > this: > > if (type == CompWindowTypeDockMask && (w->state & CompWindowStateBelowMask)) > type = CompWindowTypeNormalMask; > > I disabled the bit of ROX that sets _NET_WM_STATE_BELOW (but I still > think compiz is in the wrong, not ROX) and my panel stayed on the edge. > I'm attaching a little patch. > > I'll report it on the compiz forums and/or bug tracker, but it could be > a while before a fix is generally available so perhaps we should have an > extra Compatibility option in ROX? Good idea. Have you got a patch I can pull? -- Dr Thomas Leonard http://rox.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Tony H. <h...@re...> - 2008-05-12 18:45:59
|
In <cd5...@ma...> "Thomas Leonard" <ta...@gm...> wrote: > 2008/5/12 Tony Houghton <h...@re...>: > > > > I'll report it on the compiz forums and/or bug tracker, but it > > could be a while before a fix is generally available so perhaps we > > should have an extra Compatibility option in ROX? > > Good idea. Have you got a patch I can pull? I'll try to get around to it tonight. I wonder if we also ought to get rid of the panel_is_a_dock option and force it on, or at least make it default to on. Setting the DOCK type hint is the correct thing to do and I'm not sure why anyone would want to disable it. -- TH * http://www.realh.co.uk |
From: Tony H. <h...@re...> - 2008-05-12 21:41:58
Attachments:
rox-panel-on-top-option.diff
|
In <200...@ti...n> Tony Houghton <h...@re...> wrote: > I'll try to get around to it tonight. I wonder if we also ought to get > rid of the panel_is_a_dock option and force it on, or at least make it > default to on. Setting the DOCK type hint is the correct thing to do > and I'm not sure why anyone would want to disable it. Here's my patch to add a keep panel on top option. If you applied the previous patch revert it when you apply this. Reading the tooltip for the dock option I realised it could be to support window managers that are aware of the DOCK type hint but not the BELOW state, so I haven't deleted the option, but I have changed it to TRUE by default. -- TH * http://www.realh.co.uk |
From: Thomas L. <ta...@gm...> - 2008-05-13 18:07:40
|
2008/5/12 Tony Houghton <h...@re...>: > In <200...@ti...n> > > Tony Houghton <h...@re...> wrote: > > > I'll try to get around to it tonight. I wonder if we also ought to get > > rid of the panel_is_a_dock option and force it on, or at least make it > > default to on. Setting the DOCK type hint is the correct thing to do > > and I'm not sure why anyone would want to disable it. > > Here's my patch to add a keep panel on top option. If you applied the > previous patch revert it when you apply this. > > Reading the tooltip for the dock option I realised it could be to > support window managers that are aware of the DOCK type hint but not the > BELOW state, so I haven't deleted the option, but I have changed it to > TRUE by default. Applied, thanks! -- Dr Thomas Leonard http://rox.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Tony H. <h...@re...> - 2008-05-13 20:34:42
|
In <200...@ti...n> Tony Houghton <h...@re...> wrote: > I'll report it on the compiz forums and/or bug tracker, but it could > be a while before a fix is generally available so perhaps we should > have an extra Compatibility option in ROX? Apparently this is fixed in compiz git <http://forum.compiz-fusion.org/showthread.php?t=8323> but I'm not adventurous enough to try that (I couldn't get compiz to work at all until I switched from Debian to Ubuntu) so I'll stick with panel_on_top for the next 6 months. -- TH * http://www.realh.co.uk |
From: Lucas H. <lu...@di...> - 2008-05-13 22:03:03
|
On Tue, 13 May 2008 21:31:07 +0100 Tony Houghton <h...@re...> wrote: > In <200...@ti...n> > Tony Houghton <h...@re...> wrote: > > > I'll report it on the compiz forums and/or bug tracker, but it could > > be a while before a fix is generally available so perhaps we should > > have an extra Compatibility option in ROX? > > Apparently this is fixed in compiz git > <http://forum.compiz-fusion.org/showthread.php?t=8323> but I'm not > adventurous enough to try that (I couldn't get compiz to work at all > until I switched from Debian to Ubuntu) so I'll stick with > panel_on_top for the next 6 months. > I'll give it a go today, keep you posted. -- Lucas Hazel <lu...@di...> |
From: Samuel Dionne-R. <sa...@di...> - 2008-05-14 17:20:09
|
Le Mon, 12 May 2008 22:42:02 +0100, Tony Houghton a écrit : > In <200...@ti...n> Tony Houghton <h...@re...> > wrote: > >> I'll try to get around to it tonight. I wonder if we also ought to get >> rid of the panel_is_a_dock option and force it on, or at least make it >> default to on. Setting the DOCK type hint is the correct thing to do >> and I'm not sure why anyone would want to disable it. > > Here's my patch to add a keep panel on top option. If you applied the > previous patch revert it when you apply this. > > Reading the tooltip for the dock option I realised it could be to > support window managers that are aware of the DOCK type hint but not the > BELOW state, so I haven't deleted the option, but I have changed it to > TRUE by default. It may not be the place to ask, but how may I apply the said patch? Here's what I tried and what I got: samuel@HOMER:~/BENCH/test$ patch < patch patching file Options.xml patch: **** malformed patch at line 13: name='pinboard_forward_buttons_13' label='Pass all backdrop mouse samuel@HOMER:~/BENCH/test$ |
From: Tony H. <h...@re...> - 2008-05-14 18:37:39
|
In <g0dpta$g85$1...@ge...> Samuel Dionne-Riel <sa...@di...> wrote: > It may not be the place to ask, but how may I apply the said patch? > Here's what I tried and what I got: > > samuel@HOMER:~/BENCH/test$ patch < patch > patching file Options.xml > patch: **** malformed patch at line 13: > name='pinboard_forward_buttons_13' label='Pass all backdrop mouse It looks like your mail reader wrapped the text before you saved it. You need to save it as an attachment without formatting it. You need to be in the directory containing ROX-Filer and use the -p1 option with patch (or in the ROX-Filer directory and use -p2). But why not just pull from Thomas' git repository? -- TH * http://www.realh.co.uk |
From: Thomas L. <ta...@gm...> - 2008-05-15 17:00:20
|
2008/5/14 Tony Houghton <h...@re...>: > In <g0dpta$g85$1...@ge...> > Samuel Dionne-Riel <sa...@di...> wrote: > >> It may not be the place to ask, but how may I apply the said patch? [...] > But why not just pull from Thomas' git repository? Yep. Quick reminder of how to get and test the latest version of ROX-Filer: http://roscidus.com/desktop/using-git -- Dr Thomas Leonard http://rox.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Samuel Dionne-R. <sa...@di...> - 2008-05-15 17:57:00
|
Le Wed, 14 May 2008 19:37:27 +0100, Tony Houghton a écrit : > In <g0dpta$g85$1...@ge...> > Samuel Dionne-Riel <sa...@di...> wrote: > >> It may not be the place to ask, but how may I apply the said patch? >> Here's what I tried and what I got: >> >> samuel@HOMER:~/BENCH/test$ patch < patch patching file Options.xml >> patch: **** malformed patch at line 13: >> name='pinboard_forward_buttons_13' label='Pass all backdrop mouse > > It looks like your mail reader wrapped the text before you saved it. You > need to save it as an attachment without formatting it. > > You need to be in the directory containing ROX-Filer and use the -p1 > option with patch (or in the ROX-Filer directory and use -p2). > > But why not just pull from Thomas' git repository? Because I didn't think of that, didn't know it would be possible, and didn't know how to do it either (but I'm confident following http:// roscidus.com/desktop/using-git , I'll be able to do it) Anyway, is there currently a timeframe for an official 0install release of a test version of the latest ROX (with this patch)? |