rox-devel

RE: [rox-devel] Scrolling the panel

[Tom H. <tac...@ta...>]

> > > > 4. Scroll when the pointer gets near the end (RISC OS style).
> > >
> > > This worked really well - so long as it works smoothly and quickly
> > > (nothing worse than waiting for it to chunder along at one 
pixel/second).
> >
> > OK. I was hoping to skip 4 though, as it's the hardest to implement ;-)
> >
> > > Some sort of indication at either end of the panel showing that there 
is
> > > stuff off the edge of the screen would also be useful (purhaps a 
small
> > > arrow in the appropriate top corner of the panel?)
> >
> > Hmm, but if we're adding an arrow without making the bar shorter then 
we
> > might as well have click-to-scroll on the little arrow...
>
> Thats true, but remember thingie's (can't remember his name, sorry) law 
of
> GUI useability. A corner is easier to hit than a space or a side of the

Fitz, IIRC. (I have just finished Jef Raskin's the Humane Interface which 
is quite a good read - it suggests getting rid of fillers amongst other 
things.) Time taken to position pointer is roughly proportional to the log 
of the ratio of distance to and perceived distance across figure (distances 
along the same line). Edge of screen is good because experienced users move 
the mouse way over the required distance. The little resize triangles in 
some schemes doesn't work well, because the distance across is tiny when 
coming from the center of its window.

The time taken and speed of the RISC OS iconbar scrolling irritated me. I 
think to do it well you need to detect the retardation of the pointer as it 
is about to stop in the scroll zone. Sitting there and waiting because any 
shorter time might indicate that the pointer is about to leave is not good 
enough, IMHO. Perhaps some subtle indication of when the scroll is about to 
come would be helpful.

Tackline

Re: [rox-devel] Scrolling the panel

[Thomas L. <ta...@le...>]

On Mon, 28 Aug 2000, Garrett C wrote:

> > Hmm, but if we're adding an arrow without making the bar shorter then we
> > might as well have click-to-scroll on the little arrow...
> 
> Thats true, but remember thingie's (can't remember his name, sorry) law of
> GUI useability. A corner is easier to hit than a space or a side of the
> screen, and smaller objects are harder to hit than large ones.  Therefore
> if the little arrows are the solution and are to be used as buttons, they 
> should be in the corners of the screen (bottom corners of the panel).
> 
> I take it that it would be possible to add an arrow without the need to
> resize the bar?

Good points. A super-imposed arrow that only appears when the bar can
scroll should be OK. I reckon we could make it quite large too - about a
quarter of the bar's height, say?

> The other option, of course, would be to constantly have an invisible
> border at each end of the panel, which turns into a gnome-style arrow when
> needed.  Which would solve the problem of the arrow being too small to hit
> with the mouse reliably, too.

Possibly, but maybe confusing?

Anyway, I've added the ability to drag it by the background - that's now
in CVS. Unless anyone objects, I'll look into adding arrows too...


Thomas Leonard
-- 
tal197 at users.sourceforge.net
The ROX desktop (free/GPL) : http://rox.sourceforge.net

Re: [rox-devel] maintainers

[Andy P. <squ...@uk...>]

Thomas Leonard wrote:
> 
> Speaking of which, we need to aquire some binary-maintainers and packagers
> for the eventual 1.0.0 release - any offers?

Well, I'm up for it - RedHat anyway - although I've not
fulfilled the role before, so I'd have to have a look at it
first and see what is required.

-- 
Andy Piper - Fareham, Hampshire (UK) 
and...@fr...    |  an...@un...
* OpenUT for Linux       |  http://openut.sourceforge.net
* Unreal Tournament News |  http://www.unrealtournament.org

Re: [rox-devel] Scrolling the panel

[Garrett C <ga...@cs...>]

<snip>
 
> > > 4. Scroll when the pointer gets near the end (RISC OS style).
> > 
> > This worked really well - so long as it works smoothly and quickly
> > (nothing worse than waiting for it to chunder along at one pixel/second).
> >
> > How about a combination of 3 and 4? If the mouse is at the edge, the panel
> > scrolls.  However, the option is also there to grab it by a spare space
> > and scroll it yourself at your own speed.
> 
> OK. I was hoping to skip 4 though, as it's the hardest to implement ;-)
> 
> > Some sort of indication at either end of the panel showing that there is
> > stuff off the edge of the screen would also be useful (purhaps a small
> > arrow in the appropriate top corner of the panel?)
> 
> Hmm, but if we're adding an arrow without making the bar shorter then we
> might as well have click-to-scroll on the little arrow...

