headers
Thomas Leonard | 1 Feb 2003 15:43
Picon
Favicon

Re: ROX-Filer 1.3.5 + latest NVidia drivers (1.0-4191)

On Fri, Jan 31, 2003 at 09:24:37PM +0100, Olivier Fourdan wrote:
> John,
> 
> Most recent video cards are 3D capable and reserve some amount of
> onboard memory for 3D. As it seems, with recent NVidia drivers, the
> amount of memory left for pixmap is fairly small. What happens is that
> the video image f the backdrop doesn't fit in the video memory (although
> you might have tons of megs on the card, the fact is that this video
> memory is kept for 3D)
> 
> As the pixmap doesn't fit in video memory, XFree has to store it in the
> main memory and transfers are very slow between video<->system memory.
> That's why it looks so slow when you drag windows... 
> 
> Thomas,
> 
> You can easily fix that for the filer by turning off double buffering on
> the backdrop window. Since it's a gtk window, it has double buffering
> enabled by default, meaning that twice as much video memory is required
> (for almost nothing in that case since the window has no chance to be
> resized).

Unfortunately, turning off double buffering also completely messes up the
redrawing of the icons. My plan was to break the area down into smaller
tiles for drawing (see TODO note in pinboard.c:1493), possibly by
intersecting the redraw region with the occupied regions and then
redrawing all the rectangles in that.

However, since redraw is very fast on my machine, it's difficult to know
what will make a difference. I really need someone with a slow machine to
(Continue reading)

Permalink | Reply | 2 comments |
headers
Thomas Leonard | 1 Feb 2003 18:18
Picon
Favicon

Re: ROX-Filer 1.3.5 + latest NVidia drivers (1.0-4191)

On Sat, Feb 01, 2003 at 02:43:23PM +0000, Thomas Leonard wrote:
[ pinboard double-buffering ]
> Unfortunately, turning off double buffering also completely messes up the
> redrawing of the icons. My plan was to break the area down into smaller
> tiles for drawing (see TODO note in pinboard.c:1493), possibly by
> intersecting the redraw region with the occupied regions and then
> redrawing all the rectangles in that.

Well, I've done some experiments. Drawing each rectangle in the region
doesn't work well, because there are sometimes hundreds of 2x1 areas.
Dividing the area into tiles also doesn't work, because it's far too slow
(you can watch the tiles appearing!).

Instead, I've done as Olivier suggested and turned off double buffering.
The problems with this approach before turned out to be clipping related
(some of the drawing operations don't do their own clipping because they
assume the pixmap will get clipped as it's applied). I've tried to work
around those problems.

The new system might be slightly more flickery, but it should be a lot
faster for people with limited video memory (and probably faster for
everyone else too).

Probably needs lots of testing...

--

-- 
Thomas Leonard			http://rox.sourceforge.net
tal00r <at> ecs.soton.ac.uk		tal197 <at> users.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jim Knoble | 1 Feb 2003 21:11
Picon
Favicon

Re: ROX-Filer 1.3.5 + latest NVidia drivers (1.0-4191)

Circa 2003-02-01 14:43:23 +0000 dixit Thomas Leonard:

: However, since redraw is very fast on my machine, it's difficult to know
: what will make a difference. I really need someone with a slow machine to
: implement it ;-)

You can always run under something like bochs
( http://bochs.sourceforge.net/ ) to slow things down a bit.
Alternatively, temporarily turn off accelerated video drawing in your X
server (use 'Option "Accel" "off"' in the "Device" section).  You can
also slow down a system somewhat by reducing the amount of real memory
available (anyone know if modern Linux kernels accept the 'mem=' option
to specify less than the real amount of physical memory?).

Cheers.

--

-- 
jim knoble  |  jmknoble <at> pobox.com  |  http://www.pobox.com/~jmknoble/
(GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491)
"I am non-refutable."  --Enik the Altrusian
Permalink | Reply | 0 comments |
headers
Stuart Langridge | 2 Feb 2003 08:35

Re: scroll wheel in Rox-Edit

Thomas Leonard spoo'd forth:
>> The GtkTextView object, which is what Rox Edit uses for its text
>> editor, doesn't seem to receive mousewheel scroll events (which are
>> normally mapped to buttons 4 and 5 in X). Not sure why this is.
> 
> GDK remaps them to scroll events. I've added some code which might make it
> work, but it's rather hard to test without a wheel mouse...
> 
> (also the amount it scrolls by is probably wrong... edit the
> scroll_event() function in EditWindow.py:222).

It seems to scroll by the right amount. One tiny change to the code:
scroll_event gets passed two parameters, what the textview object that
you're scrolling on is and the event, so the definition of scroll_event
needs to be scroll_event(self,text,event). Then it works perfectly.

sil

--

-- 
Penelope Pitstop: Ohhh, it's my arch enemy, the Hooded Claw!
The Hooded Claw: Who did you expect? Dick Dastardly?
           -- The Perils of Penelope Pitstop, "Jungle Jeopardy"
Permalink | Reply | 0 comments |
headers
Thomas Leonard | 2 Feb 2003 16:29
Picon
Favicon

Re: Archiver locking up

On Wed, Jan 29, 2003 at 01:38:11PM +0100, Guido Schimmels wrote:
> On Wed, 29 Jan 2003 11:22:58 +0000
> Thomas Leonard <tal00r <at> ecs.soton.ac.uk> wrote:
> 
> > Guido, do you still have the problem with the changed version?
> 
> Sorry, your fix didn't make a difference.

