Re: [Screem-devel] some screem UI thoughts

[Sven Salzwedel <sven@mo...>]

Hi,

Am Sa, den 13.03.2004 schrieb David A Knight um 19:03:
> If you read back through the list archives I want to get rid of it,
just
> undecided on if the functionality should be moved elsewhere or if the
> menuitems are sufficient.

Yes, I've read, but too late :) I don't think that it is needed to place
it elsewhere, since they are accessible via menu. Some shortcuts would
be good, though.

> the treeview is just under developed at the moment, think something
> along the lines of mlview as to what it is intended to be.  The tree
> view in the notebook is just meant as a quick overview.

Uh, I just found out that they do not show the same when using real
(x)html files. Normally I have PHP files open, so that this treeview
shows only crap for me (this is no complain :).

> To be honest I never use it either, the initial intention with screem
> was to embed mozilla in there, but the licensing still isn't sorted
out
> in mozilla to be all GPL / compatible.  Screem includes some FSF
> copyrighted code used in sitecopy, so adding an exception to allow
> linking with mozilla like galeon/epiphany do isn't an option.

Well, for the time until the gre is embeddable I'd suggest to leave it
out, since you don't use it too.

> Tabs at the top have been made the default in cvs.  I've made this
> configurable by setting /apps/screem/ui/tab_position which defaults to
> "top".  other valid settings being "bottom", "left", and "right".  I
> have no intention to provide a ui to this option though.

I think that's no problem when the default is "top", thanks.

> My personal view on close buttons on tabs are that they are useless
and
> only clutter up the ui, tabs can be closed with ctrl+w anyway, or via
> the close file menu item, or via the right click popup menu on them.

Yes, I know. The problem is that you have to do one more click when
using the main or tab menu. So using this close button is much more
convenient when you already use the mouse. Thanks again for adding the
button.

> To take this consistancy further should the tabs also have an icon
> showing the document type just like gedit, and epiphany with favicons?

Yes, I'd welcome this. It is easier to distinguish the file you want to
select when you have a lot of files open.

Well, is it possible to highlight the background of the current line
where the cursor is placed? I've seen this in some KDE editors and some
other windows editor. This really helpful to find the line I was
editing, for example before switching to another desktop. It is
sometimes not easy find that little blinking cursor, especially when you
have drunk some beer and it's 4 o'clock in the morning :). Is this
possible with gtksourceview in screem or should I go to their bugzilla?

Regards,

Sven

PS: Unfortunately sent it to you personally first, sent it now to list
O.o
--=20
may the source be with you

Re: [Screem-devel] some screem UI thoughts

[Sven Salzwedel <sven@mo...>]

Hi,

Am Sa, den 13.03.2004 schrieb David A Knight um 19:03:
> If you read back through the list archives I want to get rid of it,
just
> undecided on if the functionality should be moved elsewhere or if the
> menuitems are sufficient.

Yes, I've read, but too late :) I don't think that it is needed to place
it elsewhere, since they are accessible via menu. Some shortcuts would
be good, though.

> the treeview is just under developed at the moment, think something
> along the lines of mlview as to what it is intended to be.  The tree
> view in the notebook is just meant as a quick overview.

Uh, I just found out that they do not show the same when using real
(x)html files. Normally I have PHP files open, so that this treeview
shows only crap for me (this is no complain :).

> To be honest I never use it either, the initial intention with screem
> was to embed mozilla in there, but the licensing still isn't sorted
out
> in mozilla to be all GPL / compatible.  Screem includes some FSF
> copyrighted code used in sitecopy, so adding an exception to allow
> linking with mozilla like galeon/epiphany do isn't an option.

Well, for the time until the gre is embeddable I'd suggest to leave it
out, since you don't use it too.

> Tabs at the top have been made the default in cvs.  I've made this
> configurable by setting /apps/screem/ui/tab_position which defaults to
> "top".  other valid settings being "bottom", "left", and "right".  I
> have no intention to provide a ui to this option though.

I think that's no problem when the default is "top", thanks.

> My personal view on close buttons on tabs are that they are useless
and
> only clutter up the ui, tabs can be closed with ctrl+w anyway, or via
> the close file menu item, or via the right click popup menu on them.

Yes, I know. The problem is that you have to do one more click when
using the main or tab menu. So using this close button is much more
convenient when you already use the mouse. Thanks again for adding the
button.

> To take this consistancy further should the tabs also have an icon
> showing the document type just like gedit, and epiphany with favicons?

Yes, I'd welcome this. It is easier to distinguish the file you want to
select when you have a lot of files open.

Well, is it possible to highlight the background of the current line
where the cursor is placed? I've seen this in some KDE editors and some
other windows editor. This really helpful to find the line I was
editing, for example before switching to another desktop. It is
sometimes not easy find that little blinking cursor, especially when you
have drunk some beer and it's 4 o'clock in the morning :). Is this
possible with gtksourceview in screem or should I go to their bugzilla?

Regards,

Sven

PS: Unfortunately sent it to you personally first, sent it now to list
O.o
--=20
may the source be with you

Re: [Screem-devel] some screem UI thoughts

[Andy Korvemaker <lists.gnome@ak...>]

On Sun, 14 Mar 2004 15:23:50 +0100, "Sven Salzwedel" <sven@...>
said:
> Well, for the time until the gre is embeddable I'd suggest to leave it
> [the preview pane] out, since you don't use it too.

For what it's worth, I use it. It's not a critical feature, but I do like
it. Testing pages with gtkhtml can give an idea what the page may look
like on less robust browsers. I find it a useful feature for testing
usability and accessibility.

andy