Thats true, but remember thingie's (can't remember his name, sorry) law of
GUI useability. A corner is easier to hit than a space or a side of the
screen, and smaller objects are harder to hit than large ones.  Therefore
if the little arrows are the solution and are to be used as buttons, they 
should be in the corners of the screen (bottom corners of the panel).

I take it that it would be possible to add an arrow without the need to
resize the bar?

The other option, of course, would be to constantly have an invisible
border at each end of the panel, which turns into a gnome-style arrow when
needed.  Which would solve the problem of the arrow being too small to hit
with the mouse reliably, too.

Chris.

Re: [rox-devel] Scrolling the panel

[Thomas L. <ta...@le...>]

On Mon, 28 Aug 2000, Garrett C wrote:

> > 1. Add some kind of scrollbar when it gets too long,
> 
> Ugly - I don't like it when a scrollbar suddenly decides to appear from
> nowhere, and the panel would have to resize itself vertically as a result.

I agree, although it doesn't have to be a full sized scrollbar. It could
just be a 'grab bar' running along the top which you can drag.
 
> > 2. Put arrows at each end,
> 
> I dont like this, for the same reason you give below and because it is,
> again, not a good-looking solution

OK.
 
> > 3. Hold the mouse button down on a blank area and drag it back and forth,
> 
> If the panel is so full that it needs to scroll, mightn't it be a little
> awkward to find a blank area (especially if partially-transparent icons
> are used so their borders are not clear)?

The gap in the middle will always work for scrolling, so it's only a
problem if your bar is so full that one side takes up more than a screen
width. In which case you've got problems anyway, 'cos then there's no way
to easily add stuff to the bar ;-)

> > 4. Scroll when the pointer gets near the end (RISC OS style).
> 
> This worked really well - so long as it works smoothly and quickly
> (nothing worse than waiting for it to chunder along at one pixel/second).
>
> How about a combination of 3 and 4? If the mouse is at the edge, the panel
> scrolls.  However, the option is also there to grab it by a spare space
> and scroll it yourself at your own speed.

OK. I was hoping to skip 4 though, as it's the hardest to implement ;-)

> Some sort of indication at either end of the panel showing that there is
> stuff off the edge of the screen would also be useful (purhaps a small
> arrow in the appropriate top corner of the panel?)

Hmm, but if we're adding an arrow without making the bar shorter then we
might as well have click-to-scroll on the little arrow...

> Or, some other solutions (I still prefer my suggestion above though):
> 1. The panel doubles its height to include more icons

Not with the current layout code!

> 2. The icons are scaled down to fit in, eventually taking up two rows when
> they are small enough
> 
> But both of these suggestions have finite limits to the number of icons
> possible, unlike scrolling.

I'm not sure whether we need to support infinitly long bars, though. I see
scrolling as being mainly useful when you've just added a couple too many
icons, or if you find yourself in a lower-res mode than usual. Maybe other
people will want to use the bar differently, though.

> > BTW, can I take the deafening silence over the new event system to mean
> > that it works perfectly?
> 
> If this is only in CVS, then I haven't had a chance to look at it yet -
> sorry!

I thought this was probably what had happened! Well, I hope someone tests
it before the next release!

Speaking of which, we need to aquire some binary-maintainers and packagers
for the eventual 1.0.0 release - any offers?


Thomas Leonard
-- 
tal197 at users.sourceforge.net
The ROX desktop (free/GPL) : http://rox.sourceforge.net

Re: [rox-devel] Scrolling the panel

[Garrett C <ga...@cs...>]

Hi,

On Mon, 28 Aug 2000, Thomas Leonard wrote:

> Anyone got any thoughts on how panel scrolling should work?
> 
> My list of possibilities so far is:
> 
> 1. Add some kind of scrollbar when it gets too long,

Ugly - I don't like it when a scrollbar suddenly decides to appear from
nowhere, and the panel would have to resize itself vertically as a result.

> 2. Put arrows at each end,

I dont like this, for the same reason you give below and because it is,
again, not a good-looking solution
 
> 3. Hold the mouse button down on a blank area and drag it back and forth,

If the panel is so full that it needs to scroll, mightn't it be a little
awkward to find a blank area (especially if partially-transparent icons
are used so their borders are not clear)?

> 4. Scroll when the pointer gets near the end (RISC OS style).