The stange thing is, it works for me on both the desktop (Debian/unstable
with Gtk+-2.2.0) and on a laptop (Debian/testing with Gtk+-2.0.6).

What does iowatch_marshal() (gobjectmodule.c:1312) return?

	...
		g_print("iowatch_marshal: returned %d\n", res);
		return res;
	}

--

-- 
Thomas Leonard			http://rox.sourceforge.net
tal00r <at> ecs.soton.ac.uk		tal197 <at> users.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
Permalink | Reply | 0 comments |
headers
Thomas Leonard | 2 Feb 2003 18:13
Picon
Favicon

ROX-Lib 1.9.6

New ROX-Lib:

	http://rox.sourceforge.net/rox_lib.php3

Just a few minor changes:

- Make the default window class the name of the application directory, not
  'AppRun' (suggested by Albert Wagner).

- With pygtk-1.99.14, only the first error message from a process would be
  detected; this meant that ROX-Lib wouldn't detect when the process quit
  (reported by joehill). Two reports that this still isn't fixed, although
  it did fix it on both of my machines...

- <hbox> and <vbox> layouts didn't work in the options box (Allen
  Leonard).

- If python is too old, raise SystemExit instead of quitting.

- Ensure that True and False are defined.

- Work around bug in some versions of pygtk that stopped the options
  window from working.

--

-- 
Thomas Leonard			http://rox.sourceforge.net
tal00r <at> ecs.soton.ac.uk		tal197 <at> users.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
(Continue reading)

Permalink | Reply | 0 comments |
headers
Olivier Ripoll | 3 Feb 2003 11:24
Picon

Re: What is "file(1) says.." in File->info?

Albert Wagner wrote:

> On Friday 31 January 2003 3:25 pm, Olivier Ripoll wrote:
> <snip>
>
> Thanks for your reply, Olivier.
>
> > IIRC too, Rox does not use "file" to set the icon, so you must rely
> > on the mime-type.
>
> How does Rox decide the mime-type?
>
> > the only way to distinguish your perl script from a bash
> > script is to name it blabla.pl instead of blabla.sh.
> >
> Sorry, but I am still confused.  I just added a .pl extension to a
> perl script(first line: #!/usr/bin/perl ) and its info remained the
> same.
>
> Please have patience. I am sometimes a little slow on the uptake.
>
> Albert

Okay, here are more information about your question, and this time it is
accurate, as I did it this weekend on my linux box.

In your home directory, there should be a ".mime" directory, containing a
"packages" directory. Here you should find an xml file called rox.xml. If
not, create it based on the one found in /usr/share/mime(or
mime-types)/packages or on the freedesktop.xml one
(Continue reading)

Permalink | Reply | 1 comment |
headers
Thomas Leonard | 3 Feb 2003 11:34
Picon
Favicon

Re: What is "file(1) says.." in File->info?

On Mon, Feb 03, 2003 at 11:24:02AM +0100, Olivier Ripoll wrote:
[...]
> Okay, here are more information about your question, and this time it is
> accurate, as I did it this weekend on my linux box.
> 
> In your home directory, there should be a ".mime" directory, containing a
> "packages" directory. Here you should find an xml file called rox.xml. If
> not, create it based on the one found in /usr/share/mime(or
> mime-types)/packages or on the freedesktop.xml one
> 
> Here is my file (the dashed lines are not in the file itself!)
> ----------------------------------------------------------------
> <?xml version="1.0"?>
> <mime-info xmlns='http://www.freedesktop.org/standards/shared-mime-info'>
> 
>   <mime-type type="application/vnd.blender">
>     <comment>Blender 3D model</comment>
>     <comment xml:lang="fr">Modele 3D Blender</comment>
>     <glob pattern="*.blend"/>
>     <glob pattern="*.Blend"/>
>     <glob pattern="*.BLEND"/>

Pattern matching is done twice: first case sensitive and then not, so you
only need one of these three.

> Okay, so what can be seen. There may be a few errors, like the xmlns
> pointing to freedesktop, but this is not important.

It's vital, actually. Otherwise, update-mime-database won't know that this
is the <mime-type> element as defined at freedesktop.org... it might think
(Continue reading)

Permalink | Reply | 0 comments |
headers
Albert Wagner | 3 Feb 2003 10:17

Dir in Apps dir

Perhaps I was up too late last night, but I have a situation that I am 
totally baffled by.  How does a regular directory get changed into an 
App?  I have a regular directory in my Apps directory(/usr/apps).  The 
regular directory contains AppIcon.xpm, AppInfo.xml, and AppRun.  Yet, 
it acts like a regular directory and in the detail view its type is Dir 
rather than App.
Permalink | Reply | 12 comments |
headers
Thomas Leonard | 3 Feb 2003 16:37
Picon
Favicon

Re: Dir in Apps dir

On Mon, Feb 03, 2003 at 03:17:58AM -0600, Albert Wagner wrote:
> Perhaps I was up too late last night, but I have a situation that I am 
> totally baffled by.  How does a regular directory get changed into an 
> App?  I have a regular directory in my Apps directory(/usr/apps).  The 
> regular directory contains AppIcon.xpm, AppInfo.xml, and AppRun.  Yet, 
> it acts like a regular directory and in the detail view its type is Dir 
> rather than App.

AppRun must be an executable with the same owner as the directory
containing it.

--

-- 
Thomas Leonard			http://rox.sourceforge.net
tal00r <at> ecs.soton.ac.uk		tal197 <at> users.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
Permalink | Reply | 11 comments |

Gmane