This worked really well - so long as it works smoothly and quickly
(nothing worse than waiting for it to chunder along at one pixel/second).
 
> 
> (2) has the problem that adding the arrows will make the bar even shorter,
> which means that you might not be able to get rid of them again just by
> removing whatever it was that made them appear...
> 
> Anyone got a preference?

How about a combination of 3 and 4? If the mouse is at the edge, the panel
scrolls.  However, the option is also there to grab it by a spare space
and scroll it yourself at your own speed.

Some sort of indication at either end of the panel showing that there is
stuff off the edge of the screen would also be useful (purhaps a small
arrow in the appropriate top corner of the panel?)

Or, some other solutions (I still prefer my suggestion above though):
1. The panel doubles its height to include more icons
2. The icons are scaled down to fit in, eventually taking up two rows when
they are small enough

But both of these suggestions have finite limits to the number of icons
possible, unlike scrolling.

> BTW, can I take the deafening silence over the new event system to mean
> that it works perfectly?

If this is only in CVS, then I haven't had a chance to look at it yet -
sorry!


Hope the above helps!

Chris

[rox-devel] Scrolling the panel

[Thomas L. <ta...@le...>]

Anyone got any thoughts on how panel scrolling should work?

My list of possibilities so far is:

1. Add some kind of scrollbar when it gets too long,

2. Put arrows at each end,

3. Hold the mouse button down on a blank area and drag it back and forth,

4. Scroll when the pointer gets near the end (RISC OS style).


(2) has the problem that adding the arrows will make the bar even shorter,
which means that you might not be able to get rid of them again just by
removing whatever it was that made them appear...

Anyone got a preference?


BTW, can I take the deafening silence over the new event system to mean
that it works perfectly?


Thomas Leonard
-- 
tal197 at users.sourceforge.net
The ROX desktop (free/GPL) : http://rox.sourceforge.net

[rox-devel] Event handling

[Thomas L. <ta...@le...>]

I've moved all the filer and pinboard code over to the new event handling
system in bind.c. Which means, basically, the mess is all in one place now
;-)

So, all those people who want to play with single-click / double-click /
which-button-does-what stuff can have a play in there without worrying
too much about pointer grabs and syncing pinboard, filer and panel code.

On the other hand, I've probably broken some stuff, so it all needs lots
of testing, especially by people who don't use the standard bindings!


In terms of user-visible changes:

- Mouse bindings now have their own section in Options.
- In single-click mode you can navigate without selecting anything (and,
  therefore, without losing the selection).


Other changes:

- The toolbar buttons are slightly larger (so they look better).
- When you use target mode the toolbar displays some text
  (eg 'Rename ... ?') so you don't forget what you're doing!


CVS has the latest version now; the snapshot will update within 24 hours.


Thomas Leonard
-- 
tal197 at users.sourceforge.net
The ROX desktop (free/GPL) : http://rox.sourceforge.net

Re: [rox-devel] icons

[Thomas L. <ta...@le...>]

On Wed, 16 Aug 2000, Garrett C wrote:

> How close is ROX to a 1.0.0 release atm, btw?

Well, I need to finish the new panel code, but that's mostly done (I'd
like to be able to drag *from* the panel as well as to).

We need to sort out the behaviour code too. For the panel, I've routed it
all through the new bind.c file, which takes a mouse event and decides how
to respond. The goal is to make directories and the pinboard use the same
system; then we can configure things like single-click navigation all in
one place.

So, at least one more devel release, then update translations and check
docs and then probably a pre-release with binaries so we get more testers
before the final release...


Thomas Leonard
-- 
tal197 at users.sourceforge.net
The ROX desktop (free/GPL) : http://rox.sourceforge.net

Re: [rox-devel] Initial filer window height patch

[Thomas L. <ta...@le...>]

On Fri, 18 Aug 2000, James Kermode wrote:

> Some time ago I suggested an option to set the initial
> height of filer windows, as I often found that I had to
> resize them immediatly after opening them. Now, I've
> finally got round to doing it!

This patch looks excellent - I've applied it and committed it to CVS.

The new version also allows panel icons to be repositioned - drag them
with the middle button, like with the pinboard.

> BTW, the rox postscript manual seems to have disappered from
> the current CVS release.

There aren't any computer-generated files in CVS (it's a waste of space
keeping track of changes in the postscript as well as the lyx source).

I usually only update the manual before doing a release anyway...


Thanks,

Thomas Leonard
-- 
tal197 at users.sourceforge.net
The ROX desktop (free/GPL) : http://rox.sourceforge.net

[rox-devel] Initial filer window height patch

[James K. <ja...@ke...>]

Hi,

Some time ago I suggested an option to set the initial
height of filer windows, as I often found that I had to
resize them immediatly after opening them. Now, I've
finally got round to doing it!

This patch adds a new adjustment bar named 'Initial window
height' to the 'Filer window' options section. This
specifies the default height of new filer windows, in rows
of icons.

Let me know if the patch below (made using today's CVS
release) works for anyone else! It's my first contribution
to an open source project, so let me know if I've broken
any coding conventions or anything.

BTW, the rox postscript manual seems to have disappered from
the current CVS release.

Here it is (I've just included the parts that affect source
files, not all the config and Makefiles etc.):

diff -urN oldsrc/filer.c src/filer.c
--- oldsrc/filer.c	Fri Aug 18 16:11:55 2000
+++ src/filer.c	Fri Aug 18 17:15:49 2000
@@ -73,6 +73,7 @@
 static char *filer_unique_windows(char *data);
 static char *filer_menu_on_2(char *data);
 static char *filer_new_window_on_1(char *data);
+static char *filer_initial_window_height(char *data);
 
 static OptionsSection options =
 {
@@ -86,10 +87,12 @@
 gboolean o_single_click = TRUE;
 gboolean o_new_window_on_1 = FALSE;	/* Button 1 => New window */
 gboolean o_unique_filer_windows = FALSE;
+gint o_initial_window_height = 3;
 static GtkWidget *toggle_single_click;
 static GtkWidget *toggle_new_window_on_1;
 static GtkWidget *toggle_menu_on_2;
 static GtkWidget *toggle_unique_filer_windows;
+static GtkAdjustment *adj_initial_window_height;
 
 /* Static prototypes */
 static void attach(FilerWindow *filer_window);
@@ -131,6 +134,7 @@
 	option_register("filer_menu_on_2", filer_menu_on_2);
 	option_register("filer_single_click", filer_single_click);
 	option_register("filer_unique_windows", filer_unique_windows);
+	option_register("filer_initial_window_height", filer_initial_window_height);
 
 	busy_cursor = gdk_cursor_new(GDK_WATCH);
 }
@@ -953,7 +957,7 @@
 
 	{
 		GtkWidget	*vbox;
-		int		col_height = ROW_HEIGHT_LARGE * 3;
+		int		col_height = ROW_HEIGHT_LARGE * o_initial_window_height;
 
 		gtk_signal_connect(GTK_OBJECT(collection),
 				"key_press_event",
@@ -1051,7 +1055,7 @@
  */
 static GtkWidget *create_options(void)
 {
-	GtkWidget	*vbox;
+	GtkWidget	*vbox, *hbox, *label, *scale;
 
 	vbox = gtk_vbox_new(FALSE, 0);
 	gtk_container_set_border_width(GTK_CONTAINER(vbox), 4);
@@ -1093,6 +1097,20 @@
 	gtk_box_pack_start(GTK_BOX(vbox), toggle_unique_filer_windows,
 			FALSE, TRUE, 0);
 
+	adj_initial_window_height = GTK_ADJUSTMENT(gtk_adjustment_new(o_initial_window_height,
+								2, 10, 1, 2, 0));
+	hbox = gtk_hbox_new(FALSE, 0);
+	gtk_box_pack_start(GTK_BOX(vbox), hbox, FALSE, TRUE, 0);
+	label = gtk_label_new(_("Initial window height"));
+	gtk_box_pack_start(GTK_BOX(hbox), label, FALSE, TRUE, 0);
+	scale = gtk_hscale_new(adj_initial_window_height);
+	gtk_scale_set_value_pos(GTK_SCALE(scale), GTK_POS_LEFT);
+	gtk_scale_set_digits(GTK_SCALE(scale), 0);
+	gtk_box_pack_start(GTK_BOX(hbox), scale, TRUE, TRUE, 0);
+	OPTION_TIP(scale, 
+		_("This option sets the initial height of filer windows, "
+		  "in rows of icons."));
+	
 	return vbox;
 }
 
@@ -1108,6 +1126,7 @@
 	gtk_toggle_button_set_active(
 			GTK_TOGGLE_BUTTON(toggle_unique_filer_windows),
 			o_unique_filer_windows);
+	gtk_adjustment_set_value(adj_initial_window_height, o_initial_window_height);
 }
 
 /* Set current values by reading the states of the widgets in the options box */
@@ -1126,16 +1145,24 @@
 			GTK_TOGGLE_BUTTON(toggle_unique_filer_windows));
 
 	collection_single_click = o_single_click ? TRUE : FALSE;
+	
+	o_initial_window_height = adj_initial_window_height->value;
 }
 
 static void save_options()
 {
+	guchar *str;
+	
 	option_write("filer_new_window_on_1", o_new_window_on_1 ? "1" : "0");
 	option_write("filer_menu_on_2",
 			collection_menu_button == 2 ? "1" : "0");
 	option_write("filer_single_click", o_single_click ? "1" : "0");
 	option_write("filer_unique_windows",
 			o_unique_filer_windows ? "1" : "0");
+			
+	str = g_strdup_printf("%d", o_initial_window_height);
+	option_write("filer_initial_window_height", str);
+	g_free(str);
 }
 
 static char *filer_new_window_on_1(char *data)
@@ -1160,6 +1187,12 @@
 static char *filer_unique_windows(char *data)
 {
 	o_unique_filer_windows = atoi(data) != 0;
+	return NULL;
+}
+
+static char *filer_initial_window_height(char *data)
+{
+	o_initial_window_height = atoi(data);
 	return NULL;
 }

-- 
James Kermode
ja...@ke...
http://www.kerm.freeserve.co.uk

[rox-devel] Panel support

[Thomas L. <ta...@le...>]

I've committed the new panel code to CVS. It's mostly finished and should
be usable, although you can't reorder the icons yet (but then, you
couldn't do that before either ;-)

The CVS snapshot should update within 24 hours.

The new system works like the pinboard:

	$ rox --bottom MyPanel

creates a new bottom-panel called MyPanel, which you can then drag icons
to. The config is stored in Choices. You can now place mount points on the
panel and you can choose which side to put icons on.


Thomas Leonard
-- 
tal197 at users.sourceforge.net
The ROX desktop (free/GPL) : http://rox.sourceforge.net

Re: [rox-devel] icons

[Garrett C <ga...@cs...>]

On Wed, 16 Aug 2000, Thomas Leonard wrote:

> On Sun, 6 Aug 2000, Garrett C wrote:
> 
> [ ... ]
> 
> > I was looking at a few screenies of Nautilus the other day, and I noticed
> > what may be a similar feature, but extending it somewhat. Directories and
> > files appeared to have extra images overlaid in some cases, to indicate
> > properties such as 'draft', or 'proof-read'.  Having the ability to
> > overlay specified icons on certain files/directories could be a neat
> > feature.
> 
> I've been thinking for a while about having some system of storing
> selections in named registers. All that would be needed then would be a
> way to specify an icon for each register and that icon would be shown over
> all members.
> 

Thats sounds like a good approach.

> This would perhaps involve some kind of 'paint' mode where you can click
> on file to toggle them in and out of the group (need some better
> terminology, though!).
> 

Possibly a dialog brought up from the menu, showing a choice of
groups. The group would be selected, and then the user could just click on
the files he wants to select.  Normal selecting of files, and
rubber-banding selections would of course be available.  And an option to
add a group of your own devising.

> One nice idea would be to store these groups of files inside Choices in a
> form that other utilities could parse. Then, you could have a
> 'to-be-deleted' group (with a big red X over each file included) and have
> a cron script remove them periodically. Or, similarly, a 'to-be-archived'
> group.

I like that.  Consideration might need to be made for some files being in
two groups...either that or limit the user to one group per file.

> 
> This would have to be post-1.0.0 though...

Yes, it is quite a major addition and not really a function that could be
considered fundamental to a filemanager.

How close is ROX to a 1.0.0 release atm, btw?

Cheers,

Chris.

Re: [rox-devel] icons

[Thomas L. <ta...@le...>]

On Sun, 6 Aug 2000, Garrett C wrote:

[ ... ]

> I was looking at a few screenies of Nautilus the other day, and I noticed
> what may be a similar feature, but extending it somewhat. Directories and
> files appeared to have extra images overlaid in some cases, to indicate
> properties such as 'draft', or 'proof-read'.  Having the ability to
> overlay specified icons on certain files/directories could be a neat
> feature.

I've been thinking for a while about having some system of storing
selections in named registers. All that would be needed then would be a
way to specify an icon for each register and that icon would be shown over
all members.

This would perhaps involve some kind of 'paint' mode where you can click
on file to toggle them in and out of the group (need some better
terminology, though!).

One nice idea would be to store these groups of files inside Choices in a
form that other utilities could parse. Then, you could have a
'to-be-deleted' group (with a big red X over each file included) and have
a cron script remove them periodically. Or, similarly, a 'to-be-archived'
group.

This would have to be post-1.0.0 though...


Thomas Leonard
-- 
tal197 at users.sourceforge.net
The ROX desktop (free/GPL) : http://rox.sourceforge.net

Re: [rox-devel] Re: Panel

[Thomas L. <ta...@le...>]

On Thu, 10 Aug 2000, Garrett C wrote:

[ new panel ]
> That does sound a lot better! Refering back to an earlier thread, could
> the file in Choices be designed so that it can store a path for the icon
> of each item? Thus mount points could be made to look like dsk drives etc
> if you so wished.

This probably isn't the right place to do it... /mnt/floppy should look
the same on the pinboard, on a panel or in a filer window, IMHO.

> > But, if anyone wants a list of simple utils that need writing, just let me
> > know ;-)
> 
> Maybe in October - my dissertation is pretty rough atm. But what sort of
> utils have you thought of?

We need a few bits and pieces... like:

- A Printer icon which you can drop files on to print. This could be as
  simple as a script that does `lpr "$@"' or something more powerful with
  options to choose the printer, view the queue, preview in gv, etc.

- An 'Outbox' program which you can drop a file onto to email it.
  It would popup a box asking for the address and other header
  fields. This would be an excellent demo of the drag-and-drop system,
  since you could then use any text editor for sending email!

- Improvements to Archive (such as a visible indication of when it's
  extracting).

And so on... any takers?


Thomas Leonard
-- 
ta...@us...
The ROX desktop (free/GPL) : http://rox.sourceforge.net

[rox-devel] Re: rox-filer bug

[Vladimir K. <un...@rz...>]

Hi,

Thomas Leonard wrote:

> Well, actually, there isn't any regexp code ;-) I just copied the file
> straight from GNOME...

Heheh, you've got me on this one... :))

> However, there is a possible solution to the .tar.gz problem in the TODO
> file - try matching on each dot in turn (.tar.gz, then .gz) which would
> work in this case, but not for things like `Makefile'.

This would be very nice. Could get all that compressed Postscript show up
right at last.

> > Another minor issue is binding keys to menu items. Binding something a ?
> > makes a "shft-?" show beside the item. Shouldn't it rather be "?" or
> > "shft-/" ?

Alright, I can live with that. :)

Vladimir
-- 
Vladimir Klebanov  --	un...@rz...
			http://www.uni-karlsruhe.de/~unny
"To be natural is such a very difficult pose to keep up." -- Wilde

[rox-devel] Re: rox-filer bug

[Thomas L. <ta...@le...>]

On Thu, 10 Aug 2000, Vladimir Klebanov wrote:

> Thomas,
> 
> Here are two issues with ROX-Filer:
> 
> I cannot get a .tar.gz file to be recognized as something more meaningful
> than just a plain app/x-gunzip. A .tgz works fine. Is it possible that the
> regex evaluation code is broken? I saw that Choices/MIME-info/Standard _has_
> (regex) rules for dealing with that by default.

Well, actually, there isn't any regexp code ;-) I just copied the file
straight from GNOME...

There won't be any regexp stuff until the next version of glib is out
(otherwise, I'll have to do it all twice). Also, I'm quite worried about
the potential speed hit of matching thousands of files against a dozen or
so expressions.

However, there is a possible solution to the .tar.gz problem in the TODO
file - try matching on each dot in turn (.tar.gz, then .gz) which would
work in this case, but not for things like `Makefile'.

> Another minor issue is binding keys to menu items. Binding something a ?
> makes a "shft-?" show beside the item. Shouldn't it rather be "?" or
> "shft-/" ?

I think we need the shft+ bit, otherwise people will get most
confused! And shft-/ isn't to easy to locate on the keyboard if you were
expecting `?' (but easier if you really wanted shft+/, of course!).

Anyway, it's not my problem ;-) It's part of Gtk+; Gimp is the same...


Thomas Leonard
-- 
ta...@us...
The ROX desktop (free/GPL) : http://rox.sourceforge.net

[rox-devel] Re: Panel

[Garrett C <ga...@cs...>]

> > Would changing the panel to be more pinboard-like alter anything for the
> > user, or just make future programming easier?
> 
> The differences would be:
> 
> - The panel setup would be stored in a file in Choices like the pinboard,
>   rather than as a directory. There would then be no need for Refresh,
>   Open As Directory or Show Hidden on the menu. This also means less
>   clutter in users' home directories.
> 
> - The little symlink arrows would disappear, which would look much better.
> 
> - You could lay things out differently - eg, putting drives on the left
>   and apps on the right (depending on how we implement it - need to
>   think about this).
> 
> - Mount points could go there, because they wouldn't have to be symlinks.
> 
> - A system admin could use Choices to make a system-wide default panel.
>

That does sound a lot better! Refering back to an earlier thread, could
the file in Choices be designed so that it can store a path for the icon
of each item? Thus mount points could be made to look like dsk drives etc
if you so wished.
 
> > ps. feature request: Any chance of gnome applets working on the
> > iconbar? That would add another nice functionality of RiscOS to ROX.
> 
> Depends how they communicate with the filer. Does anyone know how it
> works? If it's via X-properties then we can probably support them; if it's
> CORBA then probably not...
> 

It does appear to be CORBA from the tutorial on the gnome website.

> AfterStep dock applets might be easier to support though...
> 
> > I was thinking of starting my coding life in Linux by reproducing the
> > mode-changer thing RiscOS has, although I'm not sure how feasable that
> > would be. I haven't time at the moment, however :o(
> 
> I don't think it's possible without resetting the X server. Unless you
> just mean simulating the alt-kp-plus and alt-kp-minus functions.

Those were my thoughts.  You'd still need to set up the various modes
first in XF86Config or whatever, but once they were set up they could be
changed.

> 
> But, if anyone wants a list of simple utils that need writing, just let me
> know ;-)

Maybe in October - my dissertation is pretty rough atm. But what sort of
utils have you thought of?

Chris.

[rox-devel] Panel

[Thomas L. <ta...@le...>]

On Tue, 8 Aug 2000, Garrett C wrote:

> Is the pinboard a completely seperate system from the window code,
> then? This would make sense since the code would be more focused.

Some of the drag-and-drop code is shared, but that's about it. The
pinboard shows the contents of a file in a free-form manner, while filer
windows show a directory in a sorted layout. Panels would be sort of
in-between the two.

> I only
> ask because the other environment I follow the development of
> (enlightenment) just has the pinboard as a big window that is always
> behind everything else, without any decorations. There were a few problems
> with that - conflicts with gnome etc when setting backdrops etc.

We're using lots of small windows, like gmc does, which should give better
interoperability with other programs. You do need a GNOME-compliant window
manager though if you want clicks on the background to be handled by the
filer, but it's still useable without.

> Would changing the panel to be more pinboard-like alter anything for the
> user, or just make future programming easier?

The differences would be:

- The panel setup would be stored in a file in Choices like the pinboard,
  rather than as a directory. There would then be no need for Refresh,
  Open As Directory or Show Hidden on the menu. This also means less
  clutter in users' home directories.

- The little symlink arrows would disappear, which would look much better.

- You could lay things out differently - eg, putting drives on the left
  and apps on the right (depending on how we implement it - need to
  think about this).

- Mount points could go there, because they wouldn't have to be symlinks.

- A system admin could use Choices to make a system-wide default panel.

> ps. feature request: Any chance of gnome applets working on the
> iconbar? That would add another nice functionality of RiscOS to ROX.

Depends how they communicate with the filer. Does anyone know how it
works? If it's via X-properties then we can probably support them; if it's
CORBA then probably not...

AfterStep dock applets might be easier to support though...

> I was thinking of starting my coding life in Linux by reproducing the
> mode-changer thing RiscOS has, although I'm not sure how feasable that
> would be. I haven't time at the moment, however :o(

I don't think it's possible without resetting the X server. Unless you
just mean simulating the alt-kp-plus and alt-kp-minus functions...

But, if anyone wants a list of simple utils that need writing, just let me
know ;-)


Thomas Leonard
-- 
ta...@us...
The ROX desktop (free/GPL) : http://rox.sourceforge.net

[rox-devel] New options

[Thomas L. <ta...@le...>]

On Fri, 4 Aug 2000, James Kermode wrote:

> I'm pleased with the new pinboard text drawing options,
> though I think it'd be even better if you could also specify
> the text colour to be used as an option, so that you could
> choose a colour which contrasts well with your background
> image. What does anyone think?

OK, I've added this and committed it to CVS.

I've also made the timeout for the spring-open feature configurable.

The other change is the use of the short form of --version in install.sh
and a configure check for unsetenv() as not everyone has it (Mattias
Engdegard).

The CVS snapshot should automatically update every 24 hours now - let me
know if it stops working....


Thomas Leonard
-- 
ta...@us...
The ROX desktop (free/GPL) : http://rox.sourceforge.net

Re: [rox-devel] icons

[Garrett C <ga...@cs...>]

On Sun, 6 Aug 2000, Thomas Leonard wrote:

> On Sat, 5 Aug 2000, Garrett C wrote:
> 
> > I was wondering if there was any way in ROX to set a directory or link
> > icon to a specific picture.  For example, on my icon bar I would like
> > different icons for the cdrom, windows drive, home directory and floppy
> > drive.
> 
> Not at the moment. In fact, you can't even have mount points on the
> iconbar at the moment. The whole panel thing should probably be changed so
> that it acts like the pinboard - ie, stored in a config file rather than
> as a directory. Then you'd also be able to set up a site-wide default
> panel :-)
> 
> Do we need icons for all directories or just mount points? If the latter,
> we can just search for icons called 'mounted_floppy.xpm' and
> 'unmounted_floppy.xpm' in Choices, where 'floppy' is the leafname of the
> mount point. The other option is to (finally!) implement the pattern-
> matching-on-directories feature. Could be a bit slow, though...
> 
> What would people prefer?
> 

How about the first idea as default, dealing with mount points and
anything on the panel.

However, you could implement the matching-on-directories feature as an
option so people could define icons for anything if they wanted.  This
would override the previous idea. 

I was looking at a few screenies of Nautilus the other day, and I noticed
what may be a similar feature, but extending it somewhat. Directories and
files appeared to have extra images overlaid in some cases, to indicate
properties such as 'draft', or 'proof-read'.  Having the ability to
overlay specified icons on certain files/directories could be a neat
feature.

Chris

Re: [rox-devel] icons

[Thomas L. <ta...@le...>]

On Sat, 5 Aug 2000, Garrett C wrote:

> I was wondering if there was any way in ROX to set a directory or link
> icon to a specific picture.  For example, on my icon bar I would like
> different icons for the cdrom, windows drive, home directory and floppy
> drive.

Not at the moment. In fact, you can't even have mount points on the
iconbar at the moment. The whole panel thing should probably be changed so
that it acts like the pinboard - ie, stored in a config file rather than
as a directory. Then you'd also be able to set up a site-wide default
panel :-)

Do we need icons for all directories or just mount points? If the latter,
we can just search for icons called 'mounted_floppy.xpm' and
'unmounted_floppy.xpm' in Choices, where 'floppy' is the leafname of the
mount point. The other option is to (finally!) implement the pattern-
matching-on-directories feature. Could be a bit slow, though...

What would people prefer?


Thomas Leonard
-- 
ta...@us...
The ROX desktop (free/GPL) : http://rox.sourceforge.net

[rox-devel] icons

[Garrett C <ga...@cs...>]

Hi,

I was wondering if there was any way in ROX to set a directory or link
icon to a specific picture.  For example, on my icon bar I would like
different icons for the cdrom, windows drive, home directory and floppy
drive.

Cheers,

Chris.

[rox-devel] long file names

[Garrett C <ga...@cs...>]

Hi,

I noticed that filenames too long to fit into the space are now using a
red cursor after the last visable letter.  I was wondering if it would be
feasible to have the text scroll to the left if the mouse was held over
the cursor, allowing the full file name to be read, or possibly adding an
option for filenames to take up more than one line?

Incidentally, I have only just installed 0.1.26, and want to say what a
pleasant addition the auto-popup of directories is when moving files. Its
something the original RiscOS should have had.

Any chance of the popup time being configurable though? Its a little slow
for me at the moment.

Another option I thought might be good is the highlighting of icons AS you
drag a box around them, so its clear what you have caught in the box.

And finally, how about a 'set directory as panel' option in the menu?

Cheers,

Chris

[rox-devel] Pinboard Icons

[James K. <ja...@ke...>]

Okay, I've sorted out the pinboard icon thing. It was just
a matter of configuring Window Maker properly, to tell it
that ROX-Pinboard windows should stay at the bottom and not
be added to the window list. Sorry!

-- 
James Kermode
ja...@ke...
http://www.kerm.freeserve.co.